QS-Doc
This commit is contained in:
M.Scholz
parent
6ef173a253
commit
fb5de5fdf6
Binary file not shown.
@ -61,7 +61,7 @@ Gruppe 1b}
|
||||
\subsubtitle{Auftraggeber: Immanuel Schweizer (Telecooperation Group TU Darmstadt) \\
|
||||
Gruppe 1b: Murat Batu, Ulf Gebhardt, Lulzim Murati, Michael Scholz\\
|
||||
Teamleiter: Dominik Fischer\\
|
||||
Version: 0.9.0 vom 24.01.2012}
|
||||
Version: 1.0.3 vom 29.03.2012}
|
||||
|
||||
\author{Murat Batu, Ulf Gebhardt, Lulzim Murati, Michael Scholz}
|
||||
\maketitle
|
||||
@ -239,7 +239,7 @@ Die aufgef
|
||||
|
||||
\subsection{Benutzerstudie}
|
||||
\label{Anhang:Benutzerstudie}
|
||||
Die Benutzerstudie wurde von uns nicht wie geplant durchgeführt, da die Erstellung einer neuen Visualisierung nach Rücksprache mit unserem Auftraggeber ausgelassen wurde. Die Gründe hierfür waren unter anderem die sich ändernden Anforderungen im agilen Softwareprozess. So mussten wir die uns gegebene Datenbank massiv überarbeiten. Es fehlten sämtliche Fremdschlüssel, welche vom verwendeten \gls{ORM} \gls{Propel} zum Joinen der einzelnen Tabellen benötigt werden. Zudem wurden bei der Erstellung der neuen Datenbank notwendige Tabellenspalten nicht hinzugefügt. Ein weiterer Grund weshalb die neue Visualisierung ausgelassen wurde waren die unvorhersehbaren Probleme bei der Nutzung von \gls{Propel}. So eignet es sich vor allem für statische Datenbankabfragen, nicht aber für dynamische Abfragen, welche bei der Erstellung der neuen \gls{API} notwendig waren. Die gegebene Dokumentation von \gls{Propel} ist sehr kurz gefasst und behandelt meist nur einfache SQL-Abfragen. Somit standen wir im ständigen Kontakt mit dem Entwicklern, welche glücklicherweise einen gut betreuten Support-Chat anbieten.
|
||||
Die Benutzerstudie wurde von uns nicht wie geplant durchgeführt, da die Erstellung einer neuen Visualisierung nach Rücksprache mit unserem Auftraggeber ausgelassen wurde. Somit sind die folgenden beiden Abschnitte (4.1.1 und 4.1.2) nicht mehr relevant. Die Gründe hierfür waren unter anderem die sich ändernden Anforderungen im agilen Softwareprozess. So mussten wir die uns gegebene Datenbank massiv überarbeiten. Es fehlten sämtliche Fremdschlüssel, welche vom verwendeten \gls{ORM} \gls{Propel} zum Joinen der einzelnen Tabellen benötigt werden. Zudem wurden bei der Erstellung der neuen Datenbank notwendige Tabellenspalten nicht hinzugefügt. Ein weiterer Grund weshalb die neue Visualisierung ausgelassen wurde waren die unvorhersehbaren Probleme bei der Nutzung von \gls{Propel}. So eignet es sich vor allem für statische Datenbankabfragen, nicht aber für Dynamische, welche bei der Erstellung der neuen \gls{API} notwendig waren. Die gegebene Dokumentation von \gls{Propel} ist sehr kurz gefasst und beschreibt meist nur einfache SQL-Abfragen. Aus diesem Grund standen wir im ständigen Kontakt mit dem Entwicklern, welche glücklicherweise einen gut betreuten Support-Chat anbieten. Die einzelnen Tabellennamen der Datenbank enthielten zu Beginn Unterstriche. \gls{Propel} kann mit dieser festgelegten Namenskonvention jedoch nicht umgehen, weshalb alle Tabellennamen neu vergeben werden mussten. Hierbei haben wir uns an die aus Java bekannte CamelCase Konvention gehalten.
|
||||
|
||||
|
||||
|
||||
@ -318,12 +318,119 @@ Die Benutzerstudie wurde von uns nicht wie geplant durchgef
|
||||
|
||||
|
||||
\subsection{Funktionalität}
|
||||
In Übereinkunft mit unserem Auftraggeber haben wir uns dazu entschlossen den Testablauf für die beiden folgenden Use-Cases hier genauer zu beschreiben:
|
||||
\begin{itemize}
|
||||
\item Parsen der JSON-Pakete
|
||||
\item Abfrage der \gls{API}
|
||||
\end{itemize}
|
||||
Die korrekte Funktionsweise dieser beiden Use-Cases hat die höchste Priorität, da sie zusammen die Schnittstelle zu der Smartphone-App, der Basisstation der Waspmote-Sensoren und der Website darstellen.
|
||||
\subsubsection{Use-Case: Parsen der JSON-Pakete}
|
||||
Ideen für diesen Absatz (bitte vervollständigen!!): JSON-Konvention der zwei verschiedenen Pakete auflisten, dann PHPUnit-Tests der einzelnen Exceptions des JSON-Parsers. Beispielpakete parsen, erhaltene und erwartete Antwort vergleichen.! \\
|
||||
Der JSON Parser wird durch die \gls{API} aufgerufen. Er kann zwei festgelegte Formate verarbeiten, welche durch gesetzte Flags unterschieden werden. Die Daten werden mittels GET oder POST übertragen.\\
|
||||
Vorbedingung: Datenbank mit korrektem Schema existiert. \\
|
||||
Nachbedingung: Daten sind korrekt in die Datenbank eingetragen. \\
|
||||
Fehlerbehandlung:
|
||||
\begin{itemize}
|
||||
\item Fehlende Eingabedaten führen zu einer MissingParamterException.
|
||||
\item Eingabedaten, welche nicht dem JSON Format entsprechen, führen zu einer JSONException.
|
||||
\item Eingabedaten, welche nicht dem festgelegten Format entsprechen, führen zu einer DataFormatException.
|
||||
\end{itemize}
|
||||
\textbf{Format zum Ändern der Sensorinformationen:}\\
|
||||
Dieses Format wird beim Start, Login oder der Änderung von Optionen von den einzelnen Sensoren gesendet. \\
|
||||
HTTP-Post-Parameter: flag=deviceinfo\&json=JSON-Daten \\
|
||||
Beispiel: http://www.da-sense.de/api.php?flag=deviceinfo\&json=\{.....\} \\
|
||||
Das vereinbarte JSON Format sieht wie folgt aus:
|
||||
\begin{tabbing}
|
||||
\{\= ''deviceType'': INT,\\
|
||||
\> ''deviceID'': INT,\\
|
||||
\> ''deviceManufactor'': STRING,\\
|
||||
\> ''deviceModel'': STRING,\\
|
||||
\> ''deviceName'': STRING, \\
|
||||
\> ''sensors'': [\{ \= \\
|
||||
\> \> ''type'': INT,\\
|
||||
\> \> ''sensorAttributes'': [\{ \= \\
|
||||
\> \> \> ''key'': STRING,\\
|
||||
\> \> \> ''value'': STRING \\
|
||||
\> \> \> \}] \\
|
||||
\> \> \}]\\
|
||||
\}\\
|
||||
\end{tabbing}
|
||||
\textbf{Format zum Senden der Daten:}\\
|
||||
Durch dieses Format werden die gemessenen Daten der Sensoren übermittelt. \\
|
||||
HTTP-Post-Parameter: flag=input\&source=smartphone bzw. waspmote\&json=JSON-Daten \\
|
||||
Beispiel: http://www.da-sense.de/api.php?flag=input\&source=smartphone\&json=\{.....\} \\
|
||||
Das vereinbarte JSON Format sieht wie folgt aus:
|
||||
\begin{tabbing}
|
||||
\{\= ''device'': STRING, \\
|
||||
\> ''measurementType'': INT, \\
|
||||
\> ''user'': INT, \\
|
||||
\> ''series'': [\{ \= \\
|
||||
\> \> ''name'': STRING, \\
|
||||
\> \> ''visibility'':INT, \\
|
||||
\> \> ''timestamp'':LONG, \\
|
||||
\> \> ''values'': [\{ \= \\
|
||||
\> \> \> ''timestamp'': LONG, \\
|
||||
\> \> \> ''value'': FLOAT, \\
|
||||
\> \> \> ''latitude'': FLOAT, \\
|
||||
\> \> \> ''longitude'': FLOAT, \\
|
||||
\> \> \> ''altitude'': FLOAT, \\
|
||||
\> \> \> ''accuracy'': FLOAT, \\
|
||||
\> \> \> ''speed'': FLOAT bzw. NULL, \\
|
||||
\> \> \> ''provider'': STRING, \\
|
||||
\> \> \> ''tags'': [\{ \= \\
|
||||
\> \> \> \> ''key'': STRING, \\
|
||||
\> \> \> \> ''value'': STRING,\\
|
||||
\> \> \> \>\}]\\
|
||||
\> \> \>\}]\\
|
||||
\> \>\}]\\
|
||||
\}
|
||||
\end{tabbing}
|
||||
Im Folgenden sind verschiedene Testszenarien aufgelistet. Sie beinhalten eine kurze Beschreibung des einzelnen Szenarios, die eingegebenen Testdaten, sowie die erwartete und tatsächliche Ausgabe. Zudem sind die einzelnen Tests mit Datum versehen. Bei fehlgeschlagenem Test wird der Fehlergrund aufgeführt.
|
||||
|
||||
\subsubsection*{Szenario: Fehlender Parameter}
|
||||
\begin{tabular}{l l}
|
||||
Beschreibung: & bla \\
|
||||
eingegebene Testdaten: & nochMehrBla \\
|
||||
erwartete Ausgabe: & undNochMehrBla \\
|
||||
tatsächliche Ausgabe: & nochmalsMehrBla \\
|
||||
\end{tabular}
|
||||
|
||||
\subsubsection*{Szenario: Verletzung der JSON Spezifikation}
|
||||
\begin{tabular}{l l}
|
||||
Beschreibung: & bla \\
|
||||
eingegebene Testdaten: & nochMehrBla \\
|
||||
erwartete Ausgabe: & undNochMehrBla \\
|
||||
tatsächliche Ausgabe: & nochmalsMehrBla \\
|
||||
\end{tabular}
|
||||
|
||||
\subsubsection*{Szenario: Verletzung des vereinbarten Formats}
|
||||
\begin{tabular}{l l}
|
||||
Beschreibung: & bla \\
|
||||
eingegebene Testdaten: & nochMehrBla \\
|
||||
erwartete Ausgabe: & undNochMehrBla \\
|
||||
tatsächliche Ausgabe: & nochmalsMehrBla \\
|
||||
\end{tabular}\\
|
||||
|
||||
\subsubsection*{Szenario: Eingabe eines korrekten Datensatzes}
|
||||
\begin{tabular}{l l}
|
||||
Beschreibung: & bla \\
|
||||
eingegebene Testdaten: & nochMehrBla \\
|
||||
erwartete Ausgabe: & undNochMehrBla \\
|
||||
tatsächliche Ausgabe: & nochmalsMehrBla \\
|
||||
\end{tabular}
|
||||
|
||||
\subsubsection*{Szenario: Eingabe mehrerer Datensätze}
|
||||
|
||||
|
||||
|
||||
|
||||
\subsubsection{Use-Case: Abfrage der \gls{API}}
|
||||
Ideen für diesen Absatz (bitte vervollständigen!!): verschiedene Abfragen der API. Vor allem die, die für die Website gebraucht werden. Die Website-Abfragen mit Selenium testen. Mit Screenshots und Ergebnissen von Selenium belegen. Interoperabilität der einzelnen Browser mit manuellen Tests belegen. Hierbei kann man kurz auf das AJAX-Problem eingehen, welches beim Login aufgetaucht ist (Safari Login hat nicht funktioniert, weil der standardmäßig die Optin async : true hat).
|
||||
|
||||
|
||||
|
||||
\subsection{Erweiterbarkeit}
|
||||
|
||||
Ideen für diesen Absatz (bitte vervollständigen!!): Termine der einzelnen Code-Reviews auflisten. Eventuell eine Tabelle zu dokumentation von aufgetauchten Problemen erstellen. Diese könnte z.B. Thema, Zusammenhänge, Datename, Zeilennummer, Problem etc. enthalten. Dann einzelne Erkentnisse der Reviews aufführen. Wie ist der aktuelle Stand? Wo sind Probleme? Wie liegen wir im Zeitplan? ...\\
|
||||
|
||||
|
||||
|
||||
@ -348,6 +455,12 @@ F
|
||||
\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} v. 0.9.3 - 18.02.2012 - MS & Anhang: Use-Case: 4.2.1 Use-Case: Parsen der JSON-Pakete erstellt\\
|
||||
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.9.5 - 27.02.2012 - LM, UG, MB, MS & Anhang: 4.2.2 Use-Case: Abfrage der API erstellt\\
|
||||
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.9.8 - 05.03.2012 - LM, UG, MB, MS & Anhang: 4.3 Erweiterbarkeit erstellt und kleine Korrekturen des restlichen Anhangs\\
|
||||
\hline \rule[-2ex]{0pt}{5.5ex} v. 0.9.9 - 05.03.2012 - MS & Anhang: Text weshalb die Benutzerstudie nicht durchgeführt werden kann erstellt\\
|
||||
\hline \rule[-2ex]{0pt}{5.5ex} v. 1.0.1 - 15.03.2012 - LM, UG, MB, MS & Kleinere Korrekturen (Rechtschreibung und Kommasetzung)\\
|
||||
\hline \rule[-2ex]{0pt}{5.5ex} v. 1.0.3 - 29.03.2012 - LM, UG, MB, MS & Finale Korrekturen (Rechtschreibung und Kommasetzung). Abgabeversion erstellt\\
|
||||
%\hline \rule[-2ex]{0pt}{5.5ex} ... - .... & ... \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user