Software- und Systementwurf - Softwarearchitektur -

Transkript

1 Software- und Systementwurf - Softwarearchitektur - Software Engineering 1 WS 2011/2012 Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig (mit Folien von Prof. B. Rumpe)

2 Überblick Softwareentwurf Ziele Entwurfsprinzipien Architekturentwurf Architekturmuster Service-orientierte Architekturen Dr. Ina Schaefer Software Engineering 1 Seite 2

3 Software-Entwurf Ausgangspunkt: Systemspezifikation (Pflichtenheft) Ziel: Vom WAS" zum WIE": Vorgabe für Implementierung Zentrale Begriffe: Subsystem in sich geschlossen eigenständig funktionsfähig mit definierten Schnittstellen besteht aus Komponenten Komponente Baustein für ein Softwaresystem (z.b. Modul, Klasse, Paket) benutzt andere Komponenten wird von anderen Komponenten benutzt kann auch aus Unterkomponenten bestehen Dr. Ina Schaefer Software Engineering 1 Seite 3

4 Von der Analyse zum Entwurf Analyse! Anforderungs-" Ermittlung" Anforderungs-" Spezifikation" (Lastenheft)" System-" Spezifikation" (Pflichtenheft)" System-" Modellierung" Entwurf! Dr. Ina Schaefer Software Engineering 1 Seite 4

5 Gliederung des Entwurfsprozesses Architekturentwurf Subsystem-Spezifikation Schnittstellen-Spezifikation Gesamtstruktur des Systems (Grobentwurf) Komponentenentwurf Datenstrukturentwurf Algorithmenentwurf Detailstruktur des Systems (Feinentwurf) Grobentwurf: weitgehend unabhängig von Implementierungssprache Feinentwurf angepasst an die Implementierungssprache und Plattform Dr. Ina Schaefer Software Engineering 1 Seite 5

6 Arbeitsteilung beim Entwurf Architekturentwurf Entwurf Subsystem 1 Entwurf Schnittstelle 1 2 Entwurf Subsystem 2 Entwurf Schnittstelle 2... Entwurf Subsystem... Entwurf der Komponenten Dr. Ina Schaefer Software Engineering 1 Seite 6

7 Kriterien für "guten" Entwurf Korrektheit Erfüllung der Anforderungen Wiedergabe aller Funktionen des Systemmodells Sicherstellung der nichtfunktionalen Anforderungen Verständlichkeit & Präzision Gute Dokumentation Anpassbarkeit Hohe Kohäsion innerhalb der Komponenten Schwache Kopplung zwischen den Komponenten Wiederverwendung Diese Kriterien gelten auf allen Ebenen des Entwurfs (Architektur, Subsysteme, Komponenten). Dr. Ina Schaefer Software Engineering 1 Seite 7

8 Kohäsion Kohäsion ist ein Maß für die Zusammengehörigkeit der Bestandteile einer Komponente. Hohe Kohäsion einer Komponente erleichtert Verständnis, Wartung und Anpassung. Frühere Ansätze zur Kohäsion wie: ähnliche Funktionalitäten zusammenfassen führten nicht unbedingt zu stabiler Systemstruktur Bessere Kohäsion wird erreicht durch: Prinzipien der Objektorientierung (Datenkapselung) Einhaltung von Regeln zur Paketbildung Verwendung geeigneter Muster zu Kopplung und Entkopplung "Kohärente" Klasse: Es gibt keine Partitionierung in Untergruppen von zusammengehörigen Operationen und Attributen Dr. Ina Schaefer Software Engineering 1 Seite 8

9 Kopplung Kopplung ist ein Maß für die Abhängigkeiten zwischen Komponenten. Geringe Kopplung erleichtert die Wartbarkeit und macht Systeme stabiler. Arten der Kopplung: Datenkopplung (gemeinsame Daten) Schnittstellenkopplung (gegenseitiger Aufruf) Strukturkopplung (gemeinsame Strukturelemente) Reduktion der Kopplung: Kopplung kann nie auf Null reduziert werden! Schnittstellenkopplung ist akzeptabel, da höhere Flexibilität Datenkopplung vermeiden! aber durch Objektorientierung meist gegeben Strukturkopplung vermeiden! z.b. keine Vererbung über Paketgrenzen hinweg Entkopplungsbeispiel: getter/setter-methoden statt direkter Attributzugriff Dr. Ina Schaefer Software Engineering 1 Seite 9

