Updated Section 1(Introduction) of Module Guide

Doc/Design/DesignDocument.aux

-\relax 
-\providecommand\hyper@newdestlabel[2]{}
-\providecommand\HyperFirstAtBeginDocument{\AtBeginDocument}
-\HyperFirstAtBeginDocument{\ifx\hyper@anchor\@undefined
-\global\let\oldcontentsline\contentsline
-\gdef\contentsline#1#2#3#4{\oldcontentsline{#1}{#2}{#3}}
-\global\let\oldnewlabel\newlabel
-\gdef\newlabel#1#2{\newlabelxx{#1}#2}
-\gdef\newlabelxx#1#2#3#4#5#6{\oldnewlabel{#1}{{#2}{#3}}}
-\AtEndDocument{\ifx\hyper@anchor\@undefined
-\let\contentsline\oldcontentsline
-\let\newlabel\oldnewlabel
-\fi}
-\fi}
-\global\let\hyper@last\relax 
-\gdef\HyperFirstAtBeginDocument#1{#1}
-\providecommand\HyField@AuxAddToFields[1]{}
-\providecommand\HyField@AuxAddToCoFields[2]{}
-\@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces \bf  Revision History}}{i}{table.1}}
-\citation{ParnasEtAl1984}
-\citation{Parnas1972a}
-\citation{ParnasEtAl1984}
-\citation{ParnasEtAl1984}
-\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction}{1}{section.1}}
-\@writefile{toc}{\contentsline {section}{\numberline {2}Anticipated and Unlikely Changes}{2}{section.2}}
-\newlabel{SecChange}{{2}{2}{Anticipated and Unlikely Changes}{section.2}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}Anticipated Changes}{2}{subsection.2.1}}
-\newlabel{SecAchange}{{2.1}{2}{Anticipated Changes}{subsection.2.1}{}}
-\newlabel{acClass}{{1}{2}{\refstepcounter {acnum} \actheacnum :}{acnum.1}{}}
-\newlabel{acWeapon}{{2}{2}{\refstepcounter {acnum} \actheacnum :}{acnum.2}{}}
-\newlabel{acDamageCalculations}{{3}{2}{\refstepcounter {acnum} \actheacnum :}{acnum.3}{}}
-\newlabel{acSprites}{{4}{2}{\refstepcounter {acnum} \actheacnum :}{acnum.4}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {2.2}Unlikely Changes}{2}{subsection.2.2}}
-\newlabel{SecUchange}{{2.2}{2}{Unlikely Changes}{subsection.2.2}{}}
-\newlabel{ucIO}{{1}{2}{\refstepcounter {ucnum} \uctheucnum :}{ucnum.1}{}}
-\newlabel{ucArchitecture}{{2}{2}{\refstepcounter {ucnum} \uctheucnum :}{ucnum.2}{}}
-\newlabel{ucGraph}{{3}{2}{\refstepcounter {ucnum} \uctheucnum :}{ucnum.3}{}}
-\newlabel{ucNodeIdentification}{{4}{2}{\refstepcounter {ucnum} \uctheucnum :}{ucnum.4}{}}
-\newlabel{ucPathfinder}{{5}{2}{\refstepcounter {ucnum} \uctheucnum :}{ucnum.5}{}}
-\@writefile{toc}{\contentsline {section}{\numberline {3}Module Hierarchy}{2}{section.3}}
-\newlabel{SecMH}{{3}{2}{Module Hierarchy}{section.3}{}}
-\citation{ParnasEtAl1984}
-\newlabel{mHH}{{1}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.1}{}}
-\newlabel{mBH}{{2}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.2}{}}
-\newlabel{mSD}{{3}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.3}{}}
-\newlabel{mIF}{{4}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.4}{}}
-\newlabel{mOF}{{5}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.5}{}}
-\newlabel{mM}{{6}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.6}{}}
-\newlabel{mGS}{{7}{3}{\refstepcounter {mnum} \mthemnum :}{mnum.7}{}}
-\@writefile{lot}{\contentsline {table}{\numberline {2}{\ignorespaces Module Hierarchy}}{3}{table.2}}
-\newlabel{TblMH}{{2}{3}{Module Hierarchy}{table.2}{}}
-\@writefile{toc}{\contentsline {section}{\numberline {4}Connection Between Requirements and Design}{3}{section.4}}
-\newlabel{SecConnection}{{4}{3}{Connection Between Requirements and Design}{section.4}{}}
-\@writefile{toc}{\contentsline {section}{\numberline {5}Module Decomposition}{3}{section.5}}
-\newlabel{SecMD}{{5}{3}{Module Decomposition}{section.5}{}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {5.1}Hardware Hiding Module}{4}{subsection.5.1}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {5.2}Behaviour-Hiding Module(M\ref  {mBH})}{4}{subsection.5.2}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.2.1}Input Formatting Module (M\ref  {mIF})}{4}{subsubsection.5.2.1}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.2.2}Output Formatting Module (M\ref  {mOF})}{4}{subsubsection.5.2.2}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.2.3}Model Module (M\ref  {mM})}{4}{subsubsection.5.2.3}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {5.3}Software Decision Module}{5}{subsection.5.3}}
-\@writefile{toc}{\contentsline {subsubsection}{\numberline {5.3.1}Game State Module}{5}{subsubsection.5.3.1}}
-\@writefile{toc}{\contentsline {section}{\numberline {6}Traceability Matrix}{5}{section.6}}
-\newlabel{SecTM}{{6}{5}{Traceability Matrix}{section.6}{}}
-\@writefile{lot}{\contentsline {table}{\numberline {3}{\ignorespaces Trace Between Requirements and Modules}}{5}{table.3}}
-\newlabel{TblRT}{{3}{5}{Trace Between Requirements and Modules}{table.3}{}}
-\citation{Parnas1978}
-\bibstyle{plainnat}
-\bibdata{MG}
-\@writefile{lot}{\contentsline {table}{\numberline {4}{\ignorespaces Trace Between Anticipated Changes and Modules}}{6}{table.4}}
-\newlabel{TblACT}{{4}{6}{Trace Between Anticipated Changes and Modules}{table.4}{}}
-\@writefile{toc}{\contentsline {section}{\numberline {7}Use Hierarchy Between Modules}{6}{section.7}}
-\newlabel{SecUse}{{7}{6}{Use Hierarchy Between Modules}{section.7}{}}
-\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Use hierarchy among modules}}{6}{figure.1}}
-\newlabel{FigUH}{{1}{6}{Use hierarchy among modules}{figure.1}{}}

