Cleaing up L13 to reflect what was actually covered.

Lectures/L13_ModuleDecomposition/ModuleDecomposition.tex

@@ -339,252 +339,6 @@ r^{+} M_j$$
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
-\begin{frame}
-\frametitle{DAG Versus Tree}
-
-Is a DAG a tree?  Is a tree a DAG?
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{DAG Versus Tree}
-
-Would you prefer your uses relation is a tree?
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{The USES Relation}
-
-\begin{itemize}
-\item A uses B
-\begin{itemize}
-\item A requires the correct operation of B
-\item A can access the services exported by B through its interface
-\item This relation is ``statically'' defined
-\item A depends on B to provide its services
-\item For instance, A calls a routine exported by B
-\end{itemize}
-\item A is a client of B; B is a server
-\item Inheritance, Association and Aggregation imply Uses 
-\end{itemize}
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Desirable Properties}
-
-\begin{itemize}
-\item USES should be a hierarchy
-\begin{itemize}
-\item Hierarchy makes software easier to understand
-\item We can proceed from the leaf nodes (nodes that do not use other nodes)
-  upwards
-\item They make software easier to build
-\item They make software easier to test
-\end{itemize}
-\item Low coupling
-\item Fan-in is considered better than Fan-out: \structure{WHY?}
-\end{itemize}
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Hierarchy}
-
-\begin{itemize}
-\item Organizes the modular structure through \structure{levels of abstraction}
-\item Each level defines an \structure{abstract (virtual) machine} for the next level
-\item Level can be defined precisely
-\begin{itemize}
-\item $M_i$ has level $0$ if no $M_j$ exists such that $M_i r M_j$
-\item Let $k$ be the maximum level of all nodes $M_j$ such that $M_i r M_j$, then $M_i$ has level $k+1$
-\end{itemize}
-\end{itemize}
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Module Decomposition (Parnas)}
-
-\begin{center}
-\includegraphics[width=1.0\textwidth]{ParnasDecompBySecrets.png}
-\end{center}
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Module Decomposition (Parnas)}
-
-Does the module decomposition on the previous slide show a Uses relation?  Is it
-a DAG?  Is it a tree?
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{IS\_COMPONENT\_OF}
-
-\begin{itemize}
-\item The Parnas decomposition by secrets gives an IS\_COMPONENT\_OF relationship
-\item Used to describe a higher level module as constituted by a number of lower level modules
-\item A IS\_COMPONENT\_OF B means B consists of several modules of which one is A
-\item B COMPRISES A
-\item $M_{S,i} = \{ M_k | M_k \in S \wedge M_k \mbox{ IS\_COMPONENT\_OF } M_i \}$ we say that $M_{S,i}$ IMPLEMENTS
-$M_i$ 
-\item \structure{How is IS\_COMPONENT\_OF represented in UML?}
-\end{itemize}
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{A Graphical View}
-
-\begin{center}
-\includegraphics[width=1.0\textwidth]{GraphViewOf_IS_COMPONENT_OF.png}
-\end{center}
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Product Families}
-
-\begin{itemize}
-\item Careful recording of (hierarchical) USES relation and IS\_COMPONENT\_OF supports design of program families
-\item Attempt to recognize modules that will differ in implementation between family members
-\item New program family member should start at the documentation of the design, not with the code
-\end{itemize}
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Remember - Information Hiding}
-
-\begin{itemize}
-\item Basis for design (i.e.\ module decomposition)
-\item Implementation secrets are hidden to clients
-\item They can be changed freely if the change does not affect the interface
-\item \structure{Try to encapsulate changeable requirements and design decisions as implementation secrets within module
-implementations}
-\item Decomposition by secrets, not by sequence of steps
-\end{itemize}
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Prototyping}
-
-\begin{itemize}
-\item Once an interface is defined, implementation can be done
-\begin{itemize}
-\item First quickly but inefficiently
-\item Then progressively turned into the final version
-\end{itemize}
-\item Initial version acts as a prototype that evolves into the final product
-\end{itemize}
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Module Guide}
-
-\begin{itemize}
-\item Part of Parnas' Rational Design Process (RDP)
-\item When decomposing the system into modules, we need to document the module decomposition so that developers and
-other readers can understand and verify the decomposition
-\item Parnas proposed a Module Guide (MG) based on the decomposition module tree shown earlier
-\end{itemize}
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{RDP - MG}
-
-\begin{itemize}
-\item The MG consists of a table that documents each module's service and secret
-\item Conceptual modules will have broader responsibilities and secrets
-\item Following a particular branch, the secrets at lower levels ``sum up'' to
-  the secret at higher levels
-\item The leaf modules that represent code will contain much more precise
-  services and secrets
-\item Only the leaf modules are actually implemented
-\item The MG should list the likely and unlikely changes on which the design is based
-\end{itemize}
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Example}
-
-%\vspace{-1.5cm}
-\begin{center}
-\includegraphics[width=0.5\textwidth]{DecompBySecretHierarchyExample.png}
-\end{center}
-
-\href{https://gitlab.cas.mcmaster.ca/smiths/se2aa4_cs2me3/blob/master/Lectures/L13_ModuleDecomposition/DecompBySecretHierarchyExample.png}{Link}
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Module Details}
-\begin{itemize}
-\item For each module
-\item Module name
-\item Secret (informal description)
-\item Service or responsibility (informal description)
-\item For ``leaf'' modules add
-\begin{itemize}
-\item Associated requirement
-\item Anticipated change
-\item Module prefix
-\end{itemize}
-\end{itemize}
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{RDP - MIS}
-
-\begin{itemize}
-\item For each leaf module we need to document its interface and its implementation
-\item In RDP, the interfaces are documented in the Module Interface Specification (MIS)
-\item We have already seen MIS examples specified as Module State Machines
-\end{itemize}
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
 \begin{frame}
 \frametitle{References}