sages returned from the server, and defines the structure related to the second feature.
From the application’s behavior point of view there are three crucial JavaScript expressions in Listing 6.2: lines 20, 23, and 24; lines that directly modify the DOM of the page (lines 20 and 24), or communicate with the server-side (line 23). From the feature point of view: lines 20 and 23 contribute to the behavior of the first feature, and line 24 to the behavior of the second feature. Our approach is, in essence, dealing with the identification of such feature manifestation expressions, determining whether or not they are important from the perspective of the selected feature, and then performing dynamic program slicing with those expressions as slicing criteria.
6.3
Interpretation
The first phase of the identification process is interpretation (Algorithm 7). As input, this phase receives the web application code, the recorded event trace (featureScenario), and the selectors specifying parts of the page structure where the feature manifests (featureDescriptors). The goal of this phase is to create the dependency graph, identify all feature manifestation points, and gather data necessary for the computation of correct slice unions. For this reason, the algorithm declares three global variables: dGraph which stores the dependency graph, fManfs for storing feature manifestations, and exeLog for logging code expressions that can cause problems when performing slice unions. The graph construction algorithm is already described in Chapter 4, Algorithm 1. The feature manifestation point detection and dynamic information gathering is done together with the graph construction process, while JavaScript code ex- pressions are being evaluated (function OnExpressionEvaluation).
When detecting feature manifestation points, the main idea is to iden- tify JavaScript code expressions that modify the target parts of the page structure, or that communicate with the server-side application. For this reason, on each evaluation of a JavaScript code expression, the function OnExpressionEvaluation is called with the j-vertex (jVrtx ) matching the currently evaluated code expression and the evaluation result (evalRes). If the currently evaluated code expression is modifying the DOM of the page (line 4) and the modified DOM HTML nodes are parts of the tar- geted page structure (line 6) then the j-vertex causing the modification
72 Chapter 6. Identifying Code of Individual Features
20 star . c l a s s N a m e = dec ;
21 var req = new X M L H t t p R e q u e s t () ;
22 req . open (" GET ", " d . php ? d = "+ dec , false) ; 23 req . send () ; 24 notif . t e x t C o n t e n t = req . r e s p o n s e T e x t ; 25 }; 26 </ script > 27 </ body > 28 </ html >
Listing 6.2: Example application
This very simple web application has two features (application UI is shown in Figure 6.3): i) it allows the user to mark an image as a favorite and sends that decision to the server, and ii) displays the message re- turned from the server (note that they could as well be considered as a single feature, but in this example, for the sake of presentation, we will consider them as separate). Both features are triggered by a scenario in which the user, by clicking on the star, toggles the image as a favorite. On each click, a request is sent to the server with the information about the state of the star.
Figure 6.3: The UI of the application from Listing 6.2
The UI of the application is composed of two containers: the first (imageRaterContainer, line 10) is used as a container for the image ele- ment and the star element, and defines the structure related to the first feature; and the second (notif, line 14) is used for displaying status mes-
6.3 Interpretation 73
sages returned from the server, and defines the structure related to the second feature.
From the application’s behavior point of view there are three crucial JavaScript expressions in Listing 6.2: lines 20, 23, and 24; lines that directly modify the DOM of the page (lines 20 and 24), or communicate with the server-side (line 23). From the feature point of view: lines 20 and 23 contribute to the behavior of the first feature, and line 24 to the behavior of the second feature. Our approach is, in essence, dealing with the identification of such feature manifestation expressions, determining whether or not they are important from the perspective of the selected feature, and then performing dynamic program slicing with those expressions as slicing criteria.
6.3
Interpretation
The first phase of the identification process is interpretation (Algorithm 7). As input, this phase receives the web application code, the recorded event trace (featureScenario), and the selectors specifying parts of the page structure where the feature manifests (featureDescriptors). The goal of this phase is to create the dependency graph, identify all feature manifestation points, and gather data necessary for the computation of correct slice unions. For this reason, the algorithm declares three global variables: dGraph which stores the dependency graph, fManfs for storing feature manifestations, and exeLog for logging code expressions that can cause problems when performing slice unions. The graph construction algorithm is already described in Chapter 4, Algorithm 1. The feature manifestation point detection and dynamic information gathering is done together with the graph construction process, while JavaScript code ex- pressions are being evaluated (function OnExpressionEvaluation).
When detecting feature manifestation points, the main idea is to iden- tify JavaScript code expressions that modify the target parts of the page structure, or that communicate with the server-side application. For this reason, on each evaluation of a JavaScript code expression, the function OnExpressionEvaluation is called with the j-vertex (jVrtx ) matching the currently evaluated code expression and the evaluation result (evalRes). If the currently evaluated code expression is modifying the DOM of the page (line 4) and the modified DOM HTML nodes are parts of the tar- geted page structure (line 6) then the j-vertex causing the modification
74 Chapter 6. Identifying Code of Individual Features
Algorithm 7 Interpretation(code, featureScenario, featureDescriptors)
1: dGraph ← buildGraph(code, eventTrace) 2: fManfs ← []; exeLog ← []
3: function OnExpressionEvaluation(jVrtx, evalRes)
4: if isModifyingDOM(evalRes) then
5: modifNds ← getModifNodes(evalRes)
6: if match(modifNds, featureDescriptors) then
7: push(fManfs, point(jVrtx, getLastDep(jVrtx ), ’UI’))
8: end if
9: else if isEstablishingServerSideComm(evalRes) then
10: push(fManfs, point(jVrtx, getLastDep(jVrtx ), ’COM’))
11: end if
12: if canThrowException(jVrtx ) then
13: push(exeLog, point(jVrtx, getLastDep(jVrtx )))
14: end if
15: end function
and the last dependency created from the j-vertex are stored as a feature manifestation point. For server-side communication, we consider that it is a part of a feature if it is, in any way, dependent on HTML elements that are parts of the targeted page structure. Since in the interpretation phase the dependencies are not yet followed, each server-side communi- cation is treated as a potential feature manifestation point (lines 9–10, Algorithm 7), but with a flag that marks it as such (’COM’).
15 < script >
16 var star = d o c u m e n t . g e t E l e m e n t B y I d (" star ") 17 ...
18 star . onclick = f u n c t i o n () {
19 var dec = star . c l a s s N a m e == " novFav " ? " fav " : " noFav "; 20 star . c l a s s N a m e = dec ;
21 var req = new X M L H t t p R e q u e s t () ;
22 req . open (" GET ", " d . php ? d = "+ dec , false) ; 23 req . send () ;
24 ...
Listing 6.3: Code Excerpt from Listing 6.2
Example. Consider the evaluation of an assignment expression in line 18, Listing 6.3, which assigns a function to a property of an object. Since the star identifier refers to an HTML node that is part of the targeted structure, the j-vertex matching the assignment expression and