OFG Construction

The OFG representing object allocations in the Main class and object propa- gation 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 state- ments. 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.

4.5 The eLib Program 81

It can be noted that invocation of method authorizedLoan on the param- eterdoc of method borrowDocument (class Library) at line 59 is a polymor- phic call. Consequently, the method actually invoked may be that defined in classDocument, or that overridden by classesJournal andTechnicalReport

(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 asso- ciated 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 state- ments involving containers, as described in Chapter 2. For example, the edge from Library.addUser.user to Library.users results from the invocation of methodput onLibrary .users, an object of typeMap (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 methodborrowDocument at line 60 is named Loan1, the one allocated insidereturnDocument at line 70 is namedLoan2, and the one allocated inside isHolding at line 78 is namedLoan3. 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 containingLoan3, 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 classLibrary (line 78). This requires a direct invocation of methodcontains, 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.

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 infor- mation 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. Attributesusers anddocuments of classLibrary

have been found to reference objectsUser1,InternalUser1 and Book1,

TechnicalReport1,Journal1 respectively. Since one object of typeLibrary

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 ofeLib are also analyzed (OFG in Fig. 4.10), the objectsLoan1,Loan2,Loan3 are added to the object diagram. Objects Loan2

andLoan3 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 aLoan from the library loans (line 71) and to check if aLoan with givenUser andDocument exists in the library list of the loans (line 78). In the first case, the methodremoveLoan

(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 thereturnDocument andisHolding

operations.

According to the result of flow propagation in the OFG of Fig. 4.10, the ob- ject Loan1is referenced by the attributesloanofDocument,loansofLibrary,

andloans ofUser. This is reflected in the object diagram by new associations outgoing from all objects of typeDocument,Library andUser, and of any sub- type. The attributesuser anddocument of classLoan are found to contain the objects User1, InternalUser1 and Book1, TechnicalReport1, Journal1

respectively (see out sets in Fig. 4.9). Thus, all objects of typeLoan will have an association withUser1,InternalUser1 named user and with Book1,

4.5 The eLib Program 83 TechnicalReport1,Journal1 nameddocument. 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 di- agram, 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 forBook1,TechnicalReport1 andJournal1 in the object diagram. However, the target of the link isLoan1, but not Loan2 or Loan3. In other words, a link in the class diagram has disappeared in the object dia- gram, 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 fromLoan1, 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 in- dicates 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 al- located 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 di- agram, 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 ref- erenced by these two temporary objects are those allocated inside the Main

driver, and extracted fromLibrary .documents andLibrary .users respec- tively (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 (tempo- rary 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 byuserCode (line 481), or it is obtained as the user who borrows a given document (methodgetBorrower, 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).

4