Verification by translation to UML-B Dr. Colin Snook January 2010
Outline • Overview of UML-B (and Event-B) • Features of the UML model • Translation to UML-B • Verifying a Safety Requirement • Conclusion FMCO Graz 29 th Nov 2010
Event-B • Systems modelling language – Closed Systems - No environment - No concept of ‘calling’ – State - Represented by Typed Variables – Spontaneous Transitions - Guarded events that alter the state – Refinement - More detailed state, reveals more detailed events • Formal modelling environment and toolset (Rodin) – Incremental static checker – Proof tools – Extensible 3 FMCO Graz 29 th Nov 2010
Small example of Event-B FMCO Graz 29 th Nov 2010
UML-B • Diagrammatic front end for Event-B • Close integration with Rodin platform for Event-B – Automatic translation to Event-B – Rodin static checker errors fed back to diagram – Provers and Model Checkers • ‘UML-like’ – Class Diagrams and Statemachines – Diagramatic notations for Refinement • Borrows from Event-B – Invariants, axioms, guards, actions FMCO Graz 29 th Nov 2010
Class Refinement Refinement New data New invariants FMCO Graz 29 th Nov 2010
State Machine Refinement Refinement Nested state machines Split transition (refined in nested state machines) FMCO Graz 29 th Nov 2010
At each refinement • Refine Data and Events – New class attributes and class events – New nested state machines and transitions • Add invariants – specify that a hazardous state is never reached • Add guards to events/transitions – to ensure invariants are obeyed • Prove – That the behaviour doesn’t violate the invariants – That the level refines the previous level FMCO Graz 29 th Nov 2010
Verification Intermediate Modelling/Verification itself Input material Goal step Epsilon Understandabl UML UML-B model e A layered model, (This version showing of the model Rodin modelling increasing detail should be platform with built in in gradual steps available transformation verification tools inc. transformation from work Consistent by York) Proof shows that prover and animator. the model is ‘well- Model is built in layers of formed’ ‘refinement’ Safe Proof shows that Model can be animated for the model satisfies validation against the original Generis xUML the formalised model or against test cases (from Euro-Interlocking) safety invariants Valid Interlocking Animation/testing Safety requirements are Safety shows that the represented by invariants requirements model is embedded within the UML- formalization equivalent to the B model input model (from the railways) FMCO Graz 29 th Nov 2010
Principle • Can’t prove that a model is the correct one (valid) – The prover doesn’t know what we want – Need Animation for this • We can prove 2 specifications are consistent – A behavioural model satisfies an invariant – A model refines another one • Why is this useful? – Say something in a simple way (abstraction) • More likely to be correct – Prove it remains correct when we refine it FMCO Graz 29 th Nov 2010
UML model of Interlocking: Translation to UML-B Dr. Colin Snook January 2010
UML Domain Model FMCO Graz 29 th Nov 2010
UML Behaviour model - Points external trigger internal trigger ignore send guard to GUI & railyard timeout FMCO Graz 29 th Nov 2010
UML Behaviour model - Routes send trigger message to points spontaneous transition FMCO Graz 29 th Nov 2010
UML Domain Model M7 M6 M6 + C5 M5 M4 M3 + C4 M2 + C3 M1 + C2 C1 M0 + C0 FMCO Graz 29 th Nov 2010
UML-B Refinements FMCO Graz 29 th Nov 2010
UML-B - M0 + C0 Modelling message passing M0 C0 ClassTypes (given sets) Class Action: buffer : ∈ BUFFEROWNER → ℙ (MESSAGE) FMCO Graz 29 th Nov 2010
UML-B - M3 Introducing Points C4 subtypes BUFFEROWNER FMCO Graz 29 th Nov 2010
UML Behaviour model - Points external trigger internal trigger ignore send guard to GUI & railyard timeout FMCO Graz 29 th Nov 2010
UML-B - M3 point_sm Guard: move_left ∈ buffer(self) Action: buffer(self) ≔ buffer(self) ∖ {move_left} FMCO Graz 29 th Nov 2010
UML-B - M4 Elaborating Points from any state FMCO Graz 29 th Nov 2010
UML-B - M5 Elaborating Points - Moving FMCO Graz 29 th Nov 2010
UML-B Route Axioms reqd by prover track layout constants FMCO Graz 29 th Nov 2010
UML Behaviour model - Routes trigger message to points FMCO Graz 29 th Nov 2010
UML-B Route state-machine Action: buffer ≔ (buffer {self ↦ buffer(self) ∖ {set_route}}) ( λ lp · lp ∈ left_points[{self}] ∣ buffer(lp) ∪ {move_left}) ( λ rp · rp ∈ right_points[{self}] ∣ buffer(rp) ∪ {move_right}) FMCO Graz 29 th Nov 2010
UML-B Route state-machine Guard1: ∀ lp · lp ∈ left_points[{self}] ⇒ lp ∈ dom(working_sm) ∧ working_sm(lp) = left_st Guard2: <same for right points> Guard3: ∀ t · t ∈ tracks[{self}] ⇒ t ∈ dom(ready_sm) ∧ ready_sm(t) = free_st FMCO Graz 29 th Nov 2010
Proof stats …. so far FMCO Graz 29 th Nov 2010
The prover helps debug models FMCO Graz 29 th Nov 2010
UML Safety Requirement 1 S-0001 A Point that is locked by an established route shall never move INVARIANT ‘no_move’: ∀ r,p · r ∈ route ∧ r is a route route_sm(r) = established_st ∧ r is established p ∈ (left_points[{r}] ∪ right_points[{r}]) p is a point of r ⇒ (p ∈ dom(working_sm) if p is working ⇒ then working_sm(p) ≠ moving_st) p is not moving FMCO Graz 29 th Nov 2010
Reflection • The original model isn’t correct, but even if it was… • The Safety Requirements look like they will be difficult to prove • The refinements are based on the model structure, not on abstraction of the essential properties • A more abstract model of safe behaviour would allow us to use refinement in a more progressive way (wrt proof) FMCO Graz 29 th Nov 2010
Summary • Work in Progress • UML-B version of UML model – fairly close correspondence… but not identical – refinement helps get the model right (consistency proofs) – proof is mostly quite easy (but not proving much) • Safety Invariant – proofs look quite hard, maybe impossible – PO’s will drive the model – may end up with a different model • (careful no to deviate from UML?) FMCO Graz 29 th Nov 2010
Thank you Questions?
Recommend
More recommend
