Process Algebra (2IF45) Abstraction Parallel composition (short intro) Suzana Andova.

Process Algebra (2IF45)

Abstraction Parallel composition (short intro)

Suzana Andova

2

Outline of the lecture

• Unclear points from last lecture• Unclear points from Assignment 2

• Main goal: Abstraction• what is abstraction• why it is needed• how it is dealt with in equational theories

• Sub-goal: Parallel composition and communication (briefly explained, self-study the details also needed for Assignment 2)

• Evaluation form (15-20 min)


3

Specifying concurrency

• Systems are complex and consist of many components• Components are active concurrently and interact with each

other

• Modeling languages need to express this aspects• BPA(A) and TSP(A) can specify only sequential behaviour• New concepts are needed for parallel behaviour and for

communication/synchronization/simultaneous executions

• Analysis tools shall to benefit from compositionality


4

Specifying concurrency

• the true concurrency approachPetri nets, event structures, …, read more if interested in, e.g.: “Petri Nets for algebraic theories of concurrency” – Rob van

Glabbeek and Frits Vaandrager, 1987

• the approach of interleaving semantics• parallel behaviour is “sequentialized” - represented as a set of

sequential behaviours• equality like a || b = ab + ba• this assumption simplifies the representation and reasoning• so allows for elegant model of concurrent systems and their

analysis


5

Interleaving semantics for Concurrency

a||

a

b

b a

b

6


a||

a

b

b a

b

a||

ab ab

c d

ad

c cb

cd

b d

7


a||

a

b

b a

b

a||

ab ab

c d

ad

c cb

cd

b d

e

e f

g h

communication function on A: A x A ↦ A

pre-defined communication (a, b) = e(a, d) = f(c, b) = g(c, d) = h

pre-defined communication (a, b) = e

8


a||

b

a||

b

c d

e

h

communication function on A: A x A ↦ A


pre-defined communication (a, b) = e

enforced communication: a or b cannot occur if not synchronized

e

enforced communication: a, b, c or d cannot occur if not synchronized

9


c||

a db


10 Process Algebra (2IF45)

TCP = TSP with parallel composition

Deduction rules for parallel composition

x x’ x || y x’ || y

a

a

x yx || y

y y’ x || y x || y’

a

a

x yx | y

x x’ y y’, (a,b) = c x || y x’ || y’

a

c

b

x x’ y y’, (a,b) = c x | y x’ || y’

a

c

b

x x’

x ╙ y x’ || y

a

a

Language: TCP(A, )

Signature: 0, 1, (a._ )aA, +, •, ||, |, ╙, H,

Language terms T(TCP(A, )) Closed terms C(TCP(A, ))

…

11

Language: TCP(A, )

Signature: 0, 1, (a._ )aA, +, •, ||, |, ╙, H,




x || y = x ╙ y + y ╙ x + x | y

x || 1 = x

0 ╙ x = 0 1 ╙ x = 0

x ╙ 0 = x • 0

a.x ╙ y = a.(x || y)

(x + y) ╙ z = x ╙ z + y ╙ z

(x ╙ y) ╙ z = x ╙ (y || z)

12

Language: TCP(A, )

Signature: 0, 1, (a._ )aA, +, •, ||, |, ╙, H,




a.x | b.y = c.(x || y) if (a,b) = c a.x | b.y = 0 if (a,b) not defined 0 | x = 0 … (not complete set of axioms, see the book)

x || y = x ╙ y + y ╙ x + x | y

x || 1 = x

0 ╙ x = 0 1 ╙ x = 0

x ╙ 0 = x • 0

a.x ╙ y = a.(x || y)

(x + y) ╙ z = x ╙ z + y ╙ z

(x ╙ y) ╙ z = x ╙ (y || z)

but NOT:

x ╙ (y+z) = x ╙ y + x ╙ z



Deduction rules for parallel composition

x x’ x || y x’ || y

a

a

x yx || y

y y’ x || y x || y’

a

a

x yx | y

x x’ y y’, (a,b) = c x || y x’ || y’

a

c

b

x x’ y y’, (a,b) = c x | y x’ || y’

a

c

b

x x’

x ╙ y x’ || y

a

a

Language: TCP(A, )

Signature: 0, 1, (a._ )aA, +, •, ||, |, ╙, H,


…

14

Abstraction

• Systems are very complex, but we still want/try to understand them • Abstraction means “ignoring (properly) some irrelevant details” • “details” are system activities (actions)• “irrelevant” with respect to some system or sub-system behaviour we want

to inspect

• Goal is to ignore / hide some system activities so that the relevant behaviour does not change

• “Does not change” ?


15

Abstraction

Abstraction is used to • check the correctness of implementation against the system

specification

• reduce and simplify the model to enable better, fasted and cleaner model analysis


16

Abstraction for implementation

Abstraction is used to check the correctness of implementation against the system specification

Example: synchronous communication implemented with asynchronous communication


Sender Receiverm

17

Abstraction for implementation

Example: synchronous communication implemented with asynchronous communication


Sender Receiverm

High level abstraction: synchronous communication

Lower level abstraction: asynchronous reliable (lossless) communication

Lowest level abstraction: asynchronous unreliable (lossy) communication

abstraction

abstraction

refinement

refinement

18

Abstraction for implementationExample: synchronous communication implemented with asynchronous communication


Sender Receiverm

High level abstraction: synchronous communication

Sender = send(m).1 Receiver = receive(m).1

H(Sender || Receiver) = comm(m).1

send(m)

||receive(m) comm(m)

communication function(send(m), receive(m)) = comm(m)

Blocking actions: H = {send(m), receive(m)}

19



Sender Receiverm

Implementation: asynchronous communication

