Computing Dynamic Slices of Feature-Oriented Programs with Aspect-Oriented Extensions

,


Introduction
Weiser [33] first introduced the concept of a program slice. Program slicing decomposes a program into different parts related to a particular computation. A slicing criterion is used to construct a program slice. A slicing criterion is a tuple, < s, v >, consisting of a statement s, in a program and a variable v, used or defined at that statement s. Program slicing technique is employed in many areas of software engineering including debugging, program understanding, testing, reverse engineering, etc.
Feature-oriented programming (FOP) is concerned with the separate definition of individual features and the composition of required features to build varieties of a particular software product. The functionalities of a software product are identified as features in FOP paradigm. FOP is used to implement software product lines and incremental designs. A family of software systems constitutes a software product line [20]. Motivation: Today, the variability of software products is crucial for successful software development. One mechanism to provide the required variability is through Software Product Lines, which is inspired by product lines used in the industry, like product lines used in the production of a car or a meal at some fast-food restaurant. Feature-Oriented Programming (FOP) approach is used to implement software product lines. Despite the advan-tages, feature-oriented programming (FOP) yields some problems in expressing features such as lack of expressing crosscutting modularity. During software evolution, a software should adapt the unanticipated requirements and circumstances. This leads to modifications and extensions that crosscut many existing implementation units. The problem of crosscutting modularity is solved by using aspect-oriented programming (AOP). Kiczales et al. [8] proposed AOP paradigm to separate and modularize the crosscutting concerns like exception handling, synchronization, logging, security, resource sharing, etc. The modularity of crosscutting concerns in FOP can be improved by integrating AOP paradigm into FOP paradigm. In dynamic slicing techniques, first an intermediate representation of the program is statically created in the form of a dependence graph. Then, the dynamic slice is computed by traversing the graph, starting from the point specified in the slicing criterion, using an algorithm. For the programs in general languages like C/C++, Java etc., a single dependence graph is created. There is no composition of features in these languages. FOP is used to develop a family of software products. In FOP (with AOP extensions), multiple dependence graphs are created depending upon the composition of features and aspects. For example, if there are four features and two aspects in a product line out of which two features and one aspect are mandatory, then there are eight possible combinations of features and aspects. Each possible combination of features and aspects creates a different product. Thus, there are eight software products in the product line. Accordingly, there are eight dependence graphs, one graph for each product. Dynamic slice for each possible combination of features and aspects is computed using the corresponding dependence graph. The dynamic slice consists of statements from the composed program that is generated after composition of features and aspects. These statements are again mapped back to the program used for composition. This mapping is not required in general languages like C/C++, Java etc. Again, feature-oriented programs have some special characteristics such as mixins, mixin layers, refinements etc. which are not present in case of general languages like C/C++, Java etc. These characteristics of feature-oriented programs require inclusion of some new nodes/edges in the dependence graph. Similarly, these characteristics require introduction of some new steps/phases in the slicing algorithm (e.g., the handling mixins, the handling of mixin layers, etc.), which are not required in the case of general languages like C/C++, Java, etc. The existing dynamic slicing algorithms for aspect-oriented programs cannot be directly applied for slicing of feature-oriented programs with aspect-oriented extensions due to the specific features of feature-oriented programs such as the presence of mixin layers, refinements of classes, refinements of constructors etc. These characteristics of feature-oriented programs requires inclusion of some new nodes/edges in the dependence graph. Similarly, these characteristics require the introduction of some new steps/phases in the slicing algorithm. Although FOP is an extension of OOP, the existing dynamic slicing algorithms for C/C++, Java cannot be directly applied for slicing of feature-oriented programs due to the presence of aforementioned specific features. Since, program slicing has many applications including testing, software maintenance etc., there is an increasing demand for slicing of feature-oriented programs. Objective: The main objectives of this work are to develop a suitable intermediate representation of feature-oriented programs with aspect-oriented extension and to propose an efficient slicing algorithm to compute dynamic slices for the above types of programs using the developed intermediate representation. A dependence graph is used to signify the intermediate representation. For a single featureoriented program, more than one dependence graph can be obtained depending on the number of features to be composed and the number of aspects to be captured. We also aim at calculating the slice computation time for different compositions of features and different aspects captured. Organization: The organization of rest of the paper is as follows. Section 2 provides a brief introduction to featureoriented programming (FOP) and program slicing. Section 3 discusses the construction of composite feature-aspect dependence graph (CFADG), which is a dependence based intermediate representation of feature-oriented programs containing aspects. In Section 4, the details of our proposed algorithm named feature-aspect node marking dy-namic slicing (FANMDS) algorithm, is discussed. This section also presents the space and time complexity of FANMDS algorithm. Section 5 furnishes a brief overview of the implementation of FANMDS algorithm along with experimental results. A brief comparison of the proposed work with some other related work is furnished in Section 6. Section 7 concludes the paper along with some possible future work.

