comp2110 Software Design Lecture 2 Quality as the motivation for Software Design

1
comp2110 Software Design Lecture 2Quality as
the motivation forSoftware Design

• References Braude, Chapters 0 and 1
• Ian Barnes 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.

2
Why design?

• PSP experience the time spent in design
  affects
• Time spend in later phases
• 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
• Car
• Chair
• Motorcycle
• Implication Quality is undefined without
  requirements

5
Quality requirements

• Quality of the requirements limits the quality of
  the design and of the finished software.
• Good requirements must be
• Unambiguous
• Complete
• Verifiable
• Consistent
• Modifiable
• Traceable
• 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
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.

• Reusability
• Extendability
• Maintainability
• Reliability
• Compatibility
• Functionality
• Timeliness

• Correctness
• Robustness
• Modularity
• Efficiency
• Ease of use
• Portability
• Verifiability

8
Examples

• Scientific supercomputing applications
• Efficiency over-rides everything else
• (except correctness?)
• Small business tax accounting package
• correctness
• maintainability
• ease of use
• modularity (leads to maintainability?)
• The designer makes (different) tradeoffs to fit
  the different requirements written and
  unwritten.

9
Metrics

• Measure finished code (or detailed design?)
• Lines of code per class, per routine
• Number of suppliers, number of decision points
• Bandwidth (amount of data sent as parameters,
  return values)
• 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
• Watch out for the second half of that.
• Modularity
• 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.
• Bertrand Meyer, Object Oriented Software
  Construction

13
What is the role of design?

• Describe the system well enough that coders can
  build it and deploy it without serious problems.
• e.g. ACT electronic voting system
• 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