%\documentclass[handout]{beamer} 
\documentclass[t,12pt,numbers,fleqn]{beamer}
%\documentclass[ignorenonframetext]{beamer}

\newif\ifquestions
%\questionstrue
\questionsfalse

\usepackage{pgfpages} 
\usepackage{hyperref}
\hypersetup{colorlinks=true,
    linkcolor=blue,
    citecolor=blue,
    filecolor=blue,
    urlcolor=blue,
    unicode=false}
\urlstyle{same}

\usepackage{booktabs}
\usepackage{multirow}

\bibliographystyle{plain}

%\usetheme{Iimenau}

\useoutertheme{split} %so the footline can be seen, without needing pgfpages

%\pgfpagesuselayout{resize to}[letterpaper,border shrink=5mm,landscape]  %if this is uncommented, the hyperref links do not work

\mode<presentation>{}

\input{../def-beamer}

\newcommand{\topic}{Modular Design}

\input{../titlepage}

\begin{document}

\input{../footline}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Modular Design}

\bi
\item Administrative details
\item Feedback on SRS documents
\item Questions?
%\item Feedback on issues
\item Overview of design
\item Modular decomposition: advantages, guidelines etc.
\item Module guide
\item Module guide example
\ei
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Administrative Details}

\bi
\item For the design documentation you do not have to use the MG and 
MIS templates
\item No lecture on Friday, March 21
%\item GitHub issues
%\bi
% \item When closing issues give the hash for the corresponding commit
% \item Everyone should have an issue to review my comments on their SRS or CA
% \ei
% \item VnV GitHub issues for colleagues as for SRS
% \bi
% \item Provide at least 5 issues on their VnV Plan
% \item Grading as before
% \item Create issues within 2 days of being assigned the task by the project's author
% \ei
% \item Template for MG and MIS available in repo
% \item Some edits to the SRS template and FAQ (see diffs)
%\item Optional presentation slots available - first come first served
%\item Grading scheme for VnV now available on Avenue
%\item Template for MG updated in repo
\ei

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\input{../Deadlines.tex}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \begin{frame}
% \frametitle{Feedback on SRS}
% \begin{itemize}
% \item
% \href{https://github.com/smiths/capTemplate/blob/main/docs/Checklists/SRS-Checklist.pdf}
% {SRS checklist}
% \begin{itemize}
%   \item Follow the template
%   \item Filename for SRS from template (new)
%   \item All symbols are in the table of contents
%   \item Project is given a name
%   \item Characteristics with courses and level (clarified)
%   \item Goal statements are functional (new)
%   \item Each assumption is used at least once
%   \item All chunks are used at least once (new)
%   \item IMs are referenced by requirements
% \end{itemize}
% \end{itemize}
% \end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% \begin{frame}
% \frametitle{Feedback on SRS}
% \begin{itemize}
% \item
% \href{https://github.com/smiths/capTemplate/blob/main/docs/Checklists/Writing-Checklist.pdf}
% {Writing checklist}
% \begin{itemize}
%   \item Opening and closing ``quotes''
%   \item Periods that do not end sentences are followed by only one space
%   \item Long names in math mode use either mathit or text
%   \item Document is spell checked
%   \item Symbols formatted the same way in every context %inside and outside equations
% \end{itemize}
% \item Types information very helpful
% \end{itemize}
% \end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{SRS + VnV Issues --- (Mostly) Doing a great job!}
\begin{itemize}
\item Be sure to do your GitHub reviews!
\item Close issues when they are resolved
\bi
\item Explain why closing the issue
\bi
\item Maybe you will just address the issue in a comment
\item Maybe the issue will lead to repo changes
\ei
\item Include the commit hash (you just need the number)
\item Small, well-defined, commits
\item Link to other issues using hash symbol
\ei
\item Take and give feedback in the collegial spirit, use emojis as appropriate
%\item If your project doesn't have a name, give it one
\end{itemize}
\end{frame}

% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Questions?}
\begin{itemize}
\item \structure{Questions?}
\end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% \begin{frame}
% \frametitle{Feedback on SRS}
% \begin{itemize}
% \item Overall well done!
% \item Don't need padding (\textbf{Watch for MG!})
% \bi
% \item Don't make more complicated than it is
% \item Don't add assumptions that the data will be in the correct format, or of
%   the correct type 
% \ei
% \item For the characteristics of intended reader try to be more specific about
%   the education.  What degree?  What course areas?  What level?
% \item If you have a reference by entry, then the referenced by chunk (or its
%   derivation) should actually reference the chunk that has it as an entry.
% \item Functional requirements should reference the instance models
% \item Add more for nonfunctional requirements
% \item Introduce type information when it will help clarify spec
% \end{itemize}
% \end{frame}

% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% \begin{frame}[fragile]
% \frametitle{LaTeX Related Feedback}
% \bi
% \item The text is better for version control, and for reading in other editors,
%   if you use a hard-wrap at 80 characters
% \item Use \verb|``quote''| to get correct quotation marks
% \item Spell check!
% \item Check for extra and missing spaces
% \item LaTeX often inserts two spaces after a period, use \verb|Dr.\ Jeckyl| or
%   \verb|Dr.~Jeckyl|
% \item For $ABC_{Average}$ in an equation use
%   \verb|$\mathit{ABC}_{\text{Average}}$| ($\mathit{ABC}_{\text{Average}}$)
% \item Use BibTeX.  You should mention the source of the
%   template~\cite{SmithAndLai2005, SmithEtAl2007} 
% \item Cite all sources!
% \ei
% \end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}