Basic concepts
In this Section, we provide some basic concepts of featureoriented programming and outline the features of Jak language, which is a feature-oriented programming language. We also discuss the problems of feature-oriented programming and solutions to these problems through aspectoriented programming extensions.

Feature-oriented programming (FOP)
Prehofer [1] was the pioneer to coin the term featureoriented programming (FOP). The key idea behind FOP is to build the software by composing features. Features are the basic building blocks that are used to satisfy user requirements on a software system. The step-wise refinement where features incrementally refine other features leads to a stack of features that are arranged in layers. One suitable technique to implement the features is through the use of Mixin Layers. A Mixin Layer is a static component that encapsulates fragments of several different classes (Mixins) to compose all fragments consistently. Several languages like Jak [2], 1 , Fuji 2 , FeatureHouse 3 , FeatureRuby [40,41], FeatureC++ [5,3,4] support the concept of features explicitly. FeatureIDE [6] 4 is a tool that supports Feature-Oriented Software Development (FOSD) in many languages. We have taken Jak program as input in our proposed approach as it is supported by Algebraic Hierarchical Equations for Application Design (AHEAD) tool suite, which is a composer. AHEAD tool suite is a group of tools to work with Jak language. Other languages have their own composers, and those composers are not a group of tools. Jak (short for Jakarta) is a language that extends Java by incorporating feature-oriented mechanisms [2]. Jak-specific tools like jampack and mixin are invoked to compose Jak files. A Jak file is translated to its Java counterpart using another tool called jak2java. The different features supported by Jak language are Super() references, an extension of constructors, declaration of local identifiers, etc. The details of Jak language and its features can be found in [2]. A feature-tree depicts various features supported by a product line in a hierarchical manner. The feature-tree for Example 2.1 is given in Figure 1. The various aspects that are captured for Example 2.1 are given in Figure 2. Figure  3 depicts the source code for each feature given in Figure 1 and each aspect given in Figure 2.

Problems in feature-oriented programming (FOP)
Feature-oriented programming (FOP) suffers from many problems in modularization of crosscutting concerns [3,4,5]. The presence of these problems leads to degradation in modularity of program family members and also decrease in maintainability, customizability, and evolvability. Some of the problems of FOP are discussed below.
1. FOP is unable to express dynamic crosscutting concerns that affect the control flow of a program. It can only express static crosscutting concerns that affect the structure of the program. AOP languages can handle dynamic crosscutting concerns in an efficient manner through the use of pointcuts, advices etc.
2. FOP languages support only heterogeneous crosscutting concerns where different join points are provided with different pieces of codes. In contrast, AOP languages support homogeneous crosscutting concerns where different join points are provided with the same piece of code.
3. FOP suffers from excessive method extension problem when a feature crosscuts a large fraction of existing classes because of refinements. A lot of methods are to be overridden for each method on which a crosscut depends. This is because FOP is unable to modularize homogeneous crosscutting concerns. AOP uses wildcards in pointcuts to deal with this problem.

AOP extensions to FOP
AOP can be used to solve the above problems of FOP by integrating AOP language features like wildcards, pointcuts, and advices into FOP languages. The different approaches used for integrating AOP language features into FOP languages are Multi Mixins, Aspectual Mixin Layers, Aspectual Mixins. More details about these approaches can be found in [5,3,4]. The Aspectual Mixin Layers approach is a popular one amongst all the approaches since this approach overcomes all the aforementioned problems. Other approaches overcome some of the problems. We have used the approach of aspectual mixin layers in our work. We have separated the aspects from mixin layers for easy understanding of our approach. Our mixin layers contain only a set of classes. Aspects are designed as different layers.

