JAVA PRODUCTIVITY
CREATOR & ANALYZER
PRODUCTIVITY AIDS TO TRACK THE CONTROL FLOW,
PARSING OF THE CODE - ANALYZER AND LOG READER
The project deals with developing tools, which help in enhancing the activities at
different stages in the software development life cycle (SDLC).
The tools will fall under the category of CASE tools, which enable sophistication
during the software development.
AIM OF THE PROJECT
DEVELOPING TWO TOOLS
(a) Code Analyzer (jBrowser ) and
(b) Log Reader
CODE ANALYZER (jBrowser)
A tool that would track the control flow between various classes in JAVA platform
and (b) Log Reader - A tool that would help in presenting the log files of any server
in a more presentable form
The jBrowser would be a tool that would help the user track control flow between
java classes via method calls. Given a starting point, this tool tracks the entire path
within a particular location spotting various method calls under different scenarios.
We aim at building this tool as an effective tool to understand the control flow while
reengineering and reverse engineering and as a testing tool which would identify
the broken links between the java classes.
The Log Reader is another simple tool. This tool focuses on presenting the user
with a user friendly GUI, using which the user can query and extract useful
information from the log files generated by an application server in an interactive
and understandable manner.
The jBrowser can be classified as a tool for code analysis. In spite of there being
numerous tools for code analysis, all these tools are more bothered about
analyzing the program on issues relating misuse of the programming language as
such. They look out for potential bugs in the code and focus more on the code
structure.
Not many systems have targeted to track and analyze the control flow via method
calls between classes. The tools available to aid programmers in examining the
various components of a java component most of them are restricted to the class
level.

These tools primarily incorporate a single level of component display where
developers can view the various methods calls, object references and data types
that are declared within the scope of that particular class. No tool has displayed a
multilevel tracing technique for Java.
This may be attributed to the free formed nature coupled with the extensive set of
class level and multiple class level manipulations (Packages, Inheritance,
Overloading, Interfaces, Abstract and Virtual methods).
The tool unlike these traditional code analyzers, gives a new perspective to code
analysis. This tool requires a method name within a class as a start point. The tool
from the given starting point proceeds to track and identify the control flow to
various other classes via method calls from the starting point.
The tool employs exhaustive and efficient parsing to identify the various possible
ways of method calls. The tracked information is stored onto the file systems in
form of ‘XML’ files which is portable and can be used for any other applications.
The ‘XML’ file is then applied with an XSL transformation and presented as a
‘HTML’ file, which represent the extracted information in a simple user
understandable format. The concept of loggers comes into play in case of
networks where in there is an administrator monitoring the activities of the user.
Most servers have efficient methods for maintaining the log information. But the
drawback is in the representation of such details.
The servers monitor such logging information and maintain the details using
special log files. These files however represent information in form of raw textual
data which is very difficult for the users to understand. The entire purpose is lost
when the maintained files are in form of raw data, which is extremely difficult to
understand. The tool will perform an efficient parsing on the log file (systemout.log)
to store information onto convenient data structures in an explicit manner.
The GUI presents the user with an interface which enables the user to query the
information stored in the log file. The user is allowed to specify filter variables on the
basis of which the entire domain of data is filtered and displayed to the user according
to his need. The tool’s interface depicts a SQL command with graphical components
such as buttons, text fields, combo boxes, tables, etc. to perform the querying.
MODULAR DESIGN
The jBrowser is a tool which as specified above deals with tracking the control flow
between java classes via method calls. The jBrowser employs a phase strategy to
achieve its desired task.
The two phases involve 4 modules.
The four modules of the jBrowser are
1. Pre-Parsing Processing
2. Parsing
3. Storing and Manipulation
4. Building XML and presenting with a XSLT.

Code Analyzer (jBrowser)
The first there modules belong to the first phase which involves in building the
output. All the three modules interact with the file sub-system and a common back
end data store to build the output.
The three modules are employed in a recursive manner to make the system
generic and achieve optimization
PRE-PARSING PROCESSING (3P)
The 3P phase involves the creation and maintenance of several lists and other
data structures which support parsing. Since recursion is the main idea behind this
tool, 3P is involved at every iterative levels of recursion.
It is named Pre-Parsing because this phase does not involve any parsing of the
source code. This is simply to create and initialize data that would aid and facilitate
efficient parsing.
PARSING
The code analyzer (jBrowser) parsing forms the back bone as it is the module
which scans through the java files to identify method calls. To achieve this, an
exhaustive tracking of method calls through different classes is done.
This process requires efficient usage of certain data structures. It is imperative to
efficiently utilize minimal system resources to handle multiple method calls through
multiple levels.
Given these basic requirements, the parser is designed to identify and handle the
following
• Identify Object Declarations.
• Maintain a Class-Object mapping which is necessary for identifying method calls.
• Identify method calls.
• Resolving method calls inside conditional statements (if and if..else).
• Update the central database
As stated earlier, before getting on to the actual parsing there is a Pre-Parsing
Processing (3P) done. The 3P phase involves the creation and maintenance of
several lists and other data structures which support parsing.
Since recursion is the main idea behind this tool, 3P is also involved at every
iterative levels of recursion. It is named Pre-Parsing because this phase does not
involve any parsing of the source code. This is simply to create and initialize data
that would aid efficient parsing
STORING & MANIPULATION
the information is extracted from the java file, they need to be stored for future
manipulations. There are several ways of storing data. Files, database tables and
data structures are some very common ways of storing data.

• File system: This is the most common way of storing data, however the data
stored when needs to be extracted, an exhaustive parsing on that specific file
needs to be carried out. This does increase the system overhead by causing
exhaustive usage of memory.
• Database table: This is an efficient way of handling bulk volumes of data. These
databases normally run on separate database servers, serving as backend data
storage. In applications such as the above they may not be apt as they demand
high system requirements.
BUILDING OUTPUT
Now that the entire process of getting necessary information from the files and
storing them onto a temporary data structure is over, the information gathered
needs to be stored onto a permanent destination.
Of the several ways storing files, we prefer to store them in form of a XML file. This
file format makes the output portable as they could serve as inputs for several
other applications and is also easy to transfer over communication mediums.
The gathered information is stored in an XML using a simple DTD. The DTD for the
XML is designed, keeping in mind the information which needs to be represented
or stored.
Every element of the XML is called a node. There aren’t much details specified
with the element as such. The attributes of each of these elements take care of
storing and representing data
LOG READER
MODULAR DESIGN
The log reader is a simple java based tool aimed at parsing through log files and
extract information from them based on user requests. Log files have always been
cramped and generally deciphering information from the bulk of data present in
them is a tedious task.
This tool (currently developed for IBM Websphere based log files) is aimed to
improve the readability and usefulness of log files. An interactive GUI depicting a
SQL command is employed for retrieval of information from the back end data
store.
The log reader comprise of the following modules
1. Identifying information
2. Filtering and presenting data.
To first module is concerned with gathering information from the log file
(systemout.log). This module will perform an exhaustive parsing on the log file
trying to extract information which would needs to be presented to the user.
Just like the parsing done in the code analyzer, an efficient custom built data
structure in used to store the gathered information.

IDENTIFYING INFORMATION
This section deals with identifying information form the (systemout.log) log files.
The systemout.log is the log file generated by the WebSphere application server.
The systemout.log file stores information in form text, but is maintained in an
bizarre manner. The purpose of the log file is lost because of such a
representation.
FILTERING AND PRESENTING DATA
Once the information is gathered, it needs to be presented to the user as per his
request. This module involves building up a GUI. This GUI is designed in such a
way that it would depict an SQL command.
A simple SQL command of the form
select < filed names > from < table name > where < condition >
is depicted in a GUI using graphical components such as text fields, combo boxes,
buttons, tables and etc. The GUI facilitates the user to set filter values, on the
basis of which the pool of data would be filtered.
The GUI also accepts a desired array of fields which needs to be displayed while
giving the output. All this is implemented using the javax.swing package. This is
only about the front end.
The result presented to the output on successful querying is done with a simple
filtering mechanism. The GUI accepts the inputs and then this filtering is invoked
and continuously runs in a thread facilitating constant updates as a log could be
created at any instant
DEVELOPMENT REQUIREMENTS
SOFTWARE REQUIREMENTS
Java1.3
Swings
Windows 98
HARDWARE REQUIREMENTS
Intel Pentium IV Processor
256 MB RAM
40GB Hard Disk