CS 290 C Formal Models for Web Software

CS 290 C: Formal Models for Web Software Lecture 3: Modeling Navigation Instructor: Tevfik Bultan

Modeling Navigation • Many errors in web applications are due to incorrect handling of navigation • In this lecture we will argue that it is possible to model basic navigation structure of a web application using hierarchical state machines (i. e. , statecharts) • In a web application implementation, the navigation structure is buried in the code and is not easy to extract or understand – A formal model of the navigation structure can help in design, development, testing and verification of the navigation structure

Modeling web navigation with statecharts • Today I will discuss this topic based on the following paper: – “Modeling Web Navigation by Statechart” Karl R. P. H. Leung, Lucas C. K. Hui, S. M. Yiu, Ricky W. M. Tang. 24 th International Computer Software and Applications Confenrence (COMPSAC 2000)

Navigation Modeling • A navigation model should show the web pages are linked to each other: – Web page (or page): An html document returned by a web server in response to a URL request through HTTP – Hyperlink (or link): A directional link between a source and target webpage that is used for navigation. • Can be activated explicitly by the users, using a mouse click or can be invoked automatically by the browser on some predefined events (timeout, mouse movements, etc. ) • It is easy to see that one can generate a graph (or equivalently a state machine) from web pages and hyperlinks – However there are some complications

Complications • Web pages can be both static and dynamic: – Static web page: A web page that retains the same HTML for all the client requests of the same URL. It contains no reactive or executable components – Dynamic web page: A web page that returns different HTML for the URL (server side dynamic behavior) and can contain reactive or executable components (client side dynamic behavior) • Browser navigation capabilities – In addition to hyperlinks provided in web pages, browsers provide extra navigation capabilities based on back, forward buttons, history list, or the address bar (aka location bar or URL bar)

Complications • Intra vs. inter-page navigation – Inter-page navigation: This is the most common type of navigation where by activating a link in the source page we jump to the target page – Intra-page navigation: There may be links to different sections of the same page

Complications • Frame-based navigation – Frames in browser window makes concurrent viewing of web pages possible – The browser window is divided into frames, each containing a separate page for viewing – Navigation within frames can happen independently – Web pages in different frames can affect each other by using client side scripts • Navigation with multiple windows – Multiple browser windows can be used to support concurrent viewing of web pages in another way – Multiple window viewing differs from frames since windows can be created or destroyed independently

Complications • Dynamic content – Server side • A server can return different results for the requests to the same URL by creating the returned pages dynamically using server side scripts • For example a search engine will return different results for different search strings entered – Client Side • Client side programs (written in Java. Script, Flash etc. ) can dynamically define, enable or disable links without contacting the web server

Modeling navigation with statecharts • Modeling scope – Identify the pages that you want to have in the navigation model – Add all the pages that are the target of a link in the above pages also to the set (these will be used to model exit) • Events are modeled as tuples (target, position) – Target is the webpage denoting the target of a link – Position is the position in the target webpage

Modeling navigation with statecharts • If it is not possible to jump in different sections of a webpage (i. e. no intra-page navigation) than that webpage is modeled as a basic (atomic) state • If intra-page navigation is possible than we use an OR-state where each sub-state corresponds to a possible browsing position as identified by the “position” – A select connective is used to denote that one of the sub -states is selected for each incoming transition

Inter-page navigation • Links among pages are represented as transition arrows where the hyperlink activation is the event that triggers the transition • If multiple hyperlinks from one source page point to the same target page they are considered equivalent and represented with one arrow • The links can be available from all sub-states of a superstate (in which case the source of the arrow is the superstate) or from some sub-states of a super-state (in which case multiple arrows are used each originating in a different sub-state)

Grouping states • States which have a common set of links can be grouped as OR-states • This typically happens with tree-like menu structures which can be represented using OR-states • Again select connective can be used to combine transitions to sub-states of an OR-state

Modeling Frames • Frames can be modeled using AND-states where each frame corresponds to a sub-state • This allows independent navigation for each frame • If there are dependencies among frames (i. e. , clicking on a link in one frame triggers a change also in another frame), this type of behavior can be modeled by synchronization on evetns – All the events are broadcast to all parts of the statechart, so multiple transitions can be triggered by the same event • If the broadcast behavior is not wanted, then you can add the receivers identifier to the event to make sure that only the receiver reacts – Guard conditions can be used for synchronization

Modeling dynamic content • Server-side: Dynamic pages generated by server side scripts can be modeled as parameterized-OR states – Where the sub-state that is transitioned is identify by the input parameter where the event are modeled as tuples: (target, parameter) • Client-side: Client side dynamic behavior can be modeled using AND-states where the states modeling the client side dynamic behavior is one of the sub-states and the rest of the navigation model is another sub-state – Using the guard conditions, the client side dynamic behavior can enable or disable transitions

