diff --git a/Lectures/L23_FiniteStateMachines/FiniteStateMachines.tex b/Lectures/L23_FiniteStateMachines/FiniteStateMachines.tex
index 1c840e50c22d882d0f7cb9e8ffd26202ef4834a6..54c079c26be6d61f5b1fe982145b15f947cc27c1 100755
--- a/Lectures/L23_FiniteStateMachines/FiniteStateMachines.tex
+++ b/Lectures/L23_FiniteStateMachines/FiniteStateMachines.tex
@@ -158,7 +158,6 @@ A[i+1])$}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
-
 \begin{frame}
 \frametitle{Homework Exercise}
 
diff --git a/Lectures/L24_SpecificationQuality/SpecificationQuality.pdf b/Lectures/L24_SpecificationQuality/SpecificationQuality.pdf
index c9e6aeda4710fae0c7c6a3d9f6cc4eb76ee6eba9..56ff6a8bc016cd4f035c2a8c4fb953ee3fd18ca9 100644
Binary files a/Lectures/L24_SpecificationQuality/SpecificationQuality.pdf and b/Lectures/L24_SpecificationQuality/SpecificationQuality.pdf differ
diff --git a/Lectures/L24_SpecificationQuality/SpecificationQuality.tex b/Lectures/L24_SpecificationQuality/SpecificationQuality.tex
index ab9211a8cb439a4099f12274826d811793c7bc5c..b3576a68375a672dd59149ba44612362cf3ce632 100755
--- a/Lectures/L24_SpecificationQuality/SpecificationQuality.tex
+++ b/Lectures/L24_SpecificationQuality/SpecificationQuality.tex
@@ -23,7 +23,7 @@
 \mode<presentation>{}
 
 \input{../def-beamer}
-\Drafttrue
+\Draftfalse
 
 \newcommand{\topicTitle}{26 Specification Quality}
 \ifDraft
@@ -47,10 +47,8 @@
 
 \begin{itemize}
 \item Administrative details
-\item Abstract class versus interface
-\item Use cases with UML
-\item Sequence diagrams in UML
 \item Line Formatter Example
+\item Converting English to Mathematics
 \end{itemize}
 
 \end{frame}
@@ -66,16 +64,16 @@ TBD
 {
 \begin{itemize}
 
-\item A3 deadlines
+\item A3
 \begin{itemize}
-\item Part 1 - Specification: due 11:59 pm \structure{Mar 11}
-\item Part 2 - Code: due 11:59 pm Mar 20
+\item Part 1 - Specification: due 11:59 pm Mar 12
+\item Part 2 - Code: due 11:59 pm Mar 26
 \end{itemize}
 
 \item A4
 \bi
 \item Your own design and specification
-\item Due April 3 at 11:59 pm
+\item Due April 9 at 11:59 pm
 \ei
 
 \end{itemize}
@@ -87,175 +85,27 @@ TBD
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \begin{frame}
-\frametitle{A3 Hints}
+\frametitle{Line Formatter Overview}
 
-\ifDraft  
-TBD
-\else
-{
-\begin{itemize}
-\item Take advantage of what descriptive mathematical specification has to offer
-\item You do not need to worry about how to calculate values, only how to
-  describe them
-\item pointInRegion(p): A point p is considered to be in the Region if there
-  exists a point q, where q is in the Region, and the distance between the two
-  points is less than the allowed tolerance.
-\item $\theta = \cos^{-1} \left ( \frac {\mathbf{u} \cdot \mathbf{v}}{|| \mathbf{u} || ||
-\mathbf{v} ||} \right )$
-\item A valid segment is valid if it is valid with respect to all obstacles
-\bi
-\item \structure{How would you say: For all obstacles the segment is valid?}
-\item \uncover<2->{$\forall (i: \mathbb{N}| 0 \leq i < \mbox{Map.get\_obstacles.size()} :
-\mbox{is\_valid\_segment\_for\_region}(p_1, p_2, i)$}
-\ei
-\end{itemize}
-}
-\fi
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{A3 Hints Continued}
-
-\ifDraft  
-TBD
-\else
-{
 \begin{itemize}
-\item \structure{What makes a segment valid wrt a given region?}
-\bi
-\item \uncover<2->{None of the points on the segment lie within the region}
-\item \uncover<3->{For all points along the line NOT pointInRegion()}
-\item \uncover<4->{All the points using the parametric rep of a line.}
-\ei
-\item \structure{What has to be true for a valid path?}
-\bi
-\item \uncover<5->{First point in the region for the safe zone}
-\item \uncover<5->{Last point in the region for the safe zone}
-\item \uncover<5->{For all destination there is a point on the path that is in
-    the region}
-\item \uncover<5->{For all segments the segments are valid}
-\ei
-\end{itemize}
-}
-\fi
 
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-%\frametitle{Differences Between Interface and Abstract}
-\begin{itemize}
-\item Interface
-\bi
-\item Methods are implicitly abstract and public
-\item Methods can have default implementation ( JDK 8)
-\item Cannot have constructors
-\item Variables are final
-\item Can only extend interfaces
-\item Classes can extend multiple instances
-\item Appropriate for unrelated classes
-\ei
-\item Abstract class
-\bi
-\item At least one method is declared as abstract
-\item Some methods can implement a default behaviour
-\item Cannot instantiate them, but can have constructors
-\item Variables are not necessarily final
-\item Can extend other class
-\item Can implement multiple interfaces
-\item Classes can extend only one abstract class
-\item Sharing code between closely related classes
-\ei
+\item The
+  \href{https://gitlab.cas.mcmaster.ca/smiths/se2aa4_cs2me3/tree/master/Lectures/LineFormatter}
+  {line formatter specification} was written to improve on existing
+  specifications
+\item How well does the specification do with respect to the following
+  qualities: abstract, correct, unambiguous, complete, consistent and verifiable?
+\item For a requirement specification like that given, what are the advantages
+  and disadvantages of maintaining both a formal specification and a natural
+  language specification?
+\item A relevant critique in:
+  \href{https://gitlab.cas.mcmaster.ca/smiths/se2aa4_cs2me3/blob/master/ReferenceMaterial/Meyer1985.pdf}
+  {Meyer (1985)} ``On Formalism in Specification''
 \end{itemize}
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{UML Diagram for Generic Classes}
-
-\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{Use Cases}
-
-\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{Use Cases}
-
-\bi
-\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
-
-\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{Sequence Diagrams}
-
-\bi
-\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
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Sequence Diagram Question}
-
-\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{Line Formatter}