Teil IV: Objektorientierter Entwurf

Transkript

1 Teil IV: Objektorientierter Entwurf OOD.1 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 , ) Modularität und Geheimnisprinzip 2) Geschichtete Architekturen Softwaretechnologie, Prof. Uwe Aßmann 1 Obligatorische Literatur Zuser Kap 10. Ghezzi Pfleeger Prof. Uwe Aßmann, Softwaretechnologie 2

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 1) Modularität und Geheimnisprinzip 2) Entwurfsmuster für Modularität 3) BCED-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

3 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 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 Architektur Anwendung (spezifisch) Prof. Uwe Aßmann, Softwaretechnologie 6

4 Aspekte des Architekturentwurfs (Grobe) Strukturelle Zerlegung: Blockdiagramme Schichten, Sichten, Dimensionen F1 F3 F2 Physikalische Verteilung: Zentral oder verteilt? Topologie f1 f3a f2 f3b Ablaufsicht Logischer Detail-Entwurf Einhaltung nichtfunktionaler Anforderungen: Architekturbestimmende Eigenschaften (z.b. Realzeitsystem, eingebettetes System) Optimierungen Standardarchitekturen Prof. Uwe Aßmann, Softwaretechnologie 7 Montagediagramme Wurden schon in der Top-Level-Architektur behandelt UML-Komponenten sind strukturiert und mit Anschlüssen Dokument- System Adresses DokumentSystem Adress Manager Text IText Text Manager Buffer Manager TextRep IForm Lines Forms Prof. Uwe Aßmann, Softwaretechnologie 8

5 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 9 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 10

6 Beispiel Terminverwaltung PC1... PCn PDA1 PDAm Physikalische Konfi guration Termin- Server Anzeigetafel- Steuerung PC Client PDA Client Blockdiagramm PDA Sync Termin-Manager Termin-Datenbank Daten- Export Prof. Uwe Aßmann, Softwaretechnologie 11 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. Beispiele zur konkreten technischen Realisierung siehe später (MVC-Architektur, Entwurfsmuster) Prof. Uwe Aßmann, Softwaretechnologie 12

7 Veränderungsorientierter Entwurf mit dem Geheimnisprinzip Softwaretechnologie, Prof. Uwe Aßmann 13 Architekturprinzip: Komponente Nach dem Teile-und-Herrsche-Prinzip sollte Software in Komponenten oder Module eingeteilt werden Eine Komponente gruppiert Funktionalität kann unabhängig von anderen entwickelt werden hat keine impliziten, nur explizit in der Schnittstelle angegebene Abhängigkeiten zu anderen Komponenten. Komponenten können einzeln getestet werden (Einheitstest, unit test). Fehler können zu individuellen Komponenten verfolgt werden hat eine schlanke Schnittstelle. Komponenten können ausgetauscht werden, ohne daß das System zusammenbricht Komponenten können wiederverwendet werden Prof. Uwe Aßmann, Softwaretechnologie 14

8 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 15 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 Geheimnisprinzip erniedrigt die externe Kopplung und erhöht die innere Kohäsion Prof. Uwe Aßmann, Softwaretechnologie 16

9 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 17 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 Prof. Uwe Aßmann, Softwaretechnologie 18

10 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 Prof. Uwe Aßmann, Softwaretechnologie 19 Entwurfsmuster Fassade zur Reduktion von Kopplung... Ein Entwurfsmuster im Geiste Parnas (Wdh.) Softwaretechnologie, Prof. Uwe Aßmann 20

11 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 21 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 22

12 Restrukturierung hin zur Fassade Fassaden entkoppeln; Subsysteme können leichter ausgetauscht werden (Variabilitätsmuster) Clients Facade Subsystem Prof. Uwe Aßmann, Softwaretechnologie 23 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 24

13 Entwurfsmuster Fabrikmethode (FactoryMethod) zur polymorphen Variation von Komponenten (Produkte) und zum Verbergen von Produkt-Arten Softwaretechnologie, Prof. Uwe Aßmann 25 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 26

14 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 27 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 public abstract class Creator { // factory method public abstract Set createset(int n); } public class Client {... Creator cr = [.. subclass ].. public void collect() { Set myset = Creator.createSet(10);... } } // Concrete creator class public class ConcreteCreator extends Creator { public Set createset(int n) { return new ListBasedSet(n); }... } Prof. Uwe Aßmann, Softwaretechnologie 28

15 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 29 Lösung mit FactoryMethod Bilde createbuilding() als Fabrikmethode aus // abstract creator class public abstract class Building { public abstract Building createbuilding();... } // concrete creator class public class Skyscraper extends Building { Skyscraper() {... } public Building createbuilding() {... fill in more info... return new Skyscraper(); }... } Prof. Uwe Aßmann, Softwaretechnologie 30

16 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 31 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 32

17 Strategie (Strategy, Template Class) (Wdh.) Softwaretechnologie, Prof. Uwe Aßmann 33 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 34

18 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 35 Entwurfsmuster Einzelstück (Singleton) zur globalen Konfiguration einer Komponente oder Schicht (Wdh) Softwaretechnologie, Prof. Uwe Aßmann 36

19 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 37 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 38

20 OOD.1.2 Schichtenarchitekturen (Layered Architectural Styles) und die benutzt -Relation Softwaretechnologie, Prof. Uwe Aßmann 39 Drei-Schichten-Architektur 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 Basiert auf Analysemodell Fachlicher Kern Datenverwaltung Prof. Uwe Aßmann, Softwaretechnologie 40

21 Different Relations Between Components Remark: In the following, we use the word component for both the words module and class There are different relations between components Similarity is-a (inheritance), behaves-like,... Whole/part has-a (aggregation) exclusively-owns-a, owns-a is-composed-of (composition) Access accesses-a (access relation) is-privileged-to, owns-a (security) calls. is-called-by. delegates-to (delegation) It is possible to define a relationship that summarizes all of these Prof. Uwe Aßmann, Softwaretechnologie 41 USES-Relation (Relies-On, Requires, Sees-A) Component A USES (relies-on, sees-a) component B iff A requires a correct implementation of B for its own correct execution. (A requires the presence of 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 42

22 Repeat: BCE/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 BCED is linked with the 3-tier architecture <<entity>> <<database>> <<control>> Prof. Uwe Aßmann, Softwaretechnologie 43 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 44

23 Example: 3- and 4-Tier Architectures (BCED) Good encapsulation of cohesive knowledge in a layer Few 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 BCED architecture is the architecture for business-oriented software... and for projects in the projects... Prof. Uwe Aßmann, Softwaretechnologie 45 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 46

24 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 47 Example: ISO-OSI 7 Layers Network Architecture Every layer contains an abstract machine (set of operations) Presentation Layer Session Layer Data Transport Layer Presentation Layer Session Layer Data Transport Layer.. Prof. Uwe Aßmann, Softwaretechnologie 48..

25 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 49 Example: Database Systems SQL compiler transaction manager lock manager table manager physical storage management record management layer Prof. Uwe Aßmann, Softwaretechnologie 50

26 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 51 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 52

27 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 53 The End Prof. Uwe Aßmann, Softwaretechnologie 54