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

2. 1 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. 2 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. 3 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 Process Algebra (2IF45)

5. 4 Interleaving semantics for Concurrency a || a b b a b

6. 5 Interleaving semantics for Concurrency a || a b b a b a a b a b cd a d cc b c d b d

7. 6 Interleaving semantics for Concurrency a || a b b a b a a b a b cd a d cc b c d 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. 7 Interleaving semantics for Concurrency a || b a b cd 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. 8 Interleaving semantics for Concurrency c || a db pre-defined communication  (a, b) = e  (a, d) = f  (c, b) = g  (c, d) = h

10. 9 Process Algebra (2IF45) TCP = TSP with parallel composition Deduction rules for parallel composition x  x’ x || y  x’ || y a a x  y  x || y  y  y’ x || y  x || y’ a a x  y  x | 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._ ) a  A, +,, ||, |, ╙,  H, Language terms T(TCP(A,  )) Closed terms C(TCP(A,  )) …

11. 10 Language: TCP(A,  ) Signature: 0, 1, (a._ ) a  A, +,, ||, |, ╙,  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. 11 Language: TCP(A,  ) Signature: 0, 1, (a._ ) a  A, +,, ||, |, ╙,  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. 12 Process Algebra (2IF45) TCP = TSP with parallel composition Deduction rules for parallel composition x  x’ x || y  x’ || y a a x  y  x || y  y  y’ x || y  x || y’ a a x  y  x | 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._ ) a  A, +,, ||, |, ╙,  H, Language terms T(TCP(A,  )) Closed terms C(TCP(A,  )) …

14. 13 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. 14 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. 15 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) SenderReceiver m

17. 16 Abstraction for implementation Example: synchronous communication implemented with asynchronous communication Process Algebra (2IF45) SenderReceiver m High level abstraction: synchronous communication Lower level abstraction: asynchronous reliable (lossless) communication Lowest level abstraction: asynchronous unreliable (lossy) communication abstraction refinement

18. 17 Abstraction for implementation Example: synchronous communication implemented with asynchronous communication Process Algebra (2IF45) SenderReceiver m High level abstraction: synchronous communication Sender = send(m).1Receiver = 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. 18 Abstraction for implementation Example: synchronous communication implemented with asynchronous communication Process Algebra (2IF45) SenderReceiver m Implementation: asynchronous communication Sender = send_toB(m).1Receiver = 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. 19 Abstraction for implementation Example: synchronous communication implemented with asynchronous communication Process Algebra (2IF45) SenderReceiver m Implementation: asynchronous communication Buff m comm_SB(m) comm_BR(m)

21. 20 Abstraction for implementation Example: synchronous communication implemented with asynchronous communication Process Algebra (2IF45) SenderReceiver m Implementation: asynchronous communication Buff m comm_SB(m) comm_BR(m) comm(m) SenderReceiver m Specification: synchronous communication How to equate these behaviours?

22. 21 Abstraction for implementation Example: synchronous communication implemented with asynchronous communication Process Algebra (2IF45) SenderReceiver m Implementation: asynchronous communication Buff m comm_SB(m)  comm_BR(m) comm(m) SenderReceiver m Specification: synchronous communication How to equate these behaviours? 1. Hide actions if needed

23. 22 Abstraction for implementation Example: synchronous communication implemented with asynchronous communication Process Algebra (2IF45) SenderReceiver m Implementation: asynchronous communication Buff m comm_SB(m)  comm_BR(m) comm(m) SenderReceiver m Specification: synchronous communication How to equate these behaviours? 1. Hide actions if needed 2. Rename actions if needed

24. 23 Abstraction for implementation Example: synchronous communication implemented with asynchronous communication Process Algebra (2IF45) SenderReceiver m Implementation: asynchronous communication Buff m  comm(m) SenderReceiver m Specification: synchronous communication How to equate these behaviours? 1. Hide actions if needed 2. Rename actions if needed 3. Use relation that is “internal steps” sensitive

25. 24 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. 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) Check whether: “b not always occurs after a” 1.Hide irrelevant actions, in this case c and d a c a d b a  a  b

27. 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 2. Reduce the model so that the property is preserved a c a d b a  a  b

28. 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 b a  a  b a a b a b or

29. 28 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. 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? Branching bisimulation

31. 30 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’)  R 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  a a a a   

32. 31 Is this the right equivalence? a  a a  a b b b branching bisimilar! branching bisimilar ? + +

33. 32 Is this the right equivalence? a  a a  a b b b branching bisimilar! branching bisimilar ? + + What is the problem?

34. 33 Rooted Branching bisimilar processes t’ q b  s’ b p r t’  s’  p q t  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. 34 Process Algebra (2IF45) Process theory with abstraction Language: TCP  (A,  ) Signature: 0, 1, (a._ ) a  A, , +,, ||, |, ╙,  H,  I Language terms T(TCP  (A,  )) Closed terms C(TCP  (A,  )) Branching Bisimilarity on LTSs Equality of terms Deduction rulesAxioms Completeness Soundness

36. 35 Process Algebra (2IF45) Process theory with abstraction Deduction rules (as we have seen already) x  x’ x || y  x’ || y a a x  y  x || y  y  y’ x || y  x || y’ a a x  y  x | y  Language: TCP  (A,  ) Signature: 0, 1, (a._ ) a  A, , +,, ||, |, ╙,  H,  I Language terms T(TCP  (A,  )) Closed terms C(TCP  (A,  )) Deduction rules for  I Branching Bisimilarity on LTSs Equality of terms Completeness Soundness

37. 36 Process Algebra (2IF45) Process theory with abstraction Deduction rules (as we have seen already) x  x’ x || y  x’ || y a a x  y  x || y  y  y’ x || y  x || y’ a a x  y  x | y  Language: TCP  (A,  ) Signature: 0, 1, (a._ ) a  A, , +,, ||, |, ╙,  H,  I Language terms T(TCP  (A,  )) Closed terms C(TCP  (A,  )) Deduction rules for  I Branching Bisimilarity on LTSs Equality of terms Completeness Soundness Axioms of TCP(A,  ) (as we have seen them already) Axioms for  I operator

38. 37 Axiom for rooted branching bisimulation a  x y x + + … a x y + … rb Corresponding axiom

39. 38 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. 39 Process Algebra (2IF45) Process theory with abstraction Deduction rules (as we have seen already) x  x’ x || y  x’ || y a a x  y  x || y  y  y’ x || y  x || y’ a a x  y  x | y  Language: TCP  (A,  ) Signature: 0, 1, (a._ ) a  A, , +,, ||, |, ╙,  H,  I Language terms T(TCP  (A,  )) Closed terms C(TCP  (A,  )) Deduction rules for  I Branching Bisimilarity on LTSs Equality of terms Completeness 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)