1 / 29

Statecharts Semantics

Statecharts Semantics. Executable Visual Languages for System Development Fall 2010. History. This lecture is based on the paper “The Rhapsody Semantics of Statecharts” Based on the statemate semantics paper by Amnon Naamad.

eldora
Download Presentation

Statecharts Semantics

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. Statecharts Semantics Executable Visual Languages for System Development Fall 2010

  2. History This lecture is based on the paper “The Rhapsody Semantics of Statecharts” Based on the statemate semantics paper by Amnon Naamad D. Harel and A. Naamad, "The STATEMATE Semantics of Statecharts", ACM Trans. on Software Engineering Method. 5:4 (October 1996), 293-333.

  3. Implementing Systems Rhapsody (OO) since 1996 StateMate since 1986 We will discuss only Rhapsody semantics

  4. Summary • Types of States (Syntax) • Events • Actions • Steps • Junctions, Conditions (syntax) • Scope • Conflicting Transitions • Equivalent Constructions (syntax vs. semantics) • Excluded: models of time, synchronicity, history, threads D. Harel and H. Kugler, "The Rhapsody Semantics of Statecharts (or, On the Executable Core of the UML)", Integration of Software Specification Techniques for Applications in Engineering, (H. Ehrig et al., eds.), Lecture Notes in Computer Science, Vol. 3147, Springer-Verlag, 2004, pp. 325-354

  5. Basics • Statecharts describe modal behavior of classes (reactive classes – have statecharts) Class1 Class2 Class3

  6. Basics • class instances at run time have their own active configuration Instance3:S1 Instance3:Class1 Instance2:S1 Class1 Instance2:Class1 Instance1:S1 Instance1:Class1 Instance2:Class2 Class2 Instance1:Class2 Instance1:S3 Class3 Instance1:Class3

  7. Type of States • Or-states have substates related to each other by “exclusive or” • And-states have orthogonal components that are related by “and”. Or states – S, B, C, D And states – A Basic states – B1, B2, C1, C2, D1, D2, E

  8. TransitionHandling • General syntax of a transition label: m[c]/a (all optional) • M – message • C – condition - guards the transition from being taken unless true when m occurs • A – action • The action / trigger can be: • Event - asynchronous: ObjectGEN(e) • Triggered Operation – synchronous m[c]/a

  9. Actions • Entry Action / Exit Action – entrance to / exit from a state • Static Reactions – noted by > symbol • Primitive operation (method calls) can be used as actions

  10. Static Reaction (SR) The transition to be carried out as long as the system is in the state in question

  11. Static Reaction (SR) The transition to be carried out as long as the system is in the state in question Rhapsody implementation: (syntactic sugar)

  12. Basic System Reaction - Step • The semantics define fully the effects of a step. • Events are managed by an event dispatcher in a queue. • A Step is a series of microsteps as part of a run-to-completion principle

  13. Basic System Reaction When a message is triggered: • Guard evaluated • The exit action of A • Action of transition (sequential order) • The entry of B • Active configuration updated m[c]/a

  14. System Reaction - Details • Calculations in a step are based on the current data values and state configuration. No double buffering - Changes that occur in a step may be sensed in the same step. • An event exists when dispatched for the duration of one step only • A guard with side effects can affect the system, considered bad practice

  15. Events Parameters Events are added to the event queue Event parameters: paramspi Event can have inheritance State C entered. If e2 is derived from e, event e2 will trigger any e transition

  16. Events When e is generated and both objects are in A, we get a feedback loop

  17. Triggered Operations Synchronous, may return a value Calling: Result = Objt(p1,p2,…) Replying: t / reply(17)

  18. Triggered Operations Invocation of triggered operation in the middle of a transition, has no effect, return value is undefined Both objects enter state B, no feedback loop

  19. Junctions Fork and Join are AND connectors Join connector Fork connector

  20. Junctions Junction and Condition are OR connectors junction connector Equivalent construct junction connector with a common label

  21. Conditions A condition connector has one incoming transition and can have several transition segments. What will be the final state in the following? Move to C1 - first all guards are evaluated, then the transition is performed and only when performing the transition is the action performed

  22. Scope The scope of a transitionis the lowest OR-state in the hierarchy of states that is a proper common ancestor of all the sources and targets oftransitions, including states that are implicit sources or targets of transition arrows appearing inthe transition. The scope in both cases is U Entering W as default is considered a different microstep Entry is high to low, Exit is low to high

  23. Scope From B2, C1 with message f B2,C1  B1, C2 Exited: B2, B, C1, C, A Entered: A, B, B1, C, C2 Transition depends on source and target not on how it is drawn Scope is S – the lowest OR state ancestor for B1, B2, C1, C2

  24. ConflictingTransitions (Nondeterminism) • Two transitions are in conflict if there is some common state that would be exited if any one of them were to be taken. • Rhapsody does not allow non-determinism • Strategy - lower level states have priority, more OO enables substates to override transitions in higher states. Inside-out priorities, according to source state. X One of the e events must be removed, or code cannot be generated. From A, the transition to B will be taken, since it is the lower level state. From E, the transition to F will be taken, since it is the lower source state.

  25. Priority of a static reaction Determined according to the state in which it is defined, lower source state has priority. If same source state, compound transition (CT) has higher priority. Transition to B will be taken, SR not.

  26. state without enabled default transition

  27. state without enabled default transitionequivalent construction Selection may depend on the system modeled

  28. New Methodology • Try to think states, not sequential code • What are the states • What are the transitions • The more experienced you are with textual code, the more you will need to avoid textual patterns

  29. Summary Types of States (Syntax) Events Actions Steps Junctions, Conditions (syntax) Scope Conflicting Transitions Equivalent Constructions (syntax vs. semantics) Excluded: models of time, synchronicity, threads D. Harel and H. Kugler, "The Rhapsody Semantics of Statecharts (or, On the Executable Core of the UML)", Integration of Software Specification Techniques for Applications in Engineering, (H. Ehrig et al., eds.), Lecture Notes in Computer Science, Vol. 3147, Springer-Verlag, 2004, pp. 325-354

More Related