Kapitel 5 Systementwurf, Komponenten und Architekturen - SE-Wiki

Vorlesung „Softwaretechnologie“
Wintersemester
te se este 2009
009
Kapitel 5
Systementwurf, Komponenten und
Architekturen
ROOTS
Systementwurf
 Ziel: Überbrücken der Lücke zwischen gewünschtem und
existierendem System auf handhabbare Weise
Problem
Gewünschtes System
Existierende
Systeme
 Idee: Anwendung des “Divide and Conquer”-Prinzips
 Modellierung des neuen Systems als Menge von Subsystemen
 Folgeproblem: „Crosscutting concerns“ – Übergeordnete Belange die
viele Subsysteme betreffen (z
(z.B.
B Persistenz
Persistenz, Nebenläufigkeit
Nebenläufigkeit, ...))
 Erst wenn diese geklärt sind, kann man die Subsysteme unabhängig
voneinander bearbeiten
 Weg: Zielbestimmung  Dekomposition  Klärung der
übergeordneten Belangen
 Danach erst Detailentwurf der Subsysteme
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-3
ROOTS
Systementwurf
Systementwurf
1. Entwurfsziele
8. Grenzfä
fälle
Definition
D
fi iti
Abwägungen
Initialisierung
Fehler
Ende
2. System
Dekomposition
7. Programmsteuerung
Ebenen / Partitionen
Kohärenz / Kopplung
Monolithisch
Ereignisbasiert
Threads
Parallele Prozesse
3. Hardware / Software
Zuordnung
Kaufen vs. Selbermachen
Netzwerktopologie
Allokation
6. Globale
Ressourcenverwaltung
Zugriffskontrolle
Sicherheit
4. Pesistente
5. Nebenläufigkeit
Identifizierung von
Datenverwaltung
Dateien
Datenbanken
Datenstrukturen
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Thread
Seite 5-4
ROOTS
Nutzung der Ergebnisse der Anforderungsanalyse
für den Systementwurf
y
 Nichtfunktionale Anforderungen 
 Aktivität
Akti ität 1:
1 Definition
D fi iti d
der E
Entwurfsziele
t
f i l
 Use Case Modell, Objektmodell 
 Aktivität
Ak i i ä 2:
2 Systemdekomposition
S
d k
i i (A
(Auswahl
hl von S
Subsystemen
b
nach
h
funktionalen Anforderungen, Kohärenz und Kopplung)
 Aktivität 3: Hardware/Software Zuordnung
 Aktivität 4: Persistentes Datenmanagement
 Use Case Modell, Dynamisches Modell 
 Aktivität 5: Nebenläufigkeit
 Aktivität 6: Globale Ressourcenverwaltung
 Aktivität 7: Programmsteuerung
 Aktivität 8: Grenzfälle
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-5
ROOTS
Kapitel-Überblick
 Ziele und Dekomposition
 1.
1 E
Entwurfsziele
t
f i l
 2. Dekomposition in Subsysteme
SystemArchitektur
 Zielgerichteter Entwurf
 3. Hardware/Software Zuordnung
 4. Management persistenter Daten
 5.
5 Nebenläufigkeit
 6. Globale Ressourcenverwaltung
 7. Programmsteuerung
 8. Grenzfälle
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-6
ROOTS
Vorlesung „ Softwaretechnologie“
Kapitel
ap te 55: Syste
Systementwurf
e t u
ROOTS
Ziele und Dekomposition
( Brügge & Dutoit, Kap. 6)
Entwurfsziele
Dienstidentifikation
Subsystemaufteilung
1. Entwurfsziele
externe
t
Qualitäten
Q lität
Endbenutzer
Kunde
•
•
•
•
•
•
Funktionalität
Niedrige Kosten
Erhöhte Produktivität
Abwärtskompatibilität
Schnelle Entwickelung
Flexibilität
• Laufzeiteffizienz
•
•
•
•
Benutzerfreundlichkeit
Intuitive Bedienung
Erlernbarkeit
Robustheit, Fehlertoleranz
• Zuverlässigkeit
• Portabilität
• Gute Dokumentation
•
•
•
•
•
Anpassbarkeit
Minimale Fehleranzahl
Änderbarkeit,
Änderbarkeit Lesbarkeit
Wiederverwendbarkeit,
Gut definierte Schnittstellen
interne Q
Qualitäten
Entwickler
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-8
ROOTS
Interessenskonflikte  Abwägungen
 Funktionalität vs. Benutzbarkeit
 Je
J überladener,
üb l d
um so schwerer
h
zu erlernen
l
 Funktionalität vs. schnelle Entwicklung
 Viel
Vi l Funktionalität
F ki
li ä zu iimplementieren
l
i
b
braucht
h Z
Zeit
i
 Kosten vs. Robustheit
 Sparen an Qualitätssicherung
 Kosten vs. Wiederverwendbarkeit
 Quick and dirty
 Effizienz vs. Portabilität
 Effizienz durch Speziallösung für bestimmtes Betriebssystem, DBMS, ...
 Abwärtskompatibilität vs. Lesbarkeit
 Viele Sonderfälle für Altversionen erschweren die Lesbarkeit
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-9
ROOTS
Bedeutung nichtfunktionaler
Anforderungen für den Systementwurf
 DilemmaZu viele Alternativen
 Die
Di gleiche
l i h F
Funktionalität
kti
lität iistt auff verschiedenste
hi d
t A
Arten
t realisierbar
li i b
 Nutzen von NFAAuswahlkriterien
 Nichtfunktionale Anforderungen dienen als Auswahlkriterien
 Sie fokussieren die Entwurfsaktivitäten auf die relevanten Alternativen
 Beispiele (NF Anforderung  Lösungsmöglichkeiten)
 „Hoher
Hoher Durchsatz“
Durchsatz  Parallelität,
Parallelität optimistische Vorgehensweise
Vorgehensweise, …
 „Zuverlässigkeit“  Einfache GUIs, Redundanz, …
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-10
ROOTS
2. Subsystem-Dekomposition
 Erster Schritt: Subsystem-Identifikation
 Welche
W l h Di
Dienste
t werden
d von d
dem S
Subsystemen
b
t
zur V
Verfügung
fü
gestellt
t llt
(Subsystem-Interface)?
 1. Gruppiere Operationen zu Diensten
 2. Gruppiere Typen die einen Dienst realisieren zu Subsystemen
 Zweiter Schritt: Subsystem-Anordnung
Subsystem Anordnung
 Wie kann die Menge von Subsystemen strukturiert werden?
 Wie interagieren
g
sie?
 Nutzt ein Subsystem einseitig den Dienst eines anderen?
 Welche der Subsysteme nutzen gegenseitig die Dienste der anderen?
  1.
1 Schichten und Partitionen
  2. Software Architekturen
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-11
ROOTS
Subsystem-Identifikation: Dienste
 Dienst: Menge von Operationen mit gemeinsamem Zweck
 Beispiel:
B i i l B
Benachrichtigungsdienst
h i hti
di
t
 lookupChannel(), subscribe(), sendNotice(), unsubscribe()
 Dienste werden während des Systementwurfs identifiziert und spezifiziert
 Dienstspezifikation: Vollständig typisierte Menge von Operationen
 In
I UML und
d JJava würde
üd d
das einem
i
'I'Interface'
t f
' entsprechen
t
h
 Beispiel: Spezifikation des obigem Dienstes
NotificationService
NotificationChannel lookupChannel(ChannelCharacteristics)
void subscribe(Observer)
void sendNotice(Notification)
void unsubscribe(Observer)
Entscheidung: Suche
nach Channel der
bestimmte Fähigkeiten
hat soll möglich sein.
Alternative: Suche
anhand von Namen
 Verwendete Schnittstellen (Observer, ...) müssen
natürlich auch spezifiziert werden
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-13
ROOTS
Subsystem-Identifikation: Subsysteme
 Subsystem (UML: Package)
 Stark
St k kohärente
k hä t Menge
M
von Kl
Klassen, A
Assoziationen,
i ti
O
Operationen,
ti
E
Events
t
und Nebenbedingungen die einen Dienst realisieren
 Wenn es gute Gründe gibt kann ein Subsystem mehr als einen Dienst
anbieten
 Frage: Was ist Kohärenz?
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-15
ROOTS
Subsystem-Identifikation: Kopplung und
Kohärenz
 Kohärenz = Maß der Abhängigkeiten innerhalb der Kapselungsgrenzen
(hier: innerhalb eines Subsystems)
 Starke Kohärenz: Die Klassen im Subsystem haben ähnliche Aufgaben und
sind untereinander verknüpft (durch Assoziationen)
 Kopplung = Maß der Abhängigkeiten zwischen den Kapselungsgrenzen
(hier: zwischen den Subsystemen)
 Starker Kopplung: Modifikation eines Subsytems hat gravierende
Auswirkungen auf die anderen (Wechsel des Modells, breite
Neukompilierung, usw.)
 Ziel: Wartbarkeit
 Die meisten Abhängigkeiten sollten innerhalb einzelner Subsysteme
bestehen, nicht über die Subsystemgrenzen hinweg.
 Kriterien
 Subsysteme sollten maximale Kohärenz und minimale Kopplung haben
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-16
ROOTS
Beispiel: Kopplung und Kohärenz
 Gegeben folgende drei Klassen. Die Pfeile zeigen Abhängikgeiten
(Feldzugriffe Methodeanaufrufe):
(Feldzugriffe,
A
B
C
a_1
b_1
c_1
a_2
b_2
c_2
a1(A,B,C)
b1(A,B,C)
c1(A,B,C)
a2(A,B,C)
b2(A,B,C)
c2(A,B,C)
a3(A,B,C)
b3(A,B,C)
c3(A,B,C)
a4(A B C)
a4(A,B,C)
b4(A B C)
b4(A,B,C)
c4(A B C)
c4(A,B,C)
Kaum Kohäsion.
 b_1,, b_2 ungenutzt
g
b1 gehört nach A!
 b2 - b4 gehören nach C!
Völlig unkohäsive
Klasse.
B kümmert
kü
t sich
i h mehr
h
um C-Elemente als C
selbst!
Klasse mit 2
unabhängigen
Kohäsionseinheiten
 aufsplitten in 2 Klassen!
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-17
ROOTS
Vorlesung „ Softwaretechnologie“
Kapitel
ap te 55: Syste
Systementwurf
e t u
ROOTS
Das Facade Pattern
Facade Pattern
 Absicht
 Menge
g von Interfaces eines Subsystems
y
zusammenfassen
 Abhängigkeiten der Clients von der Struktur des Subsystems reduzieren
client classes
client classes
Facade
subsystem
classes
subsystem
classes
 Subsystem-Schnittstellen-Objekt
S b
S h i
ll Obj k
 Objekt, das die Schnittstelle eines Subsystems nach außen darstellt
 Bietet alle Methoden der Subsystem-Schnittstelle
Subsystem Schnittstelle
 Vorteil: Clients müssen nichts über die Interna des Subsystems wissen
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-19
ROOTS
Facade Pattern: Beispiel
Facade
Compiler
compiler
subsystem
classes
compile()
St
Stream
BytecodeStream
CodeGenerator
StackMachineCodeGen
StackMachineCodeGen.
© 2000-2009 Dr. G. Kniesel
S
Scanner
T k
Token
Parser
Symbol
ProgramNodeBuilder
StatementNode
ProgramNode
ExpressionNode
VariableNode
RISCCodeGenerator
Vorlesung „Softwaretechnologie“
Seite 5-20
ROOTS
Facade Pattern: Anwendbarkeit
 Viele Abhängigkeiten zwischen Klassen
 Reduzieren
R d i
d
durch
h Facade-Objekte
F
d Obj kt
 Einfaches Interface zu einem komplexen
p
Subsystem
y
 Einfache Dinge einfach realisierbar (aus Client-Sicht)
 Anspruchsvolle Clients dürfen auch "hinter die Facade schauen"
 zB
B für
fü seltene,
lt
komplexe
k
l
Anpassungen
A
des
d Standardverhaltens
St d d h lt
 Hierarchische Strukturierung
g eines System
y
 Eine Facade als Einstiegspunkt in jede Ebene
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-21
ROOTS
Implementierung: Konfigurierbarkeit
einer Facade
Konfiguration
g
= Subklasse
Konfiguration
g
= Parameter
Compiler
Compiler
compile()
Compiler()
compile()
Compiler(CodeGenerator)
…
CodeGenerator
RISCCompiler
StackMachineCompiler
compile()
RISCCompiler()
compile()
StackMachineCompiler()
Stac
ac eCo p e ()
RISCCodeGenerator
StackMachineCodeGen
StackMachineCodeGen.
:Compiler
:RISCCompiler
…
…
:RISCCodeGenerator
© 2000-2009 Dr. G. Kniesel
:RISCCodeGenerator
Vorlesung „Softwaretechnologie“
Seite 5-23
ROOTS
Vorlesung „ Softwaretechnologie“
Kapitel
ap te 55: Syste
Systementwurf
e t u
ROOTS
Beispiel: Vom Analysemodell zur
Systemdekomposition
Gruppieren
pp
Dienste und Subsysteme einführen
Ausgangspunkt: Objektmodell der
Analyse
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-25
ROOTS
Naive System-Dekomposition: Nur
Gruppierung in Packages
Subsystem 1
Subsystem 5
Subsystem 2
Subsystem 3
Subsystem 4
Subsystem
y
6
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-26
ROOTS
System-Dekomposition: Dienste und
Komponenten
Subsystem 1
Subsystem 5
Subsystem 2
Subsystem 3
Subsystem 4
Subsystem
y
6
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-27
ROOTS
System-Dekomposition: DiensteRealisierung mit Facades
Subsystem 1
<<Facade>>
Subsystem 5
Subsystem 2
Subsystem 3
Subsystem 4
Subsystem
y
6
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-28
ROOTS
Namensräume versus Subsysteme
Die zwei vorherigen Folien illustrieren, dass Subsysteme viel mehr sind
als Packages
 Packages sind nur Namensräume, keine Kapselungseinheiten
 Sie verhindern zufällige Namensgleichheit, erlauben aber Zugriff (via
import-Mechanismus)
 Sie haben keine eigene Kapselungsgrenze (keine Schnittstelle)
 Sie reduzieren somit nicht die Abhängigkeiten (siehe vorvorherige Folien)
 Subsysteme werden als Komponenten (s. nächster Abschnitt) realisiert
 Sie haben klar definierte Kapselungsgrenzen (Schnittstellen)
 Sie
Si begrenzen
b
somit
it die
di möglichen
ö li h Abhä
Abhängigkeiten
i k it (d
(da nur üb
über di
die
Schnittstellen zugegriffen werden kann)
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-29
ROOTS
Aufgabe (Diskussion mit Kollegen)
 Überlegen, Sie ob das vorherige Beispiel eine gute oder schlechte
Dekomposition darstellt
darstellt.
 Diskutieren Sie, was für eine Systemdekomposition „gut“
„gut oder
„schlecht“ ist.
 Kategorisieren Sie die Dekomposition aus dem Beispiel als eine der
nachfolgend vorgestellten Software-Architekturen.
 Passt es genau? Brauchen Sie Änderungen damit es passt?
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-30
ROOTS
Darstellung von Subsystemen in der UML
 Lebenszeit von Komponenten
 Manche
M
h existieren
i ti
nur zur E
Entwurfszeit
t
f
it
 Manche existieren nur bis zur Kompilierung
 Manche existieren zur Bindungsg oder Laufzeit
Der Systementwurf muss somit statische und dynamische Strukturen
modellieren.
d lli
E
Er verwendet
d t
 Komponentendiagramme für statische Strukturen (zur Entwurfs- oder
Kompilierzeit)
p
)
 Verteilungsdiagramme für dynamische Strukturen (zur Installations-,
Lade-, und Laufzeit)
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-31
ROOTS
Vorlesung „ Softwaretechnologie“
Kapitel
ap te 55: Syste
Systementwurf
e t u
Software-Komponenten
ROOTS
Intuitive Vorstellung
Anbieter
Entwickler
Anbieter
Anbieter
Anbieter
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-33
ROOTS
Ziele
 Plattformunabhängige Wiederverwendung von Komponenten
 günstigere,
ü ti
 bessere und
 schnellere Softwareentwicklung.
g
 Unterstützung für flexibel anpassbare Geschäftsprozesse
 Einfach existierende Dinge zu einem neuen Verbund zusammensetzen
 Fokus auf intelligente Anwendung anstatt der wiederholten (Neu-)
(Neu )
Entwicklung des gleichen Basisfunktionalitäten
 Märkte für Komponenten
 Möglichkeit Komponenten von Drittanbietern zu kaufen
 Möglichkeit Komponenten an andere zu verkaufen
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-34
ROOTS
Komponenten-Definition
 Clemens Szyperski , WCOP 1996
 „Eine
Ei S
Softwarekomponente
ft
k
t ist
i t eine
i Kompositionseinheit
K
iti
i h it mit
it vertraglich
t li h
spezifizierten Schnittstellen und nur expliziten Kontextabhängigkeiten."
 „Eine Softwarekomponente kann unabhängig eingesetzt werden und wird
von Dritten zusammengesetzt."
 Literatur
 Workshop on Component-Based Programming (WCOP) 1996
 Clemens Szyperski:
„Component
C
t Software
S ft
– Beyond
B
d Object-Oriented
Obj t O i t d Programming“,
P
i “
Addison Wesley Longman, 1998.
 Clemens Szyperski, Dominik Gruntz, Stephan Murer:
„Component
C
S f
Software
– Beyond
B
d Object-Oriented
Obj
Oi
d Programming“,
P
i “
Second Edition, Pearson Education, 2002.
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-35
ROOTS
Komponenten
 Kernidee  Nur explizit spezifizierte Kontextabhängigkeiten
 Daher
D h auch
h „benutzte
b
t t S
Schnittstellen“
h itt t ll “ b
beschreiben!.
h ib !
 Beispiel
 Die Komponente
p
„„Bestellung“
g braucht einen „„Person“-Dienst um die
eigenen Dienste anbieten zu können.
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-36
ROOTS
Komponenten: Beispiel
 Komposition
 Die „Order
Order“-Komponente
-Komponente nutzt den „Person
Person“-Dienst
-Dienst von „Customer
Customer“
 Hierarchische Komponenten
 Die „Store-Komponente besteht ihrerseits aus drei Unterkomponenten
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-37
ROOTS
Interaktionsspezifikation durch
„Behaviour
Behaviour Protocoll
Protocoll“
 Gegeben
 Lösung
 Folgende
F l
d S
Schnittstelle
h itt t ll
 Z
Zu jedem
j d
T
Typ wird
i d sein
i
„Verhaltensprotokoll“ mit angegeben
DB_Interface
open(DB_descr)
open(DB
descr) : Connection
close(Connection)
query(Connection,SQL) : ResultSet
getNext(ResultSet)
g
(
) : Result
 Es ist ein regulärer Ausdruck der
legale Aufrufsequenzen und
Wiederholungen spezifiziert
 Beispiel
 Problem
 Wir wissen trotzdem nicht, wie das
beabsichtigte Zusammenspiel der
einzelnen Methoden ist.
 Kann man die Methoden in jeder
beliebigen Reihenfolge aufrufen?
 „Erst
E Verbindung
V bi d
zuer Datenbank
D
b k
erstellen, dann beliebig oft anfragen
und in jedem Anfrageergebnis
beliebig oft Teilergebnisse abfragen,
dann Verbindung wieder schließen.“
protocoll DB_Interface_Use =
open(DB descr) ,
open(DB_descr)
( query(Connection,SQL) : ResultSet ,
( getNext(ResultSet) : Result )* ,
)* ,
close(Connection)
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-38
ROOTS
SOFA (Software Appliances) Component
Model
 SOFA Component (http://dsrg.mff.cuni.cz/sofa)
 1.
1 provided and required interfaces
 2. frame (black-box view)
 3. architecture (gray-box view)
 4. connectors (abstract
(
interaction))
 5. behavior protocols associated with 1., 2. ,3.
 Behaviour Protocol
 incomming event (!)
 outgoing event (?)
 regular expression describing legal event sequences
 E
Example
l
 !open, [!query, [!getNext]* ]*, !close
 Behaviour protocols enable verification of composition
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-39
ROOTS
Weiterführende Literatur zu „Behaviour
Protocolls
Protocolls“
„SOFA / DCUP“ Projekt an der Karls-Universität Prag, Prof. Plasil und
Mitarbeiter
 http://dsrg.mff.cuni.cz/projects.phtml?p=sofa&q=0
 Hierachische Komponenten mit „angebotenen“
„angebotenen und „benutzten
„benutzten“
Schnittstellen
 Spezifikation von Behaviour Protocols für beide Arten von
Schnittstellen
 Automatische Verifikation der Protokolleinhaltung bei der Komposition
von Komponenten
p
 Horizontale Verbindung von „frames“ untereinander
 Vertikale Verbindung von „frame“ mit seiner „architecture“
 Das
D ganze sogar b
beii d
dynamischen
i h U
Updates
d t d
der K
Komposition
iti (d
(d.h.
h
Ersetzung von Komponenten zur Laufzeit)
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-40
ROOTS
OM
MG
Java
M
Microsoft
Übersicht über existierende Komponentenmodelle
Modell
IDL
Schnittstellen
Ereignisse
Konfiguration
Komposition
COM/DCOM
ja
nur provided
durch
Schnittstellen
nein
nein
COM+
ja
nur provided
Ereignisdienst
Kataloge
nein
.NET
Gemeinsames
Typsystem
nur provided
Nachrichtenserver
Einsatzbeschreibung
nein
JavaRMI
nein
nur provided
durch
Schnittstellen
nein
nein
JavaBeans
nein
nur provided
durch
Schnittstellen
Binärdatei
nein
EJB
nein
nur provided
durch
Schnittstellen
Einsatzbeschreibung
nein
CORBA
ja
nur provided
Ereignisdienst
nein
nein
CCM
ja
provided und
required
Quellen und
Verbraucher
Komponentenbeschreibung
Kompositions
beschreibung
ja
provided und
required und
behaviour
protocols
Quellen und
Verbraucher
KomponentenKomponenten
und Einsatzbeschreibung
Kompositions
beschreibung
SOFA
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-41
ROOTS
Charakteristika Komponentenbasierter
Softwareentwicklung
 Strikte Trennung zwischen Schnittstellen und Implementierung
 Die
Di S
Schnittstellenspezifikation
h itt t ll
ifik ti enthält
thält alle
ll Informationen
I f
ti
die
di ein
i potentieller
t ti ll
Benutzer kennen muss. Es gibt keine anderen Kontextabhängigkeiten.
 Verfügbarkeit
V fü b k it als
l Bi
Binärcode
ä d
 Komponenten werden in ausführbarer, binärer Form für viele Plattformen
geliefert. Quellcode ist nicht erforderlich.
 Plattformunabhängigkeit
 Komponenten können auf einer Vielzahl von Rechnerumgebungen /
Betriebssystemen eingesetzt werden.
 Ortstransparenz
 Komponenten verwenden oft in Verbindung mit Middleware-Systemen
eingesetzt, so dass man nicht wissen braucht, wo sich einzelne
Komponenten zurr Laufzeit
La f eit befinden
befinden.
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-42
ROOTS
Charakteristika Komponentenbasierter
Softwareentwicklung
 Wohldefinierter Zweck, der mehr als ein einzelnes Objekt umfasst
 Eine
Ei Komponente
K
t ist
i t auff ein
i spezifisches
ifi h Problem
P bl
spezialisiert
i li i t
 Wiederverwendbarkeit
 Als domänenspezifische Abstraktionen erlauben Komponenten
Wiederverwendung auf Ebene von (Teil-)Anwendungen
 Kontextfreiheit
 Die Integration von Komponenten sollte unabhängig von einschränkenden
Randbedingungen sein.
 Portabilität und Sprachunabhängigkeit
p
gg
 Es sollte möglich sein, Komponenten in (fast) jeder Programmiersprache
zu entwickeln.
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-43
ROOTS
Charakteristika Komponentenbasierter
Softwareentwicklung
 Reflektive Fähigkeiten
 Komponenten
K
t sollten
llt Reflektion
R fl kti unterstützen,
t tüt
so dass
d
di
die von Ih
Ihnen
angebotenen und benötigten Dienste durch Introspektion bestimmt werden
können.
 Plug & Play
 Komponenten sollten leicht einzusetzen sein.
 Konfiguration
 Komponenten sollten parametrisierbar sein, damit sie leicht neuen
Situationen angepasst werden können.
 Zuverlässigkeit
 Komponenten sollten ausgiebig getestet werden.
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-44
ROOTS
Charakteristika Komponentenbasierter
Softwareentwicklung
 Eignung für Integration / Komposition
 Es
E sollte
llt möglich
ö li h sein,
i K
Komponenten
t zu kkomplexeren
l
K
Komponenten
t
zusammenzusetzen. Komponenten müssen miteinander interagieren
können.
 Unterstützung für visuelle Kompositionswerkzeuge
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-45
ROOTS
Vorlesung „ Softwaretechnologie“
Kapitel
ap te 55: Syste
Systementwurf
e t u
Komponentendiagramme
ROOTS
Komponentendiagramm: UML 2.0
 Komponentendiagramm zeigt Komponenten und deren Abhängigkeiten
 Komponenten sind gekapselte Teile eines Systems mit nach außen
wohldefinierten Schnittstellen
 Angebotene
A
b t
Schnittstellen
S h itt t ll ((‚provided
id d interfaces‘)
i t f
‘)
 Benötigte/benutzte Schnittstellen (‚required interfaces‘)
 Komponenten kapseln beliebig komplexe Teilstrukturen
 Klassen, Objekte, Beziehungen oder ganze Verbünde von
Teilkomponenten ( hierarchische Komposition)
 Quellcode, Laufzeitbibliotheken, ausführbare Dateien, …
 Komponenten bieten ‚Ports‘
 Ein Port ist Name für eine Menge zusammengehöriger Schnittstellen
 Verschiedene Ports (Namen) für mehrfach vorhandene gleiche
Schnittstelle ((z.B. mehrere USB-Schnittstellen am g
gleichen Gerät))
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-47
ROOTS
Komponentendiagramm: Elemente
 Komponente ((„component“))
 Interface mit Stereotype
<<component>>
Name
<<stereotype>>
Name
 angebotenes Interface
 benötigtes Interface
 Port
 Beziehung
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-48
ROOTS
Komponentendiagramm: Beispiel
C
Camcorder
d
pal_Signal
tv_in
mic_Signal
mic_in
audio_out
audio_in
Computer
Komponenten-Verknüpfung
firewire_in_out
öffentlicher Port
angebotenes Interface
© 2000-2009 Dr. G. Kniesel
…
nicht-öffentlicher Port
benötigtes Interface
Vorlesung „Softwaretechnologie“
Seite 5-49
ROOTS
Komponenten und Rollen (‚Parts‘)
Komponenten können in Klassendiagrammen verwendet werden und
umgekehrt
 Rollen (‚Parts
(‚Parts‘))
 Der gleiche Typ (Interfaces oder Klasse) kann in verschiedenen
Komponenten verschiedene Rollen spielen.
 „Das
Das engl
engl. Wort „Part
Part“ heißt in diesem Kontext „Rolle
Rolle“, nicht „Teil
Teil“!!
 Notation
 Rollen mit Multiplizität
 Rolleninstanzen
© 2000-2009 Dr. G. Kniesel
Mutiplizität
Rolle:Typ [Multiplizität]
Rolle:Typ
instanz/Rolle:Typ
b1/Benutzer:Typ
Vorlesung „Softwaretechnologie“
Seite 5-50
ROOTS
Vorlesung „Softwaretechnologie“
Wintersemester
te se este 2009
009
ROOTS
Subsystem-Anordnung

Software-Architekturen
Subsystem Entwurf
 Erster Schritt: Subsystem-Dekomposition
 Welche
W l h Di
Dienste
t werden
d von d
dem S
Subsystemen
b
t
zur V
Verfügung
fü
gestellt
t llt
(Subsystem-Interface)?
 1. Gruppiere Operationen zu Diensten.
 2. Identifiziere Subsysteme als stark kohärente Menge von Klassen,
Assoziationen, Operationen, Events und Nebenbedingungen die einen
Dienst realisieren
 Zweiter Schritt: Subsystem-Anordnung
 Wie kann die Menge von Subsystemen strukturiert werden?
 Nutzt ein Subsystem einseitig den Dienst eines anderen?
 Welche der Subsysteme nutzen gegenseitig die Dienste der anderen?
  1. Schichten und Partitionen
  2. Software Architekturen
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-52
ROOTS
Softwarearchitekturen
 Architektur = Subsysteme + Beziehungen der Subsysteme
Architekturen
 Schichten-Architektur
Schichten Architektur
 Client/Server Architektur
 N-tier
 Peer-To-Peer Architektur
 Repository Architektur
 Model/View/Controller
M d l/Vi /C
ll A
Architektur
hi k
 Pips and Filter Architektur
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-53
ROOTS
Schichten und Partitionen
 Schicht (=Virtuelle Maschine)
 Subsysteme,
S b
t
di
die Di
Dienste
t fü
für eine
i höh
höhere Ab
Abstraktionsebene
t kti
b
zur V
Verfügung
fü
stellt
 Eine Schicht darf nur von tieferen Schichten abhängig sein
 Eine Schicht weiß nichts von den darüber liegenden Schichten
 Partition
 Subsysteme, die Dienste auf der selben Abstraktionsebene zur Verfügung
stellen.
 Subsysteme, die sich gegenseitig aufeinander neziehen
 Architekturanalysewerkzeuge
 Identifikation von Schichten und Partitionen
 Warnung vor Abhängigkeiten die der Schichtung entgegenlaufen
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-54
ROOTS
Schichten-Architekturen
Geschichtete Systeme sind hierarchisch. Das ist wünschenswert, weil
Hierarchie die Komplexität reduziert
reduziert.
 Geschlossene Schichten-Architektur
Schichten Architektur (Opaque Layering)
 Jede Schicht kennt nur die nächsttiefere Schicht.
 Geschlossene Schichten sind leichter zu pflegen.
 Offene Schichten-Architekturen (Transparent Layering)
 Jede Schicht darf alle tiefer liegenden Schichten kennen / benutzen
benutzen.
 Offene Schichten sind effizienter.
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-55
ROOTS
Geschlossene Schichten-Architektur
Beispiel „Verteilte
Verteilte Kommunikation
Kommunikation“
Application
Object
Presentation
Format
Session
Connection
Transport
Message
Network
Packet
DataLink
Frame
Physical
Bit
 ISO = International
Organization
g
for
Standardization
 OSI = Open System
Interconnection
 Das Referenzmodell definiert
Netzwerkprotokolle in 7
übereinander liegenden Schichten
sowie strikte Regeln zu
Kommunikation zwischen diesen
Schichten.
© 2000-2009 Dr. G. Kniesel
Absstraktionse
ebenen
 ISO’s
ISO’ OSI Referenzmodell
R f
d ll
Vorlesung „Softwaretechnologie“
Seite 5-56
ROOTS
Geschlossene Schichten-Architektur
Beispiel „Verteilte
Verteilte Kommunikation
Kommunikation“
Verteilte Programmierung
Application
Object
Presentation
Format
Session
Connection
Transport
Message
Network
Packet
DataLink
Frame
Physical
Bit
i mühsam
ist
üh
und
d ffehleranfällig:
hl
fälli
 Verbindungsherstellung
zwischen Prozessen
 Kommunikation zwischen
 Packen/Entpacken von
Informationen in Nachrichten
statt Parameterübergabe
g
 Umcodierung der Informationen
wegen heterogener Platformen
 Berücksichtigung
B
k i hi
technischer
h i h
Spezifika des Transportsystems
© 2000-2009 Dr. G. Kniesel
Compu
uter- und
Netzwerkhardware
e Betriebssystem
Prozessen statt Objekten
Vorlesung „Softwaretechnologie“
Seite 5-57
ROOTS
Geschlossene Schichten-Architektur
Middleware erlaubt Konzentration auf Anwendungsschicht
Garantiert Transparenz der


Verteilung
Platform
Plattform
Unterste Hardware- und
Softwareschichten
 Betriebssystem
 Computer- und
Netzwerkhardware
© 2000-2009 Dr. G. Kniesel
Compu
uter- und
Netzwerkhardware
e Betriebssystem
Middleware
Middlew
ware
• Middlewareabhängig
• Plattformunabhängig
Vorlesung „Softwaretechnologie“
Application
Object
Presentation
Format
Session
Connection
Transport
Message
Network
Packet
DataLink
Frame
Physical
Bit
Seite 5-58
ROOTS
Middleware
 Definition: Middleware
 Softwaresystem
S ft
t
auff Basis
B i standardisierter
t d di i t Schnittstellen
S h itt t ll und
d Protokolle,
P t k ll
die Dienste bietet, die zwischen der Plattform (Betriebssystem + Hardware)
und den Anwendungen angesiedelt sind und deren Verteilung unterstützen
 Bekannte Ansätze
 Remote Procedure Calls
 Java RMI (Remote Method Invocation)
 CORBA (Common Object Request Broker Architecture)
 Wünschenswerte Eigenschaften
 Gemeinsame Ressourcennutzung
 Nebenläufigkeit
 Skalierbarkeit
 Fehlertoleranz
 Sicherheit
 Offenheit
 Vertiefung: Vorlesung „Verteilte Systeme“ (Dr. Serge Schumilov)
Applikationsserver
 Definition: Applicationsserver
 Softwaresystem
S ft
t
das
d als
l Laufzeitumgebung
L f it
b
für
fü A
Anwendungen
d
di
dientt und
d
dabei über Middleware-Funktionen hinausgehende Fähigkeiten bietet
 Transparenz der Datenquellen
 Objekt-Relationales Mapping
 Transaktionsverwaltung
 Lebenszyklusmanagement („Deployment“, Updates, Start)
 Verwaltung zur Laufzeit (Monitoring, Kalibrierung, Logging, ...)
 Beispiel-Systeme
p
y
((kommerziell))
 IBM WebSphere
 Oracle WebLogic
 Beispiel-Systeme
B i i lS t
(open
(
source))
 JBoss
 Sun Glassfish
 Apache Tomcat
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-60
ROOTS
Schichten-ArchitekturClient/Server
Abbildung von Schichten auf Rechner im Netzwerk
 Server
S
bi
bieten
t Di
Dienste
t fü
für Cli
Clients
t
 Clients ruft Operation eines Dienstes auf; die wird ausgeführt und gibt
ein Ergebnis zurück
 Client kennt das Interface des Servers (seinen Dienst)
 Server braucht das Interface des Client nicht zu kennen
 Nutzer interagieren nur mit dem Client
Server
Client
*
*
requester
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
provider
service1()
…
service2()
...
serviceN()
i N()
Seite 5-62
ROOTS
Schichten-ArchitekturClient/Server
 Oft bei Datenbanksystemen genutzt
 Front-End:
F tE d N
Nutzeranwendung
t
d
(Cli
(Client)
t)
 Back-End: Datenbankzugriff und Datenmanipulation (Server)
 Vom
V
Cli
Clientt ausgeführte
füh t F
Funktionen
kti
 Maßgeschneiderte Benutzerschnittstelle
 Front-end-Verarbeitung
g der Daten
 Aufruf serverseitiger RPCs (Remote Procedure Call)
 Zugang zum Datenbankserver über das Netzwerk
 Vom Datenbankserver ausgeführte Funktionen
 Zentrales Datenmanagement
 Datenintegrität
D t i t ität und
dD
Datenbankkonsistenz
t b kk
i t
 Datenbanksicherheit
 Nebenläufige
g Operationen
p
((multiple
p user access))
 Zentrale Verarbeitung (zum Beispiel Archivierung)
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-63
ROOTS
Entwurfsziele für Client/Server Systeme
 Portabilität
 Server
S
k
kann
auff vielen
i l unterschiedlichen
t
hi dli h M
Maschinen
hi
und
dB
Betriebssystemen
ti b
t
installiert werden und funktioniert in vielen Netzwerkumgebungen
 Transparenz
 Der Server könnte selbst verteilt sein (warum?), sollte dem Nutzer aber
einen einzigen “logischen” Dienst bieten
 Performance
 Client sollte für interaktive, UI-lastig Aufgaben maßgefertigt sein
 Server sollte CPU-intensive Operationen bieten
 Skalierbarkeit
 Server hat genug Kapazität, um eine größere Anzahl Clients zu bedienen
 Flexibilität
 Server sollte für viele Front-Ends nutzbar sein
g
 Zuverlässigkeit
 System sollte individuelle Knoten-/Verbindungsprobleme überleben
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-64
ROOTS
Probleme mit Client/Server Architekturen
 Geschichtete Systeme unterstützen keine gleichberechtigte
gegenseitige ((„Peer-to-peer
Peer to peer“)) Kommunikation
 „Peer
„Peer-to-peer“
to peer Kommunikation wird oft benötigt
 Beispiel: Eine Datenbank empfängt Abfragen von einer Anwendung,
schickt aber auch Benachrichtigungen an die Anwendung wenn der
Datenbestand sich geändert hat
hat.
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-65
ROOTS
Schichten-ArchitekturVon der einfachen
Client/Server- zur N
Client/Server
N-Tier-Architektur
Tier Architektur
Entwurfsentscheidungen verteilter Client-Server-Anwendung
 Wie
Wi werden
d di
die A
Aufgaben
f b d
der A
Anwendung
d
auff Komponenten
K
t verteilt?
t ilt?
 Typische Aufgabenteilung
 Präsentation – Schnittstelle zum Anwender
 Anwendungslogik – Bearbeitung der Anfragen
 Datenhaltung – Speicherung der Daten in einer Datenbank
 Wie viele Prozessräume gibt es?
Tier N
 Eine Stufe / Schicht (engl. ‚tier‘) kennzeichnet einen
Prozessraum innerhalb einer verteilten Anwendung
 Das N legt fest, wie viele Prozessräume es gibt
 Ein Prozessraum kann, muss jedoch nicht(!),
physikalischen
y
Rechner entsprechen
p
einem p
…
Tier 2
 Wie werden die Komponenten auf Prozessräume verteilt?
 Die Art der Zuordnung der Aufgaben zu den
Tier 1
tiers macht den Unterschied der verschiedenen
n-tier Architekturen aus
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-66
ROOTS
2-Tier Architektur
 Ältestes Verteilungsmodell: Client- und Server-Tier
 Zuordnung von Aufgaben zu Tiers
 Präsentation  Client
 Anwendungslogik  Beliebig
 Datenhaltung  Server
 Vorteile
 Einfach und schnell umzusetzen
 Performant
 Probleme
 Schwer wartbar
 Schwer skalierbar
 Software-Update Problem
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-67
ROOTS
2-Tier ArchitekturVarianten
 Ultra-Thin-Client Architekturen (a):
 Die Client
Client-Tier
Tier beschränkt sich auf Anzeige von Dialogen in einem Browser
Browser.
 Thin-Client Architekturen (a,b):
 Die Client-Tier beschränkt sich auf Anzeige von Dialogen und die Aufbereitung
d D
der
Daten
t zur A
Anzeige.
i
 Fat-Client Architekturen (c,d,e):
 Teile der Anwendungslogik liegen zusammen mit der Präsentation auf der
Cli
Client-Tier.
Ti
Client machine
User interface
User interface
User interface
User interface
User interface
Application
Application
Application
Database
User interface
Application
Application
Application
Database
Database
Database
Database
Database
(b)
S
Server
machine
hi
(c)
(d)
(e)
(a)
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-68
ROOTS
3–Tier Architekturen
 Zuordnung von Aufgaben zu 3 Tiers
 Präsentation
Pä
t ti  Client-Tier
Cli t Ti
3-Tier-Architektur
Client-Tier
Pä
Präsentation
t ti
Middle-Tier
Middle
Tier
Anwendungslogik
Server-Tier
Datenhaltung
 Anwendungslogik  Middle-Tier
 Datenhaltung
g  Server-Tier
 Standardverteilungsmodell
St d d t il
d ll fü
für einfache
i f h W
Webanwendungen
b
d
 Client-Tier = Browser zur Anzeige
 Middle-Tier = Webserver mit Servlets / ASP / Anwendung
g
 Server-Tier = Datenbankserver
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-69
ROOTS
3–Tier ArchitekturenBeispiel
Webanwendungen
 Standardverteilungsmodell für einfache Webanwendungen:
User-interface
level
User interface
HTML page
containing list
Keyword expression
HTML
generator
Query
generator
Database queries
Ranked list
of page titles
Ranking
component
Web page titles
with meta-information
© 2000-2009 Dr. G. Kniesel
Processing
level
Vorlesung „Softwaretechnologie“
Seite 5-70
Data level
ROOTS
3–Tier ArchitekturenApplicationsServer (EJB)
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-71
ROOTS
4- und Mehr-Tier Architekturen
 Unterschied zu 3-Schichten-Architekturen
 Die
Di A
Anwendungslogik
d
l ik wird
i d auff mehrere
h
S
Schichten
hi ht verteilt
t ilt (W
(Webserver,
b
Application Server)
 Motivation
 Minimierung
Minimier ng der Komple
Komplexität
ität ((„Divide
Di ide and Conquer“)
Conq er“)
 Besserer Schutz einzelner Anwendungsteile
g für die meisten Applikationen
pp
im E-Bereich
 Grundlage
 E-Business, E-Commerce, E-Government
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-72
ROOTS
4-Tier-Architektur eines
Informationssystems
Client
Tier
Web
Tier
Enterprise IS
Tier
Application
Tier
Legacy
Anwendungen
Application Server
Personalization
Process
Engine
Security
W b
Web
Web
Server
Transactions
Web Service
Interfaces
(WSDL, SOAP)
Enterprise
D t
Data
E-Business
Komponenten
p
Directory
Encryption
Backend
Interface
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-73
ROOTS
N-Tier-ArchitekturAbwägungen
Box = Komponente des Systems
Client-Tier
Pfeil = Komm
Kommunikationsverbindung
nikations erbind ng
 Mehr Boxen
 mehr Verteilung + Parallelität
 mehr Kapselung + Wiederverwendung
 Mehr Boxen
 mehr Pfeile
 Verbindungen zu verwalten
 mehr Koordination + Komplexität
 Mehr Boxen
 mehr Vermittlung
 mehr Datentransformationen
 schlechte Performanz
Entwickler einer Architektur versuchen
deswegen immer ein Kompromiss zu finden
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Server-Tier
Es gibt kein Designproblem, das man
durch Einführung einer zusätzlichen
g
Vermittlungsschicht
nicht lösen kann.
Es gibt kein Performanzproblem, das
man durch Entfernung einer zusätzlichen
Vermittlungsschicht nicht lösen kann
kann.
Seite 5-74
ROOTS
Peer-to-Peer Architektur
 Generalisierung der Client/Server Architektur
 Clients
Cli t können
kö
Server
S
sein
i und
d umgekehrt
k ht
 Schwieriger wegen möglicher Deadlocks
Peer
requester
*
service1()
service2()
…
serviceN()
i N()
application1:DBUser
*
provider
1. updateData
database:DBMS
application2:DBUser
2 changeNotification
2.
h
ifi
i
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-75
ROOTS
Pipe-and-Filter-Architecture
ausgabe
1
*
eingabe
L it
Leitung
(Pipe)
(Pi )
Filt
Filter
*
ausgabe
eingabe
1
 Filter-Subsysteme
Filt S b
t
b b it D
bearbeiten
Daten
t
 Es sind reine Funktionen
 Sie sind konzeptionell
p
und implementierungstechnisch
p
g
unabhängig
g g von
 den Pipes die die Daten zu ihnen bzw. von ihnen Weg leiten
 den Erzeugern und Verbrauchern der Daten
 Leitungs-Subsysteme leiten Daten weiter
 Sie sammeln Daten von einem oder mehreren Filtern
 Sie leiten Daten an einen oder mehrere Filter weiter
 Sie dienen der Synchronisation paralleler Filteraktivitäten
 Sie sind von allen anderen Subsystemen völlig unabhängig (genau wie die
Filter)
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-76
ROOTS
Pipe-and-Filter-Architektur: Ausschnitt
aus möglicher Systemkonfiguration
 Das Gesamtsystem entsteht einfach durch die Verknüpfung von Pipe-
und Filter-Subsystemen
Filter Subsystemen
…
:Filter
…
:Filter
:Filter
:Pipe
:Filter
:Pipe
:Filter
:Pipe
:Filter
…
:Filter
…
:Filter
…
 Vorteile
 Flexibilität: leichter Austausch von Filtern, Leichte Rekonfiguration der
Verbindungen über Pipes
 Effizienz: Hoher Grad an Parallelität (alle Filter können Parallel arbeiten!)
 Gut geeignet für automatisierte Transformationen auf Datenströmen
 Beispiel: Sattelitendatenbearbeitung
Pipe-and-Filter-Architektur: Ausschnitt
aus möglicher Systemkonfiguration
 Das Gesamtsystem entsteht einfach durch die Verknüpfung von Pipe-
und Filter-Subsystemen
Filter Subsystemen
…
:Filter
…
:Filter
:Filter
:Pipe
:Filter
:Pipe
:Filter
:Pipe
:Filter
…
:Filter
…
:Filter
…
 Weniger geeignet für
 Hochinteraktive Aufgaben
 Benutzerinteraktion macht die potentielle Parallelität zunichte
 Aufgaben, wo die Daten sich nicht bzw. nur wenig ändern, da sich dann
der Aufwand die Daten ständig zu kopieren nicht lohnt
 In diesem Fall ist eine Repository-Architektur
p
y
vorteilhafter
Repository Architektur
 Subsysteme lesen und schreiben Daten einer einzigen, gemeinsamen
Datenstruktur
 Subsysteme sind lose gekoppelt (Interaktion nur über das Repository)
 Kontrollfluss wird entweder zentral vom Repository diktiert (Trigger)
oder von den Subsystemen bestimmt (locks, synchronization
primitives)
Repository
Subsystem
createData()
setData()
getData()
searchData()
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-79
ROOTS
Repository Architektur: Beispiel „Eclipse“
Compiler
SemanticAnalyzer
SyntacticAnalyzer
LexicalAnalyzer
Optimizer
CodeGenerator
Repository
ParseTree
SymbolTable
SourceLevelDebugger
© 2000-2009 Dr. G. Kniesel
Type Info
Editor
Vorlesung „Softwaretechnologie“
Seite 5-80
ROOTS
Model/View/Controller
 Subsysteme werden in drei verschiedene Typen unterteilt
 Model
M d l Subsystem:
S b
t
Z tä di fü
Zuständig
für d
das Wi
Wissen d
der A
Anwendungsdomäne
d
d ä und
d
Benachrichtigung der Views bei Änderungen im Model.
 View Subsystem: Stellt die Objekte der Anwendungsdomäne für den
Nutzer dar
 Controller Subsystem: Verantwortlich für die Abfolge der Interaktionen mit
dem Nutzer.
 MVC ist eine Verallgemeinerung der Repository Architektur:
 Das Model Subsystem implementiert die zentrale Datenstruktur
 Das
D C
Controller
t ll S
Subsystem
b
t
schreibt
h ibt explizit
li it d
den K
Kontrollfluss
t llfl
vor
initiator
Controller
*
1
p
y
repository
Model
View
© 2000-2009 Dr. G. Kniesel
subscriber
1
notifier
*
Vorlesung „Softwaretechnologie“
Seite 5-81
ROOTS
Beispiel einer auf der MVC Architektur
basierenden Dateiverwaltung
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-82
ROOTS
Abfolge von Events
2. User types new filename
:Controller
:Model
:InfoView
5. Updated views
:FolderView
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-83
ROOTS
Zusammenfassung
 Systementwurf
 Verkleinert
V kl i t di
die Lü
Lücke
k zwischen
i h A
Anforderungen
f d
und
dd
der IImplementierung
l
ti
 Zerteilt das Gesamtsystem in handhabbare Stücke
 Definition der Entwurfsziele
 Beschreibt und priorisiert die für das System wichtigen Qualitäten
 Definiert das Wertesystem anhand dessen Optionen überprüft werden
 Subsystemdekomposition
 Führt zu einer Menge lose gekoppelter Teile, die zusammen das System
bilden
 Softwarearchitektur
 Beschreibt die Beziehungen / Interaktionen der Subsysteme
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-84
ROOTS
Vorlesung „Softwaretechnologie“
Wintersemester
te se este 2009
009
Zielgerichteter Entwurf
( Brügge & Dutoit, Kap. 7)
ROOTS
Überblick
 Dekomposition (vorhergehender Abschnitt)
 0.
0 Überblick
Üb bli k üb
über d
das S
Systementwurf
t
t
f
 1. Entwurfsziele
 2. Dekomposition
p
in Subsysteme
y
 Zielgerichteter Entwurf
 3. Nebenläufigkeit
 4. Hardware/Software Zuordnung
 5.
5 Management persistenter Daten
 6. Globale Ressourcenverwaltung und Zugangskontrolle
 7. Programmsteuerung
 8. Grenzfälle
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-86
ROOTS
3. Nebenläufigkeit
 Identifizieren nebenläufiger Ausführungsstränge und Behandeln von
Fragen zur Nebenläufigkeit.
Nebenläufigkeit
 Entwurfsziel: Reaktionszeit, Performance.
 Threads („Fäden“, „Stränge“)
 Ein Thread ist ein Pfad durch eine Menge von Zustanddiagramme, wobei
stets genau ein Objekt zur selben Zeit aktiv ist.
 Ein Thread bleibt in einem Zustandsdiagramm bis ein Objekt einen Event
an ein anderes Objekt sendet und auf einen anderen Event wartet
 Thread (ab-)spaltung: Ein Objekt sendet ein asynchrones Event
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-87
ROOTS
Nebenläufigkeit (Fortsetzung)
 Zwei Objekte heißen inhärent nebenläufig, wenn sie zur gleichen Zeit
Events empfangen können ohne zu interagieren
 Inhärent nebenläufige Objekte sollten verschiedenen Threads
zugeordnet werden
 Objekte
Obj kt mit
it sich
i h wechselseitig
h l iti ausschließenden
hli ß d Akti
Aktivitäten
ität sollten
llt
demselben Thread zugeordnet werden (Warum?)
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-88
ROOTS
Fragen zur Nebenläufigkeit
 Welche Objekte des Objektmodells sind unabhängig?
 Welche Arten von Threads sind identifizierbar?
 Bietet das System vielen Nutzern Zugriff?
 Kann eine einzelne Anfrage an das System in mehrere Teilanfragen
zerlegt werden?
 Können diese Teilanfragen parallel abgearbeitet werden?
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-89
ROOTS
4. Hardware/Software Zuordnung
 Diese Aktivität befasst sich mit zwei Fragen:
 Wie sollen wir jjedes einzelne Subsystem
y
realisieren
 In Hardware oder in Software?
 Welche Hard- / Software ist schon verfügbar?
 Komponenten von Drittanbietern die man nutzen kann
 Altlasten die man integrieren muss
 Wie wird das Objektmodell auf die gewählte Hard- und Software
abgebildet?
b bild t?
 Objekte in die Realität abbilden  auf Prozessor, Speicher, Input/Output
 Assoziationen in die Realität abbilden  auf Bus-/Netzwerktopologie
 Ein Großteil der Schwierigkeiten beim Entwurf eines Systems ist die
Folge von außen auferlegter Einschränkungen bzgl
bzgl. Hard
Hard- und
Software.
 „Aufgabe X muss von Hard- /Software Y gelöst werden.“
 „Wir haben gerade erst X Millionen für System Y ausgegeben…“
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-90
ROOTS
Zuordnung von Objekten
 Prozessor
 Ist
I t die
di geforderte
f d t Berechnungsgeschwindigkeit
B
h
h i di k it zu h
hoch
h fü
für einen
i
einzelnen
i
l
Prozessor?
 Bringt die Verteilung der Aufgaben auf verschiedene Prozessoren einen
Geschwindigkeitsgewinn?
 Wie viele Prozessoren sind für den dauerhaft stabilen Betrieb unter
Dauerlast notwendig?
 Speicher
 Ist genug Speicher vorhanden, um Belastungsspitzen abzufangen?
 I/O:
I/O
 Ist zusätzliche Hardware erforderlich, um die anfallenden Datenmengen zu
bewältigen?
 Reicht die Kommunikationsbandbreite zwischen den Subsystemen oder
angeschlossener Hardware, um die gewünschte Reaktionszeit zu
garantieren?
g
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-91
ROOTS
Zuordnung der Assoziationen:
Kommunikationstopologie
 Beschreibe die physikalische Topologie der Hardware
 Entspricht
E t i ht oft
ft der
d physikalischen
h ik li h S
Schicht
hi ht iin ISO’
ISO’s OSI Referenzmodell
R f
d ll
 Welche Assoziationen werden auf physikalische Verbindungen abgebildet?
 Welche <<benutzt>>-Beziehungen aus dem Analyse-/Entwurfsmodell
korrespondieren mit physikalischen Verbindungen?
 Beschreibe die logische Topologie (Assoziationen zwischen den
Subsystemen)
 Identifiziere Assoziationen, die nicht direkt auf physikalische Verbindungen
abzubilden sind:
 Wie sollen diese Assoziationen implementiert werden?
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-92
ROOTS
Netzwerktopologie bei verteilten
Systemen
 Wenn die Architektur verteilt ist, müssen wir auch die
Netzwerkarchitektur beschreiben (Kommunikationssubsystem)
(Kommunikationssubsystem).
 Zu stellende Fragen
 Was ist das Übertragungsmedium?
g g
((Ethernet,, Wireless))
 Welche “Quality of Service” (QOS) ist vorhanden/erforderlich? Welche Art
von Kommunikationsprotokollen können genutzt werden?
 Sollen Interaktion asynchron
asynchron, synchron oder sperrend sein?
 Welche Anforderungen gibt es an die Bandbreite zwischen den
Subsystemen?
 Stock
St k Price
P i Change
Ch
-> Broker
B k
 Icy Road Detector -> ABS System
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-93
ROOTS
Typisches Beispiel für physikalische
Topologie
Application
Client
Application
Client
Application
Client
TCP/IP
Ethernet
LAN
Communication
Agent for
Application Clients
Communication
Agent for
Application
pp
Clients
Backbone Network
TCP/IP
Global
Data
Server
Communication
Agent for Data
Server
LAN
OODBMS
Global
Data
Server
Communication
Agent for Data
Server
RDBMS
LAN
Local Data
Server
Global Data
Server
Fragen zu Hardware/Software Zuordnung
 Ist bestimmte Funktionalität schon in Hardware verfügbar?
 Müssen
Mü
Aufgaben
A f b auff bestimmter
b ti
t Hardware
H d
ausgeführt
füh t werden,
d
um
andere Hardware zu steuern oder nebenläufige Operationen zu
erlauben?
 Das ist für Embedded Systems oft der Fall.
 Welche Hard-/ Softwaresysteme existieren
 ... und
d kö
können oder
d müssen
ü
genutzt
t t werden
d
 Welche Vernetzungstopologie besteht zwischen den physikalischen
Einheiten?
 Baum, Stern, Matrix, Ring
 Was ist das passende Kommunikationsprotokoll zwischen den
Subsystemen?
 Abhängig von Bandbreite, Latenz und gewünschter Sicherheit
 Generelle Frage
g zur Systemperformance:
y
p
 Was ist die gewünschte Reaktionszeit?
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-95
ROOTS
Vorlesung „ Softwaretechnologie“
Kapitel
ap te 55: Syste
Systementwurf
e t u
ROOTS
Timing-Diagramme für
Realzeitanforderungen
3a. Realzeitanforderungen
 Realzeitanforderungen bezeichnen Anforderungen an Software in
einer bestimmten Zeitspanne zu reagieren oder etwas zu einem
bestimmten Zeitpunkt zu tun
 Meistens geht es um sehr kurze Zeitspannen (Sekunden und alles
darunter)
 Typischerweise bei "Eingebetteten Systemen" (Mischung aus Hard-
und Software)
 Im Fahrzeug- und Maschinenbau, Telekommunikation, Anlagen, …
 Dilemma
 Software ist flexibler (leichter austauschbar und wartbar) und
kostengünstiger
 Aussagen über die absolute Zeit
Zeit, die ein bestimmter Aufruf dauert sind
aber sehr schwer zu treffen
 Problem "Dynamisches Binden": Was wird denn nun aufgerufen?
 Problem "Garbage
Garbage Collection
Collection":: Wann unterbricht sie evtl
evtl. einen Aufruf?
 …
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-97
ROOTS
Zeitverlaufsdiagramm (Timing Diagram)
 Modelliert zeitabhängige Zustandsübergänge der Interaktionspartner
 Auslöser
A lö
iistt ffester
t Zeitpunkt
Z it
kt oder
d Nachrichtenaustausch
N h i ht
t
h
 Nützlich bei Interkationen mit zeitkritischem Verhalten
(
(Realzeitanforderungen)
g )
 Stellt exemplarischen Ablauf da (keine Kontrollstrukturen o.ä.)
ti i name
timing
Rolle:Typ
at(t=14.00)
Z1
Z2
Z3
Zustandswechsel
zu festem Zeitpunkt
m2
m4
Zustände
Rolle:Typ
m1
Zustandswechsel durch
Nachrichtenempfang
p g
m3
Z1
Z2
Z3
Zeitachse
Objekt-Typ
Obj
kt T und
d
-Rolle
01234
17 s
Zeiteinheit
Zeitdiagramm„Telefongespräch“
timing Telefongesprächsaufbau
talking
lifting
receiver
ringing
idle
t=now
exchange
{t..t+10}
active
idle
t lki
talking
ringing
caller
g
connecting
dialing
lifting
idle
{0 .. 2}
01234
21 s
Sequenz- versus Zeitverlaufsdiagramm
Sequenzdiaramm
q
mit Zeit
Timing
g Diagramm
g
 Keine Darstellung des
 Keine Kontrollstrukturen
Zusammenhangs von
N h i ht und
Nachrichten
d
Zustandsübergängen
 Gleiche Zeitinformationen
darstellbar (Zeitpunkt, relativer
und absoluter Zeitraum)
sd P
timing
gP
:A
:B
m1
{0..3s}
t=now
:A
X
Y
Z
:B
U
V
W
m2 {0..1 s}
m3
{t..t+5s}
0 1 2 3 4 5 6 7 8 9
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-100
s
ROOTS
Vorlesung „ Softwaretechnologie“
Kapitel
ap te 55: Syste
Systementwurf
e t u
Verteilungsdiagramme
(Deployment Diagrams)
ROOTS
Verteilungsdiagramm (Einsatzdiagramm
/ Deployment Diagram)
 Zeigt
 Ausführungsknoten
A füh
k t (Rechner
(R h
und
dL
Laufzeitumgebungen),
f it
b
)
 Kommunikationsbeziehungen zwischen Ausführungsknoten,
 Manifestation ((=Realisierung)
g) von Komponenten
p
durch Artefakte,
 Einsatz von Artefakten auf Ausführungsknoten,
 Konfiguration des Einsatzes,
 sonstige
ti Beziehungen
B i h
(Abhängigkeits-Pfeile
(Abhä i k it Pf il zeigen
i
von d
der abhängigen
bhä i
Komponente weg)
 Nutzen: Spezifikation der
 Hardware/Software Zuordnung
 Subsystemdekomposition
S bs stemdekomposition
 Verteilung im Netzwerk
 Einsatz zur Laufzeit
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-102
ROOTS
Verteilungsdiagramm  Knoten
 Komponente
 Logische Einheit mit expliziten Abhängigkeiten
 Wie im Komponentendiagramm definiert
 Artefakt
 Physische Einheit, z.B. Modell, Beschreibung,
Quellcode, ausführbarer Code
 Realisierung einer Komponente
 Laufzeitumgebung („execution environment“)
 Softwaresystem in dem Artefakte zum Einsatz
kommen
 Z.B. Java Virtual Machine, Applikationsserver, …
 Gerät („device“)
 Physikalisches Gerät auf dem Artefakte zum
Einsatz kommen (Rechner)
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
<<component>>
CALENDAR
<<artifact>>
Calendar.java
<<execution environment>>
:Browser
<<device>>
calendarClient:PC
Seite 5-103
ROOTS
Verteilungsdiagramm  Kanten
<<component>>
CALENDAR
 Manifestation (<<manifest>>)
 Komponente ist durch Artefakt realisiert
<<manifest>>
<<artifact>>
 Einsatzbeziehung (<<deploy>>)
 Artefakt wird auf Ausführungsumgebung
oder Gerät eingesetzt
Calendar.java
<<deploy>>
<<execution environment>>
:Browser
 Kommunikationsbeziehung
 Physische Verbindung über die
Ausführungsumgebungen kommunizieren
 Art kann als Stereotyp angegeben werden,
z.B. <<internet>>, <<ethernet>>, …
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
<<internet>>
<<device>>
<<device>>
calClient:
calServer:
Seite 5-104
ROOTS
Verteilungsdiagramm  Beispiel
<<device>>
<<internet>>
<<ethernet>>
<<device>>
calServer:Host
calClient:PC
<<execution
Environment>>
<<device>>
dbServer
<<execution
Environment>>
:Browser
:J2EE Server
<<artifact>>
jdbc.jar
<<deploy>>
<<deploy>>
<<artifact>>
<<artifact>>
<<deployment spec>>
CALENDAR.class
calServerProgram.jar
calServerProgram.xml
maxUsers : 50
transactionMode : nested
<<manifest>>
<<component>>
CALENDAR
C
© 2000-2009 Dr. G. Kniesel
CS 1
CS 2
Vorlesung „Softwaretechnologie“
CS 3
Seite 5-105
ROOTS
Verteilungsdiagramm  Beispiel 
Textuelle Erläuterung
<<device>>
<<internet>>
<<ethernet>>
<<device>>
calServer:Host
calClient:PC
<<execution
Environment>>
<<device>>
dbServer
<<execution
Environment>>
:Browser
:J2EE Server
<<artifact>>
jdbc.jar
<<deploy>>
<<deploy>>
<<artifact>>
<<artifact>>
<<deployment spec>>
CALENDAR.class
calServerProgram.jar
calServerProgram.xml
maxUsers : 50
transactionMode : nested
<<manifest>>
<<component>>
CALENDAR
C
© 2000-2009 Dr. G. Kniesel
CS 1
CS 2
Vorlesung „Softwaretechnologie“
CS 3
Seite 5-106
ROOTS
Visual Paradigm  Tips I
Dies sind die für „Deployment Diagrams“ spezifischen Elemente,
die auf den vorherigen Folien erklärt wurden.
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-107
ROOTS
Visual Paradigm  Tips II
 Generell ist es wichtig zwischen Namen und Stereotyp einer Beziehung
zu unterscheiden
unterscheiden. Der Stereotyp gibt die Art einer Beziehung an
an. Der
Name ist lediglich ein Bezeichner.
 Das gilt auch für Kommunikationsbeziehungen! Also schreiben Sie bitte
nicht z.B. „ethernet“ in den Namen, sondern machen Sie es wie hier:
 So sollte es richtig sein
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-108
ROOTS
Vorlesung „Softwaretechnologie“
Wintersemester
te se este 2009
009
ROOTS
Datenmanagement
Datenmanagement
 Einige Objekte in den Modellen müssen persistent sein
 Trenne
T
sauber
b zwischen
i h den
d Subsystemen,
S b
t
die
di Persistenz-Dienste
P i t
Di
t
anbieten und denen, die sie nutzen.
 Definiere klare Schnittstellen.
 Ein nicht persistentes Objekt kann durch Datenstrukturen realisiert
werden
 Ein persistentes Objekt kann folgendermaßen realisiert werden
 Dateien
 Billig, einfach, permanente Speicherung
 Low level (Lese-/Schreiboperationen)
 Der Anwendung muss gegebenenfalls Code hinzugefügt werden, um eine
angemessene Abstraktion zu realisieren
 Datenbank
 Mächtig, leicht zu portieren
 Unterstützt mehrere Schreiber und Leser
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-110
ROOTS
Datei oder Datenbank?
 Wann sollte man eine Datei benutzen?
 Sind
Si d die
di Daten
D t groß
ß (bitmaps)?
(bit
)?
 Hat man viele “raw” Daten (core dump, event trace)?
 Muß man die Daten nur kurzzeitig
g speichern?
p
 Ist die Informationsdichte niedrig (Archivdateien, Logdateien)?
 Wann sollte man eine Datenbank wählen?
 Müssen die Daten in verschiedenen Detailstufen
f von vielen Nutzern
benutzbar sein?
 Müssen die Daten auf verschiedenen Plattformen zur Verfügung stehen
(Heterogene Systeme)?
 Benutzen viele verschiedene Anwendungen die Daten?
 Benötigt das Datenmanagement eine komplexe Infrastruktur?
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-111
ROOTS
Was muss bei Benutzung einer
Datenbank beachtet werden?
 Speicherplatz
 Die
Di Datenbank
D t b k benötigt
b öti t in
i etwa
t
di dreifache
die
d if h Größe
G öß der
d Daten
D t
 Antwortzeit
 Datenbanken sind I/O oder kommunikationsabhängig (verteilte
Datenbanken). Die Antwortzeit wird auch von der CPU Zeit, Locks und
Verzögerungen durch häufige Bildschirmausgaben beeinflußt.
 Lock Arten
 Pessimistisches locking: Lock wird vor dem Zugriff auf ein Objekt gesetzt
und erst wieder aufgehoben wenn der Zugriff beendet wurde.
 Optimistisches locking: Häufiger Lese- / Schreibzugriff (hohe Parallelität!)
Wenn die Aktivität beendet wurde, prüft die Datenbank ob Konflikte
bestehen; wenn ja werden alle Änderungen verworfen.
 Administration
 Große Datenbanken benötigen ausgebildete Support Mitarbeiter, um
Sicherheits Policies, Datenträgerplatz und Backups zu verwalten, die
Sicherheits-Policies,
Leistung zu überachen und Einstellungen anzupassen.
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-112
ROOTS
Fragen zum Datenmanagement
 Sollte die Datenbank verteilt sein?
 Sollte
S llt di
die D
Datenbank
t b k erweiterbar
it b sein?
i ?
 Wie oft wird auf die Datenbank zugegriffen?
 Was ist die erwartete Anfragefrequenz? Im schlimmsten Fall (worst
case)?
 Was ist die Größe einer typischen Anfrage und einer im worst case?
 Müssen die Daten archiviert werden?
 Zielt der Systementwurf darauf ab, den Ort der Datenbanken zu
verstecken (Ortstransparenz)?
 Wird ein explizites Interface zum Zugriff auf die Daten benötigt?
 Was ist das Anfrageformat?
 Sollte die Datenbank relational oder objektorientiert sein?
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-113
ROOTS
Abbildung eines Objektmodells auf eine
relationale Datenbank
 UML Objektmodelle können auf relationale Datenbanken abgebildet
werden:
 Etwas Verlust entsteht, weil alle UML-Konstrukte auf ein einziges
relationales Datenbankkonstrukt abgebildet werden – die Tabelle.
 UML Zuordnungen
 Jede Klasse wird auf eine Tabelle abgebildet
 Jedes Attribut einer Klasse wird auf eine Spalte abgebildet
 Eine Instanz einer Klasse repräsentiert eine Zeile in der Tabelle
 Eine n-zu-m Beziehung wird in eine eigene Tabelle abgebildet
 Eine 1-zu-n Beziehung wird als verborgener Fremdschlüssel implementiert
 Methoden werden nicht abgebildet
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-114
ROOTS
Von Objektmodellen zu Tabellen I
 N-zu-M Assoziation: Eigene Tabelle für die Assoziation
serves
City
cityName
City Table
*
Airport
*
Separate
Tabelle
airportCode
p
airportName
Serves Table
Airport Table
cityName
cityName
airportCode
airportCode
airportName
Houston
Houston
IAH
IAH
Intercontinental
Albany
Houston
HOU
HOU
Hobby
Munich
Albany
ALB
ALB
Albany County
Hamburg
Munich
MUC
MUC
Munich Airport
Hamburg
HAM
HAM
Hamburg Airport
Fremdschlüssel
Fremdschlüssel
Primärschlüssel
Vorlesung „Softwaretechnologie“
Seite 5-115
Primärschlüssel
© 2000-2009 Dr. G. Kniesel
ROOTS
Von Objektmodellen zu Tabellen II
 1-zu-n oder n-zu-1 Assoziationen: Verdeckte Fremdschlüssel
Transaction
*
Portfolio
transactionID
Foreign Key
Portfolio Table
Transaction Table
t
transactionID
ti ID
© 2000-2009 Dr. G. Kniesel
portfolioID
...
portfolioID
tf li ID
Vorlesung „Softwaretechnologie“
portfolioID
Seite 5-116
....
ROOTS
Von Objektmodellen zu Tabellen 
Werkzeuge
 Applikationsserver und ähnliche Werkzeuge erledigen die Abbildung
eines Objektmodells auf ein relationales Schema ((„object
object relational
mapping“) automatisch
 Gängige Systeme / Frameworks
 Java Data Objects (JDO) – Teil der Java Enterprise APis
 Hybernate
H b
t – Teil
T il d
des A
Applikationsservers
lik ti
JB
JBoss
 ... Google „object relational mapping“ ...
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-117
ROOTS
Vorlesung „Softwaretechnologie“
Wintersemester
te se este 2009
009
Globale Ressourcenverwaltung
ROOTS
Globale Ressourcenverwaltung
 Resourcenverwaltung befasst sich mit Zugriffskontrolle
 Sie
Si beschreibt
b
h ibt di
die Z
Zugriffsrechte
iff
ht fü
für verschiedene
hi d
Akt
Akteure
 Sie beschreibt, wie Objekte sich vor unberechtigtem Zugriff schützen
 Zugriffskontrollmatrix
 Zeilen = Akteure
 Spalten = Objekte
 Inhalt der Felder = zulässige Operationen
Objekttyp1
Actor A Op1.1, Op1.2
Op1 2
Op1.2
Actor B
--Actor C
Objekttyp 2 Objekttyp 3
---
Op3.1
Op2 2 Op2
Op2.2,
Op2.3
3
Op3 2
Op3.2
Op2.1
Op3.3
sp Actor
cto C da
darf Ope
Operation
at o Op
Op2.1 au
auf Objekten
Obje te des Typs
yps Obje
Objekttyp2
ttyp aus
ausführen.
ü e
Bsp:
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-119
ROOTS
Globale Ressourcenverwaltung:
Realisierung der Zugriffskontrollmatrix
 Spaltenweise Aufteilung = Jedes Objekt weiss wer, was damit tun darf
 Access
A
C t l Lists
Control
Li t (Beispiel:
(B i i l „Unix“)
U i “)
 Zeilenweise Aufteilung
g = Jeder Actor besitzt ein „„Ticket“ das besagt,
g,
welche Operationen er ausführen darf
 Capabilities (Beispiel: „Amoeba“)
 Synonyme: „Capability
Capability “ / „Ticket
Ticket“ / „Ausweis
Ausweis“// „Schlüssel
Schlüssel“
Objekttyp1
Actor A Op1.1, Op1.2
Op1 2
Op1.2
Actor B
--Actor C
Objekttyp 2 Objekttyp 3
---
Op3.1
Op2 2 Op2
Op2.2,
Op2.3
3
Op3 2
Op3.2
Op2.1
Op3.3
sp Actor
cto C da
darf Ope
Operation
at o Op
Op2.1 au
auf Objekten
Obje te des Typs
yps Obje
Objekttyp2
ttyp aus
ausführen.
ü e
Bsp:
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-120
ROOTS
Fragen zu globalen Ressourcen
 Benötigt das System eine Authentifizierung?
 Wenn ja, welches Authentifizierungsschema?
 Nutzername und Passwort?  Zugriffskontrollliste (ACL)
 Tickets?
Ti k ?  Capability-based
C
bili b
d
 Welche Benutzerschnittstelle für die Authentifizierung?
 Wann und wie wird ein Dienst dem Rest des Systems bekannt
gemacht?
 Zur
Z Laufzeit?
L f it?
 Beim Kompilieren?
 Über einen TCP-IP-Port?
 Durch einen Namen?
 Benötigt
g das System
y
einen netzweiten „„Name Server“?
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-121
ROOTS
Vorlesung „Softwaretechnologie“
Wintersemester
te se este 2009
009
ROOTS
Bestimmung des Kontrollparadigmas
(Programmsteuerung)
Bestimmung des Kontrollparadigmas
(Programmsteuerung)
 A. Wähle implizite Kontrolle (deklarative Sprachen)
 Regelbasierte Systeme
 Logische Programmierung
 B. Oder explizite Kontrolle (prozedurale Sprachen)
 Zentrale Kontrolle
 1. Prozedurgesteuerte Kontrolle
– Kontrolle befindet sich im Programmcode.
g
Beispiel:
p
Hauptprogramm
pp g
ruft
Prozeduren in Subsystemen auf.
– Einfach, leicht zu bauen
 2. Eventgesteuerte Kontrolle
– Kontrolle sitzt in einem Dispatcher, der Funktionen von Subsystemen
durch Rückfragen aufruft.
– Flexibel, gut für Benutzerschnittstellen
 Dezentrale Kontrolle
 Kontrolle befindet sich in verschiedenen unabhängigen Objekten (von manchen
Sprachen unterstützt).
 Geschwindigkeitsgewinn durch Parallelität versus mehr Kommunikation
Kommunikation.
 Beispiel: Nachrichten-basiertes System
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-123
ROOTS
Prozedurgesteuerte vs. eventgesteuerte
Kontrolle
Procedure-Driven Control
Event-Based Control, centralized
op1()
module1
Model has changed
module2
:Model
:Coordinator
op3()
Update
op2()
Update
:View
module3
E
Event
t based,
b
d decentralized
d
t li d
It‘s time to change
:Control
:Model
Model has changed
:View
:View
:View
:View
Update
:View
Zentrale vs. dezentrale Kontrolle
 Welches von beiden soll man benutzen?
 Zentrale
Z t l Kontrolle
K t ll
 Ein Kontrollobjekt oder Subsystem kontrolliert alles (“Spinne im Netz”)
 Änderungen in der Kontrollstruktur sehr einfach durchzuführen
 Möglicher Flaschenhals für die Performance
 Mögliche Vermischung verschiedener Kontrollaufgaben („tangling“)
 Dezentrale Kontrolle
 Kontrolle ist verteilt
 Streut die Verantwortung
 Passt gut in die objektorientierte Entwicklung
 Übersicht geht eventuell verloren
 Koordination schwierig
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-125
ROOTS
Vorlesung „Softwaretechnologie“
Wintersemester
te se este 2009
009
ROOTS
Grenzfälle
Grenzfälle
 Die meiste Zeit beschäftigt man sich beim Systementwurf mit dem
Verhalten im Betriebszustand.
Betriebszustand
 Abschliessend muss man sich aber auch mit Grenzfällen befassen.
 Initialisierung
 Beschreibt, wie das System aus einem nicht initialisierten Zustand in einen
Betriebszustand gebracht wird ("startup
( startup use cases
cases”)).
 Terminierung
 Beschreibt, welche Ressourcen vor der Beendigung aufgeräumt werden und
welche Systeme benachrichtigt werden (“Terminierungs
( Terminierungs-Use
Use Cases")
Cases ).
 Fehler
 Viele mögliche Gründe: Programmierfehler, externe Probleme
(St
(Stromversorgung).
)
 Guter Systementwurf sieht fatale Fehler voraus (“Fehler-Use Cases”).
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-127
ROOTS
Fragen zu den Grenzfällen
 Initialisierung
 Wie
Wi startet
t t t das
d System?
S t ?
 Auf welche Daten muss beim Hochfahren zugegriffen werden?
 Welche Dienste müssen registriert werden?
 Was tut die Benutzerschnittstelle beim Startvorgang?
 Wie präsentiert sie sich dem Nutzer?
 Terminierung
 Dürfen einzelne Subsystemen terminieren?
 Werden andere Subsysteme benachrichtigt, wenn ein einzelnes terminiert?
 Wie werden lokale Updates der Datenbank mitgeteilt?
 Fehler
 Wie verhält sich das System
System, wenn ein Knoten oder eine
Kommunikationsverbindung ausfällt? Gibt es dafür Backupverbindungen?
 Wie stellt sich das System nach einem Fehler wieder her? Unterscheidet
dieser Vorgang sich von
on der Initialisier
Initialisierung?
ng?
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-128
ROOTS
RückblickZielgerichteter Systementwurf
Aktivitäten
 Identifikation
Id tifik ti von N
Nebenläufigkeit
b lä fi k it
 Hardware/Software Zuordnung
 Management persistenter Daten
 Globale Ressourcenverwaltung
 Wahl des Programmsteuerung
g
g
 Grenzfälle
Nutzen
 Jede Aktivität überprüft die gewählte Architektur in Hinsicht auf eine
bestimmte Frage
Frage.
 Nach Beendigung dieser Aktivitäten können die Schnittstellen der
Subsysteme abschließend definiert werden.
 Start frei für den Objektentwurf der Subsysteme!
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Seite 5-129
ROOTS
RückblickSystementwurf (Gesamt)
Systementwurf
1 Entwurfsziele
1.
8. Grenz8
fälle
Definition
Abwägungen
Initialisierung
Fehler
Ende
2. System
Dekomposition
7. Programmsteuerung
Ebenen / Partitionen
Kohärenz / Kopplung
Monolithisch
Ereignisbasiert
Threads
Parallele Prozesse
3. Hardware / Software
Zuordnung
Kaufen vs. Selbermachen
Netzwerktopologie
Allokation
6. Globale
Ressourcenverwaltung
Zugriffskontrolle
g
Sicherheit
4. Pesistente
5. Nebenläufigkeit
Identifizierung von
Datenverwaltung
Dateien
Datenbanken
Datenstrukturen
© 2000-2009 Dr. G. Kniesel
Vorlesung „Softwaretechnologie“
Thread
Seite 5-130
ROOTS