- Email: [email protected]
Using Failures and Category Theory to Verify Process Communications between Design and Implementation of Concurrent Systems
Available online at www.sciencedirect.com
ScienceDirect Procedia Computer Science 83 (2016) 700 – 704
The 7th International Conference on Ambient Systems, Networks and Technologies (ANT 2016)
Using Failures and Category Theory to Verify Process Communications between Design and Implementation of Concurrent Systems Ming Zhua , Peter Grogonoa , Olga Ormandjievaa , Heng Kuangb a Department
of Computer Science and Software Engineering, Concordia University, Montreal, Canada b IBM Canada, Markham, Canada
Abstract The process-oriented design and implementation of concurrent systems have important advantages. However, it is challenging to verify the consistency of process communications between the design and the implementation. To deal with such a challenge, we construct a formal framework for designing, implementing and verifying the consistency of process communications. In this framework, we use Failures in Communicating Sequential Processes (CSP), Erasmus and Category Theory as the foundation. The framework is illustrated by using a running example. TheAuthors. Authors.Published Published Elsevier © 2016The © 2016 by by Elsevier B.V.B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the Conference Program Chairs. Peer-review under responsibility of the Conference Program Chairs
Keywords: concurrent system; verification; category theory; Failures; CSP; process-oriented programming
1. Introduction Process-oriented approach is a necessary concept for designing and implementing concurrent systems 1 . However, design and implementation are usually at different levels of abstraction in software development process. It is challenging to incorporate knowledge and experience to control the consistency between those phases 2 . To deal with this, verification plays a critical role in checking the consistency between design and implementation of a concurrent system 3 . Research 4,5 used category theory, dataflow and traces of processes to explore approaches that may address that challenge. As a continuation, this paper uses failures to verify the consistency of process communications between design and implementation of concurrent systems. The rest of this paper is organized as follows: Section 2 provides background knowledge and related work on the Communicating Sequential Processes (CSP), the process-oriented programming language Erasmus, and category ∗
Olga Ormandjieva. Tel.: +1-514-848-2424 (ext.7810) ; fax: +1-514-848-2830. E-mail address: [email protected]
1877-0509 © 2016 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the Conference Program Chairs doi:10.1016/j.procs.2016.04.155
Ming Zhu et al. / Procedia Computer Science 83 (2016) 700 – 704
theory. In Section 3, the categorical framework is introduced for formally designing, implementing, and verifying concurrent systems. In section 4, each step in that framework is applied to a running example. Section 5 concludes our paper and suggests directions for future research. 2. Background and Related Work In this section, the background and related work on our research are introduced. 2.1. Communicating Sequential Processes Process algebra has been developed to model concurrent systems by describing algebras of communicating processes. CSP is a process algebra that formally models concurrent systems by events 6,7 . It has been widely used to specify, design and implement concurrent systems. In CSP, a process is defined as (alphabet, failures, divergences) 6,7 . If a process is assumed not to become chaos, (alphabet, failures) is enough to describe safety and liveness of the process 1 . Several operators are defined to describe the relationships between processes. Given two processes P and Q, CSP can calculate sequence P ; Q, deterministic choice P Q, non-deterministic choice P Q, parallel execution P Q, and iteration, using the recursion operator μP : A · F(P). Traces, failures and divergences with operations on processes are used to analyze the liveness and correctness of processes 1 . Besides, traces are used to verify process communications between design and implementation 5 . 2.2. Erasmus Process-oriented programming is predicted to be the next programming paradigm 1,8 . The foundation of processoriented programming is process algebra 9 . Erasmus is a process-oriented programming language based on CSP but with some differences 8 . An Erasmus program consists of cells, processes, ports, protocols and channels . A cell, containing a collection of one or more processes or cells, provides the structuring mechanism for an Erasmus program. A process is a self-contained entity which performs computations, and communicates with other processes through its ports. A port, which is of a type of protocol, serves as an interface of a process for sending and receiving messages. A protocol specifies the type and the orderings of messages that can be sent and received by the ports of the type of this protocol. A channel, which is of a type of protocol, links two ports and so enables two processes to communicate. Some research is proposed to study communications in Erasmus, which includes constructing a fair protocol that allows arbitrary, nondeterministic communication between processes 10 , and building a static analyzer to detect communication errors between processes 11 . 2.3. Category Theory Due to its abstractness and generality, category theory has led to its use as a conceptual framework in many areas of computer science 12 and software engineering 13 . It is suggested that category theory can be helpful towards discovering and verifying connections in different areas, while preserving structures in those areas 14 . In software engineering, category theory is proposed as an approach to formalizing refinement from design to implementation 15 . Specifically, for modeling concurrency, category theory is used to model, analyze, and compare Transition Systems, Trace Languages, Event Structures, Petri nets, and other classical models of concurrency 16 . However, to the best of our knowledge, there is no such kind of categorical framework for verifying the consistency between process-oriented design and implementation. The aim of this paper is to work on the categorical framework based on research 4,5 . In this paper, we use the constructs Category and Functor from category theory for the verification. 3. The Categorical Framework Based on research 4,5 , the categorical framework for verification consists of the following steps (See Fig. 1). (1). Designing: design concurrent systems in CSP, and analyze failures of processes together with communications, (2). Implementing: implement concurrent systems in Erasmus with the design refinement,
701
702
Ming Zhu et al. / Procedia Computer Science 83 (2016) 700 – 704 Communication Structure-Preserving Transformation
Design Refined-Into
Verify Abstract
Implementation
Categorical models of design
Abstraction of implementation
Communication Structure-Preserving Transformation
Categorical models of abstraction of implementation
Fig. 1. The Categorical Framework
(3). Analyzing Abstraction: abstract processes and communications out of the implementation, and analyze failures of abstracted processes as well as communications, (4). Categorizing Design: construct categorical models for the design with preserving structures of communications, (5). Categorizing Abstraction of Implementation: construct categorical models for the abstraction of implementation with preserving structures of communications, and (6). Verifying: construct functors to verify the categorical models of the design and the abstraction. Each of these steps is discussed in the following sections, detailed discussion and proofs are omitted in this short paper. 4. Illustrating the Framework by a Running Example To present the research activities, a vending machine example is given to illustrate the framework. In the example, a customer orders a drink from a vending machine. The vending machine offers tea as well as coffee, and it operates according to the following process: (1). it accepts a coin from the customer, and (2). it accepts a choice of drink from the customer before dispensing the drink. The vending machine can repeat this process indefinitely. The customer can use the vending machine only once to order tea or coffee. In the design stage, a simple version of the vending machine is created by using CSP. In the implementation stage, an enhanced vending machine from the design is implemented in Erasmus. Category theory is used to verify the consistency of process communications between the design and the implementation. 4.1. Designing the Example In the design stage, the vending machine and the customer are modeled as processes VendingMachine and Customer respectively. Both processes communicate two messages: one is coin, and the other is tea or coffee. A drink is randomly chosen by Customer. The drink offered by VendingMachine is based on the choice of Customer. According to the failures in CSP, communications between Customer and VendingMachine are modeled and analyzed as follows: Alphabet(Customer VendingMachine) ={coin,tea,coffee} Failures(Customer VendingMachine) ={{(, X)|X ⊆ {tea,coffee}}, {(coin, X)|X ⊆ {coin}}, {(coin, tea, X)|X ⊆ {coin,tea,coffee}}, {(coin,coffee, X)|X ⊆ {coin,tea,coffee}}}
4.2. Implementing the Example The implemented vending machine and customer can do more than the design requires: the customer can ask the vending machine to refund the coin instead of ordering a drink. The Erasmus code for the implementation is as follows: Drinks = protocol {coin; refund|coffee|tea; stop} VendingMachine = process order: +Drinks{ loop{
Ming Zhu et al. / Procedia Computer Science 83 (2016) 700 – 704
order.coin; select{ ||order.refund ||order.tea ||order.coffee } } } Customer = process get: -Drinks{ get.coin; case{ ||get.refund ||get.tea ||get.coffee } } Main = cell{chnl: Channel Drinks; VendingMachine(chnl); Customer(chnl)}
4.3. Analyzing Abstraction of the Example According to our former research 5 , the implementation of the vending machine example is abstracted as follows: person = coin; case{ refund| tea| coffee } vendingMachine = loop{ coin; select{ refund| tea| coffee }}
According to the failures in CSP and our former research 5 , communications between customer and vendingMachine in the implementation are modeled and analyzed as follows: Alphabet(CustomerVendingMachine) ={coin, tea, refund, coffee} Failures(CustomerVendingMachine) ={(, X) | X ⊆ {refund, tea, coffee}}, {(coin, X) | X ⊆ {coin}}, {(coin,refund, X) | X ⊆ {coin, refund, tea, coffee}}, {(coin,tea, X) | X ⊆ {coin, refund, tea, coffee}}, {(coin,coffee, X) | X ⊆ {coin, refund, tea, coffee}}}
4.4. Categorizing Failures of Communications in the Design and the Implementation Based on the Definition 4.1, categories for communications in the design (design) and the implementation (Implementation) are constructed (See Fig. 2). Definition 4.1. Category of Failures: Each object is of the form (alphabet, failures) to indicate a process. A Morphism A → B means process A evolves to process B, where alphabeta = alphabetb , and failuresa ⊆ failuresb . 4.5. Verifying the Implementation Against the Design In the implementation, not only can the custom order tea or coffee, but the vending machine can refund the coin. According to research 5 , the construction of a functor in proposition 1 can be used to check whether the approach of ordering tea or coffee in Implementation conforms to the approach of ordering tea or coffee in design (See Fig. 2). Proposition 1. design → implementation is a functor. This functor maps objects and morphisms in design to the corresponding objects and morphisms in implementation as follows:(1). For each object, ocd, in design, there must be a corresponding object, oci, in implementation, such that ocd can be mapped to oci when each trace in ocd have the same trace in oci, and the corresponding refusal in ocd is a subset of the corresponding refusal in oci. (2). For each morphism md : ocd1 → ocd2 in design, there must be a corresponding morphism mi : oci1 → oci2 in implementation, such that md can be mapped to mi when ocd1 and ocd2 can be mapped to oci1 and oci2 respectively.
703
704
Ming Zhu et al. / Procedia Computer Science 83 (2016) 700 – 704
Fig. 2. The functor and categories
5. Conclusion and Future Work As the continuation of our former research 4,5 , this paper exploits failures of communications to formally verify consistency of process communications between design and implementation of concurrent systems. To illustrate those research activities, a concurrent system is created. In doing so, the design of the system is modeled and analyzed by failures; the implementation of the system is developed in Erasmus; the failures of the implementation are analyzed based on abstraction; categories of failures from the design and implementation are created; and by constructing functors, the consistency of process communications between the design and the implementation is verified. Some activities towards the categorical verification are specified in this paper. As a future work, an in depth explanation with details and proofs will be carried out . References 1. P. Welch. Life of occam-pi. In Communicating Process Architectures 2013. Open Channel Publishing Ltd., 2013. 2. J.R. Kiniry and F. Fairmichael. Ensuring consistency between designs, documentation,formal specifications, and implementations. In Proceedings of 12th International Symposium on Component-Based Software Engineering, pages 242–261, 2009. 3. P. Godefroid. Partial-order methods for the verification of concurrent systems: an approach to the state-explosion problem. Springer, Secaucus, United States, 1996. 4. M. Zhu, P. Grogono, O. Ormandjieva, and P. Kamthan. Using category theory and data flow analysis for modeling and verifying properties of communications in the process-oriented language erasmus. In Proceedings of the Seventh C* Conference on Computer Science and Software Engineering, pages 24:1–24:4, 2014. 5. M. Zhu, P. Grogono, and O. Ormandjieva. Using category theory to verify implementation against design in concurrent systems. In The 6th International Conference on Ambient Systems, Networks and Technologies, pages 530–537, 2015. 6. C.A.R. Hoare. Communicating sequential processes. Prentice-Hall, Englewood Cliffs, United States, 1985. 7. A.W. Roscoe. Understanding concurrent systems. Springer, London, United Kingdom, 2010. 8. P. Grogono and B. Shearing. Concurrent software engineering: Preparing for paradigm shift. In Proceedings of the First C* Conference on Computer Science and Software Engineering, pages 99–108, 2008. 9. A.T. Sampson. Process-oriented patterns for concurrent software engineering. PhD thesis, University of Kent, Kent, United Kingdom, 2008. 10. P. Grogono and N. Jafroodi. A fair protocol for non-deterministic message passing. In Proceedings of the Third C* Conference on Computer Science and Software Engineering, C3S2E ’10, pages 53–58, 2010. 11. M. Zakeryfar and P. Grogono. Static analysis of concurrent programs by adapted vector clock. In Proceedings of the Sixth International C* Conference on Computer Science and Software Engineering, pages 58–66, 2013. 12. M. Barr and C. Wells. Category theory for computing science. Prentice-Hall, Upper Saddle River,United States, 2012. 13. J.L. Fiadeiro. Categories for software engineering. Springer Berlin Heidelberg, Germany, 2005. 14. S. Awodey. Category theory. The Clarendon Press Oxford University Press, New York, 2006. 15. C.A.R. Hoare. Notes on an approach to category theory for computer scientists. Constructive Methods in Computing Science, 55:245–305, 1989. 16. G. Winskel and M. Nielsen. Models for concurrency. In Handbook of Logic in Computer Science, volume 4, pages 1–148. Oxford University Press, Oxford, United Kingdom, 1995.
ScienceDirect Procedia Computer Science 83 (2016) 700 – 704
The 7th International Conference on Ambient Systems, Networks and Technologies (ANT 2016)
Using Failures and Category Theory to Verify Process Communications between Design and Implementation of Concurrent Systems Ming Zhua , Peter Grogonoa , Olga Ormandjievaa , Heng Kuangb a Department
of Computer Science and Software Engineering, Concordia University, Montreal, Canada b IBM Canada, Markham, Canada
Abstract The process-oriented design and implementation of concurrent systems have important advantages. However, it is challenging to verify the consistency of process communications between the design and the implementation. To deal with such a challenge, we construct a formal framework for designing, implementing and verifying the consistency of process communications. In this framework, we use Failures in Communicating Sequential Processes (CSP), Erasmus and Category Theory as the foundation. The framework is illustrated by using a running example. TheAuthors. Authors.Published Published Elsevier © 2016The © 2016 by by Elsevier B.V.B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the Conference Program Chairs. Peer-review under responsibility of the Conference Program Chairs
Keywords: concurrent system; verification; category theory; Failures; CSP; process-oriented programming
1. Introduction Process-oriented approach is a necessary concept for designing and implementing concurrent systems 1 . However, design and implementation are usually at different levels of abstraction in software development process. It is challenging to incorporate knowledge and experience to control the consistency between those phases 2 . To deal with this, verification plays a critical role in checking the consistency between design and implementation of a concurrent system 3 . Research 4,5 used category theory, dataflow and traces of processes to explore approaches that may address that challenge. As a continuation, this paper uses failures to verify the consistency of process communications between design and implementation of concurrent systems. The rest of this paper is organized as follows: Section 2 provides background knowledge and related work on the Communicating Sequential Processes (CSP), the process-oriented programming language Erasmus, and category ∗
Olga Ormandjieva. Tel.: +1-514-848-2424 (ext.7810) ; fax: +1-514-848-2830. E-mail address: [email protected]
1877-0509 © 2016 The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/). Peer-review under responsibility of the Conference Program Chairs doi:10.1016/j.procs.2016.04.155
Ming Zhu et al. / Procedia Computer Science 83 (2016) 700 – 704
theory. In Section 3, the categorical framework is introduced for formally designing, implementing, and verifying concurrent systems. In section 4, each step in that framework is applied to a running example. Section 5 concludes our paper and suggests directions for future research. 2. Background and Related Work In this section, the background and related work on our research are introduced. 2.1. Communicating Sequential Processes Process algebra has been developed to model concurrent systems by describing algebras of communicating processes. CSP is a process algebra that formally models concurrent systems by events 6,7 . It has been widely used to specify, design and implement concurrent systems. In CSP, a process is defined as (alphabet, failures, divergences) 6,7 . If a process is assumed not to become chaos, (alphabet, failures) is enough to describe safety and liveness of the process 1 . Several operators are defined to describe the relationships between processes. Given two processes P and Q, CSP can calculate sequence P ; Q, deterministic choice P Q, non-deterministic choice P Q, parallel execution P Q, and iteration, using the recursion operator μP : A · F(P). Traces, failures and divergences with operations on processes are used to analyze the liveness and correctness of processes 1 . Besides, traces are used to verify process communications between design and implementation 5 . 2.2. Erasmus Process-oriented programming is predicted to be the next programming paradigm 1,8 . The foundation of processoriented programming is process algebra 9 . Erasmus is a process-oriented programming language based on CSP but with some differences 8 . An Erasmus program consists of cells, processes, ports, protocols and channels . A cell, containing a collection of one or more processes or cells, provides the structuring mechanism for an Erasmus program. A process is a self-contained entity which performs computations, and communicates with other processes through its ports. A port, which is of a type of protocol, serves as an interface of a process for sending and receiving messages. A protocol specifies the type and the orderings of messages that can be sent and received by the ports of the type of this protocol. A channel, which is of a type of protocol, links two ports and so enables two processes to communicate. Some research is proposed to study communications in Erasmus, which includes constructing a fair protocol that allows arbitrary, nondeterministic communication between processes 10 , and building a static analyzer to detect communication errors between processes 11 . 2.3. Category Theory Due to its abstractness and generality, category theory has led to its use as a conceptual framework in many areas of computer science 12 and software engineering 13 . It is suggested that category theory can be helpful towards discovering and verifying connections in different areas, while preserving structures in those areas 14 . In software engineering, category theory is proposed as an approach to formalizing refinement from design to implementation 15 . Specifically, for modeling concurrency, category theory is used to model, analyze, and compare Transition Systems, Trace Languages, Event Structures, Petri nets, and other classical models of concurrency 16 . However, to the best of our knowledge, there is no such kind of categorical framework for verifying the consistency between process-oriented design and implementation. The aim of this paper is to work on the categorical framework based on research 4,5 . In this paper, we use the constructs Category and Functor from category theory for the verification. 3. The Categorical Framework Based on research 4,5 , the categorical framework for verification consists of the following steps (See Fig. 1). (1). Designing: design concurrent systems in CSP, and analyze failures of processes together with communications, (2). Implementing: implement concurrent systems in Erasmus with the design refinement,
701
702
Ming Zhu et al. / Procedia Computer Science 83 (2016) 700 – 704 Communication Structure-Preserving Transformation
Design Refined-Into
Verify Abstract
Implementation
Categorical models of design
Abstraction of implementation
Communication Structure-Preserving Transformation
Categorical models of abstraction of implementation
Fig. 1. The Categorical Framework
(3). Analyzing Abstraction: abstract processes and communications out of the implementation, and analyze failures of abstracted processes as well as communications, (4). Categorizing Design: construct categorical models for the design with preserving structures of communications, (5). Categorizing Abstraction of Implementation: construct categorical models for the abstraction of implementation with preserving structures of communications, and (6). Verifying: construct functors to verify the categorical models of the design and the abstraction. Each of these steps is discussed in the following sections, detailed discussion and proofs are omitted in this short paper. 4. Illustrating the Framework by a Running Example To present the research activities, a vending machine example is given to illustrate the framework. In the example, a customer orders a drink from a vending machine. The vending machine offers tea as well as coffee, and it operates according to the following process: (1). it accepts a coin from the customer, and (2). it accepts a choice of drink from the customer before dispensing the drink. The vending machine can repeat this process indefinitely. The customer can use the vending machine only once to order tea or coffee. In the design stage, a simple version of the vending machine is created by using CSP. In the implementation stage, an enhanced vending machine from the design is implemented in Erasmus. Category theory is used to verify the consistency of process communications between the design and the implementation. 4.1. Designing the Example In the design stage, the vending machine and the customer are modeled as processes VendingMachine and Customer respectively. Both processes communicate two messages: one is coin, and the other is tea or coffee. A drink is randomly chosen by Customer. The drink offered by VendingMachine is based on the choice of Customer. According to the failures in CSP, communications between Customer and VendingMachine are modeled and analyzed as follows: Alphabet(Customer VendingMachine) ={coin,tea,coffee} Failures(Customer VendingMachine) ={{(, X)|X ⊆ {tea,coffee}}, {(coin, X)|X ⊆ {coin}}, {(coin, tea, X)|X ⊆ {coin,tea,coffee}}, {(coin,coffee, X)|X ⊆ {coin,tea,coffee}}}
4.2. Implementing the Example The implemented vending machine and customer can do more than the design requires: the customer can ask the vending machine to refund the coin instead of ordering a drink. The Erasmus code for the implementation is as follows: Drinks = protocol {coin; refund|coffee|tea; stop} VendingMachine = process order: +Drinks{ loop{
Ming Zhu et al. / Procedia Computer Science 83 (2016) 700 – 704
order.coin; select{ ||order.refund ||order.tea ||order.coffee } } } Customer = process get: -Drinks{ get.coin; case{ ||get.refund ||get.tea ||get.coffee } } Main = cell{chnl: Channel Drinks; VendingMachine(chnl); Customer(chnl)}
4.3. Analyzing Abstraction of the Example According to our former research 5 , the implementation of the vending machine example is abstracted as follows: person = coin; case{ refund| tea| coffee } vendingMachine = loop{ coin; select{ refund| tea| coffee }}
According to the failures in CSP and our former research 5 , communications between customer and vendingMachine in the implementation are modeled and analyzed as follows: Alphabet(CustomerVendingMachine) ={coin, tea, refund, coffee} Failures(CustomerVendingMachine) ={(, X) | X ⊆ {refund, tea, coffee}}, {(coin, X) | X ⊆ {coin}}, {(coin,refund, X) | X ⊆ {coin, refund, tea, coffee}}, {(coin,tea, X) | X ⊆ {coin, refund, tea, coffee}}, {(coin,coffee, X) | X ⊆ {coin, refund, tea, coffee}}}
4.4. Categorizing Failures of Communications in the Design and the Implementation Based on the Definition 4.1, categories for communications in the design (design) and the implementation (Implementation) are constructed (See Fig. 2). Definition 4.1. Category of Failures: Each object is of the form (alphabet, failures) to indicate a process. A Morphism A → B means process A evolves to process B, where alphabeta = alphabetb , and failuresa ⊆ failuresb . 4.5. Verifying the Implementation Against the Design In the implementation, not only can the custom order tea or coffee, but the vending machine can refund the coin. According to research 5 , the construction of a functor in proposition 1 can be used to check whether the approach of ordering tea or coffee in Implementation conforms to the approach of ordering tea or coffee in design (See Fig. 2). Proposition 1. design → implementation is a functor. This functor maps objects and morphisms in design to the corresponding objects and morphisms in implementation as follows:(1). For each object, ocd, in design, there must be a corresponding object, oci, in implementation, such that ocd can be mapped to oci when each trace in ocd have the same trace in oci, and the corresponding refusal in ocd is a subset of the corresponding refusal in oci. (2). For each morphism md : ocd1 → ocd2 in design, there must be a corresponding morphism mi : oci1 → oci2 in implementation, such that md can be mapped to mi when ocd1 and ocd2 can be mapped to oci1 and oci2 respectively.
703
704
Ming Zhu et al. / Procedia Computer Science 83 (2016) 700 – 704
Fig. 2. The functor and categories
5. Conclusion and Future Work As the continuation of our former research 4,5 , this paper exploits failures of communications to formally verify consistency of process communications between design and implementation of concurrent systems. To illustrate those research activities, a concurrent system is created. In doing so, the design of the system is modeled and analyzed by failures; the implementation of the system is developed in Erasmus; the failures of the implementation are analyzed based on abstraction; categories of failures from the design and implementation are created; and by constructing functors, the consistency of process communications between the design and the implementation is verified. Some activities towards the categorical verification are specified in this paper. As a future work, an in depth explanation with details and proofs will be carried out . References 1. P. Welch. Life of occam-pi. In Communicating Process Architectures 2013. Open Channel Publishing Ltd., 2013. 2. J.R. Kiniry and F. Fairmichael. Ensuring consistency between designs, documentation,formal specifications, and implementations. In Proceedings of 12th International Symposium on Component-Based Software Engineering, pages 242–261, 2009. 3. P. Godefroid. Partial-order methods for the verification of concurrent systems: an approach to the state-explosion problem. Springer, Secaucus, United States, 1996. 4. M. Zhu, P. Grogono, O. Ormandjieva, and P. Kamthan. Using category theory and data flow analysis for modeling and verifying properties of communications in the process-oriented language erasmus. In Proceedings of the Seventh C* Conference on Computer Science and Software Engineering, pages 24:1–24:4, 2014. 5. M. Zhu, P. Grogono, and O. Ormandjieva. Using category theory to verify implementation against design in concurrent systems. In The 6th International Conference on Ambient Systems, Networks and Technologies, pages 530–537, 2015. 6. C.A.R. Hoare. Communicating sequential processes. Prentice-Hall, Englewood Cliffs, United States, 1985. 7. A.W. Roscoe. Understanding concurrent systems. Springer, London, United Kingdom, 2010. 8. P. Grogono and B. Shearing. Concurrent software engineering: Preparing for paradigm shift. In Proceedings of the First C* Conference on Computer Science and Software Engineering, pages 99–108, 2008. 9. A.T. Sampson. Process-oriented patterns for concurrent software engineering. PhD thesis, University of Kent, Kent, United Kingdom, 2008. 10. P. Grogono and N. Jafroodi. A fair protocol for non-deterministic message passing. In Proceedings of the Third C* Conference on Computer Science and Software Engineering, C3S2E ’10, pages 53–58, 2010. 11. M. Zakeryfar and P. Grogono. Static analysis of concurrent programs by adapted vector clock. In Proceedings of the Sixth International C* Conference on Computer Science and Software Engineering, pages 58–66, 2013. 12. M. Barr and C. Wells. Category theory for computing science. Prentice-Hall, Upper Saddle River,United States, 2012. 13. J.L. Fiadeiro. Categories for software engineering. Springer Berlin Heidelberg, Germany, 2005. 14. S. Awodey. Category theory. The Clarendon Press Oxford University Press, New York, 2006. 15. C.A.R. Hoare. Notes on an approach to category theory for computer scientists. Constructive Methods in Computing Science, 55:245–305, 1989. 16. G. Winskel and M. Nielsen. Models for concurrency. In Handbook of Logic in Computer Science, volume 4, pages 1–148. Oxford University Press, Oxford, United Kingdom, 1995.