inse - lecture 8 design tactics (2) - modular structure u notations for design documents u...
TRANSCRIPT
INSE - Lecture 8
Design
Tactics (2) - Modular structureNotations for design documentsVerification of design
Modular program structure
What is a “Module”? What sized chunk of program is best for
the “component” of design?(also of coding, test/debugging,
documentation, re-use…) Mid-1960s to early 1970s
dogma that a “natural” size chunk was “of course” a subroutine/procedure
because it was “the only possibility”.
Better thinking…
Around 1970 – increasing realization that the typical design decision is one of– we need this group of procedures; or– we need this data-structure (and
procedures/functions to operate on it).(The Line between those is often
unclear – the group of procedures usually imply some shared data, to be available to those procedures only.)
Implications of shared data…
Ideally we would like a “defensive wall” round such a bundle of facilities:
e.g. if the procedures share a variable which no other procedure should
use – a sort of “group local” variable.
That requirement of “no other procedure should use” is hard to enforce by hand – we need programming language support for it.
Two proposals: The general proposal -
–MODULES (Parnas, 1972) The data-oriented proposal –
– OBJECT-ORIENTATION (King, 1972)(i.e. OO is a restricted form of modularization)
Languages to support/enforce them followed:– Ada (both supported)– Modula (modules only)– C++ (OO or nothing)– Smalltalk, Eiffel, Java… (OO only)
Modularization – summary We now have languages to support the design
approach; Such a language isn’t essential, but it does
ensure we catch unintended violations of modularity– especially important in bigger programs & in safety-
critical programs;– especially to stop ham-fisted maintainers violating
the design. Many consequences to note as we work on
through the lifecycle…
Ada Augusta, Countess of Lovelace, 1815-1852
“The first programmer”- her programs were modular!
Notations for design documents
Design notation - issues
We had trouble with how to write down a specification without gaps, ambiguities, or clashes –
Now we have the same problem with design.
Again, there is a (loud) argument over the best way of doing so.
What are we describing?
To decide what a design notation must achieve, we need to sharpen our ideas of what design is.
DESIGN is not vague implementation; is the extraction of the principles of an
implementation; should reflect the requirements on an
implementation; should not anticipate the implementation.
But it’s not that simple!
But: specification, design & implementation are points on a spectrum
So to a large extent, the dividing lines between them are a matter of taste, or of need.
The spec could be regarded as the first level of design…
The implementation could be regarded as the last level – but that’s a more dubious idea.
So…
…non-trivial designs need to be in layers of increasing detail.
So we need either a design notation capable of describing
different layers of detail; or different notations for different layers of detail.
Obviously, too many different notations would be hard to work with.
Whichever…
The notation must be able to describe the principles of how the program works; maybe what effect the program has when it is
obeyed.
(The “how” if often described in English, explaining a step between to levels of design.)
Audiences…
The notation(s) should be readable by (at least): the project manager; the implementor; quality assurance; the trials engineer; the maintainer.
The all have different requirements, backgrounds, and work environments.
So what do we need?
Two main school of thought – “design is evolutionary” in terms of
modules/objects with spec as highest level – so write the design as “specs of modules” – so we need only a single notation.
“spec says what to achieve, design says how, code realizes the design – different needs, so should be > 3 notations.
Some graphical notations
Let’s start with a specialist one then look at some in widespread use.
MASCOT Good for describing concurrent activities, and
the communication between those activities – assumes you’ll use another notation for “inside” each activity.
Usually drawn by program from a standardized textual description –– checkable by programs;– more maintainable than “pure” graphics – in
particular, each design refinement is (to some extent) checkable by programs.
Structure diagrams(including “call graphs”)
A diagram of the design components of the program, and of which components use (or call) which.
E.g. for a typical simple compiler:
(Variations on structure diagrams)
Annotations to a structure diagram can be useful for expressing information that doesn’t easily fit elsewhere:
E.g. direction of flow of data between design components:
Data-flow diagrams
A box (circle, hexagon, etc) per data structure or file;
arrows to indicate flows between them.
Verification of design
Purpose of design verification Making sure that the design covers the
specification– correctly– completely.
Making sure that the freedoms left by the specification have been given appropriate design decisions.
Ideally...
… verification would be by full formal-methods proof.
That would require formal speficiation and design.
Increasingly, there are programs available to do the necessary checks: every year they do more, and do it better.
Informal verification techniques
Various forms of design review: some selected people check the design
– usually avoid people who were involved in the design itself
– unless designers of different parts “cross-check” the check might be for correctness or for
quality or both maybe check just the final design: maybe the
check is continuous throughout the design process - both options have disadvantages.
Issues
Many aspects of design reviews are matters of dispute: e.g.
who are the best checkers?– specialist checkers?– other practicing designers?
to what level of detail should the design go?
/continues
(Issues - continued)
what is the best order in which to do the review?– top-down?– bottom-up?– front-to-back?– hardest-first?– random?– other?
how should it be administered? how do you avoid personality clashes? ...
Design reviews - conclusion
Different software producers have tried different combinations: each seems to have its own disadvantages;
buteveryone seems to feel that design reviews find enough errors to pay for themselves many times over
andthe choice of which combination seems not to change the benefits much…
…so details are a management issue
After this lecture think about your past programming efforts –
did you use modularization well to separate things that should have been separate?
make prudent choices of design notations - match them to the need for the particular project.
do check designs! do make prudent choices of the checking method!
The Software Project
Manager?