Schritt-für-Schritt - Analyse der Aufgabenstellung

Die Analysephase

Das Schreiben einer Anwendung etwas komplexeren Ausmaßes ist eine heikle Angelegenheit und bedarf sorgfältiger Planung im Vorfeld. Warum? Ganz einfach: Diejenigen unter Euch, die sich bereits einmal an die Umsetzung eines eigenen Projektes gewagt haben (ob nun allein oder in Gruppen), haben sicher nach gewisser Zeit festgestellt, dass man an einigen Stellen des Programms noch andere Features hätte einbauen können, an die man zunächst gar nicht gedacht hatte. Oft geht das noch gut und man kann den fehlenden Code einfach ergänzen. Doch was ist, wenn zum Einbau der neuen Funktionen weitreichende Änderungen aller anderen Funktionen, wenn nicht des gesamten Projektes, nötig werden?
Ein weiterer Knackpunkt ist das Arbeitsumfeld der Anwendung. Wir haben sicher alle bereits von dem kleinen Schnitzer der NASA gehört, kurzerhand eine Mars-Sonde im All zu verlieren nur aufgrund der Tatsache, dass sich die Entwickler der Software nicht über die zu verwendenden Längeneinheiten einigen konnten. So etwas ist einfach nur peinlich und sollte heutzutage nicht mehr passieren. Dennoch geschehen diese fatalen Fehler und sind meistens in einem nicht ausreichenden Verständnis der Produktumgebung begründet. Im Fall unserer verschollenen Sonde war aber eher mangelnde Kommunikation im Team der Grund.

Nachdem sich das Team auf ein Prozessmodell geeinigt hat, und damit den ungefähren Ablauf des Projektes vor Augen hat, wird zunächst der Anwendungsbereich und die Aufgabenstellung in allen Einzelheiten analysiert. Die wichtigsten Punkte werden dabei in einer Prioritätenliste festgehalten. Mit diesen Daten geht es noch einmal zum Kunden, um alle Unklarheiten aus dem Weg zu räumen.
Die vorzeitige Erstellung eines Benutzerhandbuches hat sich für die Anforderungsermittlung als vorteilhaft erwiesen, die wiederum in der Ausarbeitung eines Pflichtenheftes endet. Dieses Dokument ist im weiteren Verlauf der Projektierung als Vertrag mit dem Kunden zu verstehen und wird dementsprechend von ihm unterschrieben. Neben diesen etwas weniger formalen Dokumenten hat es sich für die Kommunikation als vorteilhaft herausgestellt, diese in eine etwas allgemeinverständlichere Form zu bringen. Dazu überführt man Schritt für Schritt die textuellen Beschreibungen in eine passende Diagrammbeschreibung. Die statischen Beziehungen werden sich in einem Klassendiagramm wiederfinden, die dynamischen in einigen Sequenzdiagrammen. Als Zwischenschritt bietet sich die CRC-Karten-Methode an. Zum Ende der Analyse sollte feststehen, wie lange in etwa die Entwicklung dauern wird und wie hoch die materiellen Anforderungen (Teamstärke, Zeitaufwand und weitere Resourcen) sind.

Viele werden sich jetzt fragen, wann denn ihr unter viel Mühen erlerntes Salespoint-Wissen zur Anwendung kommt. Dazu ist zu sagen, dass man sich in der Analyse nicht auf ein Framework oder System festlegen sollte. Vielmehr soll die Aufgabenstellung ohne "Hintergedanken" analysiert werden. Wenn man das Framework jetzt schon einbinden wollte, dann würden viele sonst möglichen Denkmuster und Lösungswege verbaut, da man nur nach Äquivalenzen im Framework sucht. Zudem steht meist zu dieser frühen Phase des Projektes noch nicht fest, ob, und wenn, welches Framework eingesetzt werden wird. Im Entwurf kommen wir dann noch früh genug auf das Framework zurück.

Festlegung auf ein Prozessmodell

In unserer langjährigen Erfahrung in der Projektierung von Anwendungen haben wir es uns zur Gewohnheit gemacht, mit der Entwicklung eines passenden Prozessmodells zu beginnen. Für uns ist nicht nur der dort verankerte zeitliche Rahmen mit seinen zahlreichen Meilensteinen (milestones!) wichtig. Das Modell bildet auch einen organisatorischen Rahmen, eine Vorlage für den Umgang mit Problemfällen, wie beispielsweise den Rückfall in eine frühere Entwicklungsphase aufgrund von Änderungen im Design.

Natürlich gibt es verschiedene Möglichkeiten und Wege ein solches Modell zu erstellen. Sie hängen davon ab, wie konkret und detailliert man es am Ende haben will. Für uns war der organisatorische Rahmen der wichtigste Punkt, an dem wir auch die Modellerstellung festmachten. Er wird, wenn er einmal steht, nicht mehr geändert. Viele schmerzhafte Erfahrungen, die meist aus dem Verlust des Rahmens und dem daraus resultierenden Chaos bestehen, lehrten uns das. Andere Details, wie beispielsweise einige (nicht alle!) Meilensteine, werden zwar angegeben, können aber noch im Nachhinein geändert werden. Sie stellen lediglich Richtlinien dar.

Die Vielzahl der existierenden Prozessmodelle ruft natürlich eine Menge Befürworter und Gegner des einen oder anderen Modells auf den Plan. Fast jedes Teammitglied plädierte für ein anderes Modell, was sich als sehr produktiv erwies. Zum Finden des für uns am besten passenden - des einzig richtigen Modells wenn man so sagen will - könnte man folgende Vorgehensweise anwenden:

• Zunächst sollte jedes Teammitglied aufschreiben, was genau (immer mit Bezug auf unser Projekt) für sein favorisiertes Modell spricht und welche Punkte gegen die von den anderen Personen genannten Modelle sprechen.
• Die Notizen werden eingesammelt und einer Prüfung unterzogen, ob auch niemand zu großzügig in der positiven Beurteilung seines Modells war.
• Schließlich werden die Pros und Kontras an einer Tafel zusammengetragen und diskutiert.

Für das hier betrachtete Projekt bietet sich das an, was man als das Wasserfallmodell bezeichnet. Grob zusammengefasst sprachen etwa die folgenden Punkte dafür:

• Der zeitliche Aufwand für die Entwicklung unseres Produktes würde verhältnismäßig gering ausfallen, weshalb sich eine straight-forward Methode empfahl.
• Sollten Fehler auftreten, stören die nicht den Ablauf im Markt oder vernichten wichtige Datenbestände. Die Fehlertoleranz ist also recht hoch und langwieriges Testen ist noch nicht nötig.
• Von den meisten Entwicklern im Team wurde zunächst die unter der Bezeichnung extreme programming bekannte Technik bevorzugt (hauptsächlich aufgrund der geringen Entwicklungszeit). Aber einige Teammitglieder verfügten noch über keinerlei Erfahrung auf dem Gebiet und müssten erst eine entsprechende Nachschulung antreten, was alles nur verzögern würde.

Analyse des Aufgabenbereiches

