2014 6th International Workshop on Empirical Software Engineering in Practice

Extraction of Conditional Statements for
Understanding Business Rules
Tomomi Hatano∗ , Takashi Ishio∗ , Joji Okada† , Yuji Sakata† and Katsuro Inoue∗∗ Graduate School of Information Science and Technology, Osaka University

1-5, Yamadaoka, Suita, Osaka 565-0871, Japan
Email: {t-hatano,ishio,inoue}@ist.osaka-u.ac.jp† NTT DATA Corporation, Research and Development Headquarters, Center for Applied Software Engineering
Toyosu Center Building Annex, 3-9, Toyosu 3-chome, Koto-ku, Tokyo 135-8671, Japan
Email: {okadaju,sakatayu}@nttdata.co.jp
Abstract—In the maintenance of a business system, developers
must understand the computational business rules implemented
in the system. Computational business rules dene how an
output value of a feature is computed from inputs; the rules
are represented by conditional statements in the source code.
Unfortunately, understanding business rules is a tedious anderror-prone activity. Since a feature computes various outputs,
developers must analyze the implementation of the feature andextract the conditional statements relevant to a particular output.
In this paper, we propose a program dependence analysis technique tailored for understanding business rules. Given a variable
representing an output, our approach extracts conditional statements that may affect the computation of the output. To evaluate
the usefulness of the approach, we conducted an experiment witheight developers in a company. The results showed that ourapproach enables developers to accurately identify conditional
statements relevant to business rules.

I.

The technical statements themselves do not affect the output
directly, although they do decide whether the computation is
executed. Program slicing extracts both types of conditional
statements since it does not differentiate between the two.
Sneed et al. [8] conclude that techniques for data ow analysis
and for extracting partial paths are required for understanding
business rules.
We propose a program dependence analysis techniquetailored for understanding computational business rules. Givena variable representing an output, our approach extracts conditional statements that may affect the computation of thevalue of the variable. To exclude technical statements fromthe analysis, we use a partial control-ow graph, every pathof which outputs a computed result. In addition, we ensure
the specied variable is data dependent on a statement that is
directly or transitively dependent on the extracted conditional
statements.

I NTRODUCTION

In the maintenance of a business system, developers must
understand computational business rules implemented in thesystem [1]. Computational business rules dene how the output
of a feature is computed from inputs. An output value isaffected by conditional statements, e.g., nested if statementsin the feature source code. The rules are often described by atable listing all possible output values and their corresponding
conditions.

We have evaluated whether this approach actually contributes to the performance of developers investigating businessrules. The evaluation was a controlled experiment based on an
actual process in a company. Eight subjects in the company
were asked to identify conditional statements relevant to business rules for a system output. The results showed that ourapproach enables developers to more accurately identify conditional statements relevant to business rules, without affecting
the time required for the task.

Understanding computational business rules is a tediousand error-prone activity for two main reasons [2]. First, documentation describing the rules is generally lost, outdated,or otherwise unavailable. Second, a feature of a system may
compute multiple outputs. For each output, developers are
required to answer a question: which conditional statements are
relevant to this output value? The developers must then analyze
the implementation of the feature and extract the relevant
conditional statements in order to understand the business rules

The contributions of the paper are summarized as follows.

Backward program slicing [3] is used to understand business rules [2], [4], [5], [6], [7]. Cosentino et al. [2] propose
an application of program slicing to extract statements relevant
to business rules that compute a particular variable. However,they report that the extracted statements may include conditional statements that are irrelevant to the business rules.
The irrelevant statements are called technical statements in [2]because they often check if system resources, such as a data leor a database connection, are available for executing a feature.
978-1-4799-6666-0/14 $31.00 © 2014 IEEE
DOI 10.1109/IWESEP.2014.14•

We propose a program dependence analysis techniquefor understanding business rules. Our approach isa variant of program slicing that excludes technicalstatements.

•

We evaluate our technique by conducting an experiment involving eight industrial experts. To the bestof our knowledge, this is the rst study to apply an
automated extraction technique to experts’ tasks inbusiness rule reverse engineering.

The rest of the paper is organized as follows. Section II provides a motivating example. Sections III and IV, respectively,
describe and evaluate our approach. Section V lists related
work. Section VI describes the conclusion and future work.
25

TABLE I: Tables representing computational business rules forthe fee and time limit(a) feevalues5
1015

1 public void action(int status, boolean member) {if (hasError()) { // irrelevant
2
return;3}
4
int fee = 15;
5
if (status == STAT_CHILD) { // relevant to setFee
6
if (member) { // irrelevant
7
return;8}9fee = 5;10
} else if (status == STAT_STUDENT) { // relevant to setFee11
fee = 10;12}
13
setFee(fee);
14
setHour(2);15
if (member) { // relevant to setHour
16
setHour(3);17}18
return;1920 }(b) time limit
conditions
childrenstudents
adultsII.

values32

conditions
premium members
no members

M OTIVATING E XAMPLE

Throughout this paper, we use an example feature that
includes the business rules of an imaginary facility. The featurecomputes a usage fee and a time limit for the facility. The
charge is 15 dollars for adults, 10 dollars for students, and 5
dollars for children. The time limit is 2 h for regular members
and 3 h for premium members. Tables I(a) and I(b) describe thecomputations for the fee and time limit, respectively. Children
may not become premium members.

Fig. 1: An example method implementing business rules

The feature is implemented by a single method in Figure 1.
The method action takes two variables as input: status,
representing a user type (child / student / other), and member,
representing whether the user is a premium member. The
method computes two output variables corresponding to ausage fee and a time limit. The output variables are represented
by the parameters of the setFee and setHour methods.

program dependence graph of the method. A backward slicewith respect to a variable used in a statement is the set ofvertices that are reachable from the vertex representing thestatement by backward traversal via edges.
Although backward program slicing extracts all statementsthat may affect a given variable, it cannot answer the questionof which statements are relevant to the given variable. For
example, a backward program slice with respect to the variable
fee at line 14 includes four conditional statements (lines 2, 6,
7, and 11) that may be executed before line 14. However,
only lines 6 and 11 are relevant to the computational businessrules for fee, since the variable is assigned by statements
controlled by those statements. On the other hand, lines 2 and
7 are irrelevant to the rules in Table I(a) since they represent
conditions to decide whether the feature is executed.

The method action comprises three steps. The rst step
checks whether the database access at line 2 produced an error.
The second step computes an output fee from lines 5 through14, following the rules shown in Table I(a). Lines 7 through 9
examine a constraint between two input variables and cancel
the computation if the constraint is violated. The third step
computes an output hour at lines 15 through 18, following therules shown in Table I(b).
Developers maintaining the system must recover Tables I(a)and I(b) from the source code in Figure 1 in order to understand the computational business rules of the feature. To
recover the tables, developers must answer the question: Whichconditional statements are relevant to the values passed to
setFee and setHour?

Similarly, we can extract statements that may affect aparameter passed to setHour at lines 15 and 17, by computing
the union of program slices with respect to the lines (a decomposition slice [9]). However, the resultant slice includes four
conditional statements at lines 2, 6, 7, and 16. The statement atline 16 is relevant to the computational business rules for theparameter, while the other statements are irrelevant. As demonstrated in these examples, program slicing does not distinguishconditional statements that are relevant to the business rules
from other conditional statements. Consequently, developers
must manually extract the conditional statements relevant tothe computational business rules for the output.

