diff --git a/doku/content.tex b/doku/content.tex index a3704c6..ac0c3f2 100644 --- a/doku/content.tex +++ b/doku/content.tex @@ -4,7 +4,7 @@ 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 +Überblick über den verschiedenen Anbietern geben und somit Neugierde wecken. Dies alles soll mit möglichst wenig Aufwand verwaltet werden können. @@ -37,7 +37,7 @@ zum Projekt noch grafisch auf. \subsubsection{Risiken} Ein grosses Risiko ist das wir uns beim Erarbeiten der Datenbank sowie -beim schreiben der Applikation in Details verlieren die nicht +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. @@ -54,21 +54,21 @@ werden. 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 + \item Eine Teilfunktion des Geschäftsmodells wurde in einer C\# Applikation abgebildet. \end{itemize} \subsection{Wunschziele} \begin{itemize} - \item Die Datenbank enthält alle statische Daten Wie + \item Die Datenbank enthält alle statischen 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 +User Stories sind eine in Alltagssprache geschriebenen +Software-Anforderungen. Sie sind bewusst kurzgehalten und beschreiben die Wünsche und Ziele der Rollen welche die Software verwenden. @@ -159,6 +159,7 @@ Wir haben uns dabei zu Beginn die folgenden drei möglichen Szenarien 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 @@ -267,7 +268,7 @@ Notes & -\\ UC History & 1.0 Draft erstellt durch AZ\\ & 1.1 kleinere Anpassungen durch AZ\\ \hline -Author & A. Zweili \& I. Cadaroski\\ +Autor & A. Zweili \& I. Cadaroski\\ \hline Date & 24. August 2017\\ \hline @@ -341,13 +342,13 @@ Date & 24. August 2017\\ \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.\\ + & 3. User bestätigt die Miete mit einem Klick auf dem 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.\\ + & 3. User bestätigt die Miete mit Klick auf dem Insert Button.\\ & 4. Die Applikation meldet zurück das der Standort an diesem Datum\\ & bereits besetzt ist.\\ \hline @@ -441,7 +442,7 @@ 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 +ist sicher der Tatsache zu Schulden das wir die Arbeit in LaTeX geschrieben haben. \\ \hline Vision & Doku & 1 & 1 & 0 & \ \\ \hline @@ -449,7 +450,7 @@ 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 +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 @@ -462,7 +463,7 @@ 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 +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 @@ -470,9 +471,9 @@ 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 +vorgestellt haben. Ein grosser Anteil des Aufwandes ging an die Nachforschung des Codes verloren, da wir dies zu diesem Zeitpunkt noch -nicht angewendet Haben. \\ \hline +nicht angewendet haben. \\ \hline Datenbankverbindung & Code & 2 & 3 & 1 & Es entstand ein kleiner Mehraufwand, da bei Applikation jeweils der Verbindungsstring @@ -487,17 +488,17 @@ 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 +Grossteil der Zeit in der Informationssuche 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 +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 +haben (Login/Informationsabfrage/ Informationseingabe/Abfrage eingefüllter Daten), war das darauffolgende Verbinden des Codes auch ein grosser Aufwand \\ \hline @@ -522,9 +523,9 @@ 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. +entstanden insgesamt über 150 Commits. -Desweiteren haben wir uns die Arbeit so aufgeteilt damit wir möglichst +Des Weiteren haben wir uns die Arbeit so aufgeteilt damit wir möglichst unabhängig voneinander arbeiten konnten und somit nicht aufeinander warten mussten. @@ -585,14 +586,14 @@ jeweilige Standort hat damit mein ein Überbuchen verhindern kann. 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 +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 +Die Mitgliedsstatus-Tabelle enthält die möglichen Status die ein +Mitglied haben kann. Dabei werden hier auch Mitglieder Status wie Mitarbeiter oder Admin erfasst. \paragraph{subscribtions / (Abonnemente)} @@ -600,9 +601,9 @@ 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 +Diese Tabelle enthält alle Daten zu Änderungen des Webauftritts eines Mitgliedes. Diese Tabelle wird benötigt damit sichergestellt werden -kann das ein Mitglied nur nur die zugelassene Anzahl an Änderungen +kann das ein Mitglied nur die zugelassene Anzahl an Änderungen beantragt. Je nach Kundenwunsch könnte man diese noch erweitern um zusätzliche @@ -617,15 +618,15 @@ 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 +Enthält die Abo Kä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 +ein Fix Wert im Code abgelegt werden muss. Diese sollte es ermöglichen +dass die Dauer der Probezeit auch nachträglich noch einfach angepasst werden kann. \paragraph{rents / (Mieten)} @@ -641,7 +642,7 @@ 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 +können war es nötig eine View zu erstellen. Diese beinhaltet 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. @@ -665,7 +666,7 @@ Mitglied an welchem Ort und zu welchem Preis einen Stand gemietet hat. \subsection{C\#} -In dieser Sektion wird das Erstellen einer kleiner Anwendung +In dieser Sektion wird das Erstellen einer kleinen 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. @@ -694,7 +695,7 @@ 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: +Attribute beschreibt. Nachfolgend haben wir eine Beispiel Grafik, Abbildung: (\ref{fig:class_example}) eingefügt welche die Symbole und den Aufbau beschreibt. @@ -760,7 +761,7 @@ 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 +zuerst einen Standort heraussuchen und diesen markieren. Anschliessend kann er das passende Datum markieren und zum Abschluss die Miete mit dem ``Rent-Button'' tätigen. @@ -800,7 +801,7 @@ 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. +``Methoden-Infos'' der derzeitigen Klasse aufgerufen. Die ``GetMembers'' Klasse, Abbildung: (\ref{fig:getmembers}), wird für die Registration und den Login der Mitglieder benötigt: @@ -812,7 +813,7 @@ die Registration und den Login der Mitglieder benötigt: \label{fig:getmembers} \end{figure} -Die ``GetLocations'' Klasse, Abbildung: (\ref{fig:getlocations}), für +Die ``GetLocations'' Klasse, Abbildung: (\ref{fig: getlocations}), für das Herauslesen der Märkte um dem Mitglied alle im Moment hinzugefügten Mietoptionen darzubieten: @@ -841,16 +842,16 @@ und Abbilden der jeweiligen Märkte: 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 + Nach den ersten Tests 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. + 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 +nutzen ihn anstelle von einem ADO.NET data reader da er nützliche Erweiterungen bei unserer IDbConnection bietet, indem er Erweiterungsmethoden zur Datenbankabfrage bietet. @@ -964,24 +965,25 @@ und gibt Die in TC-08 getätigte Miete aus. & Mietliste wurde Befüllt. \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 +In Bezug auf die Planung verlief diese Casestudy wesentlich besser +als die vorherige in Webtechnologie. +Insbesondere die Zeitplanung lief sehr gut, da wir diesbezüglich Erfahrungen aus der Webtechnologie- Case Study mitnehmen konnten. +Wir hatten zwar geplant nach den Sommerferien mit der Arbeit grösstenteils fertig zu +sein, was schlussendlich nicht erreicht wurde. 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 +Durch die regelmässigen Meetings, waren wir bezüglich des Fortschritts immer auf dem aktuellsten Stand. Zusätzlich ermöglichten uns die -Meetings frühzeitig Korrekturen bezüglich der Planung vorzunehmen und +Meetings frühzeitig Korrekturen 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. +Des Weiteren hatten wir so auch ideal Zeit technische Schwierigkeiten +miteinander zu besprechen. Beispielsweise wie wir gewisse Entitäten abbilden +möchten, oder Probleme die bei der C\# Applikation auftraten. Die C\# Applikation war insgesamt der grösste Knackpunkt dieser -Casestudy. Die Anwendung funktioniert soweit wie geplant könnte in +Casestudy. Die Anwendung funktioniert so weit wie geplant, jedoch könnte sie in dieser Form allerdings wohl eher nicht produktiv eingesetzt werden. Der Aufbau der Datenbank hat uns dazu im Vergleich verhältnismässig @@ -990,8 +992,8 @@ 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 +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