106 5 Interaction Diagrams

(in general) be identified statically. However, the result is conservative. There does not exist any interaction among objects that is not represented in a statically recovered interaction diagram. Moreover, objects involved in the interactions are necessarily of one of the classes reported in the static diagrams, and cannot be of any other class.

The main limitation of the statically recovered interaction diagrams is related to the identity of the objects represented in the diagrams. When two arcs depart from a same object or enter a same object in a static interaction diagram, it cannot be ensured that the same object will actually issue or receive the calls associated with such arcs. In fact, object identity is given by the allocation statement in the program, but such a statement can be in general executed multiple times, giving rise to different objects that are represented as a single element in a static interaction diagram. On the contrary, the identity of the objects represented in dynamic interaction diagrams is based on a unique identifier that is generated and traced at run time for each newly created object. Thus, a precise object identification is possible, and correspondingly the presence of call arcs departing from or entering into the same object indicates that exactly this object is involved in the interaction.

On the other side, the main limitation of the dynamic diagrams is related to the quality of the test cases used to produce them. It may happen that not all possible interactions are exercised by the available test cases, or that not all possible type combinations are tried. In order to increase the amount of information carried by the dynamic views, it is possible to measure the level of coverage achieved with respect to the corresponding static diagram. Thus, a test case selection criterion may be defined as follows: if all object types and all possible interactions in the static diagram are covered by the available test cases, the set of dynamic diagrams obtained from the execution traces can be considered satisfactory.

From the point of view of the usability of the diagrams, static and dynamic views have contrasting properties. A static diagram concentrates all the information about the behavior of a method in a single place, the interaction diagram focused on the given method, while several dynamic diagrams may be necessary to cover all relevant interactions associated to a given method. This indicates a higher usability of the static diagrams, since just one diagram per method must be inspected. On the other side, static diagrams tend to be larger than dynamic diagrams, in that the latter account for a specific, limited execution scenario, while the former represent all possibilities.

5.4 The eLib Program

The full, static interaction diagram for the eLib program (Appendix A and B), obtained by considering all interactions among objects possibly triggered by the main control loop (line 527), contains a number of nodes, arcs and labels largely beyond the cognitive capabilities of a human being, mainly because

5.4 The eLib Program

107

of the high number of edges and of the very high number of labels (more than 200) on the edges (each edge label represents a method call). It should be recognized that this happens for a relatively small application such as eLib. In larger, more realistic, programs the problem is exacerbated. Consequently, usage of the focusing technique described in Section 5.2.2 appears to be mandatory for any program under analysis.

When focused interaction diagrams are taken into consideration, their size is largely reduced. If focused diagrams are produced for the eLib program, the typical number of edges is between 5 and 10, while labels are typically in the range 5-20. Thus, focusing seems to be a very effective technique to make the information reverse engineered from the code useful and usable. Interaction diagrams focused on selected methods restrict the scope of the program comprehension effort to a given computation and provide an amount of data that can be managed by a human being. Overall, they represent a good trade-off between providing detailed information and considering a single functionality at a time.

Fig. 5.11. Collaboration diagram focused on method borrowDocument of class

Library.

Fig. 5.11 shows the collaboration diagram obtained by focusing on the method borrowDocument of class Library. The interactions occurring among the objects to realize the library functionality of document loan are pretty clear from the diagram. First, the number of loans held by the user who intends to borrow a document is checked (call to numberOfLoans), and if it exceeds a given threshold the loan is negated. Then, availability of the selected document is verified (call to isAvailable). A third check is about the authorization to borrow the chosen document. The method authorizedLoan is called on the given document, which may belong to class Book, TechnicalReport or Journal. In the first two cases, method authorizedLoan return a fixed value (resp. true and false). In the last case, authorization depends on the user category. Thus, the value returned by authorizedLoan is obtained by invoking the method authorizedUser on the borrowing user. This method re-

108 5 Interaction Diagrams

turns true for internal users, who have more privileges than the normal user, while it returns false for the other users. In the diagram, it can be observed that authorizedLoan is numbered 3 and authorizedUser is numbered 3.1. The latter is a nested invocation occurring only when the target object of authorizedLoan is of type Journal.

If all checks give positive answers, the document can be borrowed. This is achieved by calling the method addLoan (call number 4), after creating a new Loan object (Loan1). In turn, this call triggers the execution of four nested methods. First of all, user and document are accessed from the Loan object Loan1 (calls 4.1 and 4.2). Then, method addLoan is invoked on these two objects of type User and Document (calls 4.3 and 4.4). In this way, a bidirectional association is created between Loan object and User object, and between Loan object and Document object.

Fig. 5.12. Sequence diagram focused on method returnDocument of class Library.

