Instructor's Guide
intro,
methods,
objects,
contracts,
formal,
summary,
Q/A,
literature
Objects rarely live in isolation.
In a system of some complexity,
a number of different kinds of object
classes may usually be distinguished.
Each kind of class may be regarded as playing
a specific role in the system.
For example, when considering our ATM,
classes such as card-reader and cash-dispenser
are of a completely different kind, and play a completely
different role, than the classes
account and database for instance, or the classes
event and transaction.
Often it will take some
experimentation to decide how control must
be distributed among the objects comprising the system.
Although
the framework chosen for the development of the system
may partly determine the control model,
there will usually be ample choice left for the designer of
the system to define the interactions between objects.
Object roles
- actor -- operates (suffers no operations)
- server -- suffers operations
- agent -- suffers and operates ( actor & server)
slide: Object roles
An important function of the design document
is to elucidate the role of each object class
in the system, and to point out
how the objects cooperate to complete the task.
In [Booch86], a distinction is made between objects
that suffer no operations (actors),
objects that only suffer operations (servers)
and objects that both suffer and require operations
(agents).
Such a characterization in terms of initiative
may give a first indication of
the role an object plays in the system.
For example, the account class in our ATM example
is best characterized as a server class,
whereas the transaction class may be regarded,
in the terminology of [Booch86], as an actor
class, since it actively controls the computation.
In many cases, the software control model
adopted will also influence the way in which individual
objects are supposed to behave.
See slide [3-roles].
With respect to a global view of
the system, it is necessary to ensure that each object class
is completely defined,
that is to establish that each class provides a
sufficiently complete
method interface.
In [Booch86], a characterization is given of the
kinds of methods that may occur in an interface.
These include methods to create or destroy an
object, methods to modify the state of an object and methods
that only provide information on the state of
an object, or parts thereof.
Before being able to make final decisions
with respect to the functionality of a class, however,
it is generally necessary to get a clear
overall picture of the system first.
This requires what [Booch86] characterizes
as round trip gestalt design, which in other
words expresses the need to
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.)