Vídeo caso.

objects. While this is not apparent in the class diagram, the object diagram represents this kind of information explicitly.

Let us consider a hypotheticalBinaryTree program. In its class diagram, there might be oneBinaryTreeNode class, with two auto-associations named

left and right for the two children, while a possible instance represented in the object diagram might include three objects of typeBinaryTreeNode, playing three different roles (i.e., tree root, left child and right child). The re- lationships among these three elements are compliant with those in the class diagram, but provide more information on the layout of the related instances by showing a specific scenario (where the root references two children which have no further descendants). Moreover, the object diagram is the starting point for the construction of the interaction (collaboration and sequence) di- agrams, where information about the message exchange between objects is added to the class instances, thus focusing the view on the dynamic behavior of a set of cooperating objects (a collaboration, in the UML terminology).

In the following text, two techniques are described for the recovery of the object diagram. The first exploits only static information and approxi- mates the set of objects created in the program by analyzing the allocation (new) statements and propagating the resulting objects by means of the flow propagation algorithm described in Chapter 2. The second considers a set of execution traces, associated with the test cases available for a given program, and obtained by running an instrumented version of the given program. Exe- cution traces include information about each object allocated by the program, uniquely identified, and its attributes. Object attributes which reference other objects are used to recover inter-object associations. These two techniques have advantages and disadvantages, and it is therefore desirable to be able to compute and integrate the results of both of them.

4.2 Object Diagram Recovery

The static computation of the object diagram exploits the flow propagation on the OFG to transmit information about the objects that are created in the program up to the attributes that reference them. Objects are identified by allocation site (i.e., the line of code containing the allocation statement), with no regard to the actual number of times it is executed (which is, in general, undecidable for a static analysis).

Fig. 4.1 shows the flow information that is propagated in the OFG to recover the object diagram. Each allocation site (statement of kind (5)) is associated with a unique object identifier, constructed as the class name subscripted by an incremented integer (giving the object identifier Such flow information is propagated in the OFG according to the algorithm given in Chapter 2, in the forward direction.

Construction of the object diagram is a straightforward post-processing of the computation described above. Every object identifier generates a

66 4

Fig. 4.1. Flow propagation specialization to determine the set of objects allocated in the program that are referenced by each program location.

corresponding node in the object diagram. Every node in the OFG associated to an object attribute, i.e., having a prefix and a suffix where is an attribute of class is taken into consideration when inter-object associations are generated. The out set of such an OFG node (i.e., out[c.a]) gives the set of objects reachable from all objects of class along the association implemented through the attribute Such an association can thus be given the name of the attribute,

binary search tree example Object Diagram

4.2 Object Diagram Recovery 67

The abstract syntax representation of the Java code fragment above is the following:

Fig. 4.2. Object flow graph for the binary tree example.

Fig. 4.2 shows the OFG derived from the abstract statements above. Non empty gen sets of OFG nodes are also shown. Objects of typeBinaryTreeNode

are allocated at three distinct program points, thus originating three ob- ject identifiers,BinaryTreeNode1,BinaryTreeNode2andBinaryTreeNode3, which are in the gen set of the respective left hand side locations (BinaryTree- .root,BinaryTreeNode.addLeft.n andBinaryTreeNode.addRight.n). Since there is just one allocation statement for BinaryTree objects, the only ob- ject identifier for this class is BinaryTree1, inserted into the gen set of the allocation left hand side,BinaryTree.main.bt.

After flow propagation, the following out sets are determined for the class attributes:

Construction of the object diagram is now possible. Every object identi- fier becomes a node in the object diagram. Thus, in the example above four nodes are inserted into the diagram, three of class BinaryTreeNode and one of

classBinaryTree. The out sets of the class attributes after flow propagation determine the inter-object associations. Thus, object BinaryTree1 is associ- ated with BinaryTreeNode1 through the attribute root, used as the associ- ation name. All three objects of type BinaryTreeNode are associated with

BinaryTreeNode2 through a link named left, and with BinaryTreeNode3

through a link namedright.

Fig. 4.3. Class diagram (left) and object diagram (right) for the binary tree exam- ple.

Fig. 4.3 shows the object diagram recovered from the code of the binary tree example on the right. For comparison, the related class diagram is de- picted on the left. As apparent from this figure, the class diagram is less infor- mative than the object diagram. In fact, the three elements BinaryTreeNode1,

BinaryTreeNode2, BinaryTreeNode3of the object diagram are collapsed into a single element (BinaryTreeNode) in the class diagram, with two auto- associations (left and right). The object diagram makes it clear that the attribute root of class BinaryTree always references the object identified as

BinaryTreeNode1 (first allocation site), while attributes left and right ref- erence respectively the objects BinaryTreeNode2 (second allocation site) and

BinaryTreeNode3(third allocation site).