Modeling Safe Interface Interactions for Web Applications

POLITECNICO DI MILANO Facoltà di Ingegneria dell’Informazione POLO REGIONALE DI COMO Master of Science in Computer Engineering Modeling Safe Interf...
Author: Madison Dean
1 downloads 3 Views 2MB Size
POLITECNICO DI MILANO Facoltà di Ingegneria dell’Informazione

POLO REGIONALE DI COMO

Master of Science in Computer Engineering

Modeling Safe Interface Interactions for Web Applications

Supervisor: Prof. Marco Brambilla Master Graduation Thesis by: Pham Thuy Duong Student Id. Number: 707503

Academic Year 2008/2009

MODELING SAFE INTERFACE INTERACTIONS IN WEB APPLICATIONS

ACKNOWLEDGEMENT

There are many who have made this work possible. First, I would like to show my appreciation to my supervisor Prof. Marco Brambilla, who has been my inspiration and role model for how to do good research. He has always given good advices and directions while still allowing me to go my own way. Next, I would like to thank my family, who have offered loving support and helped me to over come all the problems. They have always supported me in whatever the decisions I have made, and have given me the confidence to believe in myself. I would like to thank all my professors through the years of studying in Politecnico, both formal and informal, who gave me great knowledge, and have helped me to make the way to this thesis. I would also like to thank to all my friends who have supported me a great moral for all the years studying in Politecnico.

ABSTRACTS

The evolving from traditional hypertext document to complicated web application which embeds sophisticated user interface and business logic, has introduced many problems with the browser navigation. The original interaction model of the web with static content pages that are browsed by hyperlinks is therefore, not valid with the current web applications anymore. In this work, we introduce a new paradigm which shifts from modeling web based on pages to full-fledge finite state machine. The model considers states, events and transition from one state to another based on user interactions. With this model, pages are replaced by states, and the whole navigation described in the state machine can be controlled in one central place. In addition, back/forward navigation along the browsing history is replaced by interactive application paradigm which features Undo/Redo capabilities, and also supports for exception management policies and transactional properties. This offers a safer and more precise interaction model protecting the user from unexpected behaviors. Nevertheless, it provides programmers with little effort in term of creating, maintaining and securing web navigation.

i

DEDICATION

I would like to dedicate this thesis to my lovely niece.

ii

TABLE OF CONTENTS Page ABSTRACTS..............................................................................................................i DEDICATION............................................................................................................ii LIST OF FIGURES ...................................................................................................v I.

INTRODUCTION..........................................................................................1 1.1 1.2 1.3

II.

BackGround ...................................................................................................5 2.1 2.2 2.3 2.4 2.5 2.6

III.

Why New Model.................................................................................. 13 State Machine Concept ........................................................................15 Undo/Redo Mechanism Concept .........................................................15 Safe Navigation Concept .....................................................................16 Symbols and Explanation ....................................................................19 Online Hotel Booking Application Example.......................................20

DESIGNING META DATA STUCTURE AND API FOR THE MODEL 4.1

4.2 4.3

V.

Web Application ..................................................................................5 Stateless and Stateful ...........................................................................5 Model-View-Controller (MVC)........................................................... 6 Jakarta STRUTS Framework...............................................................10 XML.....................................................................................................11 Graphical Interface - SPL ....................................................................11

CONCEPTUAL MODEL .............................................................................13 3.1 3.2 3.3 3.4 3.5 3.6

IV.

Problem ................................................................................................1 Proposed Solution ................................................................................2 Thesis Structure ...................................................................................3

State Machine Description...................................................................24 4.1.1 Webflow.xml ...........................................................................24 4.1.2 Hotel Booking Flow Example .................................................26 Storing visits: Log Structure ................................................................27 State Machine Controller (SMC) .........................................................29 4.3.1 SMC Sequence Diagram..........................................................30 4.3.2 SMC Class Diagram ................................................................33 4.3.3 Activities Diagrams .................................................................36

IMPLEMENTATION OF THE API ...........................................................42 5.1

Technology Requirements: .................................................................. 42 iii

24

5.2 5.3 5.4 VI.

