club.shopping.de Inhaltsverzeichnis Entwurf Projekt: club Portal für shopping.de Autor: Unister GmbH letzte Änderung:

Transkript

1 Entwurf club.shopping.de Projekt: club Portal für shopping.de Autor: Unister GmbH letzte Änderung: Inhaltsverzeichnis 1 Einführung Übersicht über Komponenten Struktur und Beziehungen MVC Datenbank Librarys Das Model Die View Portal Sitemap Die Rechteverteilung Die Module Shop Modul View ShopController ShopModellKlassen ClubShopping Modul Portal View Klassen Warenkorb Modul View OrderController OrderModellKlassen Benutzerverwaltung Modul View CustomerController CustomerModellKlassen Administrator Modul View AdminController AdminModellKlassen Prozesse Shopprozesse Produktinformationsprozess Kategorienavigationsprozess Registrierungsprozess...17

2 4.1.4 Loginprozess Warenkorbverwaltungsprozess Einkaufprozess Versand Benutzerprozesse Datenänderungsprozess Bestellungsverwaltungsprozess Administratorprozesse Verwaltungsprozess für Benutzerdaten Verwaltungsprozess für Bestelldaten AktiongenerierungsProzess Qualitätsanforderungen - Coding-Standard Datenbank PHP Dateiformatierung Namens Konventionen Code Stil Inline-Dokumentation...34 Abbildungsverzeichnis Abbildung 1: MVC...1 Abbildung 2: Datenbankmodell...2 Abbildung 3: Klassenmodell...6 Abbildung 4: Sitemap...7 Abbildung 5: View_Produktansicht...8 Abbildung 6: Portallayout...10 Abbildung 7: View_Warenkorb...11 Abbildung 8: View_Kasse...12 Abbildung 9: View_UserLogin-Registrierung...13 Abbildung 10: Sequenzdiagramm - Produktinformation...16 Abbildung 11: Sequenzdiagramm - Kategorienavigation...17 Abbildung 12: Sequenzdiagramm - Registrierung...18 Abbildung 13: Sequenzdiagramm - UserLogin...20 Abbildung 14: Sequenzdiagramm - Warenkorbverwaltung...21 Abbildung 15: Sequenzdiagramm - Kasse_Start...23 Abbildung 16: Sequenzdiagramm - Kasse_Abschluss...23 Abbildung 17: Sequenzdiagramm - Versand...24 Abbildung 18: Sequenzdiagramm - Kundendaten...25 Abbildung 19: Sequenzdiagramm - Kundenbestellungen...26 Abbildung 20: Sequenzdiagramm - Administrator...28

3 1 Einführung Die Systemlandschaft für das Portalprojekt besteht aus einem Web und einem Datenbankserver. Diese sind über Balancer auf mehrere physische Server verteilt. Als Webserver steht ein Apache mit PHP5.2 auf einem Debian-Lenny-System bereit und als Datenbank wird MySQL-5.0 verwendet. 2 Übersicht über Komponenten Es 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 MVC Abbildung 1: MVC 1

4 Die Struktur der Applikation richtet sich strikt nach dem MVC-Architekturmuster. Dabei ist auf eine strenge Trennung zwischen den Einheiten Datenmodel (Model), Präsentation (View) und Programmsteuerung (Controller) zu achten. Die Geschäftslogik wird bei diesem Projekt soweit möglich im Model umgesetzt 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 den pdo_mysql MySQL Adapter. Abbildung 2: Datenbankmodell 2

