82 4 Object Diagram

4.5.2 Object Diagram Recovery

Fig. 4.11. Object diagrams for the eLib program. On the left, the diagram recovered from the driver class alone. On the right the complete diagram.

Fig. 4.11 depicts the object diagrams that are derived from the out information associated with nodes that represent class attributes. Specifically, the diagram on the left was obtained by considering only the allocation points in the driver class (Main), that is, using the results of flow propagation on the OFG of Fig. 4.9 only. Attributes users and documents of class Library have been found to reference objects User1, InternalUser1 and Book1, TechnicalReport1, Journal1respectively. Since one object of type Library is allocated in the driver class (Library1), the object diagram contains such an object with outgoing edges toward User1, InternalUser1 labeled users, and toward Book1, TechnicalReport1, Journal1 labeled documents.

When the core classes of eLib are also analyzed (OFG in Fig. 4.10), the objects Loan1, Loan2, Loan3 are added to the object diagram. Objects Loan2 and Loan3 do not reach any class attribute in the OFG after flow propagation. This means that they cannot be stored inside any class attribute. Actually, they are temporary objects used respectively to remove a Loan from the library loans (line 71) and to check if a Loan with given User and Document exists in the library list of the loans (line 78). In the first case, the method removeLoan (line 48) is executed. It removes the given Loan from the list of the loans of the library, and it updates User and Document linked to the Loan object consistently. However, the two temporary objects Loan2 and Loan3 are no longer accessible after the completion of the returnDocument and isHolding operations.

According to the result of flow propagation in the OFG of Fig. 4.10, the object Loan1is referenced by the attributes loan of Document, loans of Library, and loans of User. This is reflected in the object diagram by new associations outgoing from all objects of type Document, Library and User, and of any subtype. The attributes user and document of class Loan are found to contain the objects User1, InternalUser1 and Book1, TechnicalReport1, Journal1 respectively (see out sets in Fig. 4.9). Thus, all objects of type Loan will have an association with User1, InternalUser1 named user and with Book1,

4.5 The eLib Program

83

TechnicalReport1, Journal1 named document. The final object diagram is shown in Fig. 4.11, on the right.

4.5.3 Discussion

By contrasting the class diagram recovered in Chapter 3 (Section 3.4) for the eLib program and the object diagram in Fig. 4.11 (right), the different nature of the information they convey becomes apparent. In the object diagram, only classes of actually allocated objects are present. Thus, no node of type Document is in the object diagram, since only objects of subclasses are allocated in the program. On the contrary, in the class diagram, the class Document is represented. Moreover, in this diagram the inheritance hierarchy is visible, while it is flattened in the object diagram, where emphasis is on the actual allocation type, instead of the declared type. Correspondingly, the relationships in the class diagram are replicated in the object diagram for all objects descending from a given class. For example, the link from Document to

Loan is replicated for Book1, TechnicalReport1 and Journal1 in the object diagram. However, the target of the link is Loan1, but not Loan2 or Loan3. In other words, a link in the class diagram has disappeared in the object diagram, since the related class instances are never associated with each other by such a link. This occurs, in our example, for all incoming edges of class Loan in the class diagram, which disappear when the instances Loan2 and Loan3 are considered. Differently from Loan1, these two instances of class Loan do not participate in the associations from classes Document and User, and in the association from class Library depicted in the class diagram. Such kinds of information are not available from the class diagram, which generically indicates a set of associations for class Loan. Only when allocations of objects of class Loan are analyzed in detail, does it become clear that the object allocated inside borrowDocument is the one participating in the associations, while the other two do not.

Another interesting information that can be derived from the object diagram, but which is missing in the class diagram, is related to the outgoing links of objects Loan2 and Loan3. The document and the user that are referenced by these two temporary objects are those allocated inside the Main driver, and extracted from Library.documents and Library.users respectively (see also the OFG in Fig. 4.9). Actually, when a document is returned (temporary object Loan2) or when the presence of a loan is checked (temporary object Loan3), the involved document is obtained from the library by documentCode (docId in the command issued to the Main driver), resp. at lines 448 and 482. The user is either accessed by userCode (line 481), or it is obtained as the user who borrows a given document (method getBorrower, line 450). In all these cases, User and Document objects are extracted from those stored in the library, as depicted in the object diagram (Fig. 4.11, right).

