Teil IV: Objektorientierter Entwurf 41 Einführung in die objektorientierte Softwarearchitektur Prof. Dr. rer. nat. habil. Uwe Aßmann Institut für Software- und Multimediatechnik Lehrstuhl Softwaretechnologie Fakultät für Informatik TU Dresden Version 10-0.2, 05.07.10 1) Architekturprinzipien 2) Modularität und Geheimnisprinzip 3) Geschichtete Architekturen Softwaretechnologie, Prof. Uwe Aßmann 1 Obligatorische Literatur Zuser Kap 10. Ghezzi 4.1-4.2 Pfleeger 5.1-5.3 ST für Einsteiger 5.3, 8 Prof. Uwe Aßmann, Softwaretechnologie 2
Sekundäre Literatur D. Parnas. On a buzzword: hierarchical structure. Proceedings IFIP Congress 1974, North-Holland, Amsterdam. Prof. Uwe Aßmann, Softwaretechnologie 3 Teil IV - Objektorientierter Entwurf (Object-Oriented Design, OOD) 1) Einführung in die objektorientierte Softwarearchitektur (41) 1) Modularität und Geheimnisprinzip 2) Entwurfsmuster für Modularität 3) BCD-Architekturstil (3-tier architectures) 2) Verfeinerung des Entwurfsmodells zum Implementierungsmodell (Anreicherung von Klassendiagrammen) 1) Verfeinerung von Operationen 2) Verfeinerung von Assoziationen 3) Verfeinerung von Vererbung 3) Verfeinerung von Lebenszyklen 1) Verfeinerung von verschiedenen Steuerungsmaschinen 4) Verfeinerung mit Chicken Fattening 5) Objektorientierte Rahmenwerke (frameworks) 6) Softwarearchitektur mit dem Quasar-Architekturstil Prof. Uwe Aßmann, Softwaretechnologie 4
Von der Analyse zum Entwurf Vertrag mit dem Kunden Analyse Anforderungs- Ermittlung Fachliche Modellierung Anforderungs- Spezifikation Produktdefi nition (Anforderungen und fachliches Modell) Architektur- Spezifi kation Architektur- Entwurf Klassen- Spezifi kationen Entwurf Detail- Entwurf Prof. Uwe Aßmann, Softwaretechnologie 5 41.1 Grundlegende Architekturprinzipien Softwaretechnologie, Prof. Uwe Aßmann 6
Typische Bestandteile eines Softwaresystems Anwendungsspezifische Funktionen Benutzungsoberfläche Ablaufsteuerung Datenhaltung Infrastrukturdienste Kommunikationsdienste Sicherheitsfunktionen Zuverlässigkeitsfunktionen Systemadministration Installation, Anpassung Systembeobachtung Objektverwaltung Interne Objekt- und Prozeßkommunikation Verteilungsunterstützung etc. Architektur Technik Anwendung (spezifisch) Prof. Uwe Aßmann, Softwaretechnologie 7 Aspekte des Architekturentwurfs (Grobe) Strukturelle Zerlegung: Blockdiagramme Schichten, Sichten, Dimensionen F1 F3 F2 Physikalische Verteilung: Zentral oder verteilt? f1 f2 Topologie f3a f3b Ablaufsicht Logischer Detail-Entwurf Einhaltung nichtfunktionaler Anforderungen: Architekturbestimmende Eigenschaften (z.b. Realzeitsystem, eingebettetes System) Optimierungen Standardarchitekturen Prof. Uwe Aßmann, Softwaretechnologie 8
Architekturprinzip: Hierarchische Organisation der obersten Ebenen Mit Montagediagrammen, wurden schon in der Top-Level-Architektur behandelt Oberste Ebene des Systems ist meist hierarchisch, nicht objektorientiert strukturiert Damit die letzte Integration zum Gesamtsystem einfach verläuft Dokument- System Adresses DokumentSystem Adress Manager Text IText Text Manager Buffer email email Manager TextRep IForm Lines Forms Prof. Uwe Aßmann, Softwaretechnologie 9 Blockdiagramme (Informelle) Blockdiagramme sind kein Bestandteil von UML Blöcke stellen UML-Komponenten ohne Anschlüsse dar Blockdiagramme sind das meistverbreitete Hilfsmittel zum Skizzieren der logischen Struktur einer Systemarchitektur. Prof. Uwe Aßmann, Softwaretechnologie 10
Konfigurationsdiagramme Konfigurationsdiagramme sind nicht Bestandteil von UML Rechner, Knoten Lokales Kommunikationsnetz Speicherndes System Konfigurationsdiagramme sind das meistverbreitete Hilfsmittel zur Beschreibung der physikalischen Verteilung von Systemkomponenten. Datenkommunikations- Netz Prof. Uwe Aßmann, Softwaretechnologie 11 Beispiel Terminverwaltung PC1 PCn PDA1 PDAm Physikalische Konfi guration Termin- Server Anzeigetafel- Steuerung PC Client PDA Client Blockdiagramm PDA Sync Termin-Manager Daten- Export Termin-Datenbank Prof. Uwe Aßmann, Softwaretechnologie 12
Architekturprinzip: Hohe Kohäsion + Niedrige Kopplung Subsystem A (z.b. Benutzungsoberfl äche) Subsystem B (z.b. fachlicher Kern) Hohe Kohäsion: Subsystem B darf keine Information und Funktionalität enthalten, die zum Zuständigkeitsbereich von A gehört und umgekehrt. Niedrige Kopplung: Es muß 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. Prof. Uwe Aßmann, Softwaretechnologie 13 41.2 Veränderungsorientierter Entwurf mit dem Geheimnisprinzip Softwaretechnologie, Prof. Uwe Aßmann 14
Architekturprinzip: Einteilung in Komponenten Nach dem Teile-und-Herrsche-Prinzip sollte Software in Komponenten oder Module eingeteilt werden Eine Komponente im allgemeinden Sinne ist eine Wiederverwendungseinheit: gruppiert Funktionalität (Kohäsion) unterstützt lose Kopplung:. hat keine impliziten, nur explizit in der Schnittstelle angegebene Abhängigkeiten zu anderen Komponenten. kann unabhängig von anderen entwickelt werden. Komponenten können einzeln getestet werden (Einheitstest, unit test). Fehler können zu individuellen Komponenten verfolgt werden. hat eine schlanke Schnittstelle kann ausgetauscht werden, ohne dass das System zusammenbricht (Ersetzbarkeit) kann wiederverwendet werden Prof. Uwe Aßmann, Softwaretechnologie 15 Komponentenmodelle und Kompositionssysteme Es gibt nicht nur die UML-Komponente. sondern viele verschiedene Komponentenmodelle: Module einer modularen Programmiersprache (Modula, Ada) Klassen in objektorientierten Sprachen UML-Komponenten Fragmentkomponenten, Schablonen Dokumentkomponenten Serverseitige Webkomponenten Ein Kompositionssystem definiert: Komponentenmodell: Eigenschaften der Schnittstelle einer Komponente Kompositionstechnik: Wie werden Komponenten komponiert? Kompositionssprache: Wie wird die Architektur eines großen Systems beschrieben? --> Vorlesung CBSE (SS) Prof. Uwe Aßmann, Softwaretechnologie 16
Wie modularisiert man einen Entwurf? Parnas' Prinzip des Entwurfs mit dem Geheimnisprinzip (veränderungsorientierter Entwurf, change-oriented modularization with information hiding) [Parnas, CACM 1972]: 1) Bestimme alle Entwurfsentscheidungen, die sich ändern können 2) Entwickle für jede Entscheidung ein Komponente, die die Entscheidung verbirgt Die Entscheidung nennt man das Komponenten- oder Modulgeheimnis (module secret) 3) Entwerfe eine stabile Schnittstelle für die Komponente die unverändert bleibt, wenn sich die Entwurfsentscheidung und somit die Implementierung des Modulgeheimnisses ändert Das Das Geheimnisprinzip Geheimnisprinzip erniedrigt erniedrigt die die externe externe Kopplung Kopplung und und erhöht erhöht die die innere innere Kohäsion Kohäsion Prof. Uwe Aßmann, Softwaretechnologie 17 Geheimnisse von Modulen/Komponenten Arbeitsweise von Algorithmen Datenformate Texte, Dokumente, Bilder Datentypen Abstrakte Datentypen und ihre konkrete Implementierung Benutzerschnittstellenbibliotheken Bearbeitungsreihenfolgen Verteilung Persistenz Parallelität Prof. Uwe Aßmann, Softwaretechnologie 18
Verschiedene Arten von Komponenten/Modulen Funktionale Module ohne Zustand sin, cos, BCD arithmetic, gnu mp, Daten-Repositorien Verbergen Repräsentation, Zugriff und Zustand der Daten Symboltabellen, Materialcontainer, Abstrakte Datentypen Singletons (Konfigurationskomponenten) Klassen mit einer einzigen Instanz Prozesse (aktive Objekte) Klassen Module, die ausgeprägt werden können Generische Klassen (Klassenschablonen) Komplexe Klassen (UML-Komponenten) Fragmentkomponenten für alle gilt das Geheimnisprinzip für alle gilt das Geheimnisprinzip Prof. Uwe Aßmann, Softwaretechnologie 19 Entwurfsmuster für Geheimnisprinzip Viele Entwurfsmuster (z.b. TemplateMethod) sind Variabilitätsmuster, d.h., sie lassen einem bestimmte Geheimnisse verbergen und dann die Implementierungen austauschen (variieren) Fassade verbirgt ein ganzes Subsystem Fabrikmethode verbirgt die Allokation von Produkten TemplateMethod und Strategie verbergen einen Anteil eines Algorithmus Singleton kapselt globale Konfigurationsdaten In UML kann man Entwurfsmuster als Komponenten (Wiederverwendungeinheiten) kapseln, indem man sie als Kollaborationen spezifiziert Prof. Uwe Aßmann, Softwaretechnologie 20
Entwurfsmuster Fassade zur Reduktion von Kopplung Ein Entwurfsmuster im Geiste Parnas (Wdh.) Softwaretechnologie, Prof. Uwe Aßmann 21 Entwurfsmuster Fassade (Facade) Eine Fassade (Facade) ist ein Objektadapter, der ein komplettes Subsystem verbirgt Die Fassade bildet die eigene Schnittstelle auf die Schnittstellen der verkapselten Objekte ab Eine UML-Komponente ist gleichzeitig eine (einfache) Fassade. Die Delegationskonnektoren werden 1:1 an innere Komponenten delegiert; interne Adapter können adaptieren Prof. Uwe Aßmann, Softwaretechnologie 22
Fassaden verbergen Subsysteme Client Eine Fassade bietet eine Sicht auf ein Subsystem an. Es darf mehrere Sichten geben, nur keinen direkten Zugriff auf die inneren Objekte Abstract Facade operation() HiddenSubsystem Concrete Facade operation(). adaptedobject.specificoperation() adaptedobject2.specificoperation(). adapted Object1 adapted Object2 adapted Object3 HiddenClass1 specificoperation() HiddenClass2 specificoperation() HiddenClass3 specificoperation() Prof. Uwe Aßmann, Softwaretechnologie 23 Restrukturierung hin zur Fassade Fassaden entkoppeln; Subsysteme können leichter ausgetauscht werden (Variabilitätsmuster) Clients Facade Subsystem Prof. Uwe Aßmann, Softwaretechnologie 24
Fassaden und Schichten Falls einzelne Klassen eines Subsystems wieder Fassaden sind, entstehen fassadengeschützte Schichten Clients Facade Upper layer Facade Lower layer Prof. Uwe Aßmann, Softwaretechnologie 25 Entwurfsmuster Fabrikmethode (FactoryMethod) (vertiefend) zur polymorphen Variation von Komponenten (Produkte) und zum Verbergen von Produkt-Arten Softwaretechnologie, Prof. Uwe Aßmann 26
Problem der Fabrikmethode Wie variiert man die Erzeugung für eine polymorphe Hierarchie von Produkten? Problem: Konstruktoren sind nicht polymorph! Product ConcreteProduct1 Product = new ConcreteProduct1() ConcreteProduct2 Prof. Uwe Aßmann, Softwaretechnologie 27 Struktur Fabrikmethode FactoryMethod ist eine Variante von TemplateMethod, zur Produkterzeugung Product Creator FactoryMethod() anoperation() Product = FactoryMethod() ConcreteProduct ConcreteCreator FactoryMethod() return new ConcreteProduct Prof. Uwe Aßmann, Softwaretechnologie 28
Factory Method (Polymorphic Constructor) Abstract creator classes offer abstract constructors (polymorphic constructors) Concrete subclasses can specialize the constructor Constructor implementation is changed with allocation of concrete Creator // Abstract creator class // Abstract creator class public abstract class Creator { public abstract class Creator { // factory method // factory method public abstract Set createset(int n); public abstract Set createset(int n); public class Client { public class Client { Creator cr = [.. subclass ].. Creator cr = [.. subclass ].. public void collect() { public void collect() { Set myset = Creator.createSet(10); Set myset = Creator.createSet(10);.. // Concrete creator class // Concrete creator class public class ConcreteCreator extends Creator { public class ConcreteCreator extends Creator { public Set createset(int n) { public Set createset(int n) { return new ListBasedSet(n); return new ListBasedSet(n); Prof. Uwe Aßmann, Softwaretechnologie 29 Beispiel FactoryMethod Rahmenwerk für Gebäudeautomation Klasse Building hat eine Schablonenmethode zur Planung von Gebäuden Abstrakte Methoden: createwall, createroom, createdoor, createwindow Benutzer können Art des Gebäudes verfeinern Wie kann das Rahmenwerk neue Arten von Gebäuden behandeln? Building construct() createwall() createdoor() createwindow() createroom() Skyscraper createwall() createdoor() createwindow() createroom() house = new Building(); house.construct(); house.createwall(); house.createdoor(); house.createwindow(); Framework Extensions Prof. Uwe Aßmann, Softwaretechnologie 30
Lösung mit FactoryMethod Bilde createbuilding() als Fabrikmethode aus // abstract creator class // abstract creator class public abstract class Building { public abstract class Building { public abstract public abstract Building createbuilding(); Building createbuilding(); // concrete creator class // concrete creator class public class Skyscraper extends Building { public class Skyscraper extends Building { Skyscraper() { Skyscraper() { public Building createbuilding() { public Building createbuilding() { fill in more info fill in more info return new Skyscraper(); return new Skyscraper(); Prof. Uwe Aßmann, Softwaretechnologie 31 Factory Method im SalesPoint-Rahmenwerk Anwender von SalesPoint verfeinern die StockImpl-Klasse, die ein Produkt des Warenhauses im Lager repräsentiert z.b. mit einem CountingStockImpl, der weiß, wieviele Produkte noch da sind StockImpl +clone() : Object #createpeer(): StockImpl CountingStockImpl #createpeer(): StockImpl Prof. Uwe Aßmann, Softwaretechnologie 32
Einsatz in Komponentenarchitekturen In Rahmenwerk-Architekturen wird die Fabrikmethode eingesetzt, um von oberen Schichten (Anwendungsschichten) aus die Rahmenwerkschicht zu konfigurieren: Rahmenwerk Building Building Style Anwendung Skyscraper Castle Bungalow Mideval Style Modern Style Prof. Uwe Aßmann, Softwaretechnologie 33 Strategie (Strategy, Template Class) (Wdh.) Softwaretechnologie, Prof. Uwe Aßmann 34
Strategy (also called Template Class) Strategy wirkt wie TemplateMethod, nur wird die Hakenmethode in eine separate Klasse ausgelagert Zur Variation der Hakenklasse (und -methode) TemplateClass templatemethod() hookobject HookClass (Strategy) hookmethod() hookobject.hookmethod() ConcreteHookValueA hookmethod() ConcreteHookValueB hookmethod() Prof. Uwe Aßmann, Softwaretechnologie 35 Kombinierter Einsatz in Rahmenwerken FactoryMethod variiert den Konstruktor TemplateMethod oder Strategy (TemplateClass) variiert die Hookmethode Bridge (s. später) variiert die TemplateMethode Rahmenwerk Building createbuilding() animate() CastleTempl createbuilding() drawbuilding() CastleHook drawbuilding() Anwendung Bungalow createbuilding() Template Class ScottishCastle drawbuilding() Factory Method Template Method Prof. Uwe Aßmann, Softwaretechnologie 36
Entwurfsmuster Einzelstück (Singleton) zur globalen Konfiguration einer Komponente oder Schicht (Wdh) Softwaretechnologie, Prof. Uwe Aßmann 37 Entwurfsmuster Einzelstück (Singleton) Gesucht: globales Objekt, das global oder innerhalb einer Laufzeitkomponente (z.b. Schicht) Daten, z.b. Konfi gurationsdaten, vorhält Idee: Erstelle eine Klasse, von der genau ein Objekt existiert (Invariante) Erstelle einen artifi ziellen Konstruktor (Fabrikmethode), der oft aufgerufen werden kann, aber die Invariante sicherstellt Eigentlicher Konstruktor wird verborgen (private) Austausch der Konfi guration durch Unterklassenbildung (Variabilität) Singleton theinstance: Singleton getinstance(): Singleton 0..1 theinstance:singleton class Singleton { private static Singleton theinstance = null; private Singleton () { public static Singleton getinstance() { if (theinstance == null) theinstance = new Singleton(); return theinstance; Prof. Uwe Aßmann, Softwaretechnologie 38
Singleton im SalesPoint the Shop Der Shop im SalesPoint-Rahmenwerk ist ein Einzelstück (die Firma). Dagegen gibt es viele Verkaufsstellen (sales points) Austausch der Eigenschaften des Shops durch Unterklassenbildung Shop #Shop() $gettheshop(): Shop $settheshop (Shop sh) Prof. Uwe Aßmann, Softwaretechnologie 39 41.3 Schichtenarchitekturen (Layered Architectural Styles) und die benutzt -Relation Softwaretechnologie, Prof. Uwe Aßmann 40
Drei-Schichten-Architektur (BCD) Klassische Struktur eines interaktiven Anwendungssystems Schichten sind jeweils stark kohäsiv, und wenig gekoppelt aber warum? Oft kapselt eine Fassade eine Schicht, ein Einzelstück konfiguriert jede Schicht, Fabriken schneiden die Produkte der unteren Schichten zu, TemplateMethod/Class variieren Algorithmen der Produkte Benutzungsschnittstelle <<boundary>> Basiert auf Analysemodell Fachlicher Kern <<control>> Datenverwaltung <<data>> <<entity>> Prof. Uwe Aßmann, Softwaretechnologie 41 Verschiedene Relationen zwischen Komponenten Es gibt verschiedene Beziehungen zwischen den Komponenten eines Systems Ähnlichkeit Zugriff Vererbungsrelationen: is-a (set inheritance), behaves-like (Verhaltenskonformität), accesses-a (access relation) Zugriffsrecht: is-privileged-to, owns-a (security) Aufrufe: calls. is-called-by. delegates-to (delegation) Senden und Empfangen von Nachrichten Die USES Relation fasst alle diese zusammen Prof. Uwe Aßmann, Softwaretechnologie 42
USES-Relation (Relies-On, Requires, Sees-A) Component Component A A USES USES (relies-on, (relies-on, sees-a) sees-a) component component B B iff iff A A requires requires a a correct correct implementation implementation of of B B for for its its own own correct correct execution. execution. (A (A requires requires the the presence presence of of B) B) Requires an implementation may means visibility: A accesses public variable of B A uses a resource provided by B A allocates an instance of B A delegates work to B (A calls B) or B delegates work to A (B calls A) A calls B by exception or event If the USES relation is a partial order (a tree or a dag), then the system is called hierarchical or layered because partial orders can be layered Prof. Uwe Aßmann, Softwaretechnologie 43 Repeat: BCD/BCED Classification Boundary classes: Represent an interface item that talks with the user May persist beyond a run Control class: Controls the execution of a process, workflow, or business rules Does not persist Entity class: Describes persistent knowledge. Caches a persistent object from a database (data access object, DAO) Database class Adapter class for the database <<boundary>> Often, Entity and Database classes are unified <<entity>> <<database>> BCD/BCED is linked with the 3-tier architecture <<control>> Prof. Uwe Aßmann, Softwaretechnologie 44
Example: USES Relation in 3- and 4-Tier Architectures (BCED) 3- and 4-tier architectures have an acyclic USES relation, divided into 3 (resp. 4) layers that use each other in an acyclic relationship Upper layers see lower layers, but not vice versa Graphical user interface (GUI, Benutzerschnittstelle) <<boundary>> Application logic (business logic, Fachlicher Kern, Anwendungslogik) <<control>> Middleware (memory access, distribution) <<entity>> Data access object (DAO) Data Repository Layer (database, memory) <<database>> Prof. Uwe Aßmann, Softwaretechnologie 45 Example: 3- and 4-Tier Architectures (BCD/BCED) Good encapsulation of cohesive knowledge in a layer Low coupling due to acyclic USES relationship Better exchange of subsystems of the application GUI encapsulates user interactions and look Data repository layer encapsulates how data is stored (database, transient, persistent component platforms such as Enterprise JavaBeans) Middleware mediates between both. The middleware hides distribution. and deals with security The BCD/BCED architecture is the architecture for business-oriented software and for projects in the projects Prof. Uwe Aßmann, Softwaretechnologie 46
Example: 4-Tier Web System (Thick Client) Thick client Web Systems have a http-based middleware, in which GUI and application logic reside on the client, data is managed on the server Graphical user interface Client Application logic (business logic) <<boundary>> <<page>> <<control>> <<applet>> http Middleware Server <<entity>> Data access object (DAO) Data Repository Layer (database, memory) <<database>> Prof. Uwe Aßmann, Softwaretechnologie 47 Example: 4-Tier Web System (Thin Client) Thin client Web Systems have a http-based middleware, in which GUI resides on the client, application logic and data is managed on the server Graphical user interface Client http <<boundary>> <<page>> Application logic (business logic) Middleware Server <<control>> <<servlet>> <<entity>> Data access object (DAO) Data Repository Layer (database, memory) <<database>> Prof. Uwe Aßmann, Softwaretechnologie 48
Example: ISO-OSI 7 Layers Network Architecture Every layer contains an abstract machine (set of operations) Presentation Layer Presentation Layer Session Layer........ Data Transport Layer Session Layer........ Data Transport Layer.. Prof. Uwe Aßmann, Softwaretechnologie 49 Example: Operating Systems.. UNIX: User Space Apple- UNIX User Space Kernel Kernel Microkernel (Mach) Windows NT/XP: User Space Kernel Hardware Abstraction Layer (HAL) Prof. Uwe Aßmann, Softwaretechnologie 50
Example: Database Systems SQL compiler transaction manager lock manager table manager physical storage management record management layer Prof. Uwe Aßmann, Softwaretechnologie 51 Why are Layered Architectures Successful? Layered architectures require an acyclic USES relationship They are successful, Because the dependencies within the system are structured as a dag System is structured Internals of layers can be abstracted away Prof. Uwe Aßmann, Softwaretechnologie 52
What Have We Learned Designing the global architectural style of your application is important (Architekturentwurf) Layers play an important role The USES (relies-on) relation is different from is-a (inheritance) and part-of (aggregation) It deals with prerequisites for correct execution Can be used to layer systems, if it is acyclic Examples of architectural styles with acyclic USES relation: The BCED 4-tier architecture Layered abstract machines for interactive applications Layered behavioral state machines Both styles can be combined Prof. Uwe Aßmann, Softwaretechnologie 53 Conway s Law on Software Structure Software is always structured in the same way as the organisation which built it. Prof. Uwe Aßmann, Softwaretechnologie 54
The End Prof. Uwe Aßmann, Softwaretechnologie 55