5 2.1.3 Librarys Zend Framework und benutzerdefinierte Klassen, welche die Client-/Server-Applikation verwenden 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 gleiche Datenstruktur haben. Wir werden für die Speicherung der Daten jeweils eine Tabelle definieren, deren Spalten den Attributen beziehungsweise den Dateneinträgen der Objekte entsprechen. 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 Framework Zend_Application bietet die Möglichkeit des Bootstrappings, das einlesen von Konfigurationsdateien und das Autoloading von Klassen Zend_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 durch andere anfordernde Objekte zu kontrollieren. Rollen und Zugangsbeschränkungen werden definiert. Zend_Auth Zend_Auth_Adapter_DbTable bietet die Möglichkeit sich gegenüber Daten zu authentifizieren die in einer Datenbank Tabelle gespeichert sind. Zend_Captcha Kann zum Ausschluss von Bots in ungesicherten Formularen verwendet werden. Zend_Config Dient zum laden von Konfigurationsdateien, wahlweise im XML oder.ini Format. Zend_Controller Gewährleistet das Zusammenspiel zwischen den Zend_Controller_* Kind-Klassen um User-Requests an die Angeforderten Controller weiterzuleiten. Die Controller Architektur beinhaltet ein Pluginsystem, welches 3

6 Zend_Db Zend_Form Zend_Layout Zend_View Zend_Locale Zend_Navigation Zend_Session Zend_Validate Zend_Filter uns ermöglicht eigenen Code im Dispatch Prozess auszuführen. Parent Klasse für alle Datenbank bezogenen Aktionsklassen. Die statische Methode Zend_Db::factory() wird benutzt, um eine Instanz eines DB-Adapters zu erzeugen (z. B. Pdo_Mysql). (Anbindung einer Datenbank mit einem Adapter) Die Zend_Db_Table Klasse ist eine Objekt-Orientierte Schnittstelle zur Datenbank Tabellen. Die Zend_Db_Table_Row Klasse enthält eine einzelne Zeile eines Zend_Db_Table-Objekts. Sie besitzt Methoden für die Abfrage von verknüpften Zeilen in anderen Tabellen. Die Zend_Db_Table_Rowset Klasse besitzt mehrere Objecte nach einer Datenbankabfrage, meist nach einem fetchall() oder find(). Zend_Form vereinfacht die Erstellung und Handhabung von Formularen in einer Webanwendung. Zend_Form verwendet andere Zend Framework Komponenten (unter anderem Zend_Filter und Zend_Validator), um seine Ziele zu erfüllen. Zend_Layout und Zend_View werden für die Darstellung verwendet. Dient zur Lokalisierung. Zur Internationalisierung werden folgende Klassen verwendet: Zend_Date, Zend_Measure, Zend_Translate, Zend_Currency und Zend_TimeSync. Zend_Navigation kann zur Erstellung von Navigationsmenus oder Breadcrumbs verwendet werden. Hilft beim Verwalten und Aufbewahren von Session Daten Die Zend_Validate Komponente bietet ein Set von üblich verwendeten Prüfungverfahren um Nutzereingaben zu validieren. ein Filter wird typischerweise für das entfernen von unerwü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

7 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 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

8 Abbildung 3: Klassenmodell 6

9 2.1.5 Die View Wird zu Darstellung von Daten verwendet und zur Interaktion der Applikation mit einem Nutzer. Bei einer Nutzer Aktion fordert die View Daten vom Controller an und stellt anschließend die vom Model gelieferten Ergebnismengen als Menschen lesbare Information zur Verfügung. 2.2 Portal Sitemap Abbildung 4: Sitemap 2.3 Die Rechteverteilung Benutzer haben einen Benutzernamen, ein Passwort, eine Rolle sowie eine Liste von zugeordneten Ressourcen (Controllern) zur Interaktion. Der Benutzername und das Passwort dienen der Identifikation des Benutzers beim Login. Die folgende Tabelle zeigt die Zugriffsverteilung. Tätigkeit Rollen Administrator Mitglied Gast Registrieren x Anmelden x Abmelden x x Passwort abfordern x x Persönliche Daten anzeigen lassen x x Persönliche Daten aktualisieren x x Bestellungen anzeigen lassen x x Bestellungen verwalten x Benutzer verwalten x Angebote verwalten x Angebote anzeigen lassen x x Produktdetails anzeigen lassen x x 7

