Discussion

Static extraction and dynamic extraction of the object diagram produce dif- ferent but complementary information about the instantiations of the classes performed by a program. The static object diagram gives a conservative view of the objects that are possibly created by the program and of the relation- ships that may exist between the objects. The number of objects reflects the number of program locations where an allocation statement is present. If such a statement is executed multiple times, the actual multiplicity of the related object is greater than the multiplicity indicated in the static object diagram (i.e., one). The presence of a relationship between two objects in the static object diagram indicates that there is some path in the program along which the first object may reference the second one (through some of its attributes). The existence of a path in the program does not imply that such a path is traversed in every execution. As a consequence, the relationships between

4.4 Dynamic Analysis 77

objects indicated in the static object diagram are a conservative superset of those actually instantiated at run time. Moreover, it may happen that some of these relationships are associated to paths that can never be followed, for any input value. This is typical of static analysis: the solution is conservative, but may include infeasible parts, due to mutually exclusive conditions on the input values.

The dynamic object diagram complements the static one, in that objects are replicated in it each time a same allocation statement is re-executed, thus giving a better picture of their actual multiplicity. However, such a diagram is always partial, being based on a limited and necessarily incomplete set of test cases. An indication of the parts of the object diagram not yet explored can be obtained by contrasting it with the static object diagram. Objects and relationships in the static object diagram that are not represented in the dy- namic one are associated respectively to allocation statements and execution paths not exercised by the available test cases.

binary search tree example

As depicted in Fig. 4.3 (right), the binary tree example has a static object diagram with 4 nodes and 7 edges. The first test case executed on it (Fig. 4.8, TC1) instantiates its objects in 3 out of the 4 locations identified statically. Allocation of a BinaryTreeNode in case of left insertion (addLeft) is not exercised in TC1. Consequently, the two edges leavingBinaryTreeNode2 in the static object diagram and the two incoming edges are not represented in the first dynamic object diagram. However, the first dynamic object dia- gram provides some additional information on the multiplicity of the object

BinaryTreeNode3 (Fig. 4.3), which appears to be greater than 1. On the contrary, a unitary multiplicity seems to be confirmed for BinaryTree1 and

BinaryTreeNode1 (Fig. 4.3). Correspondence between the objects identified statically and those identified dynamically is as indicated in Table 4.2.

The second test case generates a dynamic object diagram (Fig. 4.8, TC2) in which all objects in Fig. 4.3 are represented. The last test case (Fig. 4.8, TC3) reveals that the multiplicity ofBinaryTreeNode2 (Fig. 4.3) can also be greater than 1.

The comparison of the diagrams in Fig. 4.8 (right) with that in Fig. 4.3 highlights the different and complementary nature of the information they provide. The actual shape of the allocated objects (a tree) becomes clear only when the dynamic diagrams are considered. However, they cannot be taken alone, since they do not represent all possible cases that may occur in the program. Inspection of the static object diagram allows detecting portions of the code not yet exercised, which are relevant for the construction of the objects and of the inter-object relationships, and therefore could contribute to the understanding of the object organization in the program.

With reference to the diagram in Fig. 4.3, the relationship between

BinaryTreeNode2 andBinaryTreeNode3 labeled right, and that between

BinaryTreeNode3 and BinaryTreeNode2 labeled left, are not represented in any dynamic diagram (see Fig. 4.8). Two additional test cases can be de- fined to exercise them:

TC4 ("c", "a", "b")

TC5 ("a", "c", "b")

This highlights one of the advantages of combining the static and the dynamic method, consisting of the support given to the programmers in the production of the test cases.

4.5 The eLib Program

The code of the classes in the eLib program, provided in Appendix A, does not contain the statements allocating objects of typeUser, Book, etc. In fact, it is assumed that an external driver program performs such allocations. The classes in this appendix offer functionalities for general library management, but do not include a sample implementation of an actual library application. Appendix B contains an example of such an application, with a driver class (Main) that can be used to create a library, add/remove users and documents and manage the process of borrowing/returning documents. This is the list of commands that can be issued to the Main driver from the command prompt:

4.5 The eLib Program 79

Each command is dispatched by the methoddispatchCommand (line 504), triggering the execution of a proper method of classMain (the method name is coincident with the command name). In turn, the called method exploits the functionalities provided by the core classes of the eLib program to complete its task. Thus, for example, method addUser (line 379) creates a new User

object, passing the parameters of the command (name, address, phone) to the constructor (line 382). The resulting object is added to the library by calling method addUser on the static attribute lib of class Main (line 383). Such an attribute references a statically allocated Library object, accessible to all methods of classMain.

A meaningful object diagram can be produced for the eLib program by analyzing both the code in the core classes (Appendix A) and that in the driver class (Appendix B). Actually, core classes perform just allocations of objects of typeLoan, inside methods for loan management, such asborrowDocument

(line 60), returnDocument (line 70) and isHolding (line 78). All the other object allocations are performed inside methods of classMain (Appendix B). Thus, if class Main is not included, a scarsely informative object diagram would be obtained, with only three nodes representing objects of typeLoan, disconnected with each other.