2.4 Sequenzdiagramm. Beziehung und Beispiel. Instantiierbare Anwendungsfälle. Akteur kommuniziert. A und B, da die Kommunikationsbeziehung

2.4 Sequenzdiagramm 109 Beziehung und Beispiel B is-a A Termin ändern is-a Eintrag ändern (Akteur = Benutzer) Instantiierbare Anwendungsfälle A und B. Falls A wie im Beispiel abstrakt ist: nur B. Akteur kommuniziert mit A und B, da die Kommunikationsbeziehung von A geerbt wird Tab. 2 8 Beziehungen zwischen Anwendungsfällen B A B «extend» A Terminvorschlag finden «extend» Termin erfassen (Akteur = Benutzer) A, A gemeinsam mit B und fallweise auch B. Im Beispiel bezeichnet B (Terminvorschlag finden) das erweiternde»delta«, das in unserem Beispiel keinen eigenen Anwendungsfall darstellt. Häufig wird aber für B ein Name gewählt, der»b + Delta«entspricht (etwa Place rush order «extend» Place order [Booc99]), und dadurch instantiierbar klingt. A und B. Dies ist zwar formal nicht ableitbar (Abhängigkeiten weisen keine Vererbungssemantik auf), hat sich jedoch so eingebürgert. Im Beispiel würde daher keine zweite Beziehung zwischen dem Akteur und Terminvorschlag finden eingezeichnet. B «extend» A A «include» B Termin erfassen (Akteur = Benutzer) «include» Teilnehmer verständigen A gemeinsam mit B und fallweise auch B. A A «include» B 2.4 Sequenzdiagramm Im vorhergehenden Unterkapitel wurde gezeigt, wie durch das Anwendungsfalldiagramm ein Überblick über die Funktionalität eines betrachteten Systems gegeben werden kann. Dabei standen strukturelle Zusammenhänge im Vordergrund das dynamische Systemverhalten konnte allenfalls verbal beschrieben werden. Im vorliegenden Unterkapitel treten wir nunmehr in die Diskussion der diagrammatischen Verhaltensdarstellung ein: Mit Sequenz-, Kollaborations-, Zustands- und Aktivitätsdiagrammen können unterschiedliche Aspekte des Systemverhaltens modelliert werden. Das Sequenzdiagramm wurde ursprünglich zur Modellierung von Telekommunikationssystemen entwickelt (Message Sequence Charts Kollaborationsdiagramm S. 117 Zustandsdiagramm S. 128 Aktivitätsdiagramm S. 151

110 2 UML Syntax und Semantik Sequenzdiagramm (sequence diagram)... zur exemplarischen Darstellung eines Ablaufs (= Szenario) Algorithmus vs. Szenario Aktivitätsdiagramm S. 151 [CCIT88]) und von Rumbaugh et al. zur Erstellung dynamischer Modelle objektorientierter Systeme in OMT eingeführt [Rumb91]. In UML wurde schließlich eine Version des Sequenzdiagramms übernommen, die in wesentlichen Teilen auf die von Buschmann et al. erweiterte Notation (Object Message Sequence Charts) zurückgeführt werden kann [Busc96]. Das Sequenzdiagramm beschreibt das sogenannte Interobjektverhalten, das ist die Art und Weise, wie einzelne Objekte miteinander Nachrichten austauschen (»interagieren«), um ein bestimmte Aufgabe zu erfüllen. Gemeinsam mit dem im nächsten Abschnitt vorgestellten Kollaborationsdiagramm wird es in UML daher auch als Interaktionsdiagramm bezeichnet. Sequenzdiagramme eignen sich primär zur exemplarischen Darstellung eines Ablaufs, die genau einen möglichen Ablauf eines Anwendungsfalls oder einer Operation, d.h. ein mögliches Szenario, beschreibt. Der Vorteil der Szenariosicht ist die Konzentration auf das Wesentliche durch Weglassen von Ausnahmen und Spezialfällen. Grundsätzlich besteht wohl auch die Möglichkeit der Modellierung von Fallunterscheidungen und Wiederholungen, womit Szenarien soweit verallgemeinert werden können, daß sie vollständige Algorithmen darstellen. Allerdings ist dies erfahrungsgemäß ein sehr mühsames Unterfangen, das u.u. auch zu relativ unleserlichen Diagrammen führen kann. Die Autoren empfehlen daher, Sequenzdiagramme für exemplarische Verhaltensdarstellungen einzusetzen und echte Algorithmen eher mit Aktivitätsdiagrammen oder außerhalb von UML, etwa in Pseudocode, zu notieren. Im Sequenzdiagramm werden zwei Darstellungsdimensionen unterschieden: Die vertikale Dimension entspricht einer Zeitachse, während horizontal die betrachteten Objekte aufgetragen werden. Objektsymbol Lifeline Zeitachse vertikal und ordinal skaliert Aktivierungsbalken (activation bar) Löschsymbol einx:x Wenn es sich als darstellungstechnisch günstiger erweist, kann ein Sequenzdiagramm auch um 90 gedreht angeordnet werden. Wir gehen im folgenden jedoch immer von der»klassischen«form aus. Durch die Einführung einer expliziten Zeitachse mit von oben nach unten fortschreitender Zeit kann die chronologische Reihenfolge von Nachrichten durch deren vertikale Anordnung im Diagramm definiert werden. Die Zeitachse ist im Normalfall ordinal skaliert, d.h., daß die Größe vertikaler Abstände keinerlei Bedeutung hat. Für die Modellierung von Echtzeitverarbeitung ist allerdings auch eine metrisch skalierte Zeitachse zulässig. Die an der Interaktion teilnehmenden Objekte werden horizontal nebeneinander durch je eine vertikale, strichlierte Linie repräsentiert, die sich über die»lebenszeit«des Objekts erstreckt. Am oberen Ende dieser Lifeline (die Bezeichnung wird als Jargonausdruck aus dem

2.4 Sequenzdiagramm 111 Original übernommen) ist ein Objektsymbol angebracht, das i.a. lediglich Name und Klasse des Objekts enthält. Wird eine Operation eines Objekts ausgeführt, so wird für die Dauer dieser Operation die Lifeline zu einem sogenannten Aktivierungsbalken verbreitert. Hört ein Objekt im Zuge der beschriebenen Interaktion auf zu existieren, werden Lifeline bzw. Aktivierungsbalken bis zu dieser Stelle verkürzt und durch ein Kreuz abgeschlossen. Ansonsten erstreckt sich die Objektdarstellung bis an das untere Ende des Sequenzdiagramms. Objekte, die über einen eigenen Kontrollfluß (Prozeß oder Thread) verfügen, werden aktive Objekte genannt und durch Objektsymbole mit fettem Rahmen repräsentiert (alternativ dazu kann die Eigenschaft {active} explizit angegeben werden). Sie können unabhängig von anderen Objekten operieren und werden dementsprechend mit durchgehenden Aktivierungsbalken ausgestattet. (Weitere Hinweise über aktive Objekte finden sich im Unterkapitel über Kollaborationsdiagramme.) Die Beschreibung der Interaktion zwischen den Objekten basiert auf der Angabe der Nachrichten, die zwischen den Objekten ausgetauscht werden. Diese werden normalerweise durch horizontale Pfeile notiert, die sich von der Lifeline des Senderobjekts zu jener des Empfängerobjekts erstrecken. Die Nachrichtenübermittlung wird dabei i.a. als konzeptionell verzögerungsfrei betrachtet. Sollte dies eine unzulässige Modellvereinfachung darstellen, können Nachrichtenpfeile auch abwärts gerichtet sein und damit auf zeitkonsumierende Übermittlung hinweisen (vgl. Abb. 2 63, S. 117). Die Form der Pfeilspitze gibt Aufschluß über die Art der Nachrichtenübermittlung. UML unterscheidet die folgenden Arten (weitere Varianten wären als Erweiterungen von UML zulässig): Aktives Objekt (active object) S. 123 Horizontale Pfeile stehen für Nachrichten, die ohne Zeitverlust übermittelt werden, abwärts gerichtete Pfeile repräsentieren Nachrichten mit Übermittlungszeit > 0 Synchroner Kontrollfluß, d.h., die Nachricht wird als Prozeduraufruf interpretiert, asynchroner Kontrollfluß, d.h., die Nachricht wird als Signal betrachtet, und der Sender der Nachricht wartet nicht auf die Antwort des Empfängers, sowie unspezifizierter Kontrollfluß. Kontrollflußvarianten: synchron asynchron unspezifiziert Zusätzlich können Rücksprung-Anweisungen durch strichlierte Pfeile notiert werden. In nebenläufigen Systemen kann die Zuordnung von Nachrichten zu einem bestimmten Kontrollfluß (Prozeß oder Thread) durch Vergabe von Nachrichtennummern eines bestimmte Formats erfolgen. Da die Angabe von Sequenznummern für Nachrichten in einem Sequenzdiagramm aber eher die Ausnahme darstellt schließlich wird die Reihenfolge durch die Zeitachse i.a. eindeutig bestimmt, wird dieser Mechanismus, der gleichermaßen (und vor allem) bei Kollabo- Rücksprung: Numerierung von Nachrichten S. 120

