Complex Systems Design & Distributed Calculus and Coordination

Transcription

1 Complex Systems Design & Distributed Calculus and Coordination Concurrency and Process Algebras: Theory and Practice Francesco Tiezzi University of Camerino A.A. 2014/2015 F. Tiezzi (Unicam) CoSyDesign & DCC 1 / 50

2 Who I am Prof. Francesco Tiezzi Associate Professor at University of Camerino web: tel.: francesco.tiezzi@unicam.it address: University of Camerino School of Science and Technology Computer Science Division Palazzo Battibocca Via del Bastione, , Camerino (MC), Italy F. Tiezzi (Unicam) CoSyDesign & DCC 2 / 50

3 Process algebraic approach A Process Algebraic Approach to Complex Systems Design Process algebra: theory that underpins the semantics of concurrent programming and the understanding of concurrent, distributed, and mobile systems It provides a natural approach to the design of those systems structuring them into a set of autonomous components that can evolve independently of each other and from time to time can communicate or simply synchronize compositionality: ability to build complex systems by combining simpler systems abstraction: ability to neglect certain parts of a model Tools assist modeling and analysis of the various functional and non-functional aspects of those systems F. Tiezzi (Unicam) CoSyDesign & DCC 3 / 50

4 Process algebraic approach A Process Algebraic Approach to Complex Systems Design Focus of this part of the course: Tools assist modeling and analysis of the various functional and non-functional aspects of those systems F. Tiezzi (Unicam) CoSyDesign & DCC 3 / 50

5 Outline 1/2 Concurrent Programming and Reactive Systems Process algebraic approach Semantics of regular expressions CCS pseuco TAPAs F. Tiezzi (Unicam) CoSyDesign & DCC 4 / 50

6 Outline 2/2 Behavioural equivalences Modal Logics Other tools: LTSA, mcrl2, UPPAAL Klaim Klava... F. Tiezzi (Unicam) CoSyDesign & DCC 5 / 50

7 What is Concurrent Programming Multiple processes (or threads) working together to achieve a common goal A sequential program has a single thread of control A concurrent program has multiple threads of control allowing it to perform multiple computations in parallel and to control multiple external activities occurring at the same time Communication The concurrent threads exchange information via indirect communication: the execution of concurrent processes proceeds on one or more processors all of which access a shared memory; care is required to deal with shared variables direct communication: concurrent processes are executed by running them on separate processors, threads communicate by exchanging messages F. Tiezzi (Unicam) CoSyDesign & DCC 6 / 50

8 Why Concurrent Programming 1 Performance: To gain from multiprocessing hardware (parallelism) 2 Distribution: Some problems require a distributed solution, e.g. client-server systems on one machine and the database on a central server machine 3 Ease of programming: Some problems are more naturally solved by concurrent programs 4 Increased application throughput: an I/O call need only to block one thread 5 Increased application responsiveness: High priority threads for user requests 6 More appropriate structure: For programs which interact with the environment, control multiple activities and handle multiple events F. Tiezzi (Unicam) CoSyDesign & DCC 7 / 50

9 Examples of multi-threaded programs 1 windowing systems on PCs 2 embedded real-time systems, electronics, cars, telecom 3 web servers, database servers... 4 operating system kernel F. Tiezzi (Unicam) CoSyDesign & DCC 8 / 50

10 Do I need to know about concurrent programming? Concurrency is error prone Soviet nuclear false alarm incident (1983) [fault in sw for missile detections] Therac-25 radiation overdose ( ) [sw interlock fault due to a race condition] MIM-104 Patriot Missile Clock Drift (1991) [a sw fault in the system s clock] Explosion of the Ariane 5 (1996) [self-destruction was triggered by an overflow error] North America blackout (2003) [race condition caused an alarm system failure] Mars Rover problems (2004) [interaction among concurrent tasks caused periodic sw resets]... for sure you have experienced deadlock on your machine and pressed restart (even if you have a Mac) F. Tiezzi (Unicam) CoSyDesign & DCC 9 / 50

11 Do I need to know about concurrent programming? Concurrency is error prone Soviet nuclear false alarm incident (1983) [fault in sw for missile detections] Therac-25 radiation overdose ( ) [sw interlock fault due to a race condition] MIM-104 Patriot Missile Clock Drift (1991) [a sw fault in the system s clock] Explosion of the Ariane 5 (1996) [self-destruction was triggered by an overflow error] North America blackout (2003) [race condition caused an alarm system failure] Mars Rover problems (2004) [interaction among concurrent tasks caused periodic sw resets]... for sure you have experienced deadlock on your machine and pressed restart (even if you have a Mac) F. Tiezzi (Unicam) CoSyDesign & DCC 9 / 50

12 Sequential Programming vs Concurrent Programming Sequential Programming Denotational semantics: the meaning of a program is a partial function from states to states Nontermination is bad! In case of termination, the result is unique Concurrent - Interactive - Reactive Programming Denotational semantics is very complicate due to nondeterminism Nontermination might be good! In case of termination, the result might not be unique F. Tiezzi (Unicam) CoSyDesign & DCC 10 / 50

13 Sequential Programming vs Concurrent Programming Sequential Programming Denotational semantics: the meaning of a program is a partial function from states to states Nontermination is bad! In case of termination, the result is unique Concurrent - Interactive - Reactive Programming Denotational semantics is very complicate due to nondeterminism Nontermination might be good! In case of termination, the result might not be unique F. Tiezzi (Unicam) CoSyDesign & DCC 10 / 50

14 Sequential Programming vs Concurrent Programming Sequential Programming Denotational semantics: the meaning of a program is a partial function from states to states Nontermination is bad! In case of termination, the result is unique Concurrent - Interactive - Reactive Programming Denotational semantics is very complicate due to nondeterminism Nontermination might be good! In case of termination, the result might not be unique F. Tiezzi (Unicam) CoSyDesign & DCC 10 / 50

15 Sequential Programming vs Concurrent Programming Sequential Programming Denotational semantics: the meaning of a program is a partial function from states to states Nontermination is bad! In case of termination, the result is unique Concurrent - Interactive - Reactive Programming Denotational semantics is very complicate due to nondeterminism Nontermination might be good! In case of termination, the result might not be unique F. Tiezzi (Unicam) CoSyDesign & DCC 10 / 50

16 Sequential Programming vs Concurrent Programming Sequential Programming Denotational semantics: the meaning of a program is a partial function from states to states Nontermination is bad! In case of termination, the result is unique Concurrent - Interactive - Reactive Programming Denotational semantics is very complicate due to nondeterminism Nontermination might be good! In case of termination, the result might not be unique F. Tiezzi (Unicam) CoSyDesign & DCC 10 / 50

17 Sequential Programming vs Concurrent Programming Sequential Programming Denotational semantics: the meaning of a program is a partial function from states to states Nontermination is bad! In case of termination, the result is unique Concurrent - Interactive - Reactive Programming Denotational semantics is very complicate due to nondeterminism Nontermination might be good! In case of termination, the result might not be unique F. Tiezzi (Unicam) CoSyDesign & DCC 10 / 50

18 Programming Reactive Systems The classical denotational approach is not adequate for modelling systems such as: Operating systems Communication protocols Mobile phones Vending machines The above systems compute by reacting to stimuli from their environment and are known as Reactive Systems; their distinguishing features are: Interaction (many parallel communicating processes) Nondeterminism (results are not necessarily unique) There may be no visible result (exchange of messages is used to coordinate progress) Nontermination is good (systems are expected to run continuously) F. Tiezzi (Unicam) CoSyDesign & DCC 11 / 50

19 Programming Reactive Systems The classical denotational approach is not adequate for modelling systems such as: Operating systems Communication protocols Mobile phones Vending machines The above systems compute by reacting to stimuli from their environment and are known as Reactive Systems; their distinguishing features are: Interaction (many parallel communicating processes) Nondeterminism (results are not necessarily unique) There may be no visible result (exchange of messages is used to coordinate progress) Nontermination is good (systems are expected to run continuously) F. Tiezzi (Unicam) CoSyDesign & DCC 11 / 50

20 Analysis of Reactive Systems Even short parallel programs may be hard to analyse, thus we need to face few questions: 1 How can we develop (design) a system that works? 2 How do we analyse (verify) such a system? We need appropriate theories and formal methods and tools, otherwise we will experience again: Intels Pentium-II bug in floating-point division unit Ariane-5 crash due to a conversion of 64-bit real to 16-bit integer... F. Tiezzi (Unicam) CoSyDesign & DCC 12 / 50

21 Analysis of Reactive Systems Even short parallel programs may be hard to analyse, thus we need to face few questions: 1 How can we develop (design) a system that works? 2 How do we analyse (verify) such a system? We need appropriate theories and formal methods and tools, otherwise we will experience again: Intels Pentium-II bug in floating-point division unit Ariane-5 crash due to a conversion of 64-bit real to 16-bit integer... F. Tiezzi (Unicam) CoSyDesign & DCC 12 / 50

22 Analysis of Reactive Systems Even short parallel programs may be hard to analyse, thus we need to face few questions: 1 How can we develop (design) a system that works? 2 How do we analyse (verify) such a system? We need appropriate theories and formal methods and tools, otherwise we will experience again: Intels Pentium-II bug in floating-point division unit Ariane-5 crash due to a conversion of 64-bit real to 16-bit integer... F. Tiezzi (Unicam) CoSyDesign & DCC 12 / 50

23 Analysis of Reactive Systems Even short parallel programs may be hard to analyse, thus we need to face few questions: 1 How can we develop (design) a system that works? 2 How do we analyse (verify) such a system? We need appropriate theories and formal methods and tools, otherwise we will experience again: Intels Pentium-II bug in floating-point division unit Ariane-5 crash due to a conversion of 64-bit real to 16-bit integer... F. Tiezzi (Unicam) CoSyDesign & DCC 12 / 50

24 Why formal methods? Understanding the overall behaviour resulting from system interactions can be tricky and error-prone Simple motivating example Consider the code: x = 1; y = x++ + x++; What is the value of x and y after its execution? It is even more critical when concurrency and interactions enter the game... Solid mathematical foundations lay the basis for formal reasoning on systems behavior The programmer can avoid operator ++, but we cannot afford to stop building complex systems we need to build trustworthy systems F. Tiezzi (Unicam) CoSyDesign & DCC 13 / 50

25 Why formal methods? Understanding the overall behaviour resulting from system interactions can be tricky and error-prone Simple motivating example Consider the code: x = 1; y = x++ + x++; What is the value of x and y after its execution? It is even more critical when concurrency and interactions enter the game... Solid mathematical foundations lay the basis for formal reasoning on systems behavior The programmer can avoid operator ++, but we cannot afford to stop building complex systems we need to build trustworthy systems F. Tiezzi (Unicam) CoSyDesign & DCC 13 / 50

26 Why formal methods? Understanding the overall behaviour resulting from system interactions can be tricky and error-prone Simple motivating example Consider the code: x = 1; y = x++ + x++; What is the value of x and y after its execution? It is even more critical when concurrency and interactions enter the game... Solid mathematical foundations lay the basis for formal reasoning on systems behavior The programmer can avoid operator ++, but we cannot afford to stop building complex systems we need to build trustworthy systems F. Tiezzi (Unicam) CoSyDesign & DCC 13 / 50

27 Why formal methods? Understanding the overall behaviour resulting from system interactions can be tricky and error-prone Simple motivating example Consider the code: x = 1; y = x++ + x++; What is the value of x and y after its execution? It is even more critical when concurrency and interactions enter the game... Solid mathematical foundations lay the basis for formal reasoning on systems behavior The programmer can avoid operator ++, but we cannot afford to stop building complex systems we need to build trustworthy systems F. Tiezzi (Unicam) CoSyDesign & DCC 13 / 50