"Denn sie wissen nicht, was sie tun."
Mit diesen Worten könnte man viele Dramen der Software-Entwicklung kurz aber umfassend beschreiben. Sich das Arbeitsumfeld eines zu erstellenden Produktes genau anzusehen, werden sicher viele als überflüssiges Zusatzwissen abtun. Doch um eben genanntes Szenario zu vermeiden, ist es absolut unerlässlich, sich ein exaktes Bild der späteren Einsatzumgebung der Software zu machen, die man entwickelt. Alle wichtigen Details gehören aufgeschrieben. Jedem Mitglied des Entwicklungsteams müssen die Voraussetzungen, mit denen gearbeitet wird, bekannt sein. Und alle müssen von denselben Voraussetzungen ausgehen (um derlei Kapriolen wie mit dem climate orbiter zu vermeiden). Nicht umsonst sind dem Thema der Produktumgebung mehrere Kapitel des Pflichtenheftes gewidmet.

Hinweis:
Den meisten Praktikumsgruppen wird die Möglichkeit der Besichtigung ihres (meist fiktiven) Auftraggebers leider nicht vergönnt sein. Sie müssen den Anwendungsbereich zusammen mit ihrem Tutor (der im Verlauf des Praktikums von Zeit zu Zeit die Rolle des Auftraggebers übernimmt) kennenlernen. Legt gemeinsam fest, wie Ihr Euch den Aufbau Eures jeweiligen Anwendungsbereiches vorstellt und wie die Abläufe dort aussehen. Die Aufgabenstellungen allein geben oft nicht viel her und Eure Fantasie wird Euch vermutlich über's Ziel hinausschießen lassen. Grenzt deshalb in Zusammenarbeit mit Eurem Tutor das Umfeld genau ein. Dabei solltet ihr ruhig erstmal eure Gedanken schweifen lassen. Die Liste der möglichen Funktionen ist nahezu unendlich. Sprecht euch aber danach unbedingt mit eurem Tutor ab, da er noch am ehesten einschätzen kann, was alles machbar ist. Dabei hilft die frühzeitige Abgrenzung von Pflicht- und Wunschkriterien. Viele der etwas abgedrehteren Ideen werden wohl eher den Weg zu den Wunschkriterien finden. Wie sich aber in den letzten Jahren gezeigt hat, bleibt für einige Gruppen immer noch genug Zeit, um solche Features dann auch zu implementieren.
Ein mögliches Beispiel einer solchen Ausschmückung findet ihr im nächsten Abschnitt.

Am Tag nach der Vorstellung des Projektes durch die Firmenleitung trafen wir uns noch einmal mit einigen Vertretern des Marktes um uns ein genaues Bild des Aufbaus des Großhandels und der dort ablaufenden Geschäftsprozesse zu machen. In unserem Team befand sich lediglich ein Sachverständiger für dieses Fachgebiet: Er hatte als Schüler im Laden seiner Eltern gejobt, was ihn sicherlich an Erfahrungen reicher machte, uns aber nicht wirklich weiterhalf. Deshalb kamen wir fast ohne Grundwissen (mal abgesehen von den persönlichen Vorstellungen jedes Einzelnen) zum Markt, dessen Aufbau sich zunächst grob in fünf Bereiche unterteilte:

• die Verkaufshalle mit einem Informationsstand am Eingang und den Kassen am Ausgang,
• ein Hochregal-Lager für die Warenbestände,
• das Bürogebäude mit der Verwaltung, dem Besprechungsraum und dem Büro des Chefs,
• der Kundenparkplatz und schließlich
• der Fuhrpark mit Verladerampe für ein- und ausgehende Waren.

Der Markt wird vom Kunden an einem Informationsstand betreten, an dem er von einem Mitarbeiter begrüßt (und beraten) wird und wo Unmengen an Info-Broschüren und Werbematerial der verschiedensten Anbieter für ihn bereitliegen. Aus dem Supermarkt kennt man es so, dass in den Regalen stets mehrere Produktexemplare der verschiedenen Anbieter liegen, die man in seinen Korb packt. In unserem Großhandel sieht das ein wenig anders aus, was uns anfangs auch überraschte.
Die Verkaufshalle besteht natürlich zum Großteil aus Regalen. Doch darin befindet sich von jedem Produkt immer nur ein Beispiel-Exemplar. Daneben ist stets eine Tafel mit einer Beschreibung der wichtigsten Eigenschaften, wie Hersteller, Preis usw. angebracht. Wenn man nach einer Analogie sucht, dann sollte man sich am Besten der einer Gärtnerei bedienen, in denen neben den Tüten mit den Sämereien immer auch ein kleines Beet davon befindet.
Die eigentlichen Warenbestände liegen übersichtlich sortiert und verpackt im Lager, was eine noch weit größere Halle ist, in der die Waren palettenweise aufgestapelt sind. Eine Aufteilung in verschiedene Produktkategorien und die anschließende alphabetische Sortierung innerhalb jeder Kategorie machen ein schnelles Auffinden gesuchter Artikel durch die Lagerarbeiter möglich.

Den räumlich kleinsten (aber nicht weniger wichtigen) Teil der Firma stellt das Bürogebäude dar. Dort finden intensivere Beratungsgespräche mit Großkunden statt und hier hat natürlich die Verwaltung (inkl. dem Chef) ihren Sitz.
Abgerundet wird alles durch die an das Lagerhaus angegliederte Waren-Verladerampe mit dem Fuhrpark der Firma. Hier werden angelieferte Waren von den Lagerarbeitern entgegengenommen und Lieferungen an Adressen außerhalb der Firma in Transporter verpackt. Die drei LKWs und zwei Kleintransporter der Firma stehen dazu auf einem Parkplatz direkt gegenüber der Verladerampe, neben dem Kundenparkplatz, der von der Rampe aus ebenfalls zugänglich ist.
Der Furhpark und die Auslieferung an den Kunden wurden hier zwar exemplarisch beschrieben, spielen aber im weiteren Projekt keine Rolle mehr. Der Eingriff in die vorhandene Architektur wäre an diesem Punkt zu groß, als dass er im Rahmen des Praktikums gelöst werden könnte.

Identifizierung von Anwendungsfällen

Als wichtiges Hilfsmittel für das Verständnis der Geschäftsabläufe haben sich die Anwendungsfall-Diagramme erwiesen (auch hier gilt: Grafiken prägen sich besser ein und sind übersichtlicher als verbale Beschreibungen). In Verbindung mit der Nennung der beteiligten Akteure und einer detaillierten verbalen Beschreibung helfen sie, diese Abläufe in all ihren Einzelheiten in Bezug auf die Anwendung zu erfassen.

Ein in dieser Phase häufig begangener Fehler ist, die Anwendungsfall-Diagramme zur Darstellung des zeitlichen Ablaufs der Geschäfsprozesse zu missbrauchen. Wir wollen eindringlich darauf aufmerksam machen, dass use cases nicht für diesen Zweck geeignet sind! Greift für die Darstellung des zeitlichen Ablaufs bitte auf Sequenzdiagramme (ja, auch schon in dieser Phase!) zurück.

