As discussed above we distinguish between the programs and program executions. These characterize the static aspects and the dynamic aspects of program development respectively. In this paper we discuss a similar distinction in the area of object-oriented design. More specifically in this paper our interest is the dynamic aspects of object-oriented design.
Abstraction is familiar and well-known when we talk about programs. Many key elements in modern programming languages are related to abstraction. Similarly, static design models do in themselves represent abstractions over a lot of details. On this background we find it natural to study abstraction possibilities over the details in actual and concrete program executions. In the object-oriented paradigm the program execution elements are objects and messages. The purpose of this section is to develop a model which elevates the dynamic behavior of objects from the implementation level to a design level.
At the programming/implementation level, the behavior at the dynamic level is governed and controlled by the description, which we call the program. As such, the actual program execution is in part described and derived from a static model. At the design level, it may be difficult to imagine a similar impact on the dynamic model from the static models. The problem is that we in most static design models have abstracted away from the aspects which are related to execution behavior. Furthermore, we are interested in dynamic design models which are independent of static models, such that dynamic models can be studied before we develop any static model of the software.
We will now analyze abstract program execution models, and describe these in relation to actual program execution models. We focus on the following elements in the actual execution model of an object-oriented program:
We see that the actual execution model has been chosen as a clean object-oriented model without surrounding procedural or functional elements as such. Objects and messages are the central elements. In the following we will discuss the abstract execution models in relation the elements of the actual execution model, which we outlined above.
Objects and object fields: It has to be decided to which degree internal aspects of objects, which carry the object state, are part of the dynamic OOD model. In the most concrete extreme the fields and field types from the actual execution model are also included as elements in the dynamic model (with or without type information). In the most abstract extreme the internal object aspects are abstracted away entirely. In between these, one can imagine that we identify a number of different states of the object. Here, a `state' is a more abstract notion than the vector of actual object fields. One can also imagine that we represent the object state in terms of the operation history. As discussed in section 2, these possibilities may all be formalized, or they may be kept informal. This design space is illustrated in figure 2.
Object relations: The object relations define a logical structure among the objects. The logical structure among the objects is important in its own right, not least because the object relations may induce similar relations among the classes of objects. Thus, relations among objects may give hints to the structure of the software we are working with. In addition, the relations among objects allow us to access one object O1 from another object O2, provided that O1 can be reached via a relation from O2. Reachability may be handled via the object fields, if they are part of the dynamic model. Alternatively, reachability may be handled via an object naming scheme, introduced exclusively for the purpose of the dynamic model. The naming scheme may or may not reflect object visibility in the actual execution model.
Relations between objects and classes: The relations between objects and the classes, of which the objects are instances, are important, because they provide the links between a dynamic model and the static models which are to be developed later on. Thus, in our dynamic models, we find it necessary to have a notion of classes, and to relate an object to its instantiating class.
Messages: It is appealing to use the message passing metaphor for object interaction. Messages cause activations of procedures or functions on objects, and as such the messages are crucial elements of a dynamic model. There are two objects involved in a act of sending a message: a sender and a receiver. At the programming level the receiver is specified in a rather direct way, whereas the sender is identified more indirectly (as ``the current object''). In a dynamic object model we have the possibility to chose an explicit or implicit determination of the sender and/or the receiver of a message. The actual parameters are in general expressions, but in the dynamic object model they may be limited to be notions of objects. The parameter passing and parameter correspondence mechanisms are also up to discussion in the model.
In the actual execution model, the impact of a message may be an effect on the program state and/or an object, which is the value returned as result of a message passing. The impact of a message may be important enough to warrant some special attention in the dynamic model. This can be done by accompanying each message with an account on its result. This account may be formal, informal, or both.
The start situation: The start situation designates in the most limited version an object which receives an initiating message. In the dynamic model this may be extended to a set of pre-existing objects on which the execution may take off.
Classes: Classes are elements of a program, and as such they belong to the static model, but, as already mentioned, it is important to provide information in the dynamic model which let us bridge the gap between the two kinds of models. For our purposes there seems only to be a little point in injecting a complete static model into the dynamic model. One or more static models should probably be worked out besides the dynamic model. As discussed in section 2, it is the idea of this work that the static models are created after the dynamic model. As a consequence, we should probably only include the classes and the class relations that are necessary to make sense out of the dynamic properties, and which let us ``build a bridge'' from the dynamic model to a static model.
Because of the duality between the set of object and their relations on the one hand, and the set of classes and their relations on the other hand, it may be possible to automatically derive some properties of the static model from the dynamic model. As an example, the class attributes and their types may be derived from the object fields, provided that the relation among objects and classes is present. Similarly, aggregation and association among classes may be derived from the relations (`containment' and `reference to') among the objects. In contrast, it is probably more difficult to induce the generalization/specialization relationship among classes from the object relations, because this relationship does not leave much trace in the object space.
Methods: Methods are parts of the program description. In most object-oriented design methods, methods are important elements in the central static models. Like procedures and functions, methods are abstractions of commands or expressions, and as such they play an important role also in a dynamic model. At our level of abstraction we do not care whether methods are shared among objects which are instances of the same class. (This is a distinction which, of obvious pragmatic reasons is important in the actual execution model). Given a message from one object to another, it is a method in the receiver-object which is responsible for the state transition in the dynamic model. Selected aspects of the state transition is one of the key issues in a dynamic model, and consequently the treatment of the methods becomes a crucial theme in our discussion.
In the static model the methods are organized to form ``horizontal layers'' in relation to the overall program architecture. It is usually recommended only to consider one layer at a time. Thus the methods in a layer can be regarded as black boxes that exclusively are concerned with fulfilling the contractual obligations in respect to their clients (which often are at a higher level). In a dynamic model, where we are concerned with understanding the mutual interplay among objects via messages, it may be the best approach to study ``vertical cuts'' of methods, which are linked together with message passings (method activations). This is illustrated in figure 3.
As a minimum we want our dynamic model to include object allocation and object mutation aspects. I.e., selected object births and object mutations, as prescribed in a method, should be captured in the dynamic object model. (The level on which to deal with object mutation depends on the level we deal with fields/state of the objects. This has been discussed above). In the one extreme, the description can follow a fixed control course, and as such we will call it a scenario. A scenario is an example execution which involves a number of objects and a number of messages. The model builder determines the branch of each selection and the number iterations in each loop in advance, at model definition time. In the other extreme we deal with a prescription which can include the actual variations in the control (selection and iteration), along the lines of the actual program execution; such a prescription will be called a high level program. If complete enough, one can imagine that a high level program can be used for a simulation of the program execution at a high abstraction level.