Aye My at Thin

Development of Software Testing and Analysis Tools –Part E
Submitted by
Aye Myat Thin
SCHOOL OF ELECTRICAL AND ELECTRONIC ENGINEERING
NANYANG TECHNOLOGICAL UNIVERSITY
A final year project report

presented to
Nanyang Technological University
in partial fulfillment of the requirement for the
Degree of Bachelor of Engineering(Electrical and Electronic Engineering)
Nanyang Technological University
2009/2010
Project Number: A3242-082

STATEMENT OF ORIGINALITY
I hereby certified that the content of this dissertation is the result of work done
by me and has not been submitted for education used purpose in any other
university or institution.
--------------------------- -------------------------------
Date AYE MYAT THIN
(072218H03)
ii
Table of Contents
TABLE OF CONTENTS
STATEMENT OF ORIGINALITY…………………………………………….ii
TABLE OF CONTENTS……………………………………………….……..iii
APPENDIX………………………………………………………………..……v
LIST OF FIGURES……………………………………………………..…….vi
ABSTRACT………………………………………………………………..….vii
ACKNOWLEDGEMENT………………………………………………...….viii
CHAPTER 1 INTRODUCTION
1.1 Background…………………………………………………………………………….1
1.1.1 IPathDectcor2……………………………………………………………….….1
1.1.2 Other tools…………………………………………………………………...2
1.1.3 Difficulties of tracing the source code and IR code manually…………......2
1.2 Objective of this project ………………………………………………………………3
1. 3 Report Organization………………………………………………………………….4
CHAPTER 2 RELATED TOOLS TECHNOLOGY
2.1 White –box Testing………………………………………………………………….…5

2. 2 Soot……………………………………………………………………………………..6
2.2.1 Input to IPathDetector2…………………………………………………………7
2.3 Input to Simplify and Z3……………...………………………………………...…….10
CHAPTER 3 DEVELOPMENT OF TEST SYSTEM
3.1Purpose of program…………………………………………………………………..13
3.2 Program Functionalities and diagrammatic explanation………………..……..…13
iii
Table of Contents
3.3 Results analyzed by Tools…………………………………………………………..19

CHAPTER 4 SUB-SYSTEM FOR INFEASIBLE PATH DETECTION
4.1 Purpose of the program………………………………...…………………………….20

4.1.1 Adding new methods…………………………………………………………..21
4.1.2 Encapsulation ………………………………………………………………….22
4.2 Retrieving and printing IR statements of the unsolvable paths………….…….…22
4.3 Retrieving and printing source code of the unsolvable paths……………….……23
4.4 Advantages of the developed program……………………………………………..29
4.4.1 Benefits towards IPath Detector 2……………………………………………..30
4.5 Recommendations for improvements ………………………………………………30
CHAPTER 5 MANUAL EVALUATION OF PATH FEASIBILITY
5.1 purpose of Manual Evaluation…………………………………….……………...….33

5.2 Patterns of infeasibility ……………………………………………………………….33
5.2.1 Causes of infeasibility……………………………………………………….....35
5.2.2 Organization of Manual Analysis ………………………………………….…36
5.3 Manual Analysis 1………………………………………………………………..……38
5.3.1 Path Evaluation…………………………………………………………………39
5.3.2 Summary of Manual Analysis 1 ………………………………………………41
5.4Manual Analysis 2………………………………………………………..…………….42
5.4.1Manual analysis methods……………………………………...……………....45
5.4.2 Path evaluation…………………………………………………………….…...46
5.4.3 Summary of Manual Analysis2 ………………………………………….……61
5.5 Manual Analysis 3 ………………………………………………………………...…..61
5.5.1 Path evaluation……………………………………………………..……….….61
5.5.2 Summary of Manual Analysis 3………………………………………….……62
5.5.3 Comparison of Manual Analysis and Tools results…………………….…..63
iv
Table of Contents
CHAPTER 6 CONCULSION
6.1 Achievement of the Developed Test System……………………….……………..66

6.2 Achievement of Sub-System for Infeasible Path Detection………………….…..67
6.3 Achievement for Manual Evaluation of Path Infeasibility………………………...67
6.4 Suggestions for Improvement……………………………………………….68
REFERENCES………………..……………………………………………..70
v
Table of Contents
APPENDIX
Appendix 1.0: Master Student Mark Calculation Program with GUI
A1.1 Package of GUI………………………………………………………………….A1

A1.1.1 MasterStudentDatabase.java………………………………………….A1
A1.2 Package of Utilities……………………………………………………..……..A10
A1.2.1 DataValuesTable.java………………………………………………...A10
A1.2.2 RowHeader.java………………………………………………………A16
A1.2.3 Table_Sheet.java……………………………………………………...A17
A1.2.4 Vector2D.java………………………………………………………….A21
Appendix 2.0: Attaining of Java Source and Intermediate Representation (IR)
A2.1 Main class for calling source and IR getting functions…………………..A23

A2.1.1 Analyzor.java……………………………………………………..…..A23
A2.2 Subclass for IR code retrieval………………………………………………A38
A2.2.1 Printstmt.java………………………………………………………….A38
A2.2.2 RWMethods.java……………………………………………………..A39
Appendix 3: Manual Analysis results of the paths in the tested program
A3.1 Manual Analysis 1: JtoPass using Simple IR Expression ………………A40

A3.2 Manual Analysis 2: JCM using Simple IR Expression ……………….….A44
A3.3 Manual Analysis 1: JtoPass using Original IR Expression ……………..A85
Appendix 4: User Guide……..…………………………………………………….A88
vi
List of Figures
LIST OF FIGURES
Figure 1: Flow of code conversion for the specific suite of Tools…………………….6
Figure 2: Soot Phases……………………………………………………………………...8
Figure 3: Main Window Frame of Program…………………………………………...14
Figure 4: Example of Menu and button………………………………………………...14
Figure 5: Plain Data sheet ………………………………………………………………..15
Figure 6: Error message on invalid input…………………………………………….…15
Figure 7: Display of the result of calculated total marks ………………………….…..16
Figure 8: Save as Dialog Box for choosing URL………………………………………16
Figure 9: Message box after the file saved successfully……………………………..17
Figure 10: Drop down list for choosing the file…………………………………………17
Figure 11: Opened file in Excel………………………………………………………..…18
Figure 12: Selecting all the cells …………………………………………………………18
vii
Abstract
ABSTRACT
In software structural testing, the analysis and detection of infeasible paths in

the program is critical. Automated test data generation plays an important part in
reducing the cost and increasing the reliability of software testing. However, a
challenging problem in path-oriented test data generation is the existence of
infeasible program paths, where considerable effort may be wasted in trying to
generate input data to traverse the paths. But the problem is that there is not fully
reliable program that can detect all infeasible paths and it has been a long pending
problem in structural testing.
If tool can correctly detect all major infeasible paths in the tested system, the
precision of static analysis will be greatly enhanced, and therefore improves its use
in many areas, particularly in structural testing [9] and code optimization. Thus, the
most key place where infeasibility rise is identified based on two patterns of the code
statements. These two patterns will be described detail later in this report. So,
basically, the developing tool, IPathDetector2 is designed to test the infeasibility of
the paths using these two patterns. By using this tool, larger portion of infeasible
paths were identified and the precision and coverage of the earlier method is much
more improved.
But, it still not completely robust for automated testing as there are theoretically
invisible causes of the inability to detect some forms of infeasibility. Thus, some
infeasible paths will not be identified Compared to different automated analysis tools;
which are Simplified, Z3, although some of the previously unidentified paths are
solved, there variations between the results obtained using 3 different tools are
found.
This report will comprise of ways of finding weakness and cause of those
variations by mean of manual analysis, so that to carry on actions improve the
performance quality and reliability of IPathDetecotr 2.
viii
Acknowledgement
ACKNOWLEDGEMENT
I would like to express my sincere appreciation to the two persons, who have
given me great guidance throughout my project development.
First and foremost, I would like to give my deep thanks to Dr . Tan Hee Beng
Kuan, my FYP supervisor, for directing the whole concept of the project and sharing
knowledge of software testing. His encouragement and structural instructions has
helped me to get over the difficulties along the ways and keep me dedicated.
And also I would like to show my gratitude to Mr Ding Sun, final year PHD
student from Electrical and Electronic Engineering. He has helped me widen the
knowledge about Programming and enforce my critical thinking skills in developing
functions for project. Moreover, he has patiently and willing explained the ambiguity
and doubts throughout my project developments.
Their kind guidance and help motivated me to continue trying and finally get
the targets of the project on time. Thus, I would like to show my heartfelt thanks to
those people with sincerity.
ix
Chapter 1 Introduction
CHAPTER 1 INTRODUCTION
1.1 Background
IPathDetecotr 2 has been developed as a software analysis tool developed

since. It was been initialized, edit and enhanced by chains of PHD, post graduate
and under graduate students. So, since after nearly 2 years of alteration of
functionalities and operations, many of the improvements of the performance and
capability of the tools have been better compared to the Simplify and Z3 software
testing tools ‘ capabilities as follows:[13]
1.1.1 IPathDectcor2
Linear method, a symbolic checking of the relation between symbols of the

predicate nodes, is used for automatic analysis of IpathDetector2 program. Liner
equation method is also. Each of the predicate node statement will be group together
and simply use them to solve as how the matrix in mathematic is solved for
evaluation of the predicate nodes.
Use 2 patterns in evaluation of the tested java code which are flag-based or e-
correlated analysis.
Since there tool has been implemented since year…and it’s a work of different
programmers, there might have functional or logical errors s that would sway the
results from getting the correct answer but the program still workable. Not 100%
assured that all the methods or test cases implemented in the tool is robust and error
free.
1
1.1.2 Other tools
Simplify:
Can test 50% of the total paths in the tested program because of the
methodological wrong assumption that when testing some predicate node, it testing
for all values of same variable as in predicate node
The major weakness of Simplified tool is that it only support int and does not
support other primitive data types.
Z3:
Can test nearly 100% of paths in the tested program
It supports all primitive data types.
It is methodologically better than Simplified because it test for existing variable
in the predicate node
1.1.3 Difficulties of tracing the source code and IR code manually
If there are variations among tools’ results, manual analysis checking needs to be
done. The study of either or both of relevant IR or source code is essential to find out
the source of variations. And have to locate the correct code of the list of varied path
id. So it is very time consuming and unreliable to correlate back the class name back
to path id and match the converted IR and extracted original java source code. The
disadvantages of tracing the codes manually based on path id.
 is not timesaving
 is unreliable
 May involve many human errors
 May involve wrong interpretation where matching the class name back to path
id
 Might copy the wrong source and IR files from wrong class name
2
Thu, it is very inconvenient for manual analysis and evaluation of checking the
infeasibility and feasibility of paths without having being able to directly retrieve
source code and converted IR representations from the desired path id.
1.2 Objective of this project

White box testing of the test system is done automatically by tools. Since
there are variation in the results of tools analysis, reliable checking need to be done
and so there comes to the necessity to do manual analysis for the following
expectancy of outcomes.
1. Major infeasible paths will be detected correctly

2. The ambiguity among variations among the answers of tools will be solved
3. The cause of missing / wrong detection will be found and can improve
based on it.
To test more efficiently and accurately, it is required to conduct manual

analysis , it is important to find a way to do manual analysis without wasting much
effort in location source codes and IR by the resulted unsolved or varied path id ,
analyzed by tools.
Thus main objective is to Implement the sub-system for infeasible path

detection ,comprised functions to support Manual Analysis and analysis of manual
analysis findings contrast to tools result to find out the weakness area in
IPathDetector2 before publishing it formally as software testing tool.
Next is to do manual checking for the variations among the results of the
paths analyzed by tools using the developed subsystem for infeasible path detection
and decide the feasibility or infeasibility. Moreover, objective is to identify the correct
feasibility or infeasibility of the unsolvable path.
Last objective but not the least, is that to compare the results obtained from
Manual Analysis and Tools results and find the actual cause of the infeasibility
before carrying out improvements and amendments to IPathDetector2.
3
1.3 Report Organization
The work done will be shown in the classified as chapters as follows:

1.Introduction and backgrounds
2.Related Tools Technology used in the project
3.A sub-system for Infeasible Path Detection
4.Development of Test System
5.Manual Evaluation of Path Feasibility
6.Conclusion
4
Chapter 2 Related Tools Technology
CHAPTER 2 RELATED TOOLS TECHNOLOGY
2.1 White –box Testing
The software testing technology used in testing tools are white box testing.
Since, all the intra-path, inter-path tool testing and manual analysis falls under the
white box testing. The tool testing and manual analysis checks the functions and
results of internal data structure, code and algorithms and data operation. Because
of this, tool testing and manual analysis went through during IPathDetector2
construction stage is classified as white-box testing.
Thus, by the nature of white box testing is not like black box testing nature,
which only looking at the input and output and ignore the inter-operations and data
flow. White-box testing purpose is to make the internal system is transparent and
viewable to user. So, white box testing is suitable tesing methodology to be used in
IPath detector2 automatic and manual path analysis.
Figure 1 represents the white box-testing strategy. So, all the system’s
executable program parts are visible using white box-testing strategy. And those
were being focus in review and reliability checking. Means the feasibility checking,
validation, error finding, correction of data flow, path flow, structure , control flow ,
and all other internal program is functions that White box testing allows to testers.
Inputs and outputs are taken as causes and effects in white-box testing.
Consequently, to check the internal data operations and path flow, this
usually requires writing code or a minimally sub-system program to do analysis .It
also requires technical knowledge on both the specific software and tools pending for
testing.
The test cases which apply white box testing are to be built on the structure instead
of functions. So, since the structure of IPathDetector2 ‘s path detection program is
based on the Control Flow Graph, the automatic and manual analysis should follow
the Control Flow Graph based structure.[21]
Path coverage (all the possible combinations of true and false condition
predicate nodes), branch coverage (traverse every branch statements), or statement
coverage (executing line by line at least once) can be exhaustive using white-box
testing. So, test case which use white box testing are design based on whether the
basic , random , or all nodes or paths will be covered or traversed at least once.
Problems of intractability within the internal system are overcome using white
box testing. Thus, I path detector 2 is designed to use white box testing and
structured to cover all the possible paths in the test system to detect the
infeasibilities within the whole system.
5
2.2 Soot
The diagrammatic view of how the the code conversion of from the source
code to relevant tools input IR for different tools is as shown in the Figure 1 below.
6
Source Code
Start of the definition of the path
Soot
Intermediate
Representation
(IR) statement
lines of the path
IR expression in the form IR expression in the form IR expression in the form

of process able by of process able by Z3 of process able by
Simplified IPathDetector2 (proposed
method)
7
Source Code
Epression
Linear
tool Using
of IR for each
specific form
from IR to
Conversion
Execution using Soot
Simplified tool Z3 Tool IPathDetector 2

Tool(Jimple IR)
Figure 1: Flow of code conversion for the specific suite of Tools

Soot is Java language based software. Soot is free software and is licensed
under the GNU lesser General Public License. Soot can be used as a standalone
tool to optimize or inspect class files. Soot can be used as well as Java optimized
8
framework, for analyzing and transforming Java byte code (which supports more
than 200 different operations) by providing four intermediate representations
(IR)shown below.
1. Baf:
 It is a streamlined representation of stack-based byte-code

 It has a form of three address code
 It is simple to manipulate.
2. Jimple:
 It is used to convert stack-based byte-code into typed 3-address

code/intermediate representation (“Jimplifying”)
 Thus, it is more suitable for optimization.
 It consists of 15 different possible operations.
3. Shimple:
 It is an SSA (Statistic Single Assignment) variation of Jimple.
4. Grimp:
 It is an aggregated version of Jimple

 It is suitable for decompilation and code inspection.
2.2.1 Input to IPathDetector 2(Jimple IR)
IPathdector2 use Jimple form Soot to convert the source code to IR code during
configuration.
-p jb use-original-names:true
Thus, the following is the detail procedure of how the Jimple works in source
code conversion. Soot’s execution is done in a set of different jp (jimple body) packs
which of each pack contains different phases.
When conversion from source code to IR code, jimple IR is obtained and used
in IPathDetector2.Jimple is an IR of JAVA program which was in the form of three
address code which is an alternative to stack-based bytecode.Jimple is also the
heart of soot optimization framework. That is why; it is believed to be more effective
in optimization by designers. The main purpose of converting stack-based bytecode
to three address code(“simplifying”) is to see each position in stack has own
variables and assigning values to those variables. It is to check that the operations
on variables are done only after certain values are assignment to variable.
Example of how three-address code can be transformed from stack-based

bytecode as shown below.
9
Stack-based based byte code:
iload 1 // load variable x1, and push it onto the stack

iload 2 // load variable x2, and push it onto the stack
iadd // pop two values, and push the sum of the two onto the stack
istore 1 // pop a value from the stack, and push it onto the stack
Three-address code:
stack1 = x1 // iload 1
stack2 = x2 // iload 2
stack1 = stack1 + stack2 // iadd
x1 = stack1 // istore 1
Step1: Jimple Body Creation (jb):
Firstl, Soot applies the jb pack to every single method body, or in other
terms to every method that has a body. Native methods such as
System.currentTimeMillis() have no body. The jb pack is fixed and it is
concerned with the creation of the Jimple representation. It cannot be changed!
The diagram belown shows you the different pack that exist in Soot.
Figure 2: Soot Phases [1]
Step2: Whole-program packs (cg, wjtp, wjop, wjap)
Secondly, Soot applies four whole-program packs to the body which are
as shown below:
1. cg, the call graph pack,

2. wjtp, the whole-jimple transformation pack,
3. wjop, the whole-jimple optimization pack
4. wjap, the whole-jimple annotation pack.
10
All of the four-program packs can be changed by adding “Scene

Transformers” that conduct a whole-program analysis. A Scene Transformer
accesses the program through the Scene in order to analyze and transform the
program.
Stpe 3: Jimple packs (jtb, jop, jap)
Thirdly, Soot then applies three jimple packs to each body :
1. jtp(the jimple transformation pack) is usually where intra-procedural

analyses are placed. It is empty and enabled by default.
2. jop(the jimple optimization pack)comes pre-equipped with a set of
Jimple optimizations. It is disabled by default and can be enabled by
using Soot’s -o command line option.
3. jap(the jimple annotation pack)is for jimple annotation. Annotations are
added to each Jimple body that let a JVM assess the results of the
optimizations. This pack is enabled by default.
Every Transform added to a (non-whole) Jimple pack must be a

BodyTransformer. [1]
Step 4: Packs Baf Bodies (bb) and tag
Fourthly and as the diagram shown above, Soot lastly applied the packs bb and
tag to each body. The bb pack converts the (optimized and tagged) Jimple bodies
into Baf bodies. Baf is Soot’s stack based intermediate representation from
which Soot creates bytecode. The tag pack last but not least aggregates certain
tags. For instance, if multiple Jimple (or Baf) statements share the same line number
tag then Soot will retain this tag only on the first instruction that carries this tag, to
gain uniqueness.
By using Jimple from Soot, IR statements are resulted. IR is the Intermediate

representation form of the original source code. It is necessary for creating specific input
IR codes to testing tools (IPathDetector 2, Simplified and Z3) and useful in manual
analysis of the tested to locate the predicated nodes.
2.3 Input to Simplify and Z3
11
Although Jimple IR form is much simpler than original java source code, it is not
directly be able to use as input into other tools and Simplify and Z3. Moreover for the
purpose of manual analysis, Jimple IR still looks complicated to read and coding of
each predicate node may be written lengthy and looks complicate.
Thus, input for Simplify and Z3 system is created using three address code ,
which is Statistic Single Assignment Form (SSA) form as elaborated below.
Three Address Code
Three-address code, abbreviated to TAC or 3AC, is an intermediated code

used by compilers in code-improving transformations. Each instruction in three-
address code can be described as: operator, operand1, operand2, result. Each
simple operation has the general form as follows:
x:= y op z
e.g x : = y + z
Where x, y and z are variables, constants or temporary variables generated

by the compiler. op represents any operator, e.g. an arithmetic operator.
Expressions containing more than one fundamental operation, such as:
a := b + c x d
It is not represent-able in three-address code as a single instruction.

Instead, they are decomposed into an equivalent number of instructions, such as
e := c x d
a := b + e
The term three-address code is still used even if some instructions use
(more or fewer than two operands).
Abbreviation notation
The naming of all the variables, method or functions in short form and
declare the begin letter followed by numeric identification as follows:
V0: Variable
V1: another different /unique name of variable and so on.
F 0: a complicated call or simple call of a function
12
F1: another unique /different path of complicated call or simple call of a function
and so on.
N 0: a number which have float data type
N 1: another different number which have float data type and so on.
O 0: object of the class of constructor
O 1: another unique different representation of the class of constructor and so
on.
The conversion is start from the very beginning of the line until the path is
finished sequentially. The steps of code transformation form source to IR code for
the paths are as follow:
Step 1:First of all, if line is definition statement, then the variable, or object or
returned variable from called function or number ,it will be given a name that
identify the first Capital letter of its type and the defined name and value will be
pushed into hash map.
Step 2: On moving on to the next lines, and as long as the line is statement or
definition, the new variable, or object or returned variable will be checked
whether already in the hash map.
Step 2.1: If yes, then the current value will overwrite the previous value
Step 2.2: It no, then repeat step 1.
Step 3: Follow the same procedure as in step for all the definition statements
Step 4: When s predicate node is reached, then check whether the then the
variable, or object or returned variable from called function or number used in
the node is inside hash map
Step 4.1: If yes, then take out the value of them from hash map and write in the
expression of IR statement by substituting the value of them in the expression.
Step 4.2: If no, then give a name that identify the first Capital letter of its type
and the defined name and write the IR statement by substituting the name in
the place of them.
Step 5: repeat step 2 or step 4 based on whether the statement is definition or

decision node.
Step 6: After all the lines under a path is finished conversion, all the converted IR of
the statement is stored in the a vector.
Note: have used four different types of hash maps for the storage of variable, objects,
returns of the called functions, and String.
13
Input IR to Simplify is better is used for manual analysis, since it is easier to

evaluate and give clearer view to get result. Although the input IR to Simplify is
much easier to manual evaluation, there might have the wrong assignment of the
notation or conflicts of assignment of notations.
But, it is not 100% reliable since there might be the programming error during
conversion .Thus original source code and Jimple IR are still necessary as a first
step in manual analysis. Only if some IR and source code looks very lengthy and
complicated the input IR to Simplify is better to use.
14
Chapter 3 Development of Test System
CHAPTER 3 DEVELOPMENT OF TEST SYSTEM

(Master Student marks’ Calculation and Collection program)
3.1 Purpose of program
The purpose of creating this program is used in the analyzing of the detect
ability of infeasible paths by different tools, which are Simplified + Z3 and
IPathDetector 2.List of purpose is as below:
1. For testing using proposed method (IPathDectector 2) and Z3 and Simplified

2. For comparing the results from tools
Reliability of IPath detector 2 has been tested using 9 different java source
codes with different size and levels of standards of complexity and different total
number of paths involved. Some of those above mentioned program are written by
different levels of programmers and having different performance and functionalities.
So, the more number of the different source programs with different characteristics
or functions or size or level of complexity, the more it can be assured to reliability of
the performance of the IPathDetector2.
It is implemented be tested using IPathDetecor 2, Z3 and Simplified Tools and
to look out if there any difference between results after analyzed and to continue
manual analysis if there is a variation between results.
Inputs used to created test system are Predicate nodes involved codes Flag based
nodes involved codes (which will satisfy IPathDectector2 patterns) .
3.2 Program Functionalities and diagrammatic explanation

