Transcript Kein Folientitel

3. Objektorientierte Spezifikation
Zunächst: allgemeines zur objektorientierten Spezifikation (auch
objektorientierte Analyse (OOA) genannt)
Dann: Die Unified Modeling Language UML
20.07.2015
Modellierung WS 06/07
1
Objektorientierte Analyse
3.1 Objektorientierte Analyse
Objekt = „Gegenstand, mit dem etwas geschieht“
Folgerungen:
– Wann immer gehandelt wird, sind Objekte Behandelte und auch
Ausführende.
– Handlungen stellen das Verhalten von Objekten dar.
– Ziel von Handlungen sind Änderungen von Objekten
Jedes Objekt (in der Realität) vereint Zustand und Verhalten
20.07.2015
Modellierung WS 06/07
2
Objektorientierte Analyse
Sprachgebrauch
• Der Zustand eines Objektes ist gegeben durch die Wertebelegung
seiner Attribute.
• Das Verhalten eines Objektes wird definiert durch seine Methoden.
• Nachrichten reizen ein Objekt zum Handeln und Antworten (=
Anwenden von Methoden).
• Objekte werden dynamisch erzeugt und vernichtet.
20.07.2015
Modellierung WS 06/07
3
Objektorientierte Analyse
Beispiele
20.07.2015
Objekt
Attribute
Methoden
Mensch
Alter
Gewicht
...
Nenne-Alter
Nenne-Gewicht
Verzehre-Nahrung (...)
Laufe (...)
...
Personalausweis
Name
Nummer
Ausstellungsdatum
Ablaufdatum
...
Ausstellen (...)
Verlängern (...)
...
Modellierung WS 06/07
4
Objektorientierte Analyse
Beobachtungen aus Beispielen:
– Das Verhalten eines Objektes hängt von seinem Zustand ab.
– Der Zustand wird durch das Verhalten verändert.
Zustand und Verhalten sind eng verbunden.
Folgerungen
– Einkapselung = Zustand und Verhalten sind Bestandteile des Objekts.
– Information Hiding = Zustand und Verhalten sind im Objekt verborgen.
– Autonomie = ein Objekt entscheidet selbst über seine Reaktion auf
eine Nachricht.
20.07.2015
Modellierung WS 06/07
5
Objektorientierte Analyse
OOA - Statik und Dynamik
• OOA erfaßt statische und dynamische Aspekte
– statische Aspekte: alles um die Struktur von Klassen
• Klassen
• Attribute, Operationen
• Subsysteme
– dynamische Aspekte: alles rund um Objekte und ihre Werte
• Objekte
• Ereignisse
• Prozesse (verstanden als die Ausführung von Operationen)
20.07.2015
Modellierung WS 06/07
6
Objektorientierte Analyse
Ziel der Objektorientierung
Bereitstellung von geeigneten Konzepten für den Umgang mit
Objekten.
Zum Beispiel:
• Erzeugen gleichartiger Objekte
• Erzeugen einander ähnlicher Objekte
• Definition gleichartiger Kommunikationsbeziehungen zwischen
Objekten.
20.07.2015
Modellierung WS 06/07
7
Objektorientierte Analyse
Grundelemente der Objektorientierung: Klassenbildung
Definition einer Klasse (= Schablone)
•
Definition der Attribute
•
•
Definition der Methoden
bei Bedarf Erzeugung von Objekten als „zu füllende Kopien“
Vorteile:
•
•
Klassenbeschreibung ist unabhängig von der Existenz von Objekten
Definition und Nutzung sind voneinander getrennt.
Beispiel:
Der Blankovordruck eines Personalausweises wird nach einer Druckschablone erstellt
und anschließend nach Anweisung ausgefüllt.
20.07.2015
Modellierung WS 06/07
8
Objektorientierte Analyse
Grundelemente der Objektorientierung: Vererbung
• Ziel: Übernehmen einer Klassenbeschreibung beim Erzeugen einer
ähnlichen Klasse
• Konzept: Vererbung
= Übernahme der Klassendefinition einer Superklasse in die
Klassendefinition einer Subklasse
Beispiel für Vererbung:
Versicherung
Person
erbt von
erzeuge
erbt von
erzeuge
erzeuge
Versicherter
20.07.2015
Mitarbeiter
Modellierung WS 06/07
9
Objektorientierte Analyse
Grundelemente der Objektorientierung: Vererbung
• Konzept: Mehrfacherbung
= eine Subklasse besitzt mehrere Superklassen
Beispiel für Mehrfacherbung:
Versicherung
Person
erbt von
erzeuge
erbt von
erzeuge
erzeuge
Versicherter
Mitarbeiter
erbt von
erbt von
versicherter
Mitarbeiter
20.07.2015
erzeuge
Modellierung WS 06/07
10
Objektorientierte Analyse
Grundlemente der Objektorientierung: Beziehungen
zwischen Klassen
Gleichartige Kommunikationsbeziehungen
zwischen Objekten werden durch die Definition der Beziehungen zwischen Klassen
vorgegeben:
• Assoziation („hat-Kenntnis-von“)
• Aggregation („ist-Teil-von“)
Beispiel:
Versicherung
kennt
Vertrag
Person
besteht-aus
Paragraph
20.07.2015
erbt von
Versicherter
Modellierung WS 06/07
erbt von
Mitarbeiter
11
Objektorientierte Analyse
Grundelemente der Objektorientierung: Beziehung
zwischen Klassen
Beispiel für erzeugte Objekte:
Versicherung
kennt
Vertrag
Person
besteht-aus
Paragraph
20.07.2015
erbt von
Versicherter
Modellierung WS 06/07
erbt von
Mitarbeiter
12
Objektorientierte Analyse
Grundelemente der Objektorientierung: Polymorphie
Polymorphie:
statisch:
- in Abhängigkeit von den Parametertypen wird die
passende Operation gewählt.
- dies geht auch ohne Objektorientierung
Bsp.: +
dynamisch:
die aufzurufende Operation wird erst dann ermittelt (und an das
Operationssymbol gebunden), wenn sie aufgerufen wird (und nicht
etwa zur Compile-Zeit)
20.07.2015
Modellierung WS 06/07
13
Objektorientierte Analyse
FigurenBehaelter
figuren: set
anzeigen()
GeomFigur
x:integer
y:integer
sichtbar: Boolean
anzeigen()
entfernen()
setPosition(neuX, neuY)
Kreis
radius {radius>0}
setRadius(neuR)
anzeigen()
20.07.2015
anzeigen „smalltalk-beispiel“
figuren do [:f | f anzeigen.].
„do: iteriert über die Elemente f
der Menge figuren“
Rechteck
a {a>0}
b {b>0}
setA(neuA)
setB(neuB)
anzeigen()
Modellierung WS 06/07
14
Objektorientierte Analyse
Grundelemente der Objektorientierung: Objektidentität
Objektidentität
• Objektwertgleichheit  Objektgleichheit
• Es kann objektwertgleiche Objekte geben
• Unterscheidung erfolgt über interne Kennungen (Surrogate)
20.07.2015
Modellierung WS 06/07
15
Objektorientierte Analyse
Zusammenfassung
Objekt-Orientierung
• Ein objekt-orientiertes System besteht aus einer Menge von
Objekten, die miteinander Nachrichten austauschen.
• Bei der Gestaltung erleichtern Klassen, (Mehrfach-)Vererbung,
Aggregation und Assoziation die Definition, die Konfiguration und
den Einsatz von Objekten.
• Die Struktur der Klassen ist statisch.
• Die Menge und Struktur der Objekte ändert sich dynamisch.
20.07.2015
Modellierung WS 06/07
16
Objektorientierte Analyse
Grundphilosophie objekt-orientierter
Software-Entwicklung
•
•
•
•
„reale“ Handlungsabläufe werden ins „Software-Modell“ übertragen
Realität wird als objektorientiertes System aufgefaßt
„reale“ Objekte werden durch passende „Modell-Objekte“ ersetzt
„Modell-Objekte“ übernehmen die „Modell-Handlung“
Objekte bestimmen und geeignetes Modell schaffen!
20.07.2015
Modellierung WS 06/07
17
Objektorientierte Analyse
Entwicklungsabschnitte
• OO-Analyse:
Bestimmen von Objekten und Klassen aus
der Realität des Anwendungsbereichs
• OO-Design:
Ergänzen der Strukturen
aufgrund technischer Erfordernisse
• OO-Programmierung:
Umsetzen in Programmiersprache
und Anpassen an Sprachspezifika
20.07.2015
Modellierung WS 06/07
18
Objektorientierte Analyse
OO-Analyse besteht aus
der Erforschung des Anwendungsbereichs, d.h.
•
•
•
•
•
Objekte entdecken
Klassen ableiten
Klassen strukturieren
Aufgaben zuordnen
Zusammenarbeit festlegen
20.07.2015
Modellierung WS 06/07
19
Objektorientierte Analyse
Erforschung: Vorgehen
Entdecken von Objekten des Anwendungsbereichs:
•
Ableiten aus textueller Beschreibung
(Hauptwörter selektieren und normieren)
•
•
•
Ableiten aus eigenem Wissen
Ableiten aus Expertenbefragung
Ableiten aus „Use Case Model“
(Analyse der anwendungstypischen Handlungsabläufe)
Kandidaten für Objekte sind
•
greifbare Dinge
•
•
Konzepte
Ereignisse
20.07.2015
Modellierung WS 06/07
20
Objektorientierte Analyse
Erforschung: Weiteres Vorgehen
Ableiten von Klassen aus Objekten
=„natürliche“ Gemeinsamkeiten von Objekten erkennen und diese in Klassen
zusammenfassen
Strukturieren der Klassen
•
existierende Vererbungsstrukturen bestimmen
(mögliche Subklassen suchen)
(mögliche Superklassen suchen)
•
Superklassen ergänzen
(Gemeinsamkeiten in Superklassen extrahieren)
•
Abhängigkeiten bestimmen
(Aggregationen und Assoziationen charakterisieren)
20.07.2015
Modellierung WS 06/07
21
Objektorientierte Analyse
Erforschung: Beispiel Vererbung
Ohne Beziehungen
Mit Vererbung
Gerät
Pumpe
Membranpumpe
Zentrifugalpumpe
Kühler
Pumpe
Zentrifugalpumpe
Kühler
Membranpumpe
Notation: OMT
20.07.2015
Modellierung WS 06/07
22
Objektorientierte Analyse
Erforschung: Beispiel Aggregation
Ohne Beziehungen
Sekretariat
Firma
Bereich
Abteilung
Mit Aggregation
Firma
Bereich
Leitung
Abteilung
Sekretariat
Leitung
Notation: OMT
20.07.2015
Modellierung WS 06/07
23
Objektorientierte Analyse
Erforschung: Weiteres Vorgehen
Zuordnen von Aufgaben zu Klassen
• Klassen beschreiben
• Attribute bestimmen
(Zustände von Objekten abgrenzen)
(Attribute Superklassen zuordnen)
(Relevanz von Attributen für alle Objekte)
• Methoden bestimmen
(Verhalten zu Attributen)
(Leistungen des Systems verteilen)
(Relevanz von Methoden für alle Objekte)
20.07.2015
Modellierung WS 06/07
24
Objektorientierte Analyse
Erforschung: Weiteres Vorgehen
Zusammenarbeit festlegen
= Nachrichtenaustausch zwischen Objekten verschiedener
Klassen charakterisieren
Klassen sind Vertragspartner der Form „Produzent“ und „Konsument“
wie im Wirtschaftsleben:
• Nachfrage nach Verhalten aufstellen
• Angebote an Verhalten vornehmen
• Angebote und Nachfragen einander anpassen
20.07.2015
Modellierung WS 06/07
25
Objektorientierte Analyse
OO-Analyse
Das Ergebnis der vorgestellten OO-Analyse ist eine
statische Struktur von Klassen (= Klassenmodell).
Es fehlt eine Beschreibung der Dynamik, z.B. Angaben über
•
das Erzeugen und Vernichten von Objekten,
•
•
die zu einem Zeitpunkt konkret agierende Menge von Objekten,
die Wirkung einer Methodenanwendung auf den internen Zustand
eines Objektes
den Ablauf der Kommunikation zwischen Objekten
•
20.07.2015
Modellierung WS 06/07
26
Objektorientierte Analyse
OO-Analyse
Zur Beschreibung der Dynamik von objektorientierten Systemen
werden „herkömmliche“ Methoden eingesetzt. Zum Beispiel:
•
Zustandsdiagramme
•
•
•
Sequenzdiagramme
Anwendungsfalldiagramme
formale, semiformale und informale Texte
Eine statische Struktur ohne Dynamikmodellierung
ist Stückwerk !
20.07.2015
Modellierung WS 06/07
27
Objektorientierte Analyse
Vorteile von objektorientierten Methoden gegenüber
funktionsorientierten (strukturierten) Methoden
•
•
•
•
•
•
•
•
20.07.2015
Ganzheitliche Betrachtung
unterschiedliche Abstraktionsebenen bei Anwendung des gleichen
Paradigmas
evolutionäre Entwicklung ist möglich
einfacher Zugang zu Anwendungsgebiet
bessere Kommunikationsbasis als bei separaten ER-Modellen und
Funktionsbäumen (oder ähnlicher Darstellung)
kein Paradigmenwechsel in der Entwicklung
bessere Durchschaubarkeit durch Übereinstimmung der Strukturen mit der
Realität
einfache Möglichkeit der Wiederverwendung
Modellierung WS 06/07
28
Objektorientierte Analyse
Risiken und Gefahren von objektorientierten Methoden
• wenig Erfahrung
• Scaling-Up-Problem noch nicht vollständig bekannt / gelöst
– Konfigurations-Management
– integriertes Qualitäts-Management
• Überschätzung von Einzelaspekten, z.B. Vererbung, und deren
exzessive Verwendung
• Gefahr der Überspezifikation (der Zweck des Verständnisses gerät
außer Sicht)
• unausgereifte Werkzeuge
20.07.2015
Modellierung WS 06/07
29
Objektorientierte Analyse
Rückblick auf Historie
Ursprünge der Vererbung
Grundlagen für Einkapselung
Grundlage für Notationen
Dynamikmodellierung
Programmiersprache SIMULA
Information Hiding
Abstrakte Datentypen
Entity-Relationship-Modellierung
(traditionelle Methoden)
1967
1972
1975
1976
Objektorientierung kombiniert etablierte Methoden!
20.07.2015
Modellierung WS 06/07
30
Objektorientierte Analyse
Objektorientierte Modellierungssprachen
ermöglichen Vorteile, sie garantieren sie
nicht.
Deshalb: objektorientierte Modellierung muß
durch geeignete Methoden und Richtlinien
ergänzt werden.
Versuch: UML und passende Methode
20.07.2015
Modellierung WS 06/07
31
UML: Einführung
3.2 Die Unified Modeling Language (UML)
Spezifikationssprache: UML
Syntax
Methodik
Semantik
20.07.2015
Modellierung WS 06/07
32
UML: Einführung
OOD, 1991
S.Shlaer, S. Mellor
OOA und OOD, 1991
P. Coad, E. Yourdon,
1991
G. Booch
OMT, 1991
J. Rumbaugh
CRC-Karten
(Class-ResponsibilitiesCollaborations)
R. -Brock 1990
OOSE, 1992
I. Jacobson
Unified Method
G. Booch / J. Rumbaugh,
1995
State Charts
(erw. / hierarchische
Zustandsübergangsdiagramme)
D. Harel
Unified Modeling Language (UML)
G. Booch / J. Rumbaugh / L. Jacobson
1996
Integrationen auf dem Weg zur UML
Integrationen ohne Niederschlag in der UML
20.07.2015
Modellierung WS 06/07
33
UML: Einführung
Beschreibungsmittel in UML
•
Anwendungsfalldiagramme (Use Case
Diagram)
–
–
–
•
–
•
•
Klassen
Beziehungen zwischen Klassen
•
•
•
•
•
–
Komponenten
Beziehungen zwischen Komponenten
Einsatzdiagramme
–
–
–
Komponenten
Beziehungen
Knoten
Kollaborationsdiagramme
•
•
20.07.2015
•
Zustände
Zustandsübergänge
Ereignisse
Aktivitäten
Objektzustände
Zustände
Beziehungen
Ereignisse
Implementierungsdiagramme
Komponentendiagramm
–
–
Aktivitätsdiagramme
Objekte
Beziehungen inklusive Nachrichtenaustausch
(zeitlich geordnet)
Zustandsdiagramme
•
•
•
Verhaltensdiagramme
–
Sequenzdiagramme (Weg-Zeit-Diagramme)
•
•
Akteure
Anwendungsfälle
Beziehungen
Klassendiagramme
(Klassenstrukturdiagramm)
–
–
•
–
Objekte
Beziehungen inklusive Nachrichtenaustausch
(räumlich geordnet)
Modellierung WS 06/07
34
UML: Einführung
OOA
1) Klassendiagramme (inkl. CRC Cards)
falls das
Anwendungsgebiet
workflow-geprägt
ist
2) Anwendungsfalldiagramm
3a) Sequenzdiagramme
3b) Kollaborationsdiagramme
OOD
6) Aktivitätendiagramm
20.07.2015
4) Zustandsübergangsdiagramm
Modellierung WS 06/07
5) Komponentendiagramme
35
UML: Klassendiagramme
UML-Klassendiagramme
Klassifikation
->
Bildung von Klassen
Generalisierung/ ->
Vererbung
Spezialisierung
Bildung von Ober- und Unterklassen
Assoziation
->
Beziehung zwischen Objekten einer oder mehrerer
Klassen
Aggregation
->
Spezialfall der Assoziation, Objekte sind Bestandteile eines anderen Objektes
20.07.2015
Modellierung WS 06/07
36
UML: Klassendiagramme
Klassifikation
Assoziation
Name-von-B-aus
1
0..*
B
A
Name-von-A-aus
Ein A-Objekt steht zu beliebig vielen B-Objekten
in Verbindung.
Die Beziehung von A aus gesehen heißt „Namevon-A-aus“.
Ein B-Objekt steht zu einem A-Objekt in
Verbindung.
20.07.2015
Modellierung WS 06/07
37
UML: Klassendiagramme
Generalisierung
Aggregation
B
A
1
1..*
Ein A-Objekt steht zu einem oder mehreren BObjekten in Verbindung.
Ein B-Objekt steht zu einem A-Objekt in
Verbindung.
20.07.2015
Modellierung WS 06/07
38
UML: Klassendiagramme
Unterscheidungen verschiedener Aggregationen
Normale Aggregation
besteht aus >
Unternehmen
1..*
1
besteht aus >
Abteilung
1
Mitarbeiter
1..*
Komposition (Einzelteile sind vom Aggregat existenzabhängig d.h. sie können
ohne das Aggregat nicht existieren).
hat >
Rechnung
1
Rechnungsposition
1..*
Hinweis: Bei Komposition auf der Aggregatseite 1.
20.07.2015
Modellierung WS 06/07
39
UML: Klassendiagramme
Richtungen von Assoziationen und Aggregationen
... geben an, welche Objekte von der Beziehung wissen
A
hat >
B
Ein Objekt der Klasse A kennt das komponierte Objekt der Klasse B,
aber nicht umgekehrt, es kann Nachrichten an Objekte der Klasse B senden,
aber nicht umgekehrt!
20.07.2015
Modellierung WS 06/07
40
UML: Klassendiagramme
Kommunikation zwischen Objekten
... erfolgt über den Austausch von Nachrichten
A
B
set() ->
Ein Objekt der Klasse A kann die Nachricht set() an ein Objekt der Klasse B senden.
.
20.07.2015
Modellierung WS 06/07
41
UML: Klassendiagramme
Grundelemente der Objektorientierung: Klassen, ihre
Interna und Objekte
Klassenname
Attributname
Attribut-Typ
Operationen
Zusicherung
Kreis
radius: integer {radius > 0}
mittelpunkt: Point = (10,10)
anzeigen()
entfernen()
setPosition(pos: Point)
setRadius(neuerRadius: integer)
Initialwert
Parameter
(Name: Typ = Initialwert)
Klasse
Exemplarname
einKreis: Kreis
Attributnamen
radius=25
mittelpunkt=(10,10)
Klassenname
Attributwerte
Objekt
20.07.2015
Modellierung WS 06/07
42
UML: Klassendiagramme
Grundelemente der Objektorientierung: Vererbung
Attribute und Operationen in Vererbungsbeziehungen
GeomFigur
x:integer
y:integer
sichtbar: Boolean
anzeigen()
entfernen()
setPosition(neuX, neuY)
Kreis
radius {radius>0}
setRadius(neuR)
Rechteck
a {a>0}
b {b>0}
setA(neuA)
setB(neuB)
Dreieck
a {c-b < a < b+c}
b {a-c < b < a+c}
c {a-b < c < a+b}
setA(neuA)
setB(neuB)
setC(neuC)
Attribute und Operationen werden in den Klassen angesiedelt, in die sie der
Anschauung nach gehören. Redundanz-, Performanz- und sonstige Entwurfs- und
Implementierungsaspekte interessieren während der OOA NICHT !
20.07.2015
Modellierung WS 06/07
43
UML: Klassendiagramme
Vererbung gemäß Anschauung
Rechteck
a {a>0}
b {b>0}
setA(neuA)
setB(neuB)
anzeigen()
entfernen()
Quadrat
{a=b}
20.07.2015
Modellierung WS 06/07
Liefert für Quadrate nicht
die minimale
Implementierung, denn es
gibt zwei Kantenlängen.
44
UML: Klassendiagramme
Alternative Vererbung
Quadrat
a {a>0}
setA(neuA)
anzeigen()
entfernen()
Entspricht nicht der Anschauung,
ist aber redundanzfrei !
Rechteck
b{b>0}
setB(neuB)
20.07.2015
Modellierung WS 06/07
45
UML: Klassendiagramme
Multiple Klassifikation
• Bei multipler Klassifikation kann ein Objekt durch mehrere Klassen
beschrieben werden, die nicht über Vererbungsbeziehungen
miteinander verbunden sind.
• Zur Angabe der gültigen Kombinationen von Klassen werden
Diskriminatoren verwendet.
• Alle Klassen mit dem gleichen Diskriminator sind disjunkt.
• Vollständige Diskriminatoren bedeuten, daß die Vereinigung aller
Objekte der „Unterklassen“ die Menge der Objekte der „Oberklasse“
ergibt. Im Sinne des Diskriminators ist die „Oberklasse“ dann eine
abstrakte Klasse.
• Dynamische Diskriminatoren erlauben, daß ein Objekt zur Laufzeit
den Typ wechselt (schwierige Implementierung!)
20.07.2015
Modellierung WS 06/07
46
UML: Klassendiagramme
Multiple Klassifikation
Diskriminator
Surgeon
Female
Doctor
sex
(vollständig)
role
(dynamisch)
Family
Doctor
Person
Nurse
Male
patient
Physiotherapist
Patient
Legale Kombination von Klassen für ein Objekt:
Illegale Kombinationen von Klassen für ein Objekt:
20.07.2015
Female, Patient, Nurse
Male, Physiotherapist
Female, Patient
Patient, Doctor
Male, Doctor, Nurse
Modellierung WS 06/07
47
UML: Klassendiagramme
Abstrakte Klassen
... sind Klassen, von denen keine Objekte erzeugt werden können.
Die Klasse „GeomFigur“ ist eine abstrakte Klasse, denn es werden
konkrete Kreise, Dreiecke, Rechtecke, aber keine geometrischen
Figur-Objekte erzeugt.
20.07.2015
Modellierung WS 06/07
48
UML: Klassendiagramme
Parametrisierte Klassen
... sind Klassen, die einen Typ als Parameter haben.
Typischerweise: Stacks, Queues, Listen, Mengen
Parametrisierte Klasse
Parametrisierte Klasse mit gebundenem Parameter
T
Set
20.07.2015
Set<Integer>
Modellierung WS 06/07
49
UML: Klassendiagramme
Graphische Darstellung von parametrisierbaren und
abstrakten Klassen
parameterisierbare Klassen
Wartezimmer
i: Element
„bind“ <Patient>
Warteschlange
anfuegen()
entnehmen()
„bind“ <PKW>
Stau
abstrakte Klassen
20.07.2015
Klasse
{abstrakt}
Klasse
attribute
attribute
operationen()
operationen()
Vereinfachte Darstellung
Klasse
{abstrakt}
Modellierung WS 06/07
Klasse
50
UML: Klassendiagramme
Attribute, Klassenattribute, abgeleitete Attribute
Attribute werden beschrieben durch
–
–
–
–
Name
Datentyp oder Klasse
Initialwert
Zusicherungen / constraints (Syntax: {constraint}, keine weiteren Angaben!)
Klassenattribute gehören nicht zu einem Objekt, sondern zur Menge aller
Objekte einer Klasse (vereinfacht: zur Klasse).
Beispiel: Zähler, der angibt, wieviel Objekte eines Typs erzeugt werden.
Abgeleitete Attribute sind Attribute, deren Werte aus den Werten anderer Attribute
abgeleitet werden können. Die namen abgeleiteter Attribute beginnen mit einem
Slash /
Beispiel: Das Attribut /Alter einer Person kann aus ihrem Geburtsdatum abgeleitet
werden.
20.07.2015
Modellierung WS 06/07
51
UML: Klassendiagramme
•
•
•
•
Sichtbarkeit von Attributen
public: für alle sichtbar und benutzbar. UML-Notation +
protected: für die Klasse selbst, für die Unterklassen und für explizit ausgezeichnete Klassen.
UML-Notation #
private: für die Klasse selbst und für explizit ausgezeichnete Klassen. UML-Notation Syntax der Operationsdefinition:
visibility name (parameter-list) : return-type-expression {property-string}
visibility: + (public), # (protected), - (private)
name: string
parameter-list: beinhaltet (optional) Argumente, Syntax wie bei Attributen
return-type-expression: optional Spezifikation des Rückgabewertes (abhängig von der
Implementierungssprache)
property-string: Eigenschaften der Operation
Hinweis: In der OOA sollten die Operationen nicht im Sinne einer Schnittstellendefinition
verwendet werden. Stattdessen sollten sie die prinzipiellen Verantwortlichkeiten und
Aufgaben einer Klasse definieren. -> zum Beispiel mit CRC Karten!
20.07.2015
Modellierung WS 06/07
52
UML: Klassendiagramme
CRC Karten (Class-Responsibility-Collaboration)
• Mit CRC-Karten werden die abstrakten Aufgaben einer Klasse
definiert.
Class Name
Responsibility
Bestellung
Prüfe, ob Artikel
auf Lager
Lagerbestand
Bestimme Preis
Lagerbestand
Prüfe auf gültige
Zahlung
Kunde
Collaboration
Ausliefern
20.07.2015
Modellierung WS 06/07
53
UML: Klassendiagramme
Rollen in Assoziationen
•
•
•
20.07.2015
Jede Assoziation hat zwei Rollen. Jede entspricht einer Richtung.
Rollen können explizit benannt werden.
Der Name einer Rolle von Klasse A nach Klasse B steht am B-Ende der Assoziation (vgl.
Bestellung - interne Bestellung).
Modellierung WS 06/07
54
UML: Klassendiagramme
Multiplicity: mandatory
Bestellung
dateReceived
isPrepaid
*
number: String
price: Money
dispatch()
Constraint
close()
Kunde
1 name
adress
creditRating(): String
Association
Generalization
Class
1
{if Bestellung.Kunde.creditRating is
„poor“, then Bestellung.isPrepaid
must be true}
Rollenname
Firmenkunde
contactName
creditRating
creditLimit
remind()
billForMonth(Integer)
Attributes
Artikel
*
Multiplicity: Many-valued
Interne Bestellung
quantity: Integer
price: Money
isSatisfied: Boolean
20.07.2015
Operations
*
1
*
0..1
Arbeitnehmer
sales rep
Persönlicher
Kunde
creditcard#
{creditRating() ==
„poor“}
Multiplicity: optional
Produkt
Modellierung WS 06/07
55
UML: Klassendiagramme
Klassendiagramme: weiterführende Konzepte
Assoziationsklassen werden benutzt, um Assoziationen mit Attributen und Operationen
zu verknüpfen.
*
Arbeitgeber
Person
*
Angestellter
Firma
Beschäftigung
Periode:Zeitraum
20.07.2015
Modellierung WS 06/07
56
UML: Klassendiagramme
Klassendiagramme: weiterführende Konzepte
Assoziationsklassen können vermieden werden. Ihre Bedeutung ergibt sich gemäß dem
folgenden Beispiel.
Abgeleitete
Assoziation
/Arbeitgeber
*
Person
*
Beschäftigung
1
*
Periode:Zeitraum
*
1
Firma
Beförderung einer Assoziationsklasse zu einer vollen Klasse
Bei der Verwendung einer Assoziationsklasse gab es zwischen einer Person und einer
Firma nur ein Beschäftigungsverhältnis, diese Restriktion ist durch die Verwendung
der normalen Klasse aufgehoben.
20.07.2015
Modellierung WS 06/07
57
UML: Klassendiagramme
Klassendiagramme: weiterführende Konzepte
Frage: Ist die Restriktion sinnvoll?
*
Arbeitgeber
Person
*
Firma
Beschäftigung
Periode:Zeitraum
Annahme: eine Person verläßt eine Firma
und kehrt später wieder zurück. Also: zwischen
einer Person und einer Firma mehrere Objekte
der Klasse Beschäftigung.
20.07.2015
Modellierung WS 06/07
58
UML: Klassendiagramme
Klassendiagramme: weiterführende Konzepte
Obwohl es also sinnvolle Kombinationen von mehreren Assoziationsobjekten zwischen
zwei assoziierten Objekten gibt, läßt die UML-Semantikdefinition von
Assoziationsklassen dies nicht zu.
Dies bedeutet jedoch keine prinzipielle Einschränkung der Ausdruckskraft, da die
Beförderung der Assoziationsklasse zu einer vollen Klasse einen Ausweg bietet.
20.07.2015
Modellierung WS 06/07
59
UML: Klassendiagramme
Klassendiagramme: weiterführende Konzepte
Qualifizierte Assoziationen erlauben es, Aussagen über die Assoziationen von Mengen
von Objekten zu anderen Objekten zu machen. Das Kriterium, über das die Menge
der Objekte bestimmt wird, nennt man Qualifikation.
Bestellungseingang
Bestellung
0..1
Produkt
Menge: Nummer
Eingangsnummer
Pro Produkt gibt es für eine Menge von Bestellungen einen Bestellungseingang.
Produkt bündelt eine Menge von Bestellungen. Es qualifiziert alle Bestellungen, die
zu einem Bestellungseingang gehören!
20.07.2015
Modellierung WS 06/07
60
UML: Anwendungsfalldiagramme
UML - Anwendungsfalldiagramme
•
•
•
•
Ein Anwendungsfalldiagram zeigt die Beziehungen zwischen Akteuren und
Anwendungsfällen, d.h. es stellt das externe Systemverhalten aus der Sicht
des Anwenders dar.
Anwendungsfälle werden auch als Szenarien oder Geschäftsprozesse
bezeichnet.
Anwendungsfälle beschreiben für den Anwender sichtbare Funktionen.
Anwendungsfälle beschreiben die Erreichung eines für den Anwender
zusammenhängenden Ziels.
20.07.2015
Modellierung WS 06/07
61
UML: Anwendungsfalldiagramme
UML - Anwendungsfalldiagramme
•
Wichtig ist die Fokussierung auf Ziele des Anwenders und auf Interna des
Systems, die mit diesen Zielen zusammenhängen. Beispiel:
– Ziel: Was muß der Benutzer tun, um eine individuelle Dokumentenvorlage zu
erstellen?
– Interna: definiere eine Vorlage, kopiere sie in das Verzeichnis für Vorlagen,
wende diese Vorlage an.
•
•
Zielfokussierte Anwendungsfälle eignen sich gut für die Abstimmung mit
dem zukünftigen Anwender.
Auf das interne Verhalten ausgerichtete Anwendungsfälle eignen sich gut
für Planungszwecke.
20.07.2015
Modellierung WS 06/07
62
UML: Anwendungsfalldiagramme
Notation für Anwendungsfälle
Anwendungsfall
Akteur
uses/
extends*
ein Akteur stellt eine Rolle dar, er gibt nicht an,
wieviele Ausprägungen es gibt
Beziehung zwischen Anwendungsfall
und Akteur, der Akteur führt den
Anwendungsfall aus.
uses- oder extends-Beziehung
zwischen zwei Anwendungsfällen
AF1 uses AF2
*UML 2.0: include/extend
20.07.2015
Modellierung WS 06/07
63
UML: Anwendungsfalldiagramme
UML - Anwendungsfalldiagramme
Notation für Anwendungsfälle
Diagrammname
Akteur 2
Anwendungsfall 1
Anwendungsfall 2
Akteur 1
Anwendungsfall 3
20.07.2015
Modellierung WS 06/07
64
UML: Anwendungsfalldiagramme
Definiere
Provision
Identifiziere
Versicherungsnehmer
„uses“
Maklerkoordinator
Berate
Versicherungsnehmer
Makler
Ermittle
Partner
Mache Angebot
„extends“
Mache
CompositAngebot
Versicherungsnehmer
Angestellter
Außendienstmitarbeiter
20.07.2015
Modellierung WS 06/07
65
UML: Anwendungsfalldiagramme
Zeitschriftenumlauf
1
Mitverwend.
Anwendungsf.
„uses“
Anwendungsfall
Zeitschrift
registrieren
2
Mark. Art.
registrieren
3
„extends“
Erweiterung oder.
Variante
Umlaufzettel
erstellen
Bibliothek
4
Zeitschrift
archivieren
20.07.2015
Modellierung WS 06/07
66
UML: Anwendungsfalldiagramme
Strukturierte, textuelle Beschreibung eines
Anwendungsfalls
Af.-Nr.
Name des Anwendungsfalles
Vorbedingungen: ...
Nachbedingungen: ...
Nicht-funktionale Anforderungen: ...
Beschreibung: ..
Variationen: ...
Regeln: ...
Services: ...
Ansprechpartner: ...
Anmerkungen / offene Fragen: ...
Dialogbeispiele oder - muster: ...
Diagramme: ...
20.07.2015
Modellierung WS 06/07
67
UML: Anwendungsfalldiagramme
20.07.2015
Modellierung WS 06/07
68
UML: Anwendungsfalldiagramme
20.07.2015
Modellierung WS 06/07
69
UML: Sequenzdiagramme
UML - Sequenzdiagramme (Weg-Zeit-Diagramme) und
Kollaborationsdiagramme
• individuelle Objekte (in Sequenzdiagrammen und
Kollaborationsdiagrammen)
• Beziehungen zwischen Objekten inklusive
Nachrichtenaustausch (zeitlich geordnet) (in
Sequenzdiagrammen)
• Beziehungen zwischen Objekten inklusive
Nachrichtenaustausch (räumlich geordnet) (in
Kollaborationsdiagrammen)
20.07.2015
Modellierung WS 06/07
70
UML: Sequenzdiagramme
UML - Sequenzdiagramme (Weg-Zeit-Diagramme) und
Kollaborationsdiagramme
Sequenzdiagramme und Kollaborationsdiagramme werden zusammenfassend
als Interaktionsdiagramme bezeichnet.
Beide Arten von Diagrammen werden benutzt, um das Verhalten innerhalb
eines Anwendungsfalls detailliert zu beschreiben. Sie liefern keine formale
Beschreibung!
Sie beschreiben, wie Gruppen von Objekten miteinander interagieren.
Es werden Aussagen über die Anzahl der involvierten Objekte und über den
Nachrichtenaustausch zwischen den Objekten gemacht.
20.07.2015
Modellierung WS 06/07
71
UML: Sequenzdiagramme
UML - Sequenzdiagramme (Weg-Zeit-Diagramme)
•
•
Pro Objekt: eine vertikale Lebenslinie (wie lange existiert ein Objekt).
Nachrichten werden durch horizontale Pfeile zwischen den Lebenslinien der
involvierten Objekte angezeigt (optional ergänzt um Parameter und
zusätzliche Restriktionen). Zu den Restruktionen gehören:
– Vorbedingungen für das Versenden der Nachricht
– Iterationsangaben (wenn mehrere Objekte mit Nachrichten versorgt werden)
•
•
20.07.2015
Ein Objekt kann sich selbst eine Nachricht schicken (Selbstdelegation).
Dies wird graphisch dargestellt durch einen Pfeil, der als Quelle und Ziel die
gleiche Lebenslinie hat.
Neben Nachrichten gibt es sogenannte returns. Ein return gibt an, ob und
wann die Kontrolle an den Nachrichtenversender zurückkehrt (Pfeil mit
offener Spitze).
Modellierung WS 06/07
72
UML: Sequenzdiagramme
UML - Sequenzdiagramme (Weg-Zeit-Diagramme)
Ein BestellungsEine Bestellungr
eingabefenster
Eine interne
Bestellung
Ein Artikel
prepare()
* prepare ()
Object
check()
Message
Iteration
Condition
[check=„true“]
remove()
needsToReorder()
Self-Delegation
new
Return
Ein neu zu
bestellener
Artikel
Zeit
[check = „true“]
new
Ein Lieferartikel
Weg
Creation
20.07.2015
Modellierung WS 06/07
73
UML: Sequenzdiagramme
UML - Sequenzdiagramme
Parallele Prozesse und Aktivierungen
•
•
•
•
Mit Hilfe von Aktivierungen kann ausgedrückt werden, wann die
Operationen eines Objektes ausgeführt werden (wann also Prozesse zu
diesen Methoden existieren)
Aktivierungen werden durch Rechtecke auf den Lebenslinien der Objekte
angegeben. Ihre Höhe deutet die Lebenszeit der jeweiligen Prozesse an.
Selbstdelegation führt zu verschachtelten Aktivierungen.
Asynchrone Operationsaufrufe werden durch Pfeile mit halber Spitze
dargestellt. Bei einem asynchronen Aufruf wartet der Aufrufer nicht auf ein
Ergebnis. Typischerweise eingesetzt für:
–
–
–
–
•
20.07.2015
Erzeugen eines unabhängigen Kontrollbereichs.
Erzeugen eines neuen Objektes.
Kommunikation mit einem bereits existierenden Kontrollbereich.
Pro Objekt: eine vertikale Lebenslinie (wie lange existiert ein Objekt).
Das Löschen eines Objektes wird durch ein X am Ende seiner Lebenslinie
dargestellt.
Modellierung WS 06/07
74
UML: Sequenzdiagramme
Beispiel Transaktionsbehandlung - Regelfall
Asynchrone Nachricht
eine Transaktion
neu
Aktivierung
ein Transaktionskoordinator
ein erster Transaktionsprüfer
neu
ein zweiter Transaktionsprüfer
neu
Andere
Verarbeitung
unterdrückt
ok
gültig
alle
beendet?
ok
alle
beendet?
Objekt löscht
sich
Selbstdelegation
20.07.2015
Modellierung WS 06/07
75
UML: Sequenzdiagramme
Beispiel Transaktionsbehandlung - Fehlerfall
Wenn eine Transaktion
erzeugt wird...
neu
...dann erzeugt sie ein Objekt
Transaktionskoordinator, der
die Prüfungen überwacht.
eine Transaktion
ein Transaktionskoordinator
neu
ein erster Transaktionsprüfer
neu
Der Koordinator erzeugt eine
Reihe von Prüfern, einen pro
Prüfung. Diese Objekte
arbeiten als getrennte
Prozesse.
Wenn eine Prüfung nicht
erfolgreich ist, dann vernichtet der Koordinator alle
noch laufenden Prüfer.
ein zweiter Transaktionsprüfer
neu
Versagen
ungültig
...und teilt mit, daß die
Transaktion ungültig ist.
Löschprüfer
löschen
ein anderes
Objekt löschen
20.07.2015
Modellierung WS 06/07
76
UML: Kollaborationsdiagramme
UML - Kollaborationsdiagramme
•
•
•
•
•
20.07.2015
Kollaborationsdigramme drücken den gleichen Sachverhalt aus wie
Sequenzdiagramme.
Die Reihenfolge der Nachrichten ergibt sich aus der Numerierung der
Nachrichten.
Die Anordnung der Objekte gibt die Möglichkeit, Zusammenhänge zwischen
Objekten (zum Beispiel die Existenz von Beziehungen oder ihren
räumlichen / örtlichen Zusammenhang) zu veranschaulichen.
Namensschema für Objekte: Objektname: Klassenname
In einem Namen darf entweder der Objektname oder der Doppelpunkt und
der Klassenname ausgelassen werden.
Modellierung WS 06/07
77
UML: Kollaborationsdiagramme
: Bestellungseingabefenster
1: vorbereiten()
Objekt
Reihenfolge
Nachricht
Selbstdelegation
: Bestellung
2*: vorbereiten()
3: prüfen()
4: [prüfen==true] entfernen
Macallan:
Bestellungseingang
7: [prüfen==true] neu
Macallan Lager:
Lieferartikel
6: neu
: Lieferartikel
20.07.2015
5: Bedürfnis an
Besteller
: Lieferartikel
Modellierung WS 06/07
78
UML: Kollaborationsdiagramme
Kollaborationsdiagramm mit hierarchischer
Numerierung (UML)
: Bestellungseingabefenster
Reihenfolge
1: vorbereiten()
: Bestellung
1.1*: vorbereiten()
1.1.1: prüfen()
1.1.2: [prüfen==true] entfernen
Macallan:
Bestellungseingang
1.1.3: [prüfen==true] neu
: Lieferartikel
20.07.2015
1.1.2.1: Bedürfnis an
Besteller
Macallan Lager:
Lieferartikel
1.1.2.2: neu
: Lieferartikel
Modellierung WS 06/07
79
UML
UML
Zusammenfassung der bisherigen Diagramme
•
Klassendiagramm (inkl. CRC-Karten)
Statik
•
Anwendungsfalldiagramm
Dynamik (Benutzersicht)
•
Interaktionsdiagramm
Dynamik (Kooperation
Sequenzdiagramm
von Objekten)
Kollaborationsdiagramm
20.07.2015
Modellierung WS 06/07
80
UML
UML
Zusammenfassung der bisherigen Diagramme (2)
Und nun noch:
•
•
Zustandsübergangsdiagramme
einfache
parallele
Aktivitätsdiagramm
•
Komponentendiagramm
20.07.2015
Dynamik einzelner Objekte
Abläufe / Anwendungsfälle
und ihre Kooperation
Systemstrukturierung
Modellierung WS 06/07
81
UML: Zustandsübergangsdiagramme
UML - Zustandsübergangsdiagramm
•
•
•
•
20.07.2015
Zustandsübergangsdiagramme beschreiben die erlaubten
Zustandsübergänge eines Objektes und die Ereignisse, die die Übergänge
auslösen.
Zustände werden durch abgerundete Rechtecke dargestellt, Übergänge
durch Pfeile.
Syntax für Pfeilanschriften: Ereignis [Bedingung] Aktion wobei alle drei Teile
optional sind.
Wenn in einem Zustand interne Operationen ausgeführt werden sollen, so
finden sich diese nach dem Schlüsselwort „tue/“ im unteren Teil eines
Zustandes.
Modellierung WS 06/07
82
UML: Zustandsübergangsdiagramme
UML-Zustandsübergangsdiagramme
(Notation)
Zustand
Ereignis [Bedingung] Aktion
Zustandsübergang, der durch das Eintreten des Ereignisses
ausgelöst wird (falls die Bedingung gilt!) und dabei die Aktion
durchführt
Zustand
tue / Aktivität
Zustand, dessen Eintreten das Auslösen der Aktivität veranlaßt.
[Bedingung] Aktion
Ein Übergang ohne Ereignis tritt ein, sobald die Aktivität des
Quellzustandes beendet ist.
Zustand
[Bed3]
20.07.2015
[Bed1]
[Bed2]
Die Bedingungen werden verwendet, um den gewünschten
Zustandsübergang auszuwählen. Die Bedingungen an den
Übergängen mit demgleichen Quellzustand sollten sich
wechselseitig ausschließen.
Modellierung WS 06/07
83
UML: Zustandsübergangsdiagramme
UML-Zustandsübergangsdiagramme (2)
(Notation)
Zustand
Ereignis / Aktion
Der Zustand reagiert auf das Ereignis mit einer Aktion
(die nicht zu einem neuen Zustand führt).
entry
Ein Zustand kann mit einer Eingangsaktion (entry) und einer
Ausgangsaktinon (exit) assoziiert sein.
(alternative Darstellung: rein textuell)
Zustand
exit
entry
Zustand
exit
20.07.2015
Ereignis/
Aktion
Ein Selbstübergang dieser Art führt zur Ausführung von
• exit
• Aktion
• entry
Modellierung WS 06/07
84
UML: Zustandsübergangsdiagramme
UML - Zustandsübergangsdiagramm
(Beispiel Bestellung)
Start
/hole ersten Artikel
Hole nächsten Artikel
[nicht alle Artikel geprüft]
Prüfend
[alle Artikel geprüft
und verfügbar]
Auslieferung
tue/veranlasse
Lieferung
tue/prüfe Artikel
[Alle Artikel geprüft &&
einige nicht im Lager]
Aktivität
Artikel erhalten
[alle Artikel verfügbar]
Artikel erhalten
[einige nicht im Lager]
Wartend
Interner Übergang
20.07.2015
geliefert
Geliefert
Zustand
Modellierung WS 06/07
85
UML: Zustandsübergangsdiagramme
UML - Zustandsübergangsdiagramm
Hinweis:
• Wechselweiser Ausschluß der Bedingungen an den Übergängen,
die vom Zustand „prüfend“ ausgehen:
– nicht alle Artikel geprüft => nächster Artikel wird geprüft
– alle Artikel geprüft und alle verfügbar => Lieferung veranlassen
– alle Artikel geprüft, nicht alle verfügbar => wartend
• Zustände ohne Aktivität oder: Warten auf ein Ereignis
Bsp.: Im Zustand „wartend“ wird auf die Lieferung von Artikeln
gewartet, sonst passiert nichts !
20.07.2015
Modellierung WS 06/07
86
UML: Zustandsübergangsdiagramme
UML - Zustandsübergangsdiagramm
(Erweiterung um „Abweisen einer Bestellung“)
Anforderung: Abweisen soll jederzeit möglich sein
=> Von allen Zuständen werden Zustandsübergänge zu „Abgewiesen“ ergänzt.
Hole nächsten Artikel
[nicht alle Artikel geprüft]
[alle Artikel geprüft
und verfügbar]
Prüfend
tue/veranlasse
Lieferung
tue/prüfe Artikel
[Alle Artikel geprüft &&
einige nicht im Lager]
abweisen
Artikel erhalten
[einige nicht im Lager]
[Artikel erhalten &&
alle Artikel vorrätig]
geliefert
abweisen
Wartend
Geliefert
abweisen
20.07.2015
Auslieferung
Abgewiesen
Modellierung WS 06/07
87
UML: Zustandsübergangsdiagramme
Alternative Strukturierung durch Oberzustände
(Superstates)
aktiv
Hole nächsten Artikel
[nicht alle Artikel geprüft]
[alle Artikel geprüft
und verfügbar]
Prüfend
Auslieferung
tue/veranlasse
Lieferung
tue/prüfe Artikel
[Alle Artikel geprüft &&
einige nicht im Lager]
Artikel erhalten
[einige nicht im Lager]
Artikel erhalten
[alle Artikel verfügbar]
geliefert
Wartend
abweisen
Geliefert
Abgewiesen
Hinweis: es bleibt auf dieser Ebene unspezifiziert, wann (von welchem
Zustand kommend) der Zustand „abgewiesen“ eintritt!
20.07.2015
Modellierung WS 06/07
88
UML: Zustandsübergangsdiagramme
Zustandsübergangsdiagramme
(ein zweites Beispiel)
Prüfend
[Zahlung nicht OK]
tue/prüfe Zahlung
[Zahlung OK]
geprüft
abgewiesen
geliefert
20.07.2015
Modellierung WS 06/07
89
UML: Zustandsübergangsdiagramme
UML-Zustandsübergangsdiagramme
Oft werden externe Ereignisse als Auslöser verschiedener Zustandsübergangsdiagramme betrachtet.
In zusammengehörigen Fällen (Bestellung, Zahlung) kommt man auf diese Weise zu parallelen
Zustandsübergangsdiagrammen.
abgewiesen
(Bestellung)
wartend
abgewiesen
prüfend
(Bestellung)
veranlasse
Lieferung
geliefert
Ende
prüfend
(Zahlung)
geprüft
abgewiesen
(Zahlung)
20.07.2015
Modellierung WS 06/07
90
UML: Zustandsübergangsdiagramme
UML - Zustandsübergangsdiagramme
• Parallele Zustandsübergangsdiagramme machen Sinn, wenn ein
Objekt Mengen von unabhängigen Zuständen hat.
• Komplizierte, parallele Zustandsübergangsdiagramme sind ein Indiz
dafür, daß Objekte in mehrere Objekte aufgeteilt werden sollten
(oben z.B. in Bestellung und Zahlung)
20.07.2015
Modellierung WS 06/07
91
UML: Zustandsübergangsdiagramme
UML - Zustandsübergangsdiagramme
(Bewertung)
• Geeignet für die Beschreibung des Verhaltens eines Objektes über
mehrere Anwendungsfälle hinweg
• nicht geeignet für die Beschreibung der Interaktion zwischen
Objekten
• geeignet für die Beschreibung des Verhaltens der Objekte der
wesentlichen Klassen! Vollständigkeitsfanatismus nützt nicht viel.
• Geeignet für Benutzungsschnittstellen und Kontrollobjekte.
20.07.2015
Modellierung WS 06/07
92
UML: Aktivitätsdiagramme
UML - Aktivitätsdiagramme
•
Ein Aktivitätsdiagramm beschreibt die Reihenfolge und Abhängigkeiten von
logisch zusammengehörenden Aktivitäten.
•
Eine Aktivität ist dabei ein einzelner Schritt in einem Verarbeitungsablauf.
•
Die Aktivitäten eines Aktivitätsdiagramms sind eindeutig Objekten
zugeordnet (wichtiger Unterschied zu Datenflußdiagrammen !)
•
Aktivitäten und Aktivitätsdiagramme sind entweder
– einer Klasse
– einer Operation (besonders hilfreich für komplexe Operationen)
– einem Anwendungsfall zugeordnet. (besonders hilfreich bei Anwendungsfällen
mit Parallelität)
20.07.2015
Modellierung WS 06/07
93
UML: Aktivitätsdiagramme
UML - Aktivitätsdiagramme (Forts.)
• Aktivitätsdiagramme gehen nicht auf eine der Ursprungsnotationen
(Booch, Rumbaugh, Jacobson) zurück.
• Aktivitätsdiagramme sind nützlich, wenn es um geschäftprozeßorientierte Softwaresysteme geht.
• Die Ausführungsregeln für Aktivitätsdiagramme erinnern an die
Ausführungsregeln von Petrinetzen.
• Zur Übung kann das Aktivitätsdiagramm „Getränke“ in ein Petrinetz
überführt werden.
20.07.2015
Modellierung WS 06/07
94
UML: Aktivitätsdiagramme
UML - Aktivitätsdiagramm
(Notation)
Synchronisation der Kontrolle (AND)
mit Synchronisationsbedingung
(Die Bedingung ist optional.)
Aktivität
Aktivität
[Bedingung]
Aufsplitten der Kontrolle
(Zulassen von Parallelität)
Kontrollfluß
Aktivität1
Aktivität2
Aktivität2 wird nach
Abschluß von Aktivität1
gestartet.
Verzweigunsaktivität
(kann auch durch normale
Aktivität dargestellt werden)
[Bedingung]
20.07.2015
Kontrollfluß, der unter der
angegebenen Bedingung
gewählt wird.
Modellierung WS 06/07
95
UML: Aktivitätsdiagramme
UML-Aktivitätsdiagramm (Forts.)
(Notation)
Aktivität
Objekt
[Zustand]
Aktivität
Die Ausführung der Aktivität versetzt das Objekt in
den angegebenen Zustand (optionales, selten
verwendetes Konstrukt in Aktivitätsdiagrammen).
Klasse
Hinweis: fragwürdige Überlappung zu Zustandsübergangsdiagrammen !
Beispiel: aus dem Aktivitätsdiagramm wird eine
Bestellung in den Zustand „abgewiesen“ versetzt (was
bedeutet das,für das Zustandsübergangsdiagramm?)
20.07.2015
Aktivität wird durchgeführt,
wenn über einen der eingehenden
Kontrollflüsse die Kontrolle ankommt
(OR)
Modellierung WS 06/07
Start des Ablaufs und Identifikation
der betroffenen Klasse
Ende des Ablaufs (optional)
96
UML: Aktivitätsdiagramme
UML - Aktivitätsdiagramm
(Beispiel zur Spezifikation einer Operation)
[kein Kaffee]
Finde
Getränk
Synchonisation
[keine Cola]
[Kaffee gefunden]
[Cola gefunden]
Kaffee in
Filter
Wasser
einfüllen
Nehme
Tassen
Aktivität
Filter in
Maschine
Anschalten
20.07.2015
Nehme Dose
Cola
Ende
Kaffee
kochen
Einschenken
Modellierung WS 06/07
Trinken
97
UML: Aktivitätsdiagramme
UML - Aktivitätsdiagramm
(Beispiel zur Spezifikation eines Anwendungfalls)
Informale Beschreibung:
Wenn eine Bestellung eintrifft, überprüfen wir jede Bestellposition, um zu sehen, ob
der Lagerbestand reicht. Falls das so ist, werden die Waren der Bestellung
zugeordnet. Wenn durch diese Zuordnung der minimale Lagerbestand unterschritten
wird, dann wird eine Nachbestellung veranlaßt. Währenddessen wird die Zahlung
überprüft. Wenn die Zahlung OK ist und genügend Waren vorhanden sind, wird
geliefert. Wenn wir für die Lieferung auf nachzubestellende Waren warten müssen,
bleibt die Bestellung offen. Wenn die Zahlung nicht OK ist, wird die Bestellung
abgewiesen.
20.07.2015
Modellierung WS 06/07
98
UML: Aktivitätsdiagramme
UML - Aktivitätsdiagramm
(Beispiel zur Spezifikation des Anwendungsfalles „Bestelleingang“)
Bestellung
Mehrfacher
Auslöser
Bestellung
erhalten
*
Bestellung
abweisen
Prüfe
Zahlung
Für jede Bestellposition
Prüfe Verfügbarkeit
einer Bestellposition
[verfügbar]
[OK]
Synchronisationsbedingung
[Waren für alle
Bestellpositionen
verfügbar und
Zahlung OK]
20.07.2015
Zuordnung zur
Bestellung
[nachzubestellen]
Veranlasse
Lieferung
Modellierung WS 06/07
Nachbestellungsartikel
99
UML: Aktivitätsdiagramme
Hinweis:
1.)
2.)
3.)
UML - Aktivitätsdiagramme
hier wäre ein ausgezeichnetes Ende nicht sinnvoll, da es
mehrere Enden gibt
aus dem linken Zweig kann der rechte nicht angehalten werden! (bei
strikter Sequentialiseirung ist dieses Problem vermeidbar,
allerdings nur auf Kosten der Parallelität)
Wenn die Bedingung am Ende von „prüfe Verfügbarkeit einer
Bestellposition“ nicht erfüllt ist, stoppt der Ablauf! Im günstigsten Fall
wird eine ankommende Lieferung die weitere Auslieferung veranlassen (Frage der Ausführungssemantik!)
Besser wäre eine Ergänzung zu folgendem Aktivitätsdiagramm:
20.07.2015
Modellierung WS 06/07
100
UML: Aktivitätsdiagramme
UML - Aktivitätsdiagramm
(Beispiel zur Spezifikation des Anwendungsfalles „Bestelleingang“)
Bestellung
Erhalte
Lieferung
Bestellung
erhalten
Identifiziere ausstehende,
bestellte Artikel
*
Bestellung
abweisen
Prüfe
Zahlung
Für jede Bestellposition
Prüfe Verfügbarkeit
einer Bestellposition
[verfügbar]
[OK]
Ordere ankommende Waren
den Bestellungen zu
Zuordnung zur
Bestellung
Nachbestellungsartikel
[nachzubest.]
[Waren für alle
Bestellpositionen
verfügbar und
Zahlung OK]
Für jeden identifizierten,
*
bestellten Artikel
Alle offenen
Bestellungen
berücksichtigt
Rest ins Lager
Veranlasse
Lieferung
20.07.2015
Modellierung WS 06/07
101
UML: Aktivitätsdiagramme
UML - Aktivitätsdiagramm
(Bestelleingang und Nachlieferung)
• Homogene Spezifikation, aber
– was passiert bei vielen offenen Bestellungen?
– wie passiert die Kommunikation zwischen einem Ablauf des Typs
Nachlieferung und vielen Nachbestellungen?
Allgemein: Wie legt ein Ablaufmodell (ausgedrückt als Aktivitätsdiagramm)
die Kommunikation auf der Ebene einzelner Abläufe fest?
Zur Erinnerung: OOA dient der Spezifikation; es müssen keine vollständigen
Festlegungen der Implementierungen entstehen. Es ist deshalb durchaus
nützlich, mit Beschreibungen zu arbeiten, die nicht alles festlegen, solange
man sich der Lücken bewußt ist.
20.07.2015
Modellierung WS 06/07
102
UML: Aktivitätsdiagramme
UML - Aktivitätsdiagramm
(Strukturierung)
• Das zusammengefügte Beispiel (Bestelleingang und Nachlieferung)
ist nicht eindeutig einer Klasse, einer Operation oder einem
Anwendungsfall zuzuordnen (weil es durch Komposition zweier
getrennter Abläufe entstanden ist).
• Da man einerseits die Wechselwirkungen beschreiben möchte
(deshalb die Komposition) und andererseits die klare Zuordnung
nicht aufgeben möchte, gibt es das Strukturierungsmittel der
vertikalen Abgrenzung.
20.07.2015
Modellierung WS 06/07
103
UML: Aktivitätsdiagramme
UML-Aktivitätsdiagramm
(Beispiel zur vertikalen Abgrenzung)
Finanzen
LagerManager
Bestellungsverarbeitung
Erhalte
Lieferung
Bestellung
erhalten
Prüfe
Zahlung
[nicht OK]
Bestellung
abweisen
[OK]
[Waren für alle
Bestellpositionen
verfügbar und
Zahlung OK]
20.07.2015
Identifiziere ausstehende,
bestellte Artikel
Für jede Bestellposition
Für jeden identifizierten,
*
*
bestellten Artikel
Prüfe Verfügbarkeit
Ordere ankommende Waren
einer Bestellposition
den Bestellungen zu
[verfügbar]
Warenwirtschaft
Zuordnung zur
Bestellung
Nachbestellungsartikel
[nachzubest.]
Alle offenen
Bestellungen
berücksichtigt
Rest ins Lager
Veranlasse
Lieferung
Modellierung WS 06/07
104
UML: Aktivitätsdiagramme
UML-Aktivitätsdiagramm
Aktivitäten können verfeinert werden
(passende Abstraktionsebenen für
unterschiedliche Zwecke)
(Strukturierung)
Beispiel: Verfeinerung der Aktivität
„prüfe Zahlung“
Bestimme
Zahlungstyp
Nicht OK
[nicht OK]
Scheck
Rechnung
Normaler
Bestellwert
[N] > 1000 DM?
Kunde?
Prüfe
Scheck
[Y]
[nicht OK]
Prüfe
Kreditkarte
[nein]
[Ja]
Prüfe
Zahlungsgeschichte
[OK]
[OK]
[OK]
Vorkasse
anfordern
Kreditwürdigkeit
prüfen
[OK]
[nicht OK]
[nicht erhalten]
Nicht OK
Eröffne
Kundenkonto
OK
20.07.2015
Modellierung WS 06/07
105
UML: Aktivitätsdiagramme
UML - Aktivitätsdiagramme (Bewertung)
• geeignet für die Modellierung von Geschäftsprozessen über die
Grenzen von Anwendungsfällen hinweg.
• geeignet für die detaillierte Analyse von Anwendungsfällen.
• geeignet für die Modellierung von parallelen Software-Systemen
• nicht geeignet für die Beschreibung der Interaktion von Objekten
• nicht geeignet für die Zustandsübergänge eines einzelnen Objektes
20.07.2015
Modellierung WS 06/07
106
UML: Komponentendiagramme
UML - Komponentendiagramme - Zwischen OOA und
OOD
•
•
•
•
•
20.07.2015
In UML heißt eine Gruppe von „zusammengehörenden“ Klassen package
(Komponente).
Die Zusammenfassung von Klassen zu Komponenten dient zur
Strukturierung von Klassendiagrammen. Oft ist diese Strukturierung ein
erster Entwurfsschritt.
Als Hilfe dient die Ermittlung von Abhängigkeiten.
Zwei Komponenten sind abhängig, wenn Änderungen an der Schnittstelle
der einen der anderen bekannt gemacht werden müssen.
Zyklische Abhängigkeiten sind in UML nicht verboten, sollten aber dringend
aufgelöst werden.
Modellierung WS 06/07
107
UML: Komponentendiagramme
Komponentendiagramme - Zwischen OOA und OO
Behandlung von
Bestellungen
Mailingliste
AWT
UI
UI
Paket
Abhängigkeit
Behandlung von
Bestellungen
Mailingliste
Anwendung
Anwendung
Im kleinen Rechteck
links oben, kann dann der
Komponentenname auftauchen,
wenn die internen Klassen
innerhalb des Komponentenrechtecks
angezeigt werden sollen.
20.07.2015
Bestellungen
Modellierung WS 06/07
Kunden
108
UML: Metamodell
UML- Methodik
1 Von den Anforderungen zu Klassendiagrammen
und dann über Use Case Diagrammen zu Interaktionsdiagrammen zu
Zustandsübergangsdiagrammen
parallel Übergang zu OOD mit Hilfe von Komponentendiagrammen
Aktivitätsdiagramme nahezu beliebig zur Ablaufveranschaulichung
oder
2 Von den Anforderungen zu Use Case Diagrammen
und dann Aktivitätsdiagrammen zur Detailbeschreibung von Use Cases
und dann über Klassendiagramme zu Interaktionsdigrammen
und dann zu Zustandsübergangsdiagrammen
parallel Übergang zu OOD mit Hilfe von Komponentendiagrammen
Beide Ansätze nur als grobe Richtlinien, nicht als Dogmen!
20.07.2015
Modellierung WS 06/07
109
UML 2.0 - Neuerungen
• Seit November 2005
• Alte Diagramme im wesentlichen beibehalten
• Erweiterungen:
– Bessere dynamische Modellierung, insbesondere Zeitaspekte
– Neue Möglichkeiten zur Referenzierung, auch zwischen Verhaltensund Strukturdiagrammen
– Schachtelung in allen Verhaltensdiagrammen
20.07.2015
Modellierung WS 06/07
110
UML 2.0-Diagrammtypen
Strukturdiagramme
Klassendiagramm
Paketdiagramm
Kompositionsstrukturdiagramm
Komponentendiagramm
Objektdiagramm
Verhaltensdiagramme
Aktivitätsdiagramm
Use-CaseDiagramm
Interaktions-Diagramme
Zustandsautomat
ähnlich PetriNetzen
Sequenzdiagramm
Interaktionsübersichtsdiagramm
Zeitverlaufsdiagramm
KommunikationsDiagramm
Verteilungsdiagramm
UML 1.x:
Kollaborationsdiagramm
20.07.2015
Modellierung WS 06/07
111