Projektbericht zur Planung und Umsetzung eines Supermarkt Prototypen in Greenfoot
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Projektbericht zur Planung und Umsetzung eines Supermarkt Prototypen in Greenfoot Abgabe: 31. März 2011 Autoren: Igor Bozic (6051794) mail@igor-bozic.com Anke Claußen (6052782) anke_claussen@yahoo.de Leif Dietz (6051239) mail@leifdietz.com Erstellt im Rahmen des Projektes IT-Aneignung, Gender und Diversity (Wintersemester 2010/2011) bei Detlef Rick, Marcel Morisse, Prof. Dr. Ingrid Schirmer Arbeitsgruppe ITG Fachbereich Informatik Universität Hamburg
Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
Inhaltsverzeichnis
1 Einleitung ................................................................................................................................ 2
1.1 Einleitung ......................................................................................................................... 2
1.2 Problemstellung ................................................................................................................ 2
2 Anwendungskontext Supermarkt ............................................................................................ 5
2.1 Supermarkt Definition ...................................................................................................... 5
2.2 Wissenschaftliche Thesen im Bezug zum Prototyp ......................................................... 7
3 Implementation des Anwendungskontextes in Greenfoot .................................................... 11
3.1 Vorstellung Greenfoot .................................................................................................... 11
3.1.1 Allgemein ................................................................................................................ 11
3.1.2 Aufbau von Greenfoot ............................................................................................. 11
3.1.3 Eignung von Greenfoot ........................................................................................... 13
3.2 Implementation............................................................................................................... 13
3.2.1 Implementationsstufen ............................................................................................ 14
3.2.2 Aktuelle Implementation ......................................................................................... 18
3.2.3 Architektur .............................................................................................................. 19
3.2.4 Zukünftige Erweiterungen....................................................................................... 23
4 Projektorganisation................................................................................................................ 25
4.1 SVN ................................................................................................................................ 25
4.2 Programmierrichtlinien .................................................................................................. 25
4.3 Zeitplan........................................................................................................................... 27
4.4 Test ................................................................................................................................. 27
4.5 Fazit Organisation .......................................................................................................... 28
5 Fazit ....................................................................................................................................... 28
Quellenverzeichnis ................................................................................................................... 30
Abbildungsverzeichnis ............................................................................................................. 32
Anhang ..................................................................................................................................... 33
1Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
1 Einleitung
Die Projektarbeit ist in Zusammenarbeit von den Projektmitgliedern Igor Bozic, Anke
Claußen und Leif Dietz unter folgender Aufteilung erstellt worden:
Kapitel 1 und 2: Igor Bozic
Kapitel 3.1 bis 3.2.3: Leif Dietz
Kapitel 3.2.4 bis 4 sowie die EPKs in Kapitel 3.2.3: Anke Claußen
1.1 Einleitung
Im Rahmen des Projekts IT-Aneignung, Gender und Diversity soll ein Prototyp in einer
Simulationsumgebung entwickelt werden, welcher hauptsächlich in einer Schulprojektwoche
zum Einsatz kommt.
Der Prototyp soll ein selbständiges Arbeiten ermöglichen, ohne spezielle Informatik
Kenntnisse vorauszusetzen. Vielmehr dient er dazu, Menschen die Aufgaben der Informatik
deutlich zu machen, um Interesse daran zu wecken. Dabei wird ein Prototyp entwickelt,
welcher es ermöglicht, schnell und ohne Hintergrundwissen in das Themengebiet der
Programmierung einzusteigen, ohne dabei Vertiefungsmöglichkeiten außer Acht zu lassen.
Ziel ist hauptsächlich das Schaffen von Verständnis für die Vielseitigkeit des
Aufgabenbereiches der Informatik. Zudem soll ein Bewusstsein geschaffen werden, das in
dieser Wissenschaft viele verschiedene Fähigkeiten benötigt werden. Das Beherrschen der
technischen Ausführung ist nicht für jeden Bereich aus dieser Disziplin relevant.
Diese Projektarbeit beschäftigt sich mit der Planung, Entwicklung und Umsetzung dieses
Prototyps. Dabei wird ein Anwendungsbeispiel aus der Realität gewählt, welches mit Hilfe
von wissenschaftlichen Methoden zu einem für den Zweck optimierten Modell abstrahiert
wird. Ferner sollen Probleme, Optimierungsmöglichkeiten und Erweiterungsmöglichkeiten
aufgezeigt werden. Aufgrund des zeitlichen Rahmens dieses Projektes können jedoch nicht
alle Gegebenheiten angemessen erforscht und umgesetzt werden. Die Projektarbeit soll
deshalb auch Annahmen ohne ausreichende belegbare wissenschaftlichen Quellen begründen.
1.2 Problemstellung
Zentrale Anforderung ist die Wahl eines geeigneten Anwendungskontextes. Hierbei liegt das
Augenmerk im Titel des Projekts und zwar „Gender“. Das Szenario soll, besonders im
Hintergrund der Informatik, geschlechtsunspezifisch daherkommen. Informatik an sich ist
eine Wissenschaft, welche in Deutschland mehr Anklang bei Männern als bei Frauen findet.
Dies zeigt auch der Studienführer des Departments Informatik der Universität Hamburg,
welcher die Studienanfängerquote von Frauen mit 10-15% titelt (vgl. Uni-Hamburg 2009, S.
14). Darum ist hier besonders darauf zu achten dass der Anwendungskontext nicht bereits im
Voraus Interessentinnen abschreckt.
Aus diesem Grund wurde als Thema ein Supermarkt gewählt. Dieser erfüllt nicht nur
obligatorisch die Anforderung des geschlechterneutralen Ortes, sondern bietet zusätzliche
Vorteile für Entwickler und Anwender.
Für den Anwender erschließt sich der offensichtliche Vorteil der sofortigen Erfassung des
Kontextes, welcher durch die tägliche Nutzung impliziert wird. Hier benötigt es keiner langen
Einleitungen über Abläufe bei den Aufgabenstellungen, da diese durch die Kenntnis der
Domäne für jeden Anwender erschließbar sind. Dies senkt auch die Gefahr, dass das Szenario
wegen seiner Komplexität von vornerein abgestoßen wird. Hiermit beschäftigen sich die
Theorien des Interaction- und Interfacedesign, sowie Useabillity (vgl. Stapelkamp 2010).
Abstoßung durch den Anwender ist ein großes Risiko in der Softwareentwicklung, welche auf
2Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
verschiedenen Ebenen geschehen kann. So kann ein zu großer Funktionsumfang
gleichermaßen schlecht wie ein zu geringer aufgenommen werden. Schwer skalierbare
Anwendungskontexte erschweren die Abgrenzung eines geeigneten Umfangs.
Auch die Entwickler profitieren von diesem spezifischen Szenario. Bei Softwareentwicklung
gehört die zeitliche Planung und das Abstecken des späteren Softwareumfangs zu den
wichtigsten aber auch schwierigsten Aufgaben (vgl. Kleuker 2011, S. 51 ff).
Dieses lässt sich anhand von Vorgehensmodellen sehr gut verdeutlichen. Unabhängig davon,
nach was für einem Modell man arbeitet, drückt Abbildung 1 die allgemeinen Phasen aus,
welche sich in jedem Softwareprojekt wiederfinden lassen (vgl. Kleuker 2011, S. 24 ff).
Abbildung 1 – Vorgehensmodelle – (Eigene Darstellung nach: Kleuker 2011, Abb. 11)
Nach Kleuker (vgl. Kleuker 2011, S. 25) lassen sich die einzelnen Phasen folgendermaßen
beschreiben.
Dabei beginnt man mit einer Anforderungsanalyse, welche dazu dient, die Ziele abzustecken
und zu ergründen. Dies verlangt verschiedene Fähigkeiten vom Entwickler. Zum einen muss
er alles Relevante erfassen was der Kunde vom fertigen Produkt erwartet. Dabei ist auch
darauf zu achten, dass ein begrenztes Wissen über Softwareentwicklung oft dazu führt, dass
dem Auftraggeber nicht alle nötigen Implementierungen bewusst sind. Dieses fehlende
Wissen muss vom Entwickler kompensiert und kommuniziert werden. Zudem sollten hier
realistische Ziele im Anbetracht der Ressourcen vereinbart werden. Es empfiehlt sich, die
Ziele für beide Seiten schriftlich festzuhalten.
Im Grob- und Feindesign werden die ermittelten Ziele in ein Modell gebracht, welches direkt
für die eigentliche Entwicklung dient. Hier werden alle wichtigen Fragen von Funktionalität
über Software-Architektur bis zum Design geklärt. Ziel ist es also, beim Programmieren
schon eine genau Vorstellung zu haben, wer, was und wie macht. Dies beugt zum einen
Fehler vor, da ein genauer Plan zum Vorgehen besteht. Auch können in dieser Phase
Gruppensynergien ideal genutzt werden. Durch eine gemeinsame Planung aller Beteiligten
fließt alles potentielle Wissen für jeden Arbeitsschritt ein, welches oft die bestmögliche
3Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
Lösung hervorbringt. Zuletzt kann auch nur so sichergestellt werden, dass die personellen
Ressourcen maximal ausgenutzt werden um Leerläufe und Stillstände zu verhindern.
Die Implementierung ist der handwerkliche Teil der Entwicklung, sprich die Programmierung
an sich. Hier wird alles Geplante umgesetzt und bei Problemen eventuell noch einmal
überdacht. Im Idealfall entsteht in dieser Phase kein großer Planungsaufwand mehr. Alle Ziele
und die Art der Umsetzung sollten schon abgesteckt worden sein. Die Implementierung sollte
trotzdem nicht blind ablaufen, Kommunikation aller Beteiligten ist auch in diesem Schritt der
Entwicklung sehr wichtig.
Vor dem Einsatz sollte jede Software noch einmal getestet werden. Die Art der Test und der
Umfang hängt stark vom Einsatzgebiet ab. Die Tests können sich auf Fehlersuche im System,
Kompatibilität zur geplanten Hard- und Software oder aber auch auf Useabillity beziehen.
Viele Vorgehensmodelle binden Tests in allen Phasen des Entwicklungsprozesses ein. So soll
sichergestellt werden, dass Fehler nicht erst zum Schluss festgestellt werden, was meist einen
erheblichen Aufwand zur Behebung bedeutet.
Fehler lassen sich in keinem Projekt vermeiden, deshalb spielt die Qualitätssicherung in
jedem Entwicklungsschritt eine zentrale Rolle. Eine gute Qualitätssicherung erkennt die
Fehler früh und minimiert so die Mehrarbeit die durch Fehlplanung entsteht. Dabei kann die
Qualitätssicherung auf verschiedenste Arten umgesetzt werden. So können Tests prüfen ob
die Software auch das tut was sie soll oder frühe Hinzuziehung der Anwender die
Abstoßungswahrscheinlichkeit beim Roll-Out verringern.
Bei genauer Betrachtung der Abbildung 1 fällt einem jedoch ein großes Risiko auf. Es ist
möglich vom letzten Schritt wieder zum ersten zurückzufallen, falls sich herausstellt, dass die
Anforderungsanalyse falsch war. Zwar schließt keine Wahl dieses Risiko komplett aus,
besonders schwer modellierbare Umstände begünstigen dieses jedoch.
Durch die genauen Kenntnisse über die Anwender, lässt sich die Anforderungsanalyse als
zentraler Schritt ohne große Fragen bezüglich der Ziele und damit verbunden des Umfangs
für den Supermarkt abschließen. Hier ist besonders darauf zu achten ein einsatzfähiges
Minimalsystem zu definieren, welches je nach zeitlichen Ressourcen stets erweiterbar sein
soll.
Zwar lassen sich viele Probleme mit genügend Zeit lösen, deshalb sollte jedoch einer der
Eckpfeiler des Projektmanagements nicht außer Acht gelassen werden. Das sogenannte
magische Dreieck (vgl. Abbildung 2) zeigt ein typisches Dilemma welches in Projekten
Auftritt auf.
Abbildung 2 – magisches Dreieck – (Eigene Darstellung nach: Keßler 2002, Abb. 5.5)
Diese vereinfachte Darstellung zeigt den Zusammenhang zwischen Zeit, Qualität und Kosten.
Im weiteren Sinne fällt unter Zeit auch noch Termin. Zu Qualität zählt auch noch Ziele,
4Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
Leistungen und Nutzen. Kosten lässt sich noch mit Personalkapazitäten ergänzen(vgl. Keßler
2002, S. 55-56).
Das Ideale Projekt hätte die maximale Qualität bei minimaler Zeit und minimalen Kosten.
Dieser Zustand ist in der Realität jedoch niemals erreichbar. Die Maxi- beziehungsweise
Minimierung einer Kenngröße wirkt sich gleichzeitig immer auf die anderen Kenngrößen aus.
So kann ich in einem Bereich keine Verbesserung herbeiführen ohne gleichzeitig auch in
einem anderen eine Verschlechterung herbeizuführen. Es müssen also immer Kompromisse
eingegangen werden.
Unter Berücksichtigung dieser Aspekte wird hier zudem deutlich welche Rolle die
Modellierung hat. Ein Modell ist laut Definition immer nur eine vereinfachte Darstellung der
Realität (vgl. Fink 2005, S. 91). Es muss also sorgsam abgewägt werden welche Teile des
realen Supermarktes erfasst werden müssen. Dabei geht es nicht nur darum alle wichtigen
Details für den Prototypen einzubeziehen, sondern auch Möglichkeiten für spätere
Erweiterungen zu bieten. Bei diesem Projekt ist jedoch die knappe Zeit die zentrale Größe
welche zwangsläufig den Umfang bei fester Personalkapazität diktiert.
2 Anwendungskontext Supermarkt
Supermärkte kombinieren viele verschiedene Wissenschaftsfelder um sich ideal auf die
Bedingungen der Marktwirtschaft anzupassen. So spielen besonders Teilgebiete der
Informatik, Wirtschaftsinformatik und Betriebswirtschaftslehre eine zentraler Rolle im
täglichen Ablauf, sowie es in jedem modernen Betrieb heutzutage der Fall ist (vgl. Voß 2001,
S. 1 ff) . Für uns ist jedoch lediglich das Marketing als Teil der Betriebswirtschaftslehre sowie
Teile der Verhaltensforschung relevant.
2.1 Supermarkt Definition
Der Begriff Supermarkt wird häufig für alle Arten von Lebensmittelgeschäften benutzt. Wir
wollen uns nun korrekterweise mit der genauen Definition dieses Begriffes und den
Unterschied zu ähnlichen Geschäftsarten beschäftigen.
Die Einzelhandels Lebensmittelgeschäfte lassen sich nach Anzengruber (vgl. Anzengruber
2007, S. 8ff) in die folgenden vier Vertriebstypen aufteilen.
Hypermärkte
Hypermärkte besitzen typischerweise Verkaufsflächen von über 1500 m². Das breite
Produktangebot dieser Märktet zeichnet sich dadurch aus, dass es sich in erster Linie aus
Markenprodukten zusammensetzt. Da diese aufgrund ihrer Größe eine höhere Abnahme an
Produkten verzeichnen, können sie durch die größere Verhandlungsmacht auch besser
Einkaufspreise erzielen, was sich auch auf den Endabnehmerpreis auswirkt.
Supermärkte
Supermärkte fallen im Vergleich deutlich kleiner aus als Hypermärkte. Sie haben
charakteristisch lediglich eine Größe von bis zu 1500 m². Die flächenmäßige Begrenzung
wirkt sich auch auf das Produktangebot aus, welches auch eingeschränkter ist. Auch hier liegt
der Hauptfokus auf Markenprodukten, welche jedoch im Vergleich zum Hypermarkt oft zu
höhere Preise angeboten werden. Zudem spielt der Frischwarenbereich auch eine zentrale
Rolle, kann im Punkt Qualität aber häufig nicht mit Fachgeschäften mithalten.
5Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
Discounter
Dieser sehr neue Vertriebstyp profiliert sich ausschlaggebend über den Preis. Das
Warenangebot ist stark begrenzt und wird stark von Hausmarken dominiert. Es wird
überwiegend versucht mit günstigen Preisen die aktuell am größten nachgefragten Produkte
im Lebensmittelbereich zur Verfügung zu stellen. Zudem wird versucht eine deutlich besser
Kostenstruktur gegenüber anderen Vertriebsformen umzusetzen.
Traditionelle Fachgeschäfte
In diese Kategorie fallen Lebensmittelhändler welche sich auf wenige Warengruppen
spezialisiert haben. Sie können im Bereich Preis und Warenangebot meistens nicht mit den
anderen Vertriebsarten mithalten. Dafür bieten sie aber in der Regel Qualitativ deutlich
hochwertigere Produkte. Auch besser Beratung, Erfüllung spezielle Kundenwünsche und ein
Warenangebot aus regionaler Produktion zeichnet diese Geschäfte oft aus.
Zur Einschätzung der Relevanz zeigt Abbildung 3 die Aufteilung des Lebensmittelmarktes
nach Vertriebsformen.
3,2
4,4 Selbständige Einzelhändler
7,1
Drogeriemärkte
34
Discounter
Große Supermärkte,
26,1
Supermärkte, SB-Geschäfte
Verbrauchermärkte, SB
Warenhäuser
Sonstige Lebensmittelgeschäfte
25,2
Abbildung 3 – Lebensmittelgeschäfte nach Vertriebsart (Eigene Darstellung nach: Anzengruber 2007, Abb.4)
Nach dieser Zusammenfassung lässt sich auch die Wahl der Vertriebsart Supermarkt genauer
begründen. Ein traditionelles Fachgeschäft ist in aller Regel nur wenige Quadratmeter groß
und bietet für dieses Szenario nicht genügend relevanten Modellierungsmöglichkeiten. Die
Discounter haben zwar oft eine ähnliche Größe wie Supermärkte, bieten aber durch die starke
Fixierung auf den Preis wenige Chancen Verhaltenswissenschaftliche Unterschiede des
Kunden aufzudecken. Zwischen Hypermärkten und Supermärkten ist lediglich die Größe ein
relevanter Unterschied für uns, aufgrund der Übersichtlichkeit des Prototyps wird also der
Supermarkt bevorzugt.
6Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
2.2 Wissenschaftliche Thesen im Bezug zum Prototyp
Im späteren Verlauf der Projektarbeit wird genauer auf den Programmumfang und deren
Funktionalitäten eingegangen werden. Hier wird schon einmal im Voraus der Grobe Umfang
erläutert um diesen anhand von anerkannten Theorien zu begründen oder fehlende
wissenschaftliche Nachweise zu begründen.
Unser Ausschnitt eines Supermarktes soll das durchschnittliche Einkaufsverhalten eines
Kunden darstellen. Dabei soll ein Kunde sich selbständige durch den Supermarkt bewegen,
einkaufen und nach bestimmten Vorgaben auf die Umstände die er vorfindet reagieren. Neben
den Kunden an sich, wird es in dem Supermarkt noch Regale und Kassen geben. Regale
beinhalten Waren, welche wiederum eine Spontankaufwahrscheinlichkeit besitzen. Zudem
spielt die Zeit bei allen Aktionen eine Rolle. Ziel ist es den wirtschaftlich erfolgreichsten
Supermarkt zu erstellen. Was diese ungenau Formulierung genau bedeutet sollen die
nachfolgenden Erläuterungen deutlich machen.
Unter der Grundannahme das eine Person einen Laden betritt um etwas bestimmtes zu kaufen
oder ein Bedürfnis zu befriedigen stellt sich die Frage wie ein Mensch einkauft und was ihn
alles dazu bewegt bestimmte Produkte zu erwerben.
Hierbei können wir uns auf das sogenannte SOR-Paradigma stützen. Dieses Modell erklärt
den Prozess der stattfindet, wenn wir uns in einer Kaufentscheidung befinden. Dabei steht
SOR für Stimulus, Organismus, Reaktion. Es drückt die drei Stufen des
Entscheidungsprozesses aus. Zuerst wirkt ein Stimulus auf den Konsumenten, ein auslösender
Reiz, welcher die Aufmerksamkeit auf ein Produkt lenkt. Dieser Stimuli kann dabei sehr
vielfältig sein, etwa eine Werbebotschaft oder ein Sonderangebot. Darauf folgt der
Organismus, dies ist ein interner Prozess welcher bei jedem Menschen anders ablaufen kann.
Prinzipiell bewertet der Mensch unter Zuhilfenahme verschiedener Kriterien wie persönlicher
Einstellung, Erfahrungsberichten von Bezugspersonen oder Vergleich der Alternativen.
Dieser Prozess lässt sich nicht direkt beobachten und selbst mit Befragungen nicht unbedingt
komplett entschlüsseln, da einige Aspekte auch unterbewusst passieren. Als direkte
Konsequenz des Organismus folgt die Reaktion. In unserem Fall das Kaufen oder nicht
Kaufen des Produktes(vgl. Kuß 2000, S. 2-3).
Abbildung 4 – SOR – Paradigma – (Eigene Darstellung nach: Kuß 2000, Abb. 1.1)
Dieses Modell lässt sich so auch auf die Supermarkt Simulation übertragen. Ein Kunde läuft
selbständig durch den Laden um einen Einkaufszettel abzuarbeiten, dabei geht er an Regalen
vorbei. Befindet er sich nah genug an einem Regal, wirkt der Stimulus. In diesem Radius um
das Regal wirken die Waren auf den Kunden und er hätte die Möglichkeit sich für diese zu
entscheiden. Jede Ware hat eine Spontankaufwahrscheinlichkeit, diese ist Maßgeblich für den
Organismus. Umso höher die Spontankaufwahrscheinlichkeit, umso wahrscheinlicher ist es,
dass der Kunde dieses Produkt kauft. Als Reaktion folgt das Ergebnis des durch die
Spontankaufwahrscheinlichkeit bestimmten Organismus Prozesses, die Entscheidung, ob das
Produkt zusätzlich gekauft wird oder nicht. Dieses ist die simpelste Form der Abbildung
7Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
dieses Modelles, da für den Organismus nur eine Stellgröße ausschlaggebend ist. Nichts desto
trotz bietet dies die Möglichkeit einer realistischen Nachahmung von Kaufentscheidungen.
Bei den Regalen, und damit verbunden auch den Waren, wird es sich um eine sehr
vereinfachte Betrachtung handeln. Hier könnte man sich mit der effektivsten Anordnung von
Regalen innerhalb des Supermarktes und der sinnvollsten Anordnung der Ware innerhalb
eines Regales beschäftigen. Bei den Regalen wird dieses indirekt durch den späteren
Anwender geschehen. Diese sollen explorativ die beste Regalanordnung feststellen. Dabei
wird jedoch kein bewiesenes Modell zum Einsatz kommen. Der dem Kunden vorgegebene
Einkaufszettel wird immer durch einen mathematischen Algorithmus erstellt um eine
konstantes Einkaufsverhalten bei mehreren Simulationsläufen sicherzustellen. So kann durch
die Statistik der meist besuchten Regale, welche am Ende jedes Simulationslaufes angezeigt
wird, der Supermarkt wirtschaftlich sinnvoll gestaltet werden. Das bedeutet, dass der Kunde
an möglichst vielen Regalen vorbeikommt und so das SOR-Paradigma möglichst oft zum
Einsatz kommt, welches den Mehr Kauf von Artikeln fördert.
Bei der ganzen Simulation sollen aber auch nicht die Kundenzufriedenheit außer Betracht
gelassen werden. Bestimmte Gegebenheiten die in zwei Supermärkten objektiv gleich sind,
können in einem negativ, im anderen jedoch positiv wirken. Bei Kundenzufriedenheit geht es
um eine subjektiv wahrgenommenen Zustand des Kunden. So ist es durchaus möglich das
Warten in einer Kassenschlange für einen Kunden angenehmer wirken zu lassen. Wir wollen
uns in dem umfangreichen Bereich der Kundenzufriedenheit auf die Warteschlangen im
Kassenbereich beschränken, diese sollen auch im angemessen Umfang im bestehenden
Modell berücksichtig werden.
Hierbei werden wir uns mit externen Einflussfaktoren beschäftigen, welche eine negative
Wirkung haben können. „ Als externe Einflussfaktoren werden hier Wirkungen bezeichnet,
die von ökonomischen Bedingungen (einzel- und gesamtwirtschaftlicher Art), von sozialen
Umfeld und von den Besonderheiten der jeweiligen Kaufsituation ausgehen.“ (Kuß 2000, S.
164) Dieser Themenbereich umfasst eine sehr Umfangreiche Betrachtung möglicher
Einflussfaktoren, welche sowohl positiv als auch negativ wirken können und deshalb immer
von Gestaltern in dieser Domäne beachtet werden sollten (Kuß 2000, S. 164 ff). Wir werden
uns hier mit einem kleinen Teil dieses Themas beschäftigen, welches aber einen wichtigen
Beitrag zur Realitätsnähe liefern wird.
Für uns wird dieser Faktor die Zeit oder spezieller ausgedrückt die Wartezeit an den Kassen
sein.
8Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
Abbildung 5 – Kundenzufriedenheit – (Eigene Darstellung nach: Kotler 2007, Abb. 2.1 )
Abbildung 5 zeigt den Ansatz von Kotler (vgl. Kotler 2007, S. 43 ff) zur Erklärung von
Einflussfaktoren der Kundenzufriedenheit. Demnach entscheidet sich ein Kunde für das
Produkt mit dem größten Wertgewinn. Der Wertgewinn errechnet sich aus der Differenz
zwischen Wertsumme und Kostensumme. In der Wertsumme werden alle Eigenschaften
aufgezählt welche die subjektiven und objektiven Wertzuwächse für das Individuum
bedeuten. Die Kostensumme erfasst alle Arten von Kosten welche bei der Anschaffung
anfallen. Beide Punkte sind bei jedem Individuum von subjektiven Faktoren abhängig,
weshalb für verschiedene Personen bei gleichen Bedingungen, unterschiedliche Wertgewinne
entstehen können.
Der für uns relevante Ausschnitt findet sich unter der Kostensumme als Kosten für Zeit
wieder. Damit lässt sich das Warten in der Schlange, sprich die Konkrete Zeit, direkt als
Messgröße für Kundenzufriedenheit anwenden. Überschreitet die Zeit eine bestimmte
9Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
Schwelle, sodass die Kostensumme im Vergleich zu anderen Optionen, als negative
Empfunden wird, führt das dazu, dass die Kunden sich für ein anderes Angebot entscheiden.
In unserem Fall hieße das konkret, dass Kunden beim Betreten des Ladens diesen bei zu
langen Schlangen direkt wieder verlassen, da diese eine für ihre Vorstellungen zu lange
Wartezeit implizieren. Auch vorstellbar wäre, dass der begonnene Einkauf beim Feststellen
der Warteschlangenlänge sofort abgebrochen werden würde.
Zurzeit könnte der Eindruck entstehen, dass man durch die Anordnung eines Supermarktes,
welcher es erzwingt dass die Kunden möglichst lange im Laden bleiben, ein ideales Modell
erstellt das sich wirtschaftlich maximal Auszahlt. Es bedarf keiner großen Wissenschaft um
festzustellen, dass ein Supermarkt dieser Art von Kunden gemieden werden würde. Aus
diesem Grund soll der eben erläuterte Teilbereich zur Erklärung von Kundenzufriedenheit
auch im Prototyp Beachtung finden.
Obligatorisch wird dabei die Wartezeit an den Kassen mit einem Bezug auf die Gesamtzeit
eines Einkaufes als Messgröße verwendet. Die Kunden laufen durch den Supermarkt und
kaufen ein, am Ende ihres Einkaufes begeben sie sich zur Kasse um zu bezahlen und
anschließend den Laden zu verlassen. Bei mehreren Personen an der gleichen Kasse bilden
sich Schlangen. Übersteigt die Anzahl der Wartenden an allen Schlangen eine bestimmte
Zahl, verlassen neue Kunden sofort nach dem Betreten ohne Einkauf den Laden. Das Stauen
an den Kassen lässt sich vor allem beobachten, wenn Regalanordnungen gewählt werden,
welche den Kunden künstlich im Laden halten. Das heißt besonders enge Gänge
Aufstellungen die Laufwege unnötig stark vergrößern. Durch die größere Zahl an sich aktuell
im Laden befinden Kunden, strömen auch mehr Kunden gleichzeitig zu den Kassen, welches
diese Überlastung hervorruft.
Hier sei nochmal erwähnt, dass es durchaus möglich wäre dieses Kundenzufriedenheit auch in
einer langen Warteschlange noch positiv zu beeinflussen(vgl. Kotler 2007, S. 43 ff). Dieses
wird aufgrund der komplexen Umsetzung in unserem Modell jedoch nicht berücksichtigt.
Dieses Szenario ist mit Sicherheit nicht in seiner Art und Ausführen ausschlaggebend für die
Akzeptanz von Supermärkten in der Realität. Es bietet jedoch die Möglichkeit für den
Anwender, welcher kein Experter der Domäne ist, schnell und eindeutig Rückmeldung
darüber zu geben ob seine Überlegungen und Umsetzungen sinnvoll waren. Zudem bietet es
für das Lehrpersonal die Möglichkeit der Erklärung von den in dieser Projektarbeit erwähnten
wissenschaftlichen Theorien anhand von Praxisübungen. Es ist also für unseren
Anwendungskontext mit teilweise bewusstem Verzicht auf realitätsnähe im nötigen Umfang
modelliert. Das Modell ist bewusst für Lehrzwecke gewählt und ist deshalb in seiner aktuellen
Ausführung nicht für Simulationen, welche die wirkliche Optimierung eines realen
Supermarktes zum Ziel haben, geeignet.
10Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
3 Implementation des Anwendungskontextes in Greenfoot
3.1 Vorstellung Greenfoot
3.1.1 Allgemein
Der Prototyp des Supermarktes wird mit einer Entwicklungsumgebung namens Greenfoot
erstellt. Diese wurde von den Universitäten University of Kent (England) und Deakin
University (Australien) entwickelt und dient zur Ausbildung von Schülern und Studenten
in Java (vgl. Kölling 2010, S. 1). Als Grundlage diente das, ebenfalls zu Lehrzwecken
entwickelte, Entwicklungstool BlueJ (vgl. Henriksen et.al. 2004, S. 4). Damit kann
Greenfoot die Zusammenhänge der Klassen grafisch darstellen. Zusätzlich setzt Greenfoot
auf der gesamten Java-Welt auf und bietet damit sämtliche Funktionalitäten von Java.
Mit Greenfoot können sowohl grundlegende Konzepte der objektorientierten
Programmierung anschaulich dargestellt werden, als auch komplexe Zusammenhänge
abgebildet werden. Auf der Idee der diskreten ereignisorientierten Simulation basierend
(Johannesmeyer 2010), ist die Entwicklungsumgebung vielseitig einsetzbar. Es soll sowohl
dafür geeignet sein, 14 jährigen Schülern die ersten Grundlagen der Programmierung nahe zu
bringen, wie auch bei der universitären Ausbildung von Studenten im Bereich der
Softwareentwicklung (Kölling 2010, S. 1).
Wie dieses Ziel erreicht werden soll, wird im nächsten Abschnitt mit dem Aufbau der
Entwicklungsumgebung Greenfoot dargestellt.
3.1.2 Aufbau von Greenfoot
Abbildung 6 – Screenshot Greenfoot Entwicklungsumgebung
Die Entwicklungsumgebung von Greenfoot besteht im Wesentlichen aus dem in Abbildung 6
gezeigtem Übersichtsbildschirm des aktuellen Szenarios und einem Texteditor zur
Bearbeitung der Klassen. Als Szenario wird in Greenfoot ein Projekt bezeichnet. Es wird bei
der Erstellung eines Szenarios ein Ordner erstellt, in dem sich alle Projektdateien inklusive
der Greenfoot-Szenariostartdatei befindet.
11Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
Aufgeteilt ist der Übersichtsbildschirm in drei Bereiche: Den größten Teil nimmt die
Greenfoot Welt ein; dort wird das Programm ausgeführt. Rechts ist ein vereinfachtes
Klassendiagramm zu sehen, in dem man die Klassenvererbungen erkennen kann. Im unteren
Teil der Entwicklungsumgebung ist eine Steuerleiste, mit der man u.a. das Szenario starten
kann.
Aufbauend auf der kompletten Java Umgebung, die es einem erlaubt, sämtliche Funktionen
von Java und deren Bibliotheken zu nutzen, stellt Greenfoot zusätzlich eine eigene
Programmierschnittstelle (API - application programming interface) zur Verfügung. Diese
API beinhaltet fünf Klassen, die im Folgenden kurz beschrieben werden. Diese Klassen
werden dahingehend genutzt, dass sie Grundfunktionalitäten für die Objekte eines Szenarios
bereitstellen. Die Grundfunktionalitäten werden durch Vererbung von den API-Klassen an die
Szenario-spezifischen Klassen erweitert und spezifiziert. Anschließend wird beschrieben, wie
der simulationsähnliche Ablauf eines Szenarios von Greenfoot umgesetzt wird.
Greenfoot
Die Greenfoot Klasse stellt zum einen die Steuereinheit des aktuellen Szenarios dar. Hier
kann z.B. das Szenario gestartet oder gestoppt werden und die Geschwindigkeit des Szenarios
eingestellt werden. Zum anderen werden hier auch Funktionalitäten bereitgestellt, die für die
Interaktion mit dem Anwender des Szenarios benötigt werden. Darunter fällt z.B. das
Abfangen von Tastatureingaben und die Rückgabe eines Mauszeiger-Objektes. Dieses Objekt
ist in der MouseInfo Klasse weiter spezifiziert.
World
Ein Objekt der World Klasse oder einer erbenden Klasse ist die Grundlage eines Szenarios.
Man kann dieses Objekt als Spielfeld verstehen, auf dem sich die Akteure bewegen.
Die World Klasse bzw. die von der World Klasse erbende Klasse dient dazu, die oben
erwähnte Welt des Szenarios zu gestalten. Dazu werden in der World Klasse diverse
Funktionalitäten angeboten. Darunter fällt u.a. das Setzen einer Hintergrundgrafik für das
Szenario und das Verändern der Größe von den quadratischen Kacheln, in welche die Welt
eingeteilt ist. Auf diesen Kacheln bewegen sich die Akteure. Auch zählen das Erstellen und
Entfernen von Akteuren aus der Welt sowie Informationen darüber, wie viele Akteure sich in
der Welt befinden zu den Funktionen der World Klasse.
Actor
Die Objekte von den Akteuren stellen die agilen Elemente des Szenarios dar. Sie lassen sich
in eine Welt einfügen und können sich dann in den Grenzen dieser Welt bewegen.
Akteuren kann man, wie der Welt, eine Grafik zuordnen und somit die sich bewegenden
Akteure in der Welt voneinander unterscheiden. Die Agilität erhalten die Akteure dadurch,
dass man sie an eine beliebigen Stelle auf der Welt verschieben kann und dass man sie um
den eigenen Mittelpunkt drehen kann. Die Grafik wird dabei mitgedreht. Außerdem können
Akteure andere Akteure in der Welt erkennen, z.B. durch Überschneidung der eigenen Grafik
mit der Grafik eines anderen Akteurs oder durch das Abfragen einer bestimmten Koordinate
nach Akteuren.
MouseInfo
Diese Klasse dient dazu, die Interaktionen des Anwenders, die er mit der Maus im Szenario
durchführt, abzufangen. Dazu gehört neben der Position des Mauszeigers und der gedrückten
Maustaste auch der Akteur, mit dem die Maus zur Zeit interagiert.
12Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
GreenfootImage
Alle Grafiken und Bilder, die in das Szenario eingefügt werden, z.B. Hintergrund- oder
Akteurgrafik, sind vom Typ GreenfootImage. Man kann sowohl eine bestehende Grafik
einbinden, als auch eine neue Grafik in Greenfoot erstellen. Diese Grafiken kann man zum
einen dahingehend manipulieren, dass man z.B. Größe oder Transparenz verändern kann. Es
ist jedoch auch möglich, einfache Objekte wie Kreise oder Polygone in der Grafik zu
zeichnen und Flächen mit Farbe zu füllen.
Interne Ablauforganisation von Greenfoot
Nachdem ein Szenario gestartet wurde, erinnert die Struktur, wie die Objekte in Greenfoot
bearbeitet werden, an eine diskrete ereignisorientierte Simulation. Das Greenfoot System
erzeugt, abhängig von der eingestellten Geschwindigkeit, Ereignisse, sogenannte Acts. Die
Klassen World und Actor stellen act-Methoden zur Verfügung, die auf diese Systemereignisse
in der Art reagieren, dass die act-Methoden aufgerufen werden und der enthaltende Quellcode
ausgeführt wird.
Bei jedem Systemereignis wird zunächst die act-Methode der Welt ausgeführt. Anschließend
wird nacheinander von jedem Akteur die act-Methode aufgerufen. Die Reihenfolge der
Akteure lässt sich über die Welt selbst bestimmen.
Sind alle Objekte, die diese Act-Methode bereitstellen, einmal vom System aufgerufen
worden, wird die Zeit bis zum nächsten Systemaufruf ohne Aktion abgewartet. Ist in einer
Akteur-Klasse keine act-Methode implementiert, werden die Objekte nicht vom System
automatisch aufgerufen.
3.1.3 Eignung von Greenfoot
Der zu erstellende Prototyp soll in erster Linie dazu dienen, einer Gruppe von Schülern im
Alter von ca. 15 Jahren das Thema Programmierung und Informatik näher zu bringen. Wie
oben beschrieben, soll das genau ein Ziel von Greenfoot sein, was durch mehrere Konzepte
erreicht wird.
Die einfache Benutzeroberfläche von Greenfoot ist reduziert auf wenige Elemente, die zur
Erstellung und Benutzung von Szenarien ausreichend sind. Der Benutzer steht nicht vor einer
Vielzahl an Einstellungsmöglichkeiten oder verschachtelten Menüs, was einen Anfänger
eventuell abschrecken könnte. Außerdem ist die Komplexität von objektorientierter
Programmierung an vielen Stellen vereinfacht, bzw. sie wird anschaulich dargestellt. Durch
das angezeigte Klassendiagramm kann man schnell erkennen, wie die Vererbungsstruktur des
Szenarios aufgebaut ist und kann diese Struktur einfacher an Lernende transportieren.
Der wichtigste Punkt aus unserer Sicht ist jedoch, dass die grafische Darstellung eines
Szenarios einfach umzusetzen ist. Besonders für jüngere Menschen und Menschen ohne
Programmierkenntnisse kann es einfacher sein, die Zusammenhänge zu erkennen, wenn man
diese grafisch unterstützt.
3.2 Implementation
In diesem Kapitel wird beschrieben, wie wir die oben beschriebene Greenfoot
Entwicklungsumgebung genutzt haben, um den Anwendungskontext Supermarkt umzusetzen.
Für die Realisierung eines Supermarkt Szenarios haben wir uns entschieden, weil die Abläufe
in einem Supermarkt mit denen der Kunde in Berührung kommt, für die meisten Menschen
bekannt und vertraut sind. Man muss also nicht erst den Anwendungskontext erklären.
13Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
Das Kapitel ist folgendermaßen aufgebaut: Zunächst wird auf unterschiedliche
Implementationsstufen eingegangen. In jeder Stufe wurden grundlegende Entwicklungen
erreicht, die notwendig für weitere Entwicklungen waren. Diese werden in jeder Stufe
ausführlich beschrieben.
Anschließend wird die aktuelle Implementation erläutert, ohne allerdings auf die Details, die
in den Implementationsstufen beschrieben wurden, einzugehen.
Als letzten Punkt wird ein Ausblick auf Erweiterungen gegeben, die dem Prototypen in
Zukunft hinzugefügt werden könnten.
3.2.1 Implementationsstufen
Stufe 1
Abbildung 7 – Screenshot Implemetationsstufe 1
In der ersten Stufe wurden zunächst die grundlegenden Funktionalitäten des Kunden gelegt,
damit dieser durch den Supermarkt laufen kann. Dazu ist es nötig, dass der Kunde Ziele im
Supermarkt bekommt und diese Ziele eigenständig erreichen kann. Auf eigene Grafiken
wurde in dieser Version noch verzichtet; Regale wurden dargestellt durch Autos, Kunden
durch Ameisen.
Jeder Kunde erhält bei seiner Erstellung eine Einkaufsliste, die er im Supermarkt abarbeiten
soll. Dazu wird aus einer vorhandenen Warenliste, in der alle im Supermarkt erhältlichen
Waren aufgelistet sind, eine zufällige Anzahl Waren ausgewählt und mit ebenfalls zufällig
generierter Stückzahl in die Einkaufsliste geschrieben. Man kann die Einkaufsliste nun
fragen, was die nächste zu kaufende Ware ist und kann eine Ware als gekauft markieren.
Hat ein Kunde ein Ziel bekommen, werden die X- und Y-Koordinate des Ziels gespeichert. In
jedem Aufruf der act-Methode versucht er dann dem Ziel näher zu kommen, was im
Folgenden näher beschrieben wird.
Lauflogik
Als erstes wird geprüft, ob das Ziel bereits erreicht wurde, d.h. ob die aktuellen Koordinaten
des Kunden mit denen des Ziels innerhalb einer Toleranz übereinstimmen. Sollte dies der Fall
sein, muss ein neues Ziel bestimmt werden. Im negativen Fall wird als nächstes geprüft,
welche Kacheln um den Kunden herum frei sind, also in welche Richtungen er laufen könnte.
Dann wird ermittelt, in welche Richtung das Ziel relativ zum Kunden liegt. Ist der Weg in
14Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
diese Richtung frei, wird der Kunde um einen Schritt in die Richtung bewegt. Die
Bewegungen in X- und Y- Richtung werden unabhängig voneinander betrachtet. Muss in
beide Richtungen gelaufen werden und sind beide Richtungen frei, läuft der Kunde diagonal.
Ist in X-Richtung ein Hindernis, die Y-Richtung aber frei, läuft der Kunde nur in Y-Richtung.
Probleme treten mit dieser Strategie jedoch auf, wenn der Kunde die X-Koordinate seines
Ziels bereits erreicht hat und in Y-Richtung ein Hindernis steht. In dem Fall wird dem
Kunden eine so genannte ‚Zwangsrichtung’ vorgegeben. Das Hindernis wird dahingehend
analysiert, ob der Weg links oder rechts um das Hindernis herum vom aktuellen Standpunkt
aus kürzer ist. Ist der kürzere Weg ermittelt, wird dem Kunden eine Zwangsrichtung gesetzt,
die ihn zwingt, sich gegen seine eigentliche Lauflogik zu bewegen. Er verlässt also wieder die
bereits erreichte X-Koordinate und läuft so lange an dem Hindernis entlang, bis der Weg in
Y-Richtung frei ist. Dann wird die Zwangsrichtung aufgehoben und die normale Lauflogik
setzt wieder ein.
Ein Problem, welches mit dieser Logik auftritt, ist z.B., dass ein Kunde aus einer Sackgasse
nicht mehr herausfindet. Dieses Problem besteht auch noch in der aktuellen Implementation.
Stufe 2
Abbildung 8 - Screenshot Implemetationsstufe 2
In der nächsten Stufe wurde der komplette Ablauf vom automatischen Erstellen der Kunden
über deren Einkauf bis hin zum Kassieren an der Kasse umgesetzt. Zusätzlich wurden die
ersten eigens erstellten Grafiken für das Supermarkt Szenario eingepflegt. Dadurch musste die
Kollisionsabfrage in der Lauflogik aufgrund der neuen Grafiken neu geschrieben werden, da
die ersten Testgrafiken, wie oben beschrieben, unglücklich gewählt wurden. Diese Version
war die erste Testversion, die wir im Projekt veröffentlicht haben.
Einkaufs- / Kassierlogik
Jeder zufällig erstellte Kunde erscheint ausgerüstet mit einem Einkaufszettel im
Eingangsbereich und arbeitet autonom seinen Einkaufszettel im Supermarkt ab. Dazu wird die
nächste Ware vom Einkaufszettel gelesen und über die Ware die Zielkoordinate des
zugehörigen Regals ermittelt. Erreicht der Kunde dann die Zielkoordinate, wird die Ware als
15Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
gekauft gekennzeichnet. Waren, von denen kein Regal im Supermarkt vorhanden ist, werden
als nicht-erhältlich gekennzeichnet. Ist der Einkaufszettel abgearbeitet, wird die Kasse als Ziel
gesetzt. An der Kasse angekommen, ruft der Kunde die Kasse auf und übergibt den
Einkaufszettel. Der Kunde geht dann in einen Wartezustand über bis er von der Kasse mit
‚kassieren-fertig’ aufgerufen wird. In dieser Zeit analysiert die Kasse den Einkaufszettel und
errechnet anhand der Stückzahl und den hinterlegten Preisen der Waren den Umsatz für
diesen Kunden. In dieser Version war der Kassiervorgang jedoch noch ohne Zeitverzug.
Danach ruft die Kasse den Kunden wieder auf und dieser bekommt den Ausgang als nächstes
Ziel zugewiesen. Am Ausgang wird der Kunde automatisch aus der Welt entfernt.
Stufe 3
Abbildung 9 - Screenshot Implemetationsstufe 3
In Stufe 3 wurde der Supermarkt um weitere Regale und Waren erweitert. Aber es wurden
auch unterschiedliche Kundentypen, die sich in ihrer Laufgeschwindigkeit und der Bezahlzeit
unterscheiden, eingepflegt. Zudem wurde neben der normalen Kasse auch eine Expresskasse
erstellt, die die Kunden nur mit einer maximalen Anzahl von 10 Artikeln ansteuern dürfen.
Entscheidend auf dieser Stufe ist die Implementation von Wartezeiten an den Kassen und die
Realisierung von Warteschlangen an den Kassen.
Bezahlvorgang / Warteschlangenlogik
Nachdem eine Kasse von einem Kunden zum Kassieren aufgerufen wird, errechnet sie anhand
der übergebenen Einkaufsliste und der kundenspezifischen Bezahlzeit die gesamte Bezahlzeit.
Die kundenspezifische Bezahlzeit hängt davon ab, von welchem Kundentyp das aktuelle
Kundenobjekt ist. Nachdem die gesamte Bezahlzeit verstrichen ist, ruft die Kasse den Kunden
wieder auf und beendet den Kassiervorgang. Die Bezahlzeit ist keine reale Zeit, sondern eine
Anzahl von act-Aufrufen, die die Kasse verstreichen lässt.
Durch den Zeitverzug beim Bezahlvorgang ist es auch nötig, Warteschlangen an den Kassen
zu realisieren. Dazu hat jeder Kunde Variablen für einen Vorgänger und Nachfolger. Ist die
Kasse leer und ein Kunde fragt nach den Zielkoordinaten der Kasse, bekommt er die direkten
Koordinaten der Kasse. Der erste Kunde stellt sich vor die Kasse und wartet darauf, dass sein
16Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
Einkaufszettel kassiert wird. Die Kasse merkt sich in dieser Zeit, welcher Kunde bei ihr steht.
Fragt nun ein neuer Kunde nach den Kassenkoordinaten, so bekommt er die Koordinaten des
letzten Kunden in der Schlange. Dies ist so realisiert, dass immer der Nachfolger abgefragt
wird, bis es keinen mehr gibt. Diese Position muss die letzte in der Schlange sein. Der neue
Kunde versucht nun die Position des letzten Kunden zu erreichen, bis er in Berührung mit
diesem ist. Ist der erste Kunde in der Schlange abkassiert, löscht er seine Vorgängerposition
beim zweiten Kunden und verlässt die Kasse Richtung Ausgang. Der zweite Kunde erkennt,
dass er nun der Vorderste in der Schlange ist und rückt auf die ebenfalls gespeicherten
Kassenkoordinaten auf und beginnt mit dem Bezahlvorgang. Der neue Zweite in der Schlange
erkennt, dass er nicht mehr in Berührung mit dem Vorgänger steht und versucht wieder
dessen Position zu erreichen. So zieht sich das durch die komplette Warteschlange durch bis
alle aufgerückt sind.
Stufe 4
Abbildung 10 - Screenshot Implemetationsstufe 4
In der letzten Stufe vor der aktuellen Version wurden neben der ständig aktualisierten Grafik
die ersten Elemente der Wirtschaftlichkeitsbetrachtung und der Statistik eingebaut, sowie die
Funktion der Spontankäufe umgesetzt.
Wirtschaftlichkeit
Wie oben bereits beschrieben, berechnet jede Kasse die Umsätze, die sie an einem Kunden
macht. Diese werden ständig aufaddiert und über alle Kassen akkumuliert. Die Kosten in dem
Supermarkt ergeben sich aus den Kosten der Kassen und der Regale. Jede Kasse kostet pro
Stunde, sofern sie aktiviert ist, einen gewissen Betrag. Auch hat jedes aufgestellte Regal einen
Stundensatz, welcher zu den Gesamtkosten beiträgt. Die Kosten für die Kassen und Regale
sind jedoch nicht typabhängig, sondern jede Kasse kostet den gleichen Satz und jedes Regal
den Gleichen.
17Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
Spontankäufe
Auf dem Weg durch den Supermarkt ist jeder Kunde nun in der Lage, Waren zu kaufen, die
nicht auf seinem Einkaufszettel stehen. Nach einer gewissen Anzahl Schritten scannt der
Kunde dazu seine Umgebung mit einem festen Radius. Trifft er dabei auf Regale, wird
zufällig eines ausgewählt. Dieses Regal wird nun mit der Methode spontanKauf aufgerufen.
Jeder Regaltyp hat als Attribut eine Spontankaufwahrscheinlichkeit, die darüber entscheidet,
ob ein Kunde, der einen Spontankauf versuchen will, dies auch wirklich tut. Reagiert das
Regal positiv auf den Versuch einen Spontankaufs, so gibt es eine zufällig ermittelte Ware
zurück, die in diesem Regal zu kaufen ist. Der Kunde ermittelt dann zufällig eine Stückzahl,
welche mit der Ware dem Einkaufszettel als gekauft markiert hinzugefügt wird.
3.2.2 Aktuelle Implementation
Abbildung 11 - Screenshot Implemetationsstufe 5
Stufe 5
Die letzte und aktuelle Implementationsstufe zeichnet sich vor allem dadurch aus, dass Fehler
beseitigt wurden, fehlenden Grafiken für Objekte erstellt und eingebaut wurden und das
Szenario hinsichtlich seines Einsatzzweckes erweitert und optimiert wurde. So soll die
Wirtschaftlichkeitsbetrachtung und Optimierung eines Supermarktes durch den Anwender
eine große Rolle spielen.
Zu diesem Zweck enthält der Prototyp einen Auswertungsbildschirm, der am Ende eines
Szenariodurchlaufes angezeigt wird. Der Supermarkt lässt sich anhand einiger Parameter, wie
die gesamt zu erstellende Anzahl an Kunden, die Intervalle, in denen Kunden erstellt werden
sollen, die Laufgeschwindigkeit der unterschiedlichen Kunden, die durchschnittliche Größe
der Einkaufszettel, usw. nach eigenem Ermessen steuern. Die gesamte Anzahl Kunden steuert
dabei indirekt die Länge eines Szenariodurchlaufs. Ist die Anzahl erreicht, werden keine
neuen Kunden im Supermarkt erstellt. Verlässt dann der letzte Kunde den Supermarkt, wird
der Abschlussbildschirm angezeigt, der nützliche Informationen für die Auswertung und eine
Optimierung des Supermarkt-Layouts bietet.
18Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
Die Wirtschaftlichkeitsinformationen auf der linken Seite des Bildschirms können vor allem
für die Auswertung und den Vergleich des Layouts mit anderen Durchläufen oder anderen
Mitbewerbern herangezogen werden. Es kann aber auch Informationen darüber geben, wie
gut das Kassenlayout gestaltet ist. Der Eintrag „Kunden ohne Einkauf“ weißt auf Kunden hin,
deren Produkte in dem Supermarkt nicht vorhanden sind oder darauf, dass die Kassen zu voll
waren. Jeder Kunde besitzt eine tolerierte Maximalschlangenlänge. Wird diese Länge an allen
Kassen überschritten, während er den Supermarkt betritt, so begibt er sich sofort wieder
Richtung Ausgang. Auch gibt die durchschnittliche Wartezeit Hinweise darauf, dass eventuell
wenige Kassen im Einsatz sind.
Auf der rechten Seite der Auswertung befindet sich eine Top5 der meistbesuchten Regale.
Dabei wird jeder Besuch eines Kunden an einem Regal gezählt, ganz gleich ob es sich um
einen geplanten Kauf oder einen Spontankauf handelt. Diese Werte geben einen Hinweis
darauf, an welcher Stelle die Artikel in der Liste aller Waren stehen. Über diese Liste wird bei
der zufälligen Erstellung des Einkaufszettels eine Normalverteilung gelegt, womit jeder
Artikel eine andere Wahrscheinlichkeit erhält. Je weiter ein Artikel in der Mitte der Liste
steht, desto wahrscheinlicher erscheint er auf dem Einkaufszettel. Stehen also viele Artikel
eines Regals mittig in der Warenliste, könnte dies am Ende einen Einfluss auf die Top5
haben. Einen weiteren Hinweis kann man über die Top5 auf die
Spontankaufwahrscheinlichkeit eines Regaltyps bekommen. Beim Durchlauf könnte ein gut
platziertes Regal mit hoher Spontankaufwahrscheinlichkeit dazu führen, dass dieses Regal
viele Zugriffe hat und dadurch auf der Top5 erscheint.
3.2.3 Architektur
In diesem Kapitel wird die Architektur des Supermarkt Prototyps zusammengefasst. Zu
diesem Zweck werden zunächst ein reduziertes Klassendiagramm und anschließend der
schematische Durchlauf eines Kunden durch den Supermarkt in Form einer Ereignis-Prozess-
Kette (EPK) dargestellt.
Im Anhang befinden sich die hier aufgeführten Grafiken in höherer Auflösung.
19Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
Klassendiagramm
Abbildung 12 – Klassendiagramm (eigene Darstellung)
Das in Abbildung 12 dargestellte Klassendiagramm zeigt ausschließlich die Namen der
Klassen und die Vererbungen, die in unserem Prototyp umgesetzt sind. In blau sind die
Greenfoot Klassen dargestellt, die von der Entwicklungsumgebung zur Verfügung gestellt
werden, in gelb sind unsere umgesetzten Klassen abgebildet. Unser Supermarkt erbt von der
World-Klasse und stellt damit die Rahmenbedingungen für unser Szenario dar.
Die Akteure des Szenarios erben von der Greenfoot Klasse Actor. Die Klassen
Abschlussbildschirm und Textanzeige dienen dazu, Textbausteine an einem beliebigen Platz
im Szenario zu platzieren, sowie den Auswertungsbildschirm am Ende eines Durchlaufes
anzuzeigen. Mit Hilfe der Uhr werden zeitkonsumierende Aktionen, z.B. das Kassieren,
durchgeführt, wie auch die aktuelle Geschwindigkeit des Szenarios in eine für Menschen
nachvollziehbare Darstellung gebracht.
Die wichtigsten Akteure sind die Kunden und die statischen Akteure. Die Kundenklasse stellt
sämtliche Funktionen aller Kundentypen zur Verfügung. In den erbenden Unterklassen
werden lediglich die Grafiken für die spezielle Kundenart eingebunden und deren
Kundenspezifischen Attribute Laufgeschwindigkeit und Bezahlzeit eingestellt.
Statische Akteure sind in unserem Supermarkt Prototyp die Kassen und die Regale. Es gibt
mehrere Gründe für die Erstellung dieser Oberklassen. Funktionen, wie das Drehen eines
Objektes um 90° müssen nur einmal implementiert werden. Zudem ist die Lauflogik des
Kunden darauf ausgelegt, keine Überschneidungen mit statischen Objekten zuzulassen, was
bedeutet, dass er versucht, um alle statischen Objekte herum zu laufen. Der dritte Grund ist
das Speichern von Szenarien.
Klassen, die von keiner Greenfoot Klasse erben, sind das Speichern und Laden, sowie die
Einkaufsliste und die Warenliste. Es gibt die Möglichkeit, das aktuelle Layout des
entworfenen Szenarios zu speichern. Dabei werden alle statischen Objekte des Szenarios mit
Position und Ausrichtung in einer Textdatei gespeichert. Über die Laden Funktion kann man
diesen Zustand wieder herstellen.
20Projektbericht zur Planung und Umsetzung
eines Supermarkt Prototypen in Greenfoot Bozic, Claußen, Dietz
Ereignis-Prozess-Kette
Notation
Abbildung 13 - EPK Notation
Die Notation entspricht den Vorgaben von Frauenhofer 2011.
Szenario-Ablauf
Zum besseren Verständnis ist das EPK-Diagramm zweigeteilt. Im ersten Diagramm ist der
Durchlauf von der Erstellung bis zum Entfernen des Kunden am Ende seines Einkaufs
dargestellt. Die Komplexität der Warensuche und der Spontankäufe sind im zweiten
Diagramm abgebildet. Verknüpft sind beide Diagramme über den Prozesspfad „Kunde sucht
Ware“ im ersten Diagramm.
Es wird darauf hingewiesen, dass eine ausführliche Beschreibung verschiedener Prozesse im
Kapitel 3.2.1 zu finden ist.
Abbildung 14 - EPK: Kunde kauft ein (eigene Darstellung)
21Sie können auch lesen