The functions of the program are as follows:
I. Input the students’ data and assessments’ marks
II. Automatic calculation of the final mark of the student of the tabulated from
different % from the assessments
III. Store the data sheet and storing in .xls extension
IV. Able to create new data sheet, open, save, save as, print, edit and delete the
data sheet
13
The following Figure 3 is figure of the main page, when the program is run
and user is allowed to create new file or open file as desired.
Figure 3: Main Window Frame of Program
User can create new file, student mark database by clicking the new button
under the File menu as shown in Figure 4 below.
Figure 4: Example of Menu and button
Once click the new icon, new data sheet page will be created as in the
diagram below. Data sheet is where the students’ data and assessment marks can
14
be keyed in. The empty data sheet will contain the columns of students’ info and
assessments marks and total mark columns as shown in Figure 5 below.
Figure 5: Plain Data sheet
When entering the student’s data, if Alphabetic letters is entered for the
student marks, the system will not accept and prompt the error message as shown in
Figure 6 below.
Figure 6: Error message on invalid input
Once all the five columns for data is keyed in , the system will do the
computation of marks based on the percentage count of each of the filled in marks
and sum the results to get the total mark for each individual student and the result
will be displayed under the ‘total’ column as shown in Figure 7 below
15
Figure 7: Display of the result of calculated total marks
After the data are filled in user and total marks of the students are computed,
then the datasheet can be saved under the user desired folder. Save dialogue box
as shown in Figure 8 below will appear once the save as button was pressed and
user can select the folder to be saved. Data sheet can be saved as Excel or txt file.
Figure 8: Save As Dialog Box for choosing URL
Next after it is saved, the message dialogue box will be shown as shown in
Figure 9 below.
16
Figure 9: Message box after the file saved successfully
For opening of the saved file, click on the open button after the new data
sheet is created and the drop down list of the files saved will appear as shown in
figure 10 below and user can choose the particular file under the folder where file is
saved before.
Figure 10: Drop down list for choosing the file
17
Constraint: before opening the saved data sheet, user has to open the empty data
sheet and try to press open so that the saved file will appear without error. The
saved file can be reopened in txt file or Excel file. The sample of the opened file in
Excel is as shown in figure 11 below.
Figure 11: Opened file in Excel
When u press the select all button, all the cells under the data sheet will be
selected. Thus this will help in deleting all the data in the file as shown in figure 12
below.
Figure 12: Selecting all the cells

18
3.3 Results analyzed by Tools
The Master Mark Calculation Program is being analyzed using IPath Detector 2
and Z3 and Simplified methods and the results are as follows:
By proposed method (IPathDetector):
Total: 99
feasible: 81
Infeasible: 18
infeasible by P1: 0
infeasible by P2: 18

By Z3+Simplify:
total path: 99
total method: 59
Total Stmt is: 975
feasible: 81
infeasible: 18

The results are same, so there is no need to do manually checking.
19
Chapter 4 Sub-system for infeasible path detection
CHAPTER 4 SUB-SYSTEM FOR INFEASIBLE PATH

DETECTION
(Manual Analysis support code retrieval program)
4.1 Purpose of the program (code retrieval program by path id)
Even though the previous system is capable of displaying the source code
and IR of tested software, the function is only possible through the selection of each
class name and not by path id.
But why do we need to locate source code and IR by path id itself is as

follows:
The results of the infeasibility and feasibility of evaluated test cases /codes are given
out by path id
For Example the evaluated result is as follows.
r0->0,r1->-1 or r0>0, r1>1 where r0: IPathDetector 2
r1: Simplify + Z3
0 means feasible
1 means infeasible
-1 means unsolvable/ unknown
Thus, after the analysis using different tools is done, the data we have is the
path id and status of each of the path id.
So, before continuing further manual evaluation or conformation of the results

of the tools, the only information the analyzer will have based on tool analysis done
is path id.
Thus, the method that will be able to retrieve relevant source code and IR
based on the analyzer selected path id is vital for relationship between tool analysis
and required manual analysis need to be done for unevaluated paths or to find the
variations between the results of the paths.
20
4.1.1 Adding new methods
The main call of the class that can perform the printing of IR statement is
done under the class named Analyzor and the methods and calls which are able to
perform the printing of the source code is amended under the Analyzor class itself.
Thus, Analyzor class is where instantiated the functioning of print of both source and
IR code of the requested unsolvable Path ID.
1 new classes are added named Printstmt, which contains the functionalities
and process to get the IR statements of and print the IR code of the unsolved path ID
requested by the user.
Whereas for the retrieving and printing the relevant source code lines of the paths of
the unsolved path ID’s requested by the user, the methods and functions are created
under the existing class named Analyzor .
Both prinstmt class and Analyzor class are created under the following URL
:ICISSootRenewed/ICISSootRenewed/IPathDetector2/infeasibleDectector
To explain the functioning of the coding:

First of all, created new objects of the class named printsmt so that the variables or
methods under than could be able to called and used under the class named
Aanalyzor.
public printstmt ps =new printstmt();
Simply activate or call the constructor without parameters, which located in the
above class using the object instances created, passing the appropriate arguments.
ps.test(path, intrapathnum);
21
4.1.2 Encapsulation (Getting and setting of variables and objects)
List of Variable declaration and object declaration before the methods and call
functions of different classes and variables of different data types and objects of
different types are being added and used for the operation of printing of both Source
Code and IR statements under the Analyzor Class.
And they are as follows:

protected SootMethod sootmethod;
String methodsignature;
String classname;
SootClass sootclass;
File javaFile;
private ClassSourceFileFinder javaFinder;
Body b;
Chain units;
Unit u;
Tag tag;
int first;
String javaFileName;
int last ;
Vector vector;
String line=null;
4.2 Retrieving and Printing IR statements of the unsolvable paths
First method named test will be called by passing path and intrapathnum
arguments.
Data type of variable path –Intrapath data type, where referential data type.
Path is the variable equal to the intrapath of the system.
Data type of variable intrapathnum is int data type, where primitive data type.
Intrapathnum is the variable equal to the current path, where the system is
running.
22
.test(path, intrapathnum);
Under this prinstmt class, the major calling of functions required for printing IR
statements are written.First of all empty vector<Integer> is created where objects of
Integer data type can be stored inside. This vector is for storing the unsolvable path
ID that will be read from the Doc file input by the user.
public static Vector<Integer> idvector = new Vector<Integer>();
Next , The below line will create the object r of the readfirst class.
readfirst r = new readfirst();
Then, under the constructor of the printstmt class which is public printstmt()
Path ID int number input inside the doc file are read and then stored into the vector
as objects.
Here before action the reading of path ID from the user input file, for effective
usage of the memory and efficient reading performance with un-repetitive reading
from the file and un-iterate writing into the vector , the codes is written in the ways
that:
And as the Boolean checking is done before the vector and read method is
performed .Thus, even though every time the new instance of printstmt is created for
some purpose, the new vector won’t be created again and again and the exiting
single vector will be recalled and used due to static constraint written before the
vector name.
And similarly, the reading of path ID from file and adding into vector won’t be
repeated again if the Boolean statement is triggered into true once the first reading
from file and creation of vector is done before.
23
Thus, because of these constraints, the inter-operation of the program is

smoother, faster and save memory usage thus makes the program run more
effectively and efficiently.
static boolean alreadyread=false;

public printstmt() {
try {
if(alreadyread==false){
idvector = r.read("/myexperiment/idFile.txt");
alreadyread=true;
}
} catch (IOException e) {
System.out.println("Exception while reding the ID::\t");}
}
Test method will then do two main functions which are:

Checking whether the current path ID that the system is running contains in
the vector obtained from unsolvable path ID list File input by the user.
if (idvector.contains(pathID)){
This function will be automatically iterated every time the proveIntraPath

Method is run and until finish the complete sets of path IDs for the tested program.
If it is equal, writeFile method under RWMethods class will be called and

performed.
RWmethods rw=new RWmethods();
rw.writefile("/myexp/statements.txt","\nbegin path "+pathID+":\n");
In detail, WriteFile method will write IR statements (stmt lines) of each path from the
beginning of the path to the end to the .txt file under the folder and file name
specified.
Note:
24
In retrieving the vector that contains the list, the user would have already input
path IDs that want to extract the java soure code into the file named idFile.txt under
the specified URL metioned in the program URL(eg:C:/myexperiment/idFile.txt)
and .So, there is a .txt file under the specified folder .
25
4.3 Retrieving and Printing source code of the unsolvable paths
Then after that back to the next following lines under the ProveIntraPath
method under Analyzor class which are:
sootmethod = path.sm;
methodsignature = sootmethod.getSignature();
classname = this.classname();
try {
javaFile =getsourcfile();
b = Global.sceneDS.methodSig_gBody.get(methodsignature);
units = b.getUnits();
if (units.size() != 0) {
/** identify the first position */
u = (Unit) units.getFirst();
tag = u.getTag("LineNumberTag");
String tagstr = tag.toString();
if (u.getTag("LineNumberTag") != null) {
first = Integer.parseInt(u.getTag("LineNumberTag")
.toString());
/** get the last position */
u = (Unit) units.getLast();
last = Integer.parseInt(u.getTag("LineNumberTag")
.toString());
javaFileName = javaFile.getAbsolutePath();
int mindex = Global.sceneDS.sootMethods.indexOf(sootmethod);
}
}
} catch (Exception e) {
e.printStackTrace();
System.exit(0);
}
vector= ps.idvector;
if(vector.contains(intrapathnum)){
javaFile=getsourcfile();
BufferedReader javareader = null;
try {
javareader = new BufferedReader(new
FileReader(javaFile));
} catch (FileNotFoundException e) {
System.out.println("ex:\t"+e);
}
int count_line=0;
line=javareader.readLine();
while(line!=null){
count_line++;
if(count_line==first){
26
write("/myexp/unsolveSRC.txt","Path
ID:\t"+intrapathnum+"\n");
}
if (count_line>= first && count_line<=last){
write("/myexp/unsolveSRC.txt",line);
}else if(count_line>last){
write("/myexp/unsolveSRC.txt","\nEnd of
Path-----------------------------------------------------------\n");
break;
}
}
}
First of all and most importantly before getting the correct statements of the
perspective paths, IR statement of the current path id that system is currently
running is retrieved and put into the variable named sootmethod.
Then followed by the method signature which is unique to each method is

retrieved .Method signature is acquired so that to prevent wrong acquisition of the
other methods with the identical name but different parameters.
Next, sequentially body of the particular method under the particular

mehtodsignature is attained. Then units where store the IR lines within the body is
attained. Then first line number within the unit is set to fist and last line number is set
to last by using transitions of tag variable and getTag("LineNumberTag")function.
(note that try and catch is used for any exception errors would have occurred from
getting the body to getting the first and last tag line number of body of the
method.)First and last line no identify the portion of source lines number to be read
from java file and write into the doc file for user review.
b = Global.sceneDS.methodSig_gBody.get(methodsignature);
units = b.geUnits();

27
.toString());

.toString());
javaFileName = javaFile.getAbsolutePath();
int mindex = Global.sceneDS.sootMethods.indexOf(sootmethod);
}
}
System.exit(0);
}
As a next, the vector where contain unsolvable path IDs, under printstmt class
is being called.
Then, check whether current path id ,intrapathnum contains within the vector.
if(vector.contains(intrapathnum))
If yes, then the source file of pathid where obtained classname involved is
acquired by calling the getsourcefile()method as follows.
try {
The detail coding of the get source file method is as follows:
public File getsourcfile()

{
javaFinder = new
ClassSourceFileFinder(Global.argumentsDS.getSrcFolderPath())
;
javaFile = this.javaFinder.getJavaFile(classname);
return javaFile = this.javaFinder.getJavaFile(classname);

}
After getting the java source file where contains the method that path forms,
here comes to the steps of reading the lines form the source file and writing into the
28
text file ,retrieving the correct java source code lines and writing them out on the .txt
file under the specified folder.

try {
javareader = new BufferedReader(new FileReader(javaFile));
}
int count_line=0;
Then, the lines in the file will be read from the beginning line to end line cause
the source file contains not only the method that path go through , but also the full
class coding .The following coding does these operations.
 Check for first line
 When first line is met, it will print the header indicating the path id
 When the reading is equal to and between the first and last line, it will call the
write function to perform the writing on the specified folder and file which are
passed as arguments “/myexp/unsolvedSRC.txt”.
while(line!=null)
{
count_line++;
if(count_line==first)
{
write("/myexp/unsolveSRC.txt","Path ID:\t"+intrapathnum+"\n");
}
if (count_line>= first && count_line<=last)
{
}
else if(count_line>last)
{
Path-----------------------------------------------------------\n");
break;
}
29
SO, this is basically how the implementation of the coding of printing the IR and
source codes of the user selected paths.
Note:
For complete coding of each of the methods and classes, please refer to
appendix A for your information. Here, I have separated the coding to explain their
performance upon their call of those calls and methods to write function of source
code and IR of the tested java program into the .txt file.
4.4 Advantages of the developed program
Now, IPathDetector2 have function capable of getting the source code and IR
of any paths of the tested program after analysis. This function was never
implemented for IPathdetector2 before and yet it is very helpful in many ways for the
analyzer in doing manual checking and also it is one of the best ways to locate the
errors in evaluation of the paths and do the review of analysis and also coding.
IT is the most reliable way to check the infeasibility in coding and it will help
analyzer to locate to the area where could the infeasibility have aroused.
Manual analysis could be done by analyzing either the simplified IR

Expression or converted IR expression. After the classification of the feasibility and
infeasibility of the unsolvable paths is done, the pattern where the cause of
infeasibility or the summary of the analysis found usage of some irregular symbols or
e-correlated or flag-based pattern of infeasibility.
Thus, to check the actual reason of the occurrence of path infeasibility , have
to manually compare and find out which kind of java source code generate the
(e.g.& symbols) in IR and Simplified IR expression .& symbol is the symbol founds
on majority of the unsolvable path id and thus comparison of source code and IR
coding is done to differentiate and assure that infeasibility is caused by actual
irregular symbols where computation can’t be done by the testing tools or testing
30
tool is incapable to detect or due to the programming error in the implemented

conversion coding from source code to IR and Simplified IR code.
4.4.1 Benefits towards IPathDetector2
The developed sub-system support IPathDetecotr2 ‘s manual analysis in the

following ways:
 Previously, the source code and analysis of the analysed paths are only able
to be viewed by selecting the correct class name on HTML frame
 The source code and IR representations are only viewable once at a time and
shown by HTML frame work and it’s not saveable in txt or word file
 Have difficulty in printing out all the source code and IR representation
 Have difficulty in differentiation of which source code and IR representation is

of which class since there is no declaration of class or path name at the
beginning of source code or IR HTML display
 Have difficulty in location which class name or which source code and IR are
meant for which path id
4.5 Recommendations for Improvement
Due to the time constraint, and focus on getting the manual analysis done
over a short time correctly, I have not done much decoration to this function to be
more visible which is immediate display of the source code and IR after the program
run in the form of HTML display.
Since , the current function written is able to successfully get the source code
and IR form of the any requested pathid of the tested java program in .txt file and
the file would be able to directly saved and print out. Thus, the anomalies would help
to do the user to complete many checking effectively and efficiently, the matter of
immediate display in HTML is like a part of not much difference in doing manual
31
analysis for analyzer and actually won’t be as useful and the current .txt file .Thus,
the function is not implemented in HTML display format.
Since there is a way to do in HTML display and if the writer would need to
make a display of source code and IR of selected paths only in future, I would like to
say the exact functions written for getting source and IR by path id could be simply
reuses without any modification. Additionally, the writer need is the functions to
convert to HTM file, and actually this conversion methods java2htmal and
convert2htmal file could be found under
ICISSootRenewed/ICISSootRenewed/IPathDetector2/src/emframe/emviewer.java2H
TML. So, by simply combing the codes of “attain the source and IR by path id
“combine together with “conver2htmal” and “java2htmal”, actually, it makes easier for
future writer in the following ways:
To display 3 main components on the single frame

1.source code,
2.IR
3.Simple Expression of IR of the requested path id s
On one HTML frame, the classes and methods that appended in the appendix
A could be easily reused in conversion to HTML form directly without even needing
to do much modification and try to display to HTML frame.
The line number of the statements would be able to printed together easily by
just printing out the retrieved line number of the source code as request upon by the
user.
32
Chapter 5 Manual Evaluation of Path Feasibility
CHAPTER 5 MANUAL EVALUATION OF PATH FEASIBILITY
5.1 Purpose of Manual Evaluation
The main objective of doing manual analysis is due to the following reasons:
I.IPathDetector2 or Simplified and Z3 are able to evaluate commonly 95% of paths

in the test case
II.There are variations between the results of the paths being evaluated by
IPathDetector2 and simplified +Z3
III.The accuracy of capability of IPathDector2 should be assured reliable before
release for public use
IV.To find out the source of variations between the results obtained using different
analysis tools
V.To find out whether the sources or variations are due to weakness of
IPathDetector2 ‘s programmed analysing methods or due to user ‘s conflict of
the coding forms or test codes writers’ human errors.
5.2 Patterns of infeasibility

In IPathDetector2, Control Flow Graph (CFG) strategy is used to analyze the
paths in the system. An infeasible path in the Control Flow Graph (CFG) cannot be
exercised by any input values. Many infeasible paths exist in high quality, in all the
different size and scale of programs.
In general, to detect the feasibility of a path is to determine the solvability of

the constraint imposed by the conditions of all the branches that the path follows. If it
is proved to be unsolvable, then the path is infeasible. However, usually human
errors exist in program coding, usually, the infeasibility of a path can be determined
by the insolvability of the partial constraint imposed by conditions of branches at very
few predicate nodes that have unique characteristics in the path.
In detail, most of the infeasible paths in real code by just two properties
regardless of the programming languages used and program complexity. Based on
33
the two properties, we have developed a method to detect infeasible paths from a
given set of paths in CFG.
However, since the IPathdetctor tool is still under construction, a semi-

automatic process that includes a careful manual evaluation of those constraints that
cannot be evaluated automatically is carried out. A path in an intra-procedural CFG
is infeasible if no input data can exercise the path regardless of the associated
execution of calling and called procedures. Paths in intra-procedural CFG and inter-
procedural CFG shall be referred as intra-path and inter-path respectively. Infeasible
path in intra-CFG and inter-CFG shall be referred as intra-infeasible path and inter-
infeasible path respectively.
Two patterns of infeasibility specified are follows:
Property 1 – Flag-Based Inhibitor:
Any path P in a CFG that passes through a flag-based predicate node N such
that through propagating backward from N along only to nodes that involve
assignment of values to variables that may influence variables in (without
considering any assertions by conditions of branches encountered), symbolic
evaluation can evaluate that Q always holds regardless of values of external
variables, is infeasible, where Q is the condition of the branch at N in P.
Flag-based predicate nodes in a CFG solely based on checking the variables

defined at and referenced by nodes in CFG. Once the flag-based predicate nodes in
a CFG are identified, the infeasibility of any path that passes through a flag-based
predicate node can be inferred by applying symbolic evaluation.
Property 2 – Pair of Shallow Conflicting Branches (e-correlated nodes)
Any path P in a CFG that passes through two e-correlated predicate nodes
N1 and N2 such that the following two conditions hold is infeasible:
34
1) The sub-path from N1 to N2 in P is definition-clear with respect to the set of

external variables that are transitively referenced at both N1 and N2.
2) Through propagating backward from N2 along P only to nodes that involve
assignment of values to variables that may influence variables in Q and the
assertion by the branch condition at N1 (without considering assertions by
conditions of other branches encountered), symbolic evaluation can evaluate
that Q always holds regardless of values of external variables, where Q is the
condition of the branch at N2 in P.
From the given condition, it implies directly that there are no input values that
can exercise P. Therefore, P is infeasible. We can identify e-correlated predicate
nodes in a CFG solely based on checking the variables defined at and referenced by
nodes in CFG. Once the e-correlated predicate nodes in a CFG are identified, from
Property 2, we can infer the infeasibility of any path that passes through two e-
corrected predicate nodes such that the sub-path between the two e-correlated
predicate nodes is definition-clear with respect to the set of external variables that
are transitivity referenced at both e-correlated predicate nodes by applying symbolic
evaluation.[13]
5.2.1 Causes of infeasibility
The properties of the predicate nodes could possibly be the source of the
infeasibilities. Thus we have defined these two patterns to be used to test the
infeasible paths in our proposed tool (IPathDetector2).
1) Property1 :Flag-based
2) Property2:E-correlated
But there could be other possible source or form of statements that is unaware
or un-discovered by either Simplified or Z3 or IPathDetecotor2.Thus, thus the
manual analysis for comparing and confirm of the variations between the results of
the paths analyzed by different tool is done with the following purpose:
1)To find out the forms of infeasibility are causing the paths infeasible
35
2)To find out those source are whether from the two patterns defined in
IPathDetector 2 or new forms
Case 1:
If infeasibilities are from the two patterns defined in IPathDetector 2, this
could be due to human error in conversion of IR to IPthDetector2 input.
Case 2:
If infeasibilities are of new form un-included in the IPathDetector 2
program, then IPathDetector 2 is still not efficient tool for software testing
and need to edit the core functionality of the tool to detect all forms of
infeasibility.
3)Finally to identify the reliability of the tool
5.2.2 Organization of Manual Analysis
The purpose is to compare how the result of analysis is achieved using different
IR forms and which is more reliable and easier and less time saving and trustworthy
and easy to understand and support visible result.
Since each path id might have 1 or 2 or more of the predicate nodes, it will be
quite troublesome for analyzer in manual analysis to use Jimple IR or Source code to
evaluate every path. Coding could be quite lengthy because sometimes the method
that is called is under different package of the different class or sometimes under the
directory of until package which is necessary to by name of the classes.
It could be quite difficult or takes longer time for analyzer to reach to the
conclusion and get the meaning of the operation of the predicate node using Jimple
IR or Souce code. Thus, most of manual analysis is done using Input IR to Simplify.
Total numbers of 106 paths are done for intrapath debug under the JCM for
manual analysis using Input IR to Simplify. Total numbers of 25 paths are done for
intrapath debug under the Jtopass for manual analysis. 4 paths out of 25 paths are
36
done manual analysis using JImple IR and 21 Paths out of 25 is done manual
analysis using Input IR to Simplify.
Using which IR is better for when and how and the advantages of using of each
of IR statements or Simple IR expression will be shown with the explanation of each
patterns under the manual analysis 1,2 and 3.Classification of manual analysis done
is as follows:
Using Input IR for Simplify:
I.Manual analysis 1:21 paths from JToPass

II.Manual analysis 2:106 paths from JCM
Using Jimple IR :
I. Manual Analysis 3:4 paths JToPass
Definition of abbreviation in equation
EQ stands for equal

NOT stands for opposite of any function followed by
V stands for variable or any String name is variable
N stands for number in float
F stands for function
O stands for Object
Results of Manual Analysis: F stands for feasible and I stands for Infeasibler1:
IPathDetector 2 , r2: Simplify + Z3, 0 means feasible , 1 means infeasible -1
means unsolvable/ unknown
V.3 Manual Analysis 1
Test System used: Jtopass_debugintra_expbased
37
IR used: Input IR to Simplify

