Entwurf

club.shopping.deProjekt: club Portal für shopping.deAutor: Unister GmbHletzte Änderung: 09.09.10

Inhaltsverzeichnis 1 Einführung........................................................................................................................................1 2 Übersicht über Komponenten...........................................................................................................1

2.1 Struktur und Beziehungen.........................................................................................................12.1.1 MVC...................................................................................................................................12.1.2 Datenbank..........................................................................................................................22.1.3 Librarys..............................................................................................................................32.1.4 Das Model..........................................................................................................................52.1.5 Die View.............................................................................................................................7

2.2 Portal Sitemap............................................................................................................................72.3 Die Rechteverteilung.................................................................................................................7

3 Die Module.......................................................................................................................................83.1 Shop Modul................................................................................................................................8

3.1.1 View...................................................................................................................................83.1.2 ShopController...................................................................................................................93.1.3 ShopModellKlassen...........................................................................................................9

3.2 ClubShopping Modul.................................................................................................................93.2.1 Portal View.......................................................................................................................103.2.2 Klassen ............................................................................................................................10

3.3 Warenkorb Modul....................................................................................................................103.3.1 View..................................................................................................................................113.3.2 OrderController ...............................................................................................................123.3.3 OrderModellKlassen .......................................................................................................12

3.4 Benutzerverwaltung Modul.....................................................................................................123.4.1 View.................................................................................................................................133.4.2 CustomerController..........................................................................................................133.4.3 CustomerModellKlassen .................................................................................................14

3.5 Administrator Modul................................................................................................................153.5.1 View.................................................................................................................................153.5.2 AdminController..............................................................................................................153.5.3 AdminModellKlassen ......................................................................................................15

4 Prozesse..........................................................................................................................................164.1 Shopprozesse...........................................................................................................................16

4.1.1 Produktinformationsprozess.............................................................................................164.1.2 Kategorienavigationsprozess............................................................................................164.1.3 Registrierungsprozess......................................................................................................17

4.1.4 Loginprozess....................................................................................................................194.1.5 Warenkorbverwaltungsprozess.........................................................................................214.1.6 Einkaufprozess ...............................................................................................................224.1.7 Versand.............................................................................................................................24

4.2 Benutzerprozesse.....................................................................................................................244.2.1 Datenänderungsprozess....................................................................................................244.2.2 Bestellungsverwaltungsprozess........................................................................................25

4.3 Administratorprozesse.............................................................................................................274.3.1 Verwaltungsprozess für Benutzerdaten............................................................................274.3.2 Verwaltungsprozess für Bestelldaten...............................................................................274.3.3 AktiongenerierungsProzess..............................................................................................27

4.4 Qualitätsanforderungen - Coding-Standard.............................................................................294.5 Datenbank................................................................................................................................294.6 PHP Dateiformatierung............................................................................................................294.7 Namens Konventionen.............................................................................................................294.8 Code Stil..................................................................................................................................304.9 Inline-Dokumentation..............................................................................................................34

AbbildungsverzeichnisAbbildung 1: MVC...............................................................................................................................1Abbildung 2: Datenbankmodell...........................................................................................................2Abbildung 3: Klassenmodell................................................................................................................6Abbildung 4: Sitemap...........................................................................................................................7Abbildung 5: View_Produktansicht......................................................................................................8Abbildung 6: Portallayout..................................................................................................................10Abbildung 7: View_Warenkorb..........................................................................................................11Abbildung 8: View_Kasse..................................................................................................................12Abbildung 9: View_UserLogin-Registrierung...................................................................................13Abbildung 10: Sequenzdiagramm - Produktinformation...................................................................16Abbildung 11: Sequenzdiagramm - Kategorienavigation..................................................................17Abbildung 12: Sequenzdiagramm - Registrierung.............................................................................18Abbildung 13: Sequenzdiagramm - UserLogin..................................................................................20Abbildung 14: Sequenzdiagramm - Warenkorbverwaltung...............................................................21Abbildung 15: Sequenzdiagramm - Kasse_Start................................................................................23Abbildung 16: Sequenzdiagramm - Kasse_Abschluss.......................................................................23Abbildung 17: Sequenzdiagramm - Versand......................................................................................24Abbildung 18: Sequenzdiagramm - Kundendaten.............................................................................25Abbildung 19: Sequenzdiagramm - Kundenbestellungen..................................................................26Abbildung 20: Sequenzdiagramm - Administrator.............................................................................28

1 EinführungDie Systemlandschaft für das Portalprojekt besteht aus einem Web und einemDatenbankserver. Diese sind über Balancer auf mehrere physische Server verteilt. AlsWebserver steht ein Apache mit PHP5.2 auf einem Debian-Lenny-System bereit und alsDatenbank wird MySQL-5.0 verwendet.

2 Übersicht über KomponentenEs gibt neun grundlegende Komponenten im System:

– Datenbank (MySQL)

– Library (Zend Framework)

– Model (Zend_Db_Table Klassen)

– View (Zend_View)

– Shop (Zend_Controller)

– Benutzerverwaltung (Zend_Controller)

– Administrator (Zend_Controller)

– Checkout (Zend_Controller)

– Datenimport (Zend_Controller)

2.1 Struktur und Beziehungen

2.1.1 MVC

1

Abbildung 1: MVC

Die Struktur der Applikation richtet sich strikt nach dem MVC-Architekturmuster. Dabei ist aufeine strenge Trennung zwischen den Einheiten Datenmodel (Model), Präsentation (View) undProgrammsteuerung (Controller) zu achten. Die Geschäftslogik wird bei diesem Projekt soweitmöglich im Model umgesetzt.

2.1.2 Datenbank

Die MySQL Datenbank bietet die Möglichkeit Daten zu verwalten und zu speichern.