Backward program slicing appears to be a promising tool
to answer the question. A program slice is computed using
a program dependence graph. This graph is a directed graphin which the vertices represent all executable statements in a
program; the edges represent the control and data dependencies
among the statements. These dependencies are computed using
a control-ow graph. Figure 2a shows a control-ow graph ofthe method in Figure 1.
In the graph, each node has a label indicating its corresponding line number. In a control-ow graph, a statements2 is control dependent on a statement s1 , if s1 determines
whether s2 is executed. For example, lines 5 and 6 are control
dependent on line 2, because line 2 has another control-owpath that reaches the exit of the method without visiting lines
5 and 6. A statement s2 is data dependent on a statement s1 ,if s2 may use a variable whose value is dened by s1 . For
example, line 14 is data dependent on line 5 because the value
assigned at line 5 is used at line 14, if the execution passes
through lines 6, 11, and 14. Figure 2b shows the resultant

III.

O UR APPROACH

Our approach is a program dependence analysis of asingle method in a Java program, where we analyze data
dependencies caused by method calls in the method. Our
approach takes two inputs: method m that implements thebusiness rules to be analyzed and a setter method s called inm that receives the output of the business rules. Our approach
extracts the conditional statements in m that are relevant tos. A conditional statement c is relevant to s, if c directly ortransitively affects a statement that determines an argument formethod s. Conditional statements which are not relevant to s
26

Entry2conditional statement5

invocation of a method

6other statement

7

11

control-flow

10

12control dependence
data dependence

14

Entry

2

2

5

5

6

6

Entry

7

11

7

11

2

10

12

10

12

6

15

Entry

5

14

14
7

16

11

(a)

17
10

14

15

16

15

12

16

17

return

Entry

(a)

17

(b)

(c)
2

Fig. 2: A control-ow graph (a) and program dependence graph(b) of Figure 1
include technical statements and statements relevant to othersetter methods.

5

6

14

7

10

11

(b)

12

Our approach comprises three steps.
1)
2)
3)

Fig. 3: Three graphs to extract conditional statements: (a) is a
subgraph of Figure 2a for setFee (line 14). (b) is a dependence
graph extracted from (a). (c) is a subgraph of Figure 2a for
setHour (lines 15 and 17).

Extract a control-ow graph (CFG) of the method mand its subgraph Gs related to s.
Extract control dependence edges in the CFG and Gs
and data dependence edges in Gs .
Extract relevant conditional statements from methodm using control-ow, control dependence, and data
dependence edges.

Figure 3a shows an example subgraph of the CFG in
Figure 2a with respect to setFee. For simplicity, the vertices in
Figure 3 represent executable statements and their line numbersin the program although actual vertices of our implementation
represent bytecode instructions. While vertices 2 and 7 havebranches in the CFG, they have no branches in the subgraph.
Thus, the conditional statements corresponding to the vertices
are not relevant to the computational business rules for fee inSection II.

Our approach uses a call graph for the entire program to
identify method call instructions in m that invoke s and to
perform data dependence analysis on method calls in m. We
use variable-type analysis [10] for our implementation.
A. Control-Flow Analysis
This step constructs a CFG from the bytecode of m, andextracts its subgraph such that every path from the entry point
invokes s. A CFG is a directed graph in which the vertices
VCF G represent all bytecode instructions of m and the edges
CF represent control-ow paths [11]. Let S be the set of
instructions invoking s. Subgraph Gs has vertices Vs and edges
CFs formulated as follows.
Vs
CFs

=
=

B. Dependence Analysis
This step extracts data dependence edges (DDs ) and two
kinds of control dependence edges (CD and CDs ). CD
is the set of control dependence edges extracted from the
CFG of m. CDs and DDs are sets of control dependence
and data dependence edges extracted from the subgraph Gs .
In addition to the denition of dependence representations
given by Horwitz et al. [12], we extract the following data
dependence edges.

CF ∗{v ∈ VCF G | ∃s ∈ S : v −−−→ s}{(v1, v2) ∈ CF | v1 ∈ Vs ∧ v2 ∈ Vs }1) Constant values: A constant value used in a statement
is independent of other statements. However, we dene a data
dependence edge between a bytecode instruction that loads
a constant value and another instruction that uses the value.

