In the previous chapter we looked at idioms and patterns that resulted from object-oriented software development. In this chapter we will focus on the software engineering of object-oriented systems and issues of design in particular, including the identification of objects and the specification of contractual obligations.
Additional keywords and phrases:
requirements, analysis, implementation, design as transition,
CRC cards, responsibilities, heuristics,
In this section we will look at a variety of existing methods and the tools they offer. We do not discuss the tools and diagram techniques used in any detail. However, we will discuss the Fusion method in somewhat more detail. Fusion is a strongly systematic approach to object-oriented software development that integrates various concepts and modeling techniques from the other methods, notably OMT, Booch OOD, Objectory and CRC. We will discuss the process view underlying Fusion and sketch the models it supports in relation to the other methods. For the reader this section may supply an overview and references needed for a more detailed study of a particular method or tool.
A recent development is the Unified Modeling Language (UML), which has been approved as a standard in 1998. UML brings together the models and notations featured by the various methods. Jim Rumbaugh, Grady Booch and Ivar Jacobson, all leading experts in object-oriented development, joined forces to achieve this.
The importance of such a standardization can hardly
However, it must be noted that UML does not provide
a method, in the sense of delineating the steps that
must be taken in the development of a system.
UML itself may be regarded as a toolbox, providing
notations and modeling techniques that may be deployed
A brief overview of UML is given in
An excellent introduction to UML, including advice
how to apply it in actual projects may be found
In contrast to the model used in analysis,
both the design model and the implementation model are more
solution oriented than domain oriented.
The implementation model is clearly dependent on the available
Within a traditional life-cycle, the design model may be seen as
a transition from analysis to implementation.
The notion of objects may act as a unifying factor,
relating the concepts described in the analysis document
to the components around which the design model is built.
However, as we have noted, object-oriented development
does not necessarily follow the course
of a traditional software life-cycle.
Alternatively, we may characterize the function of the
design document as a justification of the choices
made in deciding on the final architecture of the system.
This remark holds insofar as an object-oriented approach
is adopted for both design and implementation.
An interesting architectural issue is, how may we
provide for future extensions of the system?
How easily can we reuse the design and the code for
a system supporting different kinds of accounts,
or different input or output devices?
And how can we establish that the objects, as
identified, interact as desired?
Design is to a large extent a matter of creative thinking.
Heuristics such as performing a linguistic scan
on the requirements document for finding objects
(nouns), methods (verbs) and attributes (adjectives)
may be helpful, but will hopelessly fail
when not applied with good taste and judgement.
Not surprisingly, one of the classical techniques
of creative writing, namely the shoe-box method,
has reappeared in the guise of an object-oriented
The shoe-box method consists of writing fragments
and ideas on note cards and storing them in a (shoe) box,
so that they may later be retrieved and manipulated
to find a suitable ordering for the
presentation of the material.
To find a proper decomposition into objects,
the method creates for each potential
(object) class a so-called CRC card,
which lists the Class name, the Responsibilities
and the possible Collaborators of the proposed class.
In a number of iterations, a collection of cards
will result that more or less reflects the
structure of the intended system.
According to the authors (see Beck and Cunningham, 1989), the method
effectively supports the early stages of design,
especially when working in small groups.
An intrinsic part of the method consists
of what the authors call dynamic simulation.
To test whether a given collection of cards
adequately characterizes the functionality of the intended
system, the cards may be used to simulate
the behavior of the system.
When working in a group, the cards may be distributed
among the members of the group, who participate
in the simulation game according to their cards.
See slide 3-crc.
analyze a little,
design a little,
implement a little,
test a little ...(The notion of gestalt comes from perception psychology, where it means a global perceptual configuration emerging from the background.)
For dynamically checking the invariance condition, a test should be executed when evaluating the constructor and before and after each method invocation. While a method is being executed, the invariant need not necessarily hold, but it is the responsibility of a method to restore the invariant when it is disrupted. In case object methods are recursively applied, the invariant must be restored when returning to the original caller.
An alternative approach to incorporating assertions
in a class description is presented in
A pre-condition limits the cases that a supplier must handle!
However, before we delve into the formal foundations of object-oriented modeling, we will first look at an example of application development and explore the design space of object-oriented languages and system implementation techniques. These insights will enable us to establish to what extent we may capture a design in formal terms, and what heuristics are available to accomplish the tasks remaining in object-oriented development.
(C) Æliens 04/09/2009You may not copy or print any of this material without explicit permission of the author or the publisher. In case of other copyright issues, contact the author.