Total of all 21 paths starting are found all feasible after the manual analysis
done. It is found that under this program there are only one to three predicate nodes
involved. Both flag-based and e-correlated patterns are involved. External variables
are involved in predicate nodes too. But yet there is not violation of value or definition
to cause the paths infeasible. Thus, all the manual analyzed paths under this
program are feasible.
Under the evaluation using Input IR to Simplify, it can be sub grouped into 3
different groups based on the number of expression lines included under each path.
1) Pattern 1
Result of Manual
Path ID Analysis
100 F
101 F
113 F
114 F
119 F
120 F
242 F
245 F
358 F
362 F
367 F
855 F
2) Pattern 2
Result of Manual
Path ID Analysis
237 F
238 F
239 F
240 F
241 F
243 F
244 F
852 F
3) Pattern 3
Result of Manual
Path ID Analysis
38
488 F
5.3.1 Path Evaluation
Pattern1: example of feasibility path id 100
#begin100: r1->0 , r2->-1
1(NOT (NOT (EQ (& V0 2L) 0L)))
#end
As simple as it looks, the analysis is also short and simple, since there is only
one line of expression involved.
Line 1: varible0 (V0) is bit-and with integer 2, which is represented in 2L and
tested whether the result is equal to 0.Since value of V0 is not defined
within the path, it is assumed as an external variable where any value or
number could be possible and thus the result of bit-and of V0 with 2 may
also be any value.
Thus, the result may be equal to zero and this expression is feasible. Thus,
path id 100 is feasible.
#begin237: r1->0 , r2->-1
1(NOT (NOT (EQ (& V0 2L) 0L)))
2(NOT (EQ F1 0))
#end
The manual analysis for this kind of path is still short and simple, since there is
only two lines of expression involved.
Line 1: varible0 (V0) is bit-and with integer 2, which is represented in 2L and
tested whether the result is equal to 0. Since value of V0 is not defined
within the path, it is assumed as an external variable where any value or
number could be possible and thus the result of bit-and of V0 with 2 may
also be any value. Thus, the result may be equal to zero and this
expression is feasible.
39
Line 2: function1 (F1) is tested to be equal to 0. So path id 100 is feasible.

Since value of F1 is not defined within the path, it is assumed as an
external variable where any value or number could be possible and thus
it could be not equal to zero. So it is feasible and this path 237 is
feasible overall.
#begin488: r1->0 , r2->1
1(NOT (NOT (EQ (& flagMask 3) 3)))
2(NOT (EQ (& flags 3) 0))
3(EQ (& flags 2) 0)
#end
Line 1: variable named flagMask is bit-and with integer 3, and tested whether
the result is equal to 3. Since value of flagMask is not defined within the
path, it is assumed as an external variable where any value or number
could be possible and thus the result of bit-and of flagMask with 3 may
also be any value. So this expression is feasible.
Line 2: variable named flags is bit-and with integer 3, and tested whether the
result is not equal to 0.Since value of flags is not defined within the path,
it is assumed as an external variable where any value or number could
be possible and thus the result of bit-and of flags with 3 may also be any
value. So this expression is feasible.
Line 3: variable named flags is bit-and with integer 2, and tested whether the
result is equal to 0. Since value of flags is not defined within the path, it is
assumed as an external variable where any value or number could be
possible and thus the result of bit-and of flags with 3 may also be any
value. Additionally, we know flags bit-and 3 are not equal to zero. But
how can we assure flags bit-and 2 is equal to 0 in contrast to line
no2.See the diagrammatic explanation for clearer view of result.
40
After the manual analysis done, there are 7 different groups of patterns of
coding a 4 out of them are major different courses of infeasibility of the paths.
Actually, the source of the infeasibility is found out to be due to majorly of infeasible
coding in e-correlated nodes. So 7different patterns of coding could be groups
according to the path id.
Possible values of flag when constant is 3
Possible values of flag when flags bit-and 3 results not equal to 0. So this
expression is feasible. And thus, this path 488 is feasible overall.
5.3.2 Summary of the Manual Analysis 1
For the rest of the other path id which has been done the manual analysis1 are
feasible although found involvement of & operator on at least one of the predicate
nodes under each of the path that have done manual analysis.
Which falls under which pattern of IR is show in the diagrams as above. Thus,
which kind of operation or symbol or calculation in source code would give this &
symbol representation in the IR predicate nodes.
V.4Manual Analysis 2
Test System used: JCM_debugintra_expbased

41
IR used: Input IR to Simplify
Manual evaluation is done for 106 paths and there are 7 patterns of IR under this
manual analysis are as follows:
1)pattern 1
Result of Manual
Path ID Analysis
938 F
940 I
941 I
943 I
947 I
2)pattern 2
Result of Manual
Path ID Analysis
948 F
1012 F
1092 F
1093 I
1094 I
1098 I
1099 F
1109 F
1112 F
1113 F
1137 I
1138 I
1144 I
1145 I
1146 I
1147 I
3)pattern 3
42
Result of Manual
Path ID Analysis
1322 I
1327 I
4)pattern 4
Path
ID Result of Manual Analysis
1461 F
1462 F
1463 F
1469 F
1470 F
1471 F
1545 I
1991 F
1993 F
1994 F
5) pattern 5
Result of Manual
Path ID Analysis
2074 I
2076 I
2077 I
2078 I
2079 I
2081 I
2082 I
2083 I
2084 I
6) pattern 6
Result of Manual
Path ID Analysis
2102 F
2103 I
43
2104 I
2105 I
2106 I
2107 F
2108 I
2109 I
2110 F
2111 I
2112 I
2113 I
2114 I
2115 F
2116 I
2117 I
2118 F
2119 I
2120 I
2121 I
2122 I
2123 F
2124 I
2125 I
7) pattern 7
Result of Manual
Path ID Analysis
2271 F
2292 F
2294 F
2295 F
2559 F
2561 F
2562 F
2685 F
2687 F
2688 F
2689 F
2729 F
44
5.4.1 Manual analysis methods
There are basically 3 methods to do manually analysis in a quick and accurate

way and they are as follows:
Method 1:
First of all, spot if there any variable or function or number or object that is
used in the predicate nodes under a path more than one time. If yes, mark the
lines they are used and check the statements written for each line agree to
another line.
Sometimes, since the requirements of the program is complicated or the

programmer might have accidentally make the infeasible statements
unintentionally. There why, when any variable or function or number or object
that is used in the predicate nodes again and again, thus most possible place of
arising of e-correlated pattern of infeasibility.
Method 2:
While looking for the usage of variables or numbers or any other item
more than once in predicate nodes, if the node coding is complex and lengthy,
look for most identical form of statement line that used the most number of
identical items more than once from the very first line to the last line under the
path.
Method 3:
Next after the first method is used, and still found not infeasibility, go
through line by line checking the tested value of the variable is feasible for the
45
original value of the variable which is flag-based pattern of infeasibility might

occur.
5.4.2 Path evaluation
Pattern1
#begin938: r1->0 , r2->-1
1(EQ N1 0)
2(EQ N3 0)
3(NOT (NOT (EQ N5 x)))
4(NOT (>= N7 F0))
5(NOT (> 0 (+ width 2)))
#end
Line no 1: Unique float Number1 is equal to zero, if yes, continue to next line
Line no 2: Line 1 is true, thus test whether Unique float Number3 is equal to
zero and move to next line
Line 3: Unique float Number5 is equal to external variable 5.Here x is external
variable and can be equal to any value. And also N5 value is not defined
under the path, so assumed as coming from outside of the path and thus
it is feasible for N5 to be equal to x.
Line 4: line no 3 is correct, thus, continue to test whether Unique Float Number7
is equal to F0.Same logic as in line 3, since both N7 and F0 valued are
not defined within the path, they both are assumed as external variable
and thus N7 (any number)not greater than or equal to F0 is feasible and
move to last line.
Line 5: test whether zeros is not greater than adding the external variable width
plus 2.This is feasible too.
46
Thus, path id 938 is feasible overall.
Pattern1: example of infeasible path id 940
#begin940: r1->0 , r2->-1
1 (EQ N1 0)
2 (EQ N3 0)
3 (NOT (NOT (EQ N5 x)))
4 (NOT (>= N7 F0))
5 (> 0 (+ width 2))
6 (> 0 width)
7 (NOT (>= x N8))
8 (NOT (< x (- E 4)))
9 (NOT (> x maxForNonExp))
10 (NOT (NOT (EQ N10 N11)))
11 (NOT (NOT (EQ N13 N11)))
12 (NOT (EQ neg 0))
#end
Variable width is tested in both line no 5 and 6.so line no 5 and 6 should
possibly be having e-correlate infeasibility.
Line no 7, 8, 9 have also used the same variable x for predicate nodes. Thus the
infeasibility might be there too.
Line 1: (EQ N1 0): Consider number1 (N1) as external value, so any number
could be possible for the value of it. Thus, testing whether number1 is
equal to 0 is feasible. So proceed to line no2.
Line 2: (EQ N3 0): Same logic applied as in line 1 and thus go to next line.
Line 3: (NOT (NOT (EQ N5 x))): Consider number5 (N5) as external value, so
any number could be possible for the value of it. Thus, testing whether
47
number5 is not equal (means equal) to x which is also an external value

is feasible. So proceed to next line.
Line 4: (NOT (>= N7 F0)): Consider number5 (N7) as external value, so any
number could be possible for the value of it. Thus, testing whether
number5 is not greater than or equal to Function0 which is also an
external value is feasible. So proceed to line no5.
Line 5: (> 0 (+ width 2)): Consider number1 (N1) as external value, so any
number could be possible for the value of it. Thus, testing whether
number1 is equal to 0 is feasible. So proceed to line no2.ariable width is
an external value, so any number could be possible for the value of it.
So, width value could be positive or zero or negative. Thus, testing
whether zero is greater than width plus 2 is feasible. So precede next
line
Line 6: (> 0 width): Variable width is an external value, so any number could be
possible for the value of it. So, width value could be positive or zero or
negative. Thus, testing whether zero is greater than width is also
feasible.
Line 7: (NOT (>= x N8)): Variable x is an external value, so any number could be
possible for the value of it. Number8 (N8) is also an external value, so
any number could be possible for the value of it too. So, x greater than
or equal to N8 is feasible and move to line 8
Line 8: (NOT (< x (- E 4))): Variable x is an external value, so any number could
be possible for the value of it. VariableE is also an external value, so any
number could be possible for the value of it too. So, x less than E minus
4 is feasible and move to line 9
Line9: (NOT (> x maxForNonExp)): Variable x is an external value, so any
number could be possible for the value of it. Variable named
maxForNonExp is also an external value, so any number could be
possible for the value of it too. So, x greater to E minus maxForNonExp
is feasible and go to next line
Line10:(NOT (NOT (EQ N10 N11))): Number10 is an external value, so any
number could be possible for the value of it but a unique float number.
Number11 is an external value, so any number could be possible for the
48
value of it but a unique float number. So, N10 is equal to N11 is

infeasible and move to line 8.
So thus line no 10 and 11 is where the infeasibility occurred due to flag-based

pattern.
Pattern2
Pattern2 example: example of feasibility path id 948
#begin948: r1->0 , r2->-1
1(EQ N1 0)
2(EQ N3 0)
4(>= N7 F0)
5(NOT (> 0 width))
#end
Line 1: unique number N1 has not predefined value under the path. So, it is
assumed as external variable, thus any value could be possible.
So testing whether N1 is equal to 0 is feasible and move to line 2.
Line 2: same logic is applied as line1, so it is feasible too.
Line 3: both N5 and x has not predefined value within the path, so both are
assumed as external variable and thus the expression is feasible too.
Line 4: same as line 1, 2, 3, here external variable N7 will be of any value .And,
the function0 F0 is also undefined, thus assumed to give any value, so
N7 greater than or equal to F0 is feasible too.
Line 5: width could be assumed as external variable and thus 0 not greater than
or width is feasible.
As went through line by line and explained above ,there are no variable or
function or Number has been used more than once in predicate nodes and clearly
49
thus there is not conflict between flag- based pattern or e-correlated pattern of the
predicate nodes under path id 948, thus path id 948 is concluded as feasible.
Pattern2 example: e-correlated infeasibility in sheet 2 path id 1093
#begin1093: r1->0 , r2->1
1 (NOT (EQ tok 2))
2 (NOT (EQ tok 3))
3 (NOT (EQ tok 1))
4 (EQ tok 4)
5 (EQ F0 0)
6 (NOT (EQ F1 0))
7 (EQ (& V3 8) 0)
8 (NOT (EQ F2 0))
9 (EQ (& V3 16) 0)
10 (NOT (EQ F3 0))
11 (NOT (EQ (& V3 16) 0))
#end
Path id 1093 is infeasible due to the infeasibility of nodes in line number7, 9 and
11.
But, let me do the analysis line by line for clearer view of the process of manual
analysis and better understanding of finding the source of infeasibility.
Here aware that line no 1 to 4 is using same variable to test predicate node again
and again, so there might be infeasibility due to e-correlated nodes in any two or
more than two of them.
50
Also in line no 7, 9 and 11, the same variable3 (V3) is used to test the predicate
node again and again, so there might be infeasibility due to e-correlated nodes
infeasibility.
So, look for that line carefully.
Line 1 :( NOT (EQ tok 2)): consider variable tok as external value, so any
number could be possible for the value of variable tok. Thus, testing
whether tok is not equal to 2 is feasible. So proceed to line no2
Line 2: (NOT (EQ tok 3)): Same logic applied as in line 1 and thus go to next line
Line 3: (NOT (EQ tok 1)): Same logic applied as in line 1 and thus go to next
line
Line 4: (EQ tok 4): Since consider variable tok as external value, so any number
could be possible for the value of variable tok. Thus, testing whether tok
is equal to 4 and since according to line 1 ,2 and 3 ,variable tok is not
equal to 1 or 2 or 3 .Hence there is not confliction of values for tok
variable, line no 4 is feasible. So proceed to line no5
Line 5 :( EQ F0 0): consider function0 as unknown function, so any number
could be possible. Thus, testing whether function0 is equal to 0 is
feasible. So proceed to next line.
Line 6 :( NOT (EQ F1 0)): consider function0 as unknown function, so any
number could be possible. Thus, testing whether function0 is not equal to
0 is feasible. So proceed to next line.
Line 7 :( EQ (& V3 8) 0): Test Variable3 bit-and constant number 8 is not equal
to 0. So hence variable3 is considered as external value, so any number
could be possible for the value of variable3 as in line 9. There is a bit-and
operation between Variable3 and 8, so if any no bit-and 8 could be any
no. Thus, testing whether the result of (0 bit-and a constant) would not
be equal to 0 is infeasible.
Line 8 :( NOT (EQ F2 0)): Same logic applied as in line 6 and thus go to next line
Line 9: (EQ (& V3 16) 0): Same logic applied as in line 7 and thus go to next line
Line no 10: (NOT (EQ F3 0)): test function3 is not equal to 0. So hence function3
is considered as unknown function, so any number could be possible for
51
the value of variable3.Thus, testing whether function3 is equal to 0 is

feasible. If true, then proceed to line no 11.
Line no 11 :( NOT (EQ (& V3 16) 0)): Test Variable3 bit-and constant number 16
is not equal to 0. So hence variable3 is considered as external value, so
any number could be possible for the value of variable3 as in line 7 and
9.There is a bit-and operation between Variable3 and 16, so if any no bit-
and 16 could be any no, yet in line no 7 and 9, it is assumed that
variable3 is equal to 0 and thus proceed toward line no 10 and 11. Thus,
testing whether the result of (0 bit-and a constant) would not be equal to
0 is infeasible.
So, here predicate node in line no 11 is infeasible due to predicate node in line
no 9 due to e-correlated pattern infeasibility.
Pattern3
Pattern 3: example of infeasibility path id 1322
In this pattern, each predicate node has multiple phases of mathematical and
relational operators. But, the same basic logic of math calculation is applied in
solving the complex mathematical form .So, the ones inside the inner most cal
brackets are solved first before going out of the cal bracket.
But, it will take longer time to go through line by line for every path and yet there
are many paths to do manual analysis for each tested project.
Thus, the method to do manual analysis is specified for the below purpose:
1.Less time consuming

2.Find the correct answer out of manual analysis accurately
Here, pattern 3 example will show how method 1 is useful in manual analysis
of the infeasibility of the predicate nodes. You can see identical cases in the path id
1093 to see how this method1 could be applicable in doing manual analysis. You
can see identical cases in path id 940 to see how this method1 could be applicable
in doing manual analysis.
52
#begin1322: r1->0 , r2->1
1(NOT (EQ V0 null))
2(NOT (> (- (- (+ left width) gap) size) V6))
3NOT (< (+ (+ (+ (+ V7 3) V8) V9) gap) (+ top height)))
4(NOT (EQ V12 null))
5(NOT (<= (+ (+ (+ V6 3) size) gap) (+ left width)))
6(NOT (<= (+ (+ (+ top V8) V9) gap) V7))
7(NOT (> labelCt 2))
8(NOT (< mul N0))
9(NOT (EQ V0 null))
10(NOT (<= (- (- (+ left width) gap) N2) V6))
11(NOT (>= labelCt 50))
12(NOT (<= x xmax))
14(NOT (> (- (- (+ left width) gap) N2) V6))
16(NOT (>= x xmin))
17(NOT (< i labelCt))
20(NOT (> (+ (+ (+ top gap) V8) V9) V7))
22(NOT (<= y ymax))
24(NOT (<= (+ (+ (+ top gap) V8) V9) V7))

53
26(>= y ymin)
27(NOT (<= (+ (* (* (- 2 (+ (* gap top) gap)) (- 2 (+ (* gap top) gap))) S56) (+ (- 2 (+ (*

gap top) gap)) (- 2 (+ (* gap top) gap)))) limit))
#end
So, if we check the above coding, we can see that variables named labelCt,
left,width, top, gap, x, I, V6,V8,V9,V7 are the variables and N2,N6 are the numbers
that has been used more than once in the predicate nodes under the same path.
Start off with any variable or Number that you would like to check. So, let me
follow the sequence of the variable that written on the program. Thus, since the
Simplified Expression of IR are lengthy and involve steps of mathematical calculation
for each of predicate node, it better to use 3 methods to scan through the
Expressions before doing analyzing line by line.
So, method 2 applied here, start from line no 1 as follows:
Line no 1 :( NOT (EQ V0 null)) the identical statement in line no 1 is used again
in line no 9, 13.There is no infeasibility found. So move to next or other
line.
Line no 2: has not been used more than once and its expression alone itself is
feasible. Identical statement as in line no 1 is used in line 4 and 19.
There is no infeasibility found. So move to other lines.
feasible. So move to next or other lines.
Line no 4: has been tested before so move to line 5.
feasible. So move to next or other lines.
54
For line 7: variable labelCt is used in line no 7, 11, 15, 17, 18, 21, 25,28and 29 in
logical operation with other external variables and constants. So,iIn line
7(NOT (> labelCt 2)) is feasible since labelCt is external variable and any
value could be possible. So labelCt could be not larger than 2 but the
rest of the expressions coming upfront would agree line 7.so line 11,
labelCt not greater than or equal to 50 is also feasible. Thus, line 11, 15,
17, 18, 21, 25,28and 29 are all feasible.
Line no 8: has not been used more than once and its expression alone itself.
For line 10 and 14 and 20 and 24: are the expression that been totally identical
to each other. But if you see in line 10, the result of left plus width minus
gap and then minus N2 is smaller than or equal to V6.but in line 14 is
testing whether ,the result of left plus width minus gap and then minus
N2 is greater than V6.So, this two predicate nodes are infeasible by e-
correlated pattern. The same logic applies to line 20 and 24.
So, this path id is infeasible due to line 10 and 14 and 20 and 24.
Pattern4
#begin1461: r1->0 , r2->-1
(EQ N1 0)
(NOT (> N3 F0))
(NOT (<= N5 F0))
#end
Line1: since there is no predefined value for Unique Number 1 within the path,
the testing of whether N1 equal to 0 is feasible.
Line 2: Same logic as line 1, there is no predefined value for result of function0
F0, the testing of whether N3 is not greater than F0 is feasible.
Line 2: Same logic as line 1, there is no predefined value for result of function0
F0, and here we do not know the exact value of both N3 and N5,the
testing of whether N5 is not less than or equal to F0 still not violate the
line no 2, so is feasible.
55
So even though F0 is used more than once under this path, the strong evidence
of e-correlated pattern of infeasible cannot be seen. It is concluded as
feasible.
Pattern4: example of infeasibility path id 1545
#begin1545: r1->0 , r2->1
1(NOT (NOT (EQ i 0)))
2(NOT (EQ V1 null))
3(NOT (NOT (EQ F0 0)))
4(NOT (EQ V1 null))
5(NOT (< i 0))
6(< i F0)
#end
For this path ‘s expression, the expressions are rather short and simple but still
found repetitive use of some variables in more than one predicate nodes. They are i,
and F0 and V1.
Variable i is used in line 1 and 5 and F0 is used in line 3 and 6 and V1 is used
in line 2 and 4. If start analyzing with i, in line 1, I is equal to 0,so in line 5 I is not less
than zero means I is greater than or equal to zero so, thus line 1 and 5 are feasible.
But in line 6 I is in logical operation with F0. Here it is tested whether i is less than
F0.
But under this path, F0 values are not external. F0 is actually defined in line 3
that F0 is equal to zero. So in above according to line 1 and 5, I is greater than or
equal to 0.Thus, testing i is less than F0 (which is equal to zero) in line 6 makes
infeasible due to line 3 and 5.
This infeasibility is the e-correlated feasibility.
Pattern5
56
#begin2074: r1->0 , r2->1
1(NOT (EQ V0 null))
2(NOT (NOT (EQ N1 0)))
6(NOT (EQ pixwidth N8))
7(NOT (EQ pixheight N8))
8(NOT (<= V4 N8))
9(NOT (> x (* pixwidth N9)))
10(NOT (>= x (* pixwidth N10)))
11(NOT (<= x (* pixwidth N9)))
12(NOT (< F0 (+ V0 V9)))
13(NOT (<= V10 N8))
14(NOT (> y (* pixheight N9)))
15(NOT (>= y (* pixheight N10)))
16(NOT (<= y (* pixheight N9)))
17(NOT (> F1 F2))
#end
In path id 2074, the expressions are not so long and complicated but you can
see there are some identical expressions from line 9, 10, and 11 and also 14, 15 and
16.
Other than those lines, there are no other predicate nodes where variables or
numbers or functions are used more than once.
57
Let start the analysis from those typical lines first and then only after finished
those lines, to other lines. If we see line no 9, the expression said that variable is not
greater the result of the variable named pixwidth and Number0 .So since both
variable x and pixwidth have not been defined under this path, they are assumed as
external variable and thus any value could be possible for them. So, N9 which is a
unique float no is multiplied with pixwidth, result could be possible of any number.
So, line 9 is feasible that x could be not greater than pixwidth * N9 is feasible.
The same logic applied to line 10 and it is also feasible. But in line 11, the
exactly same variables are used as in line 9 but the logical operator is opposite and
here is testing x is less than or equal to the result of pixwidth * N9.Sine assumed that
line 9 and 10 is feasible and moved on to line 11, how can it be feasible to say that
the current expression which the opposite expression of previously feasible is
feasible.
Thus line 11 is infeasible due to line 9 and 10 and it is an e-correlated pattern of
infeasibility.
The same form of infeasibility occurs in line 16 in contrast to line 14 and

