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


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.