Process algebra has been developed to model concurrent systems by describing algebras of communicating processes [8] . CSP is a process algebra that formally models concurrent systems by events [9] [10] , which might alleviate the problem of state-space explosion caused by modeling states [11] . CSP has been widely used to specify, design and implement concurrent systems [12] . In CSP, a process is defined as (alphabet, failures, divergences) [9] [10] :

・ alphabet: A set of all events a process may engage in,

・ failures: A failure (s, X) means, after engaged in a trace of events s, if any event from the set of events X occurs, the process would stop,

・ divergences: A divergence (s, D) denotes, after engaged in a trace of events s, if any event from the set of events D occurs, the process would become chaos.

Processes can be assembled together as a system, where they can interact with each other through channels. Such interactions are called communications, which are synchronized. If one process needs to communicate to another process, a channel is required between them to receive the input of messages and pass the output of messages. To describe the semantics of CSP, several rules are defined for calculating failures and divergences of a single process (P), a sequences of processes (P; Q), determinism (P □ Q), nondeterminism (P Π Q) and communications (P || Q) [9] [10] , where P and Q are processes.

Process-oriented programming is predicted to be the next programming paradigm [1] [13] [14] . The basis of process-oriented programming is process algebra [2] . Erasmus is one of process-oriented programming languages, which is based on the idea of CSP but with some differences [13] [15] [16] . 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, usually 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 ports of the type of this protocol. A channel, which is of a type of protocol, must be built between two ports for two processes to communicate. Erasmus also offers operations for deterministic choices and nondeterministic choices by using keywords select and case respectively.

In Erasmus, communication is as important as method invocation in object-oriented languages. The requirements of communications between two processes p₁ and p₂ are:

・ p₁ must have a port, π₁, which is of protocol t₁,

・ p₂ must have a port, π₂, which is of protocol t₂,

・ Each protocol may contain several different types of requests, which specifies the types of requests the port can send or receive,

・ There exists a channel, x, which is defined with either protocol t₁ or t₂. A channel has two ends, one is channel in for receiving incoming request and the other is channel out for sending outgoing request,

・ Requests are sent by a process through its client port (declared with “−”), then received at channel in of a channel and sent out by channel out of the channel, and finally received by the other process at the server port (declared with “+”),

・ Given a client port π₁ of protocol t₁ and a server port π₂ of protocol t₂, if π₁ and π₂ can communicate, t₂ must satisfy t₁. Here, t₂ satisfies t₁ is defined as that the set of types of requests of t₁ must be a subset of the set of types of requests of t₂.

Some research is proposed to study communications in Erasmus, which includes constructing a fair protocol that allows arbitrary, nondeterministic communication between processes [17] , describing an alternative construct that allows a process to nondeterministcally choose between possible communications on several channels [18] , and building a static analyzer to detect communication errors between processes [19] . In this paper, we are exploring an approach to verify consistency of communications between design and implementation of concurrent systems developed by Erasmus.

Abstraction interpretation is a method for gathering information about the behavior of the program from abstract semantics of the program instead of concrete semantics of the program [20] . It uses Galois connections to build relationships between concrete and abstract semantics with providing sound answers to questions about the behaviors of the programs [21] . Specifically, Galois connection is a relation between two partially ordered sets in order theory [20] . Given 〈C, ⊑〉 and 〈A, ≼〉 are two partially ordered sets, and two monotone functions α: C → A and γ: A → C. Then (α; γ) is a Galois connection of C and A if and only if for all x ∊ A and y ∊ C, α(x) ⊑ y º x ≼ γ(y).

As concurrent systems usually have a large number of different behaviors, directly analyzing such systems might be difficult [22] . Using Galois connection in abstraction interpretation, the concurrent systems could be simplified as abstract models with retaining some of the properties of the systems [22] . For concurrent systems developed by Erasmus, Galois connection is exploited to build abstract semantics of systems in terms of event order vector [19] [22] . In our research, Galois connection is used to construct abstract implementation.

