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.