Automatic Extraction and Verification of Page Transitions in a Web ...

14th Asia-Pacific Software Engineering Conference

Automatic Extraction and Verification of Page Transitions in a Web Application Atsuto Kubo†, Hironori Washizaki‡, Yoshiaki Fukazawa† †Waseda University Department of Computer Science and Engineering 3-4-1 Okubo, Shinjuku, Tokyo, Japan [email protected], [email protected] ‡National Institute of Infomatics, Japan 2-1-2 Hitotsubashi, Chiyoda, Tokyo, Japan [email protected]

Abstract

to learn how to write a model description for the various checking tools such as SPIN [5] or SMV [9], and maintenance of this model description is necessary for each of these tools. In many cases, the delivery period for Web applications is short, and model checking is not used because the project is completed before any benefits of using it can be realized. In addition, most model-checking techniques use a specific to their techniques, and it is necessary to maintain consistency between model and implementation as development proceeds, further increasing management costs. In this paper, we propose a technique, which automatically creates a Promela[6] code from the Struts [12] Web application framework structural data file and Java Server Pages (JSP) [11] page templates. Using the tool struts2spin that implements our technique, the cost of model-checking preparation and of maintaining the model code can be reduced.

Demand for reliability in Web applications has increased greatly in recent years as they have begun to be used more for enterprise applications. Model checking is an effective way to increase software reliability, but because most Web applications have short delivery times, preparation and application costs make it difficult to introduce model-checking techniques into the development process. In this paper, we propose a technique for automatically extracting page transitions from a Web application that has been developed using a Web application framework, such as Struts configuration files and Java Server Page templates, and transforming it into a format that can be used by existing model-checking tools. Using the proposed technique, Web application developers will be able to reduce the preparation and application costs of introducing model-checking techniques.

1. Introduction

2. Web application development and model checking

Web Applications are already being used to implement various services, such as electronic commerce on the Internet, but recently many enterprise systems are also being implemented as Web applications on internal corporate networks, further increasing the importance of this technique. As a result, there is a need for techniques that can verify the reliability of Web applications. There are many schemes for increasing the reliability of Web applications, including development using a framework [12] and automated testing [4], but few related to formal model checking [1]. The initial preparation and application costs of introducing model-checking techniques into the Web application development process are high. To introduce model checking into the software development process, it is first necessary

1530-1362/07 $25.00 © 2007 IEEE DOI 10.1109/ASPEC.2007.57

In this section, we describe the Web application model for the Struts Web application framework. We then point out some problems with Web application development using model checking and describe the solutions proposed in this paper.

2.1. Finite-state automata and linear temporal logic The finite-state automata used by model-checking tools, such as SPIN, are expressed using a Kripke structure[8], which is made up of the following structural elements:

350

1. Form Input Input (JSP)

Output (JSP)

Action Servlet

Table 1. Allowance in transitions

Business Logic

Level 1 2 3 4

Business Logic 3. Output

Starting any page No Yes Yes Yes

from

Reverse tions No No Yes Yes

transi-

Trantisions among any pages No No No Yes

2. Processing

2.3. Model checking for Web application Figure 1. Struts framework Web applications have various constraint conditions. For example, some conditions are described below. Set of states , denoted S, which is a set of possible states for the finite-state automaton.

• Transition to a particular page must be via a specific other page. For example, in an electronic commercial transaction application, a page displaying the contents of the shopping cart must be displayed before proceeding to the checkout. • Users can return to a certain page, such as an entrance page of Web application, from any position of the web application.

Set of state transitions , denoted R ∈ S × S, is a set of pairs of states. Set of label functions , denoted V : P × S → T, F , which assign a truth value to all logical expressions in the set P, based on whether they hold for a given state, S. Finite state automata, which have Kripke structure can be expressed, as a directed graph for which the states are vertices and state transitions are edges. Taking a point in time as the starting point, the state transitions of a finite-state automaton have an n-ary tree structure with each state as a node. With model-checking tools like SPIN, it is necessary to verify whether the desired property holds for the finite-state automaton in question on the n-ary tree of reachable states. Propositions on this n-ary tree are described in Linear Temporal Logic (LTL) using predicates, which express time-related conditions.