10 Produkte dem Warenkorb hinzufügen x x Produktanzahl im Warenkorb ändern x x Kaufvorgang x x Service x x x 3 Die Module Die Module sind jeweils nach MVC in drei Teile gegliedert, nämlich in das oberflächenunabhängige Model, das für die Ausgabe zuständige View und den für die Interpretation von Eingabeereignissen zuständigen Controller. Detailliere Dokumentation zu den Klassen der Controller und des Models können auch als PhpDoc 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 die Hauptnavigation, welche dann die Navigationsmenüs vom ausgewählten ClubController laden. Das Modul liefert eine Startseite mit Angeboten aus allen 3 Rubriken. Außerdem ermöglicht dieses Modul dem Benutzer sich einzuloggen, zu registrieren oder ein neues Passwort anzufordern, sowie den Warenkorb zu verwalten. Das Einloggen ist essenziell zur Benutzung der Applikation notwendig View Dieser Bereich wird von jedem Kunden benutzt. Der Shop hat das folgende Layout: Abbildung 5: View_Produktansicht 8

11 Navigation: Bietet die Möglichkeit in der Applikation zu navigieren linke Seite: zeigt unsere Facebookanhänger und Twitter Nachrichten Content Teil: Anzeige der Aktion des Tages oder von Sonderaktionen aller 3 Bereiche. Warenkorb: Zeigt die Informationen im Warenkorb des jeweiligen Kunden an. Falls der Kunde nichts im Warenkorb hat, ist dieser deaktiviert. Zum Warenkorb Hinzufügen Button: Damit fügt der Kunde die Produkte zum Warenkorb hinzu. Die Fußnavigation am Seitenende stellt kleine Buttons für Hilfe, Kontakt, AGB, Datenschutz und Impressum zur Verfügung ShopController Das Shop Modul definiert die Zend Framework MVC Controller Objekte: IndexController ShopModellKlassen Für dieses Modul werden die Zend_DB_Table-Objekte Category, Product, Customer für den IndexController sowie eine Klasse Cart definiert. 3.2 ClubShopping Modul Dieses Modul die Funktionen für den ShoppingStar Bereich bereit. Die Controller für Reisen und Geld.de werden analog aufgebaut, sind aber in dieser Version noch ohne Funktion. Die ClubController laden die Bereichs-Navigation aus der Datenbank und stellen die Aktionsprodukte eines gewählten Bereiches Grafisch dar. 9

12 3.2.1 Portal View Abbildung 6: Portallayout Die Navigation des Bereichs wird auf der linken Seite über den Community Informationen als Grafik dargestellt. Im Content Bereich, in der Mitte, werden die Angebote, Ihre Laufzeit, der Bestand, der Preis sowie sonstige Informationen zum Produkt angezeigt. Laufzeit (Timer), Bestand und Preis sind besonders hervorzuheben Klassen Für dieses Modul werden die Klassen Zend_Navigation, Product, Category, Customer verwendet. 3.3 Warenkorb Modul Das Warenkorb Modul ist das Modul, das es dem Benutzer ermöglicht, Produkte zu einer Bestellung zusammenzustellen. Das Modul bietet auch die Möglichkeit, die Anzahl der vorgemerkten Produkte zu ändern und zur Kasse zu gehen. 10

13 3.3.1 View

14

15 3.4.1 View Login Formular: Erlaubt es dem Benutzer sich einzuloggen Steuerungsleiste: Nachdem sich der Benutzer eingeloggt hat, stellt die Applikation eine Seite mit einem Menü zur Kundendatenverwaltung bereit, sowie die bisherigen ausgeführen Bestellungen des Nutzers. Das Menü beinhaltet: o Bestellungen anzeigen Button: damit lässt sich der Benutzer seine bisherigen Bestellungen inklusive Bearbeitungsstatus anzeigen (Default). o Daten anzeigen Button: damit lässt sich der Benutzer seine persönliche Daten anzeigen. Ihm wird eine Übersicht aller im System für Ihn registrierten Liefer-. und Rechnugnsadressen angezeigt. Welche er ändern aber nicht löschen kann. Abbildung 9: View_UserLogin-Registrierung CustomerController Das Benutzerverwaltung Modul definiert einen Zend Framework MVC Controller Objekt: CustomerController. 13

16 3.4.3 CustomerModellKlassen Für dieses Modul werden fünf Zend_DB_Table-Objekte definiert: Customer, Address, Order, Product und OrderDetails. 14

17 3.5 Administrator Modul Dieses Modul ermöglicht es dem Administrator sich im in einem separaten Frontend einzuloggen und die Benutzer- und Bestelldaten zu verwalten. Weiterhin können hier Aktionen angelegt und verwaltet, sowie Produktdaten aktualisiert werden View Login Formular: Erlaubt es dem Content-Manager sich einzuloggen AdminController Das Administrator Modul definiert ein Zend Framework MVC Controller Objekt: AdminController AdminModellKlassen Für dieses Modul werden die Zend_DB_Table-Objekte Address, Category, Customer, Order, OrderProduct, Product sowie ein WSDLMapper definiert. 15

18 4 Prozesse 4.1 Shopprozesse 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.

19

20

21 10. Bestätigung und Prüfen des Validierungslinks. 11. Der Kunde kann sich einloggen. checkaction(): 1. Falls die -Adresse oder das Passwort falsch ist 2. Dem Benutzer wird eine Fehlermeldung oder Passwort falsch angezeigt 3. Falls eine existiert 4. Dem Benutzer wird eine Fehlermeldung 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 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 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 kann 3. Wird er auf die Startseite geleitet und des Benutzername wird als Zend_Auth-Objekt in einer Zend_Session gespeichert. lostpasswordaction(): 19

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

23 4.1.5 Warenkorbverwaltungsprozess Objekte: View, CartController, Cart

24 4.1.6 Einkaufprozess Der Kaufvorgang beginnt mit der Anzeige der Produkte. Die Produkte können über die Landingpage oder über den Kategoriebaum der Bereiche angezeigt werden. Die aufgelisteten Produkte 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 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 versendet. Die bei der Registrierung angegebene -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

25 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

26 4.1.7 Versand Abbildung 17: Sequenzdiagramm - Versand 4.2 Benutzerprozesse Datenänderungsprozess Objekte: View, CustomerController, Customer, Address Ablauf: 1. vgl 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 Bereich umgeleitet. 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

27

28 orderaction(): 1. Der Benutzer wird eine Liste seiner Bestellungen angezeigt und kann Details zu bestimmten Bestellungen einsehen, indem er die einzelne Bestellung aus der Übersichtsliste auswählt (ähnlich dem Warenkorb aber ohne Änderungsmöglichkeit und zusätzlich mit Anzeige des Bearbeitungsstatus).

29 4.3 Administratorprozesse 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ändert werden 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 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

30

31 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 das versehentlich 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. Zeilen müssen mit einem einzelnen Zeilenvorschubzeichen (LF) enden. Zeilenvorschub-Zeichen werden 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 Standard fü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. Wenn Funktionsnamen aus mehr als einem Wort bestehen, muss der erste Buchstabe jeden Wortes großgeschrieben werden. Das wird normalerweise "camelcase" Formatierung genannt. Wortreichtum wird generell befürwortet. Funktionsnamen sollten so wortreich wie möglich sein um deren Zweck und Verhalten zu erklären. Für objekt-orientiertes Programmieren, sollten Zugriffspunkte für Instanzen oder statische Variablen immer mit "get" oder "set" beginnen. Wenn Design-Pattern implementiert werden, wie Singleton oder das Factory Pattern, sollte der Name der Methode den Namen des Pattern enthalten wo es praktikabel ist, um das Verhalten besser zu beschreiben. Für Methoden in Objekten die mit dem "private" oder "protected" Modifikator deklariert sind, muss das erste Zeichen des Namens der Methode ein einzelner Unterstrich sein. Das ist die einzige akzeptable Anwendung von einem Unterstrich im Namen einer Methode. Methoden die 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

