13hannes11/bachelor_thesis
1
0
Fork 0
mirror of https://github.com/13hannes11/bachelor_thesis.git synced 2024-09-04 01:11:00 +02:00
Code Issues Projects Releases Wiki Activity

add some more todos

Browse Source
This commit is contained in:
hannes.kuchelmeister
2020-04-23 10:58:06 +02:00
parent f7fa6f7e85
commit 3afab2607a
2 changed files with 5 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
30_Thesis/sections/10_foundations.tex
View File

@@ -216,6 +216,7 @@ He only makes changes to M.Customer which is renamed to M.Collab-Customer and in
\item[M.Collab-Customer] a modified version of M.Customer that does all communication via WebSocket and does communicate with M.Collab instead of M.Core. M.Customer is the customer facing component. It allows a customer to configure a product or solution. \item[M.Collab-Customer] a modified version of M.Customer that does all communication via WebSocket and does communicate with M.Collab instead of M.Core. M.Customer is the customer facing component. It allows a customer to configure a product or solution.
\end{description} \end{description}
\FloatBarrier \todo[inline]{design patterns: composite, pipeline}
\todo[inline]{model view controller}

6
30_Thesis/sections/50_design_and_implementation.tex
View File

@@ -50,18 +50,18 @@ The REST API looks as follows.
\end{description} \end{description}
The API is implemented with a minimal amount of functions and the recommender currently only supports one product at the same time. However, the architecture is built in a way that can be easily extended into supporting multiple products. The API is implemented with a minimal amount of functions and the recommender currently only supports one product at the same time. However, the architecture is built in a way that can be easily extended into supporting multiple products.
The general architecture adheres to the model view controller inspired architecture. The general architecture adheres to the model view controller \todo[]{wir das Konzept im Litertaurteil eingeführt? Oder ist das ein allbekanntes Konzept in der Informatik? (mir wars neu)} inspired architecture.
Data is stored and retrieved using a data access objects therefore the currently used simple TinyDB database backend can be switched to a different one easily. Data is stored and retrieved using a data access objects therefore the currently used simple TinyDB database backend can be switched to a different one easily.
\section{Database} \section{Database}
\label{sec:DesignImplementation:Database} \label{sec:DesignImplementation:Database}
The choice among database systems has to be made between \emph{non-relational} and \emph{relational} databases. Relational databases are great at the four ACID (atomicity, consistency, isolation, durability) principles. Moreover if the data structures are not changing it provides a solid basis that keeps the data reliable. A non-relational database on the other hand is ideal for rapid agile development. Moreover it shines if data requirements are not entirely clear and if a large amount of unstructured data has to be stored. Moreover non-relational databases allows the system to store the data in any kind of structure. This proves as an advantage as it allows to use the same data structure to be stored that also has to be fed out through the api. Therefore parsing methods for the API can be reused and changed upon changing requirements. Moreover the data used for the recommender is mostly not interconnected therefore a relational databases main strength the data structure does not really come into play here. Thus in this thesis a NoSQL database is used. The choice among database systems has to be made between \emph{non-relational} and \emph{relational} databases. Relational databases are great at the four ACID (atomicity, consistency, isolation, durability) principles. Moreover, if the data structures are not changing it provides a solid basis that keeps the data reliable. A non-relational database on the other hand is ideal for rapid agile development. Moreover, it excels if data requirements are not entirely clear and if a large amount of unstructured data has to be stored. Moreover, non-relational databases allows the system to store the data in any kind of structure. This proves as an advantage as it allows to use the same data structure to be stored that also has to be fed out through the api. Therefore parsing methods for the API can be reused and changed upon changing requirements. Moreover, the data used for the recommender is mostly not interconnected, therefore a relational databases main strength, the data structure, does not really come into play here. Thus, in this thesis a NoSQL database is used.
\section{Scoring Functions} \section{Scoring Functions}
\label{sec:DesignImplementation:ScroingFunctions} \label{sec:DesignImplementation:ScroingFunctions}
Scoring functions are implemented in a modular fashion. There are different types of scoring functions. Some are meant for evaluating user preferences (and inherit from the class \emph{PreferenceScoringFunction}), others are meant for penalising changes in the current configuration state and therefore inheriting from \emph{ConfigurationPenalty}. The last type of scoring function is a composite scoring function that consists of one or multiple scoring functions and combines their score into one. It uses the \emph{composite} design pattern. These functions allow ´the flexible combination of functions but moreover because of their underlying structure they can use similar components. For example preference scoring functions uses a pipeline to first convert preferences to a list of values. This is done using \emph{PreferenceToListFunction}. A list can be modified with a \emph{ListToListFunction}. This step is optional. The last mandatory step is to convert the list to a value using \emph{ListToValueFunction}. After this step the value can be modified further, for example with a threshold function or any other function. All these components allow the easy and quick creation of new scoring functions. A scoring function factory is used to assemble a scoring function based on input parameters. This gives flexibility for quickly implementing new types of scoring functions. Scoring functions are implemented in a modular fashion. There are different types of scoring functions. Some are meant for evaluating user preferences (and inherit from the class \emph{PreferenceScoringFunction}), others are meant for penalising changes in the current configuration state and therefore inheriting from \emph{ConfigurationPenalty}. The last type of scoring function is a composite scoring function that consists of one or multiple scoring functions and combines their score into one. It uses the \emph{composite} design pattern \todo[]{wurde das im Literaturteil erklärt?}. These functions allow ´the flexible combination of functions but moreover because of their underlying structure they can use similar components. For example, preference scoring functions uses a pipeline to first convert preferences to a list of values. This is done using \emph{PreferenceToListFunction}. A list can be modified with a \emph{ListToListFunction}. This step is optional. The last mandatory step is to convert the list to a value using \emph{ListToValueFunction}. After this step, the value can be modified further, for example, with a threshold function or any other function. All these components allow the easy and quick creation of new scoring functions. A scoring function factory is used to assemble a scoring function based on input parameters. This gives flexibility for quickly implementing new types of scoring functions.
\section{Technologies} \section{Technologies}