Scenario Based Comparison

Comprehending a program’s implementation is a challenging and a complicated process during software main- tenance. It consumes an integral part of the maintenance activity. The better a system can be understood, the more precise and quick the changes can be made. Every tool has their own strengths and weaknesses and each of them even though is designed for understanding a system’s implementation, has its own way of exposing the underlying details. However, the available tools need to be evaluated through comparisons among themselves. This will let the developers to select the right tools to use for the right purpose. The fact that the tools need to be evaluated is further aggravated due to the absence of any evaluation criteria or representative benchmarks. Since tools deploy different techniques, approaches and parameters, establishing a universal criteria is difficult. Therefore to overcome this difficulty and to compare the trace analysis tools more uniformly we have adapted a predictive, scenario-based approach which are as follows:

S1: A user wants to know the implementation details for a particular feature of a system and the events (thread signal, button clicks, display updates, mouse events and so on) associated with it. For instance, a user wants to know the method calls for a button click event such as the feature ‘save file’.

S2: A user wants to know the implementation details for a particular feature of a system using interactions between objects and classes. For instance, a user wants to know the number of instances of objects created and exited for the invoked classes.

S3: A user wants to know the implementation details for a particular use of a system using execution patterns containing class and method calls. For instance, a user wants to know the call graph of the series of methods invoked for a particular use such as drawing a rectangle.

S4: A user wants to know more details about the runtime behaviour of a system using metrics. For instance, a user wants to know the CPU time consumed or number of times a method, or groups of methods invoked for a particular use such as drawing a circle.

S5: A user wants to know more details about the runtime behaviour of a system using metrics, view snapshots of the user interface and at the same time see the original source code of the feature. S6: A user wants to know more fine grained details of the features by categorization into groups of appli-

cation programming interface, internal methods or clone methods. For instance, a user wants to know details of an active clone class such that in what contexts the active fragments are used, times invoked, CPU time consumed and so on. Similarly, a user can also analyse the context of use and dynamic behaviour of groups of API such as ‘String’, ‘io’, ‘Util’ and so on.

Moreover, to qualify each scenario, the tools that are able to fulfil, we have set three types of qualifiers. Each qualifier describes the degree to which the tools are capable to meet the scenario requirement. The qualifiers are classified as ‘can analyse’, ‘partially analyse’ and ‘cannot analyse’. The qualifier ‘can analyse’

Table 4.3: Summary of Strength of Tools Based on Scenarios • can analyse  partially analyse ◦ cannot analyse

Tools Scenario 1 Scenario 2 Scenario 3 Scenario 4 Scenario 5 Scenario 6 Shimba • •  ◦ ◦ ◦ ISVis ◦ • • ◦ ◦  Ovation  • •  ◦ ◦ Jinsight • • •   ◦ Program Explorer ◦ • • ◦ ◦  AVID ◦ • •  ◦ ◦ Scene • •     Collaboration Browser • •  ◦ ◦ ◦ SEAT ◦ ◦ •  • ◦ TrAM •  • • • • Extravis • • •    Salah et al.  •   ◦ ◦

signifies that the tool satisfies all the conditions of a scenario and provides a complete details of the system according to the user requirement. ‘Partially analyse’ means that a tool satisfies a few of the scenario conditions but in a different way without fulfilling all of the conditions. This means that few things such as parameter, values, or other information relevant to the scenarios are missing. However,‘cannot analyse’ means that the tools infrastructure does not allow the users to look for what they want in order to understand a system.

Table 4.3 depicts the specialities of the tools on the scenario basis as described by the qualifiers. For scenario 1 all the tools support the analysis with the exception of Program Explorer and SEAT. Ovation and the approach proposed by Salah et al. can partially allow the users to analyse a system’s feature implementation by classifying the traces into segments by event types. We can observe that most of the tools available so far are designed for the scenario 2 as well. Scenario 2 is a situation where users want to know a system’s details using interactions at the class or method levels. An interaction means communication between two components such as class or method. All the tools except TrAM and SEAT qualifies for this purpose. The interactions among the components are represented using diagrams with horizontal lines, vertical lines and other notations using boxes and arrows. However, TrAM produces a call graph of method calls from which the interaction among the classes such that the caller-callee dependencies can be derived. Knowing the method calls and the pattern of their execution also provide added information towards program

comprehension. How and when the methods are called and what patterns do they follow lets the users get more insight about the flow of program execution. Interestingly, from the literature survey we also came across that all the tools have the ability to solve the users’ purpose for the scenario 3 except Shimba, Scene, Collaboration Browser and Salah et al. where they do provide inter-class information but fail to assist in showing the execution patterns.

Metrics are one of the important means in making the comprehension process more informative by quan- tifying the dynamic behavioural aspects of a system. This is represented as scenario 4 and the majority of the tools implements the basic dynamic metrics such as total number of calls and CPU time unlike TrAM. TrAM implements six kinds of metrics categories such as system metrics, clone metrics, group metrics, active clone metrics, method metrics and trace metrics. Scenario 5 further complements the comprehension process by letting the users to locate the features more precisely and explicitly. Besides providing information through metrics a live view at the snapshots of the user interfaces and the corresponding original source code at the same time will assist in pin pointing the nature and the portion of the code of a feature in the system accu- rately. SEAT and TrAM are fully capable of fulfilling this with Jinght, Scene and Extravis are partially able to handle the situation such that none of them displays the snapshots of the user interface. Finally, scenario 6 portrays a situation when a user might want to further focus on their analysis on particular methods, API or similar fragments such as clones. Only TrAM qualifies for this scenario and it provides an extended feature of letting the users to manipulate the API, internal methods and clones to gain insights about their implementation details and associated dynamic behaviour. Few tools such as ISVis, Program Explorer, Scene and Extravis do provide focused view through categorization partially.

In summary, we can conclude that the majority of the trace analysis tools are designed for analysis of a system with emphasis on the interactions of the modules such as class and methods and the execution patterns of the method calls. Some of them also highlight the use case scenarios and give insights to the context of use of a system. If we walk from scenario 1 to scenario 6 the tools gradually fail to reveal the dynamic behaviour of a system in terms of metrics and also fall behind in specifying the snapshots of the user interface of the system being analysed with the underlying source code. They also lack the features of enhanced information browsing for methods, API and clones through filtering and categorization. On the other hand, TrAM implements the necessary features that fulfils all the scenarios with an exception of scenario 2 where it does not offer complete analysis of the interactions between the modules.