reAJAX - FBK | SE - Fondazione Bruno Kessler

eAJAX: First-Use Example and Tutorial
by Alessandro Marchetto
reAJAX is a Mozilla Firefox extension available at http://selab.fbk.eu/marchetto/tools/ajax/reAJAX.
reAJAX is a research tool. Hence, it is a prototype tool that is continuously under maintenance and
evolution. In the rest of this tutorial we try to explain how to use the tool by means of a practical
example.
Other similar Firefox extensions can be found at https://addons.mozilla.org/it/firefox/ while details,
tutorial and examples about Firefox extension development and usage can be found at
https://developer.mozilla.org/en/Extensions. It is important to notice that these extensions (i.e.,
included reAJAX) can be used only with the Mozilla browser.
reAJAX is distributed as a unique .XPI executable file. An .XPI file is a “special” container of files
organized in an ad-hoc structure that is recognized by the Mozilla browser.Figure 1 shows the
structure of the XPI file of reAJAX. In the main directory reajax2 there is the chrome directory that
is organized into: content, locale and skin. The most relevant directory is content, it contains the
logic of the extension in terms of HTML and Javascript file while additional RDF are used to
configure the extension and to transmit to the browser configuration information about the software.
Figure 1: Structure of a Mozilla Firefox Extension
To install a Firefox extension such as reAJAX it is sufficient to follow three main steps: 1. open a
new browser window; 2. drop the .XPI file into the window; and 3. follow the few and simple steps
guided by some browser wizard used by the Firefox browser to install all the extensions and to be
able to manage and execute them. Please, note that in the first installation of reAJAX, we suggest to
try reAJAX into a new user profiler of the browser and install reAJAX into the standard profile just
when we are sure that no conflict or problem are related to reAJAX and the curent browser
configuration and version. When the reAJAX installation has been finished the extension will
appear in the list of “Added Components” of the menu “Tools” of the Mozilla browser.
reAJAX has been tested with different version of Mozilla 2.x – 3.x in both Windows (2000, XP)
and Linux like operating systems and no problems happen.

