In der Klasse Verwaltung werden sämtliche Klasse diese Programmes zusammengeführt und verwaltet. Daher wird während des Programmablaufes nur ein Objekt dieser Klasse benötigt. Die Operationen dieses Objektes werden durch das Hauptprogramm aufgerufen. Somit ist das Hauptprogramm ausschließlich eine Bedienungsoberfläche zur Steuerung der Klasse Verwaltung.

Die Klasse Verwaltung ist in diesem Programm implementiert in der Header-Datei "JWI_Klassen_Verwaltung.h" und den Dateien:

"JWI_Verwaltung_BestellungAufnehmenUndBearbeiten_Implementation.cpp",

"JWI_Verwaltung_FehlbestaendeNachbestellen_Implementation.cpp",

"JWI_LieferscheineErstellen_Implementation.cpp",

"JWI_RuecklaufBearbeiten_Implementation.cpp" und

"JWI_WareneingangBearbeiten_Implementation.cpp",

die alle jeweils die Implementation eines Anwendungsfalls beinhalten, die in den UML-Modell von JWI aufgeführt sind. Die Dateien:

"JWI_Verwaltung_public_Implementation.cpp" und

"JWI_Verwaltung_private_Implementation.cpp",

enthalten die restlichen kleineren Anwendungsfälle und Hilfsfunktionen.

Insgesamt hat die Klasse Verwaltung in ihrer Implementation folgend Form:

Attribute:

int zaehler_knr

int zaehler_bnr

int zaehler_lfdnr

int zaehler_lnr

int zaehler_pnr

int zaehler_lsnr

KundenbestellungenKartei kundenbestellungen

NachbestellungenKartei nachbestellungen

LieferKartei liefer_kartei

WarteKartei warte_kartei

KundenKartei kunden

LieferantenKartei lieferanten

ProduktKartei produkte

LieferscheinListe lieferscheine

Operationen:

Verwaltung()

~Verwaltung()

void DatenSpeichern()

void DatenLaden()

void BestellungAnnehmenUndBearbeiten()

void FehlbestaendeNachbestellen()

void LieferscheineErstellen()

void WareneingangBearbeiten()

void RuecklaufBearbeiten()

void NeuerKunde()

void NeuerLieferant()

void NeuesProdukt()

void KundendatenAendern()

void LieferantendatenAendern()

void ProduktdatenAendern()

void NachbestellungAendern()

void KundenbestellungAendern()

void BearbeiteteNachbestellungenLoeschen()

void BearbeiteteKundenbestllungenLoeschen()

private:

Kundenbestellung SucheKundenbestellung(int bestellnr)

Nachbestellung SucheNachbestellungLieferantenNr(int lieferantennr)

Bestellposten SucheBestellposten(int laufendenr)

Kunde SucheKunden(int kundennr)

Lieferant SucheLieferanten(int lieferantennr)

Produkt SucheProdukt(int produktnr)

Lieferschein SucheLieferschein(int bestellungsnr)

int BestimmeLieferwagenNummer(Lieferschein liefers)

5.6.1 Veränderungen zum ursprünglichen Modell

Die Implementation der Klasse Verwaltung des ursprünglichen Entwurf bereitete große Probleme und machte somit erhebliche Veränderungen notwendig. Die größten Veränderungen wurden bei den Attributen notwendig. Dies ist vermutlich darauf zurückzuführen, daß sich durch die Klasse Liste als allgemeine Verwaltungsgrundlage einige Annahmen des ursprünglichen Modells geändert haben.

Größere Veränderungen sind im Bereich der geführten Listen und Karteien aufgetreten. Zu den ursprünglichen Listen zur Verwaltung von Kundenbestellungen, Nachbestellungen, Kunden und Produkten sind noch Listen für Lieferanten, Lieferscheine und eine Warte- und eine Lieferkartei hinzugekommen. Es war eigentlich nur vorgesehen, Referenzen auf die Objekte, die zu diesen Listen gehören, in der jeweiligen Listen zu speichern. Dieses ist jedoch nicht möglich, da dann (bei einem objektorientierten Ansatz) sämtliche Objekte auf die die Listeneinträge Bezug nehmen verloren gehen würden. Deshalb enthalten die genannten Listen bzw. Karteien in der Implementation jeweils die ganzen Objekte.

Aufgrund des Zusammenhangs der Listen werden bis zum Zeitpunkt der vollständigen Bearbeitung von Kundenbestellungen die zugehörige Bestellposten zum Teil doppelt gespeichert: zum einen in der Liste der Bestellposten die ein Attribut jeder Bestellung ist und zum anderen in der Liefer- bzw. Wartekartei, die sämtliche noch nicht ausgelieferten Bestellposten enthält. Jedoch kommt dieser Doppelerfassung ein bessere Übersichtlichkeit und Verständlichkeit des Programmes zu Gute.

Ist eine Kundenbestellung bzw. Nachbestellung vollständig bearbeitet, so wird ihr Attribut "bearbeitet" auf 1 bzw. true gesetzt. Damit ist für das Programm die Bestellung bearbeitet, wird jedoch noch weiter in der jeweiligen Liste geführt. Eine endgültiges Löschen der bearbeiteten Bestellungen wird über die Operationen "BearbeiteteNachbestellungenLoeschen" bzw. "BearbeiteteKundenbestellungenLoeschen" durchgeführt.

Das einige der Listen, die von der Klasse Verwaltung geführt werden, als Karteien bezeichnet werden hat den Grund, daß die von der Klasse Liste abgeleiteten Karteien bei Bedarf noch um Operationen zur externen Speicherung und Verwaltung er Liste ergänzt werden können. Dadurch könnten alle Elemente der Listen, die zum jeweiligen Zeitpunkt nicht benötigt werden nur extern gespeichert werden.

Die Operationen des ursprünglichen Modells bestanden nur aus allen Anwendungsfällen des Anforderungskataloges (vgl. die Anwendungsfälle des ursprünglichen Entwurfs und die Sequenzdiagramme des ursprünglichen Entwurfs). Dieses führte bei der Implementation zu gewissen Problemen. So fehlten als erstes Operationen, um die Listen zu den Elementen Kunde, Lieferant und Produkt mit Objekten zu füllen. Der Grund für das Fehlen dieser Operationen war, daß diese Objekte für sämtliche Anwendungsfälle des Anforderungskataloges vorgegeben waren und somit in diesen Anwendungsfällen nicht enthalten sind. Um weiterhin die einmal eingegebenen Daten zu diesen drei Klassen nachträglich ändern zu können waren weitere drei Operationen notwendig, die die alten Daten dieser Objekte aufgrund eines Bildschirmdialoges ändern. Deshalb wurde die Implementation um die Operationen "NeuerKunde", "NeuerLieferant", "NeuesProdukt", "KundendatenAendern", "LieferantendatenAendern" und "ProduktdatenAendern" ergänzt

Weiterhin ist es manchmal notwendig, die Daten eines Objektes zu ändern, das über einen der vorgegebenen Anwendungsfälle in das System gelangt ist. Deshalb wurde die Klasse Verwaltung ebenfalls noch um die Operationen "NachbestellungAendern" und "KundenbestellungAendern" erweitert, die völlig analog zu den übrigen Operationen ablaufen, die Objektdaten ändern.

Außerdem wurden noch die beiden Operationen "BearbeiteteNachbestellungenLoeschen" und "BearbeiteteKundenbestellungenLoeschen" hinzugefügt, die nach bestimmten noch nicht vorgegebenen Kriterien bearbeitete Nachbestellungen bzw. Kundenbestellungen aus den zugehörigen Listen löschen. Die einfachste Form eines Kriteriums, das in dem Programm beispielhaft gewählt wurde ist das Attribut "bearbeitet".

Alle neu hinzugefügten Operationen haben einen sehr einfachen Aufbau. Deshalb entsprechen ihre Sequenz- und Kollaborationsdiagramme in etwa denen des Anwendungsfalls "Rücklauf bearbeiten".

Um dem Programm dauerhaft Daten zur Verfügung zu stellen wurde die Klasse Verwaltung um die Operationen Daten laden und Daten speichern erweitert, die sämtliche Elemente aller in ihr geführten Listen und Karteien speichern bzw. laden. Daher konnte die Operation "init" des ursprünglichen Modells durch den Konstruktor der Klasse Verwaltung und die über das Hauptmenü aufrufbare Operation "Daten" laden ersetzt werden. Der Aufruf des Konstruktors der Klasse Verwaltung geschieht automatisch beim Starten des Hauptprogrammes.

Im Verlauf der Implementation stellte es sich heraus, daß es günstig ist, die beiden Anwendungsfälle "Bestellung annehmen" und "Bestellung bearbeiten" zusammenzufassen. Die Gründe dafür sind die, daß nach der Annahme einer Bestellung alle für den Anwendungsfall "Bestellung bearbeiten" erforderlichen Informationen vorhanden und in einer Instanz von "Kundenbestellung" gespeichert waren. Hätte man nun die beiden Anwendungsfälle geteilt, so hätte zu einem späteren Zeitpunkt diese Instanz von Kundenbestellung erst wieder in der Kartei der Kundenbestellungen gesucht werden müssen. Außerdem läuft der Anwendungsfall "Bestellung bearbeiten" ohnehin ohne weitere Interaktion mit dem Benutzer ab. Daher bot es sich an, die Aufteilung der Bestellposten der Kundenbestellung auf die Liefer- bzw. Wartekartei direkt im Anschluß an die Aufnahme der Bestellung anzuschließen. Ein Grund für das Aufsplitten der beiden Anwendungsfälle lag vermutlich in der ehemaligen Bearbeitung der Bestellungen von Hand.

Schließlich mußten der Klasse Verwaltung noch einige Operationen hinzugefügt werden, die bestimmte Elemente der verschiedenen Listen nach vorgegebenen Schlüsseln suchen. Da die Klasse Liste allgemein für jeden Elementtyp definiert ist, ist es nicht möglich, diese Operationen als Teil der Liste zu implementieren. Dazu wären eindeutige Schlüssel, die auf jeden Objekttyp anwendbar sind, festzulegen. Dieses ist jedoch leider nicht möglich. Aus diesem Grunde mußte für jede Liste und jeden zugehörigen Such-Schlüssel in der Klasse Verwaltung eine eigene Operation implementiert werden. Diese Operationen werden ausschließlich innerhalb er Klasse Verwaltung verwendet und sind somit als private klassifiziert.

Damit hat die Klasse Verwaltung insgesamt die größten Veränderungen vom ursprünglichen zum implementierten Modell druchgemacht.

• zurück zur Anfangsseite
• weiter zur nächsten Klasse