Program slicing
Program slicing is a technique which is employed to analyze the behavior of a program on the basis of dependencies that exist between various statements. It takes out statements from a program related to a specific computation. The extracted statements constitute a slice. Thus, a slicing criterion is employed to compute a slice. A slicing criterion consists of a statement s (or location in the program) and a variable v (or set of variables), and it is represented as a tuple < s, v >. Program slicing technique can be either static or dynamic based on the input to the program. A program slicing technique is said to be static when it extracts all the statements from a program with respect to a slicing criterion irrespective of the input to the program. On the other hand, a program slicing technique is said to be dynamic when all the statements from a program are extracted with respect to a slicing criterion for a specific input to the program. The difference between static slicing and dynamic slicing can be understood by taking an example. Let us consider the example C program given in Figure 5. The static slice with respect to slicing criterion < 11, y > is depicted as the bold italic statements in Figure 6. It includes statements 1, 2, 3, 4, 6, 7, 9, and 11. The dynamic slice with respect to slicing criterion < {x = 10}, 11, y > is depicted as the bold italic statements in Figure 7. It includes statements 1, 2, 3, 6, 9, and 11. For finding the slices of a program, first an intermediate representation of the program is constructed. Then, the slices are found out by using some algorithm on the intermediate representation.
There are many slicing algorithms found in the literature where N is the set of vertices depicting the statements and E is the set of edges symbolizing the dependence relationships between the statements. The set E captures various dependencies that exist between the statements in various mixin layers and aspects in a feature-oriented program. CFADG is constructed based on the composition of different features and aspects captured. Thus, there will be different types of CFADGs according to the features composed and aspects captured. Figure 8 shows the CFADG for the composition given in Figure 3. The square box with a1_in: n_in=n etc. specifies the actual and formal parameters. For example: a1_in: n_in=n specifies that n is an actual-in parameter. Similarly, a2_in: b_in=b specifies that b is an actual-in parameter, f1_in: x=n_in specifies that x is a formal-in parameter, f2_in: b=b_in specifies that b is a formal-in parameter. These notations are adopted from Horwitz et al. [47]. The construction of CFADG consists of the following steps: -Constructing Procedure Dependence Graph (PDG) for each method in a mixin.
-Constructing System Dependence Graph (SDG) for each mixin layer.
-Constructing Advice Dependence Graph (ADG) for each advice.
-Constructing Introduction Dependence Graph (IDG) for each introduction.
-Constructing Composite Feature Aspect Dependence Graph (CFADG) by combining all the SDGs and As-DGs.
Below, we briefly explain the steps for constructing the CFADG and the pseudocode.
(1) Construction of Procedure Dependence Graph (PDG) A procedure dependence graph (PDG) depicts the control and data dependence relationships that exist between the statements in a program with only one function/method/procedure. The nodes in the graph correspond to the program statements and edges correspond to the dependence relationships between the statements. (

2) Construction of Mixin Dependence Graph (MxDG)
A mixin dependence graph (MxDG) is used to capture all dependencies within a mixin. A MxDG has a mixin entry vertex that connects the method entry vertex of each method in the mixin by a mixin membership edge. Each method entry in the MxDG is associated with formal-in and formal-out parameter nodes. The interactions among methods in a mixin occur by calling each other. This effect of method calls is symbolized by a call node in a MxDG. Actualin and actual-out parameter nodes are created at each call node corresponding to formal-in and formal-out parameter nodes. The effect of return statements in a MxDG is represented by joining each return node to its corresponding call node through a return dependence edge. (

3) Construction of System Dependence Graph (SDG) for each Mixin Layer
A single mixin layer may contain more than one mixin. A mixin may derive another mixin through inheritance. The MxDG for the derived class is constructed. The mixin membership edges connect the mixin entry vertex of derived class to the method entry vertices of all those methods that are defined and inherited in the derived class. The SDG for a mixin layer is constructed by joining all the mixin dependence graphs for that mixin layer through parameter edges, call edges and summary edges.

