Lectures/Deadlines.tex

@@ -6,8 +6,8 @@
 \begin{tabular}{l l l}
 %{Problem Statement} & Week 02 & Jan 17\\
 %{System Req.\ Spec.\ (SRS)} & Week 04 & Feb 05\\
-\textbf{System VnV Plan} & Week 06 & Feb 14\\
-{MG + MIS} & Week 09 & Mar 14\\
+%\textbf{System VnV Plan} & Week 06 & Feb 26\\
+%{MG + MIS} & Week 10 & Mar 19\\
 %{Drasil Code} & Week 09 & Mar 14\\
 {Final Documentation} & Week 13 & Apr 11\\
 \end {tabular}
@@ -33,10 +33,10 @@ traditional SRS
 ~\newline
 \begin{tabular}{l l}
 %{SRS} & Week 03/04\\
-\textbf{Syst.\ VnV} & Week 06\\
-{POC Demo} & Week 07\\
-{MG + MIS} & Week 09\\
-Drasil & Week 11 \\
+%\textbf{Syst.\ VnV} & Week 06\\
+%{POC Demo} & Week 08\\
+%{MG + MIS} & Week 10\\
+%Drasil & Week 11 \\
 Unit VnV/Implement & Week 12 \\
 \end {tabular}
 
@@ -59,7 +59,7 @@ take it personally
 \begin{frame}
 \frametitle{Presentation Schedule}
 
-\bi
+%\bi
 
 % \item SRS Present (15 min)
 % \bi
@@ -69,22 +69,22 @@ take it personally
 % \item {Feb 4: Alaap, Yinying}
 % \ei
 
-\item Syst V\&V Plan Present (L11, L12) (20 min)
-\bi
-\item \textbf{Feb 14: Yasmin, Qianlin, Junwei, Joe}
-\item \textbf{Feb 25: Yinying, Bo, Hussein, Yuanqi (Volunteer)}
-\ei
-\item Proof of Concept Demonstrations (L14) (20 min)
-\bi
-\item \textbf{Mar 4:  Christopher, Uriel,  Volunteer?, Volunteer?}
-\ei
-\item MG+MIS Present (L17, L18) (20 minutes)  %(Drasil SRS Code)
-\bi
-\item {Mar 11: Ziyang, Aliyah, Yuanqi, Alaap}
-\item {Mar 14: Phillip, Baptiste, Kiran, Volunteer?}
-\ei
+%\item Syst V\&V Plan Present (L11, L12) (20 min)
+% \bi
+% \item {Feb 14: Qianlin, Junwei, Joe, Volunteer?}
+% \item {Feb 25: Yinying, Bo, Hussein, Volunteer?}
+% \ei
+%\item Proof of Concept Demonstrations (L14) (20 min)
+%\bi
+%\item {Mar 4:  Christopher, Uriel,  Volunteer?, Volunteer?}
+%\ei
+% \item MG+MIS Present (L17, L18) (20 minutes)  %(Drasil SRS Code)
+% \bi
+% \item {Mar 14: Ziyang, Aliyah, Yuanqi, Alaap}
+% \item {Mar 18: Phillip, Baptiste, Kiran, Volunteer?}
+% \ei
 
-\ei
+%\ei
 
 \end{frame}
 
@@ -96,10 +96,10 @@ take it personally
 \bi
 \item Implementation Present (L22 -- L25) (20 min each)
 \bi
-\item {Mar 28: Yasmin, Aliyah, Uriel, Ziyang}
-\item {Apr 1: Yuanqi, Christopher, Bo, Joe}
-\item {Apr 4: Junwei, Hussein, Kiran, Alaap}
-\item {Apr 8: Qianlin, Yinying, Baptiste, Phillip}
+\item \textbf{Mar 28: Aliyah, Uriel, Ziyang, Yuanqi}
+\item \textbf{Apr 1: Christopher, Bo, Joe, Junwei}
+\item \textbf{Apr 4: Hussein, Kiran, Alaap, Qianlin}
+\item \textbf{Apr 8: Yinying, Baptiste, Phillip}
 \ei
 \ei
 

