Lecture 2 Quality as the motivation for Software Design References:Braude, Chapters 0 and 1 My 2001...

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