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 D. Harel and A. Naamad, "The STATEMATE Semantics of Statecharts", ACM Trans. on Software Engineering Method. 5:4 (October 1996), 293-333.

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

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

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

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

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

Transition Handling 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

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

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

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

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

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

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

System Reaction – Details Object is deleted if explicitly deleted or its statechart enters a termination connector If the event queue is not empty, the top event is processed if the target object still exists Greediness - A maximal subset of non-conflicting transitions and static reactions is always executed

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

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

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

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

Junctions Fork and Join are AND connectors Join connector Fork connector

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

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

Default Transition Must be defined for any OR state Considered a microstep

History Stores most recent active configuration of a state In Rhapsody this is always “deep history” semantics

Scope The scope of a transition is the lowest OR-state in the hierarchy of states that is a proper common ancestor of all the sources and targets of transitions, including states that are implicit sources or targets of transition arrows appearing in the 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

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

Conflicting Transitions (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.

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.

Event Handling Racing conditions Example : hahar! ev3,ev1 -> ev2 <state_7,state_6> ev1,ev3 -> ev2 <state_8,state_6> Avoid by improving model

state without enabled default transition

state without enabled default transition equivalent construction Selection may depend on the system modeled

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

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