\section{Situationsanalyse} \subsection{Vision} Wir möchten eine Plattform für Markthändler schaffen welche es ihnen ermöglicht geeignete Standflächen an attraktiven Standorten zu mieten. Zusätzlich sollen sie auf einer Plattform die Möglichkeit haben sich zu präsentieren. Diese Plattform soll interessierten Kunden einen Überblick über die verschieden Anbieter geben und somit Neugierde wecken. Dies alles soll mit möglichst wenig Aufwand verwaltet werden können. \subsection{Stakeholder} Folgende Stakeholder sind in diesem Projekt zu berücksichtigen: \begin{itemize} \item Plattforminhaber \item Standbetreiber \item Marktbesucher \end{itemize} Abbildung: (\ref{fig:stakeholder}) zeigt die Beziehung der Stakeholder zum Projekt noch grafisch auf. \begin{figure} \centering \includegraphics[width=0.9\textwidth]{diagrammes/stakeholder.png} \caption{Stakeholder Diagramm\label{fig:stakeholder}} \end{figure} \subsection{Chancen und Risiken} \subsubsection{Chancen} \begin{itemize} \item Zusammenhänge zwischen Programmierung und Datenbank Modellierung besser verstehen. \item Erfahrungen im Projekt-Management vertiefen \item Umgang mit den Werkzeugen üben und verbessern \end{itemize} \subsubsection{Risiken} Ein grosses Risiko ist das wir uns beim Erarbeiten der Datenbank sowie beim schreiben der Applikation in Details verlieren die nicht gefordert werden. Sowie unter Umständen Dinge einbauen welche wir nicht genügend kennen. Dies könnte uns zu einem späteren Zeitpunkt zum Verhängnis werden. \newpage \section{Zielsetzung} \subsection{Mussziele} \begin{itemize} \item Das Geschäftsmodell wurde in ein ERM umgewandelt. \item Das ERM wurde in eine SQL-Server Datenbank umgesetzt. \item Die Arbeit wurde mittels eines Testplans überprüft. \item Die zur Verfügung stehenden Stunden sind in einer Planung den Aufgaben zugeordnet. Abweichungen wurden mittels einer Abweichungsanalyse aufgezeichnet. \item Die Lösung wurde dokumentiert. \item Eine Teilfunktion des Geschäftsmodell wurde in einer C\# Applikation abgebildet. \end{itemize} \subsection{Wunschziele} \begin{itemize} \item Die Datenbank enthält alle statische Daten Wie etwa Länder, Städte, Postleitzahlen, Standorte. \item Die Datenbank enthält ein Rechtekonzept. \end{itemize} \newpage \section{User Stories} User Stories sind sind eine in Alltagsprache geschriebenen Software-Anforderungen. Sie sind bewusst kurz gehalten und beschreiben die Wünsche und Ziele der Rollen welche die Software verwenden. \subsection{Verwaltung} Als Plattforminhaber möchte ich, \begin{itemize} \item Kontrolle über die Anmeldungen haben. \item Standbetreiber verwalten können (Standort und Termine). \item Qualitätschecks bei den Mitgliedern machen können. \item Inspektoren bezahlen können. \item die Rechnungen an die Mitglieder verwalten können. \item die Kontrolle über die Anzahl der Auftrittsanpassungen haben. \item Abonnemente verwalten können. \item sichergestellt haben das provisorische Mitglieder sich nur an einem Standort einen Platz reservieren können. \end{itemize} \subsection{Anbieter (provisorisches Mitglied)} Als provisorisches Mitglied möchte ich, \begin{itemize} \item mich registrieren können. \item eine Standfläche mieten können. \item einsehen können wie lange die Probezeit noch dauert. \end{itemize} \subsection{Anbieter (festes Mitglied)} Als festes Mitglied möchte ich, \begin{itemize} \item ein Abonnement lösen können. \item Standorte buchen können. \item meinen Auftritt anpassen können. \end{itemize} \subsection{Nachfrager/ Marktbesucher} Als Marktbesucher möchte ich, \begin{itemize} \item mich registrieren können. \item einen Überblick über die Anbieterprofile haben. \item einen Überblick der Standorte und Termine der Märkte haben. \end{itemize} \newpage \section{Use Cases} Ein Use Case sammelt alle möglichen Szenarien, die eintreten können, wenn ein Akteur versucht, mit Hilfe des betrachteten Systems ein bestimmtes Ziel zu erreichen. Dabei beschreibt er was beim Versuch der Zielerreichung passieren kann. Je nach Ablauf kann auch ein Fehlschlag ein Ergebnis eines Anwendungsfalls sein (e.g. falsches Passwort beim Login). Dabei wird die technische Lösung nicht konkret beschrieben. Die Detailstufe kann dabei sehr unterschiedlich sein. \subsection{Use Case Diagramm} ``Ein Anwendungsfalldiagramm ... ist eine der 14 Diagrammarten der Unified Modeling Language (UML), einer Sprache für die Modellierung der Strukturen und des Verhaltens von Software- und anderen Systemen. Es stellt Anwendungsfälle und Akteure mit ihren jeweiligen Abhängigkeiten und Beziehungen dar.''\cite{dbcs7} Wir verschaften uns dabei mit einem Use Case Diagramm, zu sehen in Abbildung: (\ref{fig:use_case}), zuerst einen groben Überblick über die Use Cases und wie sie zusammenhängen. \subsection{Use Cases Detailbeschreibungen} Für die Ausarbeitung der C\# Applikation haben wir uns für 5 Use Cases entschieden und diese in einer Use Case Schablone von Alistair Cockburn im Detail ausgearbeitet und beschrieben haben. Die Alistair Cockburn Schablone gibt eine gute Vorgabe für den Inhalt der Use Case Beschreibung. \subsubsection{Lösungsvarianten} Wir wollen hier auch noch darauf eingehen welche Varianten wir uns überlegt haben und wieso wir uns am Ende für die nachfolgenden 5 Use Cases entschieden haben. Dabei war es uns besonders wichtig das bei den Use Cases, Daten aus der Datenbank ausgelesen sowie auch geschreiben werden müssen. Wir haben uns dabei zu Beginn die folgenden drei möglichen Szenarien überlegt: \begin{itemize} \item Login und Registrierung einer Person. \item Lösen eines Abonnements. \item Mieten eines Standorts. \end{itemize} \paragraph{Login und Registrierung einer Person.} Bei dieser Lösungsvariante würde der komplette Registrierungsprozess abgebildet werden. Dabei würden auch die Adressdaten etc. der Person erfasst werden. \paragraph{Lösen eines Abonnements.} Das Lösen eines Abonnements würde behinhalten das eine bestehende Person eines der verschiedenen Abonnemente anschauen, auswählen und anschliessend ``kaufen'' könnte. \paragraph{Mieten eines Standorts.} Beim Mieten eines Standortes könnte ein Mitglied die Marktstandorte einsehen, auswählen und sich dort einen Spot reservieren. \paragraph{Gewählte Variante} Schlussendlich haben wir uns dafür entschieden einen Login und die Registrierung umzusetzen. Allerdings haben wir beschlossen das wir uns darauf beschränken ein Mitglied nur mit einer Email Adresse und einem Passwort zu erfassen. Zusätzlich schien uns das Mieten eines Standorts noch eine gute Funktion um eine Teilfunktion der Applikation abzubilden. \begin{landscape} \begin{figure} \centering \includegraphics[height=0.9\textheight]{diagrammes/use_cases.png} \caption{Use Case Diagramm\label{fig:use_case}} \end{figure} \end{landscape} %% -- Begining of Use Case Template -- \subsubsection{User Registrierung} {\footnotesize\begin{longtable}{|>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}|} \hline %begin title row {\cellcolor[HTML]{C0C0C0} Identifier} + Name & {\cellcolor[HTML]{C0C0C0} 1.0 User Registrierung} \\ \hline %end title row Description & Registrierung eines neuen User Accounts.\\ \hline Actors & User\\ \hline Status & Freigegeben\\ \hline Includes & -\\ \hline Trigger & User möchte sich registrieren.\\ \hline Preconditions & Email Adresse vorhanden.\\ \hline Postconditions & User hat sich einen Account erstellt.\\ \hline Normal Flow & 1. User startet Registrierung\\ & 2. User füllt Form aus\\ & 3. User schliesst Registrierung ab\\ \hline Alternative Flow & 1. User startet Registrierung\\ & 2. User füllt Form mit bereits vorhandener Email Adresse aus.\\ & 3. Applikation gibt Fehler aus\\ & 4. User verwendet einzigartige Email Adresse\\ & 5. User schliesst Registrierung ab\\ \hline Notes & -\\ \hline UC History & 1.0 Draft erstellt durch AZ\\ & 1.1 kleinere Anpassungen durch AZ\\ \hline Author & A. Zweili \& I. Cadaroski\\ \hline Date & 24. August 2017\\ \hline \caption{Use 1.0 User Registrierung} \end{longtable}} \newpage %% -- End of Use Case Template -- %% -- Begining of Use Case Template -- \subsubsection{User Login} {\footnotesize\begin{longtable}{|>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}|} \hline %begin title row {\cellcolor[HTML]{C0C0C0} Identifier} + Name & {\cellcolor[HTML]{C0C0C0} 1.1 User Login} \\ \hline %end title row Description & Login eines Users am System.\\ \hline Actors & User\\ \hline Status & Freigegeben\\ \hline Includes & -\\ \hline Trigger & User möchte sich einloggen\\ \hline Preconditions & UC 1.0 erfolgreich abgeschlossen\\ \hline Postconditions & User befindet sich im geschützten Bereich.\\ \hline Normal Flow & 1. User füllt Login Form korrekt aus\\ & 2. User quittiert Login\\ & 3. Applikation wechselt zum geschützten Bereich\\ \hline Alternative Flow & 1. User füllt Login Form mit falschen Angaben aus.\\ & 2. Applikation gibt einen Error aus\\ \hline Notes & -\\ \hline UC History & 1.0 Draft erstellt durch AZ\\ & 1.1 kleinere Anpassungen durch AZ\\ \hline Author & A. Zweili \& I. Cadaroski\\ \hline Date & 24. August 2017\\ \hline \caption{Use Case 1.1 User Login} \end{longtable}} \newpage %% -- End of Use Case Template -- %% -- Begining of Use Case Template -- \subsubsection{Standorte auflisten/suchen} {\footnotesize\begin{longtable}{|>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}|} \hline %begin title row {\cellcolor[HTML]{C0C0C0} Identifier} + Name & {\cellcolor[HTML]{C0C0C0} 2.0 Standorte auflisten/suchen} \\ \hline %end title row Description & Auflisten/suchen der Standorte in der Applikation.\\ \hline Actors & User\\ \hline Status & Freigegeben\\ \hline Includes & -\\ \hline Trigger & User möchte Standorte suchen/auflisten.\\ \hline Preconditions & UC 1.1 erfolgreich abgeschlossen\\ \hline Postconditions & -\\ \hline Normal Flow & 1. User gibt einen Suchbegriff ein.\\ & 2. Die Applikation gibt die passenden Resultate aus.\\ \hline Alternative Flow & -\\ \hline Notes & -\\ \hline UC History & 1.0 Draft erstellt durch AZ\\ & 1.1 kleinere Anpassungen durch AZ\\ \hline Author & A. Zweili \& I. Cadaroski\\ \hline Date & 24. August 2017\\ \hline \caption{Use Case 2.0 Standorte auflisten/suchen} \end{longtable}} \newpage %% -- End of Use Case Template -- %% -- Begining of Use Case Template -- \subsubsection{Standorte mieten} {\footnotesize\begin{longtable}{|>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}|} \hline %begin title row {\cellcolor[HTML]{C0C0C0} Identifier} + Name & {\cellcolor[HTML]{C0C0C0} 2.1 Standorte mieten} \\ \hline %end title row Description & Mieten eines Standortes als Test Member.\\ \hline Actors & User mit ``test\_member'' Status\\ \hline Status & Freigegeben\\ \hline Includes & -\\ \hline Trigger & \\ \hline Preconditions & UC 1.1 und 2.0 erfolgreich abgeschlossen\\ \hline Postconditions & Miete wurde erfolgreich in DB eingetragen.\\ \hline Normal Flow & 1. User wählt einen Standort aus\\ & 2. User wählt das Datum aus an dem er den Standort gerne mieten möchte.\\ & 3. User bestätigt die Miete mit einem Klick auf den Insert Button.\\ \hline Alternative Flow & \textbf{Der Alternative Flow wurde in der Applikation nicht umgesetzt.}\\ & 1. User wählt einen Standort aus\\ & 2. User wählt das Datum an dem er den Standort gerne mieten möchte.\\ & 3. User bestätigt die Miete mit klick auf den Insert Button.\\ & 4. Die Applikation meldet zurück das der Standort an diesem Datum\\ & bereits besetzt ist.\\ \hline Notes & -\\ \hline UC History & 1.0 Draft erstellt durch AZ\\ & 1.1 kleinere Anpassungen durch AZ\\ \hline Author & A. Zweili \& I. Cadaroski\\ \hline Date & 24. August 2017\\ \hline \caption{Use Case 2.1 Standorte Mieten} \end{longtable}} \newpage %% -- End of Use Case Template -- %% -- Begining of Use Case Template -- \subsubsection{Mieten anzeigen} {\footnotesize\begin{longtable}{|>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}|} \hline %begin title row {\cellcolor[HTML]{C0C0C0} Identifier} + Name & {\cellcolor[HTML]{C0C0C0} 2.2 Mieten anzeigen} \\ \hline %end title row Description & Betrachten der getätigten Mieten des aktuellen Users.\\ \hline Actors & User mit ``test\_member'' Status\\ \hline Status & Freigegeben\\ \hline Includes & -\\ \hline Trigger & User möchte sich seine Mieten anzeigen lassen\\ \hline Preconditions & UC 1.1, 2.1 erfolgreich abgeschlossen\\ \hline Postconditions & Applikation gibt die Mieten des aktuellen\\ & Users aus.\\ \hline Normal Flow & 1. User klickt auf ``Show''\\ & 2. Die Applikation gibt die Details zu den\\ & Mieten des Users aus.\\ \hline Alternative Flow & -\\ \hline Notes & -\\ \hline UC History & 1.0 Draft erstellt durch AZ\\ & 1.1 kleinere Anpassungen durch AZ\\ \hline Author & A. Zweili \& I. Cadaroski\\ \hline Date & 24. August 2017\\ \hline \caption{Use Case 2.2 Mieten anzeigen} \end{longtable}} \newpage %% -- End of Use Case Template -- \newpage \begin{landscape} \section{Stundenplanung} %% -- start Stundenplanung table -- \footnotesize \begin{longtable}{|>{\columncolor[HTML]{EFEFEF}}p{4cm}|p{2.1cm}|p{1.8cm}|p{1.8cm}|p{1.8cm}|p{7cm}|} \hline %begin title row {\cellcolor[HTML]{C0C0C0}Aktivität} & {\cellcolor[HTML]{C0C0C0}Definition} \footnote{Definition Arbeit ist grundlegend in Dokumentation (Doku) der Lösung und erarbeiten des Codes (Code) der dazugehörigen Funktionen aufgebaut} & {\cellcolor[HTML]{C0C0C0}Planung} & {\cellcolor[HTML]{C0C0C0}Leistung} & {\cellcolor[HTML]{C0C0C0}Differenz} & {\cellcolor[HTML]{C0C0C0}Erklärung} \\ \hline %endtitle row Projekt Management & Doku & 10 & 20.08 & 10.08 & Nach dem definieren der Meetings wurde uns schnell bewusst, dass eine Absprache alle 2 Wochen Nötig ist, um den Fortschritt im Auge zu behalten. \\ \hline Dokumentation & Doku & 25 & 32 & 7 & \ \\ \hline Vision & Doku & & & 0 & \ \\ \hline User Stories & Doku & 2 & 2 & 0 & \ \\ \hline RM erstellen & Doku & 3 & 4 & 1 & Beim RM haben wir viel weniger Details eingezeichnet sondern uns Hauptsächlich darauf beschränkt uns eine grobe Übersicht zu verschaffen. \\ \hline ERM erstellen & Doku & 4 & 12 & 8 & \ \\ \hline Testplan aufgebaut & Doku & 12 & 1 & -11 & \ \\ \hline SQL Scripts erstellen & Code & 7 & 7.9 & 0.9 & Das erstellen der Testdaten Scripts hat etwas mehr Zeit gebraucht als erwartet. Insbesondere da wir zuerst versucht Haben die Länder und Städte Listen bereits komplett zu erstellen. \\ \hline Frontend erstellen & Code & 25 & 16 & -9 & -25 \\ \hline Datenbankverbindung & & 2 & 4 & 2 & \ \\ \hline GUI Planung + Erstellen & & 2 & 2 & 0 & \ \\ \hline Konzept des Aufbaus & & & & 0 & \ \\ \hline Standort-Abfrage & & 4 & 9 & 5 & \ \\ \hline Rent-Reservation-Eingabe & & & & 0 & \ \\ \hline Rent-Abfrage & & & & 0 & \ \\ \hline Coding & Code & 16 & 24 & 8 & \ \\ \hline Testplan durchgeführt & Doku & 30 & & -30 & \ \\ \hline Total & & 142 & 133.98 & & \\ \hline \caption{Stundenplanung} \end{longtable} %% -- end Stundenplanung table -- \end{landscape} \newpage \section{Umsetzung} \subsection{Zusammenarbeit} Zur Zusammenarbeit am Code haben wir uns für Git entschieden. Dies ermöglichte es uns gleichzeitig am Code zu arbeiten und zwischendurch die Änderungen des anderen zu ``mergen''. Dies war von grossem Vorteil da wir so unabhängig voneinander am Code weiterarbeiten konnten. So entstanden insgesammt über 150 Commits. Desweiteren haben wir uns die Arbeit so aufgeteilt damit wir möglichst unabhängig voneinander arbeiten konnten und somit nicht aufeinander warten mussten. Andreas hat sich Hauptsächlich mit den SQL Scripts beschäftigt. Parallel dazu konnte sich Ismail in das Schreiben einer grafischen C\# Applikation einlesen. Sobald die SQL Skripte fertig waren konnte Ismail diese nutzen um die Applikation fertig zu stellen. Die Dokumentation wurde dabei fortlaufen erweitert. Da wir die Dokumentation in \LaTeX geschrieben haben und somit auch nur aus simplen Textdateien besteht konnten wir auch an dieser ohne Probleme gleichzeitig arbeiten und über Git versionieren. \subsection{ER Modell und ER Diagramm} Gleich zu Beginn des Projektes haben wir den Text zur Aufgabenstellung eingehend analysiert und daraus ein Entity-Relationship-Modell(ERM), Abbildung: (\ref{fig:rm}) erstellt. Wir haben dabei darauf verzichtet für jede Entität noch die jeweiligen Attribute einzuzeichnen da wir uns mit dem ERM Hauptsächlich einen Überblick über die Situation verschaffen wollten damit wir die Abhängigkeiten zwischen den Entitäten besser nachvollziehen konnten. Im Anschluss wurden dann das Entity-Relationship-Diagramm(ERD), Abbildung: (\ref{fig:erm}) erstellt. Dies wurde mit allen Details erstellt. Im ERD haben wir auch Eigenschaften von Attributen erfasst welche in der exportieren Übersicht hier in der Dokumentation nicht ersichtlich sind, wie etwa ``Unique'', ``Not Null'', etc. Aus dem ERD konnten dann relativ schnell die SQL Scripts abgeleitet werden. \subsection{SQL Datenbank} Nachfolgend werden die Entitäten der Datenbank kurz beschrieben damit das ERD Diagramm, Abbildung: (\ref{fig:erm}) besser verstanden werden kann. Dabei wird zuerst der Name der Tabelle in der Datenbank aufgelistet gefolgt von der deutschen Übersetzung. \paragraph{persons / (Personen)} Sind die Repräsentation einer realen Person in der Datenbank. Hier werden auch die Adressdaten eines Mitgliedes gespeichert. \paragraph{salutation / (Anreden)} Enthält die möglichen Anreden für Personen. \paragraph{cities / (Städte)} Enthält Städtenamen sowie die dazugehörige Postleizahl und einem Verweis zu welchem Land die jeweilige Stadt gehört. \paragraph{countries / (Länder)} Enthält eine Liste mit Ländernamen. \paragraph{locations / (Standorte)} Diese Tabelle enthält die Daten der Standorte wo die jeweiligen Märkte abgehalten werden. Dabei wird auch erfasst wie viel Kapazität der jeweilige Standort hat damit mein ein Überbuchen verhindern kann. \paragraph{members / (Mitglieder)} Sind die eigentlichen User im System. In der Regel verweisen sie auf eine reale Person können zu Testzwecken aber auch ohne eine reale Person im Hintergrund angelegt werden. Diese Entität wird dabei auch mit den jeweiligen Käufen verbunden damit man nachvollziehen kann wer diese getätigt hat. Hier wird auch gespeichert ob das Mitglied die notwendigen Dokumente unterzeichnet und die Kreditüberprüfung bestanden hat. \paragraph{member\_status / (Mitgliedsstatus)} Die Mitgliedsstatus Tabelle enthält die möglichen Stati die ein Mitglied haben kann. Dabei werden hier auch Mitglieder Stati wie Mitarbeiter oder Admin erfasst. \paragraph{subscribtions / (Abonnemente)} Beschreiben die Abonnementsarten welche von den Mitgliedern gekauft werden können. \paragraph{commercials / (Werbung)} Diese Tabelle enthällt alle Daten zu Änderungen des Webauftritt eines Mitgliedes. Diese Tabelle wird benötigt damit sichergestellt werden kann das ein Mitglied nur nur die zugelassene Anzahl an Änderungen beantragt. Je nach Kundenwunsch könnte man diese noch erweitern um zusätzliche Daten zu erhalten. Etwa eine Überprüfung auf die Grösse der Änderungen um zu überprüfen wie fest die Funktion von den Mitgliedern genutzt wird. \paragraph{quality\_checks / (Qualitätschecks)} Beschreibt die Beziehung zwischen zwei Mitglieder wobei eines der Mitglieder der Prüfer und ein anderes Mitglied der Geprüfte ist. Zusätzlich wird erfasst an welchem Tag der Check geplant ist und Ob der Check bestanden wurde. \paragraph{subscription\_orders / (Abonnementsbestellungen)} Enthält die Abokäufe die ein Mitglied macht und welcher Standort dabei gewählt wurde Sowie an welchem Tag der Kauf getätigt wurde. Das Kaufdatum kann in der finalen Version dazu verwendet werden zu berechnen ob das aktuelle Abo noch gültig ist oder nicht. \paragraph{trial\_period / (Probezeit)} Beinhaltet die Zeit wie lange die Probezeit ist damit diese nicht als ein Fixwert im Code abgelegt werden muss. Diese sollte es ermöglichen das die Dauer der Probezeit auch nachträglich noch einfach angepasst werden kann. \paragraph{rents / (Mieten)} Beinhaltet die Mieten welche ein Mitglied in der Probezeit getätigt hat. Dabei wird über den Mietpreis der Standort definiert der gemietet wird und mit einem Datumsfeld wird angegeben an welchem Tag der Platz reserviert wurde. \paragraph{rent\_prices / (Mietpreise)} Diese Tabelle weist jedem Standort einen Preis zu. Dies ermöglicht es die Preise für jeden Standort flexibel zu halten und den regionalen Interessengruppen anzupassen. \begin{landscape} \begin{figure} \centering \includegraphics[height=0.8\textheight]{diagrammes/rm.png} \caption{Entity-Relationship-Modell\label{fig:rm}} \end{figure} \end{landscape} \begin{landscape} \begin{figure} \centering \includegraphics[scale=0.38]{diagrammes/erm.png} \caption{Entity-Relationship-Diagramm\label{fig:erm}} \end{figure} \end{landscape} \subsection{C\#} In dieser Sektion wird das Erstellen einer kleiner Anwendung beschrieben, in der wir gewisse Segmente unserer Datenbank abrufen und bearbeiten können. Damit zeigen wir die Funktionalität und Verarbeitung unsere Datenbank auf. \subsubsection{Verbindung zur Datenbank} Um die Verbindung ( connectionstring ) abrufen zu können, erstellen wir eine ``Helper'' Klasse. Darin haben wir den Verbindungspfad definiert der beim Verbindungsaufbau in App.config aufgerufen wird. Den definitiven (connectionstring) haben wir in ``App.config'' bestimmt. \subsubsection{grafische Oberfläche} Die grafische Oberfläche (GUI) wurde beim Aufbauen des Projektes als ``Windows Form Application'' gestartet und ``Dashboard'' genannt. Nach dem Anpassen der Grösse, haben wir eine ``ListBox'' eingesetzt und sie umbenannt. Sie dient dazu, zukünftig gesuchte Daten darin aufzuführen. Um die gesuchten Daten eingebe zu können, haben wir danach eine ``TextBox'' eingefügt. Sobald die gesuchten Daten in der ``TextBox'' eingegeben wurden, werden die Informationen aufgerufen und in der ``ListBox'' aufgezeigt. \subsubsection{Definition der Klassen} Hier werden alle eingesetzten Klassen der Applikation vorgestellt und definiert. Zu jeder Klasse gibt es eine passende Grafik welche ihre Methoden und Attribute beschreibt. Nachfolgend habe wir eine Beispiel Grafik, Abbildung: (\ref{fig:class_example}) eingefügt welche die Symbole und den Aufbau beschreibt. \begin{figure}[H] \centering \includegraphics[scale=0.7]{diagrammes/example.png} \caption{Beispiel Klassen\label{fig:class_example}} \end{figure} \paragraph{Programm} Beinhaltet die Main Klasse von wo aus alle anderen Klassen und Funktionen aufgerufen werden. \paragraph{Helper} Helper.cs dient dem Zweck, den Pfad der Datenbank nicht in jeder Methode eingeben zu müssen. Dafür haben wir in dieser Klasse den Verbindungsaufbau durch den Configuration.Manager definiert. Den Pfad zur Datenbank muss dadurch nur ein einziges Mal in App.config definiert werden und kann dann durch die Helper.cs Klasse simpel aufgerufen werden. \paragraph{LoginForm} Diese Klasse, Abbildung: (\ref{fig:login_class}) wurde für das Registrieren und Einloggen des Benutzers mit einem dazugehörigen GUI, Abbildung: (\ref{fig:login}), von uns erstellt. Dadurch können sich Benutzer durch das Eingeben der Email-Adresse und des Passwortes mit dem ``Register-Button'' Registrieren und durch ein zweites eingeben der Daten und betätigen des ``Login-Button'' auch gleich einloggen. Nach dem Login wird auch gleich eine Nachricht der Applikation dem Benutzer mit dem Text ``It worked'' aufgezeigt, um den erfolgreichen Login zu melden. Dadurch möchten wir die Funktion des Einfüllens und Lesen der Daten aus der Datenbank aufzeigen. \begin{figure}[H] \centering \includegraphics[scale=0.7]{diagrammes/loginform.png} \caption{LoginForm Klasse} \label{fig:login_class} \end{figure} \begin{figure}[H] \centering \frame{\includegraphics[scale=0.7]{screenshots/login.png}} \caption{Screenshot der LoginForm} \label{fig:login} \end{figure} \paragraph{Dashboard} Auf dem Dashboard, Abbildung: (\ref{fig:dashboard_class}), haben wir den Kern was Informationen herauslesen und wieder Eingeben belangt, erstellt. In dieser Klasse werden die aus der Datenbank herausgelesenen Daten der ``locations'' und ``rents'' Tabellen im GUI, Abbildung: (\ref{fig:dashboard}) aufgezeigt und /oder eingefügt. Damit möchten wir einen Teil der finalen Applikation und Datenbank abbilden mit dem, die Benutzer Standorte heraussuchen und den Mietbeginn eingegeben können. Um unsere Demo-Applikation simpel zu halten, kann ein Mitglied nach dem Registrieren und Einloggen die vom Verwalter hinzugefügten Standorte heraussuchen, sie dann in unsere Mietbox schieben und nach dem wählen des gewünschten Zeitpunktes den Standort mieten. \begin{figure}[H] \centering \includegraphics[scale=0.7]{diagrammes/dashboard.png} \caption{Dashboard Klasse} \label{fig:dashboard_class} \end{figure} \begin{figure}[H] \centering \frame{\includegraphics[width=0.9\textwidth]{screenshots/dashboard.png}} \caption{Screenshot des Dashboards} \label{fig:dashboard} \end{figure} \paragraph{DataAccess} Mit der DataAccess Klasse, Abbildung: (\ref{fig:dataaccess}) konnten wir nahezu alle Datenbank relevanten Funktionen, die in unserem GUI ausgeführt werden, in einer einzigen Klasse abbilden. Darin haben wir den Aufruf der Datenbanktabellen mit den dazu benötigten SQL - Befehlen ausgeführt. Dadurch wird SQL- Code so gut wie nur in dieser Klasse aufgerufen und diesbezüglich verwendet. Unter anderem wird auch der Login des Benutzers darin geprüft. \begin{figure}[H] \centering \includegraphics[scale=0.7]{diagrammes/dataaccess.png} \caption{DataAccess Klasse} \label{fig:dataaccess} \end{figure} \paragraph{Get-``Klassen''} Um Daten herauszulesen oder zur Datenbank zu schicken, haben wir in C\# Klassen der ``locations'', ``rents'' und ``members'' erstellt, die sie abbilden. Damit nehmen die dazu benötigten Spalten der jeweiligen Tabellen entgegen. Danach werden die benötigten Datensätze mit den ``Methoden-Infos'' der derweiligen Klasse aufgerufen. Die ``GetMembers'' Klasse, Abbildung: (\ref{fig:getmembers}), wird für die Registration und den Login der Mitglieder benötigt: \begin{figure}[H] \centering \includegraphics[scale=0.7]{diagrammes/getmembers.png} \caption{GetMembers Klasse} \label{fig:getmembers} \end{figure} Die ``GetLocations'' Klasse, Abbildung: (\ref{fig:getlocations}), für das Herauslesen der Märkte um dem Mitglied alle im Moment hinzugefügten Mietoptionen darzubieten: \begin{figure}[H] \centering \includegraphics[scale=0.7]{diagrammes/getlocations.png} \caption{GetLocations Klasse} \label{fig:getlocations} \end{figure} Die ``GetRents'' Klasse, Abbildung: (\ref{fig:getrents}), für`s Mieten und Abbilden der jeweiligen Märkte: \begin{figure}[H] \centering \includegraphics[scale=0.7]{diagrammes/getrents.png} \caption{GetRents Klasse} \label{fig:getrents} \end{figure} \subsubsection{Probleme} \begin{itemize} \item Verbindungsaufbau Der Verbindungsaufbau zur Datenbank musste immer an den jeweiligen Test-Anwender der Datenbank angepasst werden. \item Insert Data Nach den ersten Test's wurde uns klar, dass wir ein Problem mit der weitergabe der ID's hatten. Der Fehler kam erst ans Licht, als wir anfingen die jeweiligen ``locations'' und ``members''- ID's durch das GUI einzufügen. Gelöst wurde das ganze mit einer statischen Klasse. \end{itemize} \subsubsection{Addons/ Packages} Dapper \cite{dbcs6} ist ein simpler ``object mapper'' für .NET. Wir nutzen ihn anstelle von einem ADO.NET data reader da er nütziche Erweiterungen bei unserer IDbConnection bietet, indem er Erweiterungsmethoden zur Datenbankabfrage bietet. Dapper erweitert unsere IDbConnection verwendung mit mehreren Methoden wie : \begin{itemize} \item Execute \item Query \item QueryFirst \item QueryFirstOrDefault \item QuerySingle \item QuerySingleOrDefault \item QueryMultiple \end{itemize} Weiter Infos unter : http://dapper-tutorial.net/dapper \newpage \begin{landscape} \section{Testfälle} %% -- start Test Case table -- \footnotesize \begin{longtable}{|>{\columncolor[HTML]{EFEFEF}}p{1.5cm}|p{2.5cm}|p{2.5cm}|p{2.5cm}|p{2.5cm}|p{2.5cm}|p{2.5cm}|p{2.5cm}|} \hline %begin title row \cellcolor[HTML]{C0C0C0}Testcase ID & \cellcolor[HTML]{C0C0C0}Objektive & \cellcolor[HTML]{C0C0C0}Precondition & \cellcolor[HTML]{C0C0C0}Steps & \cellcolor[HTML]{C0C0C0}Testdata & \cellcolor[HTML]{C0C0C0}Expected Result & \cellcolor[HTML]{C0C0C0}Postcondition & \cellcolor[HTML]{C0C0C0}Result \\ \hline % end title row TC-01 & Registrierung am System & - & 1. Öffnen des Programms \newline 2. Eingeben des Usernamens \newline 3. Eingeben des Passworts\newline 4. Klicken des ``Register'' Knopf & Username: muster@gmx.ch Passwort: 123456 & Erfolgreiche Registrierung & User registriert & Erfolgreich durchgeführt. 27.07.2017 A.Z. \\ \hline TC-02 & Registrierung am System & TC-01 ausgeführt. & 1. Öffnen des Programms \newline 2. Eingeben des Usernamens \newline 3. Eingeben des Passworts \newline 4. Klicken des ``Register'' Knopf & Username: \newline muster@gmx.ch Passwort: \newline 123456 & Fehlermeldung: \newline “User already exists.” & Login / Registrierung Wird wieder angezeigt & Beim ersten Durchführen fehlte Noch eine Try/Catch Funktion Was die Applikation zum Abstürzen brachte. \\ \hline TC-03 & Anmeldung am System & TC-01 ausgeführt. & 1. Öffnen des Programms \newline 2. Eingeben des Usernamens \newline 3. Eingeben des Passworts \newline 4. Klicken des ``Login'' Knopf \newline 5. Quittieren des Pop-Up & Username: \newline muster@gmx.ch Passwort: \newline 123456 & Meldung: \newline ``It worked'' Quittierung führt zum Dashboard & Dashboard wird Angezeigt. & Erfolgreich durchgeführt. 27.07.2017 A.Z. \\ \hline TC-04 & Anmeldung am System & TC-01 ausgeführt. & 1. Öffnen des Programms \newline 2. Eingeben des Usernamens \newline 3. Eingeben des Passworts \newline 4. Klicken des ``Login'' Knopf \newline 5. Fehlermeldung quittieren & Username: \newline muster@gmx.ch Passwort: \newline WrongPassword & Fehlermeldung: \newline ``Username or Password Not correct.'' & Login / Registrierung Wird wieder angezeigt & Erfolgreich durchgeführt. 27.07.2017 A.Z. \\ \hline TC-05 & Anmeldung am System & - & 1. Öffnen des Programms \newline 2. Eingeben des Usernamens \newline 3. Eingeben des Passworts \newline 4. Klicken des ``Login'' Knopf \newline 5. Fehlermeldung quittieren & Username: \newline muster@gmx.ch Passwort: \newline 123456 & Fehlermeldung: \newline ``Username or Password Not correct.'' & Login / Registrierung Wird wieder angezeigt & Erfolgreich durchgeführt. 27.07.2017 A.Z. \\ \hline TC-06 & Standorte anzeigen & TC-01 und TC-03 Ausgeführt & 1. Suchbegriff eingeben 2. ``Search'' Knopf klicken & Suchbegriff: \newline Markt & Suchresultat: \newline ``Markstrasse 300 Testmarkt'' erscheint & Suchresultat wird Angezeigt. & Zuerst wurde mit ``equal'' gesucht was es sehr Schwierig machte zu suchen. Wurde zu ``like'' korrigiert. Erfolgreich durchgeführt. 27.07.2017 A.Z. \\ \hline TC-07 & Standorte anzeigen & TC-01 und TC-03 Ausgeführt & 1. keinen Suchbegriff eingeben 2. ``Search'' Knopf klicken & & Suchresultat: \newline ``Markstrasse 300 Testmarkt Teststrasse 450 Testmark2'' Erscheint & Suchresultat wird Angezeigt. & Erfolgreich durchgeführt. 27.07.2017 A.Z. \\ \hline TC-08 & Standort mieten & TC-01, TC-03 und TC-06 ausgeführt. & 1. keinen Suchbegriff eingeben \newline 2. ``Search'' Knopf klicken \newline 3. beliebigen Standort wählen \newline 4. ``Add'' Knopf klicken \newline 5. Mietdatum auswählen \newline 6. ``Rent'' Knopf klicken & & Miete wird in Datenbank Verbucht. & & \\ \hline TC-09 & Mieten anzeigen & TC-01, TC-03, TC-06 Und TC-08 ausgeführt & 1. ``Refresh'' Knopf klicken & & Die ``Rents'' Liste wird Aktualisiert und gibt Die in TC-08 getätigte Miete aus. & Mietliste wurde Befüllt. & \\ \hline % TC-11 & & & & & & & \\ \hline \caption{Testfälle} \end{longtable} %% -- end test case table -- \end{landscape} %%% Local Variables: %%% mode: latex %%% TeX-master: "main" %%% End: