SoftEngPrinciplesContd.tex

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

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

\usepackage{booktabs}
\usepackage{listings}

\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}
\Draftfalse

\newcommand{\topicTitle}{06 Software Engineering Principles Continued (Ch.\ 3)}
\ifDraft
\newcommand{\topic}{\topicTitle~DRAFT}
\else
\newcommand{\topic}{\topicTitle}
\fi

\input{../titlepage}

\begin{document}

\input{../footline}

\lstset{language=python,basicstyle=\ttfamily,breaklines=true,showspaces=false,showstringspaces=false,breakatwhitespace=true,texcl=true,escapeinside={\%*}{*)}}

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

\begin{frame}
\frametitle{\topic}

\begin{itemize}
\item Administrative details
\item Key principles
\begin{itemize}
\item Rigour
\item Formality
\item Separation of concerns
\item Modularity
\item Abstraction
\item Anticipation of change
\item Generality
\item Incrementality
\end{itemize}
\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Administrative Details}

\ifDraft  
TBD
\else
{
\begin{itemize}
\item Assignment 1
\begin{itemize}
\item Part 1: January 22, 2018
\item Partner Files: January 28, 2018
\item Part 2: January 31, 2018
\end{itemize}
\item Questions on assignment?
\end{itemize}
}
\fi

\end{frame}

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

\begin{frame}
\frametitle{Modularity}

\begin{itemize}

\item A \structure<0->{modular system} is a complex system that is divided into smaller parts called
\structure<0->{modules}
\item Modularity enables the principle of separation of concerns to be applied in two ways:
\begin{enumerate}
\item Different parts of the system are considered separately
\item The parts of the system are considered separately from their composition
\end{enumerate}
\item \structure<0->{Modular decomposition} is the \alert{top-down} process of
  dividing a system into modules
\item Modular decomposition is a \alert{``divide and conquer''} approach
\item \structure<0->{Modular composition} is the \alert{bottom-up} process of
  building a system out of modules
\item Modular composition is an \alert{``interchangeable parts''} approach

\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Examples of Modularity}

\structure{What are examples of modularity in traditional engineering?}\\
% something assembled from parts
% computer, including peripherals
% IKEA units
% printer toner cartridge
% video games
% entertainment system
% food processor
% etc.
\end{frame}

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

\begin{frame}
\frametitle{Properties of Good Modules}

\begin{itemize}

\item To achieve the benefits of modularity, a software engineer must design
  modules with two properties
\begin{enumerate}
\item \structure<0->{High cohesion:} The components of the module are closely
  related
\item \structure<0->{Low coupling:} The module does not strongly depend on other
  modules
\end{enumerate}
\item This allows the modules to be treated in two ways:
\begin{enumerate}
\item As a set of interchangeable parts
\item As individuals
\end{enumerate}

\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Zero Coupling?}

Given that low coupling is desirable, the ideal modularization has zero coupling.  Is this
statement True or False?
\begin{enumerate}[A.]
\item True 
\item False %correct answer - without coupling, every module would have to
            %provide all of its own services - need some communication, think of electrical power
            %network in a home
\end{enumerate}

\end{frame}

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

\begin{frame}
\frametitle{Proposed Modularization for a Car}

Suppose you decide to modularize the description of a car by considering the
car as comprising small cubes 15 inches on a side.
\begin{enumerate}
\item Is the cohesion high or low?
\item Is the coupling high or low?
\item Propose a better modularization
\item In general, how should you decompose a complex system into modules?
\end{enumerate}

\end{frame}

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

\begin{frame}
\frametitle{Abstraction}

\begin{itemize}

\item \structure<0->{Abstraction} is the process of focusing on what is
  important while ignoring what is irrelevant
\item Abstraction is a special case of separation of concerns
\item Abstraction produces a \structure<0->{model} of an entity in which the
  irrelevant details of the entity are left out
\begin{itemize}
\item Many different models of the same entity can be produced by abstraction
\item Abstraction models differ from each other by what is considered important
  and what is considered irrelevant
\item Repeated application of abstraction produces a hierarchy of models
\end{itemize}
\item \structure<0->{Refinement} is the opposite of abstraction
\item Over abstraction produces models that are difficult to understand because
  they are missing so many details

\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Abstract Data Type}

\structure{What makes an Abstract Data Type Abstract?}
% don't give the implementation
% example of sequence
\end{frame}

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

\begin{frame}[fragile]
\frametitle{Abstract versus Concrete}

\structure{What is a more abstract way to state the following?}

\ttfamily
\begin{lstlisting}
def bubbleSort(a):
  n = len(a)
  for i in range(n - 1):
    for j in range(n - 1 - i):
      if a[j] > a[j + 1]:
        a[j], a[j + 1] = a[j + 1], a[j]
\end{lstlisting}
\sffamily

% use bubble sort algorithm on list of comparables a
% sort list of comparables a
% sort list over generic comparables
\end{frame}

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

\begin{frame}
\frametitle{Anticipation of Change}

\begin{itemize}

\item \structure{Anticipation of change} is the principle that future change
  should be anticipated and planned for
\item Also called \structure{design for change}
\item Techniques for dealing with change:
\begin{enumerate}
\item \structure{Configuration management:} Manage the configuration of the
  software so that it can be easily modified as the software evolves
\item \structure{Information hiding:} Hide the things that are likely to change
  inside of modules
\item \structure{Little languages:} Create little languages that can be used to
  solve families of related problems
\end{enumerate}
\item Since software is constantly changing, anticipation of change is crucial
  for the software development process

\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Anticipation of Change}

\structure{Change should be anticipated for the development process, as well as the
product.  For instance, what can you do to anticipate changes in staffing?}
% important knowledge shouldn't be with just one person
% documentation!

\end{frame}

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

\begin{frame}
\frametitle{Likely Changes}

\structure{You have been asked to design a software version of the game
  Battleship.  What are some likely changes?}
% data structure for state of game - grid size, number of ships, etc.
% hardward hiding
% gui (model view controller)
% rules
\end{frame}

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

\begin{frame}
\frametitle{Generality}

\begin{itemize}

\item The principle of \structure{generality} is to solve a more general problem
  than the problem at hand whenever possible
\item \structure{Advantages}
\begin{itemize}
\item The more general a solution is the more likely that it can be reused
\item Sometimes a general problem is easier to solve than a specific problem
\end{itemize}
\item \structure{Disadvantages}
\begin{itemize}
\item A general solution may be less efficient than a more specific solution
\item A general problem may cost more to solve than a more specific problem
\end{itemize}
\item Abstraction is often used to extract a general solution from a specific solution
\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Generality for Computational Geometry}

The $n$-dimensional volume of a Euclidean ball of radius $R$ in $n$-dimensional
Euclidean space

$$V_{2k}(R) = \frac{\pi^k}{k!} R^{2k}$$

$$V_{2k+1}(R) = \frac{2 (k!)(4 \pi)^k}{(2k+1)!} R^{2k+1}$$

\bi
\item See \href{https://en.wikipedia.org/wiki/Volume_of_an_n-ball}{Wikipedia page for
  Volume of an $n$-ball}

\item \href{http://doc.cgal.org/latest/Manual/packages.html}{CGAL includes specific
  and general kernels}

\item Domain Specific Languages (DSLs) hold the promise of generality and
  performance

\ei

\end{frame}

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

\begin{frame}
\frametitle{Generality of ODE Solver}

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

\end{frame}

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

\begin{frame}
\frametitle{Incrementality}

\begin{itemize}

\item The principle of \structure{incrementality} is to attack a problem by producing successively closer
approximations to a solution
\item Enables the development process to receive \structure{feedback} and the requirements to be adjusted accordingly
\item Techniques for developing software incrementally
\begin{enumerate}
\item \structure{Rapid prototyping:} Produce a \structure{prototype} that is ``thrown away'' later
\item \structure{Refinement:} A high-level artifact (like a requirements specification or a higher-level design) is
incrementally refined into a low-level artifact (like a lower-level design or an implementation)
\end{enumerate}
\end{itemize}
\end{frame}

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

\begin{frame}
\frametitle{Principles for High Quality Documentation}
% move this material to an earlier lecture
\begin{itemize}
\item Under quality, we should have mentioned these
\item To achieve external qualities for documentation, there are some generally
  agreed on internal qualities
\item Internal qualities can more likely be directly measured
\item Following list of qualities based on IEEE guidelines for requirements
  (IEEE Std 830-1998)
\bi
\item Complete
\item Consistent
\item Modifiable
\item Traceable
\item Unambiguous
\item Correct
\item Verifiable
\item Abstract
\ei
\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Up Next}

\begin{itemize}

\item Design (Chapter 4)
\bi
\item More on modularization
\item Mathematics for Module Interface Specification (MIS)
\item MIS
\item Abstract objects
\item Abstract Data Types (ADTs)
\item Generic ADTs
\item Object Oriented Design (OOD)
\ei

\end{itemize}

\end{frame}

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

\end{document}