28 Why formal methods? Understanding the overall behaviour resulting from system interactions can be tricky and error-prone Simple motivating example Consider the code: x = 1; y = x++ + x++; What is the value of x and y after its execution? It is even more critical when concurrency and interactions enter the game... Solid mathematical foundations lay the basis for formal reasoning on systems behavior The programmer can avoid operator ++, but we cannot afford to stop building complex systems we need to build trustworthy systems F. Tiezzi (Unicam) CoSyDesign & DCC 13 / 50

29 Why formal methods? Understanding the overall behaviour resulting from system interactions can be tricky and error-prone Simple motivating example Consider the code: x = 1; y = x++ + x++; What is the value of x and y after its execution? It is even more critical when concurrency and interactions enter the game... Solid mathematical foundations lay the basis for formal reasoning on systems behavior The programmer can avoid operator ++, but we cannot afford to stop building complex systems we need to build trustworthy systems F. Tiezzi (Unicam) CoSyDesign & DCC 13 / 50

30 Formal Methods for Reactive Systems To deal with reactive systems and guarantee their correct behaviour in all possible environments, we need: 1 To study mathematical models for the formal description and analysis of concurrent programs 2 To devise formal languages for the specification of the possible behaviour of parallel and reactive systems 3 To develop verification tools and implementation techniques underlying them F. Tiezzi (Unicam) CoSyDesign & DCC 14 / 50

31 Process Algebras Approach The chosen abstraction for reactive systems is the notion of processes Systems evolution is based on process transformation: a process performs an action and becomes another process Everything is (or can be viewed as) a process: buffers, shared memory, tuple spaces, senders, receivers,... are all processes Labelled Transition Systems (LTSs) describe processes behaviour, and permit modelling directly systems interaction F. Tiezzi (Unicam) CoSyDesign & DCC 15 / 50

32 Process Algebras Approach The chosen abstraction for reactive systems is the notion of processes Systems evolution is based on process transformation: a process performs an action and becomes another process Everything is (or can be viewed as) a process: buffers, shared memory, tuple spaces, senders, receivers,... are all processes Labelled Transition Systems (LTSs) describe processes behaviour, and permit modelling directly systems interaction F. Tiezzi (Unicam) CoSyDesign & DCC 15 / 50

33 Internal and External Actions Labelled Transition Systems Transition Labelled Graph: a transition between states is labelled by the action inducing the transition from one state to another Actions An elementary action represents the atomic (non-interruptible) abstract step of a computation that is performed by a system Actions represent various activities of concurrent systems: Sending a message Receiving a message Updating values Synchronizing with other processes... We have two main types of atomic actions: Visible Actions Internal Actions (τ) F. Tiezzi (Unicam) CoSyDesign & DCC 16 / 50

34 Internal and External Actions Labelled Transition Systems Transition Labelled Graph: a transition between states is labelled by the action inducing the transition from one state to another Actions An elementary action represents the atomic (non-interruptible) abstract step of a computation that is performed by a system Actions represent various activities of concurrent systems: Sending a message Receiving a message Updating values Synchronizing with other processes... We have two main types of atomic actions: Visible Actions Internal Actions (τ) F. Tiezzi (Unicam) CoSyDesign & DCC 16 / 50

35 Internal and External Actions Labelled Transition Systems Transition Labelled Graph: a transition between states is labelled by the action inducing the transition from one state to another Actions An elementary action represents the atomic (non-interruptible) abstract step of a computation that is performed by a system Actions represent various activities of concurrent systems: Sending a message Receiving a message Updating values Synchronizing with other processes... We have two main types of atomic actions: Visible Actions Internal Actions (τ) F. Tiezzi (Unicam) CoSyDesign & DCC 16 / 50

36 Why operators for describing systems How can we describe very large automata or LTSs? As a table? Rows and columns are labelled by states, entries are either empty or marked with a set of actions As a listing of triples? = {(q 0, a, q 1 ), (q 0, a, q 2 ), (q 1, b, q 3 ), (q 1, c, q 4 ), (q 2, τ, q 3 ), (q 2, τ, q 4 )} As a more compact listing of triples? = {(q 0, a, {q 1, q 2 }), (q 1, b, q 3 ), (q 1, c, q 4 ), (q 2, τ, {q 3, q 4 })} As XML? <lts><ar><st>q0</st><lab>a</lab><st>q1</st></ar>...</lts> F. Tiezzi (Unicam) CoSyDesign & DCC 17 / 50

37 Why operators for describing systems How can we describe very large automata or LTSs? As a table? Rows and columns are labelled by states, entries are either empty or marked with a set of actions As a listing of triples? = {(q 0, a, q 1 ), (q 0, a, q 2 ), (q 1, b, q 3 ), (q 1, c, q 4 ), (q 2, τ, q 3 ), (q 2, τ, q 4 )} As a more compact listing of triples? = {(q 0, a, {q 1, q 2 }), (q 1, b, q 3 ), (q 1, c, q 4 ), (q 2, τ, {q 3, q 4 })} As XML? <lts><ar><st>q0</st><lab>a</lab><st>q1</st></ar>...</lts> F. Tiezzi (Unicam) CoSyDesign & DCC 17 / 50

38 Why operators for describing systems How can we describe very large automata or LTSs? As a table? Rows and columns are labelled by states, entries are either empty or marked with a set of actions As a listing of triples? = {(q 0, a, q 1 ), (q 0, a, q 2 ), (q 1, b, q 3 ), (q 1, c, q 4 ), (q 2, τ, q 3 ), (q 2, τ, q 4 )} As a more compact listing of triples? = {(q 0, a, {q 1, q 2 }), (q 1, b, q 3 ), (q 1, c, q 4 ), (q 2, τ, {q 3, q 4 })} As XML? <lts><ar><st>q0</st><lab>a</lab><st>q1</st></ar>...</lts> F. Tiezzi (Unicam) CoSyDesign & DCC 17 / 50

