diff --git a/BlankProjectTemplate/docs/Design/MG/MG-Checklist.pdf b/BlankProjectTemplate/docs/Design/MG/MG-Checklist.pdf index f8e8819b0a0e9399d697aabdb3f3d25dc060e0fc..ea581a71a642b5445eda6d7053bbf301c644dfe7 100644 Binary files a/BlankProjectTemplate/docs/Design/MG/MG-Checklist.pdf and b/BlankProjectTemplate/docs/Design/MG/MG-Checklist.pdf differ diff --git a/BlankProjectTemplate/docs/Design/MG/MG-Checklist.tex b/BlankProjectTemplate/docs/Design/MG/MG-Checklist.tex index b271db054795c191f8359f2aab9880f8d5692b69..feb3eb065db71d02648093ba3f9aab96b683336c 100644 --- a/BlankProjectTemplate/docs/Design/MG/MG-Checklist.tex +++ b/BlankProjectTemplate/docs/Design/MG/MG-Checklist.tex @@ -56,7 +56,10 @@ rule. \item Level 1 of the decomposition by secrets shows: Hardware-Hiding, Behaviour-Hiding and Software Decision Hiding. - \item Uses relation is not confused with a data flow chart + \item Behaviour-Hiding modules are related to the requirements + \item Software-Decision hiding modules are concepts that need to be + introduced, but are not detailed in the requirements + \item Uses relation is not confused with a data flow chart \end{todolist} \item MG quality diff --git a/BlankProjectTemplate/docs/Design/MIS/MIS-Checklist.pdf b/BlankProjectTemplate/docs/Design/MIS/MIS-Checklist.pdf index 9d8bb1680b1d8b8dca6d34f548b612313b2f6419..8b190e6baca26d018a35c6e2e9c961bb1a8d0ab4 100644 Binary files a/BlankProjectTemplate/docs/Design/MIS/MIS-Checklist.pdf and b/BlankProjectTemplate/docs/Design/MIS/MIS-Checklist.pdf differ diff --git a/BlankProjectTemplate/docs/Design/MIS/MIS-Checklist.tex b/BlankProjectTemplate/docs/Design/MIS/MIS-Checklist.tex index 6e6bf3e0c6c44260c3813131eab2be02db8afa15..4051f4545946721d8360263cf7ad83d53c898ddc 100644 --- a/BlankProjectTemplate/docs/Design/MIS/MIS-Checklist.tex +++ b/BlankProjectTemplate/docs/Design/MIS/MIS-Checklist.tex @@ -41,13 +41,6 @@ \item Writing style \end{todolist} -\item MIS syntax - \begin{todolist} - \item Exported constants are ``hard-coded'' literal values, not variables. - Constants are values that are known at specification (and therefore compile) time - \item - \end{todolist} - \item MIS Module Classifications \begin{todolist} \item Types that only hold data (records) are modelled as exported types. For @@ -71,8 +64,24 @@ modules, but not necessarily. An example is given in the Generic Stack Module (Stack(T)) given in A3: \url{https://gitlab.cas.mcmaster.ca/smiths/se2aa4_cs2me3/blob/master/Assignments/A3/A3Soln/A3P1_Spec.pdf} + \item Abstract objects will have some kind of initialization method + \item Abstract objects will have an assumptions that programmers will + initialize first, or a state variable that is set from False to True when + the Abstract object is initialized - this state variable then needs to be + checked for each access program call + \end{todolist} + + \item MIS and Mathematical syntax + \begin{todolist} + \item Exported constants are ``hard-coded'' literal values, not variables. + Constants are values that are known at specification (and therefore compile) + time + \item Operations do not mix incorrect types. For instance, a character is not + added to an integer, an integer is not ``anded'' with a Boolean, etc. + \item Our modified Hoffmann and Strooper notation is used, or any new notation + is clearly defined. \end{todolist} - + \item MIS Semantics for each module \begin{todolist} \item Each access program does something - either an output, or a state @@ -90,26 +99,26 @@ \item State invariant is initially satisfied \item Local functions make the specification easier to read (there is no requirement that the local functions will actually be implemented in code) - \end{todolist} - - \item Mathematical syntax - \begin{todolist} - \item Operations do not mix incorrect types. For instance, a character is - not added to an integer, an integer is not ``anded'' with a Boolean, etc. - \item Our modified Hoffmann and Strooper notation is used, or any new - notation is clearly defined. + \item Modules that deal with files, the keyboard, or the screen, have + environment variables to represent these respective entitites \end{todolist} \item MIS Quality inspection for each module \begin{todolist} - \item Minimality - \item + \item Consistent + \item Essential + \item General + \item Implementation independent + \item Minimal + \item High cohesion + \item Opaque (information hiding) \end{todolist} -\item MIS Completnesss +\item MIS Completeness \begin{todolist} \item All types introduced in the spec are defined somewhere - \item + \item All modules in MG are in the MIS + \item All required sections of the template are present for all modules \end{todolist} \end{itemize}