(4) Construction of Advice Dependence Graph (ADG)
An advice dependence graph (ADG) represents an advice in an aspect. The statements or predicates in the advice are represented as vertices and dependencies amongst statements are represented as edges in an ADG. Each ADG is associated with a unique vertex called advice start vertex to signify entry into the advice.

(5) Construction of Introduction Dependence Graph (IDG)
An introduction dependence graph (IDG) represents an introduction in an aspect. If an introduction is a method or constructor, then its IDG is similar to PDG of a method. A unique vertex, called introduction start vertex, is used in IDG to signify the entry into the introduction.

(6) Construction of Pointcut Dependence Graph (PtDG)
Pointcuts in an aspect contain no body. Therefore, to represent pointcuts, only a pointcut start vertex is created to denote the entry into the pointcut.

(7) Construction of Aspect Dependence Graph (AsDG)
An aspect dependence graph (AsDG) is used to represent a single aspect. It consists of a collection of ADGs, IDGs, PtDGs that are connected by some special kinds of edges. Each AsDG is associated with a unique vertex called aspect start vertex, to represent entry into the aspect. An aspect membership edge is used to represent the membership relationships between an aspect and its members. This edge connects the aspect start vertex to each start vertex of an ADG, IDG or PtDG. Each pointcut start vertex is connected to its corresponding advice start vertex by call edges.
The CFADG is constructed by combining the SDGs for all mixin layers present in the composition and the AsDGs through special kinds of edges. The SDGs for all mixin layers in a composition are connected using refinement edges, mixin call edges, mixin data dependence edges, and mixin return dependence edges. The AsDGs are connected to all the SDGs through weaving edges and aspect data dependence edges. The mixin membership edges and aspect membership edges along with mixin start vertices and aspect start vertices are removed during construction of CFADG.
The CFADG for the program given in Figure 3 is shown in Figure 8. A CFADG contains the following types of edges: (a) Control dependence edge: A control dependence edge in a CFADG from a node n 1 to a node n 2 indicates that either node n 2 is under the scope of node n 1 or node n 1 controls the execution of node n 2 where node n 1 is a predicate node.
In Figure 8, edge (m20, s21) is a control dependence edge. (b) Data dependence edge: A data dependence edge in a CFADG from a node n 1 to a node n 2 indicates that node n 2 uses a variable that is assigned a value at node n 1 or n 1 creates an object o and o is used at n 2 .
In Figure 8, edges (s21, s22), (s39, s41), (p72, a73) are data dependence edges. (c) Mixin data dependence edge: A mixin data dependence edge in a CFADG from a node n 1 to a node n 2 indicates that node n 2 in a mixin layer defines a variable which is used at node n 1 in another mixin layer. In Figure 8, edges (s5, s16) and (s39, s54) are mixin data dependence edges. (d) Aspect data dependence edge: An aspect data dependence edge in a CFADG from a node n 1 to a node n 2 indicates that node n 2 in an aspect uses the value of a variable and that variable is defined at node n 1 in a mixin. In Figure 8, edge (s5, a1_in) is an aspect data dependence edge. (e) Call edge: A call edge in CFADG from a node n 1 to a node n 2 indicates that node n 1 calls a method defined at node n 2 . Both the nodes n 1 and n 2 are in same mixin layer. In Figure 8, edge (s41, m2) is a call edge. (f) Mixin call edge: A mixin call edge in CFADG from a node n 1 to a node n 2 indicates that node n 1 in a mixin layer calls a method that is defined in a different mixin layer at node n 2 . In Figure 8, edge (s28, m7) is a mixin call edge. (g) Return dependence edge: A return dependence edge in a CFADG from node n 1 to node n 2 indicates that node n 1 in a mixin layer returns a value to node n 2 in the same mixin layer and node n 2 calls a method where node n 1 is present. In Figure 8, edge (s18, s46) is a return dependence edge.
(h) Mixin return dependence edge: A mixin return dependence edge in a CFADG from node n 1 to node n 2 indicates that node n 1 in one mixin layer returns a value to node n 2 in another mixin layer and node n 2 calls a method where node n 1 is present. In Figure 8, edge (s11, s21) is a mixin return dependence edge.
(i) Parameter-in edge: Parameter-in edge in CFADG is added from actual-in parameters to corresponding formal-in parameters to indicate the receipt of values from the calling method to the called method.
(j) Parameter-out edge: Parameter-out edge is added from formal-out parameters to corresponding actual-out parameters to indicate the return of values from the called method to the calling method. If an actual parameter is modified inside a method, then the modified value becomes an actual-out parameter and the original value becomes an actual-in parameter. The parameter used to hold the value of actual-in parameter in method definition becomes a formalin parameter and the parameter used to hold the modified value becomes a formal-out parameter. In Figure 8, there are no parameter-out edges, since, in our example, no parameter is modified inside a method.
(k) Summary edge: The summary edge is used to represent the transitive flow of dependence between an actual-in parameter node and an actualout parameter node if the value of the actual-in parameter node affects the value of the corresponding actual-out vertex. In Figure 8, edges (s14 → a1_in, s14), (s21 → a1_in, s21), and (s28 → a1_in, s28) are summary edges.
(l) Message dependence edge: A message dependence edge from a node n 1 to another node n 2 in a dependency graph signifies that node n 1 represents a statement outputting some message without using any variable and node n 2 represents an input statement, a computation statement, a method call statement, or a predicate statement. In Figure 8, there exists a message dependence edge (s3, s4). Similarly, edges (s45, s46), (s53, s54), and (s61, s62) are message dependence edges.
(m) Refinement edge: A refinement edge in a CFADG from a node n 1 to a node n 2 indicates that node n 1 in child mixin layer calls a method k() by prefacing Super() call and k() is defined at node n 2 in parent mixin layer. In Figure 8, the edge (s44, m40) is a refinement edge. Similarly, edges (s68, m59), (s60, m51), and (s52, m43) are refinement edges.
(n) Weaving edge: A weaving edge from a node n 1 to node n 2 indicates that node n 1 is a method call node and node n 2 is a before advice node capturing the method called at n 1 and node n 2 executes before the method called by n 1 executes. OR node n 1 is the last statement in before advice and node n 2 is the method entry node of the method captured by the advice and node n 2 executes after node n 1 executes. OR node n 2 is an after advice node and node n 1 is the last statement in the method captured by node n 2 and node n 2 executes after node n 1 executes. OR node n 1 is the last statement in an after advice and node n 2 is the statement followed by method call node and the method is captured by the advice and node n 1 executes before node n 2 executes.
The brief pseudocode for constructing the CFADG for a feature-oriented program is given below, and the complete algorithm is given in Algorithm  (e) Construct AsDG by connecting advice start vertices, introduction start vertices, pointcut start vertices to aspect start vertex through aspect membership edges.
(4) Connect all SDGs through refinement edges, mixin call edges, mixin data dependence edges, and mixin return dependence edges.
(5) Connect all AsDGs to all SDGs through weaving and aspect data dependence edges.

Feature-aspect node-marking dynamic slicing (FANMDS) algorithm
In this section, we present our proposed algorithm for computing dynamic slices of feature-oriented programs using CFADG. We have named our algorithm Feature-Aspect Node-Marking Dynamic Slicing (FANMDS) algorithm as it is based on marking and unmarking the nodes of CFADG. Before presenting our FANMDS algorithm, we first introduce some definitions which will be used in our algorithm.

Definitions
Definition 1: Defn(v): Let v be a variable or an object in program P . A node u in the CFADG is said to be Def n(v) node if u corresponds to a definition statement that defines a value to variable v or u represents a statement that creates object v.
In the CFADG given in Figure 8, nodes s23, and s24 represent Defn(answer) nodes in the method logten() in mixin calc in log mixin layer.   Figure 4 In the CFADG of Figure 8, RecDef n(i) is at statement s32 before while loop and it is at statement s35 during execution of while loop.

Definition 4: Usage(v):
Let v be a variable or an object in program P . A node u in the CFADG is said to be U sage(v) node if u represents a statement that uses the variable v or u represents a statement that uses the object v to call a method on that object or to assign the object v with another object.
In the CFADG given in Figure 8, nodes s47, and s49 represent U sage(r) nodes. Similarly, node s77, and s78 are U sage(n) nodes. Definition 5: UsageSet(v): The set of all U se(v) nodes is referred to as U sageSet(v).