Doc/Design/DesignDocument.lof

-\contentsline {figure}{\numberline {1}{\ignorespaces Use hierarchy among modules}}{6}{figure.1}

Doc/Design/DesignDocument.lot

-\contentsline {table}{\numberline {1}{\ignorespaces \bf Revision History}}{i}{table.1}
-\contentsline {table}{\numberline {2}{\ignorespaces Module Hierarchy}}{3}{table.2}
-\contentsline {table}{\numberline {3}{\ignorespaces Trace Between Requirements and Modules}}{5}{table.3}
-\contentsline {table}{\numberline {4}{\ignorespaces Trace Between Anticipated Changes and Modules}}{6}{table.4}

Doc/Design/DesignDocument.out

-\BOOKMARK [1][-]{section.1}{Introduction}{}% 1
-\BOOKMARK [1][-]{section.2}{Anticipated and Unlikely Changes}{}% 2
-\BOOKMARK [2][-]{subsection.2.1}{Anticipated Changes}{section.2}% 3
-\BOOKMARK [2][-]{subsection.2.2}{Unlikely Changes}{section.2}% 4
-\BOOKMARK [1][-]{section.3}{Module Hierarchy}{}% 5
-\BOOKMARK [1][-]{section.4}{Connection Between Requirements and Design}{}% 6
-\BOOKMARK [1][-]{section.5}{Module Decomposition}{}% 7
-\BOOKMARK [2][-]{subsection.5.1}{Hardware Hiding Module}{section.5}% 8
-\BOOKMARK [2][-]{subsection.5.2}{Behaviour-Hiding Module\(M2\)}{section.5}% 9
-\BOOKMARK [3][-]{subsubsection.5.2.1}{Input Formatting Module \(M4\)}{subsection.5.2}% 10
-\BOOKMARK [3][-]{subsubsection.5.2.2}{Output Formatting Module \(M5\)}{subsection.5.2}% 11
-\BOOKMARK [3][-]{subsubsection.5.2.3}{Model Module \(M6\)}{subsection.5.2}% 12
-\BOOKMARK [2][-]{subsection.5.3}{Software Decision Module}{section.5}% 13
-\BOOKMARK [3][-]{subsubsection.5.3.1}{Game State Module}{subsection.5.3}% 14
-\BOOKMARK [1][-]{section.6}{Traceability Matrix}{}% 15
-\BOOKMARK [1][-]{section.7}{Use Hierarchy Between Modules}{}% 16

