Commit 1a9f4d38 authored by Sandro Eiler's avatar Sandro Eiler 🐌

Added content to thesis.

parent fb00fb68
......@@ -4,11 +4,8 @@
%TODO bei requirementes + principles Beispiele nennen oder referenzieren
%TODO Design vs architecture
Within this chapter, the presented requirements and principles are used to develop a design for tools and frameworks.
This design intends to enable role model creation as well as a role evaluation mechanism.
%TODO The ideas behind and how it is supposed to be done
%TODO guck, wo karmantra kursiv ist und wo nicht
Within this chapter, requirements (system integrability, project management, role modeling, ci) from Chapter \ref{cha:requirements} and principles which are presented in Chapter \ref{cha:fundamentals}, are used to develop a design for tools and frameworks.
This design intends to enable role model creation as well as a role evaluation mechanism. The design is used to specify an architecture whose implementation is described in Chapter \ref{cha:implementation}.
\section{DevOps}
\label{sec:design:devops}
......@@ -36,13 +33,13 @@ This design intends to enable role model creation as well as a role evaluation m
\item rule-based role evaluation
\end{enumerate}
The mentioned advantage of a high level of automation can be optimized with this differentiation.
Following flows make clear, how the two provisioning domains are applied.
The mentioned advantage of a high level of automation can be optimized with this differentiation between modeling and evaluation.
In the following sections flows are described for the DevUser, the target system and the tools, that are used for role modeling and role evaluation. These flows make clear, how the two provisioning domains \textit{role modeling} and \textit{role evaluations} are applied.
\subsection{Modeling}
\label{subsec:design:application:modeling}
Creating, modifying or removing a role model includes one to two steps for the DevUser which is demonstrated in Figure \ref{fig:application-modeling-flow}.
Creating, modifying or removing a role model includes the steps \textit{role model deployment} (including the integration into the target system) and \textit{rule implementation} for the DevUser which is abstractly demonstrated in Figure \ref{fig:application-modeling-flow}.
\begin{figure}[htp]
\begin{center}
......@@ -62,16 +59,16 @@ This design intends to enable role model creation as well as a role evaluation m
\item[role's evaluation behaviour] [optional] \\ \hfill If a role's behavior has to be adjusted, its inherited functions can be overwritten. A DevUser might e.g., like to order rules that are about to be checked in a specific order.
\end{description}
The so far described components, namely the role model and the role evaluation mechanism are tied together as importable module and deployed into the target system. The DevUser of course has to import this module in the correct locations.
The components which are mentioned earlier in this chapter, namely the \textit{role model} and the \textit{role evaluation mechanism} are tied together as importable module and deployed into the target system. The DevUser of course has to import this module in the correct locations.
To minimize the DevUser's costs of time and implementation complexity, all components within the importable framework can easily be prepared with templates, that just have to be filled with missing code.
It is indispensable that the DevUser has to contribute some code. Because the modeling tool has to deal with arbitrary systems, it is not possible to generate code for all existing possibilities.
How the role evaluation import module has to work, is described in \ref{subsec:design:application:eval} below.
It is indispensable that the DevUser has to contribute some code. Because the modeling tool has to deal with arbitrary systems, it is not possible to generate code for all existing possibilities of target systems.
The next section \ref{subsec:design:application:eval} describes how the role evaluation import module has to work.
\subsection{Role evaluation}
\label{subsec:design:application:eval}
Before describing how the role evaluation mechanisms are designed, basic assumptions are given on how a role model is defined.
Before describing (in section \textit{Mechanism}) how the role evaluation mechanisms are designed, basic assumptions are given (in section \textit{Role model elements}) on how a role model is defined.
\subsubsection{Role model elements}
\label{subsubsec:design:application:eval:modelelements}
......@@ -85,11 +82,14 @@ This design intends to enable role model creation as well as a role evaluation m
\item a trigger can be mapped to multiple rules
\end{itemize}
With these definitions we can also describe dependencies between roles indirectly: The dependency of one role to another can be defined as a rule.
The question remains whether we can model relations between roles. E.g., hierarchical roles have to be used.
With the definitions above we can also describe dependencies between roles indirectly: The dependency of one role to another can be defined as a rule.
\subsubsection{Mechanism}
\label{subsec:design:application:eval:trigger}
To explain the role evaluation mechanism, the role evaluation import module's overall behavior is described from the target system's perspective first. Second, the internal view is explained.
The role evaluation mechanism is started whenever a trigger in the system is fired. Figure \ref{fig:application-evaluation-flow} shows the flow of a role evaluation mechanism.
\begin{figure}[htp]
......@@ -119,13 +119,13 @@ This design intends to enable role model creation as well as a role evaluation m
\end{enumerate}
This design earmarks that all of a role's rules are checked, even if only one of its rules is connected to a trigger. The reason is that there may exist rules without connected triggers and that a system might want to inform users or the system provider exactly about which rules recently do or do not apply.
In the following sections it will become more clear, how all these principles and definitions can be included into the design of a tool.
In the following sections it will become more clear, how all these principles and definitions can be included into a tool's architecture.
\section{Data model}
\label{sec:design:datamodel}
Referring to the objectives that are derived from our DevOps considerations (in \ref{sec:design:devops}), an approach with multiple layers is designed as shown in \ref{subsec:design:datamodel:layers}.
Referring to the objectives (automation, improving interaction of development and deployment and providing better connection possibilities for people) that are derived from our DevOps considerations (in \ref{sec:design:devops}), an approach with multiple layers is designed as shown in \ref{subsec:design:datamodel:layers}.
All following descriptions are implemented for \textit{karmantra} which is explained in detail within Chapter \ref{cha:implementation}.
\subsection{Implementation layers}
......@@ -154,7 +154,7 @@ This design intends to enable role model creation as well as a role evaluation m
\item[Role Model Import Module] \hfill \\ Static files and templates for the deployment of the role model import module (explained below) depending on the DevUser's stated context.
\end{description}
The white boxes represent classes, that don't implement functional requirements directly and adapt to the layer's needs. They can be seen as support classes. The main layers (blue) are more likely to experience an evolution or even a replacement. The command line interface is not part of the importable python module which contains all functional behavior. Figure \ref{fig:class-diagram} shows the class diagram for \textit{karmantra}.
The boxes \textit{Configuration}, \textit{Logging} and \textit{Helper} (white) represent classes, that don't implement functional requirements directly and adapt to the layer's needs. They can be seen as support classes. The main layers (blue) \textit{CLI}, \textit{Core}, \textit{Modeler} and \textit{Role Model Import Module} are more likely to experience an evolution or even a replacement. The command line interface is not part of the importable python module which contains all functional behavior. Figure \ref{fig:class-diagram} shows the class diagram for \textit{karmantra}.
\begin{figure}[htp]
\begin{center}
......
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