Abbildungsverzeichnis

Abbildung 1: blah 5

Abbildung 2: blah 6

Abbildung 3: blah 5

Abbildung 4: blah 6

Abbildung 5: blah 5

Abbildung 6: blah 6

Abbildung 7: blah 5

Abbildung 8: blah 6

Tabellenverzeichnis

Tabelle 1: blah 5

Tabelle 2: blah 6

Tabelle 3: blah 5

Tabelle 4: blah 6

Tabelle 5: blah 5

Tabelle 6: blah 6

Tabelle 7: blah 5

Tabelle 8: blah 6

1.Teil 1

1.1Management Summary

1.1.1Kurzfassung des IPA-Berichtes

1.1.1.1Ausgangssituation

S

1.1.1.2Umsetzung

D

1.1.1.3Ergebniss

F

1.1.2Organisation

Die Experten bilden zusammen mit dem Fachausbildner und dem Kunden den Auftraggeber. sie sind zusammen für die Formulierung der Aufgabenstellung und die Bewertung der Projektarbeit als Ganzes zuständig.

1.1.3Projektübersicht

Dieser Bericht, die Präsentation, die Demonstration sowie das anschliessende Fachgespräch sind Bewertungsgrundlagen für die IPA (individuelle praktische Arbeit).

Nach den Standards des Projekt Managements, es wurde IPERKA verwendet, wurden die folgenden Projektphasen dokumentiert:

• Informieren
• Planung
• Entscheiden
• Realisierung
• Testphase (Kontrolle)
• Auswertung

Zusätzliche Informationen, die in diesem Bericht zu finden sind:

• Abbildungsverzeichnis
• Tabellenverzeichnis
• Quellenverzeichnis
• Protokolle
• Glossar
• Anhang

1.1.4Lehrbetrieb

Rafisa GmbH
Bernstrasse 88
CH-8953 Dietikon

1.1.5Involvierte Personen

• Kandidat: Timothé Laborie +41 78 692 2440 
• Fachvorgesetzter: Jorge Windmeisser +41 44 533 36 49
• Berufsbildner: Schärer Thomas 044 533 36 42
• Expert: Bertelli Bruno +41 58 660 33 88
• Zweit-Expert: Steinmann Remo +41 58 5584834
• Validexpert: Bonfranchi Renzo 043 266 6187

1.2Detaillierte Aufgabenstellung

1.2.1Ausgangslage

Der Kunde möchte einen Webauftritt mit dem er auch Petitionen und Umfragen selbst erstellen kann.

In der IPA-Phase wird die Logik für die Petitionen und Umfragen programmiert.

In einem weiteren Schritt, der nicht zur IPA gehört, wird der vollständige Internetauftritt erstellt und die in der IPA erstellten Arbeiten in das Gesamtprojekt eingebunden.

Die Bedienung soll möglichst einfach sein.

Seitens der Rafisa möchten wir, dass die Software modular aufgebaut ist und eine Eigenentwicklung ist, es sollen keine CMS von Drittanbieter verwendet werden.

1.2.2Detaillierte Aufgabenstellung

Das Projekt wird von Ihnen mit der Netbeans Etwicklungsumgebung initialisiert und entwickelt. Damit eine Kontrolle und Nachverfolgung möglich ist, erstellen Sie ein Mercurial Repository auf dem externen Rafisa Root Server.

Begründung der Benutzung der ausgewählten externen Bibliotheken.

Um den Aufbau für den Auftraggeber möglichst transparent zu machen, erstellen Sie die pertinenten Use-Cases, ERM- und UML 2.0 Diagramme, aus welche folgende Angaben ableitbar sind:

Bei der ERM Diagramme sind folgende Punkte zu beachten:

• Alle Entitäten und Beziehungen sind korrekt dargestellt.

• Alle Assoziationstypen (1, c, m, mc) sind korrekt eingetragen.

• Alle Primärschlüssel und Fremdschlüssel sind als solche erkenntlich, also entsprechend markiert bzw. bezeichnet.

• Alle Attributslisten sind vollständig, die Datentypen aller Attribute sind angegeben.

Source Control:

Damit eine Kontrolle und Nachverfolgung möglich ist, erstellen Sie ein Mercurial Repository auf dem externen Rafisa Root Server. Die Commits sollen im Umfang möglichst klein sein und themenverwandt. Die Commits müssen in guter Qualität kommentiert werden. Jeden Abend soll ein Push auf den Server erfolgen.