112 2 UML Syntax und Semantik Objekterzeugung new() Überwachungsbedingung (guard condition) [...] [B] m() [ B] n() Verzweigung Alternative Lifelines [B] m() [ B] n() rationsdiagrammen anwendbar ist, erst im nächsten Unterkapitel erläutert. Wird ein Objekt erst im Laufe der Interaktion auf Grund einer Nachricht wie new(), create() o.ä. erzeugt, so mündet der Pfeil dieser»erzeugenden«nachricht direkt im Symbol des Objekts, das in diesem Fall nicht am oberen Rand des Sequenzdiagramms, sondern eben erst auf jener Höhe plaziert ist, die dem Zeitpunkt seiner Erzeugung entspricht. Nachrichten können durch Überwachungsbedingungen beschriftet sein, womit Fallunterscheidungen im Sequenzdiagramm sichtbar gemacht werden: Die»überwachte«Nachricht wird nur übermittelt, wenn die in eckigen Klammern angegebene Bedingung erfüllt ist. Häufig werden durch zwei zu einander komplementäre Bedingungen alternative Nachrichten im Sinne einer if-then-else-verzweigung markiert. Dabei ist es aus Platzgründen i.a. nicht möglich, beide Nachrichtenpfeile horizontal zu führen, weshalb zwangsläufig einer der Pfeile abwärts zeigt. Um einen derartigen Pfeil von einem»zeitkonsumierenden«pfeil (s.o.) zu unterscheiden, wird er abgeknickt notiert, sodaß ein Pfeilsegment dennoch horizontal geführt werden kann und an die Unmittelbarkeit der Übertragung erinnert. Werden ein und demselben Objekt als direkte oder indirekte Folge einer solchen Verzweigung unterschiedliche Nachrichten übermittelt, wird seine Lifeline aufgespalten, um zu betonen, daß für dieses Objekt alternative»interaktionspfade«dargestellt werden. Am Ende einer solchen Alternative können die Lifeline-Zweige wieder verschmolzen werden. Als Beispiel aus dem CALENDARIUM wenden wir uns der Beschreibung eines Standardablaufs des Anwendungsfalls Termin löschen zu. Dabei gehen wir von einem zu löschenden Termin mit zwei Teilnehmern und einer Vorabbenachrichtigung (»Notifikation«) aus. Von den beiden Teilnehmern sei einer der handelnde Akteur, der zweite sei zum Zeitpunkt der Absage ebenfalls»on-line«. Beide Teilnehmer sollen durch ein Informationsfenster von der erfolgten Terminabsage informiert werden.