Hinweis:
In der Analysephase wird oft der Fehler gemacht, so viele Use-Case-Diagramme wie möglich zu erstellen, um auch jeden noch so kleinen Fall abzudecken. Das kann jedoch dazu führen, dass die Diagramme nur noch sehr wenig zum Verständnis des Problems beitragen. Daher geht es darum, die Diagramme in Form und Anzahl so einfach wie möglich zu halten, und dennoch alle wichtigen Fälle zu berücksichtigen. Das klingt jetzt ein wenig wie die Quadratur des Kreises. Daher ist auch hier die Abstimmung mit dem Tutor sehr wichtig. Als Richtlinie könnten zwei bis drei Use-Case-Diagramme gelten, die jeweils einen anderen Aufgabenbereich abdecken. Wenn diese jedoch zu groß und unübersichtlich werden, dann empfiehlt sich die Aufteilung auf mehrere Diagramme. Zeichnet auch nur die Anwendungsfälle ein, die sich klar von anderen abgrenzen. Es macht keinen Sinn, die Fälle "kaufe Artikel A" und "kaufe Artikel B" als zwei getrennte Fälle einzutragen. Auch systeminterne Abläfe, wie z.B. das Prüfen von Parametern, gehören nicht in die Use-Case-Diagramme. Bitte verzichtet der Einfachkeit halber auf "include" und "extend" Beziehungen.

Kunden
Zunächst einmal wollen wir klären, was wir unter Kunden verstehen. Die Kunden unseres Großhandels haben nämlich nicht viel mit denen herkömmlicher Supermärkte gemeinsam. Besucher unseres Handels sind meistens Vertreter (oder Einkäufer) anderer Firmen (gewöhnlich Handwerksbetriebe).
Das folgende Anwendungsfall-Diagramm veranschaulicht die Funktionen der Software, die der Kunde nutzt, während er sich im Markt aufhält. Es wird anschließend noch ausführlich beschrieben.

Anmeldung
Will nun ein solcher Kunde bei uns einkaufen, betritt er den Markt immer am Informationsstand. Daran kommt niemand unbemerkt vorbei. Das ist unter anderem eine Art Rezeption, wo sich der Kunde durch Vorzeigen seiner Kundenkarte identifiziert. Handelt es sich beim Einkäufer um einen neuen Kunden des Großhandels, füllt er zunächst ein Formular mit allen kundenrelevanten Daten (u.a. die Lieferadresse) aus bevor ihm seine Kundenkarte ausgehändigt wird.
Abschließend wird er mit einem persönlichen Assistenten in Form eines PDA ausgestattet, der ihn während seines Einkaufs begleitet, ihn über Sonderangebote informiert und seinen (virtuellen) Einkaufskorb repräsentiert. Desweiteren bietet der PDA dem Kunden während seines gesamten Aufenthaltes im Markt die Möglichkeit, seine Kundendaten zu ändern.

Einkauf
Wie bereits erwähnt wurde, liegen in den Regalen der Verkaufshalle Beispielexemplare der angebotenen Produkte aus. Dort befinden sich immer auch Informationstafeln mit den wichtigsten Artikeldaten wie dem Preis, dem Hersteller, Anwendungstipps etc.. Diese Liste von Daten kann der Kunde nun aber auch über seinen PDA abrufen. Hier bekommt er eine Übersicht der Angebotspalette (die er auf dem Display nach Produktkategorien filtern und nach Namen sortieren kann) mit den jeweils verfügbaren Mengen und dem Stückpreis.
Die Detailinformationen zu jedem Artikel lassen sich durch Auswählen des entsprechenden Artikels anzeigen. Sollte der Kunde bereits Exemplare des angezeigten Artikels in seinem Einkaufskorb haben, wird die darin befindliche Menge ebenfalls angezeigt.

Einkaufskorb
Der persönliche Assistent (in Form des PDA) des Kunden stellt unter anderem seinen (virtuellen) Einkaufskorb dar. Sowohl aus der Artikelübersicht als auch aus der Detailansicht können Artikel zum Kauf vorgemerkt werden. Ich betone ganz besonders das vorgemerkt, was soviel wie reserviert bedeutet. Denn die Produktexemplare verbleiben zunächst im Lager an ihrem Platz liegen. Es ist nur vom Computersystem dafür zu sorgen, dass die zum Kauf vorgemerkte Menge ab dem Zeitpunkt ihrer Markierung für andere Kunden nicht mehr zum Kauf zur Verfügung steht. Bevor die Produktexemplare dem Kunden gutgeschrieben werden können, muss natürlich geprüft werden, ob die von ihm ausgewählte Menge überhaupt zur Verfügung steht. Ist das nicht der Fall, wird er freundlichst darauf hingewiesen.

Von der Übersicht der angebotenen Artikel aus gelangt der Kunde leicht in das Übersichtsfenster seines persönlichen Einkaufskorbes. Hier ist es dem Kunden wieder möglich, sich die Details der Artikel anzuschauen oder den Inhalt seines Warenkorbes zu ändern. Das betrifft zum Einen eine Änderung der eingekauften Produktexemplare und zum Anderen das Löschen eingekaufter Artikel.

Bezahlung
Der einzige Weg aus dem Markt heraus führt an den Kassen vorbei. Dort geben die Kunden ihre PDAs ab, deren Daten anschließend vom Kassierer abgerufen werden. Nach dem Datentransfer wird der zu zahlende Betrag berechnet und ggf. ein Rabatt für treue Kunden abgezogen. Wenn der Kunde bestätigt hat, den Betrag zahlen zu wollen, kann er noch zwischen verschiedenen Zahlungsarten (in Bar oder mit Kreditkarte) wählen. Abschließend gibt der Kassierer die Artikelliste an das Lager weiter, wo die zuständigen Lagerarbeiter über die Lieferung informiert werden.

Einkauf abbrechen
Dem Kunden muss es jederzeit möglich sein, den Einkauf unverzüglich abzubrechen (seine Gründe dafür sind erstmal egal). Es läuft immer darauf hinaus, dass der Inhalt seines virtuellen Einkaufskorbes wieder in den Bestand der zum Kauf durch Kunden verfügbaren Produkte übergeht und der Kunde am Informationsstand (wo er den PDA wieder abgibt) den Markt verlässt.

Auslieferung
Das Lager ist in verschiedene Produktkategorien eingeteilt und jedem Lagerarbeiter ist eine Liste solcher Kategorien zugeordnet, um die er sich während seiner Arbeitszeit kümmern muss. Bei Lieferung neuer Waren muss er die Exemplare, die seine Kategorie betreffen, dort einordnen. Beim Kauf von Artikeln durch Kunden sucht er die Artikel zusammen und bringt sie zum, vorher vom Kunden angegebenen, Lieferort oder Stellplatz.

Marktmanagement
So ein Großhandel läuft natürlich nicht von alleine. Vielmehr steht hinter dem ganzen ein ausgeklügeltes Managementsystem. Dieses gliedert sich grundsätzlich in drei Teile, die der Übersicht halber in einem Use-Case-Diagramm zusammengefasst wurden.

