56 3 Class Diagram

Fig. 3.6. OFG for a portion of the eLib program. Set gen1 is used during forward flow propagation, while gen2 is used for backward propagation.

This allows a precise estimation of the contained object types. The attribute users of class Library contains objects of type User, so that an association can be drawn in the class diagram between Library and User. Similarly, the class attribute documents has been found to contain objects of type Document, resulting in the recovery of an association between Library and Document. Both associations are completely missed if container analysis is not performed.

3.4 The eLib Program

Fig. 3.7 shows the class diagram obtained by applying the basic reverse engineering method described in Section 3.1, which takes only declared types into account, to the eLib program. Since typically interconnections due to dependencies that are not associations tend to make the class diagram less readable, they have not been considered in Fig. 3.7. Only the two most important interclass relationships, associations and generalizations, are displayed. Moreover, class attributes and methods are hidden, to simplify the view, and only class names are shown.

Apparently, the class Library holds no stable reference toward the other classes in the system. In fact, it is an isolated node in Fig. 3.7. This is due to the usage of Java containers to implement associations with multiplicity greater than one. Specifically, its fields documents, users and loans are

3.4 The eLib Program

57

Fig. 3.7. Class diagram for the eLib program, obtained without container analysis.

Java containers (the declared type is the interface Map for the first two, and Collection for the latter).

A bidirectional association exists between classes Loan and Document, in that a Loan object holds a reference toward the borrowed Document object, and vice versa, a borrowed Document has access to the Loan object with data about the loan. While one would expect a similar bidirectional association between Loan and User, such a connection seems to be unidirectional, according to the class diagram in Fig. 3.7. The reason for the missing association between User and Loan is that the related multiplicity is greater than 1 (a user can borrow several documents). From the implementation point of view, the problem is the usage of a container (actually, a Collection) for the field loans of class User. On the contrary, since a document can be borrowed by exactly one user, the association from Document to Loan has the multiplicity one, and is implemented as a plain reference, that can be easily reverse engineered from the code.

To summarize, the class diagram depicted in Fig. 3.7 does not represent associations with multiplicity greater than one, since they are implemented through containers. Execution of the container analysis algorithm described in Section 3.3 is thus of fundamental importance for this program.

Fig. 3.8 shows the class diagram for the eLib program, produced by taking into account the estimated classes of the objects stored inside containers. The previously missing association between User and Loan has now been correctly recovered. This is achieved by considering the set out [User. loans] = {Loan} after flow propagation for container analysis.

Class Library is no longer a disconnected node in the diagram. Its container attributes have been analyzed, and the type determined for the contained objects allows drawing association relationships toward User, Loan and Document. They correspond to an intuitive model of a library, where the list

58 3 Class Diagram

Fig. 3.8. Class diagram for the eLib program, obtained after performing container analysis.

of registered users is available, as well as the archive of the documents and the set of loans currently active. The class diagram in Fig. 3.8 is much more informative and accurate than that in Fig. 3.7. A programmer that has to understand this application will find it much easier to map intuitive notions about a library to software components by means of the diagram in Fig 3.8.

Fig. 3.9 completes the class diagram in Fig. 3.8 with the dependency relationships, which are shown only if they connect two classes otherwise not connected by an association (association is subsumed by dependency). Class User iteratively accesses Document objects (through the association with Loan) inside method printInfo(line 323), where code and title of borrowed documents are printed (line 332). The related method calls (getCode and getTitle) are the reasons for the dependency from User to Document. In the reverse direction, the dependency is due to calls of methods getCode and getName, issued at lines 220 and 221 inside printAvalability (line 215). When a document is not available, the code and name of the user who borrowed it are printed. The User object on which calls are made is obtained from the Loan object (attribute loan) reachable from Document, which is non-null in case the document is borrowed (not available).

The dependency from Journal to User is due to the implementation of method authorizedLoan in class Journal (line 253). The base implementation of this method, in class Document, returns the constant true: every user is authorized to borrow any document. This implementation is overridden by the class TechnicalReport, returning the constant false (technical reports can be consulted, but not borrowed). The class Journal also overrides it, delegating the authorization to class User (hereby, the dependency), in that only internal users (class InternalUser) are authorized to borrow journals (line 254).