• Initialisierung des „Repository“ auf dem Mercurial-Server.

• Kleine Commits, z.B. beim Arbeitsjournal wurde einen Tageseintrag fertiggestellt.

• Themenverwandte Commits, z.B. Business-Klassen wurden erweitert.

• Täglicher Push auf den Server.

Folgende Technologien werden vom Auftraggeber vorgegeben:

• PHP OOP

• JavaScript

• jQuery

• HTML5

• CSS

• MySQL

Petition:

Eine Petition besteht aus folgende Felder: ID, Titel, Text, Erstellungsdatum, Abschlussdatum, Status.

Der Status einer Petition kann ‚Publiziert‘, ‚Abgeschlossen‘ oder ‚In Bearbeitung‘ sein. Wenn eine neue Petition erstellt wird, wird automatisch den Status ‚In Bearbeitung‘ gesetzt. Wird der Status ‚Abgeschlossen‘ gesetzt und gespeichert, darf die Petition nicht mehr geändert oder gelöscht werden. Das Feld Abschlussdatum ist ab diesem Zeitpunkt zu setzen.

Petitionen die Unterstützer haben dürfen nicht mehr geändert oder gelöscht werden.

Petitionen Erfassen/Bearbeiten Ansicht:

Petitionen werden durch eine Person erstellt und publiziert. Der Benutzer der Petitionen Bearbeiten darf, soll über ein Login in einen Erstellungs-Bereich gelangen. Dieser Bereich soll eine Liste mit den bereits erstellten Petitionen anzeigen. Es ist Funktionalität anzubieten um eine neue Petition erstellen und bearbeiten zu können.

Bei der Ansicht einer einzelnen Petition soll auch eine Liste mit den Unterstützer angezeigt werden.

Petition unterstützen:

Im öffentlichen Bereich soll eine Liste mit den publizierten Petitionen angezeigt werden. Die Liste enthält alle publizierten Petitionen und die Anzahl Unterstützer. Ein Benutzer kann aus dieser Liste eine Petition auswählen und diese wird im Detail angezeigt. Dort werden den Titel und den dazugehörigen Text angezeigt.

Der Benutzer kann die Petition unterstützen in dem er auf einen ‚Petition Unterstützen‘ Knopf/Link klickt. Nach erfolgtem Klick soll ein Formular erscheinen wo der Benutzer seine Personalien eingeben kann.

Folgende Felder soll das Formular beinhalten:

• E-Mail Adresse (Pflichtfeld, Jede Petition kann nur von einer E-Mail Adresse unterstütz werden)

• Name (Pflichtfeld)

• Vorname (Pflichtfeld)

• Strasse

• Plz und Ort

• Telefon

Petition unterstützen Bestätigungs-E-Mail:

Hat sich der Benutzer für eine Petition entschieden, die Adresse im Formular korrekt eingegeben und die Unterstützung eingegeben, soll der Benutzer eine E-Mail erhalten, mit einem Bestätigungs-Hyperlink. Mit diesem Link soll der Benutzer seine Unterstützung endgültig bestätigen. Der Hyperlink soll eindeutig sein und maximal 30 Minuten gültig sein.

• Bestätiguns-E-Mail an die E-Mail des Benutzers senden

• E-Mail mit einem Hyperlink mit der man die Unterstützung einer Petition endgültig bestätigen kann.

• E-Mail mit folgenden ‚Subject‘: ‚Rückbestätigung der Unterstüzung der Petition {name der Petiton}‘

• E-Mail mit folgendem ‚Body‘:

Hallo {Vorname des Benutzers}

Du hast dich entschieden unsere Petition {Name der Petition} zu unterstützen, vielen Dank!

Damit deine Unterstützung endgültig registriert wird, klicke folgenden Link:

{Bestätigungs Hyperlink}

Dieser Link wird nach 30 Minuten ungültig.

Wir danken dir für deine Unterstützung und wünschen dir alles Gute.

{Name der Organisation}

• Bestätigungs-Hyperlink ist eindeutig

• Bestätigungs-Hyperlink läuft nach 30 Minuten ab