10 Interne Wiederverwendung Interne Wiederverwendung (reuse) ist ein Maß für die Ausnutzung von Gemeinsamkeiten zwischen Komponenten Reduktion der Redundanz Erhöhung der Stabilität und Ergonomie Hilfsmittel für Wiederverwendung: im objektorientierten Entwurf: Vererbung, Parametrisierung im modularen und objektorientierten Entwurf: Module/Objekte mit allgemeinen Schnittstellen (Interfaces) Aber: Wiederverwendung kann die Kopplung erhöhen: Schnittstellenkopplung und Strukturkopplung Dr. Ina Schaefer Software Engineering 1 Seite 10

11 Entwurfsschritte Analyse! Anforderungs-" Ermittlung" Anforderungs-" Spezifikation" (Lastenheft)" System-" Spezifikation" (Pflichtenheft)" System-" Modellierung" Architektur-" Spezifikation" Architektur-" Entwurf" Klassen- bzw. Modul-" Spezifikationen" Entwurf! Detail-" Entwurf" Dr. Ina Schaefer Software Engineering 1 Seite 11

12 Architekturentwurf im Kontext der SW-Entwicklung Anforderungsanalyse, Domänenanalyse" Entwurf der Softwarearchitektur" Entwurf der Systemarchitektur, Auswahl der Hardware" Feindesign, Programmierung, Integration, Testen, Auslieferung" Dr. Ina Schaefer Software Engineering 1 Seite 12

13 Softwarearchitektur in der Praxis Architekturspezifikation wird zu oft nicht als separates Dokument gefordert. Häufig wird funktionale Spezifikation und Architekturspezifikation in einem Dokument realisiert. denn WAS zu spezifizieren, ohne auf grobe Strukturen des WIE einzugehen ist oft nicht möglich. Dennoch: die grobe Systemarchitektur wird der Entwurfs-Aktivität zugeordnet Ist Hardware involviert (Steuergeräte im Auto, Telekommunikations- Anlagen etc.), so wird oft bereits dadurch eine physische Architektur vorgegeben. (Sinnvoll: Architekturskizzen bereits in der Anforderungsbeschreibung.) Logische Systemarchitektur und physische Architektur sind nicht notwendig identisch. Dr. Ina Schaefer Software Engineering 1 Seite 13

14 Beispielarchitektur Dr. Ina Schaefer Software Engineering 1 Seite 14

15 4+1 Sichten -Modell der Softwarearchitektur Logische Sicht Entwurfssicht Szenarien Ablaufsicht Physikalische Sicht Philippe Kruchten, The 4+1 view model of architecture, IEEE Software, November 1995, 12(6), pp (Verwendung im Rational Unified Process - RUP) Dr. Ina Schaefer Software Engineering 1 Seite 15

16 Bestandteile der 4+1 Sichten Logische Sicht Klassenmodell Verfeinerung des Analysemodells Ablaufsicht Prozesse Koordination Szenarien Use-Cases Entwurfssicht Subsysteme Schnittstellen Grobentwurf Physikalische Sicht Komponenten Hardwaresysteme Netze Feinentwurf Dr. Ina Schaefer Software Engineering 1 Seite 16

17 Primäre Zielgruppe und Aufgabe der Sichten Logische Sicht Endanwender Entwurfssicht Programmierung Wartung Grobentwurf Ablaufsicht System-Integratoren (Performanz, Durchsatz...) Physikalische Sicht Kommunikation Verteilung Auslieferung, Installation Feinentwurf Dr. Ina Schaefer Software Engineering 1 Seite 17

18 Blockdiagramme Blockdiagramme sind kein Bestandteil von UML! (Gleichwertige Notation in UML: Implementierungsdiagramm) Blockdiagramme sind ein verbreitetes Hilfsmittel zur Skizzierung der logischen Struktur einer Systemarchitektur. Schnittstelle Subsystem umfasst Objekte bestimmter Klassen." Schnittstelle ist klar definiert. (z.b. Aufrufschnittstelle, Kommunikationsprotokoll)" Subsystem Umfassendes Subsystem Dr. Ina Schaefer Software Engineering 1 Seite 18