2.4 Sequenzdiagramm 113 b1 :Benutzer :Termin- Maske :Termin :CALEN- DARIUM :Notifikation :Queue t1 :Teilnehmer t2 :Teilnehmer b2 :Benutzer lösche! loesche() benutzer() [b ist nicht berechtigt] b [b ist berechtigt] loesche() deq(id) loesche(self) Abbruch info(self, termin) [on-line] new(hinweis) Hinweis f1 :Infofenster loesche(self) info(self, termin) [on-line] new(hinweis) f2 :Infofenster Hinweis ok! ok! Abbildung 2 61 zeigt ein entsprechendes Sequenzdiagramm, wobei vorausgesetzt wird, daß sich der agierende Benutzer b1 in einer Situation befindet, in der der zu löschende Termin durch eine entsprechende Benutzerschnittstelle (Objekt :TerminMaske) repräsentiert wird. Diesem Objekt»sendet«der Benutzer die»nachricht«lösche!, durch die die Ausführung des Anwendungsfalls initiiert wird. Die Nachrichtenübermittlung zwischen dem Menschen und dem System wird dabei typischerweise durch einen Pfeil der Kategorie»unspezifiziert«modelliert. Die Benutzerschnittstelle leitet die Löschanforderung (durch einen synchronen Operationsaufruf) an das ihr zugeordnete Terminobjekt weiter. Dieses wird dadurch aktiv (vgl. den Aktivierungsbalken) und vergewissert sich zunächst, ob der initiierende Benutzer zum Löschen überhaupt berechtigt ist. Dazu fragt es das globale Kontrollobjekt der Klasse CALENDARIUM nach dem aktuellen Benutzer. Dieses Kontrollobjekt, das während der gesamten Sitzung aktiv ist, wird durch die Nachricht benutzer() erneut aktiviert, was durch den nach rechts versetzten, zusätzlichen Aktivierungsbalken dargestellt wird. Das Ergebnis dieser Operation ist die Abb. 2 61 Sequenzdiagramm für das Löschen eines Termins Szenariodarstellung

114 2 UML Syntax und Semantik Fallunterscheidung führt zu komplexer Notation: Abbruch durch alternativen Rücksprungpfeil (nach links), auf den die Nachricht»Abbruch«an den Benutzer folgt und die Interaktion beendet wird Szenario-Darstellung... Benutzeridentifikation b, mit deren Hilfe die Berechtigung geprüft werden kann. Diese Prüfung ist in der Abbildung nicht dargestellt, sehr wohl aber die resultierende Fallunterscheidung durch die Überwachungsbedingung [b ist berechtigt]. Diese Bedingung bezieht sich streng genommen nur auf die ihr unmittelbar zugeordnete Nachricht loesche(), wobei im negativen Fall der Anwendungsfall abgebrochen wird, weshalb die Bedingung implizit auch auf die folgenden Nachrichten zutrifft. Als nächstes wird die (einzige) Notifikation gelöscht und im Zuge dessen aus der Warteschlange der noch zu versendenden Notifikationen ausgetragen (deq(id)). Diese Warteschlange kann durch ein externes System repräsentiert sein, weshalb wir hier von asynchroner Nachrichtenübermittlung ausgehen. Die Abarbeitung der Operation Notifikation::loesche() endet damit, daß das Notifikations-Objekt entfernt wird. Als nächstes informiert das Termin- Objekt sein erstes Teilnehmer-Objekt t1, daß das Termin-Objekt gelöscht wird. t1 wiederum veranlaßt das Kontrollobjekt :CALEN- DARIUM zu prüfen, ob der von ihm repräsentierte Benutzer (im Szenario: b1) on-line ist (was der Fall ist), und gegebenenfalls ein Benachrichtigungsfenster zu erzeugen, das vom entsprechenden Benutzer durch die Nachricht ok! zu quittieren ist. Dasselbe erfolgt für den zweiten Teilnehmer t2 und seinen korrespondierenden Benutzer b2, der im vorliegenden Szenario an anderer Stelle on-line ist. Nachdem beide Teilnehmer-Objekte behandelt worden sind, werden das Termin-Objekt und in der Folge auch die zugehörige Benutzerschnittstelle tatsächlich gelöscht. Dieses Beispiel zeigt einen beinahe puristischen Fall eines Szenarios, also einer exemplarischen Verhaltensbeschreibung. Für alle mehrfach auftretenden Objekte werden konkrete Anzahlen festgelegt (eine Notifikation, zwei Teilnehmer), und für die angeführten Bedingungen (etwa [on-line]) sind kaum Alternativen vorgesehen. Eine Ausnahme stellt die Berechtigungsprüfung dar, für die zwei mögliche Ausgänge dargestellt sind (was nach Meinung der Autoren bereits genügt, um das Diagramm optisch zu überfrachten...). Andererseits bringt die an sich übersichtlichere exemplarische Sichtweise auch Nachteile mit sich: Wo Vielfachheiten durch konkrete Anzahlen festgelegt sind, geht entweder der Eindruck der Vielfachheit verloren (im Beispiel: genau eine Notifikation), oder es führt die Wiederholung von Teilsequenzen zu erheblichem Zusatzaufwand für Zeichner und Leser (im Beispiel: zwei Teilnehmer). Als Alternativlösung wird in Abbildung 2 62 derselbe Sachverhalt mit Hilfe von Iterationen beschrieben. Eine zu wiederholende Nachrichten-Teilsequenz ist durch ein Rechteck zu einem Block zusammengefaßt, der im unteren Bereich Angaben zur Schleifensteuerung enthält.