Auf diesem Formular soll ein Knopf sein wo man dieses senden kann. Bei etwaigen Fehleingaben soll der Benutzer darauf hingewiesen werden. Die eingegebenen Daten sollen gespeichert werden.

Umfragen:

Umfragen bestehen aus folgenden Felder: Identifikation, Text und Ablaufdatum. Es existiert nur eine Umfrage, nur dessen Text und Antworten können geändert werden. Minimum muss eine Umfrage zwei Antworten haben, maximal sind fünf Antworten möglich.

Umfragen können von jedem Web-Besucher geantwortet werden.

Andworten:

Eine Frage besteht aus Folgenden Felder: Identifikation, Text und Anzahl Unterstützer.

Neue Umfrage:

Eine Umfrage besteht aus einer Frage und mindestens aus zwei Antworten, maximal sind fünf Antworten möglich. Die Antworten müssen durch einen Radio-Button ausgewählt werden können. Es darf nur eine Antwort gewählt werden. Ist die gewünschte Antwort ausgewählt worden, soll ein „Abstimmen“-Knopf freigegeben werden. Clickt der Benutzer der „Abstimmen“-Knopf, erscheint der „Captcha“ mit einem Eingabefeld und einem „Absenden“-Knopf.

Der „Captcha“ soll aus vier Zeichen bestehen.

Der Benutzer gibt die im „Captcha“ erscheinende Zahl im Eingabefeld ein und betätigt den „Absenden“-Knopf. Ist Alles korrekt eingegeben worden, wird die Statistik der aktuellen Umfrage anhand einer Balkengraphik angezeigt, inklusive der Antwort des aktuellen Benutzers.

Es gibt immer nur eine aktuelle Umfrage

Wird eine neue Umfrage erzeugt, werden die aktuellen Antworten und Umfrage gelöscht und der Benutzer kann aus einer Combobox die Anzahl Antworten, für die neue Umfrage, die er erfassen möchte. (2, 3, 4 oder 5). Nach erfolgter Auswahl kann der Benutzer die Antworten editieren. Mit einem ‚Publizieren‘ Knopf kann der Benutzer die Umfrage online stellen. Ist die Umfrage publiziert und hat schon, durch Internet-Nutzer, ausgewählte Antworten, ist die nicht mehr veränderbar.

Benutzer (Webmaster) der Umfragen und Petitionen erstellen kann:

Es gibt nur einen Benutzer (Webmaster) der Petitionen und Umfragen editieren und bearbeiten kann. Es wird keine Benutzerverwaltung benötigt, da dies für den Kunden zu umständlich wäre.

Validierung bei Unterstützung der Petitionen:

• E-Mail Adresse, es muss sichergestellt werden, dass es eine semantisch korrekte E-Mail Adresse ist.

• Name, muss mindestens 1 Zeichen und maximal 40 Zeichen haben.

• Vorname, muss mindestens 1 Zeichen und maximal 40 Zeichen haben.

• Strasse, muss mindestens 4 Zeichen und maximal 80 Zeichen haben.

• Plz, muss mindestens 4 Zeichen und maximal 20 Zeichen haben.

• Ort, muss mindestens 1 Zeichen und maximal 250 Zeichen haben.

• Telefon, muss mindestens 5 Zeichen und maximal 20 Zeichen haben.

Fehlerbehandlung:

Mögliche Fehler müssen abgefangen werden, z.B. wenn der MySQL Server nicht mehr funktioniert, soll nicht eine PHP interne Fehlermeldung erscheinen welche Rückschlüsse auf die Daten- und Projekt-Struktur zulässt. Die Fehler müssen durch eigene Meldungen/Fehlercodes ersetzt werden, z.B. 'Datenbankfehler D001' bei einem Fehlversuch sich beim MySQL-Server anzumelden, oder 'Datenbankfehler D002' bei einem misslungenem 'INSERT' Versuch. Diese Fehlercodes müssen dokumentiert werden.

• Kritische Datenbank-Fehler werden abfangen.

• Eigene Fehlercodes erzeugen.

• Anzeige des Fehlercodes/Meldungen bei abgefangenen Fehler.

Diverses:

Die Benutzungsmasken sollen selbsterklärend, einfach und klar strukturiert sein.

Die Sicherheit soll durch den Einsatz der PHP-PDO-Bibliothek erhöht werden.

