diff --git a/Lectures/Figures/MVC.png b/Lectures/Figures/MVC.png
new file mode 100644
index 0000000000000000000000000000000000000000..33c30238afb98ae3ff2903e35860581373f79696
Binary files /dev/null and b/Lectures/Figures/MVC.png differ
diff --git a/Lectures/Figures/MVCExampleStudent.png b/Lectures/Figures/MVCExampleStudent.png
new file mode 100644
index 0000000000000000000000000000000000000000..3cbc33e785c0735a3f27db90a016fdc6885a9dec
Binary files /dev/null and b/Lectures/Figures/MVCExampleStudent.png differ
diff --git a/Lectures/Figures/MeasurableInterface.pdf b/Lectures/Figures/MeasurableInterface.pdf
new file mode 100644
index 0000000000000000000000000000000000000000..c59665831ba138e22f2922cb4862e65f424fd183
Binary files /dev/null and b/Lectures/Figures/MeasurableInterface.pdf differ
diff --git a/Lectures/Figures/WebAppMVC.png b/Lectures/Figures/WebAppMVC.png
new file mode 100644
index 0000000000000000000000000000000000000000..bc2e69c290cd3e15ef1007e41e16a7bf5b74bdb5
Binary files /dev/null and b/Lectures/Figures/WebAppMVC.png differ
diff --git a/Lectures/L26_SpecViaUML/SpecViaUML.pdf b/Lectures/L26_SpecViaUML/SpecViaUML.pdf
index db206962bd31c5b6f0df2769c9d8c95e46b70fa7..4b788ed15d8e377541d99f2bcb37fdbf2d7417b5 100644
Binary files a/Lectures/L26_SpecViaUML/SpecViaUML.pdf and b/Lectures/L26_SpecViaUML/SpecViaUML.pdf differ
diff --git a/Lectures/L26_SpecViaUML/SpecViaUML.tex b/Lectures/L26_SpecViaUML/SpecViaUML.tex
index 81a0f3216407e53991c4858edf3849255d564060..58b683f565e866a67fbf968be8beeebbe78e7574 100755
--- a/Lectures/L26_SpecViaUML/SpecViaUML.tex
+++ b/Lectures/L26_SpecViaUML/SpecViaUML.tex
@@ -298,6 +298,16 @@ TBD
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
+\begin{frame}
+\frametitle{Code For Multiple Inheritance}
+
+\href{https://gitlab.cas.mcmaster.ca/smiths/se2aa4_cs2me3/tree/master/Lectures/L26_SpecViaUML/DataSetMultipleInheritance}
+{Data Set with Measurable Interface}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
 \begin{frame}
 \frametitle{UML Diagram for Generic Classes}
 
diff --git a/Lectures/L27_DesignPatterns/DesignPatterns.pdf b/Lectures/L27_DesignPatterns/DesignPatterns.pdf
index bff86c6eb4dfb747077eada167bb283d460e6262..8273a064118bca20b6cd4db12feb589bebc18b61 100644
Binary files a/Lectures/L27_DesignPatterns/DesignPatterns.pdf and b/Lectures/L27_DesignPatterns/DesignPatterns.pdf differ
diff --git a/Lectures/L27_DesignPatterns/DesignPatterns.tex b/Lectures/L27_DesignPatterns/DesignPatterns.tex
index 669905699a5e7836f562bb2a9be4924d325269da..526e311e03d50fae05e772c4418d86305f66d2de 100755
--- a/Lectures/L27_DesignPatterns/DesignPatterns.tex
+++ b/Lectures/L27_DesignPatterns/DesignPatterns.tex
@@ -29,9 +29,9 @@
 \mode<presentation>{}
 
 \input{../def-beamer}
-\Drafttrue
+\Draftfalse
 
-\newcommand{\topicTitle}{36 Design Patterns}
+\newcommand{\topicTitle}{27 Design Patterns}
 \ifDraft
 \newcommand{\topic}{\topicTitle~DRAFT}
 \else
@@ -39,13 +39,14 @@
 \fi
 
 \input{../titlepage}
-\Drafttrue
+\Draftfalse
 
 \begin{document}
 
 \input{../footline}
 
-\lstset{language=java,breaklines=true,showspaces=false,showstringspaces=false,breakatwhitespace=true}
+\lstset{language=java, breaklines=true, showspaces=false,
+  showstringspaces=false, breakatwhitespace=true}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -54,14 +55,13 @@
 
 \begin{itemize}
 \item Administrative details
-\item Debugging
-\item Verifying performance and reliability
+\item Specification using UML
 \item Design patterns
 \end{itemize}
 
 \end{frame}
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \begin{frame}
 \frametitle{Administrative Details}
@@ -74,149 +74,129 @@ TBD
 
 \item Today's slide are partially based on slides by Dr.\ Wassyng and on van Vliet (2000)
 
-\item A4
-\bi
-\item {Due April 5 at 11:59 pm}
-\ei
-
-\item Course evaluations
-\bi
-\item CS 2ME3: 49\%
-\item SE 2AA4: 63\%
-\item \href{https://evals.mcmaster.ca/login.php}{https://evals.mcmaster.ca/}
-\item Closes: 11:59 pm, Monday, April 10
-\ei
+\item A3
+\begin{itemize}
+\item Part 1 - Solution: Mar 18 
+\item Part 2 - Code: due 11:59 pm Mar 26
+\end{itemize}
 
-\item CAS poster and demo competition
+\item A4
 \bi
-\item April 6, 4 - 6 pm
-\item \structure{ITB/201}
-\item 12 graduate student submissions
+\item Your own design and specification
+\item Model module for game of Freecell
+\item Due April 9 at 11:59 pm
 \ei
 
-\item Think about course improvements for Wednesday
 \end{itemize}
 }
 \fi
 
 \end{frame}
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \begin{frame}
-\frametitle{Verifying Performance}
+\frametitle{UML Diagram for Generic Classes}
 
-\begin{itemize}
-\item Worst case analysis versus average behaviour
-\item For worst case focus on proving that the system response time is bounded
-  by some function of the external requests
-\item Standard deviation
-\item Analytical versus experimental approaches
-\item Consider verifying the performance of a pacemaker
-\item Visualize performance via
-\bi
-\item Identify a measure of performance (time, storage, FLOPS, accuracy, etc.)
-\item Identify an independent variable (problem size, number of processors,
-  condition number, etc.)
-\ei
-\end{itemize}
+\includegraphics[scale=0.55]{../Figures/UML_class_diagram_template.png}
 
+\href{https://coderanch.com/t/626984/a/5041/UML_class_diagram_template.png}{UML
+  Class Diagram Template}
 \end{frame}
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \begin{frame}
-\frametitle{Verifying Reliability}
+\frametitle{Use Cases}
 
-\begin{itemize}
-\item There are approaches to measuring reliability on a probabilistic basis, as
-  in other engineering fields
-\item Unfortunately there are some difficulties with this approach
-\item Independence of failures does not hold for software
-\item Reliability is concerned with measuring the probability of the occurrence
-  of failure
-\item Meaningful parameters include
-\begin{itemize}
-\item Average total number of failures observed at time $t$: $AF(t)$
-\item Failure intensity: $FI(T)=AF'(t)$
-\item Mean time to failure at time $t$: $MTTF(t) = 1/FI(t)$
-\end{itemize}
-\item Time in the model can be execution or clock or calendar time
-\end{itemize}
+\bi
+\item An overview of the usage requirements for a system
+\item Made up of:
+\bi
+\item Actors - person, organization, external system
+\item Use cases - action to be performed
+\ei
+\item Example of University Enterprise Resource Planning (ERP) software (Mosaic)
+\bi
+\item \structure{Actors?}
+\item \structure{Use cases?}
+\ei
+\ei
 
 \end{frame}
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \begin{frame}
-\frametitle{Verifying Subjective Qualities}
+%\frametitle{Use Cases}
 
-\begin{itemize}
-\item \structure{What do you think is meant by empirical software engineering?}
-\item \structure{What problems might be studied by empirical software
-    engineering?}
-\item \structure{Does the usual engineering analogy hold for empirical software
-    engineering?}
-\end{itemize}
+\includegraphics[scale=0.65]{../Figures/useCaseDiagram.jpg}
 
+\href{http://www.agilemodeling.com/artifacts/useCaseDiagram.htm}{UML
+  2 Use Case Diagrams: An Agile Introduction}
 \end{frame}
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \begin{frame}
-\frametitle{Verifying Subjective Qualities}
+\frametitle{Use Cases}
 
-\begin{itemize}
-\item Consider notions like simplicity, reusability, understandability …
-\item Software science (due to Halstead) has been an attempt
-\item Tries to measure some software qualities, such as
-abstraction level, effort, …
-\item by measuring some quantities on code, such as
 \bi
-\item $\eta_1$, number of distinct operators in the program
-\item $\eta_2$, number of distinct operands in the program
-\item $N_1$, number of occurrences of operators in the program
-\item $N_2$, number of occurrences of operands in the program
+\item Often used for capturing requirements
+\item From user's (actor's) viewpoint
+\bi
+\item Person
+\item Other system
+\item Hardware
+\item etc. (anything external
+\ei
+\item Each circle is a use case
+\item Lines represent possible interactions
+\item An actor represents a role, individuals can take on different roles
 \ei
-\item Extract information from repo, including number of commits, issues etc.
-\item Empirical software engineering
-\item Appropriate analogy switches from engineering to medicine
-\end{itemize}
 
 \end{frame}
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}[plain]
+%\frametitle{Use Cases}
+
+\includegraphics[scale=0.45]{../Figures/buying_3.jpg}
+
+\href{http://people.cs.ksu.edu/~reshma/buying_3.JPG}{Sequence Diagram For
+  On-Line Shopping}
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \begin{frame}
-\frametitle{Source Code Metric}
+\frametitle{Sequence Diagram Question}
 