Zur Kommunikation mit der Datenbank benutzen die Zend_Db_Table Klassen des Models denpdo_mysql MySQL Adapter.

2

Abbildung 2: Datenbankmodell

2.1.3 Librarys

Zend Framework und benutzerdefinierte Klassen, welche die Client-/Server-Applikationverwenden

Das Model und die View verwenden die hier zur Verfügung gestellten Klassen, um die Daten zu holen und diese dann Darzustellen.

Abbildung von Objekten in relationalen Datenbanken

Wir gehen davon aus, dass alle Exemplare der benutzerdefinierten Klassen etwa die gleicheDatenstruktur haben. Wir werden für die Speicherung der Daten jeweils eine Tabelledefinieren, deren Spalten den Attributen beziehungsweise den Dateneinträgen der Objekteentsprechen.

Die Librarys stellen dazu folgende Funktionalitäten zur Verfügung: Verbindung zur Datenbank erstellen Daten von Client abfangen Daten abfragen Daten aktualisieren Daten von Client validieren und filtern Daten einfügen Daten darstellen Formulare erstellen Identifizierung Zugriffskontrolle Authentifizierung Konfigurationsdaten innerhalb der Applikation verwenden Lokalisierung Navigation erstellen PlugIns verwenden Tabellen als Objekte speichern Session definieren und verwenden

Übersicht

Ausgewählte Klassen seien im Folgenden vorgestellt:

Zend FrameworkZend_Application bietet die Möglichkeit des Bootstrappings, das einlesen von

Konfigurationsdateien und das Autoloading von KlassenZend_Acl Zend_Acl stellt eine Implementation von leichtgewichtigen und

flexiblen Zugriffskontrolllisten für die Rechteverwaltung bereit.Im Allgemeinen kann eine Anwendung Zend_Acl verwenden,um den Zugriff auf bestimmte, geschützte Objekte durchandere anfordernde Objekte zu kontrollieren. Rollen undZugangsbeschränkungen werden definiert.

Zend_Auth Zend_Auth_Adapter_DbTable bietet die Möglichkeit sichgegenüber Daten zu authentifizieren die in einer DatenbankTabelle gespeichert sind.

Zend_Captcha Kann zum Ausschluss von Bots in ungesicherten Formularenverwendet werden.

Zend_Config Dient zum laden von Konfigurationsdateien, wahlweise im XMLoder .ini Format.

Zend_Controller Gewährleistet das Zusammenspiel zwischen denZend_Controller_* Kind-Klassen um User-Requests an dieAngeforderten Controller weiterzuleiten.

Die Controller Architektur beinhaltet ein Pluginsystem, welches

3

uns ermöglicht eigenen Code im Dispatch Prozess auszuführen.Zend_Db Parent Klasse für alle Datenbank bezogenen Aktionsklassen.

Die statische Methode Zend_Db::factory() wird benutzt, umeine Instanz eines DB-Adapters zu erzeugen (z. B. Pdo_Mysql) .(Anbindung einer Datenbank mit einem Adapter)

Die Zend_Db_Table Klasse ist eine Objekt-OrientierteSchnittstelle zur Datenbank Tabellen.Die Zend_Db_Table_Row Klasse enthält eine einzelne Zeileeines Zend_Db_Table-Objekts. Sie besitzt Methoden für dieAbfrage von verknüpften Zeilen in anderen Tabellen.Die Zend_Db_Table_Rowset Klasse besitzt mehrere Objectenach einer Datenbankabfrage, meist nach einem fetchAll() oderfind().

Zend_Form Zend_Form vereinfacht die Erstellung und Handhabung vonFormularen in einer Webanwendung.

Zend_Form verwendet andere Zend Framework Komponenten(unter anderem Zend_Filter und Zend_Validator), um seineZiele zu erfüllen.

Zend_LayoutZend_View

Zend_Layout und Zend_View werden für die Darstellungverwendet.

Zend_Locale Dient zur Lokalisierung. Zur Internationalisierung werdenfolgende Klassen verwendet: Zend_Date, Zend_Measure,Zend_Translate, Zend_Currency und Zend_TimeSync.

Zend_Navigation Zend_Navigation kann zur Erstellung von Navigationsmenusoder Breadcrumbs verwendet werden.

Zend_Session Hilft beim Verwalten und Aufbewahren von Session DatenZend_Validate Die Zend_Validate Komponente bietet ein Set von üblich

verwendeten Prüfungverfahren um Nutzereingaben zuvalidieren.

Zend_Filter ein Filter wird typischerweise für das entfernen vonunerwünschten Teilen einer Eingabe verwendet.

Benutzerdefinierte Klassen

Actions extends Zend_Db_Table_Abstract

AddressTypes extends Zend_Db_Table_Abstract

Addresses extends Zend_Db_Table_Abstract

Categories extends Zend_Db_Table_Abstract

Cities extends Zend_Db_Table_Abstract

Countries extends Zend_Db_Table_Abstract

Customers extends Zend_Db_Table_Abstract

Manufacturers extends Zend_Db_Table_Abstract

OrderState extends Zend_Db_Table_Abstract

Orders extends Zend_Db_Table_Abstract

OrderProducts extends Zend_Db_Table_Abstract

PaymentTypes extends Zend_Db_Table_Abstract

4

ProductMedias extends Zend_Db_Table_Abstract

Product extends Zend_Db_Table_Abstract

ProductsShipments extends Zend_Db_Table_Abstract

Shipments extends Zend_Db_Table_Abstract

Titles extends Zend_Db_Table_Abstract

2.1.4 Das Model

wird in PHP als Zend_Db_Table_Abstract implementiert stellt Operationen bereit, die dann vom Controller zur Umsetzung von Ereignissen

genutzt werden können, stellt Zustandsinformationen bereit, die dann vom View abgerufen werden können, um