Personal
Damit der Großhandel seinen regulären Betrieb überhaupt aufnehmen kann, braucht er natürlich Personal.
Der Manager kümmert sich um das Einstellen, Zuteilen und Entlassen von Mitarbeitern. Bei der Einstellung werden die Daten des neuen Mitarbeiters in das Computersystem eingegeben. Anschließend wird ihm eine Stelle im Markt zugeteilt, an der der "Neue" fortan seine Dienste verrichten darf. Bei Lagerarbeitern kommt hinzu, dass ihnen bestimmte Kategorien des Lagers zugeteilt werden, die sie zu versorgen haben. Kommt es dann doch einmal zu einer Entlassung, wird dem Mitarbeiter ein Entlassungsgeld gezahlt, dass auf Basis der Dauer seiner Beschäftigung und dem zuletzt gezahlten Gehalt berechnet wird.

Angebot
Zum Füllen der Regale müssen natürlich zunächst Waren vom Marktmanager eingekauft werden. Für die Bestellung steht dem Manager ein erweiterter Artikelkatalog zur Verfügung (der Katalog des Kunden enthält ja nur die im Markt verfügbaren Artikel). Hier wählt der Manager die Waren zur Bestellung (direkt beim Produkthersteller) aus und kann die Bestellung für einen vom Hersteller abhängigen Zeitpunkt zur Lieferung vormerken. Trifft diese dann ein, wird sie von Lagerarbeitern beim Tageswechsel kontrolliert und die einzelnen Positionen abgehakt. Verspätete Lieferungen oder nicht gelieferte Positionen können auf ein späteres Datum verschoben oder ganz gestrichen werden.
Die für den Verkauf von Artikeln wichtigen Daten, wie sein Verkaufspreis, können jederzeit vom Manager geändert werden. Für die Umsetzung gibt es zwei Alternativen: Die Änderung erfolgt sofort und erscheint noch im selben Moment auf allen Anzeigen des Marktes (auch die Anzeige des Kunden-Einkaufskorbes wird sofort aktualisiert) oder alle Änderungen eines Tages werden erst beim Tageswechsel wirksam.

Inventur
Es kann ja immer wieder passieren, dass ein Lagerarbeiter einen Artikel zuviel verpackt oder bei einer Lieferung weniger Waren geliefert werden als bestellt wurden und beides, ohne dass es im Datenbestand der Anwendung vermerkt wird.
Für die Durchführung der Inventur muss der Markt geschlossen sein. Der Manager wählt verschiedene (vertrauenswürdige) Lagerarbeiter für die Kontrollen aus und teilt ihnen die Produktkategorien zu, für deren Kontrolle sie verantwortlich sein werden. Dort vergleichen sie die Bestände in den Lagerregalen mit den Einträgen im Computersystem und vermerken Fehlbestände in Listen, die nach der Inventur dem Manager ausgehändigt werden.

Statistiken
Um den Geschäftsbetrieb besser überwachen zu können, gab es schon immer Statistiken und Bilanzen. Unser Auftraggeber ist natürlich an einer Umsatzübersicht interessiert, wie auch an Verkaufsstatistiken für die verschiedenen Produkte sowie Produktkategorien. Mit Statistik ist hierbei gemeint, aufzuzeigen, wieviele Artikel in einem gewissen Zeitraum ge- und verkauft wurden. Dazu zählt auch eine Übersicht, in der der Manager ablesen kann, wie lange in etwa der Bestand eines bestimmten Produktes noch reichen wird.

Ein orientierendes Kundengespräch

In den vergangenen Tagen haben wir versucht, uns ein Bild von den verschiedenen Geschäftsabläufen zu machen, die in einem Großhandel tagtäglich abgewickelt werden. Nachdem wir die Abläufe verstanden, haben wir versucht, sie so zu modellieren, dass eine Einbettung in unsere Anwendung prinzipiell möglich ist. Da es aber immer gewisse Feinheiten gibt, die man als Laie in so kurzer Zeit unmöglich erkennen kann und es in unserer Wunschliste sicher auch Punkte gab, deren Umsetzung der Kunde gar nicht wollte, setzten wir uns nochmal mit Firmenvertretern zusammen, um eine endgültige Prioritätenliste zusammenzustellen.

Streichungen
Wir präsentierten also unsere Anwendungsfall-Diagramme und lieferten einige Erklärungen dazu, wie wir uns den Ablauf vorstellen. Dabei wurde von anderer Seite häufig genickt und auch manchmal fragend der Kopf geschüttelt, worauf ein reges "Notizen machen" folgte. Nach unserer Präsentation gab es deshalb eine Menge Fragen und wir kamen zu folgenden Streichungen:

• Zunächst müsste die Arbeitsplatzzuteilung des Personals überarbeitet werden. Es wird in Zukunft nicht mehr so sein, dass jeder Lagerarbeiter für einen bestimmten Teil des Lagers (eine oder mehrere Produktkategorien) zuständig ist. Stattdessen bekommen die Lagerarbeiter ihre Aufträge so zugeteilt, wie sie gerade frei sind - wohl aus ökonomischen Gründen.
• Desweiteren konnte man niemanden finden, der ständig die Informationen über Sonderangebote aktualisieren möchte und man stellte fest, dass eine persönliche Beratung am Informationsstand in diesem Fall mehr Kundennähe bringen würde. Wir merkten aber an, dass bei einer Erweiterung der Anwendung zum Online-Handel eine solche Funktion unbedingt dazu gehört und setzten diesen Punkt auf die Wunschliste mit den Erweiterungen für Version 2.0.
• Die Durchführung einer Inventur ist ein solch komplexes Unterfangen, dass man in dieser Programmversion dankend darauf verzichtet hat. Auch diese Produktfunktion soll (zusammen mit der Fehlbestandskorrektur durch den Manager) unbedingt für Version 2.0 in Betracht gezogen werden.
• Die Erstellung der Bilanz ist ein sehr komplexer Vorgang, der weit über die Buchführung des Warenbestandes und der Kassenzettel hinausgeht. Deshalb soll die Anwendung (in dieser Version) nicht damit betraut werden.
• Ein Warenkatalog wird zentral von den Herstellern verschickt und nicht vom Händler eingegeben. Deshalb bestand hier kein Bedarf an manueller Eingabe von Artikeldaten.

Fehlende Funktionen
Schließlich haben wir auch ein paar Funktionen übersehen, deren Einarbeitung unbedingt erfolgen muss:

• Eine Inventur ist ganz gut und schön. Doch was machen die Lagerarbeiter, wenn sie im laufenden Geschäftsbetrieb einen Fehlbestand im Lager bemerken? Sie müssen die Möglichkeit erhalten, Fehlbestände zu jeder Zeit zu melden und eine Aktualisierung des Datenbestandes der Anwendung herbeizuführen.
• Eine sehr wichtige Angelegenheit stellt der sogenannte Tagesabschluss dar. Bei Schließung des Marktes werden die Lieferungen des vergangenen Tages entladen (die Lagerarbeiter haben tagsüber genug andere Dinge um die Ohren). Schließlich möchte sich das Management im Rahmen dieses Tagesabschlusses noch die Umsatzstatistik des vergangenen Tages anschauen.
• In der Analyse sahen wir bisher keine Notwendigkeit für die Verwaltung des Kundenstammes durch den Marktmanager. Die Firma verlangt aber danach, weshalb dem Bereich der Kundenbetreuung noch Funktionen für die übersichtliche Darstellung des Kundenstammes und Bearbeitung der Kundendaten hinzuzufügen sind.

