process algebra (2if45) abstraction parallel composition (short intro) suzana andova

Process Algebra (2IF45)

Abstraction Parallel composition (short intro)

Suzana Andova

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)

Specifying concurrency

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

• 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

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

Interleaving semantics for Concurrency

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

communication function on A: A x A ↦ A

pre-defined communication (a, b) = e

enforced communication: a or b cannot occur if not synchronized

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

10 Process Algebra (2IF45)

TCP = TSP with parallel composition

Deduction rules for parallel composition

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

x yx || y

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

x yx | y

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

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

x x’

x ╙ y x’ || y

Language: TCP(A, )

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

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

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)

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

x yx || y

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

x yx | y

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

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

x x’

x ╙ y x’ || y

Language: TCP(A, )

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

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” ?

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

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

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

refinement

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

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

Sender Receiverm

Buff m

comm_SB(m)

comm_BR(m)

Sender Receiverm

Buff m

comm_SB(m)

comm_BR(m)

comm(m)

Sender Receiverm

Specification: synchronous communication

How to equate these behaviours?

Sender Receiverm

Buff m

comm_SB(m)

comm_BR(m)

comm(m)

Sender Receiverm

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

Sender Receiverm

Buff m

comm_SB(m)

comm_BR(m)comm(m)

comm(m)

Sender Receiverm

2. Rename actions if needed

Sender Receiverm

Buff m

comm(m)

Sender Receiverm

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

Abstraction for model reduction

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

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

Check whether: “b not always occurs after a”

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

2. Reduce the model so that the property is preserved

Abstraction

specification

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

Abstraction

specification

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

Branching bisimilar processes

t’’

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

Is this the right equivalence?

branching bisimilar!

branching bisimilar?+ +

Is this the right equivalence?

branching bisimilar!

branching bisimilar?+ +

What is the problem?

Rooted Branching bisimilar processes

s’ b

t s’

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

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

x yx || y

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

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

x yx || y

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

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

Axiom for rooted branching bisimulation

Corresponding axiom

Axiom for rooted branching bisimulation

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

Corresponding axiom

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

x yx || y

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

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

marko dožić, suzana stojanović rundić, vesna plešinac...

process algebra (2if45) abstraction and recursions in ...

process algebra (2if45) probabilistic branching...

process algebra (2if45) assignments

simple language of communicating...

casual portrait everton e suzana

process algebra (2if45) probabilistic process algebra

process algebra (2if45) probabilistic extension: semantics...

process algebra (2if45) working with probabilistic systems

process algebra (2if45) basic notions of equational theory

suzana delic ppt

suzana Černe, prof. @ robert raplenovich, prof

suzana j. camargosuzana/cv_feb20.pdf · suzana j. camargo...

process algebra (2if45) analysing probabilistic systems

suzana paper 2

process algebra (2if45) probabilistic extension: semantics...

zavrŠni rad - mali princ - suzana Šambar

process algebra (2if45) dr. suzana andova. 1 process algebra...

process algebra (2if45) recursion in process algebra

process algebra (2if45) extending process algebra: parallel...