wörk

ThesTeX/content/3-solution.tex

@@ -42,7 +42,7 @@ The default Kibana worchbench does not qualify for this, a custom interface coul
 \image{\textwidth}{../../PresTeX/images/kibana2}{Game trace in Kibana}{img:kibana2}
 
 
-\section{Architecture}
+\section{Architectural Design}
 
 \subsection{Overview}
 Based on the learnings above, a custom stack seems like a feasible alternative:
@@ -61,12 +61,13 @@ The already mentioned interfaces (Web and CLI/API) for both target groups are th
 The analysis framework.
 \image{\textwidth}{solution.pdf}{Architecture approach}{img:solution}
 
+The following sections describe each of those components.
 \subsection{Analysis Framework}
 
 The analysis framework takes game logs, processes their entries, collects results, and renders them to an output.
 \autoref{img:flow} shows the data flows through the framework.
 Every processed log file has its own analysis chain.
-The log entries are fed sequentionally into the analysis chain.
+The log entries are fed sequentially into the analysis chain.
 \image{\textwidth}{map-reduce.pdf}{Data flows}{img:flow}
 
 \subsubsection{Analyzer}
@@ -85,20 +86,42 @@ A consumed log entry is not passed down the analysis chain anymore.
 This can be useful to filter verbose logs before computationally expensive operations.
 
 \subsubsection{Result}
+When all entries of a game log have been processed, the results of each analyzer are collected.
+Each result is linked to the analyzer which has produced this artifact to avoid ambiguous data sets.
 
-\subsubsection{Render}
-
-
-\subsection{Interfaces}
-The interfaces are rather straightforward:
-Users select game logs for processing, choose which analyzing methods shall be applied, and finally set a rendering target.
-
-
+\subsubsection{Postprocessing \& Render}
+When all game logs are processed, the whole result set is passed into the Postprocessing step.
+This is the first step to compare multiple game logs, i.e. the results of the analyzed game logs, directly.
+
+Postprocessing is a hard requirement for rendering the results, as at least a transformation into the desired format is absolutley necessary.
+Rendering is not restricted to visualizations, artifacts of all kind can be produced.
+A whole range from static plots and CSV exports to structured JSON data for interactive map visualizations is possible.
+
+\subsubsection{Log parser}
+Key to the framework described above is a component to import game log data, parse it, and prepare it to a common format for processing.
+
+\subsection{Web Interface}
+The web interface is rather straightforward:
+Expert users prepare a set of analysis methods and bundle them with suitable rendering targets to an analysis suit.
+Non-expert users select game logs for processing, choose a prepared analysis suit, and receive a rendered result once the analysis process has finished.
+
+\subsection{CLI/API Interface}
+Providing insight access to analysis and render classes, the CLI/API interface offers the most powerful way to explore the log data.
+By implementing custom algorithms, expert users can cope with difficult input formats and special requirements.
 
 
+\subsection{Architecture}
 
+The API is a standalone microservice.
+It is independent of both game servers and user interfaces.
 
+Separation from game servers narrows the scope, and allows the usage with any kind of game.
+Games without central server can provide a mocked server to supply logged data, while games with server can e.g. expose API endpoints with authentication and user management.
+By acting like any normal client, the framework can avoid obstacles like CORS/XSS prevention.
 
+The independence to user interfaces, mainly the web interface, allows scalability through load-balancing with mulitple API workers.
+Expert users with special requirements can embed the framework in projects without pulling in large amounts of dependencies.
+\begin{comment}
 
 
 \subsection{old}
@@ -129,4 +152,4 @@ Game independance:
 	\item API for integration
 	\item allow load distribution
 \end{itemize}
-\image{\textwidth}{architecture.pdf}{archoitecure overview}{img:arch}
+\end{comment}

ThesTeX/content/4-implementation.tex

@@ -2,6 +2,8 @@
 \section{konfigurierbarkeit (log import)}
 \section{...}
 
+\image{\textwidth}{architecture.pdf}{archoitecure overview}{img:arch}
+
 \section{1. vortrag}
 
 \section{Outlook: Implementation}