Transcript Lecture9

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)
1
Process Algebra (2IF45)
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
2
Process Algebra (2IF45)
Specifying concurrency
• the true concurrency approach
Petri 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
3
Process Algebra (2IF45)
Interleaving semantics for Concurrency
b
||
a
b
a
a
b
4
Interleaving semantics for Concurrency
b
||
a
b
a
a
b
b
||
a
b
a
d
a
b
c
d
c
d
c
b
5
a
c
d
Interleaving semantics for Concurrency
b
||
a
b
a
e
pre-defined communication
(a, b) = e
a
b
||
a
c
b
d
a
c
b
d
e
f
a
b
d
g
c h
d
b
communication function on A
: A x A ↦ A
6
a
c
pre-defined communication
(a, b) = e
(a, d) = f
(c, b) = g
(c, d) = h
Interleaving semantics for Concurrency
pre-defined communication
(a, b) = e
||
a
e
b
enforced communication:
a or b cannot occur if not
synchronized
||
a
b
c
d
e
h
pre-defined communication
(a, b) = e
(a, d) = f
(c, b) = g
(c, d) = h
enforced communication:
a, b, c or d cannot occur if
not synchronized
communication function on A
: A x A ↦ A
7
Interleaving semantics for Concurrency
||
a
8
c
b
d
pre-defined communication
(a, b) = e
(a, d) = f
(c, b) = g
(c, d) = h
TCP = TSP with parallel composition
Language: TCP(A, )
Signature: 0, 1, (a._ )aA, +, •, ||, |,
Language terms T(TCP(A, ))
Closed terms C(TCP(A, ))
Deduction rules for parallel composition
a y’
y
a x || y’
x || y 
a x’
x
a
x || y 
x’ || y
x y
x || y
x y
x | y
a x’ y 
b y’, (a,b) = c
x
c x’ || y’
x || y 
a x’ y 
b y’, (a,b) = c
x
c
x|y
x’ || y’
9
a x’
x
a
x╙y
x’ || y
…
Process Algebra (2IF45)
╙, H,
TCP = TSP with parallel composition
Language: TCP(A, )
Signature: 0, 1, (a._ )aA, +, •, ||, |,
Language terms T(TCP(A, ))
Closed terms C(TCP(A, ))
╙, 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)
10
Process Algebra (2IF45)
TCP = TSP with parallel composition
Language: TCP(A, )
Signature: 0, 1, (a._ )aA, +, •, ||, |,
Language terms T(TCP(A, ))
Closed terms C(TCP(A, ))
but NOT:
x ╙ (y+z) = x ╙ y + x ╙ z
╙, 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)
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)
11
Process Algebra (2IF45)
TCP = TSP with parallel composition
Language: TCP(A, )
Signature: 0, 1, (a._ )aA, +, •, ||, |,
Language terms T(TCP(A, ))
Closed terms C(TCP(A, ))
Deduction rules for parallel composition
a y’
y
a x || y’
x || y 
a x’
x
a
x || y 
x’ || y
x y
x || y
x y
x | y
a x’ y 
b y’, (a,b) = c
x
c x’ || y’
x || y 
a x’ y 
b y’, (a,b) = c
x
c
x|y
x’ || y’
12
a x’
x
a
x╙y
x’ || y
…
Process Algebra (2IF45)
╙, 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” ?
13
Process Algebra (2IF45)
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
14
Process Algebra (2IF45)
Abstraction for implementation
Abstraction is used to check the correctness of implementation against
the system specification
Example: synchronous communication implemented with
asynchronous communication
Sender
15
m
Receiver
Process Algebra (2IF45)
Abstraction for implementation
Example: synchronous communication implemented with
asynchronous communication
Sender
m
Receiver
High level abstraction: synchronous communication
refinement
abstraction
Lower level abstraction: asynchronous reliable (lossless) communication
refinement
abstraction
Lowest level abstraction: asynchronous unreliable (lossy) communication
16
Process Algebra (2IF45)
Abstraction for implementation
Example: synchronous communication implemented with
asynchronous communication
Sender
m
Receiver
High level abstraction: synchronous communication
Sender = send(m).1
Receiver = receive(m).1
H(Sender || Receiver) = comm(m).1
communication function
(send(m), receive(m)) = comm(m)
||
send(m)
17
receive(m)
comm(m)
Process Algebra (2IF45)
Blocking actions:
H = {send(m), receive(m)}
Abstraction for implementation
Example: synchronous communication implemented with
asynchronous communication
Sender
m
Buff
m
Receiver
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)}
18
Process Algebra (2IF45)
Abstraction for implementation
Example: synchronous communication implemented with
asynchronous communication
Sender
m
Buff
m
Receiver
Implementation: asynchronous communication
comm_SB(m)
comm_BR(m)
19
Process Algebra (2IF45)
Abstraction for implementation
Example: synchronous communication implemented with
asynchronous communication
Sender
m
Receiver
Specification: synchronous
communication
Sender
m
Buff
m
Receiver
Implementation: asynchronous
communication
comm_SB(m)
comm(m)
comm_BR(m)
How to equate these behaviours?
20
Process Algebra (2IF45)
Abstraction for implementation
Example: synchronous communication implemented with
asynchronous communication
Sender
m
Receiver
Specification: synchronous
communication
Sender
m
Buff
m
Receiver
Implementation: asynchronous
communication
comm_SB(m)