\frametitle{Review of our ``Faked'' Rational Design Process}

\begin{center}
\includegraphics[scale=0.55]{../Figures/VModelOfProcessXOut.pdf}
\end{center}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Our Goals for Design Overview}

\begin{itemize}
  \item Handle complexity and size by decomposing a complex system into parts
  (modules, units, objects, ...)
  \item Decomposition should be based on a principle -- we'll emphasize information hiding
  \item Uses relation between parts should be a hierarchy
  \item Document the interface for all modules
  \begin{itemize}
    \item Access programs (methods)
    \item Inputs and outputs and their type
    \item State variables (instance variables)
    \item Syntax and semantics
    \item Environment variables
  \end{itemize}
  \item Use abstraction to make the specification more general, and easier
  \item Formal specification where possible
  \item Input-Calculate-Output pattern
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{SWHS MG Example}
~\\

\href{https://github.com/smiths/swhs/blob/master/docs/Design/MG/PCM_MG.pdf} {Module Guide for Solare Water Heating System Incorporating Phase Change Material (PCM)} 

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle{What is Design?}
\begin{itemize}
\item Your requirements document identifies ``What,'' now we begin to look at ``How''
\item Your system should meet both your functional and nonfunctional requirements
\item There is no unique ``optimal'' design
\begin{itemize}
\item Different goals will lead to different designs
\item There is a mix of art and science in design
\item Even with fully formal requirements specification there does not yet exist
  a systematic way to obtain a design
\item Favour art in some areas and favour science in others
\end{itemize}
\end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{What is Design Continued?}

\begin{itemize}

\item Provides structure to any artifact
\item Decomposes system into parts, assigns responsibilities, ensures that parts
  fit together to achieve a global goal
\item Design refers to
\bi
\item Activity
\bi
\item Bridge between requirements and implementation
\item Structure to an artifact
\ei
\item Result of the activity
\bi
\item System decomposition into modules (module guide)
\item Module interface specification (MIS)
\ei
\end{itemize}
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Why Decompose Into Modules?}

\begin{itemize}
\item Separation of concerns
\item Cannot understand all of the details
\item All engineering fields use decomposition
\item Modules will act as ``work assignments''
\item Decomposition needs to follow a systematic procedure (as for SRS)
\item Need to ensure that modules when fit together achieve our global goals
\item Document in a Software Design Document (Module Guide)
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Benefits of Modularity}
\begin{itemize}
\item Shorter development time
\item Improved verification
\item Reduced maintenance costs
\item Easier to understand
\begin{itemize}
\item Small modules
\item An abstract interface
\end{itemize}
\item Modules can be developed independently
\item Modules can be tested independently
\item Modules can be reused
\item Software is easy to change, extend, maintain
\item This requires identifying the anticipated changes in the design and in the requirements
\end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Two Important Goals for Decomposition}

