In Booch's book Object-oriented Analysis and Design with Applications (2. edition) [2] two different dynamic modeling notations are introduced. The first of these, which is called object diagrams, presents a dynamic model as a graph, where the nodes are objects and where the edges are object relations in a broad sense. Following Booch's notation it is possible to adorn both nodes and links with a variety of details. The second notation is interaction diagrams. As acknowledged by Booch, the interaction diagrams in the Booch notation are very similar to Jacobsons's interaction diagrams which we described in section 5.2 of this paper. In addition interaction diagram and object diagram carry the same semantics. Consequently, we will limit ourselves to a discussion of Booch's object diagrams in this paper.
Booch introduces Object Diagrams through a simple example, which we have reproduced in figure 14. We will not here explain the details of Booch's notation nor the intuition behind the example; for that purpose the reader should consult section 5.4 of [2]. From the figure it it appears that a PlanAnalyst object sends a message timeToHarvest to the PlanMetrics ``utility class'' (a collection of procedures) which in turn activates GardeningPlan object. The GardeningPlan object is seen to be a parameter of the PlanMetrics procedure (because of the P symbol in the GardeningPlan object). Further on, the GardeningPlan object sends the message maturationTime to the C object (of type GrainCrop). The latter is a part of the GardeningPlan object because of the F symbol in C. The temporal sequencing of the messages is described by the numbers in front of each message.
A number of additional graphical means associated with the nodes and edges make it possible to describe such aspects as (1) the returned object from an operation, (2) roles of the object associations, (3) data flow, (4) syncronization among objects, and (5) informal 'development notes'. It is not intended that all these aspects should be present on all objects or object relations in an object diagram. Still, it is our evaluation that one can easily end up with complicated and cluttered diagrams.
When dealing with object diagrams from Booch, the designer's attention is attracted towards the graphical means of expressions in the diagrams. The degree of formalization is relatively high, compared with Jacobson and the BON notation, not least because it is required that the object diagram should be consistent with a preexisting static model (a class diagram). In itself the diagrammatic style of presentation appeals to the reader's intuition: It is possible to see a number of objects that communicate via the established object relations. In addition, a number of qualities of the objects and the object communications can be read directly from the applied adornments.
As a weakness of the approach behind the Booch object diagram it can be noticed that there is a limit to the number of aspects of a dynamic model that can be put into a graph presentation, as adornments. The limit is probably already reached in the proposed notation. If it is attempted to add elements of explanations (along the lines of the so-called development note in figure 14), the diagram would be totally overloaded with information.
In figure 15 we show a trace of the example from figure
14 in the notation adopted for this report. We are
mainly interested to show the structure of a scenario trace of the
graph in figure 14. (The details, especially the
intuitive explanations, are only standard strings).
We provide the four
different objects as being on an initial scene.
(There is no need for objects that show up during the scenario).
Notice that we are able to express that the C object is part of the GP object,
see line four of the trace in figure 15.
This corresponds to the small F symbol in the GrainCrop object in figure
14.
In our approach to making dynamic models, we are able to deal with the problem of 'information overloading', because we focus on an internal representation instead of just means of digrammatical presentation. A trace is only one out of many possible presentations, which may select information from the internal representation and somehow present that information for the designer.
Using Booch's object diagrams it is not possible to capture creation of new objects (nor destruction of existing objects). In that respect, object diagrams are similar to the other dynamic models we have found in the literature and described in this paper. It is, however, interesting to observe that Rumbaugh has introduced a notation called object interaction diagrams for the 2nd-generation OMT method (JOOP paper) which to some degree is able to capture the creation of new objects in the notation. In many respects, Rumbaugh's object interaction diagrams are similar in style to Booch's object diagrams, although different graphical conventions are used. What is important here is that Rumbaugh propose to use colors (or similar means) in order to distinguish existing objects, new objects, and disposed objects from each other. This may be useful in some limited scenarios, but it is difficult to imagine that colors can be used to give a full account on the temporal aspects of dynamic models.
As we have done for both the BON notation and for the Jacobsons's interaction diagrams, we will finally in this section show how the circle construction problem can be expressed in a Booch object diagram, see figure 16.
In step 1, the message circleThroughPoints is sent to APoint. In step 2 and 3 we construct two line segments from APoint to P, and from Apoint to Q. We see that these messages return the lines L1 and L2. In step 4 the central line of L1 is found. The resulting object is called CL1. Step 5 through 7 show the different step that are necessary for the construction of CL1. It might be attractive to modularize the scenario such that the details involved in the construction of a central line is shown in its own scenario. We also need the central line CL2 of L2, but the messages that are involved in constructing it are not shown on figure 16. In step 8 we test whether the two central lines are parallel. As it appears, we assume in the shown scenario that they are not. In step 9 we find the center point of the desired circle as the intersection of CL1 and CL2, and we find the distance from the center point to one of the original points (step 10). Finally we construct the circle in step 11 (by sending a message to the class Circle).
By using the dataflow symbol to indicate returned values and returned objects from messages, it is possible to indicate which objects are created by which message. However, all the necessary details make the object diagram quite difficult to read (and difficult to produce and maintain). And as it has been the case for all static presentations of dynamic models, which we have exercised in this paper, the actual dynamics of object creation cannot easily be captured. I.e., all the objects are present in the figure, although the majority of the objects actually appear during the construction process (and disappear again, because they are only temporary objects, local to some of the methods involved in the construction task).