32 Variablen: Variablennamen dürfen nur alphanumerische Zeichen enthalten. Unterstriche sind nicht gestattet. Nummern sind in Variablen gestattet in den meisten Fällen aber nicht empfohlen. Für Instanzvariablen die mit dem "private" oder "protected" Modifikator deklariert werden, muss das erste Zeichen des Funktionsnamens ein einzelner Unterstrich sein. Das ist die einzige akzeptierte Anwendung eines Unterstriches in einem variablen Namen. Klassenvariablen welche als "public" deklariert werden sollten nie mit einem Unterstrich beginnen. Wie bei Funktionsnamen (siehe Abschnitt 3.3) müssen Variablennamen immer mit einem Kleinbuchstaben starten und der "camelcaps" Schreibweise folgen. Wortreichtum wird generell befürwortet. Variablen sollen immer so wortreich wie mö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. Wenn eine Schleife mehr als 20 Codezeilen enthält sollten die Index-Variablen einen ausführlicheren Namen haben. Konstanten: Konstanten können beides enthalten, sowohl alphanumerische Zeichen als auch Unterstriche. Nummern sind in Konstantennamen gestattet. Alle Buchstaben die in Konstantenname verwendet werden müssen großgeschrieben haben, während Wörter in einem Konstantennamen durch Unterstriche getrennt werden müssen. Konstanten müssen als Klassenkonstanten definiert werden mit dem "const" Modifikator. Von einer Definition von Konstanten im globalen Bereich mit der "define" Funktion wird stärkstens abgeraten. 4.8 Code Stil PHP Code Abgrenzung: PHP Code muss immer mit der kompletten Form des Standard-PHP Tags abgegrenzt sein. 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 den String abzugrenzen. Wenn ein literaler String selbst Apostrophe enthält, ist es gestattet den String mit Anführungszeichen oder "doppeltes Anführungszeichen" abzugrenzen. Das ist speziell für SQL Anweisungen nützlich. Diese Syntax ist zu bevorzugen, im Gegensatz zum Ausbruch von Apostrophs, da Sie viel einfacher lesbar ist. Variabler Austausch: Variabler Austausch ist nicht gestatten, man muss Variablen immer verbinden. Verbinden von Strings: Strings müssen verbunden werden indem man den "." Operator verwendet. Ein Leerzeichen muss immer vor und nach dem "." Operator hinzugefügt werden um die Lesbarkeit zu erhöhen. Bei langen Strings, ist es empfohlen die Anweisung in mehrere Zeilen umzubrechen um die Lesbarkeit zu erhöhen. In diesen Fällen sollte jede folgende Zeile mit Leerraum aufgefüllt werden so das der "." Operator genau unterhalb des "=" Operators ist. Arrays: 30

