Modeling is a key activity in a program design process. In our
context, a model is a generalized description
represented in a stylized fashion, which is used in analyzing or
explaining an existing or a forthcoming program. 
The models which are relevant for program design
purposes can roughly be divided into static models and dynamic models.
In this paper, the terms `static models' and `dynamic models' have a special, restricted meaning. A static model is considered as an abstraction of the source program, as it appears as a document, with special emphasis on the structural relations among program components. A dynamic model is considered as an abstraction of the program execution. Consequently, a dynamic model deals with the concrete data objects, the interaction among the data objects, and the creation and deletion of these during the program execution. Classes versus instances of classes may serve as an example of the difference between the elements of the two models. The distinction among static and dynamic models, considered as abstractions, will be discussed further in section 2 below.
In this paper we will restrict the discussion of dynamic models to object-oriented design situations. The object-oriented design process follows an analysis phase, the purpose of which is to understand the problem at hand. Object-oriented design (OOD) is followed by an implementation phase, in which the design (considered as a product) is refined to an executable program via an implementation in some given programming language.
In general, a design is a plan for construction. An object-oriented design is a design in which classes and methods play a key role in the static design models, and in which objects and messages play a key role in the dynamic design models.
It is more difficult to make a dynamic OOD model than a static OOD model. The reason is that a dynamic model reflects the actual dynamics in a program execution, at some rather high abstraction level. Thus, the elements of a dynamic model may appear, may modify themselves and other elements, and may finally disappear as a function of time. In comparison, a static OOD model is typically concerned with the structural relations among classes, and there are no temporal aspects to be dealt with.
One of the ideas behind this work is that dynamic OOD models should be formulated before the central static models, which involve classes and their mutual relations. It is our hypothesis that programmers think in terms objects, object relations and object interaction during the creative phases of the design process. Consequently, it is probably a gain if the dynamic model can be created directly as one of the first models, at the time where the designer is shaping the overall computational idea relative to the objects at hand.
In the OOD literature [7][9][3], dynamic models are typically expressed as various kinds of diagrams. However, it is not easy to embed information about the ``temporal dimension'' of a dynamic model in diagrams, without making the diagrams very complicated. The complications both affect the producers and the readers of the diagrams. Furthermore the complicated nature of the diagrams severely limits the size of the models which can be handled in a realistic way.
It may be argued that programming languages should be used for descriptions of the desired dynamics. Indeed, a program formulated in a programming language certainly captures the dynamics which we want to model. However, using a programming language the designer is forced to care about a great number of irrelevant details, seen in relation to the design task. It is important that the designer can formulate the dynamic model in way which he or she feels is natural in relation to the creative line of thoughts in the mind of the designer. A programming language is not directed towards such a purpose.
Based on the observations that both diagrammatic formalisms and programming languages are unsuitable for expressing dynamic OOD models, we will in this paper discuss adequate tools for building, exploring and analyzing dynamic models. Such tools may, together, be thought of as a dynamic medium which matches the properties of the dynamic models. A program document or a diagram on a piece of paper is `dead' in comparison to a model, which is represented as a data structure in a computer-based tool. The latter may be presented and interpreted in numerous ways, which support the designer in formulating ``the right dynamic model'' of the solution to a problem, he or she is working on.