UML Sequenzdiagramme

UML-Sequenzdiagramm

https://oer-informatik.de/uml-sequenzdiagramm

tl/dr; (ca. 10 min Lesezeit): Mit UML-Sequenzdiagramm wird die zeitliche Abfolge von Nachrichten zwischen Akteuren dargestellt. Die Notationsmittel werden an Beispielen vorgestellt.

Was beschreibt das UML-Sequenzdiagramm?

Mit UML Sequenzdiagrammen werden Nachrichten im zeitlichen Verlauf dargestellt, die zwischen interagierenden Akteuren (z.B. Instanzen von Softwaresystemen) ausgetauscht werden. Sequenzdiagramme sind i.d.R. so angeordnet, dass die vertikale Achse die zeitliche Dimension darstellt, horizontal sind unterschiedliche Akteure angeordnet.

Welche Einsatzgebiete haben UML-Sequenzdiagramme?

Sequenzdiagramme können in allen Phasen des Softwareentwicklungsprozesses genutzt. Wichtig ist, dass man den Detailreichtum, die genutzten Spezifikationselemente und die Namensgebung der Elemente immer anpasst der Fragestellung:

Wem möchte ich mit meinem Sequenzdiagramm was mitteilen?

Adressat und Intention des Diagramms sollten immer im Zentrum stehen und unterscheiden sich je Phase:

  • In der Analysephase werden die Nachrichtenflüsse der Geschäftsprozesse dargestellt oder einzelne Szenarien der Anwendungsfällen präzisiert. Dies geschieht häufig im Dialog mit anderen Projektbeteiligten, dem Auftraggeber, der Fachdomäne. Entsprechend sollten wenig Notationsmittel verwendet werden und die Sprache der Problemdomäne für die Bezeichnungen gewählt werden.

  • In der Entwurfs- und Implementierungsphase könnnen Interaktionen der Systemkomponenten, der Nutzer oder Drittsysteme modelliert und dokumentiert werden. Adressaten wären hier v.a. andere Entwickler, daher können mehr Notationselemente verwendet werden und auch die Sprache der Lösungsdomäne verwendet werden.

  • Im Rahmen der Qualitätssicherung lassen sich über Sequenzdiagramme Testfälle modellieren, die Schneidung von Integrationstests festlegen und Mocking entscheidungen dokumentierten. Namen sollten bei Akzeptanztests der Problemdomäne, bei Unit- und Integrationstests der Lösungsdomäne entliehen sein.

Bestandteile eines UML-Sequenzdiagramms

Kommunikationspartner

Das Sequenzdiagramm beschreibt Nachrichtenfolgen zwischen Kommunikationspartnern. Die einzelnen Kommunikationspartner werden jeweils an den Kopf eine Lebenslinie gezeichnet: Systeme / Systemkomponenten / Objekte werden als Rechteck gekennzeichnet, vereinzelt werden auch andere Symbole verwendert (z.B. Strichmännchen für menschliche Akteure).

Jeder Kommunikationspartner ist eine identifizierbare Instanz (Objekt) eines Typs (Klasse) und muss deshalb einen Namen tragen. Dieser kann den Instanznamen, den Typnamen oder eine Referenz enthalten.

Der Instanzname ist jeweils mit einem Doppelpunkt vom Typnamen getrennt (martin: User). Bei anonymen Instanzen kann der Instanzname weggelassen werden (siehe :Backend), sofern der Typ nicht relevant ist und ein Instanzname vergeben wurde, kann der Typname weggelassen werden (frontend). Wenn die Lebenslinie auf das umgebende Objekt referenziert langt ein Hinweis auf self.

Die Nabensgebung von UML-Sequenzdiagrammen folgt vereinfacht folgender Syntax (hier als EBNF notiert):

Lifeline = ([ "<objectname>" ] [":" "<classname>"] ) | "self".

Bildhaft als Railroad/Syntaxdiagramm dargestellt entspricht dies:

Lebenslinien

Von den Bezeichnern der Kommunikationspartner erstreck sich i.d.R. nach unten (entspricht der zeitliche Dimension) die Lebenslinie (lifeline).

Sofern die Kommunikationspartner noch passiv sind (keine Nachrichten/Methodenaufrufe bearbeiten) werden die Lebenslinien als einfache oder gestrichelte Linie dargestellt. Im Beispiel unten trifft dies auf Robert Walton zu, der als ich-Erzähler des Romans “Frankenstein” erst spät im Buch eine aktive Rolle übernimmt.

Sofern ein Kommunikationspartner etwas ausführt oder auf Fertigstellung eines Methodenaufrufs wartet wird der Bereich als aktiv (Rechteck) gekennzeichnet (wie bei Viktor Frankenstein). Neue Lebenslinien können durch Konstruktoraufrufe (hier beispielhaft als new() notiert) erzeugt werden. Die jeweiligen Kommunikationspartner sind erst ab diesem Zeitpunkt instanziiert (siehe Unhold, Frankensteins Monster). Die Erzeugungsnachricht wird mit einer gestrichelten Linie und offener Pfeilspitze notiert.

Lebenslinien können ein unbestimmtes Ende haben - die Objektinstanzen gibt es dann weiterhin (siehe Robert, Viktor, Unhold), oder das jeweilige Objekt wird komplett gelöscht (wie bei Henri, der von Unhold umgebracht wird). Dekonstruktionsnachrichten und die Löschung werden durch ein “X” auf der zerstörten Lebenslinie gekennzeichnet.

Nachrichtenflüsse

Nachrichten einer Interaktion werden als gerichtete Kante (Pfeil) vom Absender zum Empfänger dargestellt. Linienart und Pfeilspitze definieren hierbei die Art der Nachricht:

Wird eine Nachricht als synchrone Nachricht (Aufrufe / calls ) mit ausgefüllter Pfeilspitze notiert, so wartet der Absender auf die Ausführung der Operation. Erst wenn die Aktion beendet ist (und ggf. eine Antwort empfangen wurde) setzt der Absender seine Aktivitäten fort.

Im Gegensatz dazu setzt ein Absender seine weiteren Aktionen unmittelbar nach dem Absenden einer asynchronen Nachricht fort. Sie werden mit offener Pfeilspitze (“Indianerpfeil”) notiert. Antworten auf asynchrone Nachrichten werden im UML-Sequenzdiagramm als neue unabhängige asynchrone Nachrichten notiert.

Sofern der Absender / Empfänger einer Nachricht für die betreffende Modellierung nicht relevant oder unbekannt ist spricht man von gefundenen Nachrichten (FoundMessage) bzw. verlorenen Nachrichten (LostMessage). Sie starten bzw. enden nicht an Lebenslinien, sondern an einem ausgefüllten Punkt.

Benamung von Nachrichten

Nachrichten können nach folgendem Muster bezeichnet werden (Notation in EBNF):

message-name[([parameter-name=]parameter-value, ...)]

Bildhaft mit Syntax/Railroad-Diagrammen dargestellt ergeben sich folgende vereinfachte Regelen für Nachrichtennamen:

wobei für die einzelnen Parameter gilt:

Das heißt:

  • ein Name muss genannt werden,

  • Argumente können benannt werden,

  • Die Bezeichner der übergebenen Argumente (Parameternamen) können genannt werden.

Im Fall einer Antwortnachricht kann der Rückgabewert angegeben werden sowie die Variable, in der dieser Rückgabewert gespeichert wurde:

[variable = ] message-name [([parameter-name=]parameter-wert, ...)] [ : returnvalue]

Selbstnachrichten

Nachrichten kann jeder Teilnehmer auch an sich selbst schicken (Methodenaufrufe eines Objekts auf sich selbst). Absenderin und Empfängerin sind dann identisch.

Schleifen im Sequenzdiagramm

Schleifen werden im UML-Sequenzdiagramm über kombinierte Fragmente dargestellt. Im Fall einer Wiederholung über das Schlüsselwort loop in Kombination mit einem guard (im einfachsten Fall der Anzahl der Schleifendurchläufe oder einer Bedingung, bis zu deren zutreffen der Schleifenrumpf ausgeführt wird).

Bedingte Anweisungen im Sequenzdiagramm

Auch bedingte Anweisungen werden als kombiniertes Fragment dargestellt. Der guard (die Bedingung) wird mit eckigen Klammern umgeben:

Concurrency - Parallelisierung im Sequenzdiagramm

Wenn mehrere Interaktionen parallel verlaufen wird dies mit dem kombinierten Fragment par notiert. Die Abläufe der einzelnen Bereiche können somit zeitgleich verlaufen. Die Nachrichten ausserhalb des kombinierten Fragments erfolgen wieder synchronisiert und sequenziell.

Weitere kombinierte Fragmente

Analog zu den vorgenannten kombinierten Fragementen loop, alt und par gibt es eine Reihe weiterer Bezeichner, die in den Rahmenköpfen notiert werden und für folgende Eigenschaften stehen:

  • opt: Nachrichten in diesem Rahmen sind optional

  • strict: die modellierte Nachrichtenreihenfolge muss zwingend erhalten beleiben

  • critical: Die Nachrichtenfolge darf auf keinen Fall unterbrochen werden und gilt als unteilbar (atomar).

