112 5 Interaction Diagrams

related test cases would include a sequence of operations that change the state of the library, by adding users and documents, as well as Loan objects associated to users borrowing documents. The method printUserInfo should be invoked with the library in different states. The resulting sequence diagrams would resemble that obtained statically and represented in Fig. 5.14, with a few important differences. Only instances of classes Book and Journal would be present in the diagram, since there is no way to make a TechnicalReport object participate in a loan. Moreover, when the source of the calls number 1.6 and 1.7 is of type User, the target is always of type Book, in that there is no way to make a Journal object participate in a loan, when the associated user is not an InternalUser.

The example above highlights the different and complementary nature of statically and dynamically recovered interaction diagrams. The former represent all possible interactions in a single diagram, but may include interactions that can never occur due to infeasible conditions that cannot be detected statically. The latter show only interactions that are ensured to be possible, since they are obtained by an actual program execution. However, their results are scattered in a set of diagrams (one for each test case), none of which usually represents all possible interactions in a conservative way.

5.5 Related Work

Information about class instances collected at run-time is dealt with by several research prototypes [42, 62, 67, 97], In these research projects, creation of objects and inter-object message exchange are captured by tracing the execution of the program in a given set of scenarios. In [67] static information limited to method invocations (call graph) can be combined with execution traces, thanks to a common representation of both data in a single database of logic facts, from which views are created through queries. In [41] the call graph is animated by highlighting the currently executing methods. Construction of call graphs for Object Oriented programs and their accuracy are considered in [28, 83].

Sequence diagrams are constructed by means of a dynamic analysis in [29]. The proposed approach exploits Aspect Oriented Programming [40] to intercept the execution of method calls in a non invasive way. The original source code is weaved with an external aspect that defines which run time events to capture and which data to record. The original code does not need be instrumented at all. Aspects are used to instrument Java code also in [8], where a mapping is defined between a metamodel of the execution traces and a metamodel of the scenario diagrams, adapted from the UML sequence diagram metamodel. Such a mapping is given as a set of consistency rules expressed in the Object Constraint Language (OCL) [98]. They account for the message exchanges that occur in non-distributed as well as in distributed systems and they are used to reverse engineer UML sequence diagrams from exccu-

5.5 Related Work

113

tion traces. In distributed systems, the order of execution of the methods is determined without resorting to a global clock, by matching each sequence of remote calls with the corresponding sequence of remote method executions.

In [20], points-to analysis is exploited to statically recover all possible execution traces for a given object, represented in a so-called Object Process Graph. Sequences of relevant instructions, including invocation instructions, are represented in the resulting graphs. Among the devised applications, these graphs can be used for protocol validation.

Experimental results on the application of the method described in this chapter to a large C++ system are presented in [90]. The static technique for the reverse engineering of the interaction diagrams has been applied to about half million lines of C++ code. To generate diagrams of manageable size, both partial analysis (with sub-systems being considered separately) and focusing (on each single method) have been exploited. Combined together, they have been fundamental to produce usable diagrams. The resulting views have been evaluated by the author of the related code, who judged them extremely informative and able to summarize information spread across the code. The lesson we learned is that the interactions among objects are a great help in support of program comprehension, but at the same time they require proper interactive facilities and reduction methods to scale to large software systems.

This page intentionally left blank