improve abstract

.gitattributes

@@ -0,0 +1,5 @@
+*.png filter=lfs diff=lfs merge=lfs -text
+*.ods filter=lfs diff=lfs merge=lfs -text
+*.pdf filter=lfs diff=lfs merge=lfs -text
+*.eps filter=lfs diff=lfs merge=lfs -text
+*.sla filter=lfs diff=lfs merge=lfs -text

25_Outline/outline.tex

@@ -1,4 +1,3 @@
-%% LaTeX2e class for student theses
 %% thesis.tex
 %% 
 %% Karlsruhe Institute of Technology
@@ -17,7 +16,7 @@
 
 %% Available page modes: oneside, twoside
 %% Available modes: draft, final (see README)
-\documentclass[oneside, english, draft]{sdqthesis}
+\documentclass[oneside, english, final]{sdqthesis}
 
 
 %% ---------------------------------

25_Outline/sections/20_foundations.tex

@@ -69,7 +69,7 @@ a users \emph{utility function} that maps a domain value to a utility value and
 
 A recommender system is a system that gives individualized recommendations to users to guide them through a large space of objects \cite[~ p. 331]{burkeHybridRecommenderSystems2002}.
 
-There are several approaches to recommender systems presented in \cite{felfernigGroupRecommenderSystems2018}, these are: collaborative filtering, \todo[inline]{critiquing-based recommendation,} constraint-based recommendation, content-based filtering and hybrid recommendation.
+There are several approaches to recommender systems presented in \cite{felfernigGroupRecommenderSystems2018}, these are: collaborative filtering, constraint-based recommendation, content-based filtering and hybrid recommendation.
 
 \begin{table}
     \centering    
@@ -94,13 +94,6 @@ Collaborative Filtering can not only be done using users, it can also be item-ba
 \autoref{tab:Foundations:RecommenderSystem:MoviePreferences} shows an example rating matrix. A simple user-based way to calculate a rating would be to use a k-nearest neighbour (kNN) algorithm and then take the average of those ratings. Using this method with $k := 2$ and euclidean distance our closest neighbours are \textit{Lucy} and \textit{Diane} therefore giving us a predicted rating of $4$.  If we use an item based approach instead, we will try to find similar items based on the users rating. An example of similar items here would be \textit{Forest Gump} and \textit{Wall-E} as John and Lucy each have given them the sane rating and Eric's rating is off by one. Using again kNN with $k := 2$ we find that \textit{Forest Gump} and \textit{Wall-E} are the most similar to \textit{Titanic} thereby having a predicted rating of $4.5$.
 However this simple similarity and prediction function does not take into account different distances. For example Lucy's ratings are more similar compared to Eric's than Diane's but Diane's and Lucy's rating is valued the same amount.
 
-\todo[inline]{
-Critiquing-Based Recommendation %\subsection{Critiquing-Based Recommendation}
-Items are recommended and a user can then critique on attributes of the recommendation. Based on that a similar item which does not have those critiques can be recommended. User preferences are implicitly collected this way \cite{knijnenburgEachHisOwn2011}.
-
-With a critique based approach Eric sees a suggestion of watching \textit{The Island} and its attributes. He then can say that he finds this movie has too much action. The critique based recommender will now present a movie that has similar attributes as \textit{The Island} but with less action. For example \textit{Titanic} could be the next suggestion.
-}
-
 \subsection{Constraint-Based Recommendation}
 Hereby filter rules are defined which filter out items that don't fulfil specified rules. A user models their requirements with these rules and thereby gets a list of recommended items. This approach requires deep knowledge about a product because it needs a detailed description of features  \cite[~ p. 12]{felfernigDecisionTasksBasic2018}.
 
