4. Objektorientierter Entwurf

Transkript

1 4. Objektorientierter Entwurf 4.1 Entwurf der Softwarearchitektur Softwaretechnologie, Prof. Uwe Aßmann 1

2 Obligatorische Literatur Zuser Ghezzi Pfleeger Prof. Uwe Aßmann, Softwaretechnologie 2

3 Sekundäre Literatur D. Parnas. On a buzzword: hierarchical structure. Proceedings IFIP Congress 1974, North-Holland, Amsterdam. Prof. Uwe Aßmann, Softwaretechnologie 3

4 Von der Analyse zum Entwurf Analyse Anforderungs- Ermittlung Anforderungs- Spezifikation (Pflichtenheft) Funktionale Spezifikation (Produktdefinition) Fachliche Modellierung Architektur- Spezifikation Klassen- bzw. Modul- Spezifikationen Architektur- Entwurf Entwurf Detail- Entwurf Prof. Uwe Aßmann, Softwaretechnologie 4

5 Typische Bestandteile eines Softwaresystems Anwendungsspezifische Funktionen Benutzungsoberfläche Ablaufsteuerung Datenhaltung Kommunikationsdienste Sicherheitsfunktionen Zuverlässigkeitsfunktionen Systemadministration Installation, Anpassung Infrastrukturdienste Systembeobachtung Objektverwaltung Interne Objekt- und Prozeßkommunikation Verteilungsunterstützung Architektur Anwendung (spezifisch) Prof. Uwe Aßmann, Softwaretechnologie 5

6 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 6

7 Blockdiagramme Blockdiagramme sind kein Bestandteil von UML! (Gleichwertige Notation in UML: Implementierungsdiagramm) Blockdiagramme sind das meistverbreitete Hilfsmittel zum Skizzieren der logischen Struktur einer Systemarchitektur. Subsystem Schnittstelle Subsystem umfaßt Objekte bestimmter Klassen Schnittstelle ist klar definiert (Aufrufschnittstelle, Kommunikationsprotokoll) Umfassendes Subsystem Prof. Uwe Aßmann, Softwaretechnologie 7

8 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 8

9 Beispiel Terminverwaltung PC1... PCn PDA1 PDAm Physikalische Konfiguration Termin- Server Anzeigetafel- Steuerung PC Client PDA Client Blockdiagramm PDA Sync Termin-Manager Termin-Datenbank Daten- Export Prof. Uwe Aßmann, Softwaretechnologie 9

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

11 Drei-Schichten-Architektur Klassische Struktur eines (interaktiven) Anwendungssystems Basis für vielfältige Abwandlungen Schichten sind jeweils stark kohäsiv, und wenig gekoppelt aber warum? Benutzungsschnittstelle Basiert auf Analysemodell Fachlicher Kern Datenverwaltung Prof. Uwe Aßmann, Softwaretechnologie 11

12 Layered Architectural Styles and the USES Relationship Softwaretechnologie, Prof. Uwe Aßmann 12

13 How Can We Structure The Architecture of A System? Layering is an important feature of an architecture Simplicity Low coupling, strong cohesion How to achieve layering? Prof. Uwe Aßmann, Softwaretechnologie 13

14 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 is-a (inheritance) has-a (aggregation) owns-a is-composed-of (composition) 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 14

15 USES (Relies-On)-Relation Component A USES (relies-on) 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 mean: A accesses public variable of B A delegates work to B (A calls B) or B delegates work to A (B calls A). The uses relation is different from the call relation A allocates an instance of B A uses a resource provided by B 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 15

16 BCE/BCED Classification Boundary classes: <<boundary>> Represent an interface item that talks with the user May persist beyond a run <<control>> 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 <<entity>> <<database>> Often, Entity and Database classes are unified BCED is linked with the 3-tier architecture Prof. Uwe Aßmann, Softwaretechnologie 16

17 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 Graphical user interface (GUI, Benutzerschnittstelle) <<boundary>> Application logic (business logic, Fachlicher Kern) <<control>> Middleware (memory access, distribution) <<entity>> Data access object (DAO) Data Repository Layer (database, memory) <<database>> Prof. Uwe Aßmann, Softwaretechnologie 17

18 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 18

