diff --git a/30_Thesis/sections/10_foundations.tex b/30_Thesis/sections/10_foundations.tex index 8752e7e..7b1e20f 100644 --- a/30_Thesis/sections/10_foundations.tex +++ b/30_Thesis/sections/10_foundations.tex @@ -202,7 +202,7 @@ This thesis presents one use case from forestry. It gradually extends this use c 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. The extended architecture is shown in \autoref{fig:Foundations:CollaborativeConfiguratorMerlin}. -He only makes changes to M.Customer which is renamed to M.Collab-Customer and introduces a new component M.Collab. +He only makes changes to M.Customer which is renamed to \texttt{M.Collab-Customer} and introduces a new component \texttt{M.Collab}. \begin{figure} \centering @@ -214,10 +214,10 @@ He only makes changes to M.Customer which is renamed to M.Collab-Customer and in The following list provides a short overview of each component. \begin{description} - \item[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[M.Model] is the editor to create products and rules. These rules can then be uploaded to M.Core. - \item[M.Collab] is a node.js server application that communicates with M.Core via REST-API and with M.Collab-Customer via WebSockets. It sits in between M.Collab-Customer and M.Core and handles all processing regarding collaborative configuration. - \item[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 M.Collab-Customer are send to M.Collab. + \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} \section{Software Design} diff --git a/30_Thesis/sections/50_design_and_implementation.tex b/30_Thesis/sections/50_design_and_implementation.tex index 072f45f..be74bc5 100644 --- a/30_Thesis/sections/50_design_and_implementation.tex +++ b/30_Thesis/sections/50_design_and_implementation.tex @@ -4,7 +4,7 @@ This thesis requires a group configuration system with a recommender. In this thesis \emph{CAS Configurator Merlin} \cite{IndustrySpecificProduct2020} is extended. As this configurator does not allow group configuration, a modified version is used that has been developed by \citeauthor{raabKollaborativeProduktkonfigurationEchtzeit2019} \cite{raabKollaborativeProduktkonfigurationEchtzeit2019}. The base system and its extension are described in \autoref{sec:Foundations:BaseSystem}. \todo[inline]{refactor} -\autoref{fig:DesignImplementation:RecommenderForCollaborativeConfiguratorMerlin} shows the system architecture after the recommender was added. For this thesis M.Collab and M.Collab-Customer have undergone some slight modifications to allow the displaying of recommendations and to query the recommender. The user interface is shown in \autoref{fig:DesignImplementation:RecommenderForCollaborativeConfiguratorMerlin}. It extends the user interface of M.Collab-Customer by adding a 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. +\autoref{fig:DesignImplementation:RecommenderForCollaborativeConfiguratorMerlin} shows the system architecture after the recommender was added. 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:RecommenderForCollaborativeConfiguratorMerlin}. It extends the user interface of \texttt{M.Collab-Customer} 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} \centering @@ -17,16 +17,16 @@ This thesis requires a group configuration system with a recommender. In this th \section{Microservice} \label{sec:DesignImplementation:Microservice} -An existing base system can be extended in different directions. As M.Collab already functions as middleman between M.Collab-Customer and M.Core, one solution would be to add recommender functionality to 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 M.Collab from a system that works similar to a router to one that additionally handles recommendations. M.Collab manages communication between M.Collab-Customer instances and between M.Core and M.Collab-Customer. Thus this solution was discarded. +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 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. +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. -Due to these reasons it was decided to create a new microservice, called M.Recommend which communicates with 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 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. +Due to these reasons it was decided to create a new microservice, 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. \begin{figure} \centering \includegraphics[width=0.6\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 \emph{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.} + \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} @@ -34,7 +34,7 @@ Due to these reasons it was decided to create a new microservice, called M.Recom \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, M.Collab sends a HTTP-POST-request to M.Recommend (see \autoref{fig:DesignImplementation:SequenceDiagramRecommendation}). This request contains preferences and the current configuration. M.Recommend generates a recommendation based on the received data as a response. The recommended finished configuration is now sent from M.Collab via broadcast over WebSockets to all M.Customer clients. +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} \centering @@ -72,7 +72,7 @@ Scoring functions are implemented in a modular fashion. There are different type \section{Technologies} \label{sec:DesignImplementation:Technologies} -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. +\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.