mirror of
https://github.com/smyalygames/checklist-tester.git
synced 2025-05-18 14:34:12 +02:00
66 lines
2.8 KiB
TeX
66 lines
2.8 KiB
TeX
\documentclass[../dissertation.tex]{subfiles}
|
|
|
|
\begin{document}
|
|
\section{Solution Stack}
|
|
\begin{itemize}
|
|
\item There would be around 3 main components to this tester
|
|
\begin{itemize}
|
|
\item Formal Model
|
|
\item Flight Simulator plugin
|
|
\item Checklist Tester (to connect the formal model and flight simulator)
|
|
\end{itemize}
|
|
\item As VDM-SL is being used, it uses VDMJ to parse the model~\cite{vdmj}. This was a starting
|
|
point for the tech stack, as VDMJ is also open source.
|
|
\item VDMJ uses Java, therefore my language of choice was a language related to Java.
|
|
\end{itemize}
|
|
|
|
\subsection{Formal Model}
|
|
\begin{itemize}
|
|
\item There were a few ways of implementing the formal model into another application
|
|
\item Some of these methods were provided by Overture~\cite{overture-remote}
|
|
\begin{itemize}
|
|
\item RemoteControl interface
|
|
\item VDMTools API~\cite{vdmtoolbox-api}
|
|
\end{itemize}
|
|
\item However, both of these methods did not suit what was required as most of the
|
|
documentation for RemoteControl was designed for the Overture Tool IDE. VDMTools
|
|
may have handled the formal model differently
|
|
\item The choice was to create a VDMJ wrapper, as the modules are available on Maven
|
|
\end{itemize}
|
|
|
|
\subsection{Checklist Tester}
|
|
\begin{itemize}
|
|
\item VDMJ uses Java, meaning the logical choice would be to use something with Java
|
|
\item As the tester is going to include a UI, the language choice was still important
|
|
\item Kotlin~\cite{kotlin} was the choice in the end as Google has been putting Kotlin first
|
|
compared to Java, it includes less boilerplate code (e.g. getters and setters)~\cite{android-kotlin}
|
|
\item There are a variety of GUI libraries to consider using
|
|
\begin{itemize}
|
|
\item JavaFX~\cite{javafx}
|
|
\item Swing~\cite{flatlaf}
|
|
\item Compose Multiplatform~\cite{compose}
|
|
\end{itemize}
|
|
\item The decision was to use Compose Multiplatform in the end, due to time limitations and
|
|
having prior experience in using Flutter~\cite{flutter}
|
|
\item Compose Multiplatform has the ability to create a desktop application and a server,
|
|
which would allow for leeway if a server would be needed
|
|
\end{itemize}
|
|
|
|
\subsection{Flight Simulator Plugin}
|
|
\begin{itemize}
|
|
\item There are two main choices for flight simulators that can be used
|
|
for professional simulation
|
|
\begin{itemize}
|
|
\item X-Plane~\cite{x-plane}
|
|
\item Prepar3D~\cite{p3d}
|
|
\end{itemize}
|
|
\item X-Plane was the choice due to having better documentation for the SDK, and a variety
|
|
of development libraries for the simulator itself
|
|
\item For the plugin itself, there was already a solution developed by NASA, X-Plane Connect~\cite{xpc}
|
|
that is more appropriate due to the time limitations and would be more likely to be reliable
|
|
as it has been developed since 2015
|
|
\end{itemize}
|
|
|
|
|
|
\end{document}
|