19 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>> Middleware Server http <<entity>> Data access object (DAO) Data Repository Layer (database, memory) <<database>> Prof. Uwe Aßmann, Softwaretechnologie 19

20 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 <<control>> <<servlet>> Server <<entity>> Data access object (DAO) Data Repository Layer (database, memory) <<database>> Prof. Uwe Aßmann, Softwaretechnologie 20

21 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 21..

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

23 Example: Database Systems SQL compiler transaction manager lock manager table manager physical storage management record management layer Prof. Uwe Aßmann, Softwaretechnologie 23

24 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 24

25 The Architectural Styles of Layered Abstract Machines (Layered Interpreters).. a special form of layered architecture for interactive systems... Softwaretechnologie, Prof. Uwe Aßmann 25

26 The Layered Abstract Machines Style (Layered Interpreters) The architectural style Layered Abstract Machines is a variant of a layered style, which assumes abstract machines (interpreters) on each layer There may be an arbitrary number of layers, not only 3 or 4 This style is the predominant style for interactive command systems Office systems Editors of any form Form-based applications Web-based applications Also for command-based batch systems Order processing Transaction processing (OLTP, online transaction processing) Prof. Uwe Aßmann, Softwaretechnologie 26

27 Layered Abstract Machines (Layered Interpreters) An abstract machine (interpreter) consists of a set of operations (functions) and data, realized in a lower level abstract (or real) machine. The lower level machine is hidden The abstract machine can be represented by a class or a module Relies on the design pattern Command and Interpreter (see Design Patterns and Frameworks ) <<interpreter>> Processor open() <<command>> read() <<command>> write() <<command>> close() <<command>> Prof. Uwe Aßmann, Softwaretechnologie 27

28 Layered Abstract Machines (Layered Interpreters) The USES relation between abstract machines should be cycle-free, i.e., layerable Realized by one or several modules or classes, whose interfaces export the operations and the data <<interpreter>> HigherProcessor open() <<command>> read() <<command>> write() <<command>> close() <<command>> realization <<interpreter>> LowerProcessor start() <<command>> get() <<command>> put() <<command>> stop() <<command>> Prof. Uwe Aßmann, Softwaretechnologie 28

29 Layered Abstract Machines Right abstract machine to solve the problem applicationorientedness Newly created even more abstract machine USES Relation Newly created abstract machine Specification or programming language Prof. Uwe Aßmann, Softwaretechnologie 29

30 Applications of Layered Abstract Machines Abstract machines are found on every level in systems, hardware and software Operating system: interface is a set of kernel or shell operations Programming language: operations are the set of language constructs system: the visual commands form the operations Macros: are translated to a lower level language Compiler: macros supported by static semantics The chip itself is an abstract/real machine, mapped to microcode Prof. Uwe Aßmann, Softwaretechnologie 30

31 The Entire Computer is an Abstract Machine Hierarchy Specification language Prolog-Interpreter High level programming language Intermediate language Assembler Pike-Interpreter, VDM JVM-Interpreter, emacs Lisp Code,.NET-VM Machine code Microcode Gates Physics? Kernel interface Chip simulator OS Microcode interpreter Prof. Uwe Aßmann, Softwaretechnologie 31

32 Wordprocessor as Layered Abstract Machine Wordprocessor Commands (textual, click-and-drop) Java USES Relation JVM Operating System C Assembler Prof. Uwe Aßmann, Softwaretechnologie 32

33 Structuring of Application Logic in 4-tier Architecture Layered Abstract Machines offer a structuring help for the application logic, but also for other layers. Graphical user interface Application logic (business logic) Abstract machine 1 <<control>> Abstract machine 2 Abstract machine 3 Middleware <<entity>> Data access object (DAO) Data Repository Layer (database, memory) Prof. Uwe Aßmann, Softwaretechnologie 33

34 Why not use Layered Abstract Machines in Your Project? If you design your project, and you have an interactive application Use 4-tier as general architectural style Try to identify abstract machines in the application logic layer (and may be the others, too) And layer them, so that your application has the style Layered Abstract Machines Advantage: further simplicity low coupling, high cohesion. Prof. Uwe Aßmann, Softwaretechnologie 34

35 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 The USES relationship 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 Both styles can be combined Prof. Uwe Aßmann, Softwaretechnologie 35

36 The End Prof. Uwe Aßmann, Softwaretechnologie 36