GENERATING A DRIVER FOR ANALYSIS OT
AN EVENT-DRIVEN APPLICATION
RELATED APPLICATION
[1] This application claims the benefit, under 35 U.S.C. § 119(c). of U.S. Provisional
Patent Application No. 61/177908. filed 13 May 2009, which is incorporated herein by
reference.
TECHNICAL FIELD
[2] This disclosure relates generally to event-driven applications, such as. fo:
example, graphical user interface (GUI) or web applications.
BACKGROUND
[3] Quality assurance for event-driven applications—particularly applications with
graphical user interfaces (GUIs) or ones designed for use in connection with the World wide
Web—is increasingly important. Event-driven applications arc often difficult to test because
they have large sets of possible user inputs. Current approaches to testing event-driven
applications include live-subject testing, capture-replay, unit testing, crawling, and model-based
testing. Live-subject testing and capture-replay approaches involve considerable manual work
and require a tester to step through a set of use-case scenarios while clicking on buttons or links
and entering data into forms displayed through an interface, such as a web browser supporting
the event-driven application. While event-driven applications arc often designed to constrain
and guide a user through a set of scenarios, the set of all possible user inputs may be too large for
manual testing. Unit test cases are generally designed to check one user event at a time and do
not adequately address the checking of sequences of user events. Crawling techniques are
typically designed to visit web pages automatically. However, without user guidance (e.g.. the
specification of user inputs), crawlers may be unable to visit all possible pages of an event-driven
application. Model-based approaches generally rely on user specifications.
BRIEF DESCRIPTION OF TI IE DRAWINGS
[4] FIGURE 1 illustrates an example framework for validating an event-driven
application.
[5] FIGURE 2 illustrates an example unified modeling language (EMI ) class
diagram of elements of a page transition graph (PTG) data structure.
[6] FIGURE 3 illustrates an example PTG-based driver traversal algorithm.
[7] FIGURE 4 illustrates an example data flow for an example event-driven
application.
[8] FIGURE 5 illustrates an example code excerpt from an example JAVA
SERVERPAGES (JSP) file.
[9] FIGURE 6 illustrates an example code excerpt from an example struts-config.xml
file.
[10] FIGURE 7 illustrates an example page-transition portion of an example PTG data
structure.
[11] FIGURE 8 illustrates example driver extensions for example STRUTS-specific
event-handling application programming interfaces (APIs).
[12] FIGURE 9 illustrates an example method for validating an event-driver
application.
[13] FIGURE 10 illustrates example output of an example PTG traversal.
[14] FIGURE 11 illustrates an example computer system.
DESCRIPTION OF EXAMPLE EMBODIMENTS
[15| In particular embodiments, to analyze an event-driven application, it may be
necessary to create (1) a driver to exercise the behavior of the event-driven application and (2)
stubs to simulate components that the event-driven application may use but are out of the ¦nop.
of the analysis. For example, a driver may simulate user actions with respect to the event-drivei:
application and stubs may simulate a database used by the event-driven application. Pariicuia;
embodiments may generate a driver for an event-driven application by employing a technique
that involves (1) specifying an application-specific PTG that encodes information about the
possible pages of the web application, user events (e.g.. the selection of links or buttons on those
pages), event handlers, and user data; and (2) using an application-independent driver to traverse
the application-specific PTG and generate sequences of user events allowed by the application-
specific PTCi. This technique may facilitate the checking of navigation and busincss-logu
requirements of a web application.
[16| Particular embodiments relate to validating web or other event-driven application-.
that have been developed using JAVA or other suitable software platforms and that may utilize
server-side technologies (e.g., JSP) or other technologies to generate web or other page- ilia
include Hyper Text Markup Language (HTML) content, XML content, or other embedded
resources for rendering and displaying to a user at a client or other device. Particuia:
embodiments provide a framework that facilitates the validation of navigation and busine.YS-logic
requirements of event-driven applications using model-based analysis techniques. Particular
embodiments relate to a validation framework that performs validation based on a behavioral
diagram, graph, or other model of the event-driven application under test In particular
embodiments, the behavioral model takes the form of a PTG model or data structure that encode-
multiplc nodes (e.g., screens or other pages), user events or transitions supported by the event-
driven application (e.g., button clicks or clicks on links), corresponding event-handlers, and u.sc:
data. Particular embodiments use the PTG to generate drivers and use-case scenarios includiiu
test sequences of one or more events that cover contemplated user-interaction pattern.-, allow on
by the interface of the event-driven application.
[17] GUI and Web applications are generally open event-driven systems that take
sequences of events (e.g., button clicks in a browser window or a GUI page or screen) anc.
produce changes in the user interface displayed to a user (e.g.. a transition to a different page o;
screen) or the underlying application (e.g., an online shopping cart at an online store becoming
empty). To analyze an open event-driven application with validation techniques, it ma> be
necessary to close the event-driven application with a model of the event-driven application'-
environment, represented by components that the event-driven application interacts with.
Generally, the environment of an event-driven application under test may be grouped into
drivers, which use the application under test (as a user interacting with the event-driven
application may), and stubs(c.g., a database component or library code), which the e\cni-dri\ei:
application may call.
[18| In particular embodiments, to generate a driver simulating user events, the type*,
of events and event handlers used by the event-driven application must be identified. An .in
example and not by way of limitation, the event-handling mechanism of JAVA F.l:. (JAVA
PLATFORM, ENTERPRISE EDITION, also known as J2EF) applications is an example of the
observer pattern, where application-specific event handlers register to listen for specific c\eiits
JAVA EE is a widely used platform for server programming in the JAVA programming
language. The JAVA EE platform differs from the JAVA Standard Edition Platform (JAVA Shi
in that it adds libraries which provide functionality to deploy fault-tolerant, distributed, multi-tier
JAVA software, based largely on modular components running on an application server. A
typical JAVA EE uses HttpScrvlctRcquest and MttpScrvletRcsponse types, from the
javax.servlct.http package, to encode incoming and outgoing events. The event-handling classes
usually have special event-handling method (e.g., pcrform(HttpScrvlclRcquest)). Registration o'
event handlers to events generally happens at the time of deployment of the application
according to descriptor files such as, for example, X.V1L configuration files.
[I9| FIGURE I illustrates an example framework for validating an event-dnv.T
application. The framework includes environment generator 102 and validation toolkit i()4
Environment generator 102 accesses an implementation of the application under test 106 As ,n,
example and not by way of limitation, application 106 may be a web application or other e\ent
driven application. In particular embodiments, environment generator 102 generates an
implementation of an environment 108 of application 106. Environment I0S is gencialh
represented by components that application 106 interacts with during execution of application
106. Application 106 and environment 108 may be input to validation toolkit 104 for analysis
Validation toolkit 104 may output one or more validation results 114. Environment generato"
102 and validation toolkit 104 may be executed within or operate within one or more compute
systems, as illustrated in FIGURE 1 1 and described below. In particular embodiments
application code 106 resides at the same computer system as environment generator 102 or
validation toolkit 104. As an alternative, application 106 may reside at a separate compute
system that is connected or coupled to the computer system hosting environment generator 10?
and validation toolkit 104. Environment generator 102 and validation toolkit 104 may include
one or more software components residing at one or more computer systems, which ma\ be
similar to example computer system 600. Particular embodiments may implement either or both
of environment generator 102 and validation toolkit 104 as hardware, software, or a combination
of hardware and software. As an example and not by way of limitation, one or more computer
systems ma> execute particular logic or software to perform one or more steps of one or mor-.
processes described or illustrated with respect to environment generator 102 and validation
toolkit 104. One or more of the computer systems may be unitary or distributed, spanning.
multiple computer systems or multiple datacentcrs. where appropriate. The present disclosure
contemplates any suitable computer system.
[20| In particular embodiments, environment generator 102 includes a driver generato:
1 10 that produces one or more drivers 1 12 that simulate user actions or events at a "front end"' o
application 106. Environment generator 102 may then combine drivers 112 output b> cli,\e:
generator 110 with stubs to generate environment 108. As an example and not by wa\ o:'
limitation, some user actions may produce or result in page transitions only while other use;
actions may generate events that are subsequently sent to corresponding event handlers lb:
processing, for example, to trigger code execution of application 106. To generate a driver for
application 106, driver generator 1 10 may identify the types of events and event handlers or
event handling classes utilized by application 106.
[211 In particular embodiments, driver generator 1 10 generates test sequences based or
the behavior model thai includes a PTG data structure (or PTG). In particular embodiments.
driver generator 1 10 is configured to use the PTC) that encodes information about possible pagc.s
or nodes of application 106 and possible events or transitions supported by application 106.
along with information about the event handlers and event data for those events that require
corresponding event handlers and event data. The PTG facilitates the registration of the even'
handlers for application 106 and generation of sequences of events to drive the c\ent-handling
code of application 106 and exercise possible sequence of events allowed by the PTG.
|22| FIGURE 2 illustrates an example UMI. class diagram of elements of a PTG dat.,
structure 200 used by the driver generator 110. As an example and not by way of limitation.
PTG 200 encodes application-specific information about the set of available pages 202 o:'
application 106. Generally, each page 202 of PTG 200 representing application 10(i includes ;¦
set of possible events 204. Each event 204 represents a user event (e.g.. a button click or cliel-.
on a link) that a user may perform when interacting with a particular page of application !06
Some events may not be always enabled (e.g., buttons and links may become disabled depcndi'in.
on some condition). To reflect this possibility, event 204 keeps track of its "cnablednc.s.s." lb;
example, using a boolean "enabled." Button clicks, among other user events, arc typical!;
handled by corresponding event handlers. As such, some events 204 may have a set of even;
handlers 206 associated with them. Additionally, some events may require user data, such as ii
when a page presents a form or text box with which a user may enter information. To reflect thi
possibility, an event 204 may have a set of event data 208. populated with data items 2'0
attached to it. As an example and not by way of limitation, event data 20K may hold keys anc
values that may correspond to the names of the text fields (e.g., userlU and password of a login
form) and the user values entered in such fields. Generally, the PTG data structure usee! in
driver generator 1 10 serves as a specification of the event handler registrations and possible use-
case scenarios for validating application 106. Driver generator 110 generates one or moidrivers 1 12 based on the PTG data structure that may then be used to set up the event-handling
core of application 106 and exercise possible sequences of events allowed by the PTG.
[23] In particular embodiments, the PTG data structure is modeled using FC'I.IPSl
MODELING FRAMEWORK (EMF). EMF supports model specification u.^iny JAVA
interfaces. As an example and not by way of limitation, given JAVA interfaces. 1A1I m.iautomatically generate the PTG code and provide additional facilities, such as writing the mode1
in XML and loading it from XML to JAVA.
[24] In particular embodiments, the PTG may offer two levels of information: (L
navigation and (2) navigation with event-handling. The navigation level, containing informatioi:
about possible page transitions, may be used to perform checking with respect to navigation
requirements of application 106. In particular embodiments, as this analysis (performing
validation with respect to navigation requirements of application 106) doe* not require tlia
application 106 be a part of the model, this analysis may be implemented using any suitable
graph-checking algorithms. As an example and not by way of limitation, a set of requiremetr
templates used to check navigation requirements of application 106 may include reachability
(c.g, page A is reachable from page B), shortest path (e.g., page A is at least N steps av\a\ from
page B), and precedence (e.g., to visit page A, a user must first go through page B).
[25| Each requirement template may be instantiated with specific page values A and B
To increase usability, particular embodiments offer possible values for A and B. based on tiu
application-specific PTG used by environment generator 102. However. thi> stop rim s:il.
require selecting specific page names from a list of pages available from or supported In
application 106. Furthermore, particular embodiments include several checks thai look \'o<
possible violations without user specifications. As an example and not by way of limitation.
particular embodiments may include checks for possible violations in application 106 Mich as
presence of unreachable pages. As another example, a customizable application-specilu
checker may check whether every page available from application 106 has a link back to the
home page of the application.
|26| In contrast to navigation requirements, to check business logic requirements the
underlying code of application 106 must be checked. In particular embodiments, dri\e:
generator 110 incorporates an application-independent driver 112 based on the PTG dat;
structure that, given a populated application-specific PTG data structure, traverses the P'l'Ci am!
generates and executes sequences of user events. As described above, the driver 1 12 ma\ Iv
reused for applications associated with the same framework for which the driver was produced
[27] FIGURE 3 illustrates an example PTG-based traversal algorithm, which may !x
used to implement a driver incorporated into driver generator 110. This traversal is .speciIleal 1designed for JAVA EE event-handling APIs. As an example and not by wa\ of limitation, tiie
driver may implement the following: proccssPagc() calls proccssEvcnt() for each enabled e\en'
attached to the given page; processEventQ creates an HttpScrvletRequest object, populates the
HttpScrvictRequest object, and executes the event-handling code; processEventDatat) populate--
the HttpServletRcqucst object with event data; proccssEventHandlingO call.s the c\ent handling
method of the event handler and returns a next page depending on the result. The algorithm
implementing the driver of FIGURE 3 recursively calls processPagcl) on the next page 'I'm
algorithm may also be augmented with conditions to vary the traversal of the PTG. As ai:
example and not by way of limitation, such conditions may include a condition that a list o-
visited transitions can be used to avoid loops and a condition that an integer constant can be use;:
to limit the length of each generated sequence. Another feature of driver I 12. in partieula
embodiments, is its extensible APIs. As an example and not by way of limitation, certain
methods may be overridden to customize the driver according to a desired traversal algorithm,
the underlying analysis framework (e.g., to execute with JAVA PATHFINDER (JIT') ;)changing for-loops into nondcterministic choices), and the framework used to encode the event-
handling APIs (e.g.. STRUTS). To encode a nondcterministic choice, one can use JPI'N
modeling primitive Verify.random(n) which forces JPE to systematically explore all possible
values from a set of integers from 0 to n.
[28] The implementation of driver 112 and stubs (collectively forming environmen:
108) along with the implementation of application 106 may be fed into validation toolkit 10-4. In
particular embodiments, validation toolkit 104 employs the JPF model checker to check the
business logic requirements of application 106. In particular embodiments, validation toolki:
104 also utilizes one or more JPF extensions to enable analysis of event-driven applications
Particular embodiments utilize the JPF listener framework to implement listeners that .support
requirement specification based on temporal logic.
|29| In particular embodiments, driver generator 110 may include a driver 1 12 suitable
for validating a STRUTS-bascd web applications. As an example and not by ua\ of limitation.
such Struts-based Web applications may encode their page transitions using XML. HTML, and
JSP. In particular embodiments, the application PTG may be specified in XML. In particular
embodiments, driver generator 1 10 may include one or more extensions for generating drivers
for STRUTS-bascd applications. More specifically, particular embodiments include extensions
of the PTG data structure and driver 1 12 for use with STRUTS-bascd web applications.
130] In STRUTS, the controller is represented by the STRUTS servlct controller,
which intercepts incoming user requests and sends these requests to appropriate event hanulcr.
according to action mappings specified in, for example, an XML descriptor file called struis-
config.xml. In Struts. the request-handling classes arc subclassed from
org.apachc.struts.action.Action and the event-handling method is called execute!). Actions
encapsulate calls to business logic classes, interpret the outcome, and dispatch control to the
appropriate view component to generate the response. Form population is supported by the
ActionForm class, which facilitates the storing and validating of user data.
[31| FIGURF. 4 illustrates an example data flow for an example eveni-cinvei
application, which may be a STRUTS-bascd web application. The data flow generally alternates
between: (1) view to action (e.g., when a user clicks on a link or submits a form 404 (which mabe represented by JSP), controller layer 402 receives the request, looks up the mapping, anc;
forwards to an appropriate action 406, which calls business layer 40S): and (2) action to \ica
(e.g., after the call to underlying service 410 returns, action 406 forwards to a resource in tru
view layer and a page is displayed in a web browser.
|32| In particular embodiments. PTG can be specified based on existing na\ iuaiior-
models (e.g.. in UML) or application implementation, using three sources: (1) inibimarion iron;
JSP files; (2) information from XML configuration files; and (3) information from class (e.g..
JAVA class) files that encode Actions and Forms of the application under test.
[331 To demonstrate the technique of specifying the PTG, consider a registration
example. The registration example allows users to register and login to their accounts, followec:
by a logout. This example has six JSP pages: indcx.jsp (the initial page), wclcome.jsp.
userlogin.jsp. loginsucccss.jsp, usct'Rcgister.jsp, and registerSuccess.jsp. Each JSP page
corresponds to a node in the PTG, therefore, the PTG for this example contains at least six nodes
Each page contains information about possible user events. FIGURE 5 illustrates an example
code excerpt from an example JSP file relevant to population of the PTG lor the registration
example. The welcome page (wclcome.jsp) contains links back to itself, to userR.egister.jsp. and
userlogin.jsp. and the uscrlogin.jsp page contains a reference to a "/uscrlogin" action. To resolw
the meaning of this action, particular embodiments may need to consult one or more WII
configuration files.
[34| STRUTS XML configuration files may contain mappings from user actions to
their source page, the Action class that processes them, the form class that holds user data, am-
possible destination pages. FIGURE 6 illustrates an example code excerpt from an example
struts-config.xml file that provides an action mapping for the UserLoginAction. In FIGl RL 6.
UserLoginAction specifics the event handler type, UscrLoginForm specifies the event is
responds to. and uscrlogin.jsp specifies the page this event is available on. The outcome ot the
event depends on whether the event handling code returns, for example, "success" or "failure."
In the case of success, the next page is loginsucccss.jsp, while, in the case of failure, the ncx
page is uscrlogin.jsp.
|35| FIGURE V illustrates an example page-transition portion of an example P'I'G dat;.
structure for the registration example based on information in the applications JSP and XM1
files. In particular embodiments, the resulting PTG may be further enhanced with additional
browser-supported transitions (e.g.. clicking a "back" button in a Web browser rendering a page
of application 106). However, it may be sufficient to specify the application-specific P I'G io;
checking application-specific requirements and, as such, in particular embodiments, tin
generated PTG does not include various non-application-spccific additional browser-supportcc
transitions.
|36| The PTG analysis of the application with respect to navigation requirement-
requires no extensions for S'l'RU'l S-based web applications. In particular embodiment-, me
PTG-based analysis of the application may require overriding the event-handling method.- of the
driver to confirm to STRUTS event-handling APJs. FIGURE 8 illustrates example drive
extensions for example STRUTS-spccific event-handling APIs. The extensions are code
excerpts from a driver 1 12 produced for STRUTS-bascd web applications needed to override
event-handling methods, to account for the STRUTS-specific event-handling APIs. In particular
embodiments, the driver generation and its extensions for S'l'RUTS-based web application.- ;nabe implemented using JAVA.
[37] FIGURE 9 illustrates an example method for validating an event-drivei.
application. The method begins at step 1 102, where an implementation of the application uncier
lest is accessed. At step 1 104. a PTG is populated. At step 1 106, the PTG is analyzed with
re-pect to navigation requirements (e.g., each page is reachable from the home page) of the
application under test. At step 1 1 OS. one or more drivers for the application under test are
automatically generated based on information encoded in the PTG. At 1110. the drivers are usee
to analyze the application under test, including validation of business logic requirement.- oi t!u
application under test. At step 1 1 12, one or more results of the analyses are output, at which
point the method ends. Although the present disclosure describes and illustrate- particular .-rep-
ot" the method of FIGURE 9 as occurring in a particular order, the present disclosure
contemplates any suitable steps of the method of FIGURE 9 occurring in any suitable order
Moreover, although the present disclosure describes and illustrates particular component-
carrying out particular steps of the method of FIGURE 9, the present disclosure contemplate-
any suitable combination of any suitable components carrying out any suitable steps of" the
method of FIGURE 9.
[38] FIGURE 10 illustrates example output of an example PIG travers.il. includiiiL
test sequences generated and executed by the driver of FIGURE 8, based on the PTG ofl-IGl RI
6 using the algorithm of FIGURE 3 to bound the length of the test sequences.
|39| FIGURE I 1 illustrates an example computer system 600. In pariicula:
embodiments, one or more computer systems 600 perform one or more steps of one or moiv
methods described or illustrated herein. In particular embodiments, one or more computer
systems 600 provide functionality described or illustrated herein. In particular embodiments
software running on one or more computer systems 600 performs one or more steps of one or
more methods described or illustrated herein or provides functionality described or illustrated
herein. Particular embodiments include one or more portions of one or more computer system-
600.
|40| This disclosure contemplates any suitable number of computer systems 600 Thi--
disclosure contemplates computer system 600 taking any suitable physical form. .As cxampk
and not by way of limitation, computer system 600 may be an embedded computer system ;.
system-on-chip (SOC), a single-board computer system (SBC) (e.g., a computcr-on-module
(COM) or system-on-modulc (SOM)), a desktop computer system, a laptop or notebook
computer system, an interactive kiosk, a mainframe, a mesh of computer systems, a mobiK
telephone, a personal digital assistant (PDA), a server, or a combination of two or more of these
Where appropriate, computer system 600 may include one or more computer systems 600: !x
unitary or distributed: span multiple locations: span multiple machines; or reside in a cloud,
which may include one or more cloud components in one or more networks. Where appropna:c
one or more computer systems 600 may perform without substantial spatial or tempora
limitation one or more steps of one or more methods described or illustrated herein. As an
example and not by way of limitation, one or more computer systems 600 may perform in rea-
dme or in batch mode one or more steps of one or more methods described or illustrated herein
One or more computer systems 600 may perform at different times or at different locations one
or more steps of one or more methods described or illustrated herein, where appropriate.
[41] In particular embodiments, computer system 600 includes a processor (>02.
memory 604, storage 606. an input/output (I/O) interface 608, a communication interface MO.
and a bus 612. Although this disclosure describes and illustrates a particular computer system
having a particular number of particular components in a particular arrangement, this disclosure
contemplates any suitable computer system having any suitable number of any suitable
components in any suitable arrangement.
(42| In particular embodiments, processor 602 includes hardware for executing
instructions, such as those making up a computer program. As an example and not by way o
limitation, to execute instructions, processor 602 may retrieve (or fetch) the instructions from an
internal register, an internal cache, memory 604. or storage 606; decode and execute them: am:
then write one or more results to an internal register, an internal cache, mcmor\ 604. or storage
606. In particular embodiments, processor 602 may include one or more internal caches for ctata
instructions, or addresses. The present disclosure contemplates processor 602 including ansuitable number of any suitable internal caches, where appropriate. As an example and not In
way of limitation, processor 602 may include one or more instruction caches, one or more data
caches, and one or more translation lookaside buffers (TLBs). Instructions in the instruction
caches may be copies of instructions in memory 604 or storage 606, and the instruction cache--
may speed up retrieval of those instructions by processor 602. Data in the data caches nun oe
copies of data in memory 604 or storage 606 for instructions executing at processor o()2 to
operate on; the results of previous instructions executed at processor 602 for access bsubsequent instructions executing at processor 602 or for writing to memory 604 or storage "06
or other suitable data. The data caches may speed up read or write operations by processor "02
The TLBs may speed up virtual-address translation for processor 602. In particular
embodiments, processor 602 may include one or more internal registers for data, instructions, o:
addresses. 1 he present disclosure contemplates processor 602 including any suitable number of
any suitable internal registers, where appropriate. Where appropriate, processor 602 may include
one or more arithmetic logic units (ALUs); be a multi-core processor; or include one or more
processors 602. Although this disclosure describes and illustrates a particular processor, this
disclosure contemplates any suitable processor.
[43] In particular embodiments, memory 604 includes main memory for storing
instructions for processor 602 to execute or data for processor 602 to operate on. As an example
and not by way of limitation, computer system 600 may load instructions from storage 6()o or
another source (e.g., another computer system 600) to memory 604. Processor 602 ma\ thou
load the instructions from memory 604 to an internal register or internal cache. To execute the
instructions, processor 602 may retrieve the instructions from the internal register or internal
cache and decode them. During or after execution of the instructions, processor 602 may write
one or more results (which may be intermediate or final results) to the internal register or internal
cache. Processor 602 may then write one or more of those results to memory 604. In par.kula:
embodiments, processor 602 executes only instructions in one or more internal registers or
internal caches or in memory 604 (as opposed to storage 606 or elsewhere) and operates onl> on
data in one or more internal registers or internal caches or in memory o04 (as opposed to storage
606 or elsewhere). One or more memory buses (which may each include an address bus ana a
data bus) may couple processor 602 to memory 604. Bus 61 2 may include one or more memon.
buses, as described below. In particular embodiments, one or more memors management units
(MMUs) reside between processor 602 and memory 604 and facilitate accesses to memor\ f>0-
requested by processor 602. In particular embodiments, memory 604 includes random access
memory (RAM). This RAM may be volatile memory, where appropriate Where appropriate.
this RAM may be dynamic RAM (DRAM) or static RAM (SRAM). Moreover, where
appropriate, this RAM may be single-ported or multi-ported RAM. The present disclosure
contemplates any suitable RAM. Memory 604 may include one or more memories 604. where
appropriate. Although this disclosure describes and illustrates particular memory, this disclosure
contemplates any suitable memory.
[44| In particular embodiments, storage 606 includes mass storage for data 01
instructions. As an example and not by way of limitation, storage 606 may include an 111)1). a
floppy disk drive, flash memory, an optical disc, a magneto-optical disc, magnetic tape, or a
Universal Serial Bus (USB) drive or a combination of two or more of these. Storage 606 mainclude removable or non-removable (or fixed) media, where appropriate. Storage 606 ma\ lie
internal or external to computer system 600, where appropriate. In particular embodiments,
storage 606 is non-volatile, solid-state memory. In particular embodiments, storage 606 include*
read-only memory (ROM). Where appropriate, this ROM may be mask-programmed ROM.
programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM
(LEPROM), electrically alterable ROM (EAROM), or flash memory or a combination of two or
more of these. This disclosure contemplates mass storage 606 taking any suitable physical form.
Storage 606 may include one or more storage control units facilitating communication bet we or.
processor 602 and storage 606. where appropriate. Where appropriate, storage 606 may include
one or more storages 606. Although this disclosure describes and illustrates particular storage
this disclosure contemplates any suitable storage.
[451 In particular embodiments, I/O interface 608 includes hardware, software, or both
providing one or more interfaces for communication between computer system 600 and one o:'
more I/O devices. Computer system 600 may include one or more of these I O devices, where
appropriate. One or more of these I/O devices may enable communication between a peison anc
computer system 600. As an example and not by way of limitation, an I/O device may include a
keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus,
tablet, touchscreen, trackball, video camera, another suitable I/O device or a combination of two
or more of these. An I/O device may include one or more sensors. This disclosure contemplate-
any suitable I/O devices and any suitable I/O interfaces 608 for them. Where appropriate, I 0
interface 608 may include one or more device or software drivers enabling processor 602 to
drive one or more of these I/O devices. I/O interface 608 may include one or more I O interlace ¦
608, where appropriate. Although this disclosure describes and illustrates a particular I O
interface, this disclosure contemplates any suitable 10 interface.
|46| In particular embodiments, communication interface 610 includes hardware
software, or both providing one or more interfaces for communication (e.g.. packet-hasee
communication) between computer system 600 and one or more other computer systems 600 or
one or more networks. As an example and not by way of limitation, communication interface
610 may include a network interface controller (NIC) or network adapter for commiinicatiiu.
with an Ethernet or other wire-based network or a wireless NIC (\VNIC) or wireless adapter to;
communicating with a wireless network, such as a WI-FI network. This disclosure contemplate-,
any suitable network and any suitable communication interface 610 for it. As an example and
not by way of limitation, computer system 600 may communicate with an ad hoc network. a
personal area network (PAN), a local area network (LAN), a wide area network (WAN). .;
metropolitan area network (MAN), or one or more portions of the Internet or a combination oi'
two or more of these. One or more portions of one or more of these networks may be wired or
wireless. As an example, computer system 600 may communicate with a w irelcss PAN (WPAN ¦
(e.g., a BLUETOOTH WPAN), a WI-FI network, a WI-MAX network, a cellular iclephonc
network (e.g., a Global System for Mobile Communications (GSM) network), or other suitahk
wireless network or a combination of two or more of these. Computer system 600 may include
any suitable communication interface 610 for any of these networks, where appropriate.
Communication interface 610 may include one or more communication interlace.*. 610. \\:tciappropriate. Although this disclosure describes and illustrates a particular communicaiioi:
interface, this disclosure contemplates any suitable communication interface.
[47] In particular embodiments, bus 612 includes hardware, software, or both coupling
components of computer system 600 to each other. As an example and not by way of limitation,
bus 612 may include an Accelerated Graphics Port (AGP) or other graphics bus. an l-nhanceci
Industry Standard Architecture (EISA) bus, a front-side bus (FSB), a HYPERTRANSPOR1
(HT) interconnect, an Industry Standard Architecture (ISA) bus, an INFINIBAND interconnect
a low-pin-count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a
Peripheral Component Interconnect (PCI) bus, a PCI-Exprcss (PCI-X) bus, a serial advanced
technology attachment (SATA) bus. a Video Electronics Standards Association local (VLB) bus.
or another suitable bus or a combination of two or more of these. Bus 612 mav include on: or
more buses 612, where appropriate. Although this disclosure describes and illustrates .-.
particular bus, this disclosure contemplates any suitable bus or interconnect.
[48{ Herein, reference to a computer-readable storage medium encompasses one or
more tangible computer-readable storage media possessing structure. As an example and not 'v.
way of limitation, a computer-readable storage medium may include a semiconductor-based o:
other integrated circuit (IC) (such, as for example, a field-programmable gate array (I-P(i A ) or an
application-specific IC (ASIC)), a hard disk, an HDD, a hybrid hard drive (HHD). an optica1
disc, an optical disc drive (ODD), a magneto-optical disc, a magneto-optical drive, a lloppy disk.
a floppy disk drive (TDD), magnetic tape, a holographic storage medium, a solid-state drive
(SSD), a RAM-drive, a SECURE DIGITAL card, a SECURE DIGITAL drive, or another
suitable computer-readable storage medium or a combination of two or more of these, where
appropriate. Herein, reference to a computer-readable storage medium excludes any medium
that is not eligible for patent protection under 35 U.S.C. >j 101. Herein, reference to a computer-
readable storage medium excludes transitory forms of signal transmission (such as a propagating
electrical or electromagnetic signal per se) to the extent that they are not eligible for patent
protection under 35 U.S.C. ^ 101.
[49| This disclosure contemplates one or more computer-readable storage media
implementing any suitable storage. In particular embodiments, a computer-readable stoiagi.
medium implements one or more portions of processor 602 (e.g., one or more internal register-
or caches), one or more portions of memory 604. one or more portions of storage 606. or a
combination of these, where appropriate. In particular embodiments, a computer-readable
storage medium implements RAVI or ROM. In particular embodiments, a computer-readable
storage medium implements volatile or persistent memory. In particular embodiments, one or
more computer-readable storage media embody software. Herein, reference to software maencompass one or more applications, bytccodc, one or more computer programs, one or more
executablcs, one or more instructions, logic, machine code, one or more scripts, or source code
and vice versa, where appropriate. In particular embodiments, software includes one or more
application programming interfaces (APIs). This disclosure contemplates any suitable software
written or otherwise expressed in any suitable programming language or combination o:'
programming languages. In particular embodiments, software is expressed as source code or
object code. In particular embodiments, software is expressed in a higher-level programming
language, such as, for example, C, Perl, or a suitable extension thereof. In particular
embodiments, software is expressed in a lower-level programming language, such as as>cmbllanguage (or machine code). In particular embodiments, software is expressed in JAVA. In
particular embodiments, software is expressed in Hyper Text Markup Language (HTML).
Extensible Markup Language (XML), or other suitable markup language.
[50] The present disclosure encompasses all changes, substitutions, variations.
alterations, and modifications to the example embodiments herein that a person having ordinary
skill in the art would comprehend. Similarly, where appropriate, the appended claims encompass-
all changes, substitutions, variations, alterations, and modifications to the example embodiment.-,
herein that a person having ordinary skill in the art would comprehend.
We Claim:
1. A method in at least one computer system (600) for validating an event-
driven application, the at least one computer system comprising:
- at least one processor (602) including hardware enabled to retrieve
instructions from one of an internal register, a memory, a storage device,
a translation lookaside, buffer (TLB); decode and execute the retrieved
instructions; write one or more results in one of said retrievable means;
- at least a memory (604) for storing instructions and allowing the
processor (602) to execute the instructions, the memory (604) further
allowing the processor (602) to acquire data from one of a storage device
(606) and a second computer system (600) and load to the memory (604)
which data being transferable from the memory (604) to an internal
register or an internal cache by the processor (602);
- at least one system bus (612) including hardware or software or both and
coupling components including peripherial devices of the computer system
(600);
- the storage device (606) comprising a mass storage means operably
connected to the computer system (600) and selectable from group
consisting of ROM,PROM,EPROM, EAROM, and a flash memory, or a
combination therefrom;
- at least one each input/output interface (608) for communication between
the computer system (600) and one or more input/output devices
selectable from a group considering of keyboard, keypad, microphone,
monitor, mouse, scanner, speaker, printer, camera or a desired
combination thereof;
- a communication interface (610) including hardware, software, or both
providing one or more interfaces for communication between the
computer system (600) and one or more distributed computer systems or
one or more networks; and
- the computer system (600) incorporated with atleast one application code
(106), one environment generator (102) and a validation kit (104)
including one or more software components possibly residing at other
distributed computer systems (600) or the same computer system (600),
the environment generator (102) including the validation kit (104) being
implementable as hardware, software or a combination of hardware and
software; the method comprising the steps of:
specifying (1102) an application-specific navigation model of an event-driven
application (106), the application-specific navigation model encoding (1104);
one or more pages (202) of the event-driven application (106);
one or more events (204) supported by the event-driven application;
one or more event handlers (206) for processing one or more of the events
(204); and
one or more event data (208) for one or more of the events (204);
analyzing (1106) the navigation model with respect to one or more navigation
requirements of the event-driven application (106) to determine whether the
event-driven application (106) satisfies the navigation requirements;
generating (1108) one or more drivers (112) for the event-driven application
(106) based on the navigation model, wherein the drivers (112) are
collectively or individually configured to:
for each of the pages (202) of the event-driven application (106), process
events that are available and enabled on the page (202); and
for each of the events (204);
populate the page (202) with event date (208);
invoke a registered event handler (206) for the event (204); and
calculate a next page (202) based on a result returned by the registered
event handler (206); and
recursively process the next page (202); and
traversing the navigation model with the application-independent event
drivers (112) to analyze (1110) the event-driven application (106) with
respect
to one or more business-logic requirements of the event-driven application
(106) to determine (1112) whether the event-driven application (106)
satisfies the business-logic requirements.
2. The method of Claim 1, wherein the event-driven
application is an open event-driven application.
3. The method of Claim 1, wherein the application-specific navigation model is a
page transition graph (PTG).
4. The method of Claim 1, wherein the event-driven application is a web application
comprising one or more of JAVA SERVERPAGES (JSP), Hyper Text Markup Language
(HTML) code or content, Extensible Markup Language (XML) code or content, or JAVA code.
5. The method of Claim 1, wherein the event-driven application is a STRUTS-based
web application.
6. The method of Claim 1, wherein the event-driven application is a graphical user
interface (GUI) application.
7. The method of Claim 1, wherein one or more of the events each comprise one or
more page transitions or one or more events that are processed by one or more event handlers.
8. The method of Claim 1, wherein traversing the navigation model with the
application-independent event drivers to analyze the event-driven application comprises:
for each of one or more first ones of the pages of the event-driven application,
determining whether the first one of the pages is reachable from one or more second ones of the
pages of the event-driven application, whether the first one of the pages is at least a
predetermined number of transitions away from one or more of the seconds ones of the pages, or
whether the first one of the pages is reachable without first transitioning to one or more of the
seconds ones of the pages; or
determining whether all the pages of the event-driven application have incoming and
outgoing transitions.

In one embodiment, a method includes specifying an application-specific navigation
model of an event-driven application; analyzing the navigation model with respect to one or
more navigation requirements of the event-driven application to determine whether the event-
driven application satisfies the navigation requirements; generating one or more drivers for the
event-driven application based on the navigation model; and traversing the navigation model
with the application-independent event drivers to analyze the event-driven application with
respect to one or more business-logic requirements of the event-driven application to determine
whether the event-driven application satisfies the business-logic requirements.