33 Nummerisch indizierte Arrays: Negative Nummern sind in Indizes nicht gestattet. Ein indiziertes Array kann mit irgendeiner nicht-negativen Nummer beginnen, trotzdem sind alle BasisIndex neben 0 nicht erlaubt. Wenn indizierte Arrays mit dem Array Funktion deklariert werden, muss ein folgendes Leerzeichen nach jeder Kommaabgrenzung hinzugefügt werden um 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 das der Beginn jeder Zeile ausgerichtet ist. Wenn das so ist, muss das beginnende Array Element in der folgenden Zeile beginnen und es muss ein Einrückungslevel tiefer stehen als die Zeile welche die Array Deklaration enthält und alle folgenden Zeilen sollten die gleiche Einrückung haben; der schließende Teil sollte in einer eigenen Zeile stehen und das gleiche Einrückungslevel haben wie die Zeile welche die Array Deklaration enthält. Es ist nicht gestattet 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 jede folgende Linie mit Leerraum aufgefüllt werden so das beide, der Schlüssel und der Wert untereinander stehen. Das beginnende Array Element muss in der folgenden Zeile beginnen und um ein Einrückungslevel tiefer stehen als die Zeile welche die Array Deklaration enthält und alle folgenden Zeilen sollten die gleiche Einrückung haben; der schließende Teil sollte in einer 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 so eingerückt werden das Sie untereinander stehen. Es ist nicht gestattet ein Komma für das letzte Element in Array zu verwenden. Klassen: Klassen Deklarationen: Die Klammer muss immer in der Zeile unter dem Klassennamen geschrieben werden. Jede Klasse muss einen Dokumentationsblock haben der dem PHPDocumentor Standard entspricht. Jeder Code in der Klasse muss mit vier Leerzeichen eingerückt sein. Nur eine Klasse ist in jeder PHP Datei gestattet. Das Platzieren von zusätzlichem Code in Klassendateien ist nicht gestattet. Klassen die andere Klassen erweitern oder welche Interfaces implementieren sollen Ihre Abhä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üsselwort umzubrechen und diese Zeilen um ein Einrückungslevel einzurücken. Wenn die Klasse mehrere Interfaces implementiert und die Deklaration die maximale Zeilenlä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

34 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 Klasse deklariert wird muss am Beginn der Klasse ausgelistet werden, vor der Deklaration von allen Methoden. Das var Konstrukt ist nicht gestattet. Klassenvariablen definieren Ihre Sichtbarkeit durch die Verwendung des private, protected, oder public Modifikatoren. Das gestatten von direktem Zugriff auf Klassenvariablen durch deren Deklaration als public ist gestattet aber es wird 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 von Klassen müssen immer Ihre Sichtbarkeit durch Verwendung einer der private, protected, oder public Modifikatoren definieren. Wie bei Klassen, sollte die Klammer immer in der Zeile unterhalb des Funktionsnamens geschrieben werden. Leerzeichen zwischen dem Funktionsnamen und der öffnenden Klammer für die Argumente sind nicht erlaubt. Von Funktionen im globalen Raum wird komplett abgeraten. In den Fällen wo die Liste der Argumente die maximale Zeilenlänge überschreitet, sollten Zeilenumbrüche eingeführt werden. Zusätzliche Argumente der Funktion oder Methode müssen durch einen zusätzlichen Einrückungslevel nach der Funktion oder Methodendeklaration eingerü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 Funktion oder Methode mit einem einzelnen Leerzeichen das die zwei trennt, und mit dem gleichen Einrückungslevel wie die Deklaration der Funktion oder Methode. Es ist nicht erlaubt über 10 Parameter für eine Funktion zu definieren, dafür sollte man Container benutzen. Hinweis: Notiz: Die Übergabe per Referenz ist die einzige erlaubt Mechanismus für die Übergabe von Parametern in der Deklaration einer Funktion. Der Aufruf durch Referenz ist nicht gestattet. Der Rückgabewert darf nicht in Klammern stehen. Das kann die Lesbarkeit behindern und zusätzlich den Code unterbrechen wenn eine 32