Es dürfen keine Daten physikalisch gelöscht werden, sondern nur als ‚gelöscht‘ markiert werden.

Jede Aktion soll in einer Logdatei festgehalten werden. Aus dieser Datei soll ersichtlich sein was, wann getätigt wurde. Die Logdatei soll durch keinen der Benutzer manipulierbar sein.

Es ist eine Benutzer-Anleitung zu erstellen. Diese richtet sich an die zuständigen Webmaster. Folgende Themen müssen behandelt sein:

• Erstellung/Statusänderung einer Petition

• Erstellung einer neuen Umfrage

Tests:

Die Aufgabe umfasst die Installation eines Webauftrittes der funktionell ist, jedoch ohne definitive Designelemente. Das Ganze soll ausgiebig getestet werden.

• Dazu ist ein Testkonzept zu erstellen.

• Die Tests sind gemäss Konzept durchführen.

Mindestens folgende Testszenarien müssen durchgeführt werden:

• Petition erstellen, publizieren und sperren

• Petition unterstützen

• Umfrage erstellen und publizieren

• Umfrage durch Web-User: Captcha-Mechanismus, IP-Sperrung bei erfolgte Teilnahme, Anzeige der Statistiken.

1.2.3Firmenstandards

1.2.3.1Code-Konventionen

• Namenskonvention: analog Java für selbstdefinierte Programmteile. Klassen sind ‚upper camel case‘, Methoden sind ‚lower camel case‘, Variablen sind ‚lower camel case‘ und Konstanten müssen ‚upper case underscore separated‘ sein.

• Formatierung des Codes: Netbeans PHP Standard Formatierer.

• Variablen/Felder durch das ‚protected‘ Schlüsselwort geschützt, Zugriff auf diese nur durch Methoden.

• Stringliterale wo möglich und sinnvoll als Konstanten.

1.2.3.2Quellcode-Dokumentation

• Klassen Definition, ausführliche Kommentare inklusive Instanzierungs-Beispiele.

• Methoden ausführlich inklusive Parameter, Rückgabewerte und etwaige Throws.

• Konstanten, Sinn und Zweck.

1.2.4Rahmenbedingungen

1.2.4.1Mittel und Methoden

• Windows oder Linux Entwicklungs-PC.
• Linux oder Windows Web-Server.
• Netbeans Entwicklerumgebung.
• MAMP/XAMPP Entwickler-Chain.
• Internet-Suchmaschine zur Beschaffung von Informationen.
• PHP-Serverseitige Skriptsprache (Objektorientiert).
• SQL Datenbankabfragesprache.
• HTML-Dokumentbeschreibungssprache.
• CSS Layoutsprache
• Mercurial Source Control Management System

1.2.4.2Vorkenntnisse

• OO Programmieren
• HTML, PHP, CSS, SQL, jQuery
• Projektabwicklung

1.2.4.3Vorarbeiten

• Installation der notwendigen Software um damit professionell entwickeln zu können.
• Installation und Konfiguration der Netbeans-IDE.
• Erfassung von Testdaten.

1.2.4.4Neue Lerninhalte

Keine

1.2.4.5Arbeiten in den letzten 6 Monaten

Projektabwicklung, Installationen von Infrastruktur, Webprojekte, strukturierte Programmierung OO-PHP/PHP, HTML, CSS, JavaScript, jQuery. Netbeans IDE, XAMPP, MAMP,. Firefox, Chromium. 

1.2.5Zeitplan

1.2.6Tagesprotokolle

1.2.6.1Tagesprotokoll vom Freitag, 05.05.2017

| Tagesziele |||||

1.2.6.2Tagesprotokoll vom Dienstag, 09.05.2017

| Tagesziele |||||

1.2.6.3Tagesprotokoll vom Mittwoch, 10.05.2017

1.2.6.4Tagesprotokoll vom Donnerstag, 11.05.2017

1.2.6.5Tagesprotokoll vom Freitag, 12.05.2017

2.1Projektplanung

2.1.1Verwendetes Tool für Diagramme

Für die Erstellung der Diagramme benutzte ich das Tool Draw.io. Es ist kostenlos und hat viele verschiedene Export-Optionen wie zum Beispiel Google Drive, Dropbox oder Bild(png).

Ausserdem kenne ich mich mit dem Tool sehr gut aus, weil ich es schon oft für andere Projekte benutzt habe. Es hat auch alle Komponenten, die ich für die Erstellung der UML Diagramme brauche.

2.1.2Struktur der Webseite

Hier plane ich die Ordner und die Dateistruktur der Webseite.

| Ordner oder Datei | Beschreibung |

Das ist nur die Basis-Ordnerstruktur. Es kommen noch Libraries und weitere Dateien dazu.

2.1.3Use-Cases

2.1.3.1Endbenutzer

Use-Cases für Endbenutzer:

• Der Benutzer kann anhand der Navigation die Seite wechseln.
• Der Benutzer kann die aktuelle Umfrage beantworten. Er muss dazu die Captcha abschreiben und kann dann die Resultate anschauen.
• Der Benutzer kann Petitionen anschauen
• Der Benutzer kann Petitionen unterstützen. Er muss dann seine Email Adresse verifizieren.

2.1.3.2Webmaster

Use-Cases für den Webmaster.

• Der Webmaster kann alles, was der Endbenutzer auch kann.
• Der Webmaster kann sich über ein verstecktes Formular einloggen.
• Der Webmaster kann sich ausloggen.
• Der Webmaster kann eine neue Umfrage erstellen. Die alte Umfrage wird dann ersetzt.
• Der Webmaster kann eine neue Petition erstellen.
• Der Webmaster kann eine existierende Petition ändern, aber nur, wenn sie noch nicht publiziert worden ist.
• Der Webmaster kann eine Petition publizieren.
• Der Webmaster kann eine Petition abschliessen.
• Der Webmaster kann die Log Datei anschauen.

2.1.4Testkonzept

Hier beschreibe ich die Planung der Tests. Ich plane UnitTests und prüfe dann auch noch, ob die GUI korrekt funktioniert. Wenn ich die Webseite dann fertig programmiert habe, führe ich die Tests durch.

2.1.4.1UnitTests

UnitTests sind kleine, isolierte Tests, die die verschiedenen Funktionen auf der Webseite testen. Die GUI wird später getestet.

2.1.4.1.1. Persistence

2.1.4.1.2. Petitionen

2.1.4.1.3. Umfrage

2.1.4.1.4. Admin

2.1.4.2GUI Tests

Hier teste ich ob die GUI auf derie Webseite funktionierent. Zum Beispiel ob die Navigation funktioniert, ob der Status der Petitionen korrekt angezeigt wird oder die Fehlermeldungen bei ungültigen URLs angezeigt werden.

2.1.5Flowcharts

2.1.5.1Petition Unterstützen

Dieses Flussdiagramm visualisiert den kompletten Ablauf um eine Petition zu unterstützen.

2.1.5.2Umfrage beantworten

Dieses Flussdiagramm visualisiert den kompletten Ablauf um eine Umfrage zu beantworten.

2.1.5.3Petition Verwaltung

Dieses Flussdiagramm visualisiert den kompletten Ablauf für die Petition Verwaltung.

2.1.5.4Umfrage Verwaltung

Dieses Flussdiagramm visualisiert den kompletten Ablauf für die Umfrage Verwaltung.

2.1.6ERM

2.1.6.1Gemeinsame Felder

Es hat zwei Felder, die je eine de Tabelle hat.

Uuid

Die ID der Entity. Die ID wird automatisch durch PHP generiert , mit der Funktion „com_create_guid“. Ich nehmme dann die Tabellennamen und dien generierten ID mit einem Underscore zusammen.

Beispiel: Petitionen_270c6ab2-0906-4f33-9922-e769b84742f8

Deleted

In dire Aufgabestellung steht: „Es dürfen keine Daten physikalisch gelöscht werden, sondern nur als ‚gelöscht‘ markiert werden.“

Dieses Feld ist eine Boolean (TINYINT mit eine Grösse von 1), die sagt, ob die Entity gelöscht ist oder nicht. Standartmässig ist das Feld auf 0 (nicht gelöscht).

2.1.6.2Tabelle webmaster

Diese Tabelle enthält die Login-Daten für den Webmaster.

2.1.6.3Tabelle umfrageantwort

Diese Tabelle enthält die Antworten für die Umfragen.

2.1.6.4Tabelle Umfrage