Daten darzustellen akzeptiert Anmeldungen von Ereignisempfängern und benachrichtigt diese über

Änderungen seiner Zustände. Das Model wird vom View benutzt, um bei Änderungen der Daten die Darstellung

aktualisieren zu können. verwendet die bereits erwähnte Library (Zend Framework)

5

6

Abbildung 3: Klassenmodell

2.1.5 Die View

Wird zu Darstellung von Daten verwendet und zur Interaktion der Applikation mit einemNutzer. Bei einer Nutzer Aktion fordert die View Daten vom Controller an und stelltanschließend die vom Model gelieferten Ergebnismengen als Menschen lesbare Information zurVerfügung.

2.2 Portal Sitemap

2.3 Die Rechteverteilung

Benutzer haben einen Benutzernamen, ein Passwort, eine Rolle sowie eine Liste vonzugeordneten Ressourcen (Controllern) zur Interaktion. Der Benutzername und das Passwortdienen der Identifikation des Benutzers beim Login. Die folgende Tabelle zeigt dieZugriffsverteilung.

Tätigkeit RollenAdministrator Mitglied Gast

Registrieren xAnmelden xAbmelden x xPasswort abfordern x xPersönliche Daten anzeigen lassen x xPersönliche Daten aktualisieren x xBestellungen anzeigen lassen x xBestellungen verwalten xBenutzer verwalten xAngebote verwalten xAngebote anzeigen lassen x xProduktdetails anzeigen lassen x x

7

Abbildung 4: Sitemap

Produkte dem Warenkorb hinzufügen x xProduktanzahl im Warenkorb ändern x xKaufvorgang x xService x x x

3 Die ModuleDie Module sind jeweils nach MVC in drei Teile gegliedert, nämlich in dasoberflächenunabhängige „Model“, das für die Ausgabe zuständige „View“ und den für dieInterpretation von Eingabeereignissen zuständigen „Controller“.Detailliere Dokumentation zu den Klassen der Controller und des Models können auch alsPhpDoc eingesehen werden.

3.1 Shop Modul

Das "Shop"-Modul bildet eine „Übernavigation“ zu den verschiedenen Aktions-Clubs Shopping-Angebote, Reisen-Angebote, Money-Angebote. Drei Buttons zur Clubauswahl bilden dieHauptnavigation, welche dann die Navigationsmenüs vom ausgewählten ClubController laden.Das Modul liefert eine Startseite mit Angeboten aus allen 3 Rubriken. Außerdem ermöglichtdieses Modul dem Benutzer sich einzuloggen, zu registrieren oder ein neues Passwortanzufordern, sowie den Warenkorb zu verwalten. Das Einloggen ist essenziell zur Benutzungder Applikation notwendig.

3.1.1 View

Dieser Bereich wird von jedem Kunden benutzt. Der Shop hat das folgende Layout:

8

Abbildung 5: View_Produktansicht

Navigation: Bietet die Möglichkeit in der Applikation zu navigierenlinke Seite: zeigt unsere Facebookanhänger und Twitter NachrichtenContent Teil: Anzeige der Aktion des Tages oder von Sonderaktionen aller 3 Bereiche.Warenkorb: Zeigt die Informationen im Warenkorb des jeweiligen Kunden an. Falls der Kundenichts im Warenkorb hat, ist dieser deaktiviert.„Zum Warenkorb Hinzufügen“ Button: Damit fügt der Kunde die Produkte zum Warenkorbhinzu.Die Fußnavigation am Seitenende stellt kleine Buttons für Hilfe, Kontakt, AGB, Datenschutzund Impressum zur Verfügung.

3.1.2 ShopController

Das Shop Modul definiert die Zend Framework MVC Controller Objekte: IndexController.

3.1.3 ShopModellKlassen

Für dieses Modul werden die Zend_DB_Table-Objekte Category, Product, Customer für denIndexController sowie eine Klasse Cart definiert.

3.2 ClubShopping Modul

Dieses Modul die Funktionen für den ShoppingStar Bereich bereit. Die Controller für Reisen undGeld.de werden analog aufgebaut, sind aber in dieser Version noch ohne Funktion.

Die ClubController laden die Bereichs-Navigation aus der Datenbank und stellen dieAktionsprodukte eines gewählten Bereiches Grafisch dar.

9

3.2.1 Portal View

Die Navigation des Bereichs wird auf der linken Seite über den Community Informationen alsGrafik dargestellt.Im Content Bereich, in der Mitte, werden die Angebote, Ihre Laufzeit, der Bestand, der Preissowie sonstige Informationen zum Produkt angezeigt. Laufzeit (Timer), Bestand und Preis sindbesonders hervorzuheben.

3.2.2 Klassen

Für dieses Modul werden die Klassen Zend_Navigation, Product, Category, Customerverwendet.

3.3 Warenkorb Modul

Das „Warenkorb“ Modul ist das Modul, das es dem Benutzer ermöglicht, Produkte zu einerBestellung zusammenzustellen. Das Modul bietet auch die Möglichkeit, die Anzahl dervorgemerkten Produkte zu ändern und zur Kasse zu gehen.

10

Abbildung 6: Portallayout

3.3.1 View

3.4.1 View

Login Formular: Erlaubt es dem Benutzer sich einzuloggen Steuerungsleiste: Nachdem sich der Benutzer eingeloggt hat, stellt die Applikation eine Seitemit einem Menü zur Kundendatenverwaltung bereit, sowie die bisherigen ausgeführenBestellungen des Nutzers. Das Menü beinhaltet:o „Bestellungen anzeigen“ Button: damit lässt sich der Benutzer seine bisherigenBestellungen inklusive Bearbeitungsstatus anzeigen (Default). o „Daten anzeigen“ Button: damit lässt sich der Benutzer seine persönliche Datenanzeigen. Ihm wird eine Übersicht aller im System für Ihn registrierten Liefer-. undRechnugnsadressen angezeigt. Welche er ändern aber nicht löschen kann.

