Merge branch 'master' of mojotrollz.eu:college

This commit is contained in:
lutz 2012-01-31 10:51:04 +01:00
commit f973ff3ef3
692 changed files with 417221 additions and 565 deletions

BIN
.DS_Store vendored

Binary file not shown.

4
.gitignore vendored
View File

@ -39,3 +39,7 @@ ws2011/BP/soapUI/.DS_Store
ws2011/BP/alte BPs Unterlagen/daSense vorherige Gruppe/.DS_Store
ws2011/BP/PHP-UML/.DS_Store
literature/Galileo Computing - Java ist auch eine Insel 10 Auflage/bilder/.picasa.ini
ws2011/CE/Klausurvorbereitung/.picasa.ini

Binary file not shown.

BIN
ss2010/.DS_Store vendored Normal file

Binary file not shown.

Binary file not shown.

Binary file not shown.

View File

@ -0,0 +1,35 @@
{\rtf1\ansi\ansicpg1252\cocoartf1138\cocoasubrtf230
{\fonttbl\f0\fmodern\fcharset0 Courier;}
{\colortbl;\red255\green255\blue255;\red237\green245\blue255;\red245\green0\blue0;}
\paperw11900\paperh16840\margl1440\margr1440\vieww10800\viewh8400\viewkind0
\deftab720
\pard\pardeftab720
\f0\fs26 \cf0 \cb2 [09:02] <tud> Do propel has the option to automatically join tables with their foreign key? I have some tables and would like to join them all with their foreign keys\
[09:05] <\cf3 Jarda\cf0 > tud: you can do FooQuery::create()->joinWith('Foo.Bar')->find()\
[09:06] <Jarda> didn't really get what you mean\
[09:06] <tud> Is "Bar" the foreign key in your example?\
[09:07] <Jarda> yeah\
[09:07] <tud> thanks\
[09:08] <tud> dorn here xD\
[09:08] <tud> the problem is we need 2 join a lot of tables dynamicly\
[09:08] <tud> is there a best pratice\
[09:09] <tud> for example we get via get params ColumnA,TableA and ColumnB,TableB -> now we need 2 join those 2 tables and select the 2 coulmns\
[09:09] <tud> this needs 2 be done dynamicly\
[09:09] <Jarda> hmm.. ok\
[09:09] <tud> any ideas?\
[09:09] <Jarda> well\
[09:10] <Jarda> you could in your FooQuery class write a public function joinByParameters(array $params) \{\'a0foreach ($params as $parm) \{ $this->joinWith(...); \} return $this; \}\
[09:10] <Jarda> or something like that\
[09:10] <Jarda> depends on the specific use case\
[09:12] <tud> so the best way is 2 use joinwith where u give the column u wanna join on?\
[09:12] <Jarda> yeah, or actually it's the foreign key name you give as parameter\
[09:13] <Jarda> <foreign-key foreignTable="bar"><reference local="bar_id" foreign="id" /></foreign-key> and then you use ->joinWith('Foo.Bar');\
[09:13] <tud> what happens if u have done smith like this: tbl1->join with(tbl2.column) ->joinwith(tbl3.column)->join with(.... does that work?#\
[09:13] <Jarda> you can have multiple joins, yes\
[09:14] <tud> and he automatically detects how 2 join it? over multiple tables?\
[09:14] <Jarda> yes, it should work\
[09:16] <tud> for example if tbl1.A->tbl2.A and tbl1.B->tbl3.A but we join tbl1->join with(tbl2.A)->join with(tbl3.A) - this will work?\
[09:17] <Jarda> if the foreign keys are wrintten in the schema, it should work\
[09:17] <Jarda> try it out\
[09:18] <tud> k much thx if that works its really amazing work ;-) much thx 4 the help}

View File

@ -0,0 +1,14 @@
- view bis nächstes treffen
- propel integration bis nächstes treffen
- json parser bis nächstes treffen
- immanuel tifft sich mit visualisierungsfrau nächsten montag
- authentifikation nicht geklärt wer es macht
- json besprechung -> leq/data -> umbennen nach "value"
- waspnodes - divice id = mac address
- oauth file -> war ein test -> kann weg
- präsentation: Über Projekt + Website -> nicht über coderefactoring
- speed mit ins json aufnehmen
- ein einziges json format - keine unterschiede für verschiedene anwendungen
- das andere jsonformat -> für update der diviceinfo
- weiter auf testsite arbeiten
- nächstes treffen wieder 13:30

View File

@ -0,0 +1,12 @@
Nächstes Treffen:
nächsten Dienstag (31.01.2012): 10.oo Uhr
- Propel fertigmachen
- Noisemap: wurde von Chris komplett neu geschrieben. Hat kein Propel wegen Zeitdruck genutzt. Sein Endpoint soll richtig funktionieren. Im Moment keine andere Möglichkeit.
- API muss komplett (reinschreiben, auslesen) funktionieren und soll dann auf die hauptseite geschoben werden.
- API mit Noisemap-App testen!
- Testen, testen, testen!
- Authentifizierung: checken ob der User eine gültige sessionID hat bzw. diese authentifiziert ist bevor Daten in die Datenbank geschrieben werden können.
- Benutzerbereich muss bis 1.2. fertiggestellt werden
- HTML5-Map einbinden, wenn wir sie erhalten

View File

@ -0,0 +1,25 @@
/lang/de-de/default/
data.php
dbscan.php
geopoint.php - rechtsklick auf karte -> geopoint
home.php - frame am anfang
impressum.php - Impressum
location.php
map.php
project.php - Über das Projekt
sensor.php - auf ein sensor klicken und auf die id klicken...
/lang/de-de/error/
general.php - Benutzer
/lang/de-de/
dasense.php - homepage
/templates/
about.php - Über das Projekt-Frame
dasense.php - Homepage
geopoint.php - rechtsklick auf karte und geopoint
home.php - anfangsframe (Herzlich willkommen)
impressum.php - Impressum-Frame
login_user.php - Benutzer-Frame
sensor.php - klick auf den einzelnen sensor und die id

Binary file not shown.

View File