Benutzerhandbuch, Version 0.1

Wir haben doch noch gar kein Stück Code geschweige denn irgendeine Oberfläche, die es zu beschreiben gäbe. Wozu also ein Handbuch schon jetzt anfangen? Diese Frage wird sicherlich bei vielen von Euch aufkommen. Dabei liegt die Antwort doch auf der Hand! Was machen wir hier denn? Genau: wir analysieren. Und ein Handbuch ist eine fantastische Möglichkeit dazu - eine häufig nicht beachtete Unterstützung der Analyse. Schließlich wollen wir doch die Fallen, die in der späteren Entwicklung noch auf uns warten möglichst frühzeitig erkennen. Deshalb schreibt man die groben Abläufe und Zusammenhänge diesmal im Blickwinkel des Benutzers der späteren Anwendung auf. Grob deshalb, weil wir ja wirklich noch kein Stück GUI haben.

Aus Gründen der Übersichtlichkeit haben wir das Benutzerhandbuch jeweils aus der Sicht jedes möglichen Nutzers der Anwendung geschrieben. Zunächst wollen wir jedoch die ganz besonderen Eigenheiten des SalesPoint-Frameworks im Bezug auf die Benutzeroberfläche erklären. Sie sind nicht nur für jede Anwendung, die mit dem Framework erstellt wurde einheitlich, sondern auch für jeden der Nutzer unserer Anwendung. Eine Zusammenfassung für alle Nutzer empfiehlt sich also.

Das Anwendungsfenster unterteilt sich zunächst in zwei Bereiche: die Menüleiste und den Rahmen für die vielen verschiedenen SalesPoint-Fenster (mit SalesPoint bezeichnen wir hier tatsächlich den Ort der Interaktion des Nutzers mit der Anwendung und nicht das Framework). Im Anwendungsmenü befinden sich immer Funktionen für die Beendigung der Anwendung und das Starten bzw. Umschalten von/zwischen SalesPoint-Fenstern. Diese können im Rahmenfenster nebeneinander existieren und sich auch überlappen. Jedes dieser internen Fenster kann über ein eigenes Menü für die Funktionen des SalesPoints verfügen.

Zunächst einmal muss sich ein Kunde in der Anwendung als solcher erkenntlich machen. Die Identifikation erfolgt in einem Dialogfenster für die Eingabe von Benutzernamen und Passwort. Sind beide korrekt, bekommt er ein neues Fenster innerhalb des Rahmenfensters geöffnet, in dem sich der Kunden-Salespoint befindet. Von dort aus kann er seine Kundendaten in einem Eingabedialog ändern oder den Einkauf beginnen, wobei er in die Ansicht seines Einkaufskorbes wechselt.

Im Eingabedialog für die Änderung der Kundendaten werden dem Nutzer zunächst die aktuell eingestellten Daten angezeigt. Sie können alle (bis auf die Kundennummer), ja selbst das Geschlecht, nachträglich geändert werden. Nach der Änderung der Daten findet eine Überprüfung der eingegebenen Daten statt und der Kunde wird über dabei aufgetretene Fehler und Unstimmigkeiten mit Hilfe von Meldungsfenstern informiert. Sind die Eingaben schließlich alle korrekt, werden die alten Kundendaten von der Anwendung mit den neuen Eingaben überschrieben.

Entscheidet sich der Kunde für den Einkauf im Großhandel, gelangt er zur Ansicht des Einkaufskorbes mit dem Marktangebot. Dort kann er aus der Liste der Waren, die der Markt momentan anbietet, Produkte mit Angabe der gewünschten Menge in den Einkaufskorb legen und sie auch wieder zurück in den Markt befördern, wo sie anschließend wieder anderen Kunden zum Kauf zur Verfügung stehen. Diesen Prozess kann er beliebig oft wiederholen, bis er sich für das Ende des Einkaufs entscheidet und zur Kasse begibt. Danach wird er in die Kassenwarteschlange eingereiht und wartet auf seinen Aufruf durch den nächsten freien Kassierer.

Nach der Anmeldung bei der Anwendung findet sich der Kassierer in der Übersicht der Kassenwarteschlange wieder. Dort sind alle Kunden aufgelistet, die momentan auf die Bezahlung ihrer gekauften Waren warten. Hier wählt er einen aus und leitet seine Bezahlung ein. Im nächsten Fenster wird eine Zusammenfassung des Einkaufs in Form eines Kassenzettels angezeigt. Den tatsächlich zu bezahlenden Betrag kann der Kassierer aber noch durch die Änderung des Kundenrabattes (der schon vorausberechnet eingetragen wurde) nachträglich verändern. Schließlich kann er noch die Art der Bezahlung, die vom Kunden gewünscht wird, eingeben. Sind alle Eingaben gemacht und die Bezahlung des Geldbetrages durch den Kunden bestätigt worden, wird die Auslieferung der Artikel durch einen Lagerarbeiter in die Wege geleitet. Der Kassierer selbst beginnt von vorn in der Ansicht der Kundenwarteschlange.

Auch der Lagerarbeiter muss sich natürlich erst einmal bei der Anwendung als Nutzer identifizieren. Nach der Auswahl des nächsten zu bearbeitenden Lieferauftrages kommt er zur Ansicht mit der Liste der zu liefernden Waren. Die kann er eine nach der anderen als "geliefert" abhaken oder einen Fehlbestand der Ware an das Management melden. Sind alle Waren geliefert worden, gilt der Lieferauftrag als erledigt und der Lagerarbeiter fährt mit dem nächsten Kunden fort.

Der wichtigste Teil der Benutzeroberfläche des Managers ist die Verwaltung der vom Großhandel angebotenen Waren. In einem Fenster kann er deshalb aus der Liste aller Artikel Produktexemplare für den Kauf durch den Großhandel auswählen. Er hat einen ähnlichen Einkaufskorb wie der Kunde und wählt neben dem Artikel selbst auch die Anzahl der zu liefernden Exemplare aus. Ist er mit dem Einkauf fertig, werden die Bestellungen abgeschickt und das Geld vom Marktkonto abgezogen. Die Waren stehen dem Markt dann nach Ablauf der Lieferdauer zur Verfügung. Zum Angebot gehört auch die Verwaltung des Produktkatalogs. Verschiedene Daten der angebotenen Artikel, u.a. der Verkaufspreis oder dessen Beschreibung können dort vom Manager geändert werden.

Die Verwaltung des Personalstammes beginnt mit einer Auflistung des im Markt angestellten Personals. Aus dieser Liste kann der Manager einen Eintrag/Mitarbeiter auswählen und seine Daten in einem entsprechenden Eingabedialog ändern. Desweiteren ist die Entlassung eines zuvor ausgewählten Mitarbeiters möglich wie auch die Neueinstellung von Personal. Dazu wird dem Manager ein Dialogfenster präsentiert, wo er die Personaldaten des neuen Mitarbeiters eingeben kann. Der "Neue" erscheint fortan in der Liste des Personals und versieht seinen Dienst im Großhandel.

