Software Design, Modelling and Analysis in UML Lecture 11: Core State Machines I 2015-12-10 Prof. Dr. Andreas Podelski, Dr. Bernd Westphal – 11 – 2015-12-10 – main – Albert-Ludwigs-Universit¨ at Freiburg, Germany
Contents & Goals Last Lecture: • What makes a class diagram a good class diagram? • Core State Machine syntax This Lecture: • Educational Objectives: Capabilities for following tasks/questions. • What does this State Machine mean? What happens if I inject this event? • Can you please model the following behaviour. • What is: Signal, Event, Ether, Transformer, Step, RTC. • Content: • UML standard: basic causality model – 11 – 2015-12-10 – Sprelim – • Ether • Transformers • Step, Run-to-Completion Step 2 /34
The Basic Causality Model – 11 – 2015-12-10 – main – 3 /34
6.2.3 The Basic Causality Model (OMG, 2011b, 11) “ ‘Causality model’ is a specification of how things happen at run time [...]. The causality model is quite straightforward: • Objects respond to messages that are generated by objects executing communication actions. • When these messages arrive, the receiving objects eventually respond by executing the behavior that is matched to that message. • The dispatching method by which a particular behavior is associated with a given message depends on the higher-level formalism used and is not defined in the UML specification (i.e., it is a semantic variation point). – 11 – 2015-12-10 – Sstmcaus – • E [ n � = ∅ ] /x := x + 1; n ! F • s 1 s 2 F/ s 1 s 2 /n := ∅ F/x := 0 /p ! F s 3 4 /34
6.2.3 The Basic Causality Model (OMG, 2011b, 11) “ ‘Causality model’ is a specification of how things happen at run time [...]. The causality model is quite straightforward: • Objects respond to messages that are generated by objects executing communication actions. • When these messages arrive, the receiving objects eventually respond by executing the behavior that is matched to that message. • The dispatching method by which a particular behavior is associated with a given message depends on the higher-level formalism used and is not defined in the UML specification (i.e., it is a semantic variation point). – 11 – 2015-12-10 – Sstmcaus – The causality model also subsumes behaviors invoking each other and passing information to each other through arguments to parameters of the invoked behavior, [...]. This purely ‘procedural’ or ‘process’ model can be used by itself or in conjunction with the object-oriented model of the previous example.” 4 /34
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 cessing is based on the run-to- comple- inconsistent 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 • The run-to-completion assumption sim- from the pool and dispatched if the pro- plifies the transition function of the StM, cessing of the previous [...] is fully com- since concurrency conflicts are avoided pleted. during the processing of event, allowing • The processing of a single event occur- the StM to safely complete its run-to- rence by a state machine is known as a completion step . – 11 – 2015-12-10 – Sstmcaus – run-to-completion step . • The order of dequeuing is not defined , • Before commencing on a run-to- leaving open the possibility of modeling completion step , a state machine is different priority-based schemes. in a stable state configuration with • Run-to-completion may be implemented all entry/exit/internal-activities (but not in various ways . [...] necessarily do-activities) completed. 5 /34
� � signal � � n Example C E p x : Int D 0 .. 1 � � signal � � 0 .. 1 F • SM C : E [ n � = ∅ ] /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 } ) ( ∅ , ∅ ) ( σ 1 , ε 1 ) ( σ 2 , ε 2 ) ( σ 3 , ε 3 ) u 1 u 1 – 11 – 2015-12-10 – Sstmcaus – u 1 : C u 1 : C u 1 : C x = 27 x = 28 x = 28 st = s 1 st = s 2 st = s 3 u 3 : E u 4 : F u 4 : F stb = 1 stb = 0 stb = 0 p p p n n to u 1 to u 2 to u 2 u 2 : D u 2 : D u 2 : D st = s 1 st = s 1 st = s 1 stb = 1 stb = 1 stb = 1 6 /34
� � signal � � n Example C E p x : Int D 0 .. 1 � � signal � � 0 .. 1 F • SM C : E [ n � = ∅ ] /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 – 11 – 2015-12-10 – Sstmcaus – 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 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 st = s 1 st = s 1 st = s 1 st = s 2 stb = 1 stb = 1 stb = 1 stb = 0 6 /34
– 11 – 2015-12-10 – main – Ether 7 /34
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 – 2015-12-10 – Sether – 8 /34
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. – 11 – 2015-12-10 – Sether – (See also the discussion on page 421.) (OMG, 2011b, 450) 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. 9 /34
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. – 11 – 2015-12-10 – Sether – ⊖ : Eth × D ( E ) → Eth • an operation to clear the ether for a given object, i.e. [ · ] : Eth × D ( C ) → Eth . 10 /34
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 – 11 – 2015-12-10 – Sether – � , if e 2 = e 1 ε ( ε. ( u, e 1 ) , e 2 ) �→ ε. ( u, e 1 ) , otherwise • [ · ] : Eth × D ( C ) → Eth remove all ( u, e ) from ε 11 /34
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”. – 11 – 2015-12-10 – Sether – • Lossy queue ( ⊕ needs to become a relation then). • . . . 12 /34
System Configuration – 11 – 2015-12-10 – main – 13 /34
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 } , 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 ) – 11 – 2015-12-10 – Sstmscnf – ∪ { stable , st C } ∪ { params E | E ∈ E 0 } | C ∈ C } , E 0 ) • 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 . 14 /34
– 11 – 2015-12-10 – main – References 33 /34
References OMG (2011a). Unified modeling language: Infrastructure, version 2.4.1. Technical Report formal/2011-08-05. OMG (2011b). Unified modeling language: Superstructure, version 2.4.1. Technical Report formal/2011-08-06. – 11 – 2015-12-10 – main – 34 /34
Recommend
More recommend
