11 < div id =" c o n t a i n e r "> </ div > 12 < script > 13 var c o n t a i n e r = d o c u m e n t . g e t E l e m e n t B y I d (" c o n t a i n e r ") ; 14 c o n t a i n e r . onclick = f u n c t i o n() { 15 c o n t a i n e r . style . b a c k g r o u n d C o l o r = " red "; 16 var h t t p R e q u e s t = new X M L H t t p R e q u e s t () ;
17 h t t p R e q u e s t . open (" GET ", " s e r v e r S i d e . php ", false) ; 18 h t t p R e q u e s t . send () ; 19 c o n t a i n e r . t e x t C o n t e n t += h t t p R e q u e s t . r e s p o n s e T e x t ; 20 }; 21 </ script > 22 </ body > 23 </ html >
Listing 6.1: An example of feature manifestations
As can be seen from the example in Listing 6.1, a feature manifes- tation matches an evaluation of a JavaScript expression executed when demonstrating a scenario, an evaluation that either modifies the struc- ture of the page, or communicates with the server. Feature manifesta- tions capture the essence of a feature in a particular scenario. One of the key insights that we use in this process is: in order to identify the code that implements a feature in a scenario, we have to identify code responsible for each feature manifestation.
6.2
Overview of the Identification process
A feature manifests when a user performs a certain scenario, and feature manifestations can only be determined dynamically. For this reason we base the approach on the dynamic analysis of application execution while feature scenarios are exercised. Scenarios are an integral part of our approach, and in the current process they have to be set up either manually by the user, or automatically generated with a scenario generation technique (Chapter 5).
In order to identify the implementation of a certain feature, we have to track dependencies between different parts of the application. For this reason, we use the Client-side Dependency Graph (Chapter 4), as the main artifact in the process. The overall Feature Identification process is shown in Figure 6.2. From the perspective of the whole reuse process (Chapter 3), the Feature Identification is the first step, and Figure 6.2 details the steps of the Feature Identification activity from Figure 3.2.
68 Chapter 6. Identifying Code of Individual Features
each feature is triggered by a sequence of user actions, i.e. a scenario, and a triggered feature manifests as a sequence of: i) UI modifications to the structure of the page, and/or ii) Server-side communications. These structural changes and server-side communications represent the feature behavior in a particular scenario and we refer to them as Feature Manifestations.
Figure 6.1: Feature manifestations
For example, Listing 6.1 shows a simple application with a feature that manifests when a user clicks on the part of the page structure de- fined with the div element in line 11. The feature manifests with one UI modification (line 15 – changing the background color of the container el- ement), one server-side communication (line 18 – sending a synchronous message to the server), and one UI modification (line 19 – append text content to the container element).
1 < html > 2 < head > 3 < style > 4 # c o n t a i n e r {
5 width : 100 px ; height : 100 px ; 6 background - color : blue ; 7 }
8 </ style > 9 </ head > 10 < body >
6.2 Overview of the Identification process 69
11 < div id =" c o n t a i n e r "> </ div > 12 < script > 13 var c o n t a i n e r = d o c u m e n t . g e t E l e m e n t B y I d (" c o n t a i n e r ") ; 14 c o n t a i n e r . onclick = f u n c t i o n() { 15 c o n t a i n e r . style . b a c k g r o u n d C o l o r = " red "; 16 var h t t p R e q u e s t = new X M L H t t p R e q u e s t () ;
17 h t t p R e q u e s t . open (" GET ", " s e r v e r S i d e . php ", false) ; 18 h t t p R e q u e s t . send () ; 19 c o n t a i n e r . t e x t C o n t e n t += h t t p R e q u e s t . r e s p o n s e T e x t ; 20 }; 21 </ script > 22 </ body > 23 </ html >
Listing 6.1: An example of feature manifestations
As can be seen from the example in Listing 6.1, a feature manifes- tation matches an evaluation of a JavaScript expression executed when demonstrating a scenario, an evaluation that either modifies the struc- ture of the page, or communicates with the server. Feature manifesta- tions capture the essence of a feature in a particular scenario. One of the key insights that we use in this process is: in order to identify the code that implements a feature in a scenario, we have to identify code responsible for each feature manifestation.
6.2
Overview of the Identification process
A feature manifests when a user performs a certain scenario, and feature manifestations can only be determined dynamically. For this reason we base the approach on the dynamic analysis of application execution while feature scenarios are exercised. Scenarios are an integral part of our approach, and in the current process they have to be set up either manually by the user, or automatically generated with a scenario generation technique (Chapter 5).
In order to identify the implementation of a certain feature, we have to track dependencies between different parts of the application. For this reason, we use the Client-side Dependency Graph (Chapter 4), as the main artifact in the process. The overall Feature Identification process is shown in Figure 6.2. From the perspective of the whole reuse process (Chapter 3), the Feature Identification is the first step, and Figure 6.2 details the steps of the Feature Identification activity from Figure 3.2.
70 Chapter 6. Identifying Code of Individual Features
The Feature Identification consists of two phases: Interpretation and Graph Marking.
Figure 6.2: Identifying code and resources of a feature based on a sce- nario
Phase 1 – Interpretation – receives as input the whole web applica- tion code, a feature scenario that causes the manifestation of the desired
feature, and a set of feature descriptors (i.e. CSS selectors1 or XPath
expressions2) that specify HTML elements which define parts of the
page structure where the feature manifests. The goal of this phase is to build the client-side dependency graph, identify all feature manifestation points and gather dynamic information (Execution Summary) necessary for the accurate identification and extraction of feature code. The pro- cess interprets the whole web application with the scenario as a guideline. During the interpretation, as code expressions are evaluated, the depen- dency graph is created (Chapter 4), and when a point in the application
1http://www.w3.org/TR/CSS2/selector.html 2http://www.w3.org/TR/xpath/
6.2 Overview of the Identification process 71
execution is reached (i.e. a code expression is evaluated) that represents a feature manifestation, that point is stored.
Phase 2 – Graph marking – marks all code and resources that directly or indirectly contribute to the demonstrated feature, by traversing the dependency graph for every HTML node in the specified structure and for every feature manifestation. In essence, the graph marking phase performs dynamic program slicing (Section 2.6.2) with the HTML nodes of the specified structure and feature manifestations as slicing criteria. Usually there are multiple such slicing criteria, and in essence, the feature code is actually a union of code slices obtained for each slicing criterion. However, it is a well known fact that unions of dynamic slices do not necessarily reproduce application behavior for each slicing criteria [28]. For this reason, in order to compute correct unions, we gather additional dynamic data in the interpretation phase (Execution Summary).
Once the correct union of slices is computed, we generate code and download resources from the marked nodes. This action, in essence, extracts a subset of the original application still able to reproduce the scenario. In other words, the implementation of a feature, for this par- ticular scenario, is identified and extracted.
6.2.1
Example
In the following sections we will illustrate the identification process with a running example shown in Listing 6.2.
1 < html > 2 < head > 3 < style >
4 . fav { background - image : url (" fS . png ") ;} 5 . noFav { background - image : url (" nS . png ") ;} 6 # star { width : 32 px ; height : 32 px ;} 7 </ style >
8 </ head > 9 < body >
10 < div class =" i m a g e R a t e r C o n t a i n e r "> 11 < img alt =" Image " src =" atom . png "/ > < br / > 12 < div id =" star " class =" noFav "> </ div > 13 </ div >
14 < div id =" notif "> </ div > 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 var notif = d o c u m e n t . g e t E l e m e n t B y I d (" notif ") 18 star . onclick = f u n c t i o n () {
70 Chapter 6. Identifying Code of Individual Features
The Feature Identification consists of two phases: Interpretation and Graph Marking.
Figure 6.2: Identifying code and resources of a feature based on a sce- nario
Phase 1 – Interpretation – receives as input the whole web applica- tion code, a feature scenario that causes the manifestation of the desired
feature, and a set of feature descriptors (i.e. CSS selectors1 or XPath
expressions2) that specify HTML elements which define parts of the
page structure where the feature manifests. The goal of this phase is to build the client-side dependency graph, identify all feature manifestation points and gather dynamic information (Execution Summary) necessary for the accurate identification and extraction of feature code. The pro- cess interprets the whole web application with the scenario as a guideline. During the interpretation, as code expressions are evaluated, the depen- dency graph is created (Chapter 4), and when a point in the application
1http://www.w3.org/TR/CSS2/selector.html 2http://www.w3.org/TR/xpath/
6.2 Overview of the Identification process 71
execution is reached (i.e. a code expression is evaluated) that represents a feature manifestation, that point is stored.
Phase 2 – Graph marking – marks all code and resources that directly or indirectly contribute to the demonstrated feature, by traversing the dependency graph for every HTML node in the specified structure and for every feature manifestation. In essence, the graph marking phase performs dynamic program slicing (Section 2.6.2) with the HTML nodes of the specified structure and feature manifestations as slicing criteria. Usually there are multiple such slicing criteria, and in essence, the feature code is actually a union of code slices obtained for each slicing criterion. However, it is a well known fact that unions of dynamic slices do not necessarily reproduce application behavior for each slicing criteria [28]. For this reason, in order to compute correct unions, we gather additional dynamic data in the interpretation phase (Execution Summary).
Once the correct union of slices is computed, we generate code and download resources from the marked nodes. This action, in essence, extracts a subset of the original application still able to reproduce the scenario. In other words, the implementation of a feature, for this par- ticular scenario, is identified and extracted.
6.2.1
Example
In the following sections we will illustrate the identification process with a running example shown in Listing 6.2.
1 < html > 2 < head > 3 < style >
4 . fav { background - image : url (" fS . png ") ;} 5 . noFav { background - image : url (" nS . png ") ;} 6 # star { width : 32 px ; height : 32 px ;} 7 </ style >
8 </ head > 9 < body >
10 < div class =" i m a g e R a t e r C o n t a i n e r "> 11 < img alt =" Image " src =" atom . png "/ > < br / > 12 < div id =" star " class =" noFav "> </ div > 13 </ div >
14 < div id =" notif "> </ div > 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 var notif = d o c u m e n t . g e t E l e m e n t B y I d (" notif ") 18 star . onclick = f u n c t i o n () {
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-