[Task]: Layout for final presentation
This commit is contained in:
mlabusch
parent
9f879c923d
commit
15241953ce
Binary file not shown.
|
|
@ -1,25 +1,50 @@
|
|||
\section{Definition der Anforderungen}
|
||||
\label{sec: Definition der Anforderungen}
|
||||
|
||||
Der Microservice Warenwirtschaft dient der Verwaltung der einzelnen Waren pro Produkt für den Webshop Mosh, sodass zum Beispiel neue Waren erfasst und keine Waren verkauft werden können, die sich nicht mehr im Lagerbestand befinden. Dieser Microservice basiert auf den nachfolgend aufgeführten Anforderungen. Mit dem Begriff Produkt werden im Folgenden die über Mosh angebotenen Früchtearten, zum Beispiel Kiwis bezeichnet, während mit dem Begriff Ware die einzelnen Positionen pro Fruchtart im Lagerbestand bezeichnet werden.
|
||||
Der Microservice Warenwirtschaft dient der Verwaltung der Warenbestände für den Webshop Mosh. Er ermöglicht es zum Beispiel, dass neue Waren erfasst werden können und keine Waren verkauft werden, die sich nicht mehr im Warnbestand befinden. Die nachfolgende Tabelle \ref{tabl:Begriffe} definiert die hier verwendeten Begriffe, so wie sie in dem Code und innerhalb dieser Dokumentation verwendet werden.
|
||||
\begin{table}[H]
|
||||
\begin{small}
|
||||
\begin{center}
|
||||
\caption{Begriffsdefinition}
|
||||
\renewcommand{\arraystretch}{1.2}
|
||||
\begin{tabularx}{\textwidth}{|X|X|X|}
|
||||
|
||||
\hline
|
||||
|
||||
\textbf{Begriff} & \textbf{Englische Übersetzung} &\textbf{Bedeutung}\\ \hline
|
||||
|
||||
Produkt & Product & Über den Webshop angebotene Früchte- oder Gemüseart, zum Beispiel Kiwis\\ \hline
|
||||
Ware & Good & Einzelne Frucht oder einzelnes Gemüse pro Produkt (zum Beispiel eine Kiwi)\\ \hline
|
||||
Warenbestand & Stock & Anzahl der einzelnen Waren pro Produkt, die sich im Lager befinden\\ \hline
|
||||
|
||||
\end{tabularx}
|
||||
\label{tabl:Begriffe}
|
||||
\end{center}
|
||||
\end{small}
|
||||
\end{table}
|
||||
|
||||
\newpage
|
||||
Die übergeordnete Aufgabe dieses Microservice ist die Speicherung der Waren mit ihrem Lagerort sowie einem Zeitstempel, wann sie erfasst wurden. Nachfolgend werden die weiteren, detaillierten Anforderungen an diesen Microservice zusammengefasst.
|
||||
|
||||
\begin{itemize}
|
||||
\item Speicherung der Waren pro Produkt mit einem Zeitstempel, wann sie erfasst wurden sowie ihrem Lagerort
|
||||
\item Admin-Frontend
|
||||
\item Funktionen des Admin-Frontends
|
||||
\begin{itemize}
|
||||
\item Hinzufügen neuer Waren zum Bestand
|
||||
\item Manuelles Entfernen von Waren aus dem Bestand, zum Beispiel wenn der Bestand verdorben ist
|
||||
\item Entfernen von Waren aus dem Bestand, wenn diese an einen Kunden versendet werden
|
||||
\item Blockieren von Waren in dem Bestand, wenn ein Kunde sie in seinen Warenkorb gelegt hat
|
||||
\item Hinzufügen neuer Waren zum Warenbestand
|
||||
\item Manuelles Entfernen von Waren aus dem Warenbestand, zum Beispiel wenn diese verdorben sind
|
||||
\item Entfernen von einzelnen Waren aus dem Warenbestand, wenn diese an einen Kunden versendet werden
|
||||
\item Blockieren von Waren in dem Warenbestand, wenn ein Kunde sie in seinen Warenkorb gelegt hat
|
||||
\item Automatische Freigaben von blockierten Waren, wenn diese nach 30 Minuten nicht an den Versand überstellt wurden
|
||||
\end{itemize}
|
||||
\item Kunden-Frontend
|
||||
\item Funktionen des Kunden-Frontends
|
||||
\begin{itemize}
|
||||
\item Anzeige der Produktverfügbarkeit über ein Ampelsystem, mehr als zehn Waren entsprechen grün, fünf bis zehn Waren entsprechen gelb und weniger als fünf Waren entsprechen rot
|
||||
\item Anzeige des Warenbestands über ein Ampelsystem
|
||||
\item Ein Warenbestand größer sieben entspricht der Farbe grün (ausreichende Anzahl vorhanden)
|
||||
\item Ein Warenbestand zwischen vier und sieben entspricht der Farbe orange (moderate Anzahl vorhanden)
|
||||
\item Ein Warenbestand zwischen null und drei entspricht der Farbe rot (geringe Anzahl vorhanden)
|
||||
\end{itemize}
|
||||
\item Optionale Zusatz-Funktionen
|
||||
\item Optionale Zusatzfunktionen
|
||||
\begin{itemize}
|
||||
\item Ausgabe einer Statistik, wie viele Waren im letzten Monat aus dem Bestand versandt und wie viele manuell entfernt wurden im Admin-Fontend
|
||||
\item Ampeldarstellung pro Waren, die Anzeigt ab die Ware bereits überaltert ist, im Admin-Frontend
|
||||
\item Ausgabe einer Statistik, wie viele Waren im letzten Monat aus dem Warenbestand versandt und wie viele manuell entfernt wurden im Admin-Fontend
|
||||
\item Ampeldarstellung pro Ware, die Anzeigt ob diese bereits überaltert ist, im Admin-Frontend (ein Alter von mehr als X Tagen wird als überaltert angesehen)
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
|
|
|
|||
|
|
@ -48,9 +48,11 @@
|
|||
\titleformat*{\section}{\LARGE}
|
||||
\titleformat*{\subsection}{\Large}
|
||||
\titleformat*{\subsubsection}{\large}
|
||||
\titleformat*{\paragraph}{\ttfamily\bfseries }
|
||||
|
||||
\setlength{\abovecaptionskip}{1pt}
|
||||
\setlength{\belowcaptionskip}{1pt}
|
||||
\titlespacing{\paragraph}{0pt}{11pt}{0.5pt}
|
||||
\setlength{\parindent}{0pt}
|
||||
\setlength{\parskip}{5.5pt}
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,8 @@
|
|||
\section{Architektur des Microservice}
|
||||
\label{sec: Architektur des Microservice}
|
||||
Der Microservice Warenwirtschaft wurde in der Programmiersprache Go\footnote{https:\//golang.org\/doc\/} entwickelt. Go-An-wendungen bestehen aus Packages, in denen die einzelnen Go-Files organisiert sind, Klassen im Sinne der Objektorientierung gibt es nicht. Der Microservice Warenwirtschaft sett sich aus den neun Packages zusammen, die in der Abbildung X dargestellt werden. In den beiden nachfolgenden Unterkapiteln werden die Packages und die darin enthaltenen Go-Files des Presentation sowie des Application Layers kurz vorgestellt. Go-Files mit der Bezeichnung \texttt{<<Name>>\_test.go} beinhalten Whitebox-Testfälle um die Funktionen der benannten Go-Files zu prüfen. Aus Gründen der Übersichtlichkeit werden diese File hier nicht explizit aufgeführt.
|
||||
Der Microservice nutzt anstelle einer klassischen Datenbank eine In-Memory-Datenbank im Cache. Aus diesem Grund verschwimmen klassischen Grenzen des Application und Persitant Layers und auf die dezidierte Aufführung des letzteren wird verzichtet.
|
||||
|
||||
|
||||
\begin{figure}[H]
|
||||
\begin{center}
|
||||
|
|
@ -9,29 +12,72 @@
|
|||
\label{pic:Struktur des Microservice}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Schnittstellen zu anderen Microservices}
|
||||
\label{subsec: Schnittstellen zu anderen Microservices}
|
||||
Der Microservice Warenwirtschaft weißt drei Schnittstellen\footnote{Da es nicht Teil der übergeordneten Aufgabenstellung war, die Microservices der einzelnen Projektgruppen zu einem lauffähigen Webshop zusammenzufügen, greift der Microservice Warenwirtschaft an diesen Stellen auf Testdaten zurück} zu anderen Microservices auf. Zum einen sollten für die Authentifizierung der Benutzer des Admin-Frontends auf den Microservice Benutzerauthentifizierung zurückgegriffen werden. Außerdem benötigt der Microservice Informationen darüber, ob ein Benutzer eine Ware in den Warenkorb gelegt hat und ob eine Ware versandt wurde. Somit entstehen ebenfalls Schnittstellen zu den Microservices Bestellung und Versandt.
|
||||
|
||||
\begin{itemize}
|
||||
\item Der Microservice wurde in der Programmiersprache Go\footnote{https:\//golang.org\/doc\/} entwickelt.
|
||||
\item \textcolor{red}{ToDo: kurze Beschreibung der Programmstruktur und genauere Beschreibung der Einzelteile in Unterkapiteln}
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Schnittstellen}
|
||||
\label{subsec: Schnittstellen}
|
||||
|
||||
\subsection{Presentation Layer}
|
||||
\label{subsec: Presentation Layer}
|
||||
Der Presentation Layer umfasst alle Packages, die sich mit der eigentlichen Darstellung der Warenwirtschaft aus der Sicht des Endbenutzers befassen. Im Detail ist dies das Package \texttt{webroot}, welches den statischen Inhalt der Frontends, wie zum Beispiel die HTML-Files und Bilder enthält.
|
||||
|
||||
|
||||
\subsection{Application Layer}
|
||||
\label{subsec: Application Layer}
|
||||
|
||||
\subsection{Persistant Layer}
|
||||
\label{subsec: Persistant Layer}
|
||||
\paragraph{cmd:} Go-File main.go, welches alle Angaben zu den Config-Files der Applikation enthält
|
||||
|
||||
\paragraph{contrib:} zusätzliche Dateien, wie die SVG-Datei, die die Ampel zur Darstellung der Verfügbarkeit der Waren in dem Kunden-Frontend beschreibt
|
||||
|
||||
|
||||
\paragraph{http:} Go-Files, die die Anwendungslogik (Funktionen) beinhalten.
|
||||
\begin{itemize}
|
||||
\item \texttt{good.go}: Funktionen für die Auflistung und Zählung der vorhandenen Waren sowie die Feststellung ihrer Verfügbarkeit zusammen
|
||||
\item \texttt{good\_temp.go}: Hilfsfunktionen, die für die Darstellung des Warenbestandes als Ampel im Kunden-Frontend benötigt werden
|
||||
\item \texttt{main.go}: Funktionen, die für das Binden der URL-Pfade notwendig sind
|
||||
\item \texttt{status.go}: Funktion, die den Status des Microservice abfragt
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\paragraph{models:} Go-Files, die Structs und zugehörige Hilfsfunktionen beinhalten
|
||||
\begin{itemize}
|
||||
\item \texttt{config.go}: Structs mit den Informationen zur Konfiguration des Webservers, der Datenbank und dem Cache-Management sowie Hilfsfunktionen zum Lesen von Config-Files
|
||||
\item \texttt{duration.go}: Structs und Hilfsfunktionen zur Definition eines Typs für Zeitangaben
|
||||
\item \texttt{good.go}: Structs und Hilfsfunktionen zur Darstellung von Waren, hier werden auch die beschriebenen Funktionalitäten wie das Blockieren von Waren beschrieben
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\paragraph{runtime:} Go-Files mit weiteren Hilfsfunktionen
|
||||
\begin{itemize}
|
||||
\item \texttt{auth.go}: Hilfsfunktionen zur Prüfung, ob eine Berechtigung für den Zugriff vorliegt
|
||||
\item \texttt{cache\_worker.go}: Hilfsfunktionen für das Löschen und Anlegen von Cache-Workers
|
||||
\item \texttt{good\_release.go}: Hilfsfunktionen zum Entsperren von blockierten Waren
|
||||
\item \texttt{product.go}: Hilfsfunktionen zum Anlegen eines Caches für Produkte und zur Prüfung
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\newpage
|
||||
\paragraph{lib:} fasst die vier Packages \texttt{database}, \texttt{http}, \texttt{log} und \texttt{worker} zusammen
|
||||
|
||||
\begin{itemize}
|
||||
\item \texttt{database}: Go-File \texttt{main.go} mit Funktionen für das Öffnen und Schließen der Datenbank
|
||||
\item \texttt{http}: Go-Files, die die Webserverlogik umgesetzten
|
||||
\begin{itemize}
|
||||
\item \texttt{io.go}: Funktionen zum Lesen und Schreiben von JSON aus beziehungsweise in HTTP-PAckete
|
||||
\item \texttt{permission.go}: Funktionen zur Prüfung der Berechtigung für den Zugriff
|
||||
\end{itemize}
|
||||
\item \texttt{log}: Go-File \texttt{main.go}, das den Logger startet und initiiert
|
||||
\item \texttt{worker}: Go-File \texttt{worker.go}, dass Funktionen für die Nutzung des Caches als Datenbank (Worker) bereitstellt
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Integrierte Tests}
|
||||
\label{subsec: Integrierte Tests}
|
||||
\label{subsec: Integrierte Test}
|
||||
Neben den Go-Files die bereits Whitebox-Tests enthalten, ist in dem Package \texttt{test} ein weiteres Go-File entgalten. Dieses setzt einen Test des Webservers um. Mit Hilfe der integrierten Test kann in der hier beschriebenen Version eine Code-Coverage von 100\% erreicht werden, das heißt jedes Stück Code wird mindestens einmal zur Ausführung gebracht.
|
||||
|
||||
\subsection{Admin-Frontend}
|
||||
\label{subsec: Admin-Frontend}
|
||||
|
||||
|
||||
|
||||
\subsection{Anpassung des Monolithen}
|
||||
\label{subsec: Anpassung des Monolithen}
|
||||
25
README.md
25
README.md
|
|
@ -4,14 +4,17 @@ This is a microservice cutted out of a [Monolith](https://gitlab.com/matthiassto
|
|||
[](https://travis-ci.org/genofire/hs_master-kss-monolith) [](https://coveralls.io/github/genofire/hs_master-kss-monolith?branch=master)
|
||||
|
||||
## Features of this stock mircoservice
|
||||
* save goods via product with timestamp, if it was found and there place in a warehouse (in the admin front end)
|
||||
* add new goods
|
||||
* manual delete of goods, e.g if the good get fouled
|
||||
* remove a good from warehouse, if it was send to customer
|
||||
* lock goods, if a customer has it in his bill (and release after time x, if it was not send to customer)
|
||||
* customer front end
|
||||
* display availability with something like a traffic lights
|
||||
|
||||
### Nice to have / Can-But-Must-Not-Feature
|
||||
* display of statistics values like how many goods was removed in a time range
|
||||
* traffic light in admin front end of goods which get fouled in next time or is already fouled
|
||||
* The main functionality of the microservice is to store the goods with their storage location and a time stamp, when they where stored.
|
||||
* Functionality of the admin frontend
|
||||
** Add new goods to the stock
|
||||
** Manually remove a single goods from the stock, for example when they are rancid
|
||||
** Remove single goods from the stock, when they are send to a costumer
|
||||
** Block goods from the stock, when a costumer added them to hie cart
|
||||
* Functionality of the costumer frontend
|
||||
** Show the store with a traffic light food labelling
|
||||
** A stock of more then seven goods corresponds to the colour green (sufficient amount of goods)
|
||||
** A stock between four and seven goods corresponds to the colour orange (moderate amount of goods)
|
||||
** A stock between zero and three goods corresponds to the colour red (slim amount of goods)
|
||||
* Optional Features
|
||||
** Admin frontend: display of a statistic on how many goods where convexed and manually removed from the stock during the last month
|
||||
** Traffic light food labelling for each good, which indicates whether the good is too old
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
package test
|
||||
|
||||
// Request a easy manager to test REST-API
|
||||
// Request an easy manager to test REST-API
|
||||
import (
|
||||
"bytes"
|
||||
"encoding/json"
|
||||
|
|
@ -16,7 +16,7 @@ import (
|
|||
|
||||
var srv *http.Server
|
||||
|
||||
//Init to initialisieren a API
|
||||
//Init to initialisieren an API
|
||||
func Init(t *testing.T) (assertion *assert.Assertions, router *goji.Mux) {
|
||||
assertion = assert.New(t)
|
||||
database.Open(database.Config{
|
||||
|
|
|
|||
Reference in New Issue