B. Rumpe: Modellierung mit UML

<< zurück

weiter >>

6.1 Konzepte der Sequenzdiagramme

Abbildung 6.1 beschreibt ein Sequenzdiagramm, das im Folgenden als Beispiel verwendet wird, um daran die verfügbaren Konzepte zu erklären.

Abbildung 6.1: Sequenzdiagramm zur Annahme eines Gebots

Die wesentlichen im Sequenzdiagramm auftretenden Konzepte sind in Abbildung 6.2 kurz erläutert.

Objekt: im Sequenzdiagramm hat dieselbe Bedeutung wie im Objektdiagramm (siehe Abbildung 4.1), wird allerdings nur mit Namen und Typ dargestellt. Mehrere Objekte desselben Typs sind erlaubt. Name oder Typ sind optional.
Zeitlinie.: Im Sequenzdiagramm werden zeitlich aufeinanderfolgende Ereignisse von oben nach unten dargestellt. Jedes Objekt hat eine Zeitlinie, die das Voranschreiten der Zeit dieses Objekts darstellt. Die Zeit ist nicht maßstabsgetreu und muss auch nicht in allen Objekten gleich sein. Die Zeitlinie dient daher nur zur Darstellung zeitlicher Reihenfolgen von Interaktionen.
Interaktion.: Eine Interaktion zwischen zwei Objekten kann, wie in Abschnitt 5.4.3 diskutiert, eine von mehreren Arten von Stimuli sein. Dazu gehören Methodenaufrufe, Returns, Exceptions und asynchrone Nachrichten. Im Sequenzdiagramm können die Parameter von Interaktionen angegeben oder ausgelassen werden.
Aktivitätsbalken.: Zur Bearbeitung eines Methodenaufrufs ist ein Objekt eine gewisse Zeit aktiv. Zur Darstellung dieser Aktivität dient der Aktivitätsbalken, der bei Rekursion auch geschachtelt auftreten kann.
Bedingung.: Zur detaillierten Beschreibung von Eigenschaften während eines Ablaufs können OCL-Bedingungen (engl. „Guards“) eingesetzt werden.

Abbildung 6.2: Begriffsdefinitionen für Sequenzdiagramme

Objekt, Zeitlinie, Aktivität

Im Sequenzdiagramm werden Objekte in einer Reihe nebeneinander dargestellt und mit einer nach unten gerichteten Zeitlinie versehen. Objekte tragen optional einen Namen und einen Typ. Es werden aber im Gegensatz zum Objektdiagramm keine Attribute und keine Links dargestellt. An einem Objekt ankommende und abgehende Interaktionen sind in zeitlicher Reihenfolge durch das Auftreffen auf der Zeitlinie dargestellt und könnte in dieser Form von einem Beobachter protokolliert worden sein.

Als Interaktionen sind im Prinzip auch asynchrone Nachrichten zugelassen. Jedoch kann asynchrone Kommunikation nur eingeschränkt dargestellt werden. So wird vereinfachend angenommen, dass eine gleichzeitige oder überkreuzende Versendung von Nachrichten nicht auftritt. Diese Vereinfachung ist motiviert aus dem Einsatz von Sequenzdiagrammen für Testzwecke, in denen Nebenläufigkeit explizit kontrolliert wird, um determinierte Testergebnisse zu erhalten. Dadurch wird die Modellierung mit Sequenzdiagrammen wesentlich vereinfacht, es sind aber unter Umständen bestimmte, in einer Implementierung mögliche Sachverhalte nicht durch Sequenzdiagramme darstellbar. Ähnliche Annahmen sind auch bei anderen, komplexeren MSC-Dialekten zu finden [Krü00, BMR⁺96]. Im Rest dieses Kapitels wird deshalb nur der sequentielle Methodenaufruf weiter diskutiert.

Ein Aktivitätsbalken wird verwendet, darzustellen, wann eine Methode eines Objekts ausgeführt wird. Aktivitätsbalken beginnen und enden im Normalfall bei ein- beziehungsweise ausgehenden Pfeilen. Aktivitätsbalken können weggelassen werden. Es kann dann aber das später noch diskutierte Problem der Mehrdeutigkeit entstehen. Bei einem rekursiven Aufruf werden Aktivitätsbalken, wie später noch diskutiert, geschachtelt dargestellt. Da ein Return-Pfeil ebenfalls ausgelassen werden kann, darf ein Aktivitätsbalken in diesem Fall ohne ausgehenden Pfeil enden.

Die Arten der möglichen Interaktionen sind in Abbildung 6.3 dargestellt. Jede Interaktion mit Ausnahme des später diskutierten rekursiven Aufrufs wird durch einen waagrechten Pfeil dargestellt, der symbolisiert, dass die dabei verbrauchte Zeit vernachlässigt wird.¹

An den Pfeilen werden Methodenaufrufe, Returns oder Exceptions angegeben. Diese können mit oder ohne Argumente angegeben sein. Ein Argument ist ein Java-Ausdruck. Handelt es sich um eine einfache Variable, die vorher noch nicht aufgetreten ist, so wird diese mit dem ersten Auftreten definiert. Return-Angaben können auch vollständig weggelassen werden, da die gestrichelte Pfeilform bereits eindeutig ist. Aufgrund der Natur von Returns wird festgelegt, dass ein Return nur angegeben werden kann, wenn auch der zugehörige Methodenaufruf im Sequenzdiagramm angegeben ist.

Um eine Überladung der Informationen zu verhindern, kann statt der Argumente der Interaktion auch der Unvollständigkeits-Indikator „… “ angegeben werden. Dies hat den gleichen Effekt, als würden die Parameter vollständig weggelassen werden.

Abbildung 6.3: Interaktionsformen im Sequenzdiagramm

Statische Methoden

Wenn eine Methode statisch ist, so wird sie wie auch im Klassendiagramm unterstrichen. In diesem Fall endet der Pfeil an einer Klasse, die damit analog zu einem Objekt eingesetzt wird. Abbildung 6.4 demonstriert dies.²

Abbildung 6.4: Statische Methode im Sequenzdiagramm

Objekterzeugung

Wird ein Objekt während der Interaktion neu erzeugt, so kann dies dargestellt werden, indem die Zeitlinie des Objekts später beginnt. Abbildung 6.5 zeigt zwei typische Formen von Objekterzeugung. Für bestimme Formen der Objekterzeugung verwendet, sind beide Darstellungen sogar äquivalent. Form (b) ist dann nur eine ausführlichere, implementierungsnähere Darstellung.

Eine Darstellung für die Zerstörung eines Objekts wird in UML/P nicht angeboten, da dies auch in der Zielsprache Java nicht explizit herbeigeführt wird.

Abbildung 6.5: Erzeugung eines neuen Objekts

Stereotypen und Merkmale

Auch bei Sequenzdiagrammen können Stereotypen und Merkmale angegeben werden. In Abschnitt 6.4 wird der Stereotyp ≪match≫ eingeführt, um dem Entwickler die Möglichkeit zu geben, zwischen verschiedenen Semantiken für Sequenzdiagramme auszuwählen.

Der Stereotyp ≪trigger≫ kann zum Beispiel eingesetzt werden, um damit zu markieren, dass ein Methodenaufruf ursächlich für alle weiteren Interaktionen des Sequenzdiagramms ist. Ein solcher Stereotyp ist daher vor allem für Testtreiber wie in Abbildung 6.6 geeignet und kann nur für Methodenaufrufe von Objekten der Testumgebung in die getestete Objektstruktur hinein angewendet werden. Deshalb ist meist nur der erste Methodenaufruf mit ≪trigger≫ markiert. Mit ≪trigger≫ markierten Interaktion führen notwendigerweise zu den weiteren beschriebenen Interaktionen. Andere Verhaltensweisen sind den aufgerufenen Objekten nicht erlaubt. Dies ist eine deutlich stärkere Einschränkung, als es Sequenzdiagramme ohne diesen Stereotyp darstellen.

Abbildung 6.6: Testtreiber mit startender Nachricht

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>