(Beispiel) Beispielprojekt - Verkaufsprogramm

Das Verkaufsprogramm ist das praktische Beispielprojekt, in dem exemplarisch möglichst viele theoretische Möglichkeiten angewendet werden um sie zu verifizieren.

Phasen

Problemspezifikation

Die Verwaltung einer typischen Firme des produzierenden, sekundären Wirtschaftssektors soll eine Optimierung der Produktions-, Lager- und Verkaufsvorgänge ermöglichen. Mit statistischen Mitteln, sollen Einsparungen und Marketingmaximierung erreicht werden.
 

Forderungsanalyse

Kundendaten sollen verwaltet werden. Lagerinhalte sollen aktualisiert werden. Die Produktion soll automatisch an die vorhandenen Bestellungen angepaßt werden. Eventuell längerfristige Bestellungen sollen zwecks Minimierung der Rohstoffeinkaufspreise hinausgezögert werden, damit Rohstoffe in größeren Mengen angekauft werden können. Trotzdem soll eine termingerechte Lieferung erfolgen. Die Einzelrendite jedes Artikels soll dynamisch errechnet und gegebenenfalls vom Verkäufer zu Preisänderungen und Sonderangeboten verwendet werden können.
Die Produktionskapazitäten der Fabriken sollen maximiert effizient ausgenutzt werden. Unnötige längerfristige Lagerhaltung muß selbständig vermieden werden.
 

OO-Analyse

Ein wenig abstrakt lauten die zu untersuchenden Benutzungsfälle des Softwareprojekts wie folgt.
Verkaufsvorgang: Kunde bestellt mehrere Artikel bei Verkäufer. Verkäufer ordert Produkte aus dem Lager. Fabrik bestellt Rohstoffe. Fabrik produziert Artikel im Lager. Verkäufer bildet Bilanz.

Preiskalkulation: Fabrik bestimmt Kosten der Artikel aus der Summe der Preise aller Rohstoffe. Verkäufer bestimmt Preis der Artikel.

Anmerkung: Der Einfachheit halber soll in diesem Beispielprojekt nur mit einer verringerten Menge der aus der Forderungsanalyse hervorgehenden Analyse-Elementen weitergearbeitet werden.
Klassen, deren Objekte gemeinsame Eigenschaften haben, und die Fachklassen sind:

Die Attribute der relevanten Klassen und einige Operationen: Die erkannten Beziehungen:

OO-Design

Architektur

Die Architektur diese Beispielprojekts wäre denkbar simpel. Es müßte ein Programm des Programmsystems exisitieren, das die Verwaltung im Lager erlaubt, dort Produktionsanforderungen ausgibt und die Produktionsmengen registriert, sowie die Lagerhaltung verwaltet. Und es sollte ein anderes Programm des Systems existieren, welches den Verkäufern die Interaktion mit dem Kunden ermöglicht und bestellte Artikel automatisch im Lager anfordert. Beide Programme könnten auf einem gemeinsamen Modul basieren, welches die Ggaphische Interaktion mit dem Benutzer regelt und einem Modul, was den Zugriff auf die Datenbank und die ständige gegenseitige Aktualisierung der Lager- und Verkaufsdaten automatisiert.

Steuerungs-Kontrollfluß

Das Programm für die Lagerverwaltung würde typischerweise sequentiell organisiert sein, da es eher einem Produktionskontrollsystem entspricht (siehe Architektur-Steuerungstypen).
Das Programm für die Verkaufsverwaltung würde eher ereignisorientiert aufgebaut werden, weil es mit seiner graphischen Benutzerschnittstelle meist darauf wartet, daß der Verkäufer eine der Programmfunktionen aus dem Menü auswählt.

Design

Methode

Algorithmen der Operationen
Die Kosten eines Artikels werden auf folgende Weise errechnet: Die Preise der Gesamtbestellung aller für einen Artikel benötigten Rohstoffe werden anteilig (benötigte Menge eines Artikels bezüglich der gesamt gekauften Menge) auf den Artikel angerechnet und aufsummiert.
Das Lager fordert eine Produktion an, indem es die Bestellungsmenge eines Artikels mit der im Lager vorhandenen und demnächst produzierten Menge vergleicht und, sollten zuwenig Artikel zu den Lieferterminen verfügbar sein, eine Nachproduktion anfordert. Dabei kann eine verkaufsabhängige Menge Reserve mitproduziert werden.
weitere Implementierungsklassen
Die Beziehung "bestellt" zwischen Kunde und Verkäufer benötigt eine eigene Implementierungsklasse "Bestellung", weil in einer Bestellung mehrere Artikel, ein Lieferdatum, eine Rechnungssumme etc. enthalten sind.
Das GUI und das Datenbanksystem würden auch Implementierungsklassen benötigen. Diese werden aber zugunsten der Verständlichkeit nicht aufgeführt.
Steuerungs-Kontrollfluß
Diese Entscheidung wurde schon oben während der Architektur gefällt.
gleiche Attribute zusammenfassen
Kunde und Verkäufer haben beide Eigenschaften, wie Name, Kontonummer etc. Diese gleichen Attribute könnten in einer Basisklasse "BeteiligterMensch" zusammengefaßt werden. Die spezielleren Attribute, die Verkäufer von Kunden unterscheiden, bleiben in der Verkäuferklasse, die gemeinsamen werden jetzt von "BeteiligterMensch" geerbt.
Beziehungen implementieren
Die Beziehung "Lager enthält Artikel" würde am sinnvollsten durch ein Implementierungsattribut "enthalteneArtikel" der Lagerklasse realisiert werden, welches eine Liste aller Artikel enthält
Die Beziehung "Verkäufer ordert im Lager" wird durch eine Operation "artikelOrdern" in der Lagerklasse implementiert, die der Verkäufer aufrufen kann.
Die Bestellbeziehung muß mit einer eigenen Implementierungsklasse "Bestellung" umgesetzt werden, in der das Lieferdatum enthalten ist. Diese Klasse referenziert auch eine Liste der Artikel die zur Bestellung gehören, weil die Beziehung "Bestellung besteht aus mehreren Artikeln" gilt.

Ein statisches Klassendiagramm der UML

Das Ergebnis der Methode des OOD wird in einem Klassendiagramm wie folgt festgehalten:

Implementierung

Jetzt könnte das Beispielprojekt fertig implementiert werden, denn das gesamte Konzept steht und scheint vollständig zu sein. Darauf wird jedoch im Rahmen dieser Arbeit verzichtet.