2017-10-29 21:03:20 +01:00
#+TITLE : Casestudy Webtechnologien
#+SETUPFILE : ~/git_repos/notes/settings/html_theme/setup/theme-readtheorg.setup
2017-10-30 07:54:24 +01:00
#+AUTHOR : Ivan Hörler Andreas Zweili
#+LaTeX_CLASS : article
#+LATEX_CLASS_OPTIONS : [a4paper,11pt]
#+LaTeX_HEADER : \input{style}
2018-01-06 15:53:04 +01:00
#+OPTIONS : H:5 todo:t
2018-01-18 20:05:28 +01:00
#+LANGUAGE : de
2018-01-06 15:01:17 +01:00
#+STARTUP : align
2017-10-29 21:03:20 +01:00
2018-01-05 15:04:33 +01:00
2018-02-15 20:17:52 +01:00
* Über dieses Dokument
2017-10-31 21:22:50 +01:00
2017-10-31 20:31:01 +01:00
Im nachfolgenden Abschnitt finden Sie allgemeine Informationen zu
2018-01-05 15:04:33 +01:00
diesem Dokument.
2018-02-15 20:17:52 +01:00
** Titel der Dokumentation
2017-10-31 21:22:50 +01:00
2017-10-31 20:31:01 +01:00
Die Gruppe hat verschiedene Varianten gelistet und sich für die
lustigste entschieden.
2017-10-31 22:11:09 +01:00
2017-10-31 20:31:01 +01:00
- Marktplatz
- Shopshop
2017-10-31 22:11:09 +01:00
- Barewahre-Shop
2018-02-17 15:59:48 +01:00
- *Didgeridoo-Shop*
Aufgrund des eher lustigen Namens dieses Instruments haben wir uns
entschieden diesen Titel zu verwenden. Die Ursprünge des Instruments
liegen 2000 Jahre, sagen die Forscher –
Aborigines zurück.
…Als das Traumzeitvolk die Erde verließ, hinterließ es den Menschen ein
Geschenk: Ein Horn, das ein Klangfeld zwischen ihrer Welt und unserer erzeugt…\footcite{didgeridoo}
2017-10-31 20:31:01 +01:00
** Beschreibung
2017-10-31 21:22:50 +01:00
2017-10-31 22:11:09 +01:00
Planung und Erstellung eines konfigurierbaren Web-Shops für
Didgeridoo's.
2017-10-31 20:31:01 +01:00
** Zweck und Inhalt
2017-10-31 21:22:50 +01:00
2017-10-31 20:31:01 +01:00
Zweck dieses Dokuments ist die vollständige und nachvollziehbare
Dokumentation zu unserer Case Study Webtechnologie 3.
** Aufbau
2017-10-31 21:22:50 +01:00
2017-10-31 22:11:09 +01:00
Alle Inhalte sind chronologisch sortiert, vom ältesten zum jüngsten
2017-10-31 20:31:01 +01:00
Ereigniss, und nach Kapiteln getrennt.
2018-01-05 15:04:33 +01:00
** Lizenz
2017-10-31 21:22:50 +01:00
2018-01-05 15:04:33 +01:00
Dieses Dokument sowie der dazugehörige Code wurde von Ivan Hörler und
Andreas Zweili im Rahmen einer Arbeit an der IBZ Schule erstellt und
steht unter einer GPLv3\footcite{gplv3} Lizenz. Dadurch darf die
Arbeit kopiert und weiterverarbeitet unter Einhaltung der Regeln der
GPLv3.
2017-10-31 20:31:01 +01:00
2018-01-05 15:04:33 +01:00
* TODO Projektanalyse und Planung
2017-10-30 22:17:17 +01:00
** Projektziele
2017-10-31 21:22:50 +01:00
2017-10-31 20:31:01 +01:00
Der Student erarbeitet in einer Zweiergruppe einen selbstentwickelten
Web-Shop. Die einzusezenden Technologien sollen Opensource sein. Die
zur verfügungstehende Zeit ist pro Student mit 80h zu veranschlagen.
2017-10-31 22:11:09 +01:00
Am Ende dieser Zeitspanne soll ein funktionaler Web-Shop mit minimalem
2018-01-05 15:04:33 +01:00
graphischen User Interface entstehen, die dazugehörige Dokumentation
2017-10-31 22:11:09 +01:00
umfasst alle Aspekte um die gewählte Lösung nachzuvollziehen.
2018-01-05 15:04:33 +01:00
Die Projekt wurden in der Tabelle: ([[tab:projektziele ]]) zusätzlich noch
nach Prioritäten gewichtet.
2017-10-31 20:31:01 +01:00
2017-10-31 22:11:09 +01:00
#+CAPTION : Projektziele
2018-01-05 15:04:33 +01:00
#+ATTR_LATEX : :align |>{\columncolor[HTML]{EFEFEF}}p{0.8cm}|l|p{1.5cm}|
#+NAME : tab:projektziele
2018-01-07 23:46:40 +01:00
|-------+--------------------------------------------------------------------+----------------------|
| <5> | | <20> |
| *Nr.*\cellcolor[HTML]{C0C0C0} | *Beschreibung*\cellcolor[HTML]{C0C0C0} | *Priorität*\cellcolor[HTML]{C0C0C0} |
|-------+--------------------------------------------------------------------+----------------------|
| 1. | Das Datenmodel muss korrekt konzipiert sein. | Hoch |
|-------+--------------------------------------------------------------------+----------------------|
| 2. | Alle Vorgehen müssen in diesem Dokument erläutert werden. | Mittel |
|-------+--------------------------------------------------------------------+----------------------|
| 3. | Die Arbeitsstunden müssen eingehalten werden. | Tief |
|-------+--------------------------------------------------------------------+----------------------|
| 4. | Der Shop muss funktionstüchtig sein. | Mittel |
|-------+--------------------------------------------------------------------+----------------------|
| 5. | Die Applikation muss vor der Übergabe vollständig getestet werden. | Hoch |
|-------+--------------------------------------------------------------------+----------------------|
| 6. | Problemstellungen müssen ersichtlich dokumentiert werden. | Mittel |
|-------+--------------------------------------------------------------------+----------------------|
| 7. | Die Punkte der Bewertung werden erfüllt. | Hoch |
|-------+--------------------------------------------------------------------+----------------------|
2017-10-31 20:31:01 +01:00
2018-02-15 20:19:50 +01:00
** Methoden
Die Methodik die die Gruppe wählt ist Aufgrund der nur zwei Personen
im Team beschränkt. Da jedoch Fehler und Rückschläge erwartet werden
ist eine itterative Methodik unabdingbar. Daher wandte die Gruppe eine
angepasste version von Scrum an. In dieser wird jeweils während
Sitzungen die Position des Product Owners und des Scrum Masters
eingenommen und die Backlog-Tasks dementsprechend erstellt resp.
verteilt. Während der Woche arbeiten beide Team-Mitglieder an der
Arbeit als Team-Kolegen.
** Vorkenntnisse
Die benötigten Vorkenntnisse wurden in den vorangeganenen Semestern
erarbeitet und sind in der Basis gefestigt. Diese Arbeit wird
vorwiegend weiterführende Elemente wie Frameworks neu einbringen deren
Verhalten letztendlich nicht abgeschätzt werden kann.
** Vision
Wir wollen einen Web-Shop mit geeigneter Software erstellen. Dabei
setzen wir nur freie Software ein (frei im Bezug auf Freiheit nicht
Preis). Wir untersuchen die Anforderung und wählen die uns als
geeignet erscheinenden Frameworks. Jede noch so kleine Zeiteinsparung
durch vorgefertigte Entwicklungen werden angenommen und dennoch wollen
wir keine fertigen Software Produkte einsetzen.
** TODO SWOT-Analyse
Die SWOT-Analyse ist eine Methode, die Stärken, Schwächen, Chancen und
Gefahren zu erkennen, indem eine 4-Felder-Matrix ausgefüllt wird.
Wichtig vor dem Ausfüllen der SWOT-Analyse ist es, ein klares Ziel zu
haben. Die ausegfüllte SWOT-Analyse für dieses Projekt ist in der
Tabelle: ([[tab:swot ]]) zu sehen.
2018-02-17 15:59:48 +01:00
#+CAPTION: SWOT-Analyse
#+NAME: tab:swot
#+BEGIN_EXPORT latex
%--Beginn SWOT Analyse
%---Used for SWOT Analysys Chart
%---Source https://tex.stackexchange.com/questions/177167/swot-table-how-to-convert-to-an-article
\colorlet{staerken}{lime!70}
\colorlet{schwaechen}{red!30}
\colorlet{chancen}{yellow!20}
\colorlet{risiken}{cyan!30}
\colorlet{S}{staerken!50!chancen}
\colorlet{W}{schwaechen!50!chancen}
\colorlet{O}{staerken!50!risiken}
\colorlet{T}{schwaechen!50!risiken}
% implemented this in doc instead as in preamble:
\def\bigfont#1#{\fontsize{120}{130}\selectfont #1}
\begin{tikzpicture}[scale=0.9,
any/.style={
minimum width=8cm,
minimum height=8cm,%
text width=7.5cm,
align=center,
outer sep=1pt
},
header/.style={
any,
minimum height=1cm,
fill=black!10
},
leftcol/.style={
header,rotate=90
},
bigbackgroundfont/.style={
fill=#1,
text=#1!90!black
}
]
\matrix (SWOT) [
matrix of nodes,
nodes={
any,
anchor=center
},%
column sep=-\pgflinewidth,%
row sep=-\pgflinewidth,%
row 1/.style={
nodes=header
},%
column 1/.style={
nodes=leftcol
},
inner sep=0pt]{
& |[fill=staerken]| {Stärken\\ \footnotesize (Unternehmens Anaylse)\par}
& |[fill=schwaechen]| {Schwächen\\ \footnotesize (Unternehmens Anaylse)\par} \\
| [fill=chancen] | {Chancen\\ \footnotesize (Externe Analyse)\par} |
& |[bigbackgroundfont=S]| \bigfont{S}
& |[bigbackgroundfont=W]| \bigfont{W} \\
| [fill=risiken] | {Risiken\\ \footnotesize (Externe Analyse)\par} |
& |[bigbackgroundfont=O]| \bigfont{O}
& |[bigbackgroundfont=T]| \bigfont{T} \\
};
\node[
any,
anchor=center
] at (SWOT-2-2) { % Interne Stärken/Externe Chancen feld:
\begin{itemize}
\item Know-How in Webtechnologien.
\item Quelloffene Software ist leichter zu unterhalten.
\item durch verwendung des Frameworks kann die Entwicklungszeit
stark reduziert werden.
\item Wir als Programmierer haben ein gutes Know-How
im Bereich Datenbanken.
\end{itemize}
};
\node[
any,
anchor=center
] at (SWOT-2-3) { % Interne Schwächen/Externe Chancen feld:
\begin{itemize}
\item Das Framework ist nicht vollkommen. Teile davon müssten
eventuell selber konzipiert/erarbeitet werden.
Welche Teile das sind ist noch nicht ersichtlich.
Durch die Quelloffene Lizenz kann dies dem Projekt jedoch
einen mehrwert geben, in dem diese Teile wiederverwendet
werden können.
\item Der Kunde vertraut uns, und die Beziehung ist gut.
Diese Ausgangslage mag helfen interne Schwächen durch
offene Kommunikation übergehen.
\end{itemize}
};
\node[
any,
anchor=center
] at (SWOT-3-2) { % Interne Stärken/ Externe Risiken feld:
\begin{itemize}
\item Quelloffene Software kann unkontrolliert kopiert werden.
\item Die implementation von Währungsänderungen ist
nicht trivial. Der Zeitpunkt zu dem die Kosten
eines Produktes sich ändert muss gut durchdacht werden.
\end{itemize}
};
\node[
any,
anchor=center
] at (SWOT-3-3) { % Interne Schwächen/ Externe Risiken feld:
\begin{itemize}
\item Wir als Programmierer haben keine Erfahrung im
Konsumsegment unseres Nutzers..
\item Die Umsetzung der graphischen Anwendungsoberfläche
könnte sich als schwierig erweisen.
\item Die Umsetzungszeit ist knapp bemessen.
\end{itemize}
};
\end{tikzpicture}
%--Ende SWOT Analyse
#+END_EXPORT
2018-02-15 20:19:50 +01:00
** Umweltanalyse
Die Projektumwelt-Analyse ist eine Methode, die Beziehungen,
Erwartungshaltungen und Einflüsse auf das Projekt durch interne und
externe soziale Umwelten zu betrachten und zu bewerten. Auf Grundlage
der Analyseergebnisse werden erforderliche Massnahmen zur Gestaltung
der Umweltbeziehungen abgeleitet. Die Gestaltung der
Projektumweltbeziehungen ist eine Projektmanagementaufgabe. In dieser
Tabelle: ([[tab:umweltanalyse ]]) wurden die Anforderungen und Wünsche
mit Einschätzung der Wahrscheinlichkeit der Einflussnahme aufgenommen.
Zusätzlich ist die Beziehung der Stakeholder zum Projekt noch in der
Abbildung: ([[fig:umweltgrafik ]]) grafisch dargestellt.
#+LATEX :\newpage
#+LATEX :\begin{landscape}
#+CAPTION : Umwelt-Analyse
#+ATTR_LATEX : :align |>{\columncolor[HTML]{EFEFEF}}p{0.8cm}|l|l|p{8cm}|l|
#+NAME : tab:umweltanalyse
|-------+----------------------+----------------------+-----------------------------------------------+---------------------------------------------|
| <5> | <20> | <20> | | |
| *Nr*.\cellcolor[HTML]{C0C0C0} | *Stakeholder*\cellcolor[HTML]{C0C0C0} | *Einfluss*\cellcolor[HTML]{C0C0C0} | *Anforderung/Wünsche*\cellcolor[HTML]{C0C0C0} | *Warscheinlichkeit*\cellcolor[HTML]{C0C0C0} |
|-------+----------------------+----------------------+-----------------------------------------------+---------------------------------------------|
| 1. | Auftraggeber | hoch | - Innovatives Produkt auf dem Markt anbieten. | hoch |
| | | | - Einhaltung von Terminen und Qualität. | hoch |
|-------+----------------------+----------------------+-----------------------------------------------+---------------------------------------------|
| 2. | Kunden | gering | - Einfache Lösung die anpassungsfähig ist. | hoch |
| | | | - Schnell anfangen können. | hoch |
| | | | - Viele Arbeitsschritte Automatisieren | mittel |
|-------+----------------------+----------------------+-----------------------------------------------+---------------------------------------------|
| 3. | Interessenten | gering | - Intuitiv bedienbare Webseite | hoch |
| | | | - schnell finden was gesucht wird. | hoch |
|-------+----------------------+----------------------+-----------------------------------------------+---------------------------------------------|
| 4. | Projektleiter | hoch | - Gutes Innovatives Produkt erschaffen. | mittel |
| | | | - Anerkennung im fachlichen Umfeld | hoch |
|-------+----------------------+----------------------+-----------------------------------------------+---------------------------------------------|
#+LATEX :\end{landscape}
#+CAPTION : Stakeholder Diagramm
#+ATTR_LATEX : :width .9\textwidth
#+NAME : fig:umweltgrafik
[[file:diagrammes/stakeholder_diagramm.eps ]]
** TODO Risikomanagement
2018-02-17 15:59:48 +01:00
*** Risikobeschreibung
2018-02-15 20:19:50 +01:00
#+CAPTION : Risikobeschreibung
#+ATTR_LATEX : :align |>{\columncolor[HTML]{EFEFEF}}p{0.8cm}|p{5cm}|p{5cm}|p{0.8cm}|p{0.8cm}|
#+NAME : tab:risikobeschreibung
|------------+--------------------------------+--------------------------------+-------------------------------+-------------------------------|
| <10> | <30> | <30> | | |
| *Nr.*\cellcolor[HTML]{C0C0C0} | *Beschreibung*\cellcolor[HTML]{C0C0C0} | *Massnahmen*\cellcolor[HTML]{C0C0C0} | *W^1*\cellcolor[HTML]{C0C0C0} | *A^2*\cellcolor[HTML]{C0C0C0} |
|------------+--------------------------------+--------------------------------+-------------------------------+-------------------------------|
| 1. | Die Datenbank ist schlecht modeliert. | Das ERM nach dessen Erstellung gründlich auf Fehler prüfen, falls nötig extern prüfen lassen. | 2 | 3 |
|------------+--------------------------------+--------------------------------+-------------------------------+-------------------------------|
| 2. | Viel Arbeit an der Arbeitsstelle, dabei bleibt weniger Zeit für die Casestudy. | Die Zeit die einem zur Verfügung steht nutzen und fixe Tage definieren. Projektplanung machen. | 1 | 2 |
|------------+--------------------------------+--------------------------------+-------------------------------+-------------------------------|
| 3. | Know-How zur Umsetzung ist nicht vollständig vorhanden. | Gute Informationsbeschaffung im Internet, Mitschülern, Arbeitgeber, Dozenten etc. | 2 | 2 |
|------------+--------------------------------+--------------------------------+-------------------------------+-------------------------------|
| 4. | Kommunikation innerhalb des Teams. | Klare Arbeitsaufteilung innerhalb des Teams und alle 2 Wochen Besprechungen über offene Aufgaben oder Problembehandlungen | 1 | 1 |
|------------+--------------------------------+--------------------------------+-------------------------------+-------------------------------|
| 5. | Die Programmierung des Shops benötigt zuviel Zeit | Beider Projektplanung genau definieren was die GUI Applikation beinhalten muss. Ziele definieren, abgrenzungen treffen. | 3 | 1 |
|------------+--------------------------------+--------------------------------+-------------------------------+-------------------------------|
2018-02-17 15:59:48 +01:00
*** Risikobewertung
2018-02-15 20:19:50 +01:00
#+CAPTION : Risikobewertung Wahrscheinlichkeit
#+ATTR_LATEX : :align l|l :placement [H]
#+NAME : tab:wahrscheinlichkeit
| *Bewertung* | *Beschreibung: Warscheinlichkeit (W)* |
|-------------+---------------------------------------|
| 1 = gering | Unwarscheinlich, <20% |
| 2 = mittel | Mässig warscheinlich, 20-50% |
| 3 = hoch | Hohe warscheinlichkeit > 50% |
#+CAPTION : Risikobewertung Auswirkung
#+ATTR_LATEX : :align l|l :placement [H]
#+NAME : tab:auswirkung
| *Bewertung* | *Beschreibung: Auswirkung (A)* |
|-------------+-------------------------------------------------|
| 1 = gering | geringe auswirkungen auf das Gesammtergebniss |
| 2 = mittel | Arbeitsumstellung oder grösserer Arbeitsaufwand |
| 3 = hoch | Projekt erfüllt nicht alle Anforderungen |
#+CAPTION : Grafische Darstellung der Risikoanalyse
#+ATTR_LATEX : :width 9cm :placement [H]
#+NAME : fig:risk
[[file:diagrammes/risk_analysis.eps ]]
** TODO Projektabgrenzung
Am ende des Projekts die nicht lauffähigen teile ausgrenzen. :-)
* Projektmanagement
** Organigram
2018-02-17 15:59:48 +01:00
#+CAPTION: Organigram
#+NAME: fig:Organigram
#+BEGIN_EXPORT latex
\begin{tikzpicture}[
auto, node distance = 0.4cm,
thick,
every node/.style = {
rectangle,
font = \sffamily,
white,
top color = green!90!black,
bottom color = green!60!black,
text width = 2.7cm,
align = center,
minimum height = 1cm
}
]
\node (PL) {\textbf{PL}\\Projektleiter};
\coordinate [below = 0.2cm of PL] (Unten);
\node (FD) [below = of PL] {\textbf{FD}\\Frontenddeveloper};
\node (SE) [left = of FD] {\textbf{SE}\\Softwareengineer};
\node (BD) [right = of FD] {\textbf{BD}\\Backenddeveloper};
\draw [green!60!black,thick]
(PL) -- (Unten) -| (FD)
(Unten) -| (SE)
(Unten) -| (BD);
\end{tikzpicture}
#+END_EXPORT
2018-02-15 20:19:50 +01:00
** Projektstrukturplan
2018-02-15 20:20:02 +01:00
** Varianten
Wir haben uns 3 mögliche Varianten überlegt im Bezug auf die zu
verwendende Software. Die Varianten wurden bewertet und die Variante
mit den meisten Punkten dann schlussendlich ausgewählt.
Bei jeder Variante wurden die gleichen Kriterien mit der gleichen
Gewichtung bewertet. Die Punktzahl pro Kriterium wird nach der
folgenden Formel berechnet:
\begin{equation}
G * EP = KE
\end{equation}
Also die Gewichtung(/G/ ) multipliziert mit der erreichten
Punktzahl(/EP/ ) ergibt das Kriteriumsergebnis(/KE/ ).
2018-02-15 21:00:30 +01:00
*** ASP.NET und SQL Server
2018-02-15 20:20:02 +01:00
2018-02-15 20:28:26 +01:00
ASP.NET und SQL Server, Tabelle:([[tab:asp-net ]]), haben vorallem viele
Punkte verloren da C# nur in Teilen und SQL Server gar nicht unter
einer freien Lizenz steht. Desweiteren läuft .NET Core zwar auch auf
Unix Systemen allerdings ist das verhältnismässig ein relativ kleiner
Teil der gesamten Sprache. SQL Server läuft hingegen nur unter Windows
und Linux. Desweiteren ist es sehr schwierig C# Applikationen ohne
Visual Studio zu entwickeln. Es geht in der Theorie, in der Praxis ist
es jedoch eher umständlich. Die Vorkenntnisse wurden mit 6 von Punkten
bewertet da wir C# zwar im Rahmen der Ausbildung lernen. Allerdings
noch nicht das Gefühl haben sonderlich gut mit C# umgehen zu können.
2018-02-15 20:20:02 +01:00
#+CAPTION : Bewertung der Variante ASP.NET und SQL Server
#+ATTR_LATEX : :align |>{\columncolor[HTML]{EFEFEF}}p{4cm}|c|p{2cm}|p{2cm}|p{2cm}|
2018-02-15 20:28:26 +01:00
#+NAME : tab:asp-net
2018-02-15 20:20:02 +01:00
|----------------------+----------------------+----------------------+----------------------+----------------------|
| <20> | <20> | <20> | <20> | <20> |
| *Kriterium*\cellcolor[HTML]{C0C0C0} | *Gewichtung*\cellcolor[HTML]{C0C0C0} | *max. Punktzahl*\cellcolor[HTML]{C0C0C0} | *erreichte Punktzahl*\cellcolor[HTML]{C0C0C0} | *Kriteriums- ergebnis*\cellcolor[HTML]{C0C0C0} |
|----------------------+----------------------+----------------------+----------------------+----------------------|
| Freie Software | 5 | 10 | 5 | 25 |
| Cross Plattform nutzbar | 5 | 10 | 6 | 30 |
| Lesbarkeit des Codes | 5 | 5 | 4 | 20 |
| Einfachheit des Setups | 3 | 5 | 5 | 15 |
| Ohne spezielle Tools nutzbar | 3 | 5 | 1 | 3 |
| Vorkenntnisse | 3 | 10 | 6 | 18 |
| Lernfaktor | 5 | 10 | 6 | 30 |
|----------------------+----------------------+----------------------+----------------------+----------------------|
| *Total* | | | | 141 |
#+TBLFM : @3$5=@3$2 * @3$4::@4$5=@4$2 * @4$4::@5$5=@5$2 * @5$4::@6$5=@6$2 * @6$4::@7$5=@7$2 * @7$4::@8$5=@8$2 * @8$4
#+TBLFM : @9$5=@9$2 * @9$4
#+TBLFM : @10$5=vsum(@3$5..@9$5)
2018-02-15 21:00:30 +01:00
*** PHP und MySQL
2018-02-15 20:20:02 +01:00
2018-02-15 20:28:26 +01:00
Die Variante PHP und MySQL, Tabelle:([[tab:php ]]), hat insgesamt ein sehr
gute Bewertung erhalten. Beide Projekte sind zumindest teilweise unter
einer freien Lizenz verfügbar und sind sowohl unter Windows, wie auch
Mac und Linux einsetzbar. Allerdings gibt es von MySQL noch eine
proprietäre Enterprise Variante weshalb wir hier nicht die volle
Punktzahl vergeben konnten. Abstriche gab es bei der Lesbarkeit des
Codes. Da PHP insgesamt eine ziemlich inkonsistente und ausschweifende
Sprache ist. Dafür ist das Setup sehr einfach und man kann eine PHP
basierte Applikation ohne spezielle Werkzeuge entwickeln. Da wir
jedoch bereits sehr intensiv mit PHP und MySQL in Berürung kamen haben
wir beim Lernfaktor abstriche gemacht. In Zusammenhang mit einem
2018-02-15 20:57:03 +01:00
Framework hätten wir sicher auch viel dazugelernt im Vergleich zu den
anderen Varianten jedoch auf jeden Fall weniger.
2018-02-15 20:20:02 +01:00
#+CAPTION : Bewertung der Variante PHP und MySQL
#+ATTR_LATEX : :align |>{\columncolor[HTML]{EFEFEF}}p{4cm}|c|p{2cm}|p{2cm}|p{2cm}|
#+NAME : tab:php
|----------------------+----------------------+----------------------+----------------------+----------------------|
| <20> | <20> | <20> | <20> | <20> |
| *Kriterium*\cellcolor[HTML]{C0C0C0} | *Gewichtung*\cellcolor[HTML]{C0C0C0} | *max. Punktzahl*\cellcolor[HTML]{C0C0C0} | *erreichte Punktzahl*\cellcolor[HTML]{C0C0C0} | *Kriteriums- ergebnis*\cellcolor[HTML]{C0C0C0} |
|----------------------+----------------------+----------------------+----------------------+----------------------|
| Freie Software | 5 | 10 | 8 | 40 |
| Cross Plattform nutzbar | 5 | 10 | 8 | 40 |
| Lesbarkeit des Codes | 5 | 5 | 2 | 10 |
| Einfachheit des Setups | 3 | 5 | 5 | 15 |
| Ohne spezielle Tools nutzbar | 3 | 5 | 5 | 15 |
| Vorkenntnisse | 3 | 10 | 7 | 21 |
| Lernfaktor | 5 | 10 | 4 | 20 |
|----------------------+----------------------+----------------------+----------------------+----------------------|
| *Total* | | | | 161 |
#+TBLFM : @3$5=@3$2 * @3$4::@4$5=@4$2 * @4$4::@5$5=@5$2 * @5$4::@6$5=@6$2 * @6$4::@7$5=@7$2 * @7$4::@8$5=@8$2 * @8$4
#+TBLFM : @9$5=@9$2 * @9$4
#+TBLFM : @10$5=vsum(@3$5..@9$5)
2018-02-15 21:00:30 +01:00
*** Django(Python) und MariaDB
2018-02-15 20:20:02 +01:00
2018-02-15 20:28:26 +01:00
Diese Variante, Tabelle:([[tab:django ]]) hat am meisten Punkte erhalten.
Wie bei der Variante "PHP und MySQL" sind auch hier beide Komponenten
freie Software. Im Gegensatz zu der vorherigen Variante gibt es bei
diesen Komponenten nur eine mögliche Lizenz Form. Womit sie die volle
Punktzahl in dieser Kategorie erreichten.
2018-02-15 20:20:02 +01:00
Beide Projekte laufen unter Windows, Linux sowie Mac. Wobei das Setup
unter für Django(Python) unter Windows etwas komplizierter ausfällt
als wir gerne hätten weshalb wir hier bei der Cross Plattform
Kompatibilität und dem Setup einen Abstrich gemacht haben. Python kann
ohne spezielle Tools programmiert werden und gilt als eine der
Sprachen mit der schönsten Syntax. Die Vorkenntnisse haben wir hier
als eher niedrig eingestuft dafür den Lernfaktor umso höher.
#+CAPTION : Bewertung der Variante Django und MariaDB
#+ATTR_LATEX : :align |>{\columncolor[HTML]{EFEFEF}}p{4cm}|c|p{2cm}|p{2cm}|p{2cm}|
#+NAME : tab:django
|----------------------+----------------------+----------------------+----------------------+----------------------|
| <20> | <20> | <20> | <20> | <20> |
| *Kriterium*\cellcolor[HTML]{C0C0C0} | *Gewichtung*\cellcolor[HTML]{C0C0C0} | *max. Punktzahl*\cellcolor[HTML]{C0C0C0} | *erreichte Punktzahl*\cellcolor[HTML]{C0C0C0} | *Kriteriums- ergebnis*\cellcolor[HTML]{C0C0C0} |
|----------------------+----------------------+----------------------+----------------------+----------------------|
| Freie Software | 5 | 10 | 10 | 50 |
| Cross Plattform nutzbar | 5 | 10 | 9 | 45 |
| Lesbarkeit des Codes | 5 | 5 | 5 | 25 |
| Einfachheit des Setups | 3 | 5 | 3 | 9 |
| Ohne spezielle Tools nutzbar | 3 | 5 | 5 | 15 |
| Vorkenntnisse | 3 | 10 | 4 | 12 |
| Lernfaktor | 5 | 10 | 8 | 40 |
|----------------------+----------------------+----------------------+----------------------+----------------------|
| *Total* | | | | 196 |
#+TBLFM : @3$5=@3$2 * @3$4::@4$5=@4$2 * @4$4::@5$5=@5$2 * @5$4::@6$5=@6$2 * @6$4::@7$5=@7$2 * @7$4::@8$5=@8$2 * @8$4
#+TBLFM : @9$5=@9$2 * @9$4
#+TBLFM : @10$5=vsum(@3$5..@9$5)
2018-02-15 21:00:30 +01:00
*** Ergebnis
2018-02-15 20:20:02 +01:00
2018-02-15 20:28:26 +01:00
Aufgrund der erreichten Punktzahl, Tabelle:([[tab:result ]]) bei den
vorhergehenden Variantenbewertungen haben wir uns dafür entschieden
die Variante "Django(Python) und MariaDB" umzusetzen. In der Sektion
[[Werkzeuge ]] beschreiben wir noch die weiteren Mittel welche beim
Erstellen der Case Study verwendet wurden und erklären wenn möglich
auch weshalb wir uns dafür entschieden haben.
2018-02-15 20:20:02 +01:00
#+CAPTION : Variantenbewertung Ergebnis
#+ATTR_LATEX : :align |>{\columncolor[HTML]{EFEFEF}}p{4.5cm}|r|
#+NAME : tab:result
|------------------------------------+-----------------------------------------------|
| *Variante*\cellcolor[HTML]{C0C0C0} | *Erreichte Punktzahl*\cellcolor[HTML]{C0C0C0} |
|------------------------------------+-----------------------------------------------|
| ASP.NET und SQL Server | 141 |
| PHP und MySQL | 161 |
| Django und MariaDB | 196 |
** Architektur vorbereiten
2018-02-15 20:19:50 +01:00
** Arbeitspakete definieren
* TODO Umsetzung
** Werkzeuge
2017-10-31 21:22:50 +01:00
2018-01-05 15:04:33 +01:00
Während dem Erstellen dieser Arbeit wurde eine Vielzahl an Werkzeugen
eingesetzt. Nachfolgend werden diese Werkzeuge kurz beschrieben sowie
ihre Verwendung begründet. Wir haben dabei darauf geachtet soviel Open
Source Software wie möglich zu verwenden. Nicht nur für den Web-Shop an
sich sondern generell für alle Tasks im Projekt.
2018-02-15 20:19:50 +01:00
*** Versionkontrolle
2018-01-05 15:04:33 +01:00
Eine Versionskontrollsoftware erschien uns als notwendig um den Code
auf einfache und zuverlässige Weise untereinander austauschen zu
können. Andere Lösungen wie Dropbox, etc. hätten es uns nicht erlaubt
Konflikte zu vermeinden.
Als Software für die Versionskontrolle wurde Git \footcite{git} gewählt.
Git wurde aus diversen Gründen gewählt:
- Ist der de facto Standard bei Versionskontrollsoftware
- Läuft auf allen gängigen Betriebsystemen
- Es gäbe gratis Services die man nutzen könnte (Github, Gitlab)
- Man kann offline arbeiten und Commits erstellen
- Das Team hat bereits einen eigenen Git Server zur Verfügung
- Das Team ist bereits mit Git aus vorhergehenden Projekten vertraut
dadurch muss man keine Ressourcen aufwenden eine neue Software zu lernen.
Zusätzlich hat sich Git in den vorhergehenden Projekten als robuste
und schnelle Software erwiesen.
- Git ist freie Software unter GNU Public License v2.
2018-02-15 20:19:50 +01:00
*** Entwicklungsumgebung
2018-01-05 15:04:33 +01:00
Damit beide Studenten auf der gleichen Basis arbeiten haben wir uns
dazu entschieden den Web-Shop in einer virtuellen Maschine zu
entwickeln. Dies führt jedoch in der Regel zum Problem das die
Änderungen in der virtuellen Maschine miteinander abgesprochen und
ausgetauscht werden müssen. Um dieses Problem zu beheben haben wir uns
dazu entschieden Vagrant\footcite{vagrant} zu verwenden.
Vagrant ist freie Software unter der MIT Lizenz.
Vagrant erlaubt es einem den Zustand einer virtuellen Maschine in
einer Text Datei zu beschreiben und diese dann gemäss der Beschreibung
automatisiert aufzusetzen. Dies hat den Vorteil das die Konfiguration
der virtuellen Maschine auch ohne weiteres mit dem restlichen Code in
der Versionskontrollsoftware gepflegt werden kann.
Desweiteren hilft das automatisierte Aufsetzen das vermeiden von
menschlichen Fehlern. Somit kann davon ausgegangen werden dass, das
System in der virtuellen Maschine immer den korrekten Stand zum
entwickeln sein. Sollte dies nicht mehr der Fall sein lässt sich die
virtuelle Maschine mit einem maxmimal zwei Befehlen wieder in den
Ursprungszustand zurücksetzen.
Als Hypervisor der virtuellen Maschine wurde
Virtualbox\footcite{virtualbox} eingesetzt. Virtualbox ist im Kern
freie Software unter der GNU Public License v2. Das unter einer
proprietären Lizenz erhältliche Erweiterungspacket ist für unser Setup
nicht notwendig.
2018-02-15 20:19:50 +01:00
*** Hostsystem
2018-01-05 15:04:33 +01:00
Als Hostsystem für unseren Web-Shop haben wir uns für die Linux
Distribution Debian\footcite{debian} in der Version 9 (Stretch)
entschieden. Für Debian haben wir uns vor allem aus folgenden Gründen
entschieden:
- Stabiles System
- Sehr guter Packetmanager was einem das Scripting vereinfacht.
- Gilt als sehr sicher
- Hat sich in vorhergehenden Projekten bereits als gute Basis bewiesen
- Enthält in der Grundkonfiguration nur freie Software (nicht freie
Software muss aktiv hinzugefügt werden)
- In der Linux Welt sehr verbreitet
- Im Gegensatz zu Ubuntu nicht von einer Firma abhängig
2018-02-15 20:19:50 +01:00
*** Deployment Software für Produktionsserver
2018-01-05 15:04:33 +01:00
Auch auf dem produktiven Server haben wir uns für Debian entschieden.
Um diesen aufzusetzen hatten wir in etwa die ähnlichen Anforderungen
wie für die Entwicklungsumgebung. Also einen Weg um das System
möglichst automatisch und reproduzierbar aufzusetzen. Die für die
Entwicklungsumgebung verwendete Software Vagrant ist für produktive
System allerdings eher weniger geeignet.
Für solche Fälle bietet sich eine Software Namens
"Ansible"\footcite{ansible} an. Diese bietet einem ähnlich wie Vagrant
die Möglichkeit den Zustand eines Systems in Text Dateien zu
beschreiben. Allerdings bietet einem Ansible noch zusätzliche
2018-02-17 15:59:48 +01:00
Möglichkeiten und vor allem ein standardisiertes Interface um
2018-01-05 15:04:33 +01:00
unterschiedliche Systeme auf die selbe Weise zu konfigurieren.
2018-02-17 15:59:48 +01:00
Der Vorteil gegenüber anderen System ist das Ansible mit sehr
2018-01-05 15:04:33 +01:00
wenig Abhängigkeiten für das zu konfigurierende System daherkommt. Auf
einem Linux System ist nur SSH Zugriff und Python notwendig. Einen
Client braucht man nicht zu installieren.
Ansible ist freie Software unter der GNU Public License v3.
2018-02-15 20:19:50 +01:00
*** Framework
2018-01-05 15:04:33 +01:00
Um die Entwicklung der Applikation zu vereinfachen haben wir uns dazu
entschlossen ein Framework einzusetzen. Frameworks bringen einem in
der Entwicklung diverse Vorteile. Unter anderem bieten sie Hilfen bei
sich wiederholenden Programmieraufgaben und bieten je nachdem die
Möglichkeit die Applikation in einer einzigen Sprache zu schreiben da
sich das Framework auch um die Datenbank kümmert. In der
Webentwicklung helfen sie einem insbesondere auch dabei
Sicherheitslücken wie Cross Site Scripting und SQL Injections
abzufangen.
Wir haben uns dabei für das Framework Django\footcite{django}
entschieden. Django ist ein Python basiertest Framework. Django ist
freie Software unter der drei Klausen BSD Lizenz. Wir haben uns aus
folgenden Gründen für ein Python basiertes Framework gegenüber einem
PHP basierten Framework entschieden:
- Python gilt als die Sprache mit der schöneren Syntax
- Wir wollten im Bezug auf das Programmieren etwas neues ausprobieren
was sich im Rahmen einer Case Study sehr gut machen lässt. Da man
ein "realistisches" Szenarium erhält und dieses in einem relativ
kontrollierten Rahmen ausführen kann.
- Python ist in dem von uns gewählten Hostsystem wie in den meisten
Linux Distributionen bereits integriert.
2018-02-15 20:19:50 +01:00
- Desweiteren hat Django bei einer Variantenbewertung das beste
Ergebnis geholt.
2018-01-05 15:04:33 +01:00
2018-01-06 15:01:35 +01:00
Die verwendete Version war dabei 1.10.7-2 aus dem Debian Stretch Repository.
2018-02-15 20:19:50 +01:00
*** Webserver
2018-01-05 15:04:33 +01:00
Als Webserver verwenden wir ganz klassisch Apache\footcite{apache}.
Dies vorallem aus dem Grund das wir Apache aus diversen vorhergehenden
Projekten bereits sehr gut kennen und sich der Webserver dort sehr gut
bewährt hat. Apache wird dabei auch noch gut von Django unterstützt.
Der Apache Webserver ist freie Software unter der Apache License 2.0
und gehört der gemeinnützigen Organisation "Apache Foundation".
2018-02-15 20:19:50 +01:00
*** Datenbank
2018-01-05 15:04:33 +01:00
Bei der Datenbank haben wir uns für MariaDB\footcite{mariadb}
entschieden. Auch hier hauptsächlich weil wir MariaDB bereits aus
vorhergehenden Projekt kennen. MariaDB ist ein Fork von MySQL welcher
gegenüber MySQL rückwärtskompatibel ist. MariaDB ist dabei jedoch viel
Community näher als MySQL und wird dabei auch sehr demokratisch
entwickelt\footcite{mariadbgov}. MariaDB gehört dabei keiner einzelnen
Firma oder Person sonder der gemeinnützigen Organisation "MariaDB
2018-02-15 20:19:50 +01:00
Foundation". Was für zusätzliche Stabilität sorgen sollte. MariaDB ist
freie Software unter GNU Public License v2. Desweiteren hat MariaDB bei
einer Variantenbewertung das beste Ergebnis geholt.
2018-01-05 15:04:33 +01:00
2018-02-15 20:19:50 +01:00
*** Editoren
2018-01-05 15:04:33 +01:00
Das Hauptwerkzeug von jedem Entwickler ist sein Text Editor. Dabei
hat jeder meistens seine ganz eigene Präferenzen wenn es um die Wahl
des Editors geht.
2018-01-06 15:02:30 +01:00
- Atom :: Ivan hat während der Case Study hauptsächlich mit
Atom\footcite{atom} gearbeitet. Atom wird von Github Inc.
entwickelt und basiert auf dem Electron Framework welches
seinerseit auf Webtechnologien wie Node.js und Chromium
basiert. Atom ist freie Software unter der MIT Lizenz.
- GNU Emacs :: Andreas arbeitet hauptsächlich mit dem Editor GNU
Emacs\footcite{emacs}. GNU Emacs ist mit 32 Jahren
(obwohl seine Wurzeln bis ins Jahre 1976 zurückgehen)
wohl eines der ältesten noch "aktiven" Software
Projekte. Emacs ist freie Software unter der GNU Public
License v3.
2018-01-05 15:04:33 +01:00
2018-02-15 20:19:50 +01:00
*** Dokumentation
2018-01-05 15:04:33 +01:00
Diese Dokumentation wurde in Org-mode\footcite{orgmode} einer
Erweiterung für den Text Editor Emacs geschrieben. Anschliessend wurde
die Dokumentation in LaTeX\footcite{latex} Code konvertiert und
finalisiert. Der Zwischenschritt über Org-mode wurde gewählt weil
Org-mode etwas einfacher zu schreiben ist als reines LaTeX.
LaTeX ist eine Software welche einem die Benutzung des Textsatzsystems
TeXs vereinfacht. Wir haben LaTeX gegenüber einem "What You See Is
What You Get" Editor gewählt weil es einem mit seiner Markup Sprache
erlaubt das Dokument in Text Dateien zu erstellen. Was wir als
Programmierer sehr angenehm finden. Dadurch das LaTeX auch nur aus
reinen Textdateien besteht kann man die Dokumente auch ohne weiteres
in die Versionskontrollsoftware einchecken und somit auf einfache
Weise zusammen daran arbeiten und die Entwicklung im Log
zurückverfolgen kann.
2018-01-06 15:02:39 +01:00
LaTeX ist freie Software unter der LaTeX Project Public License.
2018-01-05 15:04:33 +01:00
Die Grafiken in diesem Dokument wurden hauptächlich mit dem Vektor
Grafik Editor Inkscape\footcite{inkscape} erstellt. Inkscape ist freie
2018-02-06 22:02:57 +01:00
Software unter der GNU Public License v3. Für das Entity Relation
Diagramm in [[Models ]] haben wir jedoch Dia\footcite{dia} verwendet. Dia
ist freie Software unter der GNU Public License v2.
2018-01-05 15:04:33 +01:00
Die Klassen Diagramme haben wir mit der Django Erweiterung
"Django-Extensions"\footcite{django_extensions} erstellt.
Django-Extensions ist freie Software unter der MIT Lizenz.
2017-10-31 20:31:01 +01:00
2018-01-05 15:04:33 +01:00
** TODO Spezifikation
2018-01-06 15:03:18 +01:00
*** User Stories
2018-01-05 15:04:33 +01:00
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.
2018-01-06 15:03:18 +01:00
**** Auftraggeber/Verwaltung
2018-01-05 15:04:33 +01:00
2018-01-06 15:02:55 +01:00
Als Anbieter möchte ich...
- Artikel in Kategorien strukturieren damit Kunden sich orientieren können.
- Bilder zu meinen Artikeln hinzufügen damit sich Kunden das Produkt
anschauen können.
- Artikel aktiv oder versteckt schalten können damit ich Produkte auch
temporär aus dem Verkauf nehmen kann.
- Lagerbestände verwalten können damit ich rechzeitig nachbestellen kann.
- Nachbestellungen von Artikeln erfassen können damit ich weiss was
bestellt wurde.
- eine komplette Liste meiner Artikel einsehen können damit ich einen
Überblick über meine Produkte habe.
- eine Liste aller Bestellungen einsehen können um allenfalls
Anpassungen vornehmen zu können.
- Produkte und Kategorien in einer Admin Seite editieren können um
diese einfach administrieren zu können.
2018-01-06 15:03:18 +01:00
**** Kunde
2018-01-05 15:04:33 +01:00
2018-01-06 15:02:55 +01:00
Als Kunde möchte ich...
- durch Kategorien zu den Produkten navigieren um diese einfacher zu finden.
- Artikel einem Warenkorb hinzufügen können damit ich ungestört
stöbern kann und erst am Schluss den administrativen Teil erledigen muss.
- meinen Warenkorb anzeigen und editieren können um allenfalls
Korrekturen vornehmen zu können.
- die Artikel in meinem Warenkorb bestellen können.
- vor dem Abschluss des Kaufs eine Zusammenstellung der Bestellung
einsehen um die Richtigkeit der Daten zu überprüfen.
- mich registrieren können damit ich meine Adresse nicht jedes Mal neu
eingeben muss.
- in einem Bereich der Webseite meine Profildaten zur Überprüfung
einsehen können.
- Artikel in meiner bevorzugten Währung kaufen können damit ich die
Preise nicht umrechnen muss.
2018-01-06 15:03:18 +01:00
**** Interessenten
2018-01-05 15:04:33 +01:00
2018-01-06 15:02:55 +01:00
Als Interessent möchte ich...
- die angebotenen Artikel einsehen können um mir ein Bild über das
Angebot machen zu können.
- die Preise in einer anderen Währung anzeigen können um die
Preise in einer mir bekannten Währung vergleichen zu können.
2018-01-18 20:11:56 +01:00
*** Use Cases
2018-01-05 15:04:33 +01:00
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 Pass- wort beim
Login). Dabei wird die technische Lösung nicht konkret beschrieben.
Die Detailstufe kann dabei sehr unterschiedlich sein.\footcite{usecase}
2018-02-01 21:59:58 +01:00
**** Anwendungsfalldiagramm
2018-01-05 15:04:33 +01:00
"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."\footcite{usecasediagramm}
2018-01-07 18:52:40 +01:00
Das Anwendungsfalldiagramm für unseren Webshop ist in der Abbildung:
([[fig:usecase ]]) zu sehen. Wir haben uns dabei auf die Hauptaspekte des
Webshops beschränkt.
#+LATEX :\newpage
#+LATEX :\begin{landscape}
2018-01-07 11:01:25 +01:00
#+CAPTION : Anwendungsfalldiagramm
2018-01-07 18:52:40 +01:00
#+ATTR_LATEX : :height.9\textwidth
2018-01-07 11:01:25 +01:00
#+NAME : fig:usecase
2018-01-07 18:52:40 +01:00
[[file:diagrammes/use_case.eps ]]
#+LATEX :\end{landscape}
#+LATEX :\newpage
2018-01-07 11:01:25 +01:00
2018-02-01 21:59:58 +01:00
**** Use Cases Detailbeschreibung
2018-01-05 15:04:33 +01:00
2018-01-18 19:57:30 +01:00
Use Cases werden in der Regel mit Hilfe einer sogenannten Use Case
Schablone im Detail beschrieben damit klar ist wie der Ablauf jeweils
genau aussieht. Die von uns verwendete Schablone wurde von Alistair
Cockburn definiert.
Da ein Web-Shop eine sehr umfangreiche Applikation ist gibt es sehr
viele Use Cases welche beschrieben und umgesetzt werden müssen. Aus
zeitlichen Gründen haben wir nur einen kleinen Teil der Use Cases im
Detail ausgearbeitet. Insbesondere diese welche wir selber
2018-02-01 21:59:58 +01:00
aus programmiert haben. Die gesamte Liste an Use Cases sieht wie folgt
2018-01-18 19:57:30 +01:00
aus, die Use Cases mit den Nummern wurden dabei im Detail ausgearbeitet:
#+LATEX : {\footnotesize
2018-01-18 20:12:16 +01:00
| - [[*Artikel durchst%C3%B6bern][1.0 Artikel durchstöbern]] | - Kategorie erfassen (Admin Funktion) |
| - [[Registration][2.0 Registration]] | - Kategorie ändern (Admin Funktion) |
| - [[User Login][2.1 User Login]] | - Kategorie löschen (Admin Funktion) |
2018-01-18 19:57:30 +01:00
| - User Profil ansehen | - Bild hochladen (Admin Funktion) |
2018-01-18 20:12:16 +01:00
| - [[Artikel in Warenkorb legen][3.0 Artikel in Warenkorb legen]] | - Bild ändern (Admin Funktion) |
| - [[W%C3%A4hrung %C3%A4ndern][3.1 Währung ändern]] | - Bild löschen (Admin Funktion) |
2018-01-18 19:57:30 +01:00
| - Währung aktualisieren (Admin Funktion) | - Bestellung erfassen (Admin Funktion) |
2018-01-18 20:12:16 +01:00
| - [[Checkout][3.2 Checkout]] | - [[Bestellung %C3%A4ndern/korrigieren][7.0 Bestellung ändern/korrigieren (Admin Funktion)]] |
| - [[User Passwort %C3%A4ndern][4.0 User Passwort ändern (Admin Funktion)]] | - Bestellung löschen (Admin Funktion) |
| - [[Artikel erfassen][5.0 Artikel erfassen (Admin Funktion)]] | - [[max_pictures Option anpassen][6.0 max_pictures Option anpassen (Admin Funktion)]] |
2018-01-18 19:57:30 +01:00
| - Artikel ändern (Admin Funktion) | - max_pictures Option deaktivieren (Admin Funktion) |
| - Artikel löschen (Admin Funktion) | - User erfassen (Admin Funktion) |
| - Materialbestellung erfassen (Admin Funktion) | - User/Personen Daten ändern (Admin Funktion) |
| - Materialbestellung ändern/korrigieren (Admin Funktion) | - User löschen (Admin Funktion) |
| - Materialbestellung löschen (Admin Funktion) | - User Berechtigungen anpassen (Admin Funktion) |
| - Stadt hinzufügen (Admin Funktion) | |
| - Stadt ändern (Admin Funktion) | |
| - Stadt löschen (Admin Funktion) | |
#+LATEX :}
2018-01-17 22:07:17 +01:00
***** Artikel durchstöbern
2018-01-18 19:57:30 +01:00
#+LATEX :{\footnotesize
2018-01-17 22:07:17 +01:00
#+CAPTION : Use 1.0 Artikel durchstöbern
2018-01-18 19:57:30 +01:00
#+ATTR_LATEX ::environment longtable :align |>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}| :placement [H]
2018-01-17 22:07:17 +01:00
#+NAME : tab:browse_article
|---------------------+--------------------------------|
| | <30> |
| *Identifier + Name* | 1.0 Artikel durchstöbern |
|---------------------+--------------------------------|
| *Description* | Durchklicken der verschiedenen Kategorieren und ansehen der Artikel Details und Bilder. |
|---------------------+--------------------------------|
| *Actors* | Kunden, Interessenten |
|---------------------+--------------------------------|
| *Status* | Freigegeben |
|---------------------+--------------------------------|
| *Includes* | - |
|---------------------+--------------------------------|
| *Trigger* | User möchte Artikel einsehen |
|---------------------+--------------------------------|
| *Preconditions* | Website aufgerufen |
|---------------------+--------------------------------|
| *Postconditions* | - |
|---------------------+--------------------------------|
| *Normal Flow* | 1. Website aufrufen |
| | 2. Kategorienen durchsehen |
| | 3. Artikel anklicken |
|---------------------+--------------------------------|
| *Alternative Flow* | - |
|---------------------+--------------------------------|
| *Notes* | - |
|---------------------+--------------------------------|
| *UC History* | 1.0 Darft erstellt durch AZ |
|---------------------+--------------------------------|
| *Author* | A. Zweili & I. Hörler |
|---------------------+--------------------------------|
| *Date* | 16.01.2018 |
|---------------------+--------------------------------|
2018-01-18 19:58:47 +01:00
#+LATEX :}
2018-01-17 22:07:17 +01:00
***** Registration
2018-01-18 19:58:47 +01:00
#+LATEX :{\footnotesize
2018-01-17 22:07:17 +01:00
#+CAPTION : Use Case 2.0 Registration
2018-01-18 19:58:47 +01:00
#+ATTR_LATEX : :environment longtable :align |>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}| :placement [H]
2018-01-17 22:07:17 +01:00
#+NAME : tab:registration
|---------------------+--------------------------------|
| | <30> |
| *Identifier + Name* | 2.0 Registration |
|---------------------+--------------------------------|
| *Description* | Ein User registriert sich einen Account. |
|---------------------+--------------------------------|
| *Actors* | Interessent |
|---------------------+--------------------------------|
| *Status* | Freigebgen |
|---------------------+--------------------------------|
| *Includes* | - |
|---------------------+--------------------------------|
| *Trigger* | User möchte einen Account erstellen. |
|---------------------+--------------------------------|
| *Preconditions* | Email Adresse vorhanden |
|---------------------+--------------------------------|
| *Postconditions* | Account wurde erfolgreich erstellt. |
|---------------------+--------------------------------|
| *Normal Flow* | 1. User klickt auf den Link "Go to registration.". |
| | 2. User füllt das Registrations Formular aus. |
| | 3. User schliesst die Registrierung mit Klick auf "Register" ab. |
| | 4. Die Website leitet ihn in den Login Bereich um. |
|---------------------+--------------------------------|
| *Alternative Flow* | 1. User klickt auf den Link "Go to registration.". |
| | 2. User füllt das Registrations Formular mir falschen Daten aus. |
| | 3. Die Website gibt die entsprechenden Fehler aus. |
| | 4. Der User korrigiert die Angaben. |
| | 5. User schliesst die Registrierung mit Klick auf "Register" ab. |
| | 6. Die Website leitet ihn in den Login Bereich um. |
|---------------------+--------------------------------|
| *Notes* | - |
|---------------------+--------------------------------|
| *UC History* | 1.0 Darft erstellt durch AZ |
|---------------------+--------------------------------|
| *Author* | A. Zweili & I. Hörler |
|---------------------+--------------------------------|
| *Date* | 16.01.2018 |
|---------------------+--------------------------------|
2018-01-18 19:58:47 +01:00
#+LATEX :}
2018-01-17 22:07:17 +01:00
***** User Login
2018-01-18 19:58:47 +01:00
#+LATEX :{\footnotesize
2018-01-17 22:07:17 +01:00
#+CAPTION : Use Case 2.1 User Login
2018-01-18 19:58:47 +01:00
#+ATTR_LATEX : :environment longtable :align |>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}| :placement [H]
2018-01-05 15:04:33 +01:00
#+NAME : tab:login
2018-01-17 22:07:17 +01:00
|---------------------+--------------------------------|
| | <30> |
| *Identifier + Name* | 2.1 User Login |
|---------------------+--------------------------------|
| *Description* | Ein Kunde logt sich auf der Website ein. |
|---------------------+--------------------------------|
| *Actors* | Kunde |
|---------------------+--------------------------------|
| *Status* | Freigeben |
|---------------------+--------------------------------|
| *Includes* | - |
|---------------------+--------------------------------|
| *Trigger* | Ein Kunde möchte sich einloggen. |
|---------------------+--------------------------------|
| *Preconditions* | UC 2.0 erfolgreich abgeschlossen. |
|---------------------+--------------------------------|
| *Postconditions* | User hat sich erfolgreich eingeloggt. |
|---------------------+--------------------------------|
| *Normal Flow* | 1. User klickt in der Navigation auf "Login". |
| | 2. User gibt Zugangsdaten ein. |
| | 3. User beendet Login mit Klick auf "Login". |
| | 4. Die Website leitet ihn auf die Index Seite um und zeigt neu eine "Profil" und "Logout" Schaltfläche. |
|---------------------+--------------------------------|
| *Alternative Flow* | 1. User klickt in der Navigation auf "Login". |
| | 2. User gibt falsche Zugangsdaten ein. |
| | 3. User beendet Login mit Klick auf "Login". |
| | 4. Die Website gibt entsprechende Fehlermeldungen aus. |
|---------------------+--------------------------------|
| *Notes* | - |
|---------------------+--------------------------------|
| *UC History* | 1.0 Darft erstellt durch AZ |
|---------------------+--------------------------------|
| *Author* | A. Zweili & I. Hörler |
|---------------------+--------------------------------|
| *Date* | 16.01.2018 |
|---------------------+--------------------------------|
2018-01-18 19:58:47 +01:00
#+LATEX :}
2018-01-17 22:07:17 +01:00
***** Artikel in Warenkorb legen
2018-01-18 19:58:47 +01:00
#+LATEX :{\footnotesize
2018-01-17 22:07:17 +01:00
#+CAPTION : Use Case 3.0 Artikel in Warenkorb legen
2018-01-18 19:58:47 +01:00
#+ATTR_LATEX : :environment longtable :align |>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}| :placement [H]
2018-01-17 22:07:17 +01:00
#+NAME : tab:cart
|---------------------+--------------------------------|
| | <30> |
| *Identifier + Name* | 3.0 Artikel in Warenkorb legen |
|---------------------+--------------------------------|
| *Description* | Ein Kunde legt einen Artikel in den Warenkorb. |
|---------------------+--------------------------------|
| *Actors* | Kunde |
|---------------------+--------------------------------|
| *Status* | Freigeben |
|---------------------+--------------------------------|
| *Includes* | - |
|---------------------+--------------------------------|
| *Trigger* | Ein Kunde möchte einen Artikel kaufen. |
|---------------------+--------------------------------|
| *Preconditions* | UC2.1 erfolgreich abgeschlossen. |
|---------------------+--------------------------------|
| *Postconditions* | Artikel wurde im Warenkorb gespeichert. |
|---------------------+--------------------------------|
| *Normal Flow* | 1. User klickt einen Artikel an. |
| | 2. User klickt auf "Add to cart". |
| | 3. Die Website speichert den Artikel im Warenkorb. |
|---------------------+--------------------------------|
| *Alternative Flow* | 1. User klickt einen Artikel mit Stock "0.0" an. |
| | 2. User klickt auf "Add to cart". |
| | 3. Die Website meldet "We are sorry but this item is out of stock.". |
|---------------------+--------------------------------|
| *Notes* | - |
|---------------------+--------------------------------|
| *UC History* | 1.0 Darft erstellt durch AZ |
|---------------------+--------------------------------|
| *Author* | A. Zweili & I. Hörler |
|---------------------+--------------------------------|
| *Date* | 16.01.2018 |
|---------------------+--------------------------------|
2018-01-18 19:58:47 +01:00
#+LATEX :}
2018-01-17 22:07:17 +01:00
***** Währung ändern
2018-01-18 19:58:47 +01:00
#+LATEX :{\footnotesize
2018-01-17 22:07:17 +01:00
#+CAPTION : Use Case 3.1 Währung ändern
2018-01-18 19:58:47 +01:00
#+ATTR_LATEX : :environment longtable :align |>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}| :placement [H]
2018-01-17 22:07:17 +01:00
#+NAME : tab:currency
|---------------------+--------------------------------|
| | <30> |
| *Identifier + Name* | 3.1 Währung ändern |
|---------------------+--------------------------------|
| *Description* | Ein User ändert die Währung für die Preise. |
|---------------------+--------------------------------|
| *Actors* | Kunde, Interessent |
|---------------------+--------------------------------|
| *Status* | Freigeben |
|---------------------+--------------------------------|
| *Includes* | - |
|---------------------+--------------------------------|
| *Trigger* | Ein User möchte sich die Preise in einer anderen Währung anzeigen lassen. |
|---------------------+--------------------------------|
| *Preconditions* | - |
|---------------------+--------------------------------|
| *Postconditions* | Die Preise werden in der gewünschten Währung angezeigt. |
|---------------------+--------------------------------|
| *Normal Flow* | 1. Der User wählt im Drop-Down die gewünschte Währung aus. |
| | 2. Die Website aktualisiert und zeigt die neu berechneten Preise an. |
|---------------------+--------------------------------|
| *Alternative Flow* | - |
|---------------------+--------------------------------|
| *Notes* | - |
|---------------------+--------------------------------|
| *UC History* | 1.0 Darft erstellt durch AZ |
|---------------------+--------------------------------|
| *Author* | A. Zweili & I. Hörler |
|---------------------+--------------------------------|
| *Date* | 16.01.2018 |
|---------------------+--------------------------------|
2018-01-18 19:58:47 +01:00
#+LATEX :}
2018-01-17 22:07:17 +01:00
***** Checkout
2018-01-18 19:58:47 +01:00
#+LATEX :{\footnotesize
2018-01-17 22:07:17 +01:00
#+CAPTION : Use Case 3.2 Checkout
2018-01-18 19:58:47 +01:00
#+ATTR_LATEX : :environment longtable :align |>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}| :placement [H]
2018-01-17 22:07:17 +01:00
#+NAME : tab:checkout
|---------------------+--------------------------------|
| | <30> |
| *Identifier + Name* | 3.2 Checkout |
|---------------------+--------------------------------|
| *Description* | User gibt seinen Warenkorb als Bestellung auf. |
|---------------------+--------------------------------|
| *Actors* | Kunde |
|---------------------+--------------------------------|
| *Status* | Freigeben |
|---------------------+--------------------------------|
| *Includes* | - |
|---------------------+--------------------------------|
| *Trigger* | Ein Kunde möchte seine Artikel im Warenkorb bestellen. |
|---------------------+--------------------------------|
| *Preconditions* | UC2.1 und UC3.0 erfolgreich abgeschlossen. |
|---------------------+--------------------------------|
| *Postconditions* | Die Bestellung wurde von der Website gespeichert. |
|---------------------+--------------------------------|
| *Normal Flow* | 1. Der User klickt in der Navigation auf "Cart". |
| | 2. Die Website leitet ihn zum Warenkorb um. |
| | 3. Der User klickt dort auf "Checkout". |
| | 4. Die Website gibt ihm eine komplette Übersicht der Bestellung sowie der Empfängeradresse. |
| | 5. User klickt auf "Send order". |
|---------------------+--------------------------------|
| *Alternative Flow* | 1. Der User klickt in der Navigation auf "Cart". |
| | 2. Die Website leitet ihn zum Warenkorb um. |
| | 3. Der User klickt dort auf "Checkout". |
| | 4. Die Website gibt ihm eine komplette Übersicht der Bestellung sowie der Empfängeradresse. |
| | 5. Der User bricht die Bestellung mit Klick auf "Cancel" ab. |
|---------------------+--------------------------------|
| *Notes* | - |
|---------------------+--------------------------------|
| *UC History* | 1.0 Darft erstellt durch AZ |
|---------------------+--------------------------------|
| *Author* | A. Zweili & I. Hörler |
|---------------------+--------------------------------|
| *Date* | 16.01.2018 |
|---------------------+--------------------------------|
2018-01-18 19:58:47 +01:00
#+LATEX :}
2018-01-17 22:07:17 +01:00
***** User Passwort ändern
2018-01-18 19:58:47 +01:00
#+LATEX :{\footnotesize
2018-01-17 22:07:17 +01:00
#+CAPTION : 4.0 User Passwort ändern
2018-01-18 19:58:47 +01:00
#+ATTR_LATEX : :environment longtable :align |>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}| :placement [H]
2018-01-17 22:07:17 +01:00
#+NAME : tab:password
|---------------------+--------------------------------|
| | <30> |
| *Identifier + Name* | 4.0 User Passwort ändern |
|---------------------+--------------------------------|
| *Description* | Ein Administrator ändert ein User Kennwort. |
|---------------------+--------------------------------|
| *Actors* | Verwaltung |
|---------------------+--------------------------------|
| *Status* | Freigeben |
|---------------------+--------------------------------|
| *Includes* | - |
|---------------------+--------------------------------|
| *Trigger* | Ein Administrator möchte ein Passwort zurücksetzen weil es vergessen wurde. |
|---------------------+--------------------------------|
| *Preconditions* | Account mit Administrationsrechten vorhanden. |
|---------------------+--------------------------------|
| *Postconditions* | Auf dem User Account wurde ein neues Passwort gesetzt. |
|---------------------+--------------------------------|
| *Normal Flow* | 1. Der Administrator loggt sich unter https://didgeridoo.ml/admin ein. |
| | 2. Admin klickt auf "Users". |
| | 3. Admin wählt den passenden Account aus. |
| | 4. Klickt unterhalb des Passwort Hashes auf "this form". |
| | 5. Gibt zweimal das neue Passwort ein und klickt "Change password". |
| | 6. Die Website leitet den Admin zurück zu den User Details. |
|---------------------+--------------------------------|
| *Alternative Flow* | 1. Der Administrator loggt sich unter https://didgeridoo.ml/admin ein. |
| | 2. Admin klicht auf "Users". |
| | 3. Admin wählt den passenden Account aus. |
| | 4. Klickt unterhalb des Passwort Hashes auf "this form". |
| | 5. Gibt zweimal ein invalides Passwort ein und klickt "Change password". |
| | 6. Die Website gibt eine entsprechende Fehlermeldung aus. |
| | 7. Der Admin korrigiert die Passwörter und klickt auf "Change password". |
| | 8. Die Website leitet den Admin zurück zu den User Details. |
|---------------------+--------------------------------|
| *Notes* | - |
|---------------------+--------------------------------|
| *UC History* | 1.0 Darft erstellt durch AZ |
|---------------------+--------------------------------|
| *Author* | A. Zweili & I. Hörler |
|---------------------+--------------------------------|
| *Date* | 16.01.2018 |
|---------------------+--------------------------------|
2018-01-18 19:58:47 +01:00
#+LATEX :}
2018-01-17 22:07:17 +01:00
***** Artikel erfassen
2018-01-18 19:58:47 +01:00
#+LATEX :{\footnotesize
2018-01-17 22:07:17 +01:00
#+CAPTION : 5.0 Artikel erfassen
2018-01-18 19:58:47 +01:00
#+ATTR_LATEX : :environment longtable :align |>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}| :placement [H]
2018-01-17 22:07:17 +01:00
#+NAME : tab:create_article
|---------------------+--------------------------------|
| | <30> |
| *Identifier + Name* | 5.0 Artikel erfassen |
|---------------------+--------------------------------|
| *Description* | Ein Administrator erfasst einen neuen Artikel mit Bildern. |
|---------------------+--------------------------------|
| *Actors* | Verwaltung |
|---------------------+--------------------------------|
| *Status* | Freigeben |
|---------------------+--------------------------------|
| *Includes* | - |
|---------------------+--------------------------------|
| *Trigger* | Um das Sortiment zu erweitern möchte der Administrator einen neuen Artikel erfassen. |
|---------------------+--------------------------------|
| *Preconditions* | Account mit Administrationsrechten vorhanden. |
|---------------------+--------------------------------|
| *Postconditions* | Der Artikel wir im Webshop angezeigt. |
|---------------------+--------------------------------|
| *Normal Flow* | 1. Der Administrator loggt sich unter https://didgeridoo.ml/admin ein. |
| | 2. Admin klickt neben "Articles" auf "+ Add". |
| | 3. Admin füllt das Formular aus und lädt ein Bild hoch. |
| | 4. Klickt unten rechts auf "Save". |
| | 5. Die Website speichert den Artikel in der Datenbank. |
|---------------------+--------------------------------|
| *Alternative Flow* | 1. Der Administrator loggt sich unter https://didgeridoo.ml/admin ein. |
| | 2. Admin klickt neben "Articles" auf "+ Add". |
2018-01-18 19:59:07 +01:00
| | 3. Admin füllt das Formular aus und lädt zuviele Bilder hoch. |
2018-01-17 22:07:17 +01:00
| | 4. Klickt unten rechts auf "Save". |
| | 5. Die Website gibt eine entsprechende Fehlermeldung aus. |
2018-01-18 19:59:07 +01:00
| | 6. Der Admin entfernt die überzähligen Bilder. |
2018-01-17 22:07:17 +01:00
| | 7. Die Website speichert den Artikel in der Datenbank. |
|---------------------+--------------------------------|
| *Notes* | - |
|---------------------+--------------------------------|
| *UC History* | 1.0 Darft erstellt durch AZ |
|---------------------+--------------------------------|
| *Author* | A. Zweili & I. Hörler |
|---------------------+--------------------------------|
| *Date* | 16.01.2018 |
|---------------------+--------------------------------|
2018-01-18 19:58:20 +01:00
#+LATEX :}
***** max_pictures Option anpassen
#+LATEX :{\footnotesize
#+CAPTION : Use Case 6.0 max_pictures Option anpassen
#+ATTR_LATEX : :environment longtable :align |>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}| :placement [H]
#+NAME : tab:max_pictures
|---------------------+--------------------------------|
| | <30> |
| *Identifier + Name* | 6.0 max_pictures Option anpassen |
|---------------------+--------------------------------|
| *Description* | Ein Administrator ändert die max_pictures Option. |
|---------------------+--------------------------------|
| *Actors* | Verwaltung |
|---------------------+--------------------------------|
| *Status* | Freigeben |
|---------------------+--------------------------------|
| *Includes* | - |
|---------------------+--------------------------------|
| *Trigger* | Ein Administrator möchte die maximale Anzahl Bilder pro Artikel anpassen. |
|---------------------+--------------------------------|
| *Preconditions* | Account mit Administrationsrechten vorhanden. |
|---------------------+--------------------------------|
| *Postconditions* | Der neue Wert wurde von der Website gespeichert. |
|---------------------+--------------------------------|
| *Normal Flow* | 1. Der Administrator loggt sich unter https://didgeridoo.ml/admin ein. |
| | 2. Admin klickt auf "Options" und anschliessend auf "max_pictures". |
| | 3. Admin ändert den Wert "Value" zu einer Ganzzahl seiner Wahl. |
| | 4. Klickt unten rechts auf "Save". |
| | 5. Die Website speichert den Wert in der Datenbank. |
|---------------------+--------------------------------|
| *Alternative Flow* | 1. Der Administrator loggt sich unter https://didgeridoo.ml/admin ein. |
| | 2. Admin klickt auf "Options" und anschliessend auf "max_pictures". |
| | 3. Admin ändert den Wert "Value" zu einer Gleitzahl seiner Wahl. |
| | 4. Klickt unten rechts auf "Save". |
| | 5. Die Website gibt eine entsprechende Fehlermeldung aus. |
| | 6. Der Admin korrigiert den Wert und klickt "Save". |
| | 7. Die Website speichert den Wert in der Datenbank. |
|---------------------+--------------------------------|
| *Notes* | - |
|---------------------+--------------------------------|
| *UC History* | 1.0 Darft erstellt durch AZ |
|---------------------+--------------------------------|
| *Author* | A. Zweili & I. Hörler |
|---------------------+--------------------------------|
| *Date* | 16.01.2018 |
|---------------------+--------------------------------|
#+LATEX :}
***** Bestellung ändern/korrigieren
#+LATEX :{\footnotesize
#+CAPTION : Use Case 7.0 Bestellung ändern/korrigieren
#+ATTR_LATEX : :environment longtable :align |>{\columncolor[HTML]{EFEFEF}}p{.25\textwidth}|p{.7\textwidth}| :placement [H]
#+NAME : tab:change_order
|---------------------+--------------------------------|
| | <30> |
| *Identifier + Name* | 7.0 Bestellung ändern/korrigieren |
|---------------------+--------------------------------|
| *Description* | Ein Administrator korrigiert eine Bestellung. |
|---------------------+--------------------------------|
| *Actors* | Verwaltung |
|---------------------+--------------------------------|
| *Status* | Freigeben |
|---------------------+--------------------------------|
| *Includes* | - |
|---------------------+--------------------------------|
| *Trigger* | Administrator ändert auf Wunsch eines Kunden eine Bestellung. |
|---------------------+--------------------------------|
| *Preconditions* | Account mit Administrationsrechten vorhanden. |
|---------------------+--------------------------------|
| *Postconditions* | Die Bestellung hat eine angepasste Artikel Menge. |
|---------------------+--------------------------------|
| *Normal Flow* | 1. Der Administrator loggt sich unter https://didgeridoo.ml/admin ein. |
| | 2. Admin klickt auf "Orders" und anschliessend auf die passende Order ID. |
| | 3. Admin ändert den Wert "Amount" des ersten Artikels zu 0. |
| | 4. Klickt unten rechts auf "Save". |
| | 5. Die Website speichert die Bestellung in der Datenbank. |
|---------------------+--------------------------------|
| *Alternative Flow* | - |
|---------------------+--------------------------------|
| *Notes* | - |
|---------------------+--------------------------------|
| *UC History* | 1.0 Darft erstellt durch AZ |
|---------------------+--------------------------------|
| *Author* | A. Zweili & I. Hörler |
|---------------------+--------------------------------|
| *Date* | 16.01.2018 |
|---------------------+--------------------------------|
#+LATEX :}
2018-01-05 15:04:33 +01:00
2018-02-07 20:36:18 +01:00
*** Models
2018-01-16 22:32:02 +01:00
2018-01-29 22:28:02 +01:00
Wie bereits in [[Framework ]] beschrieben übernimmt das Framework die
2018-02-06 22:02:57 +01:00
Erstellung der Tabellen in der Datenbank. Für den Aufbau der Anwendung
und der Kommunikation im Team ist es jedoch von absoluter
Notwendigkeit das man sich über die Beziehung zwischen den Objekten
Gedanken macht. Insbesondere wenn die Anwendung nach wie vor auf einer
relationalen Datenbank basiert. Aus diesem Grund haben wir vor Beginn
der Arbeit ein klassisches Entity Relation Diagramm aufgezeichnet.
Während der Entwicklung haben wir es dann kontinuierlich erweitert und
korrigiert. Das finale Ergebnis ist in der Abbildung:([[fig:erd ]]) zu sehen.
2018-01-29 22:28:02 +01:00
erstellt haben.
2018-02-07 20:36:18 +01:00
Django übernimmt dann jedoch das erstellen der Tabellen und benennen
derjenigen weshalb das Resultat in der Datenbank dann etwas anders
aussieht. Zusätzlich kommt Django auch noch mit eigenen Tabellen
daher. Der finale Aufbau der Datenbank ist in der
Abbildung:([[fig:final_erd ]]) zu sehen. Dieses ERD wurde mit der Django
Erweiterung "Djangoextensions"\footcite{djangoextensions} erstellt.
Nachfolgend werden wir die von uns erstellten Modells im Detail
beschreiben und auf jeweils spezifische Probleme eingehen.
2018-01-29 22:28:02 +01:00
#+LATEX :\newpage
#+LATEX :\begin{landscape}
#+ATTR_LATEX : :height.9\textwidth
#+CAPTION : Entity Relation Diagramm
#+NAME : fig:erd
[[file:diagrammes/erd.eps ]]
#+LATEX :\end{landscape}
#+LATEX :\newpage
#+LATEX :\newpage
#+LATEX :\begin{landscape}
#+ATTR_LATEX : :height.9\textheight
2018-02-06 22:02:57 +01:00
#+CAPTION : Django Datenbank Aufbau
2018-01-29 22:28:02 +01:00
#+NAME : fig:final_erd
[[file:diagrammes/final_erd.png ]]
#+LATEX :\end{landscape}
#+LATEX :\newpage
2018-02-01 21:59:58 +01:00
**** Category
2017-12-03 16:52:15 +01:00
2018-02-01 21:59:58 +01:00
Das "Category" Modell, Abbildung:([[fig:category ]]) ist der Kernpunkt der
Artikelnavigation und vom Aufbau her eigentlich eher simpel.
Allerdings hatten wir etwas Mühe die hierarchische Darstellung im
Template sauber abzubilden. Hier half uns ein Artikel\footcite{tree}
von Stackoverflow auf die richtige Lösung zu kommen. Nämlich das sich
das ganze um zwei in einander verschachtelte Dictionaries handelt.
Somit konnten wir dann über die Kategorie iterieren.
2018-01-16 22:32:02 +01:00
2018-01-16 22:30:51 +01:00
#+ATTR_LATEX : :width 9cm :placement [H]
2017-12-03 16:52:15 +01:00
#+CAPTION : Klassenmodel für Kategorien
2018-01-05 15:04:33 +01:00
#+NAME : fig:category
2018-02-07 20:44:34 +01:00
[[file:pictures/class_category.png ]]
2017-12-03 16:52:15 +01:00
2018-02-01 21:59:58 +01:00
**** Option
Gemäss der Anforderung FA\_1.4 muss es möglich sein für einen Artikel 0-5
Bilder hochzuladen. Wir stellen dies über eine Variabel im "Option"
Modell, Abbildung:([[fig:option ]]), sicher gegen welche beim Speichern
überprüft wird. Die Variabel ist als Option im Admin Interface
hinterlegt. Dadurch ist es möglich den Wert auch nachträglich
noch zu ändern oder ganz zu deaktivieren.
Da diese Variabel jedoch essentiell für die Funktion des Webshops ist
mussten wir sicherstellen das sie von einem Administrator nicht aus
Versehen gelöscht oder umbenannt wird. Des weiteren macht es in der
Applikation im Momentan wenig Sinn wenn der User selber Optionen
hinzufügen kann. Aus diesen Gründen haben wir für das "Option" Modell
den "Add" Button\footcite{removeadd} und die "Delete"
Option\footcite{removedelete} entfernt sowie den Namen im Admin
Interface nur lesbar gemacht\footcite{readonly}. Somit ist nun nur
noch der Wert editierbar.
2018-01-16 22:32:02 +01:00
2018-01-16 22:30:51 +01:00
#+ATTR_LATEX : :width 9cm :placement [H]
2017-12-03 16:52:15 +01:00
#+CAPTION : Klassenmodel für Optionen
2018-01-05 15:04:33 +01:00
#+NAME : fig:option
2018-02-07 20:44:34 +01:00
[[file:pictures/class_option.png ]]
2017-12-03 16:52:15 +01:00
2018-02-01 21:59:58 +01:00
**** ArticleStatus
Das Modell "ArticleStatus", Abbildung:([[fig:articlestatus ]]), wird über
einen Fremdschlüssel mit dem "Article" Modell verbunden und gibt
diesem verschiedene Status. Gemäss der Anforderung FA\_1.4 muss ein
Artikel die Status "active" und "hidden" haben. Wir haben dies in der
Applikation dann auch gleich so umgesetzt das nur die Artikel
angezeigt werden welche nicht den Status "hidden" haben.
2017-12-03 16:52:15 +01:00
2018-01-16 22:30:51 +01:00
#+ATTR_LATEX : :width 9cm :placement [H]
2017-12-03 16:52:15 +01:00
#+CAPTION : Klassenmodel für Artikelstatus
2018-01-05 15:04:33 +01:00
#+NAME : fig:articlestatus
2018-02-07 20:44:34 +01:00
[[file:pictures/class_articlestatus.png ]]
2017-12-03 16:52:15 +01:00
2018-02-01 21:59:58 +01:00
**** ExchangeRate
2017-12-03 16:52:15 +01:00
2018-02-01 21:59:58 +01:00
Wir legen die Wechselkurse im Modell "ExchangeRate",
Abbildung:([[fig:exchangerate ]]), ab. Um Manipulationen aufs Datum und den
Namen einfacher zu machen werden diese beiden Attribute als
Fremdschlüssel hinterlegt. Die Wechselkurse werden dabei aus dem RSS
Feed\footcite{snb} der Schweizerischen Nationalbank stündlich
abgeholt. Vor dem Ablegen in der Datenbank wird dann noch überprüft ob
sich die Werte geändert haben oder nicht.
Wir haben uns für den die Daten der SNB entschieden da sie einerseits
die benötigten Wechselkurse anbieten und anderseit bereits von unserer
Basiswährung CHF ausgehen. Dadurch müssen wir nicht zuerst aus einer
anderen Währung zurückrechnen.
2018-01-16 22:32:02 +01:00
2018-01-16 22:30:51 +01:00
#+ATTR_LATEX : :width 9cm :placement [H]
2017-12-03 16:52:15 +01:00
#+CAPTION : Klassenmodel für Wechselkurse
2018-01-05 15:04:33 +01:00
#+NAME : fig:exchangerate
2018-02-07 20:44:34 +01:00
[[file:pictures/class_exchangerate.png ]]
2017-12-03 16:52:15 +01:00
2018-02-06 22:02:57 +01:00
**** ExchangeRate_name
2018-02-01 21:59:58 +01:00
Im Modell ExchangeRate_name, Abbildung:([[fig:exchangerate_name ]]), ist nur
eine Liste mit allen möglichen Währungsnamen abgelegt.
#+ATTR_LATEX : :width 9cm :placement [H]
#+CAPTION : Klassenmodel für Wechselkurse
#+NAME : fig:exchangerate_name
2018-02-06 22:02:57 +01:00
[[file:pictures/exchangerate_name.png ]]
2018-02-01 21:59:58 +01:00
2018-02-06 22:02:57 +01:00
**** ExchangeRate_date
2018-02-01 21:59:58 +01:00
Damit die Wechselkurse des Tages einfacher auf einer Zeile angezeigt
werden können haben wir das Datum in ein eigenes Modell,
Abbildung:([[fig:exchangerate_date ]]), ausgelagert. Dabei wird das Datum
als Standardwert mitgegeben. Wir hatten dies zu Beginn noch falsch
implementiert und das Datum als Funktion übergeben. Das führte jedoch
dazu, dass die Funktion einmal beim Starten des Servers ausgeführt
wurde und alle Wechselkurse immer das gleiche Datum hatten. Auf
Stackoverflow fanden wir dann die Lösung\footcite{timezone} das wir
die Datumsfunktion als Variabel übergeben müssen damit sie bei jedem
Erstellen des Objekt evaluiert wird.
#+ATTR_LATEX : :width 9cm :placement [H]
#+CAPTION : Klassenmodel für Wechselkurse
#+NAME : fig:exchangerate_date
2018-02-06 22:02:57 +01:00
[[file:pictures/exchangerate_date.png ]]
2018-02-01 21:59:58 +01:00
**** Article
Das Modell "Article", Abbildung([[fig:article ]]), ist als solches nicht
sehr komplex und widerspiegelt einen Artikel aus der realen Welt.
Gemäss der Anforderung FA\_1.4 hat er eine eindeutige ID (den
Primärschlüssel), einen Namen von maximal 200 Zeichen, eine
Beschreibung von maximal 2000 Zeichen, Status sowie 0 - 5
Produktbilder.
2017-12-03 16:52:15 +01:00
2018-01-16 22:30:51 +01:00
#+ATTR_LATEX : :width 9cm :placement [H]
2017-12-03 16:52:15 +01:00
#+CAPTION : Klassenmodel für Artikel
2018-01-05 15:04:33 +01:00
#+NAME : fig:article
2018-02-07 20:44:34 +01:00
[[file:pictures/class_article.png ]]
2017-12-03 16:52:15 +01:00
2018-02-01 21:59:58 +01:00
**** OrderStatus
Damit nachvollzogen werden kann in welchen Zustand sich eine
Bestellung gerade befindet haben wir ein Modell "OrderStatus",
Abbildung:([[fig:orderstatus ]]), erstellt. Für dieses Modell sind folgende
Status angedacht:
- ordered -> vom Kunden bestellt
- delivered -> Bestellung wurde versandt
- cancelled -> Bestellung storniert
- on hold -> Bestellung pausiert
2017-12-03 16:52:15 +01:00
2018-02-06 22:02:57 +01:00
Der "OrderStatus" wird vom "Order" sowie auch dem "OrderOfGoods" Modell
verwendet.
2018-01-16 22:30:51 +01:00
#+ATTR_LATEX : :width 9cm :placement [H]
2017-12-03 16:52:15 +01:00
#+CAPTION : Klassenmodel für Bestellstatus
2018-01-05 15:04:33 +01:00
#+NAME : fig:orderstatus
2018-02-07 20:44:34 +01:00
[[file:pictures/class_orderstatus.png ]]
2017-12-03 16:52:15 +01:00
2018-02-06 22:02:57 +01:00
**** OrderOfGoods
Das Modell "OrderOfGoods", Abbildung:([[fig:orderofgoods ]]), bildet die
Nachbestellungen fürs Warenlager ab. Dabei wird es hauptsächlich für
die Verwaltung verwendet um die Nachbestellungen im Griff zu haben.
2017-12-03 16:52:15 +01:00
2018-01-16 22:30:51 +01:00
#+ATTR_LATEX : :width 9cm :placement [H]
2017-12-03 16:52:15 +01:00
#+CAPTION : Klassenmodel für Warenbestellungen
2018-01-05 15:04:33 +01:00
#+NAME : fig:orderofgoods
2018-02-07 20:44:34 +01:00
[[file:pictures/class_orderofgoods.png ]]
2017-12-03 16:52:15 +01:00
2018-02-06 22:02:57 +01:00
**** Picture
2017-12-03 16:52:15 +01:00
2018-02-06 22:02:57 +01:00
Über das Modell "Picture", Abbildung:([[fig:picture ]]) können Bilder für
einen Artikel hochgeladen werden. Grundsätzlich kann man Bilder
relativ einfach über das Attribut "models.ImageField" zu einem Modell
hinzufügen. Wir hatten allerdings noch einige Probleme mit dem
Konfigurieren von Django damit der Upload funktionierte und wir die
Bilder in den Templates verwenden konnten. Die Lösungen für den Upload
fanden wir in einem Stackoverflow Post\footcite{upload}. Auch für das
verwenden der Bilder in den Templates fanden wir in einem Post auf
Stackoverflow\footcite{images} die Lösung.
2018-01-16 22:32:02 +01:00
2018-01-16 22:30:51 +01:00
#+ATTR_LATEX : :width 9cm :placement [H]
2017-12-03 16:52:15 +01:00
#+CAPTION : Klassenmodel für Bilder
2018-01-05 15:04:33 +01:00
#+NAME : fig:picture
2018-02-07 20:44:34 +01:00
[[file:pictures/class_picture.png ]]
2017-12-03 16:52:15 +01:00
2018-02-06 22:02:57 +01:00
**** Order und OrderPosition
Bestellungen der Kunden werden im Modell "Order",
Abbildung:([[fig:order ]]), erfasst. Wobei im Modell Order nur die Kunden
2018-02-07 19:01:37 +01:00
ID gespeichert wird, sowie, gemäss der Anforderung FA\_3.3, der
Foreign Key zum "ExchangeRate" Modell. Über den Foreign Key wird eine
Beziehung auf den für die Bestellung aktuellen Wechselkurs der Währung
hergestellt.
Da sich bei der Beziehung zwischen den Artikeln und dem Kunden um eine
"Viele zu Viele" Beziehung handelt braucht es noch ein zusätzliches
Modell welches die Beziehung abbildet. Dies realisieren wir über das
Modell "OrderPostion", Abbildung:([[fig:orderposition ]]).
2018-02-06 22:02:57 +01:00
In diesem Modell werden dann noch zusätzlich die bestellte Menge sowie
2018-02-07 19:01:37 +01:00
der Preis zur Zeit der Bestellung in schweizer Franken des jeweiligen
Artikels erfasst. Somit kann auch später noch nachvollzogen werden zu
welchem Preis die Ware bezogen wurde.
2017-12-03 16:52:15 +01:00
2018-01-16 22:30:51 +01:00
#+ATTR_LATEX : :width 9cm :placement [H]
2017-12-03 16:52:15 +01:00
#+CAPTION : Klassenmodel für Bestellungen
2018-01-05 15:04:33 +01:00
#+NAME : fig:order
2018-02-07 20:44:34 +01:00
[[file:pictures/class_order.png ]]
2017-12-03 16:52:15 +01:00
2018-02-06 22:02:57 +01:00
#+ATTR_LATEX : :width 9cm :placement [H]
#+CAPTION : Klassenmodel für Bestellungens Positionen
#+NAME : fig:orderposition
[[file:pictures/class_orderposition.png ]]
**** ShoppingCart und ShoppingCartPosition
2017-12-03 16:52:15 +01:00
2018-02-06 22:28:07 +01:00
Bevor die Bestellungen erfasst werden kann der Kunde die Artikel in
einem Warenkorb sammeln. Dieser funktioniert sehr ähnlich wie die
Bestellungen. Über das Modell "ShoppingCart",
Abbildung:([[fig:shoppingcart ]]), und das Modell "ShoppingCartPosition",
Abbildung:([[fig:shoppingcartposition ]]), werden die ausgewählten Artikel
sowie ihre Mengen einem User zugewiesen. Im Gegensatz zur Bestellung
wird im Artikel jedoch der Preis nicht gespeichert da sich der Preis
2018-02-07 19:01:37 +01:00
vor der Bestellung noch ändern könnte. Wenn die Verwaltung etwa die
Preise anpasst oder die Währungen den Kurs ändern.
2018-02-06 22:28:07 +01:00
2018-01-16 22:30:51 +01:00
#+ATTR_LATEX : :width 9cm :placement [H]
2017-12-03 16:52:15 +01:00
#+CAPTION : Klassenmodel für Warenkörbe
2018-01-05 15:04:33 +01:00
#+NAME : fig:shoppingcart
2018-02-07 20:44:34 +01:00
[[file:pictures/class_shoppingcart.png ]]
2017-12-03 16:52:15 +01:00
2018-02-06 22:28:07 +01:00
#+ATTR_LATEX : :width 9cm :placement [H]
#+CAPTION : Klassenmodel für Warenkorbs Positionen
#+NAME : fig:shoppingcartposition
2018-02-07 20:44:34 +01:00
[[file:pictures/class_shoppingcartposition.png ]]
2018-02-06 22:28:07 +01:00
2018-02-07 20:20:57 +01:00
**** City
Das "City" Modell speichert Städte Namen und die dazugehörige
Postleizahl. Die Städte werden als Teil der Adresse auf dem "Person"
Modell hinterlegt. Im aktuellen Zustand der Applikation enthält die
Tabelle die Daten aller schweizer Städte.
2017-12-03 16:52:15 +01:00
2018-01-16 22:30:51 +01:00
#+ATTR_LATEX : :width 9cm :placement [H]
2017-12-03 16:52:15 +01:00
#+CAPTION : Klassenmodel für Städte
2018-01-05 15:04:33 +01:00
#+NAME : fig:city
2018-02-07 20:44:34 +01:00
[[file:pictures/class_city.png ]]
2017-12-03 16:52:15 +01:00
2018-02-07 20:20:57 +01:00
**** Salutation
"Salutation", zu Deutsch Anrede, ist das Modell welches die möglichen
Anreden beinhaltet die ein User für sich hinterlegen kann.
Für den Moment haben wir die folgenden Auswahlmöglichkeiten
hinterlegt:
- Herr
- Frau
- Dr.
2017-12-03 16:52:15 +01:00
2018-01-16 22:30:51 +01:00
#+ATTR_LATEX : :width 9cm :placement [H]
2017-12-03 16:52:15 +01:00
#+CAPTION : Klassenmodel für Anreden
2018-01-05 15:04:33 +01:00
#+NAME : fig:salutation
2018-02-07 20:44:34 +01:00
[[file:pictures/class_salutation.png ]]
2017-12-03 16:52:15 +01:00
2018-02-07 20:20:57 +01:00
**** Person
Das "Person" Modell dient dazu Informationen über einen User zu
speichern die nicht relevant sind für die Authentifizierung.
Es gibt mehrere Möglichkeiten wie man das "User" Modell in Django
erweitern kann. In einem Post\footcite{usermodel} von Vitor Freitas
werden die möglichen vier Varianten aufgeführt und erklärt. Eine davon
ist nicht dafür gemacht zusätzliche Informationen zu speichern. Zwei
weitere Varianten bauen darauf auf von einer Basis "User" Klasse
abzuleiten. Die erste Variante war für unsere Zwecke nicht geeignet da
wir zwingend zusätzliche Informationen speichern wollten. Die
Varianten mit Vererbungen erschienen uns ungeeignet da die Möglichkeit
besteht die Sicherheit der Authentifizierung zu schwächen. Aus diesem
Grund wird in der Django Dokumentation eher davor abgeraten diese
Varianten wenn man nicht genau weiss was man macht.
Die verbeiblende Variante erweitert das "User" Modell über eine
"One-to-One" Beziehung ein sogenanntes "Profil". Dadurch bleibt das
"User" Modell intakt und man kann zusätzliche Informationen über den
User speichern. Man sollte im Profil jedoch nur Daten speichern welche
nicht sicherheitsrelevant sind. Der Nachteil dieser Variante ist das
die Datenbank mit zusätzlichen Anfragen belastet werden kann.
2018-01-16 22:32:02 +01:00
2018-01-16 22:30:51 +01:00
#+ATTR_LATEX : :width 9cm :placement [H]
2017-12-03 16:52:15 +01:00
#+CAPTION : Klassenmodel für Personen
2018-01-05 15:04:33 +01:00
#+NAME : fig:person
2018-02-07 20:44:34 +01:00
[[file:pictures/class_person.png ]]
2017-11-05 11:42:31 +01:00
2017-10-30 22:17:17 +01:00
** Benutzerinterface
2018-02-17 15:59:48 +01:00
*** Mockup skizze
#+CAPTION : Ein frühes Mockup des Shop
#+ATTR_LATEX : :width \textwidth
#+NAME : mockup
[[file:pictures/mockup-full-snipet.png ]]
#+LATEX :\newpage
2017-10-30 22:17:17 +01:00
*** Frontend Umsetzung
2018-02-17 15:59:48 +01:00
Die Umsetztung des Frontends mittels Django integrierter Template
funktionen sind geprägt vom einstmalig eigenständigen Jinja Template
framework das auch in Python programmiert wurde. Mittlerweile ist es
integrierter bestandteil vom django Framework.
Dieses snipet erklärt deren Nutzung:
#+CAPTION : jinja Code Block
#+BEGIN_SRC python
{% extends 'base.html' %} --> Dieser codeblock wird im base.html eingefügt.
{% block title %}Memberlist{% endblock %} --> Titel wird in den tag
title eingefügt.
{% block content %} --> wird in den block mit dem tag ''content'' eingefügt.
<ul > --> standard unordered List item von HTML.
{% for user in users %} --> schleifenkopf
<li >
<a href="{{ user.url }}" >{{ user.username }}</a > --> für
jeden Benutzer wird eine listitem erstellt und der Username als text eingefügt.
</li >
{% endfor %}
</ul >
{% endblock %}
#+END_SRC
2017-10-30 22:17:17 +01:00
*** Backend Umsetzung
2018-01-05 15:04:33 +01:00
2018-02-17 15:59:48 +01:00
Django ist ein Modelbasiertes Framework das die Programmierung der
Datenbank gleich selbst regelt. Dadurch lässt sich backendseitig
durchgängig in Python arbeiten.
Die Umsetzung gliedert sich vereinfacht in 3 Bereiche:
1. Einem Frontend dass für den Benutzer gemacht ist und das mehrere
submodule wie Cathegories oder Wahrenkorb beinhaltet.
2. Ein Backend welches zum Bearbeiten/Erstellen von Produkten dient.
3. Currencies die Täglich abgeholt werden
2018-01-16 22:32:26 +01:00
** Testing
*** Fixtures
2018-01-05 15:04:33 +01:00
2018-01-07 23:46:40 +01:00
#+LATEX :\newpage
#+LATEX :\begin{landscape}
2018-01-16 22:32:26 +01:00
*** Testfälle
2018-01-05 15:04:33 +01:00
#+CAPTION : Testfälle
2018-01-16 22:32:39 +01:00
#+ATTR_LATEX : :environment longtable :align |>{\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}| :placement [H]
2018-01-05 15:04:33 +01:00
#+NAME : tab:testcases
2018-01-07 23:46:40 +01:00
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|
| <20> | <20> | <20> | <20> | <20> | <20> | <20> | <20> |
| *Testcase ID*\cellcolor[HTML]{C0C0C0} | *Objective*\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*\cellcolor[HTML]{C0C0C0} |
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|
| *TC-01* | | | | | | | |
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|
| *TC-02* | | | | | | | |
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|
| *TC-03* | | | | | | | |
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|
| *TC-04* | | | | | | | |
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|
| *TC-05* | | | | | | | |
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|
| *TC-06* | | | | | | | |
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|
| *TC-07* | | | | | | | |
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|
| *TC-08* | | | | | | | |
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|
| *TC-09* | | | | | | | |
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|
| *TC-10* | | | | | | | |
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|
| *TC-11* | | | | | | | |
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|
| *TC-12* | | | | | | | |
|----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------+----------------------|
#+LATEX :\end{landscape}
#+LATEX :\newpage
2017-10-31 21:22:50 +01:00
2017-10-30 22:17:17 +01:00
* Fazit
** Projektmanagement
** Umsetzung
** Gelerntes
2017-10-29 21:03:20 +01:00
2018-01-03 18:28:09 +01:00
* TODO samples [to be deleted] :noexport:
2017-10-29 21:03:20 +01:00
*** Subsubsection
- List
- List
- List
2017-10-30 22:50:09 +01:00
*** TODO Subsubsection
2017-10-29 21:03:20 +01:00
1. Numbered List
2. Numbered List
3. Numbered List
2017-10-30 22:50:09 +01:00
**** NEXT Subsubsubsection
Diese Section müssten man dann zuerst abschliesen damit die
übergeordnete abgeschlossen werden kann.
2017-10-29 21:03:20 +01:00
*** Table
| Name | Funktion | Beschreibung |
|------+----------+--------------|
| | | |
| | | |
| | | |
2018-02-17 15:59:48 +01:00
| | | |
2017-10-29 21:03:20 +01:00
*** Code Block
2017-10-30 07:54:24 +01:00
#+CAPTION : Python Code Block
2017-10-29 21:03:20 +01:00
#+BEGIN_SRC python
for var in collection:
while variable = True:
#+END_SRC
2017-10-30 07:54:24 +01:00
#+CAPTION : SQL Code Block
2017-10-29 21:03:20 +01:00
#+BEGIN_SRC sql
create FUNCTION functionname()
RETURNS varchar(100)
AS BEGIN
END
go
#+END_SRC
2017-10-30 22:52:41 +01:00
#+LATEX : \begin{sexylisting}{SQL Code Block}
create FUNCTION functionname()
RETURNS varchar(100)
AS BEGIN
END
go
#+LATEX : \end{sexylisting}