Sicher stehen dem Manager auch Mittel zur Verwaltung des Kundenstammes zur Verfügung. Aus einer Liste aller Kunden, mit denen der Markt zu tun hat, kann er Manager wieder einen Eintrag für die weitere Bearbeitung auswählen. In einem Dialogfenster für die Bearbeitung der Kundendaten kann beispielsweise der dem Kunden gewährte Treuerabatt geändert werden. Auch die Beendigung der Geschäftsbeziehung zum Kunden ist möglich.

Abschließend beinhaltet der Manager-SalesPoint auch zwei Funktionen zum Öffnen und Schließen des Marktes bzw. deren Ankündigung für die Mitarbeiter und Kunden um sich auf das Ereignis vorzubereiten. Die statistischen Übersichten stehen hier ebenso zur Verfügung.

Das Pflichtenheft

All unsere bisherigen Bemühungen kommen nun in einem Pflichtenheft zum Ausdruck, das eine detaillierte verbale Beschreibung aller Anforderungen beinhaltet, die von uns und dem Auftraggeber an das zu erstellende Produkt gestellt werden. Dieses Dokument ist eines der wichtigsten Artefakte, die im Laufe der Entwicklung erstellt werden, und sollte dementsprechend sorgfältig geschrieben werden. Es stellt quasi den Vertrag dar, den unsere Firma mit dem Auftraggeber vereinbart. Er wird vom Auftraggeber unterschrieben, der sich damit verpflichtet uns für alle im Pflichtenheft enthaltenen Punkte zu bezahlen. Er muss uns allerdings nur dann bezahlen, wenn wir unseren Teil der Vereinbarung korrekt und vor allem vollständig erledigen (d.h. alle Punkte des Pflichtenheftes in das Produkt integrieren).
Noch eine wichtige Bemerkung: nachträgliche Änderungen der Analysephase sollten sich in einer neuen Version des Pflichtenheftes wiederfinden, die ebenfalls vom Auftraggeber durch seine Unterschrift abgesegnet werden muss.

Kommen wir nun zur Gliederung des Dokuments. Wie so oft, gibt es auch hier einen Industriestandard (VDI/VDE), der für unsere Zwecke allerdings unpassend und viel zu kompliziert ist. Es gibt eine Vereinfachung, die von Professor Balzert vorgeschlagen wurde und an die wir uns im Praktikum halten werden. Sie ist auch in seinem Buch "Lehrbuch der Software-Technik" auf den Seiten 114 ff. näher beschrieben. Auszüge daraus wurden in einer Übersicht über das Pflichtenheft zusammengestellt.

Wir haben natürlich auch ein Pflichtenheft der Anwendung erstellt, in eine vorzeigbare Form gebracht und mit dem Kunden durchgesprochen. Nachdem er keine Einwände dagegen hatte, gibt es nun einen gültigen Vertrag und wir können uns weiter der Analyse des Aufgabenbereichs widmen.

Anwendung der CRC-Karten Methode

Es gibt einen Abschnitt in der Analyse, der die Geduld der Entwickler auf eine harte Probe stellt. Bekanntlich werden Interaktionsdiagramme (also Sequenz- und Kollaborationsdiagramme) gezeichnet um die Beziehungen und den Nachrichtenfluss zwischen Objekten und den zeitlichen Ablauf von Aktionen darzustellen. Für seine Visualisierung stellen diese Diagrammtypen das absolute Optimum dar. Ihr großes Handycap ist aber die umständliche Nutzung und Erstellung. Das sticht besonders beim Ausprobieren verschiedener Alternativen bei der Umsetzung von Produktfunktionen hervor. Denn entweder muss man viel radieren und neuzeichnen oder exzessiven Gebrauch von der <ENTF>-Taste in CASE-Tools machen und die Objekte hinterher wieder neu zusammenklicken (was eigentlich nicht weniger aufwendig ist als die Papiervariante). Dies setzt vor allem das Vorhandensein von CASE-Tools bzw. die Existenz einer einheitlichen Diagrammsprache voraus.

Beides war gegen Ende der 80er Jahre in den Tektronix-Laboratorien (damals eines der größten Zentren der Objekttechnologie) nicht vorhanden. Der Zwang immer komplexere Projekte zu Visualisieren führte zur Entwicklung der CRC-Karten-Methode. Man erkannte auch schnell, dass die Verwendung dieser einfach zu erstellenden Kärtchen die Diskussion unter den Entwicklern fördert und sie sich prima für "brainstorming-sessions" eignen. Diese Sitzungen sind eine feine Sache in vielerlei Hinsicht. Sie fördern nicht nur die Zusammenarbeit im Team (und machen nebenbei bemerkt eine Menge Spaß) sondern sorgen auch dafür, dass die Ideen jedes einzelnen Mitarbeiters in das Projekt einfließen können und er sich fortan damit identifiziert (und deshalb evtl. härter mitarbeitet). Und schließlich sehen drei bis vier Augenpaare mehr als nur eins, oder?

Die Verwendung der CRC-Karten wurde bereits in der Vorlesung vorgestellt, weshalb wir an dieser Stelle nicht weiter darauf eingehen wollen und sofort mit den Karten für den Großhandel fortfahren.

Abbildung 2.3: Markt	Abbildung 2.4: Warenkatalog
Abbildung 2.5: Artikel	Abbildung 2.6: Hersteller
Abbildung 2.7: Manager	Abbildung 2.8: Bestellung
Abbildung 2.9: Buchhaltung	Abbildung 2.10: Warenlager
Abbildung 2.11: Mitarbeiter	Abbildung 2.12: Kasse
Abbildung 2.13: Kassierer	Abbildung 2.14: Kassenzettel
Abbildung 2.15: Lagerarbeiter	Abbildung 2.16: InfoStand
Abbildung 2.17: Kunde	Abbildung 2.18: Einkaufskorb

Modellierung komplexer Abläufe - Sequenzdiagramme

Der Sinn von Sequenzdiagrammen ist klar. Sie sind in der Lage, die meisten komplizierten, zeitlichen Abläufe und Nachrichten zwischen den Objekten zu verdeutlichen, was uns mit den Anwendungsfall-Diagrammen nicht so recht gelingen will. Sie erleichtern das Verständnis von Abläufen im System enorm. Beim Durchspielen der CRC-Karten solltet ihr ja bereits auf einige Abläufe gestoßen sein. In reiner Textform sind diese jedoch schwer zu verstehen. Zudem werden Faktoren wie die Lebensdauer von Objekten oder Aufrufe des Objektes an sich selbst schwer erkennbar. Sequenzdiagramme helfen dabei, eine gewisse Ordnung in das System zu bringen. Man kommt weg vom abstrakten Klassen-Gedanken und hin zum Hantieren mit Objekten. Dies erleichtert vielen das Verständnis des Problems. Insbesondere, wenn ihr dem Auftraggeber die wichtigsten Abläufe mal eben kurz darstellen wollt/müsst, sind Sequenz-Diagramme Gold wert. Neben den eben genannten Punkten kann man an ihnen auch schwierig zu ortende Analysefehler ausfindig machen, die weder auf den CRC-Karten noch in den Use-Cases sichtbar sind. Sie werden zum Teil überhaupt erst durch die zeitliche Darstellung sichtbar.

