Process Algebra (2IF45) Abstraction Parallel composition (short intro) Suzana Andova
Jan 18, 2018
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)
Process Algebra (2IF45)
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
Process Algebra (2IF45)
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
Process Algebra (2IF45)
5
Interleaving semantics for Concurrency
a||
a
b
b a
b
6
Interleaving semantics for Concurrency
a||
a
b
b a
b
a||
ab ab
c d
ad
c cb
cd
b d
7
Interleaving semantics for Concurrency
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
Interleaving semantics for Concurrency
a||
b
a||
b
c d
e
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
enforced communication: a or b cannot occur if not synchronized
e
enforced communication: a, b, c or d cannot occur if not synchronized
9
Interleaving semantics for Concurrency
c||
a db
pre-defined communication (a, b) = e(a, d) = f(c, b) = g(c, d) = h
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,
Language terms T(TCP(A, )) Closed terms C(TCP(A, ))
Process Algebra (2IF45)
TCP = TSP with parallel composition
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,
Language terms T(TCP(A, )) Closed terms C(TCP(A, ))
Process Algebra (2IF45)
TCP = TSP with parallel composition
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
13 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, ))
…
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” ?
Process Algebra (2IF45)
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
Process Algebra (2IF45)
16
Abstraction for implementation
Abstraction is used to check the correctness of implementation against the system specification
Example: synchronous communication implemented with asynchronous communication
Process Algebra (2IF45)
Sender Receiverm
17
Abstraction for implementation
Example: synchronous communication implemented with asynchronous communication
Process Algebra (2IF45)
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
Process Algebra (2IF45)
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
Abstraction for implementationExample: synchronous communication implemented with asynchronous communication
Process Algebra (2IF45)
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
Abstraction for implementationExample: synchronous communication implemented with asynchronous communication
Process Algebra (2IF45)
Sender Receiverm
Implementation: asynchronous communication
Buff m
comm_SB(m)
comm_BR(m)
21
Abstraction for implementationExample: synchronous communication implemented with asynchronous communication
Process Algebra (2IF45)
Sender Receiverm
Implementation: asynchronous communication
Buff m
comm_SB(m)
comm_BR(m)
comm(m)
Sender Receiverm
Specification: synchronous communication
How to equate these behaviours?
22
Abstraction for implementationExample: synchronous communication implemented with asynchronous communication
Process Algebra (2IF45)
Sender Receiverm
Implementation: asynchronous communication
Buff m
comm_SB(m)
comm_BR(m)
comm(m)
Sender Receiverm
Specification: synchronous communication
How to equate these behaviours?1. Hide actions if needed
23
Abstraction for implementationExample: synchronous communication implemented with asynchronous communication
Process Algebra (2IF45)
Sender Receiverm
Implementation: asynchronous communication
Buff m
comm_SB(m)
comm_BR(m)comm(m)
comm(m)
Sender Receiverm
Specification: synchronous communication
How to equate these behaviours?1. Hide actions if needed
2. Rename actions if needed
24
Abstraction for implementationExample: synchronous communication implemented with asynchronous communication
Process Algebra (2IF45)
Sender Receiverm
Implementation: asynchronous communication
Buff m
comm(m)
comm(m)
Sender Receiverm
Specification: synchronous communication
How to equate these behaviours?1. Hide actions if needed
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
Process Algebra (2IF45)
a
c
a
d Check whether: “b not always occurs after a”
b
26
Abstraction for model reduction
Abstraction is used to reduce and simplify the model to enable better, fasted and cleaner model analysis
Process Algebra (2IF45)
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
Abstraction for model reduction
Abstraction is used to reduce and simplify the model to enable better, fasted and cleaner model analysis
Process Algebra (2IF45)
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
a
c
a
d
ba
a
b
28
Abstraction for model reduction
Abstraction is used to reduce and simplify the model to enable better, fasted and cleaner model analysis
Process Algebra (2IF45)
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
a
c
a
d
ba
a
b
a a
b
a
b
or
29
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
Process Algebra (2IF45)
Question: How do we chose to relate behaviours with internal steps?
30
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
Process Algebra (2IF45)
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
35 Process Algebra (2IF45)
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
36 Process Algebra (2IF45)
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
Language terms T(TCP(A, ))
Closed terms C(TCP(A, ))
Deduction rules for I
Branching Bisimilarity on LTSs
Equality of termsCompleteness
Soundness
37 Process Algebra (2IF45)
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
Language terms T(TCP(A, ))
Closed terms C(TCP(A, ))
Deduction rules for I
Branching Bisimilarity on LTSs
Equality of termsCompleteness
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
40 Process Algebra (2IF45)
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
Language terms T(TCP(A, ))
Closed terms C(TCP(A, ))
Deduction rules for I
Branching Bisimilarity on LTSs
Equality of termsCompleteness
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)