The Reverse Engineering process proposed in this section aims at reconstructing a Finite State Machine modelling the behaviour of an existing Rich Internet Application using a combination of dynamic analysis and clustering techniques involving the RIA user interfaces. The process is based on two sequential steps of Extraction and Abstraction, respectively. The Extraction step implements the RIA dynamic analysis for tracing the sequence of event-driven Client Interfaces produced during the RIA execution, as well as some event handling related processing information. The information collected during this step can be used to build a direct graph, the RIA Interface Transitions Graph (TG), whose nodes represent the RIA client interfaces, and edges represent events that cause the
38
generation of new interfaces. Of course, using dynamic analysis techniques for collecting information about the RIA execution behaviour requires that two main problems are addressed. The former is a problem of adequacy of the set of traced executions for representing all the relevant behaviours of the RIA. This problem can be addressed by adopting suitable strategies for assuring that traced executions capture all possible behaviours of a RIA during the execution of its use cases. The latter problem is a problem of explosion of the number of different client interfaces produced during the RIA executions. To solve this problem, the proposed reverse engineering process introduces the Abstraction step, where equivalence criteria are exploited for clustering together equivalent client interfaces and equivalent transitions between interfaces of the TG, and generating a FSM correspondently. Additional details about both Extraction and Abstraction steps will be presented in the next sub-sections.
2.2.1 Extraction step
The Extraction step is actually a tracing activity of user sessions where the RIA is executed in a controlled environment in order to trigger sequences of events (making up the execution of specific use cases of the application) and to register corresponding results available on the client side of the application.
This tracing activity can be modelled by the statechart diagram shown in Figure 2.2 that includes two main iterative states, the Event Waiting and the Event Handling Completion Waiting one.
Figure 2.2: The Tracing Activity of the Extraction Step
Raised Event Event Handiling Completed
Event Waiting entry/DOM Extraction
Event Handling Completion Waiting entry/Transition Tracing exit/End transition Tracing
Start Tracing
End Tracing
39
When the Start Tracing initial state is entered, a new Web page is loaded and rendered by the browser, and the Event Waiting state is reached where the page remains frozen until any event rises.
Entering in the Event Waiting state, the DOM Extraction activity, consisting of extracting and storing information about the structure of the currently rendered DOM, is carried out.
The occurrence of a raised event causes a transition from the Event Waiting state towards the Event Handling Completion Waiting state.
Three main types of events are able to trigger this transition:
user events, corresponding to user actions made on any input device, such as mouse or keyboard;
time events, due to the occurrence of a timed condition;
http response event, due to receptions of responses to some http request, such as a request for a web page, or an asynchronous Ajax (XHR) request.
During the reverse engineering process, in order to avoid loss of data or inconsistent data, the execution of the RIA should be controlled by delaying a new event occurrence until the DOM Extraction activity in each Event Waiting state has been completed. While entering in the Event Handling Completion Waiting state, a Transition Tracing activity is carried out consisting of the extraction and storage of information related to the raised event, such as its type, its timestamp of raising, and the DOM element node which it has been raised on. When the event handling is completed, the time of the event handling termination is stored (End Transition Tracing activity) and the reverse engineering process returns in the Event Waiting state, for continuing the Tracing activity. While in the Event Waiting state, the Tracing activity can be stopped by the reverse engineer in order to exit from the Extraction step of the process.
2.2.2 Abstraction step
At the end of the Extraction step, the reverse engineering process enters the Abstraction one, where data extracted during the tracing activity is analysed in order to obtain the FSM modelling the RIA behaviour.
40
The abstraction of this model is accomplished in two steps: in the first step, a Transition Graph whose nodes represent the generated RIA client interfaces, and edges represent events that caused the generation of new interfaces, is built.
In the second step, this graph is analysed and Clustering techniques are used for grouping together its equivalent nodes and transitions. The resulting graph is submitted to a Concept assignment process, which will finally generate the FSM.
The clustering techniques exploit equivalence criteria of the client interfaces based on the analysis of the corresponding DOM configurations. In particular, we have considered (and experimented with) several heuristic criteria such as the one that considers two client interfaces to be equivalent if their DOMs include the same set (or sub-sets) of ‗active element nodes‘, that is elements with registered events of selected types (such as user event, time event, asynchronous events, etc.) and having the same event handlers.
As a consequence, transitions of the TG between equivalent client interfaces and associated with the same type of event will be considered equivalent and clustered together too.
After the completion of the clustering task, a simplified TG will be obtained. This graph will be submitted to a Concept Assignment task where each node of the TG will be initially assumed as a distinct state of the State Machine, and the software engineer knowledge and experience will be needed for validating or discarding this hypothesis. The transitions between states will be deduced accordingly.
At the end of this task, the FSM modelling the behaviour of the RIA will be finally obtained.