<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">%\documentclass[t,12pt,numbers,fleqn,handout]{beamer}
\documentclass[t,12pt,numbers,fleqn]{beamer}

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

\usepackage{hhline}
\usepackage{booktabs}
\usepackage{multirow}
\usepackage{multicol}
\usepackage{array}
\usepackage{listings}

\usepackage{amssymb}
\usepackage{amsmath}

\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&lt;presentation&gt;{}

\input{../def-beamer}
\Draftfalse

\newcommand{\topicTitle}{27 Design Patterns}
\ifDraft
\newcommand{\topic}{\topicTitle~DRAFT}
\else
\newcommand{\topic}{\topicTitle}
\fi

\input{../titlepage}
\Draftfalse

\begin{document}

\input{../footline}

\lstset{language=java, breaklines=true, showspaces=false,
  showstringspaces=false, breakatwhitespace=true}

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

\begin{frame}
\frametitle{\topic}

\begin{itemize}
\item Administrative details
\item Specification using UML
\item Design patterns
\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Administrative Details}

\ifDraft  
TBD
\else
{
\begin{itemize}

\item Today's slide are partially based on slides by Dr.\ Wassyng and on van Vliet (2000)

\item A3
\begin{itemize}
\item Part 1 - Solution: Mar 18 
\item Part 2 - Code: due 11:59 pm Mar 26
\end{itemize}

\item A4
\bi
\item Your own design and specification
\item Model module for game of Freecell
\item Due April 9 at 11:59 pm
\ei

\end{itemize}
}
\fi

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

\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{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 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{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{Design Patterns}

\begin{itemize}

\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.''
\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
\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Strategy Design Pattern}

\bi
\item From \href{https://sourcemaking.com/design_patterns/strategy}{Source
    Making web-page}
\item Define a family of algorithms, encapsulate each one, and make them
  interchangeable. 
\item Strategy lets the algorithm vary independently from the clients that use
  it.
\item Capture the abstraction in an interface, bury implementation details in
  derived classes.
\item \structure{Where have we used this pattern?}
\ei

\end{frame}

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

\begin{frame}
\frametitle{UML Diagram of Measurable Interface}

\medskip
\medskip

\includegraphics[scale=0.85]{../Figures/MeasurableInterface.pdf}

\end{frame}

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

\begin{frame}
\frametitle{UML Diagram of Measurer Interface}

\includegraphics[scale=0.6]{../Figures/UMLDataSetMeasurerInterface.pdf}

\end{frame}

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

\begin{frame}
\frametitle{Model View Controller (MVC)}

\begin{itemize}

\item Separate computational elements from I/O elements
\item Three components
\begin{enumerate}
\item Model encapsulates the system's data as well as the operations on the data
\item View displays the data from the model components, possibly multiple view components
\item Controller handles input actions
\end{enumerate}
\item The controller may or may not depend on the state of the model
\item The controller depends on model state when menu items are enabled or disabled depending on the state of the model
\end{itemize}

\end{frame}

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

\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}
~\\
From /Tutorials/OLD\_MVC

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

\begin{itemize}

\item A pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it
\item A pattern must balance a set of opposing forces
\item Patterns document existing, well-proven design experience
\item Patterns identify and specify abstractions above the level of single components (modules)
\item Patterns provide a common vocabulary and understanding for design principles
\item Patterns are a means of documentation
\item Patterns support the construction of software with defined properties, including non-functional requirements, such as flexibility and maintainability
\end{itemize}

\end{frame}

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

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

\begin{itemize}

\item Context: the situation giving rise to a design pattern
\item Problem: a recurring problem arising in that situation
\item Solution: a proven solution to that problem

\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{The Proxy Pattern (from van Vliet (2000))}

\begin{itemize}

\item Context: A client needs services from another component.  Though direct access is possible, this may not be the best approach
\item Problem: We do not want to hard-code access to a component into a client.  Sometimes, such direct access is
inefficient; in other cases it may be unsafe.  This inefficiency or insecurity is to be handled by additional control
mechanisms, which should be kept separate from both the client and the component to which it needs access.
\item Solution: The client communicates with a representative rather than the component itself.  This representative, the
\structure{proxy}, also does and pre- and postprocessing that is needed.
\item \href{https://en.wikipedia.org/wiki/Proxy_pattern}{Code}
\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{UML Diagram of Proxy}

\includegraphics[scale=0.5]{../Figures/Proxy_pattern_diagram.png}

\end{frame}

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

\begin{frame}
\frametitle{Command Processor Pattern}

\begin{itemize}

\item Context: User interfaces which must be flexible or provide functionality that goes beyond the direct handling of
user functions.  Examples are undo facilities or logging functions
\item Problem: We want a well-structured solution for mapping an interface to the internal functionality of a system. 
All `extras' which have to do with the way user commands are input, additional commands such as undo and redo, and any
non-application-specific processing of user commands, such as logging, should be kept separate from the interface to
the internal functionality.

\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Command Processor Pattern Continued}

\begin{itemize}

\item Solution: A separate component, the \structure{command processor}, takes care of all commands.  The command
processor component schedules the execution of commands, stores them for later undo, logs them for later analysis, and
so on.  The actual execution of the command is delegated to a supplier component within the application.

\end{itemize}

\end{frame}

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

\begin{frame}
\frametitle{Command in UML}

\includegraphics[scale=0.8]{../Figures/command.png}
~\\
\href{http://www.dofactory.com/net/command-design-pattern}{http://www.dofactory.com/net/command-design-pattern}

\end{frame}

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

\begin{frame}
\frametitle{Adapter Design Pattern}

\structure{When have we used the adapter (or wrapper) design pattern?}

\end{frame}

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

\begin{frame}
\frametitle{Adapter Design Pattern}

\includegraphics[scale=0.7]{../Figures/500px-AdapterPatternForWiki.jpg}

Adapter wraps one class

\end{frame}

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

\begin{frame}
\frametitle{Factory Pattern}

\includegraphics[scale=0.55]{../Figures/factory_pattern_uml_diagram.jpg}

\href{https://www.tutorialspoint.com/design_pattern/factory_pattern.htm}{Code}

\end{frame}

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

\begin{frame}
\frametitle{Singleton Pattern}

\includegraphics[scale=1.7]{../Figures/Singleton.jpg}

\end{frame}

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

\end{document}

</pre></body></html>