19 UML Komponentendiagramme Das Komponenten-Diagramm stellt die (logischen) Komponenten des Systems und deren Schnittstellen (Ports) dar. Architektur: Anwendung UI Bank UI = User Interface = Benutzerschni7stelle/ Benutzeroberfläche GUI = Graphical User Interface = grafische Benutzerschni7stelle Dr. Ina Schaefer Software Engineering 1 Seite 19

20 Komponenten Name der Komponente HTTP Webservice «component» WebInterface optionaler grafischer Stereotyp Database bereitgestellte Schnittstelle benötigte Schnittstelle Dr. Ina Schaefer Software Engineering 1 Seite 20

21 Komposition von Komponenten Port! benötigte! Schnittstelle! Zusammengesetzte! Komponente! Komponente! A" bereitgestellte! Schnittstelle! D" B" C" D" A" analoges Blockdiagramm B" C" Dr. Ina Schaefer Software Engineering 1 Seite 21

22 Konfigurationsdiagramme Konfigurationsdiagramme sind (noch) nicht Bestandteil von UML! Konfigurationsdiagramme sind das meistverbreitete Hilfsmittel zur Beschreibung der physikalischen Verteilung von System- Komponenten. Rechner, Knoten Lokales Kommunikationsnetz Speicherndes System Datenkommunikations- Netz Dr. Ina Schaefer Software Engineering 1 Seite 22

23 UML: Verteilungsdiagramm engl.: deployment diagram zeigt die physische Verteilung von Systemen Node (Knoten) <<processor>>" Client" Stereotypen kennzeichnen die Arten von Knoten <<network>> local network" <<processor>>" Server 1" <<processor>>" Server 2" A" B" Komponenten können zugeordnet werden Dr. Ina Schaefer Software Engineering 1 Seite 23

24 Beispiel Terminverwaltung PC1"..." PCn" PDA1" PDAm" Physikalische! Konfiguration" Termin-" Server" Anzeigetafel-" Steuerung" PC Client" PDA Client" Blockdiagramm" PDA Sync" Termin-Manager" Daten-" Export" Termin-Datenbank" Dr. Ina Schaefer Software Engineering 1 Seite 24

25 Kriterien für guten Entwurf Wie bereits diskutiert ist auf Kohäsion und Kopplung zu achten: Hohe Kohäsion: Kohäsion = "Zusammenhalt" Die Dinge sollen in Struktureinheiten zusammengefasst werden, die inhaltlich zusammengehören. Niedrige Kopplung: Kopplung = Abhängigkeiten Einzelne Struktureinheiten sollen möglichst unabhängig voneinander sein. Daneben allgemeine Eigenschaften, z.b.: Korrektheit, Anpassbarkeit, Verständlichkeit, Ressourcenschonung Dr. Ina Schaefer Software Engineering 1 Seite 25

26 Hohe Kohäsion und Niedrige Kopplung Subsystem A! " (z.b. Benutzungs-" oberfläche)" Hohe Kohäsion: Subsystem B darf keine Information und Funktionalität enthalten, die zum Zuständigkeitsbereich von A gehört und umgekehrt. Subsystem B!! (z.b. fachlicher Kern)" Niedrige Kopplung: Es muss möglich sein, Subsystem A weitgehend auszutauschen oder zu verändern, ohne Subsystem B zu verändern. Änderungen von Subsystem B sollten nur möglichst einfache Änderungen in Subsystem A nach sich ziehen. Dr. Ina Schaefer Software Engineering 1 Seite 26

27 Qualitätssicherung mittels Szenarien Szenarien (für Anwendungsfälle) sind von zentraler Bedeutung: Integration der verschiedenen Sichten Kriterium für Architekturbewertung (Auswahl alternativer Muster) Qualitätssicherung (Review) Bewertung für Softwarearchitekturen: Architektur(en) festlegen Im Architekturentwurf: Alternativen Bei der abschließenden Qualitätssicherung: gewählte Architektur Szenarien durchspielen Direkte Szenarien : Auf der Architektur gut realisierbar Indirekte Szenarien : Nur nach Architekturerweiterung realisierbar Architekturen bewerten nach: Anzahl der direkten Szenarien Aufwand zur Modifikation für indirekte Szenarien Abschätzung der Effizienz Dr. Ina Schaefer Software Engineering 1 Seite 27

28 Architekturmuster für die Entwurfssicht Struktursicht der Architektur: Zerlegung in Subsysteme eigenständiger Funktionalität Keine Aussage über physikalische Verteilung Darstellung meist durch Blockdiagramme: Subsystem Datenfluss-Schnittstelle Aufrufschnittstelle Muster (Architekturmuster, Architekturstile): Kette (Chain) Schichten Interpreter Model-View-Controller (MVC) Dr. Ina Schaefer Software Engineering 1 Seite 28

29 Architekturmuster Pipes & Filters Phase 2.1 Phase 1 Phase 3 Phase 2.2 Zwischenprodukt 1.1 Zwischenprodukt 1.2 Zwischenprodukt 2.1 Zwischenprodukt 2.2 Deutsch auch Kette Inkrementelle oder phasenweise Verarbeitung Beispiele: UNIX pipes Batch-sequentielle Systeme Compiler-Grundstruktur Dr. Ina Schaefer Software Engineering 1 Seite 29

30 Beispiel: Compiler-Architektur Instanz von Pipes & Filters : Kombination von Ketten Quell- Programm Tokens Syntaxbaum Ziel- Programm Scanner Parser Code- Generator Symboltabelle Fehlermeldungen Fehler- Ausgabe Fehlermeldungen Dr. Ina Schaefer Software Engineering 1 Seite 30

31 Architekturmuster "Schichten" Benutzer Schicht 2 Schicht 1 Systemkern Jede Schicht bietet Dienste (nach oben) und nutzt Dienste (von unten) Beispiele: Kommunikationsprotokolle Datenbanksysteme, Betriebssysteme Dr. Ina Schaefer Software Engineering 1 Seite 31

32 Beispiel: 3-Schichten-Referenzarchitektur Benutzungsschnittstelle Fachlicher Kern Persistenzschicht Entwurfsregeln: Benutzungsschnittstelle greift nie direkt auf Datenhaltung zu. Persistenzschicht verkapselt Zugriff auf Datenhaltung, ist aber nicht identisch mit dem Mechanismus der Datenhaltung (z.b. Datenbank). Fachlicher Kern basiert auf dem Analyse-Modell Erlaubt das Aufsetzen von interaktiven, batch, etc. Benutzerschnittstellen und den Austausch von Datenbanken Dr. Ina Schaefer Software Engineering 1 Seite 32

33 Variante: 3-Schichten-Referenzarchitektur Benutzungsschnittstelle Fachlicher Kern Systemfunktionen Persistenzschicht Beispiele für Systemfunktionen: Verkapselung von plattformspezifischen Funktionen Schnittstellen zu Fremdsystemen Dr. Ina Schaefer Software Engineering 1 Seite 33

34 Architekturmuster "Interpreter" Benutzer Programm Abstrakte Maschine Basissystem Schichtenarchitektur mit Parametrisierung Beispiele: Portable Sprachimplementierung (z.b. Java Virtual Machine) Emulation von Systemarchitekturen (z.b. Soft Windows) Dr. Ina Schaefer Software Engineering 1 Seite 34

35 Model-View-Controller Controller (Programmsteuerung) Wählt View aus Bildet Nutzereingaben auf Modelupdates ab View (Darstellung der Daten) Fordert Update des Models an Sendet Nutzereingaben an Controller Model (Datenhaltung) Benachrichtigt über Änderungen Dr. Ina Schaefer Software Engineering 1 Seite 35

36 Architekturmuster für die physikalische Sicht Physikalische Sicht der Architektur: Aufteilung der Funktionalität auf Knoten (Rechner) eines Netzes Darstellung meist durch Konfigurationsdiagramme: Knoten Kommunikation Muster (Verteilungsmuster): Zentrales System Client/Server: Two-Tier (Thin-Client, Fat-Client) Three-Tier (GUI; Applikationskern, Datenhaltung) Föderation Cloud Computing Dr. Ina Schaefer Software Engineering 1 Seite 36

37 Verteilungsmuster "Zentrales System" "Unintelligentes" Terminal Zentrales System Beispiele: Klassische Großrechner-("Mainframe"-)Anwendungen Noch einfachere Variante: Lokale PC-Anwendungen (identifizieren Zentrale und Terminal) Dr. Ina Schaefer Software Engineering 1 Seite 37

