formal software design with alloy and electrum temporal logic - - PowerPoint PPT Presentation

▶
formal software design with alloy and electrum
SMART_READER_LITE
LIVE PREVIEW

formal software design with alloy and electrum temporal logic - - PowerPoint PPT Presentation

Jul 09, 2023 234 likes •755 views

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 fdrale de Toulouse Carnegie Mellon

slide-1
SLIDE 1

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

slide-2
SLIDE 2

temporal logic

slide-3
SLIDE 3

formal software design with alloy and electrum / temporal logic 3 / 50

linear temporal logic

Electrum includes temporal connectives from Linear Temporal Logic (LTL). Formulas are interpreted over infinite sequences of states (traces).

slide-4
SLIDE 4

formal software design with alloy and electrum / temporal logic 4 / 50

future operators

Electrum Meaning

always p p is always true from now on eventually p p will eventually be true after p p will be true in the next state p until q q will eventually be and p is true until then p releases q q can only be false afer p is true

slide-5
SLIDE 5

formal software design with alloy and electrum / temporal logic 5 / 50

past operators

Electrum Meaning

historically p p was always true

  • nce p

p was once true before p p was true in the previous state p since q q was once true and p has been true aferwards p triggered q

if p was once true, then q has been true onwards

slide-6
SLIDE 6

formal software design with alloy and electrum / temporal logic 6 / 50

semantics by example

eventually B

slide-7
SLIDE 7

formal software design with alloy and electrum / temporal logic 7 / 50

semantics by example

not eventually B

slide-8
SLIDE 8

formal software design with alloy and electrum / temporal logic 8 / 50

semantics by example

always A

slide-9
SLIDE 9

formal software design with alloy and electrum / temporal logic 9 / 50

semantics by example

not always A

slide-10
SLIDE 10

formal software design with alloy and electrum / temporal logic 10 / 50

semantics by example

before B

slide-11
SLIDE 11

formal software design with alloy and electrum / temporal logic 11 / 50

semantics by example

not before B

slide-12
SLIDE 12

formal software design with alloy and electrum / temporal logic 12 / 50

semantics by example

  • nce B
slide-13
SLIDE 13

formal software design with alloy and electrum / temporal logic 13 / 50

semantics by example

  • nce A
slide-14
SLIDE 14

formal software design with alloy and electrum / temporal logic 14 / 50

semantics by example

always (B implies eventually A)

slide-15
SLIDE 15

formal software design with alloy and electrum / temporal logic 15 / 50

semantics by example

not always (A implies eventually B)

slide-16
SLIDE 16

formal software design with alloy and electrum / temporal logic 16 / 50

semantics by example

eventually always A

slide-17
SLIDE 17

formal software design with alloy and electrum / temporal logic 17 / 50

semantics by example

not eventually always B

slide-18
SLIDE 18

formal software design with alloy and electrum / temporal logic 18 / 50

semantics by example

always eventually A

slide-19
SLIDE 19

formal software design with alloy and electrum / temporal logic 19 / 50

semantics by example

not always eventually B

slide-20
SLIDE 20

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)

slide-21
SLIDE 21

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

slide-22
SLIDE 22

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])) }

slide-23
SLIDE 23

formal software design with alloy and electrum / temporal logic 23 / 50

slide-24
SLIDE 24

formal software design with alloy and electrum / temporal logic 24 / 50

exercise

https://github.com/haslab/Electrum2/wiki/Trash (exercises 4)

slide-25
SLIDE 25

infinite traces

slide-26
SLIDE 26

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

slide-27
SLIDE 27

formal software design with alloy and electrum / infinite traces 27 / 50

finite representation with lassos

Lasso 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.

slide-28
SLIDE 28

example

slide-29
SLIDE 29

formal software design with alloy and electrum / example 29 / 50

leader election in a ring

Verify the correctness of the protocol: One leader will be elected

slide-30
SLIDE 30

formal software design with alloy and electrum / example 30 / 50

configuration and state

  • pen 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 }

slide-31
SLIDE 31

formal software design with alloy and electrum / example 31 / 50

election

fun elected : set Node { { n : Node | once n.id in n.inbox } }

slide-32
SLIDE 32

formal software design with alloy and electrum / example 32 / 50

  • perations

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 { ... }

slide-33
SLIDE 33

formal software design with alloy and electrum / example 33 / 50

behavior

fact init { no inbox

  • utbox = id

} fact transitions { always (skip or some n : Node | send[n] or compute[n]) }

slide-34
SLIDE 34

formal software design with alloy and electrum / example 34 / 50

exercise

https://github.com/haslab/Electrum2/wiki/Leader-election (exercise 1-3)

slide-35
SLIDE 35

safety vs liveness

slide-36
SLIDE 36

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)

slide-37
SLIDE 37

formal software design with alloy and electrum / safety vs liveness 37 / 50

leader election

assert safety { always lone elected }

slide-38
SLIDE 38

formal software design with alloy and electrum / safety vs liveness 38 / 50

slide-39
SLIDE 39

formal software design with alloy and electrum / safety vs liveness 39 / 50

exercise

https://github.com/haslab/Electrum2/wiki/Leader-election (exercise 4)

slide-40
SLIDE 40

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

slide-41
SLIDE 41

formal software design with alloy and electrum / safety vs liveness 41 / 50

leader election

assert liveness { eventually some elected }

slide-42
SLIDE 42

formal software design with alloy and electrum / safety vs liveness 42 / 50

slide-43
SLIDE 43

fairness

slide-44
SLIDE 44

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)

slide-45
SLIDE 45

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 }

slide-46
SLIDE 46

concurrent executions

slide-47
SLIDE 47

formal software design with alloy and electrum / concurrent executions 47 / 50

interleaved vs. concurrent executions

Previous 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

slide-48
SLIDE 48

formal software design with alloy and electrum / concurrent executions 48 / 50

  • perations 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)) } }

slide-49
SLIDE 49

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]) } }

slide-50
SLIDE 50

formal software design with alloy and electrum / concurrent executions 50 / 50