1 / 34

Statecharts

CS 290C: Formal Models for Web Software Lecture 2: Navigation Modeling with Statecharts Instructor: Tevfik Bultan. Statecharts. A visual formalism for specifying hierarchical state machines “ A Visual Formalism for Complex Systems, ” David Harel, Science of Computer Programming, 1987

juanitaj
Télécharger la présentation

Statecharts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS 290C: Formal Models for Web Software Lecture 2: Navigation Modeling with StatechartsInstructor: Tevfik Bultan

  2. Statecharts • A visual formalism for specifying hierarchical state machines • “A Visual Formalism for Complex Systems,” David Harel, Science of Computer Programming, 1987 • Especially useful for modeling reactive systems • systems which continuously react to internal or external events without terminating • State machines in UML are based on Statecharts • Statecharts is a formal language, it has formal semantics

  3. Statecharts Statecharts characteristics: • Hierarchical grouping of states • superstates are formed by grouping other states • Superstates can be formed using AND composition or OR composition • When the system is in an AND-state it is in all of its substates • When the system is in an OR-state it is in only one of its substates • If a state has no substates it is an atomic state • Synchronization and communication between different parts of the system is achieved using events

  4. Statecharts • Initial (default)state is A • If event x occurs while in state A, the • next state will be B • If event y occurs while in state A, the • next state will be C x B A y t C D A basic state machine Given the event sequence: y, x, t Behavior of the state machine is: A  C  D The x event is ignored since it does not enable any transition when the system is in state C Note that we are interested in the behavior of the machine — the paths it takes (including the states it visits. This is different then using the state machines as language recognizers (as in automata theory or compilers) y t

  5. Statecharts: OR-states • D is an OR-state, its substates are A and C • When the system is in state D it is either in A • or C (but not both) • The default state of D is A. When the system • transitions to state D it will go to state A unless • it is explicitly specified otherwise • While the system is in state A or C (meaning • it is in state D) if event t occurs it transitions • to B • While the system is in state B if event x • occurs the system transitions to state D, since • the default state in D is A, it transitions to A D x A t y B C z A hierarchical state machine

  6. Statecharts: OR-states D x A Given the event sequence: x, y, t, z Behavior of the hierarchical state machine: B  D(A)  D(C)  B  D(C) Behavior of the equivalent basic state machine: B  A  C  B  C t y B x y t z C z A hierarchical state machine x A t y B x y t z t C z Equivalent basic state machine

  7. Statecharts: Transitions • Statechart transitions have a source state and a target state and are labeled as trigger-event [guard-condition] / generated-events source state target state trigger-event[guard-condition]/action

  8. Statecharts: Transitions • The transition is enabled if • the trigger-event occurs, and • the guard-condition is true while the system is in the source state of the transition • A transition can be taken if it is enabled • The events can be generated • by the state machine itself (internal events), or • can be generated by the environment (external events)

  9. Statecharts: Transitions • When a transition is taken • it generates the generated-events (a set of events) • which may enable other transitions • and, it transitions to its destination state • Guard condition is a boolean expression that combines predicates in the form In(state) • In(state) evaluates to true when the system is in the specified state

  10. Statecharts: Transitions • Two transitions are conflicting if they cannot be taken at the same time • If two conflicting transitions are enabled at the same time, one of them is taken non-deterministically • Two outgoing transitions from state A are • conflicting (they cannot be taken at the • same time). • When event t occurs if the system is in state • A both transitions are enabled. • Since they are conflicting one of them is • taken nondeterministically A t t C B

  11. Statecharts: AND-states (concurrency) • R is and AND-state • When the system is in the AND-state • R, it is both in state A and state D • A and D are OR-states • When the system is in state A it is • either in state B or in state C (but not • in both) • When the system is in state D it is in • Only one of E or F or G R A D t B E z F v x y[in G] G x C A hierarchical state machine

  12. Statecharts: AND-states (concurrency) R • Note that event x causes • a synchronization between • states A and D when A • is in B and D is in F. • They make a concurrent • transition: • A goes from B to C • D goes from F to G A D t B E z F v x y[in G] G x C A hierarchical state machine t z B-F Equivalent basic state machine B-E B-G x v x x y v C-G C-E x C-F z t

  13. Statecharts: State hierarchy We can think of the state hierarchy as a tree: R R(AND) A D t B E z F v x y[in G] A(OR) D(OR) G x C B C E F G A hierarchical state machine • R is the root state • B,C, E, F, G are the leaf (atomic) states • Other than the atomic (leaf) states each • state is marked as an OR or an AND state

  14. Statecharts: State hierarchy R A D t B E A hierarchical state machine z F v x y[in G] G x C Given the event sequence: x, z, y, t, v The behavior of the statechart is: R(A(B))-R(D(F))  R(A(C))-R(D(G))  R(A(C))-R(D(F))  R(A(C))-R(D(E))  R(A(C))-R(D(G)) It is hard to read the above representation. We can show the behavior using only the atomic states (assuming they have unique names): B-F  C-G  C-F  C-E  C-G x z t v x z t v

  15. Statecharts: Internal vs. External events • Internal events have higher priority • when an internal event is generated, first the transitions enabled by the internal event is taken before the next external event is considered Given the input event sequence: x,y The behavior of the statechart is: A  C  B  C A x/t y x t y t C B y

  16. Statecharts: History Entrances • Entering the history state (marked with H in a circle) in state D means that enter the most recently visited substate of D • What if substates of D have their own substates? • H* (deep history state) means enter all the most recently visited descendants R z A D H K t B E z w F v x y[in G] Given the input event sequence: x,w,z The behavior of the statechart is: B-F  C-G  K B-G G x C x w z

  17. StateCharts: Conditional Entrances • The statechart on the top can be equivalently represented using the statechart at the bottom • The conditional entrance combines multiple transitions that are triggered by the same event but have different guards • The outgoing edge of the conditional is taken based on which of the guards hold R e[P] K A e[Q] e[R] B C e R [P] C K A [Q] [R] B C

  18. StateCharts: Selection Entrances • The statechart on the top can be equivalently represented using the statechart at the bottom • The selection entrance combines multiple entrances that have different events • The outgoing edge of the selection is taken based on the event that is observed R e1 K A e2 e3 B C R e1 S K A e2 e3 B C

  19. Statecharts: Parameterized States • If there are set of substates that share common characteristics, they can be combined as a parameterized state • There is a substate for each value of the parameter R i in [1 .. 10] S-i

  20. Statecharts: An Example Alarm Shut Given the input event sequence: start, t_on, inc, dec, stop The behavior of the statechart is: Shut  Off-1  On-1  On-2  On-1  Shut t_on start stop Op Mode Vol start t_on On 1 t_off t_on inc dec inc dec stop Off 2

  21. Modeling Navigation with Statecharts • 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

  22. Modeling web navigation with statecharts • 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. 24th International Computer Software and Applications Confenrence (COMPSAC 2000)

  23. Navigation Modeling • A navigation model should show how 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.) • The question is can we generate a graph (or equivalently a state machine) from web pages and hyperlinks • There are some complications

  24. 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)

  25. 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

  26. 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

  27. 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 JavaScript, Flash etc.) can dynamically define, enable or disable links without contacting the web server

  28. 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

  29. Modeling navigation with statecharts • If it is not possible to jump in different sections of a webpage (i.e. no intra-page navigation), then 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

  30. 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 super-state (in which case the source of the arrow is the super-state) or from some sub-states of a super-state (in which case multiple arrows are used each originating in a different sub-state)

  31. 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

  32. 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

  33. 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 events 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

  34. What can we do after generating navigation models? • 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. • I will discuss a verification tool next week • However this brings up another problem, how are we going to characterize properties of navigation models? • I will discuss this also next week

More Related