API Implementation.............................................................................47 Summary-List of Functions .................................................................53 Graphical Editor Integration ................................................................54

CONCLUSION AND FUTURE WORKS ...................................................58

REFERENCES...........................................................................................................60

iv

LIST OF FIGURES Figure 2.1 Traditional Web Application Architecture.................................................. 7 Figure 2.2 Components of MVC...................................................................................... 8 Figure 2.3 Example of Architecture of MVC in Java-based Web Application........... 9 Figure 2.4 Struts Framework Architecture.................................................................. 10 Figure 3.1 Traditional Stateful Request-Driven Web Application ............................ 13 Figure 3.2 Process-Driven Web Application ................................................................ 14 Figure 3.3 State Machine Model.................................................................................... 15 Figure 3.4 Visit Structure with Back/Forward Behaviors .......................................... 16 Figure 3.5 Safe Navigation Box...................................................................................... 17 Figure 3.6 Back/Forward Behavior with Presence of Safe Navigation Box .............. 17 Figure 3.7 Exception Management in Safe Navigation Box........................................ 19 Figure 3.8 Hotel Booking Model Example.................................................................... 20 Figure 3.9 Example of Differences of Visit Sequence with Hotel Booking ................ 22 Figure 3.10 Back/Forward Behavior Example in Online Hotel Booking .................. 23 Figure 4.1 XML Structure of Hotel Booking flow ....................................................... 26 Figure 4.2 XML Structure of Visit Log File ................................................................. 27 Figure 4.3 XML Structure of Visit Log File ................................................................. 27 Figure 4.4 Handle Event Sequence Diagram................................................................ 30 Figure 4.5 HandleBack Sequence Diagram .................................................................. 31 Figure 4.6 Loading Data into States Sequence Diagram............................................. 32 Figure 4.7 API Class Diagram ....................................................................................... 35 Figure 4.8 Handle Event Activity Diagram .................................................................. 37 Figure 4.9 HandleBack Activity Diagram .................................................................... 39 Figure 4.10 HandleForward Activity Diagram ............................................................ 40 Figure 5.1 Architecture of Web Application used in the Implementation ................ 44 Figure 5.2 DOM tree of the Web Flow.......................................................................... 46 Figure 5.3 State Machine Description Example with SimPL Graphical Editor ....... 54 Figure 5.4 : Process of System Family Configuration using SimPL for WebFlow... 55 Figure 5.5 Configuration of SimPL for WebFlow Family .......................................... 56 Figure 5.6 Template for Generating WebFlow.xml from the Graphical Editor ...... 57

v

CHAPTER I

INTRODUCTION Recently, the web has become a popular tool for doing business quickly and effectively. Users now can book a hotel room, plan travel, trade in stocks, bid on auctions, and access many different services online with only few clicks. The company now can bring itself to a new level-from local to global -by using business-support web application (a desktop-like application but can be accessed globally through internet). With the increasing continuously in speed of the internet broadband, web application has become more and more accessible and continuously evolved to increase user experience and interactivity. 1.1

Problem The web has evolved from a platform for navigating hypertext

documents to a platform for implementing complex business applications, where user interaction relies on richer interaction paradigms such as RIA (Rich Internet Application), AJAX (Asynchronous JavaScript And XML), that include partial page updates, asynchronous interactions, and several kinds of events, generated by both users and systems. In this context, the original interaction paradigm of the Web, based on a simple navigation approach of moving from one page to another is too simplistic. Browsers themselves, that still provide the traditional features of Back and Forward page navigation along the browsing history, and inadequate for dealing with the complexity of current applications. For instance, the web application behavior is indeterministic with respect to the actions allowed by current browsers. Depending on the browser and on the application, different behaviors can occur when: 1

Introduction

 The user clicks on the Back and Forward buttons in a page where some fields were filled in, sometimes the data is preserved, sometimes it is lost (e.g when entering personal details for ticket purchasing in Trenitalia: www.trenitalia.it );  The user clicks on the Back button when browsing an AJAX application, often he is sent back to the initial state of the whole application (see www.mangooutlet.com a well-known web site for purchasing garments; www.gmail.com ;…);  Or after committed the transactions, user clicks back buttons and, acknowledging it or not clicks confirm again, this can lead to double record (www.surveymonkey.com )  Or the user navigates back on a link where a side effect had been triggered (e.g. updating some data, see Amazon bug).  The behavior after exceptions and errors (e.g. session timeout) is also indeterministic. 1.2

