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

reduce usage of therefore and replace by synonyms

Browse Source
This commit is contained in:
hannes.kuchelmeister
2020-05-07 12:48:16 +02:00
parent eb4a543884
commit 00d01fb669
3 changed files with 9 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -16,7 +16,7 @@ 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 single responsibility and separation of concern software design principles. It would change M.Collab from a system that works similar to a router to one that additionally handles recommendations. M.Collab manages communication between M.Collab-Customer instances and between M.Core and M.Collab-Customer. Therefore this solution was discarded.
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 single responsibility and separation of concern software design principles. It would change M.Collab from a system that works similar to a router to one that additionally handles recommendations. M.Collab manages communication between M.Collab-Customer instances and between M.Core and M.Collab-Customer. 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.
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.
@@ -55,7 +55,7 @@ Data is stored and retrieved using data access objects. Therefore, the currently
\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. Moreover, it excels if data requirements are not entirely clear and if a large amount of unstructured data has to be stored. Moreover, non-relational databases 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. Therefore 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 NoSQL database is used.
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. Moreover, it excels if data requirements are not entirely clear and if a large amount of unstructured data has to be stored. Moreover, non-relational databases 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 NoSQL database is used.
\section{Scoring Functions}
\label{sec:DesignImplementation:ScroingFunctions}