39 Why operators for describing systems How can we describe very large automata or LTSs? As a table? Rows and columns are labelled by states, entries are either empty or marked with a set of actions As a listing of triples? = {(q 0, a, q 1 ), (q 0, a, q 2 ), (q 1, b, q 3 ), (q 1, c, q 4 ), (q 2, τ, q 3 ), (q 2, τ, q 4 )} As a more compact listing of triples? = {(q 0, a, {q 1, q 2 }), (q 1, b, q 3 ), (q 1, c, q 4 ), (q 2, τ, {q 3, q 4 })} As XML? <lts><ar><st>q0</st><lab>a</lab><st>q1</st></ar>...</lts> F. Tiezzi (Unicam) CoSyDesign & DCC 17 / 50

40 Why operators for describing systems How can we describe very large automata or LTSs? As a table? Rows and columns are labelled by states, entries are either empty or marked with a set of actions As a listing of triples? = {(q 0, a, q 1 ), (q 0, a, q 2 ), (q 1, b, q 3 ), (q 1, c, q 4 ), (q 2, τ, q 3 ), (q 2, τ, q 4 )} As a more compact listing of triples? = {(q 0, a, {q 1, q 2 }), (q 1, b, q 3 ), (q 1, c, q 4 ), (q 2, τ, {q 3, q 4 })} As XML? <lts><ar><st>q0</st><lab>a</lab><st>q1</st></ar>...</lts> F. Tiezzi (Unicam) CoSyDesign & DCC 17 / 50

41 Why operators for describing systems Linguistic aspects are important! The previous solutions are ok for machines... not for humans Are prefix and sum operators sufficient? They are ok to describe small finite systems p = a.b.(c+d) q = a.(b.c+b.d) r = a.b.c+a.c.d But additional operators are needed to design systems in a structured way (e.g. p q) to model systems interaction to abstract from details to represent infinite systems F. Tiezzi (Unicam) CoSyDesign & DCC 18 / 50

42 Why operators for describing systems Linguistic aspects are important! The previous solutions are ok for machines... not for humans Are prefix and sum operators sufficient? They are ok to describe small finite systems p = a.b.(c+d) q = a.(b.c+b.d) r = a.b.c+a.c.d But additional operators are needed to design systems in a structured way (e.g. p q) to model systems interaction to abstract from details to represent infinite systems F. Tiezzi (Unicam) CoSyDesign & DCC 18 / 50

43 Why operators for describing systems Linguistic aspects are important! The previous solutions are ok for machines... not for humans Are prefix and sum operators sufficient? They are ok to describe small finite systems p = a.b.(c+d) q = a.(b.c+b.d) r = a.b.c+a.c.d But additional operators are needed to design systems in a structured way (e.g. p q) to model systems interaction to abstract from details to represent infinite systems F. Tiezzi (Unicam) CoSyDesign & DCC 18 / 50

44 A motivating example: regular expressions Commonly used for searching and manipulating text based on patterns Example Regular expression: [hc]at (h + c); a; t Text: the cat eats the bat s hat rather than the rat Matches: cat, hat F. Tiezzi (Unicam) CoSyDesign & DCC 19 / 50

45 A motivating example: regular expressions Regular expressions Commonly used for: searching and manipulating text based on patterns representing regular languages in a compact form describing sequences of actions that a system can execute Regular expressions as a simple programming language Programming constructs: sequence, choice, iteration, stop We define the semantics of regular expressions by means of the Structural Operational Semantics approach F. Tiezzi (Unicam) CoSyDesign & DCC 20 / 50

46 A motivating example: regular expressions Regular expressions Commonly used for: searching and manipulating text based on patterns representing regular languages in a compact form describing sequences of actions that a system can execute Regular expressions as a simple programming language Programming constructs: sequence, choice, iteration, stop We define the semantics of regular expressions by means of the Structural Operational Semantics approach F. Tiezzi (Unicam) CoSyDesign & DCC 20 / 50

47 Regular expressions: syntax and informal semantics Abstract syntax E ::= 0 1 a E + E E; E E Operators precedence binds more than + and ; ; binds more than + Informal semantics 0 is the empty event 1 is the terminal event a is an event (or atomic action) where a A, with A finite alphabet E + F can be either E or F (choice operator) E; F is the expression E followed by F (sequencing) E is an n-length sequence of E with n 0 (Kleene star) F. Tiezzi (Unicam) CoSyDesign & DCC 21 / 50

48 Regular expressions: syntax and informal semantics Abstract syntax E ::= 0 1 a E + E E; E E Operators precedence binds more than + and ; ; binds more than + Informal semantics 0 is the empty event 1 is the terminal event a is an event (or atomic action) where a A, with A finite alphabet E + F can be either E or F (choice operator) E; F is the expression E followed by F (sequencing) E is an n-length sequence of E with n 0 (Kleene star) F. Tiezzi (Unicam) CoSyDesign & DCC 21 / 50

49 Regular expressions: syntax and informal semantics Abstract syntax E ::= 0 1 a E + E E; E E Operators precedence binds more than + and ; ; binds more than + Informal semantics 0 is the empty event 1 is the terminal event a is an event (or atomic action) where a A, with A finite alphabet E + F can be either E or F (choice operator) E; F is the expression E followed by F (sequencing) E is an n-length sequence of E with n 0 (Kleene star) F. Tiezzi (Unicam) CoSyDesign & DCC 21 / 50

50 Regular expressions: syntax and informal semantics Abstract syntax E ::= 0 1 a E + E E; E E Operators precedence binds more than + and ; ; binds more than + Informal semantics 0 is the empty event 1 is the terminal event a is an event (or atomic action) where a A, with A finite alphabet E + F can be either E or F (choice operator) E; F is the expression E followed by F (sequencing) E is an n-length sequence of E with n 0 (Kleene star) F. Tiezzi (Unicam) CoSyDesign & DCC 21 / 50

51 Regular expressions: syntax and informal semantics Abstract syntax E ::= 0 1 a E + E E; E E Operators precedence binds more than + and ; ; binds more than + Informal semantics 0 is the empty event 1 is the terminal event a is an event (or atomic action) where a A, with A finite alphabet E + F can be either E or F (choice operator) E; F is the expression E followed by F (sequencing) E is an n-length sequence of E with n 0 (Kleene star) F. Tiezzi (Unicam) CoSyDesign & DCC 21 / 50

52 Regular expressions: syntax and informal semantics Abstract syntax E ::= 0 1 a E + E E; E E Operators precedence binds more than + and ; ; binds more than + Informal semantics 0 is the empty event 1 is the terminal event a is an event (or atomic action) where a A, with A finite alphabet E + F can be either E or F (choice operator) E; F is the expression E followed by F (sequencing) E is an n-length sequence of E with n 0 (Kleene star) F. Tiezzi (Unicam) CoSyDesign & DCC 21 / 50

53 Regular expressions: syntax and informal semantics Abstract syntax E ::= 0 1 a E + E E; E E Operators precedence binds more than + and ; ; binds more than + Informal semantics 0 is the empty event 1 is the terminal event a is an event (or atomic action) where a A, with A finite alphabet E + F can be either E or F (choice operator) E; F is the expression E followed by F (sequencing) E is an n-length sequence of E with n 0 (Kleene star) F. Tiezzi (Unicam) CoSyDesign & DCC 21 / 50

54 Regular expressions: informal semantics With an informal semantics the meaning of composite expressions may be not clear Example (a + b) (a + b ) They are syntactically different What about their meaning? F. Tiezzi (Unicam) CoSyDesign & DCC 22 / 50

55 Regular expressions: informal semantics With an informal semantics the meaning of composite expressions may be not clear Example (a + b) (a + b ) They are syntactically different What about their meaning? F. Tiezzi (Unicam) CoSyDesign & DCC 22 / 50

56 Regular expressions: informal semantics With an informal semantics the meaning of composite expressions may be not clear Example (a + b) (a + b ) They are syntactically different What about their meaning? F. Tiezzi (Unicam) CoSyDesign & DCC 22 / 50

57 Regular expressions: operational semantics We define an abstract machine for executing regular expressions Transition relation Is a ternary relation E µ F, where µ A {ε} (ε empty action) Is defined by an inference system Describes, by induction on the structure of the expressions, the behaviour of a machine that takes as input a regular expression and executes it For a generic operator op we shall have one or more rules like: α E 1 i1 E α i1 E m im E im op(e 1,, E n ) α op(e 1,, E n) where {i 1,, i m } {1,, n} F. Tiezzi (Unicam) CoSyDesign & DCC 23 / 50

58 Regular expressions: operational semantics We define an abstract machine for executing regular expressions Transition relation Is a ternary relation E µ F, where µ A {ε} (ε empty action) Is defined by an inference system Describes, by induction on the structure of the expressions, the behaviour of a machine that takes as input a regular expression and executes it For a generic operator op we shall have one or more rules like: α E 1 i1 E α i1 E m im E im op(e 1,, E n ) α op(e 1,, E n) where {i 1,, i m } {1,, n} F. Tiezzi (Unicam) CoSyDesign & DCC 23 / 50

59 Regular expressions: operational semantics We define an abstract machine for executing regular expressions Transition relation Is a ternary relation E µ F, where µ A {ε} (ε empty action) Is defined by an inference system Describes, by induction on the structure of the expressions, the behaviour of a machine that takes as input a regular expression and executes it For a generic operator op we shall have one or more rules like: α E 1 i1 E α i1 E m im E im op(e 1,, E n ) α op(e 1,, E n) where {i 1,, i m } {1,, n} F. Tiezzi (Unicam) CoSyDesign & DCC 23 / 50

60 Regular expressions: operational semantics Transition relation rules (Tic) (Sum 1 ) (Seq 1 ) (Star 1 ) 1 ε 1 E µ E (Atom) E + F µ E (Sum 2 ) E a E E; F a E ; F E ε 1 (Seq 2 ) (Star 2 ) a a 1 a A F µ F E + F µ F E ε 1 E; F ε F E µ E E µ E ; E Structural Operational Semantics (SOS [Plotkin]) Transition relation is the least relation satisfying the above rules F. Tiezzi (Unicam) CoSyDesign & DCC 24 / 50

61 Regular expressions: operational semantics Transition relation rules (Tic) (Sum 1 ) (Seq 1 ) (Star 1 ) 1 ε 1 E µ E (Atom) E + F µ E (Sum 2 ) E a E E; F a E ; F E ε 1 (Seq 2 ) (Star 2 ) a a 1 a A F µ F E + F µ F E ε 1 E; F ε F E µ E E µ E ; E 1 indicates the terminal state: the machine has completed the execution and loops by executing the empty action F. Tiezzi (Unicam) CoSyDesign & DCC 24 / 50

62 Regular expressions: operational semantics Transition relation rules (Tic) (Sum 1 ) (Seq 1 ) (Star 1 ) 1 ε 1 E µ E (Atom) E + F µ E (Sum 2 ) E a E E; F a E ; F E ε 1 (Seq 2 ) (Star 2 ) a a 1 a A F µ F E + F µ F E ε 1 E; F ε F E µ E E µ E ; E Expression a executes action a and stops F. Tiezzi (Unicam) CoSyDesign & DCC 24 / 50

63 Regular expressions: operational semantics Transition relation rules (Tic) (Sum 1 ) (Seq 1 ) (Star 1 ) 1 ε 1 E µ E (Atom) E + F µ E (Sum 2 ) E a E E; F a E ; F E ε 1 (Seq 2 ) (Star 2 ) a a 1 a A F µ F E + F µ F E ε 1 E; F ε F E µ E E µ E ; E E + F can behave either as E or as F : if E evolves to E by performing action µ then E + F can evolve to E by performing µ; similarly for F F. Tiezzi (Unicam) CoSyDesign & DCC 24 / 50

