Upload
stephen-logan
View
214
Download
0
Embed Size (px)
Citation preview
Lecture 2
Quality as the motivation forSoftware Design
References:Braude, Chapters 0 and 1
My 2001 lecture notes on Quality
Budgen Software Design
Meyer Object-Oriented Software Construction, (2nd edition), Chapter 3
Robert Pirsig, Zen and the Art of Motorcycle Maintenance.
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.
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?
Quality
Examples:
o Caro Chairo Motorcycle
Implication: Quality is undefined without requirements
Quality = Fitness for purpose?
Quality requirements
Quality of the requirements limits the quality of the design and of the finished software.
Good requirements must be:
o Unambiguouso Completeo Verifiableo Consistento Modifiableo Traceableo Usable
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.
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.
Examples
Scientific supercomputing applicationso Efficiency over-rides everything elseo (Except correctness?)
Small business tax accounting packageo Maintainabilityo Ease of useo Modularity (leads to maintainability?)
Metrics Measure finished code (or detailed design?)
o Lines of code per class, per routineo Number of suppliers, number of decision
pointso 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
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.
Design Guidelines Simplicity
“As simple as possible, but no simpler”
- Albert Einsteino Watch out for the second half of that.
Modularityo Clear and logical separation into subsystems
(and sub-subsystems etc if necessary)
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.
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 systemo 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.
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