X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=introduction.tex;h=1060cb3fc2976f68bef04afe0c41f7bdd2eaf1e2;hb=96c38eaced38e4a3cb8df44ec54b778a1dc11b24;hp=6ec3e65fce3bf816b74ed8facc627a42510d3769;hpb=dc057560c806a535088e1d9ebdbdd0737467ecc3;p=msc-thesis1617.git diff --git a/introduction.tex b/introduction.tex index 6ec3e65..1060cb3 100644 --- a/introduction.tex +++ b/introduction.tex @@ -1,54 +1,68 @@ \section{Introduction} The \gls{TOP} paradigm and the according \gls{iTasks} implementation offer a -high abstraction level of real life workflow tasks. Through an \gls{EDSL} that -programmers can model workflow tasks. The system will then generate a -multi-user web service. This web service can be accessed through a browser and -used to complete these \glspl{Task}. Familiar workflow patterns like sequence, -parallel and conditional tasks can be modelled. From the \gls{Task} description -the system will generate an multi-user web application for real life tasks. +high abstraction level for real life workflow tasks. These workflow tasks can be +described through an \gls{EDSL} and modeled as \glspl{Task} +From the specification the system will then generate a multi-user web service. +This web service is accessed through a browser and used to complete these +\glspl{Task}. Familiar workflow patterns like sequence, parallel and +conditional tasks can be modelled using combinators. -\gls{iTasks} has been shown to be useful in many fields of operation such as incident -management~\cite{lijnse_top_2013}. Interfaces are automatically generated for -the types of data which makes rapid development possible. However, while the -tasks in the \gls{iTasks} system model after real life workflow tasks the -modelling is very high level. It is difficult to connect actual tasks to the -real tasks and let them interact. A lot of the actual tasks can be -\emph{performed} by small \gls{IoT} devices. Nevertheless, adding such devices -to the current system is difficult to say the least as it was not designed to -cope with these devices. +\gls{iTasks} has been shown to be useful in many fields of operation such as +incident management~\cite{lijnse_top_2013}. Interfaces are automatically +generated for the types of data which makes rapid development possible. +\Glspl{Task} in the \gls{iTasks} system are modelled after real life workflow +tasks but the modelling is applied on a very high level. Therefore it is +difficult to connect \gls{iTasks} tasks to the real world tasks and let them +interact. A lot of the actual tasks can be \emph{performed} by small \gls{IoT} +devices. Nevertheless, adding such devices to the current system is difficult +to say the least as it was not designed to cope with these devices. In the current system such adapters, in principle, can be written as \glspl{SDS}\footnote{Similar as to resources such as time are available in the current \gls{iTasks} implementation} but this requires a very specific -adapter to be written for every device and functionality. Moreover, this does -not allow you to build in logic into the device. A lot of the small \gls{IoT} -devices have limited processing power but can still contain decision making. -Oortgiese et al.\ lifted \gls{iTasks} from a single server model to a -distributed server architecture~\cite{oortgiese_distributed_2017} that is also -runnable on smaller devices like \acrshort{ARM}. However, this is limited to -fairly high performance devices that are equipped with high speed communication -lines. Devices in \gls{IoT} often only have \gls{LTN} communication with low -bandwidth and a very limited amount of processing power and are therefore not -suitable to run an entire \gls{iTasks} core. +adapter to be written for every device and functionality. However, this forces +a fixed logic in the device that is set at compile time. A lot of the small +\gls{IoT} devices have limited processing power but can still contain decision +making. Oortgiese et al.\ lifted \gls{iTasks} from a single server model to a +distributed server architecture that is also runnable on smaller devices like +\acrshort{ARM} devices\cite{oortgiese_distributed_2017}. However, this is +limited to fairly high performance devices that are equipped with high speed +communication channels. Devices in \gls{IoT} often only have \gls{LTN} +communication with low bandwidth and a very limited amount of processing power +and are therefore not suitable to run an entire \gls{iTasks} core. \glspl{mTask} will bridge this gap by introducing a new communication protocol, -device server application and \glspl{Task} synchronizing the formers. +device application and \glspl{Task} synchronizing the formers. The system can run on devices as small as Arduino microcontrollers and operates via the same paradigms and patterns as regular \glspl{Task}. \glspl{mTask} can run small imperative programs written in a \gls{EDSL} and -have access to \glspl{SDS}. +have access to \glspl{SDS}. In this way \glspl{Task} can be sent to the device +at runtime and information can be exchanged. \section{Document structure} The structure of the thesis is as follows. -Chapter~\ref{chp:introduction} contains the problem statement, motivation and -the structure of the document. -Chapter~\ref{chp:methods} describes the foundations on which the implementation -is built together with the new techniques introduced. -Chapter~\ref{chp:results} shows the results in the form of an example -application accompanied with implementation. +Chapter~\ref{chp:introduction} contains the problem statement, motivation, +literature embedding and the structure of the document. +Chapter~\ref{chp:top} introduces the reader to the basics of \gls{TOP} and +\gls{iTasks} +Chapter~\ref{chp:dsl} discusses the pros and cons of different embedding +methods to create \gls{EDSL}. +Chapter~\ref{chp:mtask} shows the existing \gls{mTask}-\gls{EDSL} on which is +extended on in this dissertation. +Chapter~\ref{chp:arch} shows the architecture used for \gls{IoT}-devices that +are a part of the new \gls{mTask}-system. +Chapter~\ref{chp:mtaskcont} shows the extension added to the +\gls{mTask}-\gls{EDSL} that were needed to make the system function. + +\todo{Vul aan} + Chapter~\ref{chp:conclusion} concludes by answering the research questions and discusses future research. Appendix~\ref{app:communication-protocol} shows the concrete protocol used for communicating between the server and client. Appendix~\ref{app:device-interface} shows the concrete interface for the devices. + +\section{Relevant research} +\todo{Hier alle citaten en achtergrond doen} +Ivory, firmata, dsl spul, etc.