3.4.2 CustomerController

Das Benutzerverwaltung Modul definiert einen Zend Framework MVC Controller Objekt:CustomerController.

13

Abbildung 9: View_UserLogin-Registrierung

3.4.3 CustomerModellKlassen

Für dieses Modul werden fünf Zend_DB_Table-Objekte definiert:

Customer, Address, Order, Product und OrderDetails.

14

3.5 Administrator Modul

Dieses Modul ermöglicht es dem Administrator sich im in einem separaten Frontendeinzuloggen und die Benutzer- und Bestelldaten zu verwalten. Weiterhin können hier Aktionenangelegt und verwaltet, sowie Produktdaten aktualisiert werden.

3.5.1 View

Login Formular: Erlaubt es dem Content-Manager sich einzuloggen.

3.5.2 AdminController

Das Administrator Modul definiert ein Zend Framework MVC Controller Objekt:AdminController.

3.5.3 AdminModellKlassen

Für dieses Modul werden die Zend_DB_Table-Objekte Address, Category, Customer, Order,OrderProduct, Product sowie ein WSDLMapper definiert.

15

4 Prozesse

4.1 Shopprozesse

4.1.1 Produktinformationsprozess

Objekte: View, ClubShoppingController, Product

Ablauf:

1. Der Kunde hat eine Kategorie gewählt oder eine Page für die Kampagnen aufgerufen.2. Die Produkte werden aufgelistet.3. Der Kunde drückt den Button „detaillierte Informationen“ .4. Die Methode detailsAction() der ClubShoppingController wird aufgerufen.

detailsAction():

1. Bekommt die ID über den Button. Die ID des Produkts dient als Parameter, wonach es in der product Tabelle gesucht wird.

2. Die product Tabelle wird abgefragt und die Ergebnisdetails zurückgeliefert. 3. Das entsprechende View wird zur Darstellung verwendet.4. Klickt der Kunde den Button „zum Warenkorb hinzufügen“ an, wird das Produkt in den

Warenkorb gelegt.

10. Bestätigung und Prüfen des Validierungslinks.

11. Der Kunde kann sich einloggen.

checkAction():

1. Falls die E-Mail-Adresse oder das Passwort falsch ist

2. Dem Benutzer wird eine Fehlermeldung „E-Mail oder Passwort falsch“ angezeigt

3. Falls eine E-Mail existiert

4. Dem Benutzer wird eine Fehlermeldung „E-Mail bereits im System“ angezeigt.

5. In beiden Fällen wird ihm ermöglicht die Korrektur seiner Eingaben durchzuführen.

6. Ist die Anwendung mit allen Änderungen des neuen Kunden einverstanden, geht der Prozess im „Bestätigen“ Bereich weiter, wo der Kunde um eine nochmalige Bestätigung aller Eingaben gebeten wird.

4.1.4 Loginprozess

Objekt: View, CustomerController, Customer, Zend_Session, Zend_Auth

Ablauf:

1. Der Benutzer bekommt das Loginfeld bei jedem Seitenbesuch automatisch angezeigt.

2. Der Benutzer hat2 Möglichkeiten: sich einzuloggen oder ein Passwort anzufordern, falls er sein Passwort vergessen hat

3. 1) Falls der Benutzer schon registriert ist und sich einloggen möchte:

4. Benutzt er die Eingabemaske, wo er sich durch die Eingabe seiner E-Mail und des von ihm angegebenen Passworts identifizieren muss.

5. Nach Drücken des dort erscheinenden „Login“ Buttons wird die Methode authAction() des CustomerControllers aufgerufen.

6. 2) Falls der Benutzer auf den Link „Benutzername oder Passwort vergessen?“ klickt:

7. Wird die Methode lostpasswordAction() des CustomerControllers aufgerufen.

AuthAction()

1) Falls der Benutzername und/oder das Passwort falsch ist

1. Bekommt der Benutzer erneut die Möglichkeit sich einzuloggen, muss aber zusätzlich ein Captcha bestätigen.

2. 2) Falls der Benutzer sich identifizieren kann3. Wird er auf die Startseite geleitet und des Benutzername wird als Zend_Auth-Objekt in

einer Zend_Session gespeichert.

lostpasswordAction():

19

1. Der Benutzer wird zum Bereich „Passwort anfordern“ umgeleitet, wo er ein neues Passwort und Benutzername anfordern kann.

4.1.5 Warenkorbverwaltungsprozess

Objekte: View, CartController, Cart

4.1.6 Einkaufprozess

Der Kaufvorgang beginnt mit der Anzeige der Produkte. Die Produkte können über dieLandingpage oder über den Kategoriebaum der Bereiche angezeigt werden. Die aufgelistetenProdukte können zum Warenkorb hinzugefügt werden.

Objekte: View, OrderController, Customer, Address, Paypal, Bills, Order, OrderDetails

Ablauf:

1. Der Kunde drückt den Button „Zum Warenkorb hinzufügen“.2. Das Produkt wird im virtuellen Warenkorb abgelegt und somit für die Session

gespeichert.3. Der Kunde wird zur Kasse weitergeleitet, kann aber jederzeit wieder in den Shop

wechseln.4. Ein Formular zur Auswahl seiner Versandadressen und Rechnugnsadressen wird

dargestellt .5. Der Kunde wählt eine Adresse aus oder gibt eine neue ein.6. Über einen Button „weiter“ geht es zur Bezahlung.7. Der Kunde wählt entweder Vorkasse, PayPal oder Kreditkartenzahlung aus der Auswahl

aus.8. Der Kunde drückt den Button „weiter“. 9. Eine Bestellübersicht (Produkte, Produktmengen, Preise, Gesamtpreis und

Zahlungsart) wird dargestellt.10. Der Kunde drückt den Button „Fertigstellen“.11. Es wird denn entweder die Methode banktransferAction() bzw. paypalAction()