64 Regular expressions: operational semantics Transition relation rules (Tic) (Sum 1 ) (Seq 1 ) (Star 1 ) 1 ε 1 E µ E (Atom) E + F µ E (Sum 2 ) E a E E; F a E ; F E ε 1 (Seq 2 ) (Star 2 ) a a 1 a A F µ F E + F µ F E ε 1 E; F ε F E µ E E µ E ; E E; F executes the actions of E and, afterwards, the actions of F F. Tiezzi (Unicam) CoSyDesign & DCC 24 / 50

65 Regular expressions: operational semantics Transition relation rules (Tic) (Sum 1 ) (Seq 1 ) (Star 1 ) 1 ε 1 E µ E (Atom) E + F µ E (Sum 2 ) E a E E; F a E ; F E ε 1 (Seq 2 ) (Star 2 ) a a 1 a A F µ F E + F µ F E ε 1 E; F ε F E µ E E µ E ; E E; F executes the actions of E and, afterwards, the actions of F F. Tiezzi (Unicam) CoSyDesign & DCC 24 / 50

66 Regular expressions: operational semantics Transition relation rules (Tic) (Sum 1 ) (Seq 1 ) (Star 1 ) 1 ε 1 E µ E (Atom) E + F µ E (Sum 2 ) E a E E; F a E ; F E ε 1 (Seq 2 ) (Star 2 ) a a 1 a A F µ F E + F µ F E ε 1 E; F ε F E µ E E µ E ; E E; F executes the actions of E and, afterwards, the actions of F F. Tiezzi (Unicam) CoSyDesign & DCC 24 / 50

67 Regular expressions: operational semantics Transition relation rules (Tic) (Sum 1 ) (Seq 1 ) (Star 1 ) 1 ε 1 E µ E (Atom) E + F µ E (Sum 2 ) E a E E; F a E ; F E ε 1 (Seq 2 ) (Star 2 ) a a 1 a A F µ F E + F µ F E ε 1 E; F ε F E µ E E µ E ; E E can either directly evolve to 1 or evolve to E ; E if E evolves to E F. Tiezzi (Unicam) CoSyDesign & DCC 24 / 50

68 Regular expressions: operational semantics Transition relation rules (Tic) (Sum 1 ) (Seq 1 ) (Star 1 ) 1 ε 1 E µ E (Atom) E + F µ E (Sum 2 ) E a E E; F a E ; F E ε 1 (Seq 2 ) (Star 2 ) a a 1 a A F µ F E + F µ F E ε 1 E; F ε F E µ E E µ E ; E E can either directly evolve to 1 or evolve to E ; E if E evolves to E F. Tiezzi (Unicam) CoSyDesign & DCC 24 / 50

69 Regular expressions: operational semantics Transition relation rules (Tic) (Sum 1 ) (Seq 1 ) (Star 1 ) 1 ε 1 E µ E (Atom) E + F µ E (Sum 2 ) E a E E; F a E ; F E ε 1 (Seq 2 ) (Star 2 ) a a 1 a A F µ F E + F µ F E ε 1 E; F ε F E µ E E µ E ; E E can either directly evolve to 1 or evolve to E ; E if E evolves to E F. Tiezzi (Unicam) CoSyDesign & DCC 24 / 50

70 Regular expressions: operational semantics Transition relation rules (Tic) (Sum 1 ) (Seq 1 ) (Star 1 ) 1 ε 1 E µ E (Atom) E + F µ E (Sum 2 ) E a E E; F a E ; F E ε 1 (Seq 2 ) (Star 2 ) a a 1 a A F µ F E + F µ F E ε 1 E; F ε F E µ E E µ E ; E No rule for 0: expression 0 does nothing 0 indicates the deadlock state: the machine is stuck F. Tiezzi (Unicam) CoSyDesign & DCC 24 / 50

71 A few examples for Regular Expressions (a + b) a 1; (a + b) a a + b a 1 a 1 (Atom) (Sum 1 ) (a + b) a 1; (a + b) (Star 2 ) 1; (a + b) ε (a + b) 1 ε 1 (Tic) 1; (a + b) ε (a + b) (Seq 2 ) F. Tiezzi (Unicam) CoSyDesign & DCC 25 / 50

72 A few examples for Regular Expressions (a + b) a 1; (a + b) a a + b a 1 a 1 (Atom) (Sum 1 ) (a + b) a 1; (a + b) (Star 2 ) 1; (a + b) ε (a + b) 1 ε 1 (Tic) 1; (a + b) ε (a + b) (Seq 2 ) F. Tiezzi (Unicam) CoSyDesign & DCC 25 / 50

73 Regular expressions: operational semantics Example (a + b) (a + b ) They are syntactically different Are they semantically equivalent? F. Tiezzi (Unicam) CoSyDesign & DCC 26 / 50

74 Regular expressions: operational semantics Example (a + b) (a + b ) They are syntactically different Are they semantically equivalent? F. Tiezzi (Unicam) CoSyDesign & DCC 26 / 50

75 The automaton associated to a regular expression The SOS inference rules implicitly defines a particular automaton for each regular expression E the initial state is E (we shall often omit to mark it) the set of labels is A the set of states consists of all regular expressions that can be reached starting from E via a sequence of transitions the transition relation is the one induced from the SOS rules the only final state is 1 (we shall often omit to mark it) Semantic correspondence Given any regular expression E, the automaton generated by the SOS rules has the property of recognizing exactly the regular language expressed by E Each trace of the automaton is a term of the language F. Tiezzi (Unicam) CoSyDesign & DCC 27 / 50

76 Regular expressions: operational semantics Automata associated to (a + b) and (a + b ) F. Tiezzi (Unicam) CoSyDesign & DCC 28 / 50

