In diesem Kapitel wird die Kurzbezeichnung Methode SD für alle Theorieelemente zur Erfassung und Darstellung von Sequenzen eingeführt.

10.1 Einführung

Für die UML-Autoren sind die in diesem Abschnitt vorgestellten Interaktionen (zu denen die Sequenzen gehören) partiell geordnete Ereignisfolgen (partially-ordered sequences of events) [OMG 2003a, S. 370].

Einordnung

Sequenzen als Interaktionen

Die Sequenzen gehören zur Gruppe der Interaktionen. Alle Interaktionen beschreiben Aktivitäten im Rahmen einer Aufgabenerfüllung und insbesondere den dafür notwendigen Nachrichtenverkehr. Folgende werden von den UML-Autoren angeführt:

Nachrichtenverkehr für Aktivitäten im Rahmen einer Aufgabenerfüllung

• Sequenzen mit Sequenzdiagrammen. Sie stellen den Nachrichtenaustausch zwischen einer Gruppe von Lebenslinien dar und sind die verbreitetste Variante.
• Interaktionsüberblicke mit Interaktionsüberblickdiagrammen. Sie sind eine Variante der Aktivitätsdiagramme und geben einen Überblick über den Kontrollfluss (vgl. Abschnitt 11.4.10).
• Kommunikationen mit Kommunikationsdiagrammen, die ebenfalls den Nachrichtenaustausch zwischen Lebenslinien zeigen, ergänzt um seine Reihenfolge. Diese wurden in Abschnitt 7.6 vorgestellt.

Zusätzlich und optional auch Timing Diagrams und Interaction Tables.

Allen ist gemeinsam, dass sie dynamische Aspekte des untersuchten Anwendungsbereichs beschreiben, genauer: Wechselwirkungen zwischen den Komponenten.

Dynamische
Teilaspekte

Typischerweise decken alle diese Arten von Interaktionen nur Teilaspekte ab, nicht die Gesamtheit des (System-)Geschehens im jeweiligen Anwendungsbereich [OMG 2003a, S. 403].

10.2 Grundlagen

Nach Aussage der UML-Autoren gehören Sequenzen zu den am meisten betrachteten Interaktionen und damit Sequenzdiagramme zu den am meisten verbreiteten Interaktionsdiagrammen. Sie geben durch die sogenannten Lebenslinien einen Hinweis auf die statische Struktur des Anwendungsbereichs (bzw. auf dessen Abbildung in die Klassenhierarchie des gesamten Anwendungsbereichs) und durch den Nachrichtenaustausch zwischen diesen und weiteren Modellelementen einen Einblick in wichtige dynamische Aspekte.

Der Aufbau der Sequenzdiagramme ist wie folgt (vgl. auch die folgende Abbildung):

• Ein Sequenzdiagramm besteht aus mehreren Lebenslinien, die miteinander Nachrichten austauschen und damit Abläufe modellieren.
• Eine Lebenslinie besteht aus einem Rechteck an der Spitze, das das handelnde Objekt angibt und einer darunter angeordneten senkrechten gestrichelten Linie.
• Die Lebenslinien eines Sequenzdiagramms stehen i.d.R. in gleicher Höhe nebeneinander. Ausnahmen sind die, die erst im Verlauf der Sequenz entstehen. Diese werden auf der Höhe angeordnet, auf der die Nachricht steht, durch die sie erzeugt werden (vgl. Abbildung 11.10-1 für ein Beispiel).
• Die Lebenslinie, die die Interaktion startet, wird i.d.R. ganz links angeordnet.
• Die gestrichelte Linie symbolisiert die Existenz eines Objekts während eines Zeitraums. Typischerweise für die Interaktion dann über die gesamte Länge. Vgl. für eine „verkürzte Lebenslinie auch Abbildung 11.10-1).
• Eine Säule, die über die gestrichelte Linie gelegt ist, gibt den Zeitraum an, in dem ein Objekt eine Aktion ausführt, entweder direkt oder durch ein nachgeordnetes Objekt. Diese Säule wird Kontrollfokus genannt.
• Zwischen den gestrichelten Linien bzw. den Säulen geben Pfeillinien die versendeten Nachrichten an. Diese sind, von oben nach unten, in zeitlicher Reihenfolge angeordnet. Die absolute Distanz ist aber ohne Bedeutung, d.h. es gibt keine Zeitmetrik.
• Zu einem Sequenzdiagramm gehört eine Umrahmung mit einer Bezeichnung links oben innerhalb des Rahmens mit dem Schlüsselwort sd.

Die vertikale Achse stellt somit eine Zeitachse dar, während in der horizontalen die Objekte angeordnet sind.

Vgl. Abschnitt 7.4 zur Definition und zum Aufbau von Lebenslinien

Insgesamt modelliert ein Sequenzdiagramm einen Ablauf (eher einen kürzeren als einen längeren, wegen der Übersichtlichkeit, die bei längeren leicht verloren ginge) über den Nachrichtenaustausch zwischen Objekten. Die Nachrichten verweisen auf (bzw. nutzen) die bei den Objektklassen hinterlegten Methoden.

Was wird modelliert?

Das Konzept ist damit im Herzen des objektorientierten Ansatzes angesiedelt, mehr als die oben besprochenen Aktivitäten. Denn das „Miteinander durch gegenseitigen Methodenaufruf“ ist von zentraler Bedeutung für die Aufgabenerledigung in der objektorientierten Theorie.

Im Herzen des
objektorientierten
Ansatzes

10.3 Einführende Beispiele

Auch hier sollen die Beispiele, die an Systeme erinnern, Systembeispiele genannt werden und die, die eher Geschäftsprozesse beschreiben, Prozessbeispiele.

System oder Prozess

10.3.1 Systembeispiel Mahnwesen

Anmerkung: Der Geschäftsprozess Mahnwesen ist in WebZumBuch_UM01 beschrieben und auch als Ereignisgesteuerte Prozesskette (EPK) modelliert. Außerdem findet sich dort eine Auflistung aller Modelle zu diesem Geschäftsprozess und eine Darstellung des Gesamtzusammenhanges.

Das folgende Sequenzdiagramm zeigt einen Ausschnitt aus dem Geschäftsprozess Mahnwesen und zwar den Teil, der – voll automatisiert – das Versenden von Zahlungshinweisen vornimmt.

Im Vorfeld ist bereits im Geschäftsprozess Zahlungseingangsüberwachung geklärt worden, dass ein Zahlungshinweis zu erstellen ist, um welchen Typ es sich handelt und welcher Kunde betroffen ist. Folgende Typen sind möglich:

• 1. Zahlungserinnerung
• 2. Zahlungserinnerung
• 1. Mahnung
• 2. Mahnung
• Übergabe an ein Inkassobüro

Der Client[1], d.h. der Programmteil, der in diesem Fragment den Kontrollfluss realisiert, liefert die Rechnungsnummer (der zu beanstandenden Rechnung) und die Festlegung, um welchen Zahlungshinweis es sich handelt. Dazu erzeugt er die Nachricht doErzZH (doErz(euge)­Z(ahlungs)­H(inweis)) mit den zwei Parametern (Attributen) rechnungsNr (Schlüssel der Rechnung) und zhTyp (Typ des Zahlungshinweises) und sendet sie an das Objekt (eigentlich Lebenslinie, vgl. Abschnitt 7.4) :Zahlungshinweise.

Zahlungshinweis erzeugen

Ein Objekt :Zahlungshinweise sendet dann die Nachricht erzZH() (erz(euge)­Z(ahlungs)­H(inweis)) an ein Objekt :Datenbank. Der Parameter datenstrukturZH (Datenstruktur Zahlungshinweis) enthält die Hinweise für die Gestaltung des Dokuments. Durch :Datenbank wird dann die Methode aufgerufen und – mit Hilfe der abgespeicherten Daten – der Zahlungshinweis als Datenstruktur erzeugt. Die Antwort auf diesen Methodenaufruf (deshalb der gestrichelte Pfeil) gibt den Schlüssel des Zahlungshinweises (zh_id) zurück.

Zahlungshinweis erstellen

Im Anschluss sendet :Zahlungshinweise eine Nachricht erzZHDok an :Dokumente mit der Aufforderung, das PDF-Dokument für den Zahlungshinweis zu erzeugen. Dies geschieht dort und der Schlüssel des PDF-Dokuments wird zurückgemeldet.

PDF-Dokument erzeugen

Anschließend sendet :Zahlungshinweise die Nachricht updateZHPdfId mit der Pdf_id an :Datenbank. Diese aktualisiert und meldet die erfolgreiche Aktualisierung zurück. Danach wird der Schlüssel des Zahlungshinweises (zh_id) an :Client zurückgemeldet.

Abschluss

Die Abbildung enthält u.a. folgende Komponenten:

• Mehrere synchrone Nachrichten
• Mehrere Antwortnachrichten zu Methodenaufrufen
• Mehrere Lebenslinien

Außerdem mehrere  Kontrollfokusse .

Das obige Beispiel ist, als Systembeispiel, sehr nahe an der Programmierung angesiedelt. Das SD gibt, in einer objektorientierten Lösung, einen aussagekräftigen Hinweis auf notwendige Klassen und ihre Methoden.

10.3.2 Prozessbeispiel Kaufabwicklung

Das folgende Beispiel zeigt die Abläufe rund um eine Kaufabwicklung als Sequenzdiagramm. Diese Abläufe stellen durchaus einen wahrnehmungswürdigen kleinen Geschäftsprozess dar.

In Abschnitt 11.12 wird dieses Sequenzdiagramm, im Rahmen der Prüfung der Eignung von Sequenzdiagrammen zur Prozessmodellierung, in eine Ereignisgesteuerte Prozesskette übertragen.

Dem Charakter von Sequenzdiagrammen entsprechend ist die Ablaufbeschreibung auf den Nachrichtenverkehr zwischen den (hier) zwei Partizipanten reduziert.

Alle kursiv gesetzten Texte mit ihren Pfeilen geben die Bezeichnungen wichtiger Modellelemente an und sind nicht Teil der UML.

Element-
bezeichnungen

In diesem Beispiel ist auch bei jedem Kontrollfokus angegeben, welche Tätigkeit stattfindet. Dies ist optional und in der UML nicht zwingend vorgeschrieben.

Beschreibung des Sequenzdiagramms

Hier wird für Aktivitäten im umgangssprachlichen Sinn der Begriff Tätigkeit verwendet, da der erstgenannte Begriff in der UML ja belegt ist.

Das Beispiel geht von zwei Unternehmen (Kunde und Lieferant) aus. Das eine hat einen Beschaffungswunsch, das andere soll ihn erfüllen.

Kunde und Lieferant

Grundsätzlich wird in dieser Branche ein Kaufvorgang als zweistufig angesehen. Zuerst erfolgt eine Voranfrage, die den Beschaffungswunsch grob umreisst. Nach deren Beantwortung wird im zweiten Schritt die detailliertere und aufwändigere Anfrage formuliert. Ansonsten nimmt diese Kaufabwicklung den üblichen Gang.

Alle Tätigkeiten beim Kunden und beim Lieferanten werden durch einen Kontrollfokus dargestellt, an dessen Ende die Nachrichtenübermittlung durch die Pfeillinie dargestellt ist.

Der Geschäftsprozess beginnt damit, dass beim Kunden eine Voranfrage vorbereitet wird (vgl. den obersten Kontrollfokus). Wenn dies geschehen ist, erfolgt die Nachrichtenübermittlung.