Proposed Solution These issues complicate the modeling of complex web application

(especially in term of navigation context), and hamper the user experience. We propose to evolve the interaction paradigm by moving the web (and the supporting browsers) from the browsing paradigm based on Pages, with related to Back and Forward actions, to a full-fledged interactive application paradigm based on the concept of state, and the introduction of a web flow controller which control the whole navigation interaction in one central place. We also provides the concept of storing all user visits (a move from one state to another is a Visit) to support in creating back and forward buttons inside the application. These buttons can be managed to avoid exceptions and errors in navigation. This results in a safer interaction environment where users can freely navigate through the web application and undo/redo his actions without running into unexpected behaviors. 2

Introduction

Our contribution consists in: 1) Defining a design-time modeling approach based on finite state machine for describing Web application interfaces 2) Defining the concept of the safe navigation to provide the safeness for transactional states in term of navigation. 3) Providing the concept of back tracking (visits) to allow user freely undo/redo actions within the application. This is to provide the applications with their own back/forward buttons. 4) Providing an Implementation for the model based on XML scheme to simplify the designing and developing phases. We also introduce the concept of State Machine Controller (SMC) which controls the whole navigation flow which automatically computes the next/previous state of the application, based on the current state and user event. 5) Providing a log structure to store data and navigation history of the user with respect to session to support redo/undo mechanism and to deal with exceptional behaviors and errors in term of data lost and timeout. 1.3

Thesis Structure

This thesis consists of a number of chapters: 1) Chapter 1: Chapter 1 includes introduction about the thesis topic, the problem of web navigation and proposed solutions 2) Chapter 2: Providing background technologies used in developing web applications 3) Chapter 3: Introducing the finite state machine to model safe navigation interface. We also introduce the concept of safe navigation box to secure the internal transaction in term of navigation, and the concept of visits (move from one state to another) which supports undo/redo behavior

3

Introduction

4) Chapter 4: Describing the metadata structure of the model. This is then used by the run-time controller components to manage the state of the web application. The later of this chapter introduces the designing phase of the runtime API (Application

Programming

Interface) to provide those

components. 5) Chapter 5: Based on the design in chapter 4, we move to the implementation phase to implement the API. In this chapter, the required technologies needed to implement the API are also described. 6) Chapter 6: Conclusion and Future work: review the topic covered in this project and discuss future works needed to be done to improve the project.

4

CHAPTER II

BACKGROUND 2.1

Web Application Web application is an application that is accessed via web browser over

a network such as the Internet or an intranet. It is a software application that is coded in a browser-supported language (such as HTML, PHP, JavaScript, Java, etc.) and reliant on a common web browser to render the application executable. Web applications are popular due to the ubiquity of a client or thin client. Common web applications include webmail, online retail sales, online auctions, wikis, and many other functions [1]. In web applications, the site usually uses forms for navigating from one page to another. Hyperlinks are used to submit the content of a form to the server, and then the server returns the next page (or the same page with the modified content). For this model, the same URL can be reused for the whole application. The back/forward button can record all the data which was posted to or get from server. Thus, if the user wants to go back, the data can be reposted again. 2.2

Stateless and Stateful

A state is a unique configuration of information in a program. In a finite state machine, a state is a set of instructions which will be executed in response to the machine’s input. The state can be thought as a analogous to a practical computer’s main memory [2]. A state can be understood as a set of properties transmitted by an object to the viewer (user). 5

Background