84 4 Object Diagram

4.5.4 Dynamic analysis

Let us consider a program execution in which the following commands are prompted:

The related execution trace (over time) is given in Fig 4.12. During the static initialization of classes, the object Library1 is created and is assigned to the attribute lib of class Main (time 0). Creation of two internal users at times 1, 2 results in two new objects, InternalUser1 and InternalUser2, which are inserted into the attribute users of the object Library1. Similarly, the addition of two books (objects Book1, Book2) and of a journal (object Journal1) to the library changes the attribute documents of Library1, which eventually stores these three objects (time points 3, 4, 5). At time 6, a document is borrowed by a user. This requires the creation of a new object of type Loan, Loan1, which is inserted into Library1. loans. The attributes user and document of Loan1 are found to reference the objects InternalUser1 and Journal1 respectively. In turn, Journal1. loan is a reference to Loan1, which is the only object inside InternalUser1 . loans. Returning the document Journal1 at time 7 determines the removal of Loan1 from Library1 .loans,

InternalUser1. loans and Journal1 .loan. To achieve this, a temporary Loan object (Loan2) is created which references InternalUser1and Journal1 through its attributes user and document. It is compared with the objects in Library1. loans to identify which Loan object to remove (resulting in Loan1). Execution of the command isHolding causes the creation of another temporary object of type Loan, Loan3, which also references InternalUser1 and Journal1. The presence of an identical object inside Library1. loans is checked during the execution of the requested operation.

Fig. 4.13 shows the object diagram that can be derived from the execution trace in Fig. 4.12. Arcs in this diagram are decorated with an indication of the time interval in which the related associations exist (from creation to deletion). Thus, Library1 is associated with its documents (Book1, Book2 and Journal1) and to its users (InternalUser1 and InternalUser2) for the whole duration of the program (until time 8), starting from the creation time of each object (3, 4, 5 for the documents and 1, 2 for the users). The command borrowDoc, issued at time 6, gives rise to the creation of Loan1, connected to InternalUser1 and Journal1, and inserted into the container loans of Library1. Since at the next time point (7) such a loan is deleted,

4.5 The eLib Program

85

Fig. 4.12. Execution trace obtained by running the eLib program.

86 4 Object Diagram

Fig. 4.13. Dynamic object diagram obtained from the execution trace of the eLib program.

the links connected to Loan1 cease to exist at time 7, their life interval being [6-7]. At time 7, the temporary object Loan2 is created to achieve the deletion of the previous loan. Such an object is connected to InternalUser1 and Journal1,but the related associations do not exist any longer when the object is dismissed. Thus, their life span is limited to the execution of the command returnDoc ([7-7]). Similarly, the object Loan3 is created at time 8 to verify the presence of a loan among those in the library. Being a temporary object, its life ends with the termination of the command. Correspondingly, the associations outgoing from Loan3 have a time interval [8-8].

A comparison of the static object diagram (Fig. 4.11, right) with the dynamic object diagram (Fig. 4.13) reveals the complementary nature of the information they convey. The static diagram represents all possible associations and all possible objects that may be created at run time conservatively. On the contrary, the dynamic diagram is partial and represents only the objects and the associations created during a particular program execution. Thus, since class TechnicalReport is never instantiated in the chosen execution, the dynamic diagram does not contain any object for it, while the possibility of creating TechnicalReport objects is accounted for in the static diagram. The dynamic diagram provides more information about object multiplicity. Class Book is instantiated twice in the execution being considered, and correspondingly, two objects are in the dynamic diagram (Book1, Book2). On the other side, the number of times a given allocation is executed at run time is unknown during a static analysis, so that no multiplicity information is included in the static diagram. Moreover, the dynamic diagram provides the time intervals for the associations depicted in it. This allows distinguishing, for example, more stable relationships, such as those between Library1 and its documents or users, from temporary relationships, such as those between Loan2, Loan3 and the referenced document/user. In general, in the static diagram, times of creation and removal of relationships and objects are not apparent, in that all possible relationships at any possible execution time are shown. On the contrary, the dynamic diagram shows the exact time at which