Fig. 5.12 shows the sequence diagram focused on the method returnDocument of class Library. It clarifies the message exchange that occurs when a document is returned to the library. First of all, a check is made to see if the document is actually out (call number 1, isOut). If this is not the case, nothing has to be done. A nested method execution is triggered by isOut, which resorts to isAvailable to produce the answer. If the document is out, its current borrower is obtained by requesting it via the document (call to

5.4 The eLib Program

109

getBorrower, number 2). In turn, the Document object redirects the request of the borrower to the Loan object associated to it (call 2.1, getUser). It should be noted that the involved Loan object is Loan1, i.e., the instance allocated at line 60. A new, temporary Loan object (Loan2, allocated at line 70), is then created and passed to removeLoan (call number 3) as a parameter. Inside removeLoan (nested activation in Fig. 5.12) user and document associated with the temporary Loan object are obtained (calls 3.1 and 3.2), and a call to method removeLoan on both of them (calls number 3.3 and 3.4) deletes the associations of these two objects toward the Loan object being removed. In this way, not only the Loan object is removed from the list of current loans held by the Library, but the inverse associations from User and Document to Loan are also updated. The resulting state of the library is thus consistent.

Class Library provides methods to print information about stored data. Two examples of methods that can be invoked for such a purpose are printAllLoans and printUserInfo. Their interaction diagrams are displayed in Fig. 5.13 and 5.14.

Fig. 5.13. Collaboration diagram focused on method printAllLoans of class

Library.

The first and only method execution invoked inside method printAllLoans (from class Library) is on object Loan1. Such an invocation, numbered 1 in Fig. 5.13, is iterated as long as the condition reported in square brackets before the method name (print) is true. This condition requires that method hasNext, called on the iterator i running over all loans in the library, returns true. Thus, printAllLoans delegates the print functionality to the Loan objects stored in the library inside an iteration. In turn, each Loan object can print complete loan information by requesting some of the data to the User and Document objects associated with it. This is the reason for the nested calls 1.1, 1.2 (toward objects InternalUser1 or User1) and 1.3, 1.4 (toward objects Book1, TechnicalReport1, Journal1).

This example highlights the usefulness of showing conditions in square brackets. The existence of an iteration over all loans in the library can be

110 5 Interaction Diagrams

grasped immediately from the collaboration diagram, due to the indication of a loop (asterisk before the call to print) and of the loop condition (in square brackets). While for larger diagrams the explicit indication of all conditions in square brackets may make them unreadable, because of an excessive label size, for small or medium size diagrams it may be extremely useful to include them in the arc labels. They provide important hints on the behavior of the method under analysis.

Fig. 5.14. Sequence diagram focused on method printUserInfo(User user) of class Library.

The method printUserInfo from class Library (see Fig. 5.14) has a parameter of type User, referencing a User object. The printing of information about this library user is completely delegated to the User object. Thus, printUserInfo contains just a method call, numbered 1, that transfers the control of the execution to method printInfo of class User. Inside this method, several data are obtained on the current object, by activating nested method invocations (numbered 1.1, 1.2, 1.3, 1.4). Then, the sequence of loans held by the given user are considered iteratively. For each of them, the borrowed document is requested (call to getDocument, number 1.5). The identifier and title of such a document are then accessed, by means of methods getCode (number 1.6) and getTitle (number 1.7). These further calls

5.4 The eLib Program

111

are still inside the same iteration. Retrieved information about the borrowed documents is printed to the standard output.

The sequence diagram depicted in Fig. 5.14 exploits the following results of flow propagation in the OFG:

out[User.loans]= {Loan1}

out[Loan.document] = {Book1, TechnicalReport1, Journal1}

Such results are conservative, but inaccurate in two respects: different loans should be associated with different kinds of users and no document of kind TechnicalReport should be ever present in a loan. In fact, documents of type Journal can be borrowed only by internal users (see check at line 59). Consequently, one would expect that User.loans and InternalUser.loans reference two different sets of objects, where only the second contains loans of Journals. On the contrary, only one node, User.loans, is in the OFG, and InternalUser just inherits the value of attribute loans from its superclass. On the other side, the authorization of a given User to borrow a document depends on the outcome of the call at line 59, to method authorizedLoan. A static analysis of the source code can hardly distinguish among the possible outcomes of this call, depending on the actual type of the target object and of the parameter. Similarly, the impossibility of creating a new loan when the given document is of type TechnicalReport is also hard to determine from a static analysis. In fact, it still depends on the outcome of the call to authorizedLoan at line 59.

The inaccuracies of the static analysis used to approximate the objects referenced by the attribute loans of class User and by the attribute document of class Loan have the following consequences for the sequence diagram in Fig. 5.14. The two calls to getCode and getTitle (numbered 1.6 and 1.7 resp.) have two objects as possible sources (namely, User1 and InternalUser1), and three objects as possible targets (namely, Book1, TechnicalReport1 and Journal1). However, object TechnicalReport1 can never be the target of the two calls, since technical reports are never authorized for loan and consequently cannot be referenced by the attribute document of Loan1. Object Journal1 can be the target of the two calls only when the source is InternalUser1, while it can never be returned by getDocument when the source is User1, since normal users are not allowed to borrow journals. The static analysis conducted to determine the objects possibly referenced by class attributes cannot detect such infeasible situations, implied by the behavior of authorizedLoan. In general, static analyses have only limited capabilities of dealing with the detection of infeasible conditions. On the other side, the results shown in Fig. 5.14 are conservative, in that they account for all possible run time behaviors. No interaction among objects can occur, when printUserInfo is called, that is not represented in the statically recovered diagram.

It would also be possible to recover the sequence diagram for the printUserInfo method of class Library by means of a dynamic analysis. The