FOLDOC defines state as how something is, its configuration, attributes, condition or information content. Virtually, all software have states. The state is considered to be a point in some space of all possible states. A software changes from one state to another over time when triggered by some kind of event. The event could be a network message, a timer expiring or an application message. Components that do not have state that is there is no trigger that cause a transition, are called stateless [3]. A web application that relies upon state is stateful, and the one does not relies on state is stateless. However, it is still a debate when one says that HTTP is stateless protocol and AJAX is stateful. In traditional web application, each browser web page interacts with the server by sending only one request to sever and server reply to the page by sending back one response. Each time the response is sent, the whole page is reloaded. In RIC (Rich Internet Application) and in AJAX (Asynchronous JavaScript and XML), each page can interact with the server by sending more than one requests, and the server responses to each request individually. Thus, the page is partially uploaded when one response is sent. In this circumstance, the traditional web application is considered stateless (only one state per page) but AJAX is stateful (more than one states in one page). 2.3

Model-View-Controller (MVC) The traditional architecture of web application consists of three tiers:

Client tier, middle tier and database tier.

6

Background

Figure 2.1 Traditional Web Application Architecture

The middle tier is the most complex tier; it has the responsibility of handling HTTP request from client, developing services needed and returning the response to the client. The fundamental functions provided by middle tier are:  Receive requests and send response to browser  Dynamically generate user interfaces  Execution of business logic  Database communication MVC (Model-View-Controller) is an architectural pattern used to model the middle tier. It is used to isolates business logic from user interface. With MVC, an application can be easier to modify with respect to the visual appearance of the application or the underlying business process without affecting the other. MVC consist of three components: Model, View and Controller. The model represents the information (data) of the application; the view corresponds to elements of the user interface such as text, checkbox items, and so forth. The controller manages the communication of data and the business rules used to manipulate the data to and from the model.

7

Background

Figure 2.2 Components of MVC

Figure 2.2 illustrate the structure of MVC. The client first sends requests to the controller. The controller defines the behavior of client based on request. It then maps user actions to model updates. The controller then decides which components to invoke from the model. The model represents the business logic and provides functions to perform requests and update database. The view presents the data in the model and results of the request. MVC benefits fall into multiple categories: [4]  Separation of concerns in the codebase  Developer specialization and focus  Parallel development by separate teams The Pattern MVC is used to organize the structure of interactive software application. Its goal is to separate these functions and to facilitate maintenance and scalability of applications. It can be used for both traditional desktop application and for web applications. 8

Background

Figure 2.3 Example of Architecture of MVC in Java-based Web Application

The model architecture in figure 2.3 introduces a servlet between the browser and the JSP (Java Server Page) pages in Java-based web application. This servlet acts as a controller to handles the incoming requests. It is based on request URL, input parameters, the rule of selecting the appropriate view instance, and the Java Beans which represent the model necessary to view [5]. The applications that rely on this architecture are significantly easier to maintain and improve. The controller servlet provides a single point of control for security and logging. The model 2 is recommended for most web applications, especially for the large and complicated applications which require a lot of resources.

9

Background

2.4

Jakarta STRUTS Framework

Figure 2.4 Struts Framework Architecture

In Java web application, the client usually submits information to the server via web form. The information is either goes to java servlet to processes it, interacts with a database and produces HTML-formatted response, or it is given directly to a JavaServerPages(JSP) document which combines HTML and Java code to achieve the same result. Both approaches are often inadequate for large project because they mix application logic with presentation and make maintenance difficult [6]. The goal of Struts framework is clearly separate the model from the view and controller. Struts provides the controller and facilitates the writing of templates for the view or presentation layer. The web application programmer is responsible for writing the model code, and for creating a central configuration file struts-config.xml which binds together model, view and controller. 10

Background

Request from the client are sent to the controller in the form of “action” defined in the configuration file, if the controller receives such a request, it calls the corresponding action class which interacts with the applicationspecific model code. The model code returns an “actionForward” to tell the controller which output page to send to the client. Information is passed between model and view in the form of special JavaBeans. A powerful custom tag library allows it to read and write the content of these beans from the presentation layer without the need for any embedded Java code [7]. 2.5

XML XML is stand for Extensible Markup Language. It is a specification for

creating custom markup languages. It is classified as an extensible language, because it allows the user to define the mark-up elements. The purpose of XML is to share structured data, especially over the internet. It also helps the application to encode documents and the serialize data. [8] XML in combination with other standards makes it possible to define the content of a document separately from its formatting, making it easy to reuse that content in other applications or for other presentation environments. Most importantly, XML provides a basic syntax that can be used to share information between different kinds of computers, different applications, and different organizations without needing to pass through many layers of conversion. 2.6