comm(m)
comm_BR(m)
How to equate these behaviours?
1. Hide actions if needed
21
Process Algebra (2IF45)
Abstraction for implementation
Example: synchronous communication implemented with
asynchronous communication
Sender
m
Receiver
Specification: synchronous
communication
Sender
m
Buff
m
Receiver
Implementation: asynchronous
communication
comm_SB(m)

comm(m)
comm_BR(m)
comm(m)
How to equate these behaviours?
1. Hide actions if needed
2. Rename actions if needed
22
Process Algebra (2IF45)
Abstraction for implementation
Example: synchronous communication implemented with
asynchronous communication
Sender
m
Receiver
Specification: synchronous
communication
Sender
m
Buff
m
Receiver
Implementation: asynchronous
communication

comm(m)
comm(m)
How to equate these behaviours?
1. Hide actions if needed
2. Rename actions if needed
3. Use relation that is “internal steps” sensitive
23
Process Algebra (2IF45)
Abstraction for model reduction
Abstraction is used to reduce and simplify the model to enable better,
fasted and cleaner model analysis
Check whether:
“b not always occurs after a”
d
a
b
24
a
c
Process Algebra (2IF45)
Abstraction for model reduction
Abstraction is used to reduce and simplify the model to enable better,
fasted and cleaner model analysis
Check whether:
“b not always occurs after a”
d
a
b
a

c
a
1. Hide irrelevant actions, in this case c and d
25
Process Algebra (2IF45)
b
a

Abstraction for model reduction
Abstraction is used to reduce and simplify the model to enable better,
fasted and cleaner model analysis
Check whether:
“b not always occurs after a”
d
a
b
a

c
a
1. Hide irrelevant actions, in this case c and d
b
2. Reduce the model so that the property is preserved
26
Process Algebra (2IF45)
a

Abstraction for model reduction
Abstraction is used to reduce and simplify the model to enable better,
fasted and cleaner model analysis
Check whether:
“b not always occurs after a”
d
a
b
a

c
a
1. Hide irrelevant actions, in this case c and d
a

b
a
2. Reduce the model so that the property is preserved
b
27
Process Algebra (2IF45)
a
a
or
b
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
Question: How do we chose to relate behaviours with internal steps?
28
Process Algebra (2IF45)
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
Question: How do we chose to relate behaviours with internal steps?
Branching bisimulation
29
Process Algebra (2IF45)
Branching bisimilar processes
s
t