Viele der hier gezeigten Sequenzdiagramme entstanden bereits während der Erstellung der CRC-Karten als Unterstützung in den brainstorming-sessions. Es ist aus oben genannten Gründen eine gute Idee, sie dort bereits anzulegen. Dazu kommt noch der Fakt, dass diese Sitzungen zumeist heiter und gelockert ablaufen und die langwierige Erstellung dieser Diagramme damit leichter fällt.

Hinweis:
Spätenstens jetzt werden sich viele die Frage stellen, wie viele Sequenzdiagramme denn erstellt werden sollen, und wie man aus der Unendlichkeit der möglichen Diagramme die richtigen auswählt. Zur Anzahl lässt sich keine allgemeingütige Aussage machen. So wenig wie möglich, aber so viele wie nötig. Hier hilft wieder nur eine Absprache mit dem Betreuer. Was die Frage der Auswahl betrifft, so hat sich die Auswahl eines Use-Cases und das Darstellen mehrerer alternativer Szenarien an diesem als hilfreich heraus gestellt. Somit sind die folgenden Sequenzdiagramm ein wenig als Overkill anzusehen, auch wenn sie euch sicher dabei helfen können ein Gefühl für die Sequenzdiagramme zu bekommen.

Einkauf durch den Manager
Das erste erstellte Sequenzdiagramm beschreibt den Einkauf neuer Artikel für den Großhandel durch den Marktmanager. Er fängt damit an, vom Markt eine Referenz auf den Warenkatalog zu holen (der Markt hat mehr oder weniger direkt Zugang zum gesamten Datenbestand der Anwendung). Von dem lässt er sich dann die Übersichtsliste aller verfügbaren Artikel aus dem Katalog nach Kategorien und anschließend nach Namen sortiert erstellen und anzeigen. Der Katalog greift dazu auf die Informationen zu, die in seinen Artikel-Objekten gespeichert sind, die wiederum Informationen über den Hersteller enthalten. Aus der nun vorhandenen Übersichtsliste wählt der Manager einen Artikel aus und lässt sich vom Warenkatalog eine Referenz darauf zurückgeben. Er gibt dem Katalog dazu lediglich den Artikelnamen, der daraufhin seinen Artikelbestand auf der Suche nach dem Zielobjekt durchgeht und einen Namensvergleich durchführt. Mit dem Zugriff auf das einzelne Artikelobjekt kann sich der Manager nun eine Maske mit Detailinformationen zum Artikel erstellen und diverse Überlegungen zum Kauf anstellen. Will er nun eine bestimmte Menge an Artikeln kaufen, muss er nur einen Button in dieser Maske betätigen und in einem Eingabeformular die Menge der zu kaufenden Waren eingeben.

Das löst eine Funktion im Warenkatalog aus, der mit Hilfe der Artikelinformationen den Einkaufspreis für diese Menge berechnet und die Liquidität (Zahlungsfähigkeit) des Marktes daraufhin prüft. Ist sie gewährleistet wird automatisch (am besten nach nochmaliger Bestätigung) das Geld vom Marktkonto abgezogen (ja, gezahlt wird im Voraus) und mit Hilfe der im Artikel gespeicherten Herstellerinformationen die Lieferdauer ermittelt. Sind alle Berechnungen getätigt, wird ein neues Objekt des Typs Lieferung erstellt und in den Lieferlisten des Marktes abgelegt.

Produktpalette bearbeiten
Hierbei geht es um die Bearbeitung der spezifischen Verkaufsdaten eines Artikels aus dem Warenlager (nicht dem Warenkatalog!). Dessen Informationen sind ebenfalls über den Markt zugänglich, den wiederum alle Anwendungsobjekte kennen sollten. Der Manager holt sich also zunächst eine Referenz auf das Warenlager direkt beim Markt-Objekt ab und lässt sich darüber eine Inhaltsübersicht (die ähnlich gestaltet ist und genauso aufgebaut wird wie die Übersicht des Warenkatalogs) des Lagers anzeigen. Nochmal: hier sind nur die Artikel enthalten, von denen mindestens ein Exemplar im Lager vorhanden ist. Da diese Information ziemlich wichtig ist, wird zur Kurzbeschreibung des Artikels auch noch die Anzahl der im Lager verfügbaren Exemplare angezeigt.

Wieder wählt der Manager aus dieser Liste den Artikel aus, der für ihn von Interesse ist und gelangt damit zu dessen Detailansicht - einer Maske, die diesmal auch Felder enthält, die editierbar sind. Eines davon ist der Verkaufspreis, den die Kunden im Großhandel für ein Exemplar des Artikels bezahlen müssen. Die Eingabe eines neuen Verkaufspreises wird vor dessen Speicherung zunächst auf ihre Gültigkeit hin geprüft. Ungültige Preise könnten zum Beispiel negative Werte sein oder Werte mit mehr als zwei Nachkommastellen oder exorbitant hohe Werte, die irgendwo bei 500% über dem vom Hersteller empfohlenen Verkaufspreis liegen. Bei ungültigen Eingaben erfolgt keine Speicherung und der Manager bekommt den Grund dafür in einem Meldungsfenster angezeigt.

Einkauf durch den Kunden
Der Kunde hat, wie auch der Manager, immer einen Zugang zum Markt (also eine Referenz auf das Markt-Objekt verfügbar), über den er sich jetzt das Warenlager des Marktes holt und das Marktangebot anzeigen lässt. Dabei handelt es sich um dieselbe Produktübersicht wie die des Managements, jedoch mit Zusatzinformationen zur Anzahl der angezeigten Artikel im Einkaufskorb des Kunden. Nach der Auswahl eines der Artikel wird mit Hilfe des Artikelnamens im Warenlager-Objekt nach dem entsprechenden Artikel-Objekt gesucht und dieses an den Kunden zur Anzeige von dessen Detailinformationen zurückgegeben.

Entscheidet sich der Kunde zum Kauf eines Artikels, gibt er zunächst in einem Eingabefenster die Menge der Produktexemplare ein, die er in seinem virtuellen Einkaufskorb wiederfinden will. Wenn diese Menge nicht verfügbar ist, wird der eingegebene Wert korrigiert und der Kunde über diese Korrektur informiert. Jetzt wird etwas deutlich: Das Warenlager speichert (anders als der Warenkatalog) Zusatzinformationen zu jedem gespeicherten Artikel-Objekt - seinen Bestand und den im Markt zum Kauf zur Verfügung stehenden Bestand. Zwei (immer positive) Ganzzahlen. Der zweite von beiden wird nun korrigiert, damit sich andere Kunden nicht auch Produktexemplare in ihren Einkaufskorb legen, die im Lager gar nicht mehr zur Verfügung stehen sollten. Schließlich wird die Menge der Exemplare im Einkaufskorb korrigiert und der Kunde kann den Einkauf fortstetzen.

