Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • 2018
2 results
Blame Permalink
Forked from W. Spencer Smith / cas741
676 commits behind the upstream repository.
Code owners
Assign users and groups as approvers for specific file changes. Learn more.
MISContinued.tex 22.69 KiB 
%\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}{18 MIS Continued}

\input{../titlepage}

\begin{document}

\input{../footline}

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

\begin{frame}
\frametitle{MIS Continued}

\bi
\item Administrative details
\item Questions?
\item Exceptions
\item Quality criteria
\item Modules with external interaction, enviro variables
\item GUI modules
\item ADTs
\item Generic modules
\item OO design spec
\item Examples
\ei
\end{frame}

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

\begin{frame}
\frametitle{Administrative Details}

\bi
\item GitHub issues for colleagues
\bi
\item Assigned 1 colleague (see \texttt{Repos.xlsx} in repo)
\item Provide at least 5 issues on their MG
\item Grading as before
\item Due by Tuesday, Nov 14, 11:59 pm
\ei
\item MIS template in CAS 741 repo
\ei

\end{frame}

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

\begin{frame}
\frametitle{Administrative Details: Deadlines}
~\newline
\begin{tabular}{l l l}
\textbf{MIS Present} & Week 10 & Week of Nov 13\\
\textbf{MIS} & Week 11 & Nov 22\\
Impl.\ Present & Week 12 & Week of Nov 27\\
Final Documentation & Week 13 & Dec 6\\
\end {tabular}

\end{frame}

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

\begin{frame}
\frametitle{Administrative Details: Presentation Schedule}

\bi
\item MIS Present
\bi
\item \textbf{Tuesday: Isobel, Keshav, Paul}
\item \textbf{Friday: Shusheng, Xiaoye, Devi}
\ei
\item Impl.\ Present
\bi
\item Tuesday: Alexander S., Steven, Alexandre P.
\item Friday: Jason, Geneva, Yuzhi
\ei

\ei

\end{frame}

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

\begin{frame}
\frametitle{MIS Presentations and Documentation}
\begin{itemize}
\item For each module
\bi
\item Module or Template Module or Generic Template Module
\item Syntax, especially access programs
\item State variables
\ei
\item Do not need a formal spec for everything
\item Goal is communication with a developer or maintainer
\item Clarifying comments in the MIS are helpful
\item Use notation from SRS wherever possible
\end{itemize}
\end{frame}

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

\begin{frame}
\frametitle{Questions?}
\begin{itemize}
\item Questions about MIS presentations?
\item Questions about MIS documentation?
\item Other questions?
\end{itemize}
\end{frame}

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

\begin{frame}

\frametitle{Exception Signalling}

\begin{itemize}
\item Useful to think about exceptions in the design process
\item Will need to decide how exception signalling will be done
\begin{itemize}
\item A special return value, a special status parameter, a global variable
\item Invoking an exception procedure
\item Using built-in language constructs
\end{itemize}
\item Caused by errors made by programmers, not by users
\item Write code so that it avoid exceptions
\item Exceptions will be particularly useful during testing
\end{itemize}

\end{frame}

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

\begin{frame}

\frametitle{Assumptions versus Exceptions}

\begin{itemize}
\item The assumptions section lists assumptions the module developer is permitted to make about the programmer's behaviour
\item Assumptions are expressed in prose
\item Use assumptions to simplify the MIS and to reduce the complexity of the final implementation
\item Interface design should provide the programmer with a means to check so that they can avoid exceptions
\item When an exceptions occurs no state transitions should take place, any output is {\it don't care}
\end{itemize}

\end{frame}

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

\begin{frame}

\frametitle{Quality Criteria}

\begin{itemize}
\item Consistent
\begin{itemize}
\item Name conventions
\item Ordering of parameters in argument lists
\item Exception handling, etc.
\end{itemize}
\item Essential - omit unnecessary features
\item General - cannot always predict how the module will be used
\item As implementation independent as possible
\item Minimal - avoid access routines with two potentially independent services
\item High cohesion - components are closely related
\item Low coupling - not strongly dependent on other modules
\item Opaque - information hiding
\end{itemize}

\end{frame}

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

\begin{frame}

\frametitle{SWHS Example}

Look at SWHS repo

\end{frame}

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

\begin{frame}
\frametitle{Modules with External Interaction}

\begin{itemize}
\item In general, some modules may interact with the environment or other modules
%\item The Display Point Masses Applet module does this
\item Environment might include the keyboard, the screen, the file system, motors, sensors, etc.
\item Sometimes the interaction is informally specified using prose (natural language)
\item Can introduce an environment variable
\begin{itemize}
\item Name, type
\item Interpretation
\end{itemize}
\item Environment variables include the screen, the state of a motor (on, direction of rotation, power level, etc.),
the position of a robot

\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{External Interaction Continued}

\begin{itemize}
\item Some external interactions are hidden
\begin{itemize}
\item Present in the implementation, but not in the MIS
\item An example might be OS memory allocation calls
\end{itemize}
\item External interaction described in the MIS
\begin{itemize}
\item Naming access programs of the other modules
\item Specifying how the other module's state variables are changed
\item The MIS should identify what external modules are used
\end{itemize}
\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{MIS for GUI Modules}

\begin{itemize}
\item Could introduce an environment variable
\item window: sequence [RES\_H][RES\_V] of pixelT
\begin{itemize}
\item Where window[r][c] is the pixel located at row r and column c, with numbering zero-relative and beginning at the
upper left corner
\item Would still need to define pixelT
\end{itemize}
\item Could formally specify the environment variable transitions
\item More often it is reasonable to specify the transition in prose
\item In some cases the proposed GUI might be shown by rough sketches
\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Display Point Masses Module Syntax}

\textbf{Exported Access Programs}\\
~\newline
\begin{tabular}{| l | l | l | l |}
\hline
\textbf{Routine name} & \textbf{In} & \textbf{Out} & \textbf{Exc}\\
\hline
DisplayPointMassesApplet & ~ & DisplayPointMassesApplet & ~\\
\hline
paint & ~ & ~ & ~\\
\hline
\end{tabular}

\end{frame}

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

\begin{frame}
\frametitle{Display Point Masses Module Semantics}

\textbf{Environment Variables}\\
$\mathit{win}:$ 2D sequence of pixels displayed within a web-browser \\

\noindent DisplayPointMassesApplet():
\begin{itemize}
\item transition: The state of the abstract object ListPointMasses is modified as follows:\\
ListPointMasses.init()\\
ListPointMasses.add(0, PointMassT(20, 20, 10))\\
ListPointMasses.add(1, PointMassT(120, 200, 20))\\
...
\end{itemize}

\noindent paint():
\begin{itemize}
\item transition $win := $ Modify window so that the point masses in ListPointMasses 
are plotted as circles.  The centre of each circles should be the corresponding x and y coordinates and the radius should
be the mass of the point mass.
\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Specification of ADTs}
\begin{itemize}
\item Similar template to abstract objects
\item ``Template Module'' as opposed to ``Module''
\item ``Exported Types'' that are abstract use a ?
\begin{itemize}
\item pointT = ?
\item pointMassT = ?
\end{itemize}
\item Access routines know which abstract object called them
\item Use ``self'' to refer to the current abstract object
\item Use a dot ``.'' to reference methods of an abstract object
\begin{itemize}
\item $p.\mbox{xcoord()}$
\item $\mathit{self}.pt.\mbox{dist}(p.\mbox{point}())$
\end{itemize}
\item Similar notation to Java
\item The syntax of the interface in C is different
\end{itemize}
\end{frame}

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

\begin{frame}
\frametitle{Syntax Line ADT Module}

\textbf{Template Module}\\
~\newline
lineADT\\
~\newline
\textbf{Uses}\\
~\newline
pointADT\\
~\newline
\textbf{Exported Types}\\
~\newline
lineT = ?

\end{frame}

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

\begin{frame}
\frametitle{Syntax Line ADT Module Continued}

\begin{tabular}{| l | l | l | l |}
\hline
\textbf{Routine name} & \textbf{In} & \textbf{Out} & \textbf{Exceptions}\\
\hline
new lineT & pointT, pointT & lineT & ~\\
\hline
start & ~ & pointT & ~\\
\hline
end & ~ & pointT & ~\\
\hline 
length & ~ & real & ~\\
\hline
midpoint & ~ & pointT & ~\\
\hline
rotate & real & ~ & ~\\
\hline
\end{tabular}

\end{frame}

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

\begin{frame}
\frametitle{Semantics Line ADT Module}

\textbf{State Variables}\\
~\newline
$s$: pointT\\
$e$: pointT\\
~\newline
\textbf {State Invariant}\\
~\newline
None\\
~\newline
\textbf{Assumptions}\\
~\newline
None

\end{frame}

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

\begin{frame}
\frametitle{Access Routine Semantics Line ADT Module}

\noindent new lineT ($p_1, p_2$):
\begin{itemize}
\item transition: $s, e := p_1, p_2$
\item output: $out := \mathit{self}$
\item exception: none
\end{itemize}

\noindent start:
\begin{itemize}
\item output: $out := s$
\item exception: none
\end{itemize}

\noindent end:
\begin{itemize}
\item output: $out := e$
\item exception: none
\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Access Routine Semantics Continued}

\noindent length:
\begin{itemize}
\item output: $out := s.\mathrm{dist}(e)$
\item exception: none
\end{itemize}

\noindent midpoint:
\begin{itemize}
\item output: $out := $
$$\mathrm{new~} \mathrm{pointT} (\mathrm{avg}(s.\mathrm{xcoord}, e.\mathrm{xcoord}), \mathrm{avg}(s.\mathrm{ycoord},
e.\mathrm{ycoord}))$$
\item exception: none
\end{itemize}

\noindent rotate ($\phi$):\\
$\phi$ is in radians
\begin{itemize}
\item transition: $s.\mathrm{rotate}(\phi), e.\mathrm{rotate}(\phi)$
\item exception: none
\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Line ADT Local Functions}

\textbf{Local Functions}\\
~\newline
avg: real $\times$ real $\rightarrow$ real

\noindent avg($x_1, x_2$) $\equiv \frac{x_1 + x_2}{2}$

\end{frame}

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

% \begin{frame}
% \frametitle{ADTs in C}

% \begin{itemize}
% \item Each object will be a pointer to a struct that holds its state
% \item The interface for each routine, other than initialization routines, will need this pointer
% \item There is an implicit object of the ADT type as the first input parameter in all routines other than init
% \item Need to add a prefix to all routines, other than initialization routines, to avoid naming conflicts
% \item For PointADT, using prefix {\tt pt\_}
% \begin{itemize}
% \item {\tt typedef struct Point* pointT;}
% \item \uncover<2->{\tt pointT pt\_init(float x, float y);}
% \item \uncover<3->{\tt float pt\_xcoord(pointT self);}
% \item \uncover<4->{\tt float pt\_ycoord(pointT self);}
% \item \uncover<5->{\tt float pt\_dist(pointT self, pointT p);}
% \end{itemize}
% \item For PointMassADT use prefix {\tt pm\_}
% \end{itemize}
% \end{frame}

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

\begin{frame}
\frametitle{Generic Modules}

\begin{itemize}
\item What if we have a sequence of integers, instead of a sequence of point masses?
\item What if we want a stack of integers, or characters, or pointT, or pointMassT?
\item Do we need a new specification for each new abstract object?
\item No, we can have a single abstract specification implementing a family of abstract objects that are distinguished
only by a few variabilities
\item Rather than duplicate nearly identical modules, we parameterize one \structure{generic module} with respect to
type(s)
\item Advantages
\begin{itemize}
\item Eliminate chance of inconsistencies between modules
\item Localize effects of possible modifications
\item Reuse
\end{itemize}
\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Generic Stack Module Syntax}

\textbf{Generic Module}\\
~\newline
Stack(T)\\
~\newline
\textbf{Exported Constants}\\
~\newline
$\mbox{MAX\_SIZE} = 100$
~\newline

\textbf{Exported Access Programs}\\
~\newline
\begin{tabular}{| l | l | l | l |}
\hline
\textbf{Routine name} & \textbf{In} & \textbf{Out} & \textbf{Exceptions}\\
\hline
... & ... & ... & ...\\
\hline
\end{tabular}

\end{frame}

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

\begin{frame}
\frametitle{Stack Module Syntax}

\textbf{Exported Access Programs}\\
~\newline
\begin{tabular}{| l | l | l | l |}
\hline
\textbf{Routine name} & \textbf{In} & \textbf{Out} & \textbf{Exceptions}\\
\hline
s\_init & ~ & ~ & ~\\
\hline
s\_push & T & ~ & FULL\\
\hline
s\_pop & ~ & ~ & EMPTY\\
\hline
s\_top & ~ & T & EMPTY\\
\hline
s\_depth & ~ & integer & ~\\
\hline
\end{tabular}

\end{frame}

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

\begin{frame}
\frametitle{Semantics}

\textbf{State Variables}\\
~\newline
\uncover<2->{\structure<2>{$s$: sequence of T}}\\
~\newline
\textbf{State Invariant}\\
~\newline
\uncover<3->{\structure<3>{$|s| \leq \mbox{MAX\_SIZE}$}}\\
~\newline
\textbf{Assumptions}\\
~\newline
\uncover<4->{\structure<4>{s\_init() is called before any other access routine}}\\

\end{frame}

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

\begin{frame}
\frametitle{Access Routine Semantics}

