...
 
Commits (2)
......@@ -10,9 +10,6 @@ docu:
install-dev:
conda create --name karmantra --file requirements-dev.txt
install-docu:
install-docu-requirements:
pip install mkdocs
pip install mkdocs-material
thesis:
texliveonfly thesis/document.tex
/tmp
## Core latex/pdflatex auxiliary files:
*.aux
*.lof
*.log
*.lot
*.fls
*.out
*.toc
## Bibliography auxiliary files (bibtex/biblatex/biber):
*.bbl
*.bcf
*.blg
*-blx.aux
*-blx.bib
*.brf
*.run.xml
## Build tool auxiliary files:
*.fdb_latexmk
*.synctex
*.synctex.gz
*.synctex.gz(busy)
*.pdfsync
\ No newline at end of file
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
<name>thesis</name>
<comment></comment>
<projects>
</projects>
<buildSpec>
<buildCommand>
<name>net.sourceforge.texlipse.builder.TexlipseBuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>net.sourceforge.texlipse.builder.TexlipseNature</nature>
</natures>
</projectDescription>
eclipse.preferences.version=1
org.jboss.ide.eclipse.as.core.singledeployable.deployableList=
#TeXlipse project settings
#Mon Oct 12 12:12:55 CEST 2015
markTmpDer=true
builderNum=2
outputDir=
makeIndSty=
bibrefDir=
outputFormat=pdf
tempDir=tmp
mainTexFile=document.tex
outputFile=document.pdf
langSpell=en
markDer=true
srcDir=
\section*{Abstract}
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.
\ No newline at end of file
\section*{Acknowledgment}
This master thesis would not exist in this way without following wonderful people: Robin helped me as supervisor with his calm and prudent willingness to adapt to all needs that came up, not only for this master thesis. Erce supported me tirelessly with his programming experience, friendship and talks. And the lovely and idealistic \textit{Karrot} group, allowed me not only to find my thesis subject. Through this group I learned a lot about the connection between democracy and computer science, group structures and utopistic living communities. Warm hugs to you Nick, Tilmann, Janina and Bruno!
My thanks also go to my closest friends, my flat mates and my family who supported me throughout the years. Without all that love, the things I do would not have the same meaning and higher purpose.
As this master thesis is written, the world is hit by the Corona Virus. I hope that we can make the best out of it and build a better society where humans stand together regardless of nationality and wealth.
\ No newline at end of file
\chapter{Conclusion}
\label{cha:conclusion}
Within this chapter, a summary is given for the approaches and contributions, given in this master thesis.
Last of all, the implementation is discussed and an outlook for future work is given.
\section{Summary}
\label{sec:conclusion:summary}
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}
Accomplishing the implementation of a generic tool like \textit{karmantra}, we can have a look at the non-functional requirements and ask if it is possible to do better. If we take the requirement of comprehensibility as an example, we can argue that it is still hard or impossible for many people to understand the developer's implementation of role models. Focusing on the links between rules, roles and triggers, this contribution provides enough clarity for non-technical users already through human-readable and easy to read configuration files. Since the developers have to implement the rule's behaviors, we could look at how to make these implementations more transparent. The developer's rule implementations fully depend on the role model embedding system. This does not allow to build a generic tool anymore. Instead the approach would have to be to build a full service system with an interface to allow communication between the developer's system and the role model system. That role model system might need to have full control over the user database as well, which results in new challenges of assigning responsibilities to different services.
The reason of generating a generic tool, which does not allow having a rule creation service affects other developer needs as well. For example a notification system that informs members about role changes has to be implemented by the developer. Fortunately this has been respected in the design of \textit{karmantra}, so that it is made easy to include cases like this one.
We have seen that the tool \textit{karmantra} can provide a platform independent tool that can even allow including templates for other programming languages. If we look at the development process, it can be questioned if there are use cases where having \textit{karmantra} as a python tool fits all needs. Despite justifying the decision of using python, it should not be too challenging to transfer the concepts within this thesis to implement \textit{karmantra} with other programming languages.
Improvement can come from extending \textit{karmantra} by the possibility to define, how rules are connected. Modeling of arbitrary rules could become more comfortable, if e.g., some rules can be connected through a disjunction instead of a conjunction. For now this option is manually feasible by overriding a role's evaluation function.
\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 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 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.
\documentclass[numbers=noenddot]{thesis}
% put name, etc. here
\fullname{Sandro Eiler}
\email{sandro.eiler@uni-ulm.de}
\headline{Design and Implementation\\of a Generic Framework\\for Rule-based Automated\\User Role Management}
\titel{karmantra - a generic framework for rule-based automated user role management}
\thesisyear{2020}
\matnr{751972}
\reviewerA{Prof. Dr. Manfred Reichert}
\reviewerB{Prof. Dr. Rüdiger Pryss}
\tutor{Robin Kraft}
\typ{Master's thesis }
\faculty{Engineering, Computer Science and Psychology}
\department{Databases and Information Systems Department}
% If you do not wish to have a licence please remove the following text.
% The licence allows to duplicate and copy for noncommercial purposes.
% Doing so the author does always have to be stated. A commercial
% utilization is still possible for the author.
\license{
This work is licensed under the Creative Commons.
Attribution-NonCommercial-ShareAlike 3.0 License. To view a copy of this
license, visit http://creativecommons.org/licenses/by-nc-sa/3.0/de/ or send a
letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco,
California, 94105, USA. \\ Composition: PDF-\LaTeXe
}
\hypersetup{%
pdftitle=\pdfescapestring{\thetitel},
pdfauthor={\thefullname},
pdfsubject={\thetyp},
}
% hyphenation
\hyphenation{Sil-ben-trenn-ung}
\begin{document}
\frontmatter
\maketitle
% imprint
\clearpage
\imprint
\cleardoublepage
% starting here linespacing 1,4 10pt/14pt
\setstretch{1.4}
\input{abstract}
\cleardoublepage
\input{acknowledgment}
\tableofcontents
\mainmatter
% chapters of the thesis start here
\input{introduction}
\input{fundamentals}
\input{requirements}
\input{design}
\input{implementation}
\input{evaluation}
\input{conclusion}
% bibliograhpy
\bibliographystyle{splncs}
\begingroup
\interlinepenalty 10000
\sloppy
\bibliography{literature}
\endgroup
% appendices
\appendix
% appendices starting here
\input{sources}
\backmatter
\listoffigures
%\listoftables
\clearpage
\honestydisclaimer
\end{document}
\chapter{Evaluation}
\label{cha:evaluation}
In this chapter the test procedure for \textit{karmantra} is presented, the fulfillment of non-functional requirements is discussed and a theoretical application of the developed concepts is explained using the platform \textit{Karrot}.
\section{Testing}
\label{sec:evaluation:testing}
To evaluate a correct behavior of \textit{karmantra}, integration test cases are written with python's standard test libraries.
The following list explains the tested cases and which functions they are mapped to. The tests cover the functional requirements as addressed in Section \ref{sec:implementation:requirments} have all run successfully.
\subsection{Modeling}
\label{subsec:evaluation:testing:modeling}
For testing \textit{karmantra}'s modeling full set of functions, tests are applied for tasks with the scope of core tasks (as described in Section \ref{subsec:design:tasks:coretasks}).
This is done by importing \textit{karmantra} as module. With every test case, a task is submitted to the module to be executed.
To prepare and clean up tests, python's provided \textit{unittest} functions \textit{setUp} and \textit{tearDown} are used.
\begin{itemize}
\item Creating a new project for modeling roles:\\ \textit{test\_create\_new\_project}
\item Delete an existing project:\\ \textit{test\_project\_deletion}
\item List existing projects:\\ \textit{test\_project\_list\_projects\_existing}\\
\textit{test\_project\_list\_projects\_empty}
\item Add a role to project:\\ \textit{test\_project\_add\_role}\\ \textit{test\_add\_role\_failing}\\ \textit{test\_add\_role\_overwriting}
\item Remove a role from project:\\ \textit{test\_remove\_role}
\item Add a rule to project:\\ \textit{test\_add\_rule}
\item Add a trigger to project:\\ \textit{test\_add\_trigger}
\item Connect a rule to a role:\\ \textit{test\_connect\_rule\_to\_role}
\item Remove a rule from project:\\ \textit{test\_remove\_rule\_failing}
\item Remove a trigger from project:\\ \textit{test\_remove\_trigger\_and\_rule}
\item Disconnect a rule from a role:\\ \textit{test\_disconnect\_rule\_from\_role}
\end{itemize}
\subsection{Model usage}
\label{subsec:evaluation:testing:modelusage}
Having implemented tests for the correct behavior of \textit{karmantra}'s modeling options, the functionality of the outcoming model is the subsequent important field for testing.
To test the functionality of the importable role model, a test class with example users within a group has been created.
To simulate a realistic use case, the user and group objects lack attributes necessary for \textit{karmantra}'s evaluation process.
Having implemented such a test set, the wrappers for users and groups were adapted to demonstrate the usability of arbitrary systems. In a second step the role evaluation itself is tested both for the case of not being applicable for a user and for being applicable for a user.
\section{Fulfillment of non-functional requirements}
\label{sec:evaluation:requirements}
The fulfillment of non-functional requirements from \ref{sec:requirements:nonfunctional} is verifiable with Chapter \ref{cha:design} mostly:
\begin{description}
\item[Documentation] \hfill \\ A documentation of design and implementation is provided with this master thesis. Additionally, a deployable \textit{readthedocs} documentation with descriptions and tutorials is provided.
\item[Re-Usability Of Code] \hfill \\ The speraration of layers (\ref{subsec:design:datamodel:layers}), helper classes \ref{sec:implementation:components} and models allowed a very modular approach. The use of standard library solutions was mentioned and performed.
\item[Robustness] \hfill \\ \textit{karmantra} tolerates erroneous input e.g., with the
input validation for command line arguments \ref{subsec:implementation:components:cli} but also with modeling functions. With using python's exception handling, a most unwanted hard crashes can be prevented.
\item[Portability] \hfill \\ Portability is ensured through implementation layers (\ref{subsec:design:datamodel:layers}) and the use of templates for different contexts (\ref{subsec:implementation:structure:main-karmantra-deployment}).
\item[Open Source] \hfill \\ As described in \ref{subsec:implementation:developmentprocess:licensing}, \textit{karmantra} is licensed under the \textit{GNU General Public License, version 3}.
\item[Low Usability Complexity] \hfill \\ The careful design of tasks (\ref{sec:design:tasks}) and command line arguments ensures that DevUsers can profit from low usability complexity. For the command line interface, a walkthrough is usable, while using \textit{karmantra} as python module comes with clearly defined and easily understandable tasks.
\end{description}
\section{Theoretical application of concept}
\label{sec:evaluation:application}
To show that \textit{karmantra} is applicable, the online platform \textit{Karrot} is analyzed below. On this basis it will be apparent how \textit{karmantra} can be included into a working system. \textit{Karrot} has been chosen, because it fits the idea of automated rule-based role assignment, it shows another use case among many business solutions and because it is assumed to be more complex to include \textit{karmantra} into an existing system than starting from scratch. The exchange with and help from the developers of \textit{Karrot} did not only support the following theoretical application of concept, but also the design chapter of this master thesis.
\subsection{Karrot}
\label{subsec:evaluation:application:karrot}
\textit{Karrot} is a platform, connecting people all over the world to save food from being thrown away. Its motivation comes from the fact that about one billion people have to hunger while twelve billion people can be fed with today’s possibilities. Foodsaving groups intend to raise awareness for production and consumption of food through saving food. \textit{Karrot} provides the possibility for groups to organize via its platform. Its idea is to use automated role assignment without interfering with group's decisions on role assignment.
\subsection{Current role implementation}
\label{subsec:evaluation:application:current}
%TODO Bezug nehmen, welche meiner Module für Umsetzung verwendet werden könnten
\subsubsection{Querying roles}
\label{subsubsec:evaluation:application:current:query}
Assuming, \textit{Karrot} wants to find out if a user has the role \textit{editor}, the function \textit{is\_editor(user)} is called. \textit{is\_editor(user)} is a member of a group instance. The function itself calls the function \textit{is\_member\_with\_role(user,rolename)} from the class \textit{GroupMembership}. Figure \ref{fig:evaluation-karrot-queries} visualizes the process.
\begin{figure}[htp]
\begin{center}
\includegraphics[width=1.0\linewidth]{karrot01} %pdf, jpg, png...
\caption{\textit{Karrot} queries roles through the Django framework.}
\label{fig:evaluation-karrot-queries}
\end{center}
\end{figure}
\subsubsection{Updating roles}
\label{subsubsec:evaluation:application:current:update}
At the moment there is only one trigger for the change of roles: Giving \textit{trust carrots}. Whenever a \textit{trust carrot} is given by a user A to a user B, \textit{Karrot} will check if the change will affect user B's \textit{editor} role status. If so, the new role will be made persistent. Figure \ref{fig:evaluation-karrot-update} represents the process in an abstract way.
\begin{figure}[htp]
\begin{center}
\includegraphics[width=1.0\linewidth]{karrot02} %pdf, jpg, png...
\caption{\textit{Karrot} queries roles through the Django framework.}
\label{fig:evaluation-karrot-update}
\end{center}
\end{figure}
\subsubsection{Proposal for implementation}
\label{subsubsec:evaluation:application:current:proposal}
Following the intentions and requirements of \textit{Karrot}, a decoupling of the role evaluation process can be achieved with \textit{karmantra}, as visualized in Figure \ref{fig:evaluation-karrot-triggers}.
\begin{figure}[htp]
\begin{center}
\includegraphics[width=1.0\linewidth]{karrottriggers} %pdf, jpg, png...
\caption{Rule-based role evaluation can be implemented for \textit{Karrot}, using \textit{karmantra}.}
\label{fig:evaluation-karrot-triggers}
\end{center}
\end{figure}
Figure \ref{fig:evaluation-karrot-triggers} represents all steps that are taken within a role assignment process:
\begin{enumerate}
\item A user action or system task takes place.
\item The system uses the action from 1. as a trigger for \textit{karmantra}'s role evaluation framework. Information like the user and group are passed to the framework.
\item Knowing which triggers map to which rules, an evaluation process is initiated for the associated roles.
\item Every role that has to be checked, examines whether its rules apply.
\item The results are given back to the system.
\item The system can use the results e.g., to update the user's attributes in the database.
\item Additionally the system can use the result for e.g., user notification (7.1) or statistics (7.2).
\end{enumerate}
Knowing the key functions (see \ref{subsubsec:evaluation:application:current:query}) for the recent role evaluation mechanism, it is possible to connect this approach to \textit{Karrot}.
\ No newline at end of file
This diff is collapsed.
This diff is collapsed.
\chapter{Introduction}
\label{cha:introduction}
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 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.
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.
How good a software solution is (for the users or the supplier) may depend on how interaction between groups members is made possible.
As described, group members have roles. In software systems, roles are often assigned by administrative users.
The assignment of roles is based on rules.
Rules can be explicit and comprehensible. For a rule, being explicit means, that roles are applied on the basis of objective criteria. Being comprehensible means, that a rule is understandable by group members and the assignment process is transparent to the software users. Conversely, rules that are not comprehensible and explicit can exist if they are kept in an administrator's mind who then performs role assignments. In a more technical way the aim of achieving explicit and comprehensible rules can be missed if rule implementation is nested and hidden in code or implemented in a complex way.
As we will examine, there are endless possibilities of role models that can be applied to systems.
Some use cases demand a flexible approach that allows different role assignment models for different groups.
Automating role assignments in a rule-based way can lead to clearer and more comprehensive assignment processes.
This in turn can lead to positive effects in the sense that participation for improving a system is easier.
We will see that through a rule-based automated user role management, group structures can be reflected more in a needed, natural and flexible way.
We will analyze the international online platform \textit{Karrot}, which allows people from all over the world to connect in groups for saving food, and see how its needs for an automated rule-based role evaluation can be satisfied with this approach.
\section{Problem statement}
\label{sec:introduction:problemstatement}
The development of a role model leads to various potential challenges:
\begin{itemize}
\item
The role model may change over time and has to be re-implemented.
\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 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
Software tools focus on specific target groups only, such as enterprises or municipal stakeholders.
\item
Democratic group processes can be lived in arbitrary environments, like organizations and enterprises. The evaluation of member's roles can be an intended objective for such processes. Role assignment is rarely thought as a result of such democratic processes and therefore few software approaches include this premise.
\end{itemize}
Considering all these challenges can be difficult in a development process. A developer tool that supports building wanted role models in a way that it is decoupled from the rest of the system and that can be changed easily afterwards, might be helpful.
For this it's important to figure out a meta model that can fit all needs of systems with rule-based role assignment. Additionally a generic tool has to have a high degree of module interchangeability, since arbitrary environments, operating systems and programming languages have to be supported. With this master thesis these challenges are addressed.
% Section: objective
\section{Objective}
\label{sec:introduction:objective}
Having stated problems of implementing rule-based role assignment, this thesis strives to address these.
The main contribution is the design of a role assignment solution for developers which is meant to be kept as generic as possible. This includes an implementation of the emerging concepts in form of a tool, called \textit{karmantra}.
First, an analysis and design is done of what is needed to fulfill arbitrary developer needs. This includes figuring out a meta model for role models and all its preconditions. The design also includes defining interchangeable implementation layers for \textit{karmantra} to ensure, arbitrary developing environments can be supported in the long run. An important question for this project is, how decoupling of role evaluation can be implemented, especially in arbitrary systems.
The tool \textit{karmantra} is supposed to support a developer with generating and managing a decoupled role model, allowing an rule-based automated role evaluation.
Referring to the stated challenges, the following main objectives for the tool \textit{karmantra} are going to be achieved:
\begin{itemize}
\item
Automated rule-base role models can easily be generated and modified.
\item
The role model can be generated in a decoupled, comprehensible and clean way.
\item
The tool allows to integrate different programming languages and environments like e.g., \textit{python} and \textit{php}.
\end{itemize}
\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 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.
The actual implementation solution is shown in Chapter 5, where the overall development process and the important implementation details for all framework modules can be found.
In Chapter 6, the outcome is evaluated through defining tests and a theoretical application of concept for the online platform \textit{Karrot}.
Lastly the thesis approach and outcome are discussed to be able to give an outlook for future work.
\ No newline at end of file
This diff is collapsed.
\chapter{Requirements}
\label{cha:requirements}
The following collected requirements were collected by interviewing developers from different platforms and tie in the related work from above.
\section{Functional requirements}
\label{sec:requirements:functional}
The following functional requirements build the verifiable basis for the evaluation of Chapter \ref{cha:design} (design) and Chapter \ref{cha:implementation} (implementation).
\subsection{System integrability}
\label{subsec:requirements:functional:systemintegrability}
The developer has to have the possibility to integrate the roles into the preferred location. Adding new roles to the system must not be limited to a specific development environment.
\textbf{Components:}
\begin{description}
\item[\textit{API}] \hfill \\ Let's the DevUser control the tool in a generic way.
\item[\textit{Framework Configurability}] \hfill \\ Let's the DevUser define this tool's behavior (e.g., to override existing roles).
\end{description}
%\pagebreak
\subsection{Project management}
\label{subsec:requirements:functional:projectmanagement}
The DevUser must have the possibility to specify a path, where the project shall be deployed.
A project must be producible and removable. Dealing with multiple projects has to be possible.
\textbf{Components:}
\begin{description}
\item[\textit{Listing projects}] \hfill \\ Allows registering projects for a quicker access.
\item[\textit{Project creation}] \hfill \\ Allows creating a new role model in a specified location.
\item[\textit{Project removal}] \hfill \\ Allows removing a role model in a specified location.
\item[\textit{Model structure}] \hfill \\ The model structure can also be changed manually in an easy way.
\end{description}
\subsection{Role modeling}
\label{subsec:requirements:functional:modeling}
The DevUser must be able to add and remove roles.
The DevUser must be able to add and remove rules.
The DevUser must be able to add and remove triggers.
The DevUser must be able to map triggers to role's rules.
\textbf{Components:}
\begin{description}
\item[\textit{Define abstract role class}] \hfill \\ All roles can inherit from the abstract class.\\
\item[\textit{Define abstract rule class}] \hfill \\ All rules can inherit from the abstract class.\\
\item[\textit{Trigger mapping }] \hfill \\ Allows that triggers are mapped to the related role's rules.\\
\item[\textit{Role evaluation mechanism}] \hfill \\ The role model is eventually usable for users of groups.\\
\end{description}
\subsection{Command line interface}
\label{subsec:requirements:functional:cli}
Besides an API, a command line interface must give the possibility to execute all tasks as described in \ref{subsec:requirements:functional:systemintegrability}, \ref{subsec:requirements:functional:projectmanagement} and \ref{subsec:requirements:functional:modeling}.
\section{Non-functional requirements}
\label{sec:requirements:nonfunctional}
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 \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 \\ \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.
Also for the applied role module and its role evaluation mechanisms, portability should be possible.
\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 \\ \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}
This diff is collapsed.
%\chapter{Sources}
%TODO This appendix contains important source code snippets.
%\begin{lstlisting}[caption={Lines of code}]
%public class Hello {
% public static void main(String[] args) {
% System.out.println("Hello World");
% }
%}
%\end{lstlisting}
This diff is collapsed.
\NeedsTeXFormat{LaTeX2e}[1994/06/01]
\ProvidesClass{thesis}[2012/04/25 DBIS Thesis Package]
\DeclareOption*{\PassOptionsToClass{\CurrentOption}{scrbook}}
\ExecuteOptions{a4paper,
10pt,
%bibtotoc,
bibliography=totoc,
%liststotoc,
listof=totoc,
twoside,
openright,
%pointlessnumbers,
numbers=noenddot,
%normalheadings,
headings=normal,
chapterprefix, % Display chapters with additional "Chapter" title
headsepline, % Line afer header
DIV=9}
\ProcessOptions\relax
\LoadClass{scrbook}
\pagestyle{headings}
\RequirePackage[english]{babel}
\RequirePackage[utf8]{inputenc}
\RequirePackage[T1]{fontenc}
\RequirePackage{lmodern}
\RequirePackage{microtype}
\renewcommand{\sfdefault}{phv}
\renewcommand{\rmdefault}{phv}
\renewcommand{\ttdefault}{pcr}
\RequirePackage{graphicx}
\graphicspath{{img/}}
\RequirePackage{verbatim}
\RequirePackage{tabularx}
\RequirePackage{url}
\RequirePackage{color}
\RequirePackage{amssymb}
\RequirePackage{setspace}
\RequirePackage{listings}
\RequirePackage{amsmath} %js
\RequirePackage{booktabs} %js
\RequirePackage{multirow} %js
\RequirePackage[left]{eurosym} %js
\RequirePackage{amsthm} %js
\RequirePackage{ragged2e} %js
\RequirePackage{float} %js
\RequirePackage[section]{placeins} %js
\RequirePackage{epigraph} %js
\setlength{\epigraphwidth}{0.4\textwidth}
\RequirePackage{longtable} %js
\RequirePackage[grey,helvetica]{quotchap} %js
\RequirePackage[printonlyused]{acronym} %js
\lstset{language=Java,
showstringspaces=false,
frame=single,
numbers=left,
basicstyle=\ttfamily,
numberstyle=\tiny,
captionpos=b,
}
%js definition-umgebung setzen!
\newtheorem{definition}{Definition}
% js end definition
% put name etc. here
\newcommand{\@fullname}{\null}
\newcommand{\@email}{\null}
\newcommand{\@headline}{\null}
\newcommand{\@titel}{\null}
\newcommand{\@thesisyear}{\null}
\newcommand{\@matnr}{\null}
\newcommand{\@reviewerA}{\null}
\newif\if@reviewerBSet
\@reviewerBSetfalse
\newcommand{\@reviewerB}{\null}
\newif\if@tutorSet
\@tutorSetfalse
\newcommand{\@tutor}{\null}
\newcommand{\@typ}{\null}
\newcommand{\@faculty}{\null}
\newcommand{\@department}{\null}
\newif\if@licenseSet
\@licenseSetfalse
\newcommand{\@license}{\null}
\newcommand{\fullname}[1]{\renewcommand{\@fullname}{#1}}
\newcommand{\email}[1]{\renewcommand{\@email}{#1}}
\newcommand{\headline}[1]{\renewcommand{\@headline}{#1}}
\newcommand{\titel}[1]{\renewcommand{\@titel}{#1}}
\newcommand{\thesisyear}[1]{\renewcommand{\@thesisyear}{#1}}
\newcommand{\matnr}[1]{\renewcommand{\@matnr}{#1}}
\newcommand{\reviewerA}[1]{\renewcommand{\@reviewerA}{#1}}
\newcommand{\reviewerB}[1]{\renewcommand{\@reviewerB}{#1}\@reviewerBSettrue}
\newcommand{\tutor}[1]{\renewcommand{\@tutor}{#1}\@tutorSettrue}
\newcommand{\typ}[1]{\renewcommand{\@typ}{#1}}
\newcommand{\faculty}[1]{\renewcommand{\@faculty}{#1}}
\newcommand{\department}[1]{\renewcommand{\@department}{#1}}
\newcommand{\license}[1]{\renewcommand{\@license}{#1}\@licenseSettrue}
\newcommand{\thefullname}[0]{\@fullname}
\newcommand{\theemail}{\@email}
\newcommand{\theheadline}{\@headline}
\newcommand{\thetitel}{\@titel}
\newcommand{\thejahr}{\@thesisyear}
\newcommand{\thematnr}{\@matnr}
\newcommand{\thereviewerA}{\@reviewerA}
\newcommand{\thereviewerB}{\@reviewerB}
\newcommand{\thebetreuer}{\@tutor}
\newcommand{\thetyp}{\@typ}
\newcommand{\thefaculty}{\@faculty}
\newcommand{\thedepartment}{\@department}
\newcommand{\thelicense}{\@license}
% Colors in tables
\RequirePackage{colortbl}
\definecolor{Gray}{rgb}{0.80784, 0.86667, 0.90196} %darkblue
\definecolor{Lightgray}{rgb}{0.9176, 0.95, 0.95686} %lightblue
\definecolor{Accent}{rgb}{0.6627, 0.63529, 0.55294} %accentcolor
\setlength{\arrayrulewidth}{0.1pt}
\clubpenalty = 10000
\widowpenalty = 10000
\setlength{\parindent}{0pt}
\setlength{\parskip}{1.4ex plus 0.35ex minus 0.3ex}
\setcounter{tocdepth}{1} % table of contents depth
\setcounter{secnumdepth}{2} % Define enumeration of the headline depth
% \pdfinfo{
% /Author (\@fullname)
% /Title (\pdfescapestring{\@titel})
% /Producer (pdfeTex 3.14159-1.30.6-2.2)
% /Keywords (TAGS DEFINIEREN)
% }
\RequirePackage{hyperref}
\hypersetup{%
% pdftitle=\pdfescapestring{\@titel},
% pdfauthor={\@fullname},
% pdfsubject={\@typ},
% pdfproducer={pdfeTex 3.14159-1.30.6-2.2},
colorlinks=false,
pdfborder=0 0 0 % no box surrounding links!
}
\renewcommand{\maketitle}[0]
{
% titelepage
\thispagestyle{empty}
\begin{addmargin*}[4mm]{-32mm}
\includegraphics[height=1.8cm]{img/general/unilogo_bild}
\hfill
\includegraphics[height=1.8cm]{img/general/unilogo_wort}\\[1em]
{\footnotesize
{\bfseries Universität Ulm} \textbar ~89069 Ulm \textbar ~Germany
\hspace*{78.5mm}\parbox[t]{38mm}{\bfseries Faculty of\\
\@faculty\\
\mdseries \@department}\\[2cm]
\parbox{140mm}{\bfseries \huge \@headline}\\[0.5em]
{\footnotesize \@typ at Universität Ulm}\\[3em]
{\footnotesize \bfseries Submitted by:}\\
{\footnotesize \@fullname\\\@email}\\[2em]
{\footnotesize \bfseries Reviewer:}\\
{\footnotesize\@reviewerA
\if@reviewerBSet\\%
\@reviewerB\fi%
}\\[2em]
\if@tutorSet%
{\footnotesize \bfseries Supervisor:}\\
{\footnotesize\@tutor}\\\fi%
\\
{\footnotesize\@thesisyear}
}
\end{addmargin*}
}
\newcommand{\imprint}[0]
{
\thispagestyle{empty}
{ \small
\flushleft
Version from \today \\\vfill
\copyright~\@thesisyear~\@fullname\\[0.5em]
\if@licenseSet
\@license
\fi
}
}
\def\dotfill#1{\cleaders\hbox to #1{.}\hfill}
\newcommand\dotline[2][.5em]{\leavevmode\hbox to #2{\dotfill{#1}\hfil}}
\newcommand{\honestydisclaimer}[0]
{
\thispagestyle{empty}
Name: \thefullname \hfill Matriculation number: \thematnr \vspace{2cm}
\minisec{Honesty disclaimer}
I hereby affirm that I wrote this thesis independently and that I did not use any other
sources or tools than the ones specified. \vspace{2cm}
Ulm, 17.04.2020 \hspace{0.27\textwidth}
\hspace{0.07\textwidth} \includegraphics[width=50mm]{signature} %\dotline{0.6\textwidth}
\hspace{10cm} {\footnotesize \thefullname}
}
\documentclass{article}
\usepackage{geometry}
\geometry{noheadfoot, margin=0.5in}
\usepackage{prerex}
\begin{document}
\thispagestyle{empty}
\begin{chart}
\end{chart}
\end{document}