Entwicklung eines E-Shops

Inhaltsverzeichnis

Abbildungsverzeichnis

1 Use Case Diagramm
1.1 Use Case „Informieren“
1.2 Use Case „Bestellen“
1.3 Use Case „Kontakt aufnehmen“
1.4 Use Case „Zahlen“

2 Aktivitätsdiagramm
2.1 Aktivitätsdiagramm zu „Informieren“
2.2 Aktivitätsdiagramm zu „Bestellen“
2.3 Aktivitätsdiagramm zu „Kontakt aufnehmen“

3 Datenmodellierung

4 php Programmierung
4.1 index.php
4.2 artikel_haupt.php
4.3 details.php
4.4 warenkorb.php
4.5 warenkorb_status.php
4.6 kasse.php
4.7 bestellung.php
4.8 agb.php
4.9 kontakt.php

Anhang

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Use Case E-Shop

Abbildung 2: Aktivitätsdiagramm zu "Informieren"

Abbildung 3: Aktivitätsdiagramm zu "Bestellen"

Abbildung 4: Aktivitätsdiagramm zu "Kontakt aufnehmen"

Abbildung 5: Entity-Relationship-Modell des E-Shops

1 Use Case Diagramm

Ein Use Case Diagramm gibt einen Überblick über das zu entwickelnde Produkt und seine Schnittstellen zur Umgebung. Das folgende Use Case Diagramm veranschaulicht den von uns entwickelten E-Shop aus Sicht des Käufers.

Ein einzelner Use Case definiert einen Arbeitsablauf, der mit Hilfe der zu entwickeln-den Software durchgeführt wird. Die Akteure sind Rollen, die ein Benutzer des Sys-tems spielt.¹

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Use Case E-Shop

1.1 Use Case „Informieren“

Der erste Use Case heißt „Informieren“. Das Ziel dieses Use Cases ist es, den Shop kennenzulernen². Unser Shop hat auf der Käuferseite den Akteur User, da beim Betreten des Shops noch nicht klar ist, ob es sich bei dem User um einen Kunden oder einen Surfer handelt. Diese beiden Akteure sind über eine Generalisierung mit dem User verbunden und übernehmen dadurch seine Haupteigenschaften.

Der Use Case „Informieren“ kann von beiden Akteuren, „Surfer“ und „Kunde“, ausgelöst werden, indem sie unseren Shop über einen Link auf diversen Internetseiten bzw. über andere Wege betreten.

Als positives Ergebnis wird beim „User“ Kaufinteresse geweckt und er wird zum „Kunde“ bzw. der „Surfer“ erhält die von ihm benötigten Informationen. Im negativen Fall wird der Shop wieder verlassen, da keine ausreichenden Informationen zur Verfügung standen bzw. kein Kaufinteresse geweckt wurde..

Bei diesem Use Case handelt es sich um einen primären Use Case, da er immer abläuft und somit ein notwendiges Verhalten beschreibt.

Wenn der Shop betreten wurde, können zum einen die allgemeinen Geschäftsbedingungen nachgelesen sowie die Produkte angeschaut werden. Die erste Möglichkeit wird durch eine „include“-Beziehung zum Use Case „AGB lesen“ dargestellt. Dieser Use Case stellt eine Möglichkeit dar, er muss aber nicht ausgelöst werden. Somit ist er der Kategorie „optional“ zuzurechnen.

Außerdem kann zwischen verschiedenen Artikelmodulen gewählt und die Artikel in Detailansichten betrachtet werden. Dafür ist die Bereitstellung eines aktuellen Katalogs durch den Verkäufer erforderlich. Dies wird durch eine „include“-Beziehung zum Use Case „Katalog aktualisieren“ veranschaulicht. Dies ist ein primärer Use Case, da er ein notwendiges Verhalten beschreibt. Da hier allerdings nur der Prozess aus Sicht des Käufers betrachtet werden soll, und dieser Use Case vom Akteur „Verkäufer“ ausgelöst wird, liegt dieser Use Case außerhalb unseres Systems. Auf ihn soll im Weiteren nicht näher eingegangen werden.

1.2 Use Case „Bestellen“

Der zweite Use Case heißt „Bestellen“.³ Ziel dieses Use Cases ist es, einzelne Artikel aus dem Shop-Sortiment zu bestellen. Da es sich hier um die Hauptfunktion eines Shops handelt, ist dieser Use Case der Kategorie „primär“ zuzuordnen. Er beschreibt ein notwendiges Verhalten.

Hier agiert der „Kunde“. Vor der Bestellung muss dieser die Produkte jeweils anschauen und auswählen. Als positives Ergebnis erfolgt eine Bestellung im Shop. Als negatives Ergebnis kann es Fehlermeldungen geben, falls die AGBs nicht akzeptiert wurden bzw. die Kundendaten falsch eingegeben wurden.

Eine Bestellung wird ausgelöst, wenn Waren aus dem Warenkorb bestellt werden. Dazu müssen zuerst die gewünschten Artikel im Warenkorb gespeichert werden. Dabei ist ebenfalls ein aktueller Katalog notwendig. Aus diesem Grund besteht eine „include“-Beziehung zum externen Use Case „Katalog aktualisieren“.

Anschließend wird die Bestellung initiiert. Dazu müssen die Kundendaten eingege-ben werden, wodurch der Kunde auch für unser System ein Kunde wird. Dieser Vor-gang „Kunde werden“ wird als einzelner Use Case beschrieben und über eine „extend“-Beziehung mit dem Use Case „Bestellen“ verbunden. Er ist somit notwen-dig, bevor überhaupt eine Bestellung ablaufen kann. Dadurch ist er der Kategorie „primär“ zuzuordnen.

Anschließend müssen die AGBs gelesen und bestätigt werden. Dabei läuft wieder der oben beschriebenen Use Case „AGBs lesen“ ab, der über eine „include“Beziehung mit dem Use Case „Bestellen“ verbunden ist.

Beim Abschicken der Bestellung an das System wird durch selbiges die Verfügbar-keit der bestellten Artikel geprüft. Es existiert einen einzelner Use Case „Verfügbar-keit Prüfen“, der über eine „include“-Beziehung mit dem Use Case „Bestellen“ verbunden ist. Nur wenn die Artikel verfügbar sind, kann eine Bestellung ausgelöst werden. Es handelt sich dabei um einen primären Use Case, da er notwendiges Ver-halten beschreibt. Da diese Prüfung allerdings nicht vom Käufer sondern vom Sys-tem durchgeführt wird und dieser Use Case somit außerhalb der Systemgrenze liegt, wird darauf nicht weiter eingegangen.

1.3 Use Case „Kontakt aufnehmen“

Der dritte Use Case heißt „Kontakt aufnehmen“.⁴ Er wird entweder vom „Kunde“ oder vom „Surfer“ ausgelöst. Dieser möchte Fragen stellen bzw. spezielle Informationen an den Verkäufer senden. Der Use Case beschreibt damit optionales Verhalten, wel-ches für den Einsatz des Systems nützlich aber nicht unbedingt notwendig ist.

Verläuft dieser Prozess erfolgreich, wird die E-Mail bzw. ein Brief an den Verkäufer versandt bzw. ein Telefonat geführt. Ansonsten erhält der „Kunde“ bzw. der „Surfer“ eine Fehlermeldung vom E-Mail-Client, bzw. der Verkäufer ist telefonisch nicht erreichbar oder der Brief kommt zurück.

Ausgelöst wird der Use Case durch einen Aufruf der Kontakt-Seite. Dort findet der „Kunde“ bzw. „Surfer“ einen Link, der einen E-Mail Client öffnet, sowie die Adresse und Telefonnummer des Shops. Mit diesen Informationen kann er nun eine E-Mail bzw. einen Brief losschicken bzw. den Verkäufer anrufen.

1.4 Use Case „Zahlen“

Ein weiterer Use Case heißt „Zahlen“. Er wird vom Kunde ausgelöst. Voraussetzung dafür ist, dass eine Bestellung abgeschickt wurde, somit ein Kaufvertrag zustande kam und der „Kunde“ bzw. „Surfer“ eine Bestätigungs-Mail mit den Rechnungs- und Überweisungsdaten vom System bekommen hat. Der Zahlungsverkehr soll nicht durch unseren Shop unterstützt werden, sondern über die normale Bankverbindung des „Kunden“ bzw. „Surfer“. Die Eingabe des Zahlungseingangs erfolgt über den Verkäufer. Da in diesem Diagramm jedoch nur auf die Käufersicht näher eingegan-gen wird, liegt dieser Use Case ebenfalls außerhalb unserer Systemgrenze.

2 Aktivitätsdiagramm

Aktivitätsdiagramme beschreiben die Ablaufmöglichkeiten eines Systems mit Hilfe von Aktivitäten sowie die Zusammenhänge zwischen den vorher im Use Case Diagramm erläuterten Use Cases.⁵

Das Aktivitätsdiagramm ist in zwei Swinlanes (vertikal verlaufende Bahnen) aufge-teilt, mit denen die Zuständigkeiten für die jeweiligen Aktivitäten gezeigt werden. In unserem Fall werden die Zuständigkeiten auf den Hauptakteur „Kunde“ sowie das „System“ verteilt. Auch hier wird die Sicht des Verkäufers nicht näher betrachtet, sondern nur auf Aktivitäten, die vom Kunden ausgehen und durch das System verar-beitet werden eingegangen. Da der gesamte Ablauf sehr komplex ist, wird im folgen-den dem Aufbau des Use Case Diagramms gefolgt und der Ablauf in drei einzelnen Aktivitätsdiagrammen abgebildet.