35 Methode später auf Rückgabe durch Referenz geändert wird. Verwendung von Funktionen und Methoden: Funktionsargumente sollten durch ein einzelnes trennendes Leerzeichen nach dem Komma Trennzeichen getrennt werden. Übergabe von Referenzen zur Laufzeit ist strengstens verboten. Siehe die Sektion für Funktions Deklarationen 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 zu erhöhen. In solchen Fällen sind die normalen Richtlinien für das Schreiben von Arrays trotzdem noch anzuwenden. Kontrollanweisungen: If/Else/Elseif: Kontrollanweisungen die auf den if und elseif Konstrukten beruhen müssen ein einzelnes Leerzeichen vor der öffnenden Klammer der bedingten Anweisung und ein einzelnes Leerzeichen nach der schließenden Klammer. Innerhalb der bedingten Anweisungen zwischen den Klammern, müssen die Operationen, für die Lesbarkeit, durch Leerzeichen getrennt werden. Innere Klammern sind zu befürworten um die logische Gruppierung für größeren bedingte Anweisungen zu erhöhen. Die öffnende Klammer wird in der selben Zeile geschrieben wie die Bedingungsanweisung. Die schließende Klammer wird immer in einer eigenen Zeile geschrieben. Jeder Inhalt innerhalb der Klammer muss durch Verwendung von vier Leerzeichen eingerückt werden. Wenn die Kontrollanweisung die Ursache für eine Überschreitung der maximalen Zeilenlänge ist und sie mehrere Anweisungen hat, kann die Kontrollanweisung in mehrere Zeilen gebrochen werden. In solchen Fällen, ist die Zeile vor dem logischen Operator zu brechen und die Zeile so einzurücken das Sie unter dem ersten Zeichen der Kontrollanweisung steht. Der schließende Teil der Kontrollanweisung ist mit der öffnenden Klammer in einer eigenen Zeile zu platzieren, wobei ein einzelnes Leerzeichen die zwei trennen muss, und der Einrückungslevel identisch mit der öffnenden Kontrollanweisung sein ist. Die Einrückung des späteren Deklarationsformats dient der Vorbeugung von Problemen beim Hinzufü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 if Anweisungen mit else und/oder elseif Konstrukten: PHP erlaubt das Anweisungen in einigen Fällen auch ohne Klammern zu schreiben. Dieser Coding Standard macht keine Unterscheidungen und es müssen alle if, elseif oder else Anweisungen in Klammern geschrieben werden. Switch: Kontrollanweisungen die mit der switch Anweisung geschrieben werden müssen ein einzelnes Leerzeichen vor der öffnenden Klammer der Bedingten Anweisung besitzen, und auch nach der schließenden Klammer. Jeglicher Inhalt innerhalb der switch Anweisung muss durch Verwendung von vier Leerzeichen eingerückt sein. Der Inhalt unter jeder case Anweisung muss durch Verwendung von vier zusätzlichen Leerzeichen eingerückt werden. Das default Konstrukt darf nie bei der switch Anweisung vergessen werden. 33

36 4.9 Inline-Dokumentation Dokumentations Format: Alle Dokumentationsblöcke ("DocBlock") müssen mit dem phpdocumentor Format kompatibel sein. Für weiterführende Informationen siehe: Alle Klassen-Dateien müssen einen "file-level" DocBlock am Beginn jeder Datei enthalten. Dateien: Jede Datei die PHP Code enthält muss einen!docblock am Beginn der Datei besitzen welcher mindestens diese phpdocumentor Tags enthält. /** * Kurze Beschreibung der Datei * * Lange Beschreibung der Datei (wenn vorhanden)... * Clubshopping Clubshopping_Db Adapter Copyright (c) 2010 <Firma> GmbH $Id:$ */ Hinweis: Notiz: Damit $Id:$ auch funktioniert, muss man die svn:keywords aktivieren Klassen: Jede Klasse muss einen DocBlock haben welche mindestens diese phpdocumentor Tags enthält: /** * Kurze Beschreibung der Klasse * * Lange Beschreibung der Klasse (wenn vorhanden)... * Clubshopping Clubshopping_Db Adapter Copyright (c) 2010 <Firma> GmbH */ Funktionen: Jede Funktion, auch Objekt Methoden, muss einen DocBlock haben welcher mindestens folgendes enthält: Eine Beschreibung der Funktion, alle Argumente, alle möglichen Rückgabewerte. Es ist nicht notwendig das "@access" Tag zu verwenden, weil das Accesslevel bereits vom "public", "private" oder "protected" Modifikator bekannt ist wenn die Funktion deklariert wird. 34