To increase the reliability of Web applications, it is necessary to ensure that these types of constraints are not violated. Items of the above list represent conditions on the structure of page transitions. Since model checker SPIN, which is used in the proposed technique, represents conditions using LTL on the structure of page transitions. In this paper, we consider conditions on only structures of page transitions, and do not consider wallclock-time based conditions, such as a timeout of user operation, because the LTL does not deal wallclock-time based conditions. HyperText Transport Protocol (HTTP), which is used by Web applications, is a stateless protocol. State information for HTTP sessions is held using session cookies or part of the URI, but clients can overwrite its content. In other words, strictly speaking, it is not possible for the server to control which page the client will transit to next. As such, in this paper, we establish levels with respect to the possibility that a client will transit between pages in a Web application as shown in Table 1. At level 1, the user only performs operations anticipated by the Web application designer, and at level 4, all permitted operations are considered. For the purposes of this paper, model checking will handle clients according to level 2 in the table. In Level 4, the most pessimistic level, the client can start arbitrary operations from any page (Figure 2(a)), or do backwards transitions using the ”Back” button or other means (Figure 2(b)), and the transition to the next page for a given page cannot be specified (Figure 2(c)). If Level 4 is assumed, the page transition graph becomes a complete graph. In contrast, Level 3 assumes that for a given page, only transitions to pre-specified pages will occur. Level

2.2. Web application model in Struts The application model for the Struts Web application framework uses a set of pages and a set of transitions between pages. Separation of pages from processing is a particular characteristic of the Struts application model. In Struts, as shown in Figure 1, page generation is handled by JSP, and processing is handled by action servlets. The JSP and action servlets can be developed independently, so associations between them are made using a configuration file, and both can accommodate many-to-many associations. Processing in a Struts application proceeds as follows: 1. The user sends form data as a request to the server. 2. The server handles the request with an action servlet that makes calls to the business logic. 3. The action servlet returns the processing results using a JSP.

351

(c)

(a)

Inputs
struts-config.xml

(b)




JSP Template


Transition
Variable



SPIN model (Promela)


mtype definition


State Variable


Event Channel
Event


Variable

Figure 4. Mappings among each model in the proposed technique

FSM

Model Checker Specific Model struts-config.xml JSP


State



Figure 2. Optimistic Levels for page transitions of Web applications

Web App. Page Transition Spec.

Finite-state automata (Kripke structure)

Promela

Model Checker Description

by the model-checking tools. Note that traditional schemes use a model that allocates a state to each page within the Web application [1, 10]. The proposed technique additionally allocates a state for each action servlet. Although the model that maps a page into a state is easy to understand, however, in actual Web applications, there are both transitions of a page to multiple actions and multiple pages to an action transition. The previous model, which maps a page into a state, cannot consider above-mentioned transitions. Thus, we map actions into states, in addition to pages.

Figure 3. Approach of the proposed technique

2 further assumes that backwards transitions will also not occur. Level 1 is the most optimistic, assuming that the client will only perform specific operations from given initial pages.

3.2. Model transformation

3. Proposed technique

The model transformation processing done by struts2spin is shown in Figure 4. This is accomplished with the following three steps.

3.1. Approach Most approaches to model checking are forward engineering, in which models with a high level of abstraction are step-wise transformed into models with a low level of abstraction. However, in practical development, it is possible that when changes are made to the specifications, only the implementation will be changed, leading to inconsistency between the specification and implementation, and making model checking based on the specifications meaningless. Because of this, in this paper we avoid problems of inconsistency between specifications and implementation by extracting the required information from the existing implementation. The approach taken in the proposed technique is shown in Figure 3. The page transition specification from the Web application implementation is used as the input to the technique. In Struts, the page transition specification consists of the Struts configuration file as well as the JSP template files, so this set of files is the input for the proposed technique. By analyzing this input, a specification description of the Web application page transition as a finite-state automaton conforming to Kripke structure is obtained, and this finite-state automaton is converted and output in a form that can be read

1. Transformation of Struts configuration files and JSP template files to a finite-state automaton description with Kripke structure. 2. Simplification of the finite-state automata description 3. Transformation of the finite-state automata description to a description in the Promela language. 3.2.1

Input files analysis

