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

2. Modular program structure

3. What is a “ Module ” ? u What sized chunk of program is best for the “ component ” of design? (also of coding, test/debugging, documentation, re-use … ) u Mid-1960s to early 1970s dogma that a “ natural ” size chunk was “ of course ” a subroutine/procedure u because it was “ the only possibility ”.

4. Better thinking … u 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.)

5. Implications of shared data … u 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. u That requirement of “ no other procedure should use ” is hard to enforce by hand – we need programming language support for it.

6. Two proposals: u The general proposal - –MODULES (Parnas, 1972) u 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)

7. Modularization – summary u We now have languages to support the design approach; u 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. u Many consequences to note as we work on through the lifecycle …

8. Ada Augusta, Countess of Lovelace, 1815-1852 “ The first programmer ” - her programs were modular!

9. Notations for design documents

10. Design notation - issues u We had trouble with how to write down a specification without gaps, ambiguities, or clashes – u Now we have the same problem with design. u Again, there is a (loud) argument over the best way of doing so.

11. What are we describing? To decide what a design notation must achieve, we need to sharpen our ideas of what design is. DESIGN u is not vague implementation; u is the extraction of the principles of an implementation; u should reflect the requirements on an implementation; u should not anticipate the implementation.

12. 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. u The spec could be regarded as the first level of design … u The implementation could be regarded as the last level – but that ’ s a more dubious idea.

13. So … … non-trivial designs need to be in layers of increasing detail. So we need u either a design notation capable of describing different layers of detail; u or different notations for different layers of detail. Obviously, too many different notations would be hard to work with.

14. Whichever … The notation must be able to describe u the principles of how the program works; u 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.)

15. Audiences … The notation(s) should be readable by (at least): u the project manager; u the implementor; u quality assurance; u the trials engineer; u the maintainer. The all have different requirements, backgrounds, and work environments.

16. So what do we need? u Two main school of thought – u “ 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. u “ spec says what to achieve, design says how, code realizes the design – different needs, so should be > 3 notations.

17. Some graphical notations u Let ’ s start with a specialist one u then look at some in widespread use.

18. MASCOT u Good for describing concurrent activities, and the communication between those activities – assumes you ’ ll use another notation for “ inside ” each activity. u 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.

20. Structure diagrams (including “ call graphs ” ) u A diagram of the design components of the program, and of which components use (or call) which. E.g. for a typical simple compiler:

21. (Variations on structure diagrams) u 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:

22. Data-flow diagrams u A box (circle, hexagon, etc) per data structure or file; u arrows to indicate flows between them.

23. Verification of design

24. Purpose of design verification u Making sure that the design covers the specification –correctly –completely. u Making sure that the freedoms left by the specification have been given appropriate design decisions.

25. Ideally... … verification would be by full formal- methods proof. u That would require formal speficiation and design. u Increasingly, there are programs available to do the necessary checks: every year they do more, and do it better.

26. Informal verification techniques Various forms of design review: u some selected people check the design –usually avoid people who were involved in the design itself –unless designers of different parts “ cross-check ” u the check might be for correctness or for quality or both u maybe check just the final design: maybe the check is continuous throughout the design process - both options have disadvantages.

27. Issues Many aspects of design reviews are matters of dispute: e.g. u who are the best checkers? –specialist checkers? –other practicing designers? u to what level of detail should the design go? /continues

28. (Issues - continued) u what is the best order in which to do the review? –top-down? –bottom-up? –front-to-back? –hardest-first? –random? –other? u how should it be administered? u how do you avoid personality clashes? u...

29. Design reviews - conclusion Different software producers have tried different combinations: each seems to have its own disadvantages; but everyone seems to feel that design reviews find enough errors to pay for themselves many times over and the choice of which combination seems not to change the benefits much … … so details are a management issue

30. After this lecture u think about your past programming efforts – did you use modularization well to separate things that should have been separate? u make prudent choices of design notations - match them to the need for the particular project. u do check designs! do make prudent choices of the checking method!

32. The Software Project Manager?