38 Verteilungsmuster "Client/Server" "Intelligenter" Client Server Sogenannte "Two-Tier" Client/server-Architektur Andere Namen: "Front-end" für "Client", "Back-end" für "Server" Client: Benutzungsschnittstelle Einbindung in Geschäftsprozesse Entkoppelt von Netztechnologie und Datenhaltung Server: Datenhaltung, evtl. Fachlogik Dr. Ina Schaefer Software Engineering 1 Seite 38

39 "Thin-Client" und "Fat-Client" Thin-Client: Nur die Benutzungsschnittstelle auf dem Client-System Ähnlich zu Zentralem System, aber oft Download- Mechanismen Anwendungen: "Screen-Scraping" (Umsetzung traditioneller Benutzungsschnittstellen in moderne Technologie) Fat-Client: Teile der Fachlogik (oder gesamte Fachlogik) auf dem Client- System Hauptfunktion des Servers: Datenhaltung Entlastung des Servers Zusätzliche Anforderungen an Clients (z.b. Installation von Software) Dr. Ina Schaefer Software Engineering 1 Seite 39

40 Verteilungsmuster "Three-Tier Client/Server" "Intelligenter" Client Anwendungs- Server Server Client: Benutzungsschnittstelle evtl. Fachlogik Anwendungsserver: evtl. Fachlogik Verteilung von Anfragen auf verschiedene Server Server: Datenhaltung, Rechenleistung etc. Kommunikation unter Servern meist breitbandig. Dr. Ina Schaefer Software Engineering 1 Seite 40

41 Verteilungsmuster "Föderation" Knoten 1 Knoten 2 Knoten 5 Knoten 3 Knoten 4 Gleichberechtigte Partner (peer-to-peer) Unabhängigkeit von der Lokation und Plattform von Funktionen Verteilte kommunizierende Objekte Dr. Ina Schaefer Software Engineering 1 Seite 41

42 Cloud Computing Abstraktion von konkreten IT-Resourcen (z. B. Rechenkapazität, Datenspeicher, Netzwerkkapazitäten oder auch fertige Software) Resourcen werden dynamisch nach Bedarf zur Verfügung gestellt. Client Client Dienst Dienst Dienst Client Client Dr. Ina Schaefer Software Engineering 1 Seite 42

43 Cloud Computing (2) Üblicherweise Unterscheidung von 3 Ebenen der Cloud-Dienste: Infrastructure as a Service (IaaS): Zugang zu virtualisierten Hardware-Ressourcen, wie Rechnern, Netzwerken und Speicher. Platform as a Service (PaaS): Zugang zu Programmierungs- oder Laufzeitumgebungen mit flexiblen, dynamisch anpassbaren Rechen- und Datenkapazitäten. Entwicklung eigener Software-Anwendungen innerhalb einer Softwareumgebung, die vom Dienstanbieter (Service Provider) bereitgestellt und unterhalten wird. Software as a Service (SaaS) oder Software on demand: Zugang zu Software-Bibliotheken und Anwendungsprogrammen. Dr. Ina Schaefer Software Engineering 1 Seite 43

44 Architekturmuster der Ablaufsicht Ablaufsicht der Architektur: Definition nebenläufiger Systemeinheiten (z.b. Prozesse) Steuerung der Abfolge von Einzelfunktionen Synchronisation und Koordination Reaktion auf externe Ereignisse Darstellung z.b. durch Sequenzdiagramme Muster (Steuerungsmuster): Zentrale Steuerung Call-Return Master-Slave Ereignis-Steuerung Selective Broadcast Interrupt Dr. Ina Schaefer Software Engineering 1 Seite 44

45 Steuerungsmuster "Call-Return" Hauptprogramm Unterprogramm 1 Unterprogramm 1.1 Unterprogramm 1.2 Dr. Ina Schaefer Software Engineering 1 Seite 45

46 Steuerungsmuster "Master-Slave" Manager Benutz.- oberfläche Sensor Aktuator Dr. Ina Schaefer Software Engineering 1 Seite 46

47 Steuerungsmuster "Selective Broadcast" Event Handler Subsystem 1 Subsystem 2 Subsystem 3 Ereignis e e Ereignis e' e' e e' e e' Dr. Ina Schaefer Software Engineering 1 Seite 47