Bezahlung an der Kasse
Der Moment der Wahrheit für den Kunden. Durch die Mitteilung an seinen virtuellen Einkaufskorb, dass er mit dem Einkauf fertig ist, leitet der die Bezahlung ein. Er besorgt sich vom Markt eine Liste aller verfügbaren Kassen (Kassen gelten als verfügbar, wenn sie sowohl offen, also mit einem Kassierer besetzt, als auch frei ist, sich also keine Kunden in der Warteschlange befinden).
Offene und freie Kassen überprüfen dauernd ihre Warteschlangen nach Kunden und fertigen diese nach dem FIFO-Prinzip (first in, first out) ab. Der Kunde übergibt nun dem Kassierer seinen PDA mit dem virtuellen Einkaufskorb, der aus den dort gespeicherten Informationen den zu bezahlenden Preis berechnet. Zusätzlich zu den Artikelinformationen zieht der Kassierer hierbei noch die Rabattliste des Marktes zu Rate, aus der er den zu gewährenden Treuerabatt berechnet. In dieser Liste sind verschiedene Einkaufsvolumina (Summe aller bisher von dem Kunden im Markt bezahlten Rechnungen) gewissen Rabatten zugeordnet. Sind alle Informationen zusammengeholt, erstellt die Kasse daraus den Kassenzettel mit Kurzinformationen zu jedem Artikel im Einkaufskorb und dessen Verkaufspreisen bzw. Mengen und anderen nützlichen Informationen, wie das aktuelle Datum und die Uhrzeit des Einkaufs.

Nun ist es wieder am Kunden in Aktion zu treten. Nach Sichtung des Kassenzettels wählt er zwischen Barzahlung und Bezahlung mit Kreditkarte. Bei der Bezahlung mit Bargeld prüft er zunächst den Inhalt seines Portemonnaies und übergibt dem Kassierer (bei Vorhandensein der entsprechenden Geldmenge) einen Betrag. Aus dem berechnet die Kasse wiederum das Rückgeld und erstellt einen vervollständigten Kassenzettel mit den Informationen zur Bezahlung. Die Bezahlung mit Karte läuft einfacher ab. Sie wird lediglich von der Kasse auf ihre Gültigkeit hin überprüft, wonach der Auftrag zur Überweisung der Geldsumme an das entsprechende Kreditinstitut geht. Nach der Bezahlung erfolgt der Auftrag an die Lagerarbeiter des Marktes zur Auslieferung der Kundenwünsche an einen von ihm zu wählenden Ort (Stellplatz auf dem markteigenen Parkplatz oder externe Lieferadresse, die vorher zusammen mit den Kundeninformationen eingeben wurde).

Hinweis:
Die Erstellung des Kassenzettels, die Abwicklung der Kartenzahlung sowie die Auslieferung an eine externe Lieferadresse wurden später im Entwurf und der Implementierung nicht umgesetzt.

Fertig! Das Klassendiagramm der Analyse

Durch das Durchführen des CRC-Karten-Spiels sollten alle wichtigen Klassen und ihre Abhängigkeiten ermittelt sein. Da die Abhängigkeiten jedoch nicht klar aus den CRC-Karten zu sehen sind, muss man die CRC-Karten noch in ein Klassendiagramm überführen. Dabei ist speziell auf die Multiplizitäten einzugehen. Es kommt vielfach die Frage auf, wozu man denn ein Klassendiagramm benötigt. Der Kunde hat doch die Use-Case-Diagramme, und kann mit einem Klassendiagramm sowieso nichts anfangen, da es viel zu technisch ist. Ein Klassendiagramm zu diesem Zeitpunkt macht aus vielerlei Sicht Sinn. Der wichtigste Grund ist die Vorbereitung und die Planung für den späteren Entwurf. Im Analyse-Klassendiagramm könnt ihr auf einen Blick die fachliche Problematik eures Projektes erfassen. Das Entwurfsklassendiagramm was später Grundlage für den Entwurf wird ist im wesentlichen eine Erweiterung eures Analyse-Diagrammes um Salespointbestandteile (natürlich auch eine Verfeinerung des Diagramms). Ein weiterer Grund ist die Einführung einer Nomenklatur. Oft kommt es zu Problemen im Team, wenn man Begriffe verwendet, die nicht klar definiert sind. Durch das Klassendiagramm legt ihr euch auf Namen für eure Klassen fest, und über die Methoden und Attribute auch über die Inhalte der Klassen. Es sollten also keine Unklarheiten mehr darüber existieren was das Programm genau macht und wie es das macht.

Fangen wir also mit dem Einkauf neuer Waren durch den Manager an. Wir brauchen zunächst einmal den Manager selbst, der ein Mitarbeiter ist. Um die Übersichten anzuzeigen, liest er den Inhalt des Warenkatalogs. Detailinformationen bekommt er aber erst durch direkten Zugriff auf die Artikel selbst, die im Katalog gespeichert sind. Unter den vielen verschiedenen Artikelinformationen sticht besonders der Hersteller hervor, der für eine Reihe von Artikeln gleich ist und auch wegen seiner zahlreichen spezifischen Eigenschaften einen eigenen Typ bekommen hat. Entscheidet sich der Manager für den Kauf von Artikeln, wird eine neue Bestellung angelegt. Diese Bestellungen zählen die Artikel auf, die der Manager gekauft hat und ordnen jedem einzelnen seine Anzahl zu. Dadurch das jede Bestellung nur Waren eines einzigen Herstellers beinhaltet, ist sie indirekt auch diesem zugeordnet. Getätigte Bestellungen wandern in die Buchhaltung, die wie das Warenlager ein fester Bestandteil des Marktes ist.

Das Warenlager lagert die vom Manager gekauften Artikel und ordnet jedem Artikel aus dem Warenkatalog seinen aktuellen Verkaufspreis und die gelagerte Anzahl zu. Es wird von den Lagerarbeitern (ebenfalls Mitarbeiter) verwaltet, die von der Kasse die Informationen zum Einkaufskorb des Kunden zugespielt bekommen um die Lieferung mit den gekauften Produkten des Kunden zusammenzustellen. Kunden melden sich beim Betreten des Großhandels am InfoStand an, der alle Informationen dafür bereithält und u.a. den Kundenstamm speichert. Er rüstet nach der Anmeldung den Kunden mit seinem PDA (dem virtuellen Einkaufskorb) aus und ist ein weiterer wichtiger Bestandteil des Marktes. Wie bereits erwähnt wurde, besitzen Kunden für die Dauer ihres Aufenthaltes im Markt einen Einkaufskorb, den sie hoffentlich reichlich füllen. Bezahlt wird schließlich an der Kasse, die (im offenen Zustand) von einem Kassierer bedient wird. Sie stellt die Kassenzettel aus, die dem Kunden ausgedruckt werden und anschließend in der Kasse und (nach dem Tagesabschluss) in der Buchhaltung zur späteren Verwendung (Erstellung von Statistiken für das Management) gespeichert werden.

Einleitung

Durchführung der Entwurfsphase