Doc/Design/DesignDocument.tex

@@ -51,50 +51,29 @@ Date 2 & 1.1 & Notes\\
 \newpage
 \pagenumbering{arabic}
 \section{Introduction}
-Decomposing a system into modules is a commonly accepted approach to developing
-software.  A module is a work assignment for a programmer or programming
-team~\citep{ParnasEtAl1984}.  We advocate a decomposition
-based on the principle of information hiding~\citep{Parnas1972a}.  This
-principle supports design for change, because the ``secrets'' that each module
-hides represent likely future changes.  Design for change is valuable in SC,
-where modifications are frequent, especially during initial development as the
-solution space is explored.  
-Our design follows the rules layed out by \citet{ParnasEtAl1984}, as follows:
-\begin{itemize}
-\item System details that are likely to change independently should be the
-  secrets of separate modules.
-\item Each data structure is used in only one module.
-\item Any other program that requires information stored in a module's data
-  structures must obtain it by calling access programs belonging to that module.
-\end{itemize}
-After completing the first stage of the design, the Software Requirements
-Specification (SRS), the Module Guide (MG) is developed~\citep{ParnasEtAl1984}. The MG
-specifies the modular structure of the system and is intended to allow both
-designers and maintainers to easily identify the parts of the software.  The
-potential readers of this document are as follows:
+\subsection{Overview}
+Blaze Brigade is a tactical simulation role-playing game that combines the strategic challenges as a form of interactive entertainment for its users. This turn-based game allows users to advance their units into enemy territory, participate in combat and strive to eliminate all of the opposing units. In adaption to the open-source freeware, Tactics Heroes, Blaze Brigade will incorporate new functional and design enhancements that may not be available to the existing open-source project. Such enhancements include the implementation of new features within the unit movement, combat and strategy aspect of the game as well as improved graphical representations of the menu menu and gameplay to improve the overall experience of the game.
+
+\subsection{Context}
+The system is fully devised and presents all of its functional and non-functional requirements in the Software Requirement Specification (SRS). As these requirements state the desirable properties of the system, the design documents will further evaluate on how these requirements are identified and achieved. The Module Guide (MG) will serve as a tool to decompose the following system into a modular structure adhering to the principle of information hiding. Upon reaching the finalized version of this document, the Module Guide can be distributed amongst various groups in order to learn and identify parts of the software that is being presented. These various groups are as follows:
+
 \begin{itemize}
-\item New project members: This document can be a guide for a new project member
-  to easily understand the overall structure and quickly find the
-  relevant modules they are searching for.
-\item Maintainers: The hierarchical structure of the module guide improves the
-  maintainers' understanding when they need to make changes to the system. It is
-  important for a maintainer to update the relevant sections of the document
-  after changes have been made.
-\item Designers: Once the module guide has been written, it can be used to
-  check for consistency, feasibility and flexibility. Designers can verify the
-  system in various ways, such as consistency among modules, feasibility of the
-  decomposition, and flexibility of the design.
+\item Developers and maintainers: Decomposing the system and documenting into the Module Guide will aid the developers and maintainers to understand the system-as-is and recognize what areas of the software are likely to be changed. In addition, a sense of the overall design will be structured and will be maintained in the following developments phases yet to come.
+\item Designers: In addition to the design pattern being documented, designers are able to determine whether the designs are constructed as initially specified. With the following anticipated changes to be happening, which areas of software is flexible and feasible to accommodate new design changes.
+\item New recruits or outsourced resources: The documentation will onboard the new recruits in familiarizing the overall structure of the implementation adhering to a specific design principle. This will reduce the downtime of debugging and have an advantage of multiple groups working on the system at once. Furthermore, if an external team were to implement the system or would like to carry out further improvements after the project timeline, this document will serve as an aid to determine the existing framework and how further implementation can take place.
 \end{itemize}
