Sequenzdiagramme

Nachdem wir die statische Struktur des Anwendungssystems durch das Klassenmodell beschrieben hatten, war unser nächster Arbeitsschritt die Modellierung der dynamischen Struktur, d. h. die Beschreibung der Abläufe im System für die einzelnen Anwendungsfälle. Dazu stellt die UML im wesentlichen zwei Konstrukte zur Verfügung: Sequenzdiagramme und Kollaborationsdiagramme (Aktivitätsdiagramme könnten zwar prinzipiell auch für diesen Zweck eingesetzt werden, allerdings sind sie mehr für die Darstellung von Algorithmen auf Operationsebene als für die Veranschaulichung der Abläufe von Anwendungsfällen geeignet.)

Von diesen beiden wählten wir zunächst das Sequenzdiagramm als Darstellungsmittel und erstellten für jeden Anwendungsfall ein solches Diagramm unter Verwendung der vom Klassenmodell gelieferten Klassen-Attribute und -Operationen. Die endgültigen Versionen der Sequenzdiagramme zu den acht Anwendungsfällen von JWI können in der Dokumentation des Beispielprojekts eingesehen werden.

Aus Platzgründen soll in dieser Präsentation nicht die Entwicklung der Sequenzdiagramme für alle Anwendungsfälle nachvollzogen werden. Vielmehr wird sich die Betrachtung im folgenden auf einige ausgewählte Beispiele beschränken, bei denen Zusammenhänge zu anderen Diagrammen bzw. Phasen des Modellierungsprozesses besonders deutlich werden:

1. Beispiel: "Lieferscheine erstellen"

2. Beispiel: "Wareneingang bearbeiten"

3. Beispiel: "Fehlbestände nachbestellen"

1. Beispiel: "Lieferscheine erstellen"

In einem ersten (naiven) Ansatz wurde die Erstellung der Lieferscheine als eine rein interne Angelegenheit der Klasse "Liefer-Kartei" betrachtet und entsprechend als einfache Operation modelliert (vgl. Abbildung 9a). Als wir jedoch das Aktivitätsdiagramm zu dieser Operation zeichneten, stellte sich schnell heraus, daß es an unserer Modellierung einiges nachzubessern gab.

Abbildung 9a: Sequenzdiagramm zum Anwendungsfall "Lieferscheine erstellen", Entwurf 1

Guided Tour: Weiter bei "Wareneingang bearbeiten"

1. Änderungen des Sequenzdiagramms "Lieferschein_erstellen":

Zunächst wurde eine neue Klasse "Lieferschein" eingeführt, um die Daten der vorbereiteten Lieferscheine zwischenspeichern zu können. Eine Darstellung der Attribute und Operationen dieser Klasse kann man sich auf der Klassenmodell-Seite anschauen. Unter Einbeziehung dieser neuen Klasse wurde anschließend Entwurf 1 grundlegend überarbeitet. Das Ergebnis ist in Abbildung 9b dargestellt.

Abbildung 9b: Sequenzdiagramm zum Anwendungsfall "Lieferscheine erstellen", Entwurf 2 [Vergrößerte Ansicht]

Guided Tour: Weiter bei der Änderung am Zustandsdiagramm "Bestellposten Kundenbestellung"

2. Änderung des Sequenzdiagramms "Lieferschein_erstellen":

Mit der Einführung der administrativen Klasse "Verwaltung" mußte das Sequenzdiagramm erneut geändert werden. Die neue Klasse wurde zwischen den Benutzer und die Klasse "Liefer-Kartei" in das Sequenzdiagramm eingebaut, und der Benutzer konnte nunmehr die Erstellung der Lieferscheine mit der Operation "lieferscheine_erstellen" der Klasse "Verwaltung" anstoßen. Eine weitere Änderung ergab sich dadurch, daß die Funktionalität des Lieferscheinausdrucks von der Klasse "Liefer-Kartei" an die Klasse "Lieferschein" übertragen wurde (vgl. die Darstellung der entsprechenden Änderungen an "Liefer-Kartei" und "Lieferschein"): Die Operation "lieferscheine_ausdrucken" wurde in der Klasse "Liefer-Kartei" eliminiert und durch die Operation "audrucken" der Klasse "Lieferschein" ersetzt. Abbildung 9c zeigt Entwurf 3 des Sequenzdiagramms.

Abbildung 9c: Sequenzdiagramm zum Anwendungsfall "Lieferscheine erstellen", Entwurf 3 [Vergrößerte Ansicht]

Guided Tour: Weiter bei der Änderung des Kollaborationsdiagramms "Lieferscheine erstellen"