Start des Geschäftsprozesses

Beim potentiellen Lieferanten stößt dies die Tätigkeit Voranfrageantwort erstellen an, die wiederum mit einer Nachricht endet, dem Übersenden der Voranfrageantwort.

Auf der Basis dieser Antwort wird dann beim Kunden eine Anfrage erarbeitet, im Sequenzdiagramm wiederum durch den Kontrollfokus ausgedrückt. Am Ende dieser Bemühungen wird die Anfrage an den Lieferanten geschickt, hier modelliert als Nachricht Anfrage senden.

Der nächste Kontrollfokus gibt nun an, dass der Kunde das Angebot entgegennimmt und einen Auftrag vorbereitet. Am Ende dieser Tätigkeiten steht das Übersenden des Auftrags an den Lieferanten.

Auftrag senden

An dieser Stelle stört doch sehr, dass der Fall nicht berücksichtigt ist, dass das Angebot letztendlich doch nicht angenommen wird. Dies ist in einer Prozessmodellierung unabdingbar. Im folgenden Abschnitt wird vorgestellt, wie dieses Einbauen von Verzweigungen – wenn auch in bescheidenem Umfang – in Sequenzdiagrammen möglich ist. Dabei wird auch dieses Beispiel, ergänzt um eine Verzweigung, herangezogen.

Beim Lieferanten wird der Auftrag entgegengenommen und eine Auftragsbestätigung verschickt. Da dies beim Kunden keine unmittelbare Tätigkeit auslöst, ist nach dem Eintreffen dieser Nachricht kein Kontrollfokus eingefügt.

Auftragsbestätigung senden

Auch die nächste Nachricht kommt vom Lieferanten, wenn er den Auftrag erledigt hat und eine Liefermitteilung sendet. Die anschließende eigentliche Lieferung ist hier ebenfalls als Nachricht modelliert, sie ist ja auch Teil des Geschäftsprozesses.

Liefermitteilung

Beim Kunden wird dann die Lieferung geprüft und nach dem hoffentlich positiven Ergebnis der Eingang bestätigt. Dies löst beim Lieferanten die Rechnungserstellung und den Versand der Rechnung aus. In der letzten Tätigkeit dieser Sequenz wird beim Kunden die Zahlung vorbereitet und durchgeführt.

Lieferung prüfen
Eingang bestätigen
Rechnung senden
Zahlung

Der Charakter der gestrichelten Linie als einer Zeitachse, entlang derer die Tätigkeiten ablaufen, wird hier sehr deutlich. Ebenso, dass jede Nachricht Tätigkeiten beim anderen Partizipanten auslöst und dass am Ende derselbigen wieder eine Nachricht verschickt wird.

Was auch insgesamt und nicht nur wie oben schon angemerkt in einer bestimmten Situation auffällt, ist das Fehlen von Verzweigungen. Dies ist untypisch für Geschäftsprozesse und ihre Modelle. Dazu unten mehr.

Die Abbildung enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Zahlreiche synchrone Nachrichten
• Mehrere Lebenslinien

Außerdem mehrere  Kontrollfokusse .

Obige zwei Beispiele stellen die Grundstruktur von Sequenzdiagrammen dar. Im folgenden wird dies nun schrittweise erweitert und vertieft.

10.4 Vertiefung

10.4.1 Weitere Theorieelemente

Ereigniseintritte

In den Abschnitten 7.5 und 10.10 wurde schon kurz auf das Auftreten von Ereignissen (event occurrences), hier auch Ereigniseintritt oder Ereignisauftreten genannt, eingegangen. Dort wird mit diesem Konstrukt die Beziehung zwischen Ereignissen und Aktionen hergestellt, indem die UML-Autoren definieren, dass Ereigniseintritte Zeitpunkte darstellen, denen Aktionen zugeordnet sind.

Ähnlich hier bei den Sequenzen. Hier sind sie inhaltlich verknüpft mit den Nachrichten, die bei den Sequenzen eine wichtige Rolle spielen und repräsentieren den Beginn bzw. das Ende der Nachricht. Das erste wird auch sendender Ereigniseintritt genannt, das zweite empfangender Ereigniseintritt.

Sendend und
empfangend

Die folgende Abbildung erläutert dies grafisch. Das Element mit der Nummer (1) repräsentiert eine Nachricht. Am Startpunkt der Nachricht (Punkt (2)) und am Endpunkt (Punkt (3)) liegt jeweils ein Ereignisauftreten vor, ein sendendes bzw. ein empfangendes.

Traces

Da jede Nachricht durch zwei Ereignisauftritte zeitlich fixiert ist, kann eine Sequenz auch so gesehen werden, dass sie aus einer oder mehreren Folgen von Ereigniseintritten besteht. Dies wird nun von den UML-Autoren für ein weiteres Element in ihrem Theoriegebäude benutzt, den Traces (fig: Spuren). Als einen Trace bezeichnen sie eine Folge von Ereigniseintritten, natürlich zusammenhängenden, die damit einen Ablauf beschreiben. Ein Trace kann dann durch einen Ausdruck wie

Folgen von Ereigniseintritten

<eventoccurrence1, eventoccurrence2, ..., eventoccurrence-n>

dargestellt werden [OMG 2003a, S. 403].

Genau diese Traces bezeichnen die UML-Autoren als Semantik der Modellelemente, die durch die Traces beschrieben werden. Dies ist auf den ersten Blick eine gewagte Reduktion dessen, was üblicherweise unter Semantik verstanden wird. Auf den zweiten Blick ist es aber konsequent. Da es ja um die Beschreibung von Abläufen geht, sind Folgen von „Ereignissen“ eine sinnvolle Technik zur Beschreibung und dies kann durchaus auch als (wenngleich inhaltlich arme) Semantik verstanden werden.

Von
Ereigniseintritten über Traces zur
Semantik

Es geht noch weiter. Hat man schon mal Semantik über Folgen von Ereignissen definiert, kann man auch darüber nachdenken, solche Folgen auf die eine oder andere Weise zusammenzubringen (oder auch zu trennen). Es geht dann ja darum, die "Semantik“ der verschiedenen Elemente zu verschmelzen.

„Semantik-
Verschmelzung“

Dafür haben die UML-Autoren ein Konzept eingeführt, das sie interleaving nennen [Anmerkung] . Sie bezeichnen damit das Verschmelzen / Verschachteln mehrerer traces dergestalt, dass die Ereignisse verschiedener traces im neuen trace in beliebiger Reihenfolge auftreten, während die Ereignisse innerhalb desselben trace ihre Reihenfolge behalten [OMG 2003a, S. 403].

Verschmelzen

Dies ist tatsächlich sinnvoll. Stellen wir uns zwei Abläufe vor, die auf diese Weise zusammengeführt werden. Jeder einzelne Ablauf behält seine Struktur (seine Abfolge von Ereigniseintritten), bezüglich des entstehenden neuen Trace ist aber nicht festgelegt, wie die Ereigniseintritte der Ausgangs-Traces zueinander stehen. Der neue Trace „leistet“ also alle Abläufe der ursprünglichen, das Verhältnis zueinander bleibt aber offen.

Soweit einige Grundbegriffe, die von zentraler Bedeutung sind für Interaktionen und die deshalb hier vorab betrachtet wurden. Im folgenden nun die Vorstellung der Komponenten von Sequenzdiagrammen im Detail.

10.4.2 Nachrichten

Auf das Konzept der Nachrichten wurde schon in Kapitel 7, insbesondere Abschnitt 7.5 eingegangen. Hier deshalb nur einige zusammenfassende und vertiefende Ergänzungen.

In Sequenzen senden sich die Lebenslinien Nachrichten, wie in Kapitel 7 beschrieben, zur gemeinsamen Aufgabenerledigung. Bei Anwendungsbereichen für die ein Softwaresystem erstellt werden soll sind dies dann Objekte (Instanzen) von Klassen und die Nachrichten betreffen i.d.R. Methodenaufrufe. Hat der Ablauf Prozesscharakter stellen die Lebenslinien oftmals beliebige Partizipanten dar, die sich nicht im Softwaresystem finden, z.B. wie oben gesehen Kunden, Lieferanten, usw. Die Nachrichten stellen dann neben Koordinierungsinformation zwar auch Aufrufe von Tätigkeiten dar, aber natürlich nicht Methodenaufrufe.

In Systemen und Prozessen

Wie oben gesehen wird jede Nachricht in Sequenzdiagrammen durch jeweils eine beschriftete Pfeillinie zwischen den betreffenden Lebenslinien ausgedrückt. Die Pfeillinie gibt dann nicht nur an, von wem die Nachricht stammt und an wen sie adressiert ist, sondern ihre Gestaltung gibt weitere Eigenschaften der Nachricht an:

• Asynchrone Nachrichten haben eine Pfeilspitze ohne Füllung.
• Synchrone Nachrichten, die ja typischerweise Methodenaufrufe darstellen, werden mit einem gefüllten Pfeilkopf dargestellt.
• Die Antwortnachricht zu einem Methodenaufruf hat eine gestrichelte Linie.
• Eine Nachricht zur Objekterzeugung hat eine gestrichelte Linie mit einem nicht gefüllten Pfeilkopf.
• Verlorene Nachrichten (lost messages) werden durch einen kleinen schwarzen Kreis am Pfeilende gekennzeichnet. Die UML-Autoren definieren diese als Nachrichten, bei denen der Sender und Sendevorgang bekannt ist, nicht aber der Empfänger und Empfangsvorgang [OMG 2003a, S. 429 und S. 438].
• Gefundene Nachrichten werden durch einen kleinen schwarzen Kreis am Startpunkt der Nachricht gekennzeichnet. Die UML-Autoren definieren diese als Nachrichten, bei denen der Empfänger und Empfangsvorgang bekannt sind, nicht aber der Sender und Sendevorgang [OMG 2003a, S. 429 und S. 439].

Um das Aktivsein von Methoden mit Methodenaufrufen durch Nachrichten zu veranschaulichen wird in der grafischen Darstellung ein dünnes graues oder weisses Rechteck gewählt, das die gestrichelte Linie der Lebenslinie bedeckt, so lange die Methode aktiv ist.

Methodenaufrufe

Beispiele

Im folgenden Beispiel geht es um Nutzer eines Systems, die sich bei einem Kontrollsystem mittels einer PIN (Personal Identification Number) identifizieren müssen. Entweder ergibt diese Prüfung ein positives Ergebnis oder nicht.

Zugangssystem

Dafür werden zwei Lebenslinien und drei Nachrichten benötigt. Die Lebenslinien sind Nutzer und Zugangskontrolle.

Alle Nachrichten sind asynchron. Bei diesen kann es passieren, dass eine Nachricht A eine andere Nachricht B „überholt“, was schlicht bedeutet, dass A nach B eintrifft, obwohl die Reihenfolge auf der sendenden Lebenslinie umgekehrt ist. Auch dies zeigt das Beispiel. Die Nachricht KarteRaus überholt die Nachricht OK. Dadurch sind hier die empfangenden Ereigniseintritte in umgekehrter Reihenfolge gegenüber den sendenden.

Sich überholende Nachrichten

Eine vierte Nachricht (aufschließen) wird von der Zugangskontrolle an die Umwelt geschickt. Eine solche Stelle, über die der Kontakt zur Außenwelt (der Sequenz) realisiert wird, trägt die Bezeichnung Gate (vgl. Abschnitt 11.4.5).