77 Regular expressions: operational semantics Example (a + b) (a + b ) They are syntactically different Are they semantically equivalent? We have to show that: s is a trace of (a + b) if and only if s is a trace of (a + b ) Proof: by induction on the length of s F. Tiezzi (Unicam) CoSyDesign & DCC 29 / 50

78 Regular expressions: operational semantics Example (a + b) (a + b ) They are syntactically different Traces( (a + b) )? = Traces( (a + b ) ) We have to show that: s is a trace of (a + b) if and only if s is a trace of (a + b ) Proof: by induction on the length of s F. Tiezzi (Unicam) CoSyDesign & DCC 29 / 50

79 Regular expressions: operational semantics Example (a + b) (a + b ) They are syntactically different Traces( (a + b) )? = Traces( (a + b ) ) We have to show that: s is a trace of (a + b) if and only if s is a trace of (a + b ) Proof: by induction on the length of s F. Tiezzi (Unicam) CoSyDesign & DCC 29 / 50

80 CCS Basics Sequential Fragment Nil process (the only atomic process) action prefixing (a.p) names and recursive definitions ( ) nondeterministic choice (+) Any finite LTS can be described (up to isomorphism) by using the operations above Parallelism and Renaming parallel composition ( ) (synchronous communication between two components = handshake synchronization) restriction (P L) relabelling (P[f ]) F. Tiezzi (Unicam) CoSyDesign & DCC 30 / 50

81 CCS Basics Sequential Fragment Nil process (the only atomic process) action prefixing (a.p) names and recursive definitions ( ) nondeterministic choice (+) Any finite LTS can be described (up to isomorphism) by using the operations above Parallelism and Renaming parallel composition ( ) (synchronous communication between two components = handshake synchronization) restriction (P L) relabelling (P[f ]) F. Tiezzi (Unicam) CoSyDesign & DCC 30 / 50

82 CCS Basics Sequential Fragment Nil process (the only atomic process) action prefixing (a.p) names and recursive definitions ( ) nondeterministic choice (+) Any finite LTS can be described (up to isomorphism) by using the operations above Parallelism and Renaming parallel composition ( ) (synchronous communication between two components = handshake synchronization) restriction (P L) relabelling (P[f ]) F. Tiezzi (Unicam) CoSyDesign & DCC 30 / 50

83 Definition of CCS: channels, actions, process names Let A be a set of channel names (e.g. tea, coffee are channel names) L = A A be a set of labels where A = {a a A} (elements of A are called names and those of A are called co-names) by convention a = a Act = L {τ} is the set of actions where τ is the internal or silent action (e.g. τ, tea, coffee are actions) K is a set of process names (constants) (e.g. CM). F. Tiezzi (Unicam) CoSyDesign & DCC 31 / 50

84 Definition of CCS (expressions) P := K process constants (K K) α.p prefixing (α Act) i I P i summation (I is an arbitrary index set) P 1 P 2 parallel composition P L restriction (L A) P[f ] relabelling (f : Act Act) such that f (τ) = τ f (a) = f (a) The set of all terms generated by the abstract syntax is the set of CCS process expressions (and is denoted by P) Notation P 1 + P 2 = i {1,2} P i Nil = i P i F. Tiezzi (Unicam) CoSyDesign & DCC 32 / 50

85 Precedence Precedence 1 restriction and relabelling (tightest binding) 2 action prefixing 3 parallel composition 4 summation Example: R + a.p b.q L means R + ( (a.p) (b.(q L)) ) F. Tiezzi (Unicam) CoSyDesign & DCC 33 / 50

86 Definition of CCS (defining equations) CCS program A collection of defining equations of the form K P where K K is a process constant and P P is a CCS process expression. Only one defining equation per process constant. Recursion is allowed: e.g. A a.a A. F. Tiezzi (Unicam) CoSyDesign & DCC 34 / 50

87 Structural Operational Semantics for CCS Structural Operational Semantics (SOS) G. Plotkin 1981 Small-step operational semantics where the behaviour of a system is inferred using syntax driven rules Given a collection of CCS defining equations, we define the following LTS (Proc, Act, { a a Act}): Proc = P (the set of all CCS process expressions) Act = L {τ} (the set of all CCS actions including τ) transition relation is given by SOS rules of the form: RULE premises conclusion conditions F. Tiezzi (Unicam) CoSyDesign & DCC 35 / 50

88 SOS rules for CCS (α Act, a L) ACT α.p α P α P j P j SUM j i I P α i P j j I COM1 P α P P Q α P Q COM2 COM3 P a P Q a Q P Q τ P Q α Q Q P Q α P Q RES P α P P L α P L α, α L REL P α P P[f ] f (α) P [f ] CON P α P K α P K P F. Tiezzi (Unicam) CoSyDesign & DCC 36 / 50

89 Deriving Transitions in CCS Let A a.a. Then ( (A a.nil) b.nil ) [c/a] c ( (A a.nil) b.nil ) [c/a]. Why? F. Tiezzi (Unicam) CoSyDesign & DCC 37 / 50

90 Deriving Transitions in CCS Let A a.a. Then ( (A a.nil) b.nil ) [c/a] c ( (A a.nil) b.nil ) [c/a]. Why? REL ( (A a.nil) b.nil ) [c/a] c ( (A a.nil) b.nil ) [c/a] F. Tiezzi (Unicam) CoSyDesign & DCC 37 / 50

91 Deriving Transitions in CCS Let A a.a. Then ( (A a.nil) b.nil ) [c/a] c ( (A a.nil) b.nil ) [c/a]. Why? COM1 a (A a.nil) b.nil (A a.nil) b.nil REL ( ) c (A a.nil) b.nil [c/a] ( (A a.nil) b.nil ) [c/a] F. Tiezzi (Unicam) CoSyDesign & DCC 37 / 50