3. Änderung des Sequenzdiagramms "Lieferschein_erstellen":

Bisher hatten wir in unserer Modellierung noch nicht berücksichtigt, daß es sich bei den Instanzen der Klasse "Lieferschein" um Durchlaufobjekte handelt, d. h. sie werden zu Beginn erzeugt und am Ende wieder gelöscht. Die endgültige Fassung des Sequenzdiagramms trägt diesem Sachverhalt Rechnung. Außerdem wurde die "neu"-Operation der Klasse "Lieferschein" um einen Rückgabewert erweitert, in dem die Nummer des neu erzeugten Lieferscheins zurückgegeben wird (vgl. Klassenmodell, Abbildung 8c). Abschließend stellt Abbildung 9d das endgültige Sequenzdiagramm zum Anwendungsfall "Lieferscheine erstellen" dar.

Abbildung 9d: Sequenzdiagramm zum Anwendungsfall "Lieferscheine erstellen", endgültige Version [Vergrößerte Ansicht]

Guided Tour: Weiter bei 1. Änderung des Aktivitätsdiagramms zur Operation "Liefer-Kartei::lieferscheine_erstellen()"

2. Beispiel: "Wareneingang bearbeiten"

Bei der Erstellung des ersten Entwurfs dieses Sequenzdiagramms stellten wir fest, daß zwischen den Anwendungsfällen "Wareneingang bearbeiten" und "Lagerbestand ermitteln" eine weitere USES-Beziehung besteht, die wir bisher nicht bedacht hatten. Um diesem Sachverhalt nunmehr gerecht zu werden, änderten wir die Beschreibung des Anwendungsfalls "Lagerbestand ermitteln" sowie das Anwendungsfalldiagramm entsprechend ab.

Für die Darstellung der USES-Beziehung im Sequenzdiagramm benutzten wir in Ermangelung einer geeigneten Notationsmöglichkeit in der UML eine einfache textuelle Anmerkung (vgl. Abbildung 10a).

Abbildung 10a: Sequenzdiagramm zum Anwendungsfall "Wareneingang bearbeiten", Entwurf 1 [Vergrößerte Ansicht]

Guided Tour: Weiter bei der Änderung der Anwendungsfälle

1. Änderungen des Sequenzdiagramms "Wareneingang bearbeiten":

Der erste Entwurf berücksichtigte noch nicht, daß bei der Übertragung eines Bestellpostens aus der Warte-Kartei in die Liefer-Kartei auch der Bestand des zugehörigen Produkts nach unten korrigiert werden muß. Darum wird im zweiten Entwurf in der Operation "nach_lieferkartei_übertragen" nach "eintrag_loeschen" außerdem die Operation "akt_best_korrigieren" der entsprechenden Instanz von "Produkt" aufgerufen.

Abbildung 10b: Sequenzdiagramm zum Anwendungsfall "Wareneingang bearbeiten", Entwurf 2 [Vergrößerte Ansicht]

2. Änderungen des Sequenzdiagramms "Wareneingang bearbeiten":

Erst als wir uns während der Erstellung des Aktivitätsdiagramms zur Operation "wareneingang_bearbeiten" der Klasse "Produkt" noch einmal näher mit dem Algorithmus hinter dieser Operation beschäftigten, fiel uns ein schwerwiegender Fehler in unserer bisherigen Modellierung auf: In Entwurf 2 des Sequenzdiagramms wird mit der Iteration "*[für alle Einträge] wareneingang_zuordnen(pnr)" die Warte-Kartei durchgegangen und der Wareneingang eines Produkts p Posten der Warte-Kartei zugeordnet, die damit lieferbar werden. Nun wurde aber bisher überhaupt nicht überprüft, ob der gerade betrachtete Warte-Kartei-Eintrag überhaupt dieses Produkt betrifft. Damit wurde zwangsläufig jeder Eintrag von der Warte-Kartei in die Liefer-Kartei übertragen, sofern die Bedingung "akt_best >= (bnr, lfdnr).menge" erfüllt war, gleichgültig ob der Eintrag zum Produkt p gehörte oder nicht. Zur Korrektur dieses Fehlers erweiterten wir die genannte Bedingung um die Forderung, daß die der Operation "wareneingang_zuordnen" als Parameter übergebene Produktnummer ("pnr") mit der Produktnummer des Bestellpostens des Eintrags übereinstimmen muß ("pnr = (bnr, lfdnr).pnr"). Das Ergebnis ist in Abbildung 10c zu sehen.

