1. Lecture 2 Quality as the motivation for Software Design References:Braude, Chapters 0 and 1 My 2001 lecture notes on Quality Budgen Software Design Meyer Object-Oriented Software Construction, (2 nd edition), Chapter 3 Robert Pirsig, Zen and the Art of Motorcycle Maintenance.

2. Why design?  PSP experience – time spent in design affects o Time spend in later phases o Number of defects found in later phases  There's more to software quality than counting defects  There's more to design than just putting in the time. Design can be done well or badly.

3. Good design? No design = bad design? What is good design? What is bad design? Is good design the same as good code? Can we tell, by looking at a design, whether it is good or bad? If so, how?

4. Quality Examples: o Car o Chair o Motorcycle Implication: Quality is undefined without requirements Quality = Fitness for purpose?

5. Quality requirements Quality of the requirements limits the quality of the design and of the finished software. Good requirements must be: o Unambiguous o Complete o Verifiable o Consistent o Modifiable o Traceable o Usable

6. How to identify quality design  Look at the finished software and relate to the requirements (fitness for purpose) But surely this is a bit extreme: we all have a strong intuitive sense of what quality is. (Elegance? Careful...) Experience over many years has led to a body of knowledge: factors that tend to contribute to good design.

7. Quality factors  Correctness  Robustness  Modularity  Efficiency  Ease of use  Portability  Verifiability  Reusability  Extendability  Maintainability  Reliability  Compatibility  Functionality  Timeliness See Meyer OOSC2, Chapter 3. These are not the definition of quality, but factors that tend to indicate quality. Their importance varies depending on requirements.

8. Examples  Scientific supercomputing applications o Efficiency over-rides everything else o (Except correctness?)  Small business tax accounting package o Maintainability o Ease of use o Modularity (leads to maintainability?)

9. Metrics  Measure finished code (or detailed design?) o Lines of code per class, per routine o Number of suppliers, number of decision points o Bandwidth (amount of data sent as parameters, return values) o Fanout (number of external routine calls)  Relationship between these numbers and quality is unclear  Better use of metrics is to look for hot spots

10. More on Metrics  Relationship between these numbers and quality is unclear  Better use of metrics is to look for hot spots  Often can't measure until after coding (too late)  Can lead to the false belief that if it can't be measured then it isn't important. Design is a creative activity that largely defies measurement.

11. Design Guidelines  Simplicity “As simple as possible, but no simpler” - Albert Einstein o Watch out for the second half of that.  Modularity o Clear and logical separation into subsystems (and sub-subsystems etc if necessary)

12. Meyer's five criteria for modular designs  Decomposability – clear logical separation...  Composability – can reassemble in different ways  Understandability – each module can be understood in isolation (ideal...)  Continuity – small changes to requirements affect few modules  Protection – exceptions don't propagate across modules but are handled where they occur.

13. What is the role of design?  Describe the system well enough that coders can build it and deploy it without serious problems. o e.g. ACT electronic voting system o e.g. COMP2110 designs from 2001  Describe all the parts of the system and how they fit together (architecture, high-level design)  Describe each part in detail so that it can be coded.

14. Why bother with formal design?  Why do we need design notation?  Why do we need to struggle with formal legalistic English  Why not just think about it and then start coding? Answer:  Communication  Clarity  Different conceptual level