<< zurück

MBSE Home

weiter >>

6.5 Sequenzdiagramme in der UML

Vererbung

In einem Sequenzdiagramm werden prototypische Objekte optional mit Namen und Typ angegeben. Der Typ eines Objekts kann eine Klasse mit mehreren Unterklassen oder ein Interface sein. Entsprechend kann das im ablaufenden System beobachtete Objekt aus einer anderen Klasse sein. In diesem Sinn berücksichtigen Sequenzdiagramme also die Vererbung. Jedoch ist aufgrund der verwendeten losen Semantik für Sequenzdiagramme die Aussagekraft auch für Unterklassen beschränkt. Tatsächlich beschreibt ein Sequenzdiagramm nur, dass sich Objekte eines Typs nach dem angegebenen Muster verhalten können, aber nicht müssen.

Hilfreich ist es allerdings bei Tests, die ein gewisses Verhaltensmuster für alle Objekte eines Typs prüfen, den Objekten aus Unterklassen zum Beispiel aufgrund des vergebenen Stereotyps ≪match:visible≫ gewisse Freiheiten im Verhalten zu lassen.

Sequenzdiagramme und Statecharts

Es gibt je nach methodischem Vorgehen verschiedene Formen, Statecharts und Sequenzdiagramme in Kombination einzusetzen:

1. Aus einer Menge von Sequenzdiagrammen werden Statecharts entwickelt.
2. Statecharts und Sequenzdiagramme werden parallel und zu unterschiedlichen Zwecken eingesetzt.
3. Aus einem Statechart lassen sich Sequenzdiagramme ableiten, die das Statechart erfüllen.

Zum Beispiel ist in [Krü00, BGK99] ein Verfahren beschrieben, aus einer endlichen Menge von Sequenzdiagrammen Automaten für die beteiligten Objekte abzuleiten. In der dort benutzten Form wird durch Zerlegung eines Sequenzdiagramms in die für ein einzelnes Objekt relevanten Interaktionen zunächst ein Wort des Alphabets des Automaten gebildet. Durch manuelles Hinzufügen von Zustandsinformation kann aus der endlichen Menge von Wörtern ein Automat konstruiert werden, der diese (und weitere Wörter) akzeptiert. Durch weitere Transformationen des Automaten entsteht eine Form, die als operative Beschreibung eines Objekts verstanden werden kann, welches das durch die Sequenzdiagramme beschriebene Verhalten implementiert.

Ein ähnliches Verfahren wird in [DH01] beschrieben, in dem durch Protokollierung von erwünschtem Verhalten implizit ein LSC („Live Sequence Chart“, [HM08, HM03]) gebildet wird und daraus Automaten konstruiert werden. Beide Ansätze haben gemeinsam, dass sie zunächst von einer exemplarischen Spezifikation ausgehen und daraus eine vollständige, implementierungsnahe Beschreibung gewinnen. Diese Ansätze lassen sich mit einer geeigneten Adaption auch für UML/P einsetzen.

Die umgekehrte Form, aus gegebenen Statecharts Sequenzdiagramme zu generieren, kann für zwei Aufgaben eingesetzt werden. Zum einen können so exemplarische und leichter verständliche Beschreibungen aus einer gegebenen Statechart-Implementierung extrahiert und auf dieser Basis das Zusammenspiel beteiligter Objekte analysiert werden. Zum anderen können so aus einem Statechart Testfälle abgeleitet werden, die verschiedene Transitionsfolgen des Statecharts in Testfällen prüfen.

Eine weitere Alternative ist es, Statecharts und Sequenzdiagramme parallel einzusetzen. In diesem Fall sind beide Sichten des Systems nicht voneinander abgeleitet worden, sondern wurden manuell entwickelt. Es ist daher von Interesse, beide Beschreibungen auf Konsistenz durch analytische Techniken zu überprüfen, indem ein Sequenzdiagramm als Wort (Folge von Interaktionen) aufgefasst wird, welches das Statechart erfüllen muß. Durch die Verwendung von OCL-Bedingungen innerhalb beider Notationen ist die analytische Prüfbarkeit jedoch nur begrenzt durchführbar. Es ist deshalb eine sinnvolle Vorgehensweise, das Statechart zur Implementierung und die Sequenzdiagramme als Testfälle einzusetzen.

Sequenzdiagramme und UML-Kommunikationsdiagramme

Der UML 2-Standard bietet neben den Sequenzdiagrammen eine zusätzliche, den Sequenzdiagrammen inhaltlich eng verwandte Notation an. Kommunikationsdiagramme stellen eine Teilmenge der Informationen eines Sequenzdiagrams dar, fokussieren aber weniger auf die zeitliche Reihenfolge, sondern mehr auf die Zusammenarbeit zwischen den Objekten. Abbildung 6.19 beinhaltet die Darstellung der Sequenzdiagramme aus den Abbildungen 6.1 und 6.9 als Kommunikationsdiagramm. Dabei fehlen allerdings OCL-Bedingungen und Returns, die im Kommunikationsdiagramm nicht dargestellt werden.

Die zweidimensionale Verteilung erlaubt es, in Kommunikationsdiagrammen mehr Objekte unterzubringen. Die Reihenfolge der Interaktionen wird nicht durch Zeitlinien, sondern durch eine Nummerierung festgelegt. Dabei werden verschachtelte Aufrufe mit aufsteigenden Nummernlisten gekennzeichnet. Return-Werte werden beim Aufruf eingetragen. Ein zu den Aktivitätsbalken analoges Konzept existiert in Kommunikationsdiagrammen nicht. Mehr Details zu Kommunikationsdiagrammen sind unter anderem in [RQZ07] zu finden.

Obwohl die dargestellte Information beider Diagramme essentiell dieselbe ist, unterscheidet sich die Darstellungsform und damit der Umgang mit den Diagrammen erheblich. So ist zum Beispiel das Hinzufügen einer Interaktion im Sequenzdiagramm einfacher, weil im Kommunikationsdiagramm neu nummeriert werden muss. Außerdem können OCL-Bedingungen nicht in der einfachen Weise für bestimmte Zeitpunkte angegeben werden, wie dies bei Sequenzdiagrammen der Fall ist.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>