Abbildung 10c: Sequenzdiagramm zum Anwendungsfall "Wareneingang bearbeiten", Entwurf 3 [Vergrößerte Ansicht]

Guided Tour: Weiter bei der 3. Änderung des Klassenmodells

3. Änderungen des Sequenzdiagramms "Wareneingang bearbeiten":

Bis zu diesem Punkt sah unsere Modellierung vor, daß der Benutzer für jedes eingetroffene Produkt "p" die Operation "wareneingang_bearbeiten" der Klasse "Produkt" mit der eingetroffenen Menge als Parameter direkt aufrufen mußte. Dieser Zustand war aus zwei Gründen unbefriedigend:

Wie sollte der Benutzer zunächst die gewünschte Instanz von "Produkt" finden, dann diese Operation aufrufen und zugleich den geforderten Parameter bereitstellen können? Es wären in jedem Fall Meta-Informationen nötig, um die korrekte Instanz zu ermitteln. Natürlich könnte "wareneingang_bearbeiten" anschließend einen Bildschirmdialog mit dem Benutzer führen, damit dieser die eingetroffene Warenmenge eingeben kann. In diesem Fall wäre jedoch der Parameter überflüssig.
Der Benutzer sollte generell keinen direkten Zugriff auf Operationen von Inhaltsklassen wie "Produkt" haben. Er benötigt eine solche Zugriffsmöglichkeit auch nicht, da für ihn lediglich von Relevanz ist, wie er den Anwendungsfall "Wareneingang bearbeiten" anstoßen kann. Die internen Abläufe sind für ihn uninteressant.

Mit der Einführung der administrativen Klasse "Verwaltung" konnten diese Probleme gelöst werden, da der Benutzer nunmehr ausschließlich über die Operationen dieser Klasse auf die Funktionalität des Anwendungssystems zugreifen konnte.

Abbildung 10d zeigt den entsprechend modifizierten Entwurf des Sequenzdiagramms.

Abbildung 10d: Sequenzdiagramm zum Anwendungsfall "Wareneingang bearbeiten", Entwurf 4 [Vergrößerte Ansicht]

Guided Tour: Weiter bei der 1. Änderung des Sequenzdiagramms "Fehlbestände nachbestellen"

4. Änderungen des Sequenzdiagramms "Wareneingang bearbeiten":

Für die endgültige Version waren noch zwei kleinere Änderungen an Entwurf 4 durchzuführen:

Nachdem der Lagerbestand des Produkts p um die eingetroffene Menge nach oben korrigiert worden ist, muß das Attribut "vormerkung" von p auf 0 zurückgesetzt werden, da die zur Nachbestellung vorgemerkte Menge inzwischen eingetroffen ist. Daher wurde am Rückkehrpfeil des ersten Aufrufs von "akt_best_korrigieren" die Zusicherung ergänzt, daß nach der Abarbeitung dieser Operation in jedem Fall "p.vormerkung = 0" gilt.
Aus der bisherigen Modellierung ging noch nicht hervor, daß die Übertragung eines Bestellpostens von der Warte-Kartei in die Liefer-Kartei vor dem Löschen des Warte-Kartei-Eintrags die Erzeugung eines neuen Eintrags für diesen Posten in der Liefer-Kartei erfordert. Aus diesem Grund ruft die Operation "nach_lieferkartei_übertragen" zunächst die Operation "neuer_eintrag" der Klasse "Liefer-Kartei" auf, bevor der Eintrag gelöscht wird. Damit mußte das Sequenzdiagramm noch um eine Instanz der Klasse "Liefer-Kartei" erweitert werden.

Abbildung 10e: Sequenzdiagramm zum Anwendungsfall "Wareneingang bearbeiten", endgültige Version [Vergrößerte Ansicht]

Guided Tour: Weiter bei der 2. Änderung des Sequenzdiagramms "Fehlbestände nachbestellen"

3. Beispiel: "Fehlbestände nachbestellen"

Für den Entwurf 1 dieses Sequenzdiagrammes mußte die Klasse "Produkt" um eine Operation "nachbestellen" erweitert werden, die der Benutzer für alle Produkte p aufruft, um jeweils den Nachbestellungsvorgang für p anzustoßen.

Abbildung 11a: Sequenzdiagramm zum Anwendungsfall "Fehlbestände nachbestellen", Entwurf 1 [Vergrößerte Ansicht]

Guided Tour: Weiter bei der 2. Änderung der Klasse "Produkt"

1. Änderungen des Sequenzdiagramms "Fehlbestände nachbestellen":