Graphical Interface - SPL SPL (Simple Production Line) is a graphical editor used to model

concrete product and code generator; however, this tool can be customized to be used as a graphical editor for describing our finite state machine and code generator for state view. Technologies used: 11

Background

 the system family configuration file is an XML file  the graphical editor is part of the Graphical Instantiation Environment (GIE) Eclipse plugin  the code generator is a Java program and uses the generic text templating engine Velocity with the Velocity Template Language (VTL) See the article for more information on SimPL and Section 5.3r the integration of WebFlow with SimPL. For more information , see [9]

12

CHAPTER III

CONCEPTUAL MODEL 3.1

Why New Model Recently, most web based applications are stateful. Any application

in which the user enters all data required for a single business transaction happens in multiple pages, (e.g Shopping cart checkout). Partial data from early pages is either stored in http session or written to a database, and this is explicitly managed by the application.

Figure 3.1 Traditional Stateful Request-Driven Web Application

Traditional web frameworks (example Jakarta Struts) rely on the request driven approach, where each page submits to a distinct controller, and each controller only responsible for a single step in the overall process 13

Conceptual Model

(figure 3.1). The problem with this model is that many navigation paths can be difficult to manage, and there is no central place to manage all navigation; instead, each navigation is managed by a distinct controller. This is very difficult to maintain because changing the navigation path or adding new states can result in changing in code of many related files.

Figure 3.2 Process-Driven Web Application

Our new navigational model based on the finite State Machine which defines all navigation in a central location (in one xml file) and treats the entire interaction as one algorithm (figure 3.2). With this model, we define an internal meta model structure using XML schema, and then we build a controller to manage that structure. The designer models the state machine in a central xml file, and the controller can refer to that file to automatically manage the transactions of the application. We offer the definition of visit log files. For each transaction, we define a log file to store all user activities when interacting with the application. This log file is used to support the undo and redo mechanism. 14

Conceptual Model

We then build one controller which automatically decides what to do and where to go based on events trigged by the user. This controller also creates the log file to automatically store user data and provides undo and redo mechanism for the web application. 3.2

State Machine Concept We propose a viewpoint shift in the design of Web applications:

instead on designing applications based on pages, we move to a design based on states.

Figure 3.3 State Machine Model

In our proposal Web application navigation is represented as state machines. It consists of series of steps call “states”. Entering a state typically results in a view being displayed to the user. In each state, there are some possible events that can happen according to user actions or decisions. These events can trigger transitions to other states. A single web page can comprise several states (in that case, pages are modeled as submachines internally composed of substates), depending on the granularity chosen by the designer. The state change is basically triggered by an user action (e.g., click, submission of data in a form, and so on).The next states are computed (triggered) based on user event. This is called transition. 3.3

Undo/Redo Mechanism Concept For each event triggered by user, user will be direct to a specific state

and once the event is triggered, the current state, its event and its inputted 15

Conceptual Model

data will be saved into the storage (a log file). The storage consists of a sequence of states user has visited.

Figure 3.4 Visit Structure with Back/Forward Behaviors

The storage stores the events, the inputted parameters/data associated with each state. According to the model, we can define the back tracing: Every move to a state is called Visit. Obviously, the same user can perform several visits to the same state. The visits trace is permanently stored according to the granularity chosen by the designer in the state model, to allow undo/redo computation. Figure 3.4 shows an example of undo and redo performed by the user based on the state model. 3.4

Safe Navigation Concept Explain the concept of a safe navigation box: the behavior expected

when navigating through states within a safe navigation box. The safebox is one local- transaction (or sub-transaction or sub-flow) of the whole web

16

Conceptual Model

flow transaction. It consists of a series of steps (or states) used to provide security of the local- transaction in term of navigation. (figure 3.5)

Figure 3.5 Safe Navigation Box

Figure 3.6 Back/Forward Behavior with Presence of Safe Navigation Box