Ex−→ y denotes there exists an edge from x to y in E (i.e.,E∗(x, y) ∈ E). x −−→ y denotes there exists a path from x to yE∗through edges in E. Note that x −−→ x.
27

For example, the statement at line 17 comprises two bytecode
instructions: the instruction that loads the constant value 3and the instruction that invokes setHour. There exists a data
dependence edge between the two. This data dependence isintroduced to identify a conditional statement that controls
method call statements using different constant values.

R may include truly irrelevant statements since our approach uses only dependencies among instructions. If several
assignment statements pass the same value to s, conditional
statements that select one of those statements are irrelevant to
the output. However, our approach regards such conditional
statements as relevant to the output.

2) Field and array variables: Suppose an instruction i1
denes the value of a eld variable (or an element of an arrayvariable) and another instruction i2 uses the value of the eld
variable (or element of an array variable). There exists a data
dependence edge from i1 to i2 if i1 and i2 may access thesame eld (or the same array). Each eld is identied by classname and eld name considering class hierarchy. Each arrayis identied by its type.

Our implementation supports two techniques for providing
the extracted conditional statements to developers. The rst
one is code comments. Our tool adds code comments toconditional statements as shown in Figure 1. Since developers
are required to analyze the same method m for each output
variable, an irrelevant statement for one variable may be
relevant for another. Developers may use code comments generated for several variables to understand the entire structureof the method. The second technique is a CSV le. Our tool
outputs a le listing all the conditional statements in a speciedmethod m and indicating whether each statement is relevant
or not. Developers may record the progress of investigation in
the generated le.

3) Invocations of methods: Suppose instructions i1 and i2
invoke methods. There exists a data dependence edge from i1
to i2 if the following condition holds.
Def (i1 ) ∩ U se(i2 ) = ∅where Def (i1 ) is the set of eld and array variables that may
be dened by methods (directly or transitively) invoked fromthe instruction i1 . U se(i2 ) is the set of eld and array variables
that may be used by methods (directly or transitively) invokedfrom i2 . For a conservative analysis, we assume that librarymethods that are not included in the target program may deneand use all eld and array variables in the program.

IV.

Developers must examine the source code of a feature
to understand the computational business rules, even if therelevant conditional statements are extracted by our technique.
In order to evaluate whether our technique can help developers
identify relevant conditional statements, we conducted a controlled experiment using human subjects. We formulated thefollowing research questions.

C. Extracting conditional statements

RQ1

Using the computed dependence edges, this nal step
extracts the set of relevant conditional statements R from m
as follows.
R=

CV ∪ OW

CV

=

s
s}
{c | ∃s ∈ S, ∃d ∈ Vs : c −−−−−−−−−→ d −−−→

OW=

{c | ∃s1 , s2 ∈ S, ∃d ∈ Vs : s1 −−−s→ c ∧(CDs ∪DDs )∗

RQ2
RQ3

DD

CF ∗

(CD∪DDs )∗E VALUATIONCan our technique help developers accurately
identify conditional statements relevant to computational business rules?
Can our technique reduce the time needed to
identify relevant conditional statements?
To what degree do the results of our techniquediffer from those of the developers’ investigation?

A. Experimental Setup

DD

s
s2 }
c −−−−−−−−→ d −−−→

1) Subjects: We recruited eight reverse engineering experts
from a company. They had been engaged in reverse engineering for at least a year. Their Java experience was widelydistributed from 0.5 to 12 years, with a median of a year. No
subject was familiar with the target system.

CV represents the set of conditional statements that may affectstatements passing values to s. Each element of CV directlyor transitively affects an instruction that provides data to s.
OW represents the set of conditional statements that decide
whether a value set by s1 is overwritten by another value ats2 . Since a conditional statement affects an output even if it
decides not to execute s2 , we use CD instead of CDs for thedenition of OW .