Diese Tabelle enthält die Aktuelle Umfrage.

2.1.6.5Tabelle bannedip

Diese Tabelle enthält die IP-Adressen der Benutzer, die bereitsschon die aktuelle Umfrage begeantwortet haben. Der Inhalt der Tabelle wird gelöscht, wenn eine neue Umfrage erstellt wird.

2.1.6.6Tabelle Unterstützer

Diese Tabelle enthält die Unterstützer.

2.1.6.7Tabelle Petitionen

Diese Tabelle enthält die Petitionen.

2.1.6.8Tabelle Status

Der Status einer Petition kann ‚Publiziert‘, ‚Abgeschlossen‘ oder ‚In Bearbeitung‘ sein.

2.1.6.9Legende

2.1.7Klassendiagramme

Das Klassendiagramm enthält die Beziehungen zwischen denie einzelnen Klassen auf derie Webseite.

2.1.7.1Widgets

Jedes Widget erbt von der abstrakten IPAWidget Klasse. Die enthält den generierten HTML Code.

2.1.7.2Entity

Es hat ein Interface für die abstrakte Entity Klasse. Jede Entity erbt von dieser Klasse und enthählt die gleichen Felder, wie die Datenbank. Die Entity Klasse erhält Funktionen, um eine Entity zu erstellen und zu verändern.

2.2Entscheidungsphase

2.2.1Libraries

2.2.1.1Captcha Libraries

Für die Umfragen brauche ich eine PHP Captcha Library. Ich habe mich da für Securimage entschieden. Es ist einfach zu benutzen und ich habe diese Library schon für ein anderes Projekt benutzt. Es gibt auch eine andere Library, die BotDetect heisst. Aber die kostenlose Version hat Werbung im Hintergrund der Captcha. BotDetect hat ein paar Vorteile, wie z.B. mehr Optionen und Support für Chinesischen Zeichen, aber ich brauche die für die IPA nicht.

2.2.1.2Email Libraries

Für die Petitionen brauche ich eine E-Mail Library, um die Bestätigungsemails zu schicken.

Ich habe mich da für PHPMailer entschieden. Es gibt eigentlich nicht so viele Libraries um Emails mit PHP zu schicken, und PHPMailer ist die meist benutze. Ich kenne mich auch schon recht gut aus mit dieser Library, da ich es schon mal für ein anderes Projekt benutzt habe. Auf http://www.codexworld.com/send-html-email-php-gmail-smtp-phpmailer/ gibt es einem guten Tutorial, um die Library zu benutzen.

2.2.1.3JQuery Version

Für die Webseite brauche ich die JavaScript Library JQuery. Von JQuery gibt es 3 Versionen. Version 1 unterstützt sehr alte Versionen von Internet Explorer, aber hat Sicherheitslücken. Für mein Projekt ist der Support von alten Internet Explorer Versionen nicht wichtig, da es keinen Bestandteil der IPA ist. Ich habe mich also für die neuste Version von JQuery entschieden.

2.3Realisierungsphase

2.3.1Mercurial erstellen

Am Montag habe ich die Mercurial Repository erstellt auf http://4540.hostserv.eu:8080/scm/

2.3.2Webseite vorbereiten

Als erstes muss ich die Webseite Vorbereiten. Die Webseite braucht eine Navigation und funktionierende Links. Es braucht auch eine Autoloader, um PHP Klassen zu laden. Dann brauche ich noch einen Clicklistener, um Aktionen auszuführen.

2.3.2.1Importierte Dateien und Libraries

Für die Webseite brauche ich einige Library Dateien, die ich nicht selber erstellt habe.

autoloader.php

Der Autoloader lädt die PHP Klassen automatisch. Es erstellt eine Datei, mit den Pfäden aller Klassen auf die ganze Webseite.

ClickListener.js

Wenn der Benutzer auf einen HTML Element klickt, der eine Aktion enthält, wird die entsprechende Aktion durchgeführt.

normalize.css

Eine CSS Library die dafür sorgt, dass die Webseite ungefähr gleich aussieht auf allen Browsern.

2.3.2.2URL System

Wenn der Benutzer auf einen Link klickt, ändert sich der URL im Browser und die neue Seite wird via AJAX geladet. Das erlaubt mir, die Webseite viel responsiver zu machen und es ist dann einfacher, die verschiedenen Seiten in Dateien(Widgets) zu unterteilen. Dafür Brauche ich die Aktion „ChangePageAction“.