Der erste Entwurf hatte ein ähnliches Problem wie die ersten drei Versionen des Sequenzdiagramms zu "Wareneingang bearbeiten" in Beispiel 2: Der Benutzer mußte für die Bearbeitung des Anwendungsfalles für alle vom Anwendungssystem verwalteten Produkte die Operation "nachbestellen" aufrufen, um ggf. erforderliche Nachbestellungen anzustoßen. Diese Lösung ist aus den bereits genannten Gründen zu verwerfen. Daher bestand die erste Änderung in der Erweiterung des Diagramms um die Klasse "Verwaltung". Die zweite Änderung schloß eine Lücke in der Modellierung von Entwurf 1: Dort wurden Nachbestellungen zwar erstellt, jedoch nicht ausgedruckt. Abhilfe schaffte die Erweiterung der Klasse "Nachbestellung" um eine Operation "ausdrucken" und der Aufruf dieser Operation für alle noch nicht bearbeiteten Instanzen dieser Klasse ("bearbeitet = false") am Ende der Operation "fehlbestände_nachbestellen" von "Verwaltung". Abbildung 11b zeigt den zweiten Entwurf des Sequenzdiagramms.

Abbildung 11b: Sequenzdiagramm zum Anwendungsfall "Fehlbestände nachbestellen", Entwurf 2 [Vergrößerte Ansicht]

Guided Tour: Weiter bei der 3. Änderung des Sequenzdiagramms "Lieferschein erstellen"

2. Änderungen des Sequenzdiagramms "Fehlbestände nachbestellen":

Bisher benötigten wir in unserer Modellierung jeweils zwei Objekte der Klassen "Nachbestellung" und "Bestellposten Nachbestellung", um sowohl bereits bestehende als auch neu anzulegende Nachbestellungen handhaben zu können (vgl. Abbildung 11b): Wenn für das gerade betrachtete Produkt "p" bereits eine Nachbestellung existierte, wurde ein neuer Bestellposten ("nbpos") für diese Nachbestellung erzeugt. Anderenfalls war zunächst eine neue Nachbestellung ("nb_neu") und dann ein neuer Bestellposten (ebenfalls mit "nbpos" bezeichnet) zu erzeugen. Das zweite "Nachbestellungs"-Objekt ("nb") stand für alle erzeugten Nachbestellungen und bildete den Emfänger für die Nachrichten ("ausdrucken"), mit denen der Ausdruck der Nachbestellungen veranlaßt wurde. Nach den folgenden Änderungen benötigten wir nur noch jeweils ein Objekt von "Nachbestellung" und "Bestellposten Nachbestellung".

Die grundlegende Idee dabei war, daß ein neuer Bestellposten in jedem Fall erzeugt und an eine Nachbestellung angehängt werden muß, gleichgültig ob bereits eine Nachbestellung an den Lieferanten für das Produkt "p" vorliegt oder erst neu zu generieren ist. Darum wird in der endgültigen Fassung des Sequenzdiagramms zunächst eine neue Instanz von "Bestellposten Nachbestellung" erzeugt (unter der Bedingung, daß überhaupt ein Nachbestellungsbedarf für das Produkt "p" besteht), wobei die "neu"-Operation gegenüber den Vorgängerdiagrammen um die beiden Parameter "pnr" und "bestellmenge" erweitert ist, um dem neuen Bestellposten die benötigten Informationen zu übergeben. Wenn im Anschluß noch keine Nachbestellung an den Lieferanten des Produkts "p" existiert, wird eine solche neu angelegt. Wiederum wurde die "neu"-Operation von "Nachbestellung" um den Parameter "lnr" erweitert, damit die Nummer des Lieferanten für das Produkt "p" übergeben werden kann. Ebenfalls neu ist der Rückgabewert "bnr" dieser Operation, der die Nummer der neuen Nachbestellung enthält. Da nunmehr auf jeden Fall eine Nachbestellung vorhanden ist, zu der der zuvor erzeugte Bestellposten gehört, muß dieser nur noch dort angehängt werden. Dazu wurde die Klasse "Nachbestellung" um eine Operation "anhängen" erweitert. Der Rest des endgültigen Sequenzdiagramms stimmt mit Entwurf 2 überein.

Abbildung 11c: Sequenzdiagramm zum Anwendungsfall "Fehlbestände nachbestellen", endgültige Version [Vergrößerte Ansicht]

Guided Tour: Weiter bei den Implementierungsdiagrammen

Hintergrundinformationen

Hinweise zur Erstellung

Einordnung in das Gesamtbild der UML

Buch: Weiter bei den Kollaborationsdiagrammen

Buch: Zurück zum Klassenmodell