48 Steuerungsmuster "Interrupt" Interrupt Dispatcher Handler 1 Handler 2 e Prozess 2 e Prozess 1 Verwendet Interrupt-Vektor Dr. Ina Schaefer Software Engineering 1 Seite 48

49 Zusammenfassung Architekturmuster Architekturmuster beschreiben erprobte Strukturierungsformen für die Architektur eines Systems Architekturmuster beschreiben: Entwurfsstruktur physikalische Verteilung Kommunikationsformen und protokolle Schichtenbildung ist ein mächtiges Strukturierungsmittel Dr. Ina Schaefer Software Engineering 1 Seite 49

50 Service-orientierte Architektur Die Service-orientierte Architektur (SOA) ist ein Architekturparadigma mit folgenden Zielen: Erleichterung der Entwicklung von großen Unternehmenssystemen Orientierung an Geschäftsprozessen Integration von heterogenen Anwendungen Bessere Anpassbarkeit, Erweiterbarkeit und Skalierbarkeit Bessere Weiterentwickelbarkeit und Wartbarkeit Dr. Ina Schaefer Software Engineering 1 Seite 50

51 Begriffsklärung A service oriented architecture is a form of distributed system architecture. It consists of a set of components (services) which can be invoked, and whose interface descriptions can be published and discovered. A service is an abstract resource that represents a capability of performing tasks that form a coherent functionality from the point of view of provider and requester entities. [nach W3C, 2004] Dr. Ina Schaefer Software Engineering 1 Seite 51

52 Services Ein Service kapselt Zugriff auf die Funktionen und Daten einer oder mehrerer Applikationen und erbringt bestimmte Leistung gemäß der Service-Spezifikation. Service-Spezifikation: Servicename und Operationsnamen Ein- und Ausgabedaten mit Typen Beschreibung der Funktionalität (meist textuell) Randbedingungen (Vor- und Nachbedingungen, Invarianten) Nicht-funktionale Eigenschaften (z.b. Performance) ggf. weitere Informationen (z.b. Release, Herkunft,...) Dr. Ina Schaefer Software Engineering 1 Seite 52

53 Verwendung von Services Service Provider (Anbieter): Bietet die Möglichkeit, Funktionen gemäß Spezifikation zu nutzen Implementierung des Services unter Einhaltung der Spezifikation austauschbar Service User (Nutzer): Dem Service Provider ggf. unbekannt Kann Service auch anders nutzen, als vom Provider vorgesehen Kann Funktion auch im Auftrag weiterer Nutzer ausführen Dr. Ina Schaefer Software Engineering 1 Seite 53

54 Service Directory Aufgaben des Service Directory (Verzeichnis): Zentrale Verwaltung von Services Publikation von Service-Spezifikationen Kategorisierung von Services Schnittstellen für Suche nach Services Dr. Ina Schaefer Software Engineering 1 Seite 54

55 Referenzarchitektur Service User ➍ Spezifikation abfragen ➎ Service nutzen ➎ Service Provider ➋ Service suchen ➌ Spezifikation liefern ➊ Spezifikation publizieren Service Directory SOA-Dreieck Dr. Ina Schaefer Software Engineering 1 Seite 55

56 Dr. Ina Schaefer Software Engineering 1 Seite 56 5 Web Services Service User SOAP (über HTTP/SMTP) Service Provider (WDSL) Service Directory (UDDI) SOAP = Simple Object Access Protocol WDSL = Web Service Description Language UDDI = Universal Description Discovery and Integration

57 Designprinzipien Schnittstellenorientierung: Spezifikation abstrahiert von Implementierung. Interoperabilität: Einheitliche Kommunikationsstandards Modularität: Hohe Kohäsion im Service Niedrige Kopplung zwischen Services Bedarfsorientierung: Leistungsumfang entspricht Prozessaktivitäten. Dr. Ina Schaefer Software Engineering 1 Seite 57 5

58 Zusammenfassung Softwareentwurf Ziele und Tätigkeiten Architekturentwurf Prinzipien und Ziele 4-Sichten-Modell der Softwarearchitektur Architekturmuster für Entwurfssicht Verteilungssicht Ablaufsicht Grundbegriffe der Service-orientierten Architekturen Dr. Ina Schaefer Software Engineering 1 Seite 58