Teil IV: Objektorientierter Entwurf 41 Einführung in die objektorientierte Softwarearchitektur

Transkript

1 New Van der Aalst 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 , ) Architekturprinzipien 2) Modularität und Geheimnisprinzip 3) Geschichtete Architekturen Prof. U. Aßmann, Softwaretechnologie 1 Technische Universität Dresden, Fakultät Informatik 2 Obligatorische Literatur Sekundäre Literatur Zuser Kap 10. Ghezzi Pfleeger ST für Einsteiger 5.3, 8 D. Parnas. On a buzzword: hierarchical structure. Proceedings IFIP Congress 1974, North-Holland, Amsterdam. Prof. U. Aßmann, Softwaretechnologie 3 Prof. U. Aßmann, Softwaretechnologie 4

2 Teil IV - Objektorientierter Entwurf (Object-Oriented Design, OOD) Von der Analyse zum Entwurf Vertrag mit dem Kunden 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 Objektanreicherung 5) Objektorientierte Rahmenwerke (frameworks) 6) Softwarearchitektur mit dem Quasar-Architekturstil Analyse Anforderungs- Ermittlung Fachliche Modellierung Anforderungs- Spezifikation Architektur- Entwurf Entwurf Produktdefi nition (Anforderungen und fachliches Modell) Architektur- Spezifi kation Detail- Entwurf Klassen- Spezifi kationen 41.1 Grundlegende Architekturprinzipien Prof. U. Aßmann, Softwaretechnologie 5 Aspekte Prof. U. Aßmann, Softwaretechnologie 6 Typische Bestandteile eines Softwaresystems Anwendungsspezifische Funktionen Benutzungsoberfläche Ablaufsteuerung Datenhaltung Infrastrukturdienste Objektverwaltung Interne Objekt- und Prozeßkommunikation Verteilungsunterstützung Kommunikationsdienste Sicherheitsfunktionen Zuverlässigkeitsfunktionen Systemadministration etc. Installation, Anpassung Systembeobachtung Technische Universität Dresden, Fakultät Informatik 7 Architektur Technik Anwendung (spezifisch) Prof. U. Aßmann, Softwaretechnologie 8

3 Aspekte des Architekturentwurfs Architekturprinzip: Hierarchische Organisation der obersten Ebenen (Grobe) Strukturelle Zerlegung: Physikalische Verteilung: Blockdiagramme Schichten, Sichten, Dimensionen Zentral oder verteilt? Topologie Ablaufsicht Logischer Detail-Entwurf Einhaltung nichtfunktionaler Anforderungen: Architekturbestimmende Eigenschaften (z.b. Realzeitsystem, eingebettetes System) Optimierungen Standardarchitekturen f1 f3a F1 F3 F2 f2 f3b 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 Manager Text TextRep IText IForm Text Manager Buffer Lines Forms Prof. U. Aßmann, Softwaretechnologie 9 Prof. U. Aßmann, Softwaretechnologie 10 Blockdiagramme Konfigurationsdiagramme (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. Konfigurationsdiagramme sind nicht Bestandteil von UML Konfigurationsdiagramme sind das meistverbreitete Hilfsmittel zur Beschreibung der physikalischen Verteilung von Systemkomponenten. Rechner, Knoten Lokales Kommunikationsnetz Speicherndes System Datenkommunikations- Netz Prof. U. Aßmann, Softwaretechnologie 11 Prof. U. Aßmann, Softwaretechnologie 12

4 Beispiel Terminverwaltung Architekturprinzip: Hohe Kohäsion + Niedrige Kopplung PC1 PCn PDA1 PDAm Termin- Server Anzeigetafel- Steuerung Physikalische Konfi guration Subsystem A (z.b. Benutzungsoberfl äche) 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. Blockdiagramm PC Client PDA Client PDA Sync Termin-Manager Daten- Export Subsystem B (z.b. fachlicher Kern) Änderungen von Subsystem B sollten nur möglichst einfache Änderungen in Subsystem A nach sich ziehen. Termin-Datenbank Prof. U. Aßmann, Softwaretechnologie 13 Prof. U. Aßmann, Softwaretechnologie Veränderungsorientierter Entwurf mit dem Geheimnisprinzip Architekturprinzip: Einteilung in Komponenten Nach dem Teile-und-Herrsche-Prinzip sollte Software in Komponenten (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 Technische Universität Dresden, Fakultät Informatik 15 Prof. U. Aßmann, Softwaretechnologie 16

5 Komponentenmodelle und Kompositionssysteme Wie modularisiert man einen Entwurf? 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) 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. U. Aßmann, Softwaretechnologie 17 Geheimnisse von Modulen/Komponenten Verschiedene Arten von Komponenten/Modulen Prof. U. Aßmann, Softwaretechnologie 18 Arbeitsweise von Algorithmen Datenformate Texte, Dokumente, Bilder Datentypen Abstrakte Datentypen und ihre konkrete Implementierung Benutzerschnittstellenbibliotheken Bearbeitungsreihenfolgen Verteilung Persistenz Parallelität Prof. U. Aßmann, Softwaretechnologie 19 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. U. Aßmann, Softwaretechnologie 20

6 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 Entwurfsmuster Fassade zur Reduktion von Kopplung Ein Entwurfsmuster im Geiste Parnas (Wdh.) Entwurfsmuster Fassade (Facade) Prof. U. Aßmann, Softwaretechnologie 21 Technische Universität Dresden, Fakultät Informatik 22 Fassaden verbergen Subsysteme 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. U. Aßmann, Softwaretechnologie 23 Eine Fassade bietet eine Sicht auf ein Subsystem an. Es darf mehrere Sichten geben, nur keinen direkten Zugriff auf die inneren Objekte Client Abstract Facade operation() Concrete Facade operation(). adaptedobject.specificoperation() adaptedobject2.specificoperation(). HiddenSubsystem adapted Object1 adapted Object2 adapted Object3 HiddenClass1 specificoperation() HiddenClass2 specificoperation() HiddenClass3 specificoperation() Prof. U. Aßmann, Softwaretechnologie 24

7 Restrukturierung hin zur Fassade Fassaden und Schichten Fassaden entkoppeln; Subsysteme können leichter ausgetauscht werden (Variabilitätsmuster) Falls einzelne Klassen eines Subsystems wieder Fassaden sind, entstehen fassadengeschützte Schichten Clients Clients Facade Facade Upper layer Facade Subsystem Prof. U. Aßmann, Softwaretechnologie 25 Lower layer Prof. U. Aßmann, Softwaretechnologie Entwurfsmuster Fabrikmethode (FactoryMethod) Problem der Fabrikmethode Wie variiert man die Erzeugung für eine polymorphe Hierarchie von Produkten? Problem: Konstruktoren sind nicht polymorph! (vertiefend) zur polymorphen Variation von Komponenten (Produkte) und zum Verbergen von Produkt-Arten Product ConcreteProduct1 Product = new ConcreteProduct1() ConcreteProduct2 Technische Universität Dresden, Fakultät Informatik 27 Prof. U. Aßmann, Softwaretechnologie 28

8 Struktur Fabrikmethode Factory Method (Polymorphic Constructor) FactoryMethod ist eine Variante von TemplateMethod, zur Produkterzeugung Product ConcreteProduct Creator FactoryMethod() anoperation() ConcreteCreator FactoryMethod() Beispiel FactoryMethod Product = FactoryMethod() return new ConcreteProduct Prof. U. Aßmann, Softwaretechnologie 29 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);.. Lösung mit FactoryMethod // 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. U. Aßmann, Softwaretechnologie 30 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 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. U. Aßmann, Softwaretechnologie 31 Prof. U. Aßmann, Softwaretechnologie 32

9 Factory Method im SalesPoint-Rahmenwerk Einsatz in Komponentenarchitekturen 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 In Rahmenwerk-Architekturen wird die Fabrikmethode eingesetzt, um von oberen Schichten (Anwendungsschichten) aus die Rahmenwerkschicht zu konfigurieren: StockImpl Rahmenwerk +clone() : Object #createpeer(): StockImpl Building Building Style Anwendung CountingStockImpl #createpeer(): StockImpl Skyscraper Castle Bungalow Mideval Style Modern Style Prof. U. Aßmann, Softwaretechnologie Strategie (Strategy, Template Class) Strategy (also called Template Class) Prof. U. Aßmann, Softwaretechnologie 34 Strategy wirkt wie TemplateMethod, nur wird die Hakenmethode in eine separate Klasse ausgelagert Zur Variation der Hakenklasse (und -methode) TemplateClass hookobject HookClass (Strategy) (Wdh.) templatemethod() hookmethod() hookobject.hookmethod() ConcreteHookValueA hookmethod() ConcreteHookValueB hookmethod() Technische Universität Dresden, Fakultät Informatik 35 Prof. U. Aßmann, Softwaretechnologie 36

10 Kombinierter Einsatz in Rahmenwerken FactoryMethod variiert den Konstruktor TemplateMethod oder Strategy (TemplateClass) variiert die Hookmethode Bridge (s. später) variiert die TemplateMethode Entwurfsmuster Einzelstück (Singleton) Rahmenwerk Building createbuilding() animate() CastleTempl createbuilding() drawbuilding() CastleHook drawbuilding() Anwendung Bungalow createbuilding() Template Class ScottishCastle drawbuilding() zur globalen Konfiguration einer Komponente oder Schicht (Wdh) Factory Method Template Method Entwurfsmuster Einzelstück (Singleton) Prof. U. Aßmann, Softwaretechnologie 37 Technische Universität Dresden, Fakultät Informatik 38 Singleton im SalesPoint the Shop 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 01 theinstance:singleton class Singleton { private static Singleton theinstance = null; private Singleton () { public static Singleton getinstance() { if (theinstance == null) theinstance = new Singleton(); return theinstance; 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. U. Aßmann, Softwaretechnologie 39 Prof. U. Aßmann, Softwaretechnologie 40

11 41.3 Schichtenarchitekturen (Layered Architectural Styles) 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>> und die benutzt -Relation Basiert auf Analysemodell Fachlicher Kern <<control>> Technische Universität Dresden, Fakultät Informatik 41 Verschiedene Relationen zwischen Komponenten Datenverwaltung <<data>> <<entity>> Prof. U. Aßmann, Softwaretechnologie 42 USES-Relation (Relies-On, Requires, Sees-A) Es gibt verschiedene Beziehungen zwischen den Komponenten eines Systems Ähnlichkeit Vererbungsrelationen: is-a (set inheritance), behaves-like (Verhaltenskonformität), Zugriff 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 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 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) because partial orders can be layered Prof. U. Aßmann, Softwaretechnologie 43 Prof. U. Aßmann, Softwaretechnologie 44

12 Repeat: BCD/BCED Classification Example: USES Relation in 3- and 4-Tier Architectures (BCED) 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>> 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) Application logic (business logic, Fachlicher Kern, Anwendungslogik) Middleware (memory access, distribution) <<boundary>> <<control>> <<entity>> Data access object (DAO) Data Repository Layer (database, memory) <<database>> 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 Prof. U. Aßmann, Softwaretechnologie 45 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. U. Aßmann, Softwaretechnologie 46 Example: 4-Tier Web System (Thick Client) Middleware 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) Server http <<boundary>> <<page>> <<control>> <<applet>> <<entity>> Data access object (DAO) Data Repository Layer (database, memory) <<database>> Prof. U. Aßmann, Softwaretechnologie 47 Prof. U. Aßmann, Softwaretechnologie 48

13 Example: 4-Tier Web System (Thin Client) Example: ISO-OSI 7 Layers Network Architecture 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 Every layer contains an abstract machine (set of operations) Graphical user interface Client Application logic (business logic) Middleware Server http <<boundary>> <<page>> <<control>> <<servlet>> <<entity>> Data access object (DAO) Presentation Layer Session Layer Presentation Layer Session Layer Data Repository Layer (database, memory) <<database>> Data Transport Layer Data Transport Layer Prof. U. Aßmann, Softwaretechnologie 49 Prof. U. Aßmann, Softwaretechnologie 50 Example: Operating Systems Example: Database Systems UNIX: User Space Kernel Apple- UNIX User Space Kernel SQL compiler Microkernel (Mach) transaction manager lock manager table manager Windows NT/XP: User Space Kernel Hardware Abstraction Layer (HAL) physical storage management record management layer Prof. U. Aßmann, Softwaretechnologie 51 Prof. U. Aßmann, Softwaretechnologie 52

14 Why are Layered Architectures Successful? What Have We Learned 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 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. U. Aßmann, Softwaretechnologie 53 Prof. U. Aßmann, Softwaretechnologie 54 Conway s Law on Software Structure The End Software is always structured in the same way as the organisation which built it. 55 Prof. U. Aßmann, Softwaretechnologie 55 Prof. U. Aßmann, Softwaretechnologie 56