Gate: Tor zur
Außenwelt

Das lokale Attribut PIN wird im oberen Bereich der Abbildung angegeben.

Die Abbildung enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Asynchrone Nachrichten
• Ein Gate
• Ein lokales Attribut

Außerdem ein Beispiel für das Überholen einer Nachricht durch eine andere.

10.4.3 Strukturieren durch kombinierte Fragmente

Aufbau

Der oben eingeführten Standardnotation von Sequenzdiagrammen fehlt eine wichtige Eigenschaft. Mit ihr ist es nicht möglich, den Nachrichtenverkehr zu strukturieren, um zum Beispiel aufgrund eines Ereignisses den einen oder den anderen Nachrichtenverkehr zu wählen. M.a.W.: Es ist nicht möglich zu verzweigen.

Dies haben auch die UML-Autoren bemerkt, und deshalb bei Sequenzdiagrammen ein entsprechendes Theorieelement eingefügt, die kombinierten Fragmente (combined fragments). Sie erlauben die Definition verschiedener Fragmente zum Nachrichtenverkehr (d.h. Gruppen von Nachrichten) und – im zeitlichen Ablauf der Nachrichtenaufrufe – die Anwahl des einen oder anderen. Vgl. zur grafischen Darstellung die Ausführungen unten sowie die folgende Abbildung 11.5-1 mit Anmerkungen.

Gruppen von
Nachrichten bilden und in Beziehung setzen

Dafür sind die folgenden Operatoren definiert, die Interaktionsoperatoren (interaction operators) genannt werden. In Klammern ist noch jeweils die Kurzbezeichnung angegeben, die in den grafischen Notationen verwendet wird:

• alternatives (alt)
• assertion (assert) 
• break (break) 
• critical region (critical) 
• ignore / consider (ignore) 
• loop (loop)
• negative (neg) 
• option (opt) 
• parallel (par) 
• reference (ref)
• strict sequencing (strict) 
• weak sequencing (seq) 

Eine Erläuterung der Interaktionsoperatoren folgt unten.

Die Operanden

Liegen Operatoren vor, dann muß es auch Operanden geben, die durch die Operatoren verarbeitet werden. Diese werden hier Interaktionsoperan­den (interaction operand) genannt.

Wenn also z. B. die Aufteilung in zwei Teile erfolgte, dann stellt die untere und die obere Hälfte jeweils ein Fragment dar und jedes ist ein Interaktionsoperand. Optional kann ein Fragment eine Interaktionseinschränkung haben, von den UML-Autoren auch Wächter genannt (vgl. die Anmerkungen unten).

Interaktionsoperanden werden durch eine gestrichelte horizontale Linie getrennt. Alle Interaktionsoperanden zusammen stellen das kombinierte Fragment dar. Vgl. die folgende Abbildung.

Grafische Darstellung

Bedingungen – Interaktionseinschränkungen

Bei allen mehrstelligen Interaktionsoperatoren muß es Bedingungen geben, die festlegen, wann welches Fragment wirksam wird. Vgl. z.B. im ersten Beispiel unten die Ausdrücke [x>0] und [else]. Diese werden textlich formuliert und Interaktionseinschränkung (interaction constraint) genannt.

Eine Interaktionseinschränkung ist also ein boolescher Ausdruck, der angibt, welcher Operand in einem kombinierten Fragment Gültigkeit hat, bzw. ob ein Operand „begangen wird“ oder nicht. Wegen diesem Hintergrund werden in den UML-Texten diese booleschen Ausdrücke oft auch als Wächter (guard) bezeichnet (ähnlich wie bei den Aktivitätsdiagrammen).

Die Darstellung im Modell erfolgt in textlicher Form in eckigen Klammern auf der Lebenslinie, dort wo der erste Ereigniseintritt des Fragments vorkommt.

Es versteht sich, dass in die Bestimmung der Semantik nur Interaktionsoperanden miteinbezogen werden, deren Interaktionseinschränkungen „wahr“ sind. Ist kein Wächter da, wird dies gleichgesetzt mit einem Wächter dessen Bedingungen erfüllt sind.

Semantik-
bestimmung

Grafische Darstellung von kombinierten Fragmenten

Für die grafische Darstellung dieser Fragmente wird der gesamte dem Interaktionsoperator unterworfene Bereich mithilfe eines Rechtecks umrandet.

Ein Operator und seine Operanden

Ist der Operator mehrstellig, wird dieses Rechteck mit einer horizontalen gestrichelten Linie unterteilt (oder mit mehreren), womit die kombinierten Fragmente entstehen. Jeder durch die Unterteilung geschaffene Bereich stellt dann einen Operanden dar.

Ein Operator im linken oberen Eck des Rechtecks (in einem Fünfeck) gibt die Art der Verknüpfung an (vgl. auch die folgende Abbildung). Als Operator kann einer der oben aufgelisteten dienen, mit durchaus sehr unterschiedlicher Bedeutung. Vgl. unten.

Es ist möglich, dass ein Sequenzdiagramm mehrere solche Interaktionsoperatoren enthält. Dies nicht nur hintereinander, entlang der Nachrichtenfolge, sondern auch verschachtelt (vgl. die Beispiele in den folgenden Abbildungen).

Mehr als ein Operator

Die Abbildung enthält u.a. folgende Komponenten:

• Ein kombiniertes Fragment
• Zwei Interaktionsoperanden
• Den Interaktionsoperator alternatives (alt)

Außerdem zwei Interaktionseinschränkungen, die bei diesem Interaktionsoperator Bedingungen für die Alternativen darstellen.

Die zweite Abbildung nimmt das Beispiel Kaufabwicklung von oben wieder auf. Hier wurde nun wenigstens eine Verzweigung, d.h. ein kombiniertes Fragment, eingebaut. Angenommen wurde, dass nach Zusendung des Angebots durch den potentiellen Lieferanten der Kunde entweder zusagt oder auch absagt.

Kaufabwicklung mit Verzweigung

Bei einer Absage wird diese erstellt (vgl. den Kontrollfkus ganz unten) und die entsprechende Nachricht zum potentiellen Lieferanten geschickt.

Absage

Obige Abbildung enthält u.a. folgende Komponenten:

Zusage

• Mehrere synchrone Nachrichten

• Ein kombiniertes Fragment
• Zwei Interaktionsoperanden
• Den Interaktionsoperator alternatives (alt)
• Mehrere Lebenslinien

Außerdem mehrere  Kontrollfokusse .

Falls das Angebot akzeptiert wird, ergibt sich derselbe weitere Fortgang wie oben (vgl. Abbildung 11.3-2).

10.4.4 Die Interaktionsoperatoren

Hier nun die vertiefte Erläuterung der Interaktionsoperatoren.

Alternatives

Der Interaktionsoperator alternatives (alt) legt fest, dass das Fragment erlaubt, Verhaltensalternativen zu modellieren. Genau einer der Operanden wird also ausgeführt. Der Operand, der zur Ausführung kommt, muss eine Interaktionseinschränkung haben, die an dieser Stelle der Interaktion wahr sein muss.

Verhaltens-
alternativen

Wie bei solchen Verzweigungen (um die handelt es sich eigentlich, wenn man vom modellierten Ablauf ausgeht) üblich, gibt es sehr oft eine Verzweigung die greift, wenn alle anderen scheitern. Sie wird mit Else bezeichnet.

Else-Verzweigung

Für Beispiele und die grafische Darstellung vgl. die Abbildungen 11.5-1 und 11.10-1.

Option (einstellig)

Der Interaktionsoperator option (opt) ist einstellig und legt folgende Wahlmöglichkeit fest: Entweder der einzige Operand kommt zur Ausführung oder nichts geschieht.

Für ein Beispiel und die grafische Darstellung vgl. Abbildung 11.4-7.

Break

Das mit dem Interaktionsoperator break bezeichnete Fragment wird im Bedarfsfalle an Stelle des gesamten Restes des Fragments aufgerufen. Es erlaubt den Abbruch des Fragments an dieser Stelle.

Abbruch

Parallel merge

Der Interaktionsoperator parallel merge (par) legt fest, dass das Fragment eine „parallele“ Verschmelzung (parallel merge) zwischen zwei Verhaltenskomponenten der Operanden darstellt. Die Ereigniseintritte der Operanden können auf beliebige Weise verschachtelt werden, solange die Reihenfolge, die durch jeden Operanden festgelegt ist, erhalten bleibt. Ein parallel merge definiert eine Menge von traces, die den Weg beschreiben, die Ereigniseintritte der Operanden zu verschachteln ohne dass die Ordnung der Ereigniseintritte im Operanden zerstört wird.

Verschmelzung 1

Für ein Beispiel und die grafische Darstellung vgl. Abbildung 11.5-3.

Weak sequencing

Der Interaktionsoperator seq legt fest, dass das Fragment die beiden Operanden auf eine bestimmte Art und Weise, dem sog. weak sequencing, verbindet. Folgende Eigenschaften gelten dafür:

Verschmelzung 2

• Die Abfolge der Ereigniseintritte in jedem der Operanden wird im Ergebnis beibehalten.
• Ereigniseintritte auf verschiedenen Lebenslinien von verschiedenen Operanden können in beliebiger Reihenfolge sein.
• Ereigniseintritte auf derselben Lebenslinie von verschiedenen Operanden sind so sortiert, dass ein Ereigniseintritt des ersten Operanden vor dem des zweiten Operanden kommt.

Es handelt sich also um eine einfache sequentielle Abfolge, die auf einer Lebenslinie die Einhaltung der Reihenfolge erzwingt, diejenige zwischen Elementen verschiedener Lebenslinien aber offen lässt.

Damit wird weak sequencing zu einem parallel merge, falls die Operanden auf elementfremden (sich nicht überschneidenden) Elementen aufbauen. Es fällt auf strict sequencing (vgl. unten) zurück, falls die Operanden nur auf einer einzelnen Menge von Elementen arbeiten.

Vgl. für ein Beispiel zu weak sequencing Abbildung 11.4-13-2.

Strict sequencing

Der Interaktionsoperator strict sequencing (strict) legt fest, dass bei einer Zusammenführung mehrerer Traces jeder Ereigniseintritt seine Position auf der Lebenslinie gegenüber den anderen behält. Alle beteiligten Lebenslinien werden zusammen betrachtet. Damit hat jeder Ereigniseintritt und jede Nachricht eine bestimmte Position, die beibehalten wird.

Verschmelzung 3

Die senkrechte Dimension (die Zeitachse) behält also ihre Gültigkeit über das ganze Fragment hinweg und nicht nur für die einzelne Lebenslinie.

Negative

Der Interaktionsoperator negative (neg) legt fest, dass das Fragment Traces repräsentiert, die als ungültig deklariert sind. Er ist einstellig.

Critical Region

Der Interaktionsoperator critical region (critical) kennzeichnet ein einzelnes Fragment und legt fest, dass in diesem die Traces nicht verschachtelt sein dürfen.

Sofort auszuführen

Das folgende Beispiel veranschaulicht dies am Beispiel von Notrufen. Ein 911-call muss (bzw. musste) (in den USA) unmittelbar weitergegeben werden, vor allen anderen Anrufen. Die übrigen Anrufe können dagegen beliebig – entsprechend dem Interaktionsoperator par – verarbeitet werden.

Die Abbildung enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Mehrere kombinierte Fragmente
• Einen Interaktionsoperator par(allel)  mit drei kombinierten Fragmenten.
• Den Interaktionsoperator critical

