41-overview-architec..

Transcription

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 09-0.4, 02.01.09
1) Modularität und
Geheimnisprinzip
2) Geschichtete
Architekturen
Softwaretechnologie, © Prof. Uwe Aßmann
1
Obligatorische Literatur
►
►
►
Zuser Kap 10.
Ghezzi 4.1-4.2
Pfleeger 5.1-5.3
Prof. Uwe Aßmann, Softwaretechnologie
2
Sekundäre Literatur
►
D. Parnas. On a buzzword: hierarchical structure. Proceedings IFIP
Congress 1974, North-Holland, Amsterdam.
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
4
Von der Analyse zum Entwurf
Vertrag mit
dem Kunden
Analyse
AnforderungsErmittlung
AnforderungsSpezifikation
Produktdefi nition
(Anforderungen und
fachliches Modell)
Fachliche
Modellierung
ArchitekturSpezifi kation
KlassenSpezifi kationen
ArchitekturEntwurf
DetailEntwurf
Entwurf
5
Typische Bestandteile eines
Softwaresystems
►
►
►
►
►
Anwendungsspezifische
Funktionen
Benutzungsoberfläche
Ablaufsteuerung
Datenhaltung
Infrastrukturdienste
■
■
■
Objektverwaltung
Interne Objekt- und
Prozeßkommunikation
Verteilungsunterstützung
Architektur
►
►
►
►
Kommunikationsdienste
Sicherheitsfunktionen
Zuverlässigkeitsfunktionen
Systemadministration
■
■
Installation, Anpassung
Systembeobachtung
etc.
Anwendung
(spezifisch)
6
Aspekte des Architekturentwurfs
►
►
►
►
►
(Grobe) Strukturelle Zerlegung:
■
Blockdiagramme
■
Schichten, Sichten, Dimensionen
F1
F2
F3
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
7
Montagediagramme
►
►
Wurden schon in der Top-Level-Architektur behandelt
UML-Komponenten sind strukturiert und mit Anschlüssen
DokumentSystem
Adresses
email
DokumentSystem
Adress
Text
Manager
email
Manager
IText
TextRep
Text
Manager
Buffer
Lines
IForm
Forms
8
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.
9
Konfigurationsdiagramme
►
►
Konfigurationsdiagramme sind nicht Bestandteil von UML!
Konfigurationsdiagramme sind das meistverbreitete Hilfsmittel zur
Beschreibung der physikalischen Verteilung von Systemkomponenten.
Rechner, Knoten
Lokales
Kommunikationsnetz
Speicherndes
System
DatenkommunikationsNetz
10
Beispiel Terminverwaltung
PC1
... PCn
TerminServer
PDA1
PDAm
Physikalische
Konfi guration
AnzeigetafelSteuerung
PC Client
PDA Client
PDA Sync
Blockdiagramm
Termin-Manager
DatenExport
Termin-Datenbank
11
Architekturprinzip:
Hohe Kohäsion + Niedrige Kopplung
►
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.
Subsystem A
(z.B. Benutzungsoberfl äche)
Änderungen von Subsystem B sollten
nur möglichst einfache Änderungen in
Subsystem A nach sich ziehen.
Subsystem B
(z.B. fachlicher Kern)
►
Beispiele zur konkreten technischen
Realisierung siehe später
(MVC-Architektur, Entwurfsmuster)
12
Veränderungsorientierter Entwurf mit
dem Geheimnisprinzip
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
14
Komponentenmodelle und
Kompositionssysteme
►
►
Es gibt nicht nur die UML-Komponente....
sondern viele verschiedene Komponentenmodelle
■
■
■
■
■
■
►
Ein Kompositionssystem definiert:
■
■
■
►
Module einer modularen Programmiersprache (Modula, Ada)
Klassen in objektorientierten Sprachen
UML-Komponenten
Fragmentkomponenten, Schablonen
Dokumentkomponenten
Serverseitige Webkomponenten
Komponentenmodell: Eigenschaften der Schnittstelle einer
Komponente
Kompositionstechnik: Wie werden Komponenten komponiert?
Kompositionssprache: Wie wird die Architektur eines großen Systems
beschrieben?
--> Vorlesung CBSE (SS)
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
16
Geheimnisse von Modulen/Komponenten
►
►
Arbeitsweise von Algorithmen
Datenformate
■
►
Datentypen
■
►
►
►
►
►
Texte, Dokumente, Bilder
Abstrakte Datentypen und ihre konkrete Implementierung
Benutzerschnittstellenbibliotheken
Bearbeitungsreihenfolgen
Verteilung
Persistenz
Parallelität
17
Verschiedene Arten von
Komponenten/Modulen
Funktionale Module ohne Zustand
■
Daten-Repositorien
■
■
►
►
eim
Module, die ausgeprägt werden können
Generische Klassen (Klassenschablonen)
Komplexe Klassen (UML-Komponenten)
Fragmentkomponenten
...
►
eh
■
nis
Prozesse (aktive Objekte)
Klassen
sG
►
Klassen mit einer einzigen Instanz
da
►
pr
inz
ip
■
ilt
►
Abstrakte Datentypen
Singletons (Konfigurationskomponenten)
eg
►
Verbergen Repräsentation, Zugriff und Zustand der Daten
Symboltabellen, Materialcontainer, ...
all
►
sin, cos, BCD arithmetic, gnu mp,...
für
►
18
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
19
Entwurfsmuster Fassade zur
Reduktion von Kopplung
... Ein Entwurfsmuster im Geiste Parnas
(Wdh.)
20
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
21
Fassaden verbergen Subsysteme
►
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
HiddenSubsystem
operation()
adapted
Object1
HiddenClass1
specificOperation()
Concrete
Facade
operation()
adapted
Object2
adapted
Object3
HiddenClass2
specificOperation()
HiddenClass3
....
adaptedObject.specificOperation()
adaptedObject2.specificOperation()
....
specificOperation()
22
Restrukturierung hin zur Fassade
►
Fassaden entkoppeln; Subsysteme können leichter ausgetauscht
werden (Variabilitätsmuster)
Clients
Facade
Subsystem
23
Fassaden und Schichten
►
Falls einzelne Klassen eines Subsystems wieder Fassaden sind,
entstehen fassadengeschützte Schichten
Clients
Facade
Upper layer
Facade
Lower layer
24
Entwurfsmuster Fabrikmethode
(FactoryMethod)
zur polymorphen Variation von Komponenten (Produkte)
und zum Verbergen von Produkt-Arten
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
26
Struktur Fabrikmethode
►
FactoryMethod ist eine Variante von TemplateMethod, zur
Produkterzeugung
Creator
Product
ConcreteProduct
FactoryMethod()
anOperation()
...
Product = FactoryMethod()
...
ConcreteCreator
FactoryMethod()
return new ConcreteProduct
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);
}
...
}
28
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()
...
house = new Building();
house.construct();
...
house.createWall();
...
house.createDoor();
...
house.createWindow();
...
Framework
Skyscraper
Extensions
createWall()
createDoor()
createWindow()
createRoom()
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();
}
...
}
{
30
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
31
Einsatz in Komponentenarchitekturen
►
In Rahmenwerk-Architekturen wird die Fabrikmethode eingesetzt, um
von oberen Schichten (Anwendungsschichten) aus die
Rahmenwerkschicht zu konfigurieren:
Rahmenwerk
Building
Style
Building
Anwendung
Bungalow
Skyscraper
Castle
Modern
Style
Mideval
Style
32
Strategie (Strategy, Template Class)
(Wdh.)
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)
hookObject
TemplateClass
HookClass (Strategy)
templateMethod()
hookMethod()
hookObject.hookMethod()
ConcreteHookValueA
ConcreteHookValueB
hookMethod()
hookMethod()
34
Kombinierter Einsatz in Rahmenwerken
►
►
►
FactoryMethod variiert den Konstruktor
TemplateMethod oder Strategy (TemplateClass) variiert die
Hookmethode
Bridge (s. später) variiert die TemplateMethode
Rahmenwerk
Anwendung
Building
CastleTempl
CastleHook
createBuilding()
animate()
createBuilding()
drawBuilding()
drawBuilding()
Template
Class
Bungalow
ScottishCastle
drawBuilding()
createBuilding()
Template
Method
Factory
Method
35
Entwurfsmuster Einzelstück
(Singleton)
zur globalen Konfiguration einer Komponente
oder Schicht
(Wdh)
36
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;
}
}
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)
38
OOD.1.2 Schichtenarchitekturen
(Layered Architectural Styles)
und die “benutzt”-Relation
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
40
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
■
►
Whole/part
■
■
■
►
is-a (inheritance), behaves-like, ...
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 these41
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
42
Repeat: 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>>
Entity class:
■
■
►
Database class
■
■
►
Describes persistent knowledge. Caches a persistent object from a
database (data access object, DAO)
<<database>>
Adapter class for the database
Often, Entity and Database classes are unified
BCED is linked with the 3-tier architecture
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>>
44
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 ...
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
<<boundary>>
<<page>>
Graphical user interface
Client
<<control>>
<<applet>>
Application logic (business logic)
http
Middleware
Server
<<entity>>
Data access
object (DAO)
<<database>>
46
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
<<boundary>>
<<page>>
Client
http
<<control>>
<<servlet>>
Application logic (business logic)
Middleware
<<entity>>
Data access
object (DAO)
Server
<<database>>
47
Example: ISO-OSI 7 Layers Network
Architecture
►
Every layer contains an abstract machine (set of operations)
Presentation Layer
Presentation Layer
Session Layer
Session Layer
..
..
..
..
..
..
..
..
Data Transport Layer
Data Transport Layer
..
..
48
Example: Operating Systems
UNIX:
AppleUNIX
User Space
User Space
Kernel
Kernel
Microkernel (Mach)
Windows NT/XP:
User Space
Kernel
Hardware Abstraction Layer (HAL)
49
Example: Database Systems
SQL compiler
transaction manager
lock manager
table manager
physical storage management
record management layer
50
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
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
52
Conway’s Law on Software Structure
Software is always structured in the same
way as the organisation which built it.
53
The End
54

41-overview-architec..

Transcription

Documents pareils

02-inheritance

ein Chef geht stiften - Stiftung Meininger Baudenkmäler

transdisziplinäre Nachhaltigkeitswissenschaft

„Mixed Emotions“ – Christiansen`s Cocktailrezepte für jede

Kai-Messer sind eine scharfe Sache

Baufinanzierungsberater (m/w) - VR

22-st-programming-ag..

als PDF-Datei