-\begin{itemize}
-\item \structure{What are the consequences of complex code?}
-\item \structure{How might you measure code complexity?}
-\end{itemize}
+\bi
+\item \structure{Is a sequence diagram an operational or a descriptive
+    specification?}
+\item \structure{If objects exchange a message, should there be an association
+    between their classes?}
+\ei
 
 \end{frame}
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \begin{frame}
-\frametitle{McCabe's Source Code Metric}
+\frametitle{Sequence Diagrams}
 
-\begin{itemize}
-\item Cyclomatic complexity of the control graph
 \bi
-\item $C = e - n + 2 p$
-\item $e$ is number of edges, $n$ is number of nodes, and $p$ is number of
-  connected components
+\item Represents a specific use case scenario
+\item How objects interact by exchanging messages
+\item Time progresses in the vertical direction
+\item The vertically oriented boxes show the object's lifeline
 \ei
-\item McCabe contends that well-structured modules have $C$ in range $3 .. 7$,
-  and $C = 10$ is a reasonable upper limit for the complexity of a single module
-\item Confirmed by empirical evidence 
-\end{itemize}
 
 \end{frame}
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \begin{frame}
 \frametitle{Design Patterns}
@@ -225,21 +205,24 @@ abstraction level, effort, …
 
 \item Christopher Alexander (1977, buildings/towns):
 \begin{itemize}
-\item ``Each pattern describes a problem which occurs over and over again in our environment, and then describes the
-core of the solution to that problem, in such a way that you can use this solution a million times over, without ever
-doing it the same way.''
+\item ``Each pattern describes a problem which occurs over and over again in our
+  environment, and then describes the core of the solution to that problem, in
+  such a way that you can use this solution a million times over, without ever
+  doing it the same way.''
 \end{itemize}
 \item Design reuse (intended for OO)
 \item Solution for recurring problems
 \item Transferring knowledge from expert to novice
 %\item Provides language for communicating about design
-\item A design pattern is a recurring structure of communicating components that solves a general design problem within a particular context
-\item Design patterns consist of multiple modules, but they do not constitute an entire system architecture
+\item A design pattern is a recurring structure of communicating components that
+  solves a general design problem within a particular context
+\item Design patterns consist of multiple modules, but they do not constitute an
+  entire system architecture
 \end{itemize}
 
 \end{frame}
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \begin{frame}
 \frametitle{Strategy Design Pattern}
@@ -258,16 +241,19 @@ doing it the same way.''
 
 \end{frame}
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \begin{frame}
 \frametitle{UML Diagram of Measurable Interface}
 
-\includegraphics[scale=0.65]{../Figures/UMLDataSetMeasurableInterface.pdf}
+\medskip
+\medskip
+
+\includegraphics[scale=0.85]{../Figures/MeasurableInterface.pdf}
 
 \end{frame}
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \begin{frame}
 \frametitle{UML Diagram of Measurer Interface}
@@ -298,6 +284,61 @@ doing it the same way.''
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
+\begin{frame}
+\frametitle{MVC}
+
+\includegraphics[scale=0.6]{../Figures/MVC.png}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{MVC Web Applications}
+
+\includegraphics[scale=1]{../Figures/WebAppMVC.png}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{MVC Example}
+
+\includegraphics[scale=0.5]{../Figures/MVCExampleStudent.png}\\
+\href{https://www.tutorialspoint.com/design_pattern/mvc_pattern.htm}
+{https://www.tutorialspoint.com/design\_pattern/mvc\_pattern.htm}
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{MVC Critique}
+
+\bi
+\item Advantages
+\bi
+\item Simultaneous develoment
+\item High cohesion
+\item Low coupling
+\item Ease of modification
+\item Multiple views for a model
+\ei
+\item Disadvantages
+\bi
+\item Code navigability
+\item Multi-artifact consistency
+\item Pronounced learning curve
+\ei
+\ei
+
+\href{https://en.wikipedia.org/wiki/Model–view–controller}{Wikipedia page}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+
 \begin{frame}
 \frametitle{Design Pattern Properties}
 
@@ -316,6 +357,53 @@ doing it the same way.''
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
+\begin{frame}
+\frametitle{Classification of Patterns}
+
+\begin{itemize}
+
+\item Creational design patterns
+\bi
+\item Abstract factory
+%\item Builder
+%\item Factory method
+\item Object pool
+\item Prototype
+\item Singleton
+\ei
+\item Structural design patterns
+\bi
+\item Adapter
+\item Bridge
+%\item Composite
+%\item Decorator
+\item Facade
+%\item Flyweight
+%\item Private Class Data
+\item Proxy
+\ei
+\item Behavioural design patterns
+\bi
+%\item Chain of responsibility
+\item Command
+%\item Interpreter
+\item Iterator
+%\item Mediator
+%\item Memento
+%\item Null object
+\item Observer
+\item State
+\item Strategy
+%\item Template method
+%\item Visitor
+\ei
+
+\end{itemize}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
 \begin{frame}
 \frametitle{Describing Patterns}
 
diff --git a/Lectures/L35_Analysis/Analysis.pdf b/Lectures/L35_Analysis/Analysis.pdf
index 3dbbe68b16174cf3ce38baf889bb1d94d7ecf936..62dfcd8b6f7d1e2b33157cc80ed127f59a811c47 100644
Binary files a/Lectures/L35_Analysis/Analysis.pdf and b/Lectures/L35_Analysis/Analysis.pdf differ
diff --git a/Lectures/L35_Analysis/Analysis.tex b/Lectures/L35_Analysis/Analysis.tex
index f4406b070eff6318a240799527bb5bf40e2d072e..4a04f333e2221c0533799fe20cd74d72eef37c39 100755
--- a/Lectures/L35_Analysis/Analysis.tex
+++ b/Lectures/L35_Analysis/Analysis.tex
@@ -336,7 +336,7 @@ TBD
 \ei
 \end{frame}
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \begin{frame}
 \frametitle{Testing your Tests: Mutation Testing}
@@ -351,7 +351,7 @@ TBD
 \end{itemize}
 \end{frame}
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \begin{frame}
 \frametitle{Analysis Versus Testing}
@@ -550,7 +550,123 @@ View all of these as complementary
 
 \end{frame}
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Verifying Performance}
+
+\begin{itemize}
+\item Worst case analysis versus average behaviour
+\item For worst case focus on proving that the system response time is bounded
+  by some function of the external requests
+\item Standard deviation
+\item Analytical versus experimental approaches
+\item Consider verifying the performance of a pacemaker
+\item Visualize performance via
+\bi
+\item Identify a measure of performance (time, storage, FLOPS, accuracy, etc.)
+\item Identify an independent variable (problem size, number of processors,
+  condition number, etc.)
+\ei
+\end{itemize}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Verifying Reliability}
+
+\begin{itemize}
+\item There are approaches to measuring reliability on a probabilistic basis, as
+  in other engineering fields
+\item Unfortunately there are some difficulties with this approach
+\item Independence of failures does not hold for software
+\item Reliability is concerned with measuring the probability of the occurrence
+  of failure
+\item Meaningful parameters include
+\begin{itemize}
+\item Average total number of failures observed at time $t$: $AF(t)$
+\item Failure intensity: $FI(T)=AF'(t)$
+\item Mean time to failure at time $t$: $MTTF(t) = 1/FI(t)$
+\end{itemize}
+\item Time in the model can be execution or clock or calendar time
+\end{itemize}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Verifying Subjective Qualities}
+
+\begin{itemize}
+\item \structure{What do you think is meant by empirical software engineering?}
+\item \structure{What problems might be studied by empirical software
+    engineering?}
+\item \structure{Does the usual engineering analogy hold for empirical software
+    engineering?}
+\end{itemize}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Verifying Subjective Qualities}
+
+\begin{itemize}
+\item Consider notions like simplicity, reusability, understandability …
+\item Software science (due to Halstead) has been an attempt
+\item Tries to measure some software qualities, such as
+abstraction level, effort, …
+\item by measuring some quantities on code, such as
+\bi
+\item $\eta_1$, number of distinct operators in the program
+\item $\eta_2$, number of distinct operands in the program
+\item $N_1$, number of occurrences of operators in the program
+\item $N_2$, number of occurrences of operands in the program
+\ei
+\item Extract information from repo, including number of commits, issues etc.
+\item Empirical software engineering
+\item Appropriate analogy switches from engineering to medicine
+\end{itemize}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Source Code Metric}
+
+\begin{itemize}
+\item \structure{What are the consequences of complex code?}
+\item \structure{How might you measure code complexity?}
+\end{itemize}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{McCabe's Source Code Metric}
+
+\begin{itemize}
+\item Cyclomatic complexity of the control graph
+\bi
+\item $C = e - n + 2 p$
+\item $e$ is number of edges, $n$ is number of nodes, and $p$ is number of
+  connected components
+\ei
+\item McCabe contends that well-structured modules have $C$ in range $3 .. 7$,
+  and $C = 10$ is a reasonable upper limit for the complexity of a single module
+\item Confirmed by empirical evidence 
+\end{itemize}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
 
 \end{document}