In the first step, the Struts configuration file and JSP template files are transformed into a finite-state automaton with Kripke structure. XPath [13] is used to extract element and attribute values from each file. The following, from among the extracted attributes, are handled as states: • File names of JSP template files • action attributes from html:form elements in the JSP template files • path attributes from action elements in the Struts configuration file • path attributes from forward elements in the Struts configuration file

352

... What is your name?
...

Table 3. Transitions added in each level Levels 1 2 3 4

Transitions to be added none Transitions from the initial state to all other states Counter transitions of the existing transitions Unconditional transitions among all states

WebApp state ==

/forward_success!

running

Figure 9. The Promela template for event transitions

Remove continuous unconditional transition Input.jsp

forward_success?

output.jsp

::( WebApp state == ) -> WebApp state ==

Translate into event receiving forward_null?

_finished

Figure 10. The Promela template for unconditional transitions

Return into input.jsp

3.2.3

Figure 8. A finite-state automaton after simplification

3.2.2

Generation of Promela code

The finite-state automata description obtained in the second step is used to generate a description in Promela that can be verified using SPIN. This transformation is done with the following procedure.

Simplification of the finite-state automaton

1. All of the symbols appearing in the finite-state automaton description are gathered and symbol definitions (mtype declarations) are generated for them. 2. Generate a communication channel for the user process and the Web application process to communicate. For the current procedure, we generate a fixed channel called WebApp ch. 3. Generate a global variable called WebApp state to hold the state of the Web application. 4. Create the User process. The user process repeatedly generates events that cause transitions in the Web application. 5. Create the WebApp process for the Web application.

The finite state automaton obtained in the first step contains transitions that are meaningless for the purposes of verification, and has many states, so it is not appropriate as-is for use with the model checking tools. In the second step, the finite-state automaton description obtained in the first step will be transformed and simplified to be compatible with SPIN. The technique used is described below. Create conditional transition events and user processes Transition guard conditions are converted to eventreception transitions. The user process performs a mimetic behavior of Web application’s user. Since Web application’s users can send any message through HTTP at any time, we create a user process that sends events randomly and continuously.

The process of generating the Web application is somewhat complex. There are two types of operation possible in the Web application: event-based transitions, and unconditional transitions. The Promela code for event-based transitions is generated by embedding the appropriate variable name in the template shown in Figure 9. Similarly, Promela codes for unconditional transitions are generated by embedding variable name in the template shown in Figure 10. The template for the Web application process is shown in Figure 11. The Promela code for the Web application is obtained by embedding Promela code of the event-based

Eliminate unconditional transitions Unconditional transitions carry no meaning for model checking, so they are eliminated, and states that have unconditional transitions are unified. Simplifying the finite-state automaton description obtained in the first step gives the one shown in Figure 8.

354

mtype = { inputjsp, outputjsp, finite, initial, success, BeginAction }; chan WebApp ch = [0] of { mtype }; mtype WebApp state = initial; active proctype User() { do :: WebApp ch!success; :: skip; od } active proctype WebApp() { mtype event; do ::WebApp ch?event -> if ::( WebApp state == BeginAction && event == success ) -> WebApp state = outputjsp :: else -> skip fi ::( WebApp state == inputjsp ) -> WebApp state = finite; ::( WebApp state == inputjsp ) -> WebApp state = BeginAction; ::( WebApp state == outputjsp ) -> WebApp state = finite; ::( WebApp state == finite ) -> WebApp state = initial; ::( WebApp state == initial ) -> WebApp state = finite; ::( WebApp state == initial ) -> WebApp state = inputjsp; ::( WebApp state == initial ) -> WebApp state = outputjsp; ::( WebApp state == initial ) -> WebApp state = BeginAction; od }

Figure 12. Promela code obtained in Experiment 1 active proctype WebApp() { mtype event; do ::WebApp ch?event -> if :: else -> skip fi od }

[](subscr → ⟨⟩editreg) && [](editreg → ⟨⟩init) #define subscr (WebApp state == SaveSubscription) #define editreg (WebApp state == EditRegistrationdo) #define init (WebApp state == initial)

Figure 14. A LTL property used in Experiment 2

as an input to SPIN, we checked whether deadlocks could occur using the SPIN deadlock-detection function. A deadlock occurs when the Web application does not have any transition corresponding to the message that the user process sent. The result verified that deadlock would not occur for the Promela code.

