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

5

Interaction Diagrams

This chapter is focused on the extraction of a representation of the interactions that occur among the objects that compose an Object Oriented system. A static analysis of the source code provides a conservative superset of all possible interactions, while a dynamic analysis can be used to trace the behavior of the program during a given execution.

In Object Oriented programming, the overall functionality of an application emerges from the interactions among the communicating objects it instantiates. There is no single place where the instructions for a given system’s functionality are concentrated. On the contrary, each object gives a small contribution to a larger picture, possibly delegating part of the computation to other objects. Thus, understanding the behavior emerging from the message exchange implemented in an Object Oriented system can be a difficult task. Interaction diagrams help programmers in such a task by offering a visual language for the display of the control transfers among objects.

Interaction diagrams can be obtained from the source code by augmenting the object diagram with information about method invocations. The sequence of method dispatches is considered and their ordering is represented in the two forms of the interaction diagrams: either in collaboration diagrams, which emphasize the message flows over the structural organization of the objects, or in sequence diagrams, which emphasize the temporal ordering. Recovery of these diagrams from the source code can be achieved by defining a proper analysis on the OFG and exploiting its outcome to statically resolve the method invocations. Dynamic recovery of the interaction diagrams can be obtained by running an instrumented version of the program and collecting the dynamic interactions among the objects from the execution trace.

For statically determined diagrams, a numbering algorithm, aimed at ordering events temporally, is also described in this chapter. It is used to attach time stamps to method calls, thus making the diagrams more informative. In order for the approach to scale to large systems, it is complemented by an extension of the interaction diagram recovery algorithm to handle incomplete systems, and by a focusing technique that can be used to locate and visualize

90 5 Interaction Diagrams

only the interactions of interest. Correspondingly, focused numbering of the temporal events is also considered.

The chapter is organized as follows: Section 5.1 gives an overview on the interaction diagrams. Section 5.2 presents the specialization of the general flow propagation algorithm that is used for the reverse engineering of the interaction diagrams and some related problems, the first of which deals with the recovery of useful interaction diagrams in the presence of incomplete systems. Moreover, the usability problems of the resulting diagrams are also discussed. To make diagrams fit the cognitive abilities of humans, proper visualization techniques must be adopted. In particular, the possibility to focus on a computation of interest is described in detail, together with a related numbering algorithm, for the temporal ordering of the involved events. Interaction diagrams can be recovered at run time, for specific program’s executions, as described in Section 5.3. Examples of interaction diagrams obtained for the eLib system are provided in Section 5.4, while a discussion of the related works ends the chapter.

5.1 Interaction Diagrams

Interaction diagrams are used to model the dynamic aspects of an Object Oriented system [7]. While class diagrams are used to represent the static structure of the system, in terms of its classes and of the relationships among classes, interaction diagrams are focused on class instances (objects), working together to carry out some task. Their behavior (instead of their static structure) is represented as a sequence of messages that are exchanged among objects. The evolution over time of the method dispatches characterizes the overall behavior.

As in the object diagram, the elements represented in the interaction diagrams are the objects created by a program. The main difference between object diagram and interaction diagrams is that the former represents the structure of the object system, in terms of inter-object relationships, while the latter deals with the behavior of communicating objects, expressed in terms of the method invocations issued among the objects in the system.

The interactions among objects can be modeled in two ways: by emphasizing the time ordering of the messages (sequence diagrams), or by emphasizing the sequencing of the messages in the context of the structural organization of the objects (collaboration diagrams). In the first case, a vertical time line is displayed and events are positioned on it to indicate their temporal ordering. In the latter case, the Dewey numbering system (incremented integer numbers separated by dots) is used to indicate that a given message triggers the exchange of a set of nother nested messages. Thus, if 1 is the sequence number of the first message, 1.1 and 1.2 are respectively used for the first and second nested messages. Method calls prefixed by Dewey numbers label the inter-object relationships shown in a collaboration diagram.