bzw. creditcardAction() aufgerufen.12. Eine E-Mail mit der Bestellübersicht wird an den Kunde gesendet.13. Dem Kunden wird die Bestellnummer angezeigt und er kann wieder zur Startseite

gelangen.

BanktransferAction():

1. Die Bestellungsdaten: Bestellung ID, Kunden ID, Lieferadressen ID, Rechnungsdatum, Rechnungsbetrag und Zahlart werden in die Tabelle order gespeichert

2. Die Bestellungsdetails werden in die Tabelle orderdetails gespeichert. 3. Eine Übersichtsseite mit der Rechnung wird dem Kunden angezeigt.4. Diese Übersichtsseite wird per E-Mail versendet. Die bei der Registrierung angegebene

E-Mail-Adresse wird verwendet.

PaypalAction()

1. Die Bestellungsdaten: Bestellung ID, Kunden ID, Lieferadressen ID, Rechnungsdatum, Rechnungsbetrag und Zahlart werden in die Tabelle order gespeichert.

2. Die Bestellungsdetails werden in die Tabelle orderdetails gespeichert.3. Die PayPal API Schnittstelle wird aufgerufen um die Zahlung abzuschließen.

CreditcardAction()

1. Die Bestellungsdaten: Bestellung ID, Kunden ID, Lieferadressen ID, Rechnungsdatum, Rechnungsbetrag und Zahlart werden in die Tabelle order gespeichert .

22

2. Die Bestellungsdetails werden in die Tabelle orderdetails speichern. 3. Prüft, ob der Kunde als vertrauenswürdig gilt (vorerst über bisherige Bestellungen,

später in Kombination mit einem CheckSystem)4. Wird an die API des Kreditkarteninsitutes weitergeleitet und muss dort seine Daten

angeben, nach Bestätigung durch das Institut gilt die Ware als bezahlt.

23

4.1.7 Versand

Abbildung 17: Sequenzdiagramm - Versand

4.2 Benutzerprozesse

4.2.1 Datenänderungsprozess

Objekte: View, CustomerController, Customer, Address

Ablauf:

1. vgl. 4.1.3 Registrierungsprozess

2. Nach erfolgreicher Anmeldung gelangt der Benutzer zum Bereich „Benutzerverwaltung“. Dort bekommt er eine Übersicht über seine Bestellungen und einen Link für seine persönlichen Adressdaten.

3. Zum Ändern seiner Daten bekommt der Benutzer die Möglichkeit seine bereits eingetragenen Adressen vor auszuwählen und zu ändern (allerdings wird hier auch eine neue Adresse erzeugt) oder eine neue Adresse hinzuzufügen.

4. Nach dem Drücken des „Daten anzeigen“ Buttons, wird ein Formular dargestellt, welches bereits mit den persönlichen Daten vor ausgefüllt ist.

5. Im unteren Bereich dieser Eingabemaske befinden sich zwei Buttons „Änderungen bestätigen“ und „Änderungen verwerfen“.

6. → Beim Drücken auf „Änderungen verwerfen“ Button, wird der Benutzer zum „Benutzerverwaltungs“ Bereich umgeleitet.

7. → Falls der Benutzer bestimmte Änderungen durchgeführt hat, drückt er den „Änderungen bestätigen“ Button und wird auf den „Benutzerverwaltungs“ Bereichumgeleitet.

8. Die Methode updateAction() des CustomerControllers wird aufgerufen

updateAction()

1. Die Daten werden in den Datenbank Tabellen customer aktualisiert. In die Tabelle address wird eine neue Adresse eingetragen und eine eventuell vorausgewählte auf inaktiv gesetzt.

24

orderAction():

1. Der Benutzer wird eine Liste seiner Bestellungen angezeigt und kann Details zubestimmten Bestellungen einsehen, indem er die einzelne Bestellung aus der Übersichtslisteauswählt (ähnlich dem Warenkorb aber ohne Änderungsmöglichkeit und zusätzlich mit Anzeigedes Bearbeitungsstatus).

4.3 Administratorprozesse

4.3.1 Verwaltungsprozess für Benutzerdaten

Objekte: AdminController, Customer

Ablauf:

1. Der Administrator meldet sich über ein vom Shop unabhängiges Formular an.

2. Nach erfolgreicher Anmeldung, können Daten zu Benutzern eingesehen und geändertwerden.

4.3.2 Verwaltungsprozess für Bestelldaten

Objekte: AdminController, Order

Ablauf:

1. Der Administrator meldet sich über ein vom Shop unabhängiges Formular an.

2. Nach erfolgreicher Anmeldung, können Bestelldaten eingesehen und geändert werden.

4.3.3 AktiongenerierungsProzess

Objekte: AdminController, CSV-Mapper

Ablauf:

1. Der Administrator meldet sich über ein vom Shop unabhängiges Formular an.

2. Es wird eine Kategorie gewählt oder hinzufügt.

3. Zu dieser Kategorie kann ein neues Produkt aus einer csv-Datei ausgelesen werden.

4. Anschließend werden Aktionsdaten wie Zeitfenster und Verkaufsmenge festgelegt und gespeichert.

27

4.4 Qualitätsanforderungen - Coding-Standard

Es muss der Zend-Coding-Standard eingehalten werden, dies beinhaltet hauptsächlich:

• PHP Dateiformatierung

• Namens Konventionen

• Code Stil

• Inline-Dokumentation

4.5 Datenbank

Für die Datenbankabfragen darf ausschließlich Zend_Db_Select verwendet werden.

4.6 PHP Dateiformatierung