92 Deriving Transitions in CCS Let A a.a. Then ( (A a.nil) b.nil ) [c/a] c ( (A a.nil) b.nil ) [c/a]. Why? REL COM1 a A a.nil A a.nil COM1 a (A a.nil) b.nil (A a.nil) b.nil ( ) c (A a.nil) b.nil [c/a] ( (A a.nil) b.nil ) [c/a] F. Tiezzi (Unicam) CoSyDesign & DCC 37 / 50

93 Deriving Transitions in CCS Let A a.a. Then ( (A a.nil) b.nil ) [c/a] c ( (A a.nil) b.nil ) [c/a]. Why? REL CON a A a.a A A COM1 a A a.nil A a.nil COM1 a (A a.nil) b.nil (A a.nil) b.nil ( ) c (A a.nil) b.nil [c/a] ( (A a.nil) b.nil ) [c/a] F. Tiezzi (Unicam) CoSyDesign & DCC 37 / 50

94 Deriving Transitions in CCS Let A a.a. Then ( (A a.nil) b.nil ) [c/a] c ( (A a.nil) b.nil ) [c/a]. Why? REL COM1 ACT a a.a A CON A a A COM1 a A a.a A a.nil A a.nil a (A a.nil) b.nil (A a.nil) b.nil ( ) c (A a.nil) b.nil [c/a] ( (A a.nil) b.nil ) [c/a] F. Tiezzi (Unicam) CoSyDesign & DCC 37 / 50

95 LTS of the Process a.nil a.nil a.nil a.nil a a Nil a.nil τ a.nil Nil a a Nil Nil F. Tiezzi (Unicam) CoSyDesign & DCC 38 / 50

96 CCS in pseuco pseuco Web application allowing to create CCS specifications and interactively explore the resulting transition systems F. Tiezzi (Unicam) CoSyDesign & DCC 39 / 50

97 CCS in pseuco: regular expressions (a + b) X := ((a.1 + b.1);x) + 1 // this is the initial process X (a + b ) Y := ((Ya + Yb);Y) + 1 Ya := a. Ya + 1 Yb := b. Yb + 1 // this is the initial process Y Demo! F. Tiezzi (Unicam) CoSyDesign & DCC 40 / 50

98 CCS in pseuco: regular expressions (a + b) X := ((a.1 + b.1);x) + 1 // this is the initial process X (a + b ) Y := ((Ya + Yb);Y) + 1 Ya := a. Ya + 1 Yb := b. Yb + 1 // this is the initial process Y Demo! F. Tiezzi (Unicam) CoSyDesign & DCC 40 / 50

99 Producer-Consumer Example F. Tiezzi (Unicam) CoSyDesign & DCC 41 / 50

100 Producer-Consumer Example The system is composed of a producer a finite-capacity buffer a consumer The producer deposits items into the buffer as long as the buffer capacity is not exceeded Stored items can be withdrawn by the consumer according to some predefined discipline, like FIFO or LIFO Assumptions: The buffer has only two positions Items are all identical, so that the specific discipline that has been adopted for withdrawals is not important from the point of view of an external observer Demo! F. Tiezzi (Unicam) CoSyDesign & DCC 42 / 50

101 Producer-Consumer Example The system is composed of a producer a finite-capacity buffer a consumer The producer deposits items into the buffer as long as the buffer capacity is not exceeded Stored items can be withdrawn by the consumer according to some predefined discipline, like FIFO or LIFO Assumptions: The buffer has only two positions Items are all identical, so that the specific discipline that has been adopted for withdrawals is not important from the point of view of an external observer Demo! F. Tiezzi (Unicam) CoSyDesign & DCC 42 / 50

102 TAPAs Software tool supporting teaching of process algebras TAPAs permits: understanding the meaning of the different process algebras operators appreciating the close correspondence between textual terms and graphical representations of processes evaluating different behavioural equivalences model checking via a user-friendly tool that, in case of failures, provides appropriate counterexamples F. Tiezzi (Unicam) CoSyDesign & DCC 43 / 50

103 TAPAs F. Tiezzi (Unicam) CoSyDesign & DCC 44 / 50

104 TAPAs: CCSP (CCS+CSP) syntax F. Tiezzi (Unicam) CoSyDesign & DCC 45 / 50

105 TAPAs: CCSP (CCS+CSP) semantics 1/3 F. Tiezzi (Unicam) CoSyDesign & DCC 46 / 50

106 TAPAs: CCSP (CCS+CSP) semantics 1/3 F. Tiezzi (Unicam) CoSyDesign & DCC 46 / 50

107 TAPAs: CCSP (CCS+CSP) semantics 2/3 F. Tiezzi (Unicam) CoSyDesign & DCC 47 / 50

108 TAPAs: CCSP (CCS+CSP) semantics 2/3 F. Tiezzi (Unicam) CoSyDesign & DCC 47 / 50

109 TAPAs: CCSP (CCS+CSP) semantics 3/3 F. Tiezzi (Unicam) CoSyDesign & DCC 48 / 50

110 Producer-Consumer Example in TAPAs The system is composed of a producer a finite-capacity buffer a consumer The producer deposits items into the buffer as long as the buffer capacity is not exceeded Stored items can be withdrawn by the consumer according to some predefined discipline, like FIFO or LIFO Assumptions: The buffer has only two positions Items are all identical, so that the specific discipline that has been adopted for withdrawals is not important from the point of view of an external observer Demo! F. Tiezzi (Unicam) CoSyDesign & DCC 49 / 50

111 Producer-Consumer Example in TAPAs The system is composed of a producer a finite-capacity buffer a consumer The producer deposits items into the buffer as long as the buffer capacity is not exceeded Stored items can be withdrawn by the consumer according to some predefined discipline, like FIFO or LIFO Assumptions: The buffer has only two positions Items are all identical, so that the specific discipline that has been adopted for withdrawals is not important from the point of view of an external observer Demo! F. Tiezzi (Unicam) CoSyDesign & DCC 49 / 50

112 Producer-Consumer Example in TAPAs F. Tiezzi (Unicam) CoSyDesign & DCC 50 / 50