diff --git a/Doc/Design/ModuleGuide.pdf b/Doc/Design/ModuleGuide.pdf
index d7ff3fe5648053732d499e15365f662db3b7d4d2..48e9f30dc247704a2945ce570a4e7ec8a3c953d4 100644
Binary files a/Doc/Design/ModuleGuide.pdf and b/Doc/Design/ModuleGuide.pdf differ
diff --git a/Doc/Design/ModuleGuide.synctex.gz b/Doc/Design/ModuleGuide.synctex.gz
index 11ddc8887e29ff56ab7c4c890e87d5fac4e54620..36ca9e61f107b359b3c9fb4f0d47ea6cf8bd1aa9 100644
Binary files a/Doc/Design/ModuleGuide.synctex.gz and b/Doc/Design/ModuleGuide.synctex.gz differ
diff --git a/Doc/Design/ModuleGuide.tex b/Doc/Design/ModuleGuide.tex
index 933f8fda1b4672734c55c6452fb60cebbcce8a47..e201274b01ce7334148f9fcfa820c895daabafa6 100644
--- a/Doc/Design/ModuleGuide.tex
+++ b/Doc/Design/ModuleGuide.tex
@@ -76,10 +76,10 @@
\section{Introduction}
-\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{Summary of Project}
+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 on the existing open-source project. Such enhancements include the implementation of new features within the unit movement, combat and strategy aspects 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}
+\subsection{Context of Module Guide}
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}
@@ -92,10 +92,41 @@ The system is fully devised and presents all of its functional and non-functiona
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.
+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 analyzes which areas are expected to change. Hence, this document follows a design for change pattern and will be in the best interest throughout all of the subsystems presented in the system. For instance, the anticipated changes within the system would have been encapsulated in this process to ensure that any further changes to the design does not disrupt the main design interface of the system. As a principle for the decomposition into modular structure, the instance of low coupling is desired as the result is given as independent modules. In the same respect, high cohesion within the modules is highly desired since the elements of the module are strongly related to the module's characteristics. Therefore, this process is motivated around the concept of design for change as an exercise and validation to protect other modules of the system if any major changes occur in the overall design.
-\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.
+\subsection{Outline of Module Guide}
+The Module Guide is organized in the given order. Section \ref{SecChange} lists all of the anticipated and unlikely changes that the software system might contain. Section \ref{SecMH} decomposes the system into a list of modules into the module hierarchy. 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 three traceability matrices comparing the modules with the software requirements and anticipated changes as referenced earlier in Section \ref{SecConnection}. At last, section \ref{SecUse} pinpoints the use hierarchy between the modules initialized to establish connection between the independent modules.
+
+\subsection{Definitions, Acronyms, Abbreviations, Symbols}
+The following definitions and symbols are defined in Table \ref{TblDFN} and will be referenced throughout the remainder of the Module Guide.
+\begin{table}[H]
+ \centering
+ \begin{tabular}{p{0.4\textwidth} p{0.4\textwidth}}
+ \toprule
+ \textbf{Symbol} & \textbf{Description} \\
+ \midrule
+ SRS & Software Requirements Specification document\\
+ \midrule
+ MG & Module Guide document\\
+ \midrule
+ MIS & Module Interface Specification document\\
+ \midrule
+ Module & A decomposed subsystem of the overall software system\\
+ \midrule
+ AC & Anticipated Changes\\
+ \midrule
+ UC & Unlikely Changes\\
+ \midrule
+ MVC & Model-View-Controller\\
+ \midrule
+ FR & Functional Requirements\\
+ \midrule
+ NFR & Non-Functional Requirements\\
+ \bottomrule
+ \end{tabular}
+ \caption{List of Definitions, Acronyms, Abbreviations and Symbols}
+ \label{TblDFN}
+\end{table}
% =============== Section 2 ===============
@@ -134,7 +165,6 @@ The following design decisions are unlikely to change because they affect many m
\item [\refstepcounter{mnum} \mthemnum \label{mIF}:] Menu Module
\item [\refstepcounter{mnum} \mthemnum \label{mOF}:] Model Module
\item [\refstepcounter{mnum} \mthemnum \label{mM}:] GUI Module
- Module
\end{description}
\begin{table}[H]
@@ -160,9 +190,10 @@ Since Blaze-Brigade consists of purely software, M1 does not apply to the system
\section{Connection Between Requirements and Design} \label{SecConnection}
-The design of the system is intended to satisfy the requirements developed in
-the SRS. In this stage, the system is decomposed into modules. The connection
-between requirements and modules is listed in Table \ref{TblRT} and Table \ref{TblNFRT}.
+The system is intended to satisfy all of the functional and nonfunctional requirements that were initially specified in the SRS. In this section, the system is decomposed into modules and assess the connections between the decomposed requirements with the corresponding requirements. These are shown in the Table \ref{TblRT} and Table \ref{TblNFRT} under Section \ref{SecTM}.
+
+\hfill\break
+Most of the requirements can be categorized as one of the modules provided in the Module Hierarchy. For instance, the Menu Model extends through all of the requirements that initiate the menu option in one way or another. The model module encapsulate the model classes that represent the structure of the source code. The GUI module is primarily what users get to see as a final product which includes various parameters within the game. The design decisions that are needed to accommodate these requirements heavily rely on the main function criteria that the system holds. For instance, the appearance requirements specify the look and feel that the user should be expecting from the product and heavily focuses on the menu and GUI aspect. These modules initialized will cover those aspects and model this case scenario is such a manner that each module or submodules will be independent and protected if there is design change in the other part of the system.
% =============== Section 5 ===============
@@ -232,8 +263,7 @@ Module Decomposition summary TODO \\
\section{Traceability Matrix} \label{SecTM}
-This section shows two traceability matrices: between the modules and the
-requirements and between the modules and the anticipated changes.
+This section show three traceability matrices outlining the comparison between the modules with either the functional requirements, non-functional requirements and anticipated changes.
% the table should use mref, the requirements should be named, use something
% like fref
@@ -244,11 +274,11 @@ requirements and between the modules and the anticipated changes.
\toprule
\textbf{Req.} & \textbf{Modules}\\
\midrule
- FR1 & \mref{mHH}, \mref{mIF}, \mref{mOF}\\
- FR2 & \mref{mM}, \mref{mGS}\\
- FR3 & \mref{mIF}, \mref{mOF}\\
- FR4 & \mref{mIF}, \mref{mOF}, \mref{mM}\\
- FR5 & \mref{mM}\\
+ FR1 & \mref{mHH}, \mref{mIF}, \mref{mM}\\
+ FR2 & \mref{mBH}, \mref{mOF}\\
+ FR3 & \mref{mOF}, \mref{mM}\\
+ FR4 & \mref{mSD}, \mref{mOF}, \mref{mM}\\
+ FR5 & \mref{mOF}\\
\bottomrule
\end{tabular}
\caption{Trace Between Functional Requirements and Modules}
@@ -261,13 +291,13 @@ requirements and between the modules and the anticipated changes.
\toprule
\textbf{Req.} & \textbf{Modules}\\
\midrule
- NFR1 & \mref{mHH}, \mref{mBH}, \mref{mOF}\\
- NFR2 & \mref{mSD}, \mref{mIF}\\
+ NFR1 & \mref{mHH}, \mref{mBH}, \mref{mM}\\
+ NFR2 & \mref{mSD}, \mref{mOF}\\
NFR3 & \mref{mSD}, \mref{mM}\\
- NFR4 & \mref{mSD}, \mref{mM}\\
- NFR5 & \mref{mSD}, \mref{mM}, \mref{mGS}\\
+ NFR4 & \mref{mHH}, \mref{mSD}\\
+ NFR5 & \mref{mSD}, \mref{mOF}, \mref{mM}\\
NFR6 & \mref{mHH}, \mref{mBH}\\
- NFR7 & \mref{mOF}\\
+ NFR7 & \mref{mM}\\
NFR8 & \mref{mHH}, \mref{mSD}\\
\bottomrule
\end{tabular}
@@ -281,10 +311,10 @@ requirements and between the modules and the anticipated changes.
\toprule
\textbf{AC} & \textbf{Modules}\\
\midrule
- \acref{acClass} & \mref{mBH}, \mref{mM}, \mref{mGS}\\
- \acref{acWeapon} & \mref{mM}, \mref{mGS}\\
- \acref{acDamageCalculations} & \mref{mGS}\\
- \acref{acSprites} & \mref{mOF}\\
+ \acref{acClass} & \mref{mBH}, \mref{mSD}, \mref{mOF}\\
+ \acref{acWeapon} & \mref{mIF}, \mref{mOF}\\
+ \acref{acDamageCalculations} & \mref{mOF}\\
+ \acref{acSprites} & \mref{mM}\\
\bottomrule
\end{tabular}
\caption{Trace Between Anticipated Changes and Modules}