From 99192728a4f385420c5d90d6f660d9893e9e14c5 Mon Sep 17 00:00:00 2001 From: Andreas Zweili Date: Thu, 1 Feb 2018 21:59:58 +0100 Subject: [PATCH] extend the documentation for models --- docs/doku.org | 113 +++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 98 insertions(+), 15 deletions(-) diff --git a/docs/doku.org b/docs/doku.org index bb39250..b03ae85 100644 --- a/docs/doku.org +++ b/docs/doku.org @@ -486,7 +486,7 @@ 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} -**** Anwendungsfalliagramm +**** Anwendungsfalldiagramm "Ein Anwendungsfalldiagramm ... ist eine der 14 Diagrammarten der Unified Modeling Language (UML), einer Sprache für die Modellierung @@ -507,7 +507,7 @@ Webshops beschränkt. #+LATEX:\end{landscape} #+LATEX:\newpage -**** Use Case Detailbeschreibung +**** Use Cases Detailbeschreibung Use Cases werden in der Regel mit Hilfe einer sogenannten Use Case Schablone im Detail beschrieben damit klar ist wie der Ablauf jeweils @@ -518,7 +518,7 @@ 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 -ausprogrammiert haben. Die gesamte Liste an Use Cases sieht wie folgt +aus programmiert haben. Die gesamte Liste an Use Cases sieht wie folgt aus, die Use Cases mit den Nummern wurden dabei im Detail ausgearbeitet: #+LATEX: {\footnotesize @@ -1030,56 +1030,139 @@ wurde mithilfe der Django Applikation Der Hauptgrund warum wir das finalle ERD durch Django haben generieren lassen ist das Django bereits mit diversen Modells und somit Tabellen daher kommt. Zum Teil auch solche wir zuvor selbst geplant hatten und unser ERD -somit nicht mehr wirklich akurat war. +somit nicht mehr wirklich akkurat war. Nachfolgend werden wir die von uns erstellten Modells im Detail beschreiben und auf jeweils spezifische Probleme eingehen. -**** NEXT Category +**** Category -\footcite{tree} +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. #+ATTR_LATEX: :width 9cm :placement [H] #+CAPTION: Klassenmodel für Kategorien #+NAME: fig:category [[./pictures/class_category.png]] +**** Option -**** NEXT 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. -\footcite{readonly} -\footcite{removeadd} -\footcite{removedelete} +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. #+ATTR_LATEX: :width 9cm :placement [H] #+CAPTION: Klassenmodel für Optionen #+NAME: fig:option [[./pictures/class_option.png]] -**** NEXT ArticleStatus +**** 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. #+ATTR_LATEX: :width 9cm :placement [H] #+CAPTION: Klassenmodel für Artikelstatus #+NAME: fig:articlestatus [[./pictures/class_articlestatus.png]] -**** TODO ExchangeRate +**** ExchangeRate -\footcite{timezone} +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. #+ATTR_LATEX: :width 9cm :placement [H] #+CAPTION: Klassenmodel für Wechselkurse #+NAME: fig:exchangerate [[./pictures/class_exchangerate.png]] -**** NEXT Article +**** NEXT ExchangeRate_name + +- Note taken on [2018-02-01 Don 21:08] \\ + Bild hinterlegen. + +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 + +**** NEXT ExchangeRate_date + +- Note taken on [2018-02-01 Don 21:08] \\ + Bild hinterlegen. + +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 + +**** 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. #+ATTR_LATEX: :width 9cm :placement [H] #+CAPTION: Klassenmodel für Artikel #+NAME: fig:article [[./pictures/class_article.png]] -**** NEXT OrderStatus +**** 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 #+ATTR_LATEX: :width 9cm :placement [H] #+CAPTION: Klassenmodel für Bestellstatus