Lectures/L04_ReqContinued/ReqContinued.tex

@@ -1150,6 +1150,38 @@ to improve reliability
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
+\begin{frame}
+\frametitle{Feedback From Previous Years}
+\begin{itemize}
+\item Remember that you are writing the document for someone other than yourself
+\item Introduction section gives the name for the software/library
+\item Use \texttt{citep} and \texttt{citet} for \texttt{natbib}
+\item When the assumptions are listed, traceability is given to where they are
+used
+\item If assumptions are not used, then they may not be necessary, or they might
+be scope decisions
+\item For NFRs, specify what you want, not how to achieve it
+\item NFRs can point to the VnV plan for details (to make them unambiguous)
+\end{itemize}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Feedback From Previous Years}
+\begin{itemize}
+\item For reader/user characteristics, give the target course and what level it is taught.  (Use a generic name, not a specific course name.)
+\item Rationale provided for assumptions, scope decisions and constraints
+\item Include a reference to the source of the template you are using
+\item Requirements should trace to IMs
+\item Define all symbols in table of contents and in Description field
+\end{itemize}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
 \begin{frame}[allowframebreaks]
 \frametitle{References}
 

Lectures/L09_VerificationAndValidation/VerificAndValid.tex

@@ -490,7 +490,7 @@ From \cite{GhezziEtAl2003}
 
 \item \structure{If our code passes all test cases, is it now guaranteed to be
     error free?}
-\item \structure{Are 5000 random tests always better than 5 carefully selected
+\item \structure{Are 5000 random tests always better than 15 carefully selected
     tests?}
 
 \end{itemize}

Lectures/L10_VnVContinued/VnVContinued.tex

@@ -93,7 +93,8 @@
 \begin{itemize}
 \item
 \href{https://gitlab.cas.mcmaster.ca/smiths/cas741/-/commit/0bdea9edc7464bb57c2f3524bebfd4f3b59cdc80}
-{Some Domain Expert and Secondary Expert assignments have changed}
+{Some Domain Expert assignments have changed}
+\item Yasmin dropped the course, so Bo will need to find another project to evaluate
 \end{itemize}
 \end{frame}
 
@@ -111,6 +112,71 @@
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
+\begin{frame}
+\frametitle{Goals of Testing}
+
+\begin{itemize}
+
+\item \structure{If our code passes all test cases, is it now guaranteed to be
+    error free?}
+\item \structure{Are 5000 random tests always better than 15 carefully selected
+    tests?}
+
+\end{itemize}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Goals of Testing}
+
+\begin{itemize}
+
+\item To show the \structure{presence} of bugs (Dijkstra, 1972)
+\item If tests do not detect failures, we cannot conclude that software is defect-free
+\item Still, we need to do testing - driven by sound and systematic principles
+\begin{itemize}
+\item Random testing is often not a systematic principle to use
+% look at the example from the text, or divide by zero within a circular range
+\item Need a test plan
+\end{itemize}
+\item Should help isolate errors - to facilitate debugging
+
+\end{itemize}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Goals of Testing Continued}
+
+\begin{itemize}
+\item Should be repeatable
+\begin{itemize}
+\item Repeating the same experiment, we should get the same results
+\item Repeatability may not be true because of the effect of the execution
+  environment on testing
+\item Repeatability may not occur if there are uninitialized variables
+\item Repeatability may not happen when there is nondeterminism
+\end{itemize}
+
+\item Should be accurate
+\begin{itemize}
+\item Accuracy increases reliability
+\item Part of the motivation for formal specification
+\end{itemize}
+
+\item \structure{Is a \structure{successful} test case one that passes the test, or one
+  that shows a failure?}
+
+\end{itemize}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
 \begin{frame}
 \frametitle{Test (V\&V) Plan}
 