What can we do after generating navigation models? • As I said last week, after we obtain a formal model of the navigation behavior we can analyze it. • For example we can use verification tools to check its properties • However this brings up another problem, how are we going to characterize properties of navigation models? • For this we will briefly discuss temporal logics

Transition System • Transition systems are a very basic model used in automated verification • The idea is to model a system with just states and transitions – It is basically a flat state machine • A transition system T = (S, I, R) consists of – a set of states S – a set of initial states I S – and a transition relation R S S • Semantics of many formal languages (including sttaecharts) can be defined using transition systems

Execution Paths • An execution path is an infinite sequence of states x = s 0, s 1, s 2, . . . such that s 0 I and for all i 0, (si, si+1) R Notation: For any path x xi denotes the i’th state on the path (i. e. , si) xi denotes the i’th suffix of the path (i. e. , si+1, si+2, . . . )

Temporal Logics • Temporal logics are a type of modal logics – Modal logics were developed to express modalities such as “necessity” or “possibility” – Temporal logics focus on the modality of temporal progression • Temporal logics can be used to express, for example, that: – an assertion is an invariant (i. e. , it is true all the time) – an assertion eventually becomes true (i. e. , it will become true sometime in the future)

Temporal Logics • We will assume that there is a set of basic (atomic) properties called AP – These are used to write the basic (non-temporal) assertions about the system we are analyzing • We will use the usual boolean connectives: • We will also use four temporal operators: Invariant p : Gp (aka p) Eventually p : Fp (aka p) Next p : Xp (aka p) p Until q : p. Uq , , (Globally) (Future) (ne. Xt)

Atomic Properties • In order to define the semantics we will need a function L which evaluates the truth of atomic properties on states: L : S AP {True, False} So given a state of the transition system and an atomic property, the function L determines if the property holds on that state or not.

Linear Time Temporal Logic (LTL) Semantics Given an execution path x and LTL properties p and q x |= p q iff iff L(x 0, p) = True, where p AP not x |= p and x |= q x |= p or x |= q x |= X p x |= G p x |= F p x |= p U q iff iff x 1 |= p for all i 0, xi |= p there exists an i 0 such that xi |= q and for all 0 j < i, xj |= p

LTL Properties . . . Xp p . . . Gp p p . . . Fp p. Uq p p . . . p p q

LTL Equivalences • We do not really need all four temporal operators – X and U are enough (i. e. , X, U, AP and boolean connectives form a basis for LTL) F p = true U p G p = (F p) = (true U p)

LTL Model Checking • Given a transition system T and an LTL property p T |= p iff for all execution paths x in T, x |= p Model checking problem: Given a transition system T and an LTL property p, determine if T is a model for p (i. e. , if T |=p)

LTL Properties Transition System T = (S, I, R) p p s 1 s 2 s 3 s 4 T |= X p T |= F p T |= G p T |= F p S = {s 1, s 2, s 3, s 4} I = {s 3} R ={(s 1, s 2), (s 2, s 3), (s 3, s 1), (s 3, s 4), (s 4, s 3)} s 1 |= p s 2 |= p s 3 |= p s 4 |= p

Linear Time vs. Branching Time • In linear time logics we look at the execution paths individually • In branching time logics we view the computation as a tree – computation tree: unroll the transition relation Transition System s 1 s 2 s 3 Execution Paths s 4 s 3. . . Computation Tree s 3 s 4 s 3 s 1 s 2 s 3. . . s 4. . . s 1 s 2 s 1. . . s 3 s 4 . . . s 1. . .

Computation Tree Logic (CTL) • In CTL we quantify over the paths in the computation tree • We use the same four temporal operators: X, G, F, U • However we attach path quantifiers to these temporal operators: – A : for all paths – E : there exists a path • We end up with eight temporal operators: – AX, EX, AG, EG, AF, EF, AU, EU

CTL Equivalences • CTL basis: EX, EU, EG AX p = EX p AG p = EF p AF p = EG p p AU q = ( ( q EU ( p q)) EG q) EF p = True EU p • Another CTL basis: EX, EU, AU

CTL Model Checking • Given a transition system T= (S, I, R) and a CTL property p T |= p iff for all initial state s I, s |= p Model checking problem: Given a transition system T and a CTL property p, determine if T is a model for p (i. e. , if T |=p)

Model Checkers • There are model checking tools that can check LTL or CTL properties on transition systems • Two well-known model checkers – Spin: An LTL model checker • I will discuss this tool in the class – SMV: A CTL model checker • These tools can be used to check properties of finite state transition systems (such as statecharts specifications)

Example navigation properties in temporal logic • EF(mainpage): main page is reachable from initial pages • EF(mypage): mypage is reachable from the initial pages • AG(EF(mainpage)): main page is reachable from any state that is reachable from the initial pages • AG(homepage => EXEX(mypage)): it is possible to reach my page with two clicks from the homepage