2) Tasks: The tasks used in our experiment were createdfrom MosP 4.0.01 , an attendance management system. Two
methods, m1 and m2 , were randomly selected from the longest
methods whose conditional statements could not be removed
by program slicing. Table II shows the details of the two
methods. Column |C| represents the number of all conditional
statements in m. Column |Cs | represents the number of conditional statements located prior to a setter method call s in thesource code of m. All conditional statements were extracted
by program slicing with respect to each setter method. Column|R| indicates the number of conditional statements extracted
by our technique.

Figure 3b shows a dependence graph of the program in
Figure 1 when setFee is specied as s (i.e., S = {14}).
The conditional statements at lines 6 and 11 are extracted
as relevant statements since they hold the condition of CV .
Figure 3c shows a subgraph when setHour is specied as s(i.e., S = {15, 17}). The conditional statement at line 16 is
extracted as a relevant statement since it holds the conditionof OW . The conditional statements at lines 2 and 7 are notextracted since they do not hold the conditions of either CV orOW ; nor do they satisfy the condition of CV since they haveno dependence edge to other vertices. Furthermore, they do
not satisfy the condition of OW since they are not reachable
from setFee or setHour.

For each task, the subjects were given the following.
•

Eclipse IDE including the source code of the system.

1 http://sourceforge.jp/projects/mosp/releases/53354

28

TABLE II: Target methods

T2

LOC

|C|

|Cs |

|R|

0.95

101

17

12

7

0.90

152

23

23

15

5000

4000

0.85

Time[s]

T1

Methods
m1 = getPaidHolidayDataDto
s1 = setAcquisitionDate
m2 = chkWorkOnHolidayInfo
s2 = setPltWorkType

Accuracy

ID

1.00

0.80

3000

0.75

TABLE III: Task assignment
Subject
1, 2
3, 4
5, 6
7, 8

Task 1
Target Our approach
T1
Yes
T1
No
T2
Yes
T2
No

0.70

Task 2
Target Our approach
T2
No
T2
Yes
T1
No
T1
Yes

2000

0.65
0.60

with
our approachwithout
our approachwith
our approachwithout
our approach

Fig. 4: Comparison of the accuracy and time for tasks•

Target method m and the setter method s to beanalyzed.

•

Spreadsheet including all conditional statements andtheir line numbers in m.

public void foo(int i) {if (i == 0) {setX(10);} else if (i == 1) {setX(20);}
return;}The subjects performed one task with our technique andthe other task without our technique. Table III shows the tasks
assigned to the subjects. The results of our technique were
provided to the subjects by annotating conditional statementsin the source code (as shown in Figure 1) and in a spreadsheet.
A subject working without our technique received a list of
conditional statements in a spreadsheet without annotation. A
program slice was not explicitly provided because it includes
all the conditional statements located prior to s.

Sample code

Entry

Entry

i == 0setX(10)i == 1setX(20)

Our approachcombinedconditionsi == 0i == 1setX(10)setX(20)Developers

Fig. 5: The difference between our approach and developers

conditional statements against the total number of conditional
statements in the method. We observed that developers supported by our technique classied conditional statements moreaccurately. A Wilcoxon rank sum test showed the difference
was statistically signicant (the p-value was 0.0148). Furthermore, Cohen’s d = 0.846 showed the difference was large[13]. The improvement was achieved because subjects without
our technique tend to accidentally misclassify conditional
statements as irrelevant. Our technique enabled subjects tocarefully investigate such relevant conditional statements byidentifying irrelevant conditional statements. We concluded
that our approach enabled the developers to accurately identify conditional statements relevant to computational businessrules.

