JPT
/
bachelorthesis
0
0
Fork 0
Code Issues Pull Requests Activity

[TASK] Generic commit.

This commit is contained in:
Jan Philipp Timme 2016-10-10 10:27:48 +02:00
parent e144ad0179
commit 1db548e249
1 changed files with 33 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
Bachelorarbeit.tex
View File

@ -994,24 +994,44 @@ Hat man auf diese Weise einen Query an der Engine registriert, so muss als näch
Die Details der technischen Implementierung von Reasoning in der C-SPARQL-Engine können in \cite{barbieri:reasoning} nachgelesen werden. Weiterführend kann über die Umsetzung von Reasoning mit Complex Event Processing in der Masterarbeit von Stefan Lier\cite{hsh:reasoning} gelesen werden. Die Details der technischen Implementierung von Reasoning in der C-SPARQL-Engine können in \cite{barbieri:reasoning} nachgelesen werden. Weiterführend kann über die Umsetzung von Reasoning mit Complex Event Processing in der Masterarbeit von Stefan Lier\cite{hsh:reasoning} gelesen werden.
\chapter{Umsetzung des Beispielszenarios}\label{cpt:csparql_in_practice} \chapter{Umsetzung des Beispielszenarios}\label{cpt:csparql_in_practice}
Nachdem die Umsetzung von CEP-Regeln in C-SPARQL im vorherigen Kapitel erläutert wurde, soll nun das in Kapitel~\ref{cpt:scenario} angerissene Beispielszenario der Autoverleihgesellschaft umgesetzt werden. Ausgangspunkt hierfür sind zwei gegebene RDF-Ereignisdatenströme:
\todo{Zusammenfassungsüberleitung über das Kapitel} \paragraph{Ereignisstrom der PKW}
Dieser Ereignisdatenstrom übermittelt alle Ereignisse, die von den PKW aus dem Fuhrpark der Verleihgesellschaft ausgehen. Jedes einzelne Ereignis bezieht sich dabei auf einen konkreten PKW. Die folgenden Ereignistypen werden durch den Datenstrom übermittelt:
\todo{In diesem Kapitel wird die Engine konkret ausgepackt und mit Java-Code benutzt. Es werden Datenstromgeneratoren gezeigt, Queries registriert und vielleicht etwas Reasoning eingeschaltet und dessen Ergebnisse begutachtet.}
In diesem Kapitel wird die C-SPARQL-Engine konkret vorgestellt und verwendet um das Beispielszenario aus Kapitel~\ref{cpt:scenario} umzusetzen. Dafür werden die Anforderungen des Szenarios einzeln betrachtet, die Ereignisdatenströme und der ganze Kram, der da mit dranhängt um dann eine Lösung zu konzipieren und implementieren.
\begin{itemize} \begin{itemize}
\item RDF-Datenströme \item \textbf{\texttt{CarStatusEvent}}: Wird von jedem PKW in regelmäßigen Abständen ausgelöst und übermittelt ein Paket von Statuswerten. Neben dem Attribut \texttt{relatedCar}, welches auf den jeweiligen PKW verweist, werden die Attribute \texttt{motorOn}, \texttt{motorRPM}, \texttt{speed}, \texttt{handbrakeEngaged}, \texttt{locked} und \texttt{tirePressure\{1-4\}} für die Beschreibung der Statuswerte verwendet. Da dieses der Ereignistyp mit den meisten Attributen ist, wird im Folgenden ein Beispiel für eine solche Ereignisinstanz gezeigt:
\item Beispielszenario \begin{lstlisting}
\item Umsetzung mit C-SPARQL :event rdf:type car:CarStatusEvent .
\item Nötiger Code für das Grundsetup der Engine, Generatoren und co :event car:relatedCar :someCar .
\item Konkreter Blick auf die CSPARQL-Queries :event car:motorOn true^^xsd:boolean .
\item Ergebnisse der Abfragen :event car:motorRPM 1821^^xsd:integer .
:event car:speed 25^^xsd:integer .
:event car:handbrakeEngaged false^^xsd:boolean .
:event car:locked false^^xsd:boolean .
:event car:tirePressure1 29^^xsd:integer .
:event car:tirePressure2 28^^xsd:integer .
:event car:tirePressure3 30^^xsd:integer .
:event car:tirePressure4 29^^xsd:integer .
\end{lstlisting}
\item \textbf{\texttt{CarLockEvent} und \texttt{CarUnlockEvent}}: Sobald ein Fahrer den PKW auf- oder abschließt, wird jeweils ein \texttt{CarLockEvent} beziehungsweise \texttt{CarUnlockEvent} ausgelöst. Dieses enthält lediglich eine Angabe des betroffenen PKW über das Attribut \texttt{relatedCar}.
\item \textbf{\texttt{CarHandbrakeEngageEvent} und \texttt{CarHandbrakeReleaseEvent}}: Wird die Handbremse angezogen oder gelöst, so löst der PKW ein entsprechendes Ereignis vom Typ \texttt{CarHandbrakeEngageEvent} beziehungsweise \texttt{CarHandbrakeReleaseEvent} aus. Diese enthalten nur die Angabe des PKW über das Attribut \texttt{relatedCar}.
\item \textbf{\texttt{CarCheckEngineEvent}}: Sollte die Bordelektronik eines PKW eine Fehlermeldung auslösen, so wird diese mit einem \texttt{CarCheckEngineEvent} angezeigt. Hierbei wird der betroffene PKW über \texttt{relatedCar} angegeben.
\item \textbf{\texttt{CarAirbagTriggeredEvent}}: Wurde an einem PKW der Airbag ausgelöst, so wird ein Ereignis dieses Typen ausgelöst, um auf diesen Umstand aufmerksam zu machen. Auch hier wird lediglich der PKW über \texttt{relatedCar} angegeben.
\end{itemize} \end{itemize}
\paragraph{DriverStream}
Die Ereignisse in diesem Datenstrom beziehen sich ausschließlich auf Interaktionen von Kunden mit den PKW. Somit werden durh diesen Ereignisdatenstrom nur Ereignisse dieser zwei Typen übertragen:
\begin{itemize}
\item \texttt{CarTakenEvent}: Wird ausgelöst, wenn ein Kunde einen PKW ausleiht. Ein solches Ereignis verweist über \texttt{relatedCar} auf den geliehenen PKW und über \texttt{relatedUser} auf den entsprechenden Kunden.
\item \texttt{CarReturnedEvent}: Analog zum Ereignistypen \texttt{CarTakenEvent} wird dieses Ereignis ausgelöst, wenn ein Kunde sein geliehenes Fahrzeug wieder zurückgibt. Ebenso wie das \texttt{CarTakenEvent} wird über \texttt{relatedCar} auf den entsprechenden PKW verwiesen und über \texttt{relatedUser} auf den Kunden.
\end{itemize}
\section{Umsetzung der Anforderungen}
Um diese Ereignisdatenströme nun zu Verarbeiten, werden die Anforderungen des Szenarios aus Kapitel~\ref{cpt:scenario} zunächst genauer betrachtet und CEP-Regeln für sie formuliert.
\section{Nutzung der C-SPARQL Engine in Java} \section{Nutzung der C-SPARQL Engine in Java}