When reAJAX has been correctly installed, the browser list of “Tools” contains reAJAX and it
provides the following set of commands:
1. MutatorsInspectos
2. ABS
3. Tracer
6. BuildFSM
7. Close
While the Tracer has 2 sub-menu commands:
4. Tracer Start
5. Tracer Stop
In the rest of this tutorial we show a scenario of the reAJAX use. The scenario is based on the Cart
application implementation (source code are downloadable at the reAJAX page) and it is used to
show how to execute all main features of reAJAX to analyze a Web application and generate its
Finite State Machine. reAJAX can be applied to fully and single-page AJAX Web application, to
Web applications that partially use AJAX (e.g., in part of this GUI); and also in conventional (e.g.,
not AJAX-based) application. However, we recall that its natural use and its main goal are to
analyze full-AJAX application.
The first step of each reAJAX execution consists in loading the stating page of the target application
into the Mozilla browser enriched with the reAJAX extension. Then the execution scenario can
proceed identifying the following five main steps:
1a. Section of the inspector elements in the DOM of the application page;
1b Selection of the GUI-events that must be monitorized since they can change the
state of the selected mutator elements in the pages;
2 For each inspector, definition of its abstraction function (ABS) that will be used by
reAJAX to record the value reached at runtime by each inspector;
3 Application execution tracing by starting and stopping the reAJAX tracer;
4 Construction of the Finite State Machine (FSM) by using the collected execution
traces;
5 (extra reAJAX) Visualization of the generated FSM in the DOTTY
( http://www.graphviz.org/ ) viewer;
Notice that the steps 1a, 1b, 2, and 3 can be iteratively executed (also in different sequences) and
that it is possible to go through these different steps and go back without any kind of problem
and/or limitation and in which moment.

Step 1a. Section of the inspector elements in the DOM of the application page
First of all, we recall that an inspector element is an element of the DOM structure of an HTML
page (like a list, a field, an area, a graphical element, a container element, etc.) that is related to the
application domain and so that represents a state variable for the application state. Those inspector
elements must be selected by the user by means of the DOM-viewer provided by reAJAX. These
inspectors will be the DOM element that will be monitorized and evaluated at runtime by reAJAX
to infer the state of the application.
With the aim of selecting the set of inspectors, reAJAX provides an enriched DOM-viewer. The
viewer is a software module that add to the current page (of the target application) a draggable
popup in which reAJAX shows the complete list of HTML elements of the current page (and
ordered list of HTML tag related to the element of the DOM structure of the target page). Figure
Figure 2 shows the popup with the list of HTML element (, etc. in the left of the popup) for
the starting page of Cart. To focus and simplify the management of this list, reAJAX provides a
filter capability feature that can be used to filter out some non-relevant DOM elements. By using
the filter, the user can limit the type of the element shown in the DOM list by the DOM-viewer. A
list of HTML tag (e.g., “button, input, a”) can be used to filter the viewer element while by using
the “*” all elements of the current will be viewed in the list at each moment. In the figure, a
filter has been applied to the current page.
When the user passes the mouse over an element of the DOM list (see Figure 2 in which a
element is highlighted), reAJAX highlights the graphical element in the target page by means of a
dashed red square (see Figure 2 what happens for the selected example). So that the user
can see in the current page the element and its position. When the highlighted element is selected
(by using a mouse click) by the user some information (mainly its id/name and its XPath address in
the DOM page) are stored in the list of inspector elements for the current page. The list is shown in
the right part of the reAJAX popup. The list of selected inspectors can be stored at each time in a
file so that reAJAX can reload that inspector list at each moment without the needs to re-applying
all the selection
Figure 2: Mutators Selection for Cart

Step 1b Selection of the GUI-events that must be monitorized since they can change the state
of the selected mutator elements in the pa
Section of the events in the GUI of the target application that can have some impact in the state of
the inspector elements selected in the previous steps. Those events are called mutator elements for
the target application. The selection of these elements is performed at the same time, by means of
the same DOM-viewer and in the same way in which the inspector elements are selected. The
difference is that when selecting a mutator element, the user is asked to click on the mouse three
times in the selected element (i.e., one click to define the current element as an inspector; two clicks
to define it as inspector and mutator, at the same time; and three clicks to select it as mutator).
Step 2 For each inspector, definition of its abstraction function (ABS) that will be used by
reAJAX to record the value reached at runtime by each inspector;
When selected inspector and mutator elements, the next step consists in identifying the correct
abstraction function for each selected inspector. Notice that at least one inspector and one mutator
must be selected otherwise reAJAX does not allow the user to define the abstraction function and so
trace application executions. If the user starts the ABS definition by means of the related reAJAX
menu, for each selected inspector, reAJAX shows a popup with two different areas:
- left: it contains the list of the inspectors selected for which an abstraction must be
defined. Notice that a checkbox is used by reAJAX to show whether the abstraction
function for a given inspector element has been defined;
- right: it contains several different types of abstraction functions (see below) provided by
reAJAX and that can be customized by the user (note that this list of abstraction
functions can be obtained by means of a double-click on one of the inspectors shown in
the left side of this popup).
Currently, reAJAX provides the following set of functions:
NotNull: an element of a page exists at a given time (e.g., items of a list can
be added at runtime);
NotEmpty: an element is not empty at a given time (e.g., consider the text value of an
element );
Constant-value: strings and numbers in a textual field can assume a specific value or a
range of specific values (e.g., a number can be greater or less than a constant).
NumChildBool: true when an element contains a number (greater than 0) of other
embedded elements (children in the DOM) of a specific type (e.g., a contains
one or more rows);
NumChildAbsolute: an element contains a given number of embedded elements of a
specific type (e.g., a contains zero/one/two/etc. rows);
RegularExpressionRules: the value of an element (e.g., its content or text) matches a
regular expression. reAJAX allows to define an ordered set of pairs ``regular expression -
abstract state value'' for each element of a page. If the value of an element matches one of
the defined regular expressions its corresponding state-value is used to represent the
current state of the element (e.g., the text into a can be composed only by
lowercase letters ``[a-z]*'').
For each type of inspector (i.e., HTML element) that can compose a Web page, a predefined
abstraction is pre-configured by reAJAX. In this default configuration, the abstraction function can
be used by the user without any additional effort. In the following we summarize the most frequent
element types and their default abstraction provided by reAJAX:

DIV, SPAN, P, TEXTAREA, LI, and INPUT(of type text) NotEmpty
FORM NumChildBool()
OL, UL NumChildBool()
TABLE NumChildBool()
TR NumChildBool()
SELECT NumChildBool()
A, INPUT(of type button), IMG}, and other NotNull
Notice that the abstraction setting can be done iteratively when the user selects inspectors and
mutators. Furthermore, at each time, the defined abstraction function can be saved in a
configuration file that can be loaded in a second time.
Figure 3 shows an instance of the abstraction function definition for the Cart application.
Figure 3: Abstraction function definition for Cart

Step 3 Application execution tracing by starting and stopping the reAJAX tracer;
When inspector and mutator elements are selected, the next step consists in activating the
application execution instrumentation (it is highlighted by a reAJAX popup). Therefore, the next
application execution will be traced and during this execution the state of the application will be
recorded in a log file. To trace more executions into different log files it is sufficient to start and
stop the reAJAX tracing (respectively) before and after each application execution. Figure 3 shows
the activation of the reAJAX tracer for the Cart application.
Figure 4: Cart execution tracing
The execution tracing starts when the reAJAX tracer is activated and it stops when the same is
deactivated (by means of the reAJAX menu). Each execution trace is stored in a log file such as the
following (it is one execution of the Cart application):
ONLOAD:__:HTTP://LOCALHOST:8080/CART/:__:[
/HTML/BODY/DIV/DIV/UL[@ID='CONTENTS']=0 ;__;
/HTML/BODY/DIV/DIV/SPAN[@ID='TOTAL']=NOTEMPTYMATCH
]
CLICK:__:CHA001_REM:__:[
/HTML/BODY/DIV/DIV/UL[@ID='CONTENTS']=0 ;__;
/HTML/BODY/DIV/DIV/SPAN[@ID='TOTAL']=NOTEMPTYMATCH
]
ONUNLOAD:__:HTTP://LOCALHOST:8080/CART/:__:[
/HTML/BODY/DIV/DIV/UL[@ID='CONTENTS']=0 ;__;
/HTML/BODY/DIV/DIV/SPAN[@ID='TOTAL']=NOTEMPTYMATCH
]
Each row of the log file contains three types of information (separated from special characters
“:__:“ according to the following pattern:
- executed event (e.g., click of the rem button);
- id/name of the event or its Xpath address in the page (e.g., id of the activated button);
- state of the page according to the selected GUI inspectors (e.g., the list of items in the cart).

Step 4 Construction of the Finite State Machine (FSM) by using the collected execution traces;
By using the collected execution traces, the user can ask to reAJAX to generate the related FSM
that will be stored in a text file by the tool by using a graphical representation (the Dotty format
http://www.graphviz.org/ ). For instance, a FSM recovered for the Cart application is:
DIGRAPH FSM {
NODE [STYLE=ROUNDED]
ST0[SHAPE="RECORD",LABEL="{ ST0| }"];
ST1[SHAPE="RECORD",LABEL="{ ST1| /HTML/BODY/DIV/DIV/UL[@ID='CONTENTS']=0 |
/HTML/BODY/DIV/DIV/SPAN[@ID='TOTAL']=0 }"];
ST2[SHAPE="RECORD",LABEL="{ ST2| /HTML/BODY/DIV/DIV/UL[@ID='CONTENTS']\>0 |
/HTML/BODY/DIV/DIV/SPAN[@ID='TOTAL']\>0 }"];
ST3[SHAPE="RECORD",LABEL="{ ST3| }"];
ST0->ST1[ARROWHEAD="VEE" ,LABEL="ONLOAD_HTTP://LOCALHOST:8080/CART"];
ST1->ST2[ARROWHEAD="VEE" ,LABEL="ADD"];
ST2->ST2[ARROWHEAD="VEE" ,LABEL="ADD"];
ST1->ST1[ARROWHEAD="VEE" ,LABEL="EMPTY"];
ST2->ST1[ARROWHEAD="VEE" ,LABEL="EMPTY"];
ST2->ST1[ARROWHEAD="VEE" ,LABEL="REM"];
ST2->ST2[ARROWHEAD="VEE" ,LABEL="REM"];
ST2->ST3[ARROWHEAD="VEE" ,LABEL="ONUNLOAD_HTTP://LOCALHOST:8080/CART"];
ST1->ST3[ARROWHEAD="VEE" ,LABEL="ONUNLOAD_HTTP://LOCALHOST:8080/CART"];
}
Step 5 (extra reAJAX) Visualization of the generated FSM in the DOTTY format
The generated FSM can be visualized by using a Dotty-viewer. For instance, Figure 5 shows an
example of FSM generated for the Cart application.
Figure 5: FSM for Cart

Software License Agreement (BSD License)
Copyright (c) 2009, Fondazione Bruno Kessler: Alessandro Marchetto
All rights reserved.
Redistribution and use of this software in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this list of conditions and
the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation and/or other materials provided with the
distribution.
* Neither the name of FBK nor the names of its contributors may be used to endorse or promote
products derived from this software without specific prior written permission of the authors.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
© 2010 Marchetto Alessandro, Fondazione Bruno Kessler