Außerdem zwei verschachtelte kombinierte Fragmente (critical in par).

Ignore / Consider

Der Interaktionsoperator ignore / consider legt fest, dass es Nachrichten gibt, die im jeweiligen Fragment nicht aktiv werden dürfen.

Aktiv oder auch nicht

Umgekehrt legt consider fest, welche Nachrichten im jeweiligen Fragment beachtet werden sollen. Damit erhalten alle anderen Nachrichten im Fragment den Status „ignorieren“.

Für ein Beispiel und die grafische Darstellung vgl. Abbildung 11.4-9.

Assertion

Der Interaktionsoperator assertion (assert) legt fest, dass der im Fragment angegebene Nachrichtenverkehr auf jeden Fall stattfindet. Assertions sind oft kombiniert mit Ignore / Consider.

Für ein Beispiel und die grafische Darstellung vgl. Abbildung 11.4-9.

Loop (einstellig)

Der Interaktionsoperator loop legt fest, dass das Fragment eine Schleife repräsentiert. Der Schleifenoperand wird mehrfach wiederholt. Die Interaktionseinschränkung kann sowohl eine untere und obere Grenze für die Wiederholungen enthalten als auch einen Booleschen Ausdruck.

Das loop-Konstrukt repräsentiert eine rekursive Anwendung des seq-Operators, wo die Ergebnisse der einzelnen Schritte (der Iterationen) des loop-Operanden in eine sequentielle Abfolge gebracht werden.

Die Darstellung ist textlich. Die Syntax des loop-Operanden ist wie folgt:

Darstellung

loop [ ‘(‘ <minint> [, <maxint> ] ‘)’ ]

<minint> ::= natürliche Zahl, d.h. positive ganze Zahl

<maxint> ::= natürliche Zahl größer oder gleich <minint> | ‘*’

Einschätzung

Während das Konzept – strukturierte Sequenzdiagramme – sehr sinnvoll, ja sogar notwendig anmutet, ist die grafische Realisierung unhandlich. Wie soll dies bei komplexeren Abläufen funktionieren? Dass es aber zumindest bei überschaubaren Problemstellungen funktioniert, zeigen die Beispiele in diesem Kapitel.

Unhandlich

10.4.5 Gates

Dieses Modellelement spielte schon bei den Aktivitäten eine Rolle (vgl. Kapitel 10). Genau wie dort ist ein Gate eine Verknüpfungsstelle, an der eine Nachricht von außerhalb eines Fragments mit einer Nachricht innerhalb in Beziehung gebracht wird.

Festlegung
Nachrichtenverkehr

Die Gates werden durch einen Namen identifiziert (falls festgelegt) oder durch einen konstruierten Bezeichner, der durch Aneinanderhängen der Richtung der Nachricht und dem Nachrichtennamen (z.B. out_CardOut) gebildet wird.

Bezeichnung

Aufgabe der Gates und der Nachrichten zwischen diesen ist es, für jede Nachricht den konkreten Sender und Empfänger klarzustellen.

Gates sind Punkte auf dem Rahmen des Sequenzdiagramms, die Endpunkte der Nachrichten. Ihnen kann eine Bezeichnung zugewiesen werden. Dasselbe Gate kann mehrfach vorkommen, in derselben Abbildung oder in verschiedenen.

Darstellung

In der folgenden Abbildung ist an der  Position (1) das Gate, hervorgerufen durch eine Nachricht, die durch ein Ereignisauftreten an Punkt (2) ausgelöst wird.

10.4.6 Interaktionen – noch einmal

Zu Beginn dieses Kapitels wurden Interaktionen schon als abstrakte Klasse eingeführt, deren eine Subklasse Sequenzen in diesem Kapitel betrachtet wird. Inzwischen sind so viele Begriffe eingeführt, dass das abstrakte Konzept der Interaktionen vorgestellt werden kann.

Die UML-Autoren definieren wie folgt:

Eine Interaktion ist eine Verhaltenskomponente die den beobachtbaren Austausch von Informationen zwischen verknüpfbaren Elementen beschreibt ([OMG 2003a. S. 419] Übersetzung durch den Verfasser).

Verhalten ist ja nicht an sich da, sondern bedarf eines Trägers. Für die UML-Autoren sind das die Classifier: Interaktionen sind Verhaltenseinheiten eines sie umschließenden Classifiers. Interaktionen konzentrieren sich somit – etwas konkreter – auf den Informationsaustausch durch Nachrichten zwischen den verknüpfbaren Elementen des Classifiers.

Träger von Verhalten

Hinweis: In WebZumBuch_UM03 wird am Beispiel der Interaktionen die Metamodellierung der UML-Autoren erläutert.

Für alle Interaktionsdiagramme gilt, dass sie in einem Rechteck mit durchgezogenen Linien dargestellt werden. Im linken oberen Eck wird in einem Fünfeck das Schlüsselwort (meist sd für Sequenzdiagramm) der Interaktionsname und die Parameter angegeben. Innerhalb des Rechteck folgt die spezifische Notation für die Untertypen.

Grafische Darstellung von Interaktionen

In diesem Kapitel werden Sequenzdiagramme und, in Abschnitt 11.4.10, Sequenzdiagramme mit zeitlichen Festlegungen sowie Interaktionsüberblicksdiagramme vorgestellt. Kommunikationsdiagramme werden in Abschnitt 7.6 beschrieben.

10.4.7 Verweise auf andere Sequenzdiagramme

Man stelle sich vor, es gäbe einen Teil einer Interaktion, der in mehreren umfangreicheren Interaktionen genutzt werden kann. Dann kann er ausgelagert werden und an seiner Stelle kann ein Platzhalter stehen. Für dieses Konzept steht in der UML das Interaktionsauftreten (interaction occurrence). Konkret ist damit in der grafischen Darstellung das Element gemeint, das vom übergeordneten Sequenzdiagramm auf das untergeordnete verweist.

Erinnerung: Sequenzdiagramme sind Interaktionen

Dies ist eine Standardtechnik in jeder Theorie zur Ablaufmodellierung, vgl. zum Beispiel die Prozesswegweiser in Ereignisgesteuerten Prozessketten.

Die untergeordnete Interaktion kann in verschiedenen übergeordneten mit unter Umständen ungleichen Anbindungen eingesetzt werden. Da diese An- oder Einbindung hier durch Gates realisiert wird, ist es so, dass ein Interaktionsauftreten eine Menge aktueller Gates hat, die den formalen Gates der Interaktion, auf die sie sich bezieht, entsprechen müssen.

Aktuelle Gates für formale Gates

Die Semantik eines Interaktionsauftreten ist wiederum einfach durch die Traces der einzubindenen Interaktion gegeben.

Grafische Darstellung

Das Interaktionsauftreten wird wie ein kombiniertes Fragment dargestellt mit dem Interaktionsoperator ref.

Beispiel

In der folgenden Abbildung sind zwei Beispiele für ein Interaktionsauftreten enthalten: ÖffneTür und VerbindungHerstellen. Beide sind als kombinierte Fragmente mit ref dargestellt. Diese stellen jeweils eigene Interaktionen dar, die an anderer Stelle spezifiziert sind.

Die Abbildung enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Zwei Verweise auf andere Interaktionen bzw. Sequenzdiagramme (Interaktionsauftreten).

• Den Interaktionsoperator ref mit dem die Verweise gekennzeichnet sind.
• Den Interaktionsoperator opt.

Außerdem zwei verschachtelte kombinierte Fragmente mit den Interaktionsoperatoren opt und ref.

10.4.8 Zustandseinschränkung und Stop

Eine Zustandseinschränkung (state invariant) ist eine Einschränkung für den Zustand einer Lebenslinie. Dabei sind hier mit Zustand auch die Werte eventueller Attribute der Lebenslinie gemeint.

Festlegungen

Die Einschränkung wird zur Laufzeit(!) geprüft. Und zwar unmittelbar vor der Ausführung des nächsten Ereignisauftretens. Wenn die Bedingung wahr ist, ist der folgende Trace gültig, falls die Bedingung nicht erfüllt ist, ist der Trace in diesem Durchgang ein ungültiger Trace.

Anmerkung: Die Wortwahl Laufzeit der UML-Autoren zeigt, dass dieses Merkmal in Richtung Programmierung zielt. Es ist aber natürlich auch ohne Schwierigkeit in Prozessabläufen denkbar.

Darstellung

Die Darstellung erfolgt entweder in Textform, in geschweiften Klammern auf der Lebenslinie oder als Notiz bei einem Ereigniseintritt. Vgl. Abbildung 11.4-9 für je ein Beispiel.

Ganz gleich wie bei den Aktivitäten gibt es hier ein Element, Stop, das etwas beendet. Hier ist Stop ein Ereignisauftreten, das das Ende der Existenz einer Instanz signalisiert, einer Instanz der Lebenslinie, auf der das Stoppsymbol erscheint. Die grafische Darstellung erfolgt durch ein Kreuz in Form eines X am Ende der Lebenslinie. Vgl. Abbildung 11.4-8 für ein Beispiel.

Stop

10.4.9 Weitere Beispiele

In Ergänzung zu den obigen Beispielen, die jeweils auf ein bestimmtes Modellelement bzw. eine bestimmte Modellstruktur bezogen waren, hier noch einige umfassendere Beispiele.

Sequenzdiagramm AbstraktesBeispiel

Das erste Beispiel stammt aus [OMG 2003a]. Es ist inhaltslos gehalten, wohl um möglichst viele Elemente von Sequenzdiagrammen unterzubringen. Trotzdem ist es erkennbar ein Systembeispiel. Hier sind tatsächlich fast alle Elemente der Methode SD angeführt.

Die vier Lebenslinien, bezeichnet mit ob1:C1, ob2:C2, ob3:C3 und ob4:C4 in diesem (System-)Beispiel zeigen es wiederum deutlich: Typischerweise bestehen Lebenslinien in der Vorstellung der UML-Autoren aus Objekten (Instanzen) von Klassen. Das gerät etwas in Vergessenheit, wenn man die vielen Geschäftsprozessbeispiele sieht, muss aber immer bedacht werden (vgl. auch Abschnitt 11.12).

Klassen bzw. Objekte (Instanzen)

Hier sind es die Objekte ob1 der Klasse C1, ob3 von C3 und ob4 von C4. Die Lebenslinien sind grafisch auf derselben Höhe angeordnet, mit Ausnahme derjenigen, die erst bei der Abarbeitung entsteht. Dies ist hier ob2:C2. Es wird also angenommen, dass die von ob1:C1 kommende Nachricht create die gleichnamige Methode in C2 aufruft, die wiederum dann ob2 erzeugt.

Das Beispiel weist auch darauf hin, dass Sequenzen und ihre Diagramme mit dem restlichen System direkt verknüpft sein können. Dies geschieht durch einen Pfeil von der Randlinie aus zur ersten Lebenslinie, hier mit opti beschriftet.

Aufruf von außen

Es zeigt auch Beispiele für das Anzeigen der aktiven Phase einer Lebenslinie (eigentlich: aktive Phase der Methode). Der Balken, der dafür über die Lebenslinie gelegt ist, wird gezeichnet ab dem Ereigniseintritt, der die Methode aktiviert und bis zu ihrem Ende. Im Falle, dass eine Lebenslinie fast immer aktiv ist, wird sie – wie hier bei ob1:C1 – auch ganz durchgezogen.

Kontrollfokus