@ -0,0 +1,19 @@
JSON Format falg = deviceinfo:
http://www.da-sense.de/test/api.php?flag=deviceinfo&json={"deviceType":1, "deviceID":123456789, "deviceManufactor":"Scholz", "deviceModel":"Testdevice", "deviceName":"ErstesAPITestDevice", "sensors": [ { "type":1, "sensorAttributes": [ { "key":"testkey1", "value":"22" } ] }, {"type":2, "sensorAttributes": [ { "key":"testkey2", "value":"33" } ] } ] }
JSON Format flag = input:
http://www.da-sense.de/test/api.php?flag=input&source=smartphone&json={"device":"APITEST","measurementType":1, "user":20, "series": [ { "name":"testseries4", "visibility":0, "timestamp":1 , "values": [ { "timestamp":1, "value":52.25234634, "longitude":0, "latitude":0, "altitude":0, "accuracy":0, "speed":null, "provider":"GPS", "tags": [ { "key": 1, "value":35 } ] } ] }, { "name":"testseries5", "visibility":0, "timestamp":2 , "values": [ { "timestamp":1, "value":62.25234634, "longitude":0, "latitude":0, "altitude":0, "accuracy":0, "speed":null, "provider":"GPS", "tags": [ { "key": 1, "value":35 } ] } ] }] }
JSON Format result = ? :
http://www.da-sense.de/test/api.php?result= ….
{"device":"357194040202988","series":[{"timestamp":1327825923746,"visibility":1,"values":[{"tags":[{"value":"44100","key":"measurement:samples:count"}],"timestamp":1327825925143,"speed":0,"altitude":0,"value":213.6781463623047,"provider":"network","longitude":8.6091076,"latitude":49.676669,"accuracy":39},{"tags":[{"value":"220500","key":"measurement:samples:count"}],"timestamp":1327825930152,"speed":0,"altitude":0,"value":139.90003967285156,"provider":"network","longitude":8.6091076,"latitude":49.676669,"accuracy":39} ,"name":"testparser22"}],"user":94,"measurementType":1}

View File

@ -7,17 +7,17 @@ HTTP-Post-Parameter:
Das JSON hat folgendes Format:
{
“deviceType”: INT, (1: Smartphone)
“deviceID”: INT, (beim Smartphone die IMEI)
“deviceType”: INT, //(1: Smartphone | 2: Waspmote)
“deviceID”: INT, //(Smartphone: IMEI | Waspmote: MAC-Adresse)
“deviceManufactor”: STRING,
“deviceModel”: STRING,
“deviceName”: STRING (“Benutzerspezifischer Name, kann selbst vergeben werden,
z.B Julien Handy”)
“deviceName”: STRING //(“Benutzerspezifischer Name,
//kann selbst vergeben werden, z.B Julien Handy”)
“sensors”: [
“type”: INT, (1:Audio)
“sensorAttributes”: [ Sensorattribute als Key-Value-Pair
“type”: INT, //(1:Audio | 2: CO2 | 3: CO | 4: °C)
“sensorAttributes”: [ //Sensorattribute als Key-Value-Pair
“key”: STRING,
“value”: STRING
]
@ -28,18 +28,20 @@ Das JSON hat folgendes Format:
2.) Neues JSON-Format für das Senden der Daten.
HTTP-Post-Parameter (wie gehabt)
flag=input
source=smartphone
source=smartphone bzw. waspmote
json=JSON-Daten
{
“device”: STRING, (Handy IMEI)
“measurementType”: INT, (=1 für Lautstärke)
“user”: INT, (dasense User-ID)
“device”: STRING, //(Smartphone IMEI | Waspmote MAC-Adresse)
“measurementType”: INT, //(1:Audio | 2: CO2 | 3: CO | 4: °C)
“user”: INT, //(dasense User-ID)
“series”: [
“name": STRING,,
@ -49,11 +51,12 @@ HTTP-Post-Parameter (wie gehabt)
“values”: [
“timestamp”: LONG,
“leq”: FLOAT,
value”: FLOAT,
“latitude”: FLOAT,
“longitude”: FLOAT,
“altitude”: FLOAT,
“accuracy”: FLOAT,
"speed": FLOAT bzw. NULL,
“provider”: STRING,
“tags”: [
@ -65,3 +68,28 @@ HTTP-Post-Parameter (wie gehabt)
}
Bitte folgende Klammerung einhalten:
zu 2.) ein Beispiel:
{ "device":"APITEST,
"measurementType":1,
"user":20,
"series": [ { "name":"testseries",
"visibility":0,
"timestamp":1 ,
"values": [ { "timestamp":1,
"value":52.25234634,
"longitude":0,
"latitude":0,
"altitude":0,
"accuracy":0,
"speed":null,
"provider":"GPS",
"tags": [ { "key": 1,
"value":35 } ]
} ]
} ]
}

Binary file not shown.

Binary file not shown.

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.4 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 108 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 748 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 683 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.1 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 59 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.4 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 748 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 683 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 17 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.1 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 59 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

Binary file not shown.

View File

@ -0,0 +1,50 @@
Stichpunkte zur Vorlesung "Anforderungen an das QS-Dokument" vom 23.12.2011:
- Was wollen wir sichern? Was ist das Ziel, wie definieren wir es, und wie wird es gesichert?
- Schlecht wenn Ziele nicht eingehalten werden können. Falls externen Abhängigkeiten dazu beitragen, dass gesetzte Ziele nicht eingehalten werden können, so kann man dies im Anhang aufführen -> Kein Problem! Prinzipiell müssen die Qualitätsziele jedoch erreichbar sein.
- Qualitätsziele, die für das Projekt nicht relevant sind und Maßnahmen, die nicht durchgeführt werden, gehören nicht in das Dokument
- Benutzbarkeit, Benutzerstudie: Schlecht, dass wir am Ende des Projektes eine Benutzerstudie durchführen. Doof, dass am Ende keine Zeit mehr ist, um auf Feedback einzugehen. Es muss also genug Zeit sein, um die Ergebnisse in das Projekt einfließen zu lassen (ca 4 Wochen vor Ende des Projekts) die Benutzerstudie durchführen.
- WER (auch Tool) macht WAS wann und WIE reagieren wir auf Probleme??? Namen und Zeitraum nennen!!
- Dokument im TUD Design mit maximal 10 Seiten. Deckblatt, Glossar, Literaturverzeichnis, Versionshistorie und Anhang sind nicht in den 10 Seiten enthalten. Als normaler Fließtext können auch 4 oder 5 Seiten reichen. 10 Seiten ist das absolute Maximum!!
- Ausarbeitung der Tests bzw. Benutzerstudie gehört in den Anhang. Auch der Fragebogen im Anhang?!?!
- Beschreiben Sie nicht, was Benutzbarkeit ist bzw. was Qualitätssicherung ist!!!!! Stabilität soll jedoch beschrieben werden.
- Deckblatt: Qualitätssicherungsdokument nur in klein, Gruppennummer, Kontaktadressen (kann auch auf nächster Seite kommen), Dateum/Version.
- Kurze Einführung in das Projekt -> Passt !
- Stellen Sie einem unbeteiligtem Dritten folgende Fragen: Welches sind die zentralen Qualitätsziele des Projekts? Warum sind dies die zentralen Ziele? … (mehr Fragen auf den Folien)
- Qualitätsmerkmal ist kein Ziel.
- ISO 9000 : Sicherung der Prozessqualität (tendenziell eher schwieriger)
Ergebnisse aus den aufgezeigten Beispielen:
- Ein Kapitel hat immer zwei Unterkapitel und nicht nur eins wie in Einleitung -> Das Projekt!
- Anwendung der deutschen Rechtschreibung (Bindestriche etc.)
- Eine Evaluation kann die Benutzerfreundlichkeit nicht sicherstellen, sie kann nur Grundlage für anschließende Maßnahmen sein.
- Einleitung: In diesem Dokument werden…. zu unspezifisch für das aktuelle Projekt! -> weglassen!
- Jeder Satz soll Projektspezifisch sein!
- Alle im deutschen geläufigen Wörter auch in deutsch schreiben
- nicht "wir wollen", "es sollte getan werden…" -> "Wir sichern die Qualität des Codes auf die folgende Art und Weise…."
- Kommasetzung
- Codequalität: Zitat kann drin bleiben. "des Projekt"
- Qualitätswerkzeuge: Steigern unsere Produktivität, dienen jedoch nicht der Qualitätssicherheit. Bsp.: Fehler in der Syntax findet der Compiler, nicht nur Netbeans. Nicht einfach alle Werkzeuge aufzählen.
- 3.3.2 Fragebogen: Was ist Anfang März? "verschiedensten" gibt es nicht. "nutzerspezifische Anforderungen", was ist damit gemeint? Warum darf der Nutzer die Anforderungen erstellen?
- 3.3.3 Analyse: Projekt ist viel zu kurz, um eine Logfile-Analyse durchzuführen.
- 3.4 Codequailtät: "…werden dem Ziel … " "Der Code soll…." wo ist der Zusammenhang?
- manuelle Überprüfung: Was heisst Aussagekräftig?
Stichpunkte von Treffen mit Dominik:
- 2.1, 2.2 Kopie von ISO rausmachen. "Wir definieren nach ISO"!
Codequalität: In der OpenSource Szene sind folgende Codestandards etabliert…..
Strukturierung: einfachstes Format: grobe, große Ziele. Kann auf eine halbe Seite passen. Rest sind Maßnahmen. Also Aufteilung in zwei Kapitel möglich.
Abgabetermin: Ende Januar (24.01)! Anhang dann Ende März!

Binary file not shown.

View File

@ -16,13 +16,13 @@
%\newglossaryentry{}{name={},description={}}
\newglossaryentry{SVN}{name={SVN},description={Subversion ist eine freie Software zur zentralisierten Versionsverwaltung}}
\newglossaryentry{Git}{name={Git},description={Freie Anwendung zur verteilten Versionsverwaltung}}
\newglossaryentry{SQL-Injection}{name={SQL-Injection}, plural={SQL-Injections},description={Angriff auf Datenbank mit dem Ziel eigenen SQL-Code auszuführen und Daten auszulesen bzw. zu ändern}}
\newglossaryentry{SQL-Injection}{name={SQL-Injection}, plural={SQL-Injections},description={Angriff auf Datenbank mit dem Ziel eigenen \gls{SQL}-Code auszuführen und Daten auszulesen bzw. zu ändern}}
\newglossaryentry{Propel}{name={Propel},description={Datenbankschnittstellte, die eine einfache Interaktion mit der vorhandenen Datenbank bietet. Mehr Informationen unter: \href{http://www.propelorm.org/}{http://www.propelorm.org/}}}
\newglossaryentry{Agile Softwareentwicklung}{{name=Agile Softwareentwicklung},plural={Agilen Softwareentwicklung},description={Softwareentwicklungsprozess, welcher auf sich ändernde Anforderungen flexibel eingeht}}
\newglossaryentry{API}{name={API},description={Application Programming Interface: Programmteil, durch den andere Programme die Funktionalität des eigentlichen Programmes nutzen können}}
\newglossaryentry{User-Front-End}{name={User-Front-End},description={Für den Benutzer sichtbarer Teil der Anwendung}}
\newglossaryentry{CO}{name={CO},description={Kohlenstoffmonoxid (chemische Verbindung)}}
\newglossaryentry{CO2}{name={CO2},description={Kohlenstoffdioxid (chemische Verbindung)}}
\newglossaryentry{CO2}{name={CO\textsubscript{2}},description={Kohlenstoffdioxid (chemische Verbindung)}}
\newglossaryentry{dB}{name={dB},description={Dezibel: Logarithmische Einheit von Akustikpegeln}}
\newglossaryentry{JSON}{name={JSON},description={JavaScript Object Notation: universelles Datenaustauschformat}}
\newglossaryentry{Parser}{name={Parser},description={Übersetzung eines (Programm-)Codes in eine neue Struktur/Format}}
@ -33,106 +33,121 @@
\newglossaryentry{Use-Case}{name={Use-Case},description={Anwendungsfall: Modellelement in der UML-Sprache}}
\newglossaryentry{Webservice}{name={Webservice},description={Schnittstelle zur Interaktion mit anderen Anwendungen via XML-basierter Nachrichten}}
\newglossaryentry{Webinterface}{name={Webinterface},plural={Webinterfaces},description={grafische Benutzeroberfläche}}
\newglossaryentry{Waspmotes Sensoren}{name={Waspmotes Sensoren},description={Wireless Sensoren, welche auf Straßenbahnen installiert werden und der Datenerfassung dienen. Mehr unter: \href{http://www.libelium.com/products/waspmote}{http://www.libelium.com/products/waspmote}}}
\newglossaryentry{Waspmote Sensoren}{name={Waspmote Sensoren},description={Wireless Sensoren, welche auf Straßenbahnen installiert werden und der Datenerfassung dienen. Mehr unter: \href{http://www.libelium.com/products/waspmote}{http://www.libelium.com/products/waspmote}}}
\newglossaryentry{WSDL}{name={WSDL},description={Web Services Description Language: Beschreibungssprache für Webservices}}
\newglossaryentry{XML}{name={XML},description={Extensible Markup Language: Auszeichnungssprache zur hierarchisch struktierten Darstellung von Daten in Textdatenform}}
\newglossaryentry{XHTML}{name={XHTML},description={Extensible Hypertext Markup Language: Auszeichnungssprache zur strukturierten Darstellung von Texten, Bildern und Hyperlinks in Textform}}
\newglossaryentry{MVC}{name={Model-View-Controller-Pattern}, description={Entwurfsmuster zur Strukturierung von Software. Nachzulesen unter anderem in \textit{Design Patterns} von Erich Gamma et al}}
\newglossaryentry{Browser-Sandbox}{name={Browser Sandbox}, description={Browser Sandbox in ein Onlinetool, welches über die Seite \href{http://spoon.net/browsers/}{http://spoon.net/browsers/} erreichbar ist.}}
\newglossaryentry{whitebox}{name={Whiteboxtest}, plural={Whiteboxtests}, description={Softwareentwickler hat während der Tests Kenntnisse über die innere Funktionsweise der zu testenden Module}}
\newglossaryentry{blackbox}{name={Blackboxtest}, plural={Blackboxtests}, description={Softwareentwickler hat während der Tests keine Kenntniss über die innere Funktionsweise der zu testenden Module}}
\newglossaryentry{Selenium}{name={Selenium}, description={Selenium ist ein Tool, mit dem Benutzereingaben automatisiert werden können. Mehr unter: \href{http://seleniumhq.org/}{http://seleniumhq.org/}}}
\newglossaryentry{PHPUnit}{name={PHPUnit}, description={Mittels PHPUnit können Whiteboxtests von \gls{PHP}-Code durchgeführt werden. Dies geschieht vergleichbar mit dem bekannten JUnit Testframework in Java}}
\newglossaryentry{HTML5}{name={HTML5}, description={\textbf{H}yper\textbf{t}ext \textbf{M}arkup \textbf{L}anguage in Version 5. Die offizielle Verabschiedung soll 2014 durch das \gls{W3C} erfolgen}}
\newglossaryentry{W3C}{name={W3C}, description={World Wide Web Consortium: Standardisiert die Techniken des Word Wide Webs. Mehr unter: \href{http://www.w3.org/}{http://www.w3.org/}}}
\newglossaryentry{SQL}{name={SQL}, description={\textbf{S}tructured \textbf{Q}uery \textbf{L}anguage: Sprache um mit einer Datenbank zu interagieren}}
\newglossaryentry{PreparedStatement}{name={Prepared Statement}, plural={Prepared Statements}, description={Vorbereitete Anweisung für Datenbanken. Sie enthält Platzhalter anstelle der Paramterwerte}}
\newglossaryentry{JavaScript}{name={JavaScript}, description={Dynamisch typisierte, objektorientierte, klassenlose Skriptsprache}}
% Glossareintrag für ORM
\newglossaryentry{ORM}{name={ORM-Framwork}, description={Erlaubt eine Abbildung der Objekte auf eine relationale Datenbank. Die Objekte stammen von einer objektorientierten Programmiersprache}}
\begin{document}
\title{Qualitätssicherungsdokument\\
da-sense \\
Wintersemester 2011/2012}
\title{Thema: da-sense\\
Gruppe 1b}
\subtitle{Auftraggeber: Immanuel Schweizer (Telecooperation Group TU Darmstadt) \\
\subtitle{Qualitätssicherungsdokument zum Bachelor-Praktikum im Wintersemester 2011/2012}
\subsubtitle{Auftraggeber: Immanuel Schweizer (Telecooperation Group TU Darmstadt) \\
Gruppe 1b: Murat Batu, Ulf Gebhardt, Lulzim Murati, Michael Scholz\\
Teamleiter: Dominik Fischer
}
\subsubtitle{Verison: 0.1.0}
Teamleiter: Dominik Fischer\\
Version: 0.9.0 vom 24.01.2012}
\author{Murat Batu, Ulf Gebhardt, Lulzim Murati, Michael Scholz}
\maketitle
% % % % % % % % % % % % % % % %% % % % % % % % % % % KONTAKT % % % % % % % % % % % % % % % %% % % % % % % % % % % % % % % %
\newpage
\section*{Kontakt}
\label{Kontakt}
\begin{tabular}{p{5cm} p{11cm}}
& \\
\textbf{Auftraggeber:} & \textbf{Immanuel Schweizer} \\
& Telecooperation Group TU Darmstadt \\
& Büro: S2|02 A216 \\
& E-Mail: \href{mailto:schweizer@tk.informatik.tu-darmstadt.de}{schweizer@tk.informatik.tu-darmstadt.de} \\
& \\
& \\
\textbf{Teamleiter:} & \textbf{Dominik Fischer} \\
& E-Mail: \href{mailto:dfischer@stud.tu-darmstadt.de}{dfischer@stud.tu-darmstadt.de} \\
& \\
& \\
\textbf{Gruppe:} & \textbf{Murat Batu} \\
& E-Mail: \href{mailto:wu07hufy@rbg.informatik.tu-darmstadt.de}{wu07hufy@rbg.informatik.tu-darmstadt.de} \\
& \\
& \textbf{Ulf Gebhardt} \\
& E-Mail: \href{mailto:hu56nifa@rbg.informatik.tu-darmstadt.de}{hu56nifa@rbg.informatik.tu-darmstadt.de} \\
& \\
& \textbf{Lulzim Murati} \\
& E-Mail: \href{mailto:l\_murati@rbg.informatik.tu-darmstadt.de}{l\_murati@rbg.informatik.tu-darmstadt.de} \\
& \\
& \textbf{Michael Scholz} \\
& E-Mail: \href{mailto:mi48azih@rbg.informatik.tu-darmstadt.de}{mi48azih@rbg.informatik.tu-darmstadt.de} \\
\end{tabular}
\newpage
%Inhaltsverzeichnis anzeigen
\tableofcontents
% % % % % % % % % % % % % % % %% % % % % % % % % % % EINLEITUNG % % % % % % % % % % % % % % % %% % % % % % % % % % % % % % % %
\newpage
\section{Einleitung}
In diesem Dokument werden Tests und Prozesse beschrieben, dokumentiert und ausgewertet. Ziel der Qualitätssicherung ist die Sicherstellung sowohl der angestrebten Softwarequalität als auch der Qualität der Prozesse. Dazu werden verschiedene Testmethoden angewandt, um Kernpunkte wie etwa Funktionalität, Richtigkeit und in Teilbereichen auch Interoperabilität zu überprüfen. Des weiteren wird auf die verwendeten Ansätze zur konstruktiven Qualitätssicherung eingegangen. In den kommenden Kapiteln wird auf die verwendeten Methoden, Werkzeuge sowie die eigentlichen Prüfprozesse eingegangen.
% Weiterhin werden die jeweiligen Testspezifikationen dargelegt sowie die Beschreibung der Tests und deren Ergebnisse vorgestellt.
\subsection{Das Projekt}
Das Projekt da-sense ist ein großflächiges Sensornetzwerk in Darmstadt. Es besteht aus einer Webapplikation, die dem Nutzer in Zukunft erlauben soll verschiedene Naturerscheinungen wie z.B. Lautstärkepegel (\gls{dB}), \gls{CO}- und \gls{CO2}-Konzentration einzusehen. Die Daten hierfür stammen aus verschiedenen Quellen (Smartphones und \gls{Waspmotes Sensoren}) und werden in eine Datenbank transferiert, die schließlich über die Webapplikation visualisiert abgerufen werden können. Bisher konnten die Datenbank und die Webapplikation nur mit den von Smartphones gesendeten Daten umgehen. Im Rahmen des Bachelorpraktikums im Wintersemester 2011/2012 sollen folgende Funktionalitäten hinzukommen:
\section{Das Projekt}
\label{DasProjekt}
Das Projekt da-sense ist ein großflächiges Sensornetzwerk in Darmstadt. Es besteht aus einer Webapplikation, die dem Nutzer in Zukunft erlauben soll verschiedene Naturerscheinungen wie z.B. Lautstärkepegel (\gls{dB}), \gls{CO}- und \gls{CO2}-Konzentration einzusehen. Die Daten hierfür stammen aus verschiedenen Quellen (Smartphones und \gls{Waspmote Sensoren}) und werden in eine Datenbank transferiert, die schließlich über die Webapplikation visualisiert abgerufen werden können. Bisher konnten die Datenbank und die Webapplikation nur mit den von Smartphones gesendeten Daten umgehen. Im Rahmen des Bachelorpraktikums im Wintersemester 2011/2012 sollen folgende Funktionalitäten hinzukommen:
\begin{itemize}
\item Umstrukturierung der Datenbank für neue Sensortypen
\item Installation von \gls{Waspmotes Sensoren} auf Straßenbahnen
\item Anpassung der \gls{API} auf neue Datenbank und Erstellung einer neue Visualisierung des \gls{User-Front-End}
\item Installation von \gls{Waspmote Sensoren} auf Straßenbahnen
\item Anpassung der \gls{API} auf neue Datenbank und Erstellung einer neuen Visualisierung der gesammelten Daten
\item Android-App
\end{itemize}
Das Projekt wurde auf insgesamt drei Gruppen aufgeteilt. In diesem Dokument werden ausschließlich die Bereiche der Gruppe 1b behandelt.
Der Themenbereich umfasst die Umstellung der \gls{API} auf eine neue Datenbank und die Erstellung einer neuen Visualisierung des \gls{User-Front-End}.
Der Themenbereich umfasst die Umstellung der \gls{API} auf eine neue Datenbank und die Erstellung einer neuen Visualisierung der gesammelten Daten.
% % % % % % % % % % % % % % % %% % % % % % % % % % % QUALITÄTSZIELE % % % % % % % % % % % % % % % %% % % % % % % % % % % % % % % %
\section{Qualitätsziele}
%Als Qualitätziele haben die Merkmale Funktionalität, Benutzbarkeit und Codequalität die höchste Priorität.
%In diesem Abschnitt werden die zu testenden Qualitätsziele genauer spezifiziert. Dabei werden die Qualitätsmerkmale Funktionalität und Benutzbarkeit besonderst hevorgehoben, da sie für unser Projekt von höchster Priorität sind. Das Merkmal der Codequalität soll den nachfolgenden Gruppen, die sich mit dem Projekt da-sense beschäftigen werden, einen besseren Einstieg gewährleisten.
%Die Merkmale sind für ein erfolgreiches Projekt unabdingbar.Das Merkmal der Funktionalität wird von unserem Auftraggeber gefordert. Die %Benutzbarkeit ist unabdingbar, da die neue Visualisierung des \gls{User-Front-End} nach erfolgreichen Abschluss des Projekts einer %großen Personengruppe zur Verfügung stehen soll.
\subsection{Funktionalität}
Funktionalität beschreibt das Vorhandensein von geforderten Funktionen mit festgelegten Eigenschaften, die von den Funktionen erfüllt werden \cite{ISO/IEC 9126}. \\
Die Funktionalität lässt sich in die folgenden Punkte gliedern:
\begin{itemize}
% \item Angemessenheit:
% \textit{Eignung von Funktionen für spezielle Aufgaben.}
\item Richtigkeit: \\
\textit{Die Funktionen liefern die richtigen bzw. erwarteteten Ergebnisse.} \\
Die Funktionen werden von uns auf einem Testserver im Livebetrieb getestet, bevor sie im \gls{Git} den übrigen Entwicklern zur Verfügung gestellt werden. Somit befinden sich im \gls{Git} nur bereits getestete Funktionen und somit eine lauffähige Version der Website.
\item Interoperabilität: \\
\textit{Fehlerfreie Kooperation mit vorhandenen Systemen.} \\
Es gilt zu gewährleisten, das die Website mit allen gängigen Webbrowsern (Firefox, Chrome, Internet Explorer ab Version 7, Safari) im vollen Funktionsumfang erreichbar ist. Da uns hierfür kein Testwerkzeug bekannt ist, werden wir die Tests nur manuell durchführen können. Zudem wird uns hierbei die Benutzerstudie Informationen zu den einzelnen Webbrowsern beschaffen (Vgl. Abschnitt \ref{fragebogen} Frage 3).
\item Sicherheit: \\
\textit{Blockierung von unberechtigtem Zugriff auf vertraulichen Daten (Datenbank).} \\
Um dieses Ziel zu gewährleisten, nutzen wir die Datenbankschnittstelle \gls{Propel}, die \glspl{SQL-Injection} verhindert und übersichtliche Datenbankinteraktionen erlaubt.
\item Ordnungsmäßigkeit: \\
\textit{Einhaltung von anwendungsspezifisch Normen und gesetzlichen Bestimmungen.} \\
Hier ist als Beispiel die datenschutzkonforme Nutzung von Google Analytics im Abschnitt \ref{subsubsec:datenschutz} zu nennen.
\end{itemize}
\subsection{Benutzbarkeit}
\label{subsec:zielBenutzbarkeit}
Als Benutzbarkeit wird der Aufwand definiert, der zum Einsatz der Software von dem Benutzer aufgebracht werden muss. Zudem bedarf es einer individuellen Beurteilung der Benutzung durch eine vorher bestimmte Benutzergruppe \cite{ISO/IEC 9126}. \\
Die Benutzbarkeit lässt sich in die folgenden Punkte gliedern:
\begin{itemize}
\item Verständlichkeit: \\
\textit{Aufzubringender Aufwand des Benutzers, damit sich dieser auf der Weboberfläche zurechtfindet, z.B. verständliche Menüführung.}
\item Erlernbarkeit: \\
\textit{Aufzubringender Aufwand des Benutzers um die Anwendung korrekt zu nutzen.}
\item Bedienbarkeit: \\
\textit{Aufzubringender Aufwand des Benutzers die Anwendung zu bedienen.}
\item Attraktivität: \\
\textit{Beschreibt die Anziehungskraft der Anwendung auf den Benutzer.}
\item Konformität: \\
\textit{Beschreibt den Grad, in dem die Software Normen zur Benutzbarkeit erfüllt.}
\end{itemize}
\parindent 0pt
Um dies zu gewährleisten werden wir am Ende des Projekts eine Benutzerstudie durchführen, die uns eine Rückmeldung über die gennanten Punkte liefern soll. Der Ablauf der Studie ist in Abschnitt \ref{subsec:aktionBenutzbarkeit} beschrieben.
\label{Ziel:Benutzbarkeit}
Die Benutzbarkeit unterteilen wir, wie vom Auftraggeber im zweiten Teil des Praktikums gefordert, in die drei Qualitätsmerkmale \textit{Verständlichkeit}, \textit{Bedienbarkeit} und \textit{Attraktivität}, welche wir nach \cite{ISO/IEC 9126} definieren. \\ \\
Eine intuitive und leicht bedienbare Benutzeroberfläche steigert die Aufmerksamkeit des Besuchers und verhilft dem Projekt zu einem höheren Bekanntheitsgrad. Hierbei kommt eine moderne und attraktive Visualisierung der Daten zum Einsatz, die die Informationserfassung unterstützt. Die gewünschte Visualisierung wird von unserem Auftraggeber erarbeitet und steht zum jetzigen Zeitpunkt noch nicht fest. Durch das Bekanntwerden des Projekts erhofft sich unser Auftraggeber eine breite Verteilung der kommenden da-sense Android-App, mit der Benutzer Daten sammeln und in die Datenbank transferieren können. Die Daten sind anschließend über die Webapplikation abrufbar.
\subsection{Codequalität}
>>Any fool can write code that a computer can understand. Good programmers write code that humans can understand.<< \cite{fowler}. \\
Der Quellcode, der im Rahmen des Projekt erstellt wird, soll offen für Erweiterungen sein und wird von weiteren Gruppen genutzt. Daher muss darauf geachtet werden, dass sämtliche Codebausteine auch für Außenstehende lesbar und verständlich sind. Zudem ist davon auszugehen, dass das Projekt in Zukunft als Open Source Projekt veröffentlicht wird, so dass auch unifremde Entwickler Zugriff haben und von der bestehenden Codequalität profitieren werden.
\subsection{Funktionalität}
\label{Ziel:Funktionalitaet}
Die Funktionalität unterteilen wir, wie vom Auftraggeber gefordert, in die drei Qualitätsmerkmale \textit{Richtigkeit}, \textit{Interoperabilität} und \textit{Sicherheit}, welche wir nach \cite{ISO/IEC 9126} definieren.
\begin{itemize}
\item Richtigkeit: \\
Da an dem gesamten Projekt da-sense viele Studenten mitwirken, können wir nicht für jede existierende Funktion die Richtigkeit garantieren. Wir beschränken uns hierbei auf die Funktionen der Datenbankinteraktionen und der Darstellung der neuen Visualisierung, welche von uns selbst implementiert werden.
\item Sicherheit: \\
Das Merkmal der Sicherheit wird beim Datenaustausch zwischen Smartphones bzw. \gls{Waspmote Sensoren} und der \gls{API} gefordert. Hierbei muss die Anwendung resistent gegenüber Angriffen, z.B. in Form von \glspl{SQL-Injection}, sein.
\item Interoperabilität: \\
Das Merkmal der Interoperabilität wird im zweiten Teil des Praktikums, bei der Visualisierung der gesammelten Daten, gewährleistet. Die Darstellung der gesammelten Daten muss in allen gängigen Webbrowsern (Firefox, Chrome, Internet Explorer und Safari) fehlerfrei sein. Wir beschränken uns bei den angegebenen Browsern auf die jeweilige aktuelle Version. Dies ist notwendig, da die neue Visualisierung auf \gls{HTML5} basiert.
\end{itemize}
\subsection{Erweiterbarkeit}
\label{Ziel:Codequalitaet}
>>Any fool can write code that a computer can understand. Good programmers write code that humans can understand.<< \cite{fowler}. \\ \\
Der Quellcode des Projektes ist offen für Erweiterungen und wird von weiteren Gruppen genutzt. Daher muss darauf geachtet werden, dass sämtliche Codebausteine auch für Außenstehende lesbar und verständlich sind. Geplant ist die Veröffentlichung des Quellcodes, so dass auch unifremde Entwickler Zugriff haben und von der bestehenden Codequalität profitieren. Es werden die Open Standards nach \cite{opensource.org} angewandt. Diese schließen unter anderem den Einsatz von kommerziellen Tools im Projekt aus.
@ -141,76 +156,93 @@ Der Quellcode, der im Rahmen des Projekt erstellt wird, soll offen f
% % % % % % % % % % % % % % % %% MAßNAHMEN ZUM ERREICHEN DER QUALITÄTSZIELE % % % % % % % % % % % % % % % %% % % % % % % % % %
\section{Maßnahmen zum Erreichen der Qualitätsziele}
Im folgenden Abschnitt werden die Maßnahmen zum Erreichen der oben genannten Qualitätsziele und die von uns dafür verwendeten Werkzeuge genauer beschrieben.
% Auch hier werden die Maßnahmen zur Sicherung von Funktionalität und Benutzbarkeit in den Vordergrund gestellt.
\subsection{Qualitätswerkzeuge}
\begin{itemize}
\item FireBug: \\
Dient der Fehlersuche, Bearbeitung und Monitoring des \gls{Webinterface}. FireBug ermöglicht uns die Ladezeiten einzelner Seitenelemente zu analysieren. Dies wird bei der neuen Visualisierung, deren Berechnung mittels HTML5 clientseitig ablaufen soll, von Bedeutung sein.
\item Git: \\
Als Versionsverwaltung dient \gls{Git}. Hierdurch ist ein einfacher Codeaustausch mit den übrigen Gruppen von da-sense möglich, wodurch jede Person stets über den aktuellen Code verfügt. Der Vorteil des \gls{Git} gegenüber einem \gls{SVN} ist für uns die Möglichkeit des lokalen commits, wodurch eine lokale Versionierung vorliegt. Somit kann jedes Gruppenmitglied seine Änderungen rückgängig machen.
\item Netbeans:\\
Als integrierte Entwicklungsumgebung (IDE) wird Netbeans verwendet, wodurch Syntaxfehler vermieden werden.
\item PHPUnit:\\
Testframework für PHP. Es beinhaltet eine Testumgebung für Datenbankinteraktionen, was für unser Projekt von Vorteil ist. Zudem arbeitet es mit XDebug zusammen und ermöglicht die Erstellung von CodeCoverage Analysen.
\item soapUI:\\
Freies Werkzeug, welches dem Testen des Webservices dient. Hierdurch ist es möglich manuelle Anfragen an den Webservice zu stellen und die Antworten auszuwerten. Zudem beinhaltet soapUI eine umfangreiche Testsuite.
\item XDebug:\\
Diagnose-Werkzeug (PHP-Debugger). Dient dem Auffinden von Fehlern und Code-Coverage Tests bei Ausführung des Programms.
\end{itemize}
\subsection{Funktionalität}
\textbf{Dieser Abschnitt ist noch nicht fertig!!} \\
Nach Rücksprache mit unserem Auftraggeber wird in diesem Dokument der Testablauf der folgenden zwei Use-Cases ausführlicher beschrieben:
\begin{itemize}
\item Parsen des neuen \gls{JSON}-Formats
\item Visualisierte Abfrage der Daten
\end{itemize}
\subsubsection{Use-Case: Parsen des neuen \gls{JSON}-Formats}
\subsubsection{Use-Case: Visualisierte Abfrage der Daten}
\subsection{Benutzbarkeit}
\label{subsec:aktionBenutzbarkeit}
Eine von uns durchgeführte Benutzerstudie stellt das Qualitätsmerkmal der Benutzbarkeit des neuen \glspl{Webinterface} sicher. Dieser Teil des Projekts wird erst am Ende des Projektzeitraums fertig. Aus diesem Grund kann auch die Benutzerstudie erst am Ende von uns durchgeführt werden. \\
Zur Benutzerstudie werden freiwilligen Probanden Bögen ausgeteilt, welche der Bewertung der einzelnen Kriterien (aus Abschnitt \ref{subsec:zielBenutzbarkeit}) der Benutzbarkeit des \glspl{Webinterface} dienen. Zudem werden einzelne Aktionen aller User auf der Webseite protokolliert, um im Anschluss durch eine Logdaten Analyse die Benutzerinteraktionen auswerten zu können. Durch die Benutzerstudie können somit Defizite des \glspl{Webinterface} aufgespürt und beseitigt werden. \\
Das Ziel der Benutzerstudie ist es eine Rückmeldung zu erhalten ob und wie sich der Benutzer auf der Website zurechtfindet. Es gilt herauszufinden, ob der User in einer für ihn angemessenen Zeit die gewünschten Informationen abrufen kann. Da das fertige Projekt eine breite Masse an Personen erreichen soll, ist es wichtig, dass die Benutzerstudie möglichst viele verschiedene Personengruppen umfasst. Das heißt, es werden Personen mit wenig bis viel Interneterfahrung bzw. junge bis ältere Personen als Probanden gesucht. Zudem können durch die Studie unvorhersehbare Probleme entdeckt werden, da ein Benutzer anders mit der Website umgeht als ein Entwickler. \newline \\
\textbf{Was wollen wir wissen?}
\label{Masnahme:Benutzbarkeit}
In der ersten Märzwoche 2012 (Kalenderwoche 9) wird eine Benutzerstudie durchgeführt. Somit bleibt uns genug Zeit die Ergebnisse auszuwerten und Schwachstellen in der Benutzeroberfläche zu beseitigen.
Zur Benutzerstudie werden freiwilligen Probanden Fragebögen ausgeteilt, welche der Bewertung der einzelnen Kriterien (Abschnitt \ref{Ziel:Benutzbarkeit}) der Benutzbarkeit des \glspl{Webinterface} dienen. Durch die Benutzerstudie können somit Defizite des \glspl{Webinterface} aufgespürt und beseitigt werden. \\ \\
Das Ziel der Benutzerstudie ist es eine Rückmeldung zu erhalten, ob und wie sich der Benutzer auf der Website zurechtfindet. Es gilt herauszufinden, ob der User in einer für ihn angemessenen Zeit die gewünschten Informationen abrufen kann. Da das fertige Projekt eine breite Masse an Personen erreichen wird, ist es wichtig, dass die Benutzerstudie möglichst viele verschiedene Personengruppen umfasst. Das heißt, es werden Personen unterschiedlichen Alters und mit unterschiedlicher Interneterfahrung ausgewählt. Zudem können durch die Studie unvorhersehbare Probleme entdeckt werden, da ein Benutzer auf eine andere Art und Weise mit der Website interagiert als ein Entwickler. \newline \\
\textbf{Was wir wissen wollen:}
\begin{itemize}
\item Ist die Visualisierung einfach zu verstehen und ansprechend?
\item Wie lange braucht der Nutzer um die gewünschten Informationen zu erhalten?
\item Wie lange braucht der Nutzer um sich einen Überblick zu verschaffen?
\item Treten unerwartete Fehler auf?
\end{itemize}
Die Benutzerstudie setzt sich aus den drei Teilen \textit{Beobachtung}, \textit{Fragebogen} und \textit{Logdaten Analyse} zusammen. Somit erhalten wir drei unterschiedliche Informationsquellen, welche in Korrelation zueinander stehen sollten.
Die Benutzerstudie setzt sich aus den zwei Teilen \textit{Beobachtung} und \textit{Fragebogen} zusammen. Somit erhalten wir zwei unterschiedliche Informationsquellen, welche in Korrelation zueinander stehen.
\subsubsection{Beobachtung}
Die Beobachtung des Probanden beim Bedienen der Website ist die einfachste Methode zur Evaluation. Hierbei bleibt der Entwickler in der Position des Beobachters und protokolliert. Der Proband surft frei nach seinem Willen durch die Website oder bekommt konkrete Aufgaben gestellt, die er lösen muss. \\
Bei der Beobachtung gilt es folgende Stichpunkte zu beachten:
Die Beobachtung des Probanden während der Bedienung der Website stellt die einfachste Methode dar, um auftretende Probleme frühzeitig zu erkennen. Hierbei nimmt der Entwickler die Position des Beobachters ein und führt Protokoll. Dem Probanden stehen fünf Minuten zur Verfügung, um sich mit der Benutzeroberfläche vertraut zu machen. Anschließend werden ihm Aufgaben (siehe Anhang) gestellt, die er mit Hilfe der Website lösen muss. Während der Beobachtung achtet der Entwickler auf folgende Punkte:
\begin{itemize}
\item Unerwartete Fehler
\item Probleme mit der Bedienung
\item vergangene Zeit bis zum Erhalt der gewünschten Informationen
\item ...
\item Vergangene Zeit bis zum Erhalt der gewünschten Informationen
\end{itemize}
\subsubsection{Fragebogen}
\label{fragebogen}
Der Fragebogen wird von uns Anfang März 2012 an die teilnehmenden Probanden ausgeteilt. Der genaue Termin wird sich an der Fertigstellung der neuen Visualisierung orientieren. Mit Hilfe des Fragebogens wollen wir Informationen von den verschiedensten Personengruppen aus Sicht eines Nutzers erhalten. Somit ist es möglich auf nutzerspezifische Anforderungen in der letzten Iteration des Projekts einzugehen. Die Fragen sind in drei Kategorien aufteilbar:
Mit Hilfe des Fragebogens erhalten wir Informationen von verschiedenen Personengruppen. Der Fragebogen lässt sich in die folgenden drei Kategorien unterteilen:
\begin{itemize}
\item Informationen über den Nutzer
\item Bewertung der aktuellen Website
\item Verbesserungsvorschläge
\end{itemize}
Durch Punkt eins und zwei können wir nach der Auswertung verschiedene Personengruppen identifizieren und bei ihnen aufgetauchte Probleme analysieren und beseitigen. Punkt drei erlaubt die Anpassung der Website an die nutzerspezifischen Anforderungen. \\
\textit{Der folgende Fragebogen kann sich während des gesamten Projekts ändern, da wir uns für den Prozess der \glspl{Agile Softwareentwicklung} entschieden haben. Es können neue Fragen hinzukommen oder aber bereits vorhandene geändert bzw. herausgenommen werden. Die Entscheidung über die zu stellenden Fragen obliegt dem gesamten Team. Hierdurch erhoffen wir uns, dass wir möglichst viele Bereiche des Projekts abfragen können.}
Durch Punkt eins können wir die Probanden in verschiedene Personengruppen einteilen. Die Einteilung der Personen in Gruppen erfolgt durch die Merkmale Alter und Interneterfahrung. Anschließend werden die gesammelten Ergebnisse aus Punkt zwei den einzelnen Personengruppen zugeteilt. Unterscheiden sich die Ergebnisse der einzelnen Gruppen stark, so muss der Auftraggeber entscheiden, für welche Zielgruppe die Benutzeroberfläche optimiert werden soll. Punkt drei erlaubt die Anpassung der Steuerungsoptionen der Website. Der Fragebogen ist im Anhang zu finden und kann sich noch bis zur Durchführung der Benutzerstudie ändern. Dies hängt mit dem von uns verwendeten Prozess der Agilen Softwareentwicklung zusammen. Es können Fragen hinzukommen oder aber bereits vorhandene geändert bzw. herausgenommen werden. Die Entscheidung über die zu stellenden Fragen obliegt dem gesamten Team.\\
\subsection{Funktionalität}
\label{Masnahme:Funktionalitaet} % ß wird von LaTex nicht akzeptiert als Label
Zur Sicherung der einzelnen Funktionalitätsmerkmale werden die folgenden Maßnahmen ergriffen:
\begin{itemize}
\item Richtigkeit: \\
Zur Sicherstellung der Richtigkeit werden \glspl{whitebox} mit \gls{PHPUnit} und \glspl{blackbox} mit \gls{Selenium} durchgeführt. Die korrekten Datenbankinteraktionen werden durch die Einhaltung der Vorgaben von \gls{Propel} sichergestellt. \gls{PHPUnit} erlaubt durch die integrierten Funktionen das einfache Testen von \gls{PHP}-Methoden. Somit können auftretende Fehler schnell beseitigt werden. \gls{Selenium} testet automatisiert die Anbindung der Daten an die Visualisierung. Hierzu wird eine Benutzereingabe aufgezeichnet, die nun im weiteren Entwicklungsprozess durch Selenium wiederholt ausgeführt werden kann. \gls{Propel} generiert für jede Tabelle der Datenbank eine Klasse. Die einzelnen Klassen enthalten alle notwendigen Funktionen, welche für die Datenbankinteraktionen genutzt werden. Somit können Fehler in SQL-Statements ausgeschlossen werden.
\item Sicherheit: \\
Das von uns verwendete \gls{ORM} \gls{Propel} nutzt \glspl{PreparedStatement}, mit denen sich \glspl{SQL-Injection} wirksam unterbinden lassen. Hierbei werden \gls{SQL}-Code und Daten getrennt. Zudem erfordert Propel keine \gls{SQL} Kentnisse, wodurch für neue Entwickler der Einstieg erleichtert wird. Der Eintrag der Daten über die \gls{API} erfolgt mittels HTTP-GET Parameter. Bevor die Aufnahme neuer Daten in die Datenbank erfolgen kann, ist eine Authentifizierung des Nutzers notwendig. Die Implementierung der Authentifizierung unterliegt nicht unserem Aufgabenbereich.
\item Interoperabilität: \\
Um die Interoperabilität mit den einzelnen Webbrowsern sicherzustellen, werden manuelle Tests durchgeführt. Hierzu wird jeweils die aktuelle Version des Webbrowsers verwendet. Jeder Browser wird mit denselben Benutzereingaben ausgeführt. Die jeweiligen Ausgaben erlauben einen direkten Vergleich. Außerdem werden im Rahmen der Benutzerstudie Fragebögen an Probanden ausgegeben. Die Auswertung dieser Fragebögen ermöglicht es uns, Rückschlüsse auf eventuell auftretende Fehler in der Visualisierung zu ziehen und zu beseitigen.
\end{itemize}
\subsection{Erweiterbarkeit}
\label{Masnahme:Erweiterbarkeit}
Um das Ziel der Erweiterbarkeit sicherzustellen, treffen wir folgende Vereinbarungen:
\begin{itemize}
\item Codedokumentation: \\
Jede von uns geschriebene Funktion besitzt einen vom geläufigen Javadoc-Format inspirierten Kommentarkopf der folgenden Form: \\
/** \\
* \textit{Description} \\
* @param \textit{paramtype} \\
* @return \textit{returntype} \\
* @tested \textit{boolean} \\
**/ \\
Wobei \textit{Description} durch einen funktionsbeschreibenden Text, \textit{paramtype} durch den Parametertyp, \textit{returntype} durch den Rückgabewert und \textit{boolean} durch den Wahrheitswert \glqq true\grqq\ bzw. \glqq false\grqq\ zu ersetzen ist. Somit erhalten die weiteren Entwickler schnell einen Überblick über die vorliegende Methode und ihre Funktionsweise.
\item Struktur: \\
Wir trennen im Quellcode strikt HTML-, \gls{JavaScript}- und \gls{PHP}-Code. Die Trennung erhöht die Lesbarkeit, vereinfacht die Fehlersuche und reduziert die Fehlerrate. Zur Trennung von Daten- und Präsentationsebene wird das \gls{MVC} verwendet. Hierdurch wird eine sinnvolle Codestrukturierung erreicht.
\item Namenskonvention: \\ %Glossareintrag zu CamelCase schreiben
Wir benutzen die CamelCase Konvention, welche unter anderem in Java als Standard gilt und zu einer besseren Lesbarkeit von Bezeichnern beiträgt.
\end{itemize}
Die aufgeführten Punkte werden von jedem Teammitglied eingehalten. Um dies sicherzustellen findet alle zwei Wochen ein teaminterner Codereview statt. Hierbei wird der Code aus den vergangenen zwei Wochen in der Gruppe besprochen und die Einhaltung der geforderten Konventionen geprüft. Wurden die Konventionen nicht eingehalten, so werden sie nach dem Treffen korrigiert. Somit ist jedes Teammitglied über den aktuellen Stand des Codes informiert und kennt auch die Codeteile der übrigen Teammitglieder.
% % % % % % % % % % % % % % % %% % % % % % % % % % % ANHANG % % % % % % % % % % % % % % % %% % % % % % % % % % % % % % % %
\newpage
\section{Anhang (vollständige Abgabe am 31.03.2012)}
\subsection{Benutzerstudie}
\label{Anhang:Benutzerstudie}
\subsubsection{Aufgaben}
\subsubsection{Fragebogen}
\begin{enumerate}
\item Wie alt sind Sie?
@ -279,87 +311,14 @@ Durch Punkt eins und zwei k
\end{enumerate}
\subsubsection{Logdaten Analyse}
Zur Analyse der Logdaten wird das kostenlose Tool Google Analytics verwendet, welches uns mit seiner Vielseitigkeit und Flexibilität überzeugt hat. Zudem erfolgt die Bedienung intuitiv, weshalb eine unter Umständen längere Einarbeitungszeit in andere Tools entfällt.
GoogleAnalytics erlaubt es verschiedenste Statistiken zu erhalten, mit deren Hilfe wir die Qualität des \glspl{User-Front-End} weiter erhöhen können. \\
Für uns sind die folgenden Statistiken von großer Bedeutung:
\begin{itemize}
\item Besucherzahlen
\item am meisten aufgerufene Seiten
\item Pfad der besuchten Seiten
\item Ausstiegsseiten
\item \glqq Absprungsrate\grqq
\item Besuchszeit der einzelnen Seiten
\item ...
\end{itemize}
Hierdurch erlangen wir einen Überblick wie das \gls{Webinterface} von den Nutzern bedient wird und können daraus schließen welche Funtionalitäten intutiv und welche weniger intuitiv sind.
\parindent 0pt
\paragraph{Datenschutz}
Um eine datenschutzkonforme Nutzung von Google Analytics zu gewährleisten, müssen folgende Vorgaben erfüllt werden \cite{DBA}:
\label{subsubsec:datenschutz}
\begin{itemize}
\item Vertrag zur Auftragsdatenverarbeitung mit Google (§ 11 BDSG - Vertrag)
\item Anonymisierung der IP-Adressen
\item Widerspruchsrecht der Betroffenen
\item angepasster Datenschutzhinweis
\item Löschung von Altdaten (bestehende Google Analytics Profile)
\end{itemize}
Punkt eins wird in den kommenden Wochen bearbeitet. Die Anonymisierung der IP-Adressen erfolgt durch Abschneiden der letzten 8 Bit der IP-Adresse. Das Widerspruchsrecht der Nutzer wird durch Google gewährleistet. Hierzu wird ein Add-on für den Webbrowser angeboten, welches Google Analytics deaktiviert. Da bisher keine Daten gesammelt wurden, müssen von uns auch keine Altdaten gelöscht werden.\\
Der angepasste Datenschutzhinweis findet sich im Impressum durch folgende Vorlage: \\
>> Diese Website benutzt Google Analytics, einen Webanalysedienst der Google Inc. (\glqq Google\grqq). Google Analytics verwendet sog. \glqq Cookies\grqq, Textdateien, die auf Ihrem Computer gespeichert werden und die eine Analyse der Benutzung der Website durch Sie ermöglichen. Die durch den Cookie erzeugten Informationen über Ihre Benutzung dieser Website werden in der Regel an einen Server von Google in den USA übertragen und dort gespeichert. Im Falle der Aktivierung der IP-Anonymisierung auf dieser Webseite, wird Ihre IP-Adresse von Google jedoch innerhalb von Mitgliedstaaten der Europäischen Union oder in anderen Vertragsstaaten des Abkommens über den Europäischen Wirtschaftsraum zuvor gekürzt. Nur in Ausnahmefällen wird die volle IP-Adresse an einen Server von Google in den USA übertragen und dort gekürzt. Im Auftrag des Betreibers dieser Website wird Google diese Informationen benutzen, um Ihre Nutzung der Website auszuwerten, um Reports über die Websiteaktivitäten zusammenzustellen und um weitere mit der Websitenutzung und der Internetnutzung verbundene Dienstleistungen gegenüber dem Websitebetreiber zu erbringen. Die im Rahmen von Google Analytics von Ihrem Browser übermittelte IP-Adresse wird nicht mit anderen Daten von Google zusammengeführt. Sie können die Speicherung der Cookies durch eine entsprechende Einstellung Ihrer Browser-Software verhindern; wir weisen Sie jedoch darauf hin, dass Sie in diesem Fall gegebenenfalls nicht sämtliche Funktionen dieser Website vollumfänglich werden nutzen können. Sie können darüber hinaus die Erfassung der durch das Cookie erzeugten und auf Ihre Nutzung der Website bezogenen Daten (inkl. Ihrer IP-Adresse) an Google sowie die Verarbeitung dieser Daten durch Google verhindern, indem sie das unter dem folgenden Link (\href{http://tools.google.com/dlpage/gaoptout?hl=de}{http://tools.google.com/dlpage/gaoptout?hl=de}) verfügbare Browser-Plugin herunterladen und installieren. Nähere Informationen hierzu finden Sie unter \href{http://tools.google.com/dlpage/gaoptout?hl=de}{http://tools.google.com/dlpage/gaoptout?hl=de} bzw. unter
\href{http://www.google.com/intl/de/analytics/privacyoverview.html}{http://www.google.com/intl/de/analytics/privacyoverview.html} (allgemeine Informationen zu Google Analytics und Datenschutz). Wir weisen Sie darauf hin, dass auf dieser Webseite Google Analytics um den Code \glqq gat.\_anonymizeIp();\grqq erweitert wurde, um eine anonymisierte Erfassung von IP-Adressen (sog. IP-Masking) zu gewährleisten. << \cite{DBA}
\subsection{Codequalität}
Die folgenden Anforderungen und Vereinbarungen sollen dem Ziel eines gut strukturierten und gut lesbaren Codes beitragen:
\begin{itemize}
\item Kommentare: \\
Jede von uns geschriebene, nicht triviale Funktion muss einen Kommentarkopf der folgenden Form besitzen:\\
/** \\
* \textit{Description} \\
* @param \textit{paramtype} \\
* @return \textit{returntype} \\
* @tested \textit{boolean} \\
**/ \\
Wobei \textit{Description} durch einen funktionsbeschreibenden Text, \textit{paramtype} durch den Parametertyp, \textit{returntype} durch den Rückgabewert und \textit{boolean} durch den Wahrheitswert \glqq true\grqq bzw. \glqq false\grqq zu ersetzen sind.
\item Struktur: \\
Der Code soll folgenden Standards gerecht werden: \\
\begin{itemize}
\item \gls{XHTML} in Version 1.1, standardisiert vom W3C 2010, \href{http://www.w3.org/TR/xhtml11/}{http://www.w3.org/TR/xhtml11/}
\end{itemize}
\item Namenskonventionen: \\
Als Konvention nutzen wir CamelCase, welche in Java als Standard gilt und zu einer besseren Lesbarkeit von Bezeichnern beiträgt.
\item Wiki: \\
Zusätzlich zu den Kommentaren im Code wird ein Wiki gepflegt, das im \gls{Git} abrufbar ist und somit der besseren Verständlichkeit des Projekts durch andere Gruppen beiträgt.
\end{itemize}
% % % % % % % % % % % % % % % %% % % % % % % % % % % ANHANG % % % % % % % % % % % % % % % %% % % % % % % % % % % % % % % %
\newpage
\section{Anhang}
Der Anhang wird erst in der finalen Version, die am 31.03.2012 abgegeben werden muss, komplett sein.
\subsection{Testdokumentation}
Auf den folgenden Seiten findet sich die Dokumentation über die von uns durchgeführten Tests im Laufe des Praktikums.
\subsubsection{Funktionalität}
\subsubsection{Benutzerstudie}
Wie in Abschnitt \ref{subsec:aktionBenutzbarkeit} beschrieben, wird die Benutzerstudie erst am Ende des Projekts durchgeführt, da das Webinterface zum jetzigen Zeitpunkt noch nicht fertiggestellt ist. Die Testdokumentation erfolgt somit im Anschluss und wird sich in der finalen Version dieses Dokuments (Abgabedatum 31.03.2012) befinden.
\subsubsection{Logdaten Analyse}
Die Logdaten Analyse steht in Zusammenhang mit der Benutzerstudie und wird somit auch erst am Ende des Projekts durchgeführt. Die Testdokumentation erfolgt somit im Anschluss und wird sich in der finalen Version dieses Dokuments (Abgabedatum 31.03.2012) befinden.
\subsubsection{Codequalität}
%\subsubsection{Codequalität}
\subsection{User-Stories}
@ -370,12 +329,20 @@ Die Logdaten Analyse steht in Zusammenhang mit der Benutzerstudie und wird somit
Für eine bessere Nachvollziehbarkeit sind die Änderungen in diesem Dokument tabellarisch festgehalten.
\begin{tabbing}
\begin{tabular}{||p{5.4cm}||p{11cm}||}
\begin{tabular}{||p{6cm}||p{11cm}||}
%\hline \rule[-2ex]{0pt}{5.5ex} Noch eine version & test \\
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.0.0 - 01.12.2011 - MS & Dokument angelegt\\
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.0.1 - 09.12.2011 - MS & Einleitung, Qualitätsziele (Codequalität, Funktionalität), Qualitätswerkzeuge\\
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.0.9 - 14.12.2011 - MS & Benutzerstudie \\
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.1.0 - 18.12.2011 - LM, MB, MS & Fehlerkorrekturen, Details hinzugefügt \\
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.1.0 - 01.12.2011 - MS & Dokument angelegt\\
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.1.6 - 09.12.2011 - MS & Einleitung, Qualitätsziele (Codequalität, Funktionalität)\\
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.2.1 - 11.12.2011 - MS, UG & Qualitätswerkzeuge hinzugefügt \\
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.2.9 - 14.12.2011 - MS & Benutzerstudie \\
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.3.4 - 17.12.2011 - MB, LM & Fehlerkorrekturen \\
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.4.0 - 18.12.2011 - LM, MB, MS & Fehlerkorrekturen, Details hinzugefügt \\
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.4.8 - 11.01.2012 - MS & Fehlerkorrekturen, Dokument überarbeitet \\
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.5.1 - 12.01.2012 - LM, UG, MB, MS & Fragebogen: Fragen überarbeitet \\
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.7.0 - 13.01.2012 - LM, UG, MB, MS & Dokument nach Feedback komplett überarbeitet\\
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.7.5 - 15.01.2012 - MS & Logfile Analyse entfernt \\
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.8.1 - 18.01.2012 - MS & Rechtschreibfehler, Kommasetzung \\
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.9.0 - 24.01.2012 - LM, UG, MB, MS & Erste Abgabeversion ohne Anhang \\
%\hline \rule[-2ex]{0pt}{5.5ex} ... - .... & ... \\
\hline
\end{tabular}
@ -394,15 +361,18 @@ F
%fügt elemenmte dem toc hinzu
\addcontentsline{toc}{section}{Literatur}
\begin{thebibliography}{------}
% \bibitem[BSS+2008]{bss+:2008} Helmut Balzert, Christian Schäfer, Marion Schröder, Uwe Kern: \emph{Wissenschaftliches Arbeiten - Wissenschaft, Quellen, Artefakte, Organisation, Präsentation}, Witten: W3L, 2008
\bibitem[DBA]{DBA} \href{http://www.datenschutzbeauftragter-info.de/fachbeitraege/google-analytics-datenschutzkonform-einsetzen/}{http://www.datenschutzbeauftragter-info.de/fachbeitraege/google-analytics-datenschutzkonform-einsetzen/}
\bibitem[ISO/IEC 9126]{ISO/IEC 9126} International Organization for Standardization \emph{ISO/IEC 9126} \\Auszug: Wikipedia, \href{http://de.wikipedia.org/wiki/ISO/IEC_9126}{http://de.wikipedia.org/wiki/ISO/IEC\_9126}
% \bibitem[ISO9001]{iso:9001} International Organization for Standardization. \emph{ISO 9001}, 12.2008
\bibitem[FBBOR+1999]{fowler} Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts: \emph{Refactoring: Improving the Design of Existing Code}, Written: 1999
\bibitem[ISO/IEC 9126]{ISO/IEC 9126} International Organization for Standardization \emph{ISO/IEC 9126} \\Auszug: Wikipedia, \href{http://de.wikipedia.org/wiki/ISO/IEC_9126}{http://de.wikipedia.org/wiki/ISO/IEC\_9126}
\bibitem[OSI]{opensource.org} Open Source Initiative: \href{http://www.opensource.org/}{http://www.opensource.org/}
% \bibitem[BSS+2008]{bss+:2008} Helmut Balzert, Christian Schäfer, Marion Schröder, Uwe Kern: \emph{Wissenschaftliches Arbeiten - Wissenschaft, Quellen, Artefakte, Organisation, Präsentation}, Witten: W3L, 2008
% \bibitem[ISO9001]{iso:9001} International Organization for Standardization. \emph{ISO 9001}, 12.2008
% \bibitem[WIKI2011]{wiki:2011} Wikipedia, die freie Enzyklopädie. \emph{WIKIPEDIA}, Stand: 12.12.2011
\end{thebibliography}

Binary file not shown.

View File

@ -0,0 +1,61 @@
2.3 "Erweiterbarkeit"
-> "Damit das Projekt in Zukunft in der Open-Source-Szene anerkannt wird, werden die Open Standards nach [OSI] angewendet. Hierbei duerfen keine kommerziellen Tools im Projekt
eingesetzt werden"
ersetzen durch
"Die Open Standards werden nach [OSI] angewendet. Dieser schliesst den Einsatz kommerzieller
Tools im Projekt aus." [Anmerkung: schliesst schreibt man mit scharfem S!]
-> leicht abgeändert eingefügt!
3.1 "Funktionalitaet"
-> "Richtigkeit":
-> "Interoperabilitaet":
"In jedem Browser werden exakt dieselben Benutzereingaben ausgefuehrt. Die jeweiligen
Ausgaben koennen somit direkt verglichen werden."
ersetzen durch:
"Jeder Browser wird mit den selben Benutzereingaben ausgefuehrt. Die jeweiligen
Ausgaben erlauben einen direkten Vergleich."
-------------------
"Zudem erhalten wir durch die Auswertung des Fragenbogens, der im Rahmen der
Benutzerstudie an Probanden ausgegeben wird, eine Rueckmeldung ueber eventuell
auftretende Fehler der Visualisierung."
ersetzen durch:
"Ausserdem werden, im Rahmen der Benutzerstudie, Frageboegen an Testpersonen [oder
Probanden] ausgegeben. Die Auswertung dieser Frageboegen ermoeglicht es uns,
Rueckschluesse auf eventuell auftretende Fehler in der Visiualisierung zu ziehen und zu
beseitigen."
3.2 "Benutzbarkeit"
Mein Vorschlag:
"In der ersten Maerzwoche 2012 fuehren wir eine Benutzerstudie durch, um das
Qualitaetsmerkmal der Benutzbarkeit des Webinterfaces zu gewaehrleisten. Hierzu bekommen frewillige Probanden einen Fragebogen ausgeteilt, mit dem sie die Ausgestaltung und
Bedienung der Webseite bewerten. Die Evaluierung der Ergebnisse gestattet die Erkennung und Beseitigung von Problemen im Webinterface. Ausserdem wird festgestellt, ob der
Benutzer in einem angemessenen Zeitrahmen die gewuenschten Inhalte finden und abrufen
kann. Fuer die Benutzerstudie kommen Menschen unterschiedlichen Alters und mit
unterschiedlicher Interneterfahrung in Frage. Dies steigert die Aussagekraft der Studie."
3.2.1 "Beobachtung"
"Die Beobachtung des Probanden waehrend der Bedienung der Webseite, stellt die einfachste
Methode dar, um auftretende Probleme fruehzeitig zu erkennen. Hierbei nimmt der
Entwickler die Position des Beobachters ein und fuehrt Protokoll. Dem Probanden stehen
fuenf Minuten zur Verfuegung, um sich mit der Benutzeroberflaeche vertraut zu machen.
Anschliessend [Anmerkung: Anschliessend mit scharfem S!] werden Aufgaben gestellt, die
er loesen muss. Waehrend der Beobachtung achtet der Entwickler auf folgende Punkte:"
3.2.2 "Fragebogen"
Wuerde ich gerne Morgen nochmal besprechen

View File

@ -0,0 +1,44 @@
QS-Dokument - Verbesserungsvorschläge:
-> Bei jeder Maßnahme muss aufgeführt werden:
- Was wird gemacht?
- Wie wird getestet?
- Wann wird es gemacht?
- Wer macht es?
- Und wie wird im Fehlerfall reagiert?
3.1 Funktionalität:
Richtigkeit (Datenbankinteraktionen und Darstellung der Visualisierung):
Sicherheit:
Interoperabilität:
------------------------------------------------------------------------------------------------------------------
3.2 Benutzbarkeit:
3.2.1 Beobachtung:
3.2.2 Fragebogen:
------------------------------------------------------------------------------------------------------------------
3.3: Codequalität:

View File

@ -1,3 +1,7 @@
- 2.1, 2.2 Kopie von ISO rausmachen. "Wir definieren nach ISO"!
Codequalität: In der OpenSource Szene sind folgende Codestandards etabliert…..
Strukturierung: einfachstes Format: grobe, große Ziele. Kann auf eine halbe Seite passen. Rest sind Maßnahmen. Also Aufteilung in zwei Kapitel möglich.
Abgabetermin: Ende Januar (24.01)! Anhang dann Ende März!

View File

@ -1 +1 @@
Um das Glossar zu erstellen muss die .text-Datei einmal kompiliert, dann mittel Konsole und "makeglossaries Qs-Dokument" die Glossardateien erstellt und anschließend die .text-Datei nochmals kompiliert werden.
Um das Glossar zu erstellen muss die .text-Datei einmal kompiliert, dann mittels Konsole und "makeglossaries Qs-Dokument" die Glossardateien erstellt und anschließend die .text-Datei nochmals kompiliert werden.

View File

@ -7,29 +7,31 @@
\begin{document}
\title{User Stories\\
da\_sense \\
Wintersemester 2011/2012}
\title{Thema: da-sense\\
Gruppe 1b}
\subtitle{Auftraggeber: Immanuel Schweizer (Telecooperation Group TU Darmstadt) \\
\subtitle{User-Stories zum Bachelor-Praktikum im Wintersemester 2011/2012}
\subsubtitle{Auftraggeber: Immanuel Schweizer (Telecooperation Group TU Darmstadt) \\
Gruppe 1b: Murat Batu, Ulf Gebhardt, Lulzim Murati, Michael Scholz\\
Teamleiter: Dominik Fischer
}
\subsubtitle{Verison: 0.0.1}
Teamleiter: Dominik Fischer}
\author{Murat Batu, Ulf Gebhardt, Lulzim Murati, Michael Scholz}
\maketitle
%INFOS zur den User Stories:
% velocity: Zeit pro Story Point: Berechnet sich aus (Tatsächlicher Aufwand) / (Geschätzter Aufwand)
\newpage
\begin{tabbing}
\begin{tabular}{ || p{5.4cm} || p{11cm} ||}
\hline \rule[-2ex]{0pt}{5.5ex} ID & 1.1\\
\hline \rule[-2ex]{0pt}{5.5ex} Name & Anpassung des JSON-Parsers an neues JSON-Format \\
\hline \rule[-2ex]{0pt}{5.5ex} Name & Anpassung des JSON-Parsers an neues JSON-Format und neue Datenbank \\
\hline \rule[-2ex]{0pt}{5.5ex} Beschreibung & Durch die veränderte Datenbank hat sich auch das JSON-Format, indem die Daten von den Sensoren gesendet werden, geändert. Somit muss der aktuelle JSON-Parser angepasst werden.\\
\hline \rule[-2ex]{0pt}{5.5ex} Geschätzter Aufwandc& 7\\
\hline \rule[-2ex]{0pt}{5.5ex} Tatsächlicher Aufwand (h) & noch offen\\
\hline \rule[-2ex]{0pt}{5.5ex} Velocity & noch offen \\ %2,17 h/Story-Point\\
\hline \rule[-2ex]{0pt}{5.5ex} Geschätzter Aufwand (h) & 13\\
\hline \rule[-2ex]{0pt}{5.5ex} Tatsächlicher Aufwand (h) & 15,5\\
\hline \rule[-2ex]{0pt}{5.5ex} Velocity & 1,19 h/Story-Point \\
\hline \rule[-2ex]{0pt}{5.5ex} Entwickler & Michael Scholz\\
\hline \rule[-2ex]{0pt}{5.5ex} Iteration & 1\\
\hline \rule[-2ex]{0pt}{5.5ex} Akzeptanzkriterium & Smartphone-App und Wespmote-Sensoren können problemlos Daten in die Datenbank schreiben.\\
@ -44,24 +46,40 @@ Teamleiter: Dominik Fischer
\begin{tabbing}
\begin{tabular}{ || p{5.4cm} || p{11cm} ||}
\hline \rule[-2ex]{0pt}{5.5ex} ID & 6.1\\
\hline \rule[-2ex]{0pt}{5.5ex} Name & Erste Integration in bestehendes Programm \\
\hline \rule[-2ex]{0pt}{5.5ex} Beschreibung & Als User möchte ich die bisher realisierten Funktionalitäten innerhalb des bestehenden Editors
verwenden können.\\
\hline \rule[-2ex]{0pt}{5.5ex} Geschätzter Aufwandc& 9\\
\hline \rule[-2ex]{0pt}{5.5ex} Tatsächlicher Aufwand (h) & 19,5\\
\hline \rule[-2ex]{0pt}{5.5ex} Velocity & 2,17 h/Story-Point\\
\hline \rule[-2ex]{0pt}{5.5ex} Entwickler & Max Mustermann\\
\hline \rule[-2ex]{0pt}{5.5ex} Iteration & 4\\
\hline \rule[-2ex]{0pt}{5.5ex} Akzeptanzkriterium & Es ist möglich eine Open Street Map Karte zu laden
und im Editor anzeigen zu lassen wobei Funktionalitäten wie zoom und scrollen auch nutzbar
sein sollen.\\
\hline \rule[-2ex]{0pt}{5.5ex} Bemerkung & --\\
\hline \rule[-2ex]{0pt}{5.5ex} ID & 1.2\\
\hline \rule[-2ex]{0pt}{5.5ex} Name & SQL-Statements im JSON-Parser mittels Propel realisieren \\
\hline \rule[-2ex]{0pt}{5.5ex} Beschreibung & Der gesamte SQL-Code zur Datenbankanbindung soll sich in einer eigenen Klasse befinden und mittels Propel realisiert werden. Somit darf der JSON-Parser nur noch Funktionsaufrufe der SQL-Klasse enthalten.\\
\hline \rule[-2ex]{0pt}{5.5ex} Geschätzter Aufwand (h) & 6,5\\
\hline \rule[-2ex]{0pt}{5.5ex} Tatsächlicher Aufwand (h) & 8 \\
\hline \rule[-2ex]{0pt}{5.5ex} Velocity & 1,23 h/Story-Point\\
\hline \rule[-2ex]{0pt}{5.5ex} Entwickler & Michael Scholz\\
\hline \rule[-2ex]{0pt}{5.5ex} Iteration & 2\\
\hline \rule[-2ex]{0pt}{5.5ex} Akzeptanzkriterium & Smartphone-App und Wespmote-Sensoren können problemlos Daten in die Datenbank schreiben, wie in User-Storie 1.1 gefordert.\\
\hline \rule[-2ex]{0pt}{5.5ex} Bemerkung & Die aufgerufenen Funktionen befinden sich unter \glqq classes/propel/propel\_dasensedata.php\grqq. Hier sind alle SQL-Statements enthalten, die für die Interaktion mit der Datanbank \glqq dasensedata\grqq\ nötig sind.\\
\hline
\end{tabular}
\end{tabbing}
% % % % % % % % % % % % % % % % % % NEXT TABLE % % % % % % % % % % % % % % % % % %
\vspace{1cm}
\begin{tabbing}
\begin{tabular}{ || p{5.4cm} || p{11cm} ||}
\hline \rule[-2ex]{0pt}{5.5ex} ID & 2.1\\
\hline \rule[-2ex]{0pt}{5.5ex} Name & Entwicklung und Integration der Preprocessing Klasse in das bestehende Projekt\\
\hline \rule[-2ex]{0pt}{5.5ex} Beschreibung & Zur strikten Trennung von HTML-, PHP- und JavaScript-Code existieren Platzhalter, an deren Stelle Inhalte dynamisch eingebunden werden. Die Ersetzung dieser Platzhalter "ubernimmt die Preprocessing Klasse.\\
\hline \rule[-2ex]{0pt}{5.5ex} Geschätzter Aufwand (h) & 1\\
\hline \rule[-2ex]{0pt}{5.5ex} Tatsächlicher Aufwand (h) & 1,5\\
\hline \rule[-2ex]{0pt}{5.5ex} Velocity & 1,5 h/Story-Point \\
\hline \rule[-2ex]{0pt}{5.5ex} Entwickler & Lulzim Murati\\
\hline \rule[-2ex]{0pt}{5.5ex} Iteration & 1\\
\hline \rule[-2ex]{0pt}{5.5ex} Akzeptanzkriterium & Alle Platzhalter werden erkannt und durch die gewünschten Inhalte substituiert, um die korrekte Darstellung der Webseite zu gew"ahrleisten.\\
\hline \rule[-2ex]{0pt}{5.5ex} Bemerkung & Ein Platzhalter besitzt ein festes Format: \$\{bezeichner\}. Zur Erweiterung und Umstrukturierung der Webseite, können weitere Platzhalter eingef"ugt werden.\\
\hline
\end{tabular}
\end{tabbing}
% % % % % % % % % % % % % % % % % % NEXT TABLE % % % % % % % % % % % % % % % % % %
\vspace{1cm}
@ -71,7 +89,7 @@ sein sollen.\\
\hline \rule[-2ex]{0pt}{5.5ex} Name & Erste Integration in bestehendes Programm \\
\hline \rule[-2ex]{0pt}{5.5ex} Beschreibung & Als User möchte ich die bisher realisierten Funktionalitäten innerhalb des bestehenden Editors
verwenden können.\\
\hline \rule[-2ex]{0pt}{5.5ex} Geschätzter Aufwandc& 9\\
\hline \rule[-2ex]{0pt}{5.5ex} Geschätzter Aufwand (h) & 9\\
\hline \rule[-2ex]{0pt}{5.5ex} Tatsächlicher Aufwand (h) & 19,5\\
\hline \rule[-2ex]{0pt}{5.5ex} Velocity & 2,17 h/Story-Point\\
\hline \rule[-2ex]{0pt}{5.5ex} Entwickler & Max Mustermann\\
@ -93,7 +111,7 @@ sein sollen.\\
\hline \rule[-2ex]{0pt}{5.5ex} Name & Erste Integration in bestehendes Programm \\
\hline \rule[-2ex]{0pt}{5.5ex} Beschreibung & Als User möchte ich die bisher realisierten Funktionalitäten innerhalb des bestehenden Editors
verwenden können.\\
\hline \rule[-2ex]{0pt}{5.5ex} Geschätzter Aufwandc& 9\\
\hline \rule[-2ex]{0pt}{5.5ex} Geschätzter Aufwand (h) & 9\\
\hline \rule[-2ex]{0pt}{5.5ex} Tatsächlicher Aufwand (h) & 19,5\\
\hline \rule[-2ex]{0pt}{5.5ex} Velocity & 2,17 h/Story-Point\\
\hline \rule[-2ex]{0pt}{5.5ex} Entwickler & Max Mustermann\\
@ -115,7 +133,7 @@ sein sollen.\\
\hline \rule[-2ex]{0pt}{5.5ex} Name & Erste Integration in bestehendes Programm \\
\hline \rule[-2ex]{0pt}{5.5ex} Beschreibung & Als User möchte ich die bisher realisierten Funktionalitäten innerhalb des bestehenden Editors
verwenden können.\\
\hline \rule[-2ex]{0pt}{5.5ex} Geschätzter Aufwandc& 9\\
\hline \rule[-2ex]{0pt}{5.5ex} Geschätzter Aufwand (h) & 9\\
\hline \rule[-2ex]{0pt}{5.5ex} Tatsächlicher Aufwand (h) & 19,5\\
\hline \rule[-2ex]{0pt}{5.5ex} Velocity & 2,17 h/Story-Point\\
\hline \rule[-2ex]{0pt}{5.5ex} Entwickler & Max Mustermann\\
@ -137,7 +155,7 @@ sein sollen.\\
\hline \rule[-2ex]{0pt}{5.5ex} Name & Erste Integration in bestehendes Programm \\
\hline \rule[-2ex]{0pt}{5.5ex} Beschreibung & Als User möchte ich die bisher realisierten Funktionalitäten innerhalb des bestehenden Editors
verwenden können.\\
\hline \rule[-2ex]{0pt}{5.5ex} Geschätzter Aufwandc& 9\\
\hline \rule[-2ex]{0pt}{5.5ex} Geschätzter Aufwand (h) & 9\\
\hline \rule[-2ex]{0pt}{5.5ex} Tatsächlicher Aufwand (h) & 19,5\\
\hline \rule[-2ex]{0pt}{5.5ex} Velocity & 2,17 h/Story-Point\\
\hline \rule[-2ex]{0pt}{5.5ex} Entwickler & Max Mustermann\\
@ -159,29 +177,7 @@ sein sollen.\\
\hline \rule[-2ex]{0pt}{5.5ex} Name & Erste Integration in bestehendes Programm \\
\hline \rule[-2ex]{0pt}{5.5ex} Beschreibung & Als User möchte ich die bisher realisierten Funktionalitäten innerhalb des bestehenden Editors
verwenden können.\\
\hline \rule[-2ex]{0pt}{5.5ex} Geschätzter Aufwandc& 9\\
\hline \rule[-2ex]{0pt}{5.5ex} Tatsächlicher Aufwand (h) & 19,5\\
\hline \rule[-2ex]{0pt}{5.5ex} Velocity & 2,17 h/Story-Point\\
\hline \rule[-2ex]{0pt}{5.5ex} Entwickler & Max Mustermann\\
\hline \rule[-2ex]{0pt}{5.5ex} Iteration & 4\\
\hline \rule[-2ex]{0pt}{5.5ex} Akzeptanzkriterium & Es ist möglich eine Open Street Map Karte zu laden
und im Editor anzeigen zu lassen wobei Funktionalitäten wie zoom und scrollen auch nutzbar
sein sollen.\\
\hline \rule[-2ex]{0pt}{5.5ex} Bemerkung & --\\
\hline
\end{tabular}
\end{tabbing}
% % % % % % % % % % % % % % % % % % NEXT TABLE % % % % % % % % % % % % % % % % % %
\vspace{1cm}
\begin{tabbing}
\begin{tabular}{ || p{5.4cm} || p{11cm} ||}
\hline \rule[-2ex]{0pt}{5.5ex} ID & 6.1\\
\hline \rule[-2ex]{0pt}{5.5ex} Name & Erste Integration in bestehendes Programm \\
\hline \rule[-2ex]{0pt}{5.5ex} Beschreibung & Als User möchte ich die bisher realisierten Funktionalitäten innerhalb des bestehenden Editors
verwenden können.\\
\hline \rule[-2ex]{0pt}{5.5ex} Geschätzter Aufwandc& 9\\
\hline \rule[-2ex]{0pt}{5.5ex} Geschätzter Aufwand (h) & 9\\
\hline \rule[-2ex]{0pt}{5.5ex} Tatsächlicher Aufwand (h) & 19,5\\
\hline \rule[-2ex]{0pt}{5.5ex} Velocity & 2,17 h/Story-Point\\
\hline \rule[-2ex]{0pt}{5.5ex} Entwickler & Max Mustermann\\

BIN
ws2011/BP/Wiki-Stuff/.DS_Store vendored Normal file

Binary file not shown.

View File

@ -0,0 +1,189 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<graphml xmlns="http://graphml.graphdrawing.org/xmlns" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:y="http://www.yworks.com/xml/graphml" xmlns:yed="http://www.yworks.com/xml/yed/3" xsi:schemaLocation="http://graphml.graphdrawing.org/xmlns http://www.yworks.com/xml/schema/graphml/1.1/ygraphml.xsd">
<!--Created by yFiles for Java 2.8-->
<key for="graphml" id="d0" yfiles.type="resources"/>
<key for="port" id="d1" yfiles.type="portgraphics"/>
<key for="port" id="d2" yfiles.type="portgeometry"/>
<key for="port" id="d3" yfiles.type="portuserdata"/>
<key attr.name="url" attr.type="string" for="node" id="d4"/>
<key attr.name="description" attr.type="string" for="node" id="d5"/>
<key for="node" id="d6" yfiles.type="nodegraphics"/>
<key attr.name="Beschreibung" attr.type="string" for="graph" id="d7"/>
<key attr.name="url" attr.type="string" for="edge" id="d8"/>
<key attr.name="description" attr.type="string" for="edge" id="d9"/>
<key for="edge" id="d10" yfiles.type="edgegraphics"/>
<graph edgedefault="directed" id="G">
<data key="d7"/>
<node id="n0">
<data key="d4"/>
<data key="d5"><![CDATA[UMLClass]]></data>
<data key="d6">
<y:UMLClassNode>
<y:Geometry height="28.0" width="100.0" x="353.0" y="46.0"/>
<y:Fill color="#C5D683" color2="#C5D683" transparent="false"/>
<y:BorderStyle color="#C5D683" type="line" width="1.0"/>
<y:NodeLabel alignment="center" autoSizePolicy="content" fontFamily="Dialog" fontSize="13" fontStyle="bold" hasBackgroundColor="false" hasLineColor="false" height="19.310546875" modelName="internal" modelPosition="t" textColor="#000000" visible="true" width="24.48388671875" x="37.758056640625" y="3.0">api</y:NodeLabel>
<y:UML clipContent="true" constraint="" omitDetails="false" stereotype="" use3DEffect="true">
<y:AttributeLabel/>
<y:MethodLabel/>
</y:UML>
</y:UMLClassNode>
</data>
</node>
<node id="n1">
<data key="d4"/>
<data key="d5"><![CDATA[UMLClass]]></data>
<data key="d6">
<y:UMLClassNode>
<y:Geometry height="28.0" width="166.0" x="542.0" y="114.0"/>
<y:Fill color="#C5D683" color2="#C5D683" transparent="false"/>
<y:BorderStyle color="#C5D683" type="line" width="1.0"/>
<y:NodeLabel alignment="center" autoSizePolicy="content" fontFamily="Dialog" fontSize="13" fontStyle="bold" hasBackgroundColor="false" hasLineColor="false" height="19.310546875" modelName="internal" modelPosition="t" textColor="#000000" visible="true" width="138.189453125" x="13.9052734375" y="3.0">ArgumentController</y:NodeLabel>
<y:NodeLabel alignment="center" autoSizePolicy="content" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" height="18.1328125" modelName="internal" modelPosition="c" textColor="#000000" visible="true" width="232.28125" x="-33.140625" y="4.93359375">handles all HTTP-GET/POST-Paramters</y:NodeLabel>
<y:NodeLabel alignment="center" autoSizePolicy="content" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" height="18.1328125" modelName="internal" modelPosition="c" textColor="#000000" visible="true" width="25.779296875" x="70.1103515625" y="4.93359375">test</y:NodeLabel>
<y:UML clipContent="true" constraint="" omitDetails="false" stereotype="" use3DEffect="true">
<y:AttributeLabel/>
<y:MethodLabel/>
</y:UML>
</y:UMLClassNode>
</data>
</node>
<node id="n2">
<data key="d4"/>
<data key="d5"><![CDATA[UMLClass]]></data>
<data key="d6">
<y:UMLClassNode>
<y:Geometry height="28.0" width="159.0" x="130.0" y="114.0"/>
<y:Fill color="#C5D683" color2="#C5D683" transparent="false"/>
<y:BorderStyle color="#C5D683" type="line" width="1.0"/>
<y:NodeLabel alignment="center" autoSizePolicy="content" fontFamily="Dialog" fontSize="13" fontStyle="bold" hasBackgroundColor="false" hasLineColor="false" height="19.310546875" modelName="internal" modelPosition="t" textColor="#000000" visible="true" width="125.62109375" x="16.689453125" y="3.0">AccountController</y:NodeLabel>
<y:UML clipContent="true" constraint="" omitDetails="false" stereotype="" use3DEffect="true">
<y:AttributeLabel/>
<y:MethodLabel/>
</y:UML>
</y:UMLClassNode>
</data>
</node>
<node id="n3">
<data key="d4"/>
<data key="d5"><![CDATA[UMLClass]]></data>
<data key="d6">
<y:UMLClassNode>
<y:Geometry height="28.0" width="129.0" x="56.0" y="269.0"/>
<y:Fill color="#C5D683" color2="#C5D683" transparent="false"/>
<y:BorderStyle color="#C5D683" type="line" width="1.0"/>
<y:NodeLabel alignment="center" autoSizePolicy="content" fontFamily="Dialog" fontSize="13" fontStyle="bold" hasBackgroundColor="false" hasLineColor="false" height="19.310546875" modelName="internal" modelPosition="t" textColor="#000000" visible="true" width="97.7041015625" x="15.64794921875" y="3.0">DaSenseLogin</y:NodeLabel>
<y:UML clipContent="true" constraint="" omitDetails="false" stereotype="" use3DEffect="true">
<y:AttributeLabel/>
<y:MethodLabel/>
</y:UML>
</y:UMLClassNode>
</data>
</node>
<node id="n4">
<data key="d4"/>
<data key="d5"><![CDATA[UMLClass]]></data>
<data key="d6">
<y:UMLClassNode>
<y:Geometry height="28.0" width="145.0" x="208.0" y="269.0"/>
<y:Fill color="#C5D683" color2="#C5D683" transparent="false"/>
<y:BorderStyle color="#C5D683" type="line" width="1.0"/>
<y:NodeLabel alignment="center" autoSizePolicy="content" fontFamily="Dialog" fontSize="13" fontStyle="bold" hasBackgroundColor="false" hasLineColor="false" height="19.310546875" modelName="internal" modelPosition="t" textColor="#000000" visible="true" width="142.39794921875" x="1.301025390625" y="3.0">DaSenseRegistration</y:NodeLabel>
<y:UML clipContent="true" constraint="" omitDetails="false" stereotype="" use3DEffect="true">
<y:AttributeLabel/>
<y:MethodLabel/>
</y:UML>
</y:UMLClassNode>
</data>
</node>
<node id="n5">
<data key="d4"/>
<data key="d5"><![CDATA[UMLClass]]></data>
<data key="d6">
<y:UMLClassNode>
<y:Geometry height="28.0" width="187.0" x="383.0" y="269.0"/>
<y:Fill color="#C5D683" color2="#C5D683" transparent="false"/>
<y:BorderStyle color="#C5D683" type="line" width="1.0"/>
<y:NodeLabel alignment="center" autoSizePolicy="content" fontFamily="Dialog" fontSize="13" fontStyle="bold" hasBackgroundColor="false" hasLineColor="false" height="19.310546875" modelName="internal" modelPosition="t" textColor="#000000" visible="true" width="179.82373046875" x="3.588134765625" y="3.0">DaSenseRegistrationStudy</y:NodeLabel>
<y:UML clipContent="true" constraint="" omitDetails="false" stereotype="" use3DEffect="true">
<y:AttributeLabel/>
<y:MethodLabel/>
</y:UML>
</y:UMLClassNode>
</data>
</node>
<edge id="e0" source="n0" target="n2">
<data key="d8"/>
<data key="d9"><![CDATA[UMLuses]]></data>
<data key="d10">
<y:PolyLineEdge>
<y:Path sx="0.0" sy="0.0" tx="0.0" ty="0.0"/>
<y:LineStyle color="#000000" type="dashed" width="1.0"/>
<y:Arrows source="none" target="short"/>
<y:EdgeLabel alignment="center" distance="2.0" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" hasText="false" height="4.0" modelName="six_pos" modelPosition="tail" preferredPlacement="anywhere" ratio="0.5" textColor="#000000" visible="true" width="4.0" x="-55.56242460363052" y="21.525813297399864"/>
<y:EdgeLabel alignment="center" distance="2.0" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" height="18.1328125" modelName="six_pos" modelPosition="shead" preferredPlacement="anywhere" ratio="0.5" textColor="#000000" visible="true" width="86.517578125" x="-162.23872285730698" y="7.7743598090277715">call = account</y:EdgeLabel>
<y:BendStyle smoothed="false"/>
</y:PolyLineEdge>
</data>
</edge>
<edge id="e1" source="n0" target="n1">
<data key="d8"/>
<data key="d9"><![CDATA[UMLuses]]></data>
<data key="d10">
<y:PolyLineEdge>
<y:Path sx="0.0" sy="0.0" tx="0.0" ty="0.0"/>
<y:LineStyle color="#000000" type="dashed" width="1.0"/>
<y:Arrows source="none" target="short"/>
<y:EdgeLabel alignment="center" distance="2.0" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" hasText="false" height="4.0" modelName="six_pos" modelPosition="tail" preferredPlacement="anywhere" ratio="0.5" textColor="#000000" visible="true" width="4.0" x="55.097297219669144" y="20.101874824042795"/>
<y:EdgeLabel alignment="center" distance="2.0" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" height="18.1328125" modelName="six_pos" modelPosition="stail" preferredPlacement="anywhere" ratio="0.5" textColor="#000000" visible="true" width="407.40625" x="77.87096449908086" y="5.10694239161036">default: ArgumentController handles all HTTP-GET/POST-Parameters</y:EdgeLabel>
<y:BendStyle smoothed="false"/>
</y:PolyLineEdge>
</data>
</edge>
<edge id="e2" source="n2" target="n3">
<data key="d8"/>
<data key="d9"><![CDATA[UMLuses]]></data>
<data key="d10">
<y:PolyLineEdge>
<y:Path sx="0.0" sy="0.0" tx="0.0" ty="0.0"/>
<y:LineStyle color="#000000" type="dashed" width="1.0"/>
<y:Arrows source="none" target="short"/>
<y:EdgeLabel alignment="center" distance="2.0" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" hasText="false" height="4.0" modelName="six_pos" modelPosition="tail" preferredPlacement="anywhere" ratio="0.5" textColor="#000000" visible="true" width="4.0" x="-33.3337906376008" y="61.536376953125"/>
<y:EdgeLabel alignment="center" distance="2.0" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" height="18.1328125" modelName="six_pos" modelPosition="head" preferredPlacement="anywhere" ratio="0.5" textColor="#000000" visible="true" width="136.984375" x="-180.67242471018145" y="54.469970703125">flag = login / available</y:EdgeLabel>
<y:BendStyle smoothed="false"/>
</y:PolyLineEdge>
</data>
</edge>
<edge id="e3" source="n2" target="n4">
<data key="d8"/>
<data key="d9"><![CDATA[UMLuses]]></data>
<data key="d10">
<y:PolyLineEdge>
<y:Path sx="0.0" sy="0.0" tx="0.0" ty="0.0"/>
<y:LineStyle color="#000000" type="dashed" width="1.0"/>
<y:Arrows source="none" target="short"/>
<y:EdgeLabel alignment="center" distance="2.0" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" hasText="false" height="4.0" modelName="six_pos" modelPosition="tail" preferredPlacement="anywhere" ratio="0.5" textColor="#000000" visible="true" width="4.0" x="32.019888797883084" y="61.536376953125"/>
<y:EdgeLabel alignment="center" distance="2.0" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" height="18.1328125" modelName="six_pos" modelPosition="ttail" preferredPlacement="anywhere" ratio="0.5" textColor="#000000" visible="true" width="110.587890625" x="55.55295331401214" y="98.778564453125">flag = registration</y:EdgeLabel>
<y:BendStyle smoothed="false"/>
</y:PolyLineEdge>
</data>
</edge>
<edge id="e4" source="n2" target="n5">
<data key="d8"/>
<data key="d9"><![CDATA[UMLuses]]></data>
<data key="d10">
<y:PolyLineEdge>
<y:Path sx="0.0" sy="0.0" tx="0.0" ty="0.0"/>
<y:LineStyle color="#000000" type="dashed" width="1.0"/>
<y:Arrows source="none" target="short"/>
<y:EdgeLabel alignment="center" distance="2.0" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" hasText="false" height="4.0" modelName="six_pos" modelPosition="tail" preferredPlacement="anywhere" ratio="0.5" textColor="#000000" visible="true" width="4.0" x="107.4139404296875" y="66.67850474382607"/>
<y:EdgeLabel alignment="center" distance="2.0" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" height="18.1328125" modelName="six_pos" modelPosition="tail" preferredPlacement="anywhere" ratio="0.5" textColor="#000000" visible="true" width="148.462890625" x="127.03155635710687" y="54.4510498046875">flag = registration_study</y:EdgeLabel>
<y:BendStyle smoothed="false"/>
</y:PolyLineEdge>
</data>
</edge>
</graph>
<data key="d0">
<y:Resources/>
</data>
</graphml>

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

View File

@ -0,0 +1,166 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<graphml xmlns="http://graphml.graphdrawing.org/xmlns" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:y="http://www.yworks.com/xml/graphml" xmlns:yed="http://www.yworks.com/xml/yed/3" xsi:schemaLocation="http://graphml.graphdrawing.org/xmlns http://www.yworks.com/xml/schema/graphml/1.1/ygraphml.xsd">
<!--Created by yFiles for Java 2.8-->
<key for="graphml" id="d0" yfiles.type="resources"/>
<key for="port" id="d1" yfiles.type="portgraphics"/>
<key for="port" id="d2" yfiles.type="portgeometry"/>
<key for="port" id="d3" yfiles.type="portuserdata"/>
<key attr.name="url" attr.type="string" for="node" id="d4"/>
<key attr.name="description" attr.type="string" for="node" id="d5"/>
<key for="node" id="d6" yfiles.type="nodegraphics"/>
<key attr.name="Beschreibung" attr.type="string" for="graph" id="d7"/>
<key attr.name="url" attr.type="string" for="edge" id="d8"/>
<key attr.name="description" attr.type="string" for="edge" id="d9"/>
<key for="edge" id="d10" yfiles.type="edgegraphics"/>
<graph edgedefault="directed" id="G">
<data key="d7"/>
<node id="n0">
<data key="d4"/>
<data key="d5"><![CDATA[UMLClass]]></data>
<data key="d6">
<y:UMLClassNode>
<y:Geometry height="28.0" width="133.0" x="230.0" y="69.0"/>
<y:Fill color="#C5D683" color2="#C5D683" transparent="false"/>
<y:BorderStyle color="#C5D683" type="line" width="1.0"/>
<y:NodeLabel alignment="center" autoSizePolicy="content" backgroundColor="#C5D683" fontFamily="Dialog" fontSize="13" fontStyle="bold" height="19.310546875" lineColor="#C5D683" modelName="internal" modelPosition="t" textColor="#000000" visible="true" width="40.6767578125" x="46.16162109375" y="3.0">index</y:NodeLabel>
<y:UML clipContent="true" constraint="" omitDetails="false" stereotype="" use3DEffect="true">
<y:AttributeLabel/>
<y:MethodLabel/>
</y:UML>
</y:UMLClassNode>
</data>
</node>
<node id="n1">
<data key="d4"/>
<data key="d5"><![CDATA[UMLClass]]></data>
<data key="d6">
<y:UMLClassNode>
<y:Geometry height="28.0" width="133.0" x="230.0" y="172.0"/>
<y:Fill color="#C5D683" color2="#C5D683" transparent="false"/>
<y:BorderStyle color="#C5D683" type="line" width="1.0"/>
<y:NodeLabel alignment="center" autoSizePolicy="content" fontFamily="Dialog" fontSize="13" fontStyle="bold" hasBackgroundColor="false" hasLineColor="false" height="19.310546875" modelName="internal" modelPosition="t" textColor="#000000" visible="true" width="108.76806640625" x="12.115966796875" y="3.0">LoginController</y:NodeLabel>
<y:UML clipContent="true" constraint="" omitDetails="false" stereotype="" use3DEffect="true">
<y:AttributeLabel/>
<y:MethodLabel/>
</y:UML>
</y:UMLClassNode>
</data>
</node>
<node id="n2">
<data key="d4"/>
<data key="d5"><![CDATA[UMLClass]]></data>
<data key="d6">
<y:UMLClassNode>
<y:Geometry height="28.0" width="133.0" x="43.0" y="172.0"/>
<y:Fill color="#C5D683" color2="#C5D683" transparent="false"/>
<y:BorderStyle color="#C5D683" type="line" width="1.0"/>
<y:NodeLabel alignment="center" autoSizePolicy="content" fontFamily="Dialog" fontSize="13" fontStyle="bold" hasBackgroundColor="false" hasLineColor="false" height="19.310546875" modelName="internal" modelPosition="t" textColor="#000000" visible="true" width="71.564453125" x="30.7177734375" y="3.0">Controller</y:NodeLabel>
<y:UML clipContent="true" constraint="" omitDetails="false" stereotype="" use3DEffect="true">
<y:AttributeLabel/>
<y:MethodLabel/>
</y:UML>
</y:UMLClassNode>
</data>
</node>
<node id="n3">
<data key="d4"/>
<data key="d5"><![CDATA[UMLClass]]></data>
<data key="d6">
<y:UMLClassNode>
<y:Geometry height="28.0" width="133.0" x="452.0" y="172.0"/>
<y:Fill color="#C5D683" color2="#C5D683" transparent="false"/>
<y:BorderStyle color="#C5D683" type="line" width="1.0"/>
<y:NodeLabel alignment="center" autoSizePolicy="content" fontFamily="Dialog" fontSize="13" fontStyle="bold" hasBackgroundColor="false" hasLineColor="false" height="19.310546875" modelName="internal" modelPosition="t" textColor="#000000" visible="true" width="113.83349609375" x="9.583251953125" y="3.0">LocaleController</y:NodeLabel>
<y:UML clipContent="true" constraint="" omitDetails="false" stereotype="" use3DEffect="true">
<y:AttributeLabel/>
<y:MethodLabel/>
</y:UML>
</y:UMLClassNode>
</data>
</node>
<node id="n4">
<data key="d4"/>
<data key="d5"><![CDATA[UMLClass]]></data>
<data key="d6">
<y:UMLClassNode>
<y:Geometry height="28.0" width="133.0" x="230.0" y="263.0"/>
<y:Fill color="#C5D683" color2="#C5D683" transparent="false"/>
<y:BorderStyle color="#C5D683" type="line" width="1.0"/>
<y:NodeLabel alignment="center" autoSizePolicy="content" fontFamily="Dialog" fontSize="13" fontStyle="bold" hasBackgroundColor="false" hasLineColor="false" height="19.310546875" modelName="internal" modelPosition="t" textColor="#000000" visible="true" width="107.0478515625" x="12.97607421875" y="3.0">FrontController</y:NodeLabel>
<y:UML clipContent="true" constraint="" omitDetails="false" stereotype="" use3DEffect="true">
<y:AttributeLabel/>
<y:MethodLabel/>
</y:UML>
</y:UMLClassNode>
</data>
</node>
<edge id="e0" source="n1" target="n2">
<data key="d8"/>
<data key="d9"><![CDATA[UMLimplements]]></data>
<data key="d10">
<y:PolyLineEdge>
<y:Path sx="0.0" sy="0.0" tx="0.0" ty="0.0"/>
<y:LineStyle color="#000000" type="dashed" width="1.0"/>
<y:Arrows source="none" target="white_delta"/>
<y:EdgeLabel alignment="center" distance="2.0" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" hasText="false" height="4.0" modelName="six_pos" modelPosition="tail" preferredPlacement="anywhere" ratio="0.5" textColor="#000000" visible="true" width="4.0" x="-28.981689453125" y="2.0"/>
<y:BendStyle smoothed="false"/>
</y:PolyLineEdge>
</data>
</edge>
<edge id="e1" source="n0" target="n1">
<data key="d8"/>
<data key="d9"><![CDATA[UMLuses]]></data>
<data key="d10">
<y:PolyLineEdge>
<y:Path sx="0.0" sy="0.0" tx="0.0" ty="0.0"/>
<y:LineStyle color="#000000" type="dashed" width="1.0"/>
<y:Arrows source="none" target="short"/>
<y:EdgeLabel alignment="center" distance="2.0" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" hasText="false" height="4.0" modelName="six_pos" modelPosition="tail" preferredPlacement="anywhere" ratio="0.5" textColor="#000000" visible="true" width="4.0" x="2.0" y="35.493408203125"/>
<y:BendStyle smoothed="false"/>
</y:PolyLineEdge>
</data>
</edge>
<edge id="e2" source="n1" target="n3">
<data key="d8"/>
<data key="d9"><![CDATA[UMLuses]]></data>
<data key="d10">
<y:PolyLineEdge>
<y:Path sx="0.0" sy="0.0" tx="0.0" ty="0.0"/>
<y:LineStyle color="#000000" type="dashed" width="1.0"/>
<y:Arrows source="none" target="short"/>
<y:EdgeLabel alignment="center" distance="2.0" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" hasText="false" height="4.0" modelName="six_pos" modelPosition="tail" preferredPlacement="anywhere" ratio="0.5" textColor="#000000" visible="true" width="4.0" x="42.524658203125" y="2.0"/>
<y:BendStyle smoothed="false"/>
</y:PolyLineEdge>
</data>
</edge>
<edge id="e3" source="n1" target="n4">
<data key="d8"/>
<data key="d9"><![CDATA[UMLuses]]></data>
<data key="d10">
<y:PolyLineEdge>
<y:Path sx="0.0" sy="0.0" tx="0.0" ty="0.0"/>
<y:LineStyle color="#000000" type="dashed" width="1.0"/>
<y:Arrows source="none" target="short"/>
<y:EdgeLabel alignment="center" distance="2.0" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" hasText="false" height="4.0" modelName="six_pos" modelPosition="tail" preferredPlacement="anywhere" ratio="0.5" textColor="#000000" visible="true" width="4.0" x="2.0" y="29.50341796875"/>
<y:BendStyle smoothed="false"/>
</y:PolyLineEdge>
</data>
</edge>
<edge id="e4" source="n4" target="n2">
<data key="d8"/>
<data key="d9"><![CDATA[UMLimplements]]></data>
<data key="d10">
<y:PolyLineEdge>
<y:Path sx="0.0" sy="0.0" tx="0.0" ty="0.0"/>
<y:LineStyle color="#000000" type="dashed" width="1.0"/>
<y:Arrows source="none" target="white_delta"/>
<y:EdgeLabel alignment="center" distance="2.0" fontFamily="Dialog" fontSize="12" fontStyle="plain" hasBackgroundColor="false" hasLineColor="false" hasText="false" height="4.0" modelName="six_pos" modelPosition="tail" preferredPlacement="anywhere" ratio="0.5" textColor="#000000" visible="true" width="4.0" x="-66.7149658203125" y="-28.519047538226943"/>
<y:BendStyle smoothed="false"/>
</y:PolyLineEdge>
</data>
</edge>
</graph>
<data key="d0">
<y:Resources/>
</data>
</graphml>

Binary file not shown.

After

Width:  |  Height:  |  Size: 10 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.4 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 108 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 683 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 748 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 42 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.1 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 59 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

Binary file not shown.

Binary file not shown.

After

Width:  |  Height:  |  Size: 24 KiB

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

View File

Before

Width:  |  Height:  |  Size: 190 KiB

After

Width:  |  Height:  |  Size: 190 KiB

View File

Before

Width:  |  Height:  |  Size: 244 KiB

After

Width:  |  Height:  |  Size: 244 KiB

View File

Before

Width:  |  Height:  |  Size: 249 KiB

After

Width:  |  Height:  |  Size: 249 KiB

View File

Before

Width:  |  Height:  |  Size: 204 KiB

After

Width:  |  Height:  |  Size: 204 KiB

View File

Before

Width:  |  Height:  |  Size: 201 KiB

After

Width:  |  Height:  |  Size: 201 KiB

View File

Before

Width:  |  Height:  |  Size: 223 KiB

After

Width:  |  Height:  |  Size: 223 KiB

View File

Before

Width:  |  Height:  |  Size: 173 KiB

After

Width:  |  Height:  |  Size: 173 KiB

View File

Before

Width:  |  Height:  |  Size: 171 KiB

After

Width:  |  Height:  |  Size: 171 KiB

View File

Before

Width:  |  Height:  |  Size: 180 KiB

After

Width:  |  Height:  |  Size: 180 KiB

View File

Before

Width:  |  Height:  |  Size: 199 KiB

After

Width:  |  Height:  |  Size: 199 KiB

View File

Before

Width:  |  Height:  |  Size: 182 KiB

After

Width:  |  Height:  |  Size: 182 KiB

View File

Before

Width:  |  Height:  |  Size: 165 KiB

After

Width:  |  Height:  |  Size: 165 KiB

View File

Before

Width:  |  Height:  |  Size: 168 KiB

After

Width:  |  Height:  |  Size: 168 KiB

View File

Before

Width:  |  Height:  |  Size: 194 KiB

After

Width:  |  Height:  |  Size: 194 KiB

View File

Before

Width:  |  Height:  |  Size: 183 KiB

After

Width:  |  Height:  |  Size: 183 KiB

View File

Before

Width:  |  Height:  |  Size: 183 KiB

After

Width:  |  Height:  |  Size: 183 KiB

View File

Before

Width:  |  Height:  |  Size: 179 KiB

After

Width:  |  Height:  |  Size: 179 KiB

Some files were not shown because too many files have changed in this diff Show More