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 minor fixes and todos

Browse Source
This commit is contained in:
hannes.kuchelmeister
2020-04-22 11:17:01 +02:00
parent c73285fe82
commit a01e452a5c
2 changed files with 29 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
30_Thesis/sections/40_concept.tex
View File

@@ -144,7 +144,7 @@ The used characteristics and attributes are shown in \autoref{fig:Concept:Forest
\begin{figure}
\begin{mdframed}[frametitle={Example for Forest Use Case}, linecolor=black, frametitlerulecolor=black, frametitlebackgroundcolor=gray!5]
In this example there are a small group of users. The use case is a piece of forest and variables are for example harvesting activity, which trees to grow and accessibility for people.
In this example there is a small group of users. The use case is a piece of forest and variables are for example harvesting activity, which trees to grow and accessibility for people.
\begin{align}
\begin{split}
V = \{ & \textit{indigenous}, \textit{resilient}, \textit{usable}, \textit{effort}, \textit{quantity}, \textit{price}, \textit{accessibility} \},
@@ -178,16 +178,21 @@ The used characteristics and attributes are shown in \autoref{fig:Concept:Forest
\section{Solution Generation}
\label{sec:Concept:SolutionGeneration}
\todo[inline]{hier wird erstmal nicht klar, worum es geht.
The process of finding a suitable configuration to recommend, the following steps are executed: ...
oder auf was will der Absatz hinaus?}
Given an unfinished configuration and preferences of all group members, rate a finished configuration on how well it reflects the configuration state and preferences. Use this to choose the best finished configuration out of a list to recommend. This approach is an aggregated preference strategy of ranking of candidate items (see \autoref{sec:Foundations:GroupRecommenderSystem}).
\subsection{Generating a Recommendation}
Hereby the idea is there is a database of complete configurations (possibly historic from other groups or automatically generated or both).
\todo[inline]{den prozess noch ein bisschen erklären: was bezieht der Score mit ein? Warum anschließend bestimmte Konfigurationen ausschließen? Warum dafür eine neue Bewertungsfunktion? Warum ist dieser Schritt optional? Was bedeutet es dann, wenn eine Konfiguration ausgesucht wurde?}
There is a database of complete configurations (possibly historic from other groups or automatically generated or both).
Now the recommendation procedure looks as follows:
\begin{enumerate}
\item Assign a score to each stored configuration according to $$score_{group}(\overline{configurationState},\ \overline{preferences}, \ configurationInStore)$$
\item Optional: Filter out configurations that have a score below a certain value using a different scoring function. For example filter out configurations that cause a certain level of misery.
\item Chose the configuration with the highest score as recommendation.
\end{enumerate}
@@ -199,19 +204,20 @@ Now the recommendation procedure looks as follows:
score_{group}: S \times P \times S_F \to \mathbb{R}
\end{equation}
An example group configuration scoring function is $score_{group}$ with
An example group configuration scoring function is $score_{group}$ with \todo[]{erkläre die Formel, es bleibt offen, wie über die Nutzer aggregiert wird}
\begin{equation}
score_{group}(\overline{s},\ \overline{p},\ s) = score(\overline{p},\ s) \cdot penalty(\overline{s},\ s)
\end{equation}
This thesis will use multiple scoring functions. Among those are ones for least misery, average and multiplicative which all are implemented by $score$. Average and multiplicative yield good results among the studies presented by \citeauthor{Masthoff2015} \cite{Masthoff2015}. Strategies can also be combined, one example here is average without misery. The scoring functions used for this thesis all combine $penalty$ and $score$ by multiplication. However it is possible to use other combination strategies and it is possible to combine multiple scoring functions into one group scoring function. This thesis will use simpler scoring functions that are not combined but improvement here is possible.
This thesis will use multiple scoring functions. Among those are ones for least misery, average and multiplicative which all are implemented by $score$ \todo[]{Referenz zur Stelle, wo die verwendeten Funktionen im Detail beschrieben werden}. Average and multiplicative yield good results among the studies presented by \citeauthor{Masthoff2015} \cite{Masthoff2015}. Strategies can also be combined, one example here is average without misery. The scoring functions used for this thesis all combine $penalty$ and $score$ by multiplication. However it is possible to use other combination strategies and it is possible to combine multiple scoring functions into one group scoring function. This thesis will use simpler scoring functions that are not combined but improvement here is possible.
\subsubsection{Preference Scoring}
\todo[inline]{possibly remove distance from average scoring from thesis}
All of the aggregation functions mentioned in \autoref{subsec:Concept:SolutionGeneration:ScoringFunction} have one preference per product. For configuration where a preference for all characterises exists there needs to be a function that combines the preferences of one user into her configuration score. After one score has been calculated per user the mentioned preference aggregation strategies can be used.
This thesis proposes two different scoring functions. First, to use the difference from the selected characteristic compared to the average rating of all characteristics of the corresponding feature. This approach includes all preferences of a user meaning a preference is also seen relative to other preferences.
This thesis proposes two different scoring functions.
First, to use the difference \todo[]{es wäre gut, diese Bewertung auch als Formel auszudrücken} from the selected characteristic compared to the average rating of all characteristics of the corresponding feature. This approach considers all preferences of a user meaning a preference is also seen relative to other preferences of alternative characteristics of the same feature.
As an example a feature could be
\begin{equation}
@@ -233,14 +239,14 @@ A second user with preferences
\begin{equation}
P_2 = \{(\text{low}, 0), (\text{medium},0), (\text{high},0.9) \}
\end{equation}
on the other hand results in a feature score of $0.9-0.3=0.6$. For this user characteristic \emph{high} is of higher importance.
on the other hand results in a feature score of $0.9-0.3=0.6$. For this user the characteristic \emph{high} is of higher importance.
As scores should be kept as percentages and not in the interval $[-1,1]$ a normalisation is applied by adding one and dividing by two. Therefore the respective scores are $0.7$ for user one and $0.95$ for user two. A configuration usually consists of more than one feature therefore an average rating over all features is taken to get the score one user gives to a configuration. Based on that score the in \autoref{subsec:Concept:SolutionGeneration:ScoringFunction} mentioned aggregation functions can be used.
As scores should be kept as percentages and not in the interval $[-1,1]$ a normalisation is applied by adding one and dividing by two \todo[]{die allgemeine Erklärung der Berechnung sollte vor dem Beispiel kommen}. Therefore the respective scores are $0.7$ for user one and $0.95$ for user two. A configuration usually consists of more than one feature therefore an average rating over all features is taken to get the score one user gives to a configuration. Based on that score the in \autoref{subsec:Concept:SolutionGeneration:ScoringFunction} mentioned aggregation functions can be used.
The second simpler scoring function approach is to use the the preference for each characteristic that is part of the configuration and then use the average. This approach is more transparent because the preference of a user is directly translated into the score and no weighting is done. It means that a configuration score is more simple to understand and to calculate. However, if needed, for example to give one group member more power, it allows relative weighting too. This can be done with preprocessing of preferences. Moreover, an approach like this ensures that through preprocessing feature weights can be added. It is therefore possible that a user gives different importances to features. Also, other means of weighting ratings is possible. For example the ratings of one group member who has more knowledge in an area can be increased by multiplication with a factor or alternatively the preferences for all other users can be decreased.
The second simpler scoring function approach is to use the the preference for each characteristic that is part of the configuration and then use the average. This approach is more transparent because the preference of a user is directly translated into the oscore and no weighting is done. It means that a configuration score is more simple to understand and to calculate. However, if needed, for example to give one group member more power, it allows relative weighting, too. This can be done with preprocessing of preferences. Moreover, an approach like this ensures that through preprocessing feature weights can be added \todo[]{das kann ich doch bei der anderen Funktion auch zB nachdem ich das Scoring für eine einzelne Ausprägung berechnet habe}. It is therefore possible that a user gives different importances to features. Also, other means of weighting ratings is possible. For example the ratings of one group member who has more knowledge in an area can be increased by multiplication with a factor or alternatively the preferences for all other users can be decreased.
The example above would not result in different feature scores for $P_1$ and $P_2$. Both would result in a score of $0.9$. Therefore there is a more direct link between a users preference and the score.
The simplicity of the second approach in combination with transparency is why it is the approach that will be used in further chapters in this thesis, especially as trust in a recommendation system is important.
The simplicity of the second approach in combination with transparency is why it is the approach that will be used in further chapters in this thesis \todo[]{warum hast du die erste Funktion dann erklärt?}, especially as trust in a recommendation system is important.
\subsubsection{Cofiguration Change Penalty}
\label{subsubsec:Concept:SolutionGeneration:ScoringFunction:Penalty}
@@ -253,16 +259,20 @@ In this thesis a penalty function is proposed which gives the percentage of char
0, & \text{otherwise}
\end{cases}
\end{equation}
\todo[]{erkläre die Formel $penalty_\text{proportion}$ genauer}
\todo[]{erkläre die Rolle von $\alpha$ }
\begin{equation}
penalty_{proportion}(\overline{s},\ s) = \left(\frac{\sum_{d \in \overline{s}} unchanged(d,\overline{s}, s)}{|\overline{s}|}\right)^\alpha.
\end{equation}
By including the current configuration into scoring the scoring function can take into account, changes that have been already implemented and therefore might be very costly to change.
By including the current configuration state, the scoring function can take into account that some characteristics have already been realized and therefore might be very costly to change.
\section{Illustration}
\label{sec:Concept:Illustration}
This section gives an example to illustrate how the recommendation works. The example in \autoref{fig:Concept:ForestExample} is used for that but the preferences are extended. \autoref{tab:Concept:UseCaseConfigurations} shows the current configuration state which consists of the characteristic moderate for the feature \textit{indigenous} and \textit{resilient} respectively. $S_{F1}$ to $S_{F4}$ show the stored configurations for this example. The features that will be focused on are \textit{indigenous}, \textit{resilient} and \textit{effort}. In the presented example $S_{F1}$ performs best. The exact reason for that will be presented here. $S_{F1}$ is compared to $S_{F2}$ to show the effect of divergence from the configuration state. A comparison between $S_{F1}$ and $S_{F3}$ is done to show the difference between preferences and the effect on the score and last, $S_{F4}$ is done to show the effect of switching to better preferences but diverging from the current state. The configurations all differ to $S_{F1}$ in only one characteristic that is chosen differently. As aggregation strategy the \emph{average} metric is used. The parameter $\alpha$ (see \autoref{subsubsec:Concept:SolutionGeneration:ScoringFunction:Penalty}) is set to 1. A lower $\alpha$ reduces the penalty given to configurations that deviate from the configuration state $S$.
\todo[]{Leser sind faul, bitte schreibe die Berechnung bzw wenigstens die Ergebnisse für $score$, $penalty$, $score_\text{group}$ zu jedem Vergleich dazu}
This section gives an example to illustrate how the recommendation works. The example in \autoref{fig:Concept:ForestExample} is used for that but the preferences are extended. \autoref{tab:Concept:UseCaseConfigurations} shows the current configuration state which consists of the characteristic moderate for the feature \textit{indigenous} and \textit{resilient} respectively. $S_{F1}$ to $S_{F4}$ show the stored configurations for this example. The features that will be focused on are \textit{indigenous}, \textit{resilient} and \textit{effort}. In the presented example $S_{F1}$ performs best. The exact reason for that will be presented here. $S_{F1}$ is compared to $S_{F2}$ to show the effect of divergence from the configuration state. A comparison between $S_{F1}$ and $S_{F3}$ is done to show the difference between preferences and the effect on the score and last, $S_{F4}$ is done to show the effect of switching to better preferences but diverging from the current state. The configurations all differ to $S_{F1}$ in only one characteristic that is chosen differently. As aggregation strategy the \emph{average} metric is used \todo[]{referenz zur erklärung}. The parameter $\alpha$ (see \autoref{subsubsec:Concept:SolutionGeneration:ScoringFunction:Penalty}) is set to 1. A lower $\alpha$ reduces the penalty given to configurations that deviate from the configuration state $S$ and a higher $\alpha$ increase the reluctance to change.
The difference between $S_{F1}$ and $S_{F2}$ is that instead of containing \emph{moderate} for the feature \emph{resilient} $S_{F2}$ contains \emph{high}. The scores for these two characteristics is the same as both users have rated them at $0.5$ but as $S_{F2}$ deviates from the configuration state there will be a penalty. There are two characteristics in the configuration state $S$ therefore the the penalty is $(\frac{1}{2})^\alpha = (\frac{1}{2})^1 = 0.5$. This means the score of $S_{F2}$ is half that of $S_{F1}$.
@@ -295,7 +305,7 @@ Last, $S_{F1}$ and $S_{F4}$ differentiate in terms of characteristic choice for
$S_{F3}$ & - & \pmb{\checkmark} & - & - & \pmb{\checkmark} & - & - & \checkmark & - & - & \pmb{\checkmark} & - & - & - & \checkmark & - & \checkmark & - & \checkmark & - & - \\
$S_{F4}$ & - & - & \pmb{\checkmark} & - & \pmb{\checkmark} & - & - & \checkmark & - & \pmb{\checkmark} & - & - & - & - & \checkmark & - & \checkmark & - & \checkmark & - & - \\
\end{tabularx}
\caption{A table showing the current configuration state $ S $ and the stored finished configurations $ S_{Fi} $.}
\caption{The current configuration state $ S $ and the stored finished configurations $ S_{Fi} $.}
\label{tab:Concept:UseCaseConfigurations}
\end{table}

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

@@ -1,9 +1,10 @@
\chapter{Design and Implementation}
\label{ch:DesignImplementation}
This thesis requires a group configuration system with a recommender. Developing a configurator and a recommendation system for this thesis is infeasible. Therefore, the decision was made to use an existing configurator. In this thesis \emph{CAS Configurator Merlin} \cite{IndustrySpecificProduct2020} is extended. As this configurator does not allow group configuration, a modified version is used that already has been extended by \citeauthor{raabKollaborativeProduktkonfigurationEchtzeit2019} \cite{raabKollaborativeProduktkonfigurationEchtzeit2019}. The base system and its extension are described in \autoref{sec:Foundations:BaseSystem}.
This thesis requires a group configuration system with a recommender. In this thesis \emph{CAS Configurator Merlin} \cite{IndustrySpecificProduct2020} is extended. As this configurator does not allow group configuration, a modified version is used that has been developed by \citeauthor{raabKollaborativeProduktkonfigurationEchtzeit2019} \cite{raabKollaborativeProduktkonfigurationEchtzeit2019}. The base system and its extension are described in \autoref{sec:Foundations:BaseSystem}.
\autoref{fig:DesignImplementation:RecommenderForCollaborativeConfiguratorMerlin} shows how the system looks like after the recommender is added. For this thesis M.Collab and M.Collab-Customer have undergone some slight modifications to allow the displaying of recommendations and to query the recommender. The user interface is shown in \autoref{fig:DesignImplementation:RecommenderForCollaborativeConfiguratorMerlin}. It extends the user interface of M.Collab-Customer by adding a like and dislike button and functionality to show other participants in the session.
\autoref{fig:DesignImplementation:RecommenderForCollaborativeConfiguratorMerlin} shows how the system architecture after the recommender is added. For this thesis M.Collab and M.Collab-Customer have undergone some slight modifications to allow the displaying of recommendations and to query the recommender. The user interface is shown in \autoref{fig:DesignImplementation:RecommenderForCollaborativeConfiguratorMerlin}. It extends the user interface of M.Collab-Customer by adding a like and dislike button \todo[]{bisher waren deine Präferenzen dargestellt über Werte im Bereich [0;1], jetzt taucht nur like/dislike auf. Erkläärung, wie neutral dargestellt wird.
Das musst du entweder ändern oder die Inkonsistenz gut wegargumentieren.} and functionality to show other participants in the session.
\begin{figure}
\centering
@@ -16,8 +17,8 @@ This thesis requires a group configuration system with a recommender. Developing
\section{Microservice}
\label{sec:DesignImplementation:Microservice}
An existing base system can be extended in different directions. As M.Collab already functions as middleman between M.Collab-Customer and M.Core, one solution would be to add recommender functionality into M.Collab-Customer. However this approach would conflict with the single responsibility and separation of concern software design principles. It would change M.Collab from a system that works similar to a router to one that additionally handles recommendations. M.Collab manages communication between M.Collab-Customer instances and between M.Core and M.Collab-Customer. Therefore this solution was discarded.
Another viable solution is adding the recommendation functionality into M.Core. The main benefit of this approach is that it allows the recommender to use systems that are used for solving constraint satisfaction problems to enhance recommendations. The disadvantage of this approach is however, that now the recommender is tightly coupled with the configurator. Not only does this mean that reproducing results in this thesis is only possible with access to a non open-source product but it also means that there is no possibility to use the recommender for other configuration solutions. Moreover no plugin API exists and therefore the extension would require additional effort.
An existing base system can be extended in different directions. As M.Collab already functions as middleman between M.Collab-Customer and M.Core, one solution would be to add recommender functionality into M.Collab-Customer. However, this approach would conflict with the single responsibility and separation of concern software design principles. It would change M.Collab from a system that works similar to a router to one that additionally handles recommendations. M.Collab manages communication between M.Collab-Customer instances and between M.Core and M.Collab-Customer. Therefore this solution was discarded.
Another viable solution is adding the recommendation functionality into M.Core. The main benefit of this approach is that it allows the recommender to use systems that are used for solving constraint satisfaction problems to enhance recommendations. The disadvantage of this approach is however, that now the recommender is tightly coupled with the configurator. Not only does this mean that reproducing results in this thesis is only possible with access to a non open-source product but it also means that there is no possibility to use the recommender for other configuration solutions. Moreover no plugin API exists and therefore the extension would require a large effort.
Due to these reasons the decision was made to create a new microservice, called M.Recommend which communicates with M.Collab, thereby being loosely coupled with other system components. Additionally, this approach allows to add functionality that takes advantage of a constraint satisfaction problem solver by either communicating with one via an API or by integrating one directly into the recommender M.Recommend. Moreover, it also allows the use of different technologies instead of JavaScript and Node.js. Using a separate component also allows to scale the system differently as it is possible to use multiple recommender instances for one configurator instance or one recommender instance for multiple configurator instances. This is an advantage in the age of automatically scaling systems.
\begin{figure}