Due to its abstractness and generality, category theory has led to its use as a conceptual framework in many areas of computer science [23] and software engineering [24] . It is suggested that category theory can be helpful towards discovering and verifying connections in different areas, while preserving structures in those areas [25] . In software engineering, category theory is proposed as an approach to formalizing refinement from design to implementation that are at different level of abstraction [24] [26] . Specifically, for modeling concurrency, category theory is used to model, analyze, and compare Transition System, Trace Language, Event Structure, Petri nets, and other classical models of concurrency [27] [28] [29] . Besides, category theory is applied to study relationships between geometrical models for concurrency and classical models [30] . Furthermore, a categorical framework RASF has been built to formally model and verify specification, design and implementation of Reactive Autonomic System (RAS) [31] . As there is no such kind of framework for process-oriented design and implementation, we propose the categorical framework that is inspired from the concept of RASF. To understand this paper, some of the categorical constructs are listed below:

・ A category consists of objects and morphisms. A morphism f: A → B has object A as its domain and object B as its codomain, respectively. If there are morphisms f: A → B and g: B → C, then there is also a morphism g ◦ f: A → C called their composition. Composition is associative: (h ◦ g) ◦ f = h ◦ (g ◦ f). Every object X has an identity morphism Id_X. For every morphism f: A → B, Id_B ◦ f = f = f ◦ Id_A.

・ A functor F: C → D maps each object of category C onto a corresponding object of category D, and maps each morphism of category C onto a corresponding morphism of category D, with preserving structure and composition.

In CSP, a process can be represented as (alphabet, failures, divergences), along with several rules for calculating failures and divergences [9] [10] . In our research, processes are assumed not to become chaos, so neither divergences nor chaos is discussed. A process in design is described as (alphabet, failures). Processes can communicate with each other in parallel operation ||. To generate and analyze failures, the following rules are used for our research based on CSP.

1) Let P be a process, and let a be an event occurring before P. There is a → P with the failures FLS(a → P) = {(〈〉, X)|a Ï X} ∪ {(〈a〉^⌒s, Y)|(s, Y) ∊ FLS(P)}. It means that if event a doesn’t occur first, any other event in the set of events X would cause a → P stops; if event a occurs first, and then the failures FLS(a → P) depend on FLS(P) = {(s, Y)}. Function FLS() calculates the failures of a processes. This rule is as same as the corresponding rule in CSP [9] . FLS() represent the set of failures of a process.

2) Let P and Q be two processes, and let P execute before Q. There is P; Q with the failures FLS(P; Q) = {(s, X)|(s, X) ∊ FLS(P)} ∪ {(ss^⌒t, Y)|ss ∊ STRCS(P) ⋀ (t, Y) ∊ FLS(Q)}. This rule is derived from FLS(a → P). It means that the failures FLS(P; Q) become FLS(P) first, as P executes before Q; after P accomplishing its execution with trace ss successfully, the failures FLS(P; Q) depend on FLS(Q). STRCS(P) represents a set of all the longest traces of events the process P engaged in when it finished execution successfully.

3) Let P be a process iterating n times in a loop, and let P_i represent P in the ith iteration. There is P¹; …; Pⁿ with the failures FLS(P¹; …; Pⁿ) = {(s, X) | (s, X) ∊ FLS(P)} ∪ {(s^1⌒s, X)|s¹ ∊ STRCS(P) ⋀ (s, X) ∊ FLS(P)} ∪ … ∪ {(s^1⌒s^2⌒…^⌒s^n−1⌒s, X)|sⁱ ∊ STRCS(P) 〈〉 1 ≤ i ≤ n − 1 ⋀ (s, X) ∊ FLS(P)}. This rule is derived from FLS(P; Q). It means that if P iterates once, the failures FLS(P¹; …; Pⁿ) become FLS(P); if P iterates twice, P accomplishes its execution in the first iteration successfully with trace s¹, and then the failures FLS(P¹; …; Pⁿ) depends on the failures FLS(P) in the second iteration; if P iterates n times, and P accomplishes its execution from 1st iteration to (n − 1)th iteration successfully with trace s^1⌒s^2⌒…^⌒sⁿ⁻¹, and then the failures FLS(P¹; …; Pⁿ) depend on the failures FLS(P) in the nth iteration.

4) Let P and Q be two processes executing nondeterministically. There is P Π Q with the failures FLS(P Π Q) = FLS(P) ∪ FLS(Q). Due to the nondeterminism, even though the event offered by environment satisfies P or Q, P or Q still may not execute. Thus, FLS(P Π Q) depends on either FLS(P) or FLS(Q), which is as same as the corresponding rule in CSP [9] .

5) Let P and Q be two processes executing deterministically. There is P □ Q with the failures FLS(P □ Q) = {(s, X)|(s = 〈〉 ⋀ (s, X) ∊ FLS(P) ∩ FLS(Q)) ⋁ (s ≠ 〈〉 ⋀ (s, X) ∊ FLS(P) ∪ FLS(Q))}. When both processes P and Q wait for the occurrence of the first event, FLS(P □ Q) would become the failures of both P and Q, FLS(P) ∩ FLS(Q), due to the determinism. When the trace s occurs, it indicates either P or Q executes, so FLS(P □ Q) would become FLS(P) ∪ FLS(Q)). This rule differs from CSP, because we are not using divergences [9] .

6) Let P and Q be two processes communicating with each other. There is P || Q with the failures FLS(P || Q) = {(s, X ∪ Y)|((s, X) ∊ FLS(P) ⋁ (s, Y) ∊ FLS(Q)) ⋀ (s ∊ TRCS(P) ⋀ s ∊ TRCS(Q))}. In this research, two process can communicate only when the same event occurs simultaneously in both processes. If there is a failure of P || Q, the failure would be from either FLS(P) or FLS(Q) with the occurrence of trace s in both processes P and Q. TRCS() is the set of all traces which a process may engage in.

For the example, vending machine and person can be modeled as processes vendingMachine and person respectively. Both processes communicate two messages: one is coin, the other is coke or pepsi. From the perspective of person, the choice of person can be modeled as a nondeterministic choice, as it depends on person only. However, from the perspective of vendingMachine, offering the kind of drink can be modeled as a deterministic choice, since the kind of drink offered depends on both person and vendingMachine. Process vendingMachine can run iteratively to offer drinks. As specified in the textual description of the example, process vendingMachine can offer coke or pepsi repeatedly, while process person can order coke or pepsi only once.

In the design of the example, let APHB() represent the alphabet of a process, let ps and vm denote process person and process vendingMachine respectively, let X indicate the successful termination of a process, let svm describe process vendingMachine executes only once, let svmⁱ represent the process vendingMachine in the ith iteration of a loop, and let communications between processes vendingMachine and person be modeled as pskvm. By applying rules in Section 5.1, processes and communications of the example in the design are modeled and analyzed as follows.

ps =coin→ (coke →PΠ pepsi →P)

APHB(ps) ={coin,coke,pepsi}

FLS(ps) ={(〈〉,X) | X⊆ {coke,pepsi}},{(〈coin〉,X) | X⊆ {coin,coke,pepsi}}}

svm =coin→(coke→P□ pepsi →P)

vm =svm¹;svm²;...;svmⁿ⁻¹;svmⁿ

APHB(vm) =APHB(svm) = {coin,coke,pepsi}

FLS(svm) ={{(〈〉,X) | X⊆ {coke,pepsi}},{(〈coin〉,X) | X⊆ {coin}}}

STRCS(svm) ={〈coin,coke〉,〈coin,pepsi〉}

FLS(vm) =FLS(svm¹;...;svmⁿ)

={(s,X) | (s,X) ∊ FLS(svm)}∪{(s^1⌒s,X) | s¹∊ {〈coin,coke〉,〈coin,pepsi〉}

⋀ (s,X) ∊ FLS(svm)}

∪・・・∪ {(s1^⌒...^⌒s^n−1⌒s,X) | sⁱ∊ {〈coin,coke〉,〈coin,pepsi〉}

⋀1 ≤i≤n − 1 ⋀ (s,X) ∊ FLS(svm)}

APHB(pskvm) = {coin,coke,pepsi}

FLS(pskvm) ={{(〈〉,X∪Y )|X⊆ {coke,pepsi} ⋁Y⊆ {coke,pepsi}},

{(〈coin〉,X∪Y )|X⊆ {coin,coke,pepsi} ⋁Y⊆ {coin}},

{(〈coin,coke〉,X∪Y )|X⊆ {} ⋁Y⊆ {coke,pepsi}},

{(〈coin,pepsi〉,X∪Y )|X⊆ {} ⋁Y⊆ {coke,pepsi}}}

As we are interested only in communications between processes, code not related to the communications is necessarily to be ruled out, and code relevant to the communications needs to be retained. In this paper, Galois Connection is used for abstraction.

Implementation is considered as concrete domain, and abstraction of implementation is deemed as abstract domain. There are partial-order relationships, “execute before or simultaneously”, between statements in concrete domain and between statements in abstract domain respectively. There are two partial-order sets 〈ConcreteStatements, ⊑〉 and 〈Ab-stractStatements, ≼〉, where ⊑ and ≼ represent the “execute before or simultaneously” relationship between statements in concrete domain and abstract domain respectively.

According to Galois Connection, after abstracting implementation, relationships between statements in abstract domain must be able to be mapped to corresponding relationships between statements in concrete domain, and vice versa. Thus, there are two monotone mappings, namely α: ConcreteStatements → AbstractStatements, and γ: AbstractStatements → ConcreteStatements. α and γ mappings involve communication-related statements only. There are 1). for any x, y ∊ ConcreteStatements, if x ⊑ y, then α(x) ≼ α(y); 2). for any a, b ∊ AbstractStatements, if a ≼ b, then γ(a) ⊑ γ(b), and; 3). for all x ∊ ConcreteStatements and b ∊ AbstractStatements, a(x) ≼ b º a ⊑ γ(b).

The details of mapping rules for α and γ are specified in Table 1 and Table 2 respectively.

In Table 1 and Table 2, C represents statements related to communications; C₁; C₂ means C₁ executes before C₂; |a_i| C_i (1 ≤ i ≤ n) in select indicates that if condition a_i is true, then C_i will execute (sometimes, condition a_i is not necessarily provided. If C_i is satisfied in the choice, it will be executed); || is the delimiter between choices in select or case in concrete statements, while | is the delimiter between choices in select or case in abstract statements.

By following the mapping rules of abstraction, the implementation of the vending machine example is abstracted as follows.

person =//process person

makeOrder.coin;//insert a coin

case{//nondeterministic choices

makeOrder.coke

|makeOrder.pepsi

|makeOrder.tea

}

vendingMachine =//process vendingMachine

loop{//run into a loop

getOrder.coin;//get a coin

select{//deterministic choices

getOrder.coke

|getOrder.pepsi

|makeOrder.tea

}

}

In this example, implementation is considered as concrete domain, and abstraction is considered as abstract domain. The relationships “execute before or simultaneously” between statements in abstraction are maintained in implementation, and vice versa. The details of mappings for the example are shown in Figure 4.

Erasmus is used to implement concurrent systems in this research. Processes and communications in design can be implemented by processes, ports, channels and communications in Erasmus. A process in Erasmus usually has one or

more ports for communications, which differs from the process in CSP. A set of all messages a port can send or receive is considered as the alphabet_port. A set of messages of all ports of a process is deemed as the alphabet_process = {alphabet_port1 ∪∙∙∙ ∪ alphabet_portn}. To model implementation, a process is represented as {(alphabet_port1, failures_port1), …, (alphabet_portn, failures_portn)}, and a port can be modeled as (alphabet_port, failures_port). Semantics of failures in Erasmus are similar to those of CSP, while the process in CSP is replaced by port in Erasmus. A failure (s, X) in Erasmus means, after engaged in a trace of events s, if any event from the set of events X occurs, the port would stop.

To model and analyze the abstraction of implementation, let FLS() stand for generating a set of failures from an Erasmus statement, let APHB() represent the alphabet of a port, let C be an Erasmus statement related to communications, let STRCS() represent all the longest traces of events the statement engaged in when it finished execution successfully, and let traces() denote a set of traces of events the statement may produce. A statement C may be a simple statement or compound statement (see rules below). Based on the rules in section 5.1 and Erasmus, the rules for generating and analyzing failures in abstraction of implementation are defined as follows.

1) Let P be a process, let p be a port of P, and let m be the first message that will be sent/received through prot p. The message can be represented P.p.m. P.p.m is a simple statement. If port p is unique in the system, P.p.m can be abbreviated as p.m. The failures of port p of process P for sending/receiving message m are FLS(P.p.m) = {(〈〉, X)|X ⊆ (APHB(p) − m)}. It means any event occurs on port p other than message m, p stops working.

2) Let C₁ and C₂ be two statements, and let C₁ execute before C₂. There is C₁; C₂, which is a compound statement with the failures FLS(C₁; C₂) = {(s, X)|(s, X) ∊ FLS(C₁)} ∪ {(ss^⌒t, Y)|ss ∊ STRCS(C₁) ⋀ (t, Y) ∊ FLS(C₂)}. It means that the failures FLS(C₁; C₂) become FLS(C₁) first, as C₁ executes before C₂. after C₁ accomplishing its execution with trace ss successfully, the failures FLS(C₁; C₂) depend on FLS(C₂).

3) Let C be a statement iterating n times in a loop, and let Cⁱ represent the ith iteration of a loop of C. There is loop{C} = {C¹; C²; ∙∙∙; Cⁿ⁻¹; Cⁿ}, which is a compound statement with the failures FLS(loop{C}) = {(s, X)|(s, X) ∊ FLS(C)} ∪ {(s^1⌒s, X)|s¹ ∊ STRCS(C) ⋀ (s, X) ∊ FLS(C)} ∪ ∙∙∙ ∪ {(s^1⌒s^2⌒∙∙∙^⌒s^n−1⌒sⁿ, X)|sⁱ ∊ STRCS(C) ⋀ 1 ≤ i ≤ n − 1 ⋀ (s, X) ∊ (FLS(C))}. It means that if C iterates once, the failures FLS(loop{C}) become FLS(C); if C iterates twice, and if the execution of the first iteration is accomplished successfully with trace s¹, the failures FLS(loop{C}) depends on the failures FLS(C) in the second iteration; if C iterates n times, and if the execution from 1st iteration to (n − 1)th iteration successfully with trace s1^⌒s2^⌒∙∙∙^⌒sⁿ⁻¹, the failures FLS(loop{C}) depend on the failures FLS(C) in the nth iteration.

4) Let C_i be a statement where 1 ≤ i ≤ n, and let case represent nondeterministic choices. There is case {C₁|…|C_n}, which is a compound statement with the failures FLS(case{C₁|…|C_n}) = {(s, X)|(s, X) ∊ FLS(C₁) ∪ … ∪ FLS(C_n)}. This rule is derived from the rule 4) in section 5.1 and Erasmus. It means that FLS(case{C₁|…|C_n}) depends on one of FLS(C_i) where 1 ≤ i ≤ n.

5) Let C_i be a statement where 1≤ i ≤ n, and let select represent deterministic choices. There is select{C₁|…|C_n}, which is a compound statement with the failures FLS (select{C₁|…|C_n}) = {(s, X)|(s = 〈〉 ⋀ (s, X) ∊ FLS(C₁) ∩ … ∩ FLS(C_n)) ⋁ (s ≠ 〈〉 ⋀ (s, X) ∊ FLS(C₁) ∪ … ∪ FLS(C_n))}. This rule is derived from the rule 5) in section 5.1 and Erasmus. It means that if statements C_i wait for the occurrence of the first message, FLS(select{C₁|∙∙∙|C_n}) would become FLS(C₁) ∩ … ∩ FLS(C_n). When the trace s occurs, it indicates one of C_i executes, so FLS(select{C₁|∙∙∙|C_n}) would become FLS(C₁) ∪ … ∪ FLS(C_n).

6) Let C₁ be a statement from a process, let C₂ be a statement from another process, and let C₁ and C₂ be able to communicate with each other. There is C₁ || C₂, which is a compound statement with the failures FLS(C₁ || C₂) = {(s, X ∪Y)|((s, X) ∊ FLS(C₁) ⋁ (s, Y) ∊ FLS(C₂)) ⋀ (s ∊ TRCS(C₁) ⋀ s ∊ TRCS(C₂))}. InErasmus, two ports can communicate only when the same message is sent by a port and received by anotherport simultaneously. If there is a failure of C₁||C₂, the failure would be from either FLS(C₁) or FLS(C₂) with the occurrence of trace s in both C₁ and C₂. TRCS() is the set of all traces that a process may engage in.

