lecture 11 core state machines i
play

Lecture 11: Core State Machines I 2016-12-08 Prof. Dr. Andreas - PowerPoint PPT Presentation

Software Design, Modelling and Analysis in UML Lecture 11: Core State Machines I 2016-12-08 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universitt Freiburg, Germany 11 2016-12-08 main Content Recall :


  1. Software Design, Modelling and Analysis in UML Lecture 11: Core State Machines I 2016-12-08 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal Albert-Ludwigs-Universität Freiburg, Germany – 11 – 2016-12-08 – main –

  2. Content • Recall : Basic Causality Model • Event Pool • insert, remove, clear, ready. • System Configuration • implicit attributes : stable , st , and friends. • system state plus event pool • Actions • simple action language . • transformer : effects of actions. – 11 – 2016-12-08 – Scontent – 2 /34

  3. Roadmap: Chronologically Syntax : (i) UML State Machine Diagrams. (ii) Def.: Signature with signals . N UML (iii) Def.: Core state machine . W E CD , SM � � OCL CD , SD (iv) Map UML State Machine Diagrams S ! � � to core state machines. Model S = ( T , C , V, atr ) , SM expr S , SD ! � Semantics : � M = ( � D S , A S , � SM ) B = ( Q SD , q 0 , A S , � SD , F SD ) The Basic Causality Model � (v) Def.: Ether (aka. event pool) ! ( cons 0 , Snd 0 ) � = ( � 0 , � 0 ) ( � 1 , � 1 ) · · · w � = (( � i , cons i , Snd i )) i � N (vi) Def.: System configuration . � � � � � � � � � Instances u 0 � (vii) Def.: Event . Mathematics G = ( N, E, f ) (viii) Def.: Transformer . � UML OD (ix) Def.: Transition system , computation. (x) Transition relation induced by core state ma- chine. – 10 – 2016-12-01 – Sstmover – (xi) Def.: step , run-to-completion step . – 11 – 2016-12-08 – main – (xii) Later: Hierarchical state machines. 17 /32 3 /34

  4. 15.3.12 StateMachine (OMG, 2011b, 574) • Event occurrences are detected, dis- • The same conditions apply after the run- patched, and then processed by the state to-completion step is completed. machine, one at a time. • Thus, an event occurrence will never be • The semantics of event occurrence pro- processed [...] in some intermediate and in- cessing is based on the run-to- comple- consistent situation. tion assumption , interpreted as run-to- • [IOW,] The run-to-completion step is the completion processing . passage between two state configurations • Run-to-completion processing means of the state machine. that an event [...] can only be taken from • The run-to-completion assumption sim- the pool and dispatched if the processing plifies the transition function of the StM, of the previous [...] is fully completed. since concurrency conflicts are avoided • The processing of a single event occur- during the processing of event, allowing rence by a state machine is known as a the StM to safely complete its run-to- run-to-completion step . completion step . • Before commencing on a run-to- • The order of dequeuing is not defined , completion step , a state machine is leaving open the possibility of modeling – 10 – 2016-12-01 – Sstmcaus – in a stable state configuration with all different priority-based schemes. entry/exit/internal-activities (but not • Run-to-completion may be implemented – 11 – 2016-12-08 – main – necessarily do-activities) completed. in various ways . [...] 28 /32 4 /34

  5. h h signal i i n Example C E p x : Int 0 .. 1 D h h signal i i 0 .. 1 F • SM C : E [ n 6 = � ] /x := x + 1; n ! F s 1 s 2 • : SM D F/ s 1 s 2 /n := � F/x := 0 /p ! F s 3 ( { E } , { F } ) ( � , � ) ( { F } , � ) ( � 1 , � 1 ) ( � 2 , � 2 ) ( � 3 , � 3 ) ( � 4 , � 4 ) u 1 u 1 u 2 u 1 : C u 1 : C u 1 : C u 1 : C x = 27 x = 28 x = 28 x = 28 st = s 1 st = s 2 st = s 3 st = s 3 – 10 – 2016-12-01 – Sstmcaus – u 3 : E u 4 : F u 4 : F stb = 1 stb = 0 stb = 0 stb = 0 p p p p n n to u 1 to u 2 to u 2 u 2 : D u 2 : D u 2 : D u 2 : D – 11 – 2016-12-08 – main – st = s 1 st = s 1 st = s 1 st = s 2 stb = 1 stb = 1 stb = 1 stb = 0 29 /32 5 /34

  6. – 11 – 2016-12-08 – main – Ether 6 /34

  7. Recall: 15.3.12 StateMachine (OMG, 2011b, 563) • The order of dequeuing is not defined , leaving open the possibility of modeling different priority-based schemes. – 11 – 2016-12-08 – Sether – 7 /34

  8. Ether and OMG (2011b) The standard distinguishes (among others) • SignalEvent (OMG, 2011b, 450) and Reception (OMG, 2011b, 447). On SignalEvents , it says A signal event represents the receipt of an asynchronous signal instance. A signal event may, for example, cause a state machine to trigger a transition. (OMG, 2011b, 449) [...] – 11 – 2016-12-08 – Sether – 8 /34

  9. Ether and OMG (2011b) The standard distinguishes (among others) • SignalEvent (OMG, 2011b, 450) and Reception (OMG, 2011b, 447). On SignalEvents , it says A signal event represents the receipt of an asynchronous signal instance. A signal event may, for example, cause a state machine to trigger a transition. (OMG, 2011b, 449) [...] Semantic Variation Points The means by which requests are transported to their target depend on the type of requesting action, the target, the properties of the communication medium, and numerous other factors. In some cases, this is instantaneous and completely reliable while in others it may involve transmission delays of variable duration, loss of requests, reordering, or duplication. (See also the discussion on page 421.) (OMG, 2011b, 450) – 11 – 2016-12-08 – Sether – 8 /34

  10. Ether and OMG (2011b) The standard distinguishes (among others) • SignalEvent (OMG, 2011b, 450) and Reception (OMG, 2011b, 447). On SignalEvents , it says A signal event represents the receipt of an asynchronous signal instance. A signal event may, for example, cause a state machine to trigger a transition. (OMG, 2011b, 449) [...] Semantic Variation Points The means by which requests are transported to their target depend on the type of requesting action, the target, the properties of the communication medium, and numerous other factors. In some cases, this is instantaneous and completely reliable while in others it may involve transmission delays of variable duration, loss of requests, reordering, or duplication. (See also the discussion on page 421.) (OMG, 2011b, 450) – 11 – 2016-12-08 – Sether – Our ether ( → in a minute) is a general representation of many possible choices . Often seen minimal requirement : order of sending by one object is preserved. 8 /34

  11. Ether aka. Event Pool Definition. Let S = ( T , C , V, atr , E ) be a signature with signals and D a structure. We call a tuple ( Eth , ready , ⊕ , ⊖ , [ · ]) an ether over S and D if and only if it provides • a ready operation which yields a set of events (i.e., signal instances) that are ready for a given object, i.e. ready : Eth × D ( C ) → 2 D ( E ) • a operation to insert an event for a given object, i.e. ⊕ : Eth × D ( C ) × D ( E ) → Eth • a operation to remove an event, i.e. ⊖ : Eth × D ( E ) → Eth – 11 – 2016-12-08 – Sether – • an operation to clear the ether for a given object, i.e. [ · ] : Eth × D ( C ) → Eth . 9 /34

  12. Example: FIFO Queue A (single, global, shared, reliable) FIFO queue is an ether: • Eth = ( D ( C ) × D ( E )) ∗ the set of finite sequences of pairs ( u, e ) ∈ D ( C ) × D ( E ) • ready : Eth × D ( C ) → 2 D ( E ) � { ( u 1 , e ) } , if u 1 = u 2 (( u 1 , e ) .ε, u 2 ) �→ ∅ , otherwise • ⊕ : Eth × D ( C ) × D ( E ) → Eth ( ε, u, e ) �→ ε. ( u, e ) • ⊖ : Eth × D ( E ) → Eth � ε , if e 2 = e 1 ( ε. ( u, e 1 ) , e 2 ) �→ ε. ( u, e 1 ) , otherwise – 11 – 2016-12-08 – Sether – • [ · ] : Eth × D ( C ) → Eth remove all ( u, e ) from ε 10 /34

  13. Other Examples • One FIFO queue per active object is an ether. • One-place buffer. • Priority queue. • Multi-queues (one per sender). • Trivial example: sink, “black hole”. • Lossy queue ( ⊕ needs to become a relation then). • ... – 11 – 2016-12-08 – Sether – 11 /34

  14. System Configuration – 11 – 2016-12-08 – main – 12 /34

  15. System Configuration Definition. Let S 0 = ( T 0 , C 0 , V 0 , atr 0 , E ) be a signature with signals, D 0 a structure of S 0 , ( Eth , ready , ⊕ , ⊖ , [ · ]) an ether over S 0 and D 0 . Furthermore assume there is one core state machine M C per class C ∈ C . A system configuration over S 0 , D 0 , and Eth is a pair ( σ, ε ) ∈ Σ D S × Eth where • S = ( T 0 ˙ ∪ { S M C | C ∈ C 0 } , C 0 , V 0 ˙ ∪ {� stable : Bool , − , true , ∅�} ˙ ∪ {� st C : S M C , + , s 0 , ∅� | C ∈ C } ˙ ∪ {� params E : E 0 , 1 , + , ∅ , ∅� | E ∈ E 0 } , { C �→ atr 0 ( C ) ∪ { stable , st C } ∪ { params E | E ∈ E 0 } | C ∈ C } , E 0 ) – 11 – 2016-12-08 – Sstmscnf – • D = D 0 ˙ ∪ { S M C �→ S ( M C ) | C ∈ C } , and • σ ( u )( r ) ∩ D ( E 0 ) = ∅ for each u ∈ dom( σ ) and r ∈ V 0 . 13 /34

  16. System Configuration: Example C ( σ, ε ) ∈ Σ D S 0 = ( T 0 , C 0 , V 0 , atr 0 , E ) , D 0 ; S × Eth where x : Int • S = ( T 0 ˙ ∪ { S M C | C ∈ C } , C 0 , V 0 ˙ ∪ {� stable : Bool , − , true , ∅�} ˙ ∪ {� st C : S M C , + , s 0 , ∅� | C ∈ C } c 0 .. 1 ˙ ∪ {� params E : E 0 , 1 , + , ∅ , ∅� | E ∈ E 0 } , { C �→ atr 0 ( C ) ∪ { stable , st C } ∪ { params E | E ∈ E 0 } | C ∈ C } , E 0 ) � � signal � � • D = D 0 ˙ ∪ { S M C �→ S ( M C ) | C ∈ C } , and E • σ ( u )( r ) ∩ D ( E 0 ) = ∅ for each u ∈ dom( σ ) and r ∈ V 0 . b : Bool � � signal � � F a : Int SM C : • s 1 – 11 – 2016-12-08 – Sstmscnf – s 2 s 3 14 /34

Recommend


More recommend