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