Overview of FANMDS algorithm
Before execution of a feature-oriented program F P , the features required for composition and the aspects to be captured are selected. Then, the selected features are composed and selected aspects are weaved. The CFADG is constructed statically only once based on the composition of selected features and weaving of selected aspects. The program is executed for a specified input. The executed nodes in CFADG are marked and unmarked during program execution depending upon the arise and cease of dependences respectively. When a statement executes a Super() node, it is marked by the algorithm. Also the corresponding method entry node, the associated actual and formal parameter nodes are marked. When there is an invocation of a method, the corresponding call node, the corresponding method entry node, the associated actual and formal parameter nodes are also marked. Whenever a pointcut is executed, the corresponding advice nodes are marked. When an advice is executed, the corresponding formal parameter nodes are marked. During execution, the dynamic slice of each executed statement is computed. After execution of each node and computation of dynamic slice at that node, the algorithm unmarks it. Let dyn_slice(u) denote the dynamic slice with respect to the most recent execution of node u. Let (e 1 , u), (e 2 , u), . . . , (e k , u) be all the marked predecessor nodes of u in the CFADG after execution of node u. The dynamic slice with respect to the present execution of node u is computed as dyn_slice(u) = {u, e 1 , e 2 , . . . , e k } ∪ dyn_slice(e 1 ) ∪ dyn_slice(e 2 ) ∪ . . . ∪ dyn_slice(e k ).
Our FANMDS algorithm computes the dynamic slice with respect to the specified slicing criterion by simply looking up the corresponding dyn_slice computed during run-time. Below, we present the pseudocode of our FANMDS algorithm in brief. Algorithm 9 in Appendix B presents our FANMDS algorithm in detail.

Feature-Aspect Node-Marking Dynamic Slicing (FAN-MDS) Algorithm
(1) CFADG Construction: Construct the CFADG for the given feature-oriented program with aspect-oriented extensions, statically only once.
(2) Initialization: Do the followings before each execution of F P .
(a) Unmark all nodes of CFADG.
(c) Set RecDef n(v) = N U LL for every variable v of the program F P .   (h) If u is an introduction node such that u is a method i. Mark node u. ii. Mark the formal-in and formal-out parameter nodes.
(i) If u is an introduction node such that u is a field i. Mark node u.
ii. Mark the node that defines a value to u for the current execution of u. iii. Mark the node that uses the value of u for the current execution of u.

(4) Slice Look Up
(a) For a given slicing command < u, v >, do i. Look up dyn_slice(u) for variable v for the content of the slice. ii. Map the Java statements included in the computed dynamic slice to the corresponding composed Jak statements to get the final dynamic slice iii. Display the resulting slice.
(b) If the program has not terminated, go to Step 3.

Implementation
This section briefly describes the implementation of FAN-MDS algorithm. A dynamic slicing tool has been developed to implement the algorithm which has been named feature-aspect dynamic slicing tool (FADST). Figure 11 depicts the architectural design of the slicing tool FADST. The working of our slicing tool is depicted in Figure 12, through a flow chart.
In Figure 11, the executable components are depicted in rectangular boxes and the passive components are depicted in ellipses. First, the features required to compose and aspects to be captured are selected. The selected features, the selected aspects, and the slicing criterion consisting of input, line number, and variable are provided to FADST through the Graphical User Interface (GUI) component. The Dynamic Slicer component interacts with the GUI component and produces the required result as output back to GUI. The AHEAD composer [2] composes the selected features to generate a set of Java programs. These Java programs and the selected aspects are fed to AspectJ composer. AspectJ composer weaves the aspects at the appropriate join points, and the result is a composed AspectJ program. The lexical analyzer component reads the composed AspectJ program and generates tokens from these programs. Upon encountering a useful token, the lexical analyzer component returns the token along with its type to the parser and semantic analyzer component. The parser and semantic analyzer component takes the token and analyzes it using the grammatical rules designed for the input programs.
The code instrumentor component instruments the composed AspectJ programs. The classes are instrumented with line numbers prefixed with c, the aspects are instrumented with line numbers prefixed with as, the methods are instrumented with line numbers prefixed with m, the pointcuts are instrumented with line numbers prefixed with p, the advices are instrumented with line numbers prefixed with a, and the statements containing assignments, computations, predicates are instrumented with line numbers prefixed with s.
The CFADG constructor component constructs the CFADG using the required program analysis information such as type of statement, sets of variables defined or used at a statement etc. The dynamic slicer component implements the FANMDS algorithm. We have used Java language for our implementation. A compiler writing tool, ANTLR (Another Tool for Language Recognition) 5 , has been used for lexical analyzer, parser and semantic analyzer components of FADST.
An adjacency matrix adj[][] has been used for storing the CFADG with respect to a selected composition of features of the given feature-oriented program.

Case studies and experimental results
We have applied our algorithm to some product lines 6,7 .
We have also taken some open-source Java programs 8 9 10 .
We have developed few product lines by identifying various features and converting these available Java programs into corresponding Jak programs. It may be noted that Jak is one of the feature-oriented programming languages. We have also taken the models of few product lines (such as calculator product line, stack product line, graph product line) from the work of different researchers [45,44,43,46] and developed the corresponding Jak programs. These may be considered as representative feature-oriented programs with aspect-oriented extensions. In all the product lines, we have identified the aspects that are scattered throughout the program. The product lines we have taken as our case studies have various features and aspects which can be used for composing a variety of software product lines. We have taken fifteen product lines as our case studies. The characteristics of our software product lines are depicted in Table 1. These programs are executed for different compositions of features with different aspects weaved for different inputs. Also, the algorithm has been tested for different slicing criteria for different compositions of features and different inputs. The CFADG generation time and average slice computation time for various compositions of features in different product lines are depicted in Figures 13-27.
It can be inferred from Figures 13-27 that different compositions of features result in different slice computation times. The aspects weaved at more number of join points take more time than the aspects weaved at less number of join points. For example, in Calculator Product Line (CPL), the number of join points where the aspect Print is weaved is more than that of aspect Error. That's why the slice computation time for the program where Print aspect  VisTex is a product line that features graphical manipulation of graphs and their textual representation. It is designed to be easily extendible for specific graph-based applications such as UML. is weaved is more than that of the program where Error aspect is weaved. The features containing more number of loops take more time. The composed features containing less number of executable statements take less time compared to those containing more number of executable statements.