Bei verschachtelten Aufrufen (wie hier bei foo und doit im oberen Fragment und bei bar und doit im unteren) wird die „oberste“ aufrufende Lebenslinie auch als aktiv angenommen, wenn die danach kommende die dritte Lebenslinie aufruft und dort Verarbeitung stattfindet.

Verschachtelte Aufrufe

Die Länge des Balkens hat keine inhaltliche Bedeutung, sondern wird nur aus den Notwendigkeiten der Grafik heraus gestaltet.

Im Beispiel enthalten ist auch ein kombiniertes Fragment mit dem Interaktionsoperator alt(ernative) und zwei Interaktionsoperanden. Dadurch entsteht im Ablauf eine Verzweigung, die durch die zwei Interaktionseinschränkungen [x>0] und [else] präzisiert ist.

Kombiniertes Fragment

Das Beispiel enthält synchrone und asynchrone Nachrichten. Die Nachricht create ist asynchron, was hier auch möglich ist, da keine unmittelbare Antwort erwartet wird.

Nachrichten – synchron und asynchron

Dagegen ist die nächste Nachricht foo(foo_par=x) synchron, da sie einen Methodenaufruf darstellt, der zur einer Antwort führt. Damit kann man dann auch Methodenaufrufe sinnvoll verschachteln, wie es hier mit doit(z) geschieht. Dieser ganze Abschnitt ist dann mit der Rückmeldung foo(_) beendet.