15.Other than those paths, the rests of the expression lines will be found feasible if u
check the manual analysis using ways I have explained details in previous patterns
of example. So, path id 2074 is infeasible due to e-correlated pattern in line 11 and
16.
Pattern6
#begin2103: r1->0 , r2->1
1(NOT (EQ (& buttonSet 1) 0))
2(NOT (NOT (EQ (& V1 1) 0)))
58
4(NOT (NOT (EQ (& V1 2) 0)))
6(NOT (NOT (EQ (& V1 4) 0)))
8(NOT (NOT (EQ (& V1 8) 0)))
10(NOT (NOT (EQ (& V1 16) 0)))
12(NOT (EQ (& V1 32) 0))
14(NOT (EQ (& V1 16) 0))
16(NOT (NOT (EQ (& V1 32) 0)))
#end
Under this path, it is seen that variabl1 (V1) and variable named buttonSet is
tested with different constand numbers in each predicate node.So, although there
are a few numbers of lines of expressions, they are just typically testing the value of
variable1 and buttonSet with constant numbers one line alternately.Thus, buttonSet
in involved in odd line numbers such as 1, 3, 5 and so on and V1 is involved in even
line no 2, 4,6 and so on.
Begin analyzing with odd line no where buttonSet is tested as follows:

In line 1: it is testes whether buttonSet bit-and 1 is not equal to 0.The buttonSet
value is not been initialized within the path, so it is assumed as external
variable and could be possible of any number. So, any number bit and
with 1 could result as nay number and testing whether this result not
equal to zero is possible. So, line 1 is feasible. Similarly, line no
3,5,7,9,11,13,15 are feasible too since there is not violation between
59
predicate nodes are occurred and each of their expression agree to

each other in contrast.
So, go to even number of lines where variable is involved in predicate nodes.

In line 2: variable1 is bit-and with 1, where here value of variable 1 is also not
defined within path or before, thus , it is assumed as an external
variable and thus bit-and with 1 is equal to any number .SO, testing the
result equal to 0 is possible.
So, using the same logic as in line 2, line 4, 6,8,10, 12 are feasible too.
But obviously, on the line 14 and 16 :the expression of the relational operator is
totally opposite of line 10 and 12.Since assumed line expression in line 10 and 12
are feasible and thus continued to line 12 and 14 , the expression in line 12 and 14
should match to what is it is like 10 and 12.Since both of each are not in contrast to
each other, line 14 is infeasible in contrast to line 10 and 16 is infeasible in contrast
to line 12.
So, path id 2103 is infeasible due to e-correlated pattern too.
Pattern7
#begin2271: r1->0 , r2->-1
1(EQ N1 0)
2(NOT (EQ N3 0))
3(NOT (EQ V0 null))
4(NOT (EQ V2 null))
5(NOT (EQ (& N5 V3) V3))
#end
60
In line 1: the expression (EQ N1 0) means a unique float number1 (N1) is equal
to 1.It is feasible.
Line 2: the expression (NOT (EQ N3 0)) means a unique float number3 is not
equal to 0. It is feasible and move to next line.
Line 3: the expression (NOT (EQ V0 null)) means variable0 is not equal to null. It
is feasible and move to next line.
Line 4: the expression (NOT (EQ V2 null))means variable2 is not equal to null. It
is feasible and move to next line.
Line 5: the expression ((NOT (EQ (& N5 V3) V3)) means bit-and of N5 and V3
which are both are external variable is not equal to V3.It is feasible to.
So, it is sure that there is not flag-based pattern of infeasibility. If you review,
there is not repetitive usage of the variables or numbers under this path and thus
there is no e-correlated infeasibility. From this path onwards, the other paths having
the same pattern of expression are all feasible and thus this path is concluded as
feasible.
The rest of the paths are classified into these 7 different forms of groups as in
aboved 7 patterns. It is found that 35 paths out of all the total paths that done manual
analyses are feasible. The rest of 71 paths out of 106 paths are infeasible.
All the infeasibilities aroused are due to either of the flag-based or e-correlated
pattern of infeasibility. All the infeasibilities aroused are due to either of the flag-
based or e-correlated pattern of infeasibility
5.5 Manual Analysis 3
Test System used: Jtopass_debugintra_expbased

IR used: Jimple IR
Result of Manual
Path ID Analysis
192 I
61
194 I
195 I
196 I
5.5.1 Path Evaluation
Pattern7: example of infeasibility path id 192

begin path 192:
0: this := @this: de.susebox.jtopas.AbstractTokenizer

1: image := @parameter0: java.lang.String
2: lines = new java.util.LinkedList()
3: index = 0
4: start = 0
5: goto [?= (branch)]
6: if index < image.<java.lang.String: int length()>() goto (branch)
7: if start < index goto lines.<java.util.LinkedList: boolean
add(java.lang.Object)>(image.<java.lang.String: java.lang.String
substring(int,int)>(start, index))
8: lines.<java.util.LinkedList: boolean
add(java.lang.Object)>(image.<java.lang.String: java.lang.String
substring(int,int)>(start, index))
9: return (java.lang.String[]) lines.<java.util.LinkedList: java.lang.Object[]
toArray(java.lang.Object[])>(newarray (java.lang.String)[lines.<java.util.LinkedList: int
size()>()])
Line 0: Variable definition is equal to the class name of AbstractToknizer under

the de.susebox.jtopass.
Line 1: Variable image is passed as parameter and has String data type.
Line 3: defines index value as zero.
Line 4: defines start value as zero.
Line 6: if index (which is equal to zero) less than int type length of the string of
the image, go to (branch)
Line 7: since line 7 is not a branch of line 6, thus, continuing to processing of line
7 means that index (which is equal to zero) is not less than int type
length of the string of the image.Since index =0, If the index >= int type
length of the string of the image, then int type length of the String of the
image would be 0 or negative value. IR expressions in line no 7 should
agrees that index is greater than or equal to int type length of the string
of the image.
62
In line 7: the IR expression is testing whether start less than add the Substring
from String of the image into the Linked list named line as an object.
But since due to line no 6,it is concluded that int type length of the
String of image is 0 or negative value. That means there is not length in
the String of the image. How is it feasible to get the substring of the
non-exist String and put them in Linked list?
Thus line 6 and 7 are infeasible due to e-correlated pattern.
So the follow up IR representations under this node is the predicate nodes and
continual operations with relate to image and built Linked List. Thus, since node 6
and 7 are infeasible, the rest of the nodes under 7 are considerably inoperable.
Found no typical use of any of the symbols like %( Mod) , or & (bitwise and) , or |
(bitwise or).
The infeasibility occurs for each of the rest of the path id under Manual analysis
3 is also due exactly the same source of e-correlated pattern, which are flag-bases
and e-correlated patterns of predicate nodes.
5.5.3 Comparison of Manual Analysis and Tools Results
JToPass:
Result of Manual
Path ID IPathdetector 2 Simplifeid + Z3 Analysis
100 F U F
101 F U F
113 F U F
114 F U F
119 F U F
120 F U F
237 F U F
238 F U F
239 F U F
240 F U F
241 F U F
242 F U F
243 F U F
63
244 F U F
245 F U F
358 F U F
362 F U F
367 F U F
488 F U F
852 F U F
855 F U F
JCM:
Result of Manual
938 F U F
940 F U I
941 F U I
943 F U I
947 F U I
948 F U F
1012 F I F
1092 F I F
1093 F I I
1094 F I I
1098 F I I
1099 F I F
1109 F I F
1112 F I F
1113 F I F
1137 F I I
1138 F I I
1144 F I I
1145 F I I
1146 F I I
1147 F I I
1322 F I I
1327 F I I
1461 F U F
1462 F U F
1463 F U F
1469 F U F
Result of Manual
1470 F U F
64
1471 F U F
1545 F U I
1991 F U F
1993 F U F
1994 F U F
2074 F I I
2076 F I I
2077 F I I
2078 F I I
2079 F I I
2081 F I I
2082 F I I
2083 F I I
2084 F I I
2102 F I F
2103 F I I
2104 F I I
2105 F I I
2106 F I I
2107 F I F
2108 F I I
2109 F I I
2110 F I F
2111 F I I
2112 F I I
2113 F I I
2114 F I I
2115 F I F
Result of Manual
2116 F I I
2117 F I I
2118 F I F
2119 F I I
2120 F I I
2121 F I I
2122 F I I
2123 F I F
2124 F I I
2125 F I I
2271 F U F
2292 F U F
2294 F U F
2295 F U F
65
2559 F U F
2561 F U F
2562 F U F
2685 F I F
2687 F I F
2688 F I F
2689 F I F
2729 F I F
CHAPTER 6 CONCLUSION
The overall project comprises main works of chapter 3, 4 and 5. The

conclusions will summaries the chapter 3, 4 and 5 results and achievements.
6.1 Achievement of the Developed Test System
The developed program is completely workable for collecting student’s data

and calculating student total marks by system automatically and thus help user save
trouble to calculate percentage of each assessment marks manually again and
again.
It save time for user and give user effective and accurate calculation of the
total mark for students’ marks database. It is efficient without necessary to one by
one calculation of percentage of each assessment marks and user need to just key
in original marks and the program will do the calculation of total marks.
66
Thus, if benefits to user of the program in the following ways:

Save time
Accurate and effective calculative
Efficient to use
Easy to use
Based on Tools’ analysis for Implemented test system (Master Marks

calculation program), no variation were found in the results are same, it was not
necessary to carry further checking. The reason maybe because it is a small size
program contains smaller number of methods and paths and the code doesn’t
contains complex structure since written by a junior programmer.
6.2 Achievement of Sub-System for Infeasible Path Detection
IPathDetector2 is a tool under construction, and testing the reliability of the

tool comparing with other tools’ performance (of Simplify and Z3) .Amendments and
addition of functions are constructed as required to improve its performance and to
be able to launch as one of effective and efficient software testing tool. So, during
the revolution stage, the manually checking cannot be avoided and so must be used.
The sub-system for infeasible detection improves the efficiency of the manually
checking.
6.3 Achievement for Manual Evaluation of Path Infeasibility
The findings from the results of manual Analysis are as follow:

1) 2 patterns of predefined infeasibility: All the infeasibilities aroused are due to
either of the flag-based or e-correlated pattern of infeasibility and not due to
67
other patterns or forms of infeasibility. Thus, it is proved that the cause of

infeasibilities fall under the predefined and implemented patterns of
infeasibility used in IPathDectector2. But, the reason for either IPathDetector
2 for not detecting those infeasibilities could be the transformation error during
conversion from Soot generated IR code to the Jimple IR or Input IR for
Simplify and Z3.
2) Rare operations: %, &, |, which are not well supported by Simplify, ahough Z3
supports them. However the bit size is required by Z3. But it is hard to get the
bit size for one external variable. In another word, Z3 is treated as “not
support” these operations.
This would result as unsolvable path in Z3 because the input pattern of &
operation predicate nodes require the input the exact total number of bits of
the variables using & operator, only then bit-wise and will do the operation. It
is not possible to know and define the exact number of bits for the
complicated external variables or call functions involved in & operation for
each predicate node.
Thus, while conversion from IR to IR that process able in Z3 form, it is

configured by the programmer to directly output the path as unsolvable once & bit-
wise and operator is used with one more variables, call functions or called object
values other than the constants and numbers. And since simplifysupports only the int
data type, this would be the reason for some unsolved paths involving many
variables of different types.
3) High degree: After manually checking for several times, there are certain
cases in which the degree is larger than 1. For example:
If( x*(y+3)>5)
NOT(<= (- (- (+ left width) gap)N2) V6))
68
Above cases are causing the differences between the proposed method and
actual infeasible paths .Since Z3 also doesn’t support such cases, the result
will be “unknown”. I have asked this question on its forum, but I haven’t got
answers. Both of the above two cases are rare but they does exist.
In Conclusion, the real cause of variations in tools results and reasons for not
detecting correctly by certain tools are not due to logic error in programming and
probably due to coding encapsulation error.
6.4 Suggestions for Improvement (actions to follow up)
Z3 (exact number of bits for the complicated external variables or call functions
involved in & operation for each predicate node.)
Simplify (supports only the int data type), this would be the reason for some
unsolved paths involving many variables of different types.
I path detector 2 does not fully covering the detection of predicate nodes which
include the high degree calculation and unusual symbols usage. Thus, the
improvements of the IPathdetector 2 would be achieved by inserting the function
what capable of detections of the above symptoms occurrence .Other than that,
there is no logical error found on detection of 2 patterns of infeasibility on predicates
nodes. Only conflicts occurred, when predicate nodes involve the unusual symbols
and high degree calculation
69
REFERENCES
[1]“SOOT. A Java bytecode optimization framework”,

http://www.sable.mcgill.ca/soot/
[2] “SOOT Reference Guide” ,http://www.brics.dk/SootGuide/sootsurvivorsguide.pdf
[3]“Eclipse Download”, http://www.eclipse.org/downloads/
[4] “Java Download” ,http://java.sun.com/javase/downloads/index.jsp
[5]Christopher J. F. Pickett, “Workshop on Program Analysis for Software Tools and

Engineering”, Association for Computing Machinery, New York, NY, USA2007
[6]Waston,A., “Error Detection with Basis Path Testing,”McCabe & Assocates

Outlook, Winter 1995-1996
70
[7]Barthélémy Dagenais,” Partial Program Analysis & Structural Patterns for Concern

Traceability in Evolving Software”,22nd IEEE/ACM International Conference on
Automated Software Engineering, September 2007
[8]Arni Einarsson and Janus Dam Nielsen, BRICS,” A Survivor’s Guide toJava
Program Analysis with Soot” , Department of Computer Science, University of
Aarhus, Denmark, Version 1.1,July 2008
[9]Kuan ,T, Hui, L., “Extracting Cause-Effect from Code to Aid Software Testing”,
Working Paper,2007
[10]Ankush Varma, Shuvra S. Bhattacharyya, “Java-through-C Compilation: An

Enabling Technology for Java in Embedded Systems”, IEEE Computer
Society Washington, DC, USA, 2004
[11] Laurie Hendren, Patrick Lam, Jennifer Lhotak, Ondrej Lhotak, , and Feng Qian.
Soot, a tool for analyzing and transforming java bytecode.
[12] Waston A., Error Detection with Basis Path Testing,” McCabe & Associates
Outlook, Winter 1995-1996
[13] Hee Beng Kuan Tan, Minh Ngoc Ngo, Hongyu Zhang, and Lwin Khin Sha,”
Detecting Infeasible Paths from Their Properties in Real Code”, School of Electrical
and Electronic Engineering, Nanyang Technological University
[14] Goldberg, A., Wang, T.C. and Zimmerman, D., “Applications of feasible path
analysis to program testing”. In proceeding of the 1994 International Symposium on
Software Testing and Analysis (ISSTA), 17-19 Aug. Seattle,
WA, USA, 1994
[15] Korel, B, “Automated Software Test Data Generation,IEEE Transactions on
Software Engineering”,1990
[16]Jeff Friesen ,”Beginning Java SE6 Platform from Novice to

Professional”,Newyrok, USA, 2006
71
[17] Frank M.Carrano Janet J. Prichard,”Data Abstraction and Problem Solving with
Java, Walls and Mirrors”,First Edition,Univrsity of Rhode Island, 2001
[18] Zhu, H., Hall, P.A.V. and May, J.H.R. 1997. Software unit test coverage and
adequacy. ACM Computing Surveys, 29 (4). 366-427.
[19] McCabe, T.J. Structured testing: A software testingmethodology using the

cyclomatic complexity metric. NIST Special Publication, Nat. Bur. Stand.,
Washington, DC,USA. 1982.
[20] Kaner,C. Bach, J. and Pettichord, B., “Lessons Learned in Software Testing”,
John Wiley & Sons, 2002.
[21]Liu Jianfeng, “Empirical study of Integrated White-box and black-box integration

testing”
72
Appendix 1: Master Student Mark Calculation Program with GUI
APPENDIX 1: Master Student Mark Calculation Program

