Richtlinie: Ablaufdiagramm
Ein Ablaufdiagramm ist ein UML-Konstrukt, mit dem die Abfolge der Objektinteraktionen gezeigt werden kann, die das Verhalten eines Anwendungsfallszenarios realisieren. Diese Richtlinie beschreibt die UML-Notation für dieses Konstrukt.
Beziehungen
Hauptbeschreibung

Einführung

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.

Inhalt von Ablaufdiagrammen

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.

Im Begleittext beschriebenes Diagramm

Ein Ablaufdiagramm, das einen Teil des Ereignisablaufs des Anwendungsfalls Ortsgespräch führen in einem einfachen Telefonsystem beschreibt.

Objekte

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.

Akteur

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.

Nachrichten

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

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.

Steuerungsablauf in Ablaufdiagrammen verteilen

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.

Im Begleittext beschriebenes Diagramm

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.

Im Begleittext beschriebenes Diagramm

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.

Im Begleittext beschriebenes Diagramm

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.