diff --git a/Lectures/L13_ModuleDecomposition/ModuleDecomposition.pdf b/Lectures/L13_ModuleDecomposition/ModuleDecomposition.pdf index 2738ea931ca75b701f13ec91b2557f71f4c45709..c736c13cd5a9c63984b9881afc40b1ca814edf34 100644 Binary files a/Lectures/L13_ModuleDecomposition/ModuleDecomposition.pdf and b/Lectures/L13_ModuleDecomposition/ModuleDecomposition.pdf differ diff --git a/Lectures/L13_ModuleDecomposition/ModuleDecomposition.tex b/Lectures/L13_ModuleDecomposition/ModuleDecomposition.tex index 15127b459b07d1f85d842f5320c6d8c7a61e89de..7d0c408a1b9d5ee3e360788bb4f41cc5f87715b3 100755 --- a/Lectures/L13_ModuleDecomposition/ModuleDecomposition.tex +++ b/Lectures/L13_ModuleDecomposition/ModuleDecomposition.tex @@ -13,6 +13,8 @@ \usepackage{booktabs} +\usepackage{listings} + \useoutertheme{split} %so the footline can be seen, without needing pgfpages % \pgfpagesuselayout{resize to}[letterpaper,border @@ -36,6 +38,9 @@ \input{../footline} +\lstset{language=python, breaklines=true, showspaces=false, + showstringspaces=false, breakatwhitespace=true, texcl=true, escapeinside={\%*}{*)}} + %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \begin{frame} @@ -98,6 +103,96 @@ TBD %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\begin{frame}[fragile] +\frametitle{Example Subclass Exception in Python} +\ttfamily +\begin{lstlisting} +class Full(Exception): + def __init__(self, value): + self.value = value + def __str__(self): + return str(self.value) +\end{lstlisting} +\sffamily + +Example of raising the exception + +\ttfamily +\begin{lstlisting} + if size == Seq.MAX_SIZE: + raise Full("Maximum size exceeded") +\end{lstlisting} +\sffamily + +\end{frame} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\begin{frame} + +\frametitle{Exception Signaling} + +\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{Assumptions versus Exceptions}