558 lines
19 KiB
TeX
558 lines
19 KiB
TeX
\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 auf mit möglichst wenig Aufwand verwaltet
|
|
werden können.
|
|
|
|
\subsection{Stakeholder}
|
|
Folgende Stakeholder sind in diesem Projekt zu berücksichtigen:
|
|
\begin{itemize}
|
|
\item Plattform Inhaber
|
|
\item Standbetreiber
|
|
\item Marktbesucher
|
|
\end{itemize}
|
|
|
|
\subsection{Chancen und Risiken}
|
|
|
|
\subsubsection{Chancen}
|
|
\begin{itemize}
|
|
\item Zusammenhänge zwischen Programmierung und Datenbank Modelierung
|
|
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 in
|
|
Details verlieren die nicht gefordert werden sowie unter Umständen
|
|
Dinge einbauen welche wir nicht genügend kennen was uns zu einem
|
|
späteren Zeitpunkt zum Verhängnis werden könnte.
|
|
|
|
\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 auf
|
|
die 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, Postleizahlen, Standorte.
|
|
\item Die Datenbank enthält ein Rechtekonzept.
|
|
\end{itemize}
|
|
|
|
\newpage
|
|
\section{User Stories}
|
|
\subsection{Verwaltung}
|
|
Als Plattforminaber 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 kann.
|
|
\end{itemize}
|
|
|
|
\subsection{Anbieter provisorisches Mitglied}
|
|
Als provisorisches Mitglied möchte ich,
|
|
\begin{itemize}
|
|
\item mich registrieren können.
|
|
\item einen 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 Abonnement lösen können.
|
|
\item Standorte buchen können.
|
|
\item meinen Auftritt anpassen können.
|
|
\end{itemize}
|
|
|
|
\subsection{Nachfrager/ Marktbesucher}
|
|
Als Markbesucher 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}
|
|
In den Nachfolgenden Sektionen werden die einzelnenen User Stories in
|
|
Use Cases detailierter beschrieben. Wobei das Use Case Diagramm nur
|
|
einen groben Überblick über die möglichen Szenarien innerhalb der
|
|
Applikation gibt.
|
|
|
|
Für die Funktionen welche wir in der C\# Applikation effektiv umgesetzt
|
|
haben, haben wir die Use Cases im Detail beschrieben.
|
|
\subsection{Use Case Diagramm}
|
|
|
|
\subsection{Use Cases}
|
|
|
|
%% -- Begining of Use Case Template --
|
|
\subsubsection{User Registration}
|
|
\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 Registration} \\ \hline
|
|
%end title row
|
|
Description & Der Use Case beschreibt die Registrierung\\
|
|
& eines neuen User Accounts.\\
|
|
\hline
|
|
Actors & User\\
|
|
\hline
|
|
Status & Freigegeben\\
|
|
\hline
|
|
Includes & -\\
|
|
\hline
|
|
Trigger & User möchte sich registrieren.\\
|
|
\hline
|
|
Preconditions & -\\
|
|
\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 Darft erstellt durch AZ\\
|
|
\hline
|
|
Author & A. Zweili \& I. Cadaroski\\
|
|
\hline
|
|
Date & 20. Juli 2017\\
|
|
\hline
|
|
\caption{1.0 User Registration}
|
|
\end{longtable}
|
|
\newpage
|
|
%% -- End of Use Case Template --
|
|
|
|
%% -- Begining of Use Case Template --
|
|
\subsubsection{User Login}
|
|
\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 & Der Use Case beschreibt den Login eines\\
|
|
& Users.\\
|
|
\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ützen 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 Darft erstellt durch AZ\\
|
|
\hline
|
|
Author & A. Zweili \& I. Cadaroski\\
|
|
\hline
|
|
Date & 20. Juli 2017\\
|
|
\hline
|
|
\caption{1.1 User Login}
|
|
\end{longtable}
|
|
\newpage
|
|
%% -- End of Use Case Template --
|
|
|
|
%% -- Begining of Use Case Template --
|
|
\subsubsection{Standorte begutachten}
|
|
\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 begutachten} \\ \hline
|
|
%end title row
|
|
Description & Der Use Case beschreibt das Betrachten der\\
|
|
& Standorte.\\
|
|
\hline
|
|
Actors & User\\
|
|
\hline
|
|
Status & Freigegeben\\
|
|
\hline
|
|
Includes & -\\
|
|
\hline
|
|
Trigger & User möchte Standort Details einsehen.\\
|
|
\hline
|
|
Preconditions & UC 1.1 erfolgreich abgeschlossen\\
|
|
\hline
|
|
Postconditions & -\\
|
|
\hline
|
|
Normal Flow & 1. User wählt einen Standort aus\\
|
|
& 2. Die Applikation gibt die Details zum\\
|
|
& ausgewählten Standort aus.\\
|
|
\hline
|
|
Alternative Flow & -\\
|
|
\hline
|
|
Notes & -\\
|
|
\hline
|
|
UC History & 1.0 Darft erstellt durch AZ\\
|
|
\hline
|
|
Author & A. Zweili \& I. Cadaroski\\
|
|
\hline
|
|
Date & 20. Juli 2017\\
|
|
\hline
|
|
\caption{2.0 Standorte begutachten}
|
|
\end{longtable}
|
|
\newpage
|
|
%% -- End of Use Case Template --
|
|
|
|
|
|
\newpage
|
|
\begin{landscape}
|
|
\section{Stundenplanung}
|
|
|
|
%% -- start Stundenplanung table --
|
|
\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 & 17.58 & 7.58 & 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 & 30 & 5 & \ \\ \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 verschafen. \\ \hline
|
|
ERM erstellen & Doku & 4 & 12 & 8 & \ \\ \hline
|
|
Testplan aufgebaut & Doku & 12 & 1 & -11 & \ \\ \hline
|
|
& & & & 0 & \ \\ \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
|
|
& & & & 0 & 0 \\ \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
|
|
& & & & 0 & \ \\ \hline
|
|
Testplan durchgeführt & Doku & 30 & & -30 & \ \\ \hline
|
|
Total & & 142 & 129.48 & & \\ \hline
|
|
& & & & & \\ \hline
|
|
\caption{Stundenplanung}
|
|
\end{longtable}
|
|
%% -- end Stundenplanung table --
|
|
\end{landscape}
|
|
|
|
\newpage
|
|
\section{Zusammenarbeit}
|
|
\subsection{Lösungsvarianten}
|
|
|
|
\newpage
|
|
\section{Coding}
|
|
|
|
\subsection{RM}
|
|
|
|
\subsection{ERM}
|
|
\subsubsection{Entitäten}
|
|
|
|
In dieser Sektion werden die Entitäten der Datenbank kurz beschrieben
|
|
damit das ERM besser verstanden werden kann. Dabei wird zuerst der
|
|
Name in der Datenbank aufgelistet gefolgt von der deutschen
|
|
Übersetzung.
|
|
|
|
\textbf{persons / (Personen)}
|
|
\newline
|
|
Sind die Repräsentation einer realen Person in der Datenbank. Hier
|
|
werden auch die Adressdaten eines Mitgliedes gespeichert.
|
|
|
|
\textbf{salutation / (Anreden)}
|
|
\newline
|
|
Enthält die möglichen Anreden für Personen.
|
|
|
|
\textbf{cities / (Städte)}
|
|
\newline
|
|
Enthält Städtenamen sowie die dazugehörige Postleizahl und einem
|
|
Verweis zu welchem Land die jeweilige Stadt gehört.
|
|
|
|
\textbf{countries / (Länder)}
|
|
\newline
|
|
Enthält eine Liste mit Ländernamen.
|
|
|
|
\textbf{locations / (Standorte)}
|
|
\newline
|
|
Diese Tabelle enthält die Daten der Standorte wo die jeweiligen Märkte
|
|
abgehalten werden. Dabei wird auch erfasst wieviel Kapazität der
|
|
jeweilige Standort hat damit mein ein überbuchen verhindern kann.
|
|
|
|
\textbf{members / (Mitglieder)}
|
|
\newline
|
|
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.
|
|
|
|
\textbf{member\_status / (Mitgliedsstatus)}
|
|
\newline
|
|
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 da es für die Datenbank keinen
|
|
Unterschied macht welche Funktion ein Mitglied hat.
|
|
|
|
\textbf{subscribtions / (Abonnemente)}
|
|
\newline
|
|
Beschreiben die Abonnementsarten welche von den Mitgliedern gekauft
|
|
werden können.
|
|
|
|
\textbf{commercials / (Werbung)}
|
|
\newline
|
|
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.
|
|
|
|
\textbf{quality\_checks / (Qualitätschecks)}
|
|
\newline
|
|
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.
|
|
|
|
\textbf{subscription\_orders / (Abonnementsbestellungen)}
|
|
\newline
|
|
Enthält die Abokäufe die ein Mitglied macht welcher Standort dabei
|
|
gewählt wurde sowie an welchem Tag der Kauf getätigt wurde.
|
|
|
|
\textbf{trial\_period / (Probezeit)}
|
|
\newline
|
|
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 nächträglich noch einfach angepasst
|
|
werden kann.
|
|
|
|
\textbf{rents / (Mieten)}
|
|
\newline
|
|
Beinhaltet die Mieten welche ein Mitglied in der Probezeit getätigt
|
|
hat. Dabei wird über den Mietspreis der Standort definiert der
|
|
gemietet wird und mit einem Datumsfeld wird angegeben an welchem Tag
|
|
der Platz reserviert wurde.
|
|
|
|
\textbf{rent\_prices / (Mietpreise)}
|
|
\newline
|
|
Diese weisst jedem Standort einen Preis zu. Dies ermöglicht es die
|
|
Preise für jeden Standort flexibel zu halten und den regionalen
|
|
Interessengruppen anzupassen.
|
|
|
|
\subsection{C\#}
|
|
|
|
In dieser Sektion wird das Verarbeiten einer kleiner Funktion
|
|
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{Connection}
|
|
|
|
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{GUI}
|
|
|
|
Das 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 einzugeben,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.
|
|
|
|
\textbf{Programm}
|
|
\newline
|
|
Dient grundsätzlich als Eintrittspunkt der Applikation und hat sonst
|
|
keine grosse Funktion.
|
|
|
|
\textbf{Helper}
|
|
\newline
|
|
Helper.cs dient dem Zweck, den Pfad der Datenbank nicht in jeder
|
|
Methode eingeben zu müssen. Daführ 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.
|
|
|
|
|
|
\textbf{LoginForm}
|
|
\newline
|
|
Diese Klasse 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 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üllen und Lesen der Daten aus
|
|
der Datenbank aufzeigen. Den Verbindungsaufbau in die Datenbank mit
|
|
allen nötigen Funktion(Schreiben / Lesen) haben wir in die Klasse
|
|
"DataAccess" ausgelagert.
|
|
|
|
\textbf{Dashboard}
|
|
\newline
|
|
Auf dem Dashboard haben wir unseren Kern was Informationen herauslesen
|
|
und wieder Eingeben belangt, erstellt. In dieser Klasse werden die aus
|
|
der Datenbank herausgelesenen Daten der locations / (Standorte) und
|
|
rents / (Mieten) Tabellen im GUI aufgezeigt und /oder eingefügt. Damit
|
|
möchten wir einen Teil unserer Applikation und Datenbank abbilden, mit
|
|
der Benutzer Standort heraussuchen können, neue Standorte hinzugefügt
|
|
werden können und den Mietbeginn/ das Zahlungsdatum eingegeben werden
|
|
kann. Den Verbindungsaufbau in die Datenbank mit allen nötigen
|
|
Funktion(Schreiben / Lesen) haben wir in die Klasse "DataAccess"
|
|
ausgelagert und vom GUI aus verankert.
|
|
|
|
\textbf{DataAccess}
|
|
\newline
|
|
Mit der DataAccess Klasse konnten wir nahezu alle Datenbank relevanten
|
|
Funktionen, die sonst in unseren 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 nur in dieser Klasse aufgerufen und verwendet.
|
|
|
|
\textbf{GetRents}
|
|
\newline
|
|
Um Daten herauszulesen oder zur Datenbank zu schicken, haben wir in C#
|
|
ein Model der "rents" Tabelle erstellt die sie abbildet. Damit nehmen
|
|
wir jede Spalte der Tabelle entgegen. Danach werden mit der "RentInfo"
|
|
Methode nur diejenigen Spalten der Tabelle für unser GUI abgerufen,
|
|
die wir auch wirklich benötigen. Jedoch wird die "RentInfo" Methode
|
|
noch nicht benötigt, da wir Daten nur einfügen und nicht herauslesen
|
|
möchten.
|
|
|
|
\textbf{GetMembers}
|
|
\newline
|
|
Um Daten herauszulesen oder zur Datenbank zu schicken, haben wir in C#
|
|
ein Model der "members" Tabelle erstellt die sie abbildet. Damit
|
|
nehmen wir jede Spalte der Tabelle entgegen. Danach werden mit der
|
|
"MemberInfo" Methode nur diejenigen Spalten der Tabelle für unser GUI
|
|
abgerufen, die wir auch wirklich benötigen,um die Login Daten zu
|
|
überprüfen.
|
|
|
|
\textbf{GetLocations}
|
|
\newline
|
|
Um Daten herauszulesen oder zur Datenbank zu schicken, haben wir in C#
|
|
ein Model der "locations" Tabelle erstellt die sie abbildet. Damit
|
|
nehmen wir jede Spalte der Tabelle entgegen. Danach werden mit der
|
|
"LocationInfo" Methode nur diejenigen Spalten der Tabelle für unser
|
|
GUI abgerufen, die wir auch wirklich benötigen.
|
|
|
|
\subsubsection{Problematik}
|
|
-Verbindungsaufbau
|
|
|
|
-Insert Data
|
|
|
|
-Datenvormatierung (Geburtstag)
|
|
|
|
\subsubsection{Referenzen und Addons/ Packages}
|
|
Mit Dapper \cite{dbcs6} entschieden wir uns, nachdem wir ein wenig
|
|
nachgeforscht haben und wir auf Stack Overflow fündig wurden. Da auf
|
|
dieser Webseite Dapper genutzt wird und wir bisher immer gute
|
|
Erfahrungen mit Stack Overflow hatten, schien die Entscheidung
|
|
einfach.
|
|
|
|
\subsubsection{Referenzen}
|
|
-using System.Configuration;
|
|
-using Dapper;
|
|
|
|
\subsubsection{Addons}
|
|
|
|
\newpage
|
|
\begin{landscape}
|
|
\section{Testfälle}
|
|
|
|
%% -- start Test Case table --
|
|
\begin{longtable}{|>{\columncolor[HTML]{EFEFEF}}p{1.8cm}|p{2cm}|p{2.5cm}|p{2cm}|p{2cm}|p{2cm}|p{2.5cm}|p{2cm}|}
|
|
\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 & & & & & & & \\ \hline
|
|
TC-02 & & & & & & & \\ \hline
|
|
TC-03 & & & & & & & \\ \hline
|
|
TC-04 & & & & & & & \\ \hline
|
|
TC-05 & & & & & & & \\ \hline
|
|
TC-06 & & & & & & & \\ \hline
|
|
TC-07 & & & & & & & \\ \hline
|
|
TC-08 & & & & & & & \\ \hline
|
|
TC-09 & & & & & & & \\ \hline
|
|
TC-10 & & & & & & & \\ \hline
|
|
TC-11 & & & & & & & \\ \hline
|
|
\caption{Testfälle}
|
|
\end{longtable}
|
|
%% -- end test case table --
|
|
\end{landscape}
|
|
%%% Local Variables:
|
|
%%% mode: latex
|
|
%%% TeX-master: "main"
|
|
%%% End:
|