s\_init():
\begin{itemize}
\item transition: \uncover<2->{\structure<2>{$s := <>$}}
\item exception: \uncover<3->{\structure<3>{none}}
\end{itemize}

\noindent s\_push(x):
\begin{itemize}
\item transition: \uncover<4->{\structure<4>{$s := s || <x>$}}
\item exception: \uncover<5->{\structure<5>{$exc := (|s| = \mbox{MAX\_SIZE} \Rightarrow \mbox{FULL})$}}
\end{itemize}

\noindent s\_pop():
\begin{itemize}
\item transition: \uncover<6->{\structure<6>{$s := s[0..|s| - 2]$}}
\item exception: \uncover<7->{\structure<7>{$exc := (|s| = 0 \Rightarrow \mbox{EMPTY})$}}
\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Access Routine Semantics Continued}

\noindent s\_top():
\begin{itemize}
\item output: \uncover<2->{\structure<2>{$out := s[|s| - 1]$}}
\item exception: \uncover<3->{\structure<3>{$exc := (|s| = 0 \Rightarrow \mbox{EMPTY})$}}
\end{itemize}

\noindent s\_depth():
\begin{itemize}
\item output: \uncover<4->{\structure<4>{$out := |s|$}}
\item exception: \uncover<5->{\structure<5>{none}}
\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Stack Module Properties}

$\{ \mathit{true} \}$

~~~~~s\_init()