Comparison with related work
Several works have been carried out on slicing of procedure-oriented programs [34,32,33,30,47], objectoriented programs [11,21,39,22,15], aspect-oriented programs [37,9,10,16,18,23]. But very, few work have been carried out on slicing of feature-oriented programs [35]. Zhao [9] was the first to develop a two-phase slicing algorithm to compute static slices of aspect-oriented programs. Later, Zhao et al. [10] developed an efficient algorithm for constructing system dependence graph for aspectoriented programs. Ray et al. [16] developed an algorithm to compute dynamic slices of aspect-oriented programs by constructing Aspect System Dependence Graph (AOSG). They had introduced a new logical node called Cnode to capture communication dependencies among the non-aspect code and aspect code. They had also introduced a new arc called aspect-membership arc to connect the dependence graphs of the non-aspect code and aspect code. They had not shown the actual parameters in the pointcuts. Singh et al. [18] proposed a method to compute slices depending upon the slice point location in the program. Their computed slice was an executable slice. Munjal et al. [23] automated the generation of system dependence graphs (SDG) for aspect-oriented programs by analysing the bytecode of aspect-oriented programs. Then, they proposed a three-phase slicing algorithm to compute static slices using the intermediate graph for a given aspectoriented program. All the above works [9,15,16,18,23] have not considered feature-oriented programs.
Apel et al. [3] presented a novel language for FOP in C++ namely FeatureC++. They also mentioned few problems of FOP languages. Apel et al. [4] demonstrated FeatureC++ along with its adaptation to Aspect-Oriented Programming (AOP) concepts. They discussed the use of FeatureC++ in solving various problems related to incremental software development using AOP concepts. They also discussed the weaknesses of FOP for modularization of crosscutting concerns. Apel et al. [5] discussed the limitations of crosscutting modularity and the missing support of C++. They also focused on solutions for ease evolvability of software. Batory [2] presented basic concepts of FOP and a subset of the tools of the Algebraic Hierarchical Equations for Application Design (AHEAD) tool suite. Apel et al. [7] presented an overview of featureoriented software development (FOSD) process. They had identified various key issues in different phases of FOSD. Thum et al. [6] developed an open source framework for FOSD namely FeatureIDE that supported all phases of FOSD along with support for feature-oriented programming languages, and delta-oriented programming languages, aspect-oriented programming languages. Pereira et al. [20] discussed the findings of SPL management tools from a Systematic Literature Review (SLR). These works [7,5,3,4,2,20,6] discussed only the programming and development aspects of FOP and did not consider the slicing aspects. We have presented a technique for dynamic slicing of feature-oriented programs with aspect-oriented extensions using Jak as the FOP language.
Very few work have been carried out on slicing of feature-oriented programs [35]. Sahu et al. [35] suggested a technique to compute dynamic slices of feature-oriented programs. Their technique first composed the selected features of feature-oriented programs. Then, they used an execution trace file and a dependence-based program representation namely dynamic feature-oriented dependence graph (DFDG). The dynamic slice was computed by traversing DFDG in breadth-first or depth-first manner and mapping the traversed vertices to the program statements. They had missed some of the dependences such as mixn call edge, refinement edge, and mixin return dependence edge, etc. that might arise in feature-oriented programs. The drawback of their approach is the use of execution trace file which may lead to more slice computation time. They had not considered the aspect-oriented extensions of feature-oriented programs. In our approach, we have not used any execution trace file. Usually, the execution trace file is used to store the execution history of each executed statement for a given input. Much time is required to store and retrieve the executed statements. The statements are then used for calculation of dynamic slice for each statement. Thus, extra time is required to perform I/O operations on an execution trace file. We do not use any execution trace file. During execution of the program for a given input, the dynamic slice for each statement is computed by marking and unmarking process. Thus, there is no requirement of any execution trace file for storing the executed statements. So, our proposed approach does not take any extra time to read from or write into the execution trace file, thereby reducing the slice extraction time. Also, we have considered the aspects that are scattered throughout the code. Our algorithm does not create any new node in the intermediate representation CFADG during runtime. This results in faster computation of slices.

Conclusion and future work
We have presented an approach to compute dynamic slices of feature-oriented programs with aspect-oriented extensions. The features required for composition are first selected and composed using Algebraic Hierarchical Equations for Application Design (AHEAD) composer. Then, the aspects are weaved into the generated composed Java program using AspectJ composer to produce the resultant AspectJ program. The intermediate dependence based representation of the program containing Jak code and AspectJ code is constructed and it is called Composite Feature-Aspect Dependence Graph (CFADG). The program is executed for an input. During execution, the nodes of CFADG are marked and unmarked according to our feature-aspect node marking dynamic slicing (FANMDS) algorithm. We have developed a tool to implement our FANMDS algorithm and named it FADST. Our tool FADST computes the dynamic slices and the average slice extraction times for various compositions of features and aspects weaved for various product lines. Currently, our tool is able to handle various compositions for few product lines with few aspects captured. Also, current evaluation only uses primitive feature-oriented programs. In future, we will extend our tool to handle more number of product lines with more number of compositions.
Our algorithm may easily be extended to compute dynamic slices of other feature-oriented languages like Fea-tureC++, FeatureRuby, FeatureHouse, Fuji, etc. Also, the extension of the algorithm can be used to compute conditioned slices, amorphous slices for feature-oriented programs with various aspects captured. We will also find out the differences in the performance of different aspects.
B Feature-aspect node-marking