Each task comprised two subtasks that are typical reverse
engineering processes in the company. In the rst subtask, thesubjects classied each conditional statement as either relevant
or irrelevant and wrote the result into a given spreadsheet. In
the second subtask, they used the results of the rst subtask tocreate a table of the computational business rules. Each task
is limited to 2 h. The results of the second subtask were used
to determine the correct answer of the rst subtask.
3) Procedure: At the beginning of the experiment, thesubjects were given the following information: (1) the purposeof the experiment, (2) a summary of our technique, (3) theprocess of the task, (4) an exercise in MosP using an example
task, and (5) an explanation of the answer of the example
task. The subjects performed their tasks independently after
the introduction.

2) RQ2 Can our technique reduce the time needed to
identify relevant conditional statements?: The right box plot
in Figure 4 compares the time spent to complete the task withand without our technique. Although developers supported byour technique took less time than those without our technique,the difference was not statistically signicant (the p-value was
0.6454). This is because the subjects read the entire sourcecode of the methods to understand business rules. Even if
relevant conditional statements are automatically extracted,
they must verify what conditions are represented in thosestatements. We conclude that our technique does not affectthe time for investigating source code and creating tables.

After all the tasks had been completed, the subjects discussed the correct answer with the third author, who is also areverse engineering expert in the company. Since they reachedagreement on the computational business rules in the tasks, weused the results to evaluate the accuracy of the subjects.
B. Results
1) RQ1 Can our technique help developers accurately identify conditional statements relevant to computational businessrules?: The left box plot in Figure 4 compares the accuracyof the developers’ classication of conditional statements. The
accuracy is the ratio of the number of correctly classied3) RQ3 To what degree do the results of our techniquediffer from those of the developers’ investigation?: The set of
relevant conditional statements created during the discussion29

of a particular variable while ignoring irrelevant control-owpaths; therefore, it does not preserve the semantics.

with the subjects included 17 statements. Fourteen of theoriginal 22 statements were extracted by our technique andthe remaining three conditional statements were missed by ourtechnique. Hence, the recall and the precision of our techniqueare 0.82 (14/17) and 0.64 (14/22), respectively. Our technique
included eight statements that were classied as irrelevant by
the subjects, because of a simple conservative analysis forlibrary methods. The conditional statements would be excluded
if a more precise analysis was implemented.

VI.

We have proposed a program dependence analysis technique tailored for understanding computational business rules.
Our approach extracted conditional statements that were relevant to an output value. We conducted a controlled experimentto evaluate whether or not the approach actually contributed tothe performance of the developers. We found that our approachenabled developers to more accurately identify conditional
statements relevant to computational business rules.

Our technique missed three conditional statements becauseof a difference between actual dependence and conceptual
dependence. A simplied example is shown in Figure 5. In
the source code, two conditional statements, if (i == 0) and if(i == 1), determine a value passed to the method setX. Our
approach classied the former statement as relevant and thelatter statement as irrelevant, because the former statement
determined the parameter: 10 is passed if i == 0 and 20 otherwise. On the other hand, developers classied both conditional
statements as relevant since they subconsciously regarded thetwo consecutive statements as a single control-ow structure.

In future work, we would like to support conceptually related conditional statements as described in Section IV-B3. We
are also interested in the interprocedural analysis of businessrules scattered across several methods. Finally, we plan to
apply our approach to other enterprise systems to evaluate theeffectiveness of our approach.
ACKNOWLEDGMENT

We determined that our technique can extract conditional
statements without missing relevant statements by regarding
consecutive conditional statements as a combined statement
as shown in the right side of Figure 5. Although conditional
statements extracted by this approach may include irrelevant
statements, the approach is expected to reduce the developers’ identication time since they only need to consider the
extracted statements without inspecting the other conditional
statements.
V.

C ONCLUSION AND FUTURE WORK

We would like to thank the subjects who participated inthis study. This work was supported by JSPS KAKENHI
Nos.25220003 and 26280021.
R EFERENCES[1][2]

R ELATED WORK

[3]