\begin{itemize}

\item Design for change (Parnas) \cite{Parnas1972a, Parnas1974}
\bi
\item Designers tend to concentrate on current needs
\item Special effort needed to anticipate likely changes
\item Changes can be in the design or in the requirements
\item Too expensive to design for all changes, but should design for likely
  changes
\ei
\item Product families (Parnas) \cite{Parnas1976, Parnas1979}
\bi
\item Think of the current system under design as a member of a program family
\item Analogous to product lines in other engineering disciplines
\item Example product families include automobiles, cell phones, etc.
\item Design the whole family as one system, not each individual family member
  separately 
\ei
\end{itemize}

Use Design Principle of Information Hiding

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Sample Likely Changes}

What are some examples of likely changes for software?

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%7

\begin{frame}
\frametitle{Sample Likely Changes \cite{GhezziEtAl2003}}

\begin{itemize}

\item Algorithms -- like replacing inefficient sorting algorithm with a more
  efficient one
\item Change of data representation
\bi
\item From binary tree to threaded tree
\item Array implementation to a pointer implementation
\item Approx.\ 17\% of maintenance costs attributed to data representation
  changes (Lientz and Swanson, 1980)
\ei
\item Change of underlying abstract machine
\bi
\item New release of operating system
\item New optimizing compiler
\item New version of DBMS
\item etc.
\ei
\item Change of peripheral devices

\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Binary Tree to Threaded Tree}

%\vspace{-2cm}
\begin{center}
\includegraphics[width=1.1\textwidth]{../Figures/BinTreeToThreadTree.png}
\end{center}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Sample Likely Changes}

\begin{itemize}

\item Change of ``social'' environment
\bi
\item Corresponds to requirements changes
\item New tax regime
\item EURO versus national currency in EU
\item New language for user interface
\item y2k
\ei
\item Change due to development process (prototype transformed into product)

\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Components of a Module}

\begin{itemize}

\item A software modules has two components
\begin{enumerate}
\item An \structure{interface} that enables the module's clients to use the
  service the module provides
\item An \structure{implementation} of the interface that provides the services
  offered by the module
\end{enumerate}

\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{The Module Interface}

\begin{itemize}

\item A module's interface can be viewed in various ways
\begin{itemize}
\item As a \structure{set of services}
\item As a \structure{contract} between the module and its clients
\item As a \structure{language} for using the module's services
\end{itemize}
\item The interface is \structure{exported} by the module and
  \structure{imported} by the module's clients
\item An interface describes the \structure{data} and \structure{procedures}
  that provide access to the services of the module

\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{The Module Implementation}

\begin{itemize}

\item A module's implementation is an implementation of the module's interface
\item The implementation is \structure{hidden} from other modules
\item The interface data and procedures are implemented together and may share
  data structures
\item The implementation may utilize the services offered by other modules

\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Information Hiding}

\begin{itemize}

\item Made explicit by Parnas \cite{Parnas1972a}
\item Basis for design (that is modular decomposition (Module Guide))
\item Implementation secrets are hidden to clients
\item Secret can be changed freely if the change does not affect the interface
\item \structure{Try to encapsulate changeable design decisions as
    implementation secrets within module implementations}

\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% \begin{frame}
% \frametitle{Specific Techniques for Design for Change}

% What software tool would you use if you wanted to select at build time between
% two implementations of a module, each distinguished by a different decision for
% their shared secret?

% \end{frame}

% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% \begin{frame}
% \frametitle{Specific Techniques for Design for Change}

% \begin{itemize}
% \item Anticipate definition of all family members
% \item Identify what is common to all family members, delay decisions that
%   differentiate among different members
% \item Configuration constants
% \begin{itemize}
% \item Factor constant values into symbolic constants
% \item Compile time binding
% \item MAXSPEED = 5600
% \end{itemize}
% \item Conditional compilation
% \bi
% \item Compile time binding
% \item Works well when there is a preprocessor, like for C
% \item If performance is not a concern, can often ``fake it'' at run time
% \ei
% \item Make
% \item Software generation
% \bi
% \item Compiler generator, like \texttt{yacc}
% \item Domain Specific Language
% \ei
% \end{itemize}

% \end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Questions}

\begin{itemize}
\item \structure{What relationships are there between modules?}
\item \structure{Are there desirable properties for these relations?}
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Relationships Between Modules \cite{GhezziEtAl2003}}

\begin{itemize}
\item Let $S$ be a set of modules
$$ S = \{ M_1, M_2, ..., M_n \}$$
\item A binary relation $r$ on $S$ is a subset of $S \times S$
\item If $M_i$ and $M_j$ are in $S$, $< M_i, M_j > \in r$ can be written as $M_i r M_j$
\end{itemize} 

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Relations}

\begin{itemize}
\item Transitive closure $r^{+}$ of $r$
$$M_i r^{+} M_j \mbox{ iff } M_i r M_j \mbox{ or } \exists M_k \mbox{ in } S \mbox{ such that } M_i r M_k \mbox{ and } M_k
r^{+} M_j$$
\item $r$ is a hierarchy iff there are no two elements $M_i$, $M_j$ such that
  $M_i r^{+} M_j \wedge M_j r^{+} M_i$
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Relations Continued}

\begin{itemize}
\item Relations can be represented as graphs
\item A hierarchy is a DAG (Directed Acyclic Graph)
\end{itemize}

\begin{center}
\includegraphics[width=1.0\textwidth]{../Figures/GraphAndDAG.png}
\end{center}

\structure{Why do we prefer the uses relation to be a DAG?}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Desirable Properties}

\begin{itemize}
\item USES should be a hierarchy \cite{Parnas1974}
\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{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{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{Static Definition of Uses Relation}

Your program has code like:\\
\texttt{if cond then ServiceFromMod1 else ServiceFromMod2}\\
~\newline
This is the only place where each module is used.  Does this mean the uses
relation depends on the dynamic execution of the program?
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Question about Association and DAG}

\structure{Is the uses relation here a DAG?}\\

\begin{figure}
\includegraphics[scale=0.6]{../Figures/UML_Association.png}
\end{figure}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Module Decomposition (Parnas)}

\begin{center}
\includegraphics[width=1.0\textwidth]{../Figures/ParnasDecompBySecrets.png}
\end{center}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Module Decomposition (Parnas)}

For the module decomposition on the previous slide:

\begin{itemize}
\item Does it show a Uses relation?  
\item Is it a DAG?  
\item Is it a tree?
\end{itemize}

\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]{../Figures/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{Parnas's Rational Design Process (RDP)}

% \begin{itemize}
% \item SRS
% \item MG
% \item Uses Hierarchy (updated after writing MISes)
% \item For each module
% \begin{itemize} 
% \item MIS
% \item MID (we will not emphasize this document)
% \end{itemize}
% \item Implementation
% \item Testing
% \item Very successfully used on projects such as 
% \begin{itemize}
% \item The Darlington Nuclear Reactor shutdown system
% \item The A7-E fighter jet
% \end{itemize}
% \end{itemize}

% \end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Module Guide \cite{ParnasEtAl1984}}

\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 Helps future maintainers find appropriate module
\item Parnas proposed a Module Guide (MG) based on the decomposition module tree
  shown earlier
\item Decomposition is usually three to five levels deep
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Three Top Conceptual Modules in an RDP MG}

\structure{What are the three groups of modules in a typical information-hiding
  decomposition?}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Module Decomposition (Parnas)}

\begin{center}
\includegraphics[width=1.0\textwidth]{../Figures/ParnasDecompBySecrets.png}
\end{center}

\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{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 (optional)
\end{itemize}
\end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{RDP - MG}

\begin{itemize}
\item Criteria for a good secret
\begin{itemize}
\item One module one secret, especially for leaf modules (watch for ``and'')
\item Secrets should often be nouns (data structure, algorithm, hardware, ...)
\item Secrets are often phrased as ``How to ... ''
\end{itemize}
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Good Secret?}

