remove irrelevant todos

This commit is contained in:
hannes.kuchelmeister
2020-05-07 12:53:03 +02:00
parent f0adb186b4
commit b76a886a1f
3 changed files with 2 additions and 8 deletions

View File

@@ -49,7 +49,7 @@ The REST API looks as follows.
\end{description}
The API is implemented with a minimal amount of functions and the recommender currently only supports one product at a time. However, the architecture is built in a way that it can be easily extended into supporting multiple products.
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.
The general architecture adheres to the model-view-controller inspired architecture.
Data is stored and retrieved using data access objects. Therefore, the currently used simple TinyDB database backend can be switched to a different one easily.
\section{Database}
@@ -60,7 +60,7 @@ The choice among database systems has to be made between \emph{non-relational} a
\section{Scoring Functions}
\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 inherit 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 scores to one. It uses the \emph{composite} design pattern. \todo[]{wurde das im Literaturteil erklärt?} These functions allow ´the flexible combination of functions and, in addition due to their underlying structure they can use similar components. For example, preference scoring functions use 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 provides 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 inherit 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 scores to one. It uses the \emph{composite} design pattern. These functions allow ´the flexible combination of functions and, in addition due to their underlying structure they can use similar components. For example, preference scoring functions use 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 provides flexibility for quickly implementing new types of scoring functions.
\section{Technologies}