2.4 Sequenzdiagramm 115 b1 :Benutzer lösche! :Termin- Maske loesche() :Termin t :Teilnehmer benutzer() :CALEN- DARIUM n:notifikation :Queue :Benutzer Abb. 2 62 Sequenzdiagramm für das Löschen eines Termins algorithmische Darstellung [b ist nicht berechtigt] b loesche() deq(id) für alle Notifikationen n loesche(self) Abbruch für alle Teilnehmer t info(self, termin) [on-line] new(hinweis) f :Infofenster Hinweis ok! für alle InfoFenster f Die Hauptschwierigkeit bei dieser Darstellung liegt darin, den Gültigkeitsbereich der innerhalb der Schleife benützten»lokalen«objekte sauber zu definieren. Im Beispiel stellen die Notifikation n, der Teilnehmer t und der zugehörige Akteur :Benutzer derartige Objekte dar. Anders als das innerhalb der Schleife erzeugte Fensterobjekt f existieren sie bereits von Beginn an, weshalb die Objektsymbole im Diagramm ganz oben angeordnet werden. Ihre Bedeutung erhalten sie aber erst während der entsprechenden Schleifendurchläufe durch ein in UML nicht näher spezifiziertes»binden«der Objekte an Schleifenvariablen (für alle Teilnehmer t...), oder überhaupt nur implizit (die physische Entsprechung :Benutzer des logischen Teilnehmers t ko-iteriert mit t). In Abbildung 2 62 tritt darüber hinaus noch ein anderes Problem auf: Innerhalb der zweiten Schleife werden iterativ Objekte f der Klasse InfoFenster erzeugt, die später ebenfalls in einer Schleife durch Benutzerinteraktionen wieder entfernt werden. Die Vielfach-...vs. algorithmischer Darstellung

116 2 UML Syntax und Semantik heit des Fensterobjekts muß dazu aus dem erzeugenden Schleifenblock in den eliminierenden Schleifenblock»hinübergerettet«werden, was einen semantisch eher zweifelhaften Umstand darstellt. Insgesamt wird man immer wieder feststellen, daß ein realistischer, nichttrivialer Algorithmus durch ein Sequenzdiagramm nicht sinnvoll darstellbar ist. Es wird daher empfohlen, Sequenzdiagramme primär für Szenarien zu verwenden, Faustregeln zur Verwendung von Sequenzdiagrammen Ablaufvarianten allenfalls durch mehrere, einander ergänzende Sequenzdiagramme zu modellieren und Verzweigungen und Schleifen sehr sparsam einzusetzen nur dann, wenn das Diagramm eindeutig interpretierbar bleibt. Beschriftung der Marginalie Sequenzdiagramme können an ihrem (i.a. linken) Rand mit zusätzlichen textuellen Angaben ausgestattet sein, die sich auf die Nachrichten bzw. Aktivierungen beziehen, mit denen sie vertikal ausgerichtet sind. Vorgesehen sind u.a.: Zeitbezogene Einschränkung {n.receivetime - n.sendtime < 1sec} Transitionszeit (transition time) Pseudocode Einschränkungen: Wie üblich werden Einschränkungen als logische Ausdrücke in geschwungenen Klammern angegeben. Bei Sequenzdiagrammen, die Echtzeitsysteme beschreiben, beziehen sich Einschränkungen häufig auf Transitionszeiten, indem z.b. die maximal erlaubte Dauer einer Nachrichtenübermittlung angegeben wird. Zu diesem Zweck können Sendebzw. Empfangszeitpunkt einer Nachricht n explizit referenziert werden: n.sendtime und n.receivetime (diese»pseudoattribute«haben die ehemaligen Transitionszeiten abgelöst, die als symbolische Namen ebenfalls in der Marginalie notiert wurden). Auszuführende Aktionen: Bei Bedarf können Aktionen oder Teile eines Algorithmus natürlichsprachlich oder in Pseudocode angeführt werden, um die durch eine Nachricht ausgelöste Aktivierung näher zu beschreiben. Alle diese Angaben können nicht nur in der Marginalie, sondern alternativ dazu auch unmittelbar neben dem Modellelement angegeben werden, das sie charakterisieren. Abbildung 2 63 zeigt zum Abschluß ein geradezu klassisches Sequenzdiagramm mit beschrifteter Marginalie, das den Aufbau eines Festnetztelefongesprächs modelliert [Rumb91][OMG99][Rumb99].

2.5 Kollaborationsdiagramm 117 {b.receivetime - a.sendtime < 1"} {c.receivetime - b.sendtime<10"} The call is routed through the network. {d.receivetime - d.sendtime < 5"} At this point the parties can talk. caller a: lift receiver b: dial tone c: dial digit... d: route ringing tone stop tone exchange phone rings answer phone stop ringing receiver Abb. 2 63 Sequenzdiagramm zum Aufbau eines Telefongesprächs (aus [Rumb99], S. 424 und [OMG99]). Die Verwendung von Alias- Marken wie a, b etc. für Nachrichten als Basis für die Pseudoattribute sendtime und receivetime ist allerdings nicht ganz konform zur textuellen Erläuterung in [OMG99]... 2.5 Kollaborationsdiagramm Ähnlich wie das Sequenzdiagramm zeigt das Kollaborationsdiagramm die für einen bestimmten Zweck notwendigen Interaktionen zwischen Objekten. Beide Diagrammarten werden daher in UML unter dem Oberbegriff Interaktionsdiagramm zusammengefaßt und decken im wesentlichen denselben Einsatzbereich ab. Das Kollaborationsdiagramm ist dem Sequenzdiagramm insofern überlegen, als es zusätzlich zu den Interaktionen auch den ihnen zugrundeliegenden Kontext in Form von Objektbeziehungen darstellt (Kollaboration, vgl. den folgenden Abschnitt). Umgekehrt wird darauf verzichtet, die Zeit als eigene graphische Dimension zu modellieren, sodaß die Reihenfolge von Nachrichten durch Numerieren spezifiziert werden muß. Die einzelnen Unterschiede werden in Abschnitt 2.5.2 sowie in Kapitel 5 ab Seite 246 noch genauer diskutiert. 2.5.1 Kollaboration Eine Kollaboration wird in UML als Ausschnitt aus der statischen Modellstruktur definiert, der genau jene Modellelemente enthält, die zur Erreichung eines definierten Ziels kooperieren. Dabei werden die Modellelemente auf Instanzebene (als Objekte und Objektbeziehungen) dargestellt. Eine Kollaboration repräsentiert also den statischen Kontext eines bestimmten Verhaltens wie etwa eines Anwendungsfalls oder einer Operation, der das Zusammenspiel der benötigten Teilnehmer ermöglicht. Durch Ausblenden von Modellinformation, Kollaborationsdiagramm (collaboration diagram) Wegen der negativ gefärbten Bedeutung des Begriffs»Kollaboration«findet man in der deutschsprachigen UML-Literatur auch andere Übersetzungen, etwa»kooperationsdiagramm«[kahl98]. Die Autoren meinen jedoch, daß es der Vorteil eines minimalen Hamming- Abstands zum Original rechtfertigt, die politische Dimension des Begriffs»Kollaboration«im Kontext von UML zu vernachlässigen.