\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 Alltagssprache 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 verschafften 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 geschrieben 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 beinhalten 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} Die grössten Differenzen in unserer Planung sind der C\# Applikation nachzuführen. Da wir in diesem Aspekt noch nicht die nötige Erfahrung besitzen, musste sehr viel Zeit in Wissensbeschaffung investiert werden. %% -- 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}\textbf{Aktivität}} & {\cellcolor[HTML]{C0C0C0}\textbf{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}\textbf{Planung}} & {\cellcolor[HTML]{C0C0C0}\textbf{Leistung}} & {\cellcolor[HTML]{C0C0C0}\textbf{Differenz}} & {\cellcolor[HTML]{C0C0C0}\textbf{Erklärung}} \\ \hline %endtitle row Projekt Management & Doku & 10 & 20 & 10 & Wir hatten uns zu Beginn darauf festgelegt alle zwei Wochen ein kurzes Meeting abzuhalten. Die Meetings wurden dann aber mit durchschnittlich 1h länger als ursprünglich angenommen. \\ \hline Dokumentation & Doku & 25 & 45 & 20 & Wir haben bei dieser Arbeit wesentlich mehr Zeit in die Dokumentation investiert. Ein Teil davon ist sicher der Tatsache zu schulden das wir die Arbeit in LaTeX geschrieben haben. \\ \hline Vision & Doku & 1 & 1 & 0 & \ \\ \hline User Stories & Doku & 2 & 2 & 0 & \ \\ \hline ERM erstellen & Doku & 3 & 2 & -1 & Beim RM haben wir weniger Details eingezeichnet sondern uns hauptsächlich darauf beschränkt uns eine grobe Übersicht zu verschaffen. \\ \hline ERD erstellen & Doku & 4 & 12 & 8 & Die Aufgabenstellung hat sich als wesentlich komplizierter herausgestellt als wir angenommen hatten. \\ \hline User Stories(Diagramm) erstellen & & 1 & 1 & 0 & \ \\ \hline Testplan aufgebaut & Doku & 12 & 4 & -8 & Erwies sich als weniger Aufwand, als ursprünglich gedacht. Da wir mit den Use Cases bereits gute Vorlagen hatten. \\ \hline SQL Code & & & & & \ \\ \hline SQL Scripts erstellen & Code & 7 & 8 & 1 & 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 C\# Code & & & & & \\ \hline Frontend (GUI) erstellen & Code & 25 & 30 & 5 & Der Aufbau unseres GUI zeigte sich um einiges komplizierte als wir es uns zu Anfang vorgestellt haben. Ein grosser Anteil des Aufwanfes ging an die Nachforschung des Codes verloren, da wir dies zu diesem Zeitpunkt noch nicht angewendet Haben. \\ \hline Datenbankverbindung & Code & 2 & 3 & 1 & Es entstand ein kleiner Mehraufwand, da bei Applikation jeweils der Verbindungsstring angepasst werden musste Wenn der Code auf einem anderen Computer kompiliert wurde. \\ \hline Konzept des Aufbaus & Code & 4 & 4 & 0 & Der Konzeptaufbau (Was möchten wir darstellen?), wurde von uns öfters als geplant umstrukturiert, hielt sich aber noch Im Zeitrahmen \\ \hline Login und Registration & Code & 4 & 6 & -2 & Die ID- Vergabe und die Verarbeitung benötigten mehr Aufwand als vorgesehen \\ \hline Standort-Abfrage & Code & 6 & 9 & 3 & Durch Wissenslücken ging ein Grossteil der Zeit in der Infromationssuche verloren \\ \hline Rent-Reservation-Eingabe & Code & 20 & 32 & 12 & Die Übergabe der verschiedenen ID`s in der Applikation warfen einige Probleme auf, die in der Reservation besonders Zum vorschein gekommen sind \\ \hline Rent-Abfrage & Code & 8 & 8 & 0 & \\ \hline Coding (Verbinden der Funktionen) & Code & 20 & 40 & 20 & Da wir in unserer Applikation gleich mehrere Funktionen abgebildet haben(Login/Informationsabfrage/ Informationseingabe/Abfrage eingefüllter Daten), war das darauffolgende Verbinden des Codes auch ein grosser Aufwand \\ \hline Test`s & & & & & \ \\ \hline Testplan durchgeführt & Doku & 30 & 15 & -15 & Die Tests haben wesentlich weniger Zeit gebraucht als angenommen und wurden meistens on the fly gemacht. \\ \hline \textbf{Total} & & \textbf{184} & \textbf{242} & & \\ \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. \paragraph{RentedLocations} Damit wir die getätigten Mieten in der Applikation sauber ausgeben können war es nötig eine View zu erstellen. Diese behinhaltet drei ``inner joins'' über die Tabellen ``members'', ``rents'', ``rent\_prices'' und ``locations''. Somit kann man einsehen welches Mitglied an welchem Ort und zu welchem Preis einen Stand gemietet hat. \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.23]{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 von uns erstellt. Dadurch können sich Benutzer durch das Eingeben der Email-Adresse und des Passwortes mit dem ``Register-Button'' Registrieren. Bei erfolgreicher Registrierung erhalten sie dann eine entsprechende Meldung, Abbildung: (\ref{fig:register}). Durch ein zweites Eingeben der Daten und betätigen des ``Login-Button'' können sie sich dann auch gleich einloggen, Abbildung: (\ref{fig:login}). Nach dem erfolgreichen Login wird der User dann auf das Dashboard weitergeleitet. \begin{figure}[H] \centering \includegraphics[scale=0.23]{diagrammes/loginform.png} \caption{LoginForm Klasse} \label{fig:login_class} \end{figure} \begin{figure}[H] \centering \frame{\includegraphics[scale=0.7]{screenshots/register.png}} \caption{Screenshot der Registrierung} \label{fig:register} \end{figure} \begin{figure}[H] \centering \frame{\includegraphics[scale=0.7]{screenshots/login.png}} \caption{Screenshot der LoginForm} \label{fig:login} \end{figure} \newpage \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 einen Standort zu mieten muss ein User sich zuerst einen Standort heraussuchen und diesen markieren. Anschliesend kann er das passende Datum markieren und zum Abschluss die Miete mit dem ``Rent-Button'' tätigen. \begin{figure}[H] \centering \includegraphics[scale=0.23]{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.23]{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.23]{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.23]{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.23]{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 & Pop-up mit ``Member Registered'' Text erscheint & 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. Erfolgreich durchgeführt. 13.08.2017 I.C. \\ \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 & Der User wird zum Dashboard weitergeleitet & 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. Mietdatum auswählen \newline 5. ``Rent'' Knopf klicken & & Miete wird in Datenbank Verbucht. & & Erfolgreich durchgeführt. 22.08.2017 I.C. \\ \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. & Erfolgreich durchgeführt. 22.08.2017 I.C. \\ \hline % TC-11 & & & & & & & \\ \hline \caption{Testfälle} \end{longtable} %% -- end test case table -- \end{landscape} \section{Fazit} Im Bezug auf die Planung verlief diese Case Study wesentlich besser als die vorherige. Insbesondere die Zeitplanung lief sehr gut. Wir hatten zwar geplant nach den Sommerferien mit der Arbeit fertig zu sein was wir schlussendlich nicht erreicht hatten. Jedoch wurden wir ca. einen Monat später, Anfangs September, mit dem grössten Teil der Arbeit fertig und lagen somit immer noch sehr gut in der Zeit. Durch die regelmässigen Meetings waren wir bezüglich dem Fortschritt immer auf dem aktuellsten Stand. Zusätzlich ermöglichten uns die Meetings frühzeitig Korrekturen bezüglich der Planung vorzunehmen und somit allfällige Probleme zu umgehen. Desweiteren hatten wir so auch ideal Zeit technische Schwierigkeiten miteinander zu besprechen. Wie etwa wie wir gewisse Entitäten abbilden wollen oder bei Problemen bei der C\# Applikation. Die C\# Applikation war insgesamt der grösste Knackpunkt dieser Casestudy. Die Anwendung funktioniert soweit wie geplant könnte in dieser Form allerdings wohl eher nicht produktiv eingesetzt werden. Der Aufbau der Datenbank hat uns dazu im Vergleich verhältnismässig wenig Probleme bereitet. Das Hauptproblem dabei war hauptsächlich die schwammige Beschreibung der Anforderung des Kunden. Wie auch in der letzten Case Study hat sich das Arbeiten mit Git wieder bewährt. Allerdings könnten wir uns die Funktionen von Git stärker zu nutzen machen. Etwa Test Branches erstellen um schnell etwas zu testen oder die Commits noch sauberer zu erstellen damit man einfacher mit ihnen arbeiten kann. Bezüglich der Dokumentation haben wir uns ein gute und stabile Umgebung in \LaTeX aufgebaut welche wir so nun auch ohne weiteres in späteren Arbeiten verwenden können. Insbesondere die Tabellen werden wir sehr gut auch in späteren Projekten nutzen können. %%% Local Variables: %%% mode: latex %%% TeX-master: "main" %%% End: