update presentation, the body is there

[msc-thesis1617.git] / arch.tex

diff --git a/arch.tex b/arch.tex
index 3e1ea9f..2f30b25 100644 (file)
--- a/arch.tex
+++ b/arch.tex
@@ -1,37 +1,16 @@
-The goal of the system as a whole is to offer a framework of functions with
-which an \gls{iTasks}-system can add, change and remove devices at runtime.
-Moreover, the \gls{iTasks}-system can send \gls{mTask}-\glspl{Task} ---
-compiled at runtime to bytecode by the \gls{mTask}-view --- to the device. The
-device runs an interpreter which can execute the \gls{Task}'s bytecode. Device
-profiles should be persistent during reboots of the \gls{iTasks}-system. The
-methods of interacting with \gls{mTask}-\gls{Task} should be analogous to
-interacting with \gls{iTasks}-\glspl{Task}. This means that programmers can
-access the \glspl{SDS} made for a device in the same way as regular \glspl{SDS}
-and they can execute \gls{mTask}-\glspl{Task} as if they where normal
-\gls{iTasks}-\glspl{Task}.
-
-The following terms will be used throughout the following chapter:
-\begin{itemize}
-       \item Device, Client
-
-               These terms denotes the actual device connected to the system. This can
-               be a real device such as a microcontroller but it can also just be a
-               program on the same machine as the server functioning as a client.
-       \item Server, \gls{iTasks}-System
-
-               This is the actual executable serving the \gls{iTasks} application. The
-               system contains \glspl{Task} taking care of the communication with the
-               clients.
-       \item System
-
-               The system describes the complete ecosystem, containing both the server
-               and the clients including the communication between them.
-       \item Engine
-
-               The runtime system of the client is called the engine. This program
-               handles communicating with the server and runs the interpreter for the
-               \glspl{Task} on the client.
-\end{itemize}
+The system provides a framework of functions with which an \gls{iTasks}-system
+can add, change and remove devices at runtime.  Moreover, the
+\gls{iTasks}-system can send \gls{mTask}-\glspl{Task} --- compiled at runtime
+to bytecode by the \gls{mTask}-view --- to the device. The device runs an
+interpreter which executes the \gls{Task}'s bytecode following the provided
+scheduling strategy. Devices added to the system are stored and get a profile
+for identification. These profiles are persistent during reboots of the
+\gls{iTasks}-system to allow for easy reconnecting with old devices. The way of
+interacting with \gls{mTask}-\glspl{Task} is analogous to interacting with
+\gls{iTasks}-\glspl{Task}. This means that programmers can access the
+\glspl{SDS} made for a device in the same way as regular \glspl{SDS} and they
+can execute, combine and transform \gls{mTask}-\glspl{Task} as if they where
+normal \gls{iTasks}-\glspl{Task}.
 
 \section{Devices}
 \input{arch.devices}
@@ -39,12 +18,8 @@ The following terms will be used throughout the following chapter:
 \section{iTasks}
 \input{arch.itasks}
 
-\section{Communication}
+\section{Communication}\label{sec:communication}
 \input{arch.communication}
 
-\section[Lifting mTasks to iTasks-Tasks]%
-       {Lifting \gls{mTask}-\glspl{Task} to \gls{iTasks}-\glspl{Task}}
-\input{arch.lift}
-
-\section{Example}
+\section{Example}\label{sec:archexamples}
 \input{arch.example}