2.1 Aktivitätsdiagramm zu „Informieren“

Die folgende Abbildung zeigt den Ablauf des Use Case „Informieren“.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Aktivitätsdiagramm zu "Informieren"

Die Swimlane „Kunde“ steht hierbei nicht nur für den eigentlichen Kunden, sondern auch für unseren „Surfer“, da der Informationsprozess für beide gleich ablaufen kann. Die Swimlane Kunde stellt dabei alle Aktivitäten dar, die ausschließlich vom Benutzer eingeleitet werden. Die Swimlane „System“ gibt die Aktivitäten an, die vom System ausgeführt werden. Dabei handelt es sich meist um unsichtbare Rechenoperationen und Prozesse, die für den weiteren Ablauf notwendig sind.

Der Kunde betritt die Shopseite und hat zu Beginn die Wahl, ob er sich die Artikel anschauen oder die allgemeinen Geschäftsbedingungen lesen möchte. Diese Ent-scheidungsmöglichkeit zeigt die nicht gefüllte Raute. Während der Artikelhauptanzei-ge wird vom System eine so genannte Session eröffnet und eine eigene Session ID generiert. Diese bleibt bestehen bis der Browser wieder geschlossen wird.

Anhand mehrerer Auswahlmodule von der Artikelhauptseite über die Artikelübersicht gelangt er zur Artikeldetailseite. Dazu müssen die einzelnen Artikelinformationen vom System aus der MYSQL-Datenbank ausgelesen und dargestellt werden. Anschließend entscheidet es sich, ob der User ein „Kunde“ oder „Surfer“ ist, da er die Wahl zwischen dem Beenden des Einkaufs und dem Auswählen eines Artikels und Speichern im Warenkorb hat. Dies symbolisiert die Raute am Ende des Diagramms mit einem Pfeil in Richtung des zweiten Aktivitätsdiagramms.

2.2 Aktivitätsdiagramm zu „Bestellen“

Im folgenden wird davon ausgegangen, dass der User den Shop nicht verlassen hat, sondern Kaufinteresse an einem oder mehreren Artikeln besteht. Er wird „Kunde“.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Aktivitätsdiagramm zu "Bestellen"

Die gewünschten Artikel legt er in den Warenkorb. Dabei wird vom System im Wa- renkorb die Session-ID dieses anonymen Kunden zu diesem ausgewählten Artikel gespeichert, um ihn ihm später genau zuordnen zu können. Gleichzeitig bekommt der Kunde vom System eine Benachrichtigung, dass die Artikel im Warenkorb ge-speichert wurden.

Anschließend besteht die Möglichkeit, nach weiteren Artikeln zu schauen bzw. die Auswahl zu beenden und den Warenkorb aufzurufen. Dazu werden vom System aus der Tabelle „Warenkorb“ alle Artikel gesucht, die die Session-ID des abfragenden Kunden beinhalten, und es wird der Gesamtpreis inklusive der Versandkosten be-rechnet.

Anschließend hat der Kunde noch einmal die Chance, die Bestellung abzubrechen und den Shop zu verlassen. Andererseits kann er die Bestellung initiieren, indem er den Button „Zu Kasse“ klickt. Daraufhin muss er seine Kundendaten eingeben und die allgemeinen Geschäftsbedingungen akzeptieren. Da diese Akzeptanz sehr wichtig für die rechtliche Wirksamkeit des Vertrages ist, überprüft das System, ob die Zustimmung der AGBs ordentlich erfolgt ist. Falls dies nicht der Fall ist, erhält der Kunde vom System eine Fehlermeldung und die Bestellung kann nicht fortgeführt werden, außer der Kunde akzeptiert anschließend die AGBs.

Sind alle Daten ordnungsgemäß eingegeben, kann der Kunde die Bestellung per Klick abschicken. Daraufhin wird vom System zuerst ein neuer Kunde angelegt und dazu eine neue Kundennummer generiert. Gleichzeitig, ausgedrückt durch den Splitt, wird eine neue Bestellung angelegt und dazu eine neue Bestellnummer vergeben.

Sind diese beiden Vorgänge und Nummern angelegt, erhält der Kunde vom System eine Empfangsmeldung auf dem Bildschirm und eine Rechnungsmail mit den Be-stelldaten und Überweisungsinformationen an seine eingegebene E-Mail Adresse.

Des Weiteren wird eine E-Mail mit allen Bestell- und Versanddaten an den Verkäufer gesandt, der damit über die eingegangene Bestellung informiert wird. Anschließend sind alle Aktivitäten, die zu diesem Use Case gehören abgeschlossen.

[...]

¹ Vgl. Balzert, H. (2000), S.126f

² vgl. Balzert, H. (2000), S.128

³ vgl. Balzert, H. (2000), S.128

⁴ vgl. Balzert, H. (2000), S.128

⁵ vgl. Östereich, B. (1998), S.295