Lecture Notes for CS 325
Logical Design, 16 February 2000
- behavior
specifications of varying degrees of formality
-
misinterpretations lead to designer-implementer confusion
-
formal and precise specifications of module behavior
- constrain
behavioral interpretation, promote implementational interpretation
- module specifications
- formal specifications fix
interpretations
- specifications for functionally or data
abstract modules
- all together now: module specs should be
complete, unambiguous, and understandable
- module specifications
should be implementation independent
- but, operational
specifications are helpful too
- functional specifications
- a black box with inputs and outputs
- the module
transforms inputs to outputs
- the module spec describes the
input-output transformation
- axiomatic specifications
- descriptions of input and output state
- precondition
must be true before the module executes
- postconditions will be
true when module terminates
- writing complete and consistent
pre- and postconditions is tricky
- failure to met conditions is
an exceptional condition
- class specifications
- methods are functions, so functional approaches work
-
classes are not only methods, however
- adt specification
practice provides a basis
- logical (or detailed) design
- shares techniques with design specification
-
program description language
- structured engilsh + pseudo
code
- translation to programming languages
- successive
refinement to increase the level of detail
- algorithm
design
- an algorithm is a complete description of a
computation
- who does algorithms: the system designers or the
implementors
- algorithm design is a technical skill
- modeling class state
- classes are extra-functional
- focus on class state and changes to it via methods
- fsa
are a useful model
- collapse several actual class states into a
single logical state
- use functional design to specify methods
This page last modified on 16 February
2000.