Referenzen: Auslagern von Abschnitten in weitere Sequenzdiagramme

Zur Übersichtlichkeit können Sequenzdiagrammme aufgeteilt und ineinander referenziert werden. Beispielsweise soll in folgendem Diagramm die Zustandsänderung des Subject und Benachrichtigung des ConcreteObserver ausgelagert werden von dem Triggern durch den Client:

Hierzu wird an Stelle der auszulagernden Nachrichten ein Referenzrahmen eingefügt (mit dem UML-Schlüsselwort ref und einer Bezeichnung des ausgelagerten UML-Sequenzdiagramms:)

Der referenzierte Bereich wird dann an anderer Stelle in einem Interaktionsrahmen als eigenes Diagramm angegeben. Der UML-Standard erwartet, dass dem Namen des Interaktionsrahmens sd (für sequence diagram) vorangestellt wird. Beispiel:

Zeitliche Zusicherungen

Sofern die Abfolge von Nachrichten an bestimmte zeitliche Zusicherungen gebunden ist, können dies im Diagramm angegeben werden.

Zeitdauern zwischen Nachrichten werden über einen Doppelpfeil mit angegebenem guard, der nach UML-Notation in geschweiften Klammer stehen muss, angegeben (DurationConstraint).

Darüber hinaus können auch direkt an einzelnen Nachrichten zeitliche Festlegungen getroffen werden:

  • TimeObservation: es werden bestimmte Zeitpunkte definiert, z.B. wird der Zeitpunkt, zu dem eine Nachricht abgesendet wird mit t=now direkt neben der abgehenden Nachricht an der Lebenslinie notiert.

  • TimeConstraint: Zeitpunkte, an denen eine Nachricht eintrifft oder abgesendet werden soll können definiert werden - wie alle Constraints ist diese in geschweiften Klammern notiert. Wenn eine Nachricht 3 Sekunden nach dem oben festgelegten Zeitpunkt t abgesendet werden soll notiert man beispielsweise t+3s

Weitere Literatur zu UML-Sequenzdiagrammen

  • als Primärquelle: die UML Spezifikation der Object Management Group Definition des Standards, jedoch nicht für Endnutzer aufbereitet): https://www.omg.org/spec/UML

  • für den Einstieg: Martina Siedl, Marion Brandsteidl, Christian Huemer, Gerti Kappel: UML@Classroom, dpunkt Verlag, Heidelberg 2012 Gut zu lesende Einführung in die wichtigsten UML-Diagramme, Empfehlung für den Einstieg.

  • für Lesefaule: Die Vorlesungsreihe der Technischen Uni Wien (zu UML@Classroom) kann hier angeschaut werden (Videos, Folien): http://www.uml.ac.at/de/lernen

  • als Nachschlagewerk: Christoph Kecher, Alexander Salvanos: UML 2.5 – Das umfassende Handbuch, Rheinwerk Bonn 2015, ISBN 978-3-8362-2977-7 Sehr umfangreiches Nachschlagewerk zu allen UML-Diagrammen

  • als Cheatsheet: die Notationsübersicht von oose.de: https://www.oose.de/wp-content/uploads/2012/05/UML-Notations%C3%BCbersicht-2.5.pdf

  • UML und Software Engineering: Chris Rupp, Stefan Queins & die SOPHISTen: UML2 glasklar, Hanser Verlag, München 2012; ISBN 978-3-446-43057-0 Schwerpunkt: Einbindung von UML-Diagrammen in den Softwareentwicklungszyklus

  • Zur Zertifizierungs-Vorbereitung: M. Chonoles: OCUP 2 Certification Guide , Morgan Kaufmann Verlag, Cambridge 2018, ISBN 978-0-12-809640-6 Informationen zur Zertifizierung nach OMG Certified UML Professional 2™ (OCUP 2™): Foundation Level

Software zur Erzeugung von UML-Sequenzdiagrammen

Quellen und offene Ressourcen (OER)

Die Ursprungstexte (als Markdown), Grafiken und zugrunde liegende Diagrammquelltexte finden sich (soweit möglich in weiterbearbeitbarer Form) in folgendem git-Repository:

https://gitlab.com/oer-informatik/uml/umlsequenz.

Sofern nicht explizit anderweitig angegeben sind sie zur Nutzung als Open Education Resource (OER) unter Namensnennung (H. Stein, oer-informatik.de) freigegeben gemäß der Creative Commons Namensnennung 4.0 International Lizenz (CC BY 4.0).

Creative Commons Lizenzvertrag

Kommentare gerne per Mastodon, Verbesserungsvorschläge per gitlab issue (siehe oben). Beitrag teilen:

Tags:

You may also like...