with GUI
A1.1 Package of GUI
A1.1.1 MasterStudentDatabase.java
/*
* MasterStudentDtabase.java
*
* Created on September 11, 2009, 3:26 PM
*/
package PackageGUI;
/**
*
* @author WINXP
*/
public class MasterStudentDatabase extends javax.swing.JFrame {
int SheetCount = 0;
String Status = "";
boolean AfterSaving = false;
PackageUtil.Table_Sheet sTable = new PackageUtil.Table_Sheet();
/** Creates new form MasterStudentDtabase */
public MasterStudentDatabase() {
initComponents();
}
/** This method is called from within the constructor to

* initialize the form.
* WARNING: Do NOT modify this code. The content of this method is
* always regenerated by the Form Editor.
*/
@SuppressWarnings("unchecked")
// <editor-fold defaultstate="collapsed" desc="Generated
Code">//GEN-BEGIN:initComponents
private void initComponents() {
jMenuBar2 = new javax.swing.JMenuBar();

jMenu3 = new javax.swing.JMenu();
pnContainer = new javax.swing.JPanel();
jMenuBar1 = new javax.swing.JMenuBar();
mnuNew = new javax.swing.JMenu();
jSeparator1 = new javax.swing.JSeparator();
jMenuItem1 = new javax.swing.JMenuItem();
mnuOpen = new javax.swing.JMenuItem();
mnuSave = new javax.swing.JMenuItem();
mnuSaveAs = new javax.swing.JMenuItem();
A-1

mnuPrint = new javax.swing.JMenuItem();
mnuClose = new javax.swing.JMenuItem();
mnuExit = new javax.swing.JMenuItem();
mnuAddRow = new javax.swing.JMenuItem();
mnuDeleteRow = new javax.swing.JMenuItem();
mnuSelectAll = new javax.swing.JMenuItem();
jMenu3.setText("File");
jMenuBar2.add(jMenu3);
jMenu4.setText("Edit");
setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);
setTitle("Master Student Database");
pnContainer.setAutoscrolls(true);
javax.swing.GroupLayout pnContainerLayout = new

javax.swing.GroupLayout(pnContainer);
pnContainer.setLayout(pnContainerLayout);
pnContainerLayout.setHorizontalGroup(
pnContainerLayout.createParallelGroup(javax.swing.GroupLayout.Alignment
.LEADING)
.addGap(0, 942, Short.MAX_VALUE)
);
pnContainerLayout.setVerticalGroup(
pnContainerLayout.createParallelGroup(javax.swing.GroupLayout.Alignment
.LEADING)
.addGap(0, 545, Short.MAX_VALUE)
);
mnuNew.setText("File");
mnuNew.addActionListener(new java.awt.event.ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent evt)
{
mnuNewActionPerformed(evt);
}
});
mnuNew.add(jSeparator1);
jMenuItem1.setAccelerator(javax.swing.KeyStroke.getKeyStroke(java.awt.e
vent.KeyEvent.VK_N, java.awt.event.InputEvent.CTRL_MASK));
jMenuItem1.setIcon(new
javax.swing.ImageIcon(getClass().getResource("/PackageGUI/Blank.png")))
; // NOI18N
jMenuItem1.setText("New");
jMenuItem1.addActionListener(new
java.awt.event.ActionListener() {
A-2

{
jMenuItem1ActionPerformed(evt);
}
});
mnuNew.add(jMenuItem1);
mnuOpen.setAccelerator(javax.swing.KeyStroke.getKeyStroke(java.awt.even
t.KeyEvent.VK_O, java.awt.event.InputEvent.CTRL_MASK));
mnuOpen.setIcon(new
javax.swing.ImageIcon(getClass().getResource("/PackageGUI/Open.png")));
// NOI18N
mnuOpen.setText("Open");
mnuOpen.addActionListener(new java.awt.event.ActionListener() {
{
mnuOpenActionPerformed(evt);
}
});
mnuNew.add(mnuOpen);
mnuSave.setAccelerator(javax.swing.KeyStroke.getKeyStroke(java.awt.even
t.KeyEvent.VK_S, java.awt.event.InputEvent.CTRL_MASK));
mnuSave.setIcon(new
javax.swing.ImageIcon(getClass().getResource("/PackageGUI/Save.png")));
// NOI18N
mnuSave.setText("Save");
mnuSave.setEnabled(false);
mnuSave.addActionListener(new java.awt.event.ActionListener() {
{
mnuSaveActionPerformed(evt);
}
});
mnuNew.add(mnuSave);
mnuSaveAs.setAccelerator(javax.swing.KeyStroke.getKeyStroke(java.awt.ev
ent.KeyEvent.VK_S, java.awt.event.InputEvent.SHIFT_MASK |
java.awt.event.InputEvent.CTRL_MASK));
mnuSaveAs.setIcon(new
javax.swing.ImageIcon(getClass().getResource("/PackageGUI/Save
As.png"))); // NOI18N
mnuSaveAs.setText("Save As");
mnuSaveAs.setEnabled(false);
mnuSaveAs.addActionListener(new java.awt.event.ActionListener()
{
{
mnuSaveAsActionPerformed(evt);
}
});
mnuNew.add(mnuSaveAs);
A-3
mnuPrint.setAccelerator(javax.swing.KeyStroke.getKeyStroke(java.awt.eve
nt.KeyEvent.VK_P, java.awt.event.InputEvent.CTRL_MASK));
mnuPrint.setIcon(new
javax.swing.ImageIcon(getClass().getResource("/PackageGUI/Print.png")))
; // NOI18N
mnuPrint.setText("Print");
mnuPrint.setEnabled(false);
mnuPrint.addActionListener(new java.awt.event.ActionListener()
{
{
mnuPrintActionPerformed(evt);
}
});
mnuNew.add(mnuPrint);
mnuClose.setAccelerator(javax.swing.KeyStroke.getKeyStroke(java.awt.eve
nt.KeyEvent.VK_X, java.awt.event.InputEvent.CTRL_MASK));
mnuClose.setIcon(new
javax.swing.ImageIcon(getClass().getResource("/PackageGUI/Close.png")))
; // NOI18N
mnuClose.setText("Close");
mnuClose.setEnabled(false);
mnuClose.addActionListener(new java.awt.event.ActionListener()
{
{
mnuCloseActionPerformed(evt);
}
});
mnuNew.add(mnuClose);
mnuExit.setAccelerator(javax.swing.KeyStroke.getKeyStroke(java.awt.even
t.KeyEvent.VK_F4, java.awt.event.InputEvent.ALT_MASK));
mnuExit.setIcon(new
javax.swing.ImageIcon(getClass().getResource("/PackageGUI/Exit.png")));
// NOI18N
mnuExit.setText("Exit");
mnuExit.addActionListener(new java.awt.event.ActionListener() {
{
mnuExitActionPerformed(evt);
}
});
mnuNew.add(mnuExit);
jMenuBar1.add(mnuNew);
jMenu2.setText("Edit");
mnuAddRow.setAccelerator(javax.swing.KeyStroke.getKeyStroke(java.awt.ev
ent.KeyEvent.VK_R, java.awt.event.InputEvent.ALT_MASK));

A-4
mnuAddRow.setIcon(new
javax.swing.ImageIcon(getClass().getResource("/PackageGUI/AddRow.png"))
); // NOI18N
mnuAddRow.setText("Add New Row");
mnuAddRow.setEnabled(false);
mnuAddRow.addActionListener(new java.awt.event.ActionListener()
{
{
mnuAddRowActionPerformed(evt);
}
});
jMenu2.add(mnuAddRow);
mnuDeleteRow.setAccelerator(javax.swing.KeyStroke.getKeyStroke(java.awt
.event.KeyEvent.VK_D, java.awt.event.InputEvent.ALT_MASK));
mnuDeleteRow.setIcon(new
javax.swing.ImageIcon(getClass().getResource("/PackageGUI/Delete
Row.png"))); // NOI18N
mnuDeleteRow.setText("Delete Row");
mnuDeleteRow.setEnabled(false);
mnuDeleteRow.addActionListener(new
{
mnuDeleteRowActionPerformed(evt);
}
});
jMenu2.add(mnuDeleteRow);
jMenu5.setText("View");
mnuSelectAll.setAccelerator(javax.swing.KeyStroke.getKeyStroke(java.awt
.event.KeyEvent.VK_A, java.awt.event.InputEvent.CTRL_MASK));
mnuSelectAll.setIcon(new
javax.swing.ImageIcon(getClass().getResource("/PackageGUI/Select
All.png"))); // NOI18N
mnuSelectAll.setText("Select All");
mnuSelectAll.setEnabled(false);
mnuSelectAll.addActionListener(new
{
mnuSelectAllActionPerformed(evt);
}
});
jMenu5.add(mnuSelectAll);
setJMenuBar(jMenuBar1);
javax.swing.GroupLayout layout = new

javax.swing.GroupLayout(getContentPane());
A-5
getContentPane().setLayout(layout);
layout.setHorizontalGroup(
layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
.addComponent(pnContainer,
javax.swing.GroupLayout.DEFAULT_SIZE,
javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE)
);
layout.setVerticalGroup(
layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING)
.addComponent(pnContainer,
javax.swing.GroupLayout.Alignment.TRAILING,
javax.swing.GroupLayout.DEFAULT_SIZE,
javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE)
);
setBounds(30, 30, 950, 600);

}// </editor-fold>//GEN-END:initComponents
private void mnuNewActionPerformed(java.awt.event.ActionEvent evt)

{//GEN-FIRST:event_mnuNewActionPerformed
}//GEN-LAST:event_mnuNewActionPerformed
private void mnuOpenActionPerformed(java.awt.event.ActionEvent evt)

{//GEN-FIRST:event_mnuOpenActionPerformed
String SheetName;
SheetName = sTable.Open();
if(SheetCount == 0)
{
sTable.setBounds(0,0,945, 450);
sTable.setTitle(SheetName);
sTable.setVisible(true);
sTable.setResizable(true);
pnContainer.add(sTable);
mnuClose.setEnabled(true);
}
}//GEN-LAST:event_mnuOpenActionPerformed
private void jMenuItem1ActionPerformed(java.awt.event.ActionEvent evt)

{//GEN-FIRST:event_jMenuItem1ActionPerformed
SheetCount ++;
if(SheetCount < 2)
{
sTable = new PackageUtil.Table_Sheet();
sTable.setBounds(0,0,945, 450);
sTable.setTitle("Untitle Sheet");
sTable.setVisible(true);
sTable.setResizable(true);
pnContainer.add(sTable);
mnuClose.setEnabled(true);
}
mnuDeleteRow.setEnabled(true);
mnuAddRow.setEnabled(true);
mnuSelectAll.setEnabled(true);
mnuSave.setEnabled(true);
A-6
mnuSaveAs.setEnabled(true);
mnuPrint.setEnabled(true);
}//GEN-LAST:event_jMenuItem1ActionPerformed
private void mnuCloseActionPerformed(java.awt.event.ActionEvent evt)

{//GEN-FIRST:event_mnuCloseActionPerformed
int responseType;
responseType = javax.swing.JOptionPane.showConfirmDialog(null,
"Would You Like To Save Student Marks Information.",
"Saving Confirmation",1);
if(responseType==0)
{
if(AfterSaving == true)
{
sTable.DirectSaving();
}
else
{
sTable.Save();
}
}
else if(responseType==1)
{
SheetCount = 0;
sTable.dispose();
mnuClose.setEnabled(false);
mnuDeleteRow.setEnabled(false);
mnuAddRow.setEnabled(false);
mnuSelectAll.setEnabled(false);
mnuSave.setEnabled(false);
mnuSaveAs.setEnabled(false);
mnuPrint.setEnabled(false);
}
}//GEN-LAST:event_mnuCloseActionPerformed
private void mnuSaveActionPerformed(java.awt.event.ActionEvent evt)

{//GEN-FIRST:event_mnuSaveActionPerformed
if(AfterSaving)
{
}
else
{
String SheetName;
SheetName = sTable.Save();
sTable.setTitle(SheetName);
AfterSaving = true;
}
}//GEN-LAST:event_mnuSaveActionPerformed

A-7
private void mnuPrintActionPerformed(java.awt.event.ActionEvent evt)

{//GEN-FIRST:event_mnuPrintActionPerformed
try{
sTable.tblMain.print();
}catch(java.awt.print.PrinterException pex){
javax.swing.JOptionPane.showMessageDialog(null, pex);
}
}//GEN-LAST:event_mnuPrintActionPerformed
private void mnuSaveAsActionPerformed(java.awt.event.ActionEvent evt)

{//GEN-FIRST:event_mnuSaveAsActionPerformed
sTable.ExportToExcel();
}//GEN-LAST:event_mnuSaveAsActionPerformed
private void mnuExitActionPerformed(java.awt.event.ActionEvent evt)

{//GEN-FIRST:event_mnuExitActionPerformed
if(SheetCount > 0)
{
int responseType;
responseType =
javax.swing.JOptionPane.showConfirmDialog(null, "Would You Like To Save
Student Marks Information.",
"Saving Confirmation",1);
if(responseType==0)
{
if(AfterSaving)
{
}
else
{
sTable.Save();
}
}
else if(responseType==1)
{
System.exit(0);
}
}
}//GEN-LAST:event_mnuExitActionPerformed
private void mnuSelectAllActionPerformed(java.awt.event.ActionEvent

evt) {//GEN-FIRST:event_mnuSelectAllActionPerformed
sTable.tblMain.selectAll();
}//GEN-LAST:event_mnuSelectAllActionPerformed
private void mnuAddRowActionPerformed(java.awt.event.ActionEvent evt)

{//GEN-FIRST:event_mnuAddRowActionPerformed
sTable.spInsertRow();
}//GEN-LAST:event_mnuAddRowActionPerformed
private void mnuDeleteRowActionPerformed(java.awt.event.ActionEvent

evt) {//GEN-FIRST:event_mnuDeleteRowActionPerformed
A-8
sTable.spDeleteRow() ;
}//GEN-LAST:event_mnuDeleteRowActionPerformed
/**
* @param args the command line arguments
*/
public static void main(String args[]) {
java.awt.EventQueue.invokeLater(new Runnable() {
public void run() {
new MasterStudentDatabase().setVisible(true);
}
});
}
// Variables declaration - do not modify//GEN-BEGIN:variables

private javax.swing.JMenu jMenu2;
private javax.swing.JMenuBar jMenuBar1;
private javax.swing.JMenuBar jMenuBar2;
private javax.swing.JMenuItem jMenuItem1;
private javax.swing.JSeparator jSeparator1;
private javax.swing.JMenuItem mnuAddRow;
private javax.swing.JMenuItem mnuClose;
private javax.swing.JMenuItem mnuDeleteRow;
private javax.swing.JMenuItem mnuExit;
private javax.swing.JMenu mnuNew;
private javax.swing.JMenuItem mnuOpen;
private javax.swing.JMenuItem mnuPrint;
private javax.swing.JMenuItem mnuSave;
private javax.swing.JMenuItem mnuSaveAs;
private javax.swing.JMenuItem mnuSelectAll;
private javax.swing.JPanel pnContainer;
// End of variables declaration//GEN-END:variables

A-9
A1.2 Package of Utilities
A1.2.1Data ValuesTable.java
package PackageUtil;
import javax.swing.table.*;
import javax.swing.JOptionPane;
import javax.swing.JFileChooser;
public class DataValuesTable extends AbstractTableModel

{
JFileChooser jFileChoose = new JFileChooser();
Vector2D data = null;
protected int[] row;
String CurrentPath = "";
public DataValuesTable(int rows,int cols)
{
data = new Vector2D(rows,cols);
}
public void ReNew()

{
data = null;
}
public Vector2D getData()

{
return this.data;
}
public TableModel getTableModel()
{
return this;
}
public Object getValueAt(int r, int c)

{
return data.get(r,c);
}
public int getRowCount()

{
return data.rowCount();
}
public int getColumnCount()

{
return data.colCount();
}
public void setValueAt(Object objInput, int row, int col)

A-10
boolean valid = false;
//Checking Validation For Only Marks Columns

if (col != 0 && col != 1)
{
try
{
double d = Double.parseDouble(objInput.toString());
//Checking For Input Range

if (d<0 || d>100)
{
valid = false;
data.set(row,col,null);
JOptionPane.showMessageDialog(null,"Please,
Enter Number Between 0 and 100.",
"Invalid
Marks",JOptionPane.INFORMATION_MESSAGE);
return;
}
else
{
//Input Range is less than 0 or greater than 100
valid = true;
}
}
catch(NumberFormatException nfe)
{
//Input Data is Not Number
valid = false;
}
}
else
{
//Not Marks Columns
valid = true;
}
//if Checking Ok
if (valid == true)
{
if (col != 0 && col != 1)

{
data.set(row,col,objInput);
fireTableDataChanged();
}
else
{
//If Not Marks, No Calculations

data.set(row,col,objInput);
}
if (CheckFullyEntered(row)==true)
A-11
{
Object objTotal = new Object();
objTotal = (Object)CalculateTotal(row);
data.set(row,7,objTotal);
}
else
{
}
else
{
//if Checking Not Ok, Clear Data and Not set
data.set(row,col,null);
JOptionPane.showMessageDialog(null,"Please, Enter Only
Number For Student Marks.","Invalid
Input",JOptionPane.INFORMATION_MESSAGE);
}
}
public double CalculateTotal(int row)

{
double Total = 0;
double FirstMark = 0;
double SecondMark = 0;
double FinalMark = 0;
double Indep_Sd = 0;
double PM_Tr = 0;
//Assign Each Marks

FirstMark =
Double.parseDouble(getValueAt(row,2).toString());
SecondMark =
FinalMark =
Indep_Sd = Double.parseDouble(getValueAt(row,5).toString());
PM_Tr = Double.parseDouble(getValueAt(row,6).toString());
//Calculating Percentage of Each Marks

FirstMark = FirstMark * 0.1;
SecondMark = SecondMark * 0.1;
FinalMark = FinalMark * 0.5;
Indep_Sd = Indep_Sd * 0.2;
PM_Tr = PM_Tr * 0.1;
//Calculating Total Percentage

Total = FirstMark + SecondMark + FinalMark + Indep_Sd +
PM_Tr;
return Total;

A-12
public boolean CheckFullyEntered(int row)

{
boolean entered= false;
for(int i=0;i<=6;i++)
{
if(getValueAt(row,i) == null)
{
entered = false;
break;
}
else
{
entered = true;
}
}
return entered;
}
public boolean isCellEditable(int row, int column)

{
return (column != 7);
}
public String getFilePath()

{
return CurrentPath;
}
public void DirectSave()

{
try
{
java.io.ObjectOutputStream writer = new
java.io.ObjectOutputStream(new java.io.FileOutputStream(CurrentPath));
writer.writeObject(this.data);
writer.close();
}
catch (java.io.IOException e)
{
JOptionPane.showMessageDialog(null,"Error Occurs While
Saving Student Marks Information.",
"Failed To Save",JOptionPane.ERROR_MESSAGE);
}
}
public String save()
{
String filename = "";
String SheetName = "";
if(jFileChoose.showSaveDialog(null) ==
JFileChooser.APPROVE_OPTION)
{
try
{
SheetName =
jFileChoose.getSelectedFile().getName().toString();
A-13
filename =
jFileChoose.getSelectedFile().getCanonicalFile().getCanonicalPath() +
".srl";
CurrentPath =
".srl";
java.io.ObjectOutputStream writer = new
java.io.ObjectOutputStream(new java.io.FileOutputStream(filename));
writer.writeObject(this.data);
writer.close();
JOptionPane.showMessageDialog(null,"Student Marks
Information Successfully Saved.",
"Successfully
Saved",JOptionPane.INFORMATION_MESSAGE);
}
catch (java.io.IOException e)
{
JOptionPane.showMessageDialog(null,"Error Occurs
While Saving Student Marks Information.",
"Failed To Save",JOptionPane.ERROR_MESSAGE);
}
return SheetName;
public String open()

{
String SheetName = "";
Object obj;
if(jFileChoose.showOpenDialog(null) ==
JFileChooser.APPROVE_OPTION)
{
if(jFileChoose.getSelectedFile().getName().toLowerCase().endsWith(".srl
") )
{
try
{
java.io.ObjectInputStream reader = new
java.io.ObjectInputStream(
new
java.io.FileInputStream(jFileChoose.getSelectedFile().getCanonicalPath(
)));
SheetName =
jFileChoose.getSelectedFile().getName().toString();
obj = (Object)reader.readObject();
this.data = (Vector2D)obj;
}
catch(java.io.IOException ex )
{
A-14
JOptionPane.showMessageDialog(null,"Error
Occurs While Opening Student Marks Information.",
"Failed To
Open",JOptionPane.ERROR_MESSAGE);
}
catch(ClassNotFoundException ex )
{
JOptionPane.showMessageDialog(null,"Error
Occurs While Opening Student Marks Information.",
"Failed To
Open",JOptionPane.ERROR_MESSAGE);
}
}
}
return SheetName;
}
public javax.swing.JTable reInitTable(javax.swing.JTable

objTable)
{
DataValuesTable tv = new
DataValuesTable(this.data.rowCount(),8);
objTable =new javax.swing.JTable(tv);
return objTable;
}
public void PrepareForDisplay()

{
for(int j=0; j<=this.data.rowCount()-1;j++)
{
for(int i = 0; i<=this.data.colCount()-1;i++)
{
Object obj = new Object();
obj = data.get(j,i);
if(obj==null)
{
data.set(j,i,null);
}
else
{
data.set(j,i,obj);
}
}
}
}

A-15
A1.2.2 RowHeader.java
import java.awt.*;
import javax.swing.*;
class RowHeader extends JList

{
public RowHeader(JTable table)

{
super();
String[] liste = new String[table.getRowCount()];
for (int i=0; i<table.getRowCount(); i++)

{
liste[i] = Integer.toString(i+1);
}
this.setListData(liste);
this.setFixedCellWidth(25);
this.setFixedCellHeight(table.getRowHeight());
this.setCellRenderer(new RowHeaderRenderer(table));
}
}
class RowHeaderRenderer extends JLabel implements ListCellRenderer

{
public RowHeaderRenderer(JTable table)

{
JTableHeader header = table.getTableHeader();
setOpaque(true);
setBorder(UIManager.getBorder("TableHeader.cellBorder"));
setHorizontalAlignment(CENTER);
setForeground(header.getForeground());
setBackground(header.getBackground());
setFont(header.getFont());
}
public Component getListCellRendererComponent( JList list,

Object value,int index,boolean isSelected,boolean cellHasFocus)
{
if(value == null) setText("");

A-16
A1.2.3 Table_Sheet.java
import java.awt.*;
import javax.swing.*;
import javax.swing.JTable;
import java.io.*;
public class Table_Sheet extends JInternalFrame

{
public JTable tblMain;
JScrollPane jspContainer;
DataValuesTable tv;
public Table_Sheet()
{
Container pane = getContentPane();
pane.setLayout(new BorderLayout());
tv = new DataValuesTable(15,8);
tblMain = new JTable(tv);
initTable();
packColumns(tblMain,0);
jspContainer = new JScrollPane(tblMain);

initScrollPane();
tblMain.setAutoCreateRowSorter(true);
pane.add(jspContainer, BorderLayout.CENTER);
public void initTable()

{
tblMain.setAutoResizeMode(JTable.AUTO_RESIZE_SUBSEQUENT_COLUMNS);
tblMain.setColumnSelectionAllowed(true);
tblMain.setRowSelectionAllowed(true);
tblMain.getColumnModel().getColumn(0).setHeaderValue("Matric
Number");
tblMain.getColumnModel().getColumn(1).setHeaderValue("Project/Student
Name");
tblMain.getColumnModel().getColumn(2).setHeaderValue("1st
Asessment (10%)");
tblMain.getColumnModel().getColumn(3).setHeaderValue("2nd
Asessment (10%)");
tblMain.getColumnModel().getColumn(4).setHeaderValue("Final
Assessment (50%)");
tblMain.getColumnModel().getColumn(5).setHeaderValue("Indep Sd
(20%)");

A-17
tblMain.getColumnModel().getColumn(6).setHeaderValue("PM Tr
(10%)");
tblMain.getColumnModel().getColumn(7).setHeaderValue("Total");
tblMain.getColumnModel().setColumnSelectionAllowed(false);
packColumns(tblMain,0);
}
public void initScrollPane()

{
jspContainer.setVerticalScrollBarPolicy(JScrollPane.VERTICAL_SCROLLBAR_ALWA
YS);
jspContainer.setHorizontalScrollBarPolicy(JScrollPane.HORIZONTAL_SCROLLBAR_
ALWAYS);
jspContainer.setRowHeaderView(new RowHeader(tblMain));
}
public void packColumn(JTable table, int vColIndex, int margin)

{
DefaultTableColumnModel colModel =
(DefaultTableColumnModel)table.getColumnModel();
TableColumn col = colModel.getColumn(vColIndex);
int width = 0;
TableCellRenderer renderer = col.getHeaderRenderer();

if (renderer == null)
{
renderer = table.getTableHeader().getDefaultRenderer();
}
Component comp = renderer.getTableCellRendererComponent(

table, col.getHeaderValue(), false, false, 0, 0);
width = comp.getPreferredSize().width;
for (int r=0; r<table.getRowCount(); r++)

{
renderer = table.getCellRenderer(r, vColIndex);
comp = renderer.getTableCellRendererComponent(
table, table.getValueAt(r, vColIndex), false, false,
r, vColIndex);
width = Math.max(width, comp.getPreferredSize().width);
}
width += 2*margin;
col.setPreferredWidth(width);
}
public void packColumns(javax.swing.JTable table, int margin)

{
for (int c=0; c<table.getColumnCount(); c++)
{
packColumn(table, c, margin);
}
}
public void ExportToExcel()

{
A-18
JFileChooser jFileChoose = new JFileChooser();

String filename;
if(jFileChoose.showSaveDialog(null) == JFileChooser.APPROVE_OPTION)
{
try
{
filename =
".xls";
TableModel tblModel = tblMain.getModel();
FileWriter objWriter = new FileWriter(filename);
for(int i=0; i < tblMain.getColumnModel().getColumnCount();

i++)
{
objWriter.write(tblMain.getColumnModel()
.getColumn(i).getHeaderValue().toString() + "\t");
}
objWriter.write("\n");
for(int i=0; i< tblModel.getRowCount(); i++)

{
for(int j=0; j < tblModel.getColumnCount(); j++)
{
if (tblModel.getValueAt(i,j) == null)
{
objWriter.write("" + "\t");
}
else
{
objWriter.write(tblModel.getValueAt(i,j).toString()+"\t");
}
}
objWriter.write("\n");
}
objWriter.close();
JOptionPane.showMessageDialog(null,"Student Marks
Information Successfully Saved to Excel File.",
"Successfully Saved",JOptionPane.INFORMATION_MESSAGE);
}
catch(FileNotFoundException fnf)
{
JOptionPane.showMessageDialog(null,"Excel File Cannont
Create. Failed To Save.",
"File Cannot Create",JOptionPane.INFORMATION_MESSAGE);
}
catch(IOException ioe)
{
JOptionPane.showMessageDialog(null,"Error Occur While
Saving Excel File.",
"Output Error",JOptionPane.ERROR_MESSAGE);
}
}
}
A-19
public void spInsertRow()

{
if(tblMain.getSelectedRow()!= -1)
{
tv.getData().insertRow(tblMain.getSelectedRow());
initTable();
initScrollPane();
}
}
public void spDeleteRow()

{
if(tblMain.getSelectedRow()!= -1)
{
tv.getData().deleteRow(tblMain.getSelectedRow());
initTable();
initScrollPane();
}
}
public void ReNewing()
{
tv.ReNew();
}
public void DirectSaving()
{
tv.DirectSave();
}
public String Save()

{
return tv.save();
}
public String Open()

{
return tv.open();
}

A-20
A 1.2.4 Vector2D.java
import java.util.*;
public class Vector2D implements java.io.Serializable

{
private Vector data=null;
public Vector2D(int rows,int cols)

{
int i=0;
int j=0;
Vector temp=null;
data=new Vector();
for (i=0;i<rows;i++)
{
temp = new Vector();
for (j=0;j<cols;j++)
{
temp.add(null);
}
data.add(temp);
}
}
public Object get(int row, int col)

{
try
{
return (((Vector)(data.get(row))).get(col));
}
catch (Exception e)
{
return null;
}
}
public void set(int row, int col, Object value)

{
((Vector)(data.get(row))).set(col,value);
}
public int colCount()

{
return ((Vector)(data.get(0))).size();
}

A-21
public int rowCount()

{
return data.size();
}
public void insertCol(int index)

{
for (int i=0; i< rowCount(); i++)
{
((Vector) data.get(i)).add(index,null);
}
}
public void insertRow(int index)

{
Vector temp= new Vector();
for (int i=0; i<colCount(); i++)
{
temp.add(null);
}
data.add(index,temp);
}
public void deleteRow(int index)

{
data.remove(index);
}
public void deleteCol(int index)

{
for (int i=0; i<rowCount(); i++)
{
((Vector)data.get(i)).remove(index);
}
}
}

A-22
Appendix 2: Attaining of Java Source & Intermediate Representation (IR)
APPENDIX 2: Attaining of Java Source & Intermediate

Representation (IR)
A2.1 Main class for calling source and IR getting functions
A2.1.1 Analyzor.java
package emframe.codeanalyzor;
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.File;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.FileWriter;
import java.io.IOException;
import java.io.PrintStream;
import java.util.HashMap;
import java.util.Set;
import java.util.Stack;
import java.util.Iterator;
import java.util.Vector;
import javax.swing.UIManager;
import soot.Body;
import soot.SootClass;
import soot.SootMethod;
import soot.Unit;
import soot.Value;
import soot.jimple.BinopExpr;
import soot.jimple.IfStmt;
import soot.jimple.InvokeStmt;
import soot.jimple.Stmt;
import soot.jimple.internal.AbstractDefinitionStmt;
import soot.tagkit.Tag;
import soot.util.Chain;
import emframe.Global;
import emframe.infeasibleDetector.IPGlobal;
import emframe.infeasibleDetector.dataTypes.AbstractData;
import emframe.infeasibleDetector.dataTypes.Data_Container;
import emframe.infeasibleDetector.dataTypes.Data_Number_NormalType;
import emframe.infeasibleDetector.dataTypes.Data_Number_SystemType;
import emframe.infeasibleDetector.dataTypes.Data_OtherTypes;
import emframe.infeasibleDetector.dataTypes.Data_Path;
import emframe.infeasibleDetector.dataTypes.Data_Simplify;
import emframe.infeasibleDetector.dataTypes.Data_String;
A-23
import emframe.infeasibleDetector.dataTypes.ValueTree;
import emframe.pathgen.IntraPath;
import emframe.pathgen.getsrcmethods;
import emframe.pathgen.hashstore;
import emframe.theoremProver.ProverSimplify;
import emframe.theoremProver.ProverZ3;
import emframe.utils.ClassSourceFileFinder;
import escjava.sortedProver.simplify.ProverError;
import escjava.sortedProver.simplify.SimplifyProcess;
/**
* Prover using Simplify in ESC/JAVA2
*
* @author DING SUN please import the following jar files into project: 1.
* javafe2.0.5b.jar 2. bcel-5.2.jar 3. escspecs.jar 4. esctools.jar
*/
public class Analyzor {
public Stack<Data_Path> DataSection = null;
String name = "";
// public HashMap<String, Data_Number_NormalType>

BinaryVariables_NormalType
// = null;
// public HashMap<String, Data_String> StringVariables = null;
// public HashMap<String, Data_Number_SystemType>
BinaryVariables_SystemType
// = null;
// public HashMap<String, Data_Container> Containers = null;
public Data_Path DP = null;
public HashMap<String, Data_Number_NormalType> BinaryVariables_NormalType
= new HashMap<String, Data_Number_NormalType>();
public HashMap<String, Data_String> StringVariables = new HashMap<String,
Data_String>();
public HashMap<String, Data_Number_SystemType> BinaryVariables_SystemType
= new HashMap<String, Data_Number_SystemType>();
public HashMap<String, Data_Container> Containers = new HashMap<String,
Data_Container>();
public HashMap<String, Data_OtherTypes> OtherObjects = new HashMap<String,
Data_OtherTypes>();
public HashMap<String, String> Alias = new HashMap<String, String>();
public HashMap<String, Integer> ContainerFunction = new HashMap<String,

Integer>();
public Vector<String> SimplifyEXPs = new Vector<String>();

public Vector<String> Z3Exps = new Vector<String>();
public HashMap<String, String> Z3Variables = new HashMap<String, String>();
public HashMap<String, String> tempIF = new HashMap<String, String>();
public SootMethod method = null;
public IntraPath cur_path = null;
A-24
public FileHandler fh = new FileHandler("c:\\Z3_intra.txt");
int cur_stmt_index = 0;
int curNID = 0;
Set s;
public Stack<String> SubpathName = new Stack<String>();
// static final int pathtype=1; // 1: inter path; 0: intra path
public int count = 0;
public static int intrapathnum = 0;

public static int infeasible = 0;
public static int feasible = 0;
public static int unknown = 0;
public static int extracount = 0;
public static int jumptimes = 0;
public HashMap<String, String> Parameters = new HashMap<String, String>();
public ProverSimplify Simplify = new ProverSimplify();
public ProverZ3 Z3 = new ProverZ3();

public hashstore hsp= new hashstore();
// public IntraPath intp=new IntraPath();
public getsrcmethods srcm;
protected SootMethod sootmethod;

String methodsignature;
String classname;
SootClass sootclass;
File javaFile;
private ClassSourceFileFinder javaFinder;
Body b;
Chain units;
Unit u;
Tag tag;
int first;
String javaFileName;
int last ;
Vector vector;
String line=null;
public Set set;
public Analyzor() {
public void SetMethod(SootMethod m) {

method = m;
}
public void Refresh() {

DP = new Data_Path();// new stack
BinaryVariables_NormalType.clear();// = new HashMap<String,
// Data_Number_NormalType>();
A-25
StringVariables.clear();// = new HashMap<String, Data_String>();

BinaryVariables_SystemType.clear();// = new HashMap<String,
// Data_Number_SystemType>();
Containers.clear();// = new HashMap<String, Data_Container>();
OtherObjects.clear();
Alias.clear();// = new HashMap<String, String>();
ContainerFunction.clear();// = new HashMap<String, Integer>();
SimplifyEXPs.clear();// = new Vector<String>();

Z3Exps.clear();// = new Vector<String>();
Z3Variables.clear();// = new HashMap<String, String>();
tempIF.clear();// = new HashMap<String, String>();
protected void GetEcorrealted(IfStmt ifstmt, int index) {

// tempIF
BinopExpr cond = (BinopExpr) ifstmt.getCondition();
Value op1 = cond.getOp1();

Value op2 = cond.getOp2();
if (tempIF.containsKey(op1.toString())) {
String pairs = tempIF.get(op1.toString());
pairs += "/n" + index + "--" + cond.toString();
tempIF.put(op1.toString(), pairs);
} else {
tempIF.put(op1.toString(), cond.toString());
}
public int ProveIntraPath(IntraPath path, int pathID) throws IOException {

ps.test(path, intrapathnum);
//hsp.setpathid(intrapathnum);//= new hashstore(intrapathnum);
//set=hsp.getset(path.sm);
//srcm =new getsrcmethods(set);
try {
b = Global.sceneDS.methodSig_gBody.get(methodsignature);//
assumed
// b.
// b.getMethod().g
// Java
units = b.getUnits();
A-26

.toString());// take first line and convert to
// string

.toString());
javaFileName = javaFile.getAbsolutePath();//
abstractpath
// ,
// default
// current
// user
// diectory
// ,user.
// dir
int mindex =
Global.sceneDS.sootMethods.indexOf(sootmethod);// get
// index
// of
// methods//
}
}
System.exit(0);
}
if(vector.contains(intrapathnum)){
javaFile=getsourcfile();
try {
javareader = new BufferedReader(new FileReader(javaFile));
}
int count_line=0;
A-27
while(line!=null){
count_line++;
if(count_line==first){
write("/myexp/unsolveSRC.txt","Path
ID:\t"+intrapathnum+"\n");
}
if (count_line>= first && count_line<=last){
}else if(count_line>last){
Path-----------------------------------------------------------\n");
break;
}
}
intrapathnum++;
// System.out.println("method.getSignature() is"+method.getSignature()
// );
// hashstore
//************* this.calljavfile(this.sm,pathid);
int result = 0;
Stmt stmt = null;
Data_Container DC = new Data_Container();
cur_path = path;
Refresh();// new Data_path,new stack
// if(check(intrapathnum)==true){
// writepath(path);
// }
System.out.println("--------Begin--path:");
AbstractData.Refresh();// for runtime, function call, interger variable
// such as SID,VID,FID to zero
int ifnum = 0;
int flag_curpath = -1;
//Michelle part
// srcm= new getbody(b);
// this.set=hsp.passsetofmap();
//s=hashstore.passsetofmap(intrapathnum);
for (int i = 0; i < path.size(); i++) {

// rt.test(path,intrapathnum);
if (intrapathnum == 91 && i == 3) {
A-28
System.out.println("Intra path id is" + intrapathnum

+ " , stmt id is:" + i);
}
stmt = path.get(i);
cur_stmt_index = i;
count++;
if (stmt instanceof AbstractDefinitionStmt) {
AbstractDefinitionStmt def = (AbstractDefinitionStmt) stmt;
try {
UpdateDefinition(def);// handling the assignments
}
}
if (stmt instanceof InvokeStmt) {
InvokeStmt js = (InvokeStmt) stmt;
boolean regcognizable = DC.Simulate_ContainerFunction(js
.getInvokeExpr().toString(), this);
}
if (stmt instanceof IfStmt) {
ifnum++;
IfStmt ifstmt = (IfStmt) stmt;
GetEcorrealted(ifstmt, ifnum);
boolean branch = false;
Stmt next = (Stmt) path.get(i + 1);
String target = ifstmt.getTarget().toString();

// System.out.println("current if is" + i + " , "
// + ifstmt.toString());
// System.out.println("next branch is" + next.toString());
// System.out.println("target branch is" + target.toString());
if (!next.toString().equals(target.toString())) {
branch = false;
} else {
branch = true;
}
// System.out.println("We at " + branch + " branch");
if (ifstmt.getCondition() instanceof BinopExpr) {
BinopExpr cond = (BinopExpr) ifstmt.getCondition();
try {
boolean feasible = false;
String SimplifyEXP = Data_Simplify

.Analysis_PredicateOperator(con
d, branch, this);
if (!SimplifyEXP.equals("unknown")) {
if (branch == true) {
SimplifyEXPs.add(SimplifyEXP);
} else {
SimplifyEXPs.add("(NOT " +
SimplifyEXP + ")");
}
} else {
A-29
SimplifyEXPs.add(SimplifyEXP);
// flag_curpath = -1;// -1:undefined
// break;
}
// System.out.println("The original if
is"+ifstmt.toString());
// System.out.println("The simplifyEXP
is"+SimplifyEXP);
// System.out.println("The result is"+feasible);
jumptimes++;
flag_curpath = -1;
System.out
.println("We cannot prove this at
this predicate:");
// System.out.println(ifstmt.toString());
break;
}
} else {
// System.out.println("Not BinopExpr:
"+ifstmt.getCondition());
}
}
}
flag_curpath = ProvePath();// 0:feasible ; 1:infeasible ;-1:unsolvable

System.out.println("--------End--path:");
if (ifnum == 0) {
result = 0;
} else {
result = flag_curpath;
}
switch (result) {
case 0:
feasible++;
break;
case 1:
infeasible++;
break;
case -1:
unknown++;
WriteToFile(intrapathnum);
break;
}
/*
* Iterator i = tempIF.entrySet().iterator(); while (i.hasNext()) {
* Object name = i.next(); String pairs = tempIF.get(name).toString();
* System.out.println(name.toString()+": "+pairs); }
*/
if (intrapathnum > 909) {
A-30
System.out.println("*******************************************");
System.out.println("currentpathID:" + intrapathnum);
System.out.println("*******************************************");
return result;
}
public void WriteToFile(int pathID) {
// String begin = "(benchmark tst :extrafuns (";
String variables = "";
if (Z3Exps.size() == 0) {
return;
} else {
fh.WriteLine("#begin" + pathID + ":");
for (Iterator iter = Z3Variables.keySet().iterator(); iter
.hasNext();) {
Object key = iter.next();
Object val = Z3Variables.get(key);
variables += "(" + key.toString() + " " + val.toString() + ")";
}
// variables += ")";
fh.WriteLine(variables);
for (int i = 0; i < Z3Exps.size(); i++) {
String exp = Z3Exps.get(i);
fh.WriteLine(" :formula " + exp); // entireEXP +=
}
fh.WriteLine("#end");
}
fh.Flush();
}
/*
* public void WriteToFile(int pathID) { extracount++;
* System.out.println(extracount + ", " + fh.count + " ," + fh.count1 +
* " , " + unknown); String result = "(benchmark tst "; String variables =
* " :extrafuns ("; String entireEXP = ""; if (Z3Exps.size() == 0) {
* jumptimes++; System.out.println("jump out times" + jumptimes); return; }
* else { entireEXP = ""; for (int i = 0; i < Z3Exps.size(); i++) { String
* exp = Z3Exps.get(i); entireEXP += " :formula" + exp; } }
*
* for (Iterator iter = Z3Variables.keySet().iterator(); iter.hasNext();) {
*
* Object key = iter.next();
*
* Object val = Z3Variables.get(key); variables += "(" + key.toString() +
* " " + val.toString() + ")";
*
* } variables += ")"; result += variables + entireEXP + ")"; // char * //
* f1=
* "(benchmark tst :extrafuns ((x Real) (y Real) (z Int) (dasda Real)) :formula (and (=
(- (* x 2) 1) 0.0)) "
* ; fh.WriteLine("#" + pathID + ":");
*
A-31
* // if(!result.contains("instanceof")){ fh.WriteLine(result); // }else{ //

* System.out.println("not support: "+result); // } //
* fh.WriteLine(result,unknown);
*
* fh.Flush(); }
*/
public void UpdateDefinition(AbstractDefinitionStmt defstmt)

throws Exception {
Value left = defstmt.getLeftOp();
// Value right= defstmt.getRightOp();
String typename = left.getType().toString();
Data_Container DC = new Data_Container();
if (left.getType().toString().contains("[")) { // array
} else if (left.getType().toString().contains("String")) { // String

Data_String.UpdateDefinition(defstmt, this);
} else if (left.getType().toString().contains("int")
|| left.getType().toString().contains("double")
|| left.getType().toString().contains("long")
|| left.getType().toString().contains("byte")
|| left.getType().toString().contains("float")
|| left.getType().toString().contains("short")
|| left.getType().toString().contains("char")
|| left.getType().toString().contains("boolean")) {
// UpdateDef_NormalNum(defstmt);
Data_Number_NormalType.UpdateDefinition(defstmt, this);
} else if (left.getType().toString().contains("Integer")
|| left.getType().toString().contains("Double")
|| left.getType().toString().contains("Long")
|| left.getType().toString().contains("Byte")
|| left.getType().toString().contains("Float")
|| left.getType().toString().contains("Short")) {
Data_Number_SystemType.UpdateDefinition(defstmt, this);
} else if (left.getType().toString().contains("Vector")
|| left.getType().toString().contains("HashMap")
|| left.getType().toString().contains("Hashtable")
|| left.getType().toString().contains("ArrayList")
|| left.getType().toString().contains("LinkedList")
|| left.getType().toString().contains("TreeSet")
|| left.getType().toString().contains("Stack")) {
DC.UpdateDefinition(defstmt, this);
} else {
Data_OtherTypes.UpdateDefinition(defstmt, this);
}
}
public boolean isLocal(AbstractDefinitionStmt defstmt) {

Value left = defstmt.getLeftOp();
Value right = defstmt.getRightOp();
boolean flag = true;
A-32
if (// IPGlobal.influenceDDA.doesInfluenceesContainFuncCall(defstmt,
// cur_path.getSm())
IPGlobal.influenceDDA.doesInfluenceesContainFieldRefs(defstmt, cur_path
.getSm())
|| IPGlobal.influenceDDA.doesInfluenceesContainParameters(
defstmt, cur_path.getSm())) {
flag = false;
}
return flag;
}
public void updateStatitics(String functionname) {
String name = functionname.substring(functionname.indexOf("<"),

functionname.lastIndexOf(">"));
if (ContainerFunction.containsKey(name)) {
Integer num = Integer.valueOf(ContainerFunction.get(name));
num++;
ContainerFunction.put(name, num);
// System.out.println(name.toString() + " , " + num);
} else {
ContainerFunction.put(name, new Integer(1));
}
}
public void collectStatitics() {

Iterator i = ContainerFunction.entrySet().iterator();
while (i.hasNext()) {
Object name = i.next();
Integer num = Integer.valueOf(ContainerFunction.get(name));
// System.out.println(name.toString()+" , "+num);
}
}
public String ShowValue_Simplify(AbstractData ad) {

String valueStr = ShowValue_Simplify(ad.value, ad);
return valueStr;
}
public String classname() {

String className;
sootclass = sootmethod.getDeclaringClass();
return className = sootclass.getName();
}
public File getsourcfile() {
javaFinder = new
ClassSourceFileFinder(Global.argumentsDS.getSrcFolderPath());
javaFile = this.javaFinder.getJavaFile(classname);// extract javafile first so
that can know the
// first and last line no in javafile
return javaFile = this.javaFinder.getJavaFile(classname);
}
public void write(String inputfile,String line) throws IOException{
//BufferedWriter out;
BufferedWriter out = new BufferedWriter(new FileWriter(inputfile,true));
A-33
try {
// for(int k=ft;k<=lt;k++){
out.write(line+"\n");//*******src code at line no k

out.flush();//it will be flused with all in value
// }
}catch (FileNotFoundException e) {//if no file created by user for
writing stmt, the system will create automatically
File file=new File(inputfile);
file.createNewFile();
write(inputfile,line);
}catch(IOException e){
System.out.println("IO Exception is: "+e);
}catch(Exception e){
System.out.println("Exception is:"+e);
}
}
public String ShowValue_Simplify(ValueTree vt, AbstractData ad) {

String ValueStr = "";
if (vt.isLeaf()) {
ValueStr = vt.currentNode;
if (vt.currentNode.contains(".")) {
if (Alias.containsKey(vt.currentNode + "")) {
ValueStr = Alias.get(vt.currentNode + "");
} else {
ValueStr = "N" + ad.NID;
ad.NID++;
Alias.put(vt.currentNode + "", ValueStr);
}
}
} else {
String leftStr = ShowValue_Simplify(vt.leftSub, ad);
String rightStr = ShowValue_Simplify(vt.rightSub, ad);
if (rightStr.equals("0") && vt.op.equals("/")

|| leftStr.equals("Invalid") || rightStr.equals("Invalid")) {
ValueStr = "Invalid";
} else if (vt.op.equals("/")) {// set op from '/' to '*' and using a
// temp variable to stand for the
// reverse form of the rightStr
String aliasname = "";
try {
Double r = Double.valueOf(rightStr);
double reverse = 1.0 / r;
if (Alias.containsKey(reverse + "")) {
aliasname = Alias.get(reverse + "");
} else {
aliasname = "N" + ad.NID;
A-34
ad.NID++;
Alias.put(reverse + "", aliasname);
}
if (Alias.containsKey("1/" + rightStr)) {
aliasname = Alias.get("1/" + rightStr);
} else {
aliasname = "S" + ad.SID;
ad.SID++;
Alias.put("1/" + rightStr, aliasname);
}
}
vt.op = "*";
rightStr = aliasname;
}
if (vt.op.equals("==")) {
ValueStr += "(EQ " + leftStr + " " + rightStr + ")";
} else if (vt.op.equals("!=")) {
ValueStr += "(NOT (EQ " + leftStr + " " + rightStr + "))";
} else {
ValueStr += "(" + vt.op + " " + leftStr + " " + rightStr + ")";
}
}
return ValueStr;
}
public String ShowValue_Z3(AbstractData ad) {

String valueStr = ShowValue_Z3(ad.value, ad);
return valueStr;
}
public String ShowValue_Z3(ValueTree vt, AbstractData ad) {

String ValueStr = "";
if (vt.isLeaf()) {
ValueStr = vt.currentNode;
if (ValueStr.contains(".")) {// constant real
// do noting
} else {
try {
Integer a = Integer.valueOf(vt.currentNode); // constant
// integer
String v = vt.currentNode;
if (!Z3Variables.containsKey(v)) {
if (ad.type.contains("Integer")) {
Z3Variables.put(v, "Int");
} else {
Z3Variables.put(v, "Real");
}
}
}
}
} else {
String leftStr = ShowValue_Z3(vt.leftSub, ad);
A-35
String rightStr = ShowValue_Z3(vt.rightSub, ad);
if (rightStr.equals("0") && vt.op.equals("/")

|| leftStr.equals("Invalid") || rightStr.equals("Invalid")) {
ValueStr = "Invalid";
}
if (vt.op.equals("==")) {
ValueStr += "(= " + leftStr + " " + rightStr + ")";
} else if (vt.op.equals("!=")) {
ValueStr += "(not (= " + leftStr + " " + rightStr + "))";
} else {
ValueStr += "(" + vt.op + " " + leftStr + " " + rightStr + ")";
}
}
return ValueStr;
}
/**
*
* @return -1: undefined ; 0:feasible; 1:infeasible;
*/
public int ProvePath() {
int proveresult = -1;
boolean result = true;
boolean unknown = false;
String entireEXP = "";
if (SimplifyEXPs.size() == 0) {
return 0;
} else {
for (int i = 0; i < SimplifyEXPs.size(); i++) {
String exp = SimplifyEXPs.get(i);
if (exp.equals("unknown")) {
// result = -1;
unknown = true;
continue;
}
if (i == 0) {
entireEXP = exp;
} else {
entireEXP = "(AND " + exp + " " + entireEXP + ")";
}
}
boolean a = true;
if (entireEXP.trim().equals("")) {
a = false;
} else {
a = Simplify.Prove(entireEXP);
if (a == false) {
a = Simplify.Prove("(NOT " + entireEXP + ")");
if (a == false) {
unknown = true;
} else {
result = false;
}
} else {
A-36
result = true;
}
}
if (result == false) {
proveresult = 1;
} else {
if (unknown == true) {
proveresult = -1;
} else {
proveresult = 0;
}
}
// System.out.println("entireEXP is" + entireEXP);
return proveresult;
}
/**
* @param Exp
* =//(NOT (AND (> a 4) (< a 0)))
* @return boolean, true--> infeasible; false-->feasible
*/
/*
* TRUE : (1) (X + Y > 0) and (X ?Y < 0)
*
* (2) (2X + Y > 4) and (2X <= 1 –Y)
*
* (3) (2X ?Y = 4) and (3X ?Y = 5)
*
* (4) (2XX ?X + 1 = 0)
*/
public static void main(String[] args) {
Analyzor t = new Analyzor();
char a = 'a';
System.out.println(Integer.valueOf(a));
System.out.println(t.Simplify.Prove("(EQ prop null)"));
// t.Prove("(NOT (AND (< (+ (+ x z) f(y)) 2) (> (+ (+ x z) f(y)) 5)))");
// t.Prove("(NOT (AND (< x 3) (> x 2)))");
// t.Prove("(NOT (AND (< (+ (* a f(x))(* b f(y))) c) (> (+ (* a f(x))(* b f(y))) c)))");
// t.Prove("(NOT (AND ( > (+ (* 2 x) y) 4) (<= (* 2 x) (- 1 y))))");
// t.Prove("(NOT (AND ( EQ (- (* 2 x) y) 4) (EQ (- (* 3 x) y) 5)))");
// t.Prove("(NOT (NOT (NOT (EQ (+ (- (* (* 2 x) x) x) 1) 0))))");
// t.Prove("(NOT (NOT (EQ (- (* 2 x) 1) 0)))");
// t.Prove(" (NOT (EQ (* (* 2 x) x) -10))");
// t.Prove(" (NOT (EQ (- x 1) 0))");
// t.Prove("(NOT (NOT (EQ (/ x y) (/ (+ 2 x) y))))");
// t.Prove("(NOT (NOT (EQ (! x) 0)))");
// t.Prove("(NOT (NOT (EQ (- x 1) 0)))");
// t.SendCommand();
int b = -10;
A-37
System.out.println(Math.sqrt(b));
String a5 = "55";
int i = 2 ^ 2;
System.out.println(i);
}
// (+ (- (* (* 2 x) x) x) 1)
}
/**
* 1. Send command to simplify , how to use it ? 2. def: type var= EXP 3.
* predicate : EXP1 logicOP EXP2 4. EXP ::= var ::= constant ::= var ((op var)
* |(op constant) | (op fun()) ) 5. a hashmap : <var, value>
*
*/
A2.2 Subclass for IR code retrieval
A2.2.1 Printstmt.java
import java.util.Vector;
import javax.swing.UIManager;
import javax.swing.filechooser.FileNameExtensionFilter;
import soot.jimple.Stmt;
import emframe.pathgen.IntraPath;
public class printstmt {

readfirst r = new readfirst();
PrintStream outstream=null;
static boolean alreadyread=false;
public printstmt() {
try {
if(alreadyread==false){
idvector = r.read("/myexperiment/idFile.txt");
alreadyread=true;
}
} catch (IOException e) {
System.out.println("Exception while reding the ID::\t");}}
public Vector returnidvector(){//for source file retrieve
return this.idvector;
}
public void test(IntraPath path, int pathID) throws IOException {//pathID is
currentpath, path is the total collections of paths under path id
Stmt stmt=null;
if (idvector.contains(pathID)) {//if unsolve id list contains current path id
A-38
RWmethods rw=new RWmethods();

rw.writefile("/myexp/statements.txt","\nbegin path
"+pathID+":\n");//write lines of statements in file
for (int a = 0; a < path.size(); a++) {//write the total no of lines of
statements or paths involve under current path id
stmt = path.get(a);//get Intermediate Representation and put it
in stmt
String line=a+": "+ stmt.toString();//change stmt to string
System.out.println("unsolved path id\t"+path+"\t:");
rw.writefile("/myexp/statements.txt",line);
}
rw.writefile("/myexp/statements.txt",
"\n-----------------------------------------------------------------------");
}
}
A2.2.2 RWmethod.java
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.File;
import java.io.FileReader;
import java.io.FileWriter;
import javax.swing.filechooser.FileNameExtensionFilter;
public class RWmethods {
long unsolve;
public void writefile(String stmtFileName, String line)throws IOException{
BufferedWriter out;
try {
out = new BufferedWriter(new FileWriter(stmtFileName,true));
out.write(line+"\n");
out.flush();//it will be flused with all in value
} catch (FileNotFoundException e) {//if
no file created by user for writing stmt, the system will create automatically
A-39
File file=new File(stmtFileName);

file.createNewFile();
writefile(stmtFileName,line);
}catch(IOException e){
System.out.println("IO
Exception is: "+e);
}catch(Exception e){
System.out.println("Exception is:"+e);
}
}
}
A-40
Appendix 3: Manual Analysis Results of the paths in the tested Program
APPENDIX 3: Manual Analysis results of the paths in the

tested program
A3.1 Manual Analysis 1: JtoPass using Input IR to Simplify
Path id: 101 is feasible
#begin101: r1->0 , r2->-1
1(NOT (EQ (& V0 2L) 0L))
#end
Is grouped under Pattern 1 as in explanation above.

Please refer the pattern 1 example under manual analysis 1 to get the idea of how the
conclusion for the result of manual analysis is done.
#begin113: r1->0 , r2->-1
1(NOT (NOT (EQ (& V0 4L) 0L)))
#end

#begin114: r1->0 , r2->-1
1(NOT (EQ (& V0 4L) 0L))
#end

#begin119: r1->0 , r2->-1
1(NOT (NOT (EQ (& V0 1L) 0L)))
#end
A-41

#begin120: r1->0 , r2->-1
1(NOT (EQ (& V0 1L) 0L))
#end

#begin242: r1->0 , r2->-1
1(NOT (EQ (& V0 4L) 0L))
#end
The result of manual analysis falls under the group of the pattern 1 and refer to the example
under manual analysis 1 to get the idea of how the conclusion for the result of manual
analysis is done.
#begin245: r1->0 , r2->-1
1(NOT (EQ (& V0 1L) 0L))
#end
The result of manual analysis falls under the group of Pattern 1 as in explained above.
#begin358: r1->0 , r2->-1
1(NOT (EQ (& N1 flag) 0))
#end
The result of manual analysis falls under the group of Pattern 1 as in explanation above.
A-42
#begin362: r1->0 , r2->-1
1(NOT (EQ (& V0 flag) 0))
#end
#begin367: r1->0 , r2->-1
1(NOT (EQ (& V0 flag) flag))
#end
#begin855: r1->0 , r2->-1
1(NOT (EQ (& N1 flag) flag))
#end
#begin238: r1->0 , r2->-1
1(NOT (NOT (EQ (& V0 2L) 0L)))
2(EQ F1 0)
#end
#begin240: r1->0 , r2->-1
1(NOT (NOT (EQ (& V0 4L) 0L)))
A-43
2(NOT (EQ F1 0))
#end
#begin241: r1->0 , r2->-1
1(NOT (NOT (EQ (& V0 4L) 0L)))
2(EQ F1 0)
#end
#begin243: r1->0 , r2->-1
1(NOT (NOT (EQ (& V0 1L) 0L)))
2(NOT (EQ F1 0))
#end
#begin244: r1->0 , r2->-1
1(NOT (NOT (EQ (& V0 1L) 0L)))
2(EQ F1 0)
#end
#begin852: r1->0 , r2->-1
A-44
1(NOT (EQ N1 0))
2(NOT (EQ (& N3 flag) flag))
#end
#begin488: r1->0 , r2->1
1(NOT (NOT (EQ (& flagMask 3) 3)))
2(NOT (EQ (& flags 3) 0))
3(EQ (& flags 2) 0)
#end
A3.2 Manual Analysis 2: JCM using Input IR to Simplify

Path id: 941 is infeasible
#begin941: r1->0 , r2->-1
1(EQ N1 0)
2(EQ N3 0)
4(NOT (>= N7 F0))
5(> 0 (+ width 2))
6(> 0 width)
7(NOT (>= x N8))
8(NOT (< x (- E 4)))
9(NOT (> x maxForNonExp))
10(NOT (NOT (EQ N10 N11)))
11(NOT (NOT (EQ N13 N11)))
A-45
12(EQ neg 0)
#end
Infeasible like above mentioned Pattern 1 infeasibility explanation under manual analysis 2.
conclusion for the result is achieved.
#begin943: r1->0 , r2->-1
1(EQ N1 0)
2(EQ N3 0)
4(NOT (>= N7 F0))
5(> 0 (+ width 2))
6(> 0 width)
7(NOT (>= x N8))
8(NOT (< x (- E 4)))
10(NOT (NOT (EQ N10 N11)))
11(NOT (EQ N13 N11))
12(<= x N14)
13(NOT (EQ neg 0))
#end
Path id: 947 is Infeasible
#begin947: r1->0 , r2->-1
1(EQ N1 0)
2(EQ N3 0)
A-46
4(NOT (>= N7 F0))
5(> 0 (+ width 2))
6(> 0 width)
7(>= x N8)
8(NOT (< x (- E 4)))
10(NOT (NOT (EQ N10 N11)))
11(NOT (NOT (EQ N13 N11)))
12(NOT (EQ neg 0))
#end
Ineasible like above mentioned Pattern 1 nfeasibility explanation under manual analysis 2.
#begin1012: r1->0 , r2->1
1(NOT (NOT (EQ tok 4)))
3(<= notCt 0)
4(NOT (NOT (EQ (% notCt 2) 1)))
#end
Feasible like above mentioned Pattern 2 feasibility explanation under manual analysis 2.
#begin1092: r1->0 , r2->1
1(NOT (EQ tok 2))
2(NOT (EQ tok 3))
3(NOT (EQ tok 1))
4(EQ tok 4)
A-47
5(EQ F0 0)
6(NOT (EQ F1 0))
7(EQ (& V3 8) 0)
8(NOT (EQ F2 0))
9(NOT (EQ (& V3 16) 0))
10(NOT (EQ (& V3 64) 0))
12(NOT (NOT (EQ F3 0)))
#end
#begin1094: r1->0 , r2->1
1(NOT (EQ tok 2))
2(NOT (EQ tok 3))
3(NOT (EQ tok 1))
4(EQ tok 4)
5(EQ F0 0)
6(NOT (EQ F1 0))
7(EQ (& V3 8) 0)
8(NOT (EQ F2 0))
9(EQ (& V3 16) 0)
10(NOT (EQ F3 0))
11(EQ (& V3 16) 0)
12(NOT (EQ F4 0))
13(NOT (EQ (& V3 8) 0))
#end
A-48
Pattern of infeasibility-correlated as in explanation above

Line number where the infeasibility occurs: 7and 13.
Please refer the pattern 2 example under manual analysis 2 to know how the conclusion for
the result is achieved.
#begin1098: r1->0 , r2->1
1(NOT (EQ tok 2))
2(NOT (EQ tok 3))
3(NOT (EQ tok 1))
4(EQ tok 4)
5(EQ F0 0)
6(NOT (EQ F1 0))
7(EQ (& V3 8) 0)
8(NOT (EQ F2 0))
9(EQ (& V3 16) 0)
10(EQ F3 0)
11(NOT (EQ F4 0))
12(NOT (EQ (& V3 8) 0))
#end
Pattern of infeasibility-correlated as in explanation above

Line number where the infeasibility occurs: 7and 12
Please refer the pattern 2 example under manual analysis 2 to know of how the conclusion
for the result is achieved.
#begin1099: r1->0 , r2->1
1(NOT (EQ tok 2))
2(NOT (EQ tok 3))
A-49
3(NOT (EQ tok 1))
4(EQ tok 4)
5(EQ F0 0)
6(NOT (EQ F1 0))
7(EQ (& V3 8) 0)
8(EQ F2 0)
9(NOT (EQ F3 0))
10(NOT (EQ (& V3 16) 0))
#end
#begin1109: r1->0 , r2->1
1(NOT (EQ V0 null))
3(EQ F1 0)
4(NOT (EQ F2 0))
7(NOT (EQ F4 0))
8(NOT (NOT (EQ (& V9 8) 0)))
9(NOT (EQ F5 0))
10(NOT (EQ (& V9 16) 0))
11(EQ F3 0)
12(NOT (EQ F4 0))
13(NOT (EQ isBool 0))
#end
A-50
#begin1112: r1->0 , r2->1
1(NOT (EQ V0 null))
3(EQ F1 0)
4(NOT (EQ F2 0))
7(NOT (EQ F4 0))
8(NOT (NOT (EQ (& V9 8) 0)))
9(NOT (EQ F5 0))
10(EQ (& V9 16) 0)
11(NOT (EQ (& V9 512) 0))
12(NOT (EQ N1 0))
#end
#begin1113: r1->0 , r2->1
1(NOT (EQ V0 null))
3(EQ F1 0)
4(NOT (EQ F2 0))
7(NOT (EQ F4 0))
A-51
8(NOT (NOT (EQ (& V9 8) 0)))
9(NOT (EQ F5 0))
10(EQ (& V9 16) 0)
11(NOT (EQ (& V9 512) 0))
12(EQ N1 0)
#end
#begin1137: r1->0 , r2->1
2(NOT (NOT (EQ ch 95)))
3(NOT (NOT (EQ (& V1 128) 0)))
6(NOT (EQ (& V1 128) 0))
7(NOT (EQ N3 0))
8(NOT (EQ (& V1 256) 0))
9(NOT (> i 0))
#end
Pattern of infeasibility e-correlated as in explanation above

Line number where the infeasibility occurs: 3 and 6
#begin1138: r1->0 , r2->1
A-52
3(NOT (NOT (EQ (& V1 128) 0)))
6(NOT (EQ (& V1 128) 0))
7(NOT (EQ N3 0))
8(NOT (EQ (& V1 256) 0))
9(> i 0)
10(NOT (EQ (& V1 32) 0))
11(NOT (EQ 1 0))
#end

#begin1144: r1->0 , r2->1
3(NOT (NOT (EQ (& V1 128) 0)))
6NOT (EQ (& V1 128) 0))
7(NOT (EQ N3 0))
8(NOT (EQ (& V1 256) 0))
9(> i 0)
10(EQ (& V1 32) 0)
A-53
11(NOT (EQ N5 null))
#end

#begin1145: r1->0 , r2->1
3(NOT (NOT (EQ (& V1 128) 0)))
6(NOT (EQ (& V1 128) 0))
7(NOT (EQ N3 0))
8(EQ (& V1 256) 0)
9(NOT (< V2 F0))
10(NOT (> i 0))
#end

#begin1146: r1->0 , r2->1
A-54
3(NOT (NOT (EQ (& V1 128) 0)))
6(NOT (EQ (& V1 128) 0))
7(NOT (EQ N3 0))
8(EQ (& V1 256) 0)
9(< V2 F0)
10(NOT (NOT (EQ N1 0)))
12(NOT (EQ (& V1 128) 0))
13(NOT (EQ N3 0))
14(NOT (EQ (& V1 256) 0))
15(NOT (> i 0))
#end

#begin1147: r1->0 , r2->1
3(NOT (NOT (EQ (& V1 128) 0)))
6(NOT (EQ (& V1 128) 0))
7(EQ N3 0)
A-55
8(NOT (> i 0))
#end

#begin1327: r1->0 , r2->1
1(NOT (EQ V0 null))
2(NOT (> (- (- (+ left width) gap) size) V6))
3(NOT (< (+ (+ (+ (+ V7 3) V8) V9) gap) (+ top height)))
5(NOT (<= (+ (+ (+ V6 3) size) gap) (+ left width)))
6(NOT (<= (+ (+ (+ top V8) V9) gap) V7))
8(NOT (< mul N0))
9(NOT (EQ V0 null))
10(NOT (<= (- (- (+ left width) gap) N2) V6))
12(NOT (<= x xmax))
14(NOT (> (- (- (+ left width) gap) N2) V6))
16(NOT (>= x xmin))
A-56
20(NOT (> (+ (+ (+ top gap) V8) V9) V7))
22(<= y ymax)
23(NOT (>= (+ (* (* (- 2 (+ (* gap top) gap)) (- 2 (+ (* gap top) gap))) S53) (- (- 2 (+ (* gap
top) gap)) (- 2 (+ (* gap top) gap)))) limit))
25(NOT (<= (+ (+ (+ top gap) V8) V9) V7))
27(NOT (>= y ymin))
#end

Line number where the infeasibility occurs: 10 and 14, 12 and 16
#begin1462: r1->0 , r2->-1
1(EQ N1 0)
2(NOT (> N3 F0))
3(<= N5 F0)
#end
Please refer the pattern 4 feasibility example under manual analysis 2 to get the idea of how
the conclusion for the result is achieved.
#begin1463: r1->0 , r2->-1
1(EQ N1 0)
2(> N3 F0)
A-57
#end
#begin1469: r1->0 , r2->-1
1(EQ N1 0)
2(NOT (> N3 F0))
3(NOT (<= N5 F0))
#end
#begin1470: r1->0 , r2->-1
1(EQ N1 0)
2(NOT (> N3 F0))
3(<= N5 F0)
#end
#begin1471: r1->0 , r2->-1
1(EQ N1 0)
2(> N3 F0)
#end
A-58
#begin1991: r1->0 , r2->-1
1(NOT (EQ c null))
2(NOT (EQ N1 0))
3(NOT (EQ (& V2 V3) 0))
#end
#begin1993: r1->0 , r2->-1
1(NOT (EQ c null))
2(EQ N1 0)
3(NOT (EQ (& V2 V3) 0))
#end
#begin1994: r1->0 , r2->-1
1(EQ c null)
2(NOT (EQ N1 0))
3(NOT (EQ (& V2 V3) 0))
#end
the conclusion for the result of manual analysis is done.
#begin2076: r1->0 , r2->1
1(NOT (EQ V0 null))
A-59
8(NOT (<= V4 N8))
12(NOT (< F0 (+ V0 V9)))
13(NOT (<= V10 N8))
16(<= y (* pixheight N9))
17(NOT (> F1 F2))
#end

Please refer the pattern 5 infeasibility example under manual analysis 2 to know how the
#begin2077: r1->0 , r2->1
1(NOT (EQ V0 null))
A-60
8(NOT (<= V4 N8))
12(NOT (< F0 (+ V0 V9)))
13(NOT (<= V10 N8))
15(>= y (* pixheight N10))
17(NOT (> F1 F2))
#end

#begin2078: r1->0 , r2->1
1(NOT (EQ V0 null))
8(NOT (<= V4 N8))
A-61
12(NOT (< F0 (+ V0 V9)))
13(NOT (<= V10 N8))
14(> y (* pixheight N9))
18(NOT (> F1 F2))
#end

#begin2081: r1->0 , r2->1
1(NOT (EQ V0 null))
8(NOT (<= V4 N8))
11(<= x (* pixwidth N9))
12(NOT (< F0 (+ V0 V9)))
A-62
13(NOT (<= V10 N8))
17(NOT (> F1 F2))
#end

#begin2082: r1->0 , r2->1
1(NOT (EQ V0 null))
8(NOT (<= V4 N8))
10(>= x (* pixwidth N10))
12(NOT (< F0 (+ V0 V9)))
13(NOT (<= V10 N8))
A-63
17(NOT (> F1 F2))
#end

#begin2083: r1->0 , r2->1
1(NOT (EQ V0 null))
8(NOT (<= V4 N8))
9(> x (* pixwidth N9))
13(NOT (< F0 (+ V0 V9)))
14(NOT (<= V10 N8))
18(NOT (> F1 F2))
#end
A-64

#begin2084: r1->0 , r2->1
1(NOT (EQ V0 null))
8(<= V4 N8)
9(NOT (<= V5 N8))
13(NOT (> F0 F1))
#end

#begin2104: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
A-65
4(NOT (NOT (EQ (& V1 2) 0)))
6(NOT (NOT (EQ (& V1 4) 0)))
8(NOT (NOT (EQ (& V1 8) 0)))
10(NOT (NOT (EQ (& V1 16) 0)))
12(NOT (EQ (& V1 32) 0))
14(NOT (EQ (& V1 16) 0))
16(NOT (EQ (& V1 32) 0))
#end

#begin2105: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
4(NOT (NOT (EQ (& V1 2) 0)))
6(NOT (NOT (EQ (& V1 4) 0)))
A-66
8(NOT (NOT (EQ (& V1 8) 0)))
10(NOT (NOT (EQ (& V1 16) 0)))
12(NOT (EQ (& V1 32) 0))
14(NOT (EQ (& V1 16) 0))
15(EQ (& buttonSet 32) 0)
#end

#begin2106: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
4(NOT (NOT (EQ (& V1 2) 0)))
6(NOT (NOT (EQ (& V1 4) 0)))
8(NOT (NOT (EQ (& V1 8) 0)))
10(NOT (NOT (EQ (& V1 16) 0)))
12(NOT (EQ (& V1 32) 0))
A-67
15(NOT (NOT (EQ (& V1 32) 0)))
#end

#begin2107: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
4(NOT (NOT (EQ (& V1 2) 0)))
6(NOT (NOT (EQ (& V1 4) 0)))
8(NOT (NOT (EQ (& V1 8) 0)))
10(NOT (NOT (EQ (& V1 16) 0)))
13(NOT (NOT (EQ (& V1 16) 0)))
#end
A-68
#begin2108: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
4(NOT (NOT (EQ (& V1 2) 0)))
6(NOT (NOT (EQ (& V1 4) 0)))
8(NOT (NOT (EQ (& V1 8) 0)))
10(NOT (EQ (& V1 16) 0))
12(NOT (NOT (EQ (& V1 16) 0)))
#end

#begin2109: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
4(NOT (NOT (EQ (& V1 2) 0)))
6(NOT (NOT (EQ (& V1 4) 0)))
8(NOT (NOT (EQ (& V1 8) 0)))
A-69
11(NOT (NOT (EQ (& V1 16) 0)))
#end

#begin2110: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
4(NOT (NOT (EQ (& V1 2) 0)))
6(NOT (NOT (EQ (& V1 4) 0)))
8(NOT (EQ (& V1 8) 0))
10(NOT (NOT (EQ (& V1 4) 0)))
12(NOT (NOT (EQ (& V1 16) 0)))
14(NOT (NOT (EQ (& V1 32) 0)))
#end
A-70
#begin2111: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
4(NOT (NOT (EQ (& V1 2) 0)))
6(NOT (NOT (EQ (& V1 4) 0)))
8(NOT (EQ (& V1 8) 0))
10(NOT (EQ (& V1 4) 0))
12(NOT (NOT (EQ (& V1 8) 0)))
14(NOT (NOT (EQ (& V1 16) 0)))
16(NOT (NOT (EQ (& V1 32) 0)))
#end

#begin2112: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
A-71
4(NOT (NOT (EQ (& V1 2) 0)))
6(NOT (NOT (EQ (& V1 4) 0)))
8(NOT (EQ (& V1 8) 0))
10(NOT (EQ (& V1 4) 0))
12(NOT (EQ (& V1 8) 0))
14(NOT (NOT (EQ (& V1 16) 0)))
16(NOT (NOT (EQ (& V1 32) 0)))
#end

#begin2113: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
4(NOT (NOT (EQ (& V1 2) 0)))
6(NOT (NOT (EQ (& V1 4) 0)))
A-72
8(NOT (EQ (& V1 8) 0))
10(NOT (EQ (& V1 4) 0))
13(NOT (NOT (EQ (& V1 16) 0)))
15(NOT (NOT (EQ (& V1 32) 0)))
#end

#begin2114: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
4(NOT (NOT (EQ (& V1 2) 0)))
6(NOT (NOT (EQ (& V1 4) 0)))
8(NOT (EQ (& V1 8) 0))
11(NOT (NOT (EQ (& V1 8) 0)))
A-73
13(NOT (NOT (EQ (& V1 16) 0)))
15(NOT (NOT (EQ (& V1 32) 0)))
#end

#begin2115: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
4(NOT (NOT (EQ (& V1 2) 0)))
6(NOT (NOT (EQ (& V1 4) 0)))
9(NOT (NOT (EQ (& V1 4) 0)))
11(NOT (NOT (EQ (& V1 16) 0)))
13(NOT (NOT (EQ (& V1 32) 0)))
#end
A-74
#begin2116: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
4(NOT (NOT (EQ (& V1 2) 0)))
6(NOT (EQ (& V1 4) 0))
8(NOT (NOT (EQ (& V1 4) 0)))
10(NOT (NOT (EQ (& V1 16) 0)))
12(NOT (NOT (EQ (& V1 32) 0)))
#end

#begin2117: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
4(NOT (NOT (EQ (& V1 2) 0)))
7(NOT (NOT (EQ (& V1 4) 0)))
A-75
9(NOT (NOT (EQ (& V1 16) 0)))
11(NOT (NOT (EQ (& V1 32) 0)))
#end

#begin2118: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
4(NOT (EQ (& V1 2) 0))
6(NOT (NOT (EQ (& V1 1) 0)))
8(NOT (NOT (EQ (& V1 4) 0)))
10(NOT (NOT (EQ (& V1 8) 0)))
12(NOT (NOT (EQ (& V1 16) 0)))
14(NOT (NOT (EQ (& V1 32) 0)))
#end
A-76
#begin2119: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
4(NOT (EQ (& V1 2) 0))
6(NOT (EQ (& V1 1) 0))
8(NOT (NOT (EQ (& V1 2) 0)))
10(NOT (NOT (EQ (& V1 4) 0)))
12(NOT (NOT (EQ (& V1 8) 0)))
14(NOT (NOT (EQ (& V1 16) 0)))
16(NOT (NOT (EQ (& V1 32) 0)))
#end

#begin2120: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
A-77
4(NOT (EQ (& V1 2) 0))
6(NOT (EQ (& V1 1) 0))
8(NOT (EQ (& V1 2) 0))
10(NOT (NOT (EQ (& V1 4) 0)))
12(NOT (NOT (EQ (& V1 8) 0)))
14(NOT (NOT (EQ (& V1 16) 0)))
16(NOT (NOT (EQ (& V1 32) 0)))
#end

#begin2121: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
4(NOT (EQ (& V1 2) 0))
6(NOT (EQ (& V1 1) 0))
A-78
9(NOT (NOT (EQ (& V1 4) 0)))
11(NOT (NOT (EQ (& V1 8) 0)))
13(NOT (NOT (EQ (& V1 16) 0)))
15(NOT (NOT (EQ (& V1 32) 0)))
#end

#begin2122: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
4(NOT (EQ (& V1 2) 0))
7(NOT (NOT (EQ (& V1 2) 0)))
9(NOT (NOT (EQ (& V1 4) 0)))
11(NOT (NOT (EQ (& V1 8) 0)))
A-79
13(NOT (NOT (EQ (& V1 16) 0)))
15(NOT (NOT (EQ (& V1 32) 0)))
#end

#begin2123: r1->0 , r2->1
2(NOT (NOT (EQ (& V1 1) 0)))
5(NOT (NOT (EQ (& V1 1) 0)))
7(NOT (NOT (EQ (& V1 4) 0)))
9(NOT (NOT (EQ (& V1 8) 0)))
11(NOT (NOT (EQ (& V1 16) 0)))
13(NOT (NOT (EQ (& V1 32) 0)))
#end
A-80
#begin2124: r1->0 , r2->1
2(NOT (EQ (& V1 1) 0))
4(NOT (NOT (EQ (& V1 1) 0)))
6(NOT (NOT (EQ (& V1 4) 0)))
8(NOT (NOT (EQ (& V1 8) 0)))
10(NOT (NOT (EQ (& V1 16) 0)))
12(NOT (NOT (EQ (& V1 32) 0)))
#end

#begin2125: r1->0 , r2->1
3(NOT (NOT (EQ (& V1 1) 0)))
5(NOT (NOT (EQ (& V1 4) 0)))
7(NOT (NOT (EQ (& V1 8) 0)))
A-81
9(NOT (NOT (EQ (& V1 16) 0)))
11(NOT (NOT (EQ (& V1 32) 0)))
#end

#begin2292: r1->0 , r2->-1
1(NOT (EQ c null))
2(NOT (EQ N1 0))
3(NOT (EQ (& V2 V3) 0))
#end
#begin2294: r1->0 , r2->-1
1(NOT (EQ c null))
2(EQ N1 0)
3(NOT (EQ (& V2 V3) 0))
#end
#begin2295: r1->0 , r2->-1
A-82
1(EQ c null)
2(NOT (EQ N1 0))
3(NOT (EQ (& V2 V3) 0))
#end
#begin2559: r1->0 , r2->-1
1(NOT (EQ c null))
2(NOT (EQ N1 0))
3(NOT (EQ (& V2 V3) 0))
#end
#begin2561: r1->0 , r2->-1
1(NOT (EQ c null))
2(EQ N1 0)
3(NOT (EQ (& V2 V3) 0))
#end
#begin2562: r1->0 , r2->-1
1(EQ c null)
2(NOT (EQ N1 0))
A-83
3(NOT (EQ (& V2 V3) 0))
#end
#begin2685: r1->0 , r2->1
3(NOT (EQ 1 0))
4(NOT (NOT (EQ (& V1 8) 0)))
5(NOT (EQ 1 0))
6(NOT (EQ (& V1 16) 0))
7(EQ F0 0)
8(NOT (EQ 1 0))
9(NOT (< i N1))
#end
#begin2687: r1->0 , r2->1
2 NOT (NOT (EQ F0 0)))
3(NOT (EQ 1 0))
4(NOT (NOT (EQ (& V1 8) 0)))
5(NOT (EQ 1 0))
6(EQ (& V1 16) 0)
A-84
8(NOT (EQ (& V1 512) 0))
9(NOT (EQ V2 0))
10(NOT (EQ N3 0))
#end
#begin2688: r1->0 , r2->1
3(NOT (EQ 1 0))
4(NOT (NOT (EQ (& V1 8) 0)))
5(NOT (EQ 1 0))
6(EQ (& V1 16) 0)
8(NOT (EQ (& V1 512) 0))
9(NOT (EQ V2 0))
10(EQ N3 0)
#end
#begin2689: r1->0 , r2->1
3(NOT (EQ 1 0))
4(NOT (NOT (EQ (& V1 8) 0)))
A-85
5(NOT (EQ 1 0))
6(EQ (& V1 16) 0)
8(NOT (EQ (& V1 512) 0))
9(EQ V2 0)
#end
#begin2729: r1->0 , r2->1
3(NOT (EQ 1 0))
4(NOT (NOT (EQ (& V1 8) 0)))
5(NOT (EQ 1 0))
6(NOT (EQ (& V1 16) 0))
7(EQ F0 0)
8(NOT (EQ 1 0))
9(NOT (EQ tok 3))
#end
A3. 3 Manual Analysis 3: JCM using Jimple IR
begin path 194:

3: index = 0
A-86
4: start = 0
7: tableswitch(image.<java.lang.String: char charAt(int)>(index)) { case 10: goto
lines.<java.util.LinkedList: boolean add(java.lang.Object)>(image.<java.lang.String:
java.lang.String substring(int,int)>(start, index));
case 11: goto index = index + 1;
case 13: goto lines.<java.util.LinkedList: boolean
add(java.lang.Object)>(image.<java.lang.String: java.lang.String substring(int,int)>(start,
index));
default: goto index = index + 1; }
8: index = index + 1
index))
11: if start <= 0 goto return (java.lang.String[]) lines.<java.util.LinkedList: java.lang.Object[]
size()>()])
12: lines.<java.util.LinkedList: boolean add(java.lang.Object)>(image.<java.lang.String:
java.lang.String substring(int,int)>(start, index))
size()>()])
Pattern of infeasibility-correlated as in infeasibility explanation above under manual analyis3

Line no where the infeasibility occurs: 6 and 7

3: index = 0
4: start = 0
index));
9: if index + 1 >= image.<java.lang.String: int length()>() goto index = index + 1
10: if image.<java.lang.String: char charAt(int)>(index + 1) != 10 goto index = index + 1
12: goto [?= start = index]
A-87
13: start = index

index))
size()>()])
size()>()])


3: index = 0
4: start = 0
index));
9: if index + 1 >= image.<java.lang.String: int length()>() goto index = index + 1
10: if image.<java.lang.String: char charAt(int)>(index + 1) != 10 goto index = index + 1
12: start = index
index))
size()>()])
A-88

size()>()])

A-89
Appendix 4: User Guide
“User Guide “
For running the retrieval of source or original IR code of
Manual Analysis
Of the detected undefined paths
(To identification of feasible or infeasible)
A-90
1.0 Introduction
This user manual can be as a guide to run the analysis tool and attain the source or
IR files of the selected path ID by giving input of the IDfile.txt under the specified
folder.
The manual comprises of majorly 4 main sectors, which are as mentioned below;
First of all, his user manual comprised of installation and setting up necessary
software and IDE components: Java, and Eclipse before running the developed
analysis tool, IPathDetector 2.
Secondly, it will guide of how to construct run-configuration before testing the any
source code using the developed tool, IPathdectector2.As a third, the guide
comprises of the steps of how to run the system. Lastly, there involves the steps to
how to attain the java source code of the body of the unsolved paths and
Intermediate Representation (IR) of the unsolved paths.
So, as a conclusion, this manual will direct you to achieve the print out documents of
the unsolved paths’ IR representation statements and also their source codes in
the .txt or .doc file after complete auto run of the project. It also provides a brief
introduction of the user interface of the system. The main purpose of the project is to
develop an analysis tool which will be able to detect infeasible paths in a java
program by using SOOT API in eclipse platform. And also, additionally, to find out
which are the causes of the result of unsolved paths after the analysis completed by
developed analysis tool IPathdetector2.
1.1 Minimum Hardware and Software Requirements:
Following are the basic requirements before running the analysis tool,
IPathDetector2 in any system.
They involve of the model of Desktop or LapTop , Operation System on the pac and
also 3 types of software platform as described as follows.
1) Desktop or Lap Top Capability: 1GHz Pentium III/IV PCs
2) Operating System: Windows XP, Windows Vista

A-91
3) Software platform: it is necessary of the following 3 basic
a. Java Developers Kit & JRE 1.6.0.07

b. Eclipse ganyamede 3.4
c. SOOT 2.3
2.0 INSTALLING THE SYSTEM

Since IPathDectector2 is implemented using many of Soot Functions , to run this
analysis tool, first of all the user must know the prerequisites of soot .But, as simple
as that it is basically like running Java program cause Soot is one of the Java
Optimization framework..
Soot
Soot is free software and is licensed under the GNU lesser General Public License.
Soot can be used as a standalone or as a tool to optimize or inspect class files. Soot
created by Sable research group from McGill University .
2.1 Basic Requirements for Soot:
The minimum platform requirement to be able to apply Soot is JDK 1.5 and
Eclipse 3.3.
SO, install the following before install Soot2.3.
1. Java Developer Kit 1.6
2. Eclipse IDE
2.1.1 Java J2SE 6.0 installations:
Under this link, http://java.sun.com/javase/downloads/?intcmp=2817,you will be able

get variety of models of JDk but to specifically download the JDK6 Update 16 please
use the following steps.
 Click on this think https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-

CDS_Developer-Site/en_US/-/USD/ViewProductDetail-Start?
ProductRef=java_ee_sdk-5_07-jdk-6u16-oth-ml-JPR@CDS-CDS_Developer
and follow the on-screen instructions provided by the installer and in the end
J2SE will be installed in your pc automatically together with the installing of
JDK6 is successfully complete.
A-92
 Install the JDK to C:\Program_Files\Java\jdk-version avoiding any path that

includes a space to prevent any runtime error.
 Afterwards, create a directory, workspace aas C:\Java\workspace. The
'workspace' directory will be used for self-explanatory.
2.1.2 Setting PATH variable:
Correct path variable setting is very important, if the step is omitted the program
won’t be able to run.
 For Operating System” Microsoft Vista “click on ‘Start’ > ‘Control Panel’,
double-click ‘System’. In the System window, click on ‘Advanced System
Settings’.
 Choose ‘Advanced’ tab, click on ‘Environment Variables’. In the newly
open window, click on ‘Path under System variables’, choose ‘Edit’, then
add the following to the end of the Path string. E.g. [directory
path]\jdk1.6.0_07\the directory path will be URL of where your JDK has
been installed.
Suggest adding as C:\Program_Files\Java\jdk1.6.0_07\bin and format of
the path is as follows and add in the highlight.
Example:
Path=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\
Program Files\Common Files\Roxio Shared\DLLShared\;C:\Program
Files\Common Files\Roxio Shared\DLLShared\;C:\ProgramFiles\Common
Files\Roxio Shared\11.0\DLLShared\;C:\Program Files\Java\jdk1.6.0\bin
Provided that you installed the JDK to C:\Program Files\Java\jdk1.6.0, and

there is a subdirectory named 'bin', should be all set.
 Click OK three times and the path variable setting is finished.
Note:
o The Path is a series of directories separated by semi-colon (;), therefore make
sure to add the semi-colon at the end of the current Path value before adding the
[directory path]\ jdk1.6.0_07\bin to the Path.
o There should be only one bin directory for Java JDK in the Path.
A-93
2.1.3 Eclipse Installation:
Eclipse Classic 3.5, version of Eclipse includes the Eclipse platform, java
development tools and plug-in development environment. It can be downloaded
from http://www.eclipse.org/downloads/or the direct link is
http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/R-
3.5-200906111540/eclipse-SDK-3.5-win32.zip or can be found in the CD ([drive
letter]:/Resources/ eclipse-SDK-3.4.2-win32.zip).
 Unzip the downloaded compressed file and run eclipse.exe. Upon installation
select a workspace for the project (ex C:/Program_Files/myexperiment)
 On successful installation the following welcome screen appears,
Figure 1 - Eclipse Installation Completion View
A-94
2.2 SOOT Installation:

SOOT can be downloaded as a plug-in for eclipse. It can be easily done by
following the below steps.
 In eclipse click Help and then choose Software Updates.
Figure 2 - SOOT Installation - Software Update Selection View

 In the Software Updates window, select Available Software the tab and
then click the button Add Site. In the window that pop’s up give
http://www.sable.mcgill.ca/soot/eclipse/updates/ as the address for
downloading SOOT and then click OK.
Figure 3 - SOOT Installation - Add Site View

 In the Software Updates window, select the row named
http://www.sable.mcgill.ca/soot/eclipse/updates/. Then select SOOT and
click Install.
Figure 4 - SOOT Installation - Software Update Process View
A-95
 Finally in the Install window, press next, and then accept the license
agreement and press finish.
Figure 5 - SOOT Installation - License Agreement View

Note:
Once the installation is complete Eclipse should be restated. Once eclipse is
restarted the SOOT plug-in will be available for use.
A-96
3.0 USING THE SYSTEM
3.1 Setting Up the System
Tool, IPathDetector2 project should be included in the workspace as a java

project. The steps to put in IPathdetector2 Project in the workspace as java project
are as follows:
 Click on ‘File’ and then ‘Import’. In the Import window that pop’s up, select
‘Existing projects into workspace’ under ‘General’ and then click ‘next’.
Figure 6 – Import window for setting up the system

 Then select the Select root directory radio button, then click ‘browse’.
Browse and locate the project file in the CD ([drive letter]:/Tool/
IPathDetector). Click ‘finish’. After the project has been build rename the
project as IPathDetector2. Once the project is build there should be no
error in it. The package view of the project will be:
A-97
Figure 7 - Package View for the System

Note:
If there is error in the project , you will see red cross sign upon the folder icon and if
it is so, ask for error free CD from Project Owner.
3.2 Analysis of any java program by running IPathDetector2 project:

First of all, two requirements must be fulfilled before running and testing any java
project using the analysis tool in eclipse. The steps to be followed are:
1. Adding the java program to test into the workspace
Import the test file under ([drive letter]:/SampleTestFile/ Test) into the current
workspace and name it as Test.
2. Setting up of run configuration
To test a project a new run configuration should be created for the project.
This can be done by selecting ‘run’ from the ‘menu bar’ and then ‘Run
Configuration’. Then click on ‘java application’ and then the new launch
configuration button found on the upper left corner.
I. In the ‘Main’ tap of the window, Project is the name of the infeasible path
detector project (here IPathDetector2) and Main class is the location of the
main file in the infeasible detector (Here it is emframe.Main).
A-98
New Launch Configuration Button
Figure 8 - Run Configuration View

II. Next, under the argument tab of the window, two things to be done are as
follows:
III.
Setting Program Arguments:
Arguments to be keyed into the program arguments as below
-allow-phantom-refs
-p jb use-original-names:true
-p cg all-reachable:true
-p cg verbose:true SOOT
properties
--exclude java.*
--exclude sun.*
--process-dir
A-99
Basispaths Type of Path to

be tested ,
src Source folder
location of any
java program to
be tested
(eg src foler
where jtopass
contains)
jtopass Name of any
java program to
be tested
(eg jtopass)
C:/myexperiment/ICISSootRenewed/ICISSootRenewed Location of the
project
( eg
IpathDetector2 )
Note: cannot
have space
between names
and eclipse will
give error
Which packs are enabled when?
To know which packs are enabled when, I will explain using the two
documents using their setting and defaults.
Soot command-line:
Soot is invoked by the command line which is:
“javajavaOptions soot.Manin [sootOptions*] classname*
Command lines for Soot bytecode compiler or optimizer tool:
A-100
Soot options of command lines comprises of three categories of classes,

which are:
1) Argument classes (classes listed explicitly on the command line or

directory)
2) Application classes (classes for output file)
3) Library classes (referred classes)
Argument classes are those classes which are either listed explicitly on the
command line or found in a directory specified with the -process-dir option when you
use Soot's command lines. When you use the Soot's Eclipse plug-in, argument
classes are those which you selected before starting Soot from the Navigator popup
menu or all classes in the current project if you started Soot from the Project menu.
Application classes are classes that Soot analyzes, transforms, and turns into
output files. Library classes are classes which are directly or indirectly, referred
classes by the application classes, but they are not application classes by
themselves. Soot resolves these classes and reads .class or .jimple source files for
them, but it does not perform transformations on library classes or write output files
for them.
All argument classes can necessarily be application classes. When Soot is

not in ``application mode'', argument classes are the only application classes; other
classes referenced from the argument classes become library classes. When Soot is
in application mode, every class referenced from the argument classes, directly or
indirectly, is also an application class, unless its package name indicates that it is
part of the standard Java runtime system.
Users may define the designation of application and library classes using the
Application Mode Options.
Command line Opitons
I will break up command line options to 7 groups as shown below:
1. General options
2. Input options
3. Output options
4. Processing options
5. Input Attribute options
6. Annotation options
7. Miscellaneous options
1. General options
-v, -verbose
Provide detailed information about what Soot is doing as it runs.
A-101
2. Input Options
-process-dir dir
Add all classes found in dir to the argument classes which is analyzed and
transformed by Soot. This option can be specified more than once, to add
argument classes from multiple directories.
If subdirectories of dir contain .class or .jimple files, Soot assumes that the
subdirectory names correspond to components of the classes' package
names. If dir contains subA/subB/MyClass.class, for instance, then Soot
assumes MyClass is in package subA.subB.
-allow-phantom-refs
Allow Soot to process a class even if it cannot find all classes referenced by
that class. This may cause Soot to produce incorrect results
Definition of Processing Options:
-x pkg, -exclude pkg
Exclude the library class of the package named “pkg” from application
classes. Also allows to selectively excluding classes from application classes. If you
specify both include and exclude options, first the classes from all excluded
packages are marked as library classes, then the classes from all included packages
are marked as application classes.
A-102
4.0 Setting VM arguments:
Remember to provide VM arguments as –Xmx1500m, which describes the

amount to virtual memory assigned to the project as show in figure 9.
Figure 9 - Arguments for Run configuration
IV. Lastly, under the ‘Classpath’ tab of the window, two things must be
done as follows
Adding the jars:
Add the jars used by the project by selecting User Entries, then select Add
External JARs. Add the java library jars, which can be found in
\Java\jdk1.6.0_07\jre\lib\ and
A-103
\Java\jdk1.6.0_07\jre\lib\ext\
(These are the jars that will be found in the JRE System Library of the
project being tested. Even the jars in the External Library should be
added.).
Adding the bin:
Importantly, the bin location of the project to be tested should also be
added, this can be done by selecting ‘Advanced’, then ‘Add External
Folders’ and the selecting the bin folder of the IPathDectector2.
Name of the run configuration
Figure 10 - ClassPath View for Run Configuration

1. Give it a name, click on Apply.
2. Then, you are asked whether save or not, click on ‘save’ and then click on
‘run’ button or select ‘run’, ‘run configuration’ and select the ‘named
configuration’.
3. While running the analysis, an Emframe Console Viewer window which
displays the progress status for the loading of library files by SOOT and also
for the conversion of the source code to intermediate representation will first
appear.
A-104
Figure 11 - Sample - Emframe Console

IV. Getting txt file for the user manual Analysis of selected path IDS desired by
analyzer
To get txt files which contain the retrieved source code and IR code of the
requested paths of the tested program is as follows:
Do only after the auto or manual analysis of a java program is done by 3

different tools which are IPathDetector2, Simplified, and Z3. Before running the
program again input the ids that desired to get source and IR code in the text file
given under specified URL.
(eg. C:/myexperiment/idFile.txt)
A-105
Figure 12:idFil
Advantages:
Save the trouble for analyzer to click on manual analysis button each time for
each class.
Save the trouble for analyzer to look for/brute force the saved source code
and IR in the previously saved by IntraResults.txt and InterResults.txt in
index III.
1. Next after loading, the Program Analysis Viewer, with progress bar of the
class in the system will be displayed.
4.1 Analysis can be done by user manually by clicking on the class name
displayed one by one or do the analysis automatically by clicking the
automated button. The result for intra path analysis will be displayed
after the analysis completes.
4.2 But, since our objective is to retrieve the source and IR code of the
selected path id in the idFile.txt, we would just do Automatic analysis
by clicking ‘Automated’ button on the program analysis viewer shown in
Figure13 below.
A-106
Figure 13- Sample – Program Analysis viewer

5.0 After pressing Automated, the analysis viewer will run automatically by
showing the progressing tool bar as shown in Figure 14below.
Figure 14- Sample – Progress tool bar

6.0 If the manual analyzer is displayed for any of the analysis, have to provide
the right options for deciding if the path is feasible or not.
6.1 When the program analysis viewer locates the first insolvable path, it will
prompt the following Manual Analyzer window as shown in figure
15below.
6.2 So, since our purpose is to get the source and ID code of unsolvable
paths, we won’t do manual analysing in this Analyzer window now.So,
A-107
click undefined for all the prompted windows of the unsolvable paths until
finish to the end.
Figure 15- Sample – Manual Analyzer
7.0 After all the unsolvable paths are defined as ‘un_defined’; the system will
show the complete analysis message box as shown in Figure 16 below.
Figure 12 - Sample - Interprocedural Path Analyzer View
8. You may check the specify txt file under speicfi folder to see the source code
and IR code retrieved.
Eg.
C:/myexp/statements.txt for Input IR to Simplify
C:/myexp/unsolveSRC.txt for for source code of JAVA
A-108
A-109

Aye My at Thin

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Aye My at Thin

Uploaded by

Copyright:

Available Formats

Development of Software Testing and Analysis Tools –Part E

SCHOOL OF ELECTRICAL AND ELECTRONIC ENGINEERING

NANYANG TECHNOLOGICAL UNIVERSITY

A final year project report

Project Number: A3242-082

Development of Software Testing and Analysis Tools –Part E

CHAPTER 2 RELATED TOOLS TECHNOLOGY

2.1 White –box Testing………………………………………………………………….…5

CHAPTER 3 DEVELOPMENT OF TEST SYSTEM

3.3 Results analyzed by Tools…………………………………………………………..19

4.1 Purpose of the program………………………………...…………………………….20

CHAPTER 5 MANUAL EVALUATION OF PATH FEASIBILITY

5.1 purpose of Manual Evaluation…………………………………….……………...….33

6.1 Achievement of the Developed Test System……………………….……………..66

Appendix 1.0: Master Student Mark Calculation Program with GUI

A1.1 Package of GUI………………………………………………………………….A1

Appendix 2.0: Attaining of Java Source and Intermediate Representation (IR)

A2.1 Main class for calling source and IR getting functions…………………..A23

Appendix 3: Manual Analysis results of the paths in the tested program

A3.1 Manual Analysis 1: JtoPass using Simple IR Expression ………………A40

Appendix 4: User Guide……..…………………………………………………….A88

Figure 1: Flow of code conversion for the specific suite of Tools…………………….6

Figure 2: Soot Phases……………………………………………………………………...8

Figure 3: Main Window Frame of Program…………………………………………...14

Figure 4: Example of Menu and button………………………………………………...14

Figure 5: Plain Data sheet ………………………………………………………………..15

Figure 6: Error message on invalid input…………………………………………….…15

Figure 7: Display of the result of calculated total marks ………………………….…..16

Figure 8: Save as Dialog Box for choosing URL………………………………………16

Figure 9: Message box after the file saved successfully……………………………..17

Figure 10: Drop down list for choosing the file…………………………………………17

Figure 11: Opened file in Excel………………………………………………………..…18

Figure 12: Selecting all the cells …………………………………………………………18

In software structural testing, the analysis and detection of infeasible paths in

IPathDetecotr 2 has been developed as a software analysis tool developed

Linear method, a symbolic checking of the relation between symbols of the

1.1.2 Other tools

1.1.3 Difficulties of tracing the source code and IR code manually

1.2 Objective of this project

1. Major infeasible paths will be detected correctly

To test more efficiently and accurately, it is required to conduct manual

Thus main objective is to Implement the sub-system for infeasible path

1.3 Report Organization

The work done will be shown in the classified as chapters as follows:

CHAPTER 2 RELATED TOOLS TECHNOLOGY

2.1 White –box Testing

Start of the definition of the path

IR expression in the form IR expression in the form IR expression in the form

Execution using Soot

Simplified tool Z3 Tool IPathDetector 2

Figure 1: Flow of code conversion for the specific suite of Tools

 It is a streamlined representation of stack-based byte-code

 It is used to convert stack-based byte-code into typed 3-address

 It is an SSA (Statistic Single Assignment) variation of Jimple.

 It is an aggregated version of Jimple

2.2.1 Input to IPathDetector 2(Jimple IR)

Example of how three-address code can be transformed from stack-based

Stack-based based byte code:

iload 1 // load variable x1, and push it onto the stack

Step1: Jimple Body Creation (jb):

Figure 2: Soot Phases [1]

Step2: Whole-program packs (cg, wjtp, wjop, wjap)

1. cg, the call graph pack,