Ermittlung von Klassenkandidaten:
Zunächst haben wir die textuelle Beschreibung der Anwendungsfälle
analysiert, um Substantive zu identifizieren, die zentrale Konzepte des
zu modellierenden Anwendungssystems bezeichnen und darum als Klassenkandidaten
in Erwägung zu ziehen sind. Dabei erschienen uns solche Konzepte als
besonders relevant, die an den Handlungen der Anwendungsfälle aktiv
oder passiv beteiligt sind, wie etwa "Produkte", "Kunden" oder "Bestellposten".
Auf diese Weise konnten wir folgende Liste von Klassenkandidaten aufstellen:
-
Bestellposten
-
Kunde
-
Kundenbestellung
-
Lieferant
-
Liefer-Kartei
-
Nachbestellung
-
Produkt
-
Wartei-Kartei.
Der interessierte Leser kann sich die Kandidaten im Kontext der Anwendungsfallbeschreibungen
ansehen.
Da sich herausstellte, daß sowohl zwischen den Klassen "Kundenbestellung"
und "Nachbestellung" als auch zwischen den Klassen "Kunde" und "Lieferant"
Gemeinsamkeiten bestehen (Beispielsweise haben sowohl Kunden als auch Lieferanten
eine Adresse, und Kundenbestellungen wie Nachbestellungen setzen sich aus
Bestellposten zusammen), wurde beschlossen, zwei zusätzliche abstrakte
(d. h. nicht instanziierbare) Oberklassen "Bestellung" und "Geschäftspartner"
einzuführen, um diese Gemeinsamkeiten zu modellieren. Von "Bestellung"
wurden als instanziierbare Klassen "Kundenbestellung" und "Nachbestellung",
von "Geschäftspartner" "Kunde" und "Lieferant" abgeleitet.
Der Lieferschein wurde von uns an dieser Stelle des Modellierungsprozesses
nicht als eigene Klasse modelliert, da zum einen die für einen Lieferschein
zusammengestellten Informationen nach dem Ausdruck des Scheins nicht mehr
benötigt werden (Rückinformationen über ausgelieferte Bestellposten
werden über die "Liefer-Kartei" behandelt) und zum anderen eine Integration
der Lieferscheinerstellung in die Klasse "Liefer-Kartei" favorisiert wurde,
weil die Informationen in dieser Kartei zur Erstellung der Lieferscheine
herangezogen werden.
Mit der Erweiterung unserer ursprünglichen Klassenliste um die
beiden abstrakten Klassen "Bestellung" und Geschäftspartner hatten
wir die Klassen für den ersten Entwurf
des Klassendiagramms beisammen und gingen daran, die Beziehungen
zwischen den Klassen festzulegen.
Guided Tour: Weiter bei Festlegung von Beziehungen zwischen den Klassen
1. Änderung an den Klassen:
Problem:
-
Noch während der Erstellung des Klassenmodells fiel uns folgender
Fehler in unserer Modellierung auf: Wie im ersten
Entwurf des Klassendiagramms dargestellt, ist die Klasse "Bestellposten"
über eine Entweder-Oder- Assoziation mit den Klassen "Liefer-Kartei"
bzw. "Warte-Kartei" verknüpft. Außerdem besteht eine Kompositionsbeziehung
zwischen ihr und "Bestellung", der abstrakten Oberklasse für "Kundenbestellung"
und "Nachbestellung". Da nun letztere Klassen die Eigenschaften ihrer Oberklasse
erben, wäre damit nicht nur "Kundenbestellung" indirekt über
"Bestellposten" mit "Liefer-Kartei" bzw. "Warte-Kartei" verknüpft,
sondern auch "Nachbestellung". Mit anderen Worten: Damit würden nicht
nur Bestellposten von Kundenbestellungen entweder in die Liefer-Kartei
oder in die Warte-Kartei eingetragen, sondern auch Bestellposten von Nachbestellungen,
was nicht den Gegebenheiten von JWI entspricht (vgl. Anwendungsfall "Bestellung
bearbeiten" vs. Anwendungsfall "Fehlbestände
nachbestellen"). Außerdem zeigte es sich, daß die Klasse
"Bestellposten" zu allgemein war, um sowohl die Bestellposten von Kundenbestellungen
als auch die Bestellposten von Nachbestellungen adäquat modellieren
zu können.
Unsere Lösung:
Der zweite Entwurf des Klassendiagramms
enthält keine abstrakte Klasse "Bestellung" mehr, d. h. "Kundenbestellung"
und "Nachbestellung" sind voneinander entkoppelt. Die zugehörigen
Bestellposten werden durch die beiden neuen Klassen "Bestellposten Kundenbestellung"
bzw. "Bestellposten Nachbestellung" modelliert, die von der nunmehr als
abstrakte Oberklasse modellierten Klasse "Bestellposten" abgeleitet werden.
"Bestellposten" ist weiterhin mit der Klasse "Produkt" verknüpft,
so daß sich über die aufgebaute Vererbungsbeziehung auch die
beiden abgeleiteten Bestellposten-Klassen auf diese Klasse beziehen können.
Auswirkungen der Änderung:
-
Die an den Assoziationen vorzunehmenden Änderungen
werden im Abschnitt über die Beziehungen zwischen den Klassen beschrieben.
Guided Tour: Weiter bei den ersten beiden Änderungen an den Assoziationen
2. Änderung an den Klassen:
-
Problem:
-
Bei der Erstellung des Aktivitätsdiagramms zur Operation "lieferscheine_erstellen()"
der Klasse "Liefer-Kartei" stellten wir fest, daß wir für den
von uns vorgeschlagenen Algorithmus eine Möglichkeit brauchen, die
Daten der vorbereiteten Lieferscheine zwischenzuspeichern.
-
Unsere Lösung:
-
Wir führten eine Klasse "Lieferschein" ein, deren Instanzen die Daten
der erstellten Lieferscheine temporär speichern. Im zweiten Schritt
des Algorithmus wird dann jeder Instanz von "Lieferschein" die Nummer des
ausliefernden Lieferwagens zugeordnet. Wenn die Lieferscheine schließlich
ausgedruckt worden sind, können sämtliche Instanzen von "Lieferschein"
wieder gelöscht werden.
-
-
Auswirkungen der Änderung:
Diese Änderung hatte Auswirkungen auf die Attribute
und Operationen der Klasse "Liefer-Kartei" sowie auf das Sequenzdiagramm
und das Kollaborationsdiagramm
des Anwendungsfalls "Lieferscheine erstellen".
Guided Tour: Weiter bei der 3. Änderung der Beziehungen
3. Änderung an den Klassen:
-
Problem:
-
Bei der Erstellung der Sequenzdiagramme
fiel uns auf, daß wir bei unserer Modellierung bis zu diesem Zeitpunkt
noch keine Operationen vorgesehen hatten, die vom Benutzer aufgerufen werden
können, um die Bearbeitung der Anwendungsfälle anzustoßen.
Außerdem brauchten wir eine Möglichkeit, diverse für das
Anwendungssystem globale Daten zu verwalten (z. B. die zuletzt vergebene
Bestellnummer oder die Liste der lieferbaren Produkte).
-
-
Unsere Lösung:
-
Es wurde eine administrative Klasse "Verwaltung" eingeführt, die allgemeine
Verwaltungsaufgaben innerhalb des Anwendungssystems übernimmt. Sie
ist für die Initialisierung des Anwendungssystems verantwortlich und
bündelt die Operationen, die der Benutzer direkt anstoßen kann.
Außerdem verwaltet sie eine Reihe von Attributen, die für das
Anwendungssystem globale Daten beinhalten. Die Details sind in der Dokumentation
des Beispielprojekts nachzulesen.
-
Auswirkungen der Änderung:
Eine Instanz der Klasse "Verwaltung" wurde in fast alle Sequenz- und
Kollaborationsdiagramme integriert (Eine Ausnahme bildeten die Diagramme
zum Anwendungsfall "Lagerbestand
ermitteln", da dieser vom Benutzer des Systems nicht direkt angestoßen,
sondern vielmehr von anderen Anwendungsfällen benutzt wird (vgl. die
Darstellung zu den Anwendungsfällen).)
In das Klassendiagramm ging
die Änderung allerdings infolge einer Absprache mit dem Projektleiter
nicht ein.
Weiter bei der 2. Änderung des Sequenzdiagramms "Lieferschein_erstellen":
|
