This chapter looked at
system development from a
software engineering perspective.
How may we establish that software
is reliable and to what extent can our
experience be generalized to an object-oriented approach?
1
- software quality -- structural criteria
- testing -- strategy, tactics, operational
- inheritance -- inherited code must be retested
slide: Section 4.1: Validating software
We discussed the notions of software
quality, including structural criteria,
and testing, as an empirical way in which to
validate software.
An example has been given,
illustrating that inherited code may
need to be retested.
2
- levels of testing -- influence of errors
- object test methods -- state transitions
- contracts -- interaction protocols
- static testing -- careful reading
slide: Section 4.2: A framework for testing object-oriented programs
We developed (the beginnings of)
a framework for testing object-oriented
software,
discussed the influence of errors
and looked at object test methods
directed at verifying
state transitions.
We also discussed how contracts
may provide a guideline for testing,
indicating state invariant interaction
protocols.
Testing may also be done by carefully reading the code,
preferably with a group of colleagues.
3
- metrics -- objects, attributes, communication
- law of demeter -- class interfaces
- reuse -- individual class design
slide: Section 4.3: Guidelines for design
A number of metrics for object-oriented design have been proposed.
These metrics may be used to establish
the complexity of object models.
The metrics given are meant only
as a starting point
for further research and empirical
validation.
They cover aspects such as
the complexity of the relation
between the definition and usage of attributes
and the complexity of communication
patterns between objects.
Related to the issues of complexity,
we discussed the Law of Demeter
which gives a guideline for good
object-oriented design,
including suggestions for class
transformations to improve a particular
design.
Also we looked at some guidelines
for individual class design.
Towards a formal approach
4
- contracts -- formal specification
- verification -- as a design methodology
- runtime consistency -- invariance
slide: Section 4.4: Towards a formal approach
Finally, we reflected on the possible
contribution of formal methods to
the software engineering of
object-oriented systems,
and concluded that the notion of
contracts may play an invaluable role,
both as a design methodology and as
a means to establish the runtime
consistency of a system.
- What aspects can you distinguish with respect to
software quality?
- Give an example demonstrating
how inheritance may affect tested code.
- Between what levels of testing can you distinguish?
Discuss the influence of errors for each of these levels.
- Discuss the problems involved in testing the behavior
of an object.
What would be your approach?
- Discuss how contracts may be employed to test object behavior.
- What methods of static testing can you think of?
Do you consider them relevant? Explain.
- What metrics can you think of for object-oriented design?
What is the intuition underlying these metrics?
- What evaluation criteria for metrics can you think of?
Are these sufficient for applying such metrics in actual software
projects? Explain.
- Give a formal definition of the following metrics:
WMC, DIT. NOC, CBO, RFC and LOC.
Explain their meaning from a software engineering viewpoint.
- What would be your rendering of the Law of Demeter?
Can you phrase its underlying intuition? Explain.
- Define the notions of client, supplier and acquaintance.
What restrictions must be satisfied to speak of
a preferred acquaintance and a preferred supplier?
- Characterize the elements that form part of a formal specification.
There is a massive amount of literature on software
validation and testing. A standard text is [Myers].
As research papers, I recommend [Doong90] and [Smith92].
For a further study of the Law of Demeter
look at [LH89].