Various techniques to extract computations from sourcecode have been proposed. The frameworks to extract businessrules are proposed [2], [4], [5], [6]. They represent computations of business variables using program slicing techniques.
Our analysis technique excludes irrelevant statements that are
extracted by these techniques. Moreover, we have evaluatedthe ability of our technique to assist developers.

[4]
[5]
[6]

[7]

Pichler [14] proposed a symbolic execution technique toextract computations from a Fortran program. Their techniquerequires actual test cases from a target system, while ourapproach does not assume the existence of test cases. Dubinsky
et al. [15] propose a method to identify business rules in
the code and nd the code locations. The method relies on
business terms in the code and comments while we use only
dependencies among statements. Thin slicing [16] extracts
only assignment statements that dene an output value andexcludes all conditional statements from a slice. Our techniqueextracts conditional statements that depend on assignment
statements. Decomposition slicing [9] extracts all statementsthat may affect the assignment statements of a particularvariable. Since a decomposition slice is computed by theunion of traditional program slices, it includes conditional
statements that are irrelevant to business rules as described in
our motivating example. As a variant of program slicing, ourapproach is related to amorphous slicing [17]. Amorphous slicing summarizes the computations of a particular variable while
retaining the semantics of the original program. Our approach
extracts conditional statements relevant to the computations

[8]
[9]

[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]

30

K. Wiegers and J. Beatty, Software Requirements, 3rd ed. Miscrosoft
press, 2013.
V. Cosentino, J. Cabot, P. Albert, P. Bauquel, and J. Perronnet, “Extracting business rules from COBOL: A model-based framework,” inProc. WCRE, 2013, pp. 409–416.
M. Weiser, “Program Slicing,” IEEE Trans. Softw. Eng., vol. SE-10,
no. 4, pp. 352–357, 1984.
X. Wang, J. Sun, and X. Yang, “Business rules extraction from large
legacy systems,” in Proc. CSMR, 2004, pp. 249–253.
H. Huang and W. Tsai, “Business rule extraction from legacy code,” inProc. COMPSAC, 1996, pp. 162–167.
V. Cosentino, J. Cabot, P. Albert, P. Bauquel, and J. Perronnet, “A
Model Driven Reverse Engineering Framework for Extracting Business
Rules out of a Java Application,” in Proc. RuleML, 2012, pp. 17–31.
H. Sneed, “Extracting business logic from existing COBOL programs
as a basis for redevelopment,” in Proc. IWPC, 2001, pp. 167–175.
H. Sneed and K. Erdos, “Extracting business rules from source code,”in Proc. WPC. IEEE Comput. Soc. Press, 1996, pp. 240–247.
K. B. Gallagher and J. R. Lyle, “Using program slicing in software
maintenance,” IEEE Trans. Softw. Eng., vol. 17, no. 8, pp. 751–761,
1991.
V. Sundaresan and L. Hendren, “Practical virtual method call resolution
for Java,” in Proc. OOPSLA, 2000, pp. 264–280.
F. Allen, “Control ow analysis,” ACM Sigplan Notices, vol. 5, no. 7,
pp. 1–19, 1970.
S. Horwitz, J. Prins, and T. Reps, “Integrating non-interfering versionsof programs,” ACM TOPLAS, vol. 11, no. 3, pp. 345–387, 1989.
J. Cohen, “Statistical power analysis,” Current Directions in Psychological Science, vol. 1, no. 3, pp. 98–101, 1992.
J. Pichler, “Specication extraction by symbolic execution,” in Proc.
WCRE, 2013, pp. 462–466.
Y. Dubinsky, Y. Feldman, and M. Goldstein, “Where is the businesslogic?” in Proc. ESEC/FSE, 2013, pp. 667–670.
M. Sridharan, S. J. Fink, and R. Bodik, “Thin slicing,” in Proc. PLDI,
2007, pp. 112–122.
M. Harman, D. Binkley, and S. Danicic, “Amorphous program slicing,”
Journal of Systems and Software, vol. 68, no. 1, pp. 45–64, Oct. 2003.