Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Springer Science - 2005 - Reverse Engineering of Object Orie.pdf
Скачиваний:
17
Добавлен:
15.08.2013
Размер:
6.11 Mб
Скачать

102 5 Interaction Diagrams

Fig. 5.9. Collaboration diagram focused on method returnDocument of class

Library.

5.3 Dynamic Analysis

A second approach to the construction of the interaction diagrams for a given application relies on dynamic analysis, i.e., on the analysis of the run-time behavior. Interaction diagrams can be produced out of the execution traces obtained by executing the application on a set of test cases. The basic information that must be available from the execution traces to support the construction of the interaction diagrams consists of an identifier of the current object and of the object on which each method call is issued. More specifically, in order to instrument a program for interaction diagram construction, the following additions are required:

Classes are augmented with an object identifier, computed within the execution of the class constructors.

Upon method call, the identifier of the current and of the target object are added to the execution trace. Moreover, the name of the current method is also traced.

Time stamps associated with method calls are produced and traced.

At this point, a straightforward postprocessing of the execution trace provides an interaction diagram for each test case executed. Each time a method call is found in the trace, a call relationship is drawn in the interaction diagram between the objects uniquely identified in the trace. Knowledge of the current method issuing the call is used to determine the current activation in the sequence diagram (see below). The ordering of the call events is induced by the time stamps.

5.3 Dynamic Analysis

103

Differently from the static analysis, the dynamic analysis produces a set of interaction diagrams, one for each test case. Even if each diagram usually represents a different interaction pattern, it is not ensured that all possible interactions are considered. This depends on the quality of the test cases. On the contrary, all possible behaviors are represented in the statically recovered diagrams.

eLib example

Let us consider two test cases for the eLib program1:

TC1 A book previously borrowed by a normal (not an internal) user of the library is returned, and the loan is closed.

TC2 An attempt is made to return a book which is already available for loan.

Both test cases result in the execution of the method returnDocument (line 66) from class Library, with a different parameter (resp., a borrowed and an available book).

The related execution traces are shown in Table 5.3. Fig. 5.10 displays the sequence diagrams that are obtained from the execution traces. Method activations are shown on the vertical time lines as blank vertical boxes. Such information can be easily derived from the execution traces, since the name of the current method is also traced when a call is issued. Thus, at time 5 (TC1) a new method activation is started on the time line of the object Library1 because of the call to removeLoan, which has a target object equal

1 Ad hoc drivers must be defined for them. In particular, the driver class Main in Appendix B is not compatible with TC2.

104 5 Interaction Diagrams

Fig. 5.10. Sequence diagrams for method Library.returnDocument obtained by dynamic analysis, with test cases TC1 (top) and TC2 (bottom).

to the current object. Since successive calls are made with Library1 as the current object and removeLoan as the current method, they depart from the nested activation in the time line of Library1. Similarly, a nested activation is created for the execution of isAvailable inside isOut at time 2 on object

Book1.

The same method invocations are represented in the dynamic sequence diagram in Fig. 5.10 (top) and in the static collaboration diagram in Fig. 5.9. However, the partial nature of the dynamic analysis is apparent from the comparison of the sequence diagram at the bottom of Fig. 5.10 and the static collaboration diagram in Fig. 5.9. In fact, only two of all possible interactions

5.3 Dynamic Analysis

105

are exercised in test case TC2, while all of them are conservatively shown in Fig. 5.9.

Another aspect of the partial information provided by the dynamic diagrams is the type of the objects issuing or receiving a call. In Fig. 5.10 it seems that the class of the object receiving the calls issued at times 1, 2, 3, 9 is Book and the class of the object receiving the call issued at time 8 is User. On the contrary, inspection of the statically recovered collaboration diagram in Fig. 5.9, which accounts for all statically possible objects involved in each call, reveals that other object types can be the targets of these calls (resp. TechnicalReport and Journal for the calls issued at 1, 2, 3, 9, and InternalUser for the call issued at 8). Additional test cases would be necessary to cover also these possibilities, while a static analysis conservatively reports all of them.

Where dynamic interaction diagrams are more precise than static diagrams is in object identification. In Fig. 5.10, the target of the calls isOut, getBorrower, removeLoan is a same object,Book1,of class Book. This means that exactly the same object receives these three calls. On the contrary, identity of the target of these three calls, numbered 1, 2 and 3.4 in Fig. 5.9, is not precisely defined in the case of a statically recovered diagram. The allocation point for the three alternative target objects is known exactly (line 406 for Book1, line 414 for TechnicalReport1, line 422 for Journal1). However, such allocation points may be executed repeatedly (actually, they are, since they belong to methods indirectly called inside the loop at line 521 in the main). Since it is not possible to distinguish two instances made during different loop iterations by means of a static analysis, the source and target objects in static diagrams such as that in Fig. 5.9 account for all objects allocated by the same allocation statement. On the contrary, a dynamic analysis allows distinguishing among them, and in a dynamic diagram two call relationships have the same source or the same target object if and only if exactly the same object issues or receives the calls. In the presence of dynamic binding, the knowledge of the exact object identity obtained through the dynamic analysis allows for a smaller, though possibly incomplete, set of potentially invoked polymorphic variants of the same method.

5.3.1 Discussion

As with the object diagram, static and dynamic extraction of the interaction diagrams provide different and complementary information. In static interaction diagrams, all possible method calls among all possible objects created in the program are represented. Actually, some of them may never occur in any program execution, due to the presence of infeasible paths that cannot