t’


a
s’
s
t
t’’
s
tt

s’
s’
a
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:
a
1. for all states s, t, s’  S, whenever (s, t)  R and s →
s’ for some a  A, then there are
a
 t’ and t’ → t’’ and (s, t’), (s’,t’’)  R;
states t’, t’’  S such that t
a
2. vice versa, for all states s, t, s’  S, whenever (s, t)  R and t → t’ for some a  A, then there
a
 s’ and s’ →
are states s’,s’’  S such that s 
s’’ and (s’, t), (s’’,t’)  R;
 t’ , t’ and (s, t’)  R
3. if (s, t)  R and s  then there is a state t’ such that t 
4. 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
30
Is this the right equivalence?

b
a
branching bisimilar!
a
+

+
b
a
b
branching bisimilar
a
31
?
Is this the right equivalence?

b
a
branching bisimilar!
a
+

+
b
a
b
branching bisimilar
a
What is the problem?
32
?
Rooted Branching bisimilar processes
s
t
a
a
t’

a
s’
t’
p
a
s’

q
s
t
a

b
q
s
t
a
t’t
s’

p
p
b
r
Branching Bisimulation relation between state (s, t)  R (as already defined) and the
root condition:
a
a
1. if s → s’ for a  A, then there is a state t’ S such that t → t’ and (s’, t’) R;
a
a
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
33
Process theory with abstraction
Language: TCP(A, )
Signature: 0, 1, (a._ )aA, , +, •, ||, |,
Language terms T(TCP(A, ))
Closed terms C(TCP(A, ))
Deduction rules
Branching Bisimilarity
on LTSs
34
╙, H, I
Axioms
Soundness
Completeness
Process Algebra (2IF45)
Equality of terms
Process theory with abstraction
Language: TCP(A, )
Signature: 0, 1, (a._ )aA, , +, •, ||, |,
Language terms T(TCP(A, ))
Closed terms C(TCP(A, ))
╙, H, I
Deduction rules (as we have seen already)
a y’
y
a x || y’
x || y 
a x’
x
a
x || y 
x’ || y
x y
x || y
x y
x | y
Deduction rules for I
Branching Bisimilarity
on LTSs
35
Soundness
Completeness
Process Algebra (2IF45)
Equality of terms
Process theory with abstraction
Language: TCP(A, )
Signature: 0, 1, (a._ )aA, , +, •, ||, |,
Language terms T(TCP(A, ))
Closed terms C(TCP(A, ))
Deduction rules (as we have seen already)
a y’
y
a x || y’
x || y 
a x’
x
a
x || y 
x’ || y
x y
x || y
Axioms of TCP(A, )
(as we have seen them already)
x y
x | y
Deduction rules for I
Branching Bisimilarity
on LTSs
36
╙, H, I
Axioms for I operator
Soundness
Completeness
Process Algebra (2IF45)
Equality of terms
Axiom for rooted branching bisimulation
rb
a
a

+
+
+
Corresponding axiom
37
Axiom for rooted branching bisimulation
rb
a
a

+
+
+
Corresponding axiom
B axiom
38
a.(.(x+y) + x) = a.(x+y)
Process theory with abstraction
Language: TCP(A, )
Signature: 0, 1, (a._ )aA, , +, •, ||, |,
Language terms T(TCP(A, ))
Closed terms C(TCP(A, ))
Deduction rules (as we have seen already)
a y’
y
a x || y’
x || y 
a x’
x
a
x || y 
x’ || y
╙, H, I
Axioms of TCP(A, )
(as we have seen them already)
Axioms for I operator:
x y
x || y
x y
x | y
Deduction rules for I
Branching Bisimilarity
on LTSs
39
Rooted Branching bisimulation axiom:
a.(.(x+y) + x) = a.(x+y)
Soundness
Completeness
Process Algebra (2IF45)
Equality of terms