• allgemein: Für Dateien, welche nur PHP Code beinhalten ist der schließende Tag ("?>")nicht zugelassen. Er wird von PHP nicht benötigt, und das Weglassen verhindert dasversehentlich Leerzeilen in die Antwort eingefügt werden.

• Einrücken: Ein Einzug sollte aus 4 Leerzeichen bestehen. Tabulatoren sind nicht erlaubt.

• maximale Zeilenlänge: Die maximale Länge einer PHP Codezeile beträgt 120 Zeichen.

• Zeilenbegrenzung: Die Zeilenbegrenzung folgt der Unix Textdatei Konvention. Zeilenmüssen mit einem einzelnen Zeilenvorschubzeichen (LF) enden. Zeilenvorschub-Zeichenwerden durch eine ordinale 10, oder durch 0x0A (hexadezimal) dargestellt.Beachte: Benutze nicht den Wagenrücklauf (CR) wie in den Konventionen von Apple's OS(0x0D) oder die Kombination aus Wagenrücklauf und Zeilenvorschub (CRLF) wie im Standardfür das Windows OS (0x0D, 0x0A).

4.7 Namens Konventionen

Funktionen und Methoden:

• Funktionsnamen dürfen nur Buchstaben enthalten. Unterstriche sind nicht gestattet.Nummern sind in Funktionsnamen nicht gestattet.

• Funktionsnamen müssen immer mit einem Kleinbuchstaben anfangen. WennFunktionsnamen aus mehr als einem Wort bestehen, muss der erste Buchstabe jeden Wortesgroßgeschrieben werden. Das wird normalerweise "camelCase" Formatierung genannt.

• Wortreichtum wird generell befürwortet. Funktionsnamen sollten so wortreich wiemöglich sein um deren Zweck und Verhalten zu erklären.

• Für objekt-orientiertes Programmieren, sollten Zugriffspunkte für Instanzen oderstatische Variablen immer mit "get" oder "set" beginnen. Wenn Design-Pattern implementiertwerden, wie Singleton oder das Factory Pattern, sollte der Name der Methode den Namen desPattern enthalten wo es praktikabel ist, um das Verhalten besser zu beschreiben.

• Für Methoden in Objekten die mit dem "private" oder "protected" Modifikator deklariertsind, muss das erste Zeichen des Namens der Methode ein einzelner Unterstrich sein. Das istdie einzige akzeptable Anwendung von einem Unterstrich im Namen einer Methode. Methodendie als "public" deklariert sind sollten nie einem Unterstrich enthalten.

• Funktionen im globalen Bereich (auch "floating functions" genannt) sind nicht gestattet.Diese Funktionen sollten in einer statischen Klasse gewrappt werden.

29

Variablen:

• Variablennamen dürfen nur alphanumerische Zeichen enthalten. Unterstriche sind nichtgestattet. Nummern sind in Variablen gestattet in den meisten Fällen aber nicht empfohlen.

• Für Instanzvariablen die mit dem "private" oder "protected" Modifikator deklariertwerden, muss das erste Zeichen des Funktionsnamens ein einzelner Unterstrich sein. Das istdie einzige akzeptierte Anwendung eines Unterstriches in einem variablen Namen.Klassenvariablen welche als "public" deklariert werden sollten nie mit einem Unterstrichbeginnen.

• Wie bei Funktionsnamen (siehe Abschnitt 3.3) müssen Variablennamen immer miteinem Kleinbuchstaben starten und der "camelCaps" Schreibweise folgen.

• Wortreichtum wird generell befürwortet. Variablen sollen immer so wortreich wiemöglich sein um die Daten zu beschreiben die der Entwickler in Ihnen zu speichern gedenkt.Gedrängte Variablennamen wie "$i" und "$n" sind außer in kleinsten Schleifen verboten. Wenneine Schleife mehr als 20 Codezeilen enthält sollten die Index-Variablen einen ausführlicherenNamen haben.

Konstanten:

• Konstanten können beides enthalten, sowohl alphanumerische Zeichen als auchUnterstriche. Nummern sind in Konstantennamen gestattet.

• Alle Buchstaben die in Konstantenname verwendet werden müssen großgeschriebenhaben, während Wörter in einem Konstantennamen durch Unterstriche getrennt werdenmüssen.

• Konstanten müssen als Klassenkonstanten definiert werden mit dem "const" Modifikator.Von einer Definition von Konstanten im globalen Bereich mit der "define" Funktion wirdstärkstens abgeraten.

4.8 Code Stil

PHP Code Abgrenzung:

• PHP Code muss immer mit der kompletten Form des Standard-PHP Tags abgegrenztsein. Kurze Tags sind nie erlaubt. Für Dateien die nur PHP Code enthalten, darf das schließende

Tag nie angegeben werden.

Strings:

• String Literale: Wenn ein String ein Literal ist (er also keine Variablenvertreter enthält),sollte immer das Apostroph oder "einzelne Anführungszeichen" verwendet werden um denString abzugrenzen.

Wenn ein literaler String selbst Apostrophe enthält, ist es gestattet den String mitAnführungszeichen oder "doppeltes Anführungszeichen" abzugrenzen. Das ist speziell für SQLAnweisungen nützlich. Diese Syntax ist zu bevorzugen, im Gegensatz zum Ausbruch vonApostrophs, da Sie viel einfacher lesbar ist.

• Variabler Austausch: Variabler Austausch ist nicht gestatten, man muss Variablenimmer verbinden.

• Verbinden von Strings: Strings müssen verbunden werden indem man den "." Operatorverwendet. Ein Leerzeichen muss immer vor und nach dem "." Operator hinzugefügt werdenum die Lesbarkeit zu erhöhen.

Bei langen Strings, ist es empfohlen die Anweisung in mehrere Zeilen umzubrechen um dieLesbarkeit zu erhöhen. In diesen Fällen sollte jede folgende Zeile mit Leerraum aufgefülltwerden so das der "." Operator genau unterhalb des "=" Operators ist.

