Post on 12-Aug-2019
05.12.2002 Modellierung WS 02/03 1
3. Objektorientierte Spezifikation
Zunächst: allgemeines zur objektorientierten Spezifikation (auchobjektorientierte Analyse (OOA) genannt)
Dann: Die Unified Modeling Language UML
05.12.2002 Modellierung WS 02/03 2
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
05.12.2002 Modellierung WS 02/03 3
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.
05.12.2002 Modellierung WS 02/03 4
Objektorientierte Analyse
Beispiele
Methoden
Nenne-AlterNenne-GewichtVerzehre-Nahrung (...)Laufe (...)...
Ausstellen (...)Verlängern (...)...
Attribute
AlterGewicht...
NameNummerAusstellungsdatumAblaufdatum...
Objekt
Mensch
Personalausweis
05.12.2002 Modellierung WS 02/03 5
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.
05.12.2002 Modellierung WS 02/03 6
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)
05.12.2002 Modellierung WS 02/03 7
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.
05.12.2002 Modellierung WS 02/03 8
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 erstelltund anschließend nach Anweisung ausgefüllt.
05.12.2002 Modellierung WS 02/03 9
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 erzeuge
erzeuge erzeuge
Person
Versicherter Mitarbeiter
erbt vonerbt von
05.12.2002 Modellierung WS 02/03 10
Objektorientierte Analyse
Grundelemente der Objektorientierung: Vererbung
• Konzept: Mehrfacherbung= eine Subklasse besitzt mehrere Superklassen
erzeuge
erzeuge
erzeuge
Person
Versicherter Mitarbeiter
erzeugeversicherterMitarbeiter
erbt vonerbt von
erbt vonerbt von
Beispiel für Mehrfacherbung:Versicherung
05.12.2002 Modellierung WS 02/03 11
Objektorientierte Analyse
Grundlemente der Objektorientierung: Beziehungen zwischen Klassen
Gleichartige Kommunikationsbeziehungenzwischen Objekten werden durch die Definition der Beziehungen zwischen Klassen vorgegeben:
• Assoziation („hat-Kenntnis-von“)• Aggregation („ist-Teil-von“)
Beispiel:Versicherung
Person
Versicherter Mitarbeiter
erbt vonerbt von
kenntVertrag
besteht-aus
Paragraph
05.12.2002 Modellierung WS 02/03 12
Objektorientierte Analyse
Grundelemente der Objektorientierung: Beziehung zwischen Klassen
Beispiel für erzeugte Objekte:Versicherung
Person
Versicherter Mitarbeiter
erbt vonerbt von
Paragraph
Vertragkennt
besteht-aus
05.12.2002 Modellierung WS 02/03 13
Objektorientierte Analyse
Grundelemente der Objektorientierung: Polymorphie
Polymorphie:
statisch: - in Abhängigkeit von den Parametertypen wird diepassende Operation gewählt.
- dies geht auch ohne ObjektorientierungBsp.: +
dynamisch: die aufzurufende Operation wird erst dann ermittelt (und an dasOperationssymbol gebunden), wenn sie aufgerufen wird (und nichtetwa zur Compile-Zeit)
05.12.2002 Modellierung WS 02/03 14
Objektorientierte Analyse
GeomFigurx:integery:integer
sichtbar: Booleananzeigen()entfernen()
setPosition(neuX, neuY)
FigurenBehaelterfiguren: setanzeigen()
anzeigen „smalltalk-beispiel“figuren do [:f | f anzeigen.].
„do: iteriert über die Elemente fder Menge figuren“
Kreisradius {radius>0}setRadius(neuR)
anzeigen()
Rechtecka {a>0}b {b>0}
setA(neuA)setB(neuB)anzeigen()
05.12.2002 Modellierung WS 02/03 15
Objektorientierte Analyse
Grundelemente der Objektorientierung: Objektidentität
Objektidentität
• Objektwertgleichheit ≠ Objektgleichheit
• Es kann objektwertgleiche Objekte geben
• Unterscheidung erfolgt über interne Kennungen (Surrogate)
05.12.2002 Modellierung WS 02/03 16
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.
05.12.2002 Modellierung WS 02/03 17
Objektorientierte Analyse
Grundphilosophie objekt-orientierterSoftware-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!
05.12.2002 Modellierung WS 02/03 18
Objektorientierte Analyse
Entwicklungsabschnitte
• OO-Analyse: Bestimmen von Objekten und Klassen ausder Realität des Anwendungsbereichs
• OO-Design: Ergänzen der Strukturenaufgrund technischer Erfordernisse
• OO-Programmierung: Umsetzen in Programmierspracheund Anpassen an Sprachspezifika
05.12.2002 Modellierung WS 02/03 19
Objektorientierte Analyse
OO-Analyse besteht aus
der Erforschung des Anwendungsbereichs, d.h.
• Objekte entdecken• Klassen ableiten• Klassen strukturieren• Aufgaben zuordnen• Zusammenarbeit festlegen
05.12.2002 Modellierung WS 02/03 20
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
05.12.2002 Modellierung WS 02/03 21
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)
05.12.2002 Modellierung WS 02/03 22
Objektorientierte Analyse
Erforschung: Beispiel Vererbung
Ohne Beziehungen Mit Vererbung
GerätMembran-pumpePumpe
Zentrifugal-pumpe Kühler Pumpe Kühler
Zentrifugal-pumpe
Membran-pumpe
Notation: OMT
05.12.2002 Modellierung WS 02/03 23
Objektorientierte Analyse
Erforschung: Beispiel Aggregation
Ohne Beziehungen Mit Aggregation
Sekretariat Firma Firma
BereichBereich Abteilung
Leitung
Notation: OMT
Abteilung Sekretariat Leitung
05.12.2002 Modellierung WS 02/03 24
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)
05.12.2002 Modellierung WS 02/03 25
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
05.12.2002 Modellierung WS 02/03 26
Objektorientierte Analyse
OO-Analyse
Das Ergebnis der vorgestellten OO-Analyse ist einestatische 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
05.12.2002 Modellierung WS 02/03 27
Objektorientierte Analyse
OO-Analyse
Zur Beschreibung der Dynamik von objektorientierten Systemenwerden „herkömmliche“ Methoden eingesetzt. Zum Beispiel:• Zustandsdiagramme• Sequenzdiagramme• Anwendungsfalldiagramme• formale, semiformale und informale Texte
Eine statische Struktur ohne Dynamikmodellierung ist Stückwerk !
05.12.2002 Modellierung WS 02/03 28
Objektorientierte Analyse
Vorteile von objektorientierten Methoden gegenüberfunktionsorientierten (strukturierten) Methoden
• 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
05.12.2002 Modellierung WS 02/03 29
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ätaußer Sicht)
• unausgereifte Werkzeuge
05.12.2002 Modellierung WS 02/03 30
Objektorientierte Analyse
Rückblick auf Historie
Ursprünge der Vererbung Programmiersprache SIMULA 1967Grundlagen für Einkapselung Information Hiding 1972
Abstrakte Datentypen 1975Grundlage für Notationen Entity-Relationship-Modellierung 1976Dynamikmodellierung (traditionelle Methoden)
Objektorientierung kombiniert etablierte Methoden!
05.12.2002 Modellierung WS 02/03 31
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
05.12.2002 Modellierung WS 02/03 32
UML: Einführung
3.2 Die Unified Modeling Language (UML)
Spezifikationssprache: UMLSyntax
MethodikSemantik
05.12.2002 Modellierung WS 02/03 33
UML: Einführung
OOD, 1991G. BoochS.Shlaer, S. Mellor
OOA und OOD, 1991P. Coad, E. Yourdon,
1991
OMT, 1991J. Rumbaugh
OOSE, 1992I. Jacobson
Integrationen auf dem Weg zur UML
Integrationen ohne Niederschlag in der UML
Unified MethodG. Booch / J. Rumbaugh,
1995
Unified Modeling Language (UML)G. Booch / J. Rumbaugh / L. Jacobson
1996
CRC-Karten(Class-Responsibilities-
Collaborations)R. -Brock 1990
State Charts(erw. / hierarchischeZustandsübergangs-
diagramme)D. Harel
05.12.2002 Modellierung WS 02/03 34
UML: Einführung
Beschreibungsmittel in UML
• Anwendungsfalldiagramme (Use CaseDiagram)
– Akteure– Anwendungsfälle– Beziehungen
• Klassendiagramme (Klassenstrukturdiagramm)
– Klassen– Beziehungen zwischen Klassen
• Verhaltensdiagramme– Aktivitätsdiagramme
• Zustände• Zustandsübergänge• Ereignisse• Aktivitäten• Objektzustände
– Kollaborationsdiagramme• Objekte• Beziehungen inklusive Nachrichtenaustausch
(räumlich geordnet)
– Sequenzdiagramme (Weg-Zeit-Diagramme)• Objekte• Beziehungen inklusive Nachrichtenaustausch
(zeitlich geordnet)– Zustandsdiagramme
• Zustände • Beziehungen• Ereignisse
• Implementierungsdiagramme• Komponentendiagramm
– Komponenten– Beziehungen zwischen Komponenten
• Einsatzdiagramme– Komponenten– Beziehungen– Knoten
05.12.2002 Modellierung WS 02/03 35
UML: Einführung
1) Klassendiagramme (inkl. CRC Cards)
2) Anwendungsfall-diagramm
3a) Sequenzdiagramme3b) Kollaborationsdiagramme
falls dasAnwendungsgebietworkflow-geprägt
ist
4) Zustandsübergangs-diagramm
6) Aktivitäten-diagramm
5) Komponenten-diagramme
OO
A
OO
D
05.12.2002 Modellierung WS 02/03 36
UML: Klassendiagramme
UML-Klassendiagramme
Klassifikation -> Bildung von Klassen
Generalisierung/ -> VererbungSpezialisierung Bildung von Ober- und Unterklassen
Assoziation -> Beziehung zwischen Objekten einer oder mehrererKlassen
Aggregation -> Spezialfall der Assoziation, Objekte sind Bestand-teile eines anderen Objektes
05.12.2002 Modellierung WS 02/03 37
UML: Klassendiagramme
Klassifikation Assoziation
AName-von-A-aus
B1
Name-von-B-aus0..*
Ein A-Objekt steht zu beliebig vielen B-Objekten in Verbindung.
Die Beziehung von A aus gesehen heißt „Name-von-A-aus“.
Ein B-Objekt steht zu einem A-Objekt in Verbindung.
05.12.2002 Modellierung WS 02/03 38
UML: Klassendiagramme
Generalisierung Aggregation
A B1..*1
Ein A-Objekt steht zu einem oder mehreren B-Objekten in Verbindung.
Ein B-Objekt steht zu einem A-Objekt in Verbindung.
05.12.2002 Modellierung WS 02/03 39
UML: Klassendiagramme
Unterscheidungen verschiedener Aggregationen
Normale Aggregation
Mitarbeiterbesteht aus >
1
Unternehmen1..*
Abteilungbesteht aus >
1..*1
Komposition (Einzelteile sind vom Aggregat existenzabhängig d.h. sie könnenohne das Aggregat nicht existieren).
hat >Rechnung Rechnungsposition
1..*1
Hinweis: Bei Komposition auf der Aggregatseite 1.
05.12.2002 Modellierung WS 02/03 40
UML: Klassendiagramme
Richtungen von Assoziationen und Aggregationen... geben an, welche Objekte von der Beziehung wissen
hat >A 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!
05.12.2002 Modellierung WS 02/03 41
UML: Klassendiagramme
Kommunikation zwischen Objekten... erfolgt über den Austausch von Nachrichten
set() ->A B
Ein Objekt der Klasse A kann die Nachricht set() an ein Objekt der Klasse B senden..
05.12.2002 Modellierung WS 02/03 42
UML: Klassendiagramme
Grundelemente der Objektorientierung: Klassen, ihre Interna und Objekte
ZusicherungKreis
radius: integer {radius > 0}mittelpunkt: Point = (10,10)
anzeigen()entfernen()
setPosition(pos: Point)setRadius(neuerRadius: integer)
Klassenname
Attributname
Attribut-Typ
Operationen
Initialwert
Parameter(Name: Typ = Initialwert)
Klasse
einKreis: Kreis
radius=25mittelpunkt=(10,10)
ExemplarnameKlassenname
AttributnamenAttributwerte
Objekt
05.12.2002 Modellierung WS 02/03 43
UML: Klassendiagramme
Grundelemente der Objektorientierung: VererbungAttribute und Operationen in Vererbungsbeziehungen
GeomFigurx:integery:integer
sichtbar: Booleananzeigen()entfernen()
setPosition(neuX, neuY)
Attribute und Operationen werden in den Klassen angesiedelt, in die sie der Anschauung nach gehören. Redundanz-, Performanz- und sonstige Entwurfs- undImplementierungsaspekte interessieren während der OOA NICHT !
Kreisradius {radius>0}setRadius(neuR)
Rechtecka {a>0}b {b>0}
setA(neuA)setB(neuB)
Dreiecka {c-b < a < b+c}b {a-c < b < a+c}c {a-b < c < a+b}
setA(neuA)setB(neuB)setC(neuC)
05.12.2002 Modellierung WS 02/03 44
UML: Klassendiagramme
Vererbung gemäß Anschauung
Rechtecka {a>0}b {b>0}
setA(neuA)setB(neuB)anzeigen()entfernen()
Liefert für Quadrate nichtdie minimale Implementierung, denn esgibt zwei Kantenlängen.
Quadrat{a=b}
05.12.2002 Modellierung WS 02/03 45
UML: Klassendiagramme
Alternative Vererbung
Quadrata {a>0}
setA(neuA)anzeigen()entfernen()
Entspricht nicht der Anschauung,
ist aber redundanzfrei !
Rechteckb{b>0}
setB(neuB)
05.12.2002 Modellierung WS 02/03 46
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 werdenDiskriminatoren 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!)
05.12.2002 Modellierung WS 02/03 47
UML: Klassendiagramme
Multiple Klassifikation
Femalerole(dynamisch)
sex(vollständig)
DiskriminatorSurgeon
Doctor
FamilyDoctorPerson
NurseMale patient
Physio-therapistPatient
Legale Kombination von Klassen für ein Objekt: Female, Patient, NurseMale, PhysiotherapistFemale, Patient
Illegale Kombinationen von Klassen für ein Objekt: Patient, DoctorMale, Doctor, Nurse
(vgl. Entwurfsmuster Role Model im Abschnitt zur Rolle Designer)
05.12.2002 Modellierung WS 02/03 48
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.
05.12.2002 Modellierung WS 02/03 49
UML: Klassendiagramme
Parametrisierte Klassen
... sind Klassen, die einen Typ als Parameter haben. Typischerweise: Stacks, Queues, Listen, Mengen
Parametrisierte Klasse Parametrisierte Klasse mit gebundenem ParameterSet
TSet<Integer>
05.12.2002 Modellierung WS 02/03 50
UML: Klassendiagramme
Graphische Darstellung von parametrisierbaren und abstrakten Klassen
parameterisierbare Klassen
abstrakte Klassen
Warteschlange
anfuegen()entnehmen()
i: Element „bind“ <Patient>
„bind“ <PKW>
Wartezimmer
Stau
Klasse{abstrakt}
attribute
operationen()
Klasse
attribute
operationen()
Vereinfachte Darstellung
Klasse{abstrakt} Klasse
05.12.2002 Modellierung WS 02/03 51
UML: Klassendiagramme
Attribute, Klassenattribute, abgeleitete AttributeAttribute 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 allerObjekte 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 einemSlash /
Beispiel: Das Attribut \Alter einer Person kann aus ihrem Geburtsdatum abgeleitet werden.
05.12.2002 Modellierung WS 02/03 52
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: stringparameter-list: beinhaltet (optional) Argumente, Syntax wie bei Attributenreturn-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!
05.12.2002 Modellierung WS 02/03 53
UML: Klassendiagramme
CRC Karten (Class-Responsibility-Collaboration)
• Mit CRC-Karten werden die abstrakten Aufgaben einer Klasse definiert.
BestellungBestellung
Prüfe, ob Artikel auf Lager
Bestimme Preis
LagerbestandLagerbestand
LagerbestandLagerbestand
Class Name
Responsibility Collaboration
Prüfe auf gültigeZahlung Kunde
AusliefernAusliefern
Kunde
05.12.2002 Modellierung WS 02/03 54
UML: Klassendiagramme
Rollen in Assoziationen
• 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).
05.12.2002 Modellierung WS 02/03 55
UML: Klassendiagramme
BestellungdateReceivedisPrepaidnumber: Stringprice: Moneydispatch()close()
KundenameadresscreditRating(): String
FirmenkundecontactNamecreditRatingcreditLimitremind()billForMonth(Integer)
PersönlicherKunde
creditcard#
* 1
Interne Bestellungquantity: Integerprice: MoneyisSatisfied: Boolean
1
*
Rollenname
{if Order.customer.creditRating is„poor“, then Order.isPrepaid
must be true}
Constraint
Multiplicity: Many-valued
* 1
Attributes
Multiplicity: mandatory
GeneralizationAssociationClass
{creditRating() ==„poor“}
Artikel
*0..1
Operations sales rep Multiplicity: optionalArbeitnehmer
Produkt
05.12.2002 Modellierung WS 02/03 56
UML: Klassendiagramme
Klassendiagramme: weiterführende Konzepte
Assoziationsklassen werden benutzt, um Assoziationen mit Attributen und Operationen zu verknüpfen.
Person
Beschäftigung
Periode:Zeitraum
* ArbeitgeberFirma
*Angestellter
05.12.2002 Modellierung WS 02/03 57
UML: Klassendiagramme
Klassendiagramme: weiterführende Konzepte
Assoziationsklassen können vermieden werden. Ihre Bedeutung ergibt sich gemäß dem folgenden Beispiel.
AbgeleiteteAssoziation
/Arbeitgeber
Beschäftigung
Periode:ZeitraumPerson
* *
1 * * 1Firma
Beförderung einer Assoziationsklasse zu einer vollen Klasse
Bei der Verwendung einer Assoziationsklasse gab es zwischen einer Person und einerFirma nur ein Beschäftigungsverhältnis, diese Restriktion ist durch die Verwendungder normalen Klasse aufgehoben.
05.12.2002 Modellierung WS 02/03 58
UML: Klassendiagramme
Klassendiagramme: weiterführende Konzepte
Frage: Ist die Restriktion sinnvoll?
Person
Beschäftigung
Periode:Zeitraum
* ArbeitgeberFirma
*
Annahme: eine Person verläßt eine Firmaund kehrt später wieder zurück. Also: zwischeneiner Person und einer Firma mehrere Objekteder Klasse Beschäftigung.
05.12.2002 Modellierung WS 02/03 59
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.
Eine typische Anwendung von Assoziationsklassen findet sich im EntwurfsmusterHistoric Mapping (vgl. Rolle Designer)
05.12.2002 Modellierung WS 02/03 60
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
Menge: Nummer0..1Bestellung ProduktEingangsnummer
Pro Produkt gibt es für eine Menge von Bestellungen einen Bestellungseingang.Produkt bündelt eine Menge von Bestellungen. Es qualifiziert alle Bestellungen, diezu einem Bestellungseingang gehören!
05.12.2002 Modellierung WS 02/03 61
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äftsprozessebezeichnet.
• Anwendungsfälle beschreiben für den Anwender sichtbare Funktionen.• Anwendungsfälle beschreiben die Erreichung eines für den Anwender
zusammenhängenden Ziels.
05.12.2002 Modellierung WS 02/03 62
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.
05.12.2002 Modellierung WS 02/03 63
UML: Anwendungsfalldiagramme
Notation für Anwendungsfälle
Anwendungsfall
Akteur 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/extends
uses- oder extends-Beziehungzwischen zwei AnwendungsfällenAF1 uses AF2
05.12.2002 Modellierung WS 02/03 64
UML: Anwendungsfalldiagramme
UML - Anwendungsfalldiagramme
Notation für Anwendungsfälle
Akteur 2Anwendungs-
fall 1
Anwendungs-fall 2
Anwendungs-fall 3
Diagrammname
Akteur 1
05.12.2002 Modellierung WS 02/03 65
UML: Anwendungsfalldiagramme
DefiniereProvision
Maklerkoordinator
BerateVersicherungs-
nehmer
ErmittlePartner
„uses“
IdentifiziereVersicherungs-
nehmer
Makler Mache Angebot
„extends“
AngestellterAußendienstmitarbeiter
MacheComposit-Angebot
Versicherungsnehmer
05.12.2002 Modellierung WS 02/03 66
UML: Anwendungsfalldiagramme
Mitverwend.Anwendungsf.
Erweiterung oder.Variante
„extends“Anwendungs-
fall
„uses“
Zeitschriftregistrieren
Mark. Art.registrieren
Umlaufzettelerstellen
Zeitschriftarchivieren
Zeitschriftenumlauf
1
2
3
4
Bibliothek
05.12.2002 Modellierung WS 02/03 67
UML: Anwendungsfalldiagramme
Strukturierte, textuelle Beschreibung einesAnwendungsfalls
Af.-Nr. Name des AnwendungsfallesVorbedingungen: ...Nachbedingungen: ...Nicht-funktionale Anforderungen: ...Beschreibung: ..Variationen: ...Regeln: ...Services: ...Ansprechpartner: ...Anmerkungen / offene Fragen: ...Dialogbeispiele oder - muster: ...Diagramme: ...
05.12.2002 Modellierung WS 02/03 68
UML: Anwendungsfalldiagramme
05.12.2002 Modellierung WS 02/03 69
UML: Anwendungsfalldiagramme
05.12.2002 Modellierung WS 02/03 70
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)
05.12.2002 Modellierung WS 02/03 71
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.
05.12.2002 Modellierung WS 02/03 72
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)
• 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).
05.12.2002 Modellierung WS 02/03 73
UML: Sequenzdiagramme
UML - Sequenzdiagramme (Weg-Zeit-Diagramme)Ein Bestellungs-eingabefenster Eine Bestellungr Eine interne
Bestellung Ein Artikel
prepare()* prepare ()
check()Object Condition
Iteration
Message
Ein neu zubestellener
Artikel
Ein Liefer-artikel
[check=„true“]remove()
needsToReorder()Self-Delegation
new
[check = „true“]new
Return
Creation
Zeit
Weg
05.12.2002 Modellierung WS 02/03 74
UML: Sequenzdiagramme
UML - SequenzdiagrammeParallele 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:
– 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.
05.12.2002 Modellierung WS 02/03 75
UML: Sequenzdiagramme
Beispiel Transaktionsbehandlung - Regelfall
ein Transaktions-koordinator
ein zweiter Trans-aktionsprüfer
neu
neu
neu
Aktivierung
allebeendet?
ok
Asynchrone Nachricht
eine Transaktion
ein erster Trans-aktionsprüfer
Andere Verarbeitungunterdrückt
allebeendet?gültig
okObjekt löscht sich
Selbstdelegation
05.12.2002 Modellierung WS 02/03 76
UML: Sequenzdiagramme
Beispiel Transaktionsbehandlung - Fehlerfall
Wenn eine Transaktionerzeugt wird...
...dann erzeugt sie ein ObjektTransaktionskoordinator, derdie Prüfungen überwacht.
Der Koordinator erzeugt eineReihe von Prüfern, einen proPrüfung. Diese Objekte arbeiten als getrennte Prozesse.
Wenn eine Prüfung nichterfolgreich ist, dann vernich-tet der Koordinator allenoch laufenden Prüfer.
...und teilt mit, daß dieTransaktion ungültig ist.
eine Transaktionneuein Transaktions-
koordinator
ein zweiter Trans-aktionsprüfer
löschen
neuein erster Trans-
aktionsprüferneu
neu
Versagen
ungültig Lösch-prüfer
ein anderesObjekt löschen
05.12.2002 Modellierung WS 02/03 77
UML: Kollaborationsdiagramme
UML - Kollaborationsdiagramme
• 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.
05.12.2002 Modellierung WS 02/03 78
UML: Kollaborationsdiagramme
Objekt: Bestellungs-eingabefenster
: Bestellung
Macallan: Bestellungseingang
: Lieferartikel
1: vorbereiten()
2*: vorbereiten()
7: [prüfen==true] neu
Selbstdelegation
ReihenfolgeNachricht
5: Bedürfnis anBesteller
Macallan Lager: Lieferartikel
3: prüfen()4: [prüfen==true] entfernen
: Lieferartikel
6: neu
05.12.2002 Modellierung WS 02/03 79
UML: Kollaborationsdiagramme
Kollaborationsdiagramm mit hierarchischer Numerierung (UML)
: Bestellungs-eingabefenster
: Bestellung
Macallan: Bestellungseingang
: Lieferartikel
Reihenfolge1: vorbereiten()
1.1.2.1: Bedürfnis anBesteller1.1*: vorbereiten()
1.1.3: [prüfen==true] neu
Macallan Lager: Lieferartikel
1.1.1: prüfen()1.1.2: [prüfen==true] entfernen
: Lieferartikel
1.1.2.2: neu
05.12.2002 Modellierung WS 02/03 80
UML
UMLZusammenfassung der bisherigen Diagramme
• Klassendiagramm (inkl. CRC-Karten) Statik
• Anwendungsfalldiagramm Dynamik (Benutzersicht)
• Interaktionsdiagramm Dynamik (Kooperation
Sequenzdiagramm von Objekten)
Kollaborationsdiagramm
05.12.2002 Modellierung WS 02/03 81
UML
UMLZusammenfassung der bisherigen Diagramme (2)
Und nun noch:
• Zustandsübergangsdiagramme Dynamik einzelner Objekteeinfacheparallele
• Aktivitätsdiagramm Abläufe / Anwendungsfälle und ihre Kooperation
• Komponentendiagramm Systemstrukturierung
05.12.2002 Modellierung WS 02/03 82
UML: Zustandsübergangsdiagramme
UML - Zustandsübergangsdiagramm
• 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.
05.12.2002 Modellierung WS 02/03 83
UML: Zustandsübergangsdiagramme
UML-Zustandsübergangsdiagramme(Notation)
Zustand
Zustandsübergang, der durch das Eintreten des Ereignisses ausgelöst wird (falls die Bedingung gilt!) und dabei die Aktion durchführt
Zustand, dessen Eintreten das Auslösen der Aktivität veranlaßt.
Ein Übergang ohne Ereignis tritt ein, sobald die Aktivität des Quellzustandes beendet ist.
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.
Ereignis [Bedingung] Aktion
Zustandtue / Aktivität
[Bedingung] Aktion
[Bed1]Zustand
[Bed3] [Bed2]
05.12.2002 Modellierung WS 02/03 84
UML: Zustandsübergangsdiagramme
UML-Zustandsübergangsdiagramme (2)(Notation)
ZustandEreignis / Aktion
Der Zustand reagiert auf das Ereignis mit einer Aktion(die nicht zu einem neuen Zustand führt).
Ein Zustand kann mit einer Eingangsaktion (entry) und einerAusgangsaktinon (exit) assoziiert sein.(alternative Darstellung: rein textuell)
Ein Selbstübergang dieser Art führt zur Ausführung von• exit• Aktion• entry
entry
Zustand
exit
Ereignis/Aktionentry
Zustand
exit
05.12.2002 Modellierung WS 02/03 85
UML: Zustandsübergangsdiagramme
UML - Zustandsübergangsdiagramm(Beispiel Bestellung)
Start/hole ersten Artikel
Prüfend
tue/prüfe Artikel
Auslieferung
tue/veranlasseLieferung
Hole nächsten Artikel[nicht alle Artikel geprüft]
[alle Artikel geprüft und verfügbar]
Geliefert
AktivitätArtikel erhalten
[alle Artikel verfügbar]
[Alle Artikel geprüft &&einige nicht im Lager] geliefert
Artikel erhalten[einige nicht im Lager]
Wartend
ZustandInterner Übergang
05.12.2002 Modellierung WS 02/03 86
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 Artikelngewartet, sonst passiert nichts !
05.12.2002 Modellierung WS 02/03 87
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.
Prüfend
tue/prüfe Artikel
Auslieferung
tue/veranlasseLieferung
Hole nächsten Artikel[nicht alle Artikel geprüft]
[alle Artikel geprüft und verfügbar]
GeliefertWartendabweisen
abweisen
[Artikel erhalten &&alle Artikel vorrätig]
[Alle Artikel geprüft &&einige nicht im Lager] geliefert
Artikel erhalten[einige nicht im Lager]
abweisen Abgewiesen
05.12.2002 Modellierung WS 02/03 88
UML: Zustandsübergangsdiagramme
Alternative Strukturierung durch Oberzustände(Superstates)
Prüfend
tue/prüfe Artikel
Auslieferung
tue/veranlasseLieferung
Wartend
Artikel erhalten[einige nicht im Lager]
[Alle Artikel geprüft &&einige nicht im Lager]
Hole nächsten Artikel[nicht alle Artikel geprüft]
geliefertArtikel erhalten
[alle Artikel verfügbar]
[alle Artikel geprüft und verfügbar]
aktiv
abweisenGeliefertAbgewiesen
Hinweis: es bleibt auf dieser Ebene unspezifiziert, wann (von welchem Zustand kommend) der Zustand „abgewiesen“ eintritt!
05.12.2002 Modellierung WS 02/03 89
UML: Zustandsübergangsdiagramme
Zustandsübergangsdiagramme(ein zweites Beispiel)
Prüfend
tue/prüfe Zahlung
[Zahlung nicht OK]
geprüft
geliefert
[Zahlung OK]
abgewiesen
05.12.2002 Modellierung WS 02/03 90
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 parallelenZustandsübergangsdiagrammen.
prüfend(Bestellung)
prüfend(Zahlung)
wartend
geprüft
veranlasseLieferung
Ende
abgewiesen(Bestellung)
abgewiesen
geliefert
abgewiesen(Zahlung)
05.12.2002 Modellierung WS 02/03 91
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)
05.12.2002 Modellierung WS 02/03 92
UML: Zustandsübergangsdiagramme
UML - Zustandsübergangsdiagramme(Bewertung)
• Geeignet für die Beschreibung des Verhaltens eines Objektes übermehrere 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.
05.12.2002 Modellierung WS 02/03 93
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)
05.12.2002 Modellierung WS 02/03 94
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.
05.12.2002 Modellierung WS 02/03 95
UML: Aktivitätsdiagramme
UML - Aktivitätsdiagramm(Notation)
Synchronisation der Kontrolle (AND)mit Synchronisationsbedingung (Die Bedingung ist optional.)
Aufsplitten der Kontrolle (Zulassen von Parallelität)
Aktivität
Kontrollfluß
Aktivität2 wird nachAbschluß von Aktivität1gestartet.
Verzweigunsaktivität(kann auch durch normaleAktivität dargestellt werden)
Kontrollfluß, der unter derangegebenen Bedingunggewählt wird.
Aktivität
[Bedingung]
Aktivität1 Aktivität2
[Bedingung]
05.12.2002 Modellierung WS 02/03 96
UML: Aktivitätsdiagramme
UML-Aktivitätsdiagramm (Forts.)(Notation)
Aktivität Objekt[Zustand]
Aktivität wird durchgeführt,wenn über einen der eingehendenKontrollflüsse die Kontrolle ankommt(OR)
Start des Ablaufs und Identifikationder betroffenen Klasse
Ende des Ablaufs (optional)
Aktivität
Die Ausführung der Aktivität versetzt das Objekt inden angegebenen Zustand (optionales, seltenverwendetes Konstrukt in Aktivitätsdiagrammen).
Hinweis: fragwürdige Überlappung zu Zustands-übergangsdiagrammen !
Beispiel: aus dem Aktivitätsdiagramm wird eineBestellung in den Zustand „abgewiesen“ versetzt (wasbedeutet das,für das Zustandsübergangsdiagramm?)
Klasse
05.12.2002 Modellierung WS 02/03 97
UML: Aktivitätsdiagramme
UML - Aktivitätsdiagramm(Beispiel zur Spezifikation einer Operation)
FindeGetränk
Kaffee inFilter
Wassereinfüllen
Nehme Tassen
Nehme DoseCola
Filter inMaschine
Einschenken
[keine Cola]
[Kaffee gefunden]
Ende
[Cola gefunden]
Aktivität
[kein Kaffee]
Synchonisation
TrinkenKaffee kochenAnschalten
05.12.2002 Modellierung WS 02/03 98
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.
05.12.2002 Modellierung WS 02/03 99
UML: Aktivitätsdiagramme
UML - Aktivitätsdiagramm(Beispiel zur Spezifikation des Anwendungsfalles „Bestelleingang“)
Bestellung
Bestellungerhalten
PrüfeZahlung
Prüfe Verfügbarkeiteiner Bestellposition
Zuordnung zurBestellung
Nachbestellungs-artikelVeranlasse
Lieferung
[OK]
* Für jede Bestellposition
[verfügbar]
MehrfacherAuslöser
Bestellungabweisen
Synchronisations-bedingung
[nachzubestellen][Waren für alleBestellpositionenverfügbar undZahlung OK]
05.12.2002 Modellierung WS 02/03 100
UML: Aktivitätsdiagramme
UML - AktivitätsdiagrammeHinweis:
1.) hier wäre ein ausgezeichnetes Ende nicht sinnvoll, da esmehrere Enden gibt
2.) aus dem linken Zweig kann der rechte nicht angehalten werden! (bei strikter Sequentialiseirung ist dieses Problem vermeidbar,allerdings nur auf Kosten der Parallelität)
3.) Wenn die Bedingung am Ende von „prüfe Verfügbarkeit einerBestellposition“ nicht erfüllt ist, stoppt der Ablauf! Im günstigsten Fallwird eine ankommende Lieferung die weitere Auslieferung veran-lassen (Frage der Ausführungssemantik!)
Besser wäre eine Ergänzung zu folgendem Aktivitätsdiagramm:
05.12.2002 Modellierung WS 02/03 101
UML: Aktivitätsdiagramme
UML - Aktivitätsdiagramm(Beispiel zur Spezifikation des Anwendungsfalles „Bestelleingang“)
Bestellung
Bestellungerhalten
PrüfeZahlung
Prüfe Verfügbarkeiteiner Bestellposition
Zuordnung zurBestellung
VeranlasseLieferung
[OK]
* Für jede Bestellposition
[verfügbar]
Erhalte Lieferung
Identifiziere ausstehende,bestellte Artikel
Ordere ankommende Warenden Bestellungen zu
*Für jeden identifizierten,bestellten ArtikelBestellung
abweisen
Nachbestellungs-artikel[nachzubest.]
[Waren für alleBestellpositionenverfügbar undZahlung OK]
Alle offenenBestellungenberücksichtigt
Rest ins Lager
05.12.2002 Modellierung WS 02/03 102
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.
05.12.2002 Modellierung WS 02/03 103
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.
05.12.2002 Modellierung WS 02/03 104
UML: Aktivitätsdiagramme
UML-Aktivitätsdiagramm(Beispiel zur vertikalen Abgrenzung)
Bestellungerhalten
PrüfeZahlung
Prüfe Verfügbarkeiteiner Bestellposition
Bestellungabweisen Zuordnung zur
Bestellung[OK]
*
Für jede Bestell-position
[verfügbar]
Erhalte Lieferung
Identifiziere ausstehende,bestellte Artikel
Ordere ankommende Warenden Bestellungen zu
*Für jeden identifizierten,bestellten Artikel
Lager-ManagerFinanzen Bestellungsverarbeitung
[nicht OK] Waren-wirtschaft
Alle offenenBestellungenberücksichtigt
Nachbestellungs-artikel
VeranlasseLieferung
[Waren für alleBestellpositionenverfügbar undZahlung OK]
[nachzubest.]
Rest ins Lager
05.12.2002 Modellierung WS 02/03 105
UML: Aktivitätsdiagramme
UML-Aktivitätsdiagramm (Strukturierung)
BestimmeZahlungstyp
PrüfeScheck
PrüfeKreditkarte
Normaler Kunde?
Bestellwert> 1000 DM?
Vorkasseanfordern
Kreditwürdigkeitprüfen
EröffneKundenkonto
PrüfeZahlungsgeschichte
Scheck RechnungNicht OK
[nein]
[Ja]
[OK]
[nicht OK]
[nicht OK]
[nicht erhalten]
[OK]
[OK][OK]
Aktivitäten können verfeinert werden (passende Abstraktionsebenen fürunterschiedliche Zwecke)
Beispiel: Verfeinerung der Aktivität„prüfe Zahlung“
Nicht OK[nicht OK]
OK
05.12.2002 Modellierung WS 02/03 106
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
05.12.2002 Modellierung WS 02/03 107
UML: Komponentendiagramme
UML - Komponentendiagramme - Zwischen OOA und OOD
• 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.
05.12.2002 Modellierung WS 02/03 108
UML: Komponentendiagramme
Komponentendiagramme - Zwischen OOA und OO
Behandlung vonBestellungen
UI
AWTMailingliste
UI
Behandlung vonBestellungen
Anwendung
Mailingliste
Anwendung
Bestellungen Kunden
PaketAbhängigkeit
Im kleinen Rechtecklinks oben, kann dann derKomponentenname auftauchen,wenn die internen Klasseninnerhalb des Komponentenrechtecksangezeigt werden sollen.
05.12.2002 Modellierung WS 02/03 109
UML: Metamodell
UML- Methodik1 Von den Anforderungen zu Klassendiagrammen
und dann über Use Case Diagrammen zu Interaktionsdiagrammen zu Zustandsübergangsdiagrammenparallel Übergang zu OOD mit Hilfe von KomponentendiagrammenAktivitätsdiagramme nahezu beliebig zur Ablaufveranschaulichung
oder
2 Von den Anforderungen zu Use Case Diagrammenund dann Aktivitätsdiagrammen zur Detailbeschreibung von Use Casesund dann über Klassendiagramme zu Interaktionsdigrammenund dann zu Zustandsübergangsdiagrammenparallel Übergang zu OOD mit Hilfe von Komponentendiagrammen
Beide Ansätze nur als grobe Richtlinien, nicht als Dogmen!