@@ -150,11 +143,6 @@ Using our example from \autoref{tab:Foundations:RecommenderSystem:MoviePreferenc
     \item No dependence of historic group preference accuracy 
 \end{itemize}
 
-\todo[inline]{
-    Advantages over Critique-Based Recommendation %\subsubsection{Advantages over Critique-Based Recommendation
-}
-
-
 \subsubsection{Advantages over Constrained-Based Recommendation}
 
 \begin{itemize}
@@ -200,7 +188,6 @@ Using our example from \autoref{tab:Foundations:RecommenderSystem:MoviePreferenc
                     \item Requires domain knowledge
                 \end{itemize} \\
             \hline
-            \todo[inline]{Critique-Based Recommendation } &  \todo[inline]{ todo: positives } &  \todo[inline]{ todo: negatives } \\
             Constraint-Based Recommendation 
             &   \begin{itemize}
                     \item Transparent
@@ -230,9 +217,6 @@ For a group recommender system additional definitions are needed. The attitude o
     P_i = \{(d,\ u_i(d)) \ | \ \forall d \in \mathfrak{D}(i),\ i=1,\dotsc,m \} \notag
 \end{gather}
 
-\todo[inline]{example of a group recommender}
-\todo[inline]{go more into detail about preference aggregation}
-
 
 \FloatBarrier
 

25_Outline/sections/40_concept.tex

@@ -101,10 +101,6 @@ Now the recommendation procedure looks as follows:
     \item Chose the configuration with the highest score as recommendation.
 \end{enumerate}
 
-\todo[inline]{move definitions that are made by me to here}
-
-
-
 \begin{samepage}
 \subsection{Scoring Function}
 \label{subsec:Concept:SolutionGeneration:ScoringFunction}

25_Outline/sections/60_evaluation.tex

@@ -36,7 +36,7 @@ The group score metric is to simply take the score the recommender has given to
 \label{sec:Evaluation:Questions}
 
 \begin{itemize}
-    \item Main Question: How does the group decision differ from the decision of a single decision maker? (random individual)
+    \item Main question: How does the group decision differ from the decision of a single decision maker? (random individual)
     \item How much impact does the configuration state have on the recommendation outcome? (random individual, satisfaction)
     \item How many group members are satisfied by the group decision on average? (satisfaction)
     \item Is the recommender fair, i.e. no user type is always worse off than others? (satisfaction)

30_Thesis/sections/00_introduction.tex

@@ -2,15 +2,37 @@
 \label{ch:Introduction}
 
 \section{Motivation}
-\label{sec:Introduction:Motivation}
+\label{sec:Introduction:Goals}
 
-Product configuration supports companies in their sales process, it reduces costs and decreases time needed to produce an offer for a product \cite{shafieeCostBenefitAnalysis2018}. Usually configuration is done by one user but for complex decisions the risk that a single user will make mistakes increases therefore making the decision in a group can yield better results \cite{felferningGroupBasedConfiguration2016, felfernigGroupDecisionSupport2011}. Unfortunately groups are not immune to group biases and group dynamics that can reduce the benefits of group decisions \cite{kerrBiasJudgmentComparing1996}.
-There exists work on recommender systems for configuration and there are recommender systems for groups but there has not been any work on how to combine these. A recommender system, can help reduce influence of group behaviour and thereby increases the benefit of groups making more rational decisions than individuals \cite{charnessGroupsMakeBetter2012}.
+Customers and sales people are faced with big catalogues that describe how a complex product can be built. These catalogues specify what is possible to combine but it is easy to make mistakes. The sales process takes a long time because orders have to be manually validated. With the advent of mass customization these issues were addressed. Mass customization uses a configurator. The configurator has a rulebook that contains all the attributes of a product, their corresponding characteristics and rules on how these can be combined. A system like that allows to reduce the workload and cost of sales \cite{shafieeCostBenefitAnalysis2018}. "[...] [P]roduct configuration is seen as a team activity with divergent interests" \cite{mendoncaCollaborativeProductConfiguration2008} and therefore research in the field of group-based configuration starts receiving more attention. 
+To give an idea of situations that can use group-based configuration, here are some examples:
+\begin{itemize}
+    \item A company's lorry fleet (e.g. driver, head of procurement, marketing manager)
+    \item A company's customer management software system (e.g. salesperson, human resource manager, accounting manager)
+    \item A public project to get a new area at a zoo (e.g. visitor, director, zoo-keeper)
+    \item Managing a forest (e.g. owner, environmental protection agency, consumer representative)
+    \item An existing company building and how it should be furnished (e.g. landlord, employee representative, CEO)
+\end{itemize}
 
-\section{Research Question}
-\label{sec:Introduction:ResearchQuestion}
-\begin{enumerate}
-    \item How can decision-making in group configuration processes be supported (through recommender systems)? (central question)
-    \item Which requirements do configuration systems for collaborative decision-making have and how could such a system look like?
-    \item How does group hierarchy and structure influence the decision-making process in group based configuration scenarios?
-\end{enumerate}
+Unfortunately, making decisions in a group comes with problems as a lack of communication can lead to worse decision outcomes \cite{atasItemRecommendationUsing2017}. Group dynamics and biases result in suboptimal decisions \cite{kerrBiasJudgmentComparing1996}.
+Generally, group decisions are complex and often the process that yields the decision result is unstructured, thereby not providing any reproducibility of the success. Groups have different power structures and usually individuals have different interests. Moreover, finding solutions is a rather complex task and group decisions can suffer from intransparency.
+
+Group recommenders promise to help with that as they can take individual user preferences and find good compromises for the whole group. They are used in movies, music and travel \cite{garciaGroupRecommenderSystem2009, piliponyte2013sequential, peraGroupRecommenderMovies2013,felfernigGroupRecommenderApplications2018}. The existing literature on recommenders for groups is extensive with many different approaches and domains \cite{delicResearchMethodsGroup2016, chenInterfaceInteractionDesign2011, atasItemRecommendationUsing2017, jamesonRecommendationGroups2007, chenEmpatheticonsDesigningEmotion2014, liuCGSPAComprehensiveGroup2019} but to date there have not been any approaches to combine them with group-based configuration. There have been approaches to combine recommendation techniques with configuration but these were limited to configuration for a single user only \cite{pereiraFeatureBasedPersonalizedRecommender2016, scholzConfigurationbasedRecommenderSystem2017, scholzEffectsDecisionSpace2017}.
+
+
+The above listed examples of use cases for group-based configuration show that ordinary group recommenders cannot be used here as they, unlike configuration, are used for simple products. Configuration on the other hand operates with solutions that are successively built by combining standardized features. This leads to three problems when trying to apply recommenders in this field: first, because of simple combinatorics, the number of variants is enormous. Second, because of the interrelation between features, a small change in configuration can lead to many subsequent changes and, thus, a completely different product. Third, during configuration there is an already pre-existing configuration state that is potentially expensive to change. This could be the current state of a situation for example what a building currently looks like, decisions already made regarding a project that would be expensive to change or simply a part already agreed on at an earlier stage of the project. The group recommender needs to account for these circumstances. Therefore it is necessary to explore new ideas and to take into account knowledge from group recommendation.
+
+\section{Goals of this Thesis}
+\label{sec:Introduction:Goals}
+
+This thesis aims at showing the viability of using group recommenders in a configuration setting by producing and evaluating a prototype. It is discussed what needs to be done to adapt group recommenders to allow usage of the basic recommendation technique of item-based recommendation. The research question for this thesis is the following.
+
+\begin{itemize}
+    \item How can a group recommender translate individual preferences into recommendations that improve the overall satisfaction of group members while considering constraints given by the configuration state? 
+\end{itemize}
+
+
+\section{Structure of this Thesis}
+\label{sec:Introduction:Structure}
+
+This thesis first will give an introduction, then present related work. Next, the concept for a recommender will be presented. Afterwards, design and implementation of the prototype produced in this thesis will be discussed and evaluated. Last, a conclusion will be made which includes a summary and further research possibilities for recommendation techniques in group-based configuration.

30_Thesis/sections/10_foundations.tex

@@ -1,16 +1,47 @@
 \chapter{Foundations}
 \label{ch:Foundations}
 
-Since this thesis focuses on recommender systems to support group decisions in the context of group based configuration it is important to define what we mean by these terms. This chapter describes foundations that sow what a recommender system is, approaches that can be taken and how it is possible to build with these approaches a group recommender. Additionally configuration and group configuration are defined. In group decisions biases can have an effect of the groups decision making ability and some of these are presented here to consider their effect on group decisions. 
+This chapter gives an overview of the foundations this thesis is based upon. It introduces product configuration, shows what group based product configuration looks like, examines recommender systems and basic approaches, describes group recommenders, gives a short introduction to the use case and the prototype that is extended by this thesis.
+
+\section{Product Configuration}
+\label{sec:Foundations:ProductConfiguration}
+
+Product configuration is a process consisting of a series of decision tasks whereby a product is constructed of components which interact with each other. During a configuration process no new components are created. Their interplay and specification is defined beforehand \cite[~ pp. 42, 43]{sabinProductConfigurationFrameworksa1998}. This section defines product configuration analogous to \citeauthor{felfernigOpenConfiguration2014} \cite{felfernigOpenConfiguration2014}.
+
+Formally a configuration problem can be specified as a \emph{constraint satisfaction problem (CSP)} \cite{tsangFoundationsConstraintSatisfaction1993} as 
+\begin{equation} \label{eq:Foundations:ProductConfiguration:ConstraintSatisfactionProblem}
+    CSP(V,\mathfrak{D},C),
+\end{equation}
+where $V$ is a set of \emph{variables} (which in this thesis will also be referred to as \emph{features}) with
+\begin{equation} \label{eq:Foundations:ProductConfiguration:Variables}
+    V = \{v_1, \dotsc, v_m\},
+\end{equation}
+a \emph{domain mapping} $\mathfrak{D}$ that maps variable to their corresponding domain values $D$ (which in this thesis will be also referred to as \emph{characteristics}) i.e. the values that can be assigned to each variable
+\begin{equation}\label{eq:Foundations:ProductConfiguration:DomainMapping}
+    \mathfrak{D} : V \to D; x \mapsto \mathfrak{D}(x) \qquad where \ D = \{d_1, \dotsc, d_o\},
+\end{equation}
+and \emph{constraints} $C$ that limit the solution space with 
+\begin{equation}\label{eq:Foundations:ProductConfiguration:Constraints}
+    C = \{c_1, \cdots, c_k\}.
+\end{equation}
+
+In group-based configuration (also known as collaborative or group configuration) a group instead of a single user is set to configure a product. This entails challenges in terms of synchronising  workspaces and keeping the data consistent for every group member. \citeauthor{raabKollaborativeProduktkonfigurationEchtzeit2019}'s \cite{raabKollaborativeProduktkonfigurationEchtzeit2019} approach, which this thesis extends, is to treat the group configuration the same as one shared configuration and to sync the selection of attributes across clients.
+
+\subsection{Group-Based Product Configuration}
+\label{sec:Foundations:GroupBasedProductConfiguration}
+
+Group-based product configuration is an approach to product configuration where product configuration is done by multiple users. According to \citeauthor{felferningGroupBasedConfiguration2016} \cite{felferningGroupBasedConfiguration2016} considering classical approaches as single user tasks can lead to decisions that are suboptimal. Moreover, there are scenarios where a decision is inherently a group task such as \emph{Holiday Planning}, \emph{Software Release Planning} and \emph{Product Line Scoping}. Group-based configuration takes the representation of a group directly into account.
 
 \section{Recommender System}
 \label{sec:Foundations:RecommenderSystem}
 
 A recommender system is a system that gives individualized recommendations to users to guide them through a large space of objects \cite[~ p. 331]{burkeHybridRecommenderSystems2002}.
 
-There are several approaches to recommender systems presented in \cite{felfernigGroupRecommenderSystems2018}, these are: collaborative filtering, content-based filtering, critiquing-based filtering, constraint-based, hybrid recommendation.
+There are several approaches to recommender systems presented in \cite{felfernigGroupRecommenderSystems2018}, some of them are: collaborative filtering, constraint-based recommendation and content-based filtering. There is also hybrid recommendation which combines approaches but this is not the focus in this thesis.
 
-\begin{table}
+\subsection{Collaborative Filtering}
+
+\begin{table}[b]
     \centering    
     \begin{tabular}{ l | c | c | c | c | c }
         & The Matrix & Titanic & Die Hard & Forest Gump & Wall-E \\ \hline
@@ -19,24 +50,25 @@ There are several approaches to recommender systems presented in \cite{felfernig
          Eric  & 2 & ? & 3 & 5 & 4 \\
          Diane & 4 & 3 & 5 & 3 &   \\
     \end{tabular}
-    \caption{An example showing users ratings for movies by \citeauthor{ningComprehensiveSurveyNeighborhoodBased2015} \cite{ningComprehensiveSurveyNeighborhoodBased2015}.}
-    
+    \caption[Movies: Rating Matrix]{An example showing users ratings for movies by \citeauthor{ningComprehensiveSurveyNeighborhoodBased2015} \cite{ningComprehensiveSurveyNeighborhoodBased2015}. Eric would like to know if he will like the movie Titanic.}  
     \label{tab:Foundations:RecommenderSystem:MoviePreferences}
 \end{table}
 
-\subsection{Collaborative Filtering}
-In collaborative filtering a users rating for unknown items is predicted by finding similar users who have rated it. Their rating is used as prediction
-\cite[~ pp. 7, 8]{felfernigDecisionTasksBasic2018}.
+In collaborative filtering a user's rating for unknown items is predicted by finding similar users who have rated it. Their rating is used as prediction \cite[~ pp. 7, 8]{felfernigDecisionTasksBasic2018}.
 
-Collaborative Filtering can not only be done using users, it can also be item-based. Hereby the similarity between items is used for a recommendation and not similar users \cite{ricciRecommenderSystemsHandbook2015}. In the context of configuration the similarity to other historic configurations can be used which makes it an item based approach. 
+Collaborative Filtering can not only be done using users, it can also be item-based. Hereby the similarity between items is used for a recommendation and not similar users \cite{ricciRecommenderSystemsHandbook2015}.
 
-\autoref{tab:Foundations:RecommenderSystem:MoviePreferences} shows an example rating matrix. A simple user-based way to calculate rating would be now to use a k-nearest neighbour (kNN) algorithm and then take the average of those ratings. Using this method with $k := 2$ and euclidean distance our closest neighbours are \textit{Lucy} and \textit{Diane} therefore giving us a predicted rating of $4$.  If we use item based illustration instead, we will try to find similar items based on the users rating. An example of similar items here would be \textit{Forest Gump} and \textit{Wall-E} as John and Lucy each have given them the sane rating and Eric's rating is off by one. Using again kNN with $k := 2$ we find that \textit{Forest Gump} and \textit{Wall-E} are the most similar to \textit{Titanic} thereby having a predicted rating of $4.5$.
-However this simple similarity and prediction function does not take into account different distances. For example Lucy's ratings are more similar compared to Eric's than Diane's but Diane's and Lucy's rating is valued the same amount.
+\autoref{tab:Foundations:RecommenderSystem:MoviePreferences} shows an example rating matrix for movies. A simple user-based way to calculate a rating would be to use a k-nearest neighbour (kNN) algorithm and then take the average of those ratings. Using this method with $k := 2$ and euclidean distance, Eric's closest neighbours are \textit{Lucy} and \textit{Diane} therefore giving a predicted rating of $4$. An item-based approach will try to find similar items based on the user's rating. Here, an example of similar items would be \textit{Forest Gump} and \textit{Wall-E} as John and Lucy each have given them the same rating and Eric's rating is off by one. Using again kNN with $k := 2$ it is found that \textit{Forest Gump} and \textit{Wall-E} are the most similar to \textit{Titanic} thereby having a predicted rating of $4.5$. However this simple similarity and prediction function does not take into account different distances. For example Lucy's ratings are more similar compared to Eric's than Diane's but Diane's and Lucy's ratings are valued the same.
+
+\subsection{Constraint-Based Recommendation}
+Hereby filter rules are defined which filter out items that do not fulfil specified rules. A user models their requirements with these rules and thereby gets a list of recommended items. This approach requires deep knowledge about a product because it requires a detailed description of features  \cite[~ p. 12]{felfernigDecisionTasksBasic2018}.
+
+The previous movie example (see \autoref{tab:Foundations:RecommenderSystem:MoviePreferences}) requires additional information for example about plot structure, pacing, length and other attributes of the movie. Now the user can enter filtering criteria, e.g. that the movie should be no longer than 120 minutes, be categorized as action or thriller and have a fast pacing. The system will only recommend movies that fit into these constraints.
 
 \subsection{Content-Based Filtering}
-Items and users are assigned to categories. Based on consumption and rating of items a user will have implicit ratings for categories. Predictions are now made based on a categories of the new item \cite[~ pp. 10, 11]{felfernigDecisionTasksBasic2018}.
+For the content-based filtering approach, items and users are assigned to categories. Based on consumption and rating of items a user will have ratings for categories. Predictions are now made based on the categories of a new item \cite[~ pp. 10, 11]{felfernigDecisionTasksBasic2018}.
 
-Using our example from \autoref{tab:Foundations:RecommenderSystem:MoviePreferences} and using an additional category matrix (see \autoref{tab:Foundations:RecommenderSystem:ContentBasedFilteringCategories}) we can derive a rating matrix per category (using the average rating of the user of each movie contained in this category). The result can be seen in \autoref{tab:Foundations:RecommenderSystem:ContentBasedFilteringProfiles}. To predict Eric's rating of Titanic we now can use the categories of \textit{Titanic} and average out Eric's implicit rating per category. Titanic is only in the category romance and as Eric's rating of \textit{Forest Gump} is $5$ the prediction is a rating of $5$. Categories don't have to be the genre, they could be any kind of data about a movie.
+Using the example from \autoref{tab:Foundations:RecommenderSystem:MoviePreferences} and using an additional category matrix (see \autoref{tab:Foundations:RecommenderSystem:ContentBasedFilteringCategories}), a rating matrix per category can be derived (using the average rating of the user of each movie contained in this category). The result can be seen in \autoref{tab:Foundations:RecommenderSystem:ContentBasedFilteringProfiles}. To predict Eric's rating of Titanic, the categories of \textit{Titanic} and averages of Eric's implicit rating per category are used. Titanic is only in the category romance and as Eric's rating of \textit{Forest Gump} is $5$ the prediction is a rating of $5$. Categories do not have to be the genre, they could be any kind of data relating to a movie.
 
 \begin{table}
     \centering    
@@ -48,7 +80,7 @@ Using our example from \autoref{tab:Foundations:RecommenderSystem:MoviePreferenc
          Romance & & x & & x & \\
          Family & & & & x & x \\
     \end{tabular}
-    \caption{Showing example categories for movies in \autoref{tab:Foundations:RecommenderSystem:MoviePreferences}.}
+    \caption[Movies: Category Matrix]{Showing example categories for the movies in \autoref{tab:Foundations:RecommenderSystem:MoviePreferences}.}
     
     \label{tab:Foundations:RecommenderSystem:ContentBasedFilteringCategories}
 \end{table}
@@ -62,75 +94,135 @@ Using our example from \autoref{tab:Foundations:RecommenderSystem:MoviePreferenc
         Eric  & 2.5 & 2 & 3 & 5 & 4.5 \\
         Diane & 4.5 & 4 & 5 & 3 & 3  \\
     \end{tabular}
-    \caption{User profiles generated from categories and rating from \autoref{tab:Foundations:RecommenderSystem:MoviePreferences} and \autoref{tab:Foundations:RecommenderSystem:ContentBasedFilteringCategories}.}
+    \caption[Movies: User Profile Matrix for Genres]{User profiles generated from categories and ratings from \autoref{tab:Foundations:RecommenderSystem:MoviePreferences} and \autoref{tab:Foundations:RecommenderSystem:ContentBasedFilteringCategories}.}
     
     \label{tab:Foundations:RecommenderSystem:ContentBasedFilteringProfiles}
 \end{table}
 
-\subsection{Critiquing-Based Recommendation}
-Items are recommended and a user can then critique on attributes of the recommendation. Based on that a similar item which does not have those critiques can be recommended. User preferences are implicitly collected this way \cite{knijnenburgEachHisOwn2011}.
+Advantages and disadvantages of basic recommendation techniques are listed in \autoref{tab:Foundations:RecommenderComparison}. The following subsections show advantages of content-based filtering over collaborative filtering and over constraint-based recommendation.
 
-With a critique based approach Eric sees a suggestion of watching \textit{The Island} and its attributes. He then can say that he finds this movie has too much action. The critique based recommender will now present a movie that has similar attributes as \textit{The Island} but with less action. For example \textit{Titanic} could be the next suggestion.
+\begin{table}[htb]
+    \begin{center}
+        \begin{tabularx}{\columnwidth}{X|X|X}
+            & advantages & disadvantages \\
+            \hline
+            Collaborative Filtering 
+            &   \begin{itemize}[noitemsep,topsep=0pt,parsep=0pt,partopsep=0pt, leftmargin=3.5mm]
+                    \item Serendipity of results 
+                    \item Automatic learning of market segments
+                    \item No domain knowledge required
+                \end{itemize}
+            &   \begin{itemize}[noitemsep,topsep=0pt,parsep=0pt,partopsep=0pt, leftmargin=3.5mm]
+                    \item Cold start problem for users and items
+                    \item Grey sheep problem
+                    \item Quality based on rating quality
+                    \item Data sparsity
+                    \item Privacy not guaranteed
+                \end{itemize} \\
+            \hline
+            Content-Based Filtering 
+            &   \begin{itemize}[noitemsep,topsep=0pt,parsep=0pt,partopsep=0pt, leftmargin=3.5mm]
+                    \item No community required 
+                    \item User-independent
+                    \item Transparent
+                    \item No item cold start
+                    \item Simplicity
+                    \item Robust
+                    \item Stable to constant influx of new users
+                \end{itemize}
+            &   \begin{itemize}[noitemsep,topsep=0pt,parsep=0pt,partopsep=0pt, leftmargin=3.5mm]
+                    \item Overspecialisation
+                    \item No serendipity
+                    \item User cold start problem
+                    \item Requires domain knowledge
+                \end{itemize} \\
+            \hline
+            Constraint-Based Recommendation 
+            &   \begin{itemize}[noitemsep,topsep=0pt,parsep=0pt,partopsep=0pt, leftmargin=3.5mm]
+                    \item Transparent
+                    \item Good for non-discrete values
+                \end{itemize}
+            &   \begin{itemize}[noitemsep,topsep=0pt,parsep=0pt,partopsep=0pt, leftmargin=3.5mm]
+                    \item Inconsistent constraints
+                    \item No results
+                \end{itemize} \\ 
+        \end{tabularx}
+        \caption[Comparison of Recommendation Approaches]{A description of the advantages and disadvantages of common recommendation techniques \cite{richthammerSituationAwarenessRecommender2018, shokeenStudyFeaturesSocial2019,hahslerRecommenderlabFrameworkDeveloping2015, aminiDiscoveringImpactKnowledge2011, suSurveyCollaborativeFiltering2009}}
+        \label{tab:Foundations:RecommenderComparison}
+    \end{center}
+\end{table}
 
-\subsection{Constraint-Based Recommendation}
-Hereby filter rules are defined which filter out items that don't fulfil specified rules. A user models their requirements with these rules and thereby gets a list of recommended items. This approach requires deep knowledge about a product because it needs a detailed description of features  \cite[~ p. 12]{felfernigDecisionTasksBasic2018}.
+\subsubsection{Advantages over Collaborative Filtering}
 
-Our movie example (see \autoref{tab:Foundations:RecommenderSystem:MoviePreferences}) needs have additional information for example about plot structure, pacing, length and other attributes of the movie. Now the user could give as filter, that the movie should be no longer than 120 minutes, be categorized as action or thriller and have a fast pacing. The system will only recommend movies that fit into these categories.
+Collaborative filtering has several issues that content-based filtering doesn't have. According to \citeauthor{likaFacingColdStart2014} \cite{likaFacingColdStart2014} the \emph{cold start problem} is one of the well-known problems of recommender systems. It occurs when there is sparse information for users or items. In the case of collaborative filtering this issue concerns for both items and users. Content-based filtering does not have that issue with items as they are classified based on similarity to other items. The user cold start problem however still persists when a new user has not yet rated any items. Accordingly, no similar items can be recommended.
 
-\subsection{Hybrid Recommendation}
-A hybrid recommender combines different recommendation approaches to use the strengths of each individual one and to reduce effects of weaknesses \cite{burkeHybridRecommenderSystems2002}.
+Another common issue is the \emph{grey sheep problem} \cite{grasIdentifyingGreySheep2016}. Collaborative filtering approaches assume that users that are similar, have similar preferences. A user that is not similar to any of the current user or community of users fail that assumption. Therefore, good recommendations cannot be made. These users are called \emph{grey sheep users}. Item-based filtering does not have this issue as a user's preference is directly used to find similar items to the ones they like, not similar users.
+Usually, the need for domain knowledge is a disadvantage. However, as product configuration already has domain knowledge baked in to describe features and how they can be combined, this is not a disadvantage and can even be seen as an advantage. Hence, domain knowledge can directly be used and does not first need to be learned indirectly.
+Additionally, a collaborative filtering approach spans a larger comparison space, based on preferences, compared to content-based filtering that only uses the item attributes. Thus, for applications with a large solution space, reliance on product features instead of user similarity should be considered.
+Last, content-based filtering does not depend on historic group preference accuracy. Thus, malicious actors that try to manipulate the recommendation system do not decrease recommendation accuracy. The same is true for inaccurate preferences. For example, this occurs if a user's input into a system does not accurately reflect what they actually like.
+
+\subsubsection{Advantages over Constraint-Based Recommendation}
+
+In constraint-based recommendation approaches it is possible that constraints lead to no possible solution \cite[~ p. 44]{felfernigAlgorithmsGroupRecommendation2018}. This then requires further techniques of constraint relaxing and a user is faced with the situation that they have to search for constraints which fulfil less strict requirements. Moreover, in groups a constraint-based approach has to deal with contrary user constraints. Therefore, diverse groups could have issues with it.
 
 \section{Group Recommender System}
+\label{sec:Foundations:GroupRecommenderSystem}
 
-A group recommender system is a recommender system aimed at making recommendations for a group instead of a single user. To make recommendations group members preferences have to be aggregated. This can be done by either aggregating single user recommendations or by merging preferences of each user into a group preference model. Based on this model recommendation strategies as described in \autoref{sec:Foundations:RecommenderSystem} can be used to generate recommendations \cite{jamesonRecommendationGroups2007}.
+A group recommender system is a recommender system aimed at making recommendations for a group instead of a single user. To make recommendations preferences of all group members have to be aggregated. This can be done by either aggregating single user recommendations or by merging preferences of each user into a group preference model \cite{jamesonRecommendationGroups2007}. Based on the resulting preference model, recommendation strategies can be used to generate recommendations.
 
-\section{Product Configuration}
-\label{sec:Foundations:ProductConfiguration}
+The strategy of aggregating predictions can be further divided into two strategies. \citeauthor{felfernigAlgorithmsGroupRecommendation2018} \cite{felfernigAlgorithmsGroupRecommendation2018} describes merging recommendations and "ranking of candidate items". Merging recommendations can be used when multiple possible solutions are to be presented. The recommender picks $n$ recommendation from each user's individual recommendations and merges them into a list. The second approach is that each user's individual recommender ranks all items. The group member's specific rankings then are aggregated to get a group ranking of items. Instead of ranking it is also possible to simply predict a user's rating for an item.
 
-Product configuration is a process consisting of a series of decision tasks whereby a product is constructed of components which interact with each other. During a configuration process no new components are created. Their interplay and specification is defined beforehand \cite[~ pp. 42, 43]{sabinProductConfigurationFrameworksa1998}.
+The aggregation of preferences uses a merging strategy to combine the individual preferences into group preferences. This allows a group to change its preferences during the course of the decision without changing individual preferences.
 
-Formally a configuration problem can be specified as a \emph{constraint satisfaction problem (CSP)} \cite{tsangFoundationsConstraintSatisfaction1993} as 
-\[
-    CSP(V,D,C)
-\]
-where \( V = \{v_1,\dots, v_n\} \) is a set of variables, \( D = dom : V \mapsto X \) is a relation of variables and their corresponding domain definitions \( X \), and \( C = C_{PREF} \cup C_{KB} \) is a set of constraints with customer preferences \( C_{PREF} \) and configuration knowledge base \( C_{KB} \) \cite{felferningGroupBasedConfiguration2016, felfernigOpenConfiguration2014}.
+Both the approach of merging preferences and the approach of using individual user's rankings require some kind of aggregation strategy. Strategies used in this thesis are: multiplication, average and least misery. The multiplication strategy multiplies preferences of users and thereby combines them into a group preference. Similarly the average strategy takes the average of a rating and the least misery strategy takes the lowest rating among group members. To illustrate the example in \autoref{tab:Foundations:RecommenderSystem:MoviePreferences} is used. Lucy, Eric and Diane form a group. The resulting ratings for each strategy are shown in \autoref{tab:Foundations:RecommenderSystem:AggregationStrategy}.
+
+An additional strategy is the dictatorship strategy. When the dictatorship strategy is used a random group member is chosen. This group member is called the dictator. The decision is made only based on the preference of the dictator. It is omitted from the table as the outcome is dependent on random choice.
+
+\begin{table}
+    \centering    
+    \begin{tabular}{ l | c | c | c | c | c }
+        & The Matrix & Titanic & Die Hard & Forest Gump & Wall-E \\ \hline
+         multiplication  & 8 & - & 30 & 75 & - \\
+         average  & $\frac{7}{3}$ & - & $\frac{10}{3}$ & $\frac{13}{3}$ & - \\
+         least misery  & 1 & - & 2 & 3 & - \\
+    \end{tabular}
+    \caption[Movies: Result Matrix for Group Aggregation Strategies]{An example showing preference aggregation strategies for a group using the data from \autoref{tab:Foundations:RecommenderSystem:MoviePreferences}. Titanic and Wall-E were left out because not all group members have rated these movies.}
+    \label{tab:Foundations:RecommenderSystem:AggregationStrategy}
+\end{table}
 
 
-\section{Group-Based Product Configuration}
-\label{sec:Foundations:GroupBasedProductConfiguration}
+\section{Use Case}
+\label{sec:Foundations:UseSystem}
 
-If instead of a single person configuring a product we would like to have a group of people which can be useful in multi-stakeholder decisions, it needs mechanisms for describing the preferences of multiple people. Therefore we extend the definition of product configuration from (\autoref{sec:Foundations:ProductConfiguration}) to 
-\[ 
-    C_{PREF} = \bigcup 
-PREF_i \]
-with preferences of user \( i \) as \( PREF_i \) \cite{ felferningGroupBasedConfiguration2016}.
+This thesis presents one use case from forestry. It gradually extends this use case wherever needed (see \autoref{subsec:Concept:ReccomendationGeneration:PreferenceScoring}, \autoref{sec:Concept:Illustration} and \autoref{sec:Evaluation:UseCase}) which is why it is not presented in much detail here. The product that is configured is a forest and it has certain features. These range from the amount of trees that are indigenous, climate resilient, or usable to produce wood to the quantity that should be harvested. 
 
-\section{Group-Based Configuration-Solution}
-\label{sec:Foundations:GroupBasedConfigurationSolution}
+\section{Base System}
+\label{sec:Foundations:BaseSystem}
 
-\autoref{sec:Foundations:ProductConfiguration} and \autoref{sec:Foundations:GroupBasedProductConfiguration} expand to a solution of a group-based configuration with the addition of variable assignments
-\[
-    C_{CONF} = \bigcup_{v_i \in V} \{ v_i = x_i \}, \ x_i \in dom(v_i)
-\]
-and where \( C_{CONF} \cup C_{PREF} \cup C_{KB} \) is consistent \cite{ felferningGroupBasedConfiguration2016}.
+This thesis extends a base software system, \emph{CAS Configurator Merlin}, from \emph{CAS Software AG} \cite{CASSoftwareAG}. \citeauthor{raabKollaborativeProduktkonfigurationEchtzeit2019} \cite{raabKollaborativeProduktkonfigurationEchtzeit2019} extends CAS Merlin Configurator in his thesis to allow simultaneous configuration. Here groups of people are able to simultaneously configure a product. If there are any conflicts, a conflict resolution process is started. However the prototype only allows a majority voting approach and does not provide any further group decision support. Also this process only starts upon the selection of an invalid state that gives alternatives and for the main configuration process no recommendation or conflict resolution exists.
 
-\section{Group Bias}
-\label{sec:Foundations:GroupBias}
+The extended architecture is shown in \autoref{fig:Foundations:CollaborativeConfiguratorMerlin}.
+\citeauthor{raabKollaborativeProduktkonfigurationEchtzeit2019} only makes changes to M.Customer which is renamed to \texttt{M.Collab-Customer} and introduces a new component \texttt{M.Collab}.
 
-Groups have biases same as individuals. Some of these stem from individual biases that are transferred to a group and others only occur in group settings. This section covers some of those effects. These effects are described by \citeauthor{felfernigBiasesGroupDecisions2018} \cite{felfernigBiasesGroupDecisions2018}.
+The following list provides a short overview of each component.
 
-\subsection{GroupThink}
+\begin{description}
+    \item[\texttt{M.Core}] provides the base of the configurator. It checks the configuration against all rules in the database, provides possible alternatives if a change invalidates other parts of a configuration. The system relies on a CSP solver for validation and suggestion of alternatives.
+    \item[\texttt{M.Model}] is the editor to create products and rules. These rules can then be uploaded to \texttt{M.Core} .
+    \item[\texttt{M.Collab}] is a node.js server application that communicates with \texttt{M.Core} via REST-API and with \texttt{\texttt{M.Collab-Customer}} via WebSockets. It sits in between \texttt{M.Collab-Customer} and \texttt{M.Core} and handles all processing regarding collaborative configuration.
+    \item[\texttt{M.Collab-Customer}] is the customer facing component. It allows a customer to configure a product or solution and contains the user interface. Actions undertaken in \texttt{M.Collab-Customer} are send to \texttt{M.Collab}.
+\end{description}
 
-The bias called GroupThink occurs, when group members prefer to avoid conflicts instead of being mainly interested in getting the best decision outcome. Alternative options are in these circumstances not analysed close enough \cite{janis1982groupthink}.
-An avoidance strategy for this effect is for leaders to delay stating there opinion until all alternatives have been viewed in detail \citeauthor{felfernigBiasesGroupDecisions2018}. Recommender systems can aid group decision quality through encouraged information exchange as discussed by \citeauthor{atasItemRecommendationUsing2017} in \cite{atasItemRecommendationUsing2017}.
-
-
-\subsection{Anchoring}
-
-The first information provided is relied upon to heavily. In a group setting this can be triggered by the group member to first express their opinion. Often this is triggered if group members see preferences of others too early, therefore recommender systems should not show the rating of other users \cite{cosley2003seeing}.
-
-\subsection{Serial Position Effects}
-
-The serial positioning effects is the effect that users have a higher retention rate of items in a list that are presented first or last and these items are more closely examined \cite{felfernigPersuasiveRecommendationSerial2007,murphyPrimacyRecencyEffects2006}. Additionally to remembering and examining items at the start and the end of a list also the order of items can change the option the user chooses in the end \cite{felfernigBiasesGroupDecisions2018}.
+\begin{figure}[ht]
+    \centering
+    \includegraphics[width=0.6\textwidth]{./figures/20_fountations/MerlinCollaborativeConfigurator.pdf}
+    \caption[Architecture: Collaborative Configurator]{Architecture of Collaborative Configurator Merlin \cite[Fig. 4.3]{raabKollaborativeProduktkonfigurationEchtzeit2019}}
+    \label{fig:Foundations:CollaborativeConfiguratorMerlin}
+\end{figure}
+
+\section{Software Design}
+\label{sec:Foundations:BaseSystem}
+
+In this thesis for the design of the prototype to improve software quality some rules of software engineering will be applied. The usage of \emph{design patterns} \cite{gamma2015design} and the rules of \emph{separation of concern} \cite{de2002importance} and \emph{single responsibility} \cite{martinCleanArchitectureCraftsman2017} are commonly known in the field of software engineering and, therefore, a detailed explanation is omitted here.
 
 

30_Thesis/sections/20_related_work.tex

@@ -1,47 +1,37 @@
 \chapter{Related Work}
 \label{ch:Related_Work}
 
+This chapter presents approaches for group recommenders, group-based configuration systems and recommender systems for configuration. However no literature combines these approaches to get a group recommendation for group-based configuration.
+
 \section{Group Recommender Systems}
 \label{sec:Related_Work:GroupRecommender}
 
 \begin{description}[style=unboxed, leftmargin=0cm, font=\normalfont]
-    \item[\citeauthor{choudharyMulticriteriaGroupRecommender2020}] propose a multi-criteria group recommender system. An analytical hierarchy process is used to learn priorities for film features like story, action, direction and to then make a number of best recommendations for a group of users. Their approach works well for film selection and they observe that it is easier to make recommendations for homogenous groups than for random groups. Also small groups receive better recommendations compared to large ones\cite{choudharyMulticriteriaGroupRecommender2020}.
+    \item[\citeauthor{choudharyMulticriteriaGroupRecommender2020} \cite{choudharyMulticriteriaGroupRecommender2020}] propose a multi-criteria group recommender system. An analytical hierarchy process is used to learn priorities for film features like story, action, direction and to then make a number of best recommendations for a group of users. Their approach works well for film selection and they observe that it is easier to make recommendations for homogenous groups than for random groups. Also small groups receive better recommendations compared to large ones.
 
-    \item[\citeauthor{chenInterfaceInteractionDesign2011}] looks at interface and interaction designs that supports the overall group and does not only consider each user individually. Chen design a music recommendation system \emph{GroupFun} with a focus on groups that tries to enhance mutual awareness and transparency. \citeauthor{chenInterfaceInteractionDesign2011}'s assessment is that this work is still in a preliminary stage  \cite{chenInterfaceInteractionDesign2011}. Further work in that area was conducted by \citeauthor{chenEmpatheticonsDesigningEmotion2014} looking at emotional awareness in groups and how that can be visualised in a user interface \cite{chenEmpatheticonsDesigningEmotion2014}. 
+    \item[\citeauthor{chenInterfaceInteractionDesign2011} \cite{chenInterfaceInteractionDesign2011}] looks at interface and interaction designs that support the overall group and does not only consider each user individually. Chen designs a music recommendation system \emph{GroupFun} with a focus on groups that tries to enhance mutual awareness and transparency. \citeauthor{chenInterfaceInteractionDesign2011}'s assessment is that this work is still in a preliminary stage. Further work in that area was conducted by \citeauthor{chenEmpatheticonsDesigningEmotion2014} \cite{chenEmpatheticonsDesigningEmotion2014} looking at emotional awareness in groups and how this can be visualised in a user interface. 
 \end{description}
 
 \section{Group-Based Configuration}
 \label{sec:Related_Work:GroupBasedConfiguration}
 
 \begin{description}[style=unboxed, leftmargin=0cm, font=\normalfont]
-    \item[\citeauthor{raabKollaborativeProduktkonfigurationEchtzeit2019}] builds a collaborative configurator based on the CAS Merlin Configurator. Here groups of people are able to simultaneously configure a product. If there are any conflicts a conflict resolution process is started. However the prototype only allows a majority voting approach and does not provide any group decision support \cite{raabKollaborativeProduktkonfigurationEchtzeit2019}.
+    \item[\citeauthor{felferningGroupBasedConfiguration2016} \cite{felferningGroupBasedConfiguration2016}] introduce basic definitions of group-based configuration task, show what conflicts can occur, how to deal with inconsistencies in preferences among group members and how to integrate different decision heuristics into this process.
 
-    \item[\citeauthor{felferningGroupBasedConfiguration2016}] introduces basic definitions of group based configuration tasks, shows what conflicts can occur, how to deal with inconsistencies in preferences among group members and how to integrate different decision heuristics into this process \cite{felferningGroupBasedConfiguration2016}.
-
-    \item[\citeauthor{velasquez-guevaraMultiSPLOTSupportingMultiuser2018}] implement a web based simultaneous group-based configuration system that uses constraint programming. Hereby each user configures according to their own preferences and the system proposes a configuration according to different strategies \cite{velasquez-guevaraMultiSPLOTSupportingMultiuser2018}.  
+    \item[\citeauthor{velasquez-guevaraMultiSPLOTSupportingMultiuser2018} \cite{velasquez-guevaraMultiSPLOTSupportingMultiuser2018}] implement a web-based simultaneous group-based configuration system that uses constraints. Hereby each user configures according to their own preferences and the system proposes a configuration according to different strategies. These strategies are maximization of selections (which means finding the solution with the largest number of features selected), minimizing conflicting selections (which means to minimize the inclusion of features that have conflicts) and to prioritize decisions from some users.
 \end{description}
 
 \section{Recommender Systems for Configuration}
 \label{sec:Related_Work:RecommenderSystemsForConfiguration}
 \begin{description}[style=unboxed, leftmargin=0cm, font=\normalfont]
-    \item[\citeauthor{rubinshteynEntwicklungHybridenRecommender2018}] looks at different approaches to recommendation and implements a prototype with CAS Merlin Configurator which uses a hybrid recommender system. His prototype combines constraint-based filtering with collaborative filtering \cite{rubinshteynEntwicklungHybridenRecommender2018}.
+    \item[\citeauthor{falknerRecommendationTechnologiesConfigurable2011} \cite{falknerRecommendationTechnologiesConfigurable2011}] provide an overview of recommendation approaches for configuration to improve usability of configuration systems. They look at feature recommender to recommend which features in a configuration would be useful to have and at value recommender for these features. Additionally they discuss approaches for ranking and recommending explanations for inconsistencies between customers requirements and product rules however they do not provide any recommendations and point towards further needed research.
       
-    \item [\citeauthor{benzMoeglichkeitenIntelligenterEmpfehlungssysteme2017}] uses a constraint based recommender that uses fuzzy logic to relax constraints and thereby reducing the amount of times where the recommender is unable to make recommendations. With his approach a product manager has direct influence on the recommendations. Rules for recommendations hereby are not automatically learned but only manually created and relate to predefined user interest categories \cite{benzMoeglichkeitenIntelligenterEmpfehlungssysteme2017}.
+    \item[\citeauthor{rubinshteynEntwicklungHybridenRecommender2018} \cite{rubinshteynEntwicklungHybridenRecommender2018}] looks at different approaches to recommendation and implements a prototype with CAS Merlin Configurator which uses a hybrid recommender system. His prototype combines constraint-based filtering with collaborative filtering and achieves better results in terms of precision than non-hybrid systems using collaborative filtering and constraint-based recommendation. In terms of recall his hybrid does not surpass the high numbers of constraint-based recommendations but improves upon collaborative-filtering. 
 
-    \item [\citeauthor{ullmannEntwurfUndUmsetzung2017}] implements a recommendation engine that is able to estimate customer budgets, a k-nearest neighbour classifier for finding a base configuration and non-negative matrix factorization combines with nearest neighbour to find configurations for specific users \cite{ullmannEntwurfUndUmsetzung2017}. \par
+    \item [\citeauthor{benzMoeglichkeitenIntelligenterEmpfehlungssysteme2017} \cite{benzMoeglichkeitenIntelligenterEmpfehlungssysteme2017}] uses a constraint based recommender that uses fuzzy logic to relax constraints and thereby reducing the amount of times where the recommender is unable to make recommendations. With his approach a product manager has direct influence on the recommendations. Rules for recommendations hereby are not automatically learned but only manually created and relate to predefined user interest categories.
 
-    \item[\citeauthor{wetzelPersonalisierterUndLernender2017}] combines collaborative filtering and click-stream analysis. For collaborative filtering he implements three filtering algorithms: k-nearest neighbour, weighted majority voting and non-negative matrix factorization. Collaborative filtering is used to find configurations that are similar to the current configuration. Click-stream analysis is done by using n-grams and the Smith-Waterman algorithm. \citeauthor{wetzelPersonalisierterUndLernender2017} also tries to use click-stream data in combination with Markov chains to give recommendations on how configuration options should be ordered in a configuration form \cite{wetzelPersonalisierterUndLernender2017}.
+    \item [\citeauthor{ullmannEntwurfUndUmsetzung2017} \cite{ullmannEntwurfUndUmsetzung2017}] implements a recommendation engine that is able to estimate customer budgets, a k-nearest neighbour classifier for finding a base configuration and non-negative matrix factorization combined with nearest neighbour to find configurations for specific users. \par
 
-    \item[\citeauthor{falknerRecommendationTechnologiesConfigurable2011}] provide an overview of recommendation approaches for configuration to improve usability of configuration systems. They look at feature recommender to recommend which features in a configuration would be useful to have and at value recommender for these features. Additionally they discuss approaches for ranking and recommending explanations for inconsistencies between customers requirements and product rules \cite{falknerRecommendationTechnologiesConfigurable2011}.
-\end{description}
-
-\section{Group Dynamics and Bias}
-\label{sec:Related_Work:GroupDynamicsAndBias}
-
-\begin{description}[style=unboxed, leftmargin=0cm, font=\normalfont]
-    \item[\citeauthor{charnessGroupsMakeBetter2012}] study group decision-making in the context of classical game-theoretic games. They find that groups act more rational in these contexts but also note that this can lead to decisions that sacrifice social welfare towards individual gain. They also note that diversity increases effectiveness of the group if the environment is of participatory nature in an environment that allows expression of diverse ideas \cite{charnessGroupsMakeBetter2012}.
-    \item[\citeauthor{bonnerEffectsMemberExpertise2002}] study the effects of expertise on group decision-making and performance. The look at an easy and a moderately difficult version of the game Mastermind. The results show that provided performance ratings for each group members helped groups use that expertise as group members gave more weight to high performing member's opinions. This effect was only visible when looking at the moderately difficult task. Using experts in groups caused them to perform significantly better than individuals. In their conclusion \citeauthor{bonnerEffectsMemberExpertise2002} note that expertise should be taken into account when modelling group decision-making \cite{bonnerEffectsMemberExpertise2002}.
-    \item[\citeauthor{atasItemRecommendationUsing2017}] look at how the diversity of recommendations in a group decision scenario effects information exchange among group members. In the conducted study participants chose exam topics in a group. They had support by a system that aids group decisions. A noticeable result was that increased recommendation diversity lead to greater information exchange in groups \cite{atasItemRecommendationUsing2017}. 
-    \item[\citeauthor{felfernigBiasesGroupDecisions2018}] give an overview over biases that occur in groups. Additionally they provide some measures to reduce these biases. The presented biases range from biases that are also prevalent in individuals to biases that only effect groups \cite{felfernigBiasesGroupDecisions2018}.
+    \item[\citeauthor{wetzelPersonalisierterUndLernender2017} \cite{wetzelPersonalisierterUndLernender2017}] combines collaborative filtering and click-stream analysis. For collaborative filtering he implements three filtering algorithms: k-nearest neighbour, weighted majority voting and non-negative matrix factorization. Collaborative filtering is used to find configurations that are similar to the current configuration. Click-stream analysis is done by using n-grams and the Smith-Waterman algorithm. \citeauthor{wetzelPersonalisierterUndLernender2017} also tries to use click-stream data in combination with Markov chains to give recommendations on how configuration options should be ordered in a configuration form but click-streams do not yield any improvements in terms of accuracy and recall.
 \end{description}
 

30_Thesis/sections/30_problem_and_objectives.tex

@@ -1,2 +0,0 @@
-\chapter{Problem Identification and Solution Objectives}
-\label{ch:ProblemAndObjectives}

30_Thesis/sections/40_concept.tex

@@ -1,54 +1,301 @@
 \chapter{Concept}
 \label{ch:Concept}
 
-\section{CAS Configurator Merlin}
-\label{sec:Concept:ConfiguratorMerlin}
+In this chapter definitions from \autoref{ch:Foundations} are extended, requirements formulated and assumptions made. Later, user interaction with the recommender system is described and the case study presented. Moreover, the process of generating recommendations is formulated and described. Last, the concept is illustrated using an example.
 
-\autoref{fig:Concept:ConfiguratorMerlin} shows the architecture of CAS Configurator Merlin.
-\begin{description}
-    \item[M.Core] provides the base of the configurator it checks configuration against all rules in the database, provides possible alternatives on a change that invalidates other parts of a configuration.
-    \item[M.Model] is the editor to create products and rules. These rules can then be uploaded to M.Core.
-    \item[M.Customer] is the customer facing component. It allows a customer to configure a product.
-\end{description}
+\section{Extension of Foundations}
+\label{sec:Concept:ExtensionOfFoundations}
 
-\begin{figure}
+The definitions described in \autoref{ch:Foundations} need to be extended for this thesis. This section adds definitions that are required.
+
+\subsection{Configuration State}
+
+A \emph{configuration} $S$ will be defined as a tuple of variables (\autoref{eq:Foundations:ProductConfiguration:Variables}) and their corresponding domain value with
+\begin{equation} \label{eq:Foundations:ProductConfiguration:ConfigurationState}
+    S = \{ (v_i,\ d) \ |\ v_i \in V \ \land \ d \in \mathfrak{D}(i),\ i=1,\dotsc,m \}.
+\end{equation}
+Essentially it is a set of variables and assigned values.
+
+\subsection{Finished Configuration}
+To define what a \emph{finished configuration} is, it is necessary to first define what it means for a configuration to be valid. Therefore $is\_valid$ is defined as
+\begin{equation} \label{eq:Foundations:ProductConfiguration:IsValid}
+    is\_valid : S \to \{true, false\}; x \mapsto 
+    \begin{cases}
+        true, & S \in solution\_space \\
+        false, & \text{otherwise}
+    \end{cases},
+\end{equation}
+with $solution\_space$ being the solution space of the corresponding constraint satisfaction problem. A \emph{finished configuration} $S_F$ is a configuration that contains all variables and is a valid configuration:
+\begin{equation} \label{eq:Foundations:ProductConfiguration:FinishedConfiguration}
+    S_F \subset S,\ where \ \forall v_i \in V (\exists (v_i, d) \in S_F : d \in \mathfrak{D}(i)) \land is\_valid(S_F).
+\end{equation}
+In practice, a finished configuration of a product is something that is ready to be produced. For example if a car is being configured, this means that the car can be produced in the specified way given by the finished configuration.
+
+
+\subsection{Group-Based Product Configuration}
+\label{sec:Foundations:GroupBasedProductConfiguration}
+
+Instead of a single person configuring a product, a group of people configures one product which can be useful in multi-stakeholder decisions. This setting needs mechanisms for describing the preferences of multiple people. Thus, a set of users $U$ will be introduced with
+\begin{equation}\label{eq:Foundations:ProductConfiguration:Users}
+    U = \{1, \dotsc, n\},
+\end{equation}
+and a user's \emph{utility function} that maps a domain value to a utility value and is only known to the user
+\begin{equation}
+    \begin{split}
+        u_i(d_j), \qquad \text{where}\ & u_i(d_j) \in [0,1] \\
+        & d_j \in  \mathfrak{D}(j),\\
+        & 1 \leq j \leq m, \\
+        & 1 \leq i \leq n.
+    \end{split}
+\end{equation}
+
+\subsection{Group Recommender}
+
+For a group recommender system additional definitions are required. The attitude of users is represented by their preferences $P$ which are directly related to how the user benefits from a domain value being present in the configuration. Let 
+\begin{gather} \label{tab:Foundations:GroupRecommenderSystem:Preferences}
+    P = \{ P_1, \dotsc, P_n\},\ \text{where} \\
+    P_i = \{(d,\ u_i(d)) \ | \ \forall d \in \mathfrak{D}(i),\ i=1,\dotsc,m \} \notag
+\end{gather}
+
+
+\section{Requirements}
+\label{sec:Concept:Requirements}
+
+This section lists requirements that are considered and implemented in this thesis by the group-based configurator, including the recommendation system.
+
+\begin{itemize}
+    \item Mandatory:
+        \begin{itemize}
+            \item The recommender should support a continuous value range for preferences
+            \item The recommendation engine can be used without proprietary software.
+            \item Give recommendations to a group, based on their preferences and the current configuration state.
+            \item The system supports multiple group configurators at the same time.
+            \item The system should take the current configuration state into account.
+
+            \item Recommendations should always be valid solutions.
+            \item The system has to respond in a timely manner.
+        \end{itemize}
+    \item Optional:
+        \begin{itemize}
+            \item Provide a simple user interface.
+            \item The system should be able to work with other configuration systems.
+            \item Recommendations should allow different scoring functions.
+        \end{itemize}
+\end{itemize}
+
+
+\section{Assumptions}
+\label{sec:Concept:Assumptions}
+
+Due to the fact that a thesis has limited resources, some assumptions have to be made. The assumptions made are listed in this section.
+
+\begin{itemize}
+    \item Only one product/solution is supposed to be configured at the same time by one group.
+    \item Features only support single value attributes.
+    \item The configuration is started after all group members are present.
+    \item Speed and optimization of the system does not have high priority.
+    \item The user interface is for demo purposes.
+\end{itemize}
+In order to reduce complexity, the assumptions are made that only single value attributes are supported and one product is configured at a time by a group. Consequently, less implementation work is needed. However, results are not dependent on these implementations. Most features use only single value attributes. It is also possible to model a feature that supports multiple attributes. As an example the feature \emph{audio system} has the following options: \emph{Bluetooth} or \emph{CD}. To allow multiple attributes to be selected the characteristics \emph{Bluetooth and CD} can be added.
+The assumption that users join the system and only start configuring once all members of the group joined is made to reduce the amount of work needed for creating a lobby and waiting system which is not relevant for showing the functionality of the recommender. Speed and optimization of the system having no high priority as the speed has no influence on the results of this thesis. Therefore, as long as the system is fast enough, no further optimisation of speed is needed.
+The evaluation is done solely with the recommender system and its APIs. Thus, the user interface is not directly relevant for the evaluation but it is relevant for communication of results.
+
+\section{Case Study}
+\label{sec:Concept:CaseStudy}
+
+The case study used in this thesis is a simplified version from forestry.
+The used characteristics and attributes are shown in \autoref{fig:Concept:ForestExample}. Additionally, as examples preferences, a configuration state and a finished configuration are given.
+
+\newpage
+
+\section{User Interaction with the System}
+\label{sec:Concept:UserSystemInteraction}
+
+There is one main way to use the system which is defined in \autoref{tab:Concept:MainUseCase}. This process is also visualized in \autoref{fig:Concept:ConfigurationProcess}. All users start the configuration process together.
+They select the current state at the beginning of the process. Then users repeatedly enter their preferences until each user's preferences have been entered into the system. Based on the entered preferences the system generates a recommendation that is a compromise of all users preferences.
+
+\begin{table}[htb]
+    \begin{center}
+        \begin{tabularx}{\columnwidth}{l|X}
+            \multicolumn{2}{c}{Main System Usage} \\
+            \hline
+            Preconditions   & 
+                \begin{itemize}
+                    \item The configurator is opened on each of the group member's machines
+                    \item The configuration is in an unfinished state (this state is a consensus state)
+                \end{itemize} \\
+            \hline
+            Postcondition   & 
+                \begin{itemize}
+                    \item All users have entered their preferences for each attribute explicitly.
+                    \item The system gives a recommendation based on all preferences and the unfinished configuration state
+                \end{itemize} \\
+            \hline
+            Basic Flow      & 
+                \begin{enumerate}
+                    \item A user indicates a preference for an attribute
+                    \item The system generates a recommendation (based on preferences and configuration status)
+                    \item If not all users have given their preferences go to step 1.
+                \end{enumerate} \\
+            \hline
+        \end{tabularx}
+        \caption[Main System Usage]{A description of the main way users will interact with the system}
+        \label{tab:Concept:MainUseCase}
+    \end{center}
+\end{table}
+
+\begin{figure}[htb]
     \centering
-    \includegraphics{./figures/40_concept/MerlinConfigurator.pdf}
-    \caption{Architecture of Configurator Merlin \cite[Fig. 4.1]{raabKollaborativeProduktkonfigurationEchtzeit2019}}
-    \label{fig:Concept:ConfiguratorMerlin}
+    \includegraphics[width=1\textwidth]{./figures/40_concept/bpmn_configuration_process_with_continious_recommendation.pdf}
+    \caption[Configuration Process]{A BPMN diagram of the configuration process.}
+    \label{fig:Concept:ConfigurationProcess}
 \end{figure}
 
-\section{CAS Group-Configurator}
-\label{sec:Concept:GroupConfigurator}
+\section{Recommendation Generation}
+\label{sec:Concept:SolutionGeneration}
 
-\citeauthor{raabKollaborativeProduktkonfigurationEchtzeit2019} extends CAS Merlin Configurator in his thesis to allow simultaneous configuration. The extended architecture is shown in \autoref{fig:Concept:CollaborativeConfiguratorMerlin}.
-He only makes changes to M.Customer which is renamed to M.Collab-Customer and introduces a new component M.Collab.
+This section describes how recommendations are generated. The recommender system has a database that stores possible finished configurations and the goal is to rank these recommendations according to a scoring function and to recommend the best possible configuration. The scoring function is referred to as the \emph{group configuration scoring function}. It uses the current configuration state, the preferences of the group and a finished configuration to calculate a score. This score resembles how good this configuration resembles the interest of the group. The exact procedure looks as follows:
 
-\begin{description}
-    \item[M.Collab] is a node.js server application that communicates with M.Core via REST-API and with M.Collab-Customer via WebSocket. It sits in between M.Collab-Customer and M.Core and handles all processing regarding collaborative configuration.
-    \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.
-\end{description}
+\begin{enumerate}
+    \item Assign a score to each stored configuration according to $$score_{group}(\overline{configurationState},\ \overline{preferences}, \ configurationInStore)$$
+    \item Chose the configuration with the highest score as recommendation.
+\end{enumerate}
 
-\begin{figure}
-    \centering
-    \includegraphics{./figures/40_concept/MerlinCollaborativeConfigurator.pdf}
-    \caption{Architecture of Collaborative Configurator Merlin \cite[Fig. 4.3]{raabKollaborativeProduktkonfigurationEchtzeit2019}}
-    \label{fig:Concept:CollaborativeConfiguratorMerlin}
+It is optionally possible to have multiple runs with different scoring functions. This, for example, allows the removal of configurations that cause a lot of misery.
+
+
+
+\subsection{Scoring Function}
+
+\label{subsec:Concept:SolutionGeneration:ScoringFunction}
+
+The \emph{group configuration scoring function} includes preferences and current configuration state. This function gives a score for a finished configuration (while using the current configuration state and all user preferences):
+\begin{equation}
+    score_{group}: S \times P \times S_F \to \mathbb{R}
+\end{equation}
+
+An example group configuration scoring function is $score_{group}$ defined as
+\begin{equation}
+    score_{group}(\overline{s},\ \overline{p},\ s) \coloneqq 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$ (see \ref{subsec:Concept:ReccomendationGeneration:PreferenceScoring} and \ref{subsec:Concept:ReccomendationGeneration:Penalty}). 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.
+
+\subsection{Preference Scoring}
+\label{subsec:Concept:ReccomendationGeneration:PreferenceScoring}
+
+All of the aggregation functions mentioned in \autoref{subsec:Concept:SolutionGeneration:ScoringFunction} have one preference per product. For configuration where a preference for all characteristics 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.
+
+A simple scoring function approach is to use the preference for each characteristic that is part of the configuration and then use the average. This approach is 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 simple to understand and to calculate. However, if needed, for example, to give one group member more power, it allows relative weighting. 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 are 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 formula for this rating function looks as follows:
+
+\begin{equation}
+    score(\overline{p},\ s) = aggr( \ \{score_{user}(P_i, s) \ | \ P_i \in \overline{p} \} \ )
+\end{equation}
+where $aggr$ is the aggregation function and $score_{user}(P_i, s)$ is the configuration score of user $i$ which is defined as
+\begin{equation}
+    score_{user}(P_i, s) = average(\{x \ | \ (characteristic, x) \in P_i \land characteristic \in s \}) \notag . 
+\end{equation}
+
+
+\begin{figure}[htb]
+    \begin{mdframed}[
+        nobreak=true,
+        frametitle={Example for Forestry Use Case},
+        linecolor=black, 
+        frametitlerulecolor=black, 
+        frametitlebackgroundcolor=gray!5
+    ]
+        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} \},
+            \end{split} \notag \\
+            \mathfrak{D}(\textit{indigenous}) =  \{ & \text{low}, \text{moderate}, \text{high}\}, \notag \\
+            \mathfrak{D}(\textit{resilient}) = \{ & \text{low}, \text{moderate}, \text{high}\}, \notag \\
+            \mathfrak{D}(\textit{usable}) = \{ & \text{low}, \text{moderate}, \text{high}\}, \notag \\
+            \mathfrak{D}(\textit{effort}) = \{ & \text{manual}, \text{harvester}, \text{autonomous}\}, \notag \\
+            \mathfrak{D}(\textit{quantity}) = \{ & \text{low}, \text{moderate}, \text{high}\}, \notag \\
+            \mathfrak{D}(\textit{price}) = \{ & \text{low}, \text{moderate}, \text{high}\}, \notag\\
+            \mathfrak{D}(\textit{accessibility}) = \{ & \text{low}, \text{moderate}, \text{high}\},\notag \\
+            U = \{ & 1,2\} \notag\\
+            P = \{ & P_1, P_2\} \notag\\
+            \begin{split}
+                P_1 = \{ & (\text{manual}, 0.8), (\text{harvester}, 0.3) \} \\ 
+                & \cup \{ (d,0.5)\ |\ d \in \mathfrak{D}(i),\ i \in V,\ i \notin \{ \text{manual}, \text{harvester}\} \ \} \ 
+            \end{split} \notag \\
+            P_2 = \{ & (d,0.5)\ |\ d \in \mathfrak{D}(i),\ i \in V \} \notag \\
+            S  =  \{ & (\textit{indigenous}, \text{low}), (\textit{quantity}, \text{moderate}) \} \notag \\
+            \begin{split}
+            S_F  =  \{ & (\textit{indigenous}, \text{low}), (\textit{resilient}, \text{low}), (\textit{usable},\text{low}), (\textit{effort}, \text{manual}), \\
+            & (\textit{quantity}, \text{low}), (\textit{price},\text{high}),(\textit{accessibility}, \text{low}) \} 
+            \end{split} \notag
+        \end{align}
+    \end{mdframed}
+    \caption[Forestry Use Case]{An example of use case in forestry that includes two people.}
+    \label{fig:Concept:ForestExample}
 \end{figure}
 
+The example in \autoref{fig:Concept:ForestExample} contains two users. The first user has preferences for the characteristic \emph{manual} of the feature with $0.8$ and the characteristic \emph{harvester} of the same feature with $0.3$. All other characteristics have a preference of $0.5$. The second user's preferences are $0.5$ for all characteristics. The finished configuration that is supposed to be rated in this example contains the characteristics \emph{low} for each feature except for \emph{effort} and \emph{quantity} which are set to \emph{manual} and \emph{high}. The score fore the finished configuration $S_F$ of user one is $0.54$. This score is the average of all seven features. User one rates all characteristics of all features as $0.5$ except two characteristics for \emph{effort}. Thus, all feature scores for this user are $0.5$ except the score for \emph{effort} is $0.8$ because of the user's preference of $0.8$ for the characteristic \emph{manual}. The resulting average score per feature of $0.54$ is the user's score for this configuration. User two rates all characteristics with $0.5$ therefore the resulting average is $0.5$.
+The group configuration score is dependent on the used aggregation strategy. Multiplication results in a score of $0.54 \cdot 0.5 = 0.27$. The score for average is $\frac{1}{2}(0.54 + 0.5) = 0.52$ and for least misery $\min \{0.54, 0.5\} = 0.5$.
 
-\section{Extended Configurator}
-\label{sec:Concept:ExtendedConfigurator}
+\subsection{Configuration Change Penalty}
+\label{subsec:Concept:ReccomendationGeneration:Penalty}
 
-Extending \citeauthor{raabKollaborativeProduktkonfigurationEchtzeit2019} work a module called M.Recommender is added. Its aim is to provide a recommendation server that holds all the data needed for recommendations. M.Collab and M.Collab-Customer have to be modified to allow taking in preferences and to show  recommendations. The recommender engine is set up to be in a separate system which allows the easier replacement and the usage of different technologies. The extended architecture is shown in \autoref{fig:Concept:RecommenderForCollaborativeConfiguratorMerlin}.
+This thesis proposes the following penalty function which gives the percentage of characteristics that exist in the configuration that is to be rated. This value can be tuned to be more or less strict by potentiating. This is done by selecting different values for $\alpha$, thereby, allowing more deviation or less deviation from the current configuration state. The penalty function is defined as
+\begin{equation}
+    \notag \alpha \in \mathbb{R}, \qquad     unchanged(d,\overline{s}, s) = 
+    \begin{cases}
+      1, & d \in \overline{s} \land d \in s \\
+      0, & \text{otherwise}
+    \end{cases}
+\end{equation}
+
+\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}
+In essence the function checks the number of unchanged characteristics and divides this by the number of characteristics that are in the current configuration state. The result is the proportion of unchanged characteristics when comparing the current configuration state to the finished configuration.
+
+By including the current configuration state, the scoring function can take into account that some characteristics have already been realized and accordingly might be very costly to change. A higher $\alpha$ resembles a higher cost of change and an alpha of zero represents no costs for changes.
+
+\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 (see \autoref{tab:Concept:UseCaseRating}). \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 from $S_{F1}$ in only one characteristic that is chosen differently. As aggregation strategy the \emph{average} metric is used (see \autoref{sec:Foundations:GroupRecommenderSystem}). The parameter $\alpha$ (see \autoref{subsec:Concept:ReccomendationGeneration: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.
+
+\begin{table}[htb]
+    \tiny
+    \begin{tabularx}{\columnwidth}{C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|}
+        & \multicolumn{3}{c|}{\textit{indigenous}} & \multicolumn{3}{c|}{\textit{resilient}} & \multicolumn{3}{c|}{\textit{usable}} & \multicolumn{3}{c|}{\textit{effort}} & \multicolumn{3}{c|}{\textit{quantity}} & \multicolumn{3}{c|}{\textit{price}} & \multicolumn{3}{c|}{\textit{accessibility}} \\
+        \rotatebox[origin=c]{90}{\ preferences} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{manual} & \rotatebox[origin=c]{90}{harvester} & \rotatebox[origin=c]{90}{autonomous} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} \\
+        \hline
+        $P_1$   & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & \textbf{0.1} & \textbf{0.7} & \textbf{0.9} & \textbf{0.6} & \textbf{0.8} & \textbf{0.2} & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 \\
+        $P_2$   & \textbf{0.1} & \textbf{0.6} & \textbf{0.9} & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & \textbf{0.8} & \textbf{0.3} & \textbf{0.1} & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 & 0.5 \\
+    \end{tabularx}
+    \caption[Forestry Use Case: Example Preferences]{A table showing the preferences of an example for this section.}
+    \label{tab:Concept:UseCaseRating}
+\end{table}
+
+\begin{table}[htb]
+    \tiny
+    \begin{tabularx}{\columnwidth}{C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|}
+        & \multicolumn{3}{c|}{\textit{indigenous}} & \multicolumn{3}{c|}{\textit{resilient}} & \multicolumn{3}{c|}{\textit{usable}} & \multicolumn{3}{c|}{\textit{effort}} & \multicolumn{3}{c|}{\textit{quantity}} & \multicolumn{3}{c|}{\textit{price}} & \multicolumn{3}{c|}{\textit{accessibility}} \\
+        \rotatebox[origin=c]{90}{\ configuration} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{manual} & \rotatebox[origin=c]{90}{harvester} & \rotatebox[origin=c]{90}{autonomous} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} \\
+        \hline
+        $S_{\ \ }$         & - & \pmb{\checkmark} & - & - & \pmb{\checkmark} & - & - & - & - & - & - & - & - & - & - & - & - & - & - & - & - \\
+        $S_{F1}$    & - & \pmb{\checkmark} & - & - & \pmb{\checkmark} & - & - & \checkmark & - & \pmb{\checkmark} & - & - & - & - & \checkmark & - & \checkmark & - & \checkmark & - & - \\
+        $S_{F2}$    & - & \pmb{\checkmark} & - & - & - & \pmb{\checkmark} & - & \checkmark & - & \pmb{\checkmark} & - & - & - & - & \checkmark & - & \checkmark & - & \checkmark & - & - \\
+        $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[Forestry Use Case: Example Configurations]{The current configuration state $ S $ and the stored finished configurations $ S_{Fi} $.}
+    \label{tab:Concept:UseCaseConfigurations}
+\end{table}
+
+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 are the same, with a value of $0.55$, as both users have rated them at $0.5$ but since $S_{F2}$ deviates from the configuration state there will be a penalty. There are two characteristics in the configuration state $S$, therefore, the penalty is $(\frac{1}{2})^\alpha = (\frac{1}{2})^1 = 0.5$. This means the score of $S_{F2}$ is half of $S_{F1}$, resulting in a final score of $0.275$ compared to $0.55$.
+
+The only difference between $S_{F1}$ and $S_{F3}$ is that $S_{F3}$ changes the selection for the feature \emph{effort}. The characteristic \emph{manual} is chosen in $S_{F1}$ and the characteristic \emph{harvester} for $S_{F3}$. The individual score for user one increases as they prefer \emph{harvester} with $0.8$ over \emph{manual} with $0.6$. However, user two has an individual score reduction as their score changes from $0.8$ for \emph{manual} to $0.3$ for \emph{harvester}. The larger decrease in the score of user two causes a decrease in the overall score when comparing  $S_{F1}$ to $S_{F3}$ with a score of $0.55$ to $0.53$. The scores for both users are closer together for $S_{F1}$. However, this does not necessarily have to be the case if the preference of user two for harvester were to change to $0.6$ because then both configurations would have the same score. A different user preference aggregation strategy can change that.
+
+Last, $S_{F1}$ and $S_{F4}$ differentiate in terms of the characteristic choice for the feature \emph{indigenous}. The switch from \emph{moderate} to \emph{high} when changing from $S_{F1}$ to $S_{F4}$ causes an increase in the individual scoring function of user two. This is caused because her preference for \emph{moderate} is $0.6$ and for \emph{high} is $0.9$. This results in a score of $0.57$ for $S_{F4}$. Yet, the change that causes the preference scoring function to give a higher score entails a penalty as the characteristic \emph{high} is not part of the configuration state. This penalty causes the overall score to drop to $0.29$ compared to the score of $S_{F1}$ with $0.55$.
 
-\begin{description}
-    \item[M.Recommender] is a new system that will get queried from M.Collab for recommendations, when the configuration changes. M.Recommender will return recommendations which then can be presented to users by M.Collab-Customer.
-\end{description}
  
-\begin{figure}
-    \centering
-    \includegraphics{./figures/40_concept/MerlinCollabRecommender.pdf}
-    \caption{Architecture of Collaborative Configurator Merlin with an added recommender system.}
-    \label{fig:Concept:RecommenderForCollaborativeConfiguratorMerlin}
-\end{figure}

30_Thesis/sections/50_design_and_implementation.tex

@@ -0,0 +1,97 @@
+\chapter{Design and Implementation}
+\label{ch:DesignImplementation}
+
+This thesis requires a group configuration system with a recommender. In this thesis a modified version of \emph{CAS Configurator Merlin} \cite{IndustrySpecificProduct2020} is used that has been developed by \citeauthor{raabKollaborativeProduktkonfigurationEchtzeit2019} \cite{raabKollaborativeProduktkonfigurationEchtzeit2019}. The base system is described in \autoref{sec:Foundations:BaseSystem}.
+
+For this thesis \texttt{M.Collab} and \texttt{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:UserInterface}. It is extended by adding a preference slider that works in the interval $[0,1]$. The user receives feedback on what a value means based on the thumb position. The thumb rotates from thumbs-down to neutral to thumbs-up based on the selected value. Also functionality to show other participants in the session was added.
+\begin{figure}[htb]
+    \centering
+    \includegraphics[width=0.8\textwidth]{./figures/50_design_and_implementation/user_interface_prototype.png}
+    \caption[User Interface]{The user interface of the prototype, seen by one user while configuring with three other people. The circles in the top left represent the users that are connected in the current sessions. The current configuration state is shown by the characteristics coloured in red. Recommendations are surrounded with a green border.}
+    \label{fig:DesignImplementation:UserInterface}
+\end{figure}
+
+
+\section{Microservice}
+\label{sec:DesignImplementation:Microservice}
+
+An existing base system can be extended in different directions. As \texttt{M.Collab} already functions as middleman between \texttt{M.Collab-Customer} and \texttt{M.Core} , one solution would be to add recommender functionality to \texttt{M.Collab-Customer}. However, this approach would conflict with the \emph{single responsibility} \cite{martinCleanArchitectureCraftsman2017} and \emph{separation of concern} \cite{de2002importance} software design principles. It would change \texttt{M.Collab} from a system that works similar to a router to one that additionally handles  recommendations. \texttt{M.Collab} manages communication between \texttt{M.Collab-Customer} instances and between \texttt{M.Core} and \texttt{M.Collab-Customer}. Thus this solution was discarded.
+
+Another viable solution is adding the recommendation functionality to \texttt{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, as a result the extension would require a large effort.
+
+
+\begin{figure}[tb]
+    \centering
+    \includegraphics[width=0.55\textwidth]{./figures/50_design_and_implementation/MerlinCollabRecommender.pdf}
+    \caption[Architecture: Recommender System and Configurator]{The architecture of the extended recommender system based on \citeauthor{raabKollaborativeProduktkonfigurationEchtzeit2019}'s configurator (see \autoref{fig:Foundations:CollaborativeConfiguratorMerlin}). The changes include the addition of the component \texttt{M.Recommend} and the recommender database. Changes are marked in grey. Components that have a grey background are added and components with a partial grey background undergo changes.}
+    \label{fig:DesignImplementation:RecommenderForCollaborativeConfiguratorMerlin}
+\end{figure}
+
+Due to these reasons it was decided to create a new microservice (see \autoref{fig:DesignImplementation:RecommenderForCollaborativeConfiguratorMerlin}), called \texttt{M.Recommend} which communicates with \texttt{M.Collab}, and thereby it is 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 component \texttt{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 with multiple configurator instances. This is an advantage in the age of automatically scaling systems.
+
+
+\section{API}
+\label{sec:DesignImplementation:API}
+
+The API used for the recommender is a REST-API. REST allows the flexible addition of new endpoints thereby making the system easy to extend.
+When a recommendation is supposed to be generated, \texttt{M.Collab} sends a HTTP-POST-request to M.Recommend (see \autoref{fig:DesignImplementation:SequenceDiagramRecommendation}). This request contains preferences and the current configuration. \texttt{M.Recommend} generates a recommendation based on the received data as a response. The recommended finished configuration is now sent from  \texttt{M.Collab} via broadcast over WebSockets to all M.Customer clients. 
+
+\begin{figure}[b]
+    \centering
+    \includegraphics[width=0.95\textwidth]{./figures/50_design_and_implementation/sequence_diagram_generating_recommendation.pdf}
+    \caption[Sequence Diagram: Recommendation Generation]{A sequence diagram showing the recommendation process.}
+    \label{fig:DesignImplementation:SequenceDiagramRecommendation}
+\end{figure}
+
+The REST API defines the following Endpoints and uses \emph{JSON} \cite{IntroducingJSON}.
+
+\begin{description}
+    \item[/recommender/] is reachable via a POST request and accepts a configuration state and preferences. Based on that a finished configuration is sent back as response.
+    \item[/config/] accepts GET and POST requests. Sending a GET request results in a list of all stored configurations being sent back. POST is used for adding a finished configuration to the configuration database.
+    \item[/product\_structure/] is reachable via GET and PUT. GET returns the current product structure and PUT is there to replace it.
+\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 a \emph{model-view-controller} \cite{gamma2015design} inspired architecture.
+Data is stored and retrieved using \emph{data access objects}. Therefore, the currently used simple TinyDB database backend can be replaced with a different one easily.
+
+\section{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 good in regard to at the four ACID (atomicity, consistency, isolation, durability) principles \cite{chrysanthis1998recovery, cookACIDBASEDatabase2009}. 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. Besides, it excels if data requirements are not entirely clear and if a large amount of unstructured  data has to be stored. Furthermore, non-relational databases allow the system to store the data in any kind of structure. This proves an advantage as it allows to use the same data structure to be stored that also has to be fed out through the api. Hence, parsing methods for the API can be reused and altered 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 non-relational database is used. 
+
+\section{Scoring Functions}
+\label{sec:DesignImplementation:ScroingFunctions}
+
+\begin{figure}[tb]
+    \centering
+    \includegraphics[width=1\textwidth]{./figures/50_design_and_implementation/class_diagram_scoring_functions_simplified.pdf}
+    \caption[Class Diagram: Scoring Functions]{A simplified class diagram of the classes and interface related to scoring functions. }
+    \label{fig:DesignImplementation:ClassDiagramScoringFunctions}
+\end{figure}
+
+This section describes the implementation of scoring functions (see \autoref{fig:DesignImplementation:ClassDiagramScoringFunctions}) which 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 \texttt{PreferenceScoringFunction}), others are meant for penalising changes in the current configuration state and therefore inherit from  \texttt{ConfigurationPenalty}. The last type of scoring function is \texttt{ReduceScoringFunction} that consists of one or multiple scoring functions and combines their scores to one. It uses the \emph{composite design pattern} \cite{gamma2015design}. 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 \emph{pipeline} \cite{gamma2015design} to first convert preferences to a list of values. This is done using \texttt{PreferenceToListFunction}. A list can be modified with a \texttt{ListToListFunction}. This step is optional. The last mandatory step is to convert the list to a value using \texttt{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 factory (\texttt{ScoringFunctionFactory}) is used to assemble a scoring function based on input parameters. This provides flexibility for quickly implementing new types of scoring functions.
+
+\section{Technologies}
+\label{sec:DesignImplementation:Technologies}
+
+\texttt{M.Recommend} is built in \emph{Python} \cite{PythonOrg} using \emph{FlaskRESTPlus} \cite{FlaskRESTPlus13Documentation}. \emph{FlaskRESTPlus} is an extension of \emph{Flask} \cite{FlaskDocumentation} that is meant to build a REST-Service and allows the generation of a web UI which documents the API. \emph{Flask} is a WSGI \cite{WhatWSGI} framework that is meant to easily get started with development while maintaining the ability to scale up to complex applications.
+
+As Database system \emph{TinyDB} \cite{TinyDB15Documentation} with the extension \emph{tinyrecord} \cite{junEugeneeeoTinyrecord2020} is being employed. \emph{TinyDB} is a simple well tested NoSQL database framework that can store documents that are represented as dictionaries. The extension \emph{tinyrecord} adds atomic transaction support with a record-first then execute architecture.
+
+As testing library for unit tests \emph{pytest} \cite{PytestDocumentation} is being employed which is commonly used for python. It supports automatic test discovery.
+
+For the evaluation of data and also for some operations with lists \emph{numpy} \cite{NumPy} is being employed. This library is optimised for fast scientific computing. 
+
+Visualisation is done using \emph{Matplotlib} \cite{MatplotlibDocumentation} in combination with \emph{pandas} \cite{PandasPythonData}. \emph{Pandas} is a powerful framework for data analysis and data manipulation which in the context of this thesis is being employed to load evaluation data.
+
+
+\section{Requirements Assessment}
+\label{sec:DesignImplementation:RequirementsAssesment}
+
+The requirements posed in \autoref{sec:Concept:Requirements} are assessed in this section. The recommender uses a continuous value range between zero and one for preferences. Additionally, the recommendation component is designed to be used independently, therefore it is possible to use it without proprietary software.
+Additionally, the group scoring function takes into account preferences of each group member and the current configuration state. The recommendation system can be used by multiple users at the same time as all information needed for a recommendation is sent with the recommendation request. Accordingly, multiple group configurators can use the system at the same time. Furthermore, only valid solutions are recommended because the recommender system's configuration database stores finished configurations. Moreover, the system responds in a timely manner with all components running on the same machine, a modern laptop.
+Consequently, all mandatory requirements have been fulfilled.
+
+The user interface is simple because a user only has two possible opportunities for action. They can change their preferences with a slider or change the configuration state. Additionally, the system is made to be compatible with other configuration systems. These have to implement the correct API-calls. However, this requirement was not tested with a different configuration system. Different scoring functions can be used however they can neither be selected through user interface nor through the API. Thus, this requirement is only partially fulfilled but the system allows extension to fulfil this requirement fully.
+Overall optional requirements have been addressed but they have not been thoroughly evaluated and some of them have only been partially implemented.

30_Thesis/sections/50_implementation.tex

@@ -1,2 +0,0 @@
-\chapter{Implementation}
-\label{ch:Implementation}

30_Thesis/sections/60_evaluation.tex

@@ -1,2 +1,319 @@
 \chapter{Evaluation}
 \label{ch:Evaluation}
+
+In this chapter the prototype is evaluated in terms of its functionality and its properties. The evaluation is an offline evaluation with synthetic data. All possible valid configurations are generated for one use case, i.e. all possible valid configurations for the forestry use case. Moreover, groups with explicit preferences and a configuration state (which, e.g. would be the currently existing forest) are generated, too. The evaluation will show that the recommender produces good results overall.
+
+\section{Metric}
+\label{sec:Evaluation:Metrics}
+
+A metric is required to carry out the validation. The proposed metric is the metric of satisfaction. This metric was created because pertinent literature does not provide metrics usable for this thesis. Satisfaction is quantified in this thesis by a threshold metric. A user's preference is used to calculate a rating for each possible solution. Each configuration solution gets an individual score determined by the user's preferences. The score is calculated using the average of a user's preference for each characteristic that is part of the configuration. The result allows a configuration to be compared to all other configurations and ranked according to the percentage of configurations that it beats for a specific user. The threshold metric consists of two parameters. First the threshold center $tc$ and second the satisfaction distance $sd$. The threshold for a satisfied person is at $tc + sd$ and for a dissatisfied person is at $tc - sd$. If a recommendation lies in between these two thresholds the person is classified to neither be satisfied nor be dissatisfied with the solution. For this thesis $sd=5\%$ will be used. This choice is based on the assumption that people switch from satisfied to dissatisfied rather quickly. Therefore, the parameter considered in this thesis is $tc$. An example is the choice of $tc = 60\%$. This results in a person satisfied with a recommendation if it is better than at least $65\%$ of all possible finished configurations. In contrast, a person is dissatisfied if the recommendation is not better than $55\%$ of all possible finished configurations. A recommendation that is better than at least $55\%$ and not better than $65\%$ of all possible solutions is considered neutral by the individual.
+
+Different $tc$ values allow to model different situations. A situation with a low willingness to compromise is modelled by a high $tc$. A contrary situation with a group that has a high willingness to compromise is modelled by a low $tc$.
+
+A satisfaction and dissatisfaction classification allows groups to be measured by the amount of people that are satisfied and dissatisfied. Moreover, changes in satisfaction and dissatisfaction for different parameters can be compared. A reasonable $tc$ value has to be found for groups otherwise any derived metrics will not show any meaningful results.
+
+\section{Evaluation Objective}
+\label{sec:Evaluation:Questions}
+
+This section poses three questions that will be answered during the evaluation. The questions' aim is to guide through this chapter. They set the guidelines for this evaluation and define its focuses. The questions answered during the evaluation are:
+
+\begin{itemize}
+    \item Main question: How does the satisfaction with a group decision, guided by the recommender, differ from the decision of a single decision maker, the dictator, who does not take the other group members' opinions into account?
+    \item How many group members on average are satisfied with the group decision?
+    \item How does the amount of stored finished configurations relate to satisfaction with a recommendation?
+\end{itemize}
+
+The main question is addressed to understand the behaviour the recommender and whether it gives benefits to groups. The second question is aimed at providing information regarding the data and what satisfaction looks like in group decisions and which factors influence it. Last, a technical question is posed. This question is relevant because it shows technical aspects of the recommender. This is important since other work for using the recommender in other possibly larger use cases depend on performance figures in relation to number of stored configurations.
+
+
+\begin{table}[tb]
+    \tiny
+    \begin{center}
+        \setlength\tabcolsep{3pt}
+        \begin{tabularx}{\columnwidth}{cl|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|C|}
+            & & \multicolumn{3}{c|}{\textit{indigenous}} & \multicolumn{3}{c|}{\textit{resilient}} & \multicolumn{3}{c|}{\textit{usable}} & \multicolumn{3}{c|}{\textit{effort}} & \multicolumn{3}{c|}{\textit{quantity}} & \multicolumn{3}{c|}{\textit{price}} & \multicolumn{3}{c|}{\textit{accessibility}} \\
+            & & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{manual} & \rotatebox[origin=c]{90}{harvester} & \rotatebox[origin=c]{90}{\ autonomous} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} & \rotatebox[origin=c]{90}{low} & \rotatebox[origin=c]{90}{moderate} & \rotatebox[origin=c]{90}{high} \\
+
+            \hline
+            \multirow{3}{*}{\textit{indigenous}}    & low       & - & - & - &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   \\ \cline{2-23}
+                                                    & moderate  & - & - & - &   &   & n &   &   & n &   &   &   &   &   &   &   &   &   &   &   &   \\ \cline{2-23}
+                                                    & high      & - & - & - &   &   & n &   & n & n &   &   &   &   &   & n & n &   &   &   &   &   \\ \hline
+
+            \multirow{3}{*}{\textit{resilient}}     & low       &   &   &   & - & - & - &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   \\ \cline{2-23}
+                                                    & moderate  &   &   &   & - & - & - &   &   & n &   &   &   &   &   &   &   &   &   &   &   &   \\ \cline{2-23}
+                                                    & high      &   & n & n & - & - & - &   & n & n &   &   &   &   &   & n & n & n &   &   &   &   \\ \hline
+
+            \multirow{3}{*}{\textit{usable}}        & low       &   &   &   &   &   &   & - & - & - &   &   &   &   &   & n & n & n &   &   &   &   \\ \cline{2-23}
+                                                    & moderate  &   &   & n &   &   & n & - & - & - &   &   &   &   &   &   &   &   &   &   &   &   \\ \cline{2-23}
+                                                    & high      &   & n & n &   & n & n & - & - & - &   &   &   &   &   &   &   &   &   &   &   & n \\ \hline
+
+            \multirow{3}{*}{\textit{effort}}        & low       &   &   &   &   &   &   &   &   &   & - & - & - &   &   & n & n & n &   &   &   &   \\ \cline{2-23}
+                                                    & moderate  &   &   &   &   &   &   &   &   &   & - & - & - &   &   &   &   &   &   &   & n & n \\ \cline{2-23}
+                                                    & high      &   &   &   &   &   &   &   &   &   & - & - & - &   &   &   &   &   &   &   & n & n \\ \hline
+
+            \multirow{3}{*}{\textit{quantity}}      & low       &   &   &   &   &   &   &   &   &   &   &   &   & - & - & - & n & n &   &   &   &   \\ \cline{2-23}
+                                                    & moderate  &   &   &   &   &   &   &   &   &   &   &   &   & - & - & - & n & n &   &   &   &   \\ \cline{2-23}
+                                                    & high      &   &   & n &   &   & n & n &   &   & n &   &   & - & - & - &   &   &   &   & n & n  \\ \hline
+
+            \multirow{3}{*}{\textit{price}}         & low       &   &   & n &   &   & n & n &   &   & n &   &   & n & n &   & - & - & - &   &   &   \\ \cline{2-23}
+                                                    & moderate  &   &   &   &   &   & n & n &   &   & n &   &   & n & n &   & - & - & - &   &   &   \\ \cline{2-23}
+                                                    & high      &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   & - & - & - &   &   &   \\ \hline
+
+            \multirow{3}{*}{\textit{accessibility}} & low       &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   &   & - & - & - \\ \cline{2-23}
+                                                    & moderate  &   &   &   &   &   &   &   &   &   &   & n & n &   &   & n &   &   &   & - & - & - \\ \cline{2-23}
+                                                    & high      &   &   &   &   &   &   &   &   & n &   & n & n &   &   & n &   &   &   & - & - & - \\ \hline
+        
+        \end{tabularx}
+        \caption[Forestry Use Case: Constraints]{Constraints in \emph{not with} form for the forestry use case.}
+        \label{tab:Evaluation:UseCase}
+    \end{center}
+\end{table}
+
+\section{Use Case}
+\label{sec:Evaluation:UseCase}
+The evaluation uses the forestry use case. This is a use case with four stakeholders. \autoref{fig:Concept:ForestExample} presents the attributes and characteristics of this use case. \autoref{tab:Evaluation:UseCase} extends it with rules that dictate which configurations valid.
+
+The stakeholders in this use case are: a forest owner, an athlete, an environmentalist, and a consumer. The owner sees the forest as an investment, they are interested in a high long-term profit. On the other hand consumers are interested in reasonable wood price as they use wood for furniture and also for their fireplaces. In contrast, the environmentalist is interested in a healthy forest that is not impacted negatively by human activity. Last is the athlete who is interested in good accessibility of the forest and that there is some plant and animal life.
+Every group consists of four people which is why they need to try and find a compromise. Diverging preferences make this difficult. All stakeholders have an interest in getting their will but also all parties need others to accept the decision. It is not in the interest of a stakeholder to fully have their preferences met while ending up with protests that arise from the deep dissatisfaction of other group members.
+
+
+
+\section{Data Generation}
+\label{sec:Evaluation:GeneratingGroups}
+
+This section describes the data generation process as seen in \autoref{fig:Evaluation:GeneratingDataProcess} that generates data based on the use case in \autoref{sec:Evaluation:UseCase}. Group profiles are used to generate groups of four with different group member types. The exact group composition depends on the group type. For every parameter and group type $1000$ groups are generated and converted to preferences. This number was chosen as it is the highest number that allows computing times to work overnight on the hardware that is available. Also this number is large enough to reduce strong variability between runs. For each group unfinished configurations are generated and its preferences are paired up with the generated unfinished configurations. These pairs later on are used for the evaluation. 
+
+\begin{figure}[htb]
+    \centering
+    \includegraphics[width=0.9\textwidth]{./figures/60_evaluation/bpmn_evaluation_input_data_generation.pdf}
+    \caption[Data Generation Process]{Data generation process for the evaluation}
+    \label{fig:Evaluation:GeneratingDataProcess}
+\end{figure}
+
+\subsection{Unfinished Configurations Generation}
+
+Unfinished configurations are generated using all finished configurations and taking a subset of the contained characteristics. This way all generated configurations will be valid and lead to valid solutions. For the results that are presented in this chapter around $\frac{1}{7} \approx 15\%$ of characteristics is maintained. This value is chosen to allow the existing configuration to take effect but not to skew the results due to the penalty function severely limiting possible options.
+
+\subsection{Preference Generation}
+
+For the forestry use case, the idea is that there are multiple types of user profiles. Each group profile is represented by a neutral, negative or positive attitude towards a characteristic. During data generation the attitude is converted to a preference using a normal distribution. Each preference lies in the interval $[0,1]$. Zero can be seen as worst possible option and one as best possible option. \autoref{fig:Evaluation:PreferenceDistribution} shows how the user profile can be converted to preferences. The actual group member profiles are shown in \autoref{tab:Evaluation:GroupMemberMappings}.
+
+\pgfplotsset{height=5cm,width=\textwidth,compat=1.8}
+\pgfmathdeclarefunction{gauss}{2}{%
+  \pgfmathparse{1/(#2*sqrt(2*pi))*exp(-((x-#1)^2)/(2*#2^2))}%
+}
+\begin{figure}[tb]
+    \begin{tikzpicture}
+        \begin{axis}[
+            every axis plot post/.append style={
+                mark=none, domain=0:1, samples=50, smooth
+            },
+            axis x line*=bottom,
+            xmin=0,
+            xmax=1,
+            ymin=0.1,
+            xticklabel style={
+                /pgf/number format/precision=3,
+            },
+            xtick={0,0.25, 0.5, 0.75,1},
+            hide y axis]
+          \addplot [draw=black, style={dashdotdotted}][very thick] {gauss(0.25,0.1)} node[text=black][above,pos=0.5] {negative};
+          \addplot [draw=black, style={solid}][very thick] {gauss(0.5,0.05)} node[text=black][above,pos=0.48] {neutral};
+          \addplot [draw=black, style={dotted}][very thick] {gauss(0.75,0.1)} node[text=black][above,pos=0.5] {positive};
+        \end{axis}
+        \end{tikzpicture}
+ \caption[Preference Distribution]{Distribution of preferences for a user type.}
+\label{fig:Evaluation:PreferenceDistribution}
+\end{figure}
+
+
+\begin{table}[htb]
+    \begin{center}
+        \begin{tabular}{l|c|c|c|c}
+            characteristic                              & athlete           & forest owner      & environmentalist  & consumer          \\
+            \hline
+            $(\textit{indigenous}, \text{low})$         & \textbf{negative} & \textit{positive} & \textbf{negative} & neutral           \\
+            $(\textit{indigenous}, \text{moderate})$    & \textit{positive} & neutral           & \textbf{negative} & neutral           \\
+            $(\textit{indigenous}, \text{high})$        & \textit{positive} & \textbf{negative} & \textit{positive} & \textbf{negative} \\
+            \hline
+            $(\textit{resilient}, \text{low})$          & neutral           & \textit{positive} & neutral           & neutral           \\
+            $(\textit{resilient}, \text{moderate})$     & \textit{positive} & neutral           & neutral           & neutral           \\
+            $(\textit{resilient}, \text{high})$         & \textit{positive} & \textbf{negative} & \textbf{negative} & \textbf{negative} \\
+            \hline
+            $(\textit{usable}, \text{low})$             & neutral           & neutral           & neutral           & \textbf{negative} \\
+            $(\textit{usable}, \text{moderate})$        & neutral           & neutral           & \textbf{negative} & neutral           \\
+            $(\textit{usable}, \text{high})$            & \textbf{negative} & \textit{positive} & \textbf{negative} & \textit{positive} \\
+            \hline
+            $(\textit{effort}, \text{manual})$          & \textbf{negative} & neutral           & \textit{positive} & \textbf{negative} \\
+            $(\textit{effort}, \text{harvester})$       & \textbf{negative} & \textit{positive} & \textbf{negative} & neutral           \\
+            $(\textit{effort}, \text{autonomous})$      & \textbf{negative} & \textit{positive} & \textbf{negative} & neutral           \\
+            \hline
+            $(\textit{quantity}, \text{low})$           & \textit{positive} & \textbf{negative} & \textit{positive} & \textbf{negative} \\
+            $(\textit{quantity}, \text{moderate})$      & neutral           & \textit{positive} & neutral           & \textbf{negative} \\
+            $(\textit{quantity}, \text{high})$          & \textbf{negative} & \textit{positive} & \textbf{negative} & \textit{positive} \\
+            \hline
+            $(\textit{price}, \text{low})$              & neutral           & neutral           & neutral           & \textit{positive} \\
+            $(\textit{price}, \text{moderate})$         & neutral           & \textit{positive} & neutral           & neutral           \\
+            $(\textit{price}, \text{high})$             & neutral           & \textit{positive} & neutral           & \textbf{negative} \\
+            \hline
+            $(\textit{accessibility}, \text{low})$      & \textbf{negative} & \textit{positive} & \textit{positive} & neutral           \\
+            $(\textit{accessibility}, \text{moderate})$ & neutral           & neutral           & neutral           & neutral           \\
+            $(\textit{accessibility}, \text{high})$     & \textit{positive} & \textbf{negative} & \textbf{negative} & neutral           \\
+            \hline
+        \end{tabular}
+        \caption[Forestry Use Case: Group Member Profiles]{The attitudes of each group member profile.}
+        \label{tab:Evaluation:GroupMemberMappings}
+    \end{center}
+\end{table}
+
+These user profiles can be used to generate rather homogenous groups but also to create groups that have interests that are more conflicting. The following group types, with four members each, are generated:
+
+\begin{itemize}
+    \item random groups (preferences are uniformly random)
+    \item heterogeneous groups (people adhere to one preference profile like forest owner, athlete, consumer, environmentalist)
+    \item homogeneous groups (only one preference profile for all group members which in this evaluation is the forest owner)
+\end{itemize}
+
+The natural group type for the use case is a heterogeneous group but to widen the evaluation and to see how the recommender performs with different types of groups the two other group types are evaluated too. As a result, more general statements about the recommender's performance can be made.
+
+\subsection{The Effect of Stored Finished Configurations}
+
+Another important component of the evaluation is the influence of stored finished configurations. When evaluating a subset of stored finished configurations it is important to avoid outliers. This is the reason why a process inspired by \emph{cross validation} \cite{kohaviStudyCrossValidationBootstrap1995} is used. The configuration database is randomly ordered and sliced into sub-databases of the needed size. As an example, if the evaluated stored data size is 20, a configuration database containing 100 configurations is split into five sub-databases of size 20. Now the evaluation is carried out for each of the sub-databases and finally the average is determined. This avoids the random picking of a subset which either performs much better than most other possible combinations of databases or which performs much worse. This way the data is more aligned to the expected value.
+
+\section{Hypotheses}
+\label{sec:Evaluation:Hypotheses}
+
+This section gives an overview on the hypotheses tested during data analysis. Each hypothesis is followed by an explanation as to why the hypothesis is presented. In later sections the truthfulness of the hypothesis is examined. This allows to verify if expectations about the behaviour of the recommender are true or false.
+
+\begin{hypothesis}
+    \begin{itshape}
+        \label{hyp:Evaluation:MaximumMinimum} Improvements for group recommendations are highest when the number of people satisfied with the dictator's decision is slightly lower than two and the highest reduction in dissatisfied group members can be seen at around two group members dissatisfied respectively.
+    \end{itshape} \medskip \\*    
+    This is based on the assumption that in a real situation a group of four with less than two satisfied members (with a dictator's decision) on average, has enough room for improvement so that potentially three group members can be satisfied after the use of the recommender. This means that at least one more person is satisfied with the compromise. In some groups it my then be potentially possible to shift the last person from dissatisfaction towards a neutral attitude. A higher base satisfaction is assumed to reduce the possibility to make an additional group member satisfied.
+\end{hypothesis}
+
+
+\begin{hypothesis}
+    \begin{itshape}
+        \label{hyp:Evaluation:HigherTcLessSatisfied} A higher $tc$ value results in less satisfied people and more dissatisfied people with regard to the dictator's decision.
+    \end{itshape} \medskip \\*
+    A higher $tc$ value causes a person to be dissatisfied with a higher amount of configurations. It also causes a person to be satisfied with less configurations. Therefore, recommending a random configuration causes the chance of making an individual satisfied to sink while increasing the chance of that person to be dissatisfied. Already the change in probability leads to the assumption that this result should be seen with non-random recommendations too.
+\end{hypothesis}
+
+\begin{hypothesis}
+    \begin{itshape}
+        \label{hyp:Evaluation:OnlyOneSatisfied} There exists a $tc$ value which causes only one person to be classified as satisfied with the dictator's decision and no one is classified as satisfied with the group recommender's decision.
+    \end{itshape} \medskip \\*
+    A $tc$ value that reaches a high enough level eventually should make only the dictator herself satisfied with the dictator's decision. The bound for satisfaction is so high that any group recommendation will cause the dictator to also be dissatisfied or at least neutral with the group decision. This can be understood as a complete unwillingness of a group to compromise. All group members are only satisfied with their own decision. Having two group members with identical interest, which is expected to be rare, results in this effect not being present even in a situation like that. 
+\end{hypothesis}
+
+\begin{hypothesis}
+    \begin{itshape}
+        \label{hyp:Evaluation:HomogenousMoreSatisfied} Homogeneous groups have more members satisfied with the recommender's decision but also with the dictator's decision compared to heterogeneous groups.
+    \end{itshape} \medskip \\*
+    As the interest in homogenous groups is more aligned it is to be expected that the overall satisfaction levels for more homogenous groups is higher. If the base level is already higher it is likely that even just a slight increase shifts recommendations for homogenous groups to satisfaction levels not achievable by heterogeneous groups.
+\end{hypothesis}
+
+\begin{hypothesis}
+    \begin{itshape}
+        \label{hyp:Evaluation:HeterogenousBiggerSatisfactionIncrease} More heterogeneous groups see a bigger increase in satisfaction than less heterogeneous groups when switching from a decision of a dictator to a decision made by the recommender.
+    \end{itshape} \medskip \\*
+    The assumption is made that in more heterogeneous groups the satisfaction with the dictator's decision is less. Therefore, there is a higher possible increase in satisfaction. A homogenous group that already satisfies all group members with the dictator's decision cannot see an increase in satisfaction, therefore, the assumption is made that with a higher number of people dissatisfied or neutral with the dictator's decision, more people will be be lifted into satisfaction and the increase in satisfaction will be bigger. However a group that has divergent interests actually might not be able to reach high levels of satisfaction.
+\end{hypothesis}
+
+\begin{hypothesis}
+    \begin{itshape}
+        \label{hyp:Evaluation:StoreSizeBetterResults} A higher amount of stored finished configurations results in a higher number of satisfied and a lower number of dissatisfied group members when the recommender is used to make the group decision.
+    \end{itshape} \medskip \\*
+    This hypothesis is based on the fact that the possibility to chose a bigger pool of configurations increases the chances of arriving at a good recommendation. This of course requires the assumption that aggregation strategies that pick recommendations pick configurations that also fare better in the chosen satisfaction metric. If this is not the case this hypothesis is not sustainable.
+\end{hypothesis}
+
+\begin{hypothesis}
+    \begin{itshape}
+        \label{hyp:Evaluation:AggregationStrategies} The multiplication and best average aggregation strategies perform better than the least misery aggregation strategy.
+    \end{itshape} \medskip \\
+    Best average and multiplication are strategies that perform best in some of the by \citeauthor{Masthoff2015} \cite[~ 755f]{Masthoff2015} listed online experiments. Therefore, it is reasonable to assume that they perform well here too. Least misery was listed in some studies as performing worst. Accordingly, it is expected to fare less good than other group aggregation strategies.
+\end{hypothesis}
+
+\section{Results}
+\label{sec:Evaluation:Findings}
+
+\subsection{Threshold Center Selection}
+This section aims at finding a $tc$ parameter for the analysis. This is required to reduce the amount of data that has to be looked at and to get valuable results. For this purpose all parameters except $tc$ will be fixed. The preference aggregation strategy looked at is multiplication because this strategy shows good results across the board when briefly looking at the generated data. The configuration database is used with all possible solutions (which is 148 in total). This results in a bigger visible effect in terms of satisfaction and dissatisfaction change as the recommender has access to all possible configurations and also provides more solid and predictable results. \autoref{fig:Evaluation:tcChange} shows the satisfaction change based on choice of $tc$. Of note is that the maxima of satisfaction change precedes the minima of dissatisfaction change for all group types. Maxima and minima occur at different tc values depending on the group type. Heterogeneous groups peek earliest while homogenous groups only show a peek towards the maximum $tc$ value. Changes in dissatisfaction are minimal even with $tc$ close to its maximum value for homogeneous groups. 
+
+\autoref{fig:Evaluation:tcCount} shows the amount of group members satisfied and dissatisfied with the dictator's decision. The number of satisfied people decreases with an increasing $tc$ and its downward movement accelerates. The dissatisfaction curve shows a similar trend in reverse. Here the number of dissatisfied group members increases with an increase in $tc$. The curve accelerates its growth analogous to the acceleration of the satisfaction curve. The behaviour of heterogeneous groups and random groups is similar but the curve for heterogeneous groups shows less satisfaction and more dissatisfaction for a given tc. Also both curves have a negative satisfaction change when $tc$ reaches a certain height. Homogeneous groups only have satisfied group members for most $tc$ values but they decrease rapidly for values greater than $85$. Dissatisfied group members are at zero for the whole value range of $tc$ except a very slight upward tick at the end that is barely noticeable.
+
+\begin{figure}
+    \centering
+    \includegraphics[width=1\textwidth]{./figures/60_evaluation/tc_change__multi__db-size-148.pdf}
+    \caption[Satisfaction and Dissatisfaction: Change based on $tc$]{The average satisfaction and dissatisfaction change based on $tc$ with a database size of 148 and multiplication as aggregation strategy.}
+    \label{fig:Evaluation:tcChange}
+\end{figure}
+
+\begin{figure}
+    \centering
+    \includegraphics[width=1\textwidth]{./figures/60_evaluation/tc_dictator__multi__db-size-148.pdf}
+    \caption[Satisfaction and Dissatisfaction: Average based on $tc$]{The average satisfaction and dissatisfaction with the dictator's decision based on $tc$.}
+    \label{fig:Evaluation:tcCount}
+\end{figure}
+
+
+\autoref{hyp:Evaluation:MaximumMinimum} states that the highest satisfaction change is expected at places where the overall satisfaction with the dictator's decision is close to two. However, the data shows a slightly different result. This hypothesis does not hold true. When looking at the data we see peeks in satisfaction change when values are equal to $2.81, 2.51$ and $3$ (heterogeneous, random, homogenous). Therefore, the expectation does not hold up. Most likely this happens because at lower satisfaction numbers with the dictator's decision the threshold for satisfaction is set too high which causes the group compromise to classify less group members as satisfied. Moreover, valleys for dissatisfaction change are also not at the expected value of \textit{two}. They are instead at $1.19, 1.49, 0.04$ (heterogeneous, random, homogenous). Here the valleys are lower than expected. However, the data from homogenous groups seems to be cut off. Therefore, a judgement for homogenous groups is difficult and with slightly less heterogeneous groups this graph should show bigger effects.
+
+
+
+The predicted trend that a higher $tc$ results in a lower satisfaction and a higher dissatisfaction with the dictator's decision, as predicted by \autoref{hyp:Evaluation:HigherTcLessSatisfied}, can be clearly seen in \autoref{fig:Evaluation:tcCount} and has already been described in this section. This means for the evaluation that the behaviour of the recommender is predictable and suggests that the used metrics are modelling behaviour expected in reality.
+
+\autoref{hyp:Evaluation:OnlyOneSatisfied} predicts that the satisfaction with the individual decision eventually reaches one and that no one is satisfied with the group recommender's decision. This means the satisfaction change should decrease to minus one. \autoref{fig:Evaluation:tcCount} shows a downward trend that comes close to one for heterogeneous and random groups. Therefore, the trend suggests that the hypothesis holds true with regard to heterogeneous and random groups but the drop for homogenous groups just reaches below $2.8$ suggesting that the hypothesis does not hold for homogenous groups. Also, satisfaction change in heterogeneous groups decreases close to minus one while this value is neither fully reached by random groups nor by homogenous groups. The hypothesis therefore holds true only for heterogeneous groups. A likely cause why it does not seem to hold true for random or homogenous groups is that the highest tc value still includes multiple configurations and a recommended configuration keeps some group members satisfied for some of the time. For random groups it may also be possible that a group member other than the dictator could be satisfied with the group decision.
+
+During a group decision it is better to make one less person dissatisfied than to make one more person satisfied. Therefore, this thesis uses $tc$ values that are closer to the minima of dissatisfaction change than to the maxima of satisfaction change. The minima for heterogeneous groups is at $tc = 70\%$, therefore, this is the chosen value for evaluation of the remaining hypotheses. This is needed because otherwise analysis would be infeasible due to a too large parameter space. For random groups the minima of dissatisfaction change can be found at $tc = 85\%$ which is the value used for all following analyses of random groups. For homogenous group-dissatisfaction change is decreasing until the highest possible value of $tc$. Because of that $tc = 94\%$ is used for analysis.
+
+\subsection{Recommender Performance Analysis}
+
+\begin{figure}[p]
+    \centering
+    \includegraphics[width=1\textwidth]{./figures/60_evaluation/heterogeneous_combined__amount-1000__tc-70}
+    \caption[Satisfaction and Dissatisfaction: Heterogeneous Groups]{Satisfaction and dissatisfaction using the group recommender for heterogeneous groups with $tc = 70$.}
+    \label{fig:Evaluation:HeteroSatisfaction}
+\end{figure}
+
+\begin{figure}[p]
+    \centering
+    \includegraphics[width=1\textwidth]{./figures/60_evaluation/random_combined__amount-1000__tc-85}
+    \caption[Satisfaction and Dissatisfaction: Random Groups]{Satisfaction and dissatisfaction using the group recommender for random groups with $tc = 85$.}
+    \label{fig:Evaluation:RandomSatisfaction}
+\end{figure}
+
+\begin{figure}[p]
+    \centering
+    \includegraphics[width=1\textwidth]{./figures/60_evaluation/homogeneous_combined__amount-1000__tc-94}
+    \caption[Satisfaction and Dissatisfaction: Homogeneous Groups]{Satisfaction and dissatisfaction using the group recommender for homogeneous groups with $tc = 94$.}
+    \label{fig:Evaluation:HomoSatisfaction}
+\end{figure}
+
+This subsection fixes parameters of $tc$. It describes the satisfaction change and the total amount of satisfied people with the recommender's decision dependent on the amount of stored configurations.
+
+\autoref{fig:Evaluation:HeteroSatisfaction} shows the relationship between satisfaction and dissatisfaction and the number of stored configurations. The left y-axis shows the change in satisfaction compared to a decision made by a dictator. The right axis shows the average number of satisfied group members. The left figure shows numbers for satisfaction and the right for dissatisfaction. On the left, higher numbers are better and on the right, lower ones (with regards to change). There are three graphs each. One for multiplication, one for least misery and one for best average. The graphs for satisfaction are similar to a logarithmic curve. The increase in change of satisfaction slows with a higher number of stored configurations. The change in satisfaction is always above zero and a satisfaction increase of more than three quarters of the maximum can already be seen at around 25 stored configurations. Moreover, the curve for multiplication is greater than all other curves for all parameters. Least misery reaches the lowest amount of change across all values. The minimum number of satisfaction change is $0$ for least misery, and $0.1$ for best average and multiplications. The highest number is around $0.3$ for least misery, $0.4$ for best average and $0.5$ for multiplication
+When looking at dissatisfaction change the graphs are all in the negative number range. Multiplication reaches the lowest number and best average the highest. The gap between all three functions is less than that of satisfaction increase. And overall the curves are flatter indicating that the change with 25 stored configurations already reaches close to five sixth of the minimum value. The highest number of satisfaction change is $-0.4$ for all strategies while the lowest number is around $-0.57$ for least misery, $-0.53$ for best average and $-0.63$ for multiplication.
+
+The graphs for homogenous (\autoref{fig:Evaluation:HomoSatisfaction}) and random groups (\autoref{fig:Evaluation:RandomSatisfaction}) have a similar shape but their values and slopes vary. The satisfaction change for homogenous groups is mostly negative, starting at $-2$, and only reaches a positive level for more than $100$ stored configurations with a value of $0.04$. Multiplication and best average have higher values than least misery here too. Moreover the dissatisfaction change is always positive with a value range of $[0,1]$, except for a slight fall below zero after more than $75$ configurations are stored.
+Random groups as seen in \autoref{fig:Evaluation:RandomSatisfaction} mostly have a positive change in satisfaction. Here, values range from $-0.55$ to $0.27$ for least misery, from $-0.27$ and $-0.28$ to $0.74$ for best average and multiplication. The change is higher than the change for heterogeneous groups. Dissatisfaction also changes similarly to heterogeneous groups. Here the values for random groups reach a lower level. They range from $0$ to $-0.59$ for least misery. Multiplication and best average both have a minimum value around $-0.21$ and behave similarly. The range goes down to $-0.84$ for best average and $-0.86$ for multiplication.
+
+\autoref{fig:Evaluation:HeteroSatisfaction} also shows the average number of group members satisfied and dissatisfied with the recommender's decision. Satisfaction with the recommender's decision starts at $2.4$ and quickly reaches $2.65$ for least misery and $2.8$ for best average and multiplication. The highest value for multiplication is at $2.89$. Dissatisfaction likewise quickly plateaus. Here values for different recommenders are closer together. They start at $0.74$ (least misery) to $0.78$ (best average) and fall as low as $0.62$ for least misery, $0.66$ for best average and $0.56$ for multiplication.
+
+When looking at the total numbers as shown in \autoref{fig:Evaluation:HomoSatisfaction} the value range for homogenous groups is much larger but the overall shape stays the same. Here satisfaction numbers go from $0.55$ to $2.95$. \emph{Least misery} performs visibly worse than \emph{multiplication} and \emph{best average} reaches only $2.7$. Dissatisfaction values range from $1.21$ to $0.01$ and the values are not really visibly distinguishable, except in the range of $[25,50]$. Least misery seems to have the highest number of dissatisfied group members in this range.
+
+Random groups have less overall satisfaction with $tc = 85\%$ as seen in \autoref{fig:Evaluation:RandomSatisfaction} when looking at the total numbers. Satisfaction numbers start from $1.33$ (least misery), $1.61$ (best average) and $1.6$ (multiplication) and go up to $2.15$ for least misery and $2.62$ for best average and multiplication. The dissatisfaction numbers start at $1.5$ for least misery and $1.27$ for best average and multiplication and level off at $0.9$ (least misery), $0.65$ (best average) and $0.63$ (multiplication). There is a big difference visible between least misery and the other two aggregation functions.
+
+\subsection{Discussion}
+
+Having described the data the remaining hypotheses are discussed.
+\autoref{hyp:Evaluation:HomogenousMoreSatisfied} states that homogenous groups have more satisfied members with regards to the dictator's and the group recommender's decision. \autoref{fig:Evaluation:tcCount} shows that this holds true for the dictator's decision as for every instance satisfaction in homogeneous groups is higher than that of other groups. However, \autoref{fig:Evaluation:HeteroSatisfaction}, \autoref{fig:Evaluation:HomoSatisfaction} and \autoref{fig:Evaluation:RandomSatisfaction} show that for satisfaction with the recommender's decision this does not hold true when looking at $tc$ values where the recommender performs best for each segment. In these cases the homogenous group only reaches the highest amount of satisfaction when the recommender has access to all stored configurations. With a decreasing number of stored configurations both random groups and heterogeneous groups achieve a higher satisfaction. This is likely to happen due to the similarity between group members. A recommender with imperfect knowledge and a size-reduced, configuration database generates results that are not good enough and cannot compete with the dictator who always finds the perfect individual match that group members of homogeneous groups are satisfied with. It is important to note that homogeneous groups show a higher number of satisfied people across the board when the same $tc$ values are used.
+
+\autoref{hyp:Evaluation:HeterogenousBiggerSatisfactionIncrease} states that the increase in satisfaction should be bigger for more heterogeneous groups. However, \autoref{fig:Evaluation:HeteroSatisfaction}, \autoref{fig:Evaluation:HomoSatisfaction} and \autoref{fig:Evaluation:RandomSatisfaction} show this not to be true. The recommendations for heterogeneous groups indeed cause a larger change in satisfaction compared to homogeneous groups but random groups cause a positive change of higher magnitude. Also, the decrease in dissatisfaction is higher among random groups. This possibly happens because random groups have more aligned interests and preferences among group members and, therefore, they do not diverge as much which results in compromises for the group that can satisfy more individual members. Likewise, the group preferences are still far enough apart to cause dissatisfaction and neutrality with the dictator's decision.
+
+The data shows that a larger configuration database causes the amount of satisfied group members to be greater than recommendations using a smaller database. With dissatisfaction the same is seen in the inverse. A larger configuration database causes the number of dissatisfied group members to drop compared to a small database. However, in some runs there have been instances of least misery that show a slight drop. This can be seen in \autoref{fig:Evaluation:HeteroSatisfaction} when comparing $74$ and $148$ as the number of stored configurations. Why this happens is not entirely clear but a cause might be that least misery just takes into account the worst performing group member of the group. Thus, it is possible that there is a second slightly worse solution, when comparing least misery scores, which actually has a slight advantage in terms of dissatisfaction. This second best configuration can cause it to be in the second database partition hence resulting in less dissatisfaction on average. \autoref{hyp:Evaluation:StoreSizeBetterResults} thus is supported by the data but it does not fully hold true when looking at least misery.
+
+\autoref{hyp:Evaluation:AggregationStrategies} states least misery performs worse than multiplication. For a change in satisfaction this can be seen across the board, however, for the change in dissatisfaction this is not true everywhere. \autoref{fig:Evaluation:HeteroSatisfaction} shows that least misery performs better than best average in terms of dissatisfaction reduction. This behaviour possibly occurs because an average metric yields the same results for heavily polarised decisions and decisions that everyone feels neutral about. Least misery on the other hand takes into account only the group member least satisfied with the decision and, therefore, this metric performs better. However, in other cases it performs visibly worse. Also notable is that multiplication performs best across the board. This supports the findings by \citeauthor{Masthoff2015} \cite[~p. 755f]{Masthoff2015} and further shows that the satisfaction model does show some similar results to online evaluations.
+
+To go back to the evaluation questions posed in \autoref{sec:Evaluation:Questions} this section has shown that for random and heterogeneous groups the recommender performs better than a dictator. The average satisfaction depends on the chosen parameters but for the chosen value range average satisfaction with the recommender decision lies above two and can reach close to three satisfied group members for a high number of stored configurations and for some group types. The amount of stored finished configurations plays an important role in the recommender's performance but with a fraction of stored configurations the recommender still yields good results. This shows that the recommender provides useful decision support for helping in group decisions. It provides a solid basis for groups and can help their group decision. Most decisions the recommender does improve group satisfaction which shows that the recommender is able to be used to improve group decisions.

30_Thesis/sections/70_future_work.tex

@@ -1,2 +0,0 @@
-\chapter{Future Work}
-\label{ch:FutureWork}

30_Thesis/sections/80_conclusion.tex

@@ -1,2 +1,30 @@
 \chapter{Conclusion}
 \label{ch:Conclusion}
+
+This chapter summarises the thesis and describes the exact steps that were undertaken, starting with an overview of the foundations regarding group recommenders and configuration. Furthermore, a concept for a recommender for group-based configuration is introduced, implemented as prototype and evaluated. Last, limitations of this thesis and the recommender system are presented and further research is proposed.
+
+\section{Summary}
+\label{sec:Conclusion:Summary}
+
+This thesis was motivated by the research area of group-based configuration gaining more interest. As group decisions come with many problems and biases, recommender systems are used  to help with group decisions. This avoids mistakes and helps with reproducibility of successful group decisions. To date, no research has been carried out on recommendations regarding group-based configurations. This is why the research question of this thesis focuses on: "How can a group recommender translate individual preferences into recommendations that improve the overall satisfaction of group members while considering constraints given by the configuration state?". This thesis answers the research questions by proposing a concept, implementing it as a prototype and evaluating it. Thereby the viability of such a system and such an approach is shown.
+First, the thesis introduces foundations of product configuration and extends them to group-based product configuration. Next, recommender systems are introduced and three basic approaches, collaborative filtering, content-based filtering and constraint based recommendation, are compared. Last, the \hyperref[ch:Foundations]{foundations chapter} allots an introduction into group recommendation.
+Following\autoref{ch:Foundations} (Foundations), a concept for an item-based recommender for group-based configuration, is introduced. This concept uses a database of finished configurations to choose a configuration that fits the group best. Each user's preferences are used to assign a score to a configuration. The score of all group members is then aggregated into a group score and the best configuration from the database is recommended. The recommender also all penalties for deviating from the current configuration state.
+Later, the concept is implemented as an open source microservice which is integrated into an already existing group-based configurator. The source code is available at \cite{kuchelmeister13hannes11BachelorThesis}.
+Last, an offline metric for satisfaction is introduced and it is used for evaluation. Three group types are evaluated, homogenous groups, random groups and heterogeneous groups. Overall, the evaluation shows that the recommender yields good results for groups and helps groups to form a compromise. Satisfaction among group members increases overall. A simple item-based approach therefore  already improves group decisions by finding good compromises. This is also the case when the knowledge of the recommender is limited.
+
+\section{Limitations and Further Research}
+\label{sec:Conclusion:LimitationsFurtherResearch}
+
+Due to the scope of this thesis it was not feasible to analyse all possible scenarios for the proposed approach.
+
+An offline satisfaction metric is introduced in this thesis which may lead to results that differ from real life impressions of people. It has yet to be validated in a real-world setting. The validations of this metric allows the use of the introduced satisfaction metric for other scenarios that also lack suitable existing metrics. Moreover, understanding the relation between the introduced metric and actual satisfaction can help to form more accurate satisfaction models. This helps to understand how to find better compromises and, at the same time, such a metric can directly be used as a component of a group recommender.
+
+In this thesis only a single use case was examined. Therefore, different use cases could yield different results in terms of satisfaction and the tolerance of limited knowledge. It is unclear if different scenarios which are either more complex or have more features and characteristics yield the same results. The successful application to larger products could help with large complex projects that include multiple experts from differing areas that do not necessarily agree. Also, larger products potentially reach limitations of the recommender as the solution space grows quickly. An approach that clusters configurations and other means of optimization can help with performance. Complex and large products might lead to usability issues as users potentially are overwhelmed with choices and setting all preferences individually might be infeasible. Thus, indirect means of acquiring preferences should be incorporated for more complex and larger configurations. 
+
+Furthermore, groups were automatically generated and, thus, possibly a lack of resemblance to common real-world group constellations. Consequently, real world group constellations for decisions should be analysed. This will allow the validation of the implemented groups and can lead to a better understanding of generating synthetic groups that resemble actual groups. Thus, less time has to be spent in acquiring user data.
+
+Moreover, the recommender did not perform ideally with homogenous groups, especially when knowledge about the solution space was limited. Hence, methods of detecting homogenous groups could detect cases in which the recommender perform poorly and use other recommenders instead. A recommender that should be evaluated in this context is presented by \citeauthor{choudharyMulticriteriaGroupRecommender2020} \cite{choudharyMulticriteriaGroupRecommender2020}. This recommender fares better with homogeneous groups opposed to random groups.
+
+Additionally, the group size was fixed to four members and because \citeauthor{choudharyMulticriteriaGroupRecommender2020} note that their recommender does better in smaller groups, deviating results for differently sized groups are possible. Moreover, this approach can be extended to potentially allow a whole community of people to decide about neighbourhood changes. This could range from the layout of a new community centre, staffing, equipment and uses. Therefore, such approaches of group-based configuration can be used for public participation in projects helping communities to build trust and be more involved in decisions.
+
+Finally, the approach used in this thesis assumes a flat group hierarchy. Modelling knowledge and hierarchy of a group can help to improve group decisions further as supervisors do not feel overrun by their employees and knowledge of experts on certain parts of a product or solution can use that knowledge to guide the decision that area. Experts in other areas could have more say in areas of their expertise. Thus, decisions could be expert and hierarchy driven which should help with group satisfaction about compromises.

30_Thesis/sections/abstract_de.tex

@@ -1,2 +1,3 @@
 \Abstract
-Deutsche Zusammenfassung
+
+Gruppenbasierte Konfiguration ist ein noch relativ junges Feld, das sich mit der Konfiguration von Produkten, Dienstleistungen und Lösungen durch Gruppen auseinandersetzt und Gruppenentscheidungen unterstützt. Gute Gruppenentscheidungen zu treffen ist jedoch komplex und nicht immer reproduzierbar. Empfehlungssysteme für Gruppen können hier Abhilfe schaffen. Diese wurden jedoch noch nicht für gruppenbasierte Konfiguration eingesetzt. In dieser Thesis wird ein Konzept zur Integration eines item-basierten Gruppenempfehlungssystems in einen Gruppen-Konfigurator vorgestellt, prototypisch implementiert und evaluiert. Das Konzept zeigt auf, wie Präferenzen einzelner Gruppenmitglieder kombiniert werden können, um eine Gruppenbewertung für eine Konfiguration zu erhalten. Dieser Ansatz wird genutzt, um die durch die Gruppe höchstbewertete Konfiguration aus einer Datenbank auszuwählen und zu empfehlen. Die Evaluation mit synthetischen Gruppen mit vier Personen erzielt gute Ergebnisse, insbesondere bei heterogenen Gruppen.

30_Thesis/sections/abstract_en.tex

@@ -1,2 +1,4 @@
 \Abstract
-English abstract.
+
+Group-based configuration is a fairly new configuration approach that presents a scenario where a group of people is configuring a product, service, or solution. However, good group decisions are difficult to arrive at. Therefore, to facilitate group decisions, group recommender systems are used. Yet, they have not been applied to group-based configuration. This thesis proposes a concept for an item based recommender system that helps a group to find a consensus for a configuration decision. The concept shows how preferences of individual group members can be combined to give configurations a group score. The score is used to rank configurations in a database and recommend the configuration with the highest score.
+A prototype is implemented and evaluated with a newly introduced offline satisfaction metric and with synthetically generated groups. Overall the evaluation shows that the proposed concept works especially well for heterogeneous groups.

30_Thesis/sections/appendix.tex

@@ -1,25 +0,0 @@
-\iflanguage{english}
-{\chapter{Appendix}}    % english style
-{\chapter{Anhang}}      % german style
-\label{chap:appendix}
-
-
-%% -------------------
-%% | Example content |
-%% -------------------
-\section{First Appendix Section}
-\label{sec:appendix:FirstSection}
-		
-\setcounter{figure}{0}
-		
-\begin{figure} [ht]
-  \centering
-  \caption{A figure}
-  \label{fig:anotherfigure}
-\end{figure}
-
-
-\dots
-%% ---------------------
-%% | / Example content |
-%% ---------------------

30_Thesis/sections/declaration.tex

@@ -25,7 +25,9 @@ unverändert oder mit Änderungen entnommen wurde.}
 %% ---------------------------------------------
 %% | Replace PLACE and DATE with actual values |
 %% ---------------------------------------------
-\textbf{PLACE, DATE}
+
+\regressbydays{1} % change to actual signature date
+\textbf{Wiesbaden, \printfdate{british}}
 \vspace{1.5cm}
  
 \dotfill\hspace*{8.0cm}\\

30_Thesis/thesis.bib

@@ -21,6 +21,27 @@
   file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\YXJISA5R\\Abdollahpouri et al_2019_Beyond Personalization.pdf}
 }
 
+@article{al-houmailyRecoveryPerformanceAtomic,
+  title = {Recovery and {{Performance}} of {{Atomic Commit Processs}}},
+  author = {Al-houmaily, Yousef J and Samaras, George},
+  pages = {49},
+  abstract = {A transaction is traditionally de ned so as to provide the properties of atomicity, consistency, integrity, and durability (ACID) for any operation it performs. In order to ensure the atomicity of distributed transactions, an atomic commitprotocol needs to be followed by all sites participating in a transaction execution to agree on the nal outcome, that is, commit or abort. A variety of commit protocols have been proposed that either enhance the performance of the classical two-phase commit protocol during normal processing or reduce the cost of recovery processing after a failure. In this chapter, we survey a number of two-phase commit variants and optimizations, including some recent ones, providing an insight in the performance trade-o between normal and recovery processing. We also analyze the performance of a representative set of commit protocols both analytically as well as empirically using simulation.},
+  langid = {english}
+}
+
+@article{aminiDiscoveringImpactKnowledge2011,
+  title = {Discovering {{The Impact Of Knowledge In Recommender Systems}}: {{A Comparative Study}}},
+  shorttitle = {Discovering {{The Impact Of Knowledge In Recommender Systems}}},
+  author = {Amini, Bahram and Ibrahim, Roliana and Othman, Mohd},
+  date = {2011-09-01},
+  journaltitle = {International Journal of Computer Science \& Engineering Survey},
+  shortjournal = {International Journal of Computer Science \& Engineering Survey},
+  volume = {2},
+  doi = {10.5121/ijcses.2011.2301},
+  abstract = {Recommender systems engage user profiles and appropriate filtering techniques to assist users in finding more relevant information over the large volume of information. User profiles play an important role in the success of recommendation process since they model and represent the actual user needs. However, a comprehensive literature review of recommender systems has demonstrated no concrete study on the role and impact of knowledge in user profiling and filtering approache. In this paper, we review the most prominent recommender systems in the literature and examine the impression of knowledge extracted from different sources. We then come up with this finding that semantic information from the user context has substantial impact on the performance of knowledge based recommender systems. Finally, some new clues for improvement the knowledge-based profiles have been proposed.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\3JILH3P2\\Amini et al_2011_Discovering The Impact Of Knowledge In Recommender Systems.pdf}
+}
+
 @inproceedings{andrzejakSoftwareConfigurationDiagnosis2018,
   title = {Software {{Configuration Diagnosis}} \textendash{} {{A Survey}} of {{Existing Methods}} and {{Open Challenges}}},
   booktitle = {Proceedings~of~ the~20th~{{International~Configuration~Workshop}}},
@@ -36,7 +57,7 @@
 
 @article{article,
   title = {Collaborative Product Configuration: Formalization and Efficient Algorithms for Dependency Analysis.},
-  author = {Mendon{\c c}a, Marc\'ilio and Cowan, Donald and Malyk, William and Oliveira, Toacy},
+  author = {Mendon\c{c}a, Marc\'ilio and Cowan, Donald and Malyk, William and Oliveira, Toacy},
   date = {2008-01},
   journaltitle = {JSW},
   volume = {3},
@@ -100,6 +121,19 @@
   type = {Master's thesis}
 }
 
+@inproceedings{bleckerProductConfigurationSystems2004,
+  title = {Product {{Configuration Systems}} - {{State}} of the {{Art}} - {{Conceptualization}} and {{Extensions}}},
+  booktitle = {Eight {{Maghrebian Conference}} on {{Software Engineering}} and {{Artificial Intelligence}}},
+  author = {Blecker, Thorsten and Abdelkafi, Nizar and Kreutler, Gerold and Friedrich, Gerhard},
+  date = {2004},
+  pages = {25--36},
+  location = {{Sousse, Tunisia}},
+  abstract = {Product configurators are considered to be among the most successful applications of artificial intelligence technology. In this paper, we determine different conceptualizations of configurators and condense them in a comprehensive morphological box, which should support configurator designers as well as decision makers in selecting the right system. The analysis of the criteria according to which configurators that are designed thus far reveals a neglect of the front-end perspective. Therefore, it is relevant to extend configurators with a front-end component assisting customers during product configuration through advisory. We develop a framework describing the main requirements on an advisory system and propose the technical infrastructure for its implementation. Finally, the advisory system and the configurator are integrated into a comprehensive interaction system.},
+  eventtitle = {{{MCSEAI}} 2004},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\XVBC4BP8\\Blecker et al. - Product Configuration Systems - State of the Art -.pdf},
+  langid = {english}
+}
+
 @article{bonnerEffectsMemberExpertise2002,
   title = {The Effects of Member Expertise on Group Decision-Making and Performance},
   author = {Bonner, Bryan L and Baumann, Michael R and Dalal, Reeshad S},
@@ -145,6 +179,22 @@
   number = {4}
 }
 
+@article{cachedaComparisonCollaborativeFiltering2011,
+  title = {Comparison of Collaborative Filtering Algorithms: {{Limitations}} of Current Techniques and Proposals for Scalable, High-Performance Recommender Systems},
+  shorttitle = {Comparison of Collaborative Filtering Algorithms},
+  author = {Cacheda, Fidel and Carneiro, V\'ictor and Fern\'andez, Diego and Formoso, Vreixo},
+  date = {2011-02-01},
+  journaltitle = {ACM Transactions on the Web},
+  shortjournal = {ACM Trans. Web},
+  volume = {5},
+  pages = {1--33},
+  issn = {15591131},
+  doi = {10.1145/1921591.1921593},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\9W6LI9NE\\Cacheda et al. - 2011 - Comparison of collaborative filtering algorithms .pdf},
+  langid = {english},
+  number = {1}
+}
+
 @article{carboneIndividualVsGroup2019,
   title = {Individual vs. Group Decision-Making: An Experiment on Dynamic Choice under Risk and Ambiguity},
   shorttitle = {Individual vs. Group Decision-Making},
@@ -170,6 +220,14 @@
   type = {Company Website}
 }
 
+@online{CASSoftwareAGa,
+  title = {{{CAS Software AG}} | {{CAS Software AG}}},
+  url = {https://www.cas.de/https://www.cas.de/en/company/cas-software-ag.html},
+  urldate = {2020-04-27},
+  abstract = {\{\$og.description\}},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\VJW2SBRW\\cas-software-ag.html}
+}
+
 @article{charnessGroupsMakeBetter2012,
   title = {Groups {{Make Better Self}}-{{Interested Decisions}}},
   author = {Charness, Gary and Sutter, Matthias},
@@ -233,25 +291,8 @@
   langid = {english}
 }
 
-@inproceedings{choudharyMulticriteriaGroupRecommender2020,
-  title = {Multi-Criteria {{Group Recommender System Based}} on {{Analytical Hierarchy Process}}},
-  booktitle = {Smart {{Systems}} and {{IoT}}: {{Innovations}} in {{Computing}}},
-  author = {Choudhary, Nirmal and Bharadwaj, K. K.},
-  editor = {Somani, Arun K. and Shekhawat, Rajveer Singh and Mundra, Ankit and Srivastava, Sumit and Verma, Vivek Kumar},
-  date = {2020},
-  pages = {75--84},
-  publisher = {{Springer}},
-  location = {{Singapore}},
-  doi = {10.1007/978-981-13-8406-6_8},
-  abstract = {Current researches have demonstrated that the significance of Multi-Criteria Decision-Making (MCDM) methods in Group Recommender Systems (GRSs) has yet to be thoroughly discovered. Thus, we have proposed a Multi-criteria GRS (MCGRS) to provide recommendations for group of users based on multi-criteria optimization. The idea behind our approach is that, each member in a group have different opinions about each criterion and he/she would try to make the best use of multi-criteria to fulfill his/her own preference in decision-making process. Therefore, we have employed Analytical Hierarchy Process (AHP) to learn the priority of each criterion to maximize the utility for each criterion. Then, MCGRS generate the most appropriate recommendation for the group. Experiments are performed on Yahoo! Movies dataset and the results of comparative analysis of proposed MCGRS with baseline GRSs techniques clearly demonstrate the supremacy of our proposed model.},
-  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\EFVTG9VE\\Choudhary_Bharadwaj_2020_Multi-criteria Group Recommender System Based on Analytical Hierarchy Process.pdf;C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\GCKZA5ZN\\2018_MA_Rubinshteyn_Hybrider Recommender für die Produktkonfiguration.pdf},
-  isbn = {9789811384066},
-  keywords = {Analytical hierarchy process,Decision-making,Multi-criteria group recommender systems,Recommendation mechanism},
-  langid = {english},
-  series = {Smart {{Innovation}}, {{Systems}} and {{Technologies}}}
-}
-
-@incollection{choudharyMulticriteriaGroupRecommender2020a,
+@incollection{choudharyMulticriteriaGroupRecommender2020,
+  ids = {choudharyMulticriteriaGroupRecommender2020},
   title = {Multi-Criteria {{Group Recommender System Based}} on {{Analytical Hierarchy Process}}},
   booktitle = {Smart {{Systems}} and {{IoT}}: {{Innovations}} in {{Computing}}},
   author = {Choudhary, Nirmal and Bharadwaj, K. K.},
@@ -263,11 +304,40 @@
   location = {{Singapore}},
   doi = {10.1007/978-981-13-8406-6_8},
   abstract = {Current researches have demonstrated that the significance of MultiCriteria Decision-Making (MCDM) methods in Group Recommender Systems (GRSs) has yet to be thoroughly discovered. Thus, we have proposed a Multi-criteria GRS (MCGRS) to provide recommendations for group of users based on multicriteria optimization. The idea behind our approach is that, each member in a group have different opinions about each criterion and he/she would try to make the best use of multi-criteria to fulfill his/her own preference in decision-making process. Therefore, we have employed Analytical Hierarchy Process (AHP) to learn the priority of each criterion to maximize the utility for each criterion. Then, MCGRS generate the most appropriate recommendation for the group. Experiments are performed on Yahoo! Movies dataset and the results of comparative analysis of proposed MCGRS with baseline GRSs techniques clearly demonstrate the supremacy of our proposed model.},
-  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\NN5RCJY2\\Choudhary und Bharadwaj - 2020 - Multi-criteria Group Recommender System Based on A.pdf},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\EFVTG9VE\\Choudhary_Bharadwaj_2020_Multi-criteria Group Recommender System Based on Analytical Hierarchy Process.pdf;C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\NN5RCJY2\\Choudhary und Bharadwaj - 2020 - Multi-criteria Group Recommender System Based on A.pdf},
   isbn = {9789811384059 9789811384066},
+  keywords = {Analytical hierarchy process,Decision-making,Multi-criteria group recommender systems,Recommendation mechanism},
   langid = {english}
 }
 
+@article{chrysanthis1998recovery,
+  title = {Recovery and Performance of Atomic Commit Processing in Distributed Database Systems},
+  author = {Chrysanthis, PK and Samaras, G and Al-Houmaily, YJ},
+  date = {1998},
+  journaltitle = {Recovery Mechanisms in Database Systems},
+  pages = {370--416},
+  publisher = {{Prentice-Hall}},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\XBEKIEQ9\\Chrysanthis et al. - 1998 - Recovery and performance of atomic commit processi.pdf}
+}
+
+@online{ConfigurationSolutions,
+  title = {Configuration {{Solutions}}},
+  journaltitle = {CAS Merlin},
+  url = {https://www.cas-merlin.com/configuration-solutions.html},
+  urldate = {2020-04-27},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\IC3W4XAG\\configuration-solutions.html}
+}
+
+@online{cookACIDBASEDatabase2009,
+  title = {{{ACID}} versus {{BASE}} for Database Transactions},
+  author = {Cook, John D.},
+  date = {2009-07-06},
+  journaltitle = {John D. Cook Consulting},
+  url = {https://www.johndcook.com/blog/2009/07/06/brewer-cap-theorem-base/},
+  urldate = {2020-04-27},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\NEN4DCZV\\brewer-cap-theorem-base.html}
+}
+
 @inproceedings{cosley2003seeing,
   title = {Is Seeing Believing?: How Recommender System Interfaces Affect Users' Opinions},
   booktitle = {Proceedings of the {{SIGCHI}} Conference on {{Human}} Factors in Computing Systems},
@@ -278,6 +348,24 @@
   organization = {{ACM}}
 }
 
+@article{costerEnhancingWebbasedConfiguration,
+  title = {Enhancing Web-Based Configuration with Recommendations and Cluster-Based Help},
+  author = {Coster, Rickard and Gustavsson, Andreas and Olsson, Tomas},
+  pages = {10},
+  abstract = {In a collaborative project with Tacton AB, we have investigated new ways of assisting the user in the process of on-line product configuration. A web-based prototype, RIND, was built for ephemeral users in the domain of PC configuration.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\5VQLH7YB\\Coster et al. - Enhancing web-based configuration with recommendati.pdf},
+  langid = {english}
+}
+
+@article{costerEnhancingWebbasedConfigurationa,
+  title = {Enhancing Web-Based Configuration with Recommendations and Cluster-Based Help},
+  author = {Coster, Rickard and Gustavsson, Andreas and Olsson, Tomas},
+  pages = {10},
+  abstract = {In a collaborative project with Tacton AB, we have investigated new ways of assisting the user in the process of on-line product configuration. A web-based prototype, RIND, was built for ephemeral users in the domain of PC configuration.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\WGJLRB9Q\\Coster et al. - Enhancing web-based configuration with recommendati.pdf},
+  langid = {english}
+}
+
 @article{crottGroupDecisionChoice1991,
   title = {Group Decision, Choice Shift, and Polarization in Consulting, Political, and Local Political Scenarios: {{An}} Experimental Investigation and Theoretical Analysis},
   shorttitle = {Group Decision, Choice Shift, and Polarization in Consulting, Political, and Local Political Scenarios},
@@ -294,6 +382,15 @@
   number = {1}
 }
 
+@inproceedings{de2002importance,
+  title = {On the Importance of the Separation-of-Concerns Principle in Secure Software Engineering},
+  booktitle = {Workshop on the Application of Engineering Principles to System Security Design},
+  author = {De Win, Bart and Piessens, Frank and Joosen, Wouter and Verhanneman, Tine},
+  date = {2002},
+  pages = {1--10},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\RKSI6M9G\\Verhanneman - On the importance of the separation-of-concerns pr.pdf}
+}
+
 @inproceedings{delgadoSimpleObjectivesWork2019,
   title = {Simple {{Objectives Work Better}}},
   booktitle = {Proceedings of the {{Workshop}} on {{Recommendation}} in {{Multi}}-Stakeholder {{Environments}}},
@@ -315,6 +412,31 @@
   langid = {english}
 }
 
+@article{dewinImportanceSeparationofconcernsPrinciple2002,
+  title = {On the Importance of the Separation-of-Concerns Principle in Secure Software Engineering},
+  author = {De Win, Bart and Piessens, Frank and Joosen, Wouter and Verhanneman, Tine},
+  date = {2002-09-30},
+  pages = {10},
+  abstract = {The separation-of-concerns principle is one of the essential principles in software engineering. It says that software should be decomposed in such a way that different ``concerns'' or aspects of the problem at hand are solved in well-separated modules or parts of the software. Yet, many security experts feel uneasy about trying to isolate security-related concerns, because security is such a pervasive property of a piece of software. And in fact, separating security-related concerns such as access control, or defensive input checking, is indeed very hard to achieve with current software engineering techniques.},
+  langid = {english}
+}
+
+@inproceedings{dingContextAwareRecommender2018,
+  title = {Context {{Aware Recommender System}} for {{Large Scaled Flash Sale Sites}}},
+  booktitle = {2018 {{IEEE International Conference}} on {{Big Data}} ({{Big Data}})},
+  author = {Ding, Wanying and Xu, Ran and Ding, Ying and Zhang, Yue and Luo, Chuanjiang and Yu, Zhendong},
+  date = {2018-12},
+  pages = {993--1000},
+  publisher = {{IEEE}},
+  location = {{Seattle, WA, USA}},
+  doi = {10.1109/BigData.2018.8622062},
+  abstract = {Flash Sale Sites popularize because they save great money for users. Good recommender systems can further save users' time to improve their online shopping experiences. Although there exsit a lot of studies on recommender system, very few focus on flash sale sites. Big Data, Context Sensitivity, and Feature Engineering are three key challenges for one to build a good recommender system. This paper proposes two deep learning oriented models: Tensor-AutoRec and HybridAutoRec to cope with the problems within an industrial context. First, these two models can handle storage and speed problem caused by big data. Second, both models incorporate context information, so they can generate more relevant recommendations by adapting to specific contextual situations. Third, our deep learning-based models can be trained end-to-end without tedious feature engineerings. Extensive experiments with a half year real transcation data demonstrate that our models can outperform classifcal ones in terms of different evaluation metrices. Finally, online A/B testing results showed that our model can improve our old recommendation system over various online performance indicators.},
+  eventtitle = {2018 {{IEEE International Conference}} on {{Big Data}} ({{Big Data}})},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\HMKXV8NX\\Ding et al. - 2018 - Context Aware Recommender System for Large Scaled .pdf},
+  isbn = {978-1-5386-5035-6},
+  langid = {english}
+}
+
 @article{elahiSurveyActiveLearning2016,
   title = {A Survey of Active Learning in Collaborative Filtering Recommender Systems},
   author = {Elahi, Mehdi and Ricci, Francesco and Rubens, Neil},
@@ -374,11 +496,28 @@
   langid = {english}
 }
 
+@incollection{felfernigAlgorithmsGroupRecommendation2018,
+  title = {Algorithms for {{Group Recommendation}}},
+  booktitle = {Group {{Recommender Systems}} : {{An Introduction}}},
+  author = {Felfernig, Alexander and Boratto, Ludovico and Stettinger, Martin and Tkal\v{c}i\v{c}, Marko},
+  editor = {Felfernig, Alexander and Boratto, Ludovico and Stettinger, Martin and Tkal\v{c}i\v{c}, Marko},
+  date = {2018},
+  pages = {27--58},
+  publisher = {{Springer International Publishing}},
+  location = {{Cham}},
+  doi = {10.1007/978-3-319-75067-5_2},
+  abstract = {In this chapter, our aim is to show how group recommendation can be implemented on the basis of recommendation paradigms for individual users. Specifically, we focus on collaborative filtering, content-based filtering, constraint-based, critiquing-based, and hybrid recommendation. Throughout this chapter, we differentiate between (1) aggregated predictions and (2) aggregated models as basic strategies for aggregating the preferences of individual group members.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\4JL9AY5X\\Felfernig et al_2018_Algorithms for Group Recommendation.pdf},
+  isbn = {978-3-319-75067-5},
+  langid = {english},
+  series = {{{SpringerBriefs}} in {{Electrical}} and {{Computer Engineering}}}
+}
+
 @incollection{felfernigBiasesGroupDecisions2018,
   title = {Biases in {{Group Decisions}}},
   booktitle = {Group {{Recommender Systems}} : {{An Introduction}}},
-  author = {Felfernig, Alexander and Boratto, Ludovico and Stettinger, Martin and Tkal{\v c}i{\v c}, Marko},
-  editor = {Felfernig, Alexander and Boratto, Ludovico and Stettinger, Martin and Tkal{\v c}i{\v c}, Marko},
+  author = {Felfernig, Alexander and Boratto, Ludovico and Stettinger, Martin and Tkal\v{c}i\v{c}, Marko},
+  editor = {Felfernig, Alexander and Boratto, Ludovico and Stettinger, Martin and Tkal\v{c}i\v{c}, Marko},
   date = {2018},
   pages = {145--155},
   publisher = {{Springer International Publishing}},
@@ -398,15 +537,15 @@
   date = {2008},
   pages = {3},
   abstract = {Recommender systems support users in identifying products and services in e-commerce and other information-rich environments. Recommendation problems have a long history as a successful AI application area, with substantial interest beginning in the mid1990s, and increasing with the subsequent rise of e-commerce. Recommender systems research long focused on recommending only simple products such as movies or books; constraint-based recommendation now receives increasing attention due to the capability of recommending complex products and services. In this paper, we first introduce a taxonomy of recommendation knowledge sources and algorithmic approaches. We then go on to discuss the most prevalent techniques of constraint-based recommendation and outline open research issues.},
-  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\BBYQH8IW\\Felfernig und Burke - Constraint-based Recommender Systems Technologies.pdf},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\BBYQH8IW\\Felfernig und Burke - Constraint-based Recommender Systems Technologies.pdf;C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\N6WZY4DL\\AConfiguration-basedRecommenderSystemForSupportingE-commerceDecisions.pdf},
   langid = {english}
 }
 
 @incollection{felfernigDecisionTasksBasic2018,
   title = {Decision {{Tasks}} and {{Basic Algorithms}}},
   booktitle = {Group {{Recommender Systems}} : {{An Introduction}}},
-  author = {Felfernig, Alexander and Boratto, Ludovico and Stettinger, Martin and Tkal{\v c}i{\v c}, Marko},
-  editor = {Felfernig, Alexander and Boratto, Ludovico and Stettinger, Martin and Tkal{\v c}i{\v c}, Marko},
+  author = {Felfernig, Alexander and Boratto, Ludovico and Stettinger, Martin and Tkal\v{c}i\v{c}, Marko},
+  editor = {Felfernig, Alexander and Boratto, Ludovico and Stettinger, Martin and Tkal\v{c}i\v{c}, Marko},
   date = {2018},
   pages = {3--26},
   publisher = {{Springer International Publishing}},
@@ -430,10 +569,27 @@
   langid = {english}
 }
 
+@incollection{felfernigGroupRecommenderApplications2018,
+  title = {Group {{Recommender Applications}}},
+  booktitle = {Group {{Recommender Systems}} : {{An Introduction}}},
+  author = {Felfernig, Alexander and Boratto, Ludovico and Stettinger, Martin and Tkal\v{c}i\v{c}, Marko},
+  editor = {Felfernig, Alexander and Boratto, Ludovico and Stettinger, Martin and Tkal\v{c}i\v{c}, Marko},
+  date = {2018},
+  pages = {75--89},
+  publisher = {{Springer International Publishing}},
+  location = {{Cham}},
+  doi = {10.1007/978-3-319-75067-5_4},
+  abstract = {In this chapter, we present an overview of different group recommender applications. We organize this overview into the application domains of music, movies and TV programs, travel destinations and events, news and web pages, healthy living, software engineering, and domain-independent recommenders. Each application is analyzed with regard to the characteristics of group recommenders as introduced in Chap. 2.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\49BRYWWD\\Felfernig et al_2018_Group Recommender Applications.pdf},
+  isbn = {978-3-319-75067-5},
+  langid = {english},
+  series = {{{SpringerBriefs}} in {{Electrical}} and {{Computer Engineering}}}
+}
+
 @book{felfernigGroupRecommenderSystems2018,
   title = {Group {{Recommender Systems An Introduction}}},
   shorttitle = {Group Recommender Systems},
-  author = {Felfernig, Alexander and Boratto, Ludovico and Stettinger, Martin and Tkal{\v c}i{\v c}, Marko},
+  author = {Felfernig, Alexander and Boratto, Ludovico and Stettinger, Martin and Tkal\v{c}i\v{c}, Marko},
   date = {2018},
   abstract = {This book presents group recommender systems, which focus on the determination of recommendations for groups of users. The authors summarize different technologies and applications of group recommender systems. They include an in-depth discussion of state-of-the-art algorithms, an overview of industrial applications, an inclusion of the aspects of decision biases in groups, and corresponding de-biasing approaches. The book includes a discussion of basic group recommendation methods, aspects of human decision making in groups, and related applications. A discussion of open research issues is included to inspire new related research. The book serves as a reference for researchers and practitioners working on group recommendation related topics.},
   file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\HC6C7C89\\Felfernig et al. - 2018 - Group recommender systems an introduction.pdf},
@@ -474,6 +630,22 @@
   langid = {english}
 }
 
+@inproceedings{felfernigPersonalizedUserInterfaces2010,
+  title = {Personalized User Interfaces for Product Configuration},
+  booktitle = {Proceedings of the 15th International Conference on {{Intelligent}} User Interfaces},
+  author = {Felfernig, Alexander and Mandl, Monika and Tiihonen, Juha and Schubert, Monika and Leitner, Gerhard},
+  date = {2010-02-07},
+  pages = {317--320},
+  publisher = {{Association for Computing Machinery}},
+  location = {{Hong Kong, China}},
+  doi = {10.1145/1719970.1720020},
+  abstract = {Configuration technologies are well established as a foundation of mass customization which is a production paradigm that supports the manufacturing of highly-variant products under pricing conditions similar to mass production. A side-effect of the high diversity of products offered by a configurator is that the complexity of the alternatives may outstrip a user's capability to explore them and make a buying decision. In order to improve the quality of configuration processes, we combine knowledge-based configuration with collaborative and content-based recommendation algorithms. In this paper we present configuration techniques that recommend personalized default values to users. Results of an empirical study show improvements in terms of, for example, user satisfaction or the quality of the configuration process.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\FRT6HPDN\\Felfernig et al. - 2010 - Personalized user interfaces for product configura.pdf},
+  isbn = {978-1-60558-515-4},
+  keywords = {configuration systems,model-based diagnosis,recommender systems},
+  series = {{{IUI}} '10}
+}
+
 @inproceedings{felfernigPersuasiveRecommendationSerial2007,
   title = {Persuasive {{Recommendation}}: {{Serial Position Effects}} in {{Knowledge}}-{{Based Recommender Systems}}},
   shorttitle = {Persuasive {{Recommendation}}},
@@ -536,6 +708,46 @@
   langid = {english}
 }
 
+@online{FlaskDocumentation,
+  title = {Flask {{Documentation}} (1.1.x)},
+  url = {https://flask.palletsprojects.com/en/1.1.x/},
+  urldate = {2020-04-09},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\IYAG7QV6\\1.1.x.html}
+}
+
+@online{FlaskRESTPlus13Documentation,
+  title = {Flask-{{RESTPlus}} 0.13.0 Documentation},
+  url = {https://flask-restplus.readthedocs.io/en/stable/},
+  urldate = {2020-04-09},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\CI5RGD28\\stable.html}
+}
+
+@book{gamma2015design,
+  title = {Design patterns: Entwurfsmuster als elemente wiederverwendbarer objektorientierter software},
+  author = {Gamma, Erich and Helm, Richard and Johnson, Ralph and Vlissides, John},
+  date = {2015},
+  publisher = {{MITP-Verlags GmbH \& Co. KG}},
+  langid = {german}
+}
+
+@inproceedings{garciaGroupRecommenderSystem2009,
+  title = {A {{Group Recommender System}} for {{Tourist Activities}}},
+  booktitle = {E-{{Commerce}} and {{Web Technologies}}},
+  author = {Garcia, Inma and Sebastia, Laura and Onaindia, Eva and Guzman, Cesar},
+  editor = {Di Noia, Tommaso and Buccafurri, Francesco},
+  date = {2009},
+  pages = {26--37},
+  publisher = {{Springer}},
+  location = {{Berlin, Heidelberg}},
+  doi = {10.1007/978-3-642-03964-5_4},
+  abstract = {This paper introduces a method for giving recommendations of tourist activities to a group of users. This method makes recommendations based on the group tastes, their demographic classification and the places visited by the users in former trips. The group recommendation is computed from individual personal recommendations through the use of techniques such as aggregation, intersection or incremental intersection. This method is implemented as an extension of the e-Tourism tool, which is a user-adapted tourism and leisure application, whose main component is the Generalist Recommender System Kernel (GRSK), a domain-independent taxonomy-driven search engine that manages the group recommendation.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\JDW2ZGP8\\Garcia et al_2009_A Group Recommender System for Tourist Activities.pdf},
+  isbn = {978-3-642-03964-5},
+  keywords = {Group Recommenders,Recommender Systems,Tourism},
+  langid = {english},
+  series = {Lecture {{Notes}} in {{Computer Science}}}
+}
+
 @article{glogerScrumPradigmenwechselIm2010,
   title = {Scrum: Der Pradigmenwechsel im Projekt- und Produktmanagement \textendash{} Eine Einf\"uhrung},
   shorttitle = {Scrum},
@@ -552,6 +764,75 @@
   number = {2}
 }
 
+@inproceedings{grasIdentifyingGreySheep2016,
+  title = {Identifying {{Grey Sheep Users}} in {{Collaborative Filtering}}: {{A Distribution}}-{{Based Technique}}},
+  shorttitle = {Identifying {{Grey Sheep Users}} in {{Collaborative Filtering}}},
+  booktitle = {Proceedings of the 2016 {{Conference}} on {{User Modeling Adaptation}} and {{Personalization}}},
+  author = {Gras, Benjamin and Brun, Armelle and Boyer, Anne},
+  date = {2016-07-13},
+  pages = {17--26},
+  publisher = {{Association for Computing Machinery}},
+  location = {{Halifax, Nova Scotia, Canada}},
+  doi = {10.1145/2930238.2930242},
+  abstract = {The collaborative filtering (CF) approach in recommender systems assumes that users' preferences are consistent among users. Although accurate, this approach fails on some users. We presume that some of these users belong to a small community of users who have unusual preferences, such users are not compliant with the CF underlying assumption. They are grey sheep users. This paper aims at accurately identifying grey sheep users. We introduce a new distribution-based grey sheep users identification technique, that borrows from outlier detection and from information retrieval, while taking into account the specificities of preference data on which CF relies: extreme sparsity, imprecision and users' bias. The experimental evaluation conducted on a state-of-the-art dataset shows that this new distribution-based technique outperforms state-of-the-art grey sheep users identification techniques.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\5RQPTIUR\\Gras et al_2016_Identifying Grey Sheep Users in Collaborative Filtering.pdf},
+  isbn = {978-1-4503-4368-8},
+  keywords = {collaborative filtering,grey sheep users,outlier detection,recommender systems},
+  series = {{{UMAP}} '16}
+}
+
+@article{haagProductConfigurationDecision2011,
+  title = {Product Configuration as Decision Support: {{The}} Declarative Paradigm in Practice},
+  shorttitle = {Product Configuration as Decision Support},
+  author = {Haag, Albert and Riemann, Steffen},
+  date = {2011-05},
+  journaltitle = {Artificial Intelligence for Engineering Design, Analysis and Manufacturing},
+  shortjournal = {AIEDAM},
+  volume = {25},
+  pages = {131--142},
+  issn = {0890-0604, 1469-1760},
+  doi = {10.1017/S0890060410000582},
+  abstract = {Product configuration is a key technology, which enables businesses to deliver and deploy individualized products. In many cases, finding the optimal configuration solution for the user is a creative process that requires them to decide trade-offs between conflicting goals (multicriteria optimization problem). These problems are best supported by an interactive dialog that is managed by a dedicated software program (the configurator) that provides decision support. We illustrate this using a real example (configuration of a business software system). This productively used application makes the user aware of which choices are available in a given situation, provides assistance in resolving inconsistent choices and defaults, and generates explanations if desired. One of the key configurator components used to manage this is a truth maintenance system. We describe how this component is used and two novel extensions to it: methods for declarative handling of defaults (of varying strength) and the declarative handling of incompleteness. Finally, we summarize our experiences made during the implementation of this application and the pros and cons of declarative versus procedural approaches.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\CCLKMSQI\\Haag and Riemann - 2011 - Product configuration as decision support The dec.pdf},
+  langid = {english},
+  number = {2}
+}
+
+@article{habraSoftwareEngineeringEducation,
+  title = {In {{Software Engineering Education}}},
+  author = {Habra, Naji},
+  pages = {6},
+  abstract = {Separation of concerns is the main principle of Software Engineering. It represents a key element in the teaching process of any Software Engineering methodology. The paper relates the experience of the University of Namur in introducing the separation of concerns principle in its educational scheme through an extended student project.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\MVX62LT3\\Habra - in Software Engineering Education.pdf},
+  langid = {english}
+}
+
+@article{hahslerRecommenderlabFrameworkDeveloping,
+  title = {Recommenderlab: {{A Framework}} for {{Developing}} and {{Testing Recommendation Algorithms}}},
+  author = {Hahsler, Michael},
+  pages = {40},
+  abstract = {The problem of creating recommendations given a large data base from directly elicited ratings (e.g., ratings of 1 through 5 stars) is a popular research area which was lately boosted by the Netflix Prize competition. While several libraries which implement recommender algorithms have been developed over the last decade there is still the need for a framework which facilitates research on recommender systems by providing a common development and evaluation environment. This paper describes recommenderlab which provides the infrastructure to develop and test recommender algorithms for rating data and 0-1 data in a unified framework. The Package provides basic algorithms and allows the user to develop and use his/her own algorithms in the framework via a simple registration procedure.},
+  langid = {english}
+}
+
+@report{hahslerRecommenderlabFrameworkDeveloping2015,
+  title = {Recommenderlab: {{A Framework}} for {{Developing}} and {{Testing Recommendation Algorithms}}},
+  author = {Hahsler, Michael},
+  date = {2015},
+  url = {http://elib.ict.nsc.ru/jspui/handle/ICT/1861},
+  urldate = {2020-02-19},
+  abstract = {The problem of creating recommendations given a large data base from directly elicited 
+ratings (e.g., ratings of 1 through 5 stars) is a popular research area which was lately 
+boosted by the Netflix Prize competition. While several libraries which implement recommender algorithms have been developed over the last decade there is still the need for 
+a framework which facilitates research on recommender systems by providing a common 
+development and evaluation environment. This paper describes recommenderlab which 
+provides the infrastructure to develop and test recommender algorithms for rating data 
+and 0-1 data in a unified framework. The Package provides basic algorithms and allows the 
+user to develop and use his/her own algorithms in the framework via a simple registration 
+procedure.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\5T2FEWC3\\Hahsler_2015_recommenderlab.pdf}
+}
+
 @article{hernandezdelolmoEvaluationRecommenderSystems2008,
   title = {Evaluation of Recommender Systems: {{A}} New Approach},
   shorttitle = {Evaluation of Recommender Systems},
@@ -642,6 +923,21 @@
   number = {3}
 }
 
+@online{IndustrySpecificProduct2020,
+  title = {Industry Specific Product Configuration with {{CAS SmartCustomization}}},
+  date = {2020-03-23},
+  url = {https://www.cas-merlin.com/configuration-solutions.html},
+  urldate = {2020-03-23},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\9CJPCDKA\\configuration-solutions.html}
+}
+
+@online{IntroducingJSON,
+  title = {Introducing {{JSON}}},
+  url = {https://www.json.org/json-en.html},
+  urldate = {2020-05-09},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\IJHHAP8I\\json-en.html}
+}
+
 @incollection{jamesonRecommendationGroups2007,
   title = {Recommendation to {{Groups}}},
   booktitle = {The {{Adaptive Web}}: {{Methods}} and {{Strategies}} of {{Web Personalization}}},
@@ -677,6 +973,23 @@
   file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\3JN8DV3U\\griffin-groupthink-challenger.pdf}
 }
 
+@online{JSON,
+  title = {{{JSON}}},
+  url = {https://www.json.org/json-de.html},
+  urldate = {2020-05-09},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\2WIVRT7V\\json-de.html}
+}
+
+@software{junEugeneeeoTinyrecord2020,
+  title = {Eugene-Eeo/Tinyrecord},
+  author = {Jun, Eeo},
+  date = {2020-02-01T17:00:35Z},
+  origdate = {2014-08-26T01:58:44Z},
+  url = {https://github.com/eugene-eeo/tinyrecord},
+  urldate = {2020-04-09},
+  abstract = {transaction support for TinyDB. Contribute to eugene-eeo/tinyrecord development by creating an account on GitHub.}
+}
+
 @article{kerrBiasJudgmentComparing1996,
   title = {Bias in Judgment: {{Comparing}} Individuals and Groups.},
   author = {Kerr, Norbert L and MacCoun, Robert J and Kramer, Geoffrey P},
@@ -706,6 +1019,43 @@
   langid = {english}
 }
 
+@inproceedings{kohaviStudyCrossValidationBootstrap1995,
+  title = {A {{Study}} of {{Cross}}-{{Validation}} and {{Bootstrap}} for {{Accuracy Estimation}} and {{Model Selection}}},
+  author = {Kohavi, Ron},
+  date = {1995},
+  pages = {1137--1143},
+  publisher = {{Morgan Kaufmann}},
+  abstract = {We review accuracy estimation methods and compare the two most common methods: crossvalidation and bootstrap. Recent experimental results on artificial data and theoretical results in restricted settings have shown that for selecting a good classifier from a set of classifiers (model selection), ten-fold cross-validation may be better than the more expensive leaveone -out cross-validation. We report on a largescale experiment---over half a million runs of C4.5 and a Naive-Bayes algorithm---to estimate the effects of different parameters on these algorithms on real-world datasets. For crossvalidation, we vary the number of folds and whether the folds are stratified or not; for bootstrap, we vary the number of bootstrap samples. Our results indicate that for real-word datasets similar to ours, the best method to use for model selection is ten-fold stratified cross validation, even if computation power allows using more folds. 1 Introduction It can not be emphasized enough that no claim ...},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\GGH5NYBZ\\Kohavi_1995_A Study of Cross-Validation and Bootstrap for Accuracy Estimation and Model.pdf;C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\M7BT7CCG\\summary.html}
+}
+
+@online{kuchelmeister13hannes11BachelorThesis,
+  title = {13hannes11/Bachelor\_thesis\_m.Recommend},
+  author = {Kuchelmeister, Hannes F.},
+  journaltitle = {GitHub},
+  url = {https://github.com/13hannes11/bachelor_thesis_m.recommend},
+  urldate = {2020-05-12},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\8UURN4KL\\bachelor_thesis_m.html},
+  langid = {english}
+}
+
+@article{likaFacingColdStart2014,
+  title = {Facing the Cold Start Problem in Recommender Systems},
+  author = {Lika, Blerina and Kolomvatsos, Kostas and Hadjiefthymiades, Stathes},
+  date = {2014-03-01},
+  journaltitle = {Expert Systems with Applications},
+  shortjournal = {Expert Systems with Applications},
+  volume = {41},
+  pages = {2065--2073},
+  issn = {0957-4174},
+  doi = {10.1016/j.eswa.2013.09.005},
+  abstract = {A recommender system (RS) aims to provide personalized recommendations to users for specific items (e.g., music, books). Popular techniques involve content-based (CB) models and collaborative filtering (CF) approaches. In this paper, we deal with a very important problem in RSs: The cold start problem. This problem is related to recommendations for novel users or new items. In case of new users, the system does not have information about their preferences in order to make recommendations. We propose a model where widely known classification algorithms in combination with similarity techniques and prediction mechanisms provide the necessary means for retrieving recommendations. The proposed approach incorporates classification methods in a pure CF system while the use of demographic data help for the identification of other users with similar behavior. Our experiments show the performance of the proposed system through a large number of experiments. We adopt the widely known dataset provided by the GroupLens research group. We reveal the advantages of the proposed solution by providing satisfactory numerical results in different experimental scenarios.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\MLFV7EWY\\Lika et al_2014_Facing the cold start problem in recommender systems.pdf;C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\CW4M95HK\\S0957417413007240.html},
+  issue = {4, Part 2},
+  keywords = {Cold start problem,Recommender systems},
+  langid = {english}
+}
+
 @inproceedings{liuCGSPAComprehensiveGroup2019,
   title = {{{CGSPA}}: {{Comprehensive Group Similarity Preference Aggregation Algorithm}} for {{Group Itinerary Recommendation System}}},
   shorttitle = {{{CGSPA}}},
@@ -717,7 +1067,7 @@
   doi = {10.1109/IEMCON.2019.8936245},
   abstract = {One of the key factors to group multi-session recommendation system is about aggregating the preference of all users. To address the specific issues, we propose the Comprehensive Group Similarity Preference Aggregation (CGSPA) algorithm for Group Itinerary Recommendation System implemented in this paper. CGSPA comprehensively considers three aspects to aggregate group preference requirement, which are (1) the average maximum similarity between the recommendation plan and group preference; (2) the difference between the similarity of each session in the recommendation plan and the corresponding preference needs of the user group; (3) the historical similarity between the recommendation plan and group preference. We conduct extensive experiments to verify the preference aggregation performance and the robustness of CGSPA algorithm. We conclude that with different group scales, CGSPA's group average satisfaction score is higher compared to the traditional preference aggregation algorithms.},
   eventtitle = {2019 {{IEEE}} 10th {{Annual Information Technology}}, {{Electronics}} and {{Mobile Communication Conference}} ({{IEMCON}})},
-  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\5I8BJ3LW\\Liu et al_2019_CGSPA.pdf},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\5I8BJ3LW\\Liu et al_2019_CGSPA.pdf;C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\B9MHB67G\\8936245.html},
   keywords = {CGSPA,Group Itinerary Recommendation,Preference Aggregation Algorithm,Recommendation System}
 }
 
@@ -742,9 +1092,78 @@
   note = {ZSCC: 0000001}
 }
 
+@book{martinCleanArchitectureCraftsman2017,
+  title = {Clean {{Architecture}}: {{A Craftsman}}'s {{Guide}} to {{Software Structure}} and {{Design}}},
+  shorttitle = {Clean {{Architecture}}},
+  author = {Martin, Robert C.},
+  date = {2017},
+  edition = {1st},
+  publisher = {{Prentice Hall Press}},
+  location = {{USA}},
+  abstract = {Practical Software Architecture Solutions from the Legendary Robert C. Martin (Uncle Bob) By applying universal rules of software architecture, you can dramatically improve developer productivity throughout the life of any software system. Now, building upon the success of his best-selling books Clean Code and The Clean Coder, legendary software craftsman Robert C. Martin (Uncle Bob) reveals those rules and helps you apply them. Martins Clean Architecture doesnt merely present options. Drawing on over a half-century of experience in software environments of every imaginable type, Martin tells you what choices to make and why they are critical to your success. As youve come to expect from Uncle Bob, this book is packed with direct, no-nonsense solutions for the real challenges youll facethe ones that will make or break your projects. Learn what software architects need to achieveand core disciplines and practices for achieving it Master essential software design principles for addressing function, component separation, and data management See how programming paradigms impose discipline by restricting what developers can do Understand whats critically important and whats merely a detail Implement optimal, high-level structures for web, database, thick-client, console, and embedded applications Define appropriate boundaries and layers, and organize components and services See why designs and architectures go wrong, and how to prevent (or fix) these failures Clean Architecture is essential reading for every current or aspiring software architect, systems analyst, system designer, and software managerand for every programmer who must execute someone elses designs. Register your product at informit.com/register for convenient access to downloads, updates, and/or corrections as they become available.},
+  isbn = {978-0-13-449416-6},
+  pagetotal = {432}
+}
+
+@incollection{Masthoff2015,
+  title = {Group Recommender Systems: {{Aggregation}}, Satisfaction and Group Attributes},
+  booktitle = {Recommender Systems Handbook},
+  author = {Masthoff, Judith},
+  editor = {Ricci, Francesco and Rokach, Lior and Shapira, Bracha},
+  date = {2015},
+  pages = {743--776},
+  publisher = {{Springer US}},
+  location = {{Boston, MA}},
+  doi = {10.1007/978-1-4899-7637-6\%00822},
+  abstract = {Thisgroup recommender systemsatisfactionchapter shows how a system can recommend to a group of users by aggregating information from individual user models and modeling the user's affective stateaffective state. It summarizes results from previous research in these areas. It explores how group attributes can be incorporated in aggregationaggregationstrategies. Additionally, it shows how group recommendationgroup recommender systemtechniques can be applied when recommending to individuals, in particular for solving the cold-start problem and dealing with multiple criteria.},
+  isbn = {978-1-4899-7637-6}
+}
+
+@online{MatplotlibDocumentation,
+  title = {Matplotlib 3.2.1 Documentation},
+  url = {https://matplotlib.org/},
+  urldate = {2020-04-09},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\C75Q6QS8\\matplotlib.org.html}
+}
+
+@incollection{mazoRecommendationHeuristicsImproving2014,
+  title = {Recommendation {{Heuristics}} for {{Improving Product Line Configuration Processes}}},
+  booktitle = {Recommendation {{Systems}} in {{Software Engineering}}},
+  author = {Mazo, Ra\'ul and Dumitrescu, Cosmin and Salinesi, Camille and Diaz, Daniel},
+  editor = {Robillard, Martin P. and Maalej, Walid and Walker, Robert J. and Zimmermann, Thomas},
+  date = {2014},
+  pages = {511--537},
+  publisher = {{Springer}},
+  location = {{Berlin, Heidelberg}},
+  doi = {10.1007/978-3-642-45135-5_19},
+  abstract = {In mass customization industries, such as car manufacturing, configurators play an important role both to interact with customers and in engineering processes. This is particularly true when engineers rely on reuse of assets and product line engineering techniques. Theoretically, product line configuration should be guided by the product line model. However, in the industrial context, the configuration of products from product line models is complex and error-prone due to the large number of variables in the models. The configuration activity quickly becomes cumbersome due to the number of decisions needed to get a proper configuration, to the fact that they should be taken in predefined order, or the poor response time of configurators when decisions are not appropriate. This chapter presents a collection of recommendation heuristics to improve the interactivity of product line configuration so as to make it scalable to common engineering situations. We describe the principles, benefits, and the implementation of each heuristic using constraint programming. The application and usability of the heuristics is demonstrated using a case study from the car industry.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\IB6XF8FF\\Mazo et al_2014_Recommendation Heuristics for Improving Product Line Configuration Processes.pdf},
+  isbn = {978-3-642-45135-5},
+  keywords = {Configuration Process,Constraint Program,Product Line,Product Line Engineering,Variation Point},
+  langid = {english}
+}
+
+@inproceedings{mcsherrySimilarityCompromise2003,
+  title = {Similarity and {{Compromise}}},
+  booktitle = {Case-{{Based Reasoning Research}} and {{Development}}},
+  author = {McSherry, David},
+  editor = {Ashley, Kevin D. and Bridge, Derek G.},
+  date = {2003},
+  pages = {291--305},
+  publisher = {{Springer}},
+  location = {{Berlin, Heidelberg}},
+  doi = {10.1007/3-540-45006-8_24},
+  abstract = {A common cause of retrieval failure in case-based reasoning (CBR) approaches to product recommendation is that the retrieved cases, usually those that are most similar to the target query, are not sufficiently representative of compromises that the user may be prepared to make. We present a new approach to retrieval in which similarity and compromise play complementary roles, thereby increasing the likelihood that one of the retrieved cases will be acceptable to the user. We also show how the approach can be extended to address the requirements of domains in which the user is not just seeking a single item that closely matches her query, but would like to be informed of all items that are likely to be of interest.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\G43RIHRD\\McSherry_2003_Similarity and Compromise.pdf},
+  isbn = {978-3-540-45006-1},
+  keywords = {Average Success Rate,Case Library,Monitor Size,Query Refinement,Recommender System},
+  langid = {english},
+  series = {Lecture {{Notes}} in {{Computer Science}}}
+}
+
 @article{mendoncaCollaborativeProductConfiguration2008,
   title = {Collaborative {{Product Configuration}}},
-  author = {Mendon{\c c}a, Marc\'ilio and Cowan, Donald and Malyk, William and Oliveira, Toacy},
+  author = {Mendon\c{c}a, Marc\'ilio and Cowan, Donald and Malyk, William and Oliveira, Toacy},
   date = {2008-01},
   journaltitle = {Journal of Software},
   shortjournal = {JSW},
@@ -834,6 +1253,13 @@
   langid = {english}
 }
 
+@online{NumPy,
+  title = {{{NumPy}}},
+  url = {https://numpy.org/},
+  urldate = {2020-04-09},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\3QGT59ZB\\numpy.org.html}
+}
+
 @inproceedings{offermannOutlineDesignScience2009,
   title = {Outline of a Design Science Research Process},
   booktitle = {Proceedings of the 4th {{International Conference}} on {{Design Science Research}} in {{Information Systems}} and {{Technology}} - {{DESRIST}} '09},
@@ -849,6 +1275,13 @@
   langid = {english}
 }
 
+@online{PandasPythonData,
+  title = {Pandas - {{Python Data Analysis Library}}},
+  url = {https://pandas.pydata.org/},
+  urldate = {2020-04-09},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\FD9I7UUJ\\pandas.pydata.org.html}
+}
+
 @article{peffersDesignScienceResearch2007,
   title = {A {{Design Science Research Methodology}} for {{Information Systems Research}}},
   author = {Peffers, Ken and Tuunanen, Tuure and Rothenberger, Marcus A. and Chatterjee, Samir},
@@ -879,6 +1312,24 @@
   number = {3}
 }
 
+@article{peraGroupRecommenderMovies2013,
+  title = {A Group Recommender for Movies Based on Content Similarity and Popularity},
+  author = {Pera, Maria S. and Ng, Yiu-Kai},
+  date = {2013-05-01},
+  journaltitle = {Information Processing \& Management},
+  shortjournal = {Information Processing \& Management},
+  volume = {49},
+  pages = {673--687},
+  issn = {0306-4573},
+  doi = {10.1016/j.ipm.2012.07.007},
+  abstract = {People are gregarious by nature, which explains why group activities, from colleagues sharing a meal to friends attending a book club event together, are the social norm. Online group recommenders identify items of interest, such as restaurants, movies, and books, that satisfy the collective needs of a group (rather than the interests of individual group members). With a number of new movies being released every week, online recommenders play a significant role in suggesting movies for family members or groups of friends/people to watch, either at home or at movie theaters. Making group recommendations relevant to the joint interests of a group, however, is not a trivial task due to the diversity in preferences among group members. To address this issue, we introduce GroupReM which makes movie recommendations appealing (to a certain degree) to members of a group by (i) employing a merging strategy to explore individual group members' interests in movies and create a profile that reflects the preferences of the group on movies, (ii) using word-correlation factors to find movies similar in content, and (iii) considering the popularity of movies at a movie website. Unlike existing group recommenders based on collaborative filtering (CF) which consider ratings of movies to perform the recommendation task, GroupReM primarily employs (personal) tags for capturing the contents of movies considered for recommendation and group members' interests. The design of GroupReM, which is simple and domain-independent, can easily be extended to make group recommendations on items other than movies. Empirical studies conducted using more than 3000 groups of different users in the MovieLens dataset, which are various in terms of numbers and preferences in movies, show that GroupReM is highly effective and efficient in recommending movies appealing to a group. Experimental results also verify that GroupReM outperforms popular CF-based recommenders in making group recommendations.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\KXUX8URG\\Pera_Ng_2013_A group recommender for movies based on content similarity and popularity.pdf;C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\BWWR8DFF\\S0306457312001045.html},
+  keywords = {Content-similarity,Group recommender,Movie,Popularity},
+  langid = {english},
+  number = {3},
+  series = {Personalization and {{Recommendation}} in {{Information Access}}}
+}
+
 @article{pereiraFeatureBasedPersonalizedRecommender2016,
   title = {A {{Feature}}-{{Based Personalized Recommender System}} for {{Product}}-{{Line Configuration}}},
   author = {Pereira, Juliana Alves and Matuszyk, Pawel and Krieter, Sebastian and Spiliopoulou, Myra and Saake, Gunter},
@@ -904,6 +1355,72 @@
   series = {{{GPCE}} 2016}
 }
 
+@article{pereiraPersonalizedRecommenderSystems2018,
+  title = {Personalized Recommender Systems for Product-Line Configuration Processes},
+  author = {Pereira, Juliana Alves and Matuszyk, Pawel and Krieter, Sebastian and Spiliopoulou, Myra and Saake, Gunter},
+  date = {2018-12-01},
+  journaltitle = {Computer Languages, Systems \& Structures},
+  shortjournal = {Computer Languages, Systems \& Structures},
+  volume = {54},
+  pages = {451--471},
+  issn = {1477-8424},
+  doi = {10.1016/j.cl.2018.01.003},
+  abstract = {Product lines are designed to support the reuse of features across multiple products. Features are product functional requirements that are important to stakeholders. In this context, feature models are used to establish a reuse platform and allow the configuration of multiple products through the interactive selection of a valid combination of features. Although there are many specialized configurator tools that aim to provide configuration support, they only assure that all dependencies from selected features are automatically satisfied. However, no support is provided to help decision makers focus on likely relevant configuration options. Consequently, since decision makers are often unsure about their needs, the configuration of large feature models becomes challenging. To improve the efficiency and quality of the product configuration process, we propose a new approach that provides users with a limited set of permitted, necessary and relevant choices. To this end, we adapt six state-of-the-art recommender algorithms to the product line configuration context. We empirically demonstrate the usability of the implemented algorithms in different domain scenarios, based on two real-world datasets of configurations. The results of our evaluation show that recommender algorithms, such as CF-shrinkage, CF-significance weighting, and BRISMF, when applied in the context of product-line configuration can efficiently support decision makers in a most efficient selection of features.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\YM7DR8TY\\S147784241730043X.html},
+  keywords = {Feature model,Personalized recommendations,Product lines,Product-line configuration,Recommender systems},
+  langid = {english}
+}
+
+@article{pereiraPersonalizedRecommenderSystems2018a,
+  title = {Personalized Recommender Systems for Product-Line Configuration Processes},
+  author = {Pereira, Juliana Alves and Matuszyk, Pawel and Krieter, Sebastian and Spiliopoulou, Myra and Saake, Gunter},
+  date = {2018-12},
+  journaltitle = {Computer Languages, Systems \& Structures},
+  shortjournal = {Computer Languages, Systems \& Structures},
+  volume = {54},
+  pages = {451--471},
+  issn = {14778424},
+  doi = {10.1016/j.cl.2018.01.003},
+  abstract = {Product lines are designed to support the reuse of features across multiple products. Features are product functional requirements that are important to stakeholders. In this context, feature models are used to establish a reuse platform and allow the configuration of multiple products through the interactive selection of a valid combination of features. Although there are many specialized configurator tools that aim to provide configuration support, they only assure that all dependencies from selected features are automatically satisfied. However, no support is provided to help decision makers focus on likely relevant configuration options. Consequently, since decision makers are often unsure about their needs, the configuration of large feature models becomes challenging. To improve the efficiency and quality of the product configuration process, we propose a new approach that provides users with a limited set of permitted, necessary and relevant choices. To this end, we adapt six state-of-the-art recommender algorithms to the product line configuration context. We empirically demonstrate the usability of the implemented algorithms in different domain scenarios, based on two real-world datasets of configurations. The results of our evaluation show that recommender algorithms, such as CF-shrinkage, CF-significance weighting, and BRISMF, when applied in the context of product-line configuration can efficiently support decision makers in a most efficient selection of features.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\3LYWEVPZ\\Pereira et al. - 2018 - Personalized recommender systems for product-line .pdf},
+  langid = {english}
+}
+
+@inproceedings{piliponyte2013sequential,
+  title = {Sequential Music Recommendations for Groups by Balancing User Satisfaction.},
+  booktitle = {{{UMAP}} Workshops},
+  author = {Piliponyte, Auste and Ricci, Francesco and Koschwitz, Julian},
+  date = {2013},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\Y9EFUITE\\Piliponyte et al. - Sequential Music Recommendations for Groups by Bal.pdf}
+}
+
+@unpublished{pydataExamplePredictiveAnalytics16:42:00UTC,
+  title = {An {{Example}} of {{Predictive Analytics}}: {{Building}} a {{Recommendation Engine}} \ldots{}},
+  shorttitle = {An {{Example}} of {{Predictive Analytics}}},
+  author = {PyData},
+  year = {16:42:00 UTC},
+  url = {https://www.slideshare.net/PyData/an-example-of-predictive-analytics-building-a-recommendation-engine-using-pythonanusua-trivedi},
+  urldate = {2020-02-19},
+  abstract = {PyData Seattle 2015},
+  type = {Data \& Analytics}
+}
+
+@online{PytestDocumentation,
+  title = {Pytest Documentation},
+  url = {https://docs.pytest.org/en/latest/},
+  urldate = {2020-04-09},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\EHSWVWHW\\latest.html}
+}
+
+@online{PythonOrg,
+  title = {Python.Org},
+  url = {https://www.python.org/},
+  urldate = {2020-04-09},
+  abstract = {The official home of the Python Programming Language},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\ZKIC9FPT\\www.python.org.html},
+  langid = {english}
+}
+
 @article{qiuInfluenceGroupConfiguration2015,
   title = {Influence of Group Configuration on Online Discourse Reading},
   author = {Qiu, Mingzhu and McDougall, Douglas},
@@ -931,6 +1448,18 @@
   type = {Master's thesis}
 }
 
+@inproceedings{rennebergPipelinedFilterCombination2003,
+  title = {Pipelined {{Filter Combination}} in {{Product Personalization}}},
+  booktitle = {Proc. 10th {{Int}}'l. {{Conf}}. on {{Human}}-{{Computer Interaction}}},
+  author = {Renneberg, Volker and Borghoff, Uwe M},
+  date = {2003},
+  pages = {602--606},
+  location = {{Crete, Greece}},
+  eventtitle = {{{HCI}} 2003},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\DR8RWVGQ\\Renneberg and Borghoff - Pipelined Filter Combination in Product Personaliz.pdf},
+  langid = {english}
+}
+
 @collection{ricciRecommenderSystemsHandbook2015,
   title = {Recommender Systems Handbook},
   editor = {Ricci, Francesco and Rokach, Lior and Shapira, Bracha},
@@ -946,6 +1475,19 @@ OCLC: 935904837},
   pagetotal = {1003}
 }
 
+@article{richthammerSituationAwarenessRecommender2018,
+  title = {Situation Awareness for Recommender Systems},
+  author = {Richthammer, Christian and Pernul, G\"unther},
+  date = {2018-10-24},
+  journaltitle = {Electronic Commerce Research},
+  shortjournal = {Electron Commer Res},
+  issn = {1389-5753, 1572-9362},
+  doi = {10.1007/s10660-018-9321-z},
+  abstract = {One major shortcoming of traditional recommender systems is their inability to adjust to users' short-term preferences resulting from varying situation-specific factors. To address this, we propose the notion of situationaware recommender systems, which are supposed to autonomously determine the users' current situation based on a multitude of contextual side information and generate truly personalized recommendations. In particular, we develop a situation awareness model for recommender systems, include it in a situationaware recommendation process, and derive generic design steps for the design of situation-aware recommender systems. The feasibility of these concepts is demonstrated by directly employing them for the development and implementation of a music recommender system for everyday situations. Moreover, their meaningfulness is shown by means of an empirical user study. The outcomes of the evaluation indicate a significant increase in user satisfaction compared to traditional (i.e. non-situation-aware) recommendations.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\LNRJQH7H\\Richthammer and Pernul - 2018 - Situation awareness for recommender systems.pdf},
+  langid = {english}
+}
+
 @thesis{rubinshteynEntwicklungHybridenRecommender2018,
   title = {Entwicklung eines hybriden Recommender Systems f\"ur die Produktkonfiguration},
   author = {Rubinshteyn, Alexander},
@@ -958,6 +1500,17 @@ OCLC: 935904837},
   type = {Master's thesis}
 }
 
+@unpublished{s.dianahuRecSys2015Tutorial23:21:24UTC,
+  title = {{{RecSys}} 2015 {{Tutorial}}  \textendash{} {{Scalable Recommender Systems}}: {{Where Machine}} \ldots{}},
+  shorttitle = {{{RecSys}} 2015 {{Tutorial}}  \textendash{} {{Scalable Recommender Systems}}},
+  author = {S. Diana Hu},
+  year = {23:21:24 UTC},
+  url = {https://www.slideshare.net/SDianaHu/recsys-2015-tutorial-scalable-recommender-systems-where-machine-learning-meets-search},
+  urldate = {2020-02-19},
+  abstract = {Search engines have focused on solving the document retrieval problem, so},
+  type = {Technology}
+}
+
 @article{sabinProductConfigurationFrameworksa1998,
   title = {Product Configuration Frameworks-a Survey},
   author = {Sabin, D. and Weigel, R.},
@@ -983,6 +1536,37 @@ OCLC: 935904837},
   langid = {english}
 }
 
+@article{scholzConfigurationbasedRecommenderSystem2017,
+  title = {A Configuration-Based Recommender System for Supporting e-Commerce Decisions},
+  author = {Scholz, Michael and Dorner, Verena and Schryen, Guido and Benlian, Alexander},
+  date = {2017-05},
+  journaltitle = {European Journal of Operational Research},
+  shortjournal = {European Journal of Operational Research},
+  volume = {259},
+  pages = {205--215},
+  issn = {03772217},
+  doi = {10.1016/j.ejor.2016.09.057},
+  abstract = {Multi-attribute value theory (MAVT)-based recommender systems have been proposed for dealing with issues of existing recommender systems, such as the cold-start problem and changing preferences. However, as we argue in this paper, existing MAVT-based methods for measuring attribute importance weights do not fit the shopping tasks for which recommender systems are typically used. These methods assume well-trained decision makers who are willing to invest time and cognitive effort, and who are familiar with the attributes describing the available alternatives and the ranges of these attribute levels. Yet, recommender systems are most often used by consumers who are usually not familiar with the available attributes and ranges and who wish to save time and effort. Against this background, we develop a new method, based on a product configuration process, which is tailored to the characteristics of these particular decision makers. We empirically compare our method to SWING, ranking-based conjoint analysis and TRADEOFF in a between-subjects laboratory experiment with 153 participants. Results indicate that our proposed method performs better than TRADEOFF and CONJOINT and at least as well as SWING in terms of recommendation accuracy, better than SWING and TRADEOFF and at least as well as CONJOINT in terms of cognitive load, and that participants were faster with our method than with any other method. We conclude that our method is a promising option to help support consumers' decision processes in e-commerce shopping tasks.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\MUE33V9K\\Scholz et al. - 2017 - A configuration-based recommender system for suppo.pdf},
+  langid = {english},
+  number = {1}
+}
+
+@article{scholzEffectsDecisionSpace2017,
+  title = {Effects of Decision Space Information on {{MAUT}}-Based Systems That Support Purchase Decision Processes},
+  author = {Scholz, Michael and Franz, Markus and Hinz, Oliver},
+  date = {2017-05},
+  journaltitle = {Decision Support Systems},
+  shortjournal = {Decision Support Systems},
+  volume = {97},
+  pages = {43--57},
+  issn = {01679236},
+  doi = {10.1016/j.dss.2017.03.004},
+  abstract = {This paper shows that decision makers often have a misconception of the decision space. The decision space is constituted by the relations among the attributes describing the alternatives available in a decision situation. The paper demonstrates that these misconceptions negatively affect the usage and perceptions of MAUT-based decision support systems. To overcome these negative effects, this paper proposes to use a visualization method based on singular value decomposition to give decision makers insights into the attribute relations. In a laboratory experiment in cooperation with Germany's largest Internet real estate website, this paper moreover evaluates the proposed solution and shows that our solution improves decision makers' usage and perceptions of MAUT-based decision support systems. We further show that information about the decision space ultimately affects variables relevant for the economic success of decision support system providers such as reuse intention and the probability to act as a promoter for the systems.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\939QYBKB\\Scholz et al. - 2017 - Effects of decision space information on MAUT-base.pdf},
+  langid = {english}
+}
+
 @article{schulz-hardtProductiveConflictGroup2002,
   title = {Productive Conflict in Group Decision Making: Genuine and Contrived Dissent as Strategies to Counteract Biased Information Seekingq},
   author = {Schulz-Hardt, Stefan and Jochims, Marc and Frey, Dieter},
@@ -1006,6 +1590,25 @@ OCLC: 935904837},
   langid = {english}
 }
 
+@article{shishehchiOntologicalApproachKnowledge2012,
+  title = {Ontological {{Approach}} in {{Knowledge Based Recommender System}} to {{Develop}} the {{Quality}} of {{E}}-Learning {{System}}},
+  author = {Shishehchi, Saman and Banihashem, Seyed Yashar and Zin, Nor Azan Mat and Noah, Shahrul Azman Mohd},
+  date = {2012},
+  pages = {9},
+  abstract = {The rapid growth of Internet technology and the explosion of educational resources, show the increasing importance of e-learning systems. Despite the importance of these systems, they suffer from the enormous learning materials. In recent years, recommender systems appeared to improve the quality of learning. Such systems were used in learning systems to provide the facilities during the learning process and help learners with a more accurate learning. Different recommendation techniques such as collaborative filtering, content based and the hybrid filtering were employed for e-learning domain. In addition to the importance of learner's needs in the learning process, also the training method for recommended learning materials should be important in this learning process. This paper aims to develop the knowledge based personalized e-learning recommendation system based on ontology. Furthermore, this study discusses about appropriate recommendation technique based on learning system characteristics. The first significant property of this study is the common ontology for learner and learner materials. The second property is referring to the developed pedagogy pattern for this recommendation. The learning materials filter according to the prerequisites of the learner request and learner's knowledge. Learner can ask any activities such as example or description, by using graphical user interface.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\AAEZDYL7\\Shishehchi et al. - 2012 - Ontological Approach in Knowledge Based Recommende.pdf},
+  langid = {english}
+}
+
+@article{shokeenStudyFeaturesSocial2019,
+  title = {A Study on Features of Social Recommender Systems},
+  author = {Shokeen, Jyoti and Rana, Chhavi},
+  date = {2019},
+  journaltitle = {Artificial Intelligence Review},
+  doi = {10.1007/s10462-019-09684-w},
+  abstract = {Recommender system is an emerging field of research with the advent of World Wide Web and E-commerce. Recently, an increasing usage of social networking websites plausibly has a great impact on diverse facets of our lives in different ways. Initially, researchers used to consider recommender system and social networks as independent topics. With the passage of time, they realized the importance of merging the two to produce enhanced recommendations. The integration of recommender system with social networks produces a new system termed as social recommender system. In this study, we initially describe the concept of recommender system and social recommender system and then investigates different features of social networks that play a major role in generating effective recommendations. Each feature plays an essential role in giving good recommendations and resolving the issues of traditional recommender systems. Lastly, this paper also discusses future work in this area that can aid in enriching the quality of social recommender systems.}
+}
+
 @article{sniezekGroupsUncertaintyExamination1992,
   title = {Groups under Uncertainty: {{An}} Examination of Confidence in Group Decision Making},
   shorttitle = {Groups under Uncertainty},
@@ -1023,6 +1626,16 @@ OCLC: 935904837},
   number = {1}
 }
 
+@inproceedings{stegmannGeneratingPersonalizedRecommendations2003,
+  title = {Generating {{Personalized Recommendations}} in a {{Model}}-{{Based Product Configurator System}}},
+  author = {Stegmann, Rosmary and Koch, Michael and Lacher, Martin and Leckner, Thomas and Renneberg, Volker},
+  date = {2003},
+  pages = {6},
+  abstract = {Web-based product configurator tools become increasingly important as a means for customerdriven configuration of highly configurable products today and mass customization in the future. However, with more and more possibilities to select from, the configuration process becomes too complex and tedious for the customer. In this paper, we give an overview of our ideas and concepts for supporting customers by providing personalized recommendations in different stages of the configuration process. We briefly sketch our concept for an architecture of a model-based configurator system and discuss the filtering mechanisms we plan to employ for generating recommendations.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\2RXD9ZAQ\\Stegmann et al. - Generating Personalized Recommendations in a Model.pdf},
+  langid = {english}
+}
+
 @inproceedings{stettingerCounteractingAnchoringEffects2015,
   title = {Counteracting {{Anchoring Effects}} in {{Group Decision Making}}},
   booktitle = {User {{Modeling}}, {{Adaptation}} and {{Personalization}}},
@@ -1048,6 +1661,34 @@ OCLC: 935904837},
   file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\8TDXS8ES\\2015 - Studien- und Prüfungsordnung des Karlsruher Instit.pdf}
 }
 
+@article{suSurveyCollaborativeFiltering2009,
+  title = {A {{Survey}} of {{Collaborative Filtering Techniques}}},
+  author = {Su, Xiaoyuan and Khoshgoftaar, Taghi M.},
+  date = {2009},
+  journaltitle = {Advances in Artificial Intelligence},
+  shortjournal = {Advances in Artificial Intelligence},
+  volume = {2009},
+  pages = {1--19},
+  issn = {1687-7470, 1687-7489},
+  doi = {10.1155/2009/421425},
+  abstract = {As one of the most successful approaches to building recommender systems, collaborative filtering (
+              CF
+              ) uses the known preferences of a group of users to make recommendations or predictions of the unknown preferences for other users. In this paper, we first introduce CF tasks and their main challenges, such as data sparsity, scalability, synonymy, gray sheep, shilling attacks, privacy protection, etc., and their possible solutions. We then present three main categories of CF techniques: memory-based, model-based, and hybrid CF algorithms (that combine CF with other recommendation techniques), with examples for representative algorithms of each category, and analysis of their predictive performance and their ability to address the challenges. From basic techniques to the state-of-the-art, we attempt to present a comprehensive survey for CF techniques, which can be served as a roadmap for research and practice in this area.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\LD2VDXXZ\\Su and Khoshgoftaar - 2009 - A Survey of Collaborative Filtering Techniques.pdf},
+  langid = {english}
+}
+
+@online{TableComparisonRecommender,
+  title = {Table 1 : {{The}} Comparison of Recommender Approaches Based on The...},
+  shorttitle = {Table 1},
+  journaltitle = {ResearchGate},
+  url = {https://www.researchgate.net/figure/The-comparison-of-recommender-approaches-based-on-the-knowledge-impression_tbl1_51934748},
+  urldate = {2020-02-19},
+  abstract = {Download Table | The comparison of recommender approaches based on the knowledge impression from publication: Discovering The Impact Of Knowledge In Recommender Systems: A Comparative Study | Recommender systems engage user profiles and appropriate filtering techniques to assist users in finding more relevant information over the large volume of information. User profiles play an important role in the success of recommendation process since they model and... | Recommender Systems, Information Science and Information Retrieval | ResearchGate, the professional network for scientists.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\QHYYFJVN\\The-comparison-of-recommender-approaches-based-on-the-knowledge-impression_tbl1_51934748.html},
+  langid = {english}
+}
+
 @inproceedings{thumProductConfigurationWild2018,
   title = {Product {{Configuration}} in the {{Wild}}: {{Strategies}} for {{Conflicting Decisions}} in {{Web Configurators}}},
   booktitle = {{{ConfWS}}},
@@ -1073,6 +1714,13 @@ OCLC: 935904837},
   number = {1}
 }
 
+@online{TinyDB15Documentation,
+  title = {{{TinyDB}} 3.15.1 Documentation},
+  url = {https://tinydb.readthedocs.io/en/latest/},
+  urldate = {2020-04-09},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\LL8TVTE9\\latest.html}
+}
+
 @book{tsangFoundationsConstraintSatisfaction1993,
   title = {Foundations of Constraint Satisfaction},
   author = {Tsang, Edward},
@@ -1086,6 +1734,23 @@ OCLC: 935904837},
   series = {Computation in Cognitive Science}
 }
 
+@article{tsengApplyingCasebasedReasoning2005,
+  title = {Applying Case-Based Reasoning for Product Configuration in Mass Customization Environments},
+  author = {Tseng, Hwai-En and Chang, Chien-Chen and Chang, Shu-Hsuan},
+  date = {2005-11-01},
+  journaltitle = {Expert Systems with Applications},
+  shortjournal = {Expert Systems with Applications},
+  volume = {29},
+  pages = {913--925},
+  issn = {0957-4174},
+  doi = {10.1016/j.eswa.2005.06.026},
+  abstract = {Product variation and customization is a trend in current market-oriented manufacturing environment. Companies produce products in order to satisfy customer's needs. In the customization environment, the R\&D sector in an enterprise should be able to offer differentiation in product selection after they take the order. Such product differentiation should meet the requirement of cost and manufacturing procedure. In the light of this, how to generate an accurate bill of material (BOM) that meets the customer's needs and gets ready for the production is an important issue in the intensely competitive market. The purpose of this study is to reduce effectively the time and cost of design under the premise to manufacture an accurate new product. In this study, the Case-Based Reasoning (CBR) algorithm was used to construct the new BOM. Retrieving previous cases that resemble the current problem can save a lot of time in figuring out the problem and offer a correct direction for designers. When solving a new problem, CBR technique can quickly help generate a right BOM that fits the present situation.},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\TQ6VF8TF\\Tseng et al_2005_Applying case-based reasoning for product configuration in mass customization.pdf;C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\ZENJNEH5\\S0957417405001144.html},
+  keywords = {Bill of material,Case-based reasoning,Feature tree,Mass-customization,Product configuration},
+  langid = {english},
+  number = {4}
+}
+
 @thesis{ullmannEntwurfUndUmsetzung2017,
   title = {Entwurf Und {{Umsetzung}} Einer {{Recommendation Engine}} Zur {{Produktkonfiguration}} Mit Maschinellen {{Lernverfahren}} Bei Der {{CAS Software AG}}},
   author = {Ullmann, Nils Merlin},
@@ -1170,6 +1835,14 @@ OCLC: 935904837},
   type = {Master's thesis}
 }
 
+@online{WhatWSGI,
+  title = {What Is {{WSGI}}?},
+  journaltitle = {WSGI.org},
+  url = {https://wsgi.readthedocs.io/en/latest/what.html},
+  urldate = {2020-04-09},
+  file = {C\:\\Users\\Hannes.Kuchelmeister\\Zotero\\storage\\77YX2NJ9\\what.html}
+}
+
 @article{winterInterviewMitAlan2009,
   title = {Interview mit Alan R. Hevner zum Thema ,,Design Science``},
   author = {Winter, Robert},

30_Thesis/thesis.tex

@@ -17,7 +17,7 @@
 
 %% Available page modes: oneside, twoside
 %% Available modes: draft, final (see README)
-\documentclass[twoside, english, draft]{sdqthesis}
+\documentclass[twoside, english, final]{sdqthesis}
 
 %% ---------------------------------
 %% | Information about the thesis  |
@@ -54,7 +54,16 @@
 %% Please enter the start end end time of your thesis
 \usepackage{texdate}
 \initdate{2019}{12}{16}
-\editingtime{\printfdate{british}}{\advancebymonths{4}\printfdate{british}}
+
+\editingtime{
+    \printfdate{british}
+    \advancebydays{31}
+    \advancebymonths{3}
+}{ 
+        \regressbydays{1}
+        \advancebydays{27} % corona automatic extension (34 days) - 7 days earlier hand in
+        \printfdate{british}
+}
 
 \settitle
 
@@ -69,11 +78,53 @@
 % me-ta-mo-del
 }
 
+%% --------------------------------
+%% | Ref Hypothesis                 |
+%% --------------------------------
+\newcommand{\hypothesisautorefname}{Hypothesis}
+
+%% --------------------
+%% |  Float Barriers  |
+%% --------------------
+\usepackage{placeins}
+
+%% --------------------
+%% |  Table Packages  |
+%% --------------------
+\usepackage{tabularx}
+\newcolumntype{C}{>{\centering\arraybackslash}X}
+\usepackage{multirow}
+
+%% --------------------
+%% |  Maths Packages  |
+%% --------------------
+\usepackage{amsmath}
+\usepackage{amssymb}
+
+%% --------------------
+%% | Plotting Packages |
+%% --------------------
+\usepackage{pgfplots}
+
+%% ---------------------
+%% | Generating Frames |
+%% ---------------------
+\usepackage[framemethod=TikZ]{mdframed}
+\newcounter{hypo}
+\mdtheorem[
+    nobreak=true,
+    linecolor=gray!60,
+    linewidth=1pt,
+    frametitlebackgroundcolor=gray!20,
+    frametitlefont=\sffamily\bfseries\color{black},
+]{hypothesis}{Hypothesis}
+
 %% --------------------------------
 %% | PDF Comments                 |
 %% --------------------------------
 \usepackage[colorinlistoftodos, obeyDraft]{todonotes}
 
+
 %% --------------------------------
 %% | Gantt Charts                 |
 %% --------------------------------
@@ -154,11 +205,9 @@
 \input{sections/00_introduction.tex}
 \input{sections/10_foundations.tex}
 \input{sections/20_related_work.tex}
-\input{sections/30_problem_and_objectives.tex}
 \input{sections/40_concept.tex}
-\input{sections/50_implementation.tex}
+\input{sections/50_design_and_implementation.tex}
 \input{sections/60_evaluation.tex}
-\input{sections/70_future_work.tex}
 \input{sections/80_conclusion.tex}
 
 
@@ -169,11 +218,4 @@
 
 %% Add entry to the table of contents for the bibliography
 \printbibliography[heading=bibintoc]
-
-%% ----------------
-%% |   Appendix   |
-%% ----------------
-\appendix
-\input{sections/appendix.tex}
-
 \end{document}

Additional_Notes/bpmn/configuration_process_continious_recommendation.bpmn

@@ -7,7 +7,7 @@
       <bpmn:outgoing>Flow_0sd24xk</bpmn:outgoing>
       <bpmn:outgoing>SequenceFlow_1ygx377</bpmn:outgoing>
     </bpmn:exclusiveGateway>
-    <bpmn:task id="Activity_1konb1u" name="generate recommendation">
+    <bpmn:task id="Activity_1konb1u" name="generate recommenda-tion">
       <bpmn:incoming>Flow_0sd24xk</bpmn:incoming>
       <bpmn:property id="Property_03b25wa" name="__targetRef_placeholder" />
       <bpmn:dataInputAssociation id="DataInputAssociation_0oxxzci">

Additional_Notes/bpmn/generating_evaluation_input.bpmn

@@ -1,142 +1,217 @@
 <?xml version="1.0" encoding="UTF-8"?>
-<bpmn:definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:di="http://www.omg.org/spec/DD/20100524/DI" id="Definitions_17iqhxr" targetNamespace="http://bpmn.io/schema/bpmn" exporter="bpmn-js (https://demo.bpmn.io)" exporterVersion="6.3.0">
+<bpmn:definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:dc="http://www.omg.org/spec/DD/20100524/DC" xmlns:di="http://www.omg.org/spec/DD/20100524/DI" id="Definitions_17iqhxr" targetNamespace="http://bpmn.io/schema/bpmn" exporter="bpmn-js (https://demo.bpmn.io)" exporterVersion="6.5.0-kah.1">
   <bpmn:process id="Process_0lzf9jk" isExecutable="false">
-    <bpmn:sequenceFlow id="Flow_18mvlx8" sourceRef="Activity_1tcgmr4" targetRef="Event_17s8nnq" />
-    <bpmn:sequenceFlow id="Flow_0b8m6wa" sourceRef="Activity_0wp44i7" targetRef="Activity_1tcgmr4" />
-    <bpmn:sequenceFlow id="Flow_0y9052u" sourceRef="Activity_0xj4ejn" targetRef="Activity_0wp44i7" />
-    <bpmn:sequenceFlow id="Flow_0gdv3ul" sourceRef="Event_0d8jvwa" targetRef="Activity_0xj4ejn" />
-    <bpmn:endEvent id="Event_17s8nnq">
-      <bpmn:incoming>Flow_18mvlx8</bpmn:incoming>
-    </bpmn:endEvent>
-    <bpmn:startEvent id="Event_0d8jvwa">
-      <bpmn:outgoing>Flow_0gdv3ul</bpmn:outgoing>
-    </bpmn:startEvent>
-    <bpmn:task id="Activity_1tcgmr4" name="Save">
-      <bpmn:incoming>Flow_0b8m6wa</bpmn:incoming>
-      <bpmn:outgoing>Flow_18mvlx8</bpmn:outgoing>
-      <bpmn:property id="Property_1fza8iw" name="__targetRef_placeholder" />
-      <bpmn:dataInputAssociation id="DataInputAssociation_0syollx">
-        <bpmn:sourceRef>Flow_1jss46c</bpmn:sourceRef>
-        <bpmn:targetRef>Property_1fza8iw</bpmn:targetRef>
-      </bpmn:dataInputAssociation>
-    </bpmn:task>
-    <bpmn:dataObjectReference id="Flow_1jss46c" name="Configuration State and Preferences" dataObjectRef="Flow_1be451b" />
-    <bpmn:dataObject id="Flow_1be451b" />
-    <bpmn:dataStoreReference id="Flow_0vog5x8" name="Finished Configuration Database" />
-    <bpmn:task id="Activity_0wp44i7" name="Generate Preference, Configuration Pairs">
-      <bpmn:incoming>Flow_0y9052u</bpmn:incoming>
-      <bpmn:outgoing>Flow_0b8m6wa</bpmn:outgoing>
-      <bpmn:property id="Property_0bni9in" name="__targetRef_placeholder" />
-      <bpmn:dataInputAssociation id="DataInputAssociation_1as2fpu">
-        <bpmn:sourceRef>Flow_1gbqvo5</bpmn:sourceRef>
-        <bpmn:targetRef>Property_0bni9in</bpmn:targetRef>
-      </bpmn:dataInputAssociation>
-      <bpmn:dataInputAssociation id="DataInputAssociation_197tuqn">
-        <bpmn:sourceRef>Flow_0dc8ucf</bpmn:sourceRef>
-        <bpmn:targetRef>Property_0bni9in</bpmn:targetRef>
-      </bpmn:dataInputAssociation>
-      <bpmn:dataOutputAssociation id="DataOutputAssociation_14x0clz">
-        <bpmn:targetRef>Flow_1jss46c</bpmn:targetRef>
-      </bpmn:dataOutputAssociation>
-    </bpmn:task>
-    <bpmn:dataObjectReference id="Flow_1gbqvo5" name="Partial Configurations" dataObjectRef="Flow_1cu24j2" />
-    <bpmn:dataObject id="Flow_1cu24j2" />
-    <bpmn:dataObjectReference id="Flow_0dc8ucf" name="Group Types" dataObjectRef="Flow_0majyqj" />
+    <bpmn:dataObjectReference id="Flow_0dc8ucf" name="group member profiles" dataObjectRef="Flow_0majyqj" />
     <bpmn:dataObject id="Flow_0majyqj" />
-    <bpmn:task id="Activity_0xj4ejn" name="Generate Partial Configuration">
-      <bpmn:incoming>Flow_0gdv3ul</bpmn:incoming>
-      <bpmn:outgoing>Flow_0y9052u</bpmn:outgoing>
-      <bpmn:property id="Property_0g89kuk" name="__targetRef_placeholder" />
-      <bpmn:dataInputAssociation id="DataInputAssociation_1lr92f2">
-        <bpmn:sourceRef>Flow_0vog5x8</bpmn:sourceRef>
-        <bpmn:targetRef>Property_0g89kuk</bpmn:targetRef>
+    <bpmn:task id="Activity_0el490h" name="generate groups">
+      <bpmn:incoming>Flow_0wgvs43</bpmn:incoming>
+      <bpmn:outgoing>Flow_1hdpd6e</bpmn:outgoing>
+      <bpmn:property id="Property_0fzi3ej" name="__targetRef_placeholder" />
+      <bpmn:dataInputAssociation id="DataInputAssociation_0rzl9pn">
+        <bpmn:sourceRef>Flow_0dc8ucf</bpmn:sourceRef>
+        <bpmn:targetRef>Property_0fzi3ej</bpmn:targetRef>
       </bpmn:dataInputAssociation>
-      <bpmn:dataOutputAssociation id="DataOutputAssociation_14oxqhj">
-        <bpmn:targetRef>Flow_1gbqvo5</bpmn:targetRef>
+      <bpmn:dataOutputAssociation id="DataOutputAssociation_1h1k7f3">
+        <bpmn:targetRef>DataObjectReference_0dk8ord</bpmn:targetRef>
       </bpmn:dataOutputAssociation>
     </bpmn:task>
+    <bpmn:task id="Activity_12shstq" name="generate unfinished configurations">
+      <bpmn:incoming>Flow_18ah258</bpmn:incoming>
+      <bpmn:outgoing>Flow_08qskbu</bpmn:outgoing>
+      <bpmn:property id="Property_0llmkr1" name="__targetRef_placeholder" />
+      <bpmn:dataInputAssociation id="DataInputAssociation_1k14ujc">
+        <bpmn:sourceRef>DataStoreReference_0e449rj</bpmn:sourceRef>
+        <bpmn:targetRef>Property_0llmkr1</bpmn:targetRef>
+      </bpmn:dataInputAssociation>
+      <bpmn:dataOutputAssociation id="DataOutputAssociation_1wqdnca">
+        <bpmn:targetRef>DataObjectReference_0b8tret</bpmn:targetRef>
+      </bpmn:dataOutputAssociation>
+    </bpmn:task>
+    <bpmn:dataStoreReference id="DataStoreReference_0e449rj" name="finished configuration database" />
+    <bpmn:dataObjectReference id="DataObjectReference_0b8tret" name="unfinished configurations" dataObjectRef="DataObject_0j65hg4" />
+    <bpmn:dataObject id="DataObject_0j65hg4" />
+    <bpmn:dataObjectReference id="DataObjectReference_0dk8ord" name="preferences&#10;(for each group)" dataObjectRef="DataObject_1kmiddh" />
+    <bpmn:dataObject id="DataObject_1kmiddh" />
+    <bpmn:startEvent id="Event_0e7vhme">
+      <bpmn:outgoing>Flow_1m2t9yp</bpmn:outgoing>
+    </bpmn:startEvent>
+    <bpmn:parallelGateway id="Gateway_0dm9jmc">
+      <bpmn:incoming>Flow_1m2t9yp</bpmn:incoming>
+      <bpmn:outgoing>Flow_0wgvs43</bpmn:outgoing>
+      <bpmn:outgoing>Flow_18ah258</bpmn:outgoing>
+    </bpmn:parallelGateway>
+    <bpmn:sequenceFlow id="Flow_1m2t9yp" sourceRef="Event_0e7vhme" targetRef="Gateway_0dm9jmc" />
+    <bpmn:task id="Activity_033bobt" name="pair up preferences and unfinished configurations">
+      <bpmn:incoming>Flow_1mts5v8</bpmn:incoming>
+      <bpmn:outgoing>Flow_0vx10vl</bpmn:outgoing>
+      <bpmn:property id="Property_0e1efvb" name="__targetRef_placeholder" />
+      <bpmn:dataInputAssociation id="DataInputAssociation_097tm6g">
+        <bpmn:sourceRef>DataObjectReference_0b8tret</bpmn:sourceRef>
+        <bpmn:targetRef>Property_0e1efvb</bpmn:targetRef>
+      </bpmn:dataInputAssociation>
+      <bpmn:dataInputAssociation id="DataInputAssociation_16303zg">
+        <bpmn:sourceRef>DataObjectReference_0dk8ord</bpmn:sourceRef>
+        <bpmn:targetRef>Property_0e1efvb</bpmn:targetRef>
+      </bpmn:dataInputAssociation>
+      <bpmn:dataOutputAssociation id="DataOutputAssociation_0frorp4">
+        <bpmn:targetRef>DataObjectReference_125w85o</bpmn:targetRef>
+      </bpmn:dataOutputAssociation>
+    </bpmn:task>
+    <bpmn:dataObjectReference id="DataObjectReference_125w85o" name="pairs of preferences and unfinished configurations" dataObjectRef="DataObject_0pycepc" />
+    <bpmn:dataObject id="DataObject_0pycepc" />
+    <bpmn:sequenceFlow id="Flow_0wgvs43" sourceRef="Gateway_0dm9jmc" targetRef="Activity_0el490h" />
+    <bpmn:sequenceFlow id="Flow_18ah258" sourceRef="Gateway_0dm9jmc" targetRef="Activity_12shstq" />
+    <bpmn:endEvent id="Event_02lc079">
+      <bpmn:incoming>Flow_0vx10vl</bpmn:incoming>
+      <bpmn:property id="Property_18jxcbg" name="__targetRef_placeholder" />
+      <bpmn:dataInputAssociation id="DataInputAssociation_1txvcxy">
+        <bpmn:sourceRef>DataObjectReference_125w85o</bpmn:sourceRef>
+        <bpmn:targetRef>Property_18jxcbg</bpmn:targetRef>
+      </bpmn:dataInputAssociation>
+    </bpmn:endEvent>
+    <bpmn:sequenceFlow id="Flow_0vx10vl" sourceRef="Activity_033bobt" targetRef="Event_02lc079" />
+    <bpmn:parallelGateway id="Gateway_0vlb15w">
+      <bpmn:incoming>Flow_1hdpd6e</bpmn:incoming>
+      <bpmn:incoming>Flow_08qskbu</bpmn:incoming>
+      <bpmn:outgoing>Flow_1mts5v8</bpmn:outgoing>
+    </bpmn:parallelGateway>
+    <bpmn:sequenceFlow id="Flow_1hdpd6e" sourceRef="Activity_0el490h" targetRef="Gateway_0vlb15w" />
+    <bpmn:sequenceFlow id="Flow_08qskbu" sourceRef="Activity_12shstq" targetRef="Gateway_0vlb15w" />
+    <bpmn:sequenceFlow id="Flow_1mts5v8" sourceRef="Gateway_0vlb15w" targetRef="Activity_033bobt" />
   </bpmn:process>
   <bpmndi:BPMNDiagram id="BPMNDiagram_1">
     <bpmndi:BPMNPlane id="BPMNPlane_1" bpmnElement="Process_0lzf9jk">
-      <bpmndi:BPMNShape id="Activity_0xj4ejn_di" bpmnElement="Activity_0xj4ejn">
-        <dc:Bounds x="230" y="220" width="100" height="80" />
+      <bpmndi:BPMNEdge id="Flow_1m2t9yp_di" bpmnElement="Flow_1m2t9yp">
+        <di:waypoint x="188" y="250" />
+        <di:waypoint x="225" y="250" />
+      </bpmndi:BPMNEdge>
+      <bpmndi:BPMNEdge id="Flow_0wgvs43_di" bpmnElement="Flow_0wgvs43">
+        <di:waypoint x="250" y="225" />
+        <di:waypoint x="250" y="200" />
+        <di:waypoint x="290" y="200" />
+      </bpmndi:BPMNEdge>
+      <bpmndi:BPMNEdge id="Flow_18ah258_di" bpmnElement="Flow_18ah258">
+        <di:waypoint x="250" y="275" />
+        <di:waypoint x="250" y="300" />
+        <di:waypoint x="290" y="300" />
+      </bpmndi:BPMNEdge>
+      <bpmndi:BPMNEdge id="Flow_0vx10vl_di" bpmnElement="Flow_0vx10vl">
+        <di:waypoint x="590" y="250" />
+        <di:waypoint x="621" y="250" />
+        <di:waypoint x="621" y="170" />
+        <di:waypoint x="652" y="170" />
+      </bpmndi:BPMNEdge>
+      <bpmndi:BPMNEdge id="Flow_1hdpd6e_di" bpmnElement="Flow_1hdpd6e">
+        <di:waypoint x="390" y="200" />
+        <di:waypoint x="430" y="200" />
+        <di:waypoint x="430" y="225" />
+      </bpmndi:BPMNEdge>
+      <bpmndi:BPMNEdge id="Flow_08qskbu_di" bpmnElement="Flow_08qskbu">
+        <di:waypoint x="390" y="300" />
+        <di:waypoint x="430" y="300" />
+        <di:waypoint x="430" y="275" />
+      </bpmndi:BPMNEdge>
+      <bpmndi:BPMNEdge id="Flow_1mts5v8_di" bpmnElement="Flow_1mts5v8">
+        <di:waypoint x="455" y="250" />
+        <di:waypoint x="490" y="250" />
+      </bpmndi:BPMNEdge>
+      <bpmndi:BPMNShape id="Activity_0el490h_di" bpmnElement="Activity_0el490h">
+        <dc:Bounds x="290" y="160" width="100" height="80" />
+        <bpmndi:BPMNLabel>
+          <dc:Bounds x="299" y="233" width="81" height="14" />
+        </bpmndi:BPMNLabel>
+      </bpmndi:BPMNShape>
+      <bpmndi:BPMNShape id="Activity_12shstq_di" bpmnElement="Activity_12shstq">
+        <dc:Bounds x="290" y="260" width="100" height="80" />
+        <bpmndi:BPMNLabel>
+          <dc:Bounds x="305" y="330" width="70" height="40" />
+        </bpmndi:BPMNLabel>
+      </bpmndi:BPMNShape>
+      <bpmndi:BPMNShape id="Gateway_11n50k1_di" bpmnElement="Gateway_0dm9jmc">
+        <dc:Bounds x="225" y="225" width="50" height="50" />
+      </bpmndi:BPMNShape>
+      <bpmndi:BPMNShape id="Event_0e7vhme_di" bpmnElement="Event_0e7vhme">
+        <dc:Bounds x="152" y="232" width="36" height="36" />
+      </bpmndi:BPMNShape>
+      <bpmndi:BPMNShape id="Gateway_0vlb15w_di" bpmnElement="Gateway_0vlb15w">
+        <dc:Bounds x="405" y="225" width="50" height="50" />
+      </bpmndi:BPMNShape>
+      <bpmndi:BPMNShape id="Activity_033bobt_di" bpmnElement="Activity_033bobt">
+        <dc:Bounds x="490" y="210" width="100" height="80" />
+        <bpmndi:BPMNLabel>
+          <dc:Bounds x="499" y="203" width="82" height="53" />
+        </bpmndi:BPMNLabel>
+      </bpmndi:BPMNShape>
+      <bpmndi:BPMNShape id="DataObjectReference_0dk8ord_di" bpmnElement="DataObjectReference_0dk8ord">
+        <dc:Bounds x="432" y="115" width="36" height="50" />
+        <bpmndi:BPMNLabel>
+          <dc:Bounds x="410" y="78" width="81" height="27" />
+        </bpmndi:BPMNLabel>
       </bpmndi:BPMNShape>
       <bpmndi:BPMNShape id="Flow_0dc8ucf_di" bpmnElement="Flow_0dc8ucf">
-        <dc:Bounds x="412" y="95" width="36" height="50" />
+        <dc:Bounds x="202" y="115" width="36" height="50" />
         <bpmndi:BPMNLabel>
-          <dc:Bounds x="399" y="152" width="63" height="14" />
+          <dc:Bounds x="185" y="77.5" width="70" height="27" />
         </bpmndi:BPMNLabel>
       </bpmndi:BPMNShape>
-      <bpmndi:BPMNShape id="Flow_1gbqvo5_di" bpmnElement="Flow_1gbqvo5">
-        <dc:Bounds x="412" y="230" width="36" height="50" />
+      <bpmndi:BPMNShape id="Event_02lc079_di" bpmnElement="Event_02lc079">
+        <dc:Bounds x="652" y="152" width="36" height="36" />
+      </bpmndi:BPMNShape>
+      <bpmndi:BPMNShape id="DataObjectReference_125w85o_di" bpmnElement="DataObjectReference_125w85o">
+        <dc:Bounds x="652" y="255" width="36" height="50" />
         <bpmndi:BPMNLabel>
-          <dc:Bounds x="396" y="287" width="71" height="27" />
+          <dc:Bounds x="631" y="312" width="82" height="53" />
         </bpmndi:BPMNLabel>
       </bpmndi:BPMNShape>
-      <bpmndi:BPMNShape id="Activity_0wp44i7_di" bpmnElement="Activity_0wp44i7">
-        <dc:Bounds x="540" y="150" width="100" height="80" />
-      </bpmndi:BPMNShape>
-      <bpmndi:BPMNShape id="Flow_0vog5x8_di" bpmnElement="Flow_0vog5x8">
-        <dc:Bounds x="255" y="345" width="50" height="50" />
+      <bpmndi:BPMNShape id="DataStoreReference_0e449rj_di" bpmnElement="DataStoreReference_0e449rj">
+        <dc:Bounds x="195" y="335" width="50" height="50" />
         <bpmndi:BPMNLabel>
-          <dc:Bounds x="248" y="402" width="65" height="40" />
+          <dc:Bounds x="190" y="392" width="64" height="40" />
         </bpmndi:BPMNLabel>
       </bpmndi:BPMNShape>
-      <bpmndi:BPMNEdge id="DataInputAssociation_1lr92f2_di" bpmnElement="DataInputAssociation_1lr92f2">
-        <di:waypoint x="280" y="345" />
-        <di:waypoint x="280" y="300" />
-      </bpmndi:BPMNEdge>
-      <bpmndi:BPMNEdge id="DataOutputAssociation_14oxqhj_di" bpmnElement="DataOutputAssociation_14oxqhj">
-        <di:waypoint x="330" y="260" />
-        <di:waypoint x="412" y="260" />
-      </bpmndi:BPMNEdge>
-      <bpmndi:BPMNEdge id="DataInputAssociation_1as2fpu_di" bpmnElement="DataInputAssociation_1as2fpu">
-        <di:waypoint x="448" y="246" />
-        <di:waypoint x="540" y="200" />
-      </bpmndi:BPMNEdge>
-      <bpmndi:BPMNEdge id="DataInputAssociation_197tuqn_di" bpmnElement="DataInputAssociation_197tuqn">
-        <di:waypoint x="448" y="128" />
-        <di:waypoint x="540" y="168" />
-      </bpmndi:BPMNEdge>
-      <bpmndi:BPMNShape id="Flow_1jss46c_di" bpmnElement="Flow_1jss46c">
-        <dc:Bounds x="582" y="275" width="36" height="50" />
+      <bpmndi:BPMNShape id="DataObjectReference_0b8tret_di" bpmnElement="DataObjectReference_0b8tret">
+        <dc:Bounds x="432" y="335" width="36" height="50" />
         <bpmndi:BPMNLabel>
-          <dc:Bounds x="568" y="332" width="65" height="40" />
+          <dc:Bounds x="418" y="392" width="70" height="27" />
         </bpmndi:BPMNLabel>
       </bpmndi:BPMNShape>
-      <bpmndi:BPMNShape id="Activity_1tcgmr4_di" bpmnElement="Activity_1tcgmr4">
-        <dc:Bounds x="700" y="150" width="100" height="80" />
-      </bpmndi:BPMNShape>
-      <bpmndi:BPMNEdge id="Flow_0b8m6wa_di" bpmnElement="Flow_0b8m6wa">
-        <di:waypoint x="640" y="190" />
-        <di:waypoint x="700" y="190" />
+      <bpmndi:BPMNEdge id="DataInputAssociation_0rzl9pn_di" bpmnElement="DataInputAssociation_0rzl9pn">
+        <di:waypoint x="238" y="140" />
+        <di:waypoint x="310" y="140" />
+        <di:waypoint x="310" y="160" />
       </bpmndi:BPMNEdge>
-      <bpmndi:BPMNEdge id="DataOutputAssociation_14x0clz_di" bpmnElement="DataOutputAssociation_14x0clz">
-        <di:waypoint x="593" y="230" />
-        <di:waypoint x="596" y="275" />
+      <bpmndi:BPMNEdge id="DataOutputAssociation_1h1k7f3_di" bpmnElement="DataOutputAssociation_1h1k7f3">
+        <di:waypoint x="370" y="160" />
+        <di:waypoint x="370" y="140" />
+        <di:waypoint x="432" y="140" />
       </bpmndi:BPMNEdge>
-      <bpmndi:BPMNEdge id="DataInputAssociation_0syollx_di" bpmnElement="DataInputAssociation_0syollx">
-        <di:waypoint x="618" y="289" />
-        <di:waypoint x="717" y="230" />
+      <bpmndi:BPMNEdge id="DataInputAssociation_1k14ujc_di" bpmnElement="DataInputAssociation_1k14ujc">
+        <di:waypoint x="245" y="360" />
+        <di:waypoint x="310" y="360" />
+        <di:waypoint x="310" y="340" />
       </bpmndi:BPMNEdge>
-      <bpmndi:BPMNEdge id="Flow_0y9052u_di" bpmnElement="Flow_0y9052u">
-        <di:waypoint x="280" y="220" />
-        <di:waypoint x="280" y="190" />
-        <di:waypoint x="540" y="190" />
+      <bpmndi:BPMNEdge id="DataOutputAssociation_1wqdnca_di" bpmnElement="DataOutputAssociation_1wqdnca">
+        <di:waypoint x="370" y="340" />
+        <di:waypoint x="370" y="360" />
+        <di:waypoint x="430" y="360" />
       </bpmndi:BPMNEdge>
-      <bpmndi:BPMNShape id="Event_0d8jvwa_di" bpmnElement="Event_0d8jvwa">
-        <dc:Bounds x="152" y="242" width="36" height="36" />
-      </bpmndi:BPMNShape>
-      <bpmndi:BPMNEdge id="Flow_0gdv3ul_di" bpmnElement="Flow_0gdv3ul">
-        <di:waypoint x="188" y="260" />
-        <di:waypoint x="230" y="260" />
+      <bpmndi:BPMNEdge id="DataInputAssociation_097tm6g_di" bpmnElement="DataInputAssociation_097tm6g">
+        <di:waypoint x="468" y="360" />
+        <di:waypoint x="540" y="360" />
+        <di:waypoint x="540" y="290" />
       </bpmndi:BPMNEdge>
-      <bpmndi:BPMNShape id="Event_17s8nnq_di" bpmnElement="Event_17s8nnq">
-        <dc:Bounds x="732" y="82" width="36" height="36" />
-      </bpmndi:BPMNShape>
-      <bpmndi:BPMNEdge id="Flow_18mvlx8_di" bpmnElement="Flow_18mvlx8">
-        <di:waypoint x="750" y="150" />
-        <di:waypoint x="750" y="118" />
+      <bpmndi:BPMNEdge id="DataInputAssociation_16303zg_di" bpmnElement="DataInputAssociation_16303zg">
+        <di:waypoint x="468" y="140" />
+        <di:waypoint x="540" y="140" />
+        <di:waypoint x="540" y="210" />
+      </bpmndi:BPMNEdge>
+      <bpmndi:BPMNEdge id="DataOutputAssociation_0frorp4_di" bpmnElement="DataOutputAssociation_0frorp4">
+        <di:waypoint x="590" y="280" />
+        <di:waypoint x="652" y="280" />
+      </bpmndi:BPMNEdge>
+      <bpmndi:BPMNEdge id="DataInputAssociation_1txvcxy_di" bpmnElement="DataInputAssociation_1txvcxy">
+        <di:waypoint x="670" y="255" />
+        <di:waypoint x="670" y="188" />
       </bpmndi:BPMNEdge>
     </bpmndi:BPMNPlane>
   </bpmndi:BPMNDiagram>

Additional_Notes/draw.io/MerlinCollabRecommender.drawio

@@ -1 +1 @@
-<mxfile host="www.draw.io" modified="2019-12-09T13:28:32.269Z" agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0" etag="9F-sz8phpVL5PfRKMlH8" version="12.3.8" type="device" pages="1"><diagram id="cNiUGcpUxYu83N4z4ARh" name="Page-1">7VlNc6M4EP01PjoFCLBznNiZzGFSNTXe7GxOUwoohl2MKCFiO79+JSMBQjJgxx+7NXNxoUYf6PXr1y15BGarzQOBWfSIQ5SMHCvcjMB85DgesNkvN2xLw8QBpWFJ4rA02bVhEb8jYbSEtYhDlCsdKcYJjTPVGOA0RQFVbJAQvFa7veJEXTWDS6QZFgFMdOuPOKSRsPqWVb/4guJlJJd25JsVlL2FIY9giNcNE7gfgRnBmJZPq80MJRw8CUw57vOet9WXEZTSIQOe3oM/vzxtyMP74932ZxJ58/nb2JmU07zBpBBb/l4kDHEGXxqy3znKUBqiNIi5cbcPupXooJCBJZqY0AgvcQqT+9p6R3DBRvMvsFir7vMV44wZbWb8G1G6FZ6HBcXMFNFVIt7quxQbz3FBAtSxNVfQBZIlol0QCP/wzTRWECA+ILxClGxZB8HpsXVj2bZTDiIogTR+U9kCBemW1dhqum84Zvuou+DX15x9XcNv7KGxam3aefMAz7qaYx9vRHi2vDgE7TdEKNoMgce7FXiKiAcT0V434mcqbFEjdOQ4E3oKOIci4WlIaBCw2Mz4Y4BXGU53my95KYN+Kg1VsLtGuDpdMRhDW0PMMQAmbcdyUPJZaoCUaHWCkzB0/dUjTzZ2EXr+5IyLuRsWaAx06blf/HENkUGbmP7Fh994ovUsJuPP802zsZWNlO2+MYg3n+V8vFEP27XkuJwJEv3EUxPnWwLzPA6k+XOcqJHY0qReITTiLPNmnxDaUzMpB/PrQ1Fart4SrBlOEvhyZsUCQFUsz/GvrFj27bUlq/LGr6tZ5mLB/+/ok32UPlk9+jRIZzoLqf6KyzOq2weUZzeUiSrcNjpknDP5fhJNHDXufdtvUqa/P7C6+4NpV3/2UH7xaQlqGWWUoDOLaLvsu76IVnu4mohWvvgtosb4bx86+WrWHFL4AnOdr9JXIeuQU85ocLeOYooWGdzp0prAbODhcbhHJpanBrGr+8j3dB9NzkZrvTYwl81pKKvMlwQH/7RLT2lk/RplZ7sMbSYhmVBsJZ3U2WVPQqmSV7O0rhKZOXldIAnJCqc3Ca2Ve5+TRJ7rtcQS+OoU5TbFqI4U49s9E5UwdEx0/mgH5ozEC/vxrGCRvELkzMmpXeFf/04CXD05gd/JyYyLo3nmB3pZMLEU611GZA+s2o85IRwvsuD/ILLVHb3UxmlriqEi6zk9E11WZI13PJ5OzcsdS+0DMntN8MOqCCWsUiaHrTiqCX2uOzNjP9dM55NfmXV95FE3ZprsG3AanE/9yQUPe0YodNE+bTrtgWu/e36dbLo/PtTDCmIOWPH/FMlZTnsfIrYns39FbEdz061r4PX0YF6zZv3fbwl3/Q86uP8X</diagram></mxfile>
+<mxfile host="app.diagrams.net" modified="2020-05-08T13:50:05.748Z" agent="5.0 (Windows)" etag="cPBmNkvyLjlXIU8tCLHN" version="13.0.1" type="device"><diagram id="cNiUGcpUxYu83N4z4ARh" name="Page-1">7Vpdc5s6EP01fnQGENjOY2K76cxN5t5pmqR56sgg29xg5BHyV359JZAAIYyxg3E7qftQtEgCnd2zZyXSAcPF9o7A5fwBeyjoWIa37YBRx7JM0HfYf9yyExbTtBPLjPiesGWGR/8dCaMhrCvfQ5HSkWIcUH+pGl0chsilig0SgjdqtykO1Kcu4QxphkcXBrr1xffoXFh7hpHd+Ir82Vw+2pJ3JtB9mxG8CsUDOxaYxr/k9gLKyUT/aA49vMmZwLgDhgRjmlwttkMUcHQlbsm4L3vupi9OUEjrDHh6d5+/Pm3J3fvD7e5nMHdGo3XX6ifTrGGwEoh8WwXMIQxdtjDLGKElCj0Uuj43xuugOwke8hiWookJneMZDmEwzqy3MT6Iv4HBWlmfe4yXzGgy4/+I0p0IDLiimJn0pYnVRnhFXFSxHhF8FJIZolXrFk7hK8g9QSB3h/ACUbJjHUSkd40rwzStZBBBAaT+Wo0gKAJxlo5Np/sP+2wdWRc8nUbs7XLOYhe5p2am2IVHuNPWvPlwJUhbcN1eiNeIULStg4lzLUAU3Ad90d7kiDQQtnmOQ3JcGWQKIscu39GWr62bsXDJL128WOIwXnwSgZL9A2lIWW+XRmQl/rUxNDXErBLApO3UwJNBLNkuHNZXJ2gkLDf3DnkysY3Q643VXY1sb4W6QE8y48fvraUTtPXpDz7myhGtVzEDvx5t842dbIRsyblBvPkqHhE3smFxS46LWOqhN1yYeJAFMIp8V5q/+By2eIpaGa4USymShzKcOaiZ4WoH1YeoKV9HSU1DHARwosXBjEDPZ8Cw25gwU8iIyjGUAspxnnFoxfWU4Sr7ZirM7Dibg9mN+MfsIb6HE3TQFfVZDICaCR2rd+FMaF5fOhWmDv+8uXD94+f9vxtj8rSx/pnfQuf5dvEs+VvlGDXL7Q175jeeW0TaIfgNFQhT4MU4/scnKedX846V2NasC6xzsUHSsQWtmdOFTCzlsmOeJDvGAdmppSeVlfDhktlpWlDioUwr4S7XYcl5Gu0nbh8MFOL2zF4+Pg73B0YhnpI3aLQOl6AW1I4gLQ4bUJ9iHX559bFqJLnzqk/qgM+rPpUkLu73+dNY1IDtDcN4BCmcwEgPVukzj3WIKA/nRsqnvuGoFLV1Z/Qc3Rn9s8WvXj2Vb1hCT5b6kwC7b8X6XxpZv1ztX9wL5CVDpn9TSf6ZFuxJ/6nU5Pc3qeyUS00LklF7D7JRjt4aoZjtFLIi6KlTJMsUoyoEpGcemCiBoWKi89MalOsN3111hytG1QUiWvSefRt0+QMhcHEhAn+FqHQbVOOoTi3Ac1nyd9sRHeHj32VHBCwN/xc0eWRyJdzdvMydurU5ZRt1uraBP0Hb0q9TUpIGhSnqaptjHZioXW0rPfB09Hhsb+9uduoXVFmAH1e8KVySZ5058tQO6LrnxaX97Jrh3PhxcdVbK/XMN8Ty+wLxz5KFgFDyfl4c1DioODNOlUCVjfypceE0Ofkpp8mVjjq9jOr1W9zPl3pDF4vzVVGV4fB5i6gqzua3qZIjvN4/bUNfmxm9+FfBjAa44MhCJeWCpXn22i6hwuDjVCg/vt+/09LQ/ch3LFmwHvyEdaak0+ohYjnSbe7dqn39edNOOS769/xjThv2hPoZgrjVA4hyqPQU3XYQg2NR/NODmDWzv6pLumd/vAjGvwA=</diagram></mxfile>

Additional_Notes/draw.io/MerlinCollabRecommender_nocomponent.drawio

@@ -0,0 +1 @@
+<mxfile host="app.diagrams.net" modified="2020-05-08T13:47:57.568Z" agent="5.0 (Windows)" etag="2vl78F43UzOqFOuVpeiD" version="13.0.1" type="device"><diagram id="cNiUGcpUxYu83N4z4ARh" name="Page-1">1Vldc5s4FP01fnSGD4Odx8R205lNZneaTdo8dWSQgQ0gj5C/8utXAgkkhIG4NtO6D0UXSaBzzz06KCN7nhweMNiET8iH8cgy/MPIXowsy7SnDv2PRY48YpqTIhLgyOexKvAcfUAeNHh0G/kwUzoShGISbdSgh9IUekSJAYzRXu22RrH61A0IoBZ49kCsR79HPgl51DWM6sZXGAWheLQl7qyA9x5gtE35A0eWvc5/xe0EiMl4/ywEPtpLIXs5sucYIVJcJYc5jBm6Ardi3JcTd8sXxzAlfQa8fHivX18O+OHj6f74Mw6dxWI3tqbFNDsQbzki37YxTQhFly7MMhZwA1Mfpl7Egvk6yFGAB32KJW8iTEIUoBTEyyp6n+MD2RsYtFX1eURoQ4MmDf4HCTlyYoAtQTSkL42vNkNb7MGW9XDyEYADSNrWzZPCViA9gSP3AFECCT7SDpzpY+PGME2rGIRhDEi0UxkEOBGDcmw53T8oouuouqD1OqNvJyWLXkhPrUJ5Cj+RzomWzacbXrS11J2EeAcxgYc+mDi3HERe+/aUt/dSIc14LJRqSIxrgkxBpGX5+0cHv5hoAuHbnTXeLib+Fo5tnczL538Hoy08ROQHG3Pj8NYbn4FdLw5y4ygaKV24NIg13/gj8kY1LG+JcRmlOLljAkgDXgyyLPJE+EvEYMun6FVJjVgKMe6qJHPWs5J6V01fCrS+jlICcxTHYKXxIMDAjygw9DbCNJSilCW/FGqGc8Cg5ddriqvoW6k9jaNqDho38h+Np+gRrGBnKvpXnG2rFedY7nAVt/vx8/HvvbF62Vt/hffAeb1PXgVLJLQ1lNVaOgmuhxLGYE5ujN5hLS019Jf5PzZJcxZ1uNv50p0EDnpflbMugHnz3uUOpmghSQR9m8XNPEvcjA5xO3//F6B3GwDn0rKVD6WKDI5Shw3b+rMGL8CpNrVnSkW7pquauK7+tlHjU/EGF3UVAtSapmI4hKsYVONaqVL3yMzC0XezD3eUsgtAwApkOiRU8Dbs0qcdMsJAu8hWMDUclQgTU4PJdXSUpldD6ban+Up9YVtWMfLe615GBGk/ycfUfY0sTEJkTEViKsU5ITKloMlerRS3ZkEbQJh6+6m98rk6+qUvE06qiVOrPdtVpyiWyUe1yJRrdkxUwNAy0fW/lexmVWNOcTzf0lJNINbYe3VLN+hHVKOl09VOQ0E1E1It/m7urszxn+PubEvD/ztcPVNR5GVweTE916adYwnPV1D7T1DQ8txQCN+sNkVfBXWsjomGVdDGIwJH5+Nw3yHmJ7btiuCfswhKLYnTAal4ehO67wlLY79JTzpf/ICl7a2VXfMbpPqeQHZgXCOEovvy5qDyoOWUpdwJ1G1DPmepnb8UP+X8pTVR52/W7nTAb5M2bsimW+SCuZfzPk96Z8DNfy0ZuADmjtgQS8wtDfPbSQPksyv5I/O0b9TQ/ZUTRmGMOg8Xr0Tu3+BwUT/P/4xDPwHoFaC6pmmnzepvhMXOXf0p1l7+Dw==</diagram></mxfile>

Additional_Notes/draw.io/MerlinCollaborativeConfigurator_nocomponent.drawio

@@ -0,0 +1 @@
+<mxfile host="app.diagrams.net" modified="2020-05-08T13:48:35.329Z" agent="5.0 (Windows)" etag="Yw8VlwCnFVLogHi5wWgH" version="13.0.1" type="device"><diagram id="cNiUGcpUxYu83N4z4ARh" name="Page-1">1VhNc9owEP01HMPYFjbkWD5CDs1MpzRNc8oIe4PdCssjy2D49ZXxCsuYBCcZSHsB79PuyvuktxJ0yGiZTwVNwjseAOs4VpB3yLjjODbpu+qrQDaI2HavRBYiChCrgFm0BQQtRLMogLTmKDlnMkrqoM/jGHxZw6gQfF13e+asPmtCF9AAZj5lTfQhCmSIqGdZ1cAtRItQT+3okSXV3gikIQ342oDIpENGgnNZPi3zEbCCPk1MGXfzwuj+zQTEsk3A/db/eXufi+n2brh5YqE7Hq+unH6ZZkVZhiV/z5hiXNEXB+pzDAnEAcR+VIC7OuRGswOBIgtNLmTIFzymbFKhQ8EzFV28gaWsyucr54kCbQX+Bik3uPI0k1xBoVwyHG1WiYWnPBM+vFIabjRJxQLkaxTg+hTFGDMgiVPgS5BioxxwV19ZXcu2nTJIAKMyWtV3C8VNt9jH7tN945Gqo3Lhz8+pejtj3dSDMWsF7VbzDSvbayzsXRcFerCKbdhegZCQt6HHvUY+UfKkj/ba0M8AsdCQjo47xl6NnLcyYQ+OUDHijNH5mbkgpM6F63ifzIV+gcuKGPJI/irCuy5aj8bIOMfMO2OjjVjVawQV5qM5VoXtLB33/oahG8HpjuG27Bitu8PH1tQ6ur8FXFjp/8Dudo+fZkWHtcZU0jlNm6yogzkpHgPlkMqCNzJch5GEWUJ3G2atLjctT6X27Hm9ftet8ee5vQZ/ntukr382+q6b9E1mP5odIw6+FHcrZc0Z9/8oQlIlGnkIKr+biGnOdi6GbfYHrXW7pvRK+C9ofd9XjK5S9ZjjfeUC/UEfOCf7w7p2pfzYjQK3Vc89ECXx6inKMjHKvC4eJPLsE4lKGl5JdP47Djne+YqT/WqUKS0vQVz4iP/86w5xGqQ8wHymJImLcBkpv/HYfs8V4f1SJv+DlPc/MrUCBwcp2krZdU4kOquUlVn9yC3dqz8LyOQv</diagram></mxfile>

Additional_Notes/uml/class_diagram_scoring_functions.plantuml

@@ -0,0 +1,46 @@
+@startuml
+
+skinparam class {
+	BackgroundColor White
+	ArrowColor Grey
+	BorderColor Black
+    
+}
+skinparam stereotypeCBackgroundColor #fff
+skinparam stereotypeIBackgroundColor #999
+skinparam stereotypeABackgroundColor #ddd
+skinparam monochrome true
+hide members
+
+skinparam shadowing false
+
+
+interface ScoringFunction
+class ScoringFunctionFactory
+interface ListFunction
+abstract class PreferenceScoringFunction
+abstract class ConfigurationPenealty
+class ReduceScoringFunction
+interface PreferenceToListFunction
+
+abstract class ListToListFunction
+abstract class ListToValueFunction
+interface ValueToValueFunction
+
+
+ScoringFunctionFactory --> ScoringFunction : build
+
+PreferenceScoringFunction --> "1" PreferenceToListFunction : preferenceToListFunction
+PreferenceScoringFunction --> "0..*" ListToListFunction : listToListFunctions
+PreferenceScoringFunction --> "1" ListToValueFunction : listToValueFunction
+PreferenceScoringFunction --> "0..*" ValueToValueFunction : valueToValueFunctions
+
+ScoringFunction <|-- PreferenceScoringFunction
+ScoringFunction <|-- ConfigurationPenealty
+ScoringFunction <|-- ReduceScoringFunction
+
+ReduceScoringFunction *-- "2..*" ScoringFunction
+
+ListFunction <|-- ListToListFunction
+ListFunction <|-- ListToValueFunction
+@enduml

Additional_Notes/uml/sequence_diagram_generating_recommendation.plantuml

@@ -0,0 +1,36 @@
+@startuml
+skinparam monochrome true
+skinparam SequenceBoxBackgroundColor #ffffff
+skinparam ParticipantPadding 5
+skinparam shadowing false
+hide footbox
+
+title generating a recommendation 
+
+box "Client B"
+participant "M.Customer B"
+end box
+
+box "Client A"
+participant "M.Customer A"
+end box
+
+box "Server"
+participant M.Collab
+participant M.Recommend
+end box
+
+activate "M.Customer A"
+activate "M.Customer B"
+activate M.Collab
+
+M.Collab -> M.Recommend : get_recommendation(configuration, preferences)
+activate M.Recommend
+M.Collab <-- M.Recommend : return recommendedFeatures
+deactivate M.Recommend
+
+par
+    M.Collab --> "M.Customer A" : broadcast (recommendedFeatures)
+    M.Collab --> "M.Customer B" : broadcast (recommendedFeatures)
+end
+@enduml

README.md

@@ -0,0 +1,3 @@
+# Bachelor's Thesis
+
+This repository contains all text and graphics of my bachelors thesis. The corresponding source code for the recommender is published here: https://github.com/13hannes11/bachelor_thesis_m.recommend