Updated MG with section 7(Uses Hierarchy) and added hierarchy DAG image

Doc/Design/ModuleGuide.tex

@@ -177,7 +177,7 @@ The following design decisions are unlikely to change because they affect many m
         \midrule
         Behaviour-Hiding Module  & Menu Module, GUI Module\\
         \midrule
-        Software Decision Module & Game State Module\\
+        Software Decision Module & Model Module\\
         \bottomrule
     \end{tabular}
     \caption{Module Hierarchy}
@@ -324,11 +324,12 @@ This section show three traceability matrices outlining the comparison between t
 % =============== Section 7 ===============
 
 \section{Use Hierarchy Between Modules} \label{SecUse}
-In this section, the uses hierarchy between modules is provided. Parnas1978 said of two programs A and B that A {\em uses} B if correct execution of B may be necessary for A to complete the task described in its specification. That is, A {\em uses} B if there exist situations in which the correct functioning of A depends upon the availability of a correct implementation of B.  Figure \ref{FigUH} illustrates the use relation between the modules. It can be seen that the graph is a directed acyclic graph (DAG). Each level of the hierarchy offers a testable and usable subset of the system, and modules in the higher level of the hierarchy are essentially simpler because they use modules from the lower levels.
+
+In this section of the Module Guide, the system has already been decomposed into the desired modular structure and characterized by determining the connection between the initial requirements and anticipated changes to those modules. The uses hierarchy presented in this section compares the independent modules with each other to find the common grounds on which modules uses the instance of another. This practice ensures the correctness of the program when it comes to testing as well as a reference to the integration procedure if the design of the system experiences a major change. For instance, if we model a scenario where Module A uses Module B, then all of the parameters that rely on both module have to be specified to ensure that the valid output of Module B can be efficiently used in Module A to proceed with the execution of the design. This hierarchy also represents the testing environment, as Module A and Module B would first be tested independently then the correlation between the shared parameters of both modules. In theory, Module A would present a similar module entity as it is categorized in the higher level of the hierarchy and relies on Module B on the lower level to provide some set of specified work assignment. The following user hierarchy of the current system is shown in Figure \ref{FigUH}. Notice how the representation is described as a Directed Acyclic Graph, a finite set of modules in phase from the higher levels to the lower levels of the hierarchy with no apparent recurring cycles. Hence the design pattern ensure that the decomposition has been done correctly and the definition of the design can now be distributed amongst the various groups that relate to the context of the Module Guide.
 
 \begin{figure}[H]
     \centering
-    %\includegraphics[width=0.7\textwidth]{UsesHierarchy.png}
+    \includegraphics[width=1.0\textwidth]{MGUsesHierarchy.png}
     \caption{Use hierarchy among modules}
     \label{FigUH}
 \end{figure}