Object roles and interaction
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, \ifsli{\n}{} (suffers no operations)
- server -- suffers operations
- agent -- suffers and operates ({\em 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.
Class design -- round trip gestalt
[D
analyze a little,
design a little,
implement a little,
test a little...
D]
slide: Round trip gestalt class design
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 {\em
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.)
In the next section we will consider
formal means to verify the correctness of our design.
However, before that we will look at an example
of a design paradigm that allows us to assign
specific roles to object classes and to
specify (in an implicit manner) the protocol
of interaction between instances of these classes.
Example -- the MVC paradigm
A significant part of the effort of system development
often goes into the design and implementation of
the user interface.
The general feeling with respect to user interface components
is that these clutter up the design.
Nevertheless, as the example of the automated teller machine shows,
interaction with the user may be an intrinsic
part of the system.
In [BC89], the CRC cards method has also been used
to characterize the so-called Model-View-Controller
paradigm,
which has become popular as
an architectural device for developing
user interfaces.
The MVC paradigm allows us to develop a user
interface in a non-intrusive manner,
that is without cluttering the application code.
The idea is to provide standard (base) classes
from which application-specific classes, that
implement the particular details, may be derived.
See slide [3-mvc].
Model, View & Control -- user interface design paradigm
slide: The Model-View-Controller paradigm
The class derived from the Model class
is intended to maintain the problem-related
information.
The only thing a model object needs to do
is notify the other (dependent) objects when
some of the information it carries has changed.
In response to being notified of a change, the
view object (an instance of
the class which is derived from View)
may request what it needs to know to
refresh the display of the contents
of the model object.
A controller object is employed to interact
with the user.
Any relevant input is transferred to the model object,
that may in its turn notify the view object
of a change.
For the automated teller machine, the account class
will be the obvious choice for being derived from
the Model class.
Clearly, the card-reader class will have
Controller as its base class and the screen class
will be derived from View.
An important advantage of using the MVC-paradigm
is that it allows the programmer to
separate the problem-related code from
the code needed to implement the (often intricate)
details of interacting with the various input and
output devices.
Another advantage lies in the flexibility of the approach.
One model object may be associated with
arbitrary many different view-controller pairs,
simply by adding another view object to the
list of dependent objects that will be notified of
a change.
Since each view class specifies what it needs
to know of the model, the model class
itself will remain unaffected.
Although the MVC-paradigm was
introduced in the Smalltalk-80 environment,
similar interaction protocols have been used
in user interface libraries for C++, for example
the Interviews library (see Linton {\it et al.}, 1989).
See also sections [cooperation] and [libraries].
From the perspective of design, the paradigm is
attractive since it may be applied in a cookbook
fashion to implement intricate user interfaces,
often simply by reusing available code.
See [KP88] for a number of example recipes.
In section [cooperation] we will further explore
the interaction protocol underlying the
MVC-paradigm.