@@ -1015,6 +1081,7 @@ Summary of most points below in \cite{Smith2016}
 \href{https://www.evoketechnologies.com/code-review-checklist-perform-effective-code-reviews/}{Sample
 checklists}
 \ei
+\item \href{https://gitlab.cas.mcmaster.ca/SEforSC/se4sc/-/blob/git-svn/GradStudents/Cynthia/M.EngReport/Thesis_Main.pdf?ref_type=heads} {Cynthia Liu's SC Requirements Validation Techniques}
 \end{itemize}
 \end{frame}
 

Lectures/L13_ModularDesign/ModularDesign.tex

@@ -64,6 +64,7 @@
 \bi
 \item For the design documentation you do not have to use the MG and 
 MIS templates
+\item No lecture on Friday, March 21
 %\item GitHub issues
 %\bi
 % \item When closing issues give the hash for the corresponding commit
@@ -89,44 +90,44 @@ MIS templates
 \input{../Deadlines.tex}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\begin{frame}
-\frametitle{Feedback on SRS}
-\begin{itemize}
-\item
-\href{https://github.com/smiths/capTemplate/blob/main/docs/Checklists/SRS-Checklist.pdf}
-{SRS checklist}
-\begin{itemize}
-  \item Follow the template
-  \item Filename for SRS from template (new)
-  \item All symbols are in the table of contents
-  \item Project is given a name
-  \item Characteristics with courses and level (clarified)
-  \item Goal statements are functional (new)
-  \item Each assumption is used at least once
-  \item All chunks are used at least once (new)
-  \item IMs are referenced by requirements
-\end{itemize}
-\end{itemize}
-\end{frame}
+% \begin{frame}
+% \frametitle{Feedback on SRS}
+% \begin{itemize}
+% \item
+% \href{https://github.com/smiths/capTemplate/blob/main/docs/Checklists/SRS-Checklist.pdf}
+% {SRS checklist}
+% \begin{itemize}
+%   \item Follow the template
+%   \item Filename for SRS from template (new)
+%   \item All symbols are in the table of contents
+%   \item Project is given a name
+%   \item Characteristics with courses and level (clarified)
+%   \item Goal statements are functional (new)
+%   \item Each assumption is used at least once
+%   \item All chunks are used at least once (new)
+%   \item IMs are referenced by requirements
+% \end{itemize}
+% \end{itemize}
+% \end{frame}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
-\begin{frame}
-\frametitle{Feedback on SRS}
-\begin{itemize}
-\item
-\href{https://github.com/smiths/capTemplate/blob/main/docs/Checklists/Writing-Checklist.pdf}
-{Writing checklist}
-\begin{itemize}
-  \item Opening and closing ``quotes''
-  \item Periods that do not end sentences are followed by only one space
-  \item Long names in math mode use either mathit or text
-  \item Document is spell checked
-  \item Symbols formatted the same way in every context %inside and outside equations
-\end{itemize}
-\item Types information very helpful
-\end{itemize}
-\end{frame}
+% \begin{frame}
+% \frametitle{Feedback on SRS}
+% \begin{itemize}
+% \item
+% \href{https://github.com/smiths/capTemplate/blob/main/docs/Checklists/Writing-Checklist.pdf}
+% {Writing checklist}
+% \begin{itemize}
+%   \item Opening and closing ``quotes''
+%   \item Periods that do not end sentences are followed by only one space
+%   \item Long names in math mode use either mathit or text
+%   \item Document is spell checked
+%   \item Symbols formatted the same way in every context %inside and outside equations
+% \end{itemize}
+% \item Types information very helpful
+% \end{itemize}
+% \end{frame}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -242,12 +243,12 @@ MIS templates
 \begin{frame}
 \frametitle{SWHS MG Example}
 ~\\
-\href{https://github.com/smiths/swhs/blob/master/docs/Design/MG/PCM_MG.pdf}
-{https://github.com/smiths/swhs/blob/master/docs/Design/MG/PCM_MG.pdf}
+
+\href{https://github.com/smiths/swhs/blob/master/docs/Design/MG/PCM_MG.pdf} {Module Guide for Solare Water Heating System Incorporating Phase Change Material (PCM)} 
+
 \end{frame}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
 \begin{frame}
 \frametitle{What is Design?}
 \begin{itemize}

Lectures/L15_MIS/MIS.tex

@@ -45,11 +45,10 @@
 \frametitle{Module Interface Specification (MIS)}
 
 \bi
-\item ADD STRATEGY DESIGN PATTERN
 \item Administrative details
 \item Questions?
-%\item Finish previous day slides
-\item Module guide example
+%\item Module guide example
+\item Mathematical fundamentals
 \item MIS example
 \item Integration testing
 \item MIS overview
@@ -67,28 +66,12 @@
 \frametitle{Administrative Details}
 
 \bi
-% \item When developing your code, remember that your goal is for someone else to
-%   be able to compile and run it
-% \item Upcoming classes
-% \bi
-% \item L15 - Module Interface Specification
-% \item L16 - Math Review + MIS
-% \item L17 - POC + MG Presentations
-% \item L18 - MIS Presentations
-% \ei
-\item Friday's class in ITB/201
-\item Mathematical review
-\begin{itemize}
-  \item \cite{HoffmanAndStrooper1995}
-  \item \href{https://gitlab.cas.mcmaster.ca/smiths/cas741/-/tree/master/Lectures/MathReviewPlusExample} {Review Slides}
-  \item \href{https://gitlab.cas.mcmaster.ca/smiths/se2aa4_cs2me3/-/blob/master/MISFormat/MISFormat.pdf} {MIS Format}
-\end{itemize}
 \item Potential software for drawing figures
 \bi
 \item \href{https://app.diagrams.net/} {draw.io}
 \item \href{https://www.bu.edu/math/files/2013/08/tikzpgfmanual.pdf} {Tikz} 
 \ei
-\item Go over final grading rubric, traceability Rev0 to Rev1
+%\item Go over final grading rubric, traceability Rev0 to Rev1
 \ei
 
 \end{frame}
@@ -142,10 +125,29 @@
 \begin{frame}
 \frametitle{Emphasis}
 \begin{itemize}
-\item Math notation (stoichiometry example on Friday)
-\item GUI modules (environment variables)
+\item Math notation
+\item Modules with external interaction (environment variables)
 \item Types of modules
 \item Abstract Data Types (graph example)
+\item Qualities of an interface
+\item Design patterns
+\begin{itemize}
+  \item Adapter (Wrapper) pattern
+  \item Strategy pattern
+\end{itemize}
+\end{itemize}
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Mathematical review}
+
+\begin{itemize}
+  \item Hoffman and Strooper (1995) \cite{HoffmanAndStrooper1995}
+  \item \href{https://gitlab.cas.mcmaster.ca/smiths/se2aa4_cs2me3/-/blob/master/MISFormat/MISFormat.pdf} {MIS Format}
+  \item \href{https://gitlab.cas.mcmaster.ca/smiths/cas741/-/tree/master/Lectures/MathReviewPlusExample} {Stoichiometry Example} %not a great approach, can tell by bad names
+  \item MoleculeT = seq[108] of $\mathbb{N}$
 \end{itemize}
 \end{frame}
 

Lectures/L16_MISContinued/MISContinued.tex

@@ -45,6 +45,7 @@
 \frametitle{MIS Continued}
 
 \bi
+\item ADD STRATEGY DESIGN PATTERN
 \item Administrative details
 \item Questions?
 \item Review: Records, Libraries, ADTs, Abstract Objects, Generic ADTs
@@ -94,6 +95,24 @@
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
+\begin{frame}
+\frametitle{Emphasis}
+\begin{itemize}
+\item Math notation
+\item Modules with external interaction (environment variables)
+\item Types of modules
+\item Abstract Data Types
+\item Qualities of an interface
+\item Design patterns
+\begin{itemize}
+  \item Adapter (Wrapper) pattern
+  \item Strategy pattern
+\end{itemize}
+\end{itemize}
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
 % \begin{frame}
 % \frametitle{Nonfunctional Requirements}
 % \begin{itemize}
@@ -1084,6 +1103,217 @@ where $a$, $b$ and $c$ are suitable constants
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
+\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{Adapter Design Pattern}
+
+\includegraphics[scale=0.7]{500px-AdapterPatternForWiki.jpg}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Adapter UML Diagram}
+% client uses target (follows targets interface)
+% client, adapter and adaptee appear as in previous slide
+\medskip
+\includegraphics[scale=0.7]{adapter_clip.pdf}
+
+\href{https://en.wikipedia.org/wiki/Adapter_pattern}
+{Wikipedia entry}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{SimUDuck Example}
+
+\bigskip
+
+\includegraphics[scale=0.74]{StratPat-SimUDuck.pdf}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Adding a Fly Method}
+
+\bigskip
+
+\includegraphics[scale=0.85]{StratPat-FlyMethod.pdf}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Rubber Duck Problem}
+
+\includegraphics[scale=0.7]{StratPat-RubberDuck.pdf}
+
+\structure{How to stop rubber ducks from flying?} %override to do nothing
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Rubber Duck Problem Continued}
+
+\bi
+\item Solve problem by overriding the fly() method to do nothing
+\item Not a good solution - think of the potential maintenance problems if we
+  add wooden decoys, which cannot fly, or quack - what about different quacks?
+\ei
+
+Which of the following are disadvantages of using inheritance to provide Duck
+behaviour?
+
+\begin{enumerate}[A.]
+\item Some code is duplicated across subclasses
+\item Runtime behaviour changes are difficult
+\item Difficult to gain knowledge of all duck behaviours
+\item Changes can unintentionally affect other ducks
+\item All of the above %answer
+\end{enumerate}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{How About an Interface?}
+
+\includegraphics[scale=0.75]{StratPat-Interface.pdf}
+
+Disadvantages of interface?
+
+\begin{enumerate}[A.]
+\item Maintenance nightmare - the different options for fly and quack are
+  duplicated everywhere %answer
+\item Ducks that have fly and quack are clearly shown
+\item All of the above
+\end{enumerate}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Information Hiding}
+
+How can the principle of information hiding help us?
+
+\begin{enumerate}[A.]
+\item Identify the aspects of the application that are likely to change and
+  separate them from what is unlikely to change
+\item Provide a means for part of the system to vary independently of the other
+  parts
+\item Prevent the program's user from knowing which ducks can fly and/or quack
+\item A and B %answer
+\item A, B and C
+\end{enumerate}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Separate Out Changeable Parts (Likely Changes)}
+
+\bigskip
+
+\includegraphics[scale=0.85]{StratPat-DuckBehaviours.pdf}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Implementing the Duck Behaviours}
+
+\bigskip
+
+\includegraphics[scale=0.66]{StratPat-ImpDuckBehaviours.pdf}
+
+\bi
+\item Program to an interface not an implementation (interface in the sense we have
+used it for MISes, not just a Java interface)
+\item Other modules can use these behaviours too
+\item Can add new behaviours without touching the original Duck class
+\ei
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{The Big Picture}
+
+\bigskip
+
+\includegraphics[scale=0.66]{StratPat-BigPicture.pdf}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Often Favour Composition over Inheritance}
+
+\bi
+\item Composition provides a ``has a'' relationship, as opposed to an ``is a''
+  relationship
+\item Composition provides greater flexibility
+\item Composition allows changing behaviour at runtime
+\item Many languages (like Java) do not allow multiple inheritance, but can have
+  multiple compositions
+\ei
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\begin{frame}
+\frametitle{Strategy Pattern}
+
+Defines a family of algorithms, encapsulates each one, and makes them
+interchangeable.  Strategy lets the algorithm vary independently from the
+clients that use it.
+
+\includegraphics[scale=0.6]{Strategy1.png}
+
+\end{frame}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
 \begin{frame}[allowframebreaks]
 \frametitle{References}