checklist-tester/pub/dissertation/chapters/design.tex

\documentclass[../dissertation.tex]{subfiles}

\begin{document}
%%%%% COMPONENTS %%%%%
\section{Components}

Splitting up the project into multiple components has been useful for
\begin{itemize}
  \item Aiding in planning to make the implementation more efficient
  \item Delegating specific work tasks
  \item Making the project modular, for example, allowing for a different simulator
    to be implemented with minimal need to refactor other parts of the codebase
\end{itemize}

\begin{figure}[!h]
\centering
  \begin{tikzpicture} [align=center, node distance=4cm]
    \node (connector) [box] {Checklist Tester};
    \node (plugin) [box, right of=connector] {Simulator Connector Plugin};
    \node (formal) [box, left of=connector] {Formal Method};
    \node (simulator) [box, below=0.75cm of plugin] {Flight Simulator};
  
    \draw [arrow] (formal) -- (connector);
    \draw [arrow] (plugin) -- (connector);
    \draw [arrow] (plugin) -- (simulator);
  \end{tikzpicture}
  \label{fig:abstract}
  \caption{Abstract layout of components}
\end{figure}

Each of the components in Figure~\ref{fig:abstract} will be covered in detail in this
chapter.


%%%%% FORMAL METHOD %%%%%
\section{Formal Method}
\begin{itemize}
  \item Formal modelling is the heart of the logic for testing checklists
  \item Formal model created using VDM-SL
  \item It allows to test that the checklists have been completed in a proper manner
    - and that it is provable
  \item Model keeps track of
    \begin{itemize}
      \item Aircraft state
      \item Checklist state
    \end{itemize}
  \item If an error were to occur in the model, this can be relayed that there was
    something wrong with running the test for the checklist, such as:
    \begin{itemize}
      \item Procedure compromises integrity of aircraft
      \item There is not enough time to complete the procedure
      \item There is a contradiction with the steps of the checklist
    \end{itemize}
\end{itemize}


%%%%% CHECKLIST TESTER %%%%%
\section{Checklist Tester}
Brief overview of what it is supposed to do... % TODO

\subsection{Designing}
\begin{itemize}
  \item Used Figma to create a design for the application
  \item Allows for implementing the front end to be faster because:
    \begin{itemize}
      \item They act as a requirement for code
      \item You do not forget what needs to be implemented
      \item Keeps everything consistent
      \item Allows to think about making parts of the GUI modular and what components can be reused
    \end{itemize}
  \item Figma allows for plugins such as Material 3 colours and Material 3 components
  \item Figure~\ref{fig:figma-gui} is the final design that will be used for the
    program
\end{itemize}

\begin{figure}
  \centering
  \includegraphics[width=\columnwidth]{images/figma-gui.pdf}
  \caption[GUI in Figma]{Design for the Checklist Connector GUI in Figma}
  \label{fig:figma-gui}
\end{figure}

\subsubsection{Limitations of Figma}
\begin{itemize}
  \item The Material 3 Components in Figma do not include features that are available in
    Jetpack Compose
  \item In this project, the \enquote{Simulator Test} at the bottom of Figure~\ref{fig:figma-gui}
    does not include a leading icon~\cite{material:lists}, and therefore had to be a trailing
    checkbox
  \item This was overcome by adding comments in Figma as a reminder of how the actual implementation
    should be like
  \item Another limitation is that in Figure~\ref{fig:figma-gui}, the title of the screen in the
    top app bar~\cite{material:top-app-bar} is not centered, and that is because the auto layout
    feature in Figma allows for equal spacing, rather than having each in a set position
\end{itemize}


\subsection{Compose Multiplatform}


\subsection{Storing Data}


\subsection{VDMJ Wrapper}


% Talk about how XPC was used here, not how it was implemented
\subsection{Connecting to the Flight Simulator}


\subsection{Testing}




%%%%% Simulator Connector Plugin %%%%%
\section{Simulator Connector Plugin}
% Talk about creating your own (originally happened) vs using something else that was developed
% Maybe talk about original plan? i.e. <project root>/plugin


\subsection{Creating Maven Package}
% Gradle
% Testing
% GitHub CI
\begin{itemize}
  \item XPC package is not published on a public Maven repository
  \item There has been a pull request that was merged to the \textit{develop} branch
    that provides Maven POMs~\cite{xpc:pom}. However, the maintainer for the
    project, at the time, did not have enough time to figure out the process of
    publishing the package to a Maven repository~\cite{xpc:pom-time}
  \item Therefore, had to find an alternative way to implement
  \item Jitpack~\cite{jitpack}
  \begin{itemize}
    \item In theory, simple to publish a repository, all that is required is a GitHub
      repository and searching if one has already been created on JitPack or build and publish
      a specific version
    \item However, due to the structure of the XPC repository, JitPack could not locate the
      build tools (Apache Maven in this case) as JitPack only searches on the root directory
      for the compatible build tools
  \end{itemize}
  \item Gradle gitRepository~\cite{gradle:gitRepository}
  \begin{itemize}
    \item There was not a lot of documentation
    \item Ambiguous on how to define directory for where the Java library is located in the Git repository
    \item However, as XPC was only built with Maven, Gradle was not able add the dependency as \verb|gitRepository()|
      only works with Gradle builds~\cite{gradle:gitRepoGradleOnly}
  \end{itemize}
\item Resorted to using a compiled Jar file and adding the dependency to Gradle
\item Not happy about that because it means maintaining it will be more difficult as
  it is not as simple as just changing the version number
\item Later, resorted to adding Gradle build files to XPC
\item Used automatic conversion from Maven to Gradle using \verb|gradle init| command~\cite{gradle:migratePOM}
\item Had to add local dependencies due to how Gradle works differently
\item Had to fix previous structure of Maven POM as the grouping as not good
\end{itemize}


\subsection{Submitting a Pull Request}
% What I did:
% - gitignore
% - changing url for repo
% - testing everything still worked




%%%%% SCENARIOS %%%%%
\section{Scenarios}
\begin{itemize}
  \item Use a Quick Reference Handbook (QRH) to find potential list of checklists to test
  % TODO find these accident reports
  \item Look at previous accident reports that had an incident related to checklists
    and test it with my tool to see if it will pick it up
  \item These previous accident reports can be good metrics to know what statistics to
    look out for
\end{itemize}


%%%%% DECISIONS %%%%%
\section{Decisions}
\end{document}