Each safe transaction has an initial state which defines the start of the transaction, and a final-state which commits the transaction. There is only one initial-state and one final-state in each transaction. The final state of the transaction is the confirm state which belongs to the safebox. This final-state can redirect users to other states defined by designer. Declaring final-state for each transaction is compulsory. After modifying some fields and reaching the final state, user will be redirect to a state outside of the safebox (for example, homepage); and he will not be able to go back to other internal states inside the safe box. Instead, the 17

Conceptual Model

designer should provide functions to allow user to modify the data by using other transactions. With this property, we can avoid duplicate submits. Associated with the safebox, we provide storage to store all the states which user has visited. And more than storing the state of the data at that time, we also store the input data/parameters provided by the user. The log file is saved in the Server-side. They can keep track of user activities includes all the steps in the interaction and data provided by users.  Control navigation behaviors of the web application’s back and forward buttons When the user goes back or forth to a state visited before (using back and forward buttons provided by the application, not from web browser), the state is computed (and “initialized”) using the parameters provided by the user in the last computation which is saved in the logfile. However, once a transaction is completed (when user reaches the final state of a safe transaction (safebox), all visits to the internal state of the safebox will be deleted, thus user cannot go back to the state inside the safebox, but to the state which is outside of it. Figure 3.6 illustrates the back behaviour once user reaches the final state 4. Instead of going back to state 3 (of visit 3) which is inside the safebox, user can only go back to the state 1 (of visit 1). In contrast, if the user is at visit 3 he can go back freely to visit 2, and then visit 1.  Retrieve Data Data which is inputted by users are saved in the storage, and when user go back or undo, the data can be retrieved again.  Exception Management

18

Conceptual Model

Figure 3.7 Exception Management in Safe Navigation Box

If explicit management of exception/event is specified, the corresponding state is reached and the user will be directed there. Eg., if e1=“CancelTransaction”, the user will be directed to state Ex1 (Which will lead User to other State outside of the safebox). If e2= “timeout”, the user will be sent to state Ex2 when he comes back to the site. For non-specified events, the behaviour is the default one. Using the data storage (log file), the system can keep track of user activities. So, if an unexpected error, we could:  If the session is not expired o Resend him to the current page (the last one he visited) o Send him to the first page in the transaction (the initial-state) o Fresh start (remove all history of the data)  If the session has expired (all history of the states and the data are deleted)  Always a fresh start 3.5 

Symbols and Explanation States:

Transitional state

Final State

19

Conceptual Model



Transitional State: The state is a navigation step in one webflow transaction. Transitional state is the state visible to the user (e.g input form, information page) and is transiable to other states

 Final State: Final state or confirm state when the transaction is completed, or say if the data is saved and processed in the database server. 

Events and Transition: Use the transition element to handle events that occur within a state. Usually the transition will take user from one state to another based on his action. This interaction is called event.



Safebox: is a blue box which contains the states needed to be secure in term of navigation. Usually safe box is a transaction region, example, a set of states that must be successfully accomplished altogether with allor-nothing semantics.



Exceptional Events e 2

3.6

Online Hotel Booking Application Example

Figure 3.8 Hotel Booking Model Example

20

Conceptual Model

Figure 3.8 shows the state machine of the Online Hotel Booking web application. There are 6 states needed to be accomplished to successfully book a hotel online.  First, a user enters the search page and inserts the search term (e.g Como). He clicks Search, and  The user will be directed to Search Result state with the list of hotels which match the search term  The user chooses one hotel and click View Hotel to see more details of the hotel.  The ViewHotel state is present, user then can book hotel or he can go back to the list in the SearchResult state.  If user choose book, he will need to input some information in the book hotel state (e.g number of days stay, date to stay, number of people, e.t.c)  User needs to go to next state to input personal Information (Name, address, personal document (passport, ID) and credit card information)  After all the information is inputted, he can confirm the booking transaction by choose event “Confirm”.  The confirm page is the final state of the transaction. It shows the summary information of the booking process. Here, user shouldnot be allow to go back During the transaction, before confirmation, user can go back and forth to all states to change his data. However, once he confirms the process, back and forward are not allowed. Here, the blue safebox consists of four states: HotelView, BookHotel, InputPersonalInformation and confirm page. They are all states needed to be accomplished altogether to secure the success of the hotel booking process. 21

Conceptual Model

Visits Storage Example of Online Hotel Booking In figure 3.9-a the user first visit state searchPage, performs event Search to go to SearchResult. He selects hotel and performs event Search to go to HotelView. From here, he chooses event Book and go to state BookHotel. In other situation, (figure 3.9-b) when the user is at the state HotelView, he chooses another event “ReturnToSearch” to go the “searchPage”. Here, the searchPage state is visited twice but with different path to get to. Each time the state is visited is called a visit.

(a)

(b) Figure 3.9 Example of Differences of Visit Sequence with Hotel Booking

Performing back with visits: Now let’s say if user goes back twice from visit 4 to visit 2 (figure 3.10), and he performs another event (backtoSearchPage), a new visit 5 is insert after visit 2. What happen with the visit 3 and visit 4? They should be deleted to avoid confusing in case user wants to go forward. And the new visit 5 should be set ID as visit 3. In other cases, when user goes back twice from visit 4 to visit 2, he changes data in this visit and performs the same event Select, then visit 3 and visit 4 shouldn’t be deleted, instead the visit 2 should be overwrite with the new inputted data. This allows user to retrieve the data he already

22

Conceptual Model

inputted in the visit 3 when he performs the same event again to go again to state 3 (of visit 3).

Figure 3.10 Back/Forward Behavior Example in Online Hotel Booking

Chapter Summary: Our new model provides these following properties:  Input data is saved into a restoration (log file) (avoid retyping or data lost)  Provide Back and Forward buttons inside the application.  Back/Forward behaviors of the application are controlled (transition property)  Confirmed/Committed State (Only one-way out: Commit or Abort) to avoid duplicate submits or data lost (as in case of Amazon Bug) 

Error Handlings: once transaction is committed, user cannot go back. Instead, user has to use event specified by designer, for example Modify transaction

23

CHAPTER IV

DESIGNING META DATA STUCTURE AND API FOR THE MODEL This chapter describes the designing phase of the Application Programming Interface (API) for our Finite State Machine. First, we design an internal meta data structure, and then we design the API that accesses, updates and processes the data structure. This meta data structure contains static information about the model (states, transitions, etc.) as well as runtime dynamic information (current state the user is in, input parameters, user events). We describe Webflow.xml file to store static information about the model; and sessionID_logFile.xml to store runtime dynamic information about visits. 4.1

State Machine Description

4.1.1 Webflow.xml It is possible to define the state machine with the Domain specific language by using xml file. We can define the state machine programmatically. Web Flow

Each flow starts and ends with ……………..

States: Each flow consists of sequence of different states. We categorize states into “Initial State”; “Main State” and “Final State”. Each state is addressed by one unique id, and the path to show the URL (Uniform 24

Designing -Meta Data

Resource Locator) or URI (Uniform Resource Identifier) that lead to that state. Initial State: the state when user first enters the safebox transaction.

State : is state that can trigger some events, it defines a step of the flow

If the state doesnot belong to a safebox then the attribute “safebox” should be eliminated

Final State: the end state when the safebox transaction is finished.

The is an element or child node of the root note . Each element has obligated attributes “id” and “path”. Attribute “id” defines the id of the state in the whole flow. This id should be unique for each state. Attribute “path” defines the path which stores the state. The value of the “path” can be URL (Uniform Resource Locator) or URI (Uniform Resource Identifier), depends on the navigation design. With the state which belongs to a safe box, the attribute “safebox” have to be defined. The value of this attribute indicates the name of the safebox. In one application there can be more than one safebox, so defining name for each safebox is necessary. In side a safebox there must be an initial state and final state. If a state is the initial one, then that state needs to define the attribute “status” with the value of “initial”, and the value should be “final” for the later. If the state is not an initial nor final one, then we do not have to declare attribute “status”. If the state doesnot belong to a safebox, the attribute “safebox” and “status” should be eliminated

25

Designing -Meta Data

Transition: The transition is used to handle events happen within a state. Usually, when an event occurs, the transition will lead user to another state in the flow. The tag is an element within the element. In one node there can be more than one element . The transition is a move from this state to another or itself, based on different event.