Commit 4c085809 authored by Sandro Eiler's avatar Sandro Eiler 🐌

Added content to thesis.

parent 1a9f4d38
\section*{Abstract}
Many systems that host groups of users, like e.g., social media platforms, provide problem solutions or tools for users and groups of users.
Many systems that host groups of users, like social media platforms, provide solutions or tools for users and groups of users.
Within these groups, there can exist roles, which again might be connected to permissions.
The role model itself can vary from system to system. Some are hierarchical, some have flat hierarchies, some are related to the permissions, others with notifications. Decoupling the role model implementation from the rest of the system has multiple advantages, such as achieving automatic role assignment more easily and being able to change a role model on the fly.
Within this master thesis, challenges of automated role assignment are examined and necessary elements for how a development tool can help are distilled. The main contribution is the tool \textit{karmantra}, which allows to integrate arbitrary role models in software projects and lets developers extend or alter them. The tool is kept in a very generic way to be expandable easily. With this tool, a step is taken towards decoupled and transparent role systems, that can not only serve the needs of common commercial platform needs.
%The abstract of a thesis consists of two blocks. The first one contains
%a short introduction/motivation of the topic as well as a description of
%the problem statement (around 5-8 sentences).
%The second block of the
%absctract explains the objective or contribution of the thesis (also around
%5-8 sentences).
Within this master thesis, challenges of automated role assignment are examined and necessary elements for how a development tool can help are distilled. The main contribution is the tool \textit{karmantra}, which allows to integrate arbitrary role models in software projects and lets developers extend or alter them. The tool is kept in a very generic way to be expandable easily. With this tool, a step is taken towards decoupled and transparent role systems, that can not only serve the needs of common commercial platform needs.
\ No newline at end of file
......@@ -9,6 +9,13 @@ Last of all, the implementation is discussed and an outlook for future work is g
Within this master thesis, the specified challenges for software development led to the design and implementation of the framework \textit{karmantra}. It is independent from operating systems, can be adapted to other programming languages and has the functionality of generating arbitrary models for automated rule-based role evaluation. As shown, the requirements for diverse role models can be complex. With the defined premises it was possible to develop a meta model that allows automation in a generically usable way. With this, we have seen that it is possible to build a very modular tool that is adaptable for future advancements.
Within this thesis, general problems that can occur when dealing with role models were introduced first in Chapter \ref{cha:introduction}. Also the motivation to enable automated role assignment through generic tools was explained.
In Chapter \ref{cha:fundamentals}, related work was referenced, important definitions were made and rule-based role models were presented.
In Chapter \ref{cha:requirements}, requirements were collected.
In Chapter \ref{cha:design}, a software tool design was developed that should enable both the creation of role models and a role evaluation mechanism.
The realization of \textit{karmantra} according to the principles in the \textit{Design} chapter was explained in chapter \ref{cha:implementation}, which also presented how the requirements were addressed.
Finally in Chapter \ref{cha:evaluation} the evaluation of \textit{karmantra} by integration tests was presented, the fulfillment of non-functional requirements was checked and a theoretical application of \textit{karmantra} for the platform \textit{Karrot} was explained.
\section{Discussion}
\label{sec:conclusion:discussion}
......@@ -23,13 +30,12 @@ Improvement can come from extending \textit{karmantra} by the possibility to def
\section{Outlook}
\label{sec:conclusion:outlook}
Having done a contribution in form of a design and implementation for a tool to build more flexible, automated and comprehensible rule-based role models, there's still a way to go to better software regarding the defined requirements. As mentioned, more and more programming languages and contexts like python's \textit{Django} can be included. We can see this as an ongoing process, adapting \textit{karmantra} to the changing needs of developers.
Having done a contribution in form of a design and implementation for a tool to build more flexible, automated and comprehensible rule-based role models, there is still a way to go to better software regarding the defined requirements. As mentioned, more and more programming languages and contexts like python's \textit{Django} can be included. We can see this as an ongoing process, adapting \textit{karmantra} to the changing needs of developers.
It is even thinkable to offer loadable context modules in future, where the needed respective context can be specified by the developer to keep the core of \textit{karmantra} slim.
Coming to a point where more and more features are available, other testing methods like unit testing will become valuable and important as an addition to integration tests.
Since this thesis' approach has not been tested in a long term for a developer's implementation routine yet, this is something useful in future to get more insights for possible improvements.
Concerning software development there's still a broad field for research when it comes to systems that seek to provide role evaluation on the base of commonly agreed-upon rules. This does not necessarily touch the subject of role assignment only, but becomes clear especially here. Not only social organizations can profit from the results.
Concerning software development there is still a broad field for research when it comes to systems that seek to provide role evaluation on the base of commonly agreed-upon rules. This does not necessarily touch the subject of role assignment only, but becomes clear especially here. Not only social organizations can profit from the results.
Having given this outlook and knowing that software can not provide solutions for all problems, the master thesis shall be concluded with the hope that software can and will be used to build tools that serve people and their goals for a better organisation, exchange and cohabitation on earth.
\ No newline at end of file
This diff is collapsed.
This diff is collapsed.
......@@ -125,8 +125,7 @@ This chapter covers a retrospection on related scientific literature, presents b
\end{figure}
Sometimes a role is not depending on attributes only, but on complex (possibly democratic) processes or work flows. In this case a role's rule can represent one step of a process of gaining (or losing) a role. Figure \ref{fig:fundamentals-model-processes} shows how rules can be used to represent process steps.
\subsubsection{Notifications}
\label{subsubsec:fundamentals:rolemodels:modelingasidesgroups:notifications}
......@@ -138,11 +137,4 @@ This chapter covers a retrospection on related scientific literature, presents b
\end{center}
\end{figure}
Figure \ref{fig:fundamentals-model-notifications} shows a completely different scenario. Here the use case is the regulation of sending notifications. For this we replace the roles with notifications. A notification can have one or more rules for being sent. This still perfectly fits to our environment of users and groups.
%\section{Summary}
%\label{sec:fundamentals:summary}
%TODO Überleitung
\ No newline at end of file
Figure \ref{fig:fundamentals-model-notifications} shows a completely different scenario. Here the use case is the regulation of sending notifications. For this we replace the roles with notifications. A notification can have one or more rules for being sent. This still perfectly fits to our environment of users and groups.
\ No newline at end of file
This diff is collapsed.
......@@ -4,10 +4,10 @@
In social life, acting within groups has countless advantages over acting alone.
No matter if we connect through work, a sports club, a political party, scientific collaborations or on social media platforms.
We can observe that participating within groups always entails having roles.
But groups are not only a matter of social relations. In computer systems, a user may be part of an administrator's or moderator's group for example. In this case, a role doesn't necessarily represent a social circumstance anymore, but becomes a matter of read and write privileges. Or to be more general, roles can be used to map to permissions within a system.
Roles can be obvious like e.g., employees and bosses or standard users and administrators. But there can also be "hidden" roles, which a system may not or doesn't want to represent. Considering the social component, we can give examples like "the one that brings fun to the group" or "the one that is the driving force". On the other hand, roles that lead to permissions in a computer system can influence the social structures.
But groups are not only a matter of social relations. In computer systems, a user may be part of an administrator's or moderator's group for example. In this case, a role does not necessarily represent a social circumstance anymore, but becomes a matter of read and write privileges. Or to be more general, roles can be used to map to permissions within a system.
Roles can be obvious like \textit{employees} and \textit{bosses} or \textit{standard users} and \textit{administrators}. But there can also be "hidden" roles, which a system may not or does not want to represent. Considering the social component, we can give examples like "the one that brings fun to the group" or "the one that is the driving force". On the other hand, roles that lead to permissions in a computer system can influence the social structures.
Humans connect to others within groups because they are social beings.
Today we can not only find humans within groups, like for example a therapy dog.
Today we can not only find humans within groups, like for example, a therapy dog.
If we think groups more technically, members can not only be living entities.
To satisfy the user's need of acting in groups and the developer's need of supplying software with different roles and permissions, innumerable tools, frameworks and systems exist, trying to provide a best solution.
......@@ -35,7 +35,7 @@ The development of a role model leads to various potential challenges:
\item
The role model may not reflect the actual roles and needs within groups.
\item
Having a diverse user base raises the need of providing various role models for different groups. Reasons like e.g., the lack of development resources or the developer's will can prevent respecting such needs.
Having a diverse user base raises the need of providing various role models for different groups. Reasons like the lack of development resources or the developer's will can prevent respecting such needs.
\item
A role model may be hidden or dispersed in code and therefore hard to learn by other developers and others with interest of understanding the role assignment. It might be striven to make a role model in a software comprehensible even for users without much technical background to allow a more holistic participation.
\item
......@@ -68,7 +68,7 @@ Referring to the stated challenges, the following main objectives for the tool \
\section{Structure of the thesis}
\label{sec:introduction:structure}
In Chapter 2, basic concepts and terms are specified. Therefor related work in this field is introduced.
In Chapter 2, basic concepts and terms are specified. Therefor, related work in this field is introduced.
In particular, concepts which are needed to meet the thesis' objectives, are examined. Important examples for rule-based role models will be given.
In Chapter 3, both functional and non-functional requirements are collected and described.
In Chapter 4, the concepts and designs for the implemented framework are presented.
......
......@@ -643,6 +643,8 @@
@Article{rutzdevops,
author = {R{\"u}tz, Martin},
title = {DEVOPS: A SYSTEMATIC LITERATURE REVIEW},
year = {2019},
month = {08},
}
@Misc{unittest,
......
......@@ -62,11 +62,11 @@ Besides an API, a command line interface must give the possibility to execute al
With the section of non-functional requirements, criteria are specified to be used for evaluating the approach's design implementation.
\begin{description}
\item[Documentation] \hfill \\ A documentation is required for a better understanding of karmantra and its usage. It must explain basic design concepts and how to integrate an outcoming role model within a project. Accordingly, the target group is \textit{DevUser}s.
\item[Documentation] \hfill \\ A documentation is required for a better understanding of \textit{karmantra} and its usage. It must explain basic design concepts and how to integrate an outcoming role model within a project. Accordingly, the target group is \textit{DevUser}s.
\item[Re-Usability Of Code] \hfill \\ It's required to re-use existing ("external reuse") and own ("internal reuse") components for code and design where possible and useful. The aim is to save time and resources, to reduce redundancy and to take advantage of the fact that software quality of external components can be high if it ran through a software development process with adequate testing resources.
\item[Robustness] \hfill \\ Karmantra has to tolerate erroneous input and to cope with errors during execution.
\item[Robustness] \hfill \\ \textit{karmantra} has to tolerate erroneous input and to cope with errors during execution.
A hard crash without finishing the process gracefully should be avoidable. Guidance for resolving problems should be provided where possible.
\item[Portability] \hfill \\ The tool must be usable in different development environments.
......@@ -74,6 +74,6 @@ With the section of non-functional requirements, criteria are specified to be us
\item[Open Source] \hfill \\ The developed concepts and code are licensed with an open source approach. Permission to re-use the code, at least in a non-commercial way, has to be guaranteed.
\item[Low Usability Complexity] \hfill \\ Karmantra has to be implemented in a comprehensible way. This affects the CLI as well as the rest of the API. It is required that a low complexity for usability is implemented so that both a guided walkthrough as well as automated approaches are feasible for DevUsers.
\item[Low Usability Complexity] \hfill \\ \textit{karmantra} has to be implemented in a comprehensible way. This affects the CLI as well as the rest of the API. It is required that a low complexity for usability is implemented so that both a guided walkthrough as well as automated approaches are feasible for DevUsers.
\end{description}
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment