Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
C
cas741
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Requirements
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Locked files
Build
Pipelines
Jobs
Pipeline schedules
Test cases
Artifacts
Deploy
Releases
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Code review analytics
Issue analytics
Insights
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
W. Spencer Smith
cas741
Commits
7f413d62
Commit
7f413d62
authored
4 years ago
by
W. Spencer Smith
Browse files
Options
Downloads
Patches
Plain Diff
Updates to lecture introducing modular design, module guide
parent
a5229691
No related branches found
Branches containing commit
No related tags found
No related merge requests found
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
Lectures/L13_ModularDesign/ModularDesign.pdf
+0
-0
0 additions, 0 deletions
Lectures/L13_ModularDesign/ModularDesign.pdf
Lectures/L13_ModularDesign/ModularDesign.tex
+144
-98
144 additions, 98 deletions
Lectures/L13_ModularDesign/ModularDesign.tex
with
144 additions
and
98 deletions
Lectures/L13_ModularDesign/ModularDesign.pdf
+
0
−
0
View file @
7f413d62
No preview for this file type
This diff is collapsed.
Click to expand it.
Lectures/L13_ModularDesign/ModularDesign.tex
+
144
−
98
View file @
7f413d62
...
...
@@ -31,7 +31,7 @@
\input
{
../def-beamer
}
\newcommand
{
\topic
}{
13
Modular Design
}
\newcommand
{
\topic
}{
Modular Design
}
\input
{
../titlepage
}
...
...
@@ -45,9 +45,10 @@
\frametitle
{
Modular Design
}
\bi
\item
Start recording
\item
Administrative details
\item
Questions?
%
\item Feedback on
SRS
\item
Feedback on
issues
\item
Overview of design
\item
Modular decomposition: advantages, guidelines etc.
\item
Module guide
...
...
@@ -73,8 +74,9 @@
\item
Grading as before
\item
Create issues within 2 days of being assigned the task by the project's author
\ei
\item
Template for MG available in repo
\item
Optional presentation slots available - first come first served
\item
Template for MG and MIS available in repo
\item
Some edits to the SRS template and FAQ (see diffs)
%\item Optional presentation slots available - first come first served
%\item Grading scheme for VnV now available on Avenue
%\item Template for MG updated in repo
\ei
...
...
@@ -86,18 +88,21 @@
\begin{frame}
\frametitle
{
Administrative Details: Report Deadlines
}
~
\newline
\begin{tabular}
{
l l l
}
System VnV Plan
&
Week 08
&
Oct 28
\\
MG + MIS
&
Week 10
&
Nov 25
\\
Final Documentation
&
Week 14
&
Dec 9
\\
\begin{tabular}
{
l l
}
%\textbf{SRS} & Oct 8\\
\textbf
{
System VnV Plan
}
&
Oct 29
\\
MG + MIS (Traditional)
&
Nov 19
\\
Drasil Code and Report (Drasil)
&
Nov 19
\\
Final Documentation
&
Dec 9
\\
\end
{
tabular
}
\bi
\item
The written deliverables will be graded based on the repo contents as of
11:59 pm of the due date
\item
If you need an extension, please ask
\item
If you need an extension for a written deliverable, please ask
\item
You should inform your primary and secondary reviewers of the extension
\item
Two days after each major deliverable, your GitHub issues will be due
\item
Domain expert code due 1 week after MIS deadline
%
\item Domain expert code due 1 week after MIS deadline
\ei
\end{frame}
...
...
@@ -105,20 +110,26 @@ Final Documentation & Week 14 & Dec 9\\
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle
{
Administrative Details: Presentations
}
~
\newline
\begin{tabular}
{
l l l
}
MG + MIS Syntax Present
&
Week 9
&
Week of Nov 4
\\
MIS Semantics Present
&
Week 11
&
Week of Nov 18
\\
Unit VnV or Impl.
\
Present
&
Week 12/13
&
Week of Nov 28
\\
\end
{
tabular
}
\frametitle
{
Admin Details: Presentation Schedule
}
\bi
\item
Informal presentations with the goal of improving everyone's written
deliverables
\item
Domain experts and secondary reviewers (and others) will ask questions
(listed in Repos.xlsx file)
\item
Proof of Concept Demonstrations (15 min)
\bi
\item
\textbf
{
Mon, Nov 2: Sid, Shayan, Leila, Xingzhi, Liz
}
\item
Thurs, Nov 12: Salah, John
\ei
\item
MG Present (10 minutes)
\bi
\item
Thurs, Nov 12: John, Tiago, Leila, Xuanming, Andrea
\ei
\item
MIS Present
\bi
\item
Mon, Nov 16: Shayan, Parsa, Gaby, Sid, Xingzhi
\ei
\item
Drasil Project Present (20 min each)
\bi
\item
Thurs, Nov 26: Andrea, Naveen, Ting-Yu
\ei
\ei
\end{frame}
...
...
@@ -126,39 +137,55 @@ Unit VnV or Impl.\ Present & Week 12/13 & Week of Nov 28\\
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle
{
Administrative Details:
Presentation Schedule
}
\frametitle
{
Presentation Schedule
Continued
}
\bi
\item
MG + MIS Syntax Present
\bi
\item
Monday: Deema, Bo, ?
\item
Thursday: Sasha, ?, ?
\ei
\item
MIS Syntax + Semantics Present
\bi
\item
Monday: Zhi, Peter, ?
\item
Thursday: Sharon, Ao, ?
\ei
\item
Unit VnV Plan or Impl.
\
Present
\item
Test or Impl.
\
Present (15 min each)
\bi
\item
Monday: Bo, Sasha, ?
\item
Thursday: Zhi, Peter, Ao, ?
\item
Mon, Nov 30: John, Salah, Liz, Xingzhi, Leila
\item
Thurs, Dec 3: Shayan, Naveen, Sid, Gaby, Seyed
\item
Mon, Dec 7: Ting-Yu, Xuanming, Mohamed, Andrea, Tiago
\ei
\item
4 presentations each
\item
If you will miss a presentation, please trade with someone else
\ei
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle
{
Questions?
}
\begin{itemize}
\item
\structure
{
Questions about Verification and Validation plan?
}
\item
\structure
{
Questions about Proof of Concept demos?
}
\item
\structure
{
Other questions?
}
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle
{
Feedback on SRS Issues
}
\begin{itemize}
\item
Close issues when they are resolved
\bi
\item
Explain why closing the issue
\bi
\item
Maybe you will just address the issue in a comment
\item
Maybe the issue will lead to repo changes
\ei
\item
Include the commit hash (you just need the number)
\item
Small, well-defined, commits
\item
Link to other issues using hash symbol
\ei
\item
Take and give feedback in the collegial spirit, use emojis as appropriate
\item
If your project doesn't have a name, give it one
\end{itemize}
\end{frame}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \begin{frame}
% \frametitle{Feedback on SRS}
% \begin{itemize}
...
...
@@ -231,7 +258,8 @@ Unit VnV or Impl.\ Present & Week 12/13 & Week of Nov 28\\
\begin{itemize}
\item
Different goals will lead to different designs
\item
There is a mix of art and science in design
\item
Even with fully formal requirements specification there does not yet exist a systematic way to obtain a design
\item
Even with fully formal requirements specification there does not yet exist
a systematic way to obtain a design
\item
Favour art in some areas and favour science in others
\end{itemize}
\end{itemize}
...
...
@@ -480,64 +508,6 @@ What are some examples of likely changes for software?
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle
{
Examples of Modules
\cite
{
GhezziEtAl2003
}}
\begin{itemize}
\item
\structure
{
Record
}
\begin{itemize}
\item
Consists of only data
\item
Has state but no behaviour
\end{itemize}
\item
\structure
{
Collection of related procedures (library)
}
\begin{itemize}
\item
Has behaviour but no state
\item
Procedural abstractions
% like many routines in a scientific computing library
\end{itemize}
\item
\structure
{
Abstract object
}
\begin{itemize}
\item
Consists of data (
\structure
{
fields
}
) and procedures (
\structure
{
methods
}
)
\item
Consists of a collection of
\structure
{
constructors
}
,
\structure
{
selectors
}
, and
\structure
{
mutators
}
\item
Has state and behaviour
\end{itemize}
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle
{
Examples of Modules Continued
}
\begin{itemize}
\item
\structure
{
Abstract data type (ADT)
}
\begin{itemize}
\item
Consists of a collection of abstract objects and a collection of
procedures that can be applied to them
\item
Defines the set of possible values for the type and the associated
procedures that manipulate instances of the type
\item
Encapsulates the details of the implementation of the type
\end{itemize}
\item
\structure
{
Generic Modules
}
\begin{itemize}
\item
A single abstract description for a family of abstract objects or ADTs
\item
Parameterized by type
\item
Eliminates the need for writing similar specifications for modules that
only differ in their type information
\item
A generic module facilitates specification of a stack of integers, stack
of strings, stack of stacks etc.
\end{itemize}
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \begin{frame}
% \frametitle{Specific Techniques for Design for Change}
...
...
@@ -584,8 +554,8 @@ What are some examples of likely changes for software?
\frametitle
{
Questions
}
\begin{itemize}
\item
What relationships are there between modules?
\item
Are there desirable properties for these relations?
\item
\structure
{
What relationships are there between modules?
}
\item
\structure
{
Are there desirable properties for these relations?
}
\end{itemize}
\end{frame}
...
...
@@ -1159,6 +1129,82 @@ AC2 & M2\\
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle
{
Examples of Modules
\cite
{
GhezziEtAl2003
}}
\begin{itemize}
\item
\structure
{
Record
}
\begin{itemize}
\item
Consists of only data
\item
Has state but no behaviour
\end{itemize}
\item
\structure
{
Collection of related procedures (library)
}
\begin{itemize}
\item
Has behaviour but no state
\item
Procedural abstractions
% like many routines in a scientific computing library
\end{itemize}
\item
\structure
{
Abstract object
}
\begin{itemize}
\item
Consists of data (
\structure
{
fields
}
) and procedures (
\structure
{
methods
}
)
\item
Consists of a collection of
\structure
{
constructors
}
,
\structure
{
selectors
}
, and
\structure
{
mutators
}
\item
Has state and behaviour
\end{itemize}
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle
{
Examples of Modules Continued
}
\begin{itemize}
\item
\structure
{
Abstract data type (ADT)
}
\begin{itemize}
\item
Consists of a collection of abstract objects and a collection of
procedures that can be applied to them
\item
Defines the set of possible values for the type and the associated
procedures that manipulate instances of the type
\item
Encapsulates the details of the implementation of the type
\end{itemize}
\item
\structure
{
Generic Modules
}
\begin{itemize}
\item
A single abstract description for a family of abstract objects or ADTs
\item
Parameterized by type
\item
Eliminates the need for writing similar specifications for modules that
only differ in their type information
\item
A generic module facilitates specification of a stack of integers, stack
of strings, stack of stacks etc.
\end{itemize}
\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
\frametitle
{
Getting Started
}
\begin{enumerate}
\item
Find a similar example to your problem as use that as a starting point
\item
Draft module names and secrets
\item
For each module sketch out:
\bi
\item
Classify module type (record, library, abstract object, abstract data
type, generic ADT)
\item
Access program syntax
\item
State variables (if applicable)
\ei
\item
Iterate on design
\end{enumerate}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}
[allowframebreaks]
\frametitle
{
References
}
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment