the last dependency from that j-vertex (to the j-vertex matching the star.onclick expression) are stored as a feature manifestation point. A similar process is repeated when evaluating the assignment expression in line 20. The next interesting expression evaluation occurs in line 23, where an HttpRequest is sent. According to Algorithm 7, lines 9–10, the currently evaluated node, along with its last dependency will be stored as a potential feature manifestation point.
The algorithm continues with adding the information to the exeLog (line 13, Algorithm 7). For the reasons that will be described in the following section, we log all evaluated expressions that can potentially cause exceptions.
6.4
Problems with slice unions
Our ultimate goal is to use the feature identification method to reuse feature code into another application. This requires that we are able to obtain a subset of the source code that, for a given scenario, behaves in the same way as the whole application. Since a feature manifests through a sequence of feature manifestation points, we have to identify the subset of the application’s code that influences each feature manifes- tation point. A straightforward approach for identifying the code of the entire feature would then be to just perform a union of all code expres- sions that influence at least one feature manifestation point. However, this approach is unsound.
Consider the example in Listing 6.4, where the goal is to extract the code of a feature that manifests on the parts of the web page structure with identifiers container1 and container2.
1 ab : var c1 = d o c u m e n t . g e t E l e m e n t B y I d (" c1 ") ; 2 3 abc : f u n c t i o n Cont ( a f I m p l e m e n t ) { 4 c : if( a f I m p l e m e n t ) 5 c : var a f t e r I m p l e m e n t = a f I m p l e m e n t ; 6 else 7 a f t e r I m p l e m e n t = f u n c t i o n() {}; 8
9 abc : this . init = f u n c t i o n() {
10 ab : c1 . t e x t C o n t e n t += " 1 "; /* feature m a n i f e s t a t i o n */
11 c : a f t e r I m p l e m e n t () ; 12 };
13 } 14
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
6.4 Problems with slice unions 75
the last dependency from that j-vertex (to the j-vertex matching the star.onclick expression) are stored as a feature manifestation point. A similar process is repeated when evaluating the assignment expression in line 20. The next interesting expression evaluation occurs in line 23, where an HttpRequest is sent. According to Algorithm 7, lines 9–10, the currently evaluated node, along with its last dependency will be stored as a potential feature manifestation point.
The algorithm continues with adding the information to the exeLog (line 13, Algorithm 7). For the reasons that will be described in the following section, we log all evaluated expressions that can potentially cause exceptions.
6.4
Problems with slice unions
Our ultimate goal is to use the feature identification method to reuse feature code into another application. This requires that we are able to obtain a subset of the source code that, for a given scenario, behaves in the same way as the whole application. Since a feature manifests through a sequence of feature manifestation points, we have to identify the subset of the application’s code that influences each feature manifes- tation point. A straightforward approach for identifying the code of the entire feature would then be to just perform a union of all code expres- sions that influence at least one feature manifestation point. However, this approach is unsound.
Consider the example in Listing 6.4, where the goal is to extract the code of a feature that manifests on the parts of the web page structure with identifiers container1 and container2.
1 ab : var c1 = d o c u m e n t . g e t E l e m e n t B y I d (" c1 ") ; 2 3 abc : f u n c t i o n Cont ( a f I m p l e m e n t ) { 4 c : if( a f I m p l e m e n t ) 5 c : var a f t e r I m p l e m e n t = a f I m p l e m e n t ; 6 else 7 a f t e r I m p l e m e n t = f u n c t i o n() {}; 8
9 abc : this . init = f u n c t i o n() {
10 ab : c1 . t e x t C o n t e n t += " 1 "; /* feature m a n i f e s t a t i o n */
11 c : a f t e r I m p l e m e n t () ; 12 };
13 } 14
76 Chapter 6. Identifying Code of Individual Features
15 a : var o1 = new Cont () ; 16 a : o1 . init () ;
17
18 c : var c2 = d o c u m e n t . g e t E l e m e n t B y I d (" c2 ") ; 19 bc : var o2 = new Cont (f u n c t i o n() {
20 c : c2 . t e x t C o n t e n t +=" 2 " /* feature m a n i f e s t a t i o n */
21 }) ;
22 bc : o2 . init () ;
Listing 6.4: Example illustrating the problem of merging results for three feature manifestation points. Markings a, b, and c denote the feature manifestation point that has caused the line inclusion.
The example in Listing 6.4 has 3 feature manifestation points: a) line 10 invoked by the call expression in line 16, b) line 10 invoked by the call expression in line 22, and c) line 20. From the perspective of the feature manifestation point a the necessary JavaScript code lines are: 1, 3, 9, 10, 15, 16; from the perspective of feature manifestation point b: 1, 3, 9, 10, 19, 22; and from the perspective of the feature manifestation point c: 3, 4, 5, 9, 11, 18, 19, 20, 22. For each feature manifestation point this is the minimum amount of code necessary to replicate it. If we perform a simple union of the identified code lines, we end up with the whole JavaScript source code except for lines 6 and 7. However, this is not correct: the execution of the init function (lines 9–12) caused by the call expression in line 16 (o1.init()) now contains an error that will stop application execution – the afterImplement identifier evaluates to null instead of a function, due to not including line 7 (line 11 is included in the whole code because of feature manifestation c, and is unnecessary from the perspective of feature manifestation points a and b).
In general, consider two feature manifestation points a1and a2, where
it was identified that the necessary control-flow for a1 is a sequence of
expressions . . . , ea, ec, . . . , and the control flow of a2 is a sequence of
expressions . . . , ea, eb, ec, . . . . When we construct a slice union, the
control-flow for a1 now becomes . . . , ea, eb, ec, . . . . Since eb was not
included on behalf of a1, none of its dependencies at this point of execu-
tion were traversed and there is no guarantee that eb will not cause any
problems (e.g. throw a null exception because its initialization was not included). For this reason, since our end goal is to enable automatic fea-
ture reuse, we will follow the dependencies of ebleading to the execution
of a1, at the expense of including additional code, because having exe-
cutable feature code is more important than having the minimal amount of code. To do this, in Algorithm 7, line 13, we have to collect the trace