DA

Diplomarbeit
Studienrichtung
Informatik
Harald-Rudolf Kisch
Webbasiertes Einkaufsmanagementsystem
für den Privathaushalt
Verfasser der Diplomarbeit:

Harald-Rudolf Kisch
Rechte Brandstr. 34
86167 Augsburg
Telefon: 0821 7292909
Erstprüfer: Prof. Rainer Kelch harrykisch@gmx.net
Fachbereich
Zweitprüfer: Prof. Wolfgang Klüver Informatik

Telefon: +49 821 5586-450
Fax: +49 821 5586-499
Abgabe der Arbeit: 14.03.07 Fachhochschule Augsburg

University of Applied Sciences
Baumgartnerstraße 16
D 86161 Augsburg
Telefon +49 821 5586-0

Fax +49 821 5586-222
www.fh-augsburg.de
poststelle@fh-augsburg.de
Diplomarbeit
Harald Kisch (MatNr: 702092)
Abgabe Wintersemester 06/07
Webbasiertes Einkaufsmanagementsystem
für den Privathaushalt
Fachhochschule Augsburg
University of applied sciences
Fachbereich Informatik
Erstprüfer: Prof. Dr. Rainer Kelch

Zweitprüfer: Prof. Dr. Wolfgang Klüver
Webbasiertes Einkaufsmanagementsystem für den Privathaushalt
Ich versichere, dass ich die Diplomarbeit selbständig angefertig, nicht anderweitigt für
Prüfungszwecke vorgelegt, alle benutzen Quellen und Hilfsmittel angegeben sowie wörtliche
und sinngemäße Zitate als solche gekennzeichnet habe.
Augsburg, 13. März 2007

Harald Kisch
Harald Kisch ii Diplomarbeit

Warenzeichen Die in dieser Diplomarbeit verwendeten Software- und Hardware-Bezeich-

nungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen unterliegen
im Allgemeinen warenzeichen-, marken- oder patentrechtlichen Schutz. SAP, SAP R/3-
System und BSP sind eingetragene Warenzeichen der SAP AG.
Microsoft, Windows und Internet Explorer sind eingetragene Warenzeichen der Microsoft
Corporation.
HTML und XML sind eingetragene Warenzeichen des World Wide Web Consortium des
Massachusetts Institute of Technology.
Java Script ist ein eingetragenes Warenzeichen von Sun Microsystems, Inc.
IBM WebSphere, Borland JBuilder, NetBeans IDE, Sun ONE, IntelliJ IDEA, Oracle JDe-
veloper und BEA WebLogic Workshop sind geschützte Namen der jeweiligen Hersteller.
Aufgrund der besseren Lesbarkeit wird in dieser Diplomarbeit auf die Kennzeichnung der
r TM ) verzichtet.
oben aufgeführten Wörter auf die entsprechenden Symbole (,
Harald Kisch iii Diplomarbeit

1 Abstract
Es wird immer schwerer, qualitativ hochwertige Lebensmittel einzukaufen. Es besteht die
Tendenz, dass Lebensmittel immer günstiger produziert und verkauft werden, was jedoch
häufig zu Lasten der Qualität geht. Vor biotechnologischen Eingriffen in unsere Lebens-
mittel, wie der Genmanipulation, können wir uns kaum schützen. Auf den Verpackungen
können wir meist nicht erkennen, ob die Lebensmittel mit genmanipulierten Erzeugnissen
hergestellt oder selbst genmanipuliert wurden. Ein Lebensmittelskandal folgt dem näch-
sten. Sind wir dem Ganzen völlig ausgeliefert, oder können wir uns doch irgendwie wehren,
indem wir selbst bestimmen was und von wem wir kaufen?
Was soll ich heute kochen?“ ist im Prinzip die Motivation einer Reihe von Fragestellungen,
”
die mich zu dieser Arbeit veranlassten. Um zu wissen, was man kochen soll, ist es notwendig
zu wissen, was man kochen kann. Und um zu wissen, was man kochen kann, muss man
wissen, was sich im Kühlschrank, Vorratsschrank, Keller, etc. befindet. In einem ersten
Schritt, muss das Problem: Was habe ich vorrätig?“ gelöst werden. Wie bringt man also
”
den Kühlschrank dazu, zu sagen, was sich in ihm befindet? Oder besser: Welche Rezepte
”
kann ich aus dem Kühlschrankinhalt machen? “.
Neben dem Haushaltsmanager, mit dem man seine Präferenzen definiert, Rezepte ein-
plant und bestellt, wird ein zentraler Verwaltungsrechner, der Einkaufsmanagementsystem-
Server (EMS-Server) benötigt, dessen Hauptaufgabe darin besteht, einzelne Artikel zu den
günstigsten Lieferanten bester Qualität zuzuordnen. Dieser Rechner wird von einer Softwa-
re unterstützt, die Bestellungen aufnimmt, Mengenrabatte aus allen eingehenden Bestel-
lungen berechnet, die Artikel beim günstigsten Lieferanten bestellt und dem Bringservice
die Artikel zu den Haushalten zuordnet. Die Qualität der Waren wird durch ein End-
verbraucherbewertungssystem geprüft. Falls ein Endverbraucher Grund zur Beanstandung
eines Artikels hat, kann er im EMS eine Beurteilung seiner Lieferung vornehmen. Jeder
Lebensmittellieferant bringt seine Artikel über ein individuelles Webfrontend selbst in die
EMS-Datenbank ein.
Für Hersteller, die zumeist das Warenwirtschaftssystem der SAP AG benutzen, wird ei-
ne Software (SAP-Client) benötigt, womit der Lieferant über Absatzmöglichkeiten vom
EMS-Server informiert wird. Mit dem SAP-Client können Artikeldaten aus der Hersteller-
Datenbank über ein individuelles BAPI zur eventuellen Bearbeitung aufgelistet und an
den EMS-Server übertragen werden. Nach der Bearbeitung kann der Hersteller die Daten
zur EMS-Datenbank schicken und sorgt so für aktuelle und konsistente Artikeldaten im
EMS.
Zur Gewährleistung der Artikelvielfältigkeit werden Webshops, Großhändler und Direktein-
käufer benötigt, deren Anbindung an das EMS über einen individuellen EMS-Client bzw.
Webinterface erfolgen muss.
Die Diplomarbeit konzentriert sich hierbei auf die Implementierung des Haushaltsmanager-
Clients (HHM-Clients) als wichtigster und erfolgentscheidender Bestandteil des EMS mit
Harald Kisch iv Diplomarbeit

Artikelansicht, Grundnahrungsmittelanpassung, Rezeptliste, Rezeptmatrix, Rezeptverwal-

tung sowie Rezeptplanung und Einkaufslistengenerierung. Beim EMS-Server beschränkt
sich die Diplomarbeit auf die Modellierung der notwendigen Klassen und Methoden zur
Veranschaulichung der Gesamtlösung sowie der Funktions- und Automatisierungsweise.
Die Implementierung erfolgt in PHP mit MySQL-Unterstützung. Für die Präsentations-
schicht des Anwenders wird die Web 2.0-Technologie AJAX (Asynchronous JavaScript
and XML) verwendet. Die zur AJAX-Unterstützung weiterentwickelte Entwicklungsumge-
bung Aptana, die auf Eclipse basiert, bietet komfortable Programmierunterstützung durch
Schlüsselwortauswahl, Bibliothekenverwaltung und Javascript-Debuggingmöglichkeiten
durch eigener Firefoxe-Erweiterung. Die neuen Möglichkeiten der alten Javascript-Techno-
logie erleichtert den Einstieg und Umgang mit dem Einkaufsmanagementsystem und schont
die Rechenleistung des Servers, da die Rechenlast für Datenaufbereitungen und Datenma-
nipulation durch die Asynchronität beim Client belassen wird. Für die Datenübertragung
von und zum EMS-Server wurde JSON (Java Script Object Notation) als sehr schlan-
kes und vielseitig einsetzbares Datenformat aufgrund der einfachen Lesbarkeit vor XML
ausgewählt.
Zur einfachen Handhabung der komplexen Umgebung wurde Server2Go gewählt, welches
für Windows-Betriebssysteme mit dem Ausführen einer einzigen Datei den Apache Webser-
ver, die Datenbank MySQL, PHP und die Datenbankadministrationsoberfläche PHPMyAd-
min installiert und für den sofortigen Einsatz konfiguriert. Die Plattformunabhängigkeit zu
MacOSX und Linux/Unix wird dadurch nicht beeinträchtigt, da zum Einsatz auf anderen
Betriebssystemen lediglich die auszuführenden Dateien auf einen anderen Webserver mit
PHP und MYSQL-Unterstützung kopiert werden müssen.
Alle Quellcodes und Skripte wurden auf einem Windows 2000 Betriebssystem mit den
aktuellen Mozilla Firefox- und Microsoft Internt Explorer Webbrowsern entwickelt und
getestet. Die Diplomarbeit selbst ist mit der LATEX-Entwicklungsumgebung Teχmaker unter
MacOSX 10.3 erstellt worden. Die Bilder wurden mit Visual Paradigm von Microsoft und
Photoshop erstellt.
Harald Kisch v Diplomarbeit

Webbasiertes
Einkaufsmanagementsystem für den
Privathaushalt
Harald Kisch
Augsburg, 13. März 2007
Inhaltsverzeichnis
1 Abstract iv
2 Prolog 1
3 Zielsetzung 2
4 Aufbau der Diplomarbeit 3
5 Pro und Contra 4

5.1 Das Umdenken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.2 Die Lebensmittelverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.3 Der neue Markt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6 Der Zentralserver im Überblick 6
7 Anforderungsanalyse 8
7.1 HHM Benutzeranwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2 HHM Systemanwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3 EMS-Server Benutzeranwendungsfälle . . . . . . . . . . . . . . . . . . . . . 14
7.4 EMS-Server Systemanwendungsfälle . . . . . . . . . . . . . . . . . . . . . . 16
7.5 Hersteller-Client (EMS-Client) Benutzeranwendungsfälle . . . . . . . . . . 20
7.6 Hersteller-Client (EMS-Client) Systemanwendungsfälle . . . . . . . . . . . 21
7.7 Bringservice-Manager (BSMNGR) Benutzeranwendungsfälle . . . . . . . . 24
7.8 Bringservice-Manager (BSMNGR) Systemanwendungsfälle . . . . . . . . . 26
vi
8 Systementwurf 27
8.1 Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.2 Schnittstellenbeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.3 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.4 Prozessketten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
8.5 Entwurfsmuster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
9 Abgrenzung 50
10 Implementierungstechnologien 51
10.1 Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
10.2 AJAX und die zugrunde liegenden Technologien . . . . . . . . . . . . . . . 54
10.3 Javascript Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
11 Implementierung des HHM-Clients 72

11.1 Rezepte eintragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
11.2 Rezeptliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
11.3 Grundnahrungsmittel anpassen . . . . . . . . . . . . . . . . . . . . . . . . 80
11.4 Mahlzeiten planen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
11.5 Einkaufsliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
11.6 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
11.7 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
12 Test 87
13 Epilog 90
13.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
13.2 Schlussgedanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
14 Anhang 93
Harald Kisch vii Diplomarbeit

Abbildungsverzeichnis
1 HHM-Rezeptmatrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Einkaufsmanagementsystem und Systemnutzer-Interaktionen . . . . . . . . 28
3 Fachklassendiagramm zur Übersicht . . . . . . . . . . . . . . . . . . . . . . 29
4 Use-Case HHM-Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5 Zustandsdiagramm vollständige Möglichkeiten des HHM-Clients . . . . . . 31
6 Use-Case Lieferanten-Client . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7 Zustandsdiagramm vollständige Möglichkeiten des Lieferanten-Clients . . . 32
8 Use-Cases Fassade EMS-Server . . . . . . . . . . . . . . . . . . . . . . . . 34
9 Zustandsdiagramm Standardablauf HHM-IF . . . . . . . . . . . . . . . . . 35
10 Zustandsdiagramm Standardablauf Lief-IF . . . . . . . . . . . . . . . . . . 36
11 Zustandsdiagramm Standardablauf BS-IF . . . . . . . . . . . . . . . . . . 37
12 Aktivitätsdiagramm Standardablauf Admin-IF . . . . . . . . . . . . . . . . 38
13 Aktivitätsdiagramm Standardablauf RegMNGR . . . . . . . . . . . . . . . 39
14 Aktivitätsdiagramm Standardablauf KonfMNGR . . . . . . . . . . . . . . 40
15 Aktivitätsdiagramm Standardablauf SecMNGR . . . . . . . . . . . . . . . 41
16 Aktivitätsdiagramm Standardablauf BSTMNGR . . . . . . . . . . . . . . . 42
17 Aktivitätsdiagramm Standardablauf CALCMR . . . . . . . . . . . . . . . 43
18 Kompositionsstrukturdiagramm zur Schnittstellenbeschreibung . . . . . . . 45
19 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
20 EPK-Diagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
21 Funktionsumfang Visual Paradigm for UML . . . . . . . . . . . . . . . . . 53
22 Unterschied Klassisches Web-Modell und Ajax-Modell . . . . . . . . . . . . 55
23 XMLHttpRequest-Objekt . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
24 Sequenzdiagramm Rezepte eintragen . . . . . . . . . . . . . . . . . . . . . 72
25 Rezept eintragen Schritt 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
26 Rezept eintragen Schritt 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
27 Rezept eintragen Schritt 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 75
28 Rezept eintragen Schritt 2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . 76
29 Sequenzdiagramm Rezeptliste . . . . . . . . . . . . . . . . . . . . . . . . . 77
30 Listenansicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
31 Rezeptansicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
32 Sequenzdiagramm Grundnahrungsmittel anpassen . . . . . . . . . . . . . . 80
33 Sequenzdiagramm Mahlzeiten planen . . . . . . . . . . . . . . . . . . . . . 81
34 Kalender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
35 Mahlzeit einplanen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
36 Einkaufslisten-Zeitraum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
37 Einkaufsliste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
38 Ablaufdiagramm STAF Szenario . . . . . . . . . . . . . . . . . . . . . . . . 89
39 Essensgewohnheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
40 Konsumpräferenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
41 Lebensmittelverwendung und Einkauf . . . . . . . . . . . . . . . . . . . . . 97
Harald Kisch viii Diplomarbeit

42 Qualitätskriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Harald Kisch ix Diplomarbeit

Tabellenverzeichnis
1 Benutzer-Anwendungsfall Konfiguration . . . . . . . . . . . . . . . . . . . 9
2 Benutzer-Anwendungsfall Rezept-Planung . . . . . . . . . . . . . . . . . . 11
3 Benutzer-Anwendungsfall Bestellung . . . . . . . . . . . . . . . . . . . . . 11
4 Benutzer-Anwendungsfall Bestellung stornieren . . . . . . . . . . . . . . . 12
5 Benutzer-Anwendungsfall Grundnahrungsmittel-Anpassung . . . . . . . . . 13
6 HHM-Anwendungsfall Rezeptplanung-Resteverbrauch . . . . . . . . . . . . 13
7 HHM-Anwendungsfall Zustandssicherung . . . . . . . . . . . . . . . . . . . 14
8 Benutzer-Anwendungsfall Status-Portal . . . . . . . . . . . . . . . . . . . . 15
9 System-Anwendungsfall EMS Administration . . . . . . . . . . . . . . . . . 15
10 System-Anwendungsfall Eingehende Bestellung . . . . . . . . . . . . . . . . 16
11 Sytem-Anwendungsfall Mengenrabattkalkulation . . . . . . . . . . . . . . . 17
12 Sytem-Anwendungsfall Bestellungsausgang . . . . . . . . . . . . . . . . . . 18
13 Sytem-Anwendungsfall Paketierung . . . . . . . . . . . . . . . . . . . . . . 19
14 Sytem-Anwendungsfall Paketierung . . . . . . . . . . . . . . . . . . . . . . 19
15 Sytem-Anwendungsfall Interface Management . . . . . . . . . . . . . . . . 20
16 EMS-Client Benuter-Anwendungsfall Produkte einbringen . . . . . . . . . 21
17 EMS-Client Benutzer-Anwendungsfall Forecast . . . . . . . . . . . . . . . . 22
18 EMS-Client System-Anwendungsfall Datenaufbereitung . . . . . . . . . . . 23
19 EMS-Client System-Anwendungsfall Lieferantenklassifikation . . . . . . . . 23
20 BSMNGR Benutzer-Anwendungsfall Konfiguration . . . . . . . . . . . . . 25
21 BSMNGR Benutzer-Anwendungsfall Fahrtenverwaltung . . . . . . . . . . . 25
22 BSMNGR Server-Anwendungsfall Lieferauftragsvergabe . . . . . . . . . . . 26
23 BSMNGR Server-Anwendungsfall Fahrdienstbewertung . . . . . . . . . . . 27
Harald Kisch x Diplomarbeit

Listings
1 JMS ConnectionFactory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2 Ajax Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3 XMLHttp-Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4 Stylesheet-Datei ändern . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5 Objektmethode hinzufügen . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6 Klassenmethode hinzufügen . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7 Klasse definieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8 Objekt definieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
9 Literalobjekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
10 Unterschied JSON - XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
11 Umgang mit JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
12 JSON-RPC-Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
13 JSON-RPC-Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
14 JSON-RPC-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
15 Bibliotheken einbinden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
16 Prototype Shortcut-Funktionen . . . . . . . . . . . . . . . . . . . . . . . . 71
17 Dojo Paketverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Harald Kisch xi Diplomarbeit

2 Prolog
2 Prolog
Das Bundesministerium für Bildung und Forschung hat eine Studie namens TAUCIS ver-
öffentlicht, die Auswirkungen des ubiquitären Computings“1 auf unsere Gesellschaft un-
”
tersucht. Insgesamt unterstreicht die Studie die Bereitschaft der Deutschen, sich auf die
intelligenten Systeme einzulassen, wenn die Technik anwenderfreundlich, sicher und nicht
verpflichtend ist.2
Der Visionär Negroponte hat 1995 den Bestseller Being digital“ geschrieben, der in 40 Spra-
”
chen übersetzt wurde und Teile des Einkaufsmanagementsystems beschreibt. Den Trend
zum Being digital“ (Das Leben nach den Möglichkeiten des Internets ausrichten, bis zur
”
vollständigen Parallelidentität) bestätigt auch der Technologie Hype-Cycle Report 2006.
Das IT-Marktforschungsinstitut Gartner bewertet darin die Entwicklungen der nächsten
Jahre. Zwei Trends sehen die Analysten als besonders zukunfträchtig an: Web 2.0 und Real
World Web.3 Ein Zitat von Jesse James Garrett: “The Web goes where its users want it to
go - but only when they’re ready.“4
Wir Konsumenten müssen uns nicht alles gefallen lassen, was die Industrie aufgrund ih-
res Gewinnmaximierungsverhaltens vorschreibt. Wir sind gezwungen antibiotikaversetztes
Schweinefleisch zu essen oder Schlagwörter wie Gammelfleisch, Vogelgrippe, Rinderwahn-
sinn, Genmanipulation beschreiben den Zustand unserer Nahrungsmittel. Es liegt also an
uns, etwas für eine bessere Ernährung zu tun. Die Masse hat die Macht, alles zu verändern,
was zu verändern ist, um ein gutes und sorgloses Leben in der Zukunft zu führen. Das
Einkaufsmanagementsystem verhilft dem Kunden zu mehr Selbstbestimmung über seine
Lebensmittel.
Ein wesentlicher Teil meiner Arbeit soll eine Antwort auf die häufig gestellte Frage von
vielen Frauen und manchen Männern geben: Was soll ich heute kochen?“. Um einen Re-
”
zeptvorschlag geben zu können, muss als erstes geklärt werden, welche Lebensmittel im
Haushalt vorrätig sind. Dabei wäre es eine große Erleichterung, nicht mehr den Kühl-
schrank und Vorratsschrank durchforsten zu müssen, sondern am Computer angezeigt zu
bekommen, welche Lebensmittel vorhanden sind. Die nächste große Hilfe für die oder denje-
nigen, der kochen möchte wäre, mehrere Vorschläge zu bekommen, welche Gerichte sich aus
den Lebensmitteln zubereiten lassen. Dazu ist ein umfangreiches Gesamtsystem notwendig,
welches in dieser Arbeit modelliert wird.
Um sich anzeigen zu lassen, was man aus dem Kühlschrankinhalt machen kann, braucht
man keinen Scanner, der jedes Produkt einzeln einscannt. Man braucht auch keine Waa-
gen, um Produktgewichte zu ermitteln. Am ehesten könnte man in Produktverpackungen
1
Aus dem Aufsatz von Mark Weiser - Das Ersetzen der PCs durch intelligente Gegenstände
2
Vgl: Stephan, Christia: Zukunfts(mis)klänge in PC Magazin 12/06 S. 11
3
Vgl: Dr Buchner, Manfred: Intelligente Kühlschränke, vernetzte Ohrringe, elektronische T-Shirts in PC
Magazin 12/06 S. 91
4
Perry, Bruce W.: Ajax Hacks, 2006, S. x
Harald Kisch 1 Diplomarbeit

3 Zielsetzung
eingebaute RFID-Chips benutzen, die der Kühlschrank ausliest und somit die Produkte re-
gistriert. Aber warum sich das Leben so unnötig verkomplizieren? Mit RFID hat man viel
mehr Probleme gemacht als man eigentlich lösen wollte: Sicherheit (Einkaufstüte jederzeit
auslesbar), Butter, Eier nimmt man bei Verbrauch aus der Verpackung, Vorratsschrank
und Keller haben sicherlich keine RFID-Leser, Kartoffelwaagen, etc. Die Frage, Was kann
”
ich aus meinen vorrätigen Lebensmitteln machen?“ muss einfacher und geradliniger zu lö-
sen sein. Nämlich indem man die Rezepte, die in einem Zeitraum gemacht werden sollen,
einplant, wie es früher alle guten Hausfrauen taten. Heute gibt es immer weniger Haus-
frauen, die sich die Haushaltsführung zur Lebensaufgabe machen. Die moderne Frau muss
Beruf, Haushalt und Familie gleichzeitig vereinbaren. Ob Alleinstehende, Familie oder Paa-
re, es bleibt immer weniger Zeit für den Haushalt. Es wird eine Planungshilfe benötigt. Der
Kühlschrank nimmt die Planung entgegen und bestellt die benötigten, beziehungsweise
bewusst ausgewählte Lebensmittel direkt zur Anlieferung an die Haustür. Man gibt an,
was man verbraucht, indem man sich das Rezept anzeigen lässt und zubereitet. Zukünftige
Rezepte werden anhand der Lebensmittelreste vorgeschlagen. Die Vernetzung aller Kühl-
schranksysteme gewährleistet eine sehr hohe Anzahl an Rezepten, so dass alle aktuellen
Lebensmittel sehr effizient und einfach eingeplant werden können. Zusätzlich können Aller-
gien, Krankheiten, Vorlieben und Qualität in die Rezept- und damit in der Einkaufsplanung
berücksichtigt werden. Das webbasierte Einkaufsmanagementsystem, im folgenden EMS,
kann diese und andere Bedürfnisse erfüllen. Das EMS kann in der Diplomarbeit jedoch
nicht bis zur Marktreife entwickelt werden. Dazu bedarf es einem ausgiebigen Test des
Haushaltsmanagers als Beweis dafür, dass mit dem System umgegangen werden kann.
3 Zielsetzung
Das Primärziel dieser Arbeit ist es, einen testfähigen Web 2.0 Software-Prototypen (Haus-
haltsmanager-Client) zu schaffen, um den Lebensmittelverbrauch von Privathaushalten
verwalten zu können. Mit möglichst wenig periphären Aufwand soll erreicht werden, dem
Endverbraucher eine Möglichkeit zu geben, selbst zu bestimmen, wie er sich ernähren will
oder sich krankheitsbedingt ernähren muss. Die benötigte Hardware soll nur aus einem
Touchscreen zur Benutzereingabe und einem am Internet angeschlossenen Computer be-
stehen. Weder Tastatur, noch Maus, RFID-Chips oder Barcodescanner sollen nötig sein,
um über den Kühlschrankinhalt, geplante Rezepte, Lebensmittelbestände und Bestellungen
informiert zu sein. Die Diplomarbeit konzentriert sich hierbei auf den allesentscheidenden
Haushaltsmanager, der durch Nutzerakzeptanz und Funktionsumgang die wichtigste Trieb-
feder darstellt. Mit dem Haushaltsmanager können Gerichte geplant, Rezepte verwaltet,
ergänzt, eingepflegt und Vorlieben, Krankheiten/Allergien sowie Präferenzen (zum Beispiel
Marken) berücksichtigt werden. Für die Eingabe von Text wird eine Tastatur am Touchs-
creen eingeblendet, um dem Benutzer die Eingabe von Daten zu erleichtern. Bestellungen
werden per Email an den Zentralserver geschickt, der in den Grundzügen die Gesamtfunk-
tionalität anhand der Benutzeroberflächen abbildet. In dieser Vorstufe des EMS, die meine

5 Pro und Contra
Diplomarbeit umfasst, erfolgt noch keine Bestellung beim Lieferanten.

Die Lieferanten müssen erst davon überzeugt werden, dass der Absatz über das EMS die
Investitionen für den EMS-Client rechtfertigen. Erst dann werden sie bereit sein, in einen
EMS-Client zu investieren, um ihre Artikel in das Sytem einzupflegen. Dazu bedarf es Test-
personen, die den Haushaltsmanager testen und durch die Einplanung ihrer Lebensmittel
sowie das Abschicken der Testbestellungen zeigen, dass sie bereit wären das System zu nut-
zen. Mit einer steigenden Anzahl von Testbestellungen wird das System für die Lieferanten
interessanter und damit Marktfähig. Diese Testphase dauert einige Monate und stellt das
Sekundärziel meiner Diplomarbeit dar, das aus terminlichen Gründen erst nach Abgabe
erfolgen kann.
4 Aufbau der Diplomarbeit

Bei diesem Thema ist es notwendig, möglichst viel am Anfang zu erklären. Seit sehr lan-
ger Zeit wird versucht den Kühlschrank intelligenter zu machen - bisher erfolglos. Viele
alte Konzepte wie Barcodescanner und Funkchips stecken noch zu tief in den Köpfen, um
ein schnelles Verständnis des Konzepts dieser Diplomarbeit zu ermöglichen. Nahezu alle
Fragen, die einem plötzlich durch den Kopf gehen, werden mit Geduld und Überlegung
beantwortet. Nach Verständnis folgt Begeisterung über die Einfachheit des Konzepts. Die
Diplomarbeit hat anfangs viel Zeit zur Planung und Auswahl der Möglichkeiten verlangt.
Dabei wurde mit vielen Menschen gesprochen, wie sie sich etwas derartiges vorstellen könn-
ten. Jeder Befragte war von dem Vorhaben begeistert und schilderte seine Interpretation
des Ganzen, sowie mögliche Lösungsansätze. Es stellte sich schnell heraus, was die we-
sentlichen Aspekte einer derartigen Software sein müssen - Effizienz, Usability, Sicherheit
und Design. Die Summe aller Erkenntnisse dieser Befragungen sind in die Diplomarbeit
eingearbeitet.
Um das Design möglichst ansprechend zu gestalten, wurden viele freie Icons zusammenge-
tragen. Die wenigsten wurden selbst erstellt. Der schriftliche Teil der Diplomarbeit behan-
delt das Konzept anfangs im Allgemeinen. Es werden Anforderungen im Pro und Contra
sowie Funktionalitäten analysiert und allgemein beschrieben. Anschließend werden Vorge-
hensweisen im Umgang mit dem System analysiert und konkretisiert. Das darauf folgende
Kapitel ist der Systementwurf. Darin wird das Gesamtsystem in kleine, von der Komplexi-
tät her einfachere Komponenten zergliedert und modelliert. Die gesamte Anforderungsana-
lyse kann auch als Lastenheft umgeschrieben werden, wesshalb auf ein explizites Lastenheft
aus Redundanzgründen verzichtet wird.
Nach der Abgrenzung für die im Rahmen der Diplomarbeit zu programmierenden Funk-
tionen wird ein Pflichtenheft erstellt. Danach wird die Implementierung vorgenommen. Es
werden die Technologie- und Werkzeugentscheidungen begründet sowie Meilensteine defi-
niert und Entscheidungen bezüglich des Quellcodes getroffen.

5 Pro und Contra
5 Pro und Contra

Bei der benötigten Software handelt es sich um ein Produkt für den Massenmarkt. Bei dieser
Anforderung ist es in erster Linie bedeutsam, die Funktionalitäten so ergonomisch wie
möglich zu gestalten. Jeder soll mit der Software zurecht kommen und Spass am Umgang
mit ihr haben. Ferner ist die Funktionalität wichtig, die eine komplexe Kommunikation
zwischen den einzelnen Systemkomponenten sicher stellt. Die sichtbaren Eigenschaften des
Systems, wie z.B. Leistungsfähigkeit, Zuverlässigkeit, Benutzerfreundlichkeit, Betriebs- und
Systemsicherheit sind die primären Erfolgsfaktoren, die über die Akzeptanz des Systems
entscheiden. Es gibt aber noch eine Reihe weiterer Herausforderungen, die auf dem Weg
zu einer modernen Haushaltsführung fehlen.
5.1 Das Umdenken
Einen Realisierungshemmer stellt die Umstellung dar, zu der der Endverbraucher durch
das EMS gebracht werden muss. Es gibt viele Menschen, die gerne einkaufen gehen. Man
kann zwar versuchen, diesen Menschen das virtuelle Einkaufen so schmackhaft wie möglich
zu machen, jedoch wird man sie nie davon abhalten können physisch einkaufen zu gehen.
Das ist auch nicht nötig. Immer weniger Menschen haben die Zeit und die Geduld, im-
mer mehr Lebensmittelprodukte anhand ihrer Bedürfnisse sorgfältig auszuwählen. Noch
weniger gehen in mehrere Geschäfte, um die gewünschte Qualität aller Artikel zu prüfen.
Nahezu alle Einkaufsmärkte streuen aus strategischen Gründen ihre Qualität, so dass man
gezwungen wird in unterschiedlichen Geschäften einkaufen zu gehen.
Das EMS soll all denen, die keine Zeit und Lust zum Einkaufen haben, eine Möglichkeit
bieten, ihren Alltag erheblich zu erleichtern. Das Umdenken, das bei diesen Menschen statt-
finden muss, besteht darin, dem System gewohnte Tätigkeiten bei der Rezeptplanung zu
überlassen. Man braucht sich keine Gedanken mehr zu machen, ob alle benötigten Produk-
te im Haushalt vorhanden sind, sondern überlässt die vollständige Lebensmittelplanung
dem Haushaltsmanager. Man muss die Bereitschaft und das Vertrauen haben, dass ein
technisches Gerät für das leibliche Wohl sorgen kann. Wünsche über Preis/Leistung, Mar-
ken, Qualität, Frische, etc. überlässt man der Software nur mit einem mulmigen Gefühl.
Auf der anderen Seite bietet das EMS die Befriedigung von Bedürfnissen an, die im Laden
nicht möglich wären. Selten erhält man zum Beispiel die Information, wie die Waren pro-
duziert wurden. Die Kennzeichnung für genmanipulierte Waren ist oftmals versteckt und
unauffällig, damit sie dem Einkäufer nicht auffallen. Meist kennt man die Marken kaum
und muss dem Hersteller glauben, was auf der Verpackung steht. Es ist sehr mühsam, sich
als Diabetiker die Inhaltsangaben aller Artikel durchzulesen.

5 Pro und Contra
Die Triebfedern zur Nutzung des Einkaufsmanagementsystems im Allgemeinen sind:
• Rezept- und Artikelsuche unter Berücksichtigung eingegebener Kriterien z.B. Nähr-

wertangaben
• Lebensmittelplanung unter Berücksichtigung von Allergien und Krankheiten
• Berücksichtigung von Genmanipulation, Qualität und biologische Erzeugung
• Einsicht in Informationen über Hersteller, Lieferanten und Produktion
• Ermittlung des besten Preis/Leistungsverhältnisses durch den EMS-Server
• Kalkulation und Weitergabe von Mengenrabatten aus Massenbestellungen
• Verbrauchs- und Bestandsübersicht aller Haushaltswaren
• Einkaufslistengenerierung aus aktuellem Fehlbestand sowie geplanter Mahlzeiten
• Einfache Planung und Anpassung des Lebensmittelverbrauchs
• Zeit- und Aufwandersparnis durch die Lebensmittellieferung an die Haustür
• Effiziente und übersichtliche Haushaltsführung
• Effiziente Kommunikationsmöglichkeiten durch einfache Nachrichtenverfassung (Email,
SMS) sowie Nachrichtenhinterlassung am Haushaltsmanager
• Multimedia-Funktionen, wie sie bei jedem Computer möglich sind (Internet, TV,
Radio, MP3, DVD, etc.)
5.2 Die Lebensmittelverwaltung
Ein weiterer Aspekt ist die Bestandsführung der Lebensmittel, die von Zeit zu Zeit ange-
passt werden muss. Bei Besuch, Urlaub oder Bruch ist es notwendig den Verbrauch auf
die aktuelle Bestandssituation anzupassen. Diese Benutzereingriffe sollten einfach sein, um
eine größtmögliche Akzeptanz zu erreichen. Dazu bedarf es einer Möglichkeit, die Lebens-
mittelstände per Touchscreen ohne viel Tipparbeit einzustellen.
Erstrebenswert wäre auch eine Lebensmittel-Resteverwertung, die nach Planung von be-
stimmten Mahlzeiten, Rezepte vorschlägt, die man mit den übrig gebliebenen Zutaten
zubereiten könnte, bevor das Verfallsdatum abläuft.
Zu jeder Zeit, d.h. auch bei Ausfall des Systems, müssen alle Füllstände der Lebensmittel,
persistent entweder in einer Datenbank oder in Form von XML-Dateien auf einem Daten-
träger abrufbar sein. Sollte das System beschädigt werden, zum Beispiel durch einen Virus
oder einen Festplattendefekt, muss der Zustand des Haushaltsmanagers auf möglichst ein-
fache Weise wiederhergestellt werden können. Alle Daten müssen für die Rezeptauswahl
wieder vorhanden sein, um alle aktuellen Lebensmittelreste berücksichtigen zu können.

6 Pro und Contra
Dies kann durch Sicherheitskopien auf dem Zentralserver und einer einfachen Installation
des Haushaltsmanagers, im folgenden HHM als Teil des EMS, möglich gemacht werden.
5.3 Der neue Markt
Mit der Realisierung des Haushaltsmanagers und einer zunehmenden Benutzerakzeptanz

entsteht ein neuer Markt. Anfangs wird dieser klein und zerbrechlich sein, könnte aber
enorme Dimensionen annehmen, wenn er ungehindert wächst. In diesem Markt sind die
Produkte klarer, die Anbieter transparenter und der Kunde anonymer. Um in diesen Markt
aktiv werden zu können benötigt man nur einen Computer mit Internetanschluss, einen
EMS-Client oder den Haushaltsmanager. Mit dem EMS-Client können Artikel angeboten
werden und mit dem Haushaltsmanager können Artikel erworben werden. Im Internet kann
man über eine Status-Weboberfläche alle benutzerspezifischen Vorgänge mitverfolgen. Das
Potential dieses Marktes ist grenzenlos, wesshalb es Nachahmer, Saboteure und Wieder-
sacher geben wird. Um diese Risiken zu entschärfen, wird ein hohes Maß an Sicherheit
benötigt. Alle Datenübertragungen müssen verschlüsselt stattfinden, die Nutzer, Artikel
oder Standorte dürfen nicht zugänglich sein. Falsche Angebote oder schlechte Lieferan-
ten müssen erkannt werden und das Rechenzentrum muss gegen Angriffe geschützt sein,
Angriffe erkennen, sowie auf Angriffe reagieren können um den neuen Markt zu schützen.
6 Der Zentralserver im Überblick

Der Zentralserver nimmt Bestellungen der einzelnen HHM-Clients entgegen und sichert die
Zustände der Clients ab. Er berechnet Mengenrabatte aus den eintreffenden Bestellungen,
bestimmt die Lieferanten und koordiniert einzelne Hauslieferanten. Der Zentralserver stellt
das Herzstück des EMS dar und sollte strengsten Sicherheitsrichtlinien unterliegen. Er muss
skalierbar sein, um viele gleichzeitige Zugriffe auf die verschiedenen Oberflächen verarbeiten
zu können.
Der Endverbraucher möchte sich in erster Linie nach dem Erwerb des HHM einen Ac-
count erstellen, um das EMS zu nutzen. Dazu ist eine Postidentifikation nötig, wofür er
sich eine PDF-Datei herunterladen, ausdrucken, ausfüllen, von der Post unterschreiben
und abschicken lassen muss. Dies ist auch gleichzeitig die vertragliche Grundlage für die
EMS-Dienstleistungen. Er muss seine persönlichen Daten pflegen und Änderungen z.B. an
seiner Adresse oder des Lebensmittelbudgets vornehmen können. Dies soll ein Interface
ermöglichen, dass im folgenden HHMIF genannt wird.
Diejenigen Artikel, die nicht im Internet erhältlich sind, werden von Fahrdiensten im Einzel-
oder Großhandel besorgt und an den Kunden ausgeliefert. Ein eigenes Webinterface listet
Waren und Lieferorte auf. Jeder, der ein Auto besitzt, kann sich als Nebenbeschäftigung

6 Pro und Contra
am EMS anmelden und als Fahrer tätig werden. Um dies erfolgreich zu praktizieren, be-
wertet der Kunde einzelne Fahrdienste. Dazu ist es notwendig, dass lieferantenspezifische
Auftragsformulare ausgedruckt und dem Kunden bei Anlieferung übergeben werden. Dies
soll auch im HHMIF möglich sein.
Eine der Hauptaufgaben des Zentralservers besteht darin, Mengenrabatte aus den eintref-
fenden Bestellungen zu errechnen, um einen Großteil davon, dem Kunden durch Preismin-
derung zukommen zu lassen. Diese Funktion des Zentralservers soll im folgenden CAL-
CMR heissen. CALCMR stellt neben der Zeitersparnis einen wichtigen Hauptgrund dar,
das EMS für die Nahrungsmittelbeschaffung zu verwenden. Ferner besteht Grund zur An-
nahme, dass Kunden aufgrund der Kostenersparnis und transparenterer Produkte, mehr
Wert auf die Gesundheit legen, als zuvor. Teurere, besonders lukrative oder spezielle Le-
bensmittel werden somit vermehrt nachgefragt. Viele Webshops haben sich bereits auf
Bionahrung, Feinkost oder Diabetes spezialisiert und bieten diese Lebensmittel mehr oder
weniger erfolgreich im Internet an. Ein Webinterface direkt für Webshopbetreiber könnte ei-
ne Schnittstelle schaffen, womit die Artikel aus den Webshops direkt in die EMS-Datenbank
gespeichert werden. Dieses Webinterface soll im folgenden EMSIF genannt werden.
Letztendlich sollen die Lebensmittelhersteller direkt angesprochen werden. Dafür ist ein
weiteres Webinterface notwendig. Es soll dem Lebensmittelhersteller die Möglichkeit bie-
ten, seine Waren direkt an den Kunden zu verkaufen. Dadurch vermindert sich der Preis um
jeden Zwischenhändler, der normalerweise in der Logistikkette enthalten wäre. Transport-
wege und Lagerplätze würden wegfallen, da die Lieferung und Verteilung auf die einzelnen
Haushalte Just-In-Time erfolgen könnte. Der Hersteller sollte zu jeder Zeit sehen können,
wieviel er wann über das EMS absetzen kann und würde so seine Produktion an die aktuel-
len Bedürfnissen des Marktes anpassen können. Dies führt zu höherer Effizienz und damit
zu weiteren Kosteneinsparungen auf der Seite des Herstellers. Durch die exaktere Planung
verderben weniger Waren. Das Webinterface, das dies ermöglicht, ist das EMSIF.
Einzelne Clients auf der Webshop- bzw. Herstellerseite könnten für die jeweilig eingesetz-
ten Datenbanken individuell programmiert werden. Die Daten könnten somit auf einfache
Weise aktuell gehalten werden. Eine schnelle Reaktion mit Aktionen bei freien Produkti-
onskapazitäten wäre somit ein Leichtes. Der Webshopbetreiber bzw. der Hersteller könnten
solche und ähnliche Angebote direkt an das EMS senden. Der Zentralserver nimmt diese
Angebote entgegen und verarbeitet sie direkt für alle eintreffenden Bestellungen, bis das
Kontingent erschöpft ist. Dieses Verfahren wird ebenfalls im EMSIF vorgenommen.
Ohne Zwischenlager als Puffer wird eine Verteilung an die einzelnen Haushalte bedenklich.
Der Zentralserver sollte auch dies übernehmen, um alle Bestellungen, deren Lieferungen und
Paketierung zu koordinieren. Die Bestellungen werden zum höchstmöglichen Mengenrabatt
gebündelt. Die Lieferung erfolgt somit genauso gebündelt. Jetzt muss das Bündel auf die
einzelnen HHM-Bestellungen zum Abtransport verteilt werden. Dazu sollte der Zentralser-
ver pro HHM-Bestellung eine Art Packschein erstellen und diesen als paketiert bestätigen
lassen. Dieses Verfahren soll im folgenden PCKMNGR genannt werden. Für die physische
Realisierung wäre ein System denkbar, wie es bereits bei Paketdiensten eingesetzt wird, um

7 Anforderungsanalyse
eine Warenpalette auf verschiedene Postleitzahlengebiete zu verteilen. Die Palette wäre in

diesem Fall die gebündelte Lieferung und die Postleitzahlengebiete die Hausanschriften der
Kunden. Jetzt können Fahrdienste die HHM-Bestellung ausliefern, beim Kunden kassieren
und die Tageseinnahmen zur Bank bringen, womit weitere Massenbestellungen und das
System selbst bezahlt werden.
Das folgende Kapitel beschäftigt sich mit der Analyse der Anforderungen. Alle notwen-
digen Funktionalitäten werden hier beschrieben. Es wird zwischen Benutzeranwendungs-
fällen (Anwendungsfällen bei denen der Benutzer die Aktionen ausübt) und Systeman-
wendungsfällen (Anwendungsfälle, die das System vornimmt) unterschieden. Eine Tabelle
verdeutlicht hierbei Motivation, Ergebnis, Information sowie Vor- und Nachbedingungen.
Der Fokus liegt stets auf den wesentlichen Komponenten, ohne denen das System nicht
funktionieren würde. Der Rest wird nur am Rande erwähnt.
7.1 HHM Benutzeranwendungsfälle
Als erstes wird der Umgang mit dem Haushaltsmanger aus der Benutzersichtweise be-
schrieben. Neben der Konfiguration wird der Rezeptplan, die Bestellung, das Stornieren
einer Bestellung und die Verbrauchsanpassung näher erläutert. Nicht erläutert werden die
einzelnen Kalenderfunktionen, welche Notizen, Bestellungen und Errinnerungsfunktionen
beinhalten. Die einzelnen Funkionen eines Kalenders sollten jedem bekannt sein. Sie stellen
lediglich ein Nice to have“-Feature dar und sind für die Ausführung des Gesamtsystems
”
unerheblich.
Konfiguration
Der erste Schritt nach Erwerb eines Haushaltsmanagers ist die Konfiguration. Hier werden
benutzerspezifische Daten und Einstellungen erfasst. Der Anwender soll hier Name, Adresse
und Lebensmittelverbrauch anhand der Anzahl im Haushalt lebender Personen eintragen
können. Diese Angaben werden benötigt, um die anzufertigenden Mengen für die einzel-
nen Rezepte zu bestimmen und Allergien, Krankheiten und Vorlieben durch die Auswahl
entsprechender Lebensmittel zu berücksichtigen. Die Eingaben erfolgen am Touchscreen
mit Hilfe einer eingeblendeten Tastatur. Die Konfiguration wird mit der erfolgreichen Re-
gistrierung am EMS-Server abgeschlossen.

Benutzer-Anwendungsfall HHM-Client
Name Konfiguration
Kurzbeschreibung Marken-, Hersteller-, Vorlieben-,
Budgetpräferenzen
verwalten und Verbrauchsangaben pflegen
Motivation Festlegung der Artikel nach persönlichen
Eigenschaften, Registrierung
Ergebnis Kontrolle über den Konsum, Registrierung, Vertrag
Akteure jeder Benutzer
Eingehende Information festgelegte Präferenzen
Vorbedingung Präferenzen erfassbar
Nachbedingung Registrierung beim Zentralserver zur Sicherung
Essenzielle Schritte - Persönliche Daten, Präferenzangabe,
Mengenangabe
- Budgeterfassung
- DB-Profil-Update
Tabelle 1: Benutzer-Anwendungsfall Konfiguration
Rezeptplanung
Im zweiten Schritt werden die Rezepte vorgeplant. Hierbei können ein oder mehrere Haupt-
gerichte pro Tag definiert werden. Die Rezepte hierfür werden aus einer Matrix ausgewählt.
In Y-Richtung befinden sich die Hauptbestandteile der Gerichte, wie zum Beispiel Geflügel-,
Schwein-, Rind- oder Fischgerichte. Auf der X-Achse sind die Länder aufgeführt, aus de-
nen die Gerichte stammen. Auf diese Matrix kann man einen Filter setzen, sodass nur
bestimmte Gerichte ausgewählt werden können. Zum Beispiel kann man sich nur Vegetari-
sche Gerichte anzeigen lassen, Gerichte für eine spezielle Zutat aus dem Lebensmittelvorrat
oder Gerichte nach bestimmten Preisvorstellungen. Jede Zelle der Matrix repräsentiert eine
Liste mit Gerichten.

Abbildung 1: HHM-Rezeptmatrix
Mit einem Klick auf eine Zelle in der Matrix werden alle Gerichte angezeigt. Wählt man ein
Gericht aus, erscheint ein Bild des Rezeptes mit einer Beschreibung zur Zubereitung. Der
voraussichtliche Preis sowie eine Liste mit den Zutaten können eingesehen werden. Möchte
man dieses Gericht einplanen, kann man es in einer Kalenderansicht für ein bestimmtes
Datum eintragen. Dieses Verfahren wird wiederholt, bis die Vorplanung vollständig ist.
Der Bestellvorgang
Sind alle Gerichte im Kalender eingetragen, kann man die Bestellung vornehmen.
Bestellungen stornieren
Ist ein Fehler bei der Planung aufgefallen, so kann der Benutzer einzelne Rezepte stornieren
und neu einplanen.

Name Rezeptplanung
Kurzbeschreibung Vorplanung der Gerichte für einen bestimmten
Zeitraum
Motivation Antwort auf Was kann ich heute kochen?“
”
Ergebnis Gerichte nach Vorlieben in Bezug auf Verwertung
Eingehende Information Augewählte Rezepte
Vorbedingung Rezepte vorhanden
Nachbedingung Zutaten bestellbar
Essenzielle Schritte - Zeitraum festlegen
- Gerichte auswählen
- Zutaten und Verfügbarkeit ermitteln
- Preise und Budgetverbrauch aktualisieren
- Resteverwertung berücksichtigen
- Liste mit Rezepten zur Resteverwertung anzeigen
solange Reste noch vorhanden
Tabelle 2: Benutzer-Anwendungsfall Rezept-Planung
Name Bestellung
Kurzbeschreibung Benutzer bestellt geplante oder ausgewählte
Produkte
Motivation komfortable Bestellung im Internet
Ergebnis Lieferung der Waren an die Haustüre
Eingehende Information Bestellwunsch
Vorbedingung Produkterfassung, gefüllter Warenkorb
Nachbedingung Produkte verfügbar, Budget nicht verbraucht
Essenzielle Schritte Bestellung an EMS-Server übermitteln
Tabelle 3: Benutzer-Anwendungsfall Bestellung

Benutzer-Anwendungsfall
Name Bestellung stornieren
Kurzbeschreibung Benutzer möchte Bestellungen stornieren
Motivation Korrektur einer falschen Planung
Ergebnis Bestellung storniert
Eingehende Information Stornierungswunsch, Bestellnummer
Vorbedingung Bestellung/Bestellnummer vorhanden
Nachbedingung Bestellung noch nicht unterwegs,
Stornierung wird vom Lieferanten akzeptiert
Essenzielle Schritte - Stornierwunsch vollständig übermittelt
- Mengenrabatte anpassen
- DB-Update
- Meldung zurückgeben
Tabelle 4: Benutzer-Anwendungsfall Bestellung stornieren
Verbrauch anpassen
Merkt der Benutzer, dass der Grundnahrungsmittelverbrauch zu hoch oder zu knapp be-
messen ist oder gehen zum Beispiel Gläser zu Bruch, so kann er über den Touchscreen
dauerhaft oder temporär einen höheren Verbrauch einplanen.
7.2 HHM Systemanwendungsfälle
Die Haushaltsmanager-Systemanwendungsfälle beschreiben die Funktionen des Haushalts-

mangers aus der System-Perspektive. Es werden nur diejenigen Funktionen beschrieben,
die unmittelbar vom System ausgeübt werden. Dazu gehört das Verbrauchsmanagement
die Zustandssicherung und die Kalenderfunktionalität, die jedoch nicht erläutert wird.
Verbrauchsmanagement
Der Haushaltsmanager berücksichtigt automatisch nach Auswahl eines Rezeptes auch den
Zutatenverbrauch. Dazu schlägt er andere Rezepte vor, mit denen die Zutaten aufgebraucht
werden können. Ob man diese einplant oder nicht, ist einem selbst überlassen.

Name Grundnahrungsmittel-Anpassung
Kurzbeschreibung Benutzereingriff bei Mehrverbrauch, Bruch,
Resteverwertung, Verderb
Benutzereingriff bei ausserplanmäßigem Einkauf
Motivation Sofortanpassung der Lebensmittel-Füllstände
Ergebnis aktueller Lebensmittelstand
Eingehende Information neuer Lebensmittelstand
Vorbedingung Lebensmittel erfasst, vorhanden
Nachbedingung Lebensmittelstand plausibel und innerhalb der Planwerte
Essenzielle Schritte - Skala mit dem Finger anpassen
- ggf. Ware erfassen
- DB-Update
Tabelle 5: Benutzer-Anwendungsfall Grundnahrungsmittel-Anpassung
System-Anwendungsfall HHM-Client
Name Rezeptplanung-Resteverbrauch
Kurzbeschreibung Ermittlung aller Rezepte, die mit den Resten
gemacht werden können,
Ermittlung der Zeitspanne, bis Reste
verwertet werden müssen
Motivation Ermittlung und Vorschlag der besten Verwertungs-
möglichkeiten anhand von Rezeptvorschlägen
zum möglichst vollständigen Verbrauch aller Reste
Ergebnis Reduzierung der Lebensmittelabfälle,
effizienterer Lebensmittelverbrauch
Akteure HHM
Eingehende Information Rezept ist geplant
Vorbedingung Rezept vorhanden, Rezept gebucht,
benötigte Artikel erfasst
Nachbedingung Rezepte für Lebensmittelrestverbrauch vorhanden
Essenzielle Schritte - Ermittlung aller in Frage kommender Rezepte
- Erstellen einer Primär-Rezeptliste für die weitere
Auswahl bei der Planung
Tabelle 6: HHM-Anwendungsfall Rezeptplanung-Resteverbrauch

System-Anwendungsfall HHM-Client
Name Zustandssicherung
Kurzbeschreibung Sicherung des Zustands des HHM
auf dem Zentralserver
Motivation Wiederherstellung aller Daten
Ergebnis aktueller Lebensmittelstand,
aktuelle Rezeptpläne, Budget und Bestellungen
Akteure HHM, EMS
Eingehende Information Zustandsänderung
Vorbedingung HHM ist beim EMS registriert
Nachbedingung Zustandsänderung erfasst und gesichert
Essenzielle Schritte - Zustandsänderung erfassen
- Änderung sichern
- DB-Update
Tabelle 7: HHM-Anwendungsfall Zustandssicherung
Zustandssicherung
Es empfiehlt sich regelmäßig den Zustand des Haushaltsmanagers zu sichern. Dazu scheint
der Zentralserver am geeignetsten zu sein.
7.3 EMS-Server Benutzeranwendungsfälle
Die EMS-Server Benutzeranwendungsfälle beschränken sich hauptsächlich auf Marketing-

, Aquisitions-, Support-, Sicherheits-, Kontroll-, Wartungs- und Administrationsaspekte,
die aus Zeitgründen nicht näher erläutert werden. Die Kernfunktionalitäten sollen keine
ständig anwesende Personen erfordern.
EMS-Server Benutzeranwendungsfall Status-Portal (ST-Portal)
Die Status-Liste besteht aus mehreren Datenbanktabellen, die je nach zugreifender Person
andere Sichten auf die Daten bietet. Der HHM-Kunde sieht z.B. neben seinen persönlichen
Daten, seine aktuellen Einkäufe und zukünftigen Bestellungen sowie seine Budget- und
Verbrauchsstatistik. Der Hauslieferant sowie seine Lieferdienste sehen den aktuellen Liefer-
plan mit Anfahrts- und Routenskizze. Hersteller, Webshopbesitzer und Großhändler sehen
aktuelle Verkaufsdaten und Bestellungen ihrer Produkte. Sowohl allgemeine Informationen
über Wartung oder Neuigkeiten als auch benutzerspezifische Sichten auf die eigenen Ge-
schäftsverläufe, Marktdaten oder Produktinformationen können hier eingesehen werden.

Benutzer-Anwendungsfall EMS-Server
Name Status-Portal
Kurzbeschreibung Aktuelle Informationen einsehen
Motivation Kurzinformationen bei Internetzugriff
z.B. bei Konfiguration als Startseite
Ergebnis Aktuellste System- und Leistungsinformationen
Akteure EMS-Server Status-Portal
Eingehende Information Individuelle Leistungsdaten aus EMS
Vorbedingung Registrierung am EMS, Konfiguration des Portals
Nachbedingung Akzeptierte Nutzungsbedingungen
Essenzielle Schritte Login
Tabelle 8: Benutzer-Anwendungsfall Status-Portal
Benutzer-Anwendungsfall EMS-Server
Name EMS Administration
Kurzbeschreibung Verwaltung des EMS
Motivation Kontrolle, Planung und Steuerung des EMS
Ergebnis Zentrale Administrationskonsole
Akteure EMS-Server Administrator
Eingehende Information EMS-Daten
Vorbedingung Administrationszugriff
Nachbedingung Daten verfügbar, abrufbar
Essenzielle Schritte - Login
- Konfiguration
- Informationsgenerierung
Tabelle 9: System-Anwendungsfall EMS Administration
EMS-Server Benutzeranwendungsfall Administration
Ein zweiter, wichtiger Benutzeranwendungsfall ist die Administration des EMS-Servers.

Hier können Benutzer verwaltet, Budgets kontrolliert und die Sicherheit überprüft werden.
Listen und grafische Ansichten erleichtern die Interpretation der ständigen Datenfluten.
Man kann Logdateien einsehen und Konfigurationsdateien bearbeiten. Eine Voraussicht,
generiert aus den gegenwärtigen Daten des EMS-Servers, vereinigt mit den Daten der EMS-
Clients, gibt Aufschluß über Engpässe und andere Handlungsbedarfe. Spezifische Firewall-,
Angriffserkennungs- und Backupsysteminformationen können per Mail oder SMS an ver-
schiedene Administratoren verschickt werden.

System-Anwendungsfall EMS-Server
Name Eingehende Bestellung
Kurzbeschreibung HHM-Client bestellt geplante oder ausgewählte
Produkte
Motivation Mengenrabatte, Preis-/Leistung
Ergebnis Lieferung der Waren an die Haustüre
Akteure EMS-Server BSTMNGR
Eingehende Information Warenliste
Vorbedingung Produkterfassung, vollständige Übertragung
Nachbedingung Produkte verfügbar, Budget nicht verbraucht
Essenzielle Schritte - Bestellung speichern
- gleiche Artikel anderer Bestellungen
zusammenfassen
- Mengenrabatte berechnen
- Maximalen Endpreis zur Bestätigung
übermitteln
- Nach Zusage vom Kunden wird Bestellung
als preisbestätigt markiert
Tabelle 10: System-Anwendungsfall Eingehende Bestellung
7.4 EMS-Server Systemanwendungsfälle
Die wichtigsten Anwendungsfälle, die das System selbständig, ohne Hilfe von ständig anwe-
sendem Personal vornehmen muss, werden in diesem Abschnitt erläutert. Dazu gehören der
Bestellungseingang, die Mengenrabattkalkulation, Paketierung, Bestellungsausgang, Lager-
management und das Client-Interface-Management. Die Zustandsabspeicherung, Anmel-
dungen, Lieferantenbestimmung sowie Listen- und Formularerzeugung werden hier nicht
erwähnt, da diese Anwendungsfunktionalitäten offensichtlich und umfangreich erscheinen
und damit Zeit einsparen sollen.
Eingang der Bestellung
Geht eine Bestellung beim Zentralserver ein, so muss diese als erstes gespeichert werden.
Entweder in der Datenbank oder als XML-Datei auf der Festplatte, so können die ge-
speicherten Daten für Sammelbestellungen verwendet werden. Mit einer hohen Summe an
gleichen Artikeln, können beim Lieferanten Mengenrabatte geltend gemacht werden. Je
höher die Summe der bestellten Artikel ist, desto niedriger ist der Preis für den Kunden.
Dieser Preis muss dem Kunden als Bestätigung der Bestellung zugeschickt werden. Ist der
Kunde mit dem Preis nicht einverstanden, kann er die Bestellung sofort zurückziehen.

Name Mengenrabattkalkulation
Kurzbeschreibung Mengenrabatte werden aus gleichen
Artikeln eingehender Bestellungen kalkuliert
Motivation möglichst günstiger Preis
Ergebnis besseres Preis-/Leistungsverhältnis
Akteure EMS-Server CALCMR
Eingehende Information Anzahl eines Produkts
Vorbedingung Festgelegte Mindestmenge überschritten
Nachbedingung Kapazität des Lieferanten nicht überschritten
Essenzielle Schritte - Summe Produkte erhöhen
- Mengenrabatt ermitteln
- Preis des Produkts zurückgeben
- Preisbestätigte Bestellungen einbeziehen
Tabelle 11: Sytem-Anwendungsfall Mengenrabattkalkulation
Mengenrabattkalkulation
Nach Eintreffen der Bestellungen wird für jeden einzelnen Artikel eine Suche nach gleichen
Artikeln in anderen Bestellungen gesucht. Diese Artikel werden bei Erreichen einer be-
stimmten, vom Lebensmittellieferant (Webshop, Großhandel, Hersteller) festgelegten An-
zahl zusammengefasst. Jede Bestellung kann hierbei den Preis des Artikels mindern.
Ausgang der Bestellungen
Stehen alle Bestellungen fest und befinden sie sich an der Grenze zum spätesten Bestell-
zeitpunkt, werden die Artikel für die Bestellung freigegeben. Der Bestellmanager holt sich
alle Artikel bzw. Bestellungen aus der Datenbank, deren Bestellzeitpunkt kurz bevor oder
bereits überschritten ist, legt den günstigsten Lieferanten fest und bestellt die Waren. Sind
die Artikel bei keinem Lieferanten erhältlich, werden die Fahrdienste informiert, diese zu
besorgen. Dazu wird die Auftragsliste der Fahrdienste ergänzt und aktualisiert.
Paketierung
Um die großen Bestellmengen aufgrund der Mengenrabatte wieder auf die einzelnen Haus-
halte zu verteilen, wird der Paketierungsmanager benötigt. Der Bestellmanager markiert
zuvor alle Bestellungen als bestätigt. Hier setzt der Paketierungsmanager an und verteit

Name Bestellungsausgang
Kurzbeschreibung bevorstehende Bestellungen werden ermittelt
und beim günstigsten Lieferanten bestellt
Motivation automatisierter Bestellvorgang
Ergebnis pünktliche Lieferungen
Akteure EMS-Server BSTMNGR
Eingehende Information bevorstehende Bestellungen
Vorbedingung Preis bestätigt
Nachbedingung Waren lieferbar
Essenzielle Schritte - Liste mit Bestellungen zusammenstellen
- Lieferanten festlegen
- Bestellungen verfassen
- Bestellungen absenden
Tabelle 12: Sytem-Anwendungsfall Bestellungsausgang
alle Einheiten nach der Zeit-Markierung in der Datenbank wieder auf die einzelnen Bestel-
lungen der Haushaltsmanager. Jede Bestellung der Haushalte wird als ein Paket betrachtet,
dass der Bringservice abholt und zum Kunden fährt.
Lagermanagement
Der Lagermanager ist zuständig für den Ein- und Ausgang von Kundenpaketen im Lager.
Er führt Listen über Größe und ID des Packetes. Er ordnet passende Abstellplätze zu
und übermittelt diese dem BSMNGR. Der Hauslieferant liest die Abholplätze von der
Bringservice-Liste ab, um die Waren abholen und anschließend dem Kunden ausliefern zu
können.
Client-Interface Manager
Je nachdem, welcher Benutzer (Webshopbetreiber, Großhändler, Hersteller, Lieferservice,

Haushaltsmanager) sich am EMS-Server anmeldet, bekommt er eigene Sichten auf die Da-
tenbank. Darin sind Marktdaten, Produkte zum Vergleich und Analysefunktionen für Lie-
feranten enthalten. Lieferservices können sich Aufträge ansehen, annehmen oder wieder
freigeben und Kunden können ihren Budgetverbrauch anpassen, vergangene Planungen
ansehen und ihre persönlichen Daten ändern. Der Client-Interface Manager hat wie der
Name schon sagt, die Aufgabe die Benutzeroberflächen und Funktionen für dei jeweiligen
Benutzer zur Verfügung zu stellen. Er verwaltet, loggt mit und verteilt die Ressourcen

Name Paketierung
Kurzbeschreibung Sammelbestellungen werden wieder
auf einzelne HHM-Bestellmengen verteilt
Motivation effiziente, fehlerlose Paketerstellung
Ergebnis automatisierte Paketierung
Akteure EMS-Server PCKMNGR
Eingehende Information eingetroffene Sammelbestellung
Vorbedingung Zeit-Markierung bei Bestellung
Nachbedingung genug Packkartons und Platz vorhanden
Essenzielle Schritte - Liste mit Bestellungen zusammenstellen
- Bestellungen mit Eingang abgleichen
- Anzahl Produkte Bestellungen zuordnen
- Lagermanager Größe und ID mitteilen
Tabelle 13: Sytem-Anwendungsfall Paketierung
Name Lagermanagement
Kurzbeschreibung koordiniert Ein- und Ausgang von
Kundenpacketen des Lagers
Motivation effiziente Lagerplanung
Ergebnis Just-In-Time-Belieferung
Akteure EMS-Server LagerMNGR
Eingehende Information Größe, ID des Kundenpackets
Vorbedingung Bestellung nicht storniert
Nachbedingung Lagerplatz vorhanden
Essenzielle Schritte - Ermittlung von Kunde, Adresse, Artikel
Liefertermin aus der ID
- passenden Lagerplatz zuordnen
- Hauslieferanten ermitteln und informieren
- Bringservice-Auftragsliste aktualisieren
Tabelle 14: Sytem-Anwendungsfall Paketierung

Name Interface Management
Kurzbeschreibung Überwachung, Verwaltung und Verteilung
der Ressourcen, Schnittstellen und Funktionen
Motivation effiziente und sichere Verwaltung von Zugriffen
Ergebnis Zugangs- und Ressourcenkontrolle
Akteure EMS-Server Clnt Intf MNGR
Eingehende Information Benutzername
Vorbedingung Benutzerkonto ungesperrt vorhanden
Nachbedingung korrektes Passwort
Essenzielle Schritte - Ermittlung der benötigten Ressourcen
- Zugriffsgewährung
- Aktivierung des Loggings in der Datenbank
- Start der Sitzung
Tabelle 15: Sytem-Anwendungsfall Interface Management
(Festplattenkapazität, Prozessorleistung, etc.), die benötigt werden. Wie ein Proxy über-
wacht der Interface Manager Zugriffe und Ressourcen auf die Fassade, die als Schnittstelle
zum gesamten System dient.
7.5 Hersteller-Client (EMS-Client) Benutzeranwendungsfälle
Stellvertretend für alle EMS-Clients (Hersteller-, Webshop-, Großhändler-Client) wird der

Hersteller-Client betrachtet. Die Funktionalitäten sind bis auf kleinere Unterschiede die-
selben. Der Client soll neben eigenen Angaben über Firma, Konditionen, etc. Produkte
in das System einbringen können. Diese Produkte stellt das System für den Kunden zum
Kauf zur Verfügung. Jedes Produkt hat eigene Eigenschaften, die vom EMS-Lieferanten
gepflegt werden müssen. Herstellort, Herstellungsverfahren, Produktqualität, Herkunft der
Zutaten, Zutaten-Liste, mit/ohne Zucker, biologisch, diabetikergeeignet, etc., um nur ei-
nige, wenige zu nennen. Je mehr Angaben der Hersteller macht, desto einfacher ist es für
den Kunden sich für diese Artikel zu entscheiden oder vom System ausgewählt zu werden.
Ziel ist es, eine Datenbank mit möglichst vielen Lebensmitteln und ihren Eigenschaften zu
schaffen.
Produkte einstellen
Neben der Eingabe und Pflege von Produkten, können auch Sonderangebote, Aktionspreise
und Sonderkonditionen verfasst werden, die direkt auf dem EMS-Server bearbeitet werden
können. Diese sollen dem EMS-Lieferanten die Möglichkeit geben, den Markt flexibler zu

Benutzer-Anwendungsfall EMS-Client
Name Produkte einbringen
Kurzbeschreibung Der Hersteller bringt seine Produkte
in das Gesamtsystem selbst ein
Motivation Automatisierter Verkauf von Waren
Ergebnis Produktdatenbank aller Lieferanten
mit vielfältigen Produkteigenschaften
Akteure EMS-Client Benutzer
Eingehende Information Produktpalette
Vorbedingung Konfiguration auf individuelle Bedürfnisse
Nachbedingung Produkte verfügbar, Wissen ausreichend
Essenzielle Schritte - Produkte laden, ergänzen
- Verbindung zum EMS-Server aufbauen
- Daten übertragen
Tabelle 16: EMS-Client Benuter-Anwendungsfall Produkte einbringen
nutzen. Produziert der Hersteller zuviel, kann er den Absatz durch Sonderangebote und
Aktionen steuern.
Forecast
Der EMS-Client merkt sich alle Angebote und Produkte des Lieferanten in einer eige-
nen Datenbank und berechnet den aktuellen, sowie den zukünftigen Absatz der jeweiligen
Artikel bzw. Artikelgruppen. Die Betrachtung der zukünftigen Gegebenheiten beruht auf
der Annahme der gegenwärtigen Zahlen mit angegebener Varianz für die zu erreichenden
Marktziele, Wirtschaftsbedingungen oder zukünftigen Konditionen. Hiermit soll dem An-
bieter von Produkten die Möglichkeit gegeben werden, alle Transaktionen mit dem EMS-
Server zu überblicken, Statistiken zu erstellen sowie den Markt zu kalkulieren und seine
Produktion daran anzupassen.
7.6 Hersteller-Client (EMS-Client) Systemanwendungsfälle
Die Hersteller-, Webshop- und Großhändler-Clients stellen im Prinzip eine Individualsoft-

ware dar, die an die Bedürfnisse der Lieferanten angepasst werden muss. Die Clients haben
die Hauptaufgabe die Artikeldaten der Lieferanten so aufzubereiten, dass sie mit dem
EMS-Server kompatibel sind. Je nach Datenbank des Lieferanten müssen dazu individuelle
Anpassungen zur Konvertierung vorgenommen werden.

Benutzer-Anwendungsfall EMS-Client
Name Forecast
Kurzbeschreibung Ermittlung des zufünftigen Absatzes
aus Gegenwärtigen Zahlen
Motivation Überblick über alle Transaktionen
Ergebnis statistisch kalkulative Markteinschätzung
sowie effiziente Produktionsanpassung
Akteure EMS-Client Benutzer
Eingehende Information Transaktionen, Server-Marktdaten
Vorbedingung Konfiguration auf individuelle Bedürfnisse
Nachbedingung Marktdaten verfügbar, Transaktionen ausreichend
Essenzielle Schritte - Transaktions- und Marktdaten sammeln
- Kennwerte ermitteln
- Daten für Abruf bereithalten
Tabelle 17: EMS-Client Benutzer-Anwendungsfall Forecast
Datenaufbereitung
Je nach System des Lieferanten müssen die Artikeldaten für den EMS-Server ergänzt und
umkonvertiert werden. Zum einen kann dies zum Beispiel über Prozeduren und Funktionen
in der Datenbank oder über ein BAPI aus dem SAP-System stattfinden. Die Daten wer-
den aus der Lieferantendatenbank geholt, aufgearbeitet (ergänzt, erweitert), in ein EMS-
konformes Format umgewandelt und zum EMS-Server geschickt. Dies läuft im Hintergrund
des Clients ab, wenn der Lieferant seine Artikeldaten oder Aktionen an den EMS-Server
übermitteln will.
Lieferantenklassifikation
Um Artikel, Konditionen und Kapazitäten der Lieferanten zu erfassen, werden Daten über
die geschäftlichen Beziehungen vom EMS-Client zum Abruf bereit gehalten. Diese Infor-
mationen werden benötigt, um die einzelnen Lieferanten zu klassifizieren, schnellen Zugriff
durch Vorauswahl auf gesuchte Artikel zu gewährleisten und unzuverlässige Lieferanten zu
erkennen. Die Lieferanten selbst haben nur den Einfluss, diese Daten für den Zugriff des
EMS-Servers zu sperren. Erfasst werden allgemeine Artikeldaten (Anzahl Bioprodukte,
Diabetikerprodukte, Artikelzuwachs, etc.), Konditionsschwankungen, Kapazitätsschwan-
kungen und Liefertreue.

System-Anwendungsfall EMS-Client
Name Datenaufbereitung
Kurzbeschreibung Artikeldaten werden aus der Datenbak
geholt, ergänzt und für den Transport vorbereitet
Motivation automatische Umkonvertierung der Daten
Ergebnis einfacher Datenaustausch
Akteure EMS-Client
Eingehende Information Artikeldaten
Vorbedingung Individualanpassung zur Konvertierung
Nachbedingung Benötigte Daten ergänzt
Essenzielle Schritte - Daten aus Lieferanten-Datenbank holen
- Ergänzung fehlender Positionen
- Datenaufbereitung
- Verbindungsaufbau zum EMS-Server
- Datenübertragung
Tabelle 18: EMS-Client System-Anwendungsfall Datenaufbereitung
System-Anwendungsfall EMS-Client
Name Lieferantenklassifikation
Kurzbeschreibung Datenerfassung zur Klassifikation der
Geschäftsbeziehungen zum Lieferanten
Motivation Erkennung unzuverlässiger Lieferanten
Ergebnis Hohe Kundenzufriedenheit
Akteure EMS-Client
Eingehende Information Bestelldaten, Lieferdaten, Konditionen
Vorbedingung Mindestanzahl von Bestellungen erreicht
Nachbedingung Zugriffsgewährung auf die Daten
Essenzielle Schritte - Konditionen gruppieren
- Bestell- und Lieferinformationen auswerten
- Artikeldaten erfassen
- Erkenntnisse zusammenfassen
- Erkenntnisse zum Abruf bereitstellen
Tabelle 19: EMS-Client System-Anwendungsfall Lieferantenklassifikation

7.7 Bringservice-Manager (BSMNGR) Benutzeranwendungsfälle
Der Bringservice-Manager ist eine Komponente des EMS-Servers und verwaltet alle Haus-
lieferanten. Er wird als eigenständige Komponente betrachtet, da er sowohl Benutzer- als
auch Systemanwendungsfälle beinhaltet. Die Hauslieferanten können sich beim Bringserver-
Manager alle in Frage kommenden Aufträge anzeigen lassen. Es kann angegeben werden,
wieviel Volumen oder Gewicht maximal mit dem eigenen Fahrzeug transportiert werden
kann. Angaben, welche Postleitzahlenbereiche beliefert werden können, sowie die Registrie-
rung für ein bestimmtes Gebiet zu bestimmten Tagen und Uhrzeiten, sind möglich. Der
Bringservice-Manager schickt neue Aufträge (vorausgesetzt Ort und Zeit stimmen mit der
Konfiguration überein) per Email oder SMS an den Hauslieferanten. Für jedes Lieferservice-
Mitglied ist ein eigener Account nötig, mit dem man Aufträge annehmen, angenommene
Aufträge wieder einstellen sowie Fahrten auf mehrere, vorher definierte Benutzer aufteilen
kann.
Konfiguration
Am Bringservice-Manager muss man sich vorerst registrieren. Man gibt persönliche Daten
ein und bestätigt einen Liefervertrag. Nachdem die Registrierung erfolgt ist, kann der
Hauslieferant die Konfiguration vornehmen. Dabei gibt er Leistungsangaben an, die er
zum System beitragen kann. Zum Beispiel über wieviele Fahrzeuge und Mitarbeiter er
verfügt und welche Mengen transportiert werden können. Angaben darüber, wohin und zu
welchen Zeiten er für welchen Preis Kunden beliefert. Diese Angaben sind vor Allem dafür
notwendig, damit der LagerMNGR des EMS-Servers die paketierten Sendungen einzelnen
Lieferanten zum rechtzeitigen Liefertermin zuordnen kann.
Fahrten verwalten
Hat man sich als Hauslieferant registriert und die Konfiguration vorgenommen, kann man
seine Fahrten verwalten. Vor allem diejenigen Hauslieferanten, die über mehere Fahrzeu-
ge und Mitarbeiter verfügen, bekommen mit der Fahrtenverwaltung ein Werkzeug in die
Hand, mit dem man sich schnell einen Überblick über die Auslastung der Leistungs- und
Lieferkapazitäten verschaffen kann. In der Fahrtenverwaltung können Aufträge und Än-
derungen einzelnen Fahrern per Email oder SMS zugeordnet werden. Der Hauslieferant
kann einen Lieferplan erstellen, wann, wer, mit was beliefert werden soll, um die Termine
einzuhalten. Man sieht welcher Fahrer, zu welchem Zeitpunkt, welchen Kunden beliefert
und kann auf neu eintreffende Aufträge flexibel und effizient reagieren.

Benutzer-Anwendungsfall BSMNGR
Name Konfiguration
Kurzbeschreibung Persönliche sowie Leistungsangaben,
die der Fahrer zum System beitragen kann
Motivation flexible und schnelle Lieferungen
Ergebnis Großes, flexibles Lieferantenheer
Akteure Hauslieferant
Eingehende Information Konditionen, Leistungsangaben
Vorbedingung Hauslieferant ist registriert
Nachbedingung Lieferantenvertrag akzeptiert
Essenzielle Schritte - Anmeldung / Registrierung / Vertrag
- Angabe von Leistungsdaten und Konditionen
- Angabe von Emailadresse oder Handynummer
- Speichern
Tabelle 20: BSMNGR Benutzer-Anwendungsfall Konfiguration
Benutzer-Anwendungsfall BSMNGR
Name Fahrtenverwaltung
Kurzbeschreibung Verwaltung und Überblick über Lieferaufträge
Motivation Überblick zur Lieferdienstkoordinierung
Ergebnis flexible und effiziente Lieferpläne
Akteure Hauslieferant
Eingehende Information Auftrag
Vorbedingung Konfiguration
Nachbedingung Leistungskapazitäten vorhanden
Essenzielle Schritte - Auftragsannahme
- Fahrer und Route bestimmen
- Lieferplan (neu) erstellen
- Änderungen bekanntgeben
Tabelle 21: BSMNGR Benutzer-Anwendungsfall Fahrtenverwaltung

Server-Anwendungsfall BSMNGR
Name Lieferauftragsvergabe
Kurzbeschreibung Zuordnung von Fahrer zu Kundenpaket
Motivation schnelle, automatische Lagerentnahme
Ergebnis pünktliche Lieferungen
Akteure EMS-Server BSMNGR
Eingehende Information Lieferauftrag
Vorbedingung Vollständige Daten
Nachbedingung freie Lieferkapazitäten
Essenzielle Schritte - Daten vom Packetmanager auf
Vollständigkeit überprüfen
- Fahrer informieren
- Auftrag in Liste eintragen
Tabelle 22: BSMNGR Server-Anwendungsfall Lieferauftragsvergabe
7.8 Bringservice-Manager (BSMNGR) Systemanwendungsfälle
Der EMS-Server hat bezüglich der Hauslieferanten die Aufgabe, einzelnen Kundenpakete
Lieferanten zuzuordnen. Dazu benutzt das System Listen, die von den Fahrdiensten ein-
sehbar sind. Jeder Eintrag in der Liste kann durch eine Transaktion gesperrt, gebucht oder
wieder freigegeben werden. Ferner erfolgt vom Kunden eine freiwillige Bewertung der Fahr-
dienste. Hier können Kunden unpünktliche oder fehlerhafte Lieferungen beanstanden.
Lieferaufträge vergeben
Kommt ein Auftrag vom LagerMNGR an, wird ein entsprechender Fahrdienst benachrich-
tigt. Gleichzeitig wird der Auftrag in einer freien Liste geführt, bis er von einem Hauslie-
feranten oder einem einzelnen Fahrer angenommen wird. Kann ein Hauslieferant oder ein
Fahrer gefunden werden, wird er umgehend per Email oder SMS über den Eingang des
Auftrags informiert. Hauslieferanten werden hauptsächlich damit beschäftigt sein, Aufträ-
ge unverzüglich anzunehmen und sie in den Fahrplan einzelner Fahrer zu integrieren, bevor
ein anderer Hauslieferant oder Einzelfahrer diese annehmen kann.
Fahrdienstbewertungen
Beschwert sich ein Kunde über eine Lieferung oder über einen Lieferanten, wird das vom
System gespeichert. Kommt eine Beschwerde bei einem Hauslieferanten oder Einzelfahrer
öfter vor, wird dieser darüber informiert. Bei mutwilliger Zerstörung erfolgt sofortiger Aus-
schluss vom System. Bei grober Fahrlässigkeit erhält der Fahrer eine Abmahnung. Nach drei

8 Entwurf
Server-Anwendungsfall BSMNGR
Name Fahrdienstbewertung
Kurzbeschreibung Beschwerdemanagement bei
Lieferdienstleistungen zum Kunden
Motivation Ausschluss von unzuverlässigen Fahrern
Ergebnis hohe Kundenzufriedenheit
Akteure EMS-Server BSMNGR
Eingehende Information Beschwerde zum Lieferauftrag
Vorbedingung Auftrag ist angenommen worden
Nachbedingung Fahrdienst noch aktiv
Essenzielle Schritte - Beschwerde abspeichern
- Fahrerbeschwerdenkatallog aktualisieren
- ggf. Hauslieferant oder Fahrer informieren
- ggf. Fahrdienstprüfer informieren
Tabelle 23: BSMNGR Server-Anwendungsfall Fahrdienstbewertung
Abmanungen kann er von der Lieferauftragsannahme ausgeschlossen werden. Hier bedarf

es aber einer Prüfung, die von einer natürlichen Person durchgeführt werden muss.
8 Systementwurf
Im Folgenden wird der Systementwurf systematisch durchgeführt. Abbildung 2 zeigt, wie
das Gesamtsystem arbeiten soll. Der Zentralserver arbeitet hier wie ein Nachrichtensystem,
das Nachrichten annimmt, verarbeitet und weiterleitet. Im äußeren Bereich der Grafik ste-
hen die Systemnutzer. Links oben der Endverbraucher, der vom Webshopbetreiber (links
unten) und vom Bringservice (rechts oben) beliefert wird. Unten mittig beliefert der Groß-
händler bzw. der Hersteller das System mit Lebensmitteln, die vom Bringservice an die
einzelnen Endkunden- bzw. Gastronomieadressen ausgeliefert werden. Schließlich befindet
sich rechts vom Zentralserver das gewerbliche Pendant des Haushaltsmanagers für Hotel-
und Gastronomiegewerbe - das EKM. Es erbt alle Funktionen des Haushaltsmanages, hat
jedoch ein anderes Design und einige zusätzliche Funktionen, wie Terminvereinbarungen
zur Besichtigung der Waren, Gourmetlisten, sowie ein kontrollierbares Lieferkettensystem.
Jeder Bestandteil des EMS kann als eigenständiges System betrachtet werden.

8 Entwurf
Abbildung 2: Einkaufsmanagementsystem und Systemnutzer-Interaktionen
Die blauen Pfeile stellen Warensendungen dar, die dünneren schwarzen Pfeile verdeutlichen
die Datenkommunikation. Grau hinterlegt ist das gesamte Einkaufsmanagementsystem. Es
besteht aus HHM, EKM und Zentralserver. Die Systembestandteile sind über das Inter-
net miteinander verbunden. Außerhalb des Systems benutzen die Systemnutzer angepasste
Computersysteme zur Kommunikation mit dem Zentralserver. Der Webshopbetreiber er-
hält über ein Webshop-Interface Zugriff auf den Zentralserver, um Artikel- und Bestelldaten
austauschen zu können. Dies geschieht über eine individuelle Anpassung seines Webshops.
Hersteller haben ein eigenes ERP-System, meist von der Firma SAP im Einsatz. Die Kom-
munikation mit dem Zentralserver wird hier über ein individuelles BAPI in Verbindung
mit BSP-Seiten realisiert. Der Bringservice erhält Aufträge per SMS oder Email auf sein
Handy oder PDA, welches er auch zur Navigation zum jeweiligen Zielort benutzt. Aufträge
werden per Email, SMS oder Bringservice-Interface angenommen.

8 Entwurf
8.1 Modellierung
Dieser Abschnitt beschreibt das Gesamtsystem, wie es im Groben ausprogrammiert wer-

den könnte, um die Bedürfnisse aller Komponenten zu befriedigen. Die darauf folgenden
Abschnitte beschreiben, den Haushaltsmanager genauer. Um am Ende des Kapitels den
Grund der Gesamtsystemmodellierung zu verstehen, ist es notwendig alles aus der Vogel-
perspektive zu betrachtetn. Nur so erkennt man, wie der Haushaltsmanager eine Einpla-
nung der Lebensmittel anhand generierter Rezeptvorschläge durchführen kann. Die Mo-
dellierung besteht aus der Umgebungsbeschreibung anhand von Use-Case-Diagrammen.
Darauf folgen Zustands- und Aktivitätsdiagramme, um die Benutzerführung und Funk-
tionsumfang der einzelnen EMS-Bestandteile zu verdeutlichen. Auf Bildfolgediagramme
wurde verzichtet, da sie indirekt schon in den Zustandsdiagrammen enthalten sind. Ein
Kompositionsstrukturdiagramm zeigt alle Schnittstllen auf, die durch ein darauf folgendes
Klassendiagramm spezifiziert werden können. Schließlich folgt die detailierte Modellierung
der implementierten HHM-Funktionalitäten anhand von Sequenzdiagrammen und einem
Datenmodell-Faltplan im Anhang. Auf eine Benutzerauthentisierung wurde aus Übersichts-
und Redundanzgründen verzichtet, da sie im Familienalltag eher störend als nützlich ist,
was an Familiencomputern im Allgemeinen ersichtlich ist. Am Ende werden Testfälle abge-
leitet und der Objektfluß beschrieben. Das Klassendiagramm zeigt einen Gesamtüberblick
über alle Komponenten des EMS.
Abbildung 3: Fachklassendiagramm zur Übersicht

8 Entwurf
HHM-Client
Der Haushaltsmanager-Client beinhaltet die Rezeptplanung inklusive des Eintragens und

der Pflege von Rezepten. Kunden können ihre Grundnahrungsmittel anhand Menge/Zeit
(Skala) und Rezepte verwalten. Konfigurationen für Krankheiten oder Präferenzen sowie
für Budgetkontrolle und aktuelle/geplante Bestellungen können ebenfalls am HHM-Client
durchgeführt werden.
Abbildung 4: Use-Case HHM-Client

8 Entwurf
Abbildung 5: Zustandsdiagramm vollständige Möglichkeiten des HHM-Clients
Lieferanten-Clients
Den Lieferanten-Client kann entweder ein Webshopbetreiber, Großhändler oder ein Herstel-
ler an seine Bedürfnisse anpassen lassen. Er hat die Hauptaufgabe die Artikeldaten an den
EMS-Server zu übermitteln. Neben der Artikelaufbereitung, kann der Lieferant den gegen-
wärtigen, sowie den zukünftigen Absatz aufgrund der gegenwärtigen Zahlen, Aktionsange-
bote und Konfiguration ansehen. Die Konfiguration beinhaltet neben Vertragsdaten auch
die Konditionen, welche als Grundlage für seine Dienstleistungen gelten. Der Lieferanten-
Client zeigt dem Lieferanten, welche Bestellungen aktuell sind, sowie diejenigen, die in der
Vergangenheit ausgeführt wurden. Er kann anhand der vom EMS-Server übermittelten
Marktdaten seine Lieferkapazität an die Bedürfnisse des Marktes anpassen.

8 Entwurf
Abbildung 6: Use-Case Lieferanten-Client
Abbildung 7: Zustandsdiagramm vollständige Möglichkeiten des Lieferanten-Clients

8 Entwurf
EMS-Server
Folgende Modularisierung wird festgelegt:
Modul Dienste
HHM-IF aktuelle Bestellungen, Listenmanagement, Konfiguration
Lief-IF Marktdaten, Artikel, Forecast
BS-IF Bestellung, Packeteigenschaften, Abholort, Lieferort
Admin-IF Benutzerverwaltung, Sicherheit, Konfiguration
RegMNGR Registrierung, Vertragsmanagement
KonfMNGR Konfigurationsverwaltung
SecMNGR Logdaten, Intrusion Detection, Authentifizierung, Sicherung
BSTMNGR Ein- und Ausgang der Bestellungen
CALCMR Kalkulation von Mengenrabatten
PCKMNGR Paketierung von Bestellungen
LagerMNGR Eingang und Lagerung von Bestellungen
Jedes dieser Module wird im folgenden näher beschrieben. Zur Übersicht über die Gesamt-
anwendungsmöglichkeiten des EMS-Servers, wird an dieser Stelle auf das Entwurfsmuster
Fassade“ vorgegriffen. Sie beinhaltet alle Benutzerschnittstellen und koordiniert den Zu-
”
griff auf deren Dienste.

8 Entwurf
Abbildung 8: Use-Cases Fassade EMS-Server
Module und Schnittstellen des EMS-Servers Mit der Beschreibung der einzelnen Mo-
dule des EMS-Servers vertieft sich der Detailierungsgrad. Die einzelnen Interfaces werden
als Module beschrieben, da sie nicht nur eine Schnittstelle darstellen, sondern auch Benut-
zerspezifische Dienste anbieten. Die Zugriffe auf diese Dienste werden von einer Fassade
koordiniert.

8 Entwurf
HHM-IF Die Dienste des Haushaltsmanager-Interfaces bestehen hauptsächlich aus der

Bereitstellung von Konfigurations-, Bestell- und Listenmanagement. Das Konfigurations-
management besteht aus der Ansicht und Änderungen der Einstellungen. Die Einstellungen
sind automatisch bei der Registrierung des HHM-Clients auf dem EMS-Server gespeichert
worden. Das Bestellmanagement bietet dem Kunden an, einzelne Bestellungen sowie de-
ren Positionen einzusehen, kurzfristige Änderungen vorzunehmen und einzelne Positionen
zu stornieren, falls die Bestellung noch nicht vom EMS-Server bearbeitet wurde. Im Li-
stenmanagement kann der Kunde verschiedene Listen generieren lassen. Darunter fallen
Listen über den Budgetverbrauch, Bestellungen, Lieferanten oder Waren. Die Bestellungen
werden an den BSTMNGR weitergegeben.
Abbildung 9: Zustandsdiagramm Standardablauf HHM-IF

8 Entwurf
Lief-IF Das Lieferanten-Client-Interface hat neben den Konfigurationsaspekten, wie beim

HHM-IF die Hauptaufgabe, Aktionen des Lieferanten bekannt zu machen und Artikel des
Lieferanten in das System aufzunehmen. Dazu kommuniziert es mit dem BSTMNGR, der
die Aktionen auf eingehende Bestellungen umlegt, bis das Kontingent erschöpft ist. Das
Lieferanten-Client-Interface des EMS-Servers generiert auf Anfrage aktuelle Marktdaten,
wie sie in der Konfiguration zur Ansicht eingestellt wurden. Dazu werden alle benötigten
Optionen aus der Konfiguration geholt und eine allumfassende Abfrage generiert.
Abbildung 10: Zustandsdiagramm Standardablauf Lief-IF

8 Entwurf
BS-IF Das Bringservice-Interface gibt den Hauslieferanten die Möglichkeit, ihre Fahrten
zu verwalten. Dazu ist eine Auftragsliste einsehbar, in der alle noch nicht angenommenen
Fahrten mit Paketeigenschaften und Zielort erscheinen. Der Hauslieferant kann entweder
selbst eine Fahrt für sich annehmen, oder einen Lieferauftrag an einen seiner vorher kon-
figurierten Fahrer delegieren. Die Delegation übermittelt den Auftrag über eine in der
Konfiguration bestimmte Art an den jeweiligen Lieferdienst weiter. Der Hauslieferant kann
sich mittels einer Fahrplan-Ansicht einen Überblick über alle angenommenen Fahrten ver-
schaffen. Es werden Auftragsobjekte generiert, die vom Kunden oder einen Nachbarn zur
Bestätigung der Annahme mittels elektronischer Eingabe (wie bei modernen Paketdien-
sten) unterschrieben werden müssen. Am Ende eines jeden Werktages werden die Unter-
schriften über das Internet mit dem Bringservice-Interface als Beweis der Auftragserfüllung
synchronisiert. Das Bringservice-IF gleicht nach Fahrplanbearbeitung die Daten mit dem
BSTMNGR ab.
Abbildung 11: Zustandsdiagramm Standardablauf BS-IF

8 Entwurf
Admin-IF Um den reibungslosen Ablauf sowie die Sicherheit zu gewährleisten, benötigt

das System Administratoren. Dieser Benutzerkreis hat die Aufgabe Benutzer zu verwalten,
Plausibilitäten bei Verträgen, Daten und Diensten zu überprüfen sowie die Sicherheit des
Gesamtsystems zu kontrollieren. Der Administrator kann Benutzerdaten ansehen, bearbei-
ten und löschen. Das Administrations-Interface stellt dem Administrator mehrere Dienste
für Benutzerverwaltung, Systemverwaltung und Sicherheitsverwaltung zur Verfügung.
Abbildung 12: Aktivitätsdiagramm Standardablauf Admin-IF

8 Entwurf
RegMNGR Der Registrierungsmanager stellt eine ausgelagerte Funktionalität zur Au-

thentifikation und Betriebsmittelbereitstellung dar. Dabei stellt er je nach Benutzername
bestimmte Daten und Dienste für Bringservice, HHM-Kunden, Administratoren und Liefe-
ranten bereit. Jeder Systembenutzer muss sich für den Erhalt der Zugangsdaten beim Reg-
MNGR registrieren, bevor er das EMS nutzen kann. Die beiden Benutzergruppen Theke
und Service wurden bisher nicht erwähnt. Sie stellen Hilfskräfte dar, die zum reibungslo-
sen Ablauf des EMS in Bezug auf Lagerverwaltung, Paketierung, Vertragsanbahnung, etc.
benötigt werden. Sie sind nicht Gegenstand der Diplomarbeit und werden hier aufgrund
der Vollständigkeit aufgeführt.
Abbildung 13: Aktivitätsdiagramm Standardablauf RegMNGR

8 Entwurf
KonfMNGR Der Konfigurationsmanager hat die Aufgabe alle Konfigurationen zu ver-

walten. Darunter fallen alle HHM-, Lieferantenclient-, Bringservice- sowie Systemkonfigu-
rationen. Der Konfigurationsmanager sucht die bestpassende Konfiguration für spezifizierte
Kriterien/Anwendungen heraus. Kriterien können zum Beispiel Bioprodukte, Lieferkosten
oder Postleitzahelengebiete sein. Lieferkettenoptionen, Sicherheits- oder Systemeinstellun-
gen wären beispielsweise Systemanwendungen. Der Konfigurationsmanager verknüpft dabei
alle Kriterien mit möglichen Konfigurationen, die auf das Kriterium passen. Durch den Ver-
gleich der Konfigurationen, können die besten Möglichkeiten/Konditionen ermittelt wer-
den. Neben der Kapselung aller Konfigurationen des Systems und der User verschafft sich
der Konfigurationsmanager einen Überblick über alle bestehenden Konfigurationsmöglich-
keiten. Kommt eine mögliche Einstellung hinzu, fügt er sie an alle passenden Stellen zur
Kombination mit anderen Möglichkeiten automatisch ein.
Abbildung 14: Aktivitätsdiagramm Standardablauf KonfMNGR

8 Entwurf
SecMNGR Die Sicherheit des Systems überwacht der Securitymanager, der vom Re-
gistrierungsmanager authentisierte Benutzerdaten zur Überwachung der Aktivitäten vom
RegMNGR und Prozess-IDs vom IDS-System erhält. Er ist für die System-, Sicherheits- und
Benutzerlogs zuständig und übernimmt die Daten- und Zustandssicherungen der Server-
sowie der Clientdaten. Der Securitymanager nimmt in regelmäßigen Abständen eine Siche-
rung der Systemdaten und Zustände vor, loggt alle wichtigen Prozesse mit und überwacht
Dienste, Verbindungen sowie Datenübertragungen zu und von Clients. Es werden Sicher-
heitsrichtlinien anhand von Metasploit-Sicherheitsdatenbank 5 und einem IDS-System wie
zum Beispiel Prelude 6 definiert und zur Überwachung der User verwendet. Bei erkanntem
Verstoß gegen Sicherheitsrichlinien wird eine vorher festgelegte Aktion durchgeführt und
die IP-Aderesse des Verursachers, wenn möglich, gesondert protokolliert. Tritt ein weiterer
oder schwerer Verstoß mit dieser IP-Adresse auf, wird sie für drei Stunden vom System aus-
gesperrt. Die Sperrzeit verdoppelt sich bei jedem weiteren Verstoß. Nur der Administrator
kann diese Sperren aufheben. IP-Adressen unbekannter Provider, wie sie zum Beispiel bei
Anonymisierdiensten im Internet auftreten, werden sofort 24 Stunden ausgesperrt. Böse
Absichten sind bei anonymisierter Verwendung wahrscheinlicher und Benutzer mit weniger
Kenntnissen sollen von starken Restriktionen geschont werden. Schließlich übernimmt der
Securitymanager auch die Updates der Clients vor. Im Falle der Lieferanten-Clients kann
ein Update jedoch nur individuell durch einen Systemadministrator manuell erfolgen.
Abbildung 15: Aktivitätsdiagramm Standardablauf SecMNGR
5
http://www.metasploit.com/projects/Framework, www.heise.de/security/artikel/67984
6
http://www.prelude-ids.org

8 Entwurf
BSTMNGR Die Bestellungen des HHM-Clients werden direkt an das HHM-Interface ge-
schickt, das den Bestellmanager über das Eintreffen einer neuen Bestellung informiert.
Der Bestellmanager nimmt die Bestellungen an und speichert sie in der Datenbank ab. Er
legt Lieferantenaktionen auf Bestellungen um und übergibt die restlichen Artikel dem CAL-
CMNGR, der gleiche Artikel sammelt und Mengenrabatte berechnet. Nach der Berechnung
des aktuellen Mengenrabattes anhand der aktuellen Menge, wird dem Kunde der aktuelle
Preis jedes einzelnen Artikels anhand einer vorab Auftragsbestätigung mitgeteilt. Wird die-
se Auftragsbestätigung nicht innerhalb einer vom System festgelegten Zeit storniert, gilt
die Bestellung als angenommen und wird ausgeführt. Alle angenommenen Bestellungen
werden im Bringservice-Interface als bald eintreffender Auftrag geführt. Werden Aufträge
von den Bringdiensten ausgeführt, gleicht das Bringservice-Interface seine erledigten Auf-
träge mit dem BSTMNGR ab, der anschließend die Bestellhistorie des HHM-Interfaces, die
Bringservice-Liste sowie den Lagermanager aktualisiert. Trifft eine Sammelbestellung vom
CALCMR-Modul ein, wird diese an den Lieferanten übermittelt und auf Auftragsbestäti-
gung gewartet. Nach erfolgter Bestätigung wird der Lagermanager informiert.
Abbildung 16: Aktivitätsdiagramm Standardablauf BSTMNGR

8 Entwurf
CALCMR CALCMR bedeutet Kalkulation Mengenrabatte und stellt das Modul dar, wel-
ches das System finanziert und dem Kunden Geld einspart. Vom Bestellmanager kommen
Bestellungen an, die entweder schon aktiviert sind oder erst noch aktiviert werden. Jede
Position der Bestellung wird mit gleichen Positionen anderer Bestellungen aufsummiert,
bis die Obergrenze für die höchstmöglichen Mengenrabatte erreicht ist. Die Obergrenzen
werden von den Lieferanten-Clients festgelegt. Bei nicht aktivierten Bestellungen wird der
aktuelle Mengenrabatt zurückgegeben. Erst aktivierte Bestellungen mindern bei Erreichen
der Rabattgrenze den Preis des einzelnen Artikels. Durch die Aufsummierung der Bestellun-
gen entstehen Gesamtbestellungen, die an die Lieferanten geschickt werden, wenn entweder
der Maximalrabatt erreicht, oder die Lieferzeit nah ist. Um die Gesamtbestellungen wieder
auf einzelne Kundenbestellungen umzulegen, wird der PCKMNGR informiert wieviel von
welchem Artikel zu welcher Kundenbestellung gehört.
Abbildung 17: Aktivitätsdiagramm Standardablauf CALCMR
PCKMNGR Vom CALCMR-Modul und vom LagerMNGR nimmt der Paketmanager

Bestell- und Eingangspositionen entgegen. Stimmt die Bestellung mit dem Eingang nicht
überein, trägt der Paketmanager einen Verzugsvermerk in die Datenbank ein. Somit kann
ein Administrator oder Service-Mitarbeiter dem Verzug nachgehen. Die Hauptaufgabe des
Paketmanagers besteht darin, Listen mit Bestellungen und ihren Positionen zu erstellen
und diese für den Abruf bereit zu halten. Er stellt Pakete mit Identifikationsnummern zu-
sammen, übergibt sie dem Lagermanager und trägt sie in der Bringservice-Liste als Auftrag
ein. Einen vorher gemachten Zukunftsvermerk vom BSTMNGR wird dabei gelöscht. Vom
Lagermanager erhält der Paketmanager die Information, wo sich das Paket befindet, um es
der Auftragsannahme eines Bringdienstes mit angeben zu können. Mit dem Vermerk der
Bringservice-ID wird das Paket als abgeholt markiert.

8 Entwurf
LagerMNGR Die Hauptaufgabe des Lagermanagers besteht darin, freie Lagerplätze Pa-
keten für die Abholung zuzuordnen. Er verzeichnet Lagereingänge und teilt diese dem
PCKMNGR mit. Sind Gruppenbestellungen definiert, wird der dafür zuständige Bringser-
vice nach vollständiger Paketierung benachrichtigt.
8.2 Schnittstellenbeschreibung
Zur Beschreibung der Schnittstellen soll das Kompositionsstrukturdiagramm in Abbildung

18 dienen. Es stellt in erster Linie alle Klassen inklusive Kompositionen, Vererbungen und
internen Klassen dar und führt die Namen der Schnittstellen auf, die für das System imple-
mentiert werden müssen. In Verbindung mit dem nachfolgenden Klassendiagramm können
die Schnittstellen exakt hergeleitet werden. Die jeweiligen Klassenattribute werden mit
Getter- und Settermethoden in den Schnittstellenklassen gesetzt. Zum setzen des Attri-
buts ’ID’ in Klasse A, ist die Methode ’setID A()’ in der Schnittstelle zuständig. Soll das
Attribut ID der Klasse B gesetzt werden, ruft die Instanz der Klasse A die Methode ’se-
tID B()’ auf. Die Implementierungen aller Schnittstellen können mit diesem Gedankengang
einfach hergeleitet werden, wesshalb auf ein explizites Klassendiagramm für die Schnitt-
stellenbeschreibung verzichtet wird.
Das Kompositionsstrukturdiagramm legt die Grundlagen zur Verwendung von Entwurfs-
mustern und Kapselung. Man sieht, dass alle Klassen durch eine Schnittstelle gekapselt
sind und so leicht austauschbar, erweiterbar sowie flexibel wiederverwendbar bleiben, auch
wenn lange Zeit nicht mit dem Quellcode gearbeitet wird. Es gilt als Referenz für Übersicht
und Ordnung bei der Realisierung aller Systemkomponenten.

8 Entwurf
Abbildung 18: Kompositionsstrukturdiagramm zur Schnittstellenbeschreibung
8.3 Klassendiagramm
Das Klassendiagramm entspricht dem am Anfang dieses Kapitels zur Übersicht vorgestell-
ten Fachklassendiagramm. Der Unterschied liegt darin, dass im Klassendiagramm Attri-
bute, Methoden, Vererbungen und Kompositionen mit aufgeführt sind. Auch wurden die
Klassennamen in ein für Programmierer übliches, abgekürztes Englisch übersetzt. In Ver-
bindung mit dem Kompositionsstrukturdiagramm für die Schnittstellenbeschreibung, stellt
das Klassendiagramm die Hauptfunktionalitäten des Einkaufsmanagementsystems dar. Es
müsste lediglich ein weiteres Diagramm erstellt werden, das alle Attribute und Operatio-
nen mit Schnittstellen aufführt, um das gesamte Programmiergerüst vollständig aus dem
Diagramm generieren lassen zu können. Dazu müssen noch die einzelnen Methoden im-
plementiert werden, um das Gesamtsystem vollständig objektorientiert zu realisieren. Auf

8 Entwurf
die Zusammenführung beider Diagramme wurde verzichtet, da es wesentlich unübersicht-

licher ist und zur Illustration des Programmierumfangs sowie zur Übersicht zwei kleinere
Diagramme geeigneter erscheinen.
Abbildung 19: Klassendiagramm

8 Entwurf
8.4 Prozessketten
Abbildung 20 zeigt in einem erweiterten Prozesskettendiagramm die wichtigsten Prozes-

se des Gesamtsystems. Die grünen Prozessketten entsprechen den Vorgängen im HHM.
Blau sind die Prozesse des Zentralservers und rötlich sind die Vorgänge des Hersteller-
/Großhändler-/Webshop-Clients dargestellt. Neu ist hier auch der Begriff ’Metashop’ in
Verbindung mit dem HHM. Der Metashop stellt einen vom Zentralserver zur Verfügung
gestellten Webshop dar, in dem jeder HHM-Kunde einkaufen gehen kann. Er soll jedem
Kunden eine einheitliche Schnittstelle zum gesamten Markt bieten. Im Metashop sind al-
le Artikel enthalten, die der Zentralserver von Herstellern, Webshops und Großhändlern
zum Kauf anbietet. Damit ist eine Möglichkeit geschaffen, die Kauflust des Endkundens
zu befriedigen und gleichzeitig die Möglichkeit zu geben, sich über Produkte und Herstel-
ler zu informieren. Die Beschreibung der gelben Punkte veranschaulicht, wie die einzelnen
Bestandteile des EMS zur Kommunikation ineinander greifen.
Punkt 1 liegt zwischen Hersteller-/Webshop-Client und der EMS-Datenbank. Hier wer-

den die aufgearbeiteten Webshop- bzw. Hersteller-Artikeldaten zum Zentralserver über-
tragen. Die Zentralserverdatenbank bietet umfangreiche Informationen über den Markt,
Absatzmöglichkeiten und Statistiken, die der Hersteller-/Webshop-Client zur effizienten
Absatzplanung verwenden kann.
Punkt 2 liegt zwischen HHM und EMS-Datenbank. Hier wird eine Statistik des Lebens-
mittelverbrauchs, der Status, sowie der Zustand des HHM übertragen. Eine Art ’Heartbeat’
überprüft, ob es Probleme mit dem HHM-Client gibt. Sollte das System einmal ausfallen,
können Daten und Zustand des HHM-Clients aus der Zentralserver-Datenbank wieder her-
gestellt werden.
Punkt 3 bezeichnet die Verbindung zwischen Zentralserverfunktionen und der Zentralser-

verdatenbank. Hier werden Produktpreise anhand von temporären Tabellen automatisch an
die jeweilige Artikelmenge angepasst (Rabattkalkulation). Ein Trigger erhöht bei Eintreffen
einer Bestellung die Artikelmenge, die bei Erreichen eines bestimmten Wertes den Preis
in der Ursprungstabelle ändert. Produkt- und Bestelldaten werden erfasst und in Paketen
zusammengefasst. Es gibt Sammelbestellungen und Paketbestellungen, die der Lagerma-
nager verwaltet. Der Lagermanager ist dafür zuständig, allen Aufträgen einen Lagerplatz
zuzuordnen, die von einem Kundenauftrag wieder geräumt werden.

8 Entwurf
Abbildung 20: EPK-Diagramm
8.5 Entwurfsmuster
Entwurfsmuster sind überall zu finden. Selbst das derzeitige Konzept des EMS-Servers
könnte man als Entwurfsmuster hernehmen. Entwurfsmuster helfen das Problem zu über-
blicken. Sie zeigen anderen die Denkweise auf, die sich der Programmierer überlegt hat,
um ein Problem zu lösen. Viele bekannte Entwurfsmuster, wie die Fassade, die alle Schnitt-
stellen zusammenfasst, können verwendet werden, um die Programmierung übersichtlicher
zu machen und zu vereinfachen. In der J2EE-Welt werden überall Entwurfsmuster ver-
wendet. In der Regel gibt es Connection-Factory-Klassen, die Verbindungen zu anderen
J2EE-Systemen aufbauen, wie beispielsweise beim Java Messaging Service (JMS).

8 Entwurf
connectionFactory =
( ConnectionFactory ) jndiContext . lookup ( factoryName ) ;
...
connection = connectionFactory . createConnection ( ) ;
Session session =
connection . createSession ( false , Session . AUTO_ACKNOWLEDGE ) ;
...
Listing 1: JMS ConnectionFactory
In diesem Codelisting wird eine Verbindung zu einem Nachrichtenempfänger vorbereitet.

Die Verbindung kann z.B. neutral (Übergabeparameter ’false’) oder transaktionell sein
(abhängig von anderen Verbindungen). Hier können z.B. Daten von einer Datenbank in
eine andere Datenbank geschrieben werden. Man sieht, dass die Factory-Klasse damit einen
tieferen Sinn hat verschiedene Verbindungen mit ein und derselben Klasse herstellen zu
können.
Das Buch Ajax Design Patterns [Mahemoff 2006] enthält sehr viele Praxisbeispiele mit Pro-
blemstellung, Lösung und Entscheidungen beim Anwenden von Entwurfsmustern. Es zeigt,
wie vielseitig Entwurfsmuster jetzt schon Verwendung finden, in einer so jungen Webtech-
nologie, wie AJAX. Für Anfänger eignen sich die Bücher [GOF 2001] und [GOF2 1999]
sehr gut. Darin werden die Anfänge und die Entwicklung der Entwurfsmuster7 von den
Erfindern, der Gang of Four (GoF8), beschrieben.
Ajax Stub Frameworks9 beinhalten meist folgende Entwurfsmuster:
• Delegate
• Facade
• Procedure
• Proxy
• Remote
Die Entwurfsmuster realisieren die Ausführung von serverseitigem Quellcode, ohne sich Ge-
danken über Anfragesyntax, Fehlerbehandlung und Datenübertragung machen zu müssen.
Das Ziel ist, einen entfernten Prozeduraufruf anzustoßen, als wäre es eine lokale JavaScript-
Funktion. Dies erleichtert einen natürlichen Programmierstil.
7
Eine kurze Einführung in beide Bücher, sowie der GoF-Entwurfsmuster, ist unter http://www.fh-
augsburg.de/˜ hrk/Berichte/Entwurfsmuster Einfuehrung HRK 25.10.05.pdf einsehbar
8
http://de.wikipedia.org/wiki/Viererbande (Softwareentwicklung)
9
http://jpspan.sourceforge.net

9 Entwurf
Harry Fuecks, der Autor vom Ajax Stub Toolkit JPSpan zeigt in seinem Blog10 , wie er
einen einfachen Export, z.B. mit der Zeile
var ccNum = AJAX . getCreditCardNumber ( userID ) ;
Listing 2: Ajax Export
macht.
Im Einkaufsmanagementsystem werden einige dieser Entwurfsmuster enthalten sein. Selbst
der Prototyp des Haushaltsmanagers enthält beispielsweise das SAJAX Framework11 für
die Rezeptplanung. Es realisiert im Allgemeinen eine Drag and Drop-Funktionalität, dessen
Browserquelltext immer gleich ist, jedoch je nach Realisierungssprache, wie ASP, ColdFu-
sion, Perl, PHP, Python oder Ruby, verschiedene Proxy-Komponenten besitzt.
9 Abgrenzung
Die Diplomarbeit konzentriert sich auf den Haushaltsmanager, der als zentraler Bestandteil
des Einkaufsmanagementsystems den Anforderungen gerecht werden muss. Die Benutzer
entscheiden, ob der Haushaltsmanager den Anforderungen entspricht. Trotz der Komple-
xität soll es so einfach, wie möglich gemacht werden, mit dem System zu arbeiten. Das
Design muss ansprechend gestaltet werden, da das Risiko sehr hoch ist, dass Benutzer
aufgrund der äußeren Form den Umgang mit dem Haushaltsmanager meiden. Mit dem
Haushaltsmanager steht und fällt das gesamte System, daher sollten die wichtigsten Funk-
tionen ausprogrammiert werden. Die wichtigsten Teile sind vor allem die Rezeptplanung,
die Rezeptverwaltung und die Grundnahrungsmittelanpassung. Im Anschluß werden The-
men, wie Konfiguration, Bestellung und Kommunikation mit dem EMS-Server bearbei-
tet. Der Zentralserver ist ein wichtiger Bestandteil des EMS, sollte jedoch nur zweitran-
gig behandelt werden. Sinnvollerweise sollten Benutzerwünsche und Haushaltsmanager-
Erweiterungen bei der Implementierung des Zentralservers berücksichtigt werden, bevor
eine nachträgliche Funktionserweiterung Schwierigkeiten bereitet.
10
http://ajaxblog.com/archives/2005/05/25/a-grumpier-ajaxian
11
http://www.modernmethod.com/sajax

10 Implementierungstechnologien
Die Entscheidung, welche Technologie zum dynamischen Aufbau der Seiten zum Einsatz
kommen sollte, war schwerer als angenommen. Alle Aspekte gängiger Technologien wurden
gegeneinander abgewogen. So schied J2EE schon zu Beginn der Überlegungen, aufgrund
des hohen Entwicklungsaufwands aus. Java als Basissprache wäre aufgrund der Vielsei-
tigkeit, Umfang vorhandenen Quellcodes sowie der Quelloffenheit lukrativ, musste aber
schließlich PHP aufgrund seiner Einfachheit weichen. Die Auslagerung von Quellcode in
Java Beans (EJB) und die Vorkompilierung zum schnelleren Zweitabruf schienen auf den
ersten Blick praktisch, jedoch geht der Reiz beim Anwender für diese Technologien schnell
verloren. Bei einer hohen Anzahl an Beans, Servlets und verschachtelten Klassen fällt es für
Projekt-Neueinsteiger sehr schwer, sich im Quellcode zurecht zu finden und scheint ohne
aufwendiger Dokumentationsarbeit nicht sinnvoll möglich zu sein. Die J2EE-Technologien
sind mittlerweile Standard für große Webapplikationen geworden. Es erfordert jedoch viel
Erfahrung, die komplexen Entwurfsmuster und Abstraktionsschichten sinnvoll anzuwen-
den. Entweder man kann auf seine Erfahrung zurückgreifen und schon einmal verwendeten
Quellcode benutzen oder man muss sich mühsam durch alle fremden Muster durcharbeiten,
bis das Verständnis schließlich zu effizientem Quellcode führt. Letzteres ist natürlich das
Ziel, kann jedoch unter starkem Druck nicht realisiert werden. Stattdessen wird neu im-
plementiert, was zu Redundanz und Performanceverlust führt. Dieses allgemeine Problem
mit vorhandenem J2EE-Quellcode zu lösen, erfordert viel Zeit und führt am Ziel dieser
Diplomarbeit vorbei. Ein Server alleine, wird auf Dauer der Last an Anfragen mit hoher
Wahrscheinlichkeit nicht standhalten können, weshalb beim Zentralserver auf Skalierbar-
keit geachtet werden muss. Anders ist das beim Haushaltsmanager, der kaum Anfragen
von außen verarbeitet und zu einem Zeitpunkt nur von wenigen Benutzern bedient wird.
Hier kommt es mehr auf Geschwindigkeit, Zuverlässigkeit und Flexibilität an, weshalb PHP
besser geeignet erscheint.
Das Microsoft .NET Framework hat viele Vorteile bezüglich der Möglichkeiten mit dem
Quellcode (verschiedene, erweiterte Sprachen, gute Trennung zwischen Design und Lay-
out,..), ist jedoch im Gegensatz zu PHP und Java nicht plattformunabhängig. Sollte der
Haushaltsmanager als Embedded System in einen Kühlschrank eingebaut werden, wäre
man an Microsoft-Produkte gebunden. Freie OpenSource-Software wie beispielsweise Li-
nux als Webserver zu verwenden wäre damit nicht möglich. Für den Endverbraucher hätte
das zur Folge, dass der Haushaltsmanager in der Anschaffung teurer wäre.
PHP scheint für die Anforderungen das Haushaltsmanagers genau richtig zu sein. Schlank,
ressourcenschonend, performant, einfach und von der Entwicklergemeinschaft her, sehr er-
giebig. Allein mit Pear 12 steht jedem Entwickler eine nahezu endlose Sammlung an wieder-
verwendbarem OpenSource-PHP-Code frei zur Verfügung. AJAX und PHP mit MySQL-
Unterstützung stand damit zur Entwicklung des Haushaltsmanagers fest.
12
http://pear.php.net

Viel Zeit verstrich für die Entscheidung, welches AJAX-Framework am besten geeignet
ist. Es war notwendig, alle Funktionalitäten genau zu betrachten, um dann auswählen
zu können, welche Funktionalitäten abgedeckt werden können. Die Entscheidung fiel auf
Prototype aufgrund der einfachen Funktionsaufrufe, Dojo aufgrund der beeindruckenden
Effekte und SAJAX für die Drag and Drop-Funktionalität.
10.1 Werkzeuge
Auf den nächsten Seiten werden die drei Hauptwerkzeuge zur Programmierung des Haus-
haltsmanagers vorgestellt. Auch hier soll sich die Beschreibung nur auf die Entscheidungs-
gründe beschränken. Die meisten Werkzeuge verfügen über umfangreiche Einsatzmöglich-
keiten, deren vollständige Beschreibung ebenfalls am Ziel vorbeiführen würde.
Server2Go 1.3.0
Als einfache Möglichkeit der Portabilität, Installation, Konfiguration sowie der Flexibilität
ist die Entscheidung für den Webserver auf Server2Go13 gefallen. Dieser sich selbst konfigu-
rierende Webserver enthält prinzipiell alles, was ein WAMP oder XAMP-Server14 zur Verfü-
gung stellt (MySQL-Datenbank, Administrationsoberflächen, wie PHPMyadmin, Apache-
Webserver, PHP, etc.). WAMP, XAMP bzw. LAMP ist für alle gängigen Betriebssysteme
vorhanden und wurde entwickelt, um den Einstieg in die Webapplikations-Programmierung
für Einsteiger so einfach, wie möglich zu machen. Es handelt sich dabei um eine Softwa-
re, die eine vollständige Ablaufumgebung aller benötigter Programme zum lokalen Ablauf
und Test von Webapplikationen installiert. Server2Go stellt eine Weiterentwicklung der
WAMP/XAMP-Technologie dar, mit der man nicht einmal eine Installation vornehmen
muss. Nach dem Start, installiert und konfiguriert sich der Server selbst. Dadurch, dass
Server2Go auf WAMP aufbaut, ist die auszuführende Applikation ohne weiteres auch un-
ter LAMP (Linux Apache MySQL PHP) ablauffähig. Der lokale Rechner verfügt sofort
über eine MySQL-Datenbank, einen Webserver mit PHP-Interpreter sowie einer Admi-
nistrationsoberfläche zur Verwaltung der Datenbank mittels PHP. Lokale Administrati-
onsrechte sind für eine Installation nicht notwendig. Die Webapplikation ist sofort unter
http://rechnername:4001 im lokalem Netzwerk verfügbar.
Aptana IDE
Das IDE (Integrated Development Environment) Aptana15 ist eine sehr junge Entwick-
lungsumgebung, die speziell auf die Bedürfnisse von Frontend-Entwicklern zugeschnitten
13
http://www.server2go-web.de
14
http://www.wamp.de
15
http://www.aptana.com

ist. Ihren Ursprung hat sie in Eclipse, besitzt jedoch weitaus umfassendere Unterstützung
für JavaScript, HTML und CSS. Neben der sehr gut durchdachten Codevervollständigung,
der cleveren Anordnung der Fenster sowie der sehr hilfreichen Echtzeit-Fehler-Anzeige,
verblüfft Aptana mit der Unterstützung aller großen AJAX-Frameworks sowie mit einem
JavaScript-Debugging mittels einer eigenen Mozilla Firefox-Erweiterung. Obwohl Apta-
na derzeit Version 1.0 noch nicht erreicht hat (derzeit ist Version 0.31 beta aktuell),
macht die Entwicklungsumgebung einen sehr stabilen und fortschrittlichen Eindruck. Unter
www.aptana.tv werden viele Möglichkeiten visuell vorgestellt, die bisher in keinem ande-
ren Programmierwerkzeug enthalten sind. Neben Windows, gibt es Aptana für MAC OSX,
Linux und als Plugin für die Universal-IDE Eclipse. Die Weiterentwicklung ist sehr rasant.
Ist eine neue Version verfügbar, fragt die Entwicklungsumgebung ob sie installiert werden
soll. Ein paar Klicks später, wird Aptana mit erweiterten Funktionen neu gestartet.
Visual Paradigm
Dank Professor Kelch, der auf Visual Paradigm für UML hinwies und der Lizenz der Fach-
hoschule Augsburg, sind die Diagramme dieser Diplomarbeit mit Visual Paradigm for UML
Standard Edition Version 5.3 entstanden. Das UML CASE-Tool unterstützt alle Phasen
und Rollen im Softwareentwicklungsprozess, einschliesslich Software Ingenieure, System
Analysten, Business Analysten, Systemarchitekten und andere. Es ist entwickelt worden,
um komplexe Anwendungen durch den objektorientierten Ansatz effektiv zu unterstützen.
Der Funktionsumfang ist enorm und wird in Abbildung 21 angedeutet.
Abbildung 21: Funktionsumfang Visual Paradigm for UML
Es werden die aktuellen Standards der UML-Notation und Java unterstützt. Der voll-
ständige Round-Trip-Engineering“-Ansatz wird durch Code-Generierung aus den UML-
”
Diagrammen heraus, sowie durch das Reverse-Engineering“ für Java unterstützt. Der Auf-
”
wand für alle Phasen des Software-Lebenszyklus wird erheblich verringert, da der Übergang

von Analyse und Design zur Implementierung ohne Medienbrüche im CASE Tool realisiert
werden kann. Neben Eclipse werden viele IDEs, wie IBM WebSphere, Borland JBuilder,
NetBeans IDE, Sun ONE, IntelliJ IDEA, Oracle JDeveloper und BEA WebLogic Workshop
unterstützt.
Leider konnte der vollständige Round-Trip-Engineering“-Ansatz nicht getestet werden,
”
da zum einen die Standard Edition von Visual Paradigm for UML die Code-Generierung
nicht unterstützt, und zum anderen die Entwicklungsumgebung Aptana in Verbindung mit
AJAX und JavaScript-Quellcode zur Code-Generierung vermutlich nicht geeignet ist.
10.2 AJAX und die zugrunde liegenden Technologien
Im Prinzip ist AJAX eine Wiedergeburt von JavaScript. Microsoft erkannte als erstes,
dass JavaScript sehr viel nützlicher sein kann, da die Schnittstelle zum Document Object
Model (DOM)16 eine Bildschirmänderung ohne Seiten-Neuaufbau verspricht. Daraufhin
entwickelte Microsoft das ActiveX Objekt Microsoft.XMLHTTP in Zeiten des Internet
Explorers 5.0. Seine eigene API bietet eine Kommunikation mit dem Webserver, während
der Anwender die Webseiten betrachtet. Abbildung 22 zeigt den Unterschied zwischen einer
herkömmlichen Web-Anwendung und einer AJAX-Anwendung.
16
http://www.w3.org/DOM

Abbildung 22: Unterschied Klassisches Web-Modell und Ajax-Modell

Die sogenannten Gecko-Browser, wie Firefox und Netscape aber auch Safari und Opera
besitzen ein Objekt namens XMLHttpRequest, das die gleiche Funktionalität beherrscht.
Leider sind die beiden Schnittstellen unterschiedlich implementiert, wesshalb das W3C-
Konsortium zur Standardisierung von Webtechnologien einen Standardisierungsvorschlag17
gemacht hat.
Abbildung 23: XMLHttpRequest-Objekt
17
Quelle: http://de.wikipedia.org/wiki/XMLHttpRequest

Die Instanziierung dieses Objekts muss demzufolge den Internet Explorer sowie die Gecko-
Browser folgendermaßen berücksichtigen:
var xmlHttp = null ;
// M o z i l l a , Opera , S a f a r i s o w i e I n t e r n e t E x p l o r e r 7
if ( ! xmlHttp ) {
// I n t e r n e t E x p l o r e r 6 und a e l t e r
try {
xmlHttp = new ActiveXObject ( "Msxml2 . XMLHTTP " ) ;
} catch ( e ) {
try {
xmlHttp = new ActiveXObject ( "Microsoft.
XMLHTTP " ) ;
} catch ( e ) {
xmlHttp = null ;
}
}
}
if ( xmlHttp ) {
xmlHttp . open ( ’GET ’ , ’beispiel.xml ’ , true ) ;
xmlHttp . onreadystatechange = function ( ) {
if ( xmlHttp . readyState == 4){
alert ( xmlHttp . responseText ) ;
}
};
xmlHttp . send ( null ) ;
}
Listing 3: XMLHttp-Request

Document Object Model (DOM)
Um AJAX und JavaScript vollständig zu verstehen, ist es notwendig, tiefer einzusteigen,

und sich das W3C Document Object Model zu verinnerlichen. Dabei handelt es sich um eine
plattform- und sprachunabhängige Schnittstelle für den Zugriff auf XML- und XHTML-
Dokumente. Mit DOM kann dynamisch auf einzelne Elemente des Dokuments zugegriffen
werden, um sie auszuwerten, zu bearbeiten oder zu löschen. Realisiert wird dies durch die
Darstellung des Dokuments als hierarchisch geordnete Struktur, die wiederum eine korrekte
Anwendung bestehender Formate erfordert. Für den Zugriff eines Elements auf diese Weise
ist kein Neuladen der Seite erforderlich. Die Änderungen werden sofort dargestellt. Als
Schnittstelle zum Zugriff auf die Elemente einer Seite dient die Skriptsprache JavaScript,
welche im ECMA-262 Standard18 definiert ist.
JavaScript und Cascading Style Sheets (CSS)
CSS19 wurde entwickelt, um die Formatierung einer Webseite von der HTML-Struktur klar
zu trennen. Was anfangs als Style-Attribut für ein Element einer Webseite definiert wur-
de, ist über die Zusammenfassung aller Style-Attribute im Head-Teil jeder HTML-Seite,
mittlerweile in einer Datei ausgelagert und damit zu einem unverzichtbaren Bestandteil
moderner Webseiten geworden. Über DOM ist es somit beispielsweise möglich, den Datein-
amen der CSS-Datei auf der Webseite dynamisch auszutauschen. Damit wird das gesamte
Layout geändert, ohne die Seite neu laden zu müssen. Listing 4 zeigt, wie mit JavaScript
über Verwendung von DOM das Layout einer HTML-Seite geändert werden kann.
18
http://www.ecma-international.org/publications/standards/Ecma-262.htm
19
http://www.w3.org/Style/CSS/

// mit i d =”s ” im < l i n k >−Tag

function flipStyle ( ) {
if ( document . getElementById ( "s" ) . getAttribute ( "href" ) == "styleA .
css" )
{
document . getElementById ( "s" ) . removeAttribute ( "href" ) ;
document . getElementById ( "s" ) . setAttribute ( "href" , "styleB .css " ) ;
} else{
document . getElementById ( "s" ) . removeAttribute ( "href" ) ;
document . getElementById ( "s" ) . setAttribute ( "href" , "styleA .css " ) ;
}
}
// ohne id−A t t r i b u t e im < l i n k >−Tag

function flipStyle ( ) {
if ( document . styleSheets [ 0 ] . href == "styleA .css " )
document . styleSheets [ 0 ] . href == "styleB .css " ;
else document . styleSheets [ 0 ] . href == "styleA .css " ;
}
Listing 4: Stylesheet-Datei ändern
Seit der Veröffentlichung des css Zen Garden“-Projekts20 sollten die Möglichkeiten zur
”
Gestaltung einer Webseite mit CSS bekannt geworden sein.
JavaScript und objektorientierte Programmierung (OOP)
Anders als in der prozeduralen Programmierung ist es in der objektorientierten Welt wich-
tig, sich vorab Gedanken über das Zusammenspiel der einzelnen Objekte untereinander zu
machen. Der entscheidende Vorteil der OOP ist die Wiederverwendung einzelner Kompo-
nenten in neuen Projekten. Dies spart dem Entwickler Zeit und Kosten. Vor AJAX wurde
JavaScript meist als prozedural angesehen, ist jedoch von Beginn an objektorientiert ge-
wesen. Mit einfachen Änderungen in der Gewohnheit, sowie etwas tieferem Verständnis,
ist es möglich, alle objektorientierten Ansätze im Quellcode in JavaScript zu realisieren.
Der große Unterschied zu C++ und anderen objektorientierten Sprachen ist, dass es bei
JavaScript möglich ist, zu jeder Zeit, also auch während des Ablaufs, Methoden und Eigen-
schaften von Objekten zu ändern. Einer Instanz fügt man beispielsweise folgendermaßen
eine neue Methode hinzu:
20
http://www.csszengarden.com

objFoo . setFooValue = function ( val ) { this . val = val ; }

Listing 5: Objektmethode hinzufügen
Will man allen Objekten eine Methode hinzufügen, sollte man diese Methode direkt in
deren Klasse aufnehmen.
Object . prototype . ClsFoo . setFooValue = function ( val ) {

this . val = val ;
}
Listing 6: Klassenmethode hinzufügen
Object entspricht hier der Superklasse, von der alle anderen Klassen, wie beispielsweise
window oder document erben. Diese werden bei Browserstart selbständig instanziiert und
können über das window- bzw. document-Objekt zugegriffen werden. Alle Objekte sind
von der Superklasse Objekt abgeleitet, somit haben jetzt alle anderen Objekte, wie Ar-
rays, Strings, etc. die Methode ’setFooValue’ erhalten. Beim Hinzufügen von Methoden
in vorhandene Klassen, sollte sehr vorsichtig vorgegangen werden, um negative Nebenef-
fekte zu vermeiden. Es ist nicht empfehlenswert die Klasse Object zu ändern. Konkretere
Klassen sind dagegen besser geeignet, um mit einer allgemeingültigen Methode konkrete
Herausforderungen zu meistern.
Vorsichtig sollte man auch bei vorhandenen Klassen- und Methodennamen sein. Definiert
man Standard-Methoden um, wird der vorhandene Code überschrieben und es kommt
zur Ausführung des eigenen JS-Codes statt des eigentlichen Assembler-Codes, was enorme
Geschwindigkeitsnachteile nach sich ziehen kann.

Klassen in JavaScript
Objekte sind Instanzen von Klassen. Eine Klasse wird wie in Listing 7 definiert.
ClsFoo = function ( val )

{
// c o n s t r u c t o r
this . init ( ) ;
this . setFooValue ( val ) ;
}
Listing 7: Klasse definieren
Ein dazugehöriges Objekt wird in Listing 8 instanziiert.
// e r b t von O bj ect [ o p t i o n a l ]
ClsFoo . prototype = new Object ( ) ;
// I n i t i a l i s i e r u n g
ClsFoo . prototype . init = function ( )
{
val =0;
}
//Wert s e t z e n
ClsFoo . prototype . setFooValue = function ( val )
{
this . val=val ;
}
// Objekt e r z e u g e n
objFoo = new ClsFoo ( 1 ) ;
//Wert ausgeben
alert ( objFoo . val ) ;
Listing 8: Objekt definieren
Auf Eigenschaften von Objekten kann mit dem ’.’-Operator zugegriffen werden. Die Ob-
jekteigenschaft ’prototype’ stellt eine elegante Möglichkeit dar, neue Eigenschaften und
Methoden einem Objekt zuzuweisen. Wie oben schon erwähnt, ist es dabei nicht notwen-
dig, eine neue Methode bereits in der Klasse zu definieren. Die Zuweisung erfolgt direkt,

ohne die Hauptklasse verändern zu müssen. Bei großen Projekten ist dies ein sehr interes-
santer Vorteil, da somit Entwurfsmuster über mehrere einzelne Dateien hinweg einfacher
entwickelt werden können.
Literale
Literalobjekte21 wurden mit JavaScript 1.2 eingeführt und wurden in ECMAScript v3 spe-
zifiziert. Sie sind das Pendant zu C++ -Strukturen22 (struct) und werden in Listing 9
veranschaulicht.
var LitFoo = {
pid : "1" ,
vname : "bar" ,
name : "foobar " ,
rgb : {r : 2 5 5 , g : 0 , b : 0 } // Array
getPid : function ( ) { alert ( this . pid ) }
};
Listing 9: Literalobjekt
Im Prinzip handelt es sich hierbei um einen zusammengesetzten Datentypen, der sich recht
übersichtlich darstellt. Literalobjekte können beliebig tief verschachtelt werden und nu-
merische Werte als Eigenschaften aufweisen. Numerische Werte als Namen sind jedoch
ungültig. Literale lassen sich beliebig mit anderen Literalen und Objekten verschachteln,
wodurch mächtige und komplexe Strukturen entstehen können.
21
http://developer.mozilla.org/en/docs/Core JavaScript 1.5 Guide:Literals
22
http://www.willemer.de/informatik/cpp/struct.htm

JSON
JSON23 steht für JavaScript Object Notation“ und stellt sowohl für Menschen als auch für
”
Computer ein gut lesbares Format dar. JSON ist dank zahlreicher Portierungen in C/C++,
C#, Java, Perl, PHP und Phyton verwendbar, obwohl es ursprünglich für den Datenaus-
tausch in JavaScript gedacht war. Die Portierungen erleichtern den Datenaustausch mit
anderen Programmiersprachen.
Aufgrund der Effizienz und der gut lesbaren Datenstruktur stellt JSON eine gute Alter-
native zu XML24 dar. JSON ist leichter zu parsen und durch die kleinere Datenmenge
auch schneller in der Anwendung, als XML. Daher wird oft AJAX statt XML in AJAX-
Bibliotheken verwendet. Realisiert wird JSON durch die Anwendung von Literal-Objekten.
Listing 10 verdeutlicht den Unterschied zwischen JSON und XML:
var records = {
"data" : [
{
"Name" : "Ajax" ,
"VName " : "mit " ,
"Tek" : "JSON" ,
},
{
"Name" : "Ajax" ,
"VName " : "mit " ,
"Tek" : "XML "
}
]
};
<data>
<item>
<name>Ajax</name>
<vname>mit</vname>
<tek>JSON</tek>
</item>
<item>
<name>Ajax</name>
<vname>mit</vname>
<tek>XML</tek>
</item>
</data>
23
http://www.crockford.com/JSON
24
http://www.xml.com

Listing 10: Unterschied JSON - XML
In diesem Beispiel sieht man deutlich, dass die XML-Variante fast doppelt so groß wie
JSON und auch aufwändiger zu erzeugen ist. In Listing 11 soll der einfache Umgang mit
JSON verdeutlicht werden.
// Datenausgabe
for ( var i in records . data ) {
with ( records . data [ i ] ) {
document . write ( name+" , "+vname+" , "+technik+"<br
/>" ) ;
}
}
// Hinzufuegen von r e c o r d s
records . data [ records . data . length ] = {
"name" : "Neuer Name" ,
"vname " : "Neuer Vorname " ,
"tek " : "JSON"
}
//JSON−S t r i n g i n Objekt wandeln

var jsonobj = eval ( ’(’ + string + ’)’ ) ;
// Oder s i c h e r e r
var jsonobj = JSON . parse ( string ) ;
//JSON−Objekt i n s t r i n g wandeln
var jsonstr = JSON . stringify ( jsonobj ) ;
Listing 11: Umgang mit JSON
Beim Hinzufügen wird mit der Eigenschaft ’length’ die Größe des aktuellen Arrays er-
mittelt und der neue Datensatz an das Ende eingefügt. Beim Umwandeln von Strings in
JSON-Objekte sollte aus Sicherheitsgründen25 ’parse()’ verwendet werden, da sonst jeder
Ausdruck in ausführbaren Code umgewandelt werden kann. Zahlreiche Erweiterungen26
vereinfachen und unterstützen den Umgang mit JSON, wie anfangs erwähnt, auch in an-
deren Sprachen.
25
So gefährlich ist eval() auch nicht, man muss es nur richtig anwenden
26
php-json: http://www.aurore.net/projects/php-json
JSON-PHP: http://mike.teczno.com/json.html
PEAR HTML AJAX: http://pear.php.net/package/HTML AJAX/

JSON-RPC
Zur Übergabe komplexer Objekte über das Internet eignet sich JSON-RPC27 aufgrund
seines geringeren Datenvolumens besser als XML. Das SOAP (Simple Object Access Pro-
tocol), das in Verbindung mit XML Anwendung findet, eignet sich nur für Clients, die auf
ein WSDL (Web Services Description Language) zurückgreifen können. Die aufwändige
Entwicklung auf der Server-Seite wird damit erschwert, dass sich nativ nicht jeder Browser
mit einem SOAP-basierten Web Service verbinden kann. Zur Datenübertragung zwischen
HHM und Zentralserver fiel die Entscheidung daher auf JSON-RPC statt auf XML. Listing
12 zeigt, wie ein JSON-RPC-Request aussieht.
// P r o z e d u r a u f r u f mit HTTP POST

POST / myservice HTTP / 1 . 1
User−Agent : Wget / 1 . 6
Host : www . beispiel . de
Content−Type : application/ json
Content−Length : 1 8 1
Accept : application / json
{
"version " : "1.1 " ,
"method " : "sum " ,
"params " : [ 1 7 , 2 5 ] // h i e r wird e i n Array−Objekt ü
berg eben
}
// P r o z e d u r a u f r u f mit HTTP GET

GET / myservice/sum ? a=17&b=25 HTTP / 1 . 1
User−Agent : Wget / 1 . 6
Host : www . beispiel . com
Accept : application / json
Listing 12: JSON-RPC-Request
Im HTTP-Header muss ’User-Agent’ definiert sein. Bei POST werden die Aufrufparameter
im Body der HTTP-POST Nachricht übertragen. Neben der Version und Methode muss
auch ’Content-Type’ spezifiziert sein und sollte ’application/json’ enthalten. Wogegen bei
GET die Aufrufparameter nach RFC 398628 im Request-URI29 der HTTP-Nachricht über-
tragen werden und ’Accept’ mit ’applictation/json’ spezifiziert sein muss. ’Content-Length’
27
http://json-rpc.org
28
tools.ietf.org/html/rfc3986
29
http://de.wikipedia.org/wiki/Uniform Resource Identifier

muss bei beiden Übertragungsarten angegeben werden und nach den Richtlinien und Re-
geln der HTTP-Spezifikation30 gesetzt werden.
Nach einem Remote-Prozeduraufruf erfolgt die Nachricht, ob die Anfrage erfolgreich war
oder nicht. War der Aufruf erfolgreich, wird mit der Antwort des Prozeduraufrufs der
Status-Code ’200’ zurückgegeben. Kommt der Status-Code ’500’ (Internal Server Error)
zurück, könnte das folgende Gründe haben:
• Fehler beim Parsen des JSON-Textes

• Prozedur auf dem Server unbekannt (Bei HTTP GET sollte hier ’404’ (Not Found)
zurückgegeben werden
• Prozedur konnte nicht ausgeführt werden (Meist aufgrund fehlender Übergabepara-
meter)
• Prozedur-Fehler während der Ausführung
Wie ein Prozedur-Rückgabeobjekt aussehen kann, wird in Listing 13 gezeigt.
// E r f o l g r e i c h e r P r o z e d u r a u f r u f
HTTP / 1 . 1 2 0 0 OK
Connection : close
Content−Length : 2 3
Content−Type : application/ json
Date : Sat , 0 8 Mar 2 0 0 7 1 2 : 0 2 : 4 8 GMT
Server : Apache / 1 . 3 . 3 5
{
"version " : "1.1" ,
"result " : 42
}
//JSON−RPC Error −Objekt

{
"version " : "1.1 " ,
"error " : "JSONRPCERROR " ,
"code" : 1 2 3 , //muss zwischen 1 0 0 und 9 9 9 l i e g e n
"message " : "Fehler beim Parsen des Requests - Objekts
aufgetreten!" ,
"error " : {
"name" : "JSONError" ,
"message " : "Bad array " ,
30
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4

"at" : 42 ,
"text" : "{\" id \":1 ,\" method \":\" sum \",\" params
\":[1 ,2 ,3 ,4 ,5} "}
}
}
Listing 13: JSON-RPC-Response

Zur Veranschaulichung, wie JSON-RPC in Verbindung mit PHP funktioniert, soll das fol-
gende Codebeispiel in Listing ?? dienen.
<?php
//PHP Autoload−Handler zum Nachladen ö b e n t i g t e r K la ssen

function__autoload ( $class ) {
require_once ( dirname ( __FILE__ ) ’./’ . strtolower ( basename (
$class ) ) . ’.php ’ ) ;
}
// v o r b e r e i t e n der Antwort
$response=new stdClass ;
//JSON aus POST−Request l e s e n

try {
$payload =json_decode ( file_get_contents ( ’php :// input ’ ) ) ;
// Methode vorhanden ?
if ( ! isset ( $payload−>method ) ) | | empty ( $payload−>method ) {
// throw new E x c e p t e i o n . . . k e i n e methode
}
// Als Trenner zwischen K l a s s e und Methode d i e n t ’:: ’

if ( strpos ( $payload−>method , ’::’ )===false ) {
// throw new Except io n . . . k e i n e K l a s s e
}
//JSON−Methode i n Z i e l k l a s s e und Methode a u f s p a l t e n

list ( $class , $method )=explode ( ’::’ , $payload−>method , 2 ) ;
// K l a s s e i n s t a n z i i e r e n , Laden e r f o l g t durch autoload ()

$obj = new $class ( ) ;
// Kennt K l a s s e ügewnschten Methodenaufruf ?

if ( ! is_callable ( array ( $obj , $method ) ) ) {
// throw new Except io n . . . Methode unbekannt
}
// Methode a u f r u f e n , Parameter w e i t e r r e i c h e n
if ( ! call_user_func_array ( array ( $obj , $method ) , $payload−>params ) )
{

// throw new E x c e p t e i o n . . . Auf r uf f e h l g e s c h l a g e n

}
// E r g e b n i s aus P u f f e r i n R esult−Property s i c h e r n
$response−>result=$obj−>buffer ;
} catch ( Exception $e ) {
// F e h l e r o b j e k t e r s t e l l e n , Daten aus Except io n ü bernehmen
...
$response−>error=$error ;
}
// Request−ID mitnehmen
$response−>id=$payload−>id ;
// Gzip Kompression a k t i v i e r e n
ob_start ( "ob_gzhandler" ) ;
//JSON−Antwort ausgeben
echo json_encode ( $response ) ;
?>
Listing 14: JSON-RPC-Server
Listing 14 zeigt, wie ein JSON-RPC-Request ein JSON-Objekt übergibt und dieses Objekt
mittels PHP geparst wird. Es werden benötigte Objekte erzeugt, Methoden dieser Objekte
mit den übergebenen Parametern aufgerufen und ein JSON-RPC-Response-Objekt zurück-
geliefert. Da dieses Verfahren wesentlich schneller und einfacher zu implementieren ist, als
die Realisierung eines Webservices mit XML-RPC und SOAP, wird es beispielsweise für die
Übertragung von Bestellungen, Statusinformationen und Statistiken zwischen HHM und
Zentralserver verwendet.

10.3 Javascript Libraries
Unter Libraries versteht man eine Sammlung von Funktionalitäten und Routinen für be-
stimmte Aufgaben. JavaScript-Bibliotheken31 werden zum großen Vorteil für Projekte,
überwiegend kostenlos angeboten. In anderen Programmiersprachen, wie VB, C++ oder
Delphi, ist dies nicht der Fall. Der einfache Umgang mit den Bibliotheken erleichtert zudem
den Einstieg in die Ajax-Programmierung.
JavaScript-Bibliotheken sind folgendermaßen leicht in vorhandene HTML-Seiten zwischen
<HEAD> und </HEAD> einzubinden. Listing 15 führt hierzu ein Codebeispiel auf.
<script src=" prototype.js" type="text/ javascript"></script>

Listing 15: Bibliotheken einbinden
Dabei ist die Einbindung mehrerer Bibliotheken auf einer Seite möglich, wenn Methoden
und globale Variablen nicht den selben Namen haben und sich nicht gegenseitig überschrei-
ben (Gültigkeit und Sichtbarkeit). Im Falle gleicher Namensgebungen, ist es notwendig
kleine Anpassungen an den Bibliotheken vorzunehmen. Dabei kann eine Entwicklungsum-
gebung mit JavaScript-Debugging-Funktionalität, wie das oben beschriebene Aptana, sehr
nützlich sein.
Typische Aufgaben von JavaScript-Bibliotheken bestehen darin, eine Schnittstelle zum
XMLHttpRequest-Objekt zu bieten und mittels DOM Manipulationen und visuelle Ef-
fekte zu erzeugen. Mit der Nutzung von Bibliotheken können wiederkehrende Aufgaben
schnell und effizient gelöst werden. Im folgendem werden einige wenige, aber sehr nützliche
Funktionen der Ajax-Bibliotheken ’Prototype’ und ’Dojo’ vorgestellt.
Prototype
Prototype32 ist ein sehr mächtiges JavaScript Framework, das Objektorientierung mit-
tels Literalschreibweise ermöglicht. Viele Features unterstützen den Programmierer bei
der Erstellung von aufwändigen Effekten in anspruchsvollen Programmen. Prototype be-
steht aus mehreren einzelnen Skripten, die in der Datei ’prototype.js’ zusammengeführt
werden. Jedes Skript beinhaltet eine eigene Funktionalität, welche die Gesamtfunktioali-
tät von prototype ergänzt. Neben AJAX.Request, zur Rückgabe und Ausführung eines
HTTP-Requests und Ajax.Updater, das eine ganze XHTML-Seite zurück gibt, sind die $()
Shortcut-Funktion, in Listing 16 sehr nützlich.
31
http://ajaxian.com/resources
32
http://prototype.conio.net

var e = $ ( "time" ) ;
alert ( e . style . color ) ;
// i s t g l e i c h b e d e u t e n d mit
var e = document . getElementById ( "time" ) ;

alert ( e . style . color ) ;
Listing 16: Prototype Shortcut-Funktionen
Durch diese und andere Funktionen in Prototype, wird die Programmierung mit JavaScript
deutlich vereinfacht.
Dojo
Das JavaScript Toolkit Dojo33 ist durch seine grafischen Effekte sehr beliebt. Es bietet eine
umfangreiche Widget-Sammlung und ein einfach einzusetzendes Event-System. Einzelne
Funktions-Pakete sind dynamisch nachladbar oder in eine große Datei einfügbar. Dojo ist
eine reine JavaScript-Bibliothek und besitzt leider nur eine schlechte Dokumentation. Li-
sting 17 zeigt, wie einfach Pakete nachladbar sind.
dojo . require ( "dojo.io.IframeIO" ) ;

Listing 17: Dojo Paketverwaltung
Damit ist beispielsweise ein IFrame IO-Transport34 möglich, der das Heraufladen von Da-
teien auf den Webserver ermöglicht.
33
http://dojotoolkit.org
34
http://alex.dojotoolkit.org/?p=528

11 Implementierung des HHM-Clients

Folgende Funktionalitäten entsprechen den Hauptpositionen eines Pflichtenheftes mit be-
gründeter Reihenfolge der Implementierung. Auf ein extra Pflichtenheft wurde aus Red-
undanzgründen verzichtet. Die Funktionalitäten werden anhand Sequenzdiagrammen und
Bildfolgen veranschaulicht.
11.1 Rezepte eintragen
Abbildung 24: Sequenzdiagramm Rezepte eintragen
Das Eintragen von Rezepten stellt eine wichtige Grundfunktionalität zur Erweiterung der
HHM-Datenbank mit eigenen Hausrezepten dar und erfolgt in zwei Schritten. Im ersten
Schritt gibt man allgemeine Informationen über das Rezept ein. Die virtuelle Tastatur kann
dazu durch Auswählen des Tastatursymbols aktiviert werden. Ist die virtuelle Tastatur ak-
tiviert, wird sie beim Fokussieren eines Eingabefeldes angezeigt. Die virtuelle Tastatur ist in
JavaScript implementiert und wird benötigt, wenn beispielsweise beim Touchscreen-Betrieb
des HHM keine Tastatur und kein Windows Vista vorhanden ist. Neben der virtuellen Ta-
statur kann eine angeschlossene Tastatur ebenfalls bedient werden. Damit die Konsistenz in

der Datenbank gewahrt bleibt und dem Benutzer möglichst viel Tipparbeit erspart bleibt,
werden die Einträge der meisten Felder aus Dropdown-Listboxen ausgewählt.
Abbildung 25: Rezept eintragen Schritt 1
Mit einem Klick auf die Drucktaste ’weiter’, kommt man zu Schritt zwei, in der die Zutaten
eingetragen werden. Durch einen Klick auf den Pfeil nach unten, können alle vorherigen
Eingaben zur Überprüfung ein- und ausblenden. Sollte ein Fehler aufgetreten sein, kann
man zur Korrektur mit dem Pfeil nach links zurück zum ersten Schritt gehen. Die Eingaben
des ersten Schritts gehen dabei nicht verloren.

Abbildung 26: Rezept eintragen Schritt 2
Trägt man eine Zahl für weitere Zutaten in das vorgesehene Feld ein und drückt auf ’ok’,
wird diese Anzahl Zeilen der Eingabetabelle hinzugefügt. Nimmt man für die Eingabe der
Zutaten die virtuelle Tastatur zur Hilfe, kann man mit der Pfeiltastetaste ’=>’ von Einga-
befeld zu Eingabefeld springen. Die Felder Preis bis Markt müssen nicht ausgefüllt werden.
Sie sind mit aufgeführt, um Zutaten genauer zu spezifizieren, wenn man bestimmte Präfe-
renzen benötigt (Krankheit) oder bewusst (Preis/Bio/Gentechnik) ausgewählt werden.

Abbildung 27: Rezept eintragen Schritt 2.1
Nach Angabe aller Zutaten wird das Rezept durch einen Klick auf ’weiter’ in die Datenbank
eingetragen. Zur Bestätigung, Kontrolle und Abfrage, was als nächstes getan werden soll,
wird Abbildung 28 angezeigt.

Abbildung 28: Rezept eintragen Schritt 2.2

11.2 Rezeptliste
Abbildung 29: Sequenzdiagramm Rezeptliste
Sind die Eintragungen vorgenommen, kann man sich die Rezeptliste anzeigen lassen. Mit
einem Klick auf den grünen Pfeil am Anfang jeder Zeile, kann man die Zutatenliste eines
Rezeptes auf- und zuklappen. Möchte man ein bestimmtes Rezept suchen, kann man die
Suchkriterien im Aufklappmenü des Tabellenkopfes auswählen und auf ’ok’ klicken. Die
Liste wird damit entsprechend den ausgewählten Kriterien neu aufgebaut. Die Kriterien
entsprechen den Eintragungen in der jeweiligen Datenbank-Spalte. Sind aufgrund ungünsti-
ger Kombination ausgewählter Kriterien keine Datensätze vorhanden, wird die Liste (ohne
Fehlermeldung) leer angezeigt.

Abbildung 30: Listenansicht
Wählt man ein Rezept durch einen Klick auf den Rezeptnamen aus, so wird die Rezeptan-
sicht angezeigt.

Abbildung 31: Rezeptansicht
Mit einem Klick auf das jeweilige Symbol in der grünen Kopfzeile, kann das Rezept ausge-
druckt oder gelöscht werden. Ändert man die Personenanzahl über der Zutatenliste, werden
die Mengenangaben der Zutaten automatisch angepasst.

11.3 Grundnahrungsmittel anpassen
Abbildung 32: Sequenzdiagramm Grundnahrungsmittel anpassen
Wählt man ’Haushalt’ aus dem Hauptmenü aus, werden 12 Kategorie-Symbole angezeigt.
Darunter sind alle erdengklichen Waren im Haushalt enthalten. Wählt man eine Kategorie
per Klick auf das jeweilige Symbol aus, wird eine Skala mit allen im Haushalt befindlichen
Waren und ihren Füllständen angezeigt. Die rote Markierung im blauen Balken zeigt die
im Haushalt gegenwärtige Menge an. Das Feld neben dem Balken beziffert die Mengen-
angabe. Verschiebt man die rote Markierung, ändert sich auch die Mengenangabe. Damit
ist es möglich, alle Lebensmittel und Verbrauchsgüter im Haushalt ohne Tipparbeit sehr
einfach aktuell zu halten. Aufgrund des Umfangs an möglichen Artikel im Haushalt, wurde
die Lebensmittel-Anpassung nur beispielhaft dargestellt. Die Datenbank diesbezüglich mit
Daten anzureichern hätte zu lange gedauert. Die Zeit kam der viel wichtigeren Mahlzeit-
planung zugute.

11.4 Mahlzeiten planen
Abbildung 33: Sequenzdiagramm Mahlzeiten planen
Wird im Hauptmenü ’Planen’ gewählt, erscheint der Kalender, der alle bisher geplanten
Mahlzeiten enthält.

Abbildung 34: Kalender
Pro Tag können derzeit zwei Mahlzeiten eingeplant werden. Anhand der Symbole erhält
man Auskunft, um was für eine Mahlzeit es sich handelt. Bleibt man mit der Maus über
einem Symbol stehen, wird der Name und die Bezeichnung der Mahlzeit angezeigt. Um eine
Mahlzeit einzuplanen, klickt man auf das Stift-Symbol. Daraufhin wird ein neues Fenster
mit der Rezeptliste geöffnet. Aus der Rezeptliste wird ein Gericht per Klick auf den Rezept-
namen ausgewählt und es wird die Rezeptansicht angezeigt. Unterhalb des Rezeptnamens
wird eine große Schrift angezeigt ’Mahlzeit einplanen/ersetzen’, womit das Gericht, nach
Bestätigung im Kalender erscheint.

Abbildung 35: Mahlzeit einplanen
Realisiert ist dies durch eine variantenreiche Parameterübergabe für die Rezeptansicht.
Will man beispielsweise eine Mahlzeit aus der Planung löschen, klickt man auf das Symbol
des Gerichts im Kalender. Es erscheint die Rezeptansicht mit der großen Schrift ’Mahlzeit
aus Planung entfernen’, woraufhin nach Bestätigung der Kalender ohne dieses Gericht neu
aufgebaut wird.
11.5 Einkaufsliste
Wählt man im Menü ’Einkaufsliste’, erscheint eine Eingabemaske, mit der man den Zeit-
raum angeben kann, für den die benötigten Rezeptzutaten besorgt werden sollen.

Abbildung 36: Einkaufslisten-Zeitraum
Klickt man auf die Drucktaste ’generieren’, erscheint eine druckbare Einkaufsliste, in der
auch die Mengenangaben jeweils durch Angabe der Personenzahl geändert werden kön-
nen. Damit ist es möglich, auf Planänderungen bei Bestellbestätigung zu reagieren, falls
beispielsweise der Besuch kurzfristig absagt.

Abbildung 37: Einkaufsliste
Damit wären die wichtigsten Funktionen des HHM erläutert. Weitere Informationen sind
der Dokumentation auf der inliegenden CD-Rom sowie dem Programm während der Aus-
führung entnehmbar.

11.6 Datenbank
Der Umgang mit der Datenbank ist in einer Datei namens ’dbin.php’ gekapselt. Mit Über-
gabeparametern wird in ein Switch-Case-Konstrukt verzweigt, dessen Fälle den Quellsei-
tennamen entsprechen. Anhand dieser Methodik ist es leicht zu erkennen, welcher Abschnitt
des Konstruktes für welche Seiten zuständig ist. Jeder Zweig des Konstrukts enthält ver-
schiedene DML-Statements, die je nach übergebenen Parametern Änderungen am Daten-
bestand vornehmen. Der Überblick, über die Auswirkungen einer Änderung an einer Seite
blieb damit stets erhalten.
Das Datenmodell der EMS-Datenbank befindet sich als Faltplan im Anhang. Darin wird
die Funktionalität des EMS nocheinmal abgebildet. Das Datenmodell soll nicht nur zeigen,
wie die Datenbasis der Klassen und Methoden organisiert ist, sondern soll Unklarheiten
im Zusammenhang mit der Gesamtfunktionalität des EMS beseitigen. Umfangreiche Me-
tainformationen sind mit schwarzen Pfeilen an die Objekttypen angefügt, um deutlich zu
machen, welche Daten darin gespeichert werden. Zahlen neben Objekttypen deuten auf
besondere Funktionen und getriggerte Funktionalitäten hin. Die Farbgebung soll zeigen,
welche Objekttypen, für welchen Teil des EMS zuständig sind. Dabei steht grün für die
Funktionalitäten des HHM und blau für die Funktionalitäten des Zentralservers. Die grünen
Objekttypen mit blauen Rändern sollen verdeutlichen, dass die gleichen Tabellen sowohl
in der HHM- als auch in der Zentralserverdatenbank verwendet werden. Schließlich gibt es
noch die blaue Farbgebung mit rötlichen Rändern, die darauf hindeutet, dass die Tabellen
in den EKM-, Zentralserver-, Hersteller- und Webshop-Clientdatenbanken enthalten sind.
Eine kurze Einführung in die Notation des Datenmodells, soll das Verständnis erleichtern,
die Zusammenhänge leichter erkennen lassen und letztendlich zu tieferem Verständnis der
Funktionalitäten des EMS führen.
Die Rauten im Datenmodell stellen Assoziationstypen dar, die durch bezeichnete Beziehun-
gen mit Objekttypen verbunden sind. Die Objekte, die einen Assoziationstyp beinhalten,
sind objektifizierte Assoziationstypen. Sie stellen hier die Tabellen der Datenbank dar.
Die Objekte um den objektifizierten Assoziationstypen herum, stellen die Spalten der Da-
tenbanktabellen dar, deren Spaltennamen unter den Kardinalitäten der Beziehungslinien
stehen. Die Kardinalität ’0’ bedeuet, dass die Spalte in der Datenbank mit ’NULL’ belegt
werden kann, also im Datensatz nicht zwingend gesetzt werden muss. Die Kardinalität ’1’
hingegen bedeutet, dass der Wert gesetzt werden muss. Die Kardinalität ’n’ deutet dar-
auf hin, dass es mehere Datensätze geben kann. Gelesen wird eine Kardinalität von Typ
zu Typ aus beiden Richtungen. Objekte können von anderen Objekten erben, was durch
einen Pfeil zwischen zwei Objekten symbolisiert ist. Objektifizierte Assoziationstypen ha-
ben Attributobjekte und stehen in kardinalitätsspäzifischen Zusammenhang mit anderen
Objekten. Hat der Assoziationstyp einer objektifizierten Assoziation eine Beziehung zu
einem anderen Objekt, bedeutet dies, dass der objektifizierte Assoziationstyp dieses Ob-
jekt besitzt. Eine Namenskonvention wird durch eine Raute mit leeren Beziehungsstrichen
zwischen zwei Objekten symbolisiert und stellt ein Schlüsselattribut der Datenbanktabelle

12 Test
dar. Ein Kreis mit einem Kreuz zwischen zwei Objekten bedeutet ’XOR’, entweder das
eine oder das andere Attribut kann in der Datenbank gesetzt werden, nie beide.
Zwischen HHM und Zentralserver liegt keine gemeinsame Datenbasis vor. Alle betreffen-
den Daten sind sowohl in der HHM-, als auch in der Zentralserver-Datenbank enthalten.
Dies ermöglicht ein automatisches Wiederherstellen von Datenverlusten. Das Datenmo-
dell erhebt keinen Anspruch auf Vollständigkeit, da beispielsweise keine Organisations-,
Sicherheits- und Konfigurationsdaten im Zusammenhang mit dem Zentralserver enthalten
sind. Diese müssten je nach verwendeter Technologie angepasst werden und würden die
Übersicht über das wesentliche Funktionsbild mindern.
11.7 Dokumentation
Während der Implementierung des HHM-Prototyps wurde stets an der Dokumentation

gearbeitet. Auf der inliegenden CD befindet sich eine Verknüpfung auf oberster Ebene.
Die Dokumentationsdatei ist im HTML-Format gespeichert und ohne Webserver lesbar.
Die Dokumentation umfasst Rezepteingabe, Rezeptplanung, die virtuelle Tastatur, den
Webserver und die implementierte Ausnahmebehandlung. Es werden Bugs hervorgehoben
und aktuelle Implementierungsvorhaben aufgezählt. Schließlich wird die Serververwaltung,
Datenbankadministration und die Weiterentwicklung der Anwendung beschrieben.
12 Test
Wie in der Einleitung dieser Arbeit erwähnt, muss neben den einzelnen Systemtests bei
der Implementierung, besonderer Wert auf die Robustheit und Sicherheit gelegt werden.
Selten gehören Penetrantions- sowie Sicherheitstests zur Testphase. Sie sollten aber genauso
dazu gehören, wie Funktions- und Robustheitstests. Die Qualität sowie die Akzeptanz der
Nutzer, vor allem bei neuen Technologien, hängt von der Ausführlichkeit der Tests ab.
Daher erhält die Applikationssicherheit hier besonderen Stellenwert.
Während der Implementierung wurden sofortige Tests sukzessive durchgeführt. Sehr peni-
bel wurde darauf geachtet, dass Änderungen am Quellcode an einer anderen Stelle keinen
Fehler verursachen. Wurde ein größerer Funktionsumfang fertig, wurde dieser umfangreich
von einer Testperson getestet. Die Rückmeldungen wurden in einem weiteren Schritt no-
tiert und später eingearbeitet, bevor mit der nächsten Funktionalität fortgefahren wurde.
Zwei Wochen vor Abgabe der Diplomarbeit wurde ein umfangreicher Test mit mehreren
Personen durchgeführt. Insgesamt gab es vier verschiedene Testpersonen unterschiedlichen
Alters. Bei der Auswahl der Testpersonen wurde besonderer Wert darauf gelegt, dass sie aus
einem nichttechnischen Umfeld kommen, also im beruflichen Leben nicht mit Computern

12 Test
arbeiten. Die Rückmeldungen und Meinungen der Testpersonen waren positiv. Verbesse-
rungsvorschläge und Änderungswünsche wurden eingearbeitet. Um jedoch jeden Fehler, der
möglicherweise auftreten könnte zu testen, ist ein automatisierter Testlauf notwendig.
Die Testautomatisierung ist mit dem Framework STAF35 (Software Testing Automation
Framework) von IBM angedacht. STAF ist ein plattformunabhängiges und multilinguales
(C/C++, Java,..) Framework, dass von IBM unter der GNU GPL-Lizenz entwickelt wird.
Das Framework eignet sich zum Black-Box-Test von großen Softwareprojekten. Durch die
Vielfalt an möglichen Testverfahren, können eigene Shellscripte alle erdenklichen Situatio-
nen und Programmzustände testen. Die Planung der Software wird damit vor das Design
und die Entwicklung der Software gestellt. Die anschließende Ausführung der Software
erzeugt durch STAF ein Review, welches direkt wieder in die Planung integriert werden
kann. Dadurch entsteht ein auf Tests basierter Software-Lebenszyklus. Abbildung 38 zeigt
ein Szenario, wie der Softwaretest ablaufen kann.
35
http://staf.sourceforge.net/index.php

12 Test
Abbildung 38: Ablaufdiagramm STAF Szenario

13 Epilog
13 Epilog
Abschließend sollen die Erfahrungen beschrieben werden, die während der Arbeit an der
Diplomarbeit gemacht wurden. Neben Erkenntnissen aus Implementierungstechnologien
und Werkzeugen, sollen Schlußgedanken und ein Ausblick in die Zukunft diese Arbeit
ausklingen lassen.
13.1 Zusammenfassung
Zusammenfassend kann man sagen, dass in dieser Diplomarbeit über alle Phasen des
Software-Entwicklungsprozesses hinweg, ein Einkaufsmanagementsystem entstanden ist.
Aus vielen verschiedenen Sichten wurde das System sukzessive zusammengebaut. Es wur-
den Beschreibungskompromisse umgesetzt, die aus Sicht des Autors, trotz des Umfangs,
keine wesentlichen Lücken zum Verständnis des Gesamtsystems offen lassen. Ein Proto-
typ des Haushaltsmanagers setzt nahezu alle beschriebenen Implementierungstechnologien
um und zeigt, wie komfortabel mit dem Einkaufsmanagementsystem aus Sicht des Endver-
brauchers umgegengen werden kann. Folgende Abschnitte sollen Erkenntnisse, Erfahrungen
und Schlußgedanken beinhalten, die während der Bearbeitung der Diplomarbeit gesammelt
wurden.
Modellierung UML ist eine unabdingbare Modelliersprache zur Erstellung der notwen-
digen Transparenz von Softwareprojekten. Ohne UML ist es schwer möglich, die Gedanken
beim Softwaredesign einem Außenstehenden klar und präzise zu vermitteln. Umso klarer
und konkreter die Modellierung, desto leichter fällt die Implementierung. UML dient nicht
nur der strukturierten Herangehensweise an ein Softwareproblem, sondern hiflt dem Pro-
grammierer objektorientierte Strukturen zu entwickeln und Entwurfsmuster zu erkennen
sowie anwenden zu können. Die Gedanken, die man bei der Modellierung mit UML hat, ver-
helfen später zu mehr Kreativität und geistiger Beweglichkeit bei der Programmierung.
Einstiegshürde Anfangs schien die objektorientierte Programmierung mit Javascript auf-

grund fehlender Werkzeuge nahezu unmöglich. Alle Werkzeuge zur Fehlersuche, Schlüssel-
wortauswahl und farbgestützter Darstellung des Quelltextes, mussten mühsam gesucht
werden, bis schließlich Aptana allen Ansprüchen gerecht wurde. Die Entwicklung von Ap-
tana war zeitweise sehr rasant. Mittlerweile kann Javascript-Quelltext mit allen gewohnten
Unterstützungen einer ausgereiften Entwicklungsumgebung komfortabel bearbeitet wer-
den.

13 Epilog
Trend Der Nutzen und der Komfort, den AJAX-Anwendungen bieten können, sind um
ein vielfaches höher, als plattform- und compilerabhängige Software, wie beispielsweise Vi-
sual Basic- oder C/C++ Anwendungen. AJAX hat mit seiner Asynchronität, Drag and
Drop sowie seiner Verarbeitungsgeschwindigkeit alle Nachteile von Webanwendungen auf-
gehoben und damit den Trend zu portablen Webanwendungen geebnet. Nur noch mit er-
heblichem Mehraufwand, sind Eigenschaften, wie Plattformunabhängigkeit, Remote- und
Webfähigkeit sowie Mehrbenutzerbetrieb in konventioneller Software möglich. Die Kosten
zur Erstellung indivuduell programmierter Software haben sich damit verringert.
13.2 Schlussgedanken
Wir haben immer weniger Zeit, um jeden Artikel genau anzusehen. Es stellt sich die Fra-
ge: Sollen die Nahrungsmittel, wie im Ausland teilweise geschehen, von der Wirtschaft
”
vorgeschreiben werden, oder sollen die Konsumenten entscheiden, welche Qualität auf den
Markt kommt?“ Sollte es nicht ein System geben, mit dessen Hilfe sich jeder Konsument
genau über einen Artikel informieren kann, bevor er ihn kauft?
Verbraucheranalyse Eine österreichische Ernährungsstudie36 , deren Bilder sich im An-

hang befinden, zeigt deutlich, welche Ernährungsgewohnheiten, Speisepräferenzen, Verwen-
dung und Einkauf sowie Qualitätsentscheidungen Verbrauchern wichtig sind. Werden diese
und andere Studien in das Einkaufsmanagementsystem eingebaut, gäbe es kaum noch einen
Grund selbst einkaufen zu gehen. Das Einkaufsmanagementsystem würde somit zu einem
Selbstläufer“ werden.
”
Fortsetzung Arbeiten zur automatischen Codegenerierung aus den UML-Diagrammen

oder Sprachein- und -ausgabemodule für den Haushaltsmanager wären im Anschluß an
diese Arbeit denkbar. Auch die Sicherheit sollte nicht vernachlässigt werden. Arbeiten
über Cross-Site-Scripting in Verbindung mit AJAX und dem EMS-Server wären vorteil-
haft. Auch eine Arbeit über ’Intrusion Detection - Prevention and Action’ im Clusterbetrieb
einer Webserver-Farm wäre wichtig. Um sicher zu stellen, dass keine Fehler auftreten kön-
nen, sollte eine Arbeit über STAF in Verbindung mit dem EMS-Server, speziell für die
Kalkulierung der Mengenrabatte erfolgen.
Risikovermeidung Bedacht werden muss auch, dass im Rahmen der Diplomarbeit ein
Werkzeug entstanden ist, welches für einen guten Zweck gedacht ist, jedoch auch für den
Verdrängungswettbewerb missbraucht werden könnte. Weitere Arbeiten sollten mit dem
Hintergedanken der Missbrauch-Erkennung, -Umgang und -Vermeidung implementiert wer-
den. Letztendlich sollte es einen automatisierten und kontrollierbaren Prozess geben, der
36
http://www.lebensmittelnet.at/article/archive/8164

13 Epilog
einen Missbrauch des Einkaufsmanagementsystems erkennt und Maßnahmen dagegen ein-

leitet.
Nutzen Tatsache jedoch ist, dass alleine der Prototyp des Haushaltsmanagers, ohne au-
tomatisierte Artikelbestellung im Internet einen Beitrag zur Harmonie, Ausgewogenheit
und Zufriedenheit im familiären Alltag leistet. Man kann Essenswünsche äußern, Rezep-
te sammeln, Mahlzeiten planen, Einkaufszettel und Rezepte ausdrucken, was eine große
Erleichterung für die Nutzer bei der Haushaltsführung sowie Mahlzeitenplaung darstellt.
Alle Familienmitglieder können sich aktiv bei der Mahlzeitplanung einbringen. Aufwändige
Gerichte werden meist in größerer Menge gekocht. Dies hat den Vorteil, dass nicht jeden
Tag gekocht werden muß. Letztendlich ist die Frage Was soll ich heute kochen?“ mit dem
”
Haushaltsmanager stets beantwortet.
Persönliche Meinung Mit dieser Diplomarbeit wurde ein Weg gezeigt, wie man ohne
großen technischen Aufwand, wie Barcodescanner, RFID-Chips oder Waagen im Kühl-
schrank, realisieren kann, dass der Haushaltsmanager stets alle verfügbaren Lebensmittel
im Haushalt anzeigt. Es wurde der gesamte Ablauf modelliert, der nötig wäre, um Artikel
anhand der Auswahl von Rezepten im Internet zu bestellen und dabei durch Mengenrabat-
te Geld zu sparen. Der Haushaltsmanager-Prototyp, der im Rahmen dieser Diplomarbeit
entstanden ist, zeigt, wie man mit dem System umgehen könnte. Er verwaltet Rezepte und
alle Grundnahrungsmittel und bietet verblüffende Effekte sowie eine einfache Handhabung
beim Planen, Aussuchen oder Eintragen von Rezepten. Der Haushaltsmanager-Prototyp
zeigt deutlich auf, wie komfortabel die Haushalts- und Einkaufsplanung in der Zukunft mit
einem derartigen webbasierten Einkaufsmanagementsystem sein könnte.

Anhang
14 Anhang
Literatur
[gufler] Software Engineering Projektorganisation und Management, Prof. Dr. Dr. h. c.
Manfred Broy, http://home.in.tum.de/ gufler/files/pm.pdf
[Perry 2006] Bruce W. Perry, Ajax Hacks, O‘Reilly 2006
[Gamperl 2006] Johannes Gamperl, Ajax - Web 2.0 in der Praxis, Galileo Computing 2006
[Sommerville 2001] Ian Sommerville, Software Engineering, 6. Auflage, Pearson Studium
2001
[scrum] The Knowledge Creating Company, Nonaka, Takeuchi, Oxford University Press
1995
[sdtm] Entwicklungsmethodiken zur kollaborativen Softwareerstellung - Stand der Technik
2006, http://wifo1.bwl.uni-mannheim.de/fileadmin/files/publications/CollaBaWue-
KSE-Arbeitsbericht-Stand der Technik-Methodiken.pdf
[Oestereich 2006] Bernd Oestereich, Analyse und Design mit UML 2.1, 8. Auflage, Olden-
bourg 2006
[Mahemoff 2006] Michael Mahemoff, Ajax Design Patterns, O‘Reilly 2006
[GOF 2001] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Entwurfsmuster
- Elemente wiederverwendbarer objektorientierter Software, Addison-Wesley 2001
[GOF2 1999] John M. Vlissides, Entwurfsmuster Anwenden - Die Fortsetzung des Klassi-
kers der Gang of Four, Addison-Wesley 1999
[rankin 2002] Charles Rankin, IBM SYSTEMS JOURNAL, VOL 41, NO 1, 2002
[GP Pestizide 2007] Essen ohne Pestizide - Einkaufsratgeber und Supermarktvergleich für
Obst und Gemüse, Greenpeace e.V., Neuauflage 2007
[GP Gentechnik 2006] Essen ohne Gentechnik - Einkaufsratgeber für gentechnikfreien Ge-
nuss, Greenpeace e.V., 10.Auflage 2006

Anhang
System Abkürzungen
BS Bringservice
BSMNGR Bringservice Manager, EMS-Server-Modul
BSTMNGR Bestellmanager, EMS-Server-Modul
CALCMR Calkulation Mengenrabatte, EMS-Server-Modul
Clnt Intf MNGR Client Interface Manager, EMS-Server-Modul
EMS Einkaufsmanagementsystem
HHM Haushaltsmanager
HHMIF Haushaltsmanager-Interface
HST Hersteller
HSTIF Herstellerinterface
WS Webshop
GH Großhandel
PCKMNGR Packetierungsmanager, EMS-Server-Modul
RegMNGR Registrierungsmanager, EMS-Server-Modul
SecMNGR Securitymanager, EMS-Server-Modul
ST Status
Informatik Abkürzungen
AJAX Asynchron Javascript and XML
API Application Programming Interface
BSP Business Server Pages
DML Data Manipulation Language
ERP Enterprise Ressource Planning
IDE Integrated Development Environment
IDS Intrusion Detection System
IP-Adresse Internet Protokoll-Adresse
J2EE Java to Enterprise Edition
JSON JavaScript Object Notation
MySQL OpenSource Datenbankmanagementsystem
PHP PHP: Hypertext Preprocessor,
ursprünglich Personal Home Page Tools
RPC Remote Procedure Call
SOAP Simple Object Access Protocol
oder Service Oriented Architecture Protocol
STAF Software Testing Automation Framework
UML Unified Modelling Language
URI Uniform Resource Identifier
WSDL Web Service Definition Language
XML Extended Markup Language

Anhang
Folgende Bilder sind der Quelle: http://www.lebensmittelnet.at/article/archive/8164 ent-

nommen.
Abbildung 39: Essensgewohnheiten

Anhang
Abbildung 40: Konsumpräferenzen

Anhang
Abbildung 41: Lebensmittelverwendung und Einkauf

Anhang
Abbildung 42: Qualitätskriterien

DA

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

DA

Hochgeladen von

Copyright:

Verfügbare Formate

Diplomarbeit

Verfasser der Diplomarbeit:

Erstprüfer: Prof. Rainer Kelch harrykisch@gmx.net

Zweitprüfer: Prof. Wolfgang Klüver Informatik

Abgabe der Arbeit: 14.03.07 Fachhochschule Augsburg

Telefon +49 821 5586-0

Erstprüfer: Prof. Dr. Rainer Kelch

Augsburg, 13. März 2007

Harald Kisch ii Diplomarbeit

Warenzeichen Die in dieser Diplomarbeit verwendeten Software- und Hardware-Bezeich-

Harald Kisch iii Diplomarbeit

Harald Kisch iv Diplomarbeit

Artikelansicht, Grundnahrungsmittelanpassung, Rezeptliste, Rezeptmatrix, Rezeptverwal-

Harald Kisch v Diplomarbeit

Augsburg, 13. März 2007

4 Aufbau der Diplomarbeit 3

5 Pro und Contra 4

6 Der Zentralserver im Überblick 6

11 Implementierung des HHM-Clients 72

Harald Kisch vii Diplomarbeit

Harald Kisch viii Diplomarbeit

Harald Kisch ix Diplomarbeit

Harald Kisch x Diplomarbeit

Harald Kisch xi Diplomarbeit

Harald Kisch 1 Diplomarbeit

Harald Kisch 2 Diplomarbeit

Diplomarbeit umfasst, erfolgt noch keine Bestellung beim Lieferanten.

4 Aufbau der Diplomarbeit

Harald Kisch 3 Diplomarbeit

5 Pro und Contra

5.1 Das Umdenken

Harald Kisch 4 Diplomarbeit

Die Triebfedern zur Nutzung des Einkaufsmanagementsystems im Allgemeinen sind:

• Rezept- und Artikelsuche unter Berücksichtigung eingegebener Kriterien z.B. Nähr-

5.2 Die Lebensmittelverwaltung

Harald Kisch 5 Diplomarbeit

5.3 Der neue Markt

Mit der Realisierung des Haushaltsmanagers und einer zunehmenden Benutzerakzeptanz

6 Der Zentralserver im Überblick

Harald Kisch 6 Diplomarbeit

Harald Kisch 7 Diplomarbeit

eine Warenpalette auf verschiedene Postleitzahlengebiete zu verteilen. Die Palette wäre in

7.1 HHM Benutzeranwendungsfälle

Harald Kisch 8 Diplomarbeit

Harald Kisch 9 Diplomarbeit

Harald Kisch 10 Diplomarbeit

Harald Kisch 11 Diplomarbeit

7.2 HHM Systemanwendungsfälle

Die Haushaltsmanager-Systemanwendungsfälle beschreiben die Funktionen des Haushalts-

Harald Kisch 12 Diplomarbeit

Tabelle 6: HHM-Anwendungsfall Rezeptplanung-Resteverbrauch

Harald Kisch 13 Diplomarbeit

Tabelle 7: HHM-Anwendungsfall Zustandssicherung

7.3 EMS-Server Benutzeranwendungsfälle

Die EMS-Server Benutzeranwendungsfälle beschränken sich hauptsächlich auf Marketing-

EMS-Server Benutzeranwendungsfall Status-Portal (ST-Portal)

Harald Kisch 14 Diplomarbeit

EMS-Server Benutzeranwendungsfall Administration

Ein zweiter, wichtiger Benutzeranwendungsfall ist die Administration des EMS-Servers.

Harald Kisch 15 Diplomarbeit

7.4 EMS-Server Systemanwendungsfälle

Eingang der Bestellung

Harald Kisch 16 Diplomarbeit

Ausgang der Bestellungen