Figure 11. The Promela template for the process of Web applications

transitions and unconditional transitions into the template. The entire resulting Promela code is shown in Figure 12.

4.2. Experiment 2

4. Experiments

To evaluate in the scale of actual Web applications, we performed another experiment using the mail-reader application attached with Struts 1.3.8 distribution as an input of the proposed technique. First, we performed model transformation from a Struts configuration file and JSP template files into a Promela code shown in Figure 13. Totally 20 states have been obtained from the mail-reader. Next, we verified a property shown in Figure 14. That

The proposed technique was implemented as the struts2spin tool in the Java programming language.

4.1. Experiment 1 Using Figures 5 and 6 as the input files, and performing the model transformation using struts2spin results in the Promela code shown in Figure 12. Using this Promela code

355

... active proctype WebApp() { mtype event; do ::WebApp ch?event -> if ::( WebApp state == Save && event == Success ) -> WebApp state = MainMenudo; ::( WebApp state == MainMenu && event == Success ) -> WebApp state = MainMenujsp; ::( WebApp state == Locale && event == Success ) -> WebApp state = Welcomedo; ::( WebApp state == Logoff && event == Success ) -> WebApp state = Welcomedo; ::( WebApp state == SubmitLogon && event == Success ) -> WebApp state = MainMenudo; ::( WebApp state == Welcome && event == Success ) -> WebApp state = Welcomejsp; ::( WebApp state == SaveSubscription && event == Success ) -> WebApp state = EditRegistrationdo; ::( WebApp state == SaveSubscription && event == Input ) -> WebApp state = Subscriptiondo; :: else -> skip; fi ::( WebApp state == Subscriptionjsp ) -> WebApp state = SaveSubscription; ::( WebApp state == Subscriptionjsp ) -> WebApp state = finite; ::( WebApp state == Welcomejsp ) -> WebApp state = finite; ::( WebApp state == indexjsp ) -> WebApp state = finite; ::( WebApp state == MainMenujsp ) -> WebApp state = finite; ::( WebApp state == finite ) -> WebApp state = initial; ::( WebApp state == StaticJavascriptjsp ) -> WebApp state = finite; ... ::( WebApp state == initial ) -> WebApp state = ChangePasswordjsp; od }

Figure 13. A part of Promela code obtained in experiment 2 scattered in Java source code, which should be in struts configuration files and/or JSP template files.

5. Related work Choi et al. have proposed a technique for checking page transition specifications using a model transformation tool that transforms an activity diagram, from a page transition specification of a Web application design, into an SMV model description [1]. In contrast to this forward-engineering approach, our proposed technique uses a reverse-engineering approach, extracting the Web application’s page transitions by analyzing the completed JSP template files and the Struts configuration file. Choi et al. have also proposed a technique for checking page transitions using a tool which transforms the input into a model description for UPPAAL [14], a tool that uses timed automata for model checking [2]. This technique also uses an activity diagram as input, so it also differs from the proposed technique in its forward-engineering approach. Sciascio et al. have proposed a technique that generates an SMV model description by analyzing a Web application implementation, and uses it to check the Web application structure [10]. This technique is similar to our technique in that it uses a reverse-engineering approach, but it is different in that it applies to SMV, a different model-checking tool. Moreover, they obtained states of Web applications

Figure 15. Sequence chart obtained in Experiment 2

property means that the mail-reader always can return to the initial state from SaveSubscription state through EditRegistrationdo state. As the result of verification, we obtained a failed execution path. Figure 15 is a sequence chart of the above-mentioned failed execution path. The sequence chart indicates that the mail-reader can stay in EditRegistrationdo state forever. However, since there was a transition by a return value of action servlet in Java source code, struts2spin failed to obtain transitions there. Obtaining transitions described in Java source code requires advanced techniques, such as program slicing; thus, it is a future work in this paper. The proposed technique revealed the page transitions

356

Techniques such as cookies or RESTful (Representational State Transfer) are used to preserve state for an HTTP session. The technique will be extended to automatically extract and incorporate processing for these into the model. Because cookies operations are mainly handled by action servlets, it will be necessary to analyze them using program slicing.

from only pages, however, we obtained states of Web applications from pages and actions. Kato et al. have proposed a framework for extending the Struts configuration file in order to generate test cases for a Java Web application based on Struts [7]. As we also have discussed in this paper, only the transitions from ActionFormBean to JSP can be described from the Struts configuration file. Kato et al.’s technique is able to describe the complete finite-state automaton by extending the description in the Struts configuration file. In contrast, our technique takes note of the custom JSP tags in the JSP template files that will be transformed into form elements in the output HTML, extracts information in these tags, and uses it to compensate for information not found in the Struts configuration file. Fu et al. have proposed a translation technique from XML and XPath to Promela[3]. Their and our researches are similar at the point of translation to Promela. Fu et al.’s technique focuses on the external specification of web services. In contrast, our technique focuses on the internal specification of web applications.

Concurrent sessions We plan to extend the model to handle resource conflicts occurring with multiple users in parallel sessions. Automatic generation of checking formulas Checking formulas can be automatically generated by applying additional constraint information to each page.

References [1] E.-H. Choi, T. Kawamoto, and H. Watanabe. Model checking of page trantision specification. Computer Software, 22(3):146–153, 2005. (in japanese). [2] E.-H. Choi and H. Watanabe. Model checking class specifications for web applications. In The twelfth Asia-Pacific Software Engineering Conference (APSEC 2005), pages 67– 75. Asia Pacific Software Engineering Conference, 2005. [3] X. Fu, T. Bultan, and J. Su. Model checking xml manipulating software. In the 2004 ACM/SIGSOFT International Symposium on Software Testing and Analysis (ISSTA 2004), pages 252–262, 2004. [4] R. Gold. HTTPUnit. http://httpunit. sourceforge.net/. [5] G. J. Holzmann. The model checker SPIN. IEEE Transactions on Software Engineering, 23(5):279–295, 1997. [6] G. J. Holzmann. The SPIN Model Checker: Primer and Reference Manual. Addison-Wesley, 2003. [7] K. Kato, S. Yuen, and S. Agusa. A behavior description for web applications based on struts. In Proceedings of the 20th conference of Japan Society for Software Science and Technology. (in japanese). [8] S. Kripke. Semantical considerations on modal logic. Acta Philosophica Fennica, (16):83–94, 1963. [9] K. L. McMillan. Symbolic Model Checking. Kluwer Academic Publishers, 1993. [10] E. Sciascio, F. Donini, M. Mongiello, and G. Piscitelli. Web applications design and maintenance using symbolic model checking. In Proceedings of 7th Europian Confernce on Software Maintenance and reengineering, pages 63–70. IEEE Computer Society, 2003. [11] Sun Microsystems, Inc. JavaServer Pages. http:// java.sun.com/products/jsp/. [12] The Apache Software Foundation. Struts. http:// struts.apache.org/. [13] World Wide Web Consotium. XML Path Language (XPath). http://www.w3.org/TR/xpath. [14] W. Yi, P. Pettersson, and M. Daniels. Automatic Verification of Real-Time Communicating Systems By ConstraintSolving. In D. Hogrefe and S. Leue, editors, Proc. of the 7th Int. Conf. on Formal Description Techniques, pages 223– 238. North–Holland, 1994.

6. Conclusion There is strong demand for increased reliability in Web applications as they are increasingly used to implement enterprise applications within corporations, but efforts to increase reliability using model-checking tools with Web applications are few. In order to verify applications using the various existing model-checking tools, specialized description languages must be used for each, resulting in high training costs. Web application delivery times are generally short, so it is difficult to reap the benefits within the time frame of the project, against the additional preparation and application costs related to increasing reliability. This is one reason preventing the introduction of model checking into Web application development. In this paper, we have proposed a technique that automatically extracts the page transition specification from the implementation of a Web application, and automatically transforms it into model that can be read by the SPIN model-checking tool. Because transformations are done automatically after the inputs have been specified, the amount of work required to do model checking is greatly reduced. The costs associated with introducing model checking into the development process are thus reduced, making it easier to use these techniques for Web Application development. Moreover, the esseicial framework of the proposed technique is independent from specific Web application frameworks, thus the proposed technique can be applied to another Web application framework that supports static descriptions of its page transition. Future research related to this will include the following: Transition models including session variables

357