Verification by translation to UML-B Dr. Colin Snook January 2010 - - PowerPoint PPT Presentation
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
January 2010
FMCO Graz 29th Nov 2010
FMCO Graz 29th Nov 2010
– 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
– Incremental static checker – Proof tools – Extensible
3
FMCO Graz 29th Nov 2010
FMCO Graz 29th Nov 2010
– Automatic translation to Event-B – Rodin static checker errors fed back to diagram – Provers and Model Checkers
– Class Diagrams and Statemachines – Diagramatic notations for Refinement
– Invariants, axioms, guards, actions
FMCO Graz 29th Nov 2010
New invariants Refinement New data
FMCO Graz 29th Nov 2010
Refinement Nested state machines Split transition (refined in nested state machines)
FMCO Graz 29th Nov 2010
– New class attributes and class events – New nested state machines and transitions
– specify that a hazardous state is never reached
– to ensure invariants are obeyed
– That the behaviour doesn’t violate the invariants – That the level refines the previous level
FMCO Graz 29th Nov 2010
Input material
Generis xUML
(from Euro-Interlocking)
Intermediate step
Epsilon UML (This version
should be available from work by York)
Modelling/Verification itself
transformation formalization Interlocking Safety requirements (from the railways)
Safety requirements are represented by invariants embedded within the UML- B model
Goal
transformation
UML-B model
Rodin modelling platform with built in verification tools inc. prover and animator. Model is built in layers of ‘refinement’
Model can be animated for validation against the original model or against test cases
Understandabl e A layered model, showing increasing detail in gradual steps Consistent Proof shows that the model is ‘well- formed’ Safe Proof shows that the model satisfies the formalised safety invariants Valid Animation/testing shows that the model is equivalent to the input model
FMCO Graz 29th Nov 2010
– The prover doesn’t know what we want – Need Animation for this
– A behavioural model satisfies an invariant – A model refines another one
– Say something in a simple way (abstraction)
– Prove it remains correct when we refine it
January 2010
FMCO Graz 29th Nov 2010
FMCO Graz 29th Nov 2010
external trigger internal trigger timeout guard ignore send to GUI & railyard
FMCO Graz 29th Nov 2010
send trigger message to points spontaneous transition
FMCO Graz 29th Nov 2010
M0 + C0 C1 M1 + C2 M2 + C3 M3 + C4 M6 + C5 M5 M4 M6 M7
FMCO Graz 29th Nov 2010
FMCO Graz 29th Nov 2010
M0
Class Action: buffer :∈ BUFFEROWNER → ℙ(MESSAGE)
C0
ClassTypes (given sets)
FMCO Graz 29th Nov 2010
C4
subtypes BUFFEROWNER
FMCO Graz 29th Nov 2010
external trigger internal trigger timeout guard ignore send to GUI & railyard
FMCO Graz 29th Nov 2010
Guard: move_left ∈ buffer(self) Action: buffer(self) ≔ buffer(self) ∖ {move_left}
FMCO Graz 29th Nov 2010
from any state
FMCO Graz 29th Nov 2010
FMCO Graz 29th Nov 2010
track layout constants Axioms reqd by prover
FMCO Graz 29th Nov 2010
trigger message to points
FMCO Graz 29th Nov 2010
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 29th Nov 2010
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 29th Nov 2010
FMCO Graz 29th Nov 2010
FMCO Graz 29th Nov 2010
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 29th Nov 2010
prove
abstraction of the essential properties
use refinement in a more progressive way (wrt proof)
FMCO Graz 29th Nov 2010
– fairly close correspondence… but not identical – refinement helps get the model right (consistency proofs) – proof is mostly quite easy (but not proving much)
– proofs look quite hard, maybe impossible – PO’s will drive the model – may end up with a different model