Unified Modeling Language (UML)

Transcription

15.
Überblick und Wiederholung UML
Unified Modeling Language (UML)
Unified Modeling Language ursprünglich entwickelt von
• Grady Booch,
• James Rumbaugh und
• Ivar Jacobson
(3 Amigos).
Graphische Sprache, um Artifakte von Software-Systemen zu
• visualisieren,
• spezifizieren,
• konstruieren und
• dokumentieren.
Dokumentation der „Baupläne“ eines Software Projektes.
UML 1.0 wurde 1997 der Object Management Group (OMG) zur
Standardisierung angeboten.
Im September 1997 angenommen.
Pflege der UML durch die OMG Revision Task Force (RTF).
Im Herbst 1998 wurde UML 1.3 freigegeben.
- 393
© Prof. Dr. B. Dreher, FB Informatik
FH Wiesbaden – University of Applied Sciences
-
Spez. Methoden der Softwaretechnik: Software-Komponenten, SS 1999
15.
15.1
Entwicklungsprozeß
Entwicklungsprozeß
• UML ist Modellierungssprache, keine Methode.
• Enthält keine Prozeßbeschreibung, die wichtigen Teil einer Methode
ausmacht.
• UML ist unabhängig von dem verwendeten Prozeß.
• Lösung der 3 Amigos: Rational Objectory Process.
- Eher ein Prozeßrahmenwerk (Process Framework) mit Spielräumen zur Anpassung.
• Iterativer und inkrementeller Entwicklungsprozeß.
• Software wird in Teilen entwickelt und freigegeben.
• Insbesondere die Konstruktionsphase besteht aus vielen Iterationen,
- wobei bei jeder Iteration real nutzbare Software erstellt, getestet
und integriert wird (Teilmenge der Anforderungen des Projektes).
Einstieg
(Inception)
Konstruktion
(Construction)
Ausarbeitung
(Elaboration)
1
2
3
Überleitung
(Transition)
...
Jede Iteration besteht aus den üblichen Phasen Analye, Entwurf,
Implementierung und Test.
- 394
-
15.
15.1
Entwicklungsprozeß
Zwei Vorphasen
Einstieg
• Begründung der geschäftlichen Absichten des Projektes
(Kosten/Nutzen).
• Anwendungsdomäne kennenlernen.
• Abgrenzung.
• O.K. des Managements weiterzumachen.
• „Machbarkeitsstudie“
- 395
-
15.
15.1
Entwicklungsprozeß
Zwei Vorphasen
Ausarbeitung
• Sammeln detaillierter Anforderungen.
• Analyse und Entwurf auf hohem Abstraktionsgrad: Grundlegende
Architektur, Plan für die Konstruktion.
• Welche Technologien sollen eingesetzt werden?
• Welche Risiken sind vorhanden?
• Vorgehensweise:
- Anwendungsfälle entdecken
- Gerüst eines konzeptionellen Modells des Problembereichs:
Grundlage für Objektmodell -> Problembereichsmodell
- Entwurfsmodell: Klassen zur Übernahme der Aufgaben. Wiederverwendbare Architektur für künftige Erweiterungen.
• Nicht alle Anwendungsfälle auf einmal.
- Zunächst nur zentrale Anwendungsfälle und zentrale Klassen des
Problembereichs.
- Weitere Anwendungsfälle können inkrementell hinzugefügt werden.
• Wichtige UML-Techniken neben Anwendungsfällen hierbei
(Problembereichsmodell):
- Klassendiagramme,
- Aktivitätsdiagramme (Arbeitsabläufe, workflows),
- Interaktionsdiagramme (später nützlicher).
- 396
-
15.
15.1
Entwicklungsprozeß
Eine nachgeschaltete Phase
Überleitung
• Betatests,
• Performance-Verbesserungen,
• Benutzertraining.
Im Prinzip Iterationen auch in den anderen Phasen (neben
Konstruktion).
- 397
-
15.
15.1
Entwicklungsprozeß
Konstruktion
Einstieg
(Inception)
Konstruktion
(Construction)
Ausarbeitung
(Elaboration)
1
2
3
Überleitung
(Transition)
...
• Erstellung des Systems in einer Folge von Iterationen.
- Jeweils ein eigenes Miniprojekt.
• Analyse, Entwurf, Programmierung, Test und Integration
- für jeden Anwendungsfall, der der Iteration zugewiesen ist.
- Ziel: Risikoverminderung.
- Ständiges Testen und Integrieren.
• Vorgang ist sowohl inkrementell als auch iterativ:
- Inkrementell bezüglich Funktionalität.
- Jede Iteration baut auf Anwendungsfällen der vorigen Iteration
auf.
- Iterativ bezüglich der Codebasis.
- Jede Iteration wird ein Umschreiben eines Teils des existierenden Codes zur Folge haben (Umstrukturierung, refactoring).
- Reduktion der „Softwareentropie“.
- Gleiche Funktionalität bei geänderter innerer Struktur (Umbenennung einer Methode, Verschieben von Attributen in andere
Klasse, Zusammenführung gleichartiger Methoden zweier Klassen
in Superklasse).
- 398
-
15.
15.1
Entwicklungsprozeß
Konstruktion
• Alle UML-Techniken sind in der Konstruktion wichtig und nützlich:
- Anwendungsfälle (auch Abgrenzung des Arbeitsgebietes)
- Konzeptionelles Klassenmodell (Vorbereitung einiger Konzepte für
den Anwendungsfall)
- Aktivitätsdiagramm, falls Anwendungsfall bedeutende Arbeitsablaufelemente enthält
• Dies zusammen mit Experten der Anwendungsdomäne.
• Übergang zum Entwurf:
- Detaillierte Ausarbeitung der Klassendiagramme
- Interaktionsdiagramme (Sequenz- und Kollaborationsdiagramme)
zum Zusammenspiel der Klassen zur Implementierung des Anwendungsfalls
- Klassenkarten (CRC cards): Verantwortlichkeiten der Klassen
• Nicht unbedingt detaillierte Diagramme für das ganze Systems. Nur
dort, wo es auch etwas bringt.
• Weiterhin:
- Paketdiagramme als logischer Plan des Systems.
- Für jedes Paket ein spezifikationsorientiertes Klassendiagramm
(Assoziationen, nur die wichtigen Attribute und Methoden)
-> Graphisches Inhaltsverzeichnis
- Zustandsdiagramme, falls Klasse komplexes Verhalten während
ihres Lebenszyklus hat. Selten notwendig.
- Eher Interaktionsdiagramme
- Einsatz von Entwurfsmustern (Design Patterns)
Martin Fowler, Kendall Scott:
„Iterative Entwicklung nur für Projekte einsetzen, von denen man will,
daß sie erfolgreich ablaufen“.
- 399
-
15.
15.2
Anwendungsfälle
Anwendungsfälle
Use Cases.
• Typische Interaktion zwischen einem Benutzer und einem
Computersystem:
- Eine dem Benutzer sichtbare Funktion
- Kann klein und groß sein
- Benutzer erreicht ein abgrenzbares Ziel
• Zunächst: Name und einige Absätze beschreibender Text.
• Anwendungsfälle werden häufig erst in ihrer Iteration detailliert.
• Graphische Darstellung: Anwendungsfalldiagramme (use case
diagrams).
• Beispiel: Anwendungsfälle eines Finanzhandelsplatzes:
Aktualisiere
Konten
Setze Grenze
Analysiere Risiko
<<include>>
Bewertung
Manager
Buchhaltungssystem
<<include>>
Preis für Handel
bestimmen
Handel
festmachen
Händler
Verkäufer
<<extend>>
Grenze
überschritten
- 400
-
15.
15.2
Anwendungsfälle
Akteur (actor)
• Vom Anwender in Bezug auf das System eingenommene Rolle.
- Ein Anwender kann mehrere Rollen einnehmen.
• Akteure führen Anwendungsfälle durch.
- Ein Akteur kann mehrere Anwendungsfälle ausführen.
- Ein Anwendungsfall kann von mehreren Akteuren ausgeführt
werden.
• Ein Akteur kann auch ein externes System sein.
• Hauptfokus sollte darauf liegen, die Anwendungsfälle zu erhalten,
nicht so sehr auf den Varianten der Akteure.
Beziehungen
Zwei Verbindungstypen zwischen den Anwendungsfällen:
• Extend (früher extends):
- Seltene Variation des erweiterten Anwendungsfalles.
- Sonderfall, Fehlerbehandlung.
- Dadurch wird der eigentliche Anwendungsfall nicht durch Spezialfälle überfrachtet.
- Eingefügt an extension points.
- Beschrieben im extending use case.
• Include (früher uses):
- Gleicher Verhaltensteil in mehreren Anwendungsfällen.
- Wird ausfaktorisiert (factoring out).
In UML 1.3 gibt es Generalisierung/Spezialisierung von
Anwendungsfällen
- 401
-
15.
15.3
Klassendiagramme
Klassendiagramme
• Erstellung von Klassendiagrammen ist zentrale Technik innerhalb
aller objektorientierten Methoden.
• Zwei Arten statischer Beziehungen zwischen Klassen:
- Assoziationen
- Untertypen (Generalisierung/Spezialisierung)
• Klassendiagramme zeigen auch
- Attribute und
- Operationen/Methoden der Klassen sowie
- die Bedingungen der Verbindung ihrer Objekte.
Assoziationen
Auftrag
empfangsDatum
istVorausBezahlt
anzahl: String
preis: Geld
ausführen()
abschliessen()
1
Kunde
*
1
{ wenn Auftrag.kunde.
kreditWürdigkeit() ==
"gering" dann muß
Auftrag.istVorausBezahlt
true sein }
name
adresse
kreditWürdigkeit(): String
*
Auftragsposition
menge: Integer
preis: Geld
istGeliefert:
Boolean
*
Positionen
1
Produkt
Firmenkunde
unternehmensName
kreditWürdigkeit
kreditLimit
kreditkartenNr
erinnern()
forderungenImMonat(Integer)
Verkäufer
*
0..1
{ kreditWürdigkeit() ==
"gering" }
Angestellter
- 402
Privatkunde
-
15.
15.3
Klassendiagramme
Rolle
• Entweder besonderer Bezeichner bei der Klasse, die für die Klasse
der anderen Seite diese Rolle spielt.
- Ohne besonderen Bezeichner: Name der Klasse ist auch Rollenbezeichner.
• Eine Rolle besitzt eine Kardinalität:
- Wieviele Objekte sind an der Beziehung beteiligt?
- „*“ bedeutet 0 bis viele.
• Aus den Beziehungen können Methoden abgeleitet werden, die den
Zugriff auf die verbundenen Klasse ermöglichen.
• Bei mehrwertigen Beziehungen sind Container und Iteratoren
einzusetzen.
Beispiel
class Auftrag {
private Kunde kunde;
private Vector auftragsPositionen;
...
}
class Kunde {
private Vector auftraege;
...
}
- 403
-
15.
15.3
Klassendiagramme
Assoziationen
Navigierbarkeit
• Durch zusätzliche Pfeile kann die Navigierbarkeit angezeigt werden:
Auftrag
empfangsDatum
istVorausBezahlt
anzahl: String
preis: Geld
ausführen()
abschliessen()
1
Kunde
*
1
{ wenn Auftrag.kunde.
kreditWürdigkeit() ==
"gering" dann muß
Auftrag.istVorausBezahlt
true sein }
name
adresse
*
Auftragsposition
menge: Integer
preis: Geld
istGeliefert:
Boolean
*
Positionen
Firmenkunde
Privatkunde
unternehmensName
kreditWürdigkeit
kreditLimit
kreditkartenNr
erinnern()
forderungenImMonat(Integer)
1
Produkt
Verkäufer
*
0..1
{ kreditWürdigkeit() ==
"gering" }
Angestellter
• Assoziationen können zusätzlich – meist durch ein Verb – benannt
werden.
• Für die Rollenbezeichnung verwendet man Substantive.
- 404
-
15.
15.3
Klassendiagramme
Attribute
Volle Spezifikation:
Sichtbarkeit Name: Typ = Defaultwert {Property-String}
Sichtbarkeiten:
Public
+
Protected
#
Private
Properties:
{changeable}
{addOnly}
{frozen}
Voreinstellung
Bei Feldern o.ä. kann Element hinzugefügt werden,
aber nie eines wieder entfernt werden
const Attribut
Assoziationen implizieren für die Navigierbarkeit Attribute.
- 405
-
15.
15.3
Klassendiagramme
Operationen
• Prozesse, die eine Klasse ausführen kann.
• Korrespondieren mit den Methoden der Klasse.
• Triviale Methoden (get- und set-Methoden für Attribute) werden
üblicherweise nicht dargestellt.
Spezifikation:
Sichtbarkeit Name (Parameterliste) : Rückgabetyp { Property-String }
Jeder Parameter in der Parameterliste hat die folgende Struktur:
Richtung Name : Typ = Defaultwert
Richtung steht für die Möglichkeiten
in
out
inout
Vordefinierte Properties:
{isQuery}
Zustand des Objektes bleibt unverändert
{sequential}
Nutzer müssen sicherstellen, daß ein Objekt über
diese Operation nur einmal zu einer Zeit
angesprochen wird
{guarded}
Alle Aufrufe werden serialisiert
{concurrent} Operation wird als atomar angesehen (synchronized
in Java)
Lange Listen von Operationen können durch Stereotypen klassifiziert
werden:
«constructor»
«process»
«query»
«modifier»
«helper»
- 406
-
15.
15.3
Klassendiagramme
Bedingungsregeln
Engl.: constraints
Strikte Syntax in UML:
Eingebettet zwischen geschweifte Klammern: { ... }.
Corporation
Bank Account
{ or }
Person
gender : {female, male}
0..1
wife
0..1
husband
{ self.wife.gender = female and
self.husband.gender = male }
Hier wird UML's Object Constaint Language (OCL) verwendet.
- 407
-
15.
15.3
Klassendiagramme
Stereotypen
• Weitere Klassifizierung von Klassen.
- Z.B. Entity-, Control-, Interface-Klassen bei Ivar Jacobson (hier
jedoch eigene graphische Darstellung) oder
- im MVC-Konzept.
• Bedeutet auch eine bestimmte Verantwortlichkeitskategorie.
• Dient auch als allgemeiner Erweiterungsmechanismus der UML.
• Üblicherweise zwischen « ... » dargestellt ( «Entity» ).
- 408
-
15.
15.3
Klassendiagramme
Aggregation und Komposition
Aggregation
• Unterschied zwischen Assoziation und Aggregation wird von
verschiedenen Autoren nicht einheitlich definiert.
• Ist die Assoziation zwischen Firma und ihren Angestellten eine
Aggregation?
- Peter Coad: ja,
- Jim Rumbaugh: nein.
• Aggregation ist eine
- konzeptionelle Ganzes-Teil Beziehung
- ohne konkrete Auswirkungen auf
- die Navigierbarkeit zwischen den beteiligten Klassen und
- deren Existenzabhängigkeiten.
- 409
-
15.
15.3
Klassendiagramme
Aggregation und Komposition
Komposition
• Bei der Komposition ist das anders. Hier kommt zusätzliche
Semantik ins Spiel.
- Das Ganze ist Eigentümer seiner Teile.
- Soweit Teile flexible Multiplizitäten haben können sie zwar dem
Ganzen hinzugefügt und wieder entnommen werden.
- Sie leben und sterben jedoch mit dem Ganzen zusammen.
• Ein Teil einer Komposition kann immer nur Teil eines Ganzen sein.
• Bei einer normalen Aggregation kann ein Teil Bestandteil mehrerer
Aggregate sein.
• Bei der Komposition muß das Ganze auch die Erzeugung und
Vernichtung seiner Teile verantwortlich übernehmen.
Beispiel für eine Komposition:
Window
*
Frame
Die Teile einer Komposition ähneln Attributen. Sie sind feste
Bestandteile der Ganzes-Klasse.
- 410
-
15.
15.3
Klassendiagramme
Abhängigkeit
Engl.: dependency
• Abhängigkeit von einer anderen Klasse.
- Diese kommt etwa als Typ in der Parameterversorgung einer
Methode vor.
• Bedeutet, daß eine Änderung in der Spezifikation einer Sache
(Event) Auswirkungen auf eine andere Sache (Window) hat, die die
erste Sache verwendet.
Window
open()
close()
move()
display()
handleEvent()
Event
• Die Klasse Window benutzt die Klasse Event,
- jedoch nicht im Sinne einer Assoziation, sondern
- nur im Sinne der Verwendung der Spezifikation.
• Auch die friend-Beziehung von C++ kann als Abhängigkeit
modelliert werden:
CourseSchedule
Course
add(c: Course)
remove(c: Course)
<<friend>>
Iterator
- 411
-
15.
15.3
Klassendiagramme
Abstrakte Klassen und Schnittstellen
Abstrakte Klassen
WindowsFenster
Fenster
TextEditor
nachVorne()
nachHinten()
nachVorne()
nachHinten()
X11Fenster
nachVorne()
nachHinten()
MacFenster
nachVorne()
nachHinten()
• Darstellung durch
- Kursivschrift oder
- Constraint: {abstract}.
• Gilt für Klassen und Methoden.
- 412
-
15.
15.3
Klassendiagramme
Abstrakte Klassen und Schnittstellen
Schnittstellen
• Sei InputStream eine abstrakte Klasse,
• DataInput ein Interface.
• DataInputStream ist konkreter Nachfahre von InputStream und
implementiert zusätzlich DataInput.
• Die Klasse OrderReader verwendet an einigen Stellen die
Schnittstelle DataInput und ist daher davon abhängig.
InputStream
{abstract}
<<interface>>
DataInput
OrderReader
DataInputStream
Andere Darstellung von Schnittstellen:
DataInput
OrderReader
DataInputStream
InputStream
• Hier keine Unterscheidung in der Darstellung zwischen Schnittstelle
und abstrakter Klasse.
- 413
-
15.
15.3
Klassendiagramme
Sammlungen mehrwertiger Rollen
multi-valued roles
Rolle, deren obere Schranke der Kardinalität größer als 1 ist (z.B. *).
Window
*
Subwindow
Wird üblicherweise als Menge angesehen.
- Keine besondere Anordnung der Zielobjekte.
- Kein Zielobjekt tritt mehrfach auf.
- 414
-
15.
15.3
Klassendiagramme
Sammlungen mehrwertiger Rollen
Dies kann verändert werden durch Angabe von constraints.
Window
{ordered}
*
Subwindow
Mögliche Angaben:
{ordered}
Bestimmte Anordnung, jedes Objekt nur einmal
{bag}
Keine Anordnung, Objekte können mehrfach
vorkommen
{ordered bag} Bestimmte Anordnung, Objekte können mehrfach
vorkommen
Weitere Möglichkeiten:
{hierarchy}
{dag}
Zielobjekte bilden Hierarchie
Zielobjekte bilden gerichteten azyklischen Graphen
(directed acyclic graph)
- 415
-
15.
15.3
Klassendiagramme
Qualifizierte Assoziationen
UML-Äquivalent des Programmierkonzeptes Assoziatives Feld
(associative array), Abbildung (map) und Dictionary.
Auftragsposition
0..1
Auftrag
menge: int
Produkt
Aussage:
- Für jeden Wert von Produkt kann es eine Auftragsposition geben.
- In einem Auftrag kann man nicht zwei Auftragspositionen für
dasselbe Produkt haben.
• Produkt dient als Index zum Zugriff auf die zugehörige
Auftragsposition.
• Kardinalität wird durch Qualifizierung reduziert.
- 416
-
15.
15.3
Klassendiagramme
Assoziationsklassen
Eine Assoziation zwischen zwei Klassen kann selbst Eigenschaften
besitzen.
Dies können Attribute, aber auch Operationen ein.
arbeitgeber
Person
1..*
Firma
*
Anstellung
stellung
einstellDatum
zeitraum
gehalt
Zusätzliche Bedingung:
- Es kann nur eine Instanz der Assoziationsklasse zwischen zwei
teilnehmenden Objekten bestehen.
Nach obigem Diagramm dürfte eine Person nicht aus der Firma
ausscheiden und später nocheinmal eingestellt werden.
Dann müßte die Assoziationsklasse als reguläre Klasse implementiert
werden:
Anstellung
Person
1
*
stellung
einstellDatum
zeitraum
gehalt
- 417
1..*
1
Firma
-
15.
15.3
Klassendiagramme
Parametrisierbare Klassen
Engl.: templates
Typisch für C++. Nützlich für Container-Klassen.
T
Menge
einfuegen(e: T)
entfernen(e: T)
Verwenden von Template-Klassen als gebundenes Element (bound
element):
Menge <Angestellter>
Oder ausführlicher:
T
Menge
einfuegen(e: T)
entfernen(e: T)
Verfeinerung
<<bind>>
<Angestellter>
Parameterbindung
AngestelltenMenge
• Eigentlich nicht dasselbe wie Vererbung oder Implementierung einer
Schnittstelle.
- 418
-
15.
15.4
Interaktionsdiagramme
interaction diagrams
Mit welchem Verhalten arbeiten Gruppen von Objekten zusammen.
Ein Interaktionsdiagramm beschreibt üblicherweise das Verhalten
eines Anwendungsfalles.
Anzahl exemplarischer Objekte und die Nachrichten, die zwischen
diesen Objekten innerhalb des Anwendungsfalles ausgetauscht
werden.
Beispiel-Anwendungsfall:
• Auftragserfassungsfenster sendet nachricht bereiteVor an einen
Auftrag
• Auftrag sendet bereiteVor an jede Auftragsposition des Auftrags
• Jede Auftragsposition prüft den angegebenen Lagerartikel auf
Verfügbarkeit:
- Ist noch genügend am Lager, löscht Auftragsposition die entsprechende Menge von Lagerartikeln aus dem Lager.
- Sonst fordert Lagerartikel eine neue Lieferung an.
Zwei Arten von Interaktionsdiagrammen: Sequenz- und
Kollaborationsdiagramme.
- 419
-
15.
15.4
Sequenzdiagramme (1/3)
Unser Beispiel-Anwendungsfall:
af : Auftragserfassungsfenster
ap : Auftragsposition
a : Auftrag
bereiteVor()
lagArt : LagerArtikel
* [für alle Auftragspositionen]
bereiteVor()
vorhanden := prüfe()
Bedingung
Objekt
Selbstdelegation
[vorhanden]
entnehmen()
Nachricht
Iteration
nachzubestellen :=
nachbestellungNotwendig()
[nachzubestellen]
<<create>>
nb : NachbestellArtikel
[vorhanden] <<create>>
lf : LieferArtikel
Rückgabe
Erzeugung
• Vertikale Linien sind die Lebenslinien der Objekte.
- Solange lebt das Objekt.
- Zeit läuft von oben nach unten.
- Erstmals von Ivar Jacobson so verwendet.
• Nachricht durch Pfeil zwischen den Lebenslinien zweier Objekte.
- Reihenfolge der Nachrichten anhand der vertikalen Zeitachse gegeben.
- Kennzeichnung durch wenigstens den Namen der Nachricht.
- Weiterhin möglich: Parameter, Steuerinformation.
- 420
-
15.
15.4
a : Auftrag
bereiteVor()
bereiteVor()
Bedingung
Selbstdelegation
Objekt
[vorhanden]
entnehmen()
Nachricht
Iteration
nachzubestellen :=
[nachzubestellen]
<<create>>
lf : LieferArtikel
Rückgabe
Erzeugung
• Nachricht an eigenes Objekt (eigene Methode): Selbstdelegation.
• Steuerinformationen:
- Bedingung, daß Nachricht gesendet wird.
In eckigen Klammern.
Z.B. [nachzubestellen].
Bedingung muß wahr sein, damit Nachricht gesendet wird.
- Iterationsmarkierung: Nachricht wird mehrmals an verschiedene
Empfängerobjekte geschickt (z.B. an alle Objekte eines Containers).
Eingeleitet durch einen *
Beispiel: *[für alle Auftragspositionen].
- 421
-
15.
15.4
a : Auftrag
bereiteVor()
bereiteVor()
Bedingung
Selbstdelegation
Objekt
[vorhanden]
entnehmen()
Nachricht
Iteration
nachzubestellen :=
[nachzubestellen]
<<create>>
lf : LieferArtikel
Rückgabe
Erzeugung
• Rückgaben sind optional und meistens überflüssig, wenn man
Aktivierungen verwendet.
- Rückgaben sind keine neue Nachricht!
- Sollten eher vermieden werden.
• Aktivierungen (focus of control) stellen dar, wie lange die Methode,
die auf die Nachricht hin gestartet wird, aktiv ist.
- Ist in UML optional.
- Aber sehr empfehlenswert, da dadurch die Übersichtlichkeit extrem steigt.
- 422
-
15.
15.4
Nebenläufige Prozesse
Anwendungsfall:
• Neue Transaktion: Sie erzeugt einen Transaktionskoordinator, um
die Prüfung der Transaktion zu koordinieren.
• Koordinator erzeugt Anzahl von Transaktionsprüfobjekten (hier
zwei), die unabhängig voneinander verschiedene Aspekte prüfen
können. Sie werden asynchron aufgerufen und können ihre Arbeit
unabhängig voneinander durchführen.
• Ist einer der Transaktionsprüfer fertig, benachrichtigt er den
Transaktionskoordinator (synchron oder asynchron).
• Dieser schaut nach, ob sich schon alle Prüfer gemeldet haben.
• Ist dies geschehen und die Prüfungen waren erfolgreich, dann
benachrichtigt er die Transaktion, daß alles o.k. ist.
t : Transaktion
<<create>>
tk : Transaktionskoordinator
<<create>>
asynchrone
Nachricht
tp1 : Transaktionsprüfer1
<<create>>
ok
erledigt()
ok
erledigt()
istGültig
ggf. asynchron
Vernichtung
ggf. asynchron
- 423
-
15.
15.4
Nebenläufige Prozesse
Asynchrone Nachrichten können verschiedenes tun:
• Einen neuen Thread zur Abarbeitung der Nachricht erzeugen
• Ein neues Objekt erzeugen, das dann in einem separaten Thread
läuft
• Mit einem Thread kommunizieren, der bereits läuft.
Ein anderer Verlauf des Anwendungsfalles:
Wenn eine Transaktion erzeugt wird
...
... erzeugt sie einen
Koordinator zur
Verwaltung der
Prüfung
t : Transaktion
<<create>>
tk : Transaktionskoordinator
<<create>>
Dieser erzeugt eine
Folge von Prüfern.
Diese erledigen ihre
Aufgabe in separaten Prozessen.
<<create>>
nicht o.k.
Wenn eine Prüfung
nicht o.k. ist, sorgt
der Koordinator für
den Abbruch aller
anderen Prüfer, die
noch aktiv sind ...
abbrechen()
abbrechen
istUngültig
... und teilt der
Transaktion mit, daß
sie ungültig ist.
- 424
-
15.
15.4
Kollaborationsdiagramme
Hier steht nicht so sehr
- der zeitliche Ablauf der Kommunikation im Mittelpunkt,
- als vielmehr die Zusammenarbeit der Objekte,
also z.B. die Frage,
- welches Objekt ruft welches andere Objekt auf und wenn ja,
- welche seiner Methoden.
Unser Beispiel der Auftragserfassung:
Sequenznummer
1: bereiteVor()
5: nachzubestellen :=
a : Auftrag
2: * [für alle Auftragspositionen]
bereiteVor()
3: vorhanden := prüfe()
4: [vorhanden] entnehme()
7: [vorhanden] <<create>>
lagArt : Lagerartikel
6: [nachzubestellen] <<create>>
lf : Lieferartikel
nb : Nachbestellartikel
Sequenz- und Interaktionsdiagramme sind semantisch identisch.
Das eine Diagramm läßt sich in das andere überführen.
- 425
-
15.
15.5
Paketdiagramme
Paketdiagramme
Wie zerlegt man ein großes System in kleinere Einheiten?
• Funktionale Zerlegung aus der Zeit der strukturierten Analyse:
Anwendungsfälle tun das im wesentlichen.
• Objekte fassen Daten und Funktionen zusammen. Wie könnte man
Objekte zu größeren Einheiten zusammenfassen?
• Eine solche Gruppierungseinheit wird in der UML als Paket
(package) bezeichnet. Siehe auch packages von Java.
- Kriterien der Paketbildung: Abhängigkeiten.
• Darstellung in Paketdiagrammen (package diagrams).
- Streng genommen ist ein Paketdiagramm auch ein Klassendiagramm, nur auf abstrakterer Ebene.
• Eine Abhängigkeit (dependency) besteht zwischen zwei Elementen,
wenn eine Änderung an der Definition eines Elements eine
Änderung an der Definition des anderen Elements hervorrufen
würde.
• Abhängigkeiten:
- Eine Klasse sendet eine Nachricht an eine andere
- Eine Klasse hat eine andere Klasse als Teil ihrer Daten
- Eine Klasse erwähnt eine andere Klasse als Typ eines Operationenparameters.
• Wenn letztere Klasse die Schnittstelle ändert, dann muß auch die
erstere Klasse geändert werden. Nachrichten sind sonst nicht mehr
gültig.
- 426
-
15.
15.5
Paketdiagramme
Paketdiagramme
• Idealerweise dürfen nur Schnittstellenänderungen, nicht
Implementierungsänderungen, andere Klassen berühren.
• Kunst des Entwurfs großer Systeme: Abhängigkeiten minimieren.
Beispiel
Auftragserfassung UI
Adresskartei
UI
AWT
Auftragserfassungsanwendung
Adresskarteianwendung
Auftraege
Kunden
• Abhängigkeiten sind nicht transitiv:
- Wenn sich im Paket „Auftraege“ etwas ändert, muß das nicht die
Notwendigkeit einer Änderung am Paker „Auftragserfassungs UI“
zur Folge haben.
- Das Paket „Auftragserfassungsanwendung schirmt diese Änderung ab.
• Dies ist die Semantik des Java „import“-Verhaltens, jedoch nicht
des „include“-Verhaltens bei C++.
- 427
-
15.
15.5
Paketdiagramme
Paketdiagramme
• Pakete können andere Pakete enthalten.
- Es ist nicht klar, was dabei Abhängigkeit bedeutet: Auch zu den
Unterpaketen oder nur zu dem äußeren Paket?
- In einem konkreten Projekt sollte das zuvor festgelegt werden.
- Andere Möglichkeit: Stereotypen für Abhängigkeiten: «transparent» oder «opaque».
• Was sieht man von einem Paket, zu dem man eine Abhängigkeit
hat:
- Alle öffentlichen Klassen und deren öffentliche Methoden.
• In Java ist die Default-Sichtbarkeit „package“.
- Damit kann man Dinge im Package veröffentlichen, ohne daß sie
für andere Packages sichtbar sind.
- Bei C++ ist das nicht möglich.
• Reduktion der Kopplung nach draußen:
- Allen Klassen des Pakets nur „package“-Sichtbarkeit geben und
- zusätzlich öffentliche Fassaden-Klassen definieren (Facades Design Pattern).
- Öffentliche Methoden werden an Package-interne Methoden delegiert.
- 428
-
15.
15.5
Paketdiagramme
Paketdiagramme
Das obige Beispiel erweitert:
Auftragserfassung UI
Adresskartei
UI
AWT
Auftragserfassungsanwendung
Adresskarteianwendung
Problembereich
Auftraege
Gemeinsam
Kunden
OracleSchnittstelle
{global}
+ Menge
+ Geld
+ Datumsbereich
Datenbankschnittstelle
SybaseSchnittstelle
Neu:
- Übergeordnetes Paket „Problembereich“. Abhängigkeit kann zum
gesamten Paket oder nur zu einem Unterpaket bestehen.
- Globales Package: Abhängigkeit von allen Paketen
- Generalisierung
- 429
-
15.
15.5
Paketdiagramme
Paketdiagramme
• Generalisierung impliziert immer eine Abhängigkeit des Untertyps
von dem Obertyp. Diese wird nicht explizit dargestellt.
• Zyklen in den Abhängigkeiten sollten vermieden (wenigstens
minimiert) werden.
Einsatz von Paketdiagrammen
• Unerläßlich bei großen Projekten
• Wenn da Gesamtdiagramm nicht mehr auf einer DIN A4-Seite
darstellbar ist
• Kopplung zwischen Paketen sollte minimal sein
• Paket stellt Einheit zum Testen dar (Modultest)
- 430
-
15.
15.6
Zustandsdiagramme
Zustandsdiagramme
• Verbreitete Technik zum Beschreiben des dynamischen Verhaltens
von Systemen.
- Beschreiben Zustände, die ein bestimmtes Objekt annehmen
kann, und
- wie sich sein Zustand als Ergebnis von das Objekt erreichenden
Ereignissen verändert.
• Meistens für einzelne Klasse verwendet, wenn sie ein genügend
komplexes dynamisches Verhalten während ihrer Lebenszeit
besitzen.
• Die in der UML eingesetzten Zustandsdiagramme gehen zurück auf
die sog. Statecharts von David Harel (1987). Verwendet in OMT und
später auch von Booch.
Zustände eines Auftrags
H
/hole erste Auftragsposition
in Prüfung
hole nächste Auftragsposition
[noch Positionen ungeprüft]
[alle Positionen geprüft &&
alle Positionen verfügbar]
do/prüfe Position
einige Positionen nicht am Lager]
freigegeben
do/initiiere
Auslieferung
ausgeliefert
Position erhalten
[alle Positionen verfügbar]
Position erhalten
[einige Positionen nicht am Lager]
wartend
ausgeliefert
- 431
-
15.
15.6
Zustandsdiagramme
Zustandsdiagramme: Syntax
Syntax einer Transition:
Ereignis [Bedingung] /Aktion
Nach dem Start nur eine Aktion: /hole erste Auftragsposition.
Sobald diese Aktion ausgeführt ist, betreten wir den Zustand „in
Prüfung“. Mit diesem Zustand ist eine Aktivität verbunden.
Syntax:
do/ Aktivität
Unterschied Aktion und Aktivität:
• Aktion: Kurzzeitiger, nicht unterbrechbarer Prozeß
• Aktivität: Mit Zustand asoziiert, kann länger andauern. Kann durch
Ereignis unterbrochen werden.
Dennoch immer als Methoden realisiert.
Regeln:
• Enthält die Beschriftung einer Transition kein Ereignis, so tritt sie
ein, sobald jede mit dem Zustand assoziierte Aktivität beendet ist.
• Eine Transition kann eine Bedingung (guard) in eckigen Klammern
enthalten. Nur wenn sie wahr ist, findet der Übergang statt (die
Bedingung „bewacht“ den Übergang).
• Aus einem Zustand muß über die Bedingungen eindeutig genau ein
Übergang in den nächsten Zustand führen. Die Bedingungen
müssen entsprechend sein.
• Der Übergang von dem Zustand „freigegeben“ in den Zustand
„ausgeliefert“ findet nur statt, wenn da Ereignis ausgeliefert eintritt.
Sonst verharrt das Objekt im Zustand „freigegeben“.
- 432
-
15.
15.6
Zustandsdiagramme
Zustandsdiagramme: Unterbrechung
• Wir fügen eine Transition „abbrechen“ hinzu, die jederzeit durch das
Ereignis abgebrochen ausgelöst werden kann:
H
in Prüfung
do/prüfe Position
freigegeben
do/initiiere
Auslieferung
Position erhalten
Position erhalten
wartend
ausgeliefert
abgebrochen
abgebrochen
abgebrochen
abgebrochen
ausgeliefert
• Da dieser Übergang von 3 Zuständen gleichermaßen ausgehen
kann, ist es nützlich, diese in einem Oberzustand (superstate)
zusammenzufassen.
• Die verschachtelten Unterzustände (substates) erben jede Transition
des Oberzustandes.
- 433
-
15.
15.6
Zustandsdiagramme
Verschachtelet Zustandsdiagramme
H
Aktiv
in Prüfung
do/prüfe Position
freigegeben
do/initiiere
Auslieferung
Position erhalten
Position erhalten
ausgeliefert
wartend
abgebrochen
abgebrochen
ausgeliefert
- 434
-
15.
15.6
Zustandsdiagramme
Nebenläufige Zustandsdiagramme
Parallel zur Auftragsbearbeitung gibt es Zustände, die von der
Zahlungsautorisierung abhängen:
H
in Autorisierung
do/prüfe Zahlung
[Zahlung nicht OK]
[Zahlung OK]
autorisiert
abgelehnt
ausgeliefert
- 435
-
15.
15.6
Zustandsdiagramme
Nebenläufige Zustandsdiagramme
Die Zustände der beiden Diagramme können in einem nebenläufigen
Zustandsdiagramm (concurrent state diagram) kombiniert werden:
abgebrochen
abgebrochen
wartend
H
in Prüfung
freigegeben
H
ausgeliefert
H
H
in Autorisierung
autorisiert
H
abgelehnt
• Details der internen Zuständ wurden hier weggelassen.
• Ein Auftrag kann sich zu jeder Zeit gleichzeitig in zwei
verschiedenen Zuständen befinden, jeweils einer aus jedem Bereich.
• Verläßt der Auftrag die nebenläufigen Zustände, dann befindet er
sich nur noch in einem einzelnen Zustand.
- 436
-
15.
15.6
Zustandsdiagramme
Einsatz von Zustandsdiagrammen
• Verhalten eines Objektes über mehrere Anwendungsfälle hinweg.
- Nicht sehr gut bei Beschreibung der Wechselwirkung mehrerer
Objekte untereinander.
- Dazu sind besser Interaktionsdiagramme, aber auch Aktivitätsdiagramme geeignet.
• Oft werden in Standardsituationen Zustandsdiagramme nicht als
sehr nützlich angesehen.
• Anders ist es bei Realzeitanwendungen, wenn Objekte sehr
komplexe Zustände und Zustandsänderungen haben können.
- Z.B. wenn dieselbe Botschaft (d.h. derselbe Methodenaufruf) vom
Zustand des Objektes abhängige unterschiedlichen Reaktionen
hervorruft.
- 437
-
15.
15.7
Aktivitätsdiagramme
• Ein am wenigsten erwartetes Bestandteil der UML. Keine Wurzel in
den vorigen Arbeiten der Amigos.
• Das Aktivitätsdiagramm (activity diagram) kombiniert Ideen aus
mehreren Techniken:
- Ereignisdiagramme (event diagrams) von Jim Odell,
- Zustandsbasierte Modellierungstechnik SDL,
- Petri-Netze.
• Verwand mit (altmodischen) Flußdiagrammen.
• Nützlich auch für die Beschreibung von Geschäftsprozessen.
• Kann benutzt werden, um den Kontrollfluß in einer Methode zu
beschreiben, aber auch das dynamische Verhalten mehrerer
Objekte.
- 438
-
15.
15.7
• Zentrales Symbol ist die Aktivität (activity). Bedeutung abhängig von
Entwicklungsphase:
- Analyse:Aktivität von Mensch oder Maschine.
- Design/Implementierung: Methode einer Klasse.
• Eine Aktivität kann von einer anderen Aktivität gefolgt werden (wie
Flußdiagramm).
[kein Kaffee]
Bestimme
Getränk
H
[keine Cola]
[Kaffee gefunden]
[Cola gefunden]
Kaffeepulver in
Filter füllen
Behälter mit
Wasser füllen
Cola-Büchsen
holen
Tasse holen
Filter in Machine
einsetzen
Maschine
anschalten
Kaffee filtern
Kontroll-Lampe geht aus
Kaffee
einschenken
Getränk trinken
- 439
H
-
15.
15.7
• Unterschiede zu Flußdiagrammen:
- Es können mehrer Aktivitäten folgen, d.h. mehrere Trigger gehen
von einer Aktivität aus.
- Unterschieden durch Bedingungen (guard). Logischer Ausdruck
(wie in Zustandsdiagrammen).
- Aus einem Synchronisationsbalken (synchronization bar) können
mehrere Trigger herausführen (ohne Bedingungen).
- Die darauf folgenden Aktivitäten können parallel stattfinden.
- Kann nebenläufig oder verschränkt (interleaving) sein.
- Aktivitätsdiagramme sind zur Beschreibung nebenläufiger Prozesse gut geeignet. Modellierung von Geschäftsprozessen.
- Parallele Aktivitäten müssen bei der Zusammenführung wieder
synchronisiert werden.
- Alle Trigger müssen eingetreten sein, damit die dem Synchronisationsbalken folgende Aktivität angestoßen wird (UNDBedingung).
- Wenn mehrer Trigger in eine Aktivität münden („Getränk trinken“), entspricht das einer ODER-Bedingung.
- 440
-
15.
15.7
Aktivitätsdiagramme bei Anwendungsfällen
• Aktivitätsdiagramme sind zur Beschreibung komplizierter Methoden
gut geeignet.
• Sie können aber auch dazu eingesetzt werden, Anwemdungsfälle zu
beschreiben.
• Beispiel: Anwendungsfall Auftragseingang:
Bei Eintreffen eines Auftrags prüfen wir für jeden dort aufgeführten Artikel
dessen Verfügbarkeit im Lager.
Sind sie verfügbar, weisen wir diese diesem Auftrag zu.
Führt dies zu einer Lagermenge unter der Nachbestellmenge für diesen Artikel,
bestellen wir den Artikel nach.
Zeitgleich prüfen wir, ob die Zahlung (z.B. Kreditkartenzahlung) autorisiert
wird. Ist dieses OK und haben wir die Artikel im Lager, wird der Auftrag zur
Auslieferung freigegeben. Ist die Zahlung OK, Artikel aber nicht auf Lager,
lassen wir den Auftrag bei den offenen Aufträgen warten.
Ist die Zahlung nicht OK, weisen wir diesen Auftrag zurück.
Auftrag
annehmen
H
*[für jede Auftragsposition]
Auftrag
abweisen
[erfolglos]
Zahlung
autorisieren
Artikel dieser
Position prüfen
[erfolgreich]
[auf Lager]
dem Auftrag
zuweisen
[allen Auftragspositionen
Ware zugewiesen und
Zahlung autorisiert]
[Nachbestellung
nötig]
Auftrag
freigeben
Artikel
nachbestellen
- 441
-
15.
15.7
Aktivitätsdiagramme bei Anwendungsfällen
• Neues syntaktisches Element:
- Mehrfachtrigger (multiple trigger): * als Kardinalitätskennzeichen
(multiplicity marker).
• Jede dieser Aktivitäten kann parallel zu den anderen ablaufen!
• Alle parallelen Aktivitäten müsen wieder an einem
Synchronisationsbalken zusammenlaufen.
• Ein Synchronisationsbalken kann ebenfalls eine Bedingung haben.
- Diese wird bei jedem Eintreffen eines Triggers geprüft.
- Ein ausgehender Trigger findet nur statt, wenn die Bedingung
erfüllt ist.
• Ein Aktivitätsdiagramm muß nicht unbedingt ein definiertes Ende
haben.
- In dem Fall können auch einige „Ungereimtheiten“ verbleiben:
- Sackgassen wie „Artikel nachbestellen“.
- Oder eine Aktivität besitzt nur einen bedingungsbehafteten ausgehenden Trigger.
- Was passiert, wenn Bedingung nicht erfüllt ist? Nichts: Der
Thread stoppt an dieser Stelle.
- 442
-
15.
15.7
Anwendungsfall Wareneingang
Trifft Ware ein, betrachten wir die noch offenen Aufträge und entscheiden,
welche mit dieser Lieferung erfüllt werden können. Dann weisen wir die Waren
den einzelnen Aufträgen zu. Dies kann bei diesen zur Auslieferungsfreigabe
führen. Die verbleibenden Waren kommen ins Lager.
H
Ware annehmen
Offene Auftragspositionen
auswählen
*[für jede ausgewählte Auftragsposition]
Ware dem
Auftrag
zuweisen
Ware zugewiesen und
[alle offenen Auftragspositionen abgedeckt]
Rest zum
Lagerbestand
hinzufügen
Auftrag
freigeben
• Beide Anwendungsfälle sind miteinander gekoppelt.
- 443
-
15.
15.7
Gekoppelte Anwendungsfälle
• In einem kombinierten Diagramm kann man die beiden
Aktivitätsdiagramme überlagern.
- Man sieht, wie Aktionen in einem Anwendungsfall Aktionen eines
anderen Anwendungsfalles beeinflussen.
- Ein solches Aktivitätsdiagramm besitzt mehrer Startpunkte.
H
Auftrag
annehmen
H
Ware annehmen
auswählen
[erfolglos]
Auftrag
abweisen
Zahlung
autorisieren
Artikel dieser
Position prüfen
*[für jede ausgewählte
Auftragsposition]
[erfolgreich]
[auf Lager]
Ware dem
Auftrag
zuweisen
dem Auftrag
zuweisen
[Nachbestellung
nötig]
Artikel
nachbestellen
Ware zugewiesen und
Rest zum
Lagerbestand
hinzufügen
Auftrag
freigeben
- 444
-
15.
15.7
Verantwortlichkeitsgrenzen
• Aktivitätsdiagramme beschreiben nur was passiert (funktionale
Zerlegung), nicht wer dafür verantwortlich ist (es zu tun).
• Dazu dient die Einführung von Verantwortlichkeitsgrenzen (im
Original: swimlanes).
- Jeder Bereich repräsentiert die Verantwortlichkeit einer Klasse
oder – bei reinen Geschäftsprozessen – einer bestimmten Abteilung.
H
Rechnungswesen
H
Auftragsbearbeitung
Auftrag
annehmen
Ware annehmen
auswählen
Zahlung
autorisieren
[erfolgreich]
[erfolglos]
Artikel dieser
Position prüfen
Auftrag
abweisen
*[für jede ausgewählte
Auftragsposition]
[auf Lager]
dem Auftrag
zuweisen
Lagerverwalter
Ware dem
Auftrag
zuweisen
[Nachbestellung
nötig]
Artikel
nachbestellen
Ware zugewiesen und
Rest zum
Lagerbestand
hinzufügen
Auftrag
freigeben
- 445
-
15.
15.7
Einsatz von Aktivitätsdiagrammen
• Wie alle Techniken zur Verhaltensmodellierung haben auch
Aktivitätsdiagramme konkrete Stärken und schwächen.
- Man verwendet Sie am besten in Kombination mit anderen Techniken.
• Stärke:
- Modellierung von nebenläufigen Verhalten.
- Daher auch gut zum Modellieren von Geschäftsabläufen geeignet.
• Nachteil:
- Keine Verbindung zwischen Aktivitäten und Klassen.
• Man kann Aktivitäten mit dem zuständigen Objektnamen
beschriften oder swimlanes benutzen.
• Interaktionsdiagramme sind hierbei objektorientierter.
- 446
-

Unified Modeling Language (UML)

Transcription

Documents pareils

Gutenbergschule Wiesbaden G y m n a s i u m

Ramírez: Misa Criolla Theodorakis: Canto General

Externer Brief

Formular PDF

SHAKESPEARE-TAG 2016 - Wiesbadener Casino

Die Ausbildung Zugangsvoraussetzungen

Die 10 Dreher-Punkte - Dreher Hausverwaltungen GmbH

CADscout für MicroStation V8 - Corporate Montage Europe GmbH

Immobilien-Exposé