Angegeben sind auch verschiedene Varianten von Parameterübergaben. Zum einen die Angabe eines Parameters, der – typischerweise – ein Attribut eines Datenbestandes darstellt (in foo(foo_par=x), doit(z), bar(x), mit einer Methodenantwort (als x=bar(_):15), mit Rückantworten, die ohne Parameter erfolgen (in doit(_) usw.), durch die aber die Erledigung signalisiert wird.

Parameterübergabe

Objekt 2 von Klasse 2, das ja erst bei der Abarbeitung entsteht, wird auch gleich wieder vernichtet, was durch das Element stop am Ende der Lebenslinie ob2:C2 angezeigt wird.

Element Stop

Im Beispiel sind zahlreiche Antworten auf Methodenaufrufe angegeben. Sie werden ja durch eine gestrichelt Linie und eine nicht gefüllte Spitze dargestellt.

Nachrichten als Antworten auf Methodenaufrufe

Typischerweise sind sie Teil eines „synchronen Szenarios“:

• Senderobjekt schickt eine Nachricht mit Methodenaufruf und wartet.
• Empfängerobjekt(-klasse) führt Operation aus.
• Empfängerobjekt/-klasse sendet Rückantwort.
• Senderobjekt setzt sein Tun fort.

Diese Rückantworten können Parameterwerte zurückgeben oder auch nur den Abschluss der durchgeführten Operation melden.

Die Abbildung enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Ein kombiniertes Fragment (auf der Basis des Interaktionsoperator alt)
• Den Interaktionsoperator alt
• Zwei Interaktionseinschränkungen ([x > 0]  und [else])
• Zwei Interaktionsoperanden
• Ein Element zur Beendigung der Existenz einer Instanz (stop)
• Mehrere Ereigniseintritte

Außerdem wird das Erzeugen eines Objektes (ob2:C2) in der Sequenz gezeigt. Seine Existenz endet dann auch innerhalb der Sequenz, wozu das Element Stop dient.

Interaktion / Sequenzdiagramm M

Das folgende ebenfalls abstrakte Beispiel zeigt wiederum ein Sequenzdiagramm mit weiteren Komponenten.

Der ignore-Aspekt ist bei der Bezeichnung des Sequenzdiagramms vermerkt und legt hier fest, dass die Nachrichten t und r ignoriert werden. Beim Interaktionsfragment consider ist bei der Bezeichnung festgehalten, dass die Nachrichtentypen q, v und w betrachtet werden.

Interaktionsoperator ignore / consider.

Motiv für dieses Theorieelement sind Testsituationen [OMG 2003a, S. 442]. Wenn ein System, bei dem grundsätzlich im betrachteten Abschnitt die Nachrichtentypen q, r, t v und w vorkommen, dahingehend getestet wird, dass t und r ignoriert, q, v und w aber zugelassen werden sollen, dann kann dies so wie unten angegeben im Modell ausgedrückt werden.

Nachrichten ausklammern

Im kombinierten Fragment consider ist ein weiteres Fragment des Typs assert enthalten. Dieses stellt sicher, dass der in ihm angegebene Informationsaustausch auf jeden Fall realisiert wird. Hier also das Übersenden der Nachricht q und das Wirksamwerden der Zustandseinschränkung {Y.p == 15}.

Interaktionsoperator assert

Im Beispiel sind auch zwei Zustandseinschränkungen enthalten, die eine in Textform mit geschweiften Klammern, die andere als Notiz (myState). Sie werden, wie oben ausgeführt, zur Laufzeit geprüft und zwar direkt vor dem ersten Ereigniseintritt, das auf Y nach der Zustandseinschränkung erscheint.

Zustandseinschränkungen

Die beiden Interaktionsfragmente assert und consider sind verschachtelt. Das Interaktionsfragment mit assert ist in dem mit consider enthalten. Das bedeutet, dass erwartet wird, dass die Nachricht q vorkommt, wenn vorher eine Nachricht v aufgetreten ist.

Verschachtelte Fragmente

Obige Abbildung enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Einen Interaktionsoperator ignore / consider
• Eine Zustandseinschränkung mystate
• Ein kombiniertes Fragment assert  
• Ein Interaktionsfragment mit dem Operator assert

Außerdem zwei ineinander verschachtelte Fragmente.

Abgleich Zahlungseingang

Das folgende Beispiel entstammt dem Awendungsbereich Mahnwesen. Es modelliert den Abgleich eingehender Zahlungen mit den offenen Posten und ist ein realitätsnahes (System-)Beispiel, bei dem auch die Aufgabe der Vorbereitung der Programmierung deutlich zu erkennen ist.

Hier wurde bewusst eine Verzweigung eingefügt, um deren Realisierung im Kontext der Sequenzdiagramme nochmals zu zeigen. Dies soll auch deutlich machen, dass eine breiterer Bedarf an Verzweigungen grafisch kaum zu schultern wäre.

Wir wollen wieder annehmen, dass ein Programm bzw. eine Methode einer Klasse (der Client, vgl. hierzu Abschnitt 11.3-1) die Steuerung übernimmt, sozusagen also den Kontrollfluss realisiert.

Client

Der Client fordert :Zahlungseingänge auf, evtl. neue Zahlungseingänge zu melden, einen nach dem anderen. Zurückgemeldet wird ein Schlüssel des Zahlungseingangs.

ze_id: Zahlungseingangs-
schlüssel

Mit der Nachricht (dem Methodenaufruf) doZahlungsabgleich wird dann die Bearbeitung des jeweiligen Zahlungseingangs begonnen. Nacheinander werden der Datensatz und der Buchungstext gelesen. Danach erfolgt der Abgleich mit den Rechnungen. Dies leistet die Methode abgleichRechnungen() mit den Parametern Rechnungsnummer (r_nr), Kundenschlüssel (k_id) und Buchungskontennummer (bk_nr). Folgende Ergebnisse sind hier dann möglich:

Aufruf der eigenen Methoden

• Die Zahlung ist in Ordnung.
• Es handelt sich um eine Rücklastschrift.
• Die Zahlung ist unklar, d.h., sie kann nicht zugeordent werden.

In der Abbildung is die entsprechende Verzweigung eingebaut.

Falls es sich um eine ordnungsgemäße Zahlung handelt wird die Methode doZahlungOk() aufgerufen. Sie stößt das Verbuchen der Rechnung an (mit Hilfe eines Objekts :Datenbank) und führt die notwendigen Änderungen bei den Buchungskontotransaktionen durch. Zurückgeliefert wird der Transaktionsschlüssel (ergebnis).

Zahlung in Ordnung

Verbuchen und Transkationen bereinigen

Falls es sich um eine Rücklastschrift handelte, wird die Methode zur Rücklastschriftenbearbeitung angestoßen (doRücklastschrift()). Diese ver­merkt zuerst die Tatsache der Rücklastschrift im Buchungskonto. Anschließend wird eine Mail generiert (aus vorgefertigten Textbausteinen) und an das Büro geschickt, das solche Fälle bearbeitet. Die Bearbeitung geht dann dort – nicht automatisiert – weiter. Dieser Abschnitt endet dann wie oben mit der Klärung der Transaktions_id und der Antwort auf den Methodenaufruf (ergebnis).

Rücklastschrift:
Überweisung wurde zurückgeholt

Im dritten Teil werden unklare Zahlungen durch die Methode doZahlungUnklar() bearbeitet. Als erstes wird geklärt, woher die Unklarheit rührt. Danach wird möglichst viel Information gesammelt.

Zahlung ungültig

Falls die Rechnungsnummer (r_nr) festgestellt werden kann, wird diese festgehalten. Durch Abgleich der verfügbaren Daten erfolgt dann eine vertiefte Ursachenforschung. Mögliche Ursachen sind:

• Die in der Überweisung angebene Rechnungsnummer ist falsch. An­sonsten kann der Vorgang geklärt werden.
• Der Kunde ist unbekannt.
• Der Überweisungsbetrag stimmt nicht mit dem Rechnungsbetrag überein.

Kann der Kunde festgestellt werden, versucht das Programm folgende Informationen zusammenzustellen:

Informationen sammeln

• Kundennummer
• Kundenname
• Ort
• Straße

Kann der Vorgang identifiziert werden, werden Auftragsnummer, Datumsangaben, Positions- und Gesamtsummen festgestellt.

Anschließend wird eine Mail erzeugt, in der die Ursache der Unklarheit dargelegt wird und in der alle verfügbaren Informationen zusammengestellt sind. Diese Mail wird wiederum an das Büro geschickt, das diese Fälle bearbeitet (Reklamationsbüro).

Mail mit Unklarheiten

Die Abkürzungen in der Abbildung bedeuten:

• bk_nr: Buchungskontennummer
• buch_trans: buchungskonto_transaktionen
• k_id: Kundenschlüssel
• r_nr: Rechnungsnummer
• ZE: Zahlungseingang
• ze_id: ZahlungseingangsId

Obige Abbildung enthält u.a. folgende Komponenten:

• Mehrere synchrone Nachrichten

• Ein kombiniertes Fragment
• Drei Interaktionsoperanden
• Den Interaktionsoperator alternatives (alt)
• Mehrere Lebenslinien
• Außerdem mehrere Kontrollfokusse .

Außerdem handelt es sich um ein ausgeprägtes Systembeispiel.

10.4.10 Zeitaspekte und Interaktionsüberblicke

Zeitaspekte in Sequenzdiagrammen

Wie in den obigen Abschnitten zu sehen war, spielen konkrete Zeitaspekte in Sequenzdiagrammen keine Rolle. Deshalb hier einige Ergänzungen, die es ermöglichen, Zeitaspekte zu berücksichtigen.

Diese Ergänzungen werden benutzt, wenn der Hauptzweck des Diagramms ist, zeitliche Aspekte darzustellen. Sie stellen Veränderungen im Zeitablauf auf einer Lebenslinie oder zwischen Lebenslinien dar. Der Schwerpunkt liegt dabei auf dem Zeitpunkt des Eintretens von Ereignissen, die zu Veränderungen in den erfassten Rahmenbedingungen der Lebenslinien führen.

Zeitaspekte

Die folgende Abbildung zeigt ein Beispiel, ein ganz normales Sequenzdiagramm mit zusätzlichen Festlegungen zeitlicher Aspekte. Es enthält zwei Lebenslinien, Nutzer und Zugangskontrolle, gedacht ist wieder an einen Geldautomaten.

Der Nutzer sendet einen message Code, als Parameter ist eine Zeiteinheit angegeben.

Die Zugangskontrolle sendet zwei Nachrichten zurück zum Nutzer. Dabei ist hier im Modell festgelegt, dass KarteRaus zwischen 0 und 13 Zeiteinheiten benötigen darf. Darüberhinaus darf die Spanne zwischen dem Senden des Codes und dem Empfang des OK nur zwischen d und 3*d benötigen: {d..3*d}.

Bei der Nachricht OK wird der Entstehungszeitpunkt festgehalten (t=now). Durch {t..t+3} wird dann noch die Zeitspanne bis zum Empfang der Nachricht KarteRaus festgelegt.

Wie ja auch im gleich strukturierten Beispiel von Abbildung 11.4-2 zu sehen ist, kann hier die Nachricht KarteRaus die Nachricht „Alles in Ordnung“ (OK) überholen, was bedeutet, dass sie zwar früher startet, aber später ankommt.

Überholen

Die obige Abbildung enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Mehrere zeitliche Festlegungen
• Überholen von Nachrichten

Außerdem eine Nachricht, die nach außen führt (Gate).

Interaktionsüberblicke

Das folgende Modellelement – Interaktionsüberblicke – und seine grafische Umsetzung wurde von den UML-Autoren entwickelt, um durch Kombination von Komponenten aus verschiedenen Modelltypen (Sequenz- und Aktivitätsdiagrammen) den Kontrollfluss besser erfassen zu können und einen größeren Überblick zu erhalten [OMG 2003a, S. 447]. Grundsätzlich beschreiben diese Modelle aber Interaktionen.

Die Knoten in diesen Diagrammen sind Interaktionen oder Verweise auf Interaktionen (erkennbar am Interaktionsoperator ref). Die Lebenslinien und die Nachrichten erscheinen bei dieser Überblicksdarstellung nicht, die Lebenslinien können bei der Benennung des Diagramms angeführt werden.

Knoten aus
Interaktionen bzw.
Interaktions-
auftreten

Im Vergleich zu Aktivitätsdiagrammen ergeben sich folgende Unterschiede:

• An der Stelle von Objektknoten in den Aktivitätsdiagrammen gibt es hier nur Interaktionen oder Verweise auf Interaktionen.
• Kombinierte Fragmente mit dem Interaktionsoperator alternative (alt) werden durch eine Verzweigung (entsprechend einem exklusiven Oder; vgl. Kapitel 10 Aktivitäten) und eine damit zusammenhängende Zusammenführung repräsentiert.
• Kombinierte Fragmente mit dem Operator parallel (par) werden durch eine Gabelung (entsprechend einem logischen UND) und eine entsprechende Vereinigung repräsentiert.
• Kombinierte Fragmente mit dem Operator loop werden durch einfache Schleifen repräsentiert.
• Verzweigungen und das Zusammenführen von Zweigen muss durch eine geeignete Verschachtelung dargestellt werden.

Die folgende Abbildung zeigt ein Beispiel. Sie ist inhaltlich angelehnt an Abbildung 11.4-7.

Als erstes erscheint nach dem Startknoten die Interaktion VerbindungHerstellen mit dem Argument „Falsche PIN“. Der Interaktionsoperator ref zeigt, dass es sich um einen Verweis auf eine andere Interaktion handelt.

Verweis

Die Zeitangabe 0..25 gibt, wie im vorigen Abschnitt vorgestellt, die zur Verfügung stehende Zeitdauer für den Vorgang an.

Es folgt eine Interaktion (genauer: ein Sequenzdiagramm) mit den beiden auch in der Bezeichnung genannten Lebenslinien und mit der Nachricht KarteRaus. Eine solche fragmentarische, einen in sich geschlossenen Ablauf modellierende Interaktion, wird als inline-Interaktion bezeichnet.

Inline-Interaktion

Danach folgt eine Verzweigung mit einem exklusiven Oder. Diese wird hier, wie oben ausgeführt, als Verzweigung eingefügt. Ein Zweig hat die Interaktionseinschränkung [pin ok]. Bei ihm folgt eine weitere inline-Interaktion mit der Nachricht Msg(„Bitte eintreten“) und den beteiligten Lebenslinien. Den Abschluss bei diesem Zweig bildet wieder ein Interaktionsauftreten mit dem Verweis auf eine Interaktion TürÖffnen. Auch hier ist wieder eine zeitliche Festlegung getroffen.

Pin ok
oder nicht

Der andere Zweig mit der Interaktionseinschränkung [else] führt gleich zum Schlussknoten.

Für den Zusammenhang zwischen dem ersten und zweiten Element und dann von der zweiten Inline-Interaktion zum Interaktionsauftreten (also für alle sequentiellen Abfolgen ohne Operator) sprechen die UML-Autoren von weak sequencing. D.h., auf einem Zweig wird die Abfolge der Elemente eingehalten, die zwischen Elementen verschiedener Zweige aber nicht unbedingt (vgl. Abschnitt 11.4-4).

Operator seq:
weak sequencing

Die Abbildung enthält u.a. folgende Komponenten bzw. Besonderheiten:

• Zwei Inline-Interaktionen
• Zwei Interaktionsauftreten (Verweise auf andere Interaktionen, hier Sequenzdiagramme) mit dem Interaktionsoperator ref
• Angaben zum Zeitverbrauch
• Einen Operator Verzweigung (von Aktivitätsdiagrammen) entsprechend dem logischen Oder
• Zwei Interaktionseinschränkungen

Außerdem einen Schlussknoten, der wiederum von den Aktivitätsdiagrammen geborgt wurde.

10.5 Sequenzen und Unternehmensmodellierung

10.5.1 Beitrag

Welchen Beitrag können Sequenzdiagramme zu einer Unternehmensmodellierung leisten?

Sie taugen, und dafür sind sie ja auch gedacht, zur Beschreibung des Nachrichtenverkehrs zwischen Objekten, die gemeinsam eine Aufgabe erledigen. Damit sind sie – nimmt man die Systemanalyse zur Vorbereitung der Anwendungsprogrammierung mit zu den Aufgaben der Unternehmensmodellierung – für diese geeignet. Dies ist aber auch unstrittig.

Nachrichtenverkehr zwischen Objekten
…
für Systeme

Bleibt die Frage, ob sie auch für die übergeordnete Ebene der Prozessmodellierung taugen. Wie oben zu sehen war, kann man mit ihnen schon einfache Prozesse beschreiben. Können aber auch ausreichend komplexe Geschäftsprozesse damit beschrieben werden? Wie steht es – ganz allgemein – um die Aussagekraft dieser Prozessmodelle?

Auch für Geschäftsprozesse?

Um Antworten daruf zu finden im folgenden nun eine Klärung, welche Elemente der Methode SD grundsätzlich für eine Prozessmodellierung sinnvoll erscheinen, welche nicht, welche Elemente fehlen und was da ist, aber für eine Prozessmodellierung (derzeit(?) noch) nicht gebraucht wird.

10.5.2 Theorieelemente für die Prozessmodellierung

Jede Methode zur Prozessmodellierung[3] benötigt Handelnde, Träger der Tätigkeitsfolgen. Diese sind hier durch die Objekte bzw. die Lebenslinien gegeben. Durch die Methoden der Klassen sind sogar die möglichen Handlungen fixiert. Allerdings konzentriert sich das Ganze auf die Objekte des objektorientierten Modells.

Handelnde

Wie aber die prozessnahen Beispiele oben zeigen, ist dieses Instrument durchaus flexibel. Letztendlich kann sich das Diagramm nicht wehren, wenn beliebige Akteure als Objekte niedergeschrieben werden.

Ein weiteres Element, das grundsätzlich Potential für eine Prozessmodellierung hat, sind die Nachrichten. Jede Nachricht …

Nachrichten

• erfordert Tätigkeiten zu ihrer Erzeugung und gibt damit einen Hinweis auf die konkreten einzelnen Aktivitäten
• ist ein Informationsobjekt, was insbesondere die Prozessbeispiele oben sehr deutlich machen.
• muss transport werden, was wieder eine Tätigkeit darstellt.
• löst beim Empfänger Tätigkeiten aus.

Somit geben Nachrichten deutliche Hinweise auf die Abfolge der Tätigkeiten, auf Informationsobjekte und auf den Transport derselbigen.

Der oben angeführten Tätigkeit zur Vorbereitung des Nachrichtenverkehrs entspricht der sog. Kontrollfokus. Indem er das Aktivsein des jeweiligen Objekts darstellt und an seinem Ende der Nachrichtenversand erfolgt, wird die gesamte Aktivität bis zum Versand hier erfasst.

Kontrollfokus

Ganz konkret ist dies nicht nur die Nachrichtenaufbereitung, sondern auch alles andere, was davor erfolgen muss und was Grundlage der Nachricht ist (z.B., bei Prozessbeispielen, Durchführung einer Kalkulation, Teilebeschaffung).

Auch die in jeder Prozessbeschreibung notwendigen Verzweigungen bzw. Festlegungen bzgl. der Kontrollflüsse sind zumindest teilweise vorhanden:

Verzweigungen

• Der Interaktionsoperator alternatives (alt) entspricht einem exklusiven Oder.
• Der Interaktionsoperator assertion (assert) würde in einer Prozessbeschreibung zu einem Kontrollflusszweig führen, der auf keinen Fall umgangen werden kann.
• Der Interaktionsoperator loop (loop) würde in einer Prozessbeschreibung als Rückschleife modelliert (vgl. [Staud 2006, Abschnitt 5.1]).
• Der Interaktionsoperator option (opt) würde als Verzweigung mit einem exklusiven Oder (mit einem Leerzweig) modelliert.

Insgesamt liegen mit der zeitlichen Hintereinanderanordnung der Nach­richten und den durch Interaktionsoperatoren präzisierten kombinierten Fragmenten Grundzüge eines Kontrollflusskonzeptes vor.

Kontrollfluss

Welche Situation liegt vor, wenn vor dem Nachrichtenversand kein Kontrollfokus angegeben ist. In Sequenzdiagrammen sieht man dies oft dann, wenn dem Nachrichtenversand keine ausführliche Tätigkeit vorangeht, sondern nur die der Nachrichtenerzeugung.

Nachricht ohne Kontrollfokus

Diese genügt aber, um in einer Prozessbeschreibung als Tätigkeit wahrgenommen und modelliert zu werden, in einer Ereignisgesteuerten Prozesskette z.B. als Funktion.

Auch ein Theorielement, um Sequenzdiagramme ineinander zu verschachteln, liegt mit dem Theorieelement Interaktionsauftreten (ref) vor. Damit ist es möglich, …

Verweise

• ein oft benötigtes Modellfragment einmal zu erstellen und wo immer nötig zu nutzen,
• bzw. aus Gründen der Übersichtlichkeit, einzelne Fragmente auszulagern.

10.5.3 Weitere Theorieelemente

Es gibt in der Methode SD sehr viele weitere Elemente, die zumindest in einer Standardprozessmodellierung (vgl. hierzu Kapitel 15) nicht benötigt werden.

Weitere Interaktionsoperatoren

Dies gilt z.B. für die Interaktionsoperatoren break, parallel, weak sequencing, strict sequencing, negative, critical region und ignore / consider. Diese zielen so sehr in die Systemanalyse (die Programmentwicklung), dass sie für die Prozessmodellierung keinen Sinn machen, es sei denn Prozessmodellierung fällt auf Systemanalyse zurück (vgl. unten sowie Kapitel 14).

Prozess-
modellierung vs. Systemanalyse

Asynchron / synchron und Nebenläufigkeit

Die nächsten beiden Punkte erscheinen auf den ersten Blick als untauglich für eine Standardprozessmodellierung. Bei näherem Hinsehen allerdings wird schnell klar, dass sie für eine systemnahe Prozessmodellierung natürlich notwendig sind, denn da geht es ja um die Realisierung von Programmen für die automatisierte Abwicklung von Geschäftsprozessen.

Erinnern wir uns. Ein synchroner Nachrichtenaustausch bedeutet, dass der Sender wartet, bis der Empfänger den betreffenden Methodenaufruf beendet hat, zurückmeldet und dann erst wieder aktiv wird. Bei einem asynchronen Nachrichtenaustausch dagegen wartet das Senderobjekt nicht, bis die aufgerufene Aktion durchgeführt ist, sondern führt gleich wieder irgendwelche Verarbeitungsschritte durch (vgl. Abschnitt 7.5.2).

Asynchron und Synchron

In einer Prozessbeschreibung würde dies bedeuten, dass eine Funktion (zum Beispiel) nach Absenden einer Nachricht (d.h. hier: Anstoßen einer weiteren Funktion) gleich noch weitere absendet, ohne abzuwarten, bis die vorige abgearbeitet ist.

So etwas ist in der Standardprozessmodellierung nicht vorgesehen. Diese beruht auf dem einfachen Ablaufmodell „Funktion wird angestoßen – Funktion führt ihre Aufgaben aus – nächste Funktion wird angestoßen“ usw. Etwas anderes ist nicht vorgesehen und nicht nötig. Man kommt in der Prozessmodellierung sehr gut damit aus, notfalls den Prozess über eine Schleife immer wieder neu zu starten.

Einfaches Ablaufmodell

Obiges hat auch mit dem zu tun, was in der Informatik Nebenläufigkeit genannt wird. Dadurch werden in Systemen parallele Abschnitte realisiert. Die Grundlage ist, dass das Versenden und Empfangen von Botschaften zeitlich parallel erfolgen kann [Kerner und Horn 1997, S. 270].

Nebenläufigkeit

Dies ist in der Standardprozessmodellierung nicht möglich, bzw. nicht nötig. Möglich ist aber, durch einen UND-Operator parallele Verarbeitungsschritte anzufordern. Die einzelnen Stränge werden dabei unabhängig voneinander abgearbeitet, bis sie zum Ende kommen. Falls eine Zusammenführung der getrennten Kontrollflüsse gewünscht ist, könnte ein zweiter UND-Operator eingesetzt werden (vgl. [Staud 2006, Kapitel 4]). Die folgende Abbildung zeigt ein Beispiel.

Statt von Parallelität spricht der Verfasser bei einer solchen Struktur lieber von einem Zeitfenster. Erst wenn alle Tätigkeiten zwischen den beiden UND-Operatoren abgearbeitet sind, geht es weiter. Insofern ist diese Struktur in der Prozessmodellierung eher Ausdruck der Absicht, sich um die Reihenfolge der Tätigkeiten nicht kümmern zu müssen als um wirkliche Parallelität.

Zeitfenster

Für eine Standardprozessmodellierung reicht dies auch aus, in einer Systemanalyse bedarf es der präziseren Fassung.

Überholen einer Nachricht durch eine andere

Einer Nachricht in Sequenzdiagrammen entspricht in der Prozessmodellierung der Transport von Informationsobjekten. Ein „Überholen“, wie oben beschrieben, bedeutet dann, dass der eine Transportvorgang früher gestartet wird aber später fertig ist als ein anderer.

Transport von Informations-
objekten

In der Standardprozessmodellierung ist dies nicht vorgesehen. Der Grund liegt darin, dass die Tätigkeiten mit ihren Ergebnisereignissen sequentiell angeordnet sind und dass es nur einen Kontrollfluss gibt. In Sequenzdiagrammen ist dies anders. Jede Lebenslinie hat ihre eigene Ablauffolge. Hier – in der jeweiligen sequentiellen Abfolge – ist die Reihenfolge ebenfalls fixiert und ein Einwirken von „oben“ nach „unten“ oder umgekehrt – ist nicht denkbar. Über die Lebenslinien hinweg aber schon.

Soweit die wichtigsten, über die heutige Standardprozessmodellierung hinausweisenden Theorielemente. Sie geben einen Hinweis und stellen eine Frage. Der Hinweis ist der auf die Systemnähe der Methode SD, die Frage die, ob hier nicht Hinweise gegeben werden für eine Weiterentwicklung der Geschäftsprozessmodellierung, z.B. durch Einführung einer systemnahen Prozessmodellierung. Dazu mehr in Abschnitt 11.5.8, zu zweiterem auch in Kapitel 14.

Ein Hinweis und eine Frage

10.5.4 Defizite in Hinblick auf Ablaufmodellierung

Was fehlt beim typischen Sequenzdiagramm für eine fundierte Prozessmodellierung? Bei genauer Betrachtung recht viel. Für den Abgleich wurden die 10 Punkte von Abschnitt 15.3 (Basiselemente einer Methode zur Prozessmodellierung) hinzugezogen.

(1) Elementare Tätigkeiten

Sind in der Methode SD vorgesehen. Aber nur …

• als Nachrichtenverkehr (Methodenaufruf)
• als Vorbereitung des Nachrichtenversands
• als Antwort auf eine Nachricht

Wobei die Nachrichten die Methoden der beteiligten Klassen widerspiegeln. Die „Tätigkeiten“ der Kontrollfokusse müssen in anderen Bereichen der Programmierung gesucht werden.

Bei Systemen (insbesondere Softwaresystemen) ist mehr auch nicht nötig. Hier sind die handelnden Einheiten sehr weit heruntergebrochen bis auf die für die Programmierung taugliche Ebene. In Prozessen gibt es dagegen durchaus Situationen, wo die nächste Tätigkeit einfach nur angestoßen wird durch die Erledigung der vorigen.

Systemdenken

(2) Träger der Tätigkeiten

Auch dieses Theorieelement ist vorhanden, allerdings auch wieder in eingeschränkter Form. Vorhanden sind Objekte, die Basis der Lebenslinien sind, d.h. meist deren Klassen mit ihren Methoden. Andere Träger von Aktivitäten aber nicht.

(3) Informationen auf Trägern aller Art

Informationen erscheinen hier bei den Parametern der Nachrichten. Ansonsten nicht. Die Informationsverarbeitung wird hier auf Programmebene betrachtet. Etwas mehr schimmert in den Grobmodellierungen auf, wie auch hier in den Prozessbeispielen.

Nur Parameter

(4) Informationsverarbeitung

Diese wird nicht ausgeweisen, sie ist verborgen, in der Vorbereitung des Nachrichtenverkehrs. Da dieser nicht detailliert wird, werden auch die dort angegebenen Informationen erzeugenden, verändernden und löschenden Tätigkeiten nicht angegeben.

Verborgen

(5) Ereignisse

Diese sind vorhanden rund um den Nachrichtenverkehr. Aber nur da.

(6) Kontrollfluss

Der zeitlich angeordnete Nachrichtenverkehr zwischen mehreren Lebens­linien stellt so etwas wie einen Kontrollfluss dar, allerdings einen für die Funktionsfolge, nicht für die Prozessabläufe (vgl. Stichwort Funktions­modellierung vs. Prozessmodellierung , insbesondere Abschnitt 15.2).

(7) Ebenen – Kapselung

Das Element ref erlaubt in einfacher Form die Kapselung und die Bildung von Ebenen.

(8) Verweise, Verknüpfungen

Dies könnte ebenfalls mit dem Element ref realisiert werden, wenn die Modellfragmente parallel angeordnet würden.

(9) Zeitliche Dimension

Eine Erfassung von Zeitaspekten ist nur eingeschränkt möglich. Die sequentielle Abfolge des Nachrichtenverkehrs erfasst allerdings einen für Ablauffolgen typischen Aspekt.

(10) Träger des gesamten Geschäftsprozesses

Ein solches Konzept ist nicht vorgesehen.

10.5.5 Grafische Gestaltung

Die grafische Gestaltung ist bei größeren Projekten umständlich, v.a. in zweierlei Hinsicht:

• Bei der Gestaltung der Operatoren
• Bei der Darstellung einer großeren Anzahl von Partizipanten

10.5.6 Verknüpfung mit der übrigen objektorientierten Theorie

Eine solche Verknüpfung ist gegeben, durch die Lifelines, die ja im Normalfall Objekte aus dem objektorientierten Modell repräsentieren.

10.5.7 SD und EPK im direkten Vergleich

Wenigstens kurz soll hier noch betrachtet werden, wie es um die Übertragung von Sequenzdiagrammen in eine Methode der Standardprozessmodellierung (hierfür wurde wieder die Methode EPK gewählt) steht. Ist sie möglich? Wo liegen die Probleme? Mehr dazu in WebZumBuch_UM01.

Von SD zu EPK

Beispiel Kaufabwicklung als Ereignisgesteuerte Prozesskette

Vergleich mit Methode EPK

Das oben vorgestellte Beispiel Kaufabwicklung soll hier in eine Ereignisgesteuerte Prozesskette überführt werden. Es sollte als ein typisches Prozessbeispiel dazu auch geeignet sein. Um die direkte Vergleichbarkeit zu erleichtern, wird das Sequenzdiagramm hier in Abbildung 11.5-2 nochmals angegeben.

Eigentlich geht es um die Variante mit dem kombinierten Fragment (Abbildung 11.5-2), da aber die erste Variante dieses Sequenzdiagramms (Abbildung 11.3-2) bei jedem Kontrollfokus auch eine Benennung der Tätigkeit aufweist, sollte sie auch mit hinzugezogen werden.

Die nächsten Abbildungen zeigen die Ereignisgesteuerte Prozesskette, die diesem Sequenzdiagramm entspricht, wobei zwei beispielhafte potentielle Verzweigungen hinzugefügt wurden, um anzudeuten, dass diese in einer Prozessmodellierung unabdingbar sind.

EPK = Ereignisgesteuerte Prozesskette

Vgl. für eine Einführung in die Modellierung von Geschäftsprozessen durch Ereignisgesteuerte Prozessketten [Staud 2006].

Die große Länge der Ereignisgesteuerten Prozesskette entsteht aus mehreren Gründen. Einer ist, dass hier die grafische Konvention beibehalten wurde, auch in der einfachen sequentiellen Abfolge die Ereignisse nach den Funktionen mit anzugeben. Verzichtet man darauf, werden die sequentiellen Abfolgen wesentlich kürzer. Vgl. für eine diesbezügliche Variante dieser Ereignisgesteuerten Prozesskette WebZumBuch_UM01.

Kürzer ohne Ereignisse

Auf andere Gründe, die hier zu einer recht „langen“ Ereignisgesteuerten Prozesskette führen, wird unten eingegangen.

Die Ereignisgesteuerte Prozesskette

Zu Beginn wurde ein Startereignis angefügt: Beschaffungswunsch liegt vor. Danach folgen im wesentlichen in einfacher sequentieller Abfolge Funktionen mit ihren Ergebnisereignissen. Die Funktionen speisen sich aus zwei Quellen:

• Zum einen entsprechen sie dem jeweiligen Kontrollfokus des Sequenzdiagramms.
• Zum anderen kommen sie von den übersandten Nachrichten des Sequenzdiagramms.

Die Übersendung einer Nachricht stellt einen Transportvorgang dar, Transport von Informationen. Solche Transportvorgänge können in Ereignisgesteuerten Prozessketten modelliert werden oder auch nicht (vgl. [Staud 2006]). Will man eine detaillierte Beschreibung des Geschäftsprozesses, dann drückt man die Transportvorgänge ausdrücklich durch Funktionen aus. Geht es eher um eine oberflächliche Beschreibung, dann legt man dafür keine eigenen Funktionen an. Der Transport wird dann dadurch ersichtlich, dass ein Informationsobjekt von der einen zur anderen Funktion „weiter wandert“.

Nachrichten = Transport von Informationen

Für das Beispiel hier wurde nun für jeden Kontrollfokus mindestens eine Funktion angelegt und für jede Nachrichtenübermittlung genau eine.

Bei jeder EPK-Funktion wurde außerdem festgehalten, wer ihr Träger ist. Dies ist ja im Sequenzdiagramm durch die Lebenslinien angegeben.

Träger der Funktion

Durch die Nachrichten im Sequenzdiagramm erfolgt auch ein Hinweis auf Informationsobjekte[4] in der Ereignisgesteuerten Prozesskette, so dass diese dort ebenfalls ergänzt wurden.

Informationsobjekte

Erinnerung – Methoden und ihre Begriffe:

• Tätigkeit, Tätigkeitsfolge: übergeordnete Begriffe
• Funktion: Begriff der „Methode EPK“
• Ereignis: Begriff der „Methode EPK“
• Nachricht: Begriff der „Methode SD“
• Kontrollfokus: Begriff der „Methode SD“

Der Begriff Kontrollfluss wird als übergeordneter Begriff für alle Methoden zur Ablaufbeschreibung angesehen.

Somit wird aus dem ersten Teil des Sequenzdiagramms („Voranfrage vorbereiten, Voranfrage senden“), einem Kontrollfokus und einer Nachricht, die entsprechende vierteilige Abfolge in der Ereignisgesteuerten Prozesskette. Dies ist ein weiterer Grund für die Länge der EPK.

Anstoßen der nächsten Tätigkeit

Die Tatsache, dass die Nachricht Voranfrage senden die Tätigkeit Voranfrageantwort erstellen anstößt, wird in der EPK durch den Kontrollfluss erfasst. Das Ereignis Voranfrage beim Lieferanten ist nicht nur Ergebnisereignis der Funktion Voranfrage senden, sondern auch auslösendes Ereignis für die Funktion Voranfrage auswerten und genau da liegt das Anstoßen der Funktion durch ein Ereignis.

Anstoßen

Es wurde oben schon ausgeführt: Die Sequenzdiagramme weisen nur wenige Verzweigungen auf und deren Realisierung durch die kombinierten Fragmente ist mühsam und nicht effizient. Sequenzdiagramme in der Praxis sind meist recht arm an Verzweigungen[5].

Wenige Verzweigungen

Dies passt nicht zur Prozessmodellierung. Hier wird deutlich mehr an Verzweigungen modelliert, detaillierter – also mehr beim positiven Durgang – und mehr bzgl. Störungen. Denn Störungen (Kunde akzeptiert Angebot nicht, Kalkulation gelingt nicht, usw.) sind in Geschäftsprozessen etwas alltägliches. Um sie geht es sogar oft hauptsächlich, z.B. im Rahmen der Geschäftsprozessoptimierung.

Um dies zu verdeutlichen wurde deshalb hier bei der nächsten Funktion Voranfrage auswerten (Kontrollfokus Voranfrageantwort erstellen) eine prozesstypische Verzweigung, die auf einer Störung basiert, eingebaut. Es wurde angenommen, dass die Auswertung der Voranfrage zur Ablehnung führen kann (der potentielle Kunde möchte Unmögliches), zur Bitte um Verhandlungen oder gleich zur Akzeptanz. Damit ergäbe sich dann eine prozesstypische Verzweigung. Hier wurden die Alternativen allerdings nicht weiter verfolgt.

Verzweiugng durch Störung

Die Verzweigung, die auch im Sequenzdiagramm eingebaut ist, wird weiter unten gezeigt.

Die folgende Abbildung 11.5-4 (Teil 2) zeigt den weiteren Ablauf bis zur Erstellung des Angebots. Hier bleibt es beim einfachen sequentiellen Ablauf, so wie er durch das Sequenzdiagramm angegeben ist.

Teil 3 in Abbildung 11.5-5 beginnt mit dem Ereignis, das die Beendigung der Angebotserstellung festhält und der Funktion Angebot zum Kunden senden. Anschließend ist ja im Sequenzdiagramm von Abbildung 11.5-2 ein kombiniertes Fragment, eine Verzweigung, eingebaut: Das Angebot wird entweder angenommen oder nicht. Damit liegt eine Verzweigung vor, mit dem Interaktionsoperator alt und zwei Interaktionsoperanden.

Kombiniertes Fragment
bzw.
exklusives Oder

In der EPK wird daraus eine Verzweigung mit einem exklusiven Oder. Im einen Zweig ist die Ablehnung modelliert, im anderen der positive Weitergang. Die Interaktionseinschränkungen werden zu Beschriftungen für die Ergebnisereignisse der EPK.

Entsprechend dem Sequenzdiagramm findet der Fortgang bei einer Ablehnung ein schnelles Ende. Hier wurde zum Abschluss noch ein Schlussereignis (Angebot abgelehnt) angefügt.

Im Falle der Akzeptanz des Angebots wird in beiden Modellen die Erarbeitung und der Versand des Auftrags modelliert.

Danach verlagert sich die Aktivität zum Lieferanten. Nach der Auftragsannahme wird die Auftragsbestätigung verschickt. Im Sequenzdiagramm folgt dann in einem Kontrollfokus die Auftragserledigung (Leistungserbringung) mit Liefermitteilung und Lieferung. In der EPK wurde dies alles als Folge von vier Funktionen mit ihren Ergebnisereignissen modelliert.

Teil 4

Abbildung 11.5-7 zeigt den Abschluss des Geschäftsprozesses. Der Kunde prüft die Lieferung und bestätigt den (korrekten) Eingang, was beim Lieferanten zur Erstellung und zum Versand der Rechnung führt. Die Nachricht Zahlung des Sequenzdiagramms wurde in der EPK als Funktion Zahlung durchführen modelliert, gefolgt vom Ergebnisereignis Zahlung durchgeführt, das gleichzeitig Schlussereignis ist.

Teil 5

Bei dieser letzten Funktion wurde auf eine mögliche Aufteilung verzichtet. Hätte man sie doch vorgenommen, wäre Zahlung vorbereitet eingefügt worden.

Soweit die Ableitung einer Ereignisgesteuerten Prozesskette aus einem Sequenzdiagramms, die problemlos möglich ist.

Die andere Richtung

Die Übertragung in die andere Richtung, von Ereignisgesteuerten Prozessketten zu Sequenzdiagrammen, ist nur sehr eingeschränkt möglich, es fehlen in Sequenzdiagrammen einfach zu viele Theorielemente, die eine Prozessmodellierung benötigt. Vgl. für einige diesbezügliche Versuche WebZumBuch_UM01.

Von EPK zu SD

10.5.8 Zusammenfassung

Letzendlich ist die Modellierung durch Sequenzdiagramme reduziert auf die Nachrichten und lediglich die Tätigkeiten, die für die Vorbereitung der Nachricht notwendig sind. Dies bedeutet eine enorme Einschränkung der Aussagekraft. Um es zu verdeutlichen: Es wäre nicht möglich, Tätigkeiten, als Kontrollfokus oder sonstwo, einzubauen, die nicht zu Nachrichten (d.h. Methodenaufrufen) führen.

Einschränkung

Im Umkehrschluss bedeutet dies im Übrigen, dass nur solche Probleme, die also auf diese Weise beschrieben werden können, für die Modellierung durch Sequenzdiagramme geeignet sind.

Obiges Argument greift aber nicht für Systeme. Hier sind die einzelnen Tätigkeiten so weit heruntergebrochen, dass dieses Konzept ausreicht. Gekapselt sind hier nur noch die Methoden, in denen Programmabläufe stecken.

Das gesamte Instrumentarium von Sequenzdiagrammen zielt auf Abläufe im Kleinen, nicht im Großen. Auf Systeme, nicht auf Geschäftsprozesse. Ausdruck davon ist auch die Ausrichtung auf die positiven Ergebnisse – auf Nichtverzweigung. Dies ist eher in Systemen (Programmen) denkbar, als in Geschäftsprozessen.

Systeme,
nicht Geschäftsprozesse

Insgesamt kann daher festgehalten werden: Sequenzdiagramme taugen nicht für die Prozessmodellierung. Sie decken nur Teilaspekte eines Geschäftsprozesses ab. Natürlich kann, wenn man genügend abstrahiert, jeder Geschäftsprozess auch als Sequenzdiagramm dargestellt werden, denn irgendwelche Nachrichten sozusagen als „Kitt“ zwischen diesen Aktivitäten finden sich immer, aber ein solche Modell ist weitgehend aussagefrei. Vgl. auch die im Kapitel angeführten Prozessbeispiele.

Sequenzdiagramme taugen aber, abgeleitet aus Prozessmodellen, für die Systemanalyse, insbesondere für die Vorbereitung der Programmierung. Hier spiegeln dann die Lebenslinien auch die Klassen des Klassendiagramms wider und die Nachrichten entsprechen Methodenaufrufen.

Vorbereitung der Programmierung

Insofern ist der Anspruch der UML-Autoren, der auch durch die Beispiele untermauert wird, mit Sequenzdiagrammen Geschäftsprozesse modellieren zu wollen, nicht haltbar.

Keine Prozess-
modellierung mit Sequenz-
diagrammen!

In einer zeitgemäßen Unternehmensmodellierung werden also Sequenzdiagramme dazu dienen, abgeleitet von der Prozessmodellierung, Abschnitte, die in Software gepackt werden sollen, für die Programmierung vorzubereiten. Z.B. das Mahnwesen, wie in Abschnitt 11.3-1 beschrieben.

Nehmen wir den deutlichen Trend zur völlig automatisierten Realisierung von Geschäftsprozessen, den uns die Internetunternehmen gerade demonstrieren, könnte auch eine andere Position eingenommen werden. Wenn Geschäftsprozesse, so weit es geht, durch Programme realisiert werden, sind dann Sequenzdiagramme nicht das geeignete Werkzeug der Wahl?

Oder doch?

Denkbar wäre dies für die Beschreibungsebene, die unmittelbar der Vorbereitung der Programmierung dient, die systemnahe Prozessmodellierung. Hier liegt aber bereits die Methode AD vor, die dafür deutlich besser geieignet ist (vgl. den dortigen Abgleich mit den Anforderungen an eine Standardprozessmodellierung). Insofern bleibt es für die Sequenzdiagramme bei der wichtigen Rolle in der Systemananlyse, der unmittelbaren Vorbereitung der Programmierung.

Nein!