78 4 Object Diagram

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 of BinaryTreeNode2 (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 and BinaryTreeNode3 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 defined 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 type User, 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 method dispatchCommand (line 504), triggering the execution of a proper method of class Main (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 class Main.

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 type Loan, inside methods for loan management, such as borrowDocument (line 60), returnDocument (line 70) and isHolding (line 78). All the other object allocations are performed inside methods of class Main (Appendix B). Thus, if class Main is not included, a scarsely informative object diagram would be obtained, with only three nodes representing objects of type Loan, disconnected with each other.

4.5.1 OFG Construction

The OFG representing object allocations in the Main class and object propagation from allocation points to class attributes is shown in Fig. 4.9. Allocated objects are in the gen sets of the left hand side locations of allocation statements. The result of flow propagation is depicted only for nodes representing class attributes (Library. users, Library.documents, etc.). Their out sets contain the possibly referenced objects, according to the result of the static object analysis conducted on this OFG.

80 4 Object Diagram

Fig. 4.9. OFG of the eLib program for object diagram recovery, driver class.

4.5 The eLib Program

81

It can be noted that invocation of method authorizedLoan on the parameter doc of method borrowDocument (class Library) at line 59 is a polymorphic call. Consequently, the method actually invoked may be that defined in class Document, or that overridden by classes Journal and TechnicalReport (Book does not override it), depending on the actual type of the invocation target doc. Conservatively, edges in the OFG are drawn from the node associated with doc to the this location of all methods possibly invoked in the polymorphic call (see Fig. 4.9, bottom right edges).

Construction of the OFG in Fig. 4.9 requires a transformation of the statements involving containers, as described in Chapter 2. For example, the edge from Library.addUser. user to Library.users results from the invocation of method put on Library . users, an object of type Map (line 10).

Fig. 4.10. OFG of the eLib program for object diagram recovery, core classes.

Fig. 4.10 contains the OFG for allocation points inside the core classes (Appendix A). Containers are handled similarly as for the OFG in Fig. 4.9. Only objects of type Loan are allocated inside core classes code. The Loan object allocated inside method borrowDocument at line 60 is named Loan1, the one allocated inside returnDocument at line 70 is named Loan2, and the one allocated inside isHolding at line 78 is named Loan3. The OFG portion that propagates these objects is shown in Fig. 4.10, where allocated objects are contained in gen sets. No node has a gen set containing Loan3, since this object is not propagated any further inside user classes. It is just used to check the presence of a Loan object referencing a given User and Document in the Collection loans of class Library (line 78). This requires a direct invocation of method contains, implemented by a standard library (not a user) class. In Fig. 4.10, out sets are shown only for locations representing class attributes. They are exploited for object diagram construction.