The main purpose of this section is to summarize the dynamic model, which we have developed. In addition, we will discuss a number of dimensions along which it is possible to characterize dynamic models in general.
At the outset we will clarify our view on dynamic models in contrast
to static models. This is done via the concepts and relations in
figure 1. The central concepts in the figure are
`program' and `program execution'. In our view, a program is a
description of the program execution. Various abstractions can be
defined on the program. Abstractions of the structural program
aspects are in general known as static models. Abstractions of the
process program aspects are also possible, but less common. In
relation to this paper, the abstraction of the program execution is of
primary interest. The idea with this abstraction is to elevate the
actual program execution objects and mechanisms to a level, which is
fruitful and adequate for the object-oriented design task.
A dynamic model is a description of the abstracted program execution.
It is a central decision of our current work that a dynamic
model is a scenario more than a program-like description
of a computational process. In this context, a scenario
is ``an outline or a model of an expected or a supposed sequence of
events''. Consequently, a dynamic model in our work
is a fixed example of object interactions, which can be executed in
the mind of the designer.
Execution in terms of simulation of the model on a computer is not
the goal of this work.
With this understanding of dynamic models it is seen that dynamic
models are quite similar to use cases, as promoted by Jacobson et al. in
[7].
We will now turn to a summary of the central concepts in our dynamic OOD model which are objects, scenes, and messages.
An object is an identity carrying encapsulation of some program state.
This is a definition which is similar to the object concept from
object-oriented programming languages. Currently, we do not deal explicitly with
the state of the object. Consequently, we do not describe any data
fields of an object. However, we may in our future work like to
capture the state of an object via the history of the state transforming
operations, which have been applied to the object.
When new objects are introduced it is
possible to describe how the new objects are related to the existing
objects. The class of the objects are registered. The class of an
object does not exist as a description in the dynamic model.
The sole purpose of classes is to relate the set of objects, which
are instances of the same class.
A scene is the set objects which are relevant for the current dynamic model. Objects enter the scene via a mechanism called object provision. An object provision is a convenient and somewhat magical mechanism which establish an object exactly at the time it is needed by the designer. An object may actually have existed for a long time, but in the current scenario it first becomes relevant at `object provision time'. Thus, it is seen that an object provision claims the existence of an object in addition to a certain relationship with the objects, which already have been brought onto the scene. As a simple and practical convention, all objects on the scene have a unique name, through which they can be referred to during a scenario. Other kinds of object references as well as scope considerations are deemed irrelevant for design purposes.
We use the conventional message passing metaphor for object-interaction. A message is passed from a sender object to a receiver object. At the top-level of the scenario, there are no real sender object, although the ``surrounding'' may be seen as the sender. In addition to the receiver, it is also possible to pass parameters. Parameters may be existing objects (referred by their names), object provisions (objects of which we claim the existence at parameter passing time), or informally given values (of basic types that are not necessarily related to any class).
Passing a message M to a receiver R may cause the following actions in the model:
Although it is conceived that a message activates a method from the class of the receiver object, the method concept is weak in our dynamic model. It is known to be the case that the message passings in item 2 from above are located in one single method in the class (say C) of the receiver object R. However, the same message to another object of the class C, or the same message to R with other actual parameters, may cause another sequence of messages from R (for instance because of selections with if-then-else's in the body of the method). These observations are consequences of the scenario-based approach, which we haved followed in our research until now. In conclusion, methods are weak in dynamic models; Methods are parts of the static model.
A dynamic model can be characterized using three independent dimensions:
As mentioned in the introduction, the diagrammatic means of expression dominate in the OOD literature, also with respect to the documentation of dynamic models. This is a contrast to the programming phase of the development process in which the textual means of expression dominates. Our approach in this work is to leave the decisions about `the means of expressions' open. This is achieved by working on abstract representations of the model, which may be presented either as a diagram or as a piece of text. We come back to this discussion in section 3 of this paper.
On the one hand, a formal description lends itself towards a higher degree of precision than does an informal description. On the other hand, an informal description is often better suited to enhance the intuitive understanding of the model. Both precision and intuition are important for our endeavor. In particular we believe that the designer need to document the intuitive aspects of the dynamic model, in order to promote a human, common sense understanding of the design task at hand. Therefore, we encourage the designer to give intuitive explanations in natural, written language, and we augment the representation of the dynamic model with these explanations. As a consequence we go for a dynamic model in which both formal and informal aspects are present. In some situations this leads to redundancy.