Sender = send_toB(m).1 Receiver = receive_fromB(m).1

Buff = receive_fromS(m).send_toR(m).1

G(Sender || Buff || Receiver ) = comm_SB(m).comm_BR(m).1

communication function(send_toB(m), receive_fromS(m)) = comm_SB(m)(send_toR(m), receive_fromB(m)) = comm_BR(m)

Blocking actions: G = {send_toB(m), receive_fromS(m), send_toR(m), receive_fromB(m)}

Buff m

20



Sender Receiverm


Buff m

comm_SB(m)

comm_BR(m)

21



Sender Receiverm


Buff m

comm_SB(m)

comm_BR(m)

comm(m)

Sender Receiverm

Specification: synchronous communication

How to equate these behaviours?

22



Sender Receiverm


Buff m

comm_SB(m)

comm_BR(m)

comm(m)

Sender Receiverm


How to equate these behaviours?1. Hide actions if needed

23



Sender Receiverm


Buff m

comm_SB(m)

comm_BR(m)comm(m)

comm(m)

Sender Receiverm



2. Rename actions if needed

24



Sender Receiverm


Buff m

comm(m)

comm(m)

Sender Receiverm



2. Rename actions if needed3. Use relation that is “internal steps” sensitive

25

Abstraction for model reduction

Abstraction is used to reduce and simplify the model to enable better, fasted and cleaner model analysis


a

c

a

d Check whether: “b not always occurs after a”

b

26




Check whether: “b not always occurs after a”

1. Hide irrelevant actions, in this case c and d

a

c

a

d

ba

a

b

27






2. Reduce the model so that the property is preserved

a

c

a

d

ba

a

b

28






2. Reduce the model so that the property is preserved

a

c

a

d

ba

a

b

a a

b

a

b

or

29

Abstraction


specification



Question: How do we chose to relate behaviours with internal steps?

30

Abstraction


specification



Question: How do we chose to relate behaviours with internal steps?Branching bisimulation

31

Branching bisimilar processes

t

t’

a

s a

s’

t’’

t

s

s’t’’

t s

s’

t

Branching Bisimulation relation: A binary relation R on the set of state S of an LTS is branching bisimulation relation iff the following transfer conditions hold:

1. for all states s, t, s’ S, whenever (s, t) R and s → s’ for some a A, then there are states t’, t’’ S such that t t’ and t’ → t’’ and (s, t’), (s’,t’’) R;2. vice versa, for all states s, t, s’ S, whenever (s, t) R and t → t’ for some a A, then there

are states s’,s’’ S such that s s’ and s’ → s’’ and (s’, t), (s’’,t’) R;3. if (s, t) R and s then there is a state t’ such that t t’ , t’ and (s, t’) R4. whenever (s, t) R and t then there is a state s’ such that s s’ , s’ and (s’, t) R

Two LTSs s and t are branching bisimilar, s b t, iff there is a branching bisimulation relation R such that (s, t) R

aa

a

a

32

Is this the right equivalence?

a

a

a

a

b

b b

branching bisimilar!

branching bisimilar?+ +

33

Is this the right equivalence?

a

a

a

a

b

b b

branching bisimilar!

branching bisimilar?+ +

What is the problem?

34

Rooted Branching bisimilar processes

t’

q

b

s’ b

p

r

t’

s’

pq

t s’

p

t’

t s a a

t s a a

t s a a

Branching Bisimulation relation between state (s, t) R (as already defined) and the root condition:1. if s → s’ for a A, then there is a state t’ S such that t → t’ and (s’, t’) R;2. if t → t’ for a A, then there is a state s’ S such that s → s’ and (s’, t’) R;3. s if and only if t

Two LTSs s and t are rooted branching bisimilar, s rb t, iff there is a rooted branching bisimulation relation R such that (s, t) R

a

a a

a


Process theory with abstraction Language: TCP(A, )

Signature: 0, 1, (a._ )aA, , +, •, ||, |, ╙, H, I

Language terms T(TCP(A, ))

Closed terms C(TCP(A, ))

Branching Bisimilarity on LTSs

Equality of terms

Deduction rules Axioms

Completeness

Soundness


Process theory with abstraction

Deduction rules (as we have seen already)

x x’ x || y x’ || y

a

a

x yx || y

y y’ x || y x || y’

a

a

x yx | y

Language: TCP(A, )

Signature: 0, 1, (a._ )aA, , +, •, ||, |, ╙, H, I



Deduction rules for I


Equality of termsCompleteness

Soundness




x x’ x || y x’ || y

a

a

x yx || y

y y’ x || y x || y’

a

a

x yx | y

Language: TCP(A, )

Signature: 0, 1, (a._ )aA, , +, •, ||, |, ╙, H, I






Soundness

Axioms of TCP(A, ) (as we have seen them already)

Axioms for I operator

38

Axiom for rooted branching bisimulation

a

x y

x+

+

…

a

x y+

…

rb

Corresponding axiom

39

Axiom for rooted branching bisimulation

a

x y

x+

+

…

a

x y+

…

rb

B axiom a.(.(x+y) + x) = a.(x+y)

Corresponding axiom




x x’ x || y x’ || y

a

a

x yx || y

y y’ x || y x || y’

a

a

x yx | y

Language: TCP(A, )

Signature: 0, 1, (a._ )aA, , +, •, ||, |, ╙, H, I






Soundness

Axioms of TCP(A, ) (as we have seen them already)

Axioms for I operator:

Rooted Branching bisimulation axiom:a.(.(x+y) + x) = a.(x+y)

Process Algebra (2IF45) Abstraction Parallel composition (short intro) Suzana Andova.

Documents

Transcript of Process Algebra (2IF45) Abstraction Parallel composition (short intro) Suzana Andova.