Softwaretechnik – Strukturen und Muster
Softwaretechnik – Strukturen und Muster Karsten Weicker, Nicole Weicker HTWK Leipzig, FHTW Berlin
Psychiatrist: There seems to be a definite pattern emerging. And, of course, this pattern, once isolated, can be coped with. Recognize the problem, and you are halfway on the road to its, uh, its solution. (Harold and Maude, 1971) Karsten Weicker, Nicole Weicker
1/ 1
Softwaretechnik – Strukturen und Muster Muster und Strukturen
Muster und Strukturen I
Analysemuster in der Spezifikation ⇒ Schreibweisen f¨ur typische Situationen
Karsten Weicker, Nicole Weicker
2/ 1
Softwaretechnik – Strukturen und Muster Muster und Strukturen
Muster und Strukturen I
I
Analysemuster in der Spezifikation ⇒ Schreibweisen f¨ur typische Situationen Architekturprinzipien I Prinzipien/ Gesetze, was gute Architekturen sind
Karsten Weicker, Nicole Weicker
2/ 1
Softwaretechnik – Strukturen und Muster Muster und Strukturen
Muster und Strukturen I
I
I
Analysemuster in der Spezifikation ⇒ Schreibweisen f¨ur typische Situationen Architekturprinzipien I Prinzipien/ Gesetze, was gute Architekturen sind Architekturmuster I Entwurfsmuster (Feinentwurf)
Karsten Weicker, Nicole Weicker
2/ 1
Softwaretechnik – Strukturen und Muster Muster und Strukturen
Muster und Strukturen I
I
I
I
Analysemuster in der Spezifikation ⇒ Schreibweisen f¨ur typische Situationen Architekturprinzipien I Prinzipien/ Gesetze, was gute Architekturen sind Architekturmuster I Entwurfsmuster (Feinentwurf) Konzepte in Entwurf und Implementation I grundlegende programmiersprachliche Konzepte I Konzepte, um Architekturen umzusetzen I werden in Praxis massiv genutzt I hier nur angerissen
Karsten Weicker, Nicole Weicker
2/ 1
Softwaretechnik – Strukturen und Muster Muster und Strukturen
Muster und Strukturen I
I
I
I
I
Analysemuster in der Spezifikation ⇒ Schreibweisen f¨ur typische Situationen Architekturprinzipien I Prinzipien/ Gesetze, was gute Architekturen sind Architekturmuster I Entwurfsmuster (Feinentwurf) Konzepte in Entwurf und Implementation I grundlegende programmiersprachliche Konzepte I Konzepte, um Architekturen umzusetzen I werden in Praxis massiv genutzt I hier nur angerissen Architekturstrukturen I Verfeinerung der Systemstrukturen aus Abschnitt 2
Karsten Weicker, Nicole Weicker
2/ 1
Softwaretechnik – Strukturen und Muster Muster und Strukturen
Schreibweisen im Klassendiagramm (1) Liste Liste aus mehreren gleichgearteten Elementen, feste Zuordnung
Karsten Weicker, Nicole Weicker
3/ 1
Softwaretechnik – Strukturen und Muster Muster und Strukturen
Schreibweisen im Klassendiagramm (1) Liste Liste aus mehreren gleichgearteten Elementen, feste Zuordnung
Exemplartyp Oberbegriff f¨ur mehrere Objekte einer Klasse, immer Zurodnung zu einem Oberbegriff
Karsten Weicker, Nicole Weicker
3/ 1
Softwaretechnik – Strukturen und Muster Muster und Strukturen
Schreibweisen im Klassendiagramm (2) Baugruppe Klasse besteht aus verschiedenen Instanzen einer anderen Klasse, h¨aufig: physische Komponenten
Karsten Weicker, Nicole Weicker
4/ 1
Softwaretechnik – Strukturen und Muster Muster und Strukturen
Schreibweisen im Klassendiagramm (3) St¨ uckliste Hierarchische Anordnung, in der sich Elemente aus anderen Elementen aufbauen, beliebige Tiefe
Karsten Weicker, Nicole Weicker
5/ 1
Softwaretechnik – Strukturen und Muster Muster und Strukturen
Schreibweisen im Klassendiagramm (4) Koordinator Klasse stellt semantischen Zusammenhang zwischen zwei Klasen dar, statt einer Assoziationsklasse
Karsten Weicker, Nicole Weicker
6/ 1
Softwaretechnik – Strukturen und Muster Muster und Strukturen
Schreibweisen im Klassendiagramm (4) Koordinator Klasse stellt semantischen Zusammenhang zwischen zwei Klasen dar, statt einer Assoziationsklasse
Historie Bei mehreren Vorg¨angen zu einer Klasse wird die Zeit mitprotokolliert
Karsten Weicker, Nicole Weicker
6/ 1
Softwaretechnik – Strukturen und Muster Muster und Strukturen
Schreibweisen im Klassendiagramm (5) Rollen Unterschiedliche Instanzen einer Klassen haben in verschiedenen Funktionen mit einer anderen Klasse zu tun
Karsten Weicker, Nicole Weicker
7/ 1
Softwaretechnik – Strukturen und Muster Muster und Strukturen
Schreibweisen im Klassendiagramm (6) wechselnde Rollen Historie einer Rollenverteilung wird gespeichert
Karsten Weicker, Nicole Weicker
8/ 1
Softwaretechnik – Strukturen und Muster Muster und Strukturen
Schreibweisen im Klassendiagramm (7) Gruppe Eine Gruppe setzt sich aus verschiedenen Mitgliedern zusammen, eher dynamisch
Karsten Weicker, Nicole Weicker
9/ 1
Softwaretechnik – Strukturen und Muster Muster und Strukturen
Schreibweisen im Klassendiagramm (8) Gruppenhistorie Die Zugeh¨origkeit einer Gruppe wird als Historie (¨uber einen Koordinator) gespeichert.
Karsten Weicker, Nicole Weicker
10/ 1
Softwaretechnik – Strukturen und Muster Architekturprinzipien
Architekturprinzipien I
I I I
G¨ute einer Architektur ist relativ – abh¨angig von den Anforderungen dennoch: es gibt einige allgemeine Prinzipien diese Prinzipien sollten nur bewusst missachtet werden zwei zentrale Hauptprobleme: I I
Reduktion der Komplexit¨at ¨ Erh¨ohung der Flexibilit¨at bzw. Anderbarkeit
Karsten Weicker, Nicole Weicker
11/ 1
Softwaretechnik – Strukturen und Muster Architekturprinzipien
Architekturprinzipien I
I I I
G¨ute einer Architektur ist relativ – abh¨angig von den Anforderungen dennoch: es gibt einige allgemeine Prinzipien diese Prinzipien sollten nur bewusst missachtet werden zwei zentrale Hauptprobleme: I I
Reduktion der Komplexit¨at ¨ Erh¨ohung der Flexibilit¨at bzw. Anderbarkeit
Constantine-Gesetz Eine Struktur ist best¨andig, wenn der Zusammenhang stark und die Koppelung gering ist. (nach Endres & Rombach, 2003) Karsten Weicker, Nicole Weicker
11/ 1
Softwaretechnik – Strukturen und Muster Architekturprinzipien
Prinzip der losen Kopplung I I
I
Kopplung ist die Interaktion zw. Bausteinen Arten der Kopplung: I Zugriff auf (private) Daten I Kommunikation in einer globalen Datenstruktur I Methodenaufrufe Lose Kopplung: geringstm¨ogliche Interaktion
Karsten Weicker, Nicole Weicker
12/ 1
Softwaretechnik – Strukturen und Muster Architekturprinzipien
Prinzip der losen Kopplung I I
I I
Kopplung ist die Interaktion zw. Bausteinen Arten der Kopplung: I Zugriff auf (private) Daten I Kommunikation in einer globalen Datenstruktur I Methodenaufrufe Lose Kopplung: geringstm¨ogliche Interaktion Zweck: I Komplexit¨ at gering halten I einzelne Bausteine sind leichter verst¨ andlich ¨ I lokale Anderungen sind leichter durchf¨uhrbar
Karsten Weicker, Nicole Weicker
12/ 1
Softwaretechnik – Strukturen und Muster Architekturprinzipien
Prinzip der losen Kopplung I I
I I
I
Kopplung ist die Interaktion zw. Bausteinen Arten der Kopplung: I Zugriff auf (private) Daten I Kommunikation in einer globalen Datenstruktur I Methodenaufrufe Lose Kopplung: geringstm¨ogliche Interaktion Zweck: I Komplexit¨ at gering halten I einzelne Bausteine sind leichter verst¨ andlich ¨ I lokale Anderungen sind leichter durchf¨uhrbar Vorsicht: bei zirkul¨aren Abh¨angigkeiten → Don’t call us, we call you!“ (siehe: ” Beobachtermuster sp¨ater)
Karsten Weicker, Nicole Weicker
12/ 1
Softwaretechnik – Strukturen und Muster Architekturprinzipien
Prinzip der hohen Koh¨asion I
I
I
Koh¨asion ist die Interaktion innerhalb eines Bausteins Hohe Koh¨asion: bez¨uglich der Interaktion gilt ein enger Zusammenhang aller Bestandteile des Bausteins Zweck: I
I I
alle Teile des Bausteins geh¨oren zusammen
Wechselbeziehung zu loser Kopplung wird erreicht durch: I
Abstraktion, Separation of Concerns, Information Hiding
Karsten Weicker, Nicole Weicker
13/ 1
Softwaretechnik – Strukturen und Muster Architekturprinzipien
Prinzip des Entwurfs fu¨r Ver¨anderung
I
¨ Design for Change: vorhersehbare Anderungen architektonisch vorausgeplanen ¨ Erwartbare Anderungen:
I
nicht implementierte Funktionalit¨at Unklarheiten in den Anforderungen ¨ Nicht erwartbare Anderungen:
I
I I
I
I I I
Vorsicht, falls dadurch hoher Ressourcenverbrauch
durch lose Kopplung – besonders an Hot Spots“ ” zuviel voraussehen → ein Monster“ ” Gewichtung: alle Eventualit¨aten oder handhabbar?
Karsten Weicker, Nicole Weicker
14/ 1
Softwaretechnik – Strukturen und Muster Architekturprinzipien
Separation-of-Concerns-Prinzip (1) I I I
I I
heißt etwa: Trennung von Aufgabenbereichen Ziel: Hilfestellung f¨ur die Zerlegung in Bausteine Finden von zusammengeh¨origen Teilen der Software: bestimmte Aspekte/ Aufgaben I z.B. Funktionalit¨ at, Wiederverwendung, Performanz, Logging, Sicherheit etc. → Prinzip der Modularisierung Trennung von fachlichen und technischen Teilen
Denert-Gesetz Trennnung von Interessen (separation of concerns) f¨uhrt zu Standardarchitekturen. (nach Endres & Rombach, 2003) Karsten Weicker, Nicole Weicker
15/ 1
Softwaretechnik – Strukturen und Muster Architekturprinzipien
Separation-of-Concerns-Prinzip (2) I
I
jedes Subsystem nur eine Aufgaben zur selben Zeit (z.B. Programmlogik, Pr¨asentation, Kommunikation etc.) konsequente Trennung von Interessen → Architekturen auf Standards abbildbar (Beispiel: Dreischichtenarchitektur von Denert (1991)) Nutzerschnittstelle
SW-Schnittstelle
Programmlogik
Datenbank/Dateien Karsten Weicker, Nicole Weicker
16/ 1
Softwaretechnik – Strukturen und Muster Architekturprinzipien
Information-Hiding-Prinzip (1) I I
I I
Geheimhalten von Informationen“ ” in der Modularisierung: nur Schnittstelle nach Außen sichtbar Teilaspekt: data hiding in der Software-Architektur: auch f¨ur gr¨oßere Strukturen I z.B. im Fassaden-Entwurfsmuster
Fassade
I I
Schichtenbildung wie in CORBA Black-Box-Prinzip wie in der Schnittstellenabstraktion
Karsten Weicker, Nicole Weicker
17/ 1
Softwaretechnik – Strukturen und Muster Architekturprinzipien
Information-Hiding-Prinzip (2) Parnas-Gesetz Nur Verborgenes kann ohne Risiko ver¨andert werden. (nach Endres & Rombach, 2003)
I
I I I
basiert auf Beobachtung von Entwicklern bei Philips (1972) traditioneller Ansatz: jeder → alle Entwurfsinformationen hier: je kleiner die Module, desto besser das Verst¨andnis zus¨atzlich: Zeitersparnis: nur notwendige Information
Karsten Weicker, Nicole Weicker
18/ 1
Softwaretechnik – Strukturen und Muster Architekturprinzipien
Abstraktionsprinzip I
I I
wichtige Aspekte identifizieren, unwichtige vernachl¨assigen Spezialfall des Separation of concerns In der Software-Architektur: I explizite Schnittstellen (Bsp: Header-Datei (C++)) I Trennung von Schnittstelle und Implementierung (Bsp: Java-Interfaces, s.a. Entwurfsmuster) I Liskov-Substitions-Prinzip: Vererbungen erhalten Schnittstellen I Schnittstellen-Segregation: keine zu komplexen Schnittstellen → Trennung von Schnittstellen f¨ur verschiedene Zwecke I Design-by-Contract: Vorbedingungen als Vertrag → verpflichtend f¨ur jeden Aufrufer
Karsten Weicker, Nicole Weicker
19/ 1
Softwaretechnik – Strukturen und Muster Architekturprinzipien
Modularit¨atsprinzip (1) I
I
Ziel: in sich geschlossene Systembausteine mit einfachen und stabilen architektonischen Beziehungen Kombination von I I I
I
Abstraktion Separation of Concerns und Information Hiding
Mittel zur Umsetzung I I
der losen Kopplung und hohen Koh¨asion
Karsten Weicker, Nicole Weicker
20/ 1
Softwaretechnik – Strukturen und Muster Architekturprinzipien
Modularit¨atsprinzip (2) I
Kriterien f¨ur Modularit¨at I
I
I
I
I
modulare Dekomposition des Problems: Zerlegung komplexer Probleme in unabh¨angig benutzbare kleine Bausteine modulare Komposition: Module frei zu anderen Systemen komponierbar modulare Verstehbarkeit: jedes Modul f¨ur sich verst¨andlich ¨ modulare Kontinuit¨at: kleine Anderungen in einer ¨ Anforderungsspezifikation → Anderungen in wenigen Modulen modulare Protektion: Fehler auf das Modul oder benachbarte Bausteine begrenzt
Karsten Weicker, Nicole Weicker
21/ 1
Softwaretechnik – Strukturen und Muster Architekturprinzipien
Zwei Minuten Aufgabe Diskutieren Sie nochmal kurz, welche Prinzipien was bedeuten und wie diese zusammenh¨angen. I Prinzip der losen Koppelung I Prinzip der hohen Koh¨ asion I Prinzip des Entwurfs f¨ ur Ver¨anderung I Separation-of-Concerns-Prinzip I Information-Hiding-Prinzip I Abstraktionsprinzip I Modularit¨ atsprinzip Karsten Weicker, Nicole Weicker
22/ 1
Softwaretechnik – Strukturen und Muster Architekturmuster
Entwurfsmuster Idee: grunds¨atzliche L¨osungsans¨atze in der SW-Architektur f¨ur immer wieder wiederkehrende Probleme dokumentieren. I
bestehen aus I I I I
Mustername Problembeschreibung L¨osungsbeschreibung Konsequenzen
Karsten Weicker, Nicole Weicker
23/ 1
Softwaretechnik – Strukturen und Muster Architekturmuster
Entwurfsmuster Idee: grunds¨atzliche L¨osungsans¨atze in der SW-Architektur f¨ur immer wieder wiederkehrende Probleme dokumentieren. I
bestehen aus I I I I
Mustername Problembeschreibung L¨osungsbeschreibung Konsequenzen
Gamma-Hypothese Wiederverwengung von Entw¨urfen durch Muster f¨uhrt zu einer schnelleren und besseren Wartung. (nach Endres & Rombach, 2003)
Karsten Weicker, Nicole Weicker
23/ 1
Softwaretechnik – Strukturen und Muster Architekturmuster
Entwurfsmuster (2)
I
laut einer Studie (Quelle mir unbekannt) I
I
Muster in Kommentaren dokumentiert ⇒ schnelle Wartung ⇒ korrekte Wartung Nutzung von Mustern → leichte Wartung
Karsten Weicker, Nicole Weicker
24/ 1
Softwaretechnik – Strukturen und Muster Architekturmuster
Beispiel: Observer (Beobachter) Ziel: Lose Kopplung zweier Objekte mit dem Ziel, u¨ber Ver¨anderungen zu informieren L¨osung: Entkoppelung der konkreten Objekte vom Benachrichtigungsmechanismus I einheitliche Schnittstelle f¨ ur Verwaltung der Beobachter I konkretes Daten-Handling in den implementierenden Klassen Konsequenz: Erm¨oglicht Verkn¨upfung verschiedenster Objekte Beispiel: mehrere Darstellungsformen f¨ur dieselben Daten in einer GUI Karsten Weicker, Nicole Weicker
25/ 1
Softwaretechnik – Strukturen und Muster Architekturmuster
Beispiel: Observer (Beobachter) Klassendiagramm
Karsten Weicker, Nicole Weicker
26/ 1
Softwaretechnik – Strukturen und Muster Architekturmuster
Beispiel: Observer (Beobachter) Objektdiagramm
Karsten Weicker, Nicole Weicker
27/ 1
Softwaretechnik – Strukturen und Muster Architekturmuster
Beispiel: Observer (Beobachter) Erstes Sequenzdiagramm Anmelden eines Beobachters beim Subjekt:
Karsten Weicker, Nicole Weicker
28/ 1
Softwaretechnik – Strukturen und Muster Architekturmuster
Beispiel: Observer (Beobachter) Zweites Sequenzdiagramm ¨ Bei Anderung der gespeicherten Daten im Subjekt:
Karsten Weicker, Nicole Weicker
29/ 1
Softwaretechnik – Strukturen und Muster Konzepte in Entwurf und Implementation
Grundlegende programmiersprachliche Konzepte I I I I
beeinflussen Architektur und Implementation hier nur angerissen praxisrelevant ! bekannt: I I
prozedurale Ans¨atze Objektorientierung
Karsten Weicker, Nicole Weicker
30/ 1
Softwaretechnik – Strukturen und Muster Konzepte in Entwurf und Implementation
Grundlegende programmiersprachliche Konzepte I I I I
beeinflussen Architektur und Implementation hier nur angerissen praxisrelevant ! bekannt: I I
I
prozedurale Ans¨atze Objektorientierung
weniger bekannt, jedoch aktuell I I I I I
Komponentenorientierung Meta-Architektur/ reflection generative Erzeugung v. Systembausteinen MDSD Aspektorientierung
Karsten Weicker, Nicole Weicker
30/ 1
Softwaretechnik – Strukturen und Muster Konzepte in Entwurf und Implementation
Prozedurale Ans¨atze I
I
I
I
I
Prozedur, Funktion, Unterprogramm, Routine, Operation, statische Methode setzt Separation of Concerns f¨ur wiederverwendbare Teilalgorithmen um Bsp.: Systeme in C oder Cobol, prozedurale verteilte Systeme h¨aufig gemeinsame globale Datenbereiche: ⇒ verletzt Modularisierungsprinzip und Information Hiding Schnittstellenabstraktion u¨ber Bibliotheken
Karsten Weicker, Nicole Weicker
31/ 1
Softwaretechnik – Strukturen und Muster Konzepte in Entwurf und Implementation
Objektorientierung (1) I I
I
I
I I
Objekte bilden Real-World-Konzepte ab Daten mit den bearbeitenden Methoden b¨undeln direkte Umsetzung von Information-Hiding und Modularisierung durch Laufzeit-Polymorphie wird lose Kopplung und Entwurf f¨ur Ver¨anderung erm¨oglicht nicht zwangsl¨aufig: objektorientiert = gut“ ” nur ansatzweise: Wiederverwendung
Karsten Weicker, Nicole Weicker
32/ 1
Softwaretechnik – Strukturen und Muster Konzepte in Entwurf und Implementation
Objektorientierung (2) Boochs zweite Hypothese Objektorientierte Entw¨urfe reduzieren Fehler und f¨ordern die Wiederverwertung. (nach Endres & Rombach, 2003) I I
keine allgemeine Gesetzm¨aßigkeit laut Untersuchungen von Basili und Briand (1998): I I I
tiefe Vererbung f¨uhrt zu mehr Fehlern (sehr stark) viele Unterklassen f¨uhren zu mehr Fehlern (stark) ¨ Uberladen von Methoden f¨uhrt zu mehr Fehlern (stark)
Karsten Weicker, Nicole Weicker
33/ 1
Softwaretechnik – Strukturen und Muster Konzepte in Entwurf und Implementation
Komponentenorientierung I
I I
I
I
Komponenten wiederverwendbare, in sich geschlossene Bausteine (Objekte hierf¨ur meist zu klein) vertraglich spezifizierte Schnittstellen nur explizite Abh¨angigkeiten zum Kontext der Komponente Beispiele: DLLs, JavaBeans, COM+ -Komponenten, CORBA Component Model (CCM) In Server-Komponentenarchitekturen: I Ablaufumgebung: Komponenten-Container I objektorientierte RPC-Middleware
Karsten Weicker, Nicole Weicker
34/ 1
Softwaretechnik – Strukturen und Muster Konzepte in Entwurf und Implementation
Komponentenorientierung I
I I
I
I
I
Komponenten wiederverwendbare, in sich geschlossene Bausteine (Objekte hierf¨ur meist zu klein) vertraglich spezifizierte Schnittstellen nur explizite Abh¨angigkeiten zum Kontext der Komponente Beispiele: DLLs, JavaBeans, COM+ -Komponenten, CORBA Component Model (CCM) In Server-Komponentenarchitekturen: I Ablaufumgebung: Komponenten-Container I objektorientierte RPC-Middleware setzt Modularisierungsprinzip, Separation-of-Concerns und Prinzip des Entwurfs f¨ur Ver¨anderung st¨arker um als Objekte
Karsten Weicker, Nicole Weicker
34/ 1
