Julien Brunel, David Chemouil, Alcino Cunha, Eunsuk Kang, Nuno Macedo formal software design with alloy and electrum temporal logic Universidade do Minho & INESC TEC ONERA DTIS & Université fédérale de Toulouse Carnegie Mellon University 3rd World Congress on Formal Methods, Porto, Portugal, October 2019
temporal logic
formal software design with alloy and electrum / temporal logic 3 / 50 linear temporal logic E lectrum includes temporal connectives from Linear Temporal Logic (LTL). Formulas are interpreted over infinite sequences of states (traces).
formal software design with alloy and electrum / temporal logic 4 / 50 future operators E lectrum Meaning p is always true from now on always p eventually p p will eventually be true p will be true in the next state after p p until q q will eventually be and p is true until then q can only be false afer p is true p releases q
formal software design with alloy and electrum / temporal logic 5 / 50 past operators E lectrum Meaning p was always true historically p once p p was once true p was true in the previous state before p q was once true and p has been true aferwards p since q if p was once true, then q has been true onwards p triggered q
formal software design with alloy and electrum / temporal logic 6 / 50 semantics by example eventually B
formal software design with alloy and electrum / temporal logic 7 / 50 semantics by example not eventually B
formal software design with alloy and electrum / temporal logic 8 / 50 semantics by example always A
formal software design with alloy and electrum / temporal logic 9 / 50 semantics by example not always A
formal software design with alloy and electrum / temporal logic 10 / 50 semantics by example before B
formal software design with alloy and electrum / temporal logic 11 / 50 semantics by example not before B
formal software design with alloy and electrum / temporal logic 12 / 50 semantics by example once B
formal software design with alloy and electrum / temporal logic 13 / 50 semantics by example once A
formal software design with alloy and electrum / temporal logic 14 / 50 semantics by example always (B implies eventually A)
formal software design with alloy and electrum / temporal logic 15 / 50 semantics by example not always (A implies eventually B)
formal software design with alloy and electrum / temporal logic 16 / 50 semantics by example eventually always A
formal software design with alloy and electrum / temporal logic 17 / 50 semantics by example not eventually always B
formal software design with alloy and electrum / temporal logic 18 / 50 semantics by example always eventually A
formal software design with alloy and electrum / temporal logic 19 / 50 semantics by example not always eventually B
formal software design with alloy and electrum / temporal logic 20 / 50 some ltl valid formulas always A iff not eventually not A eventually always A implies always eventually A A until B implies eventually B A releases B iff ( always not A) or B until (A and B)
formal software design with alloy and electrum / temporal logic 21 / 50 trash Design a trash such that: A deleted file can still be restored if the trash is not emptied
formal software design with alloy and electrum / temporal logic 22 / 50 trash assert restoreIsPossibleBeforeEmpty { -- a deleted file can still be restored if the trash is not emptied always ( all f:File | delete[f] implies (empty releases restoreEnabled[f])) }
formal software design with alloy and electrum / temporal logic 23 / 50
formal software design with alloy and electrum / temporal logic 24 / 50 exercise https://github.com/haslab/Electrum2/wiki/Trash (exercises 4)
infinite traces
formal software design with alloy and electrum / infinite traces 26 / 50 why infinite traces only? Semantic issues with finite traces What formulas are true in the last state? Different possible semantics In Electrum: infinite traces only Caveat: no deadlock detection in general But a finite trace can be represented by an infinite one stuttering on the last state
formal software design with alloy and electrum / infinite traces 27 / 50 finite representation with lassos L asso trace Some infinite traces can be represented by finite lasso traces Notice some infinite traces cannot Small-Model Property for LTL If an LTL formula is satisfiable, then it is satisfied by at least one lasso trace.
example
formal software design with alloy and electrum / example 29 / 50 leader election in a ring V erify the correctness of the protocol: One leader will be elected
formal software design with alloy and electrum / example 30 / 50 configuration and state open util/ordering[Id] sig Id {} sig Node { id : one Id, succ : one Node, var inbox : set Id, var outbox : set Id } fact ring { all i : Id | lone id.i all n : Node | Node in n.^succ }
formal software design with alloy and electrum / example 31 / 50 election fun elected : set Node { { n : Node | once n.id in n.inbox } }
formal software design with alloy and electrum / example 32 / 50 operations pred send [n : Node] { ... } pred compute [n : Node] { some i : n.inbox { n.inbox' = n.inbox - i n.outbox' = n.outbox + (i - n.id.*(~next)) } all m : Node - n | m.inbox' = m.inbox all m : Node - n | m.outbox' = m.outbox } pred skip { ... }
formal software design with alloy and electrum / example 33 / 50 behavior fact init { no inbox outbox = id } fact transitions { always (skip or some n : Node | send[n] or compute[n]) }
formal software design with alloy and electrum / example 34 / 50 exercise https://github.com/haslab/Electrum2/wiki/Leader-election (exercise 1-3)
safety vs liveness
formal software design with alloy and electrum / safety vs liveness 36 / 50 safety properties Something “bad” will never happen. A trace that violates a safety property has a “bad” prefix. A “bad” prefix is one s.t. every possible continuation violates the property. always p always (p implies once q) always (p implies after always not p)
formal software design with alloy and electrum / safety vs liveness 37 / 50 leader election assert safety { always lone elected }
formal software design with alloy and electrum / safety vs liveness 38 / 50
formal software design with alloy and electrum / safety vs liveness 39 / 50 exercise https://github.com/haslab/Electrum2/wiki/Leader-election (exercise 4)
formal software design with alloy and electrum / safety vs liveness 40 / 50 liveness properties Something “good” will eventually happen. A property is a liveness property if any prefix can be extended to an infinite trace satisfying it. Much harder to check than safety properties. ◮ Observing a prefix is not sufficient to detect a violation. eventually p always (p implies eventually q) always eventually p
formal software design with alloy and electrum / safety vs liveness 41 / 50 leader election assert liveness { eventually some elected }
formal software design with alloy and electrum / safety vs liveness 42 / 50
fairness
formal software design with alloy and electrum / fairness 44 / 50 fairness assumptions Necessary for verifying most liveness properties. Exclude traces where an event becomes “continuously” enabled but never occurs ◮ continuously = infinitely ofen (strong) ◮ continuously = permanently (weak) Strong fairness ( always eventually p) implies ( always eventually q) Weak fairness ( eventually always p) implies ( always eventually q)
formal software design with alloy and electrum / fairness 45 / 50 leader election specification fixed pred sendEnabled [n : Node] { some n.outbox } pred computeEnabled [n : Node] { some n.inbox } pred fairness { all n : Node { ( eventually always sendEnabled[n]) implies ( always eventually send[n]) ( eventually always computeEnabled[n]) implies ( always eventually compute[n]) } } assert liveness { fairness implies eventually some elected }
concurrent executions
formal software design with alloy and electrum / concurrent executions 47 / 50 interleaved vs. concurrent executions P revious models force interleaved execution of operations ◮ the frame condition in each event prevents other events from occurring Concurrent executions can also be specified in Electrum ◮ frame conditions must be relaxed, but still prevent arbitrary changes ◮ counter-examples can be shorter (more efficient verification) but harder to understand ◮ some properties that are true in an interleaved model may no longer be true
formal software design with alloy and electrum / concurrent executions 48 / 50 operations redefined pred skip { ... } pred send [n : Node] { ... } pred compute [n : Node] { some i : n.inbox { n.inbox' = n.inbox - i n.outbox' = n.outbox + (i - n.id.*(~next)) } }
formal software design with alloy and electrum / concurrent executions 49 / 50 frame conditions fact frame { always all n : Node { n.inbox' != n.inbox implies (compute[n] or send[succ.n]) n.outbox' != n.outbox implies (compute[n] or send[n]) } }
formal software design with alloy and electrum / concurrent executions 50 / 50
Recommend
More recommend
