INSE - Lecture 8 Design Tactics (2) - Modular structure u Notations for design documents u Verification of design.

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?