State = ( expression using N , B , . . . , , P , , , , . . . , - PDF document

3BA31 Formal Methods 1 VDM ♣ “VDM” stands for the Vienna Development Method — Result of work the in the Vienna Research Laboratory of IBM (1960s). VDM is now a standardised formal-method (VDM-SL — Specification Language): • reasoning based on the Logic of Partial Functions (LPF) • based on the notion of specifiying programs via pre- and post-condition predicates. • http://en.wikipedia.org/wiki/Vienna Development Method VDM ♣ is a non-standard dialect of VDM: • based on equational reasoning, rather than LPF. • uses pre-condition predicates, but most specifications give an abstract definition of the computed result (called explicit post-conditions in VDM-SL) • http://www.cs.tcd.ie/Andrew.Butterfield/IrishVDM/ The way in which the mathematics is used to reason about systems is very similar in both VDM-SL and VDM ♣ . 3BA31 Formal Methods 2 The “Method” in VDM ♣ : Requirements • capture the “users” expectations of the behaviour of the system to be built. • model of the environment , or the “World”. • model of the desired interactions between system and environment • This process requires building a model of the problem domain, and is often referred to as Domain Modelling or Domain Capture .

3BA31 Formal Methods 3 The “Method” in VDM ♣ : Specifications • a description of the behaviour the system must have in order to satisfy the requirements. • a model of the system to be built • the process of ensuring that a specification is consistent w.r.t the requirements is called Validation The VDM method says relatively little about validation, as this is very probelm-specific. VDM methodology does ensure that the specification makes sense, (even it if not what the users wanted !). VDM/ VDM ♣ uses its mathematics to model the pertinent parts of the system and environment (as state) and then specifies the safety conditions and operations that the system must maintain and provide. System = State + Operations 3BA31 Formal Methods 4 The “Method” in VDM ♣ In order to produce a formal model according to the Vienna Development Method , we need to: • Determine the System State – State Type – State Invariant – Initial State • Describe the Operations – Operation Pre-Condition – Operation Post-Condition • Discharge all Proof Obligations

3BA31 Formal Methods 5 The “Method” in VDM ♣ : Proof Obligations • Proof obligation is a required property of a VDM model. • Typically capture idea that model “makes sense”. • Method compliance the successful proof of every Proof Obligation. • They don’t guarantee that what a model is realistic, or what the “customer” wanted. Note: In addition to the method proof obligations, we may want to prove that other properties hold, related to our particular application. 3BA31 Formal Methods 6 The “Method” in VDM ♣ : System State System state contains all the relevant values and conditions of the system. We define it by first declaring its components and their structure, using the types and type constructors of VDM ♣ : m Σ ∈ State = ( expression using N , B , . . . , × , P , → , � → , → , . . . , ADTs ) Relationships and conditions of the state that always hold true (often called safety properties) are captured by an invariant: inv- State : State → B inv- State Σ = � . . . Proof Obligation: State Invariant Satisfiability : We must prove that the invariant is satisfiable, i.e there is at least one instance of the state datatype that satisfies it. ∃ Σ : State • inv- State Σ

3BA31 Formal Methods 7 The “Method” in VDM ♣ : Initial State We generally need to introduce the notion of an initial or starting state, at least of any system we are proposing to build: Σ 0 : State Σ 0 = . . . � Proof Obligation: Initial-State Invariant : We must prove that the initial state satisfies the invariant: inv- State Σ 0 = T RUE Note that a proof of this obligation is also a proof of the Invariant Satisfiability obligation (why?) 3BA31 Formal Methods 8 The “Method” in VDM ♣ : Operations • Capture events that change or observe the system state – initiated by the system, or – by the environment. • Have inputs and outputs • cause state changes • Two main classes of operations: – state change: no outputs, but state changes – state enquiry: outputs, but state is unchanged An operation with outputs that changes state as well, can be decomposed into two operations, on of each of the above classes. We shall assume all operators have been so decomposed.

3BA31 Formal Methods 9 The “Method” in VDM ♣ : State Change State change operations take input or control parameters of some type ( c ∈ Control ) and produce a change in state. When specifying such (called StChg, say), we need to identify the circumstances under which we consider the operator to be well-defined — the precondition of the operation . We capture this by a declaration with the following signatures and forms: : Control → State → State StChg StChg [ c ]Σ = � expression defining after-State : Control → State → B pre-StChg pre- StChg [ c ]Σ = � predicate describing pre-condition Proof Obligation: State Change Invariant We must prove that if the state before change satisfies the invariant, and the pre-condition of the operator holds, that then the invariant holds after the operation has run: inv- State Σ ∧ pre- StChg [ c ]Σ ⇒ inv- State ( StChg [ c ]Σ) 3BA31 Formal Methods 10 The “Method” in VDM ♣ : State Query State query operations take input or query parameters of some type ( q ∈ Query ), look at the state, and return an appropriate result value ( r ∈ Result ) . When specifying such (called StQry, say), we need to identify the circumstances under which we consider the operator to be well-defined — the precondition of the operation . We capture this by a declaration with the following signatures and forms: : Query → State → Result StQry StQry [ q ]Σ = � expression defining query-result : Query → State → B pre-StQry pre- StQry [ q ]Σ = � predicate describing pre-condition There is no specific proof obligation associated with queries, other than the general observation that a query’s result need not be defined or make sense if the pre-condition does not hold.

3BA31 Formal Methods 11 Scribbles 4 : Example Model — Orienteering Event We construct a model of an orienteering event, for competitors using the SportIdent (SI) System. We first introduce the Types: s ∈ SI = N SI (Competitor) Numbers c ∈ Control = N Control Numbers r ∈ Course given set of course identifiers A course has a non-empty list of controls: m κ ∈ Courses → CONTROL + = Course A competitor enters a course: m ω ∈ Entries = → Course SI A competitor runs and collects controls in order (hopefully): m → Control ∗ ω ∈ Runs = SI 3BA31 Formal Methods 12 Scribbles 4 : Orienteering State and Invariant System state is comprised of Courses, Entries and Runs: ( κ, ω, ρ ) ∈ OState = Courses × Entries × Runs � Competitors can only enter courses that are offered (1), and when running must be entered (2), and can only find controls that are out there (3): inv- OState ( κ, ω, ρ ) = rng ω ⊆ dom κ � (1) ∧ dom ρ ⊆ dom ω (2) ∧ controlsof ( ρ ) ⊆ controlsof ( κ ) (3) m → P B ) → P B : ( A controlsof ∪ / ( P elems ( rng α )) controlsof ( α ) = � ∪ / ◦ P elems ◦ rng = controlsof

3BA31 Formal Methods 13 Scribbles 4 : Orienteering Initial State Initially everything is empty: : O 0 OState = ( θ, θ, θ ) � O 0 This satisfies the invariant, and so we discharge two proof obligations: inv- OState ( θ, θ, θ ) rng θ ⊆ dom θ ∧ dom θ ⊆ dom θ ∧ controlsof ( θ ) ⊆ controlsof ( θ ) = = ∅ ⊆ ∅ ∧ ∅ ⊆ ∅ ∧ ∅ ⊆ ∅ = T RUE controlsof ( θ ) ∪ / ( P elems ( rng θ )) = ∪ / ( P elems ( ∅ ) ∪ / ( ∅ ) ∅ = = = 3BA31 Formal Methods 14 Scribbles 4 : Planning An Event We now introduce an operation to allow the planner to add a course, and we decide to impose no pre-condition, to allow the planner flexibility to change things: ( Course × Controls + ) → OState → OState : Plan Plan ( r , σ )( κ, ω, ρ ) = ( κ † { r �→ σ } , ω, ρ ) � ( Course × Controls + ) → OState → B : pre- Plan pre- Plan ( r , σ )( κ, ω, ρ ) = � T RUE

3BA31 Formal Methods 15 Scribbles 4 : Plan Proof Obligation We have to show that operation Plan preserves the invariant, when its pre-condition holds: inv- OState ( κ, ω, ρ ) ∧ pre- Plan ( r , σ )( κ, ω, ρ ) ⇒ inv- OState ( Plan ( r , σ )( κ, ω, ρ )) As the pre-condition is vacuously true, we can drop it: inv- OState ( κ, ω, ρ ) ⇒ inv- OState ( Plan ( r , σ )( κ, ω, ρ )) 3BA31 Formal Methods 16 Mini-Exercise 2 Does Plan preserve the invariant ? inv- OState ( κ, ω, ρ ) ⇒ inv- OState ( Plan ( r , σ )( κ, ω, ρ )) If you think so, give an informal argument as to why. If you think not, give a counter-example showing what goes wrong Due: at start of 12noon Lecture, Thursday, February 15th, 2007.