REPRESENTACIONES SOCIALES: ¿QUÉ SON, POR QUÉ ESTUDIARLAS, CÓMO SE ESTUDIAN?

In Ovation, execution pattern views are used to visualize and explore a program’s execution at dif- ferent levels of abstraction [26, 27]. An execution pattern is derived from Jacobson’s interaction diagrams [50] and is represented in a tree structure. Ovation offers several means to manipulate the view. For raising the level of abstraction and for dealing with the event explosion problem, the views can be flattened, subtrees can be collapsed, (nested) repetition constructs can be created, etc. Repetition constructs can be built for similar execution patterns. As in our approach, repeti- tion constructs are used for viewing execution patterns in Ovation. The execution patterns do not, however, always occur in succession. In fact, the patterns that are most difficult to find and are often most interesting ones, do not occur in succession. The subscenario constructs of SCED can be used to view those patterns and to structure the set of scenario diagrams generated. Ovation does not include such a concept. Ovation offers the user a possibility to define the similarity of patterns. She can choose one or more criteria from eight categorized ones, to be used by the pat- tern matching algorithms to decide if two pattern are “similar” or not. In our approach, behavioral

patterns can be searched based on exact string-based matches only.

Sefika et al. introduce an architecture-oriented visualization approach that can be used to view the behavior of a target system at different levels of granularity [99]. They introduce a technique called architectural-aware instrumentation, which allows the user to gather information from the target system at the desired level of abstraction. Such levels include subsystem, framework, pat- tern, class, object, and method levels. The information can then be shown using different views. The fine-grained object interaction is shown as Object Interaction Diagrams, class and framework interaction is shown as Affinity Diagrams, and framework and subsystem interaction is shown as

Ternary Diagrams. The Object Interaction Diagram is a variation of an MSC, and the Affinity

Diagram is a directed graph. The instrumentation mechanism used hard-wires the level of abstrac- tion into the source code instrumentation process, which makes the approach somewhat inflexible. The user has to decide the level of abstraction and views to be generated before running the target software. If she wants to view more or less detailed information, she has to run the software again. In other words, there is no information exchange among different views. In our approach, state diagrams can be synthesized from a set of scenario diagrams, thus providing the user a possibility to examine the information extracted using two different views. On the other hand, compared to our approach, the architectural-aware instrumentation mechanism is more efficient in data gather- ing. The approach described by Sefika et al. only supports dynamic reverse engineering. Hence, it might be difficult for the user to relate the run-time entities to the source code artifacts.

Walker et al. use high-level models for visualizing program execution information [120]. The vi- sualization focuses on object information and interaction information (e.g., a current call stack and a summary of calls). In the main view, called a cel, high-level software components are represented as boxes. The interaction among the components is shown by various kinds of directed edges be- tween two boxes. Histograms and annotations can be attached to the boxes and edges. A cel view shows events that occurred within a particular interval of the system’s execution. Summary views can be used to examine all events occurring in the trace. The system is written in Smalltalk and is used to analyze Smalltalk programs. The information is collected by instrumenting the Smalltalk

virtual machine to log the events when they occur. The mapping between low-level software arti- facts and high-level components they belong to (i.e., boxes in a cel view) is done manually using a declarative mapping language. In Shimba, static and dynamic information is shown in separate views and the high-level static components are constructed using Rigi. The user can then build high-level scenario views using a mapping between low-level software artifacts and high-level components [112].

Jinsight is a tool for visualizing the dynamic behavior of Java programs [45]. It views information about object population, method invocations, garbage collection, CPU and memory bottlenecks, thread interactions, and deadlocks. The event traces are produced as a result of instrumenting Java Virtual Machine. Jinsight offers several kinds of views that can be used to analyze the information captured in event traces. The overall object interaction can be examined using Histogram Views, a

Call Stack View shows the call stack for each thread, and references between objects can be viewed

using a Reference Pattern View. Furthermore, Jinsight uses several views for showing event traces over time: an Execution View shows an overview of communication among objects per thread, while an Invocation Browser View and Execution Pattern Views can be used for browsing pieces of event traces. The Invocation Browser View shows method calls and messages to a selected object, as well as all subsequent communication and the Execution Pattern view shows a summary of recurring interaction patterns arising from the selected method [45]. Jinsight uses a tree structured interaction diagram notation that resembles execution pattern views of Ovation [27, 26]. Jinsight is one of the most versatile dynamic reverse engineering tools available. It includes various views for examining different aspects of the run-time behavior. However, state machines, which are commonly used diagrams for specification of the dynamic behavior, are not supported by Jinsight. In addition, Jinsight does not generate information about the dynamic control flow of a selected object or method. These features are included in Shimba. Jinsight does not support static reverse engineering.

A source code instrumentation technique is used in Scene for producing event traces and visu- alizing them as scenario diagrams [59]. Scene allows the user to browse not only scenarios but

also various kinds of associated documents, such as source code, class interfaces, class diagrams, and call matrices. For compressing the large amount of extracted event trace information Scene shows the operation calls (messages) in a closed form as default: the internal events of a call are not shown unless ’opened’ by clicking the call arc. In this way the user can proceed to the inter- esting level, in a top-down fashion. Corresponding “horizontal abstractions” can be made using execution pattern views of Ovation [27, 26]. Scene offers other means to further narrow the set of displayed calls. If the number of participants becomes too large, a new scenario window is automatically opened for a call. Scene does not take advance of behavioral patterns for structuring and decreasing the information shown in scenario diagrams. Such a facility in provided in Shimba. As the event trace compressing method of Scene, the behavioral patterns shorten the event trace (i.e., decreases the number of scenario items). In Shimba, the event trace information can be com- pressed also vertically (i.e., to decrease the number of participants in a scenario diagram) using high-level components constructed in Rigi. As Jinsight [45], Scene does not support static reverse engineering, which would again provide a way to decrease the huge amount of event trace infor- mation. Scene is implemented in and for the Oberon environment.