2.3.3Datenbank implementieren

In die Planungsphase hatte ich schon das ERM erstellt. Mit MySQLWorkbench habe ich dann das ERM in SQL Code umwandelt und die Datenbank „IPA“ erstellt auf localhost. Die Testdaten hatte ich als vorarbeit schon vor der IPA erstellt, und musste die nur noch importieren.

2.3.4Persistence und Entity System

Auf die Webseite hat es 3 Persistence Klassen

2.3.4.1Datenbank und Entity

Database.php benutze ich, um Entities zu laden, ändern, speichern und löschen. Es erstellt automatisch die Verbindung mit der Datenbank und generiert dann die SQL Statements. Diese Datei wurde eigentlich für den RIO (Rafisa Interne Organisation) von Herrn Windmeisser erstellt. Ich habe dann einige Funktionen und Konstanten angepasst:

• Konstanten für die Datenbank Verbindung
• Die Funktion, um die Datenbank Verbindung zu erstellen
• Fehlercodes angepasst gemäss Aufgabestellung
• Die „loadList“ Funktion ignoriert Daten, die als gelöscht markiert sind
• Die „loadList“ Funktion kann einen ORDER BY am Ende des Query hinzufügen
• Die „save“ Funktion kann auch „update“ Statements generieren
• Die „delete“ Funktion markiert Datensätze als gelöscht, anstatt die zu löschen.

Entity.php enthält Funktionen, um eine Entity zu erstellen und verändern. In die Interface IntEntity hat es Kommentare dazu. Diese beiden Dateien habe ich auch vom RIO importiert. In die Entity Klasse habe ich noch die Konstanten „ID“ und „DELETED“ hinzugefügt.

Entities

Jede Entity Datei enthält Konstanten, die zu der entsprechenden Datenbank Tabelle passen.

Ich habe kurz einen Generator gemacht, der die Entity Dateien generiert (generator.php). Der Generator geht durch jede Tabelle in die Datenbank und schaut, was die für Felder haben.

2.3.4.2Helper

Die Datei Helper.php ist eine statische Klasse, die diverse Funktionen für die Webseite enthält.

getPage

Diese Funktion kann eine Seite laden. Als sicherheit kann es nur Klassen instanzieren, die im Ordner „Presentation/Page“ sind.

writeLog

Diese Funktion öffnet die Log Datei und schreibt eine Aktion oder Fehlermeldung rein.

2.3.4.3SessionHelper

Diese Klasse startet automatisch die Session. Mit get() und set() kann man die Session Variablen ändern. Mit der „destroy“ Funktion kann man die Session zerstören. Das benutze ich für die Logout. CheckAdmin() checkt, ob der Benutzer als Webmaster eingeloggt ist.

2.3.5Petitionen

2.3.5.1Petitionen Liste

Auf die Seite „Petitionen“ kann man alle Petitionen ansehen. Oben kann man die offenen Petitionen sehen, und unten gibt es die abgeschlossenen Petitionen. Petitionen, die noch in bearbeitung sind, kann man nur auf die Adminseite sehen. Um die Petitionen anzuzeigen, habe ich einen Widget, der „PetitionenList“ heisst, erstellt. Dieser Widget kann eine Liste von Petitionen anzeigen. Es hat auch einen editier Modus (der zweiten Parameter), der dann für die Admin Seite benutzt wird.

2.3.5.2Status einer Petition

Mit den Status Entity kann man den Status einer Petition setzen. Es gibt drei Möglichkeiten:

• Publiziert
• Abgeschlossen
• In Bearbeitung

Die ID für jeden Status ist in die Entity Klasse hardcodiert.

Wenn bei einer publizierten Petition die Datum abläuft, wird die Petition automatisch auf den „abgeschlossen“ Status gesetzt.

2.3.5.3Petition anschauen

Petition Seite laden

In die Petition Liste kann man auf einen Link klicken, um eine bestimmte Petition anzuschauen

Wenn man auf den Link klickt, wird die Aktion „ShowPetitionAction“ benutzt. Diese Aktion lädt die Petition Seite und ändert den URL im Browser.

Petition Seite