Arrays:

30

• Nummerisch indizierte Arrays: Negative Nummern sind in Indizes nicht gestattet. Einindiziertes Array kann mit irgendeiner nicht-negativen Nummer beginnen, trotzdem sind alleBasisIndex neben 0 nicht erlaubt. Wenn indizierte Arrays mit dem Array Funktion deklariertwerden, muss ein folgendes Leerzeichen nach jeder Kommaabgrenzung hinzugefügt werdenum die Lesbarkeit zu erhöhen.

Es ist gestattet mehrzeilige indizierte Arrays zu definieren bei Verwendung des "array"Konstrukts. In diesem Fall, muss jede folgende Zeile mit Leerzeichen aufgefüllt werden so dasder Beginn jeder Zeile ausgerichtet ist. Wenn das so ist, muss das beginnende Array Elementin der folgenden Zeile beginnen und es muss ein Einrückungslevel tiefer stehen als die Zeilewelche die Array Deklaration enthält und alle folgenden Zeilen sollten die gleiche Einrückunghaben; der schließende Teil sollte in einer eigenen Zeile stehen und das gleicheEinrückungslevel haben wie die Zeile welche die Array Deklaration enthält. Es ist nichtgestattet ein Komma für das letzte Element in Array zu verwenden.

• Assoziative Arrays: Wenn assoziative Arrays mit dem Array Konstrukt deklariert werden,ist das Umbrechen der Anweisung in mehrere Zeilen erforderlich. In diesem Fall muss jedefolgende Linie mit Leerraum aufgefüllt werden so das beide, der Schlüssel und der Wertuntereinander stehen. Das beginnende Array Element muss in der folgenden Zeile beginnenund um ein Einrückungslevel tiefer stehen als die Zeile welche die Array Deklaration enthältund alle folgenden Zeilen sollten die gleiche Einrückung haben; der schließende Teil sollte ineiner eigenen Zeile stehen und das gleiche Einrückungslevel haben wie die Zeile welche die

⇒Array Deklaration enthält. Wegen der Lesbarkeit sollten die verschiedenen " " Operatoren soeingerückt werden das Sie untereinander stehen. Es ist nicht gestattet ein Komma für dasletzte Element in Array zu verwenden.

Klassen:

• Klassen Deklarationen: Die Klammer muss immer in der Zeile unter dem Klassennamengeschrieben werden. Jede Klasse muss einen Dokumentationsblock haben der demPHPDocumentor Standard entspricht. Jeder Code in der Klasse muss mit vier Leerzeicheneingerückt sein. Nur eine Klasse ist in jeder PHP Datei gestattet. Das Platzieren vonzusätzlichem Code in Klassendateien ist nicht gestattet.Klassen die andere Klassen erweitern oder welche Interfaces implementieren sollen IhreAbhängigkeit auf der gleichen Zeile deklarieren wenn das möglich ist.Wenn als Ergebnis so einer Deklaration, die Länge der Zeile die Maximale Zeilenlängeüberschreitet, ist die Zeile vor dem "extends" und oder "implements" Schlüsselwortumzubrechen und diese Zeilen um ein Einrückungslevel einzurücken.Wenn die Klasse mehrere Interfaces implementiert und die Deklaration die maximaleZeilenlänge übersteigt, ist nach jedem Komma umzubrechen und die Interfaces zu separieren,und die Namen des Interfaces so einzurücken das Sie untereinander stehen.

31

Die Reihenfolge in den Klassen sollte die folgende sein:

class SampleClass

{

const CONSTANT = 1;

public $publicVar = 1;

protected $_protectedVar = 1;

private $_privateVar = 1;

public __construct()

{}

public publicMethod()

{}

protected _protectedMethod()

{}

private _privateMethod()

{}

}

• Klassenvariablen: Klassenvariablen müssen entsprechend den Variablen-Benennungs-Konventionen des Unister Coding Standard benannt werden. Jede Variable die in der Klassedeklariert wird muss am Beginn der Klasse ausgelistet werden, vor der Deklaration von allenMethoden. Das var Konstrukt ist nicht gestattet. Klassenvariablen definieren Ihre Sichtbarkeitdurch die Verwendung des private, protected, oder public Modifikatoren. Das gestatten vondirektem Zugriff auf Klassenvariablen durch deren Deklaration als public ist gestattet aber eswird davon abgeraten da hierfür Zugriffsmethoden verwendet werden sollten (set & get).

Funktionen und Methoden:

• Deklaration von Funktionen und Methoden: Funktionen müssen nach der Funktions-Namenskonvention des Unister Coding Standard benannt werden. Methoden innerhalb vonKlassen müssen immer Ihre Sichtbarkeit durch Verwendung einer der private, protected, oderpublic Modifikatoren definieren. Wie bei Klassen, sollte die Klammer immer in der Zeileunterhalb des Funktionsnamens geschrieben werden. Leerzeichen zwischen demFunktionsnamen und der öffnenden Klammer für die Argumente sind nicht erlaubt. VonFunktionen im globalen Raum wird komplett abgeraten.In den Fällen wo die Liste der Argumente die maximale Zeilenlänge überschreitet, solltenZeilenumbrüche eingeführt werden. Zusätzliche Argumente der Funktion oder Methode müssendurch einen zusätzlichen Einrückungslevel nach der Funktion oder Methodendeklarationeingerückt werden. Ein Zeilenumbruch sollte dann vor dem schließenden Argument stattfinden,welcher in der gleichen Zeile platziert werden sollte wie die öffnende Klammer der Funktionoder Methode mit einem einzelnen Leerzeichen das die zwei trennt, und mit dem gleichenEinrückungslevel wie die Deklaration der Funktion oder Methode.

Es ist nicht erlaubt über 10 Parameter für eine Funktion zu definieren, dafür sollte manContainer benutzen. Hinweis: Notiz: Die Übergabe per Referenz ist die einzige erlaubtMechanismus für die Übergabe von Parametern in der Deklaration einer Funktion.Der Aufruf durch Referenz ist nicht gestattet. Der Rückgabewert darf nicht in Klammernstehen. Das kann die Lesbarkeit behindern und zusätzlich den Code unterbrechen wenn eine

32

Methode später auf Rückgabe durch Referenz geändert wird.

• Verwendung von Funktionen und Methoden: Funktionsargumente sollten durch eineinzelnes trennendes Leerzeichen nach dem Komma Trennzeichen getrennt werden.Übergabe von Referenzen zur Laufzeit ist strengstens verboten. Siehe die Sektion für FunktionsDeklarationen für den richtigen Weg um Funktionsargumente per Referenz zu übergeben.Durch die Übergabe von Arrays als Argument für eine Funktion, kann der Funktionsaufruf den"array" Hinweis enthalten und kann in mehrere Zeilen geteilt werden um die Lesbarkeit zuerhöhen. In solchen Fällen sind die normalen Richtlinien für das Schreiben von Arrays trotzdemnoch anzuwenden.

Kontrollanweisungen:

• If/Else/Elseif: Kontrollanweisungen die auf den if und elseif Konstrukten beruhenmüssen ein einzelnes Leerzeichen vor der öffnenden Klammer der bedingten Anweisung undein einzelnes Leerzeichen nach der schließenden Klammer. Innerhalb der bedingtenAnweisungen zwischen den Klammern, müssen die Operationen, für die Lesbarkeit, durchLeerzeichen getrennt werden. Innere Klammern sind zu befürworten um die logischeGruppierung für größeren bedingte Anweisungen zu erhöhen. Die öffnende Klammer wird inder selben Zeile geschrieben wie die Bedingungsanweisung. Die schließende Klammer wirdimmer in einer eigenen Zeile geschrieben. Jeder Inhalt innerhalb der Klammer muss durchVerwendung von vier Leerzeichen eingerückt werden. Wenn die Kontrollanweisung die Ursachefür eine Überschreitung der maximalen Zeilenlänge ist und sie mehrere Anweisungen hat, kanndie Kontrollanweisung in mehrere Zeilen gebrochen werden. In solchen Fällen, ist die Zeile vordem logischen Operator zu brechen und die Zeile so einzurücken das Sie unter dem erstenZeichen der Kontrollanweisung steht.

Der schließende Teil der Kontrollanweisung ist mit der öffnenden Klammer in einer eigenenZeile zu platzieren, wobei ein einzelnes Leerzeichen die zwei trennen muss, und derEinrückungslevel identisch mit der öffnenden Kontrollanweisung sein ist.Die Einrückung des späteren Deklarationsformats dient der Vorbeugung von Problemen beimHinzufügen oder entfernen von Klauseln von der Kontrollanweisung bei späteren Revisionen.Für if Anweisungen die elseif oder else beinhalten, sind die Konventionen der Formatierungähnlich dem if Konstrukt. Das folgende Beispiel zeigt gültige Formatierungen für ifAnweisungen mit else und/oder elseif Konstrukten: PHP erlaubt das Anweisungen in einigen Fällen auch ohne Klammern zu schreiben. DieserCoding Standard macht keine Unterscheidungen und es müssen alle if, elseif oder elseAnweisungen in Klammern geschrieben werden.

• Switch: Kontrollanweisungen die mit der switch Anweisung geschrieben werden müssenein einzelnes Leerzeichen vor der öffnenden Klammer der Bedingten Anweisung besitzen, undauch nach der schließenden Klammer. Jeglicher Inhalt innerhalb der switch Anweisung mussdurch Verwendung von vier Leerzeichen eingerückt sein. Der Inhalt unter jeder caseAnweisung muss durch Verwendung von vier zusätzlichen Leerzeichen eingerückt werden.

Das default Konstrukt darf nie bei der switch Anweisung vergessen werden.

33

4.9 Inline-Dokumentation

Dokumentations Format:

Alle Dokumentationsblöcke ("DocBlock") müssen mit dem phpDocumentor Format kompatibelsein. Für weiterführende Informationen siehe: http://phpdoc.org. Alle Klassen-Dateien müsseneinen "file-level" DocBlock am Beginn jeder Datei enthalten.

Dateien:

Jede Datei die PHP Code enthält muss einen !DocBlock am Beginn der Datei besitzen welchermindestens diese phpDocumentor Tags enthält.

/**

* Kurze Beschreibung der Datei

*

* Lange Beschreibung der Datei (wenn vorhanden)...

*

* @category Clubshopping

* @package Clubshopping_Db

* @subpackage Adapter

* @copyright Copyright (c) 2010 <Firma> GmbH

* @version $Id:$

*/

Hinweis: Notiz: Damit $Id:$ auch funktioniert, muss man die svn:keywords aktivieren

Klassen:

Jede Klasse muss einen DocBlock haben welche mindestens diese phpDocumentor Tagsenthält:

/**

* Kurze Beschreibung der Klasse

*

* Lange Beschreibung der Klasse (wenn vorhanden)...

*

* @category Clubshopping

* @package Clubshopping_Db

* @subpackage Adapter

* @copyright Copyright (c) 2010 <Firma> GmbH

*/

Funktionen:

Jede Funktion, auch Objekt Methoden, muss einen DocBlock haben welcher mindestensfolgendes enthält: Eine Beschreibung der Funktion, alle Argumente, alle möglichenRückgabewerte. Es ist nicht notwendig das "@access" Tag zu verwenden, weil das Accesslevelbereits vom "public", "private" oder "protected" Modifikator bekannt ist wenn die Funktiondeklariert wird.

34