\structure{Is the following a good module secret: ``The file format for the map and the
rules for validating that the map satisfies the environmental constraints.''}

%No - more than one secret
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Typical Modules \cite{HoffmanAndStrooper1995}}

\begin{itemize}
\item \structure{What are the typical secrets for an input variable?}
\bi
\item You have an input in the environment, how to get it into your system?
\item What format is the input data?
\ei
\item \structure{What are the secrets for an output variable?}
\bi
\item How to get an output from inside the system to the external environment?
\item How will the output be determined?
\item What format will the output have?
\ei
\item \structure{What are the secrets for a state variable?}
\bi
\item What rules are there governing the state transitions?
\item What data structures or algorithms are needed?
\ei
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Typical Modules \cite{HoffmanAndStrooper1995}}

\begin{itemize}
\item Input variables
\bi
\item Machine-hiding from hardware or OS service
\item Behaviour-hiding input format
\ei
\item Output variables
\bi
\item Machine-hiding
\item Behaviour-hiding output format
\item Behaviour-hiding (calculation)
\ei
\item State variables
\bi
\item Software decision hiding for data structure/algorithm
\item Behaviour-hiding state-drive
\ei
\item Judgement is critical
\item Often combine variables into the same module
\item For non-embedded systems, machine hiding for input-output is often
  combined
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{RDP - Views}

\begin{itemize}
\item As well as the MG, the modular decomposition should be displayed using a
  variety of views
\item An obvious one is the \structure{Uses Hierarchy}
\item The Uses Hierarchy is updated once the MIS for all modules is complete
\item The Uses Hierarchy can be represented 
\begin{itemize} 
\item Graphically (if it isn't too large and complex)
\item Using a binary matrix -- \structure{What would the binary matrix look like?}
\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{RDP - MID}

% \begin{itemize}
% \item Another document that is often helpful is the Module Internal Design (MID)
%   for each module
% \item The MID provides the implementation of the module; that is, it shows how
%   we will deliver on what is promised in the MIS
% \item The MID is requirements for the code represented at a higher level of
%   abstraction than the code
% \item The MID uses the syntax of the selected programming language
% \item The MID shows decisions like whether to use a static array, or dynamic
%   memory allocation and pointers
% \item We will not focus on MIDs, since for many examples it is feasible to go
%   directly to code
% \end{itemize}

% \end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{MG Template}

\bi
\item Table of contents
\item Introduction
\item Anticipated and unlikely changes
\item Module hierarchy
\item Connection between requirements and design
\item Module decomposition
\bi
\item Hardware hiding modules
\item Behaviour hiding modules
\item Software decision hiding modules
\ei
\item Traceability matrices
\item Uses hierarchy between modules
\ei

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Traceability Matrices}
\begin{itemize}
\item Traceability matrix help inspect the design
\item Check for completeness, look at from a different viewpoint
\end{itemize}
\begin{table}[H]
\centering
\begin{tabular}{p{0.2\textwidth} p{0.6\textwidth}}
\toprule
\textbf{Req.} & \textbf{Modules}\\
\midrule
R1 & M1, M2, M3, M7\\
R2 & M2, M3\\
...& ...\\
\bottomrule
\end{tabular}
\end{table}

\begin{table}[H]
\centering
\begin{tabular}{p{0.2\textwidth} p{0.6\textwidth}}
\toprule
\textbf{AC} & \textbf{Modules}\\
\midrule
AC1 & M1\\
AC2 & M2\\
... & ...\\
\bottomrule
\end{tabular}
\end{table}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Verification}

\bi
\item Well formed (consistent format/structure)
\bi
\item Follows template
\item Follows rules (one secret per module, nouns etc.)
\ei
\item Feasible (implementable at reasonable cost)
\bi
\item Difficult to assess
\item Try sketches of MIS
\ei
\item Flexible
\bi
\item Again try sketches of MIS
\item Thought experiment as if likely change has occurred
\item Low coupling
\item Encapsulate repetitive tasks
\ei
\item May sometimes have to sacrifice information hiding
\ei

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Object Oriented Design Versus Modular Design}
\begin{itemize}
\item OO-design and OO-languages are different
\item OO-design
\begin{itemize}
\item Classes and methods
\item Classes are like modules (state variables and access functions (methods))
\item An object is an instance of a class
\item Polymorphism
\item Inheritance - use carefully
\end{itemize}
\item Implementation of modules using an OO-lang is natural
\end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Examples of Modules \cite{GhezziEtAl2003}}

\begin{itemize}

\item \structure{Record}
\begin{itemize}
\item Consists of only data
\item Has state but no behaviour
\end{itemize}
\item \structure{Collection of related procedures (library)}
\begin{itemize}
\item Has behaviour but no state
\item Procedural abstractions
% like many routines in a scientific computing library
\end{itemize}
\item \structure{Abstract object}
\begin{itemize}
\item Consists of data (\structure{fields}) and procedures (\structure{methods})
\item Consists of a collection of \structure{constructors},
  \structure{selectors}, and \structure{mutators}
\item Has state and behaviour
\end{itemize}
\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Examples of Modules Continued}

\begin{itemize}

\item \structure{Abstract data type (ADT)}
\begin{itemize}
\item Consists of a collection of abstract objects and a collection of
  procedures that can be applied to them
\item Defines the set of possible values for the type and the associated
  procedures that manipulate instances of the type
\item Encapsulates the details of the implementation of the type
\end{itemize}
\item \structure{Generic Modules}
\begin{itemize}
\item A single abstract description for a family of abstract objects or ADTs
\item Parameterized by type
\item Eliminates the need for writing similar specifications for modules that
  only differ in their type information
\item A generic module facilitates specification of a stack of integers, stack
  of strings, stack of stacks etc.
\end{itemize}

\end{itemize}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Getting Started}
\begin{enumerate}
\item Find a similar example to your problem and use that as a starting point
\item Draft module names and secrets
\item For each module sketch out:
\bi
\item Classify module type (record, library, abstract object, abstract data
  type, generic ADT)
\item Access program syntax
\item State variables (if applicable)
\ei
\item Iterate on design
\end{enumerate}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Appendix: Information Hiding Examples}
\begin{itemize}
\item
  \href{https://gitlab.cas.mcmaster.ca/smiths/pub/-/blob/master/HoffmanAndStrooper1995.pdf}
  {Hoffman and Strooper (1995)} textbook on software development: The running
  example is of a symbol table.  A very complete example.  There is a complete
  chapter on the module guide in the text. It is well explained there.
\item
  \href{https://gitlab.cas.mcmaster.ca/smiths/pub/-/blob/master/ParnasEtAl1984.pdf}
  {Parnas Et Al (1984) ``The Module Structure of Complex Systems'' }: This
  example is right back to the source.  The example focuses on the A7E military
  fighter jet.
\item
  \href{https://gitlab.cas.mcmaster.ca/smiths/pub/-/blob/master/Parnas1979.pdf
  }{Parnas (1979) ``Designing Software For Ease of Extension and Contraction''} 
\item \href{http://www.cas.mcmaster.ca/~mohrens/maze.pdf} {von Mohrenschildt
    (2005) ``The Maze Tracing Robot A Sample Specification''}: This is a small
  and complete example.
\end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}
\frametitle{Appendix Cont'd: Information Hiding Examples}
\begin{itemize}
\item
  \href{https://github.com/smiths/swhs/blob/master/docs/Design/MG/PCM_MG.pdf}
  {Jegatheesan and MacLachlan (2018), Module Guide for Solar Water Heating
    Systems Incorporating Phase Change Material}
\item
  \href{https://github.com/XingzhiMac/CAS741-Proj/blob/master/docs/Design/MG/MG.pdf}
  {Liu (2020) Module Guide for Radio Signal Strength Calculator} 
\item Key points
\bi
\item One module, one secret
\item Secrets are often nouns (data structure, algorithm, hardware, etc.)
\item Secrets are sometimes phrased with ``How to …''
\item Secrets ideally will have a one to one mapping with the anticipated
  changes for the software
\ei
\end{itemize}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{frame}[allowframebreaks]
\frametitle{References}

\bibliography{../../ReferenceMaterial/References}

\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\end{document}