In the implementation of the example, process person has only one port makeOrder, and process vendingMachine has only one port getOrder. Thus, person can be represented as {(APHB(makeOrder), FLS(makeOrder))}, and vendingMachine can be represented as {(APHB(getOrder), FLS(getOrder))}. Let GetPort describe port getPort executes only once, let GetPortⁱ represent port getPort in the ith iteration of a loop, and let communications between processes person and vendingMachine be modeled as makeOrder||getOrder. By following the rules for generating and analyzing failures in Section 7.3, the abstraction of implementation of the example can be modeled and analyzed as follows.

makeOrder = makeOrder.coin;

case{makeOrder.coke | makeOrder.pepsi | makeOrder.tea}

APHB(makeOrder) ={coin,coke,pepsi,tea}

FLS(makeOrder) ={(〈〉,X) | X⊆ {coke,pepsi,tea}},

{(〈coin〉,X) | X⊆ {coin,coke,pepsi,tea}}}

getOrder = loop{getOrder.coin;select{getOrder.coke | getOrder.pepsi | getOrder.tea}}

GetOrder = getOrder.coin;select{getOrder.coke | getOrder.pepsi | getOrder.tea}}

APHB(getOrder) = APHB(GetOrder) = {coin,coke,pepsi,tea}

FLS(GetOrder) ={{(〈〉,X) | X⊆ {coke,pepsi,tea}},{(〈coin〉,X) | X⊆ {coin}}}

STRCS(GetOrder) ={〈coin,coke〉,〈coin,pepsi〉,〈coin,tea〉}

FLS(getOrder) =FLS(loop{GetOrder})

=FLS(GetOrder¹;...;GetOrderⁿ)

={(s,X) | (s,X) ∊ FLS(GetOrder)}

∪{(s^1⌒s,X) | s¹∊{〈coin,coke〉,〈coin,pepsi〉,〈coin,tea〉}

⋀(s,X) ∊ FLS(GetOrder}

∪…∪{(s^1⌒...^⌒s^n−1⌒s,X) | sⁱ∊ {〈coin,coke〉,〈coin,peps〉,〈coin,tea〉}

⋀1 ≤i≤n−1 ⋀ (s,X) ∊ FLS(GetOrder)}

APHB(makeOrderkgetOrder) = {coin,coke,pepsi,tea}

FLS(makeOrderkgetOrder) =

{{(〈〉,X∪Y )|X⊆ {coke,pepsi,tea} ⋁Y⊆ {coke,pepsi,tea}},

{(〈coin〉,X∪Y )|X ⊆{coin,coke,pepsi,tea} ⋁Y⊆ {coin}},

{(〈coin,coke〉,X∪Y )|X ⊆ {} ⋁Y⊆ {coke,pepsi,tea}},

{(〈coin,pepsi〉,X∪Y )|X ⊆ {} ⋁Y⊆ {coke,pepsi,tea}},

{(〈coin,tea〉,X∪Y )|X ⊆ {} ⋁Y⊆ {coke,pepsi,tea}}}

In the design, communications are modeled as processes using operator ||, and a process is modeled as (alphabet, failures). As failures contain traces that can indicate the progress of the process, in this paper, failures are modeled as categories.

Definition 1. Category of Failures: Each object is a set that has subsets of failures of a process as elements. A Morphism A → ⊆ B represents A is a subset of B, which indicates the progress of the process.

By following the Definition 1, failures of processes in the example can be categorized. As communications are of our interests and communication can be modeled as processes, in this paper, communications between both processes person and vendingMachine are modeled as a category in terms of failures.

Proposition 1. CCD is a category modeling design (see Figure 5). Each object is a set that has subsets of failures of communications between processes person and vendingMachine as elements. The morphism between two objects is the ⊆ relationship, which represents the progress of communications. For example, {{(〈〉, X ∪ Y )|X ⊆ {coke, pepsi} ⋁ Y ⊆ {coke, pepsi}}} is an object, {{(〈〉, X ∪Y )|X ⊆ {coke, pepsi} ⋁ Y ⊆ {coke, pepsi}}, {(〈coin〉, X ∪ Y)|X ⊆ {coin, coke, pepsi} ⋁ Y ⊆ {coin}}} is another object, and there is morphism ⊆ between them to indicate the progress of communications from no event to event coin.