$\{ | s' | = 0 \}$

~\newline
$\{ | s | < \mbox{MAX\_SIZE} \}$

~~~~~s\_push($x$)

$\{ | s' | = | s | + 1 \wedge s'[|s'| - 1] = x \wedge s'[0..|s|-1] = s[0..|s|-1] \}$

~\newline
$\{ |s| < \mbox{MAX\_SIZE} \}$

~~~~~s\_push($x$)\\
~~~~~s\_pop()

$s' = s$

\end{frame}

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

\begin{frame}
\frametitle{Object Oriented Design}
\begin{itemize}
\item One kind of module, ADT, called class
\item A class exports operations (procedures) to manipulate instance objects (often called methods)
\item Instance objects accessible via references
\item Can have multiple instances of the class (class can be thought of as roughly corresponding to the notion of a type)
\end{itemize}
\end{frame}

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

\begin{frame}
\frametitle{Inheritance}
\begin{itemize}
\item Another relation between modules (in addition to USES and IS\_COMPONENT\_OF)
\item ADTs may be organized in a hierarchy
\item Class B may specialize class A
\begin{itemize}
\item B inherits from A
\item Conversely, A generalizes B
\end{itemize}
\item A is a superclass of B
\item B is a subclass of A
\end{itemize}
\end{frame}

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

\begin{frame}
\frametitle{Template Module Employee}

\begin{tabular}{| l | l | l | l |}
\hline
\textbf{Routine name} & \textbf{In} & \textbf{Out} & \textbf{Except}\\
\hline
Employee & string, string, moneyT & Employee & ~\\
\hline
first\_Name & ~ & string & ~\\
\hline
last\_Name & ~ & string & ~\\
\hline
where & ~ & siteT & ~\\
\hline
salary & ~ & moneyT & ~\\
\hline
fire & ~ & ~ & ~\\
\hline
assign & siteT & ~ & ~\\
\hline
\end{tabular}\\

\end{frame}

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

\begin{frame}
\frametitle{Inheritance Examples}

\textbf{Template Module}
Administrative\_Staff \textbf{inherits} Employee\\
~\newline

\begin{tabular}{| l | l | l | l |}
\hline
\textbf{Routine name} & \textbf{In} & \textbf{Out} & \textbf{Exception}\\
\hline
do\_this & folderT & ~ & ~\\
\hline
\end{tabular}\\
~\newline

\textbf{Template Module}
Technical\_Staff \textbf{inherits} Employee\\
~\newline

\begin{tabular}{| l | l | l | l |}
\hline
\textbf{Routine name} & \textbf{In} & \textbf{Out} & \textbf{Exception}\\
\hline
get\_skill & ~ & skillT & ~\\
\hline
def\_skill & skillT & ~ & ~\\
\hline
\end{tabular}\\

\end{frame}

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

\begin{frame}
\frametitle{Inheritance Continued}

\begin{itemize}
\item A way of building software incrementally
\item Useful for long lived applications because new features can be added without breaking the old applications
\item A subclass defines a subtype
\item A subtype is substitutable for the parent type
\item Polymorphism - a variable referring to type A can refer to an object of type B if B is a subclass of A
\item Dynamic binding - the method invoked through a reference depends on the type of the object associated with the
reference at runtime
\item All instances of the sub-class are instances of the super-class, so the type of the sub-class is a subtype
\item All instances of Administrative\_Staff and Technical\_Staff are instances of Employee
\end{itemize}
\end{frame}

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

% \begin{frame}
% \frametitle{Inheritance Continued}

% emp1, emp2: Employee\\
% emp3: Technical\_Staff\\

% emp1 = Administrative\_Staff() \uncover<2->{\structure{$\surd$}}\\
% emp2 = Technical\_Staff() \uncover<3->{\structure{$\surd$}}\\
% emp3 = emp1 \uncover<4->{\structure{$\times$}}\\
% emp3 = (Technical\_Staff) emp1 \uncover<5->{\structure{$\surd$}}\\
% ~\newline
% \uncover<6->{Polymorphism: type of RHS must be a subtype of the LHS}
% \end{frame}

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

\begin{frame}
\frametitle{Dynamic Binding}

\begin{itemize}
\item Many languages, like C, use static type checking
\item OO languages use dynamic type checking as the default
\item There is a difference between a \structure{type} and a \structure{class} once we know this
\begin{itemize}
\item Types are known at compile time
\item The class of an object may be known only at run time
\end{itemize}
\end{itemize}
\end{frame}

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

\begin{frame}
\frametitle{Point ADT Module}

\textbf{Template Module}\\
~\newline
PointT\\
~\newline
\textbf{Uses}\\
~\newline
N/A\\
~\newline
\textbf{Syntax}\\
~\newline
\textbf{Exported Types}\\
~\newline
PointT = ?\\

\end{frame}

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

\begin{frame}
\frametitle{Point ADT Module Continued}

\textbf{Exported Access Programs}\\
~\newline
\begin{tabular}{| l | l | l | l |}
\hline
\textbf{Routine name} & \textbf{In} & \textbf{Out} & \textbf{Exceptions}\\
\hline
new PointT & real, real & PointT & ~\\
\hline
xcoord & ~ & real & ~\\
\hline
ycoord & ~ & real & ~\\
\hline
dist & PointT & real & ~\\
\hline
\end{tabular}

~\newline
\textbf{Semantics}\\
~\newline
\textbf{State Variables}\\
~\newline
$xc$: real\\
$yc$: real

\end{frame}

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

\begin{frame}
\frametitle{Point Mass ADT Module}

\textbf{Template Module}\\
~\newline
PointMassT \textbf{inherits} PointT\\
~\newline
\textbf{Uses}\\
~\newline
PointT\\
~\newline
\textbf{Syntax}\\
~\newline
\textbf{Exported Types}\\
~\newline
PointMassT = ?\\

\end{frame}

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

\begin{frame}
\frametitle{Point Mass ADT Module Continued}

\textbf{Exported Access Programs}\\
~\newline
\begin{tabular}{| l | l | l | l |}
\hline
\textbf{Routine name} & \textbf{In} & \textbf{Out} & \textbf{Exceptions}\\
\hline
new PointMassT & real, real, real & PointMassT & NegMassExcep\\
\hline
mval & ~ & real & ~\\
\hline 
force & PointMassT & real & ~\\
\hline
fx & PointMassT & real & ~\\
\hline
\end{tabular}

~\newline
\textbf{Semantics}\\
~\newline
\textbf{State Variables}\\
~\newline
$ms$: real

\end{frame}

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

\begin{frame}
\frametitle{Point Mass ADT Module Semantics}

\noindent new PointMassT($x, y, m$):
\begin{itemize}
\item transition: $xc, yc, ms := x, y, m$
\item output: $out := \mathit{self}$
\item exception: $exc := (m < 0 \Rightarrow \mbox{NegativeMassException})$
\end{itemize}
~\newline
\noindent force($p$):
\begin{itemize}
\item output: $$out := \mathrm{UNIVERAL\_G} \frac{\mathit{self}.ms \times p.ms}
{\mathit{self}.\mathrm{dist}(p)^2}$$
\item exception: none
\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Examples}

\begin{itemize}
\item Example Point Line and Circle
\item Example Robot Path
\item Example Vector Space
\item Example Othello Program
\item Example Maze Formal Specification (Dr.\ v.\ Mohrenschildt)
\item Mustafa ElSheikh Mesh Generator \cite{CaretteEtAl2011}
\item Wen Yu Mesh Generator \cite{SmithAndYu2009}
\item Sven Barendt Filtered Backprojection
\item Sanchez sDFT
\end{itemize}

\end{frame}

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

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

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

\end{frame}

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

\end{document}