-The rest of the document is organized as follows. Section
-\ref{SecChange} lists the anticipated and unlikely changes of the software
-requirements. Section \ref{SecMH} summarizes the module decomposition that
-was constructed according to the likely changes. Section \ref{SecConnection}
-specifies the connections between the software requirements and the
-modules. Section \ref{SecMD} gives a detailed description of the
-modules. Section \ref{SecTM} includes two traceability matrices. One checks
-the completeness of the design against the requirements provided in the SRS. The
-other shows the relation between anticipated changes and the modules. Section
-\ref{SecUse} describes the use relation between modules.
+
+\noindent
+In addition to the Module Guide, the Module Interface Specification (MIS) is also a product of the design documentation. The specification defines the syntax and semantics that are associated with the functions provided in the source code. Tools like Doxygen have been utilized to generate a set of documentation that will indicate the characteristics of the functions in terms of the corresponding inputs, outputs, assumptions, exceptions, state and environment variables. These characteristics will further aid in observing how the implementation is taken place and how the design constitutes from these functions.
+
+\subsection{Design Principle}
+The design principle taken into consideration revolves around the decomposition of the overall system into a modular structure of subsystems. These subsystems are observed in an abstract manner, hiding any details that may complicate the process. This act of information hiding and encapsulation ensures that each modules hides some design aspect from the rest of the system and analyzing which areas are expected to change. This process plans for the following subsystems to be changed, hence protecting other subsystems of the software from major changes if the design decision is changed.
+
+\subsection{Outline}
+The Module Guide is organized in the given order. Section \ref{SecChange} lists the anticipated and unlikely changes of the software requirements. Section \ref{SecMH} decomposes the system into a module hierarchy of the likely changes. Section \ref{SecConnection} establishes the connection between the software requirements with the modules. Section \ref{SecMD} gives a detailed insight on how the modules have been decomposed with their corresponding descriptions. Section \ref{SecTM} includes two traceability matrices comparing the modules with the software requirements and anticipated changes. At last, section \ref{SecUse} pinpoints the use hierarchy between the modules.
+
+\newpage
+
 
 \section{Anticipated and Unlikely Changes} \label{SecChange}
 This section identifies possible changes to the software system. These changes to the design choices are organized into two categories. Anticipated changes, and unlikely changes. Anticipated changes are listed in Section \ref{SecAchange}, and the unlikely changes are listed in Section \ref{SecUchange}.

Doc/Design/DesignDocument.toc

-\contentsline {section}{\numberline {1}Introduction}{1}{section.1}
-\contentsline {section}{\numberline {2}Anticipated and Unlikely Changes}{2}{section.2}
-\contentsline {subsection}{\numberline {2.1}Anticipated Changes}{2}{subsection.2.1}
-\contentsline {subsection}{\numberline {2.2}Unlikely Changes}{2}{subsection.2.2}
-\contentsline {section}{\numberline {3}Module Hierarchy}{2}{section.3}
-\contentsline {section}{\numberline {4}Connection Between Requirements and Design}{3}{section.4}
-\contentsline {section}{\numberline {5}Module Decomposition}{3}{section.5}
-\contentsline {subsection}{\numberline {5.1}Hardware Hiding Module}{4}{subsection.5.1}
-\contentsline {subsection}{\numberline {5.2}Behaviour-Hiding Module(M\ref {mBH})}{4}{subsection.5.2}
-\contentsline {subsubsection}{\numberline {5.2.1}Input Formatting Module (M\ref {mIF})}{4}{subsubsection.5.2.1}
-\contentsline {subsubsection}{\numberline {5.2.2}Output Formatting Module (M\ref {mOF})}{4}{subsubsection.5.2.2}
-\contentsline {subsubsection}{\numberline {5.2.3}Model Module (M\ref {mM})}{4}{subsubsection.5.2.3}
-\contentsline {subsection}{\numberline {5.3}Software Decision Module}{5}{subsection.5.3}
-\contentsline {subsubsection}{\numberline {5.3.1}Game State Module}{5}{subsubsection.5.3.1}
-\contentsline {section}{\numberline {6}Traceability Matrix}{5}{section.6}
-\contentsline {section}{\numberline {7}Use Hierarchy Between Modules}{6}{section.7}