Auf die Petition Seite kann man den Titel, den Text und eine Liste mit allen Unterstützer der Petition sehen.

Wenn man auf drückt, erscheint das Formular

Formular

Die drei oberen Felder sind Pflichtsfelder.

URL System

In die Aktion „ShowPetitionAction“ wird der URL geändert, wenn der Benutzer eine Petition anschauen will. Die URL enthält die ID der Petition und sieht zum Beispiel so aus:

http://localhost/?petidb75042af-185b-4829-8051-df572c03d61a

Das String „petid“ am Anfang zeigt, das jetzt der ID einer Petition kommt.

In index.php wird dann diese ID gelesen und die entsprechende Petition geladen.

Unterstützer

Auf die Petition Seite hat es noch eine Liste aller Unterstützer. Nur die Unterstützer, die ihrer Email Adresse verifiziert haben werden angezeigt.

2.3.5.4Petition signieren

Aktion

Die Aktion „SignPetitionAction“ liest die Daten des Formulars und sendet diese zum Server. Der Server macht dann die Validierung der Eingaben und sendet die Bestätigungsemail.

Um Zeit zu sparen benutzte ich eine Regular Expression, um den AJAX Teil zu generieren:

Validierung der Eingaben

In die Helper Klasse habe ich eine Funktion erstellt, die „validate“ heisst. Die prüft, ob die Eingaben eine korrekte Länge haben. Wenn nicht wird das signieren Prozess abgebrochen.

Für Felder, die keine Pflichtfelder sind, wird nur validiert falls das Feld auch ausgefühlt worden ist.

Email senden

Um den Bestätigungsemail zu senden brauche ich einen Google Konto und die PHPMailer Library. Ich habe dieses Tutorial benutzt: http://www.codexworld.com/how-to-send-email-from-localhost-in-php/

Als erstes musste ich einen neuen Google Konto erstellen. Die Daten für das Konto sind:

• Email: ipatimothelaborie@gmail.com
• Passwort: ipapetitionumfrage

Dann habe ich auf https://www.google.com/settings/security/lesssecureapps den Zugriff aktiviert. Das ist benötigt, um PHPMailer zu benutzen.

Als nächstes habe ich den Code vom Tutorial kopiert und angepasst. Ich schickte dann einen Test Email:

Am Schluss passte ich den Text und den Subjekt gemäss der Aufgabenstellung an:

Bestätigungslink

Der Bestätigungslink sieht so aus:

http://localhost/?confirm14cfb9e7-1ad2-4012-ba62-f3204a8c2a3f

Das String „confirm“ am Anfang zeigt, das jetzt der ID einer Unterstützer kommt.

Der Bestätigungslink läuft nach 30 Minuten ab. Wenn der abgelaufen ist, muss der Benutzer seine Daten auf die Petition Seite nochmals angeben.

Dupe Check

Die sASAsaSsgdgd

2.3.6Umfrage

2.3.6.1Umfrage anschauen

D

2.3.6.2Umfrage antworten

A

2.3.7Administration

2.3.7.1Login

S

2.3.7.2Logout

D

2.3.7.3Neue Umfrage erstellen

D

2.3.7.4Neue Petition erstellen

D

2.3.7.5Petition bearbeiten

F

2.3.7.6Petition publizieren

D

2.3.7.7Petition abschliessen

S

2.3.7.8Die Log Datei

Log: class, errors

2.3.8Widgets

2.3.8.1Erklärung

S

2.3.9Aktionen

2.3.9.1Erklärung

S

2.4Testphase (Kontrollieren)

2.4.1Sicherheit

2.4.1.1SQL Injection

d

2.4.1.2Fehler Codes

D

2.4.2Kriterien überprüfen

d

2.4.3Test Cases

asdasd

2.5.1Planungsauswertung

2.5.1.1Ist-Zeitplan

D

2.5.1.2Planungsdiskrepanz

d

2.5.1.3Kommentar

D

2.5.2Persönlicher Erfahrungsbericht

Allgemein

D

Planung

S

Analyse

S

Realisierung

S

Testing

d

2.5.3Sitzungsprotokolle

2.6Anhänge

2.6.1Quelleverzeichnis

F

2.6.2Literaturverzeichnis

S

2.6.3Glossar

Timothé Laborie Seite 13 23.05.2017

Rafisa GmbH