In den meisten Fällen werden Ablaufdiagramme zur Veranschaulichung von Anwendungsfallrealisierungen verwendet (siehe Arbeitsergebnis: Anwendungsfallrealisierungen), d. h. um zu zeigen,
wie Objekte miteinander interagieren, um das Verhalten eines Anwendungsfalls teilweise oder vollständig zu erbringen.
Die Objektinteraktionen, die einen Anwendungsfall umsetzen, können in einem oder mehreren Ablaufdiagrammen dargestellt
werden. Gewöhnlich werden ein Ablaufdiagramm für den Hauptereignisablauf und ein Ablaufdiagramm für jeden unabhängigen
untergeordneten Ablauf des Anwendungsfalls verwendet.
Ablaufdiagramme sind besonders wichtig für Designer, da sie die Rollen der Objekte in einem Ablauf klar herausstellen
und damit die Grundlage für die Bestimmung von Klassenzuständigkeiten und Schnittstellen bilden.
Anders als ein Kommunikationsdiagramm enthält ein Ablaufdiagramm chronologische Abläufe, aber keine Objektbeziehungen.
Ablaufdiagramme und Kommunikationsdiagramm veranschaulichen ähnliche Informationen, aber in unterschiedlicher
Darstellungsart. Ablaufdiagramme zeigen die explizite Abfolge von Nachrichten an und eignen sich besser, wenn die
zeitliche Abfolge der Nachrichten visualisiert werden muss. Wenn Sie an den strukturellen Beziehungen zwischen den
Instanzen einer Interaktion interessiert sind, verwenden Sie ein Kommunikationsdiagramm. Weitere Informationen finden
Sie in Technik:
Kommunikationsdiagramm.
In Ablaufdiagrammen können Objekte und Akteurinstanzen zusammen mit Nachrichten angezeigt werden, die die Interaktionen
zwischen den Objekten und Instanzen verdeutlichen. Das Diagramm veranschaulicht die in den teilnehmenden Objekten
stattfindenden Aktionen anhand von Aktivierungen und Nachrichten, die die Objekte einander senden, um miteinander zu
kommunizieren. Sie können für jede Variante eines Ereignisablaufs in einem Anwendungsfall ein Kommunikationsdiagramm
erstellen.
Ein Ablaufdiagramm, das einen Teil des Ereignisablaufs des Anwendungsfalls Ortsgespräch führen in einem
einfachen Telefonsystem beschreibt.
Ein Objekt wird als vertikale gestrichelte Linie, genannt "Lebenslinie", gezeigt. Die Lebenslinie stellt die Existenz
des Objekts zu einer bestimmten Zeit dar. Ein Objektsymbol wird am Kopf der Lebenslinie gezeichnet und zeigt den Namen
des Objekts und seine Klasse (unterstrichen), getrennt durch einen Doppelpunkt, an:
Objektname : Klassenname
Sie können Objekte in Ablaufdiagrammen wie folgt verwenden:
-
Eine Lebenslinie kann ein Objekt oder seine Klasse darstellen. Somit können Sie eine Lebenslinie verwenden, um
Klassen- und Objektverhalten zu modellieren. Gewöhnlich stellt eine Lebenslinie jedoch alle Objekte einer
bestimmten Klasse dar.
-
Die Klasse eines Objekts kann unspezifiziert bleiben. Normalerweise erstellen Sie ein Ablaufdiagramm zuerst mit
Objekten und geben die zugehörigen Klassen später an.
-
Die Objekte können unbenannt bleiben. Sie sollten die Objekte jedoch benennen, wenn Sie unterschiedliche Objekte
derselben Klasse unterscheiden möchten.
-
Mehrere Lebenslinien in einem Diagramm können unterschiedliche Objekte derselben Klasse darstellen, aber wie
bereits erwähnt, müssen die Objekte so benannt werden, dass Sie die Objekte unterscheiden können.
-
Eine Lebenslinie, die eine Klasse darstellt, kann parallel zu Lebenslinien existieren, die Objekte dieser Klasse
darstellen. Der Objektname der Lebenslinie, die die Klasse darstellt, kann dem Namen der Klasse entsprechen.
Normalerweise wird eine Akteurinstanz im Ablaufdiagramm durch die erste Lebenslinie (ganz links) als Aufrufender der
Interaktion dargestellt. Wenn Sie mehrere Akteurinstanzen in einem Diagramm haben, sollten Sie versuchen, diese an den
Lebenslinien ganz links oder ganz rechts auszurichten.
Eine Nachricht ist ein Kommunikationsmittel zwischen Objekten, das Informationen vermittelt und erwartet, dass eine
Aktivität folgt. In Ablaufdiagrammen wird eine Nachricht als horizontaler durchgezogener Pfeil von der Lebenslinie
eines Objekts zur Lebenslinie eines anderen Objekts dargestellt. Wenn eine Nachricht von einem Objekt an sich selbst
gesendet wird, kann der Pfeil auf derselben Lebenslinie beginnen und enden. Die Beschriftung des Pfeils setzt sich aus
dem Namen der Nachricht und den Parametern zusammen. Der Pfeil kann auch mit einer Folgenummer beschriftet sein, um die
Position der Nachricht in der Nachrichtenfolge für die Interaktion anzuzeigen. Folgenummern werden in Ablaufdiagrammen,
in denen die physische Position des Pfeils die relative Abfolge anzeigt, häufig weggelassen.
Eine Nachricht kann unbestimmt sein, d. h. ihr Name ist eine vorläufige Zeichenfolge, die die Bedeutung der Nachricht
beschreibt. Der Name der Nachricht ist nicht der Name einer Operation des empfangenden Objekts. Sie können die
Nachricht später zuordnen, indem Sie die Operation den Nachrichtenzielobjekts angeben. Die angegebene Operation ersetzt
dann den vorläufigen Namen der Nachricht.
Scripts beschreiben den Ereignisablauf in einem Ablaufdiagramm in Textform.
Sie müssen die Scripts links neben den Lebenslinien platzieren, damit Sie den vollständigen Ablauf von oben nach unten
lesen können (siehe vorherige Abbildung). Sie können Scripts einer bestimmen Nachricht zuordnen und damit
sicherstellen, dass sich das Script mit der Nachricht bewegt.
Bei einer zentralen Steuerung eines Ereignisablaufs oder eines Teils davon steuern einige wenige Objekte den
Ablauf, indem sie Nachrichten an andere Objekte senden und von diesen empfangen. Diese steuernden Objekte bestimmen die
Reihenfolge, in der andere Objekte im Anwendungsfall aktiviert werden. Die Interaktion zwischen den restlichen Objekten
spielt eine untergeordnete Rolle oder ist gar nicht existent.
Beispiel
Im Recycling-Maschinensystem überwacht der Anwendungsfall Tagesbericht drucken unter anderem die Anzahl
und den Typ der zurückgegebenen Objekte und schreibt die gezählten Artikel auf einen Beleg. Das Steuerungsobjekt
Berichtsgenerator legt die Reihenfolge fest, in der die Summen extrahiert und geschrieben werden.
Die Verhaltensstruktur des Anwendungsfalls Tagesbericht drucken wird im Steuerungsobjekt
Berichtsgenerator zentral verwaltet.
Dies ist ein Beispiel für zentral verwaltetes Verhalten. Die Steuerstruktur wird hauptsächlich deswegen zentralisiert,
weil die unterschiedlichen Teilereignisphasen des Ereignisablaufs nicht voneinander abhängig sind. Der Hauptvorteil
dieses Ansatz ist der, dass keines der Objekte die Zählung für das jeweils nächste Objekt verfolgen muss. Wenn Sie die
Reihenfolge der Teilereignisphasen ändern möchten, müssen Sie die Änderung lediglich im Steuerungsobjekt vornehmen.
Außerdem können Sie problemlos weitere Teilereignisphasen hinzufügen, wenn Sie beispielsweise einen neuen Typ von
Pfandartikel hinzufügen möchten. Diese Struktur hat außerdem den Vorteil, dass Sie die verschiedenen Teilereignisphasen
in anderen Anwendungsfällen wiederverwenden können, da die Reihenfolge des Verhaltens nicht in die Objekte integriert
ist.
Eine dezentrale Steuerung ist erforderlich, wenn die teilnehmenden Objekte direkt und nicht über ein oder
mehrere steuernde Objekte miteinander kommunizieren.
Beispiel
Im Anwendungsfall Brief senden sendet jemand per Post einen Brief an jemand anderen in einem anderen Land. Der
Brief wird zuerst an das Land des Empfängers gesendet. In diesem Land wird der Brief an eine bestimmte Stadt gesendet.
In der Stand wiederum wird der Brief an den Empfänger gesendet.
Die Verhaltensstruktur des Anwendungsfalls Brief senden ist dezentral.
Das Anwendungsfallverhalten ist ein dezentraler Ereignisablauf. Die Teilereignisphasen gehören zusammen. Der Absender
des Briefs spricht von "einen Brief an jemanden senden". Wie Briefe in Ländern oder Städten im Einzelnen weitergeleitet
werden, muss er nicht wissen. (Wenn jemand einen Brief im eigenen Land versendet, finden wahrscheinlich nicht alle
beschriebenen Aktionen statt.)
Der verwendete Steuerungstyp richtet sich nach der Anwendung. Im Allgemeinen sollten Sie versuchen, mit unabhängigen
Objekten zu arbeiten, d. h. verschiedene Aufgaben an die Objekte zu delegieren, die sich von ihrem Charakter her am
besten dafür eignen.
Ein Ereignisablauf mit zentraler Steuerung hat ein "gabelähnliches" Ablaufdiagramm. Ein "treppenähnliches"
Ablaufdiagramm hingegen veranschaulicht eine dezentrale Steuerstruktur für teilnehmende Objekte.
Eine zentrale Steuerstruktur in einem Ereignisablauf erzeugt ein "gabelähnliches" Ablaufdiagramm. Eine dezentrale
Steuerstruktur erzeugt ein "treppenähnliches" Ablaufdiagramm.
Die Verhaltensstruktur einer Anwendungsfallrealisierung ist häufig eine Mischung von zentralem und dezentralem
Verhalten.
Eine dezentrale Struktur eignet sich in den folgenden Fällen:
-
Die Teilereignisphasen sind eng gekoppelt. Dies ist der Fall, wenn die teilnehmenden Objekte
-
einen Teil oder eine vollständige Hierarchie bilden, z. B. Land - Bundesland - Stadt,
-
eine Informationshierarchie bilden, z. B. Geschäftsführer - Abteilungsleiter - Teamleiter,
-
eine feste chronologische Abfolge darstellen (die Teilereignisphasen finden immer in derselben Reihenfolge
statt), z. B. Mitteilung - Auftrag - Rechnung - Lieferung - Zahlung,
-
eine konzeptionelle Vererbungshierarchie bilden, z. B. Tier - Säugetier - Katze.
-
Sie möchten Funktionalität kapseln und damit abstrahieren. Dies eignet sich in Situationen, wenn stets die gesamte
Funktionalität verwendet werden soll, weil die Funktionalität unnötig schwer zu erfassen ist, wenn die
Verhaltensstruktur zentralisiert ist.
Eine zentrale Struktur eignet sich in den folgenden Fällen:
-
Die Reihenfolge, in der die Teilereignisphasen stattfinden, kann sich ändern.
-
Es werden möglicherweise neue Teilereignisphasen eingefügt.
-
Teile der Funktionalität sollen wiederverwendbar sein.
|