What is OOD: In our context, a design is a plan for construction. In a program design process models may be made of the program (static models) as well as of the program execution (dynamic models). The static design models, which we are interested in, are centered about overall structural properties of the program. The dynamic design models focus on overall process properties of the program execution.
An object-oriented design (ODD) is a design (following the meaning from above) 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.
The level of abstraction in an OOD model is higher than that of an object-oriented program. In an object-oriented design model we disregard a great number of details. These details are taken care of in the programming phase of the development process.
Dynamic modeling before static modeling: At the detailed programming level, it is difficult to imagine that the dynamic model (the program execution) can be explored before the static model (the program). The reason is, of course, that the program execution is governed, described, and controlled by the program in a very narrow sense. It is tempting to conclude that static modeling comes before dynamic modeling also at the object-oriented design level, but in this paper we will argue that this need not to be the case. The starting point of the argument is the following hypothesis:
At the programming level, the program can be regarded as a description of the program execution (see figure 1). At the design level the static model need not to be a description of the abstracted program execution. The reason is that the typical abstractions, which are `applied' on the program, disregard the descriptions of process properties in favor of structural properties. However, selected elements of the static model may be extracted from an initially developed dynamic model. This is because of the duality between objects and classes, and between messages and methods; Many object relations induce similar relations among classes, and vise versa.
Despite the hypothesis from above, we most often succeed in constructing static models early in the design process. However, when dealing with complicated design tasks the mental gap between
Static is easier than dynamic: It seems to be the case that static models are better developed and that static models are more often used than dynamic models i object-oriented development processes. One reason may be that there are some major and inherent difficulties in dealing with dynamic models in comparison with static models. As the term indicates, a ``dynamic model'' consist of elements which appear, change characteristic, and disappear as a function of time. It is not easy to deal with the temporal dimension of dynamic models when using a static medium for descriptions, such as paper. Often, we are limited to work on a snapshot of a dynamic model which captures the objects at a given point in time. In some models, one of the dimensions in the plane (on the paper) is devoted to time; in other models particular graphical means are related to temporal aspects. A temporal progression of snapshots, which illustrates the dynamics in a movie-like fashion, would probably be more useful, but it is awkward to deal with such unwieldy descriptions on a static medium.
The role of the media: One of the ideas behind this work is to use a computer-based tool as the medium via which to represent dynamic OOD models. There is, of course, nothing new in using a computer-based tool for the creation and maintenance of design descriptions. When we deal with analysis and design activities various kinds of CASE tools are in widespread use. Most CASE tools are used for models of the static design and program aspects. Our idea is to use tools for creation, maintenance as well as presentation and interpretation of the dynamic aspects at a reasonable high abstraction level. It may be difficult to deal with, and to understand, a dynamic model through a printed text or a diagram. As a consequence we propose that a dynamic model is viewed and understood through a separate tool. As a matter of terminology we call the presentation and interpretation tool for a dynamic exploration tool (DET).
We prefer to think of a dynamic exploration tools as a medium through which to understand the properties of a dynamic model. The nature of this medium goes perfectly hand in hand with the nature of the dynamic models, which we want to work with. The nature of the DET medium is radically different from a drawing or a piece of text on paper. It takes a great deal of efforts to interpret a description on paper as ``being alive'' in some sense. As a medium, the paper is ``dead''. In contrast, a DET is able to convey liveness. In a DET, temporal aspects and dynamic behavior can be dealt with in a natural way, and much more directly than it is possible on a ``dead medium''.
The means of expression: In the implementation phase of program development the linguistic and textual means of expression dominate. The situation is different in the area of analysis and design. Here the diagrammatic style prevails. In general, diagrams provide overview and only little detail. In addition, a diagram may be easier to understand than a text in a formal language. Although important in some respects, we claim that the means of expression is a rather superficial property of a design artifact. A DET medium, along the lines proposed above, allows us to use a variety of different means of expressions. This is achieved by supporting several external presentations based on an appropriate internal representation of the information in the underlying tool.
The degree of formalization: Besides the means of expression we can also discuss the degree of formalization. A formal description lends itself towards a higher degree of precision than does an informal description. Notice that formalization and the means of expressions, as discussed above, are orthogonal to each other. (It is possible to have both diagrams and textual documents with a varying degree of formalization and precision). Recall that we are interested in dynamic models which are created early in the OOD phase of the development process. One of our goals is to capture object creation and object interaction in a way which enhance the intuitive understanding of the object dynamics. Consequently we will argue that considerable elements of informal explanations (in pure, natural language text) is important. We will say that our description of the OOD dynamic model are narrative. An informal, narrative account does not necessarily substitute precise and formal elements of descriptions. On the contrary, there may be redundant elements in the model such that both precision and intuitive understanding are enhanced.
Thus we are proposing a description of object dynamics, in which intuitive explanations go hand in hand with more formal and precise descriptions, which are appropriate at the given level of abstraction. When the resulting descriptions are static (on, e.g., a sheet of paper) large amounts of intuitive explanations within the descriptions may easily turn out to be a problem, because it overloads the reader with information, and because it clutters the description. Using a DET medium this is not necessarily the case, because we may provide for a variety of different ways to explore the descriptions. This will be illustrated in section 4 of this paper, where we will outline a dynamic exploration tool for object-oriented design.
The level of abstraction: As noticed above, the level of abstraction is relatively high during the OOD process as compared with the OOP process. This is both the case for the static models and for the dynamic models. It is tempting and natural to compare dynamic OOD models with models of execution of an object-oriented program. It is very important to settle on dynamic OOD models which are more abstract than the actual OOP execution models. In the next section of the paper we will discuss the problem of abstraction in relation to program execution models.
