A Polyadic pi-Calculus Approach for the Formal Specification of UML-RT

Abstract

UML-RT is a UML real-time profile that allows modeling event-driven and distributed systems; however it is not a formal specification language. This paper proposes a formal approach for UML-RT through a mapping of the UML-RT communicating elements into the 𝜋-calculus (or pi-calculus) process algebra. The formal approach both captures the intended behavior of the system being modeled and provides a rigorous and nonambiguous system description. Our proposal differentiates from other research work because we map UML-RT to 𝜋-calculus, and we allow the mapping of dynamic reconfiguration of UML-RT unwired ports. We illustrate the usage and applicability of the mapping through three examples. The first example focuses on explaining the mapping; the second one aims to demonstrate the use of the 𝜋-calculus definitions to verify system requirements; the third case is an example of mobile processes called Handover protocol.

1. Introduction

The specification and development of real-time systems are a challenge due to their characteristic of criticality and safety. Formal methods have been seen as effective in real-time system development [1, 2]. The main advantage of formal methods is to allow a rigorous and nonambiguous system description; so it is possible, through formal verification, to evaluate some aspects such as consistency, completeness, and correctness. The formal verification involves the formal modeling of the system, the formal specification of requirements or properties, and the inference rules to prove that the model satisfies the properties (model checking) [3–5].

The standard DO-178B, Software Considerations in Airborne Systems and Equipment Certification [6], is an acceptable guideline for embedded software approval used by the certification authorities. It suggests the use of formal methods to complement tests, because they generally increase confidence on correct behavior or that anomalous behavior will not occur. Furthermore, formal verification of models helps the designers to find out errors earlier in the modeling phase, which is essential to reduce costs according to Pressman [7].

The most well-known modeling language is Unified Modeling Language (UML), officially defined by the Object Management Group (OMG). Up to the UML version 1.5 [8], the standard lacks support for some important aspects of embedded real-time systems, such as time constraints, signals, and independent components. Aiming to adapt UML to real-time system modeling, some UML profiles were proposed [9, 10]. For instance, Rational Software Company (now IBM) defined the UML RealTime (UML-RT) [11] profile that permits to model distributed and event-driven systems. The profile is supported by the IBM Rational Rose RealTime (RoseRT) tool [12].

With the advance of UML 2.0 [13], UML was improved to model large-scale software systems including the ability to model entire system architectures. The basis of the improvement comes from the experience with various architectural description languages, such as UML-RT [14]. RoseRT is now commercialized as IBM Rational Rose Technical Developer tool [15]; however the features of UML-RT are still present, because they are the source of UML 2.0 structure concepts, for example, the capsule is directly translated to structured classes in UML 2.0.

As UML-RT is not a formal specification language; it is not possible to formally verify the models that are specified in UML-RT. So some researchers propose the transformation of the UML-RT model to a formal model using process algebras [16–19]. The process algebras to which transformation are proposed include CSP [20], CCS [21], and Circus [22]. Other work [23] represents the UML-RT model as timed automata.

In the present paper, we propose a formal approach to the UML-RT through a mapping of the UML-RT communicating elements into the 𝜋-calculus [24]. The 𝜋-calculus is a process algebra for systems that communicate concurrently. Its advantage is the ability to model mobility, which is made by passing channels as data through channels. The 𝜋-calculus does not address the computations that are not related to communication with other processes.

This work is an extension of our earlier work on mapping from UML-RT to 𝜋-calculus [25]. In that work, Bezerra et al. present the mapping to a 𝜋-calculus syntax version used by HAL-JACK (HD-Automata Laboratory) [26], which is an integrated tool set for the specification, verification, and analysis of concurrent and distributed systems. In this paper, we present the complete mapping using the polyadic 𝜋-calculus. The chosen syntax is the one proposed by Milner [24] and not the other one used by HAL-JACK (HD-Automata Laboratory) [26] tool, which is monoadic. The importance of polyadic is the ability to formally represent the communication of more than one message at a time. Besides, we include mapping rules to reason about the following UML-RT concepts: the entry and the exit actions, the composite states, and the transition chains.

The rest of the paper is organized as follows. In Section 2, we provide an overview of UML-RT and 𝜋-calculus, and we also describe the related work. We present the UML-RT to the 𝜋-calculus mapping in Section 3, and we illustrate the mapping with three examples in Section 4. The first example is used to explain how to apply the mapping to a UML-RT model and obtain the corresponding 𝜋-calculus definitions. The second example is employed to demonstrate that the designer is able to use the 𝜋-calculus definitions to verify if the model meets the system requirements. The third example is the Handover protocol presented in [24], and it illustrates the use of polyadic communication. Finally, in Section 5 some conclusions are drawn.

2. Theoretical Foundations

This section starts with the description of the main elements of UML-RT, which are considered in the mapping of 𝜋-calculus whose description is presented in what follows. We end the section by discussing the related work.

2.1. UML-RT

UML-RT is an extension of UML with elements to facilitate the design of real-time systems. Three of the elements, capsule, port, and connector, are used to model system structure; one element, protocol, models the communication inside the system [11].

A capsule is an active class and represents software components that can be concurrent and physically distributed. A capsule has a state diagram and a structure diagram. A state diagram is similar to a UML standard state diagram and describes the capsule behavior. A structure diagram details the internal structure of a capsule, which includes subcapsules and their connections with each other. Figure 1 shows the structure diagram of the capsule TopSystem that comprises four subcapsules: source (instance of the capsule Source), router (instance of the capsule Router), target1 (instance of the capsule ConsumerTarget), and target2 (instance of the capsule ExporterTarget). The model was constructed using the RoseRT tool.

Figure 1 

The structure diagram of the capsule TopSystem.

A port permits to exchange messages between capsules. A protocol needs to be specified for a port. A protocol defines both the number of participants in the communication and the signals that are received and sent by each participant. The connectors act as communicating channels between ports that must play different roles of the same protocol. A line between two ports represents a connector. In Figure 1, the ports q and r implement the protocol named ConfigProtocol, and they are connected to each other. The ports play conjugated roles, which can be noted in their representations: q as an empty (blank) square and r as a filled (black) square.

A port can be classified in terms of visibility (public and protected), termination (end and relay), and connectivity (wired and unwired). A public port is located at the capsule border and can interact with other capsule ports. A protected port is not visible from the outside; it serves as the communication point of the capsule with its subcapsules. In Figure 1, the capsule System has the public port out (indicated by the symbol +), and the protected ports setCT and setET (indicated by the symbol #).

With respect to the termination, an end port provides the access to the capsule behavior given by its state diagram. In Figure 1, setCT and setET are end ports of the capsule TopSystem. A relay port is used to export the subcapsule interfaces. When a relay port of a parent capsule receives a message, the message is passed automatically to the connected subcapsule port. And when a subcapsule sends a message through a port connected to a relay port of its parent capsule, the message is directly sent to the outside of the parent capsule. By definition, a relay port is public and wired. In Figure 1, out is a relay port of the capsule TopSystem.

A wired port (e.g., q and r in Figure 1) has a connector joining them to exchange messages. An unwired port does not have a connector with other ports, but it allows dynamic communication during runtime through its name registration. In Figure 1, alert, s, and t are examples of unwired ports. Unwired ports can be registered to receive and send signals. For instance, the port s can be registered with the subscriber name x, and t can be registered with the subscriber name y. In this case, if the port alert is configured with the provider name x, the signal sent by Router along alert is received by ConsumerTarget. Similarly, if the port alert is set to y, its signal is received by ExporterTarget. In RoseRT, the subscriber port is called Service Access Point (SAP) and the provider port is called Service Provisioning Point (SPP).

As mentioned, a capsule has also a state diagram. Figure 2 presents the state diagram of the ExporterTarget capsule. The initial point (filled circle) is a point which explicitly shows the beginning of the state machine. The initial transition, named Initial, connects the initial point to the initial state. It does not have an associated trigger; however it may execute an associated action.

Figure 2 

The state diagram of the capsule ExporterTarget.

Figure 3 

The composite state S2 of ExporterTarger state diagram.

A state is a condition in which the object is ready to process events. In Figure 2, there are states 𝑆1, 𝑆2, and 𝑆3. We can define actions to be performed when the control enters in a state (entry action, indicated by the symbol ) and when it leaves a state (exit action, indicated by the symbol ). A state that does not contain substates is called a simple state. A state that contains substates is called a composite or hierarchical state (indicated by the symbol ). For example, 𝑆1 and 𝑆3 are simple states; whereas 𝑆2 is a composite because it is composed of the simple states 𝑆4 and 𝑆5 as illustrated in Figure 3. Furthermore, a state can be a choice point, for example, 𝑆5, which allows a single transition to be split into two outgoing transition segments, after evaluating a condition on which branch to take. For instance, if the decision evaluation inside 𝑆5 returns true, the transition exportMsg is triggered; otherwise, the transition consumeMsg is triggered.

A transition is a relationship between two states: a source state and a destination state. It specifies the change of control from the source state to the destination state when an object in the source state receives a specified event and some conditions are met. Three concepts related to a transition include: trigger, guard condition, and action. Trigger indicates which events (signals) from which interfaces (ports) cause the transition to be taken; however the transition fires only if the guard condition is satisfied. After the transition activation, its action is executed. Actions are operation calls, a variable handling or a signal dispatch to another capsule.

Transitions can span multiple hierarchies changing context on the way from the source to the destination state. Therefore they must be partitioned into different segments by the junction pointers. Each transition segment has a distinct name. Any segment can execute actions; however only the originating segment has a trigger. For instance, the transition configPort illustrated in Figure 2 connects the states 𝑆1 and 𝑆2, but it comprises two segments inside the state 𝑆2 as shown in Figure 3: the transition configPort itself and the transition Initial1 separated by a junction pointer.

It is important to mention that the triggers and the actions are configured internally in the RoseRT tool, and the model screenshot presents only the state and transition names. Table 1 presents the transition information of the ExporterTarget state diagram, where the action is specified in C programming language. For example, the transition configPort triggers if it receives along the port setPort the signal portName. The transition action is the storage of the message, received through the port setPort, in the local variable aux using the statement “aux = *rtdata;”. Later the port t is renamed to aux, using the statement “t·registerSAP(aux);”. The transition exportMsg does not have a trigger, but it executes an action of sending along the port export the signal msg with the message 𝑑1.

Table 1 

Transitions of the ExporterTarget state diagram.

UML-RT allows defining a class and sending an object of this class as a message. For example, the capsule ExportedTarget receives a message m in the transition receiveMsg with the attributes msg1 and msg2, which are stored, respectively, in 𝑑1 and 𝑑2 variables, according to Table 1. Later, by the transition exportMsg, the capsule ExportedTarget is able to send the message 𝑑1. However, the message m can be seen as two messages 𝑚1 and 𝑚2 transmitted in a single signal, which characterizes the communication of more than one message at a time in UML-RT.

Although, there are other diagrams available in the UML-RT, such as use case, component, deployment, class, collaboration, and sequence diagrams; the proposed mapping rules deal only with the state and structure diagrams of UML-RT capsules.

A use case diagram is specially used before the modeling phase in order to identify the functionality of the system. A component diagram shows the dependencies among software components that exist at compilation time, linking time, or run-time. A deployment diagram captures the physical distribution of the run-time processes across a set of processing nodes. As our scope is focused on design, and not on the requirement or implementation, the use case, component, and deployment diagrams are not addressed.

A class diagram shows the static structure of the model. It may contain other elements besides classes, such as capsules and protocols. A collaboration diagram captures a desirable pattern of interactions between objects, emphasizing the structural organization of the objects. A capsule structure diagram is a specialized form of the collaboration diagram and includes information available also in the class diagram. A sequence diagram specifies communication scenarios of collaboration; however with the capsule structure diagram and the state diagram of each capsule it is possible to obtain all the possible collaborations; therefore the sequence diagram is not used. So our mapping considers only the state and structure diagrams of UML-RT capsules.

2.2. The 𝜋-Calculus

The 𝜋-calculus [24] is a process algebra for systems that communicate concurrently, that is, systems composed of processes that run in parallel and interact through channels. The main difference between 𝜋-calculus and its predecessors, CSP and CCS, is the possibility to pass channels as data through channels [27–29]. This characteristic allows the π-calculus to express mobility.

The prefix 𝜋 of the 𝜋-calculus represents 𝑥⟨𝑦⟩, 𝑥(𝑦), or the unobservable action 𝜏. The term 𝑥⟨𝑦⟩ indicates that the 𝜋-calculus port (or channel) x sends the 𝜋-calculus message y. The term 𝑥(𝑦) indicates that the message y is received along the port x. The round brackets (y) are used for the binding occurrence of a parametric name (one that may be instantiated by another name), and the angle brackets ⟨𝑦⟩ for nonbinding occurrences of a name.

The 𝜋-calculus process expression P is defined by the syntax: 𝑃∶=_𝑖∈𝐼𝜋_𝑖⋅𝑃_𝑖∣𝑃₁∣𝑃₂∣𝑛𝑒𝑤𝑎𝑃∣!𝑃. (1)

The term ∑_𝑖∈𝐼𝜋_𝑖⋅𝑃_𝑖 indicates summation, where I is a finite indexing set. The dot is the sequence operation, which means that 𝜋_𝑖 will occur before P_i becomes activated. If 𝑖=2, we have 𝜋₁⋅𝑃₁+𝜋₂⋅𝑃₂. If 𝑖=0, we have 𝑃=0, that is a stop process. In general, we omit the stop process, for example, we write 𝑥(𝑦) instead of 𝑥(𝑦)⋅0. The parallel composition 𝑃₁∣𝑃₂ means that 𝑃₁ and 𝑃₂ run concurrently. The term new a P represents the restriction of the name a in the P context, that is, the name a is bound in P and it is not seen outside. The replication operator !𝑃 is the composition of unlimited copies of P.

For example, considering the following processes of B, C, D, and E, where 𝐵=(𝑧⟨𝑥⟩+𝑧⟨𝑦⟩),𝐶=𝑧(𝑎)⋅𝑎⟨𝑏⟩,𝐷=𝑥(𝑐),𝐸=𝑦(𝑑). (2)(3)(4)(5)

The process B is able to send the message x along the port z or to send the message y along the port z. The process C can receive a message a through the port z, and later send the message b through the port a. The process D can only receive a message c along the port x. Finally, the process E is able to receive a message d via the port y.

Assuming that the process A (Figure 4(a)) consists of B, C, D, and E above, so by using 𝜋-calculus, the process 𝐴 is the parallel composition of the four processes: 𝐴=𝐵∣𝐶∣𝐷∣𝐸. (6)

(a)

(b)

(c)

Figure 4 

The 𝜋-calculus mobility. (a) A process, (b) 𝐴1 process, and (c) 𝐴2 process.

We can replace in (6) the definition of each process using (2) to (5), so 𝐴=(𝑧⟨𝑥⟩+𝑧⟨𝑦⟩)∣𝑧(𝑎)⋅𝑎⟨𝑏⟩∣𝑥(𝑐)∣𝑦(𝑑). (7)

To understand how to manipulate the definitions included in the process A definition, it is necessary to understand the 𝜋-calculus concepts related to the structural congruence and the reactions.

The processes P and Q in the π-calculus are structurally congruent, written 𝑃≡𝑄, if one can be transformed into the other using the rules.

(i) Change of Bound Names (Alpha-Conversion).
The alpha-conversion allows bound variable names to be renamed. As an example, in (2), we have that 𝐷=𝑥(𝑐). If 𝐷^′=𝑥(𝑐), so 𝐷≡𝐷^′, that is, D is the same as 𝐷^′.

(ii) Reordering Terms in a Summation
The reordering terms in a summation are related to the commutative operations. For instance, in (1), we have that 𝐵=(𝑧⟨𝑥⟩+𝑧⟨𝑦⟩). But we can rewrite B by reordering its terms, so 𝐵=(𝑧⟨𝑦⟩+𝑧⟨𝑥⟩).

(iii) 𝑃∣0≡𝑃,𝑃∣𝑄≡𝑄∣𝑃,𝑃∣(𝑄∣𝑅)≡(𝑃∣𝑄)∣𝑅
The first term indicates that the stop process is the neutral element in the parallel composition. The second and the third terms are the commutative and the associative operation, respectively, of the parallel composition. For example, the definition of A in (6) can also be written by reordering B and C, as 𝐴=𝐶|𝐵|𝐷|𝐸.

(iv) new 𝑥(𝑃∣𝑄)≡𝑃∣ new 𝑥𝑄, If x Is not a Free Name of P
It states that if a process P does not have the free name x, the restriction of x in the parallel composition 𝑃∣𝑄 is kept only in Q.

(v) 𝑛𝑒𝑤𝑥0≡0, and 𝑛𝑒𝑤𝑥,𝑦𝑃≡𝑛𝑒𝑤𝑦,𝑥𝑃
The first term explains that there is no need to use restriction in the stop process. The second term indicates that the order of the names in a restriction operation is not important.

(vi) !𝑃≡𝑃∣!𝑃
It states that the replication of P is the same as a parallel composition of an infinite number of P.

The reaction relation over 𝜋-calculus explains how the processes react with each other. It contains exactly the transitions which can be inferred from the following rules.

(i) TAU [𝜏⋅𝑃+𝑀→𝑃]
It states that in a process 𝜏⋅𝑃+𝑀, if 𝜏 occurs, then we choose the first option of the choice operator and the result is only the P process.

(ii) REACT [(𝑥(𝑦)⋅𝑃+𝑀)∣(𝑥⟨𝑧⟩⋅𝑄+𝑁)→{𝑧/𝑦}𝑃∣𝑄, Where {𝑧/𝑦}𝑃 Means that y Must Be Replaced by 𝑧]
It states that the two processes running concurrently (𝑥(𝑦)⋅𝑃+𝑀) and (𝑥⟨𝑧⟩⋅𝑄+𝑁) may react, because the second process sends the message z along the port x, while the first process receives a message y along the port x. After the reaction, all occurrences of y in the first process are renamed by z.

(iv) PAR [If 𝑃→𝑃^′, Then 𝑃∣𝑄→𝑃^′∣𝑄]
It states that in a parallel composition, if one process transits to another, then the parallel composition is maintained.

(v) RES [If 𝑃→𝑃^′, Then 𝑛𝑒𝑤𝑥𝑃→𝑛𝑒𝑤𝑥𝑃^′]
It states that in a restriction operation, if one process transits to another, then the restriction is maintained.

(vi) STRUCT [𝑃→𝑃^′ Implies 𝑄→𝑄^′, if 𝑃≡𝑄, 𝑃^′≡𝑄^′]
It states that if P transits to 𝑃^′ it implies that Q transits to 𝑄^′, then P and Q are structurally congruent.

In the example of the process A defined in (7), the actions 𝑧⟨𝑥⟩ of B and 𝑧(𝑎) of C are complementary and may interact generating 𝐴1: 𝐴1=0∣𝑥⟨𝑏⟩∣𝑥(𝑐)∣𝑦(𝑑). (8)

After the reaction 𝐴→𝐴1, all occurrences of a in C are replaced by x. Figure 4(b) shows 𝐴1 process, where 𝑈=𝑥⟨𝑏⟩ and B is not represented because it is a stop process.

Additionally, there is another possible interaction in A between 𝑧⟨𝑦⟩ of B and 𝑧(𝑎) of C, generating 𝐴2: 𝐴2=0∣𝑦⟨𝑏⟩∣𝑥(𝑐)∣𝑦(𝑑). (9)

After the reaction 𝐴→𝐴2, all occurrences of a in C are replaced by y. Figure 4(c) depicts 𝐴2 process, where 𝑉=𝑦⟨𝑏⟩ and B is not represented because it is a stop process.

The example illustrates the 𝜋-calculus mobility concept, because the channels x (in the reaction 𝐴→𝐴1) and y (in the reaction 𝐴→𝐴2) are passed as message along the channel z, which links processes B and C. The mobility is the main aspect of the 𝜋-calculus whose representation is addressed in this paper.

The presented 𝜋-calculus version is the monoadic π-calculus, in which a message contains exactly one name. The polyadic π-calculus [24] permits to exchange messages consisting of more than one name, using the prefixes 𝑥(𝑦) and 𝑥⟨𝑧⟩. In particular, it admits the cases 𝑥() and 𝑥⟨⟩ where 𝑦 and 𝑧 are empty, and we can write as x and 𝑥 to indicate only the synchronization between the ports.

For an example of polyadic 𝜋-calculus, consider the following process: 𝐸=𝑥(𝑦₁,𝑦₂)⋅𝐹∣𝑥⟨𝑧₁,𝑧₂⟩⋅𝐺∣𝑥⟨𝑤₁,𝑤₂⟩⋅𝐻. (10)

The first term in (10) may react with the second or the third term along the port x. The reaction with the second term replaces 𝑦₁,𝑦₂ by 𝑧₁,𝑧₂, respectively. While the reaction with the third term replaces 𝑦₁,𝑦₂ by 𝑤₁,𝑤₂, respectively.

The definition of E is different from 𝐸^′ written in monoadic 𝜋-calculus, as follows: 𝐸^′=𝑥(𝑦₁)⋅𝑥(𝑦₂)⋅𝐹∣𝑥⟨𝑧₁⟩⋅𝑥⟨𝑧₂⟩⋅𝐺∣𝑥⟨𝑤₁⟩⋅𝑥⟨𝑤₂⟩𝐻. (11)

In (11), the first term may react with the second and later with the third term, resulting that 𝑦₁ is replaced by 𝑧₁, and 𝑦₂ by 𝑤₂. It is also possible that the first term may react with the third and later with the second term. In both cases, the result of (11) using monoadic 𝜋-calculus is different from that one expected in (10) using polyadic 𝜋-calculus. For the correct encoding of the polyadic using monoadic, it is necessary to guarantee that there can be no interference on the channel along which a composite message is sent. It is addressed by Milner in [24].

A process in monoadic or polyadic 𝜋-calculus can also have a list of input names written between round brackets, for example, 𝐼(𝑚,𝑛)=𝑚⟨𝑛⟩⋅𝐼^′. (12)

In this case, the definition of process I has the port name m and the message n available as input parameters. If a process J uses the definition of I, then J calls I definition passing the input names between angle brackets, for example, 𝐽(𝑝)=𝑝(𝑞)⋅𝐼⟨𝑞,𝑟⟩. (13)

In (13), J references I definition passing q and r to, respectively, rename 𝐼 inputs m and n.

So in 𝜋-calculus, the round brackets () are used to both organize the input set of processes and organize the set of messages received through a port. Whereas the angle brackets ⟨⟩ are used to organize both the input set of process references and the set of messages sent through a port.

As described above, the 𝜋-calculus is a process algebra to describe and analyze concurrent systems consisting of processes (or agents) which interact with other connected processes.

2.3. Related Work

Some approaches use 𝑍 [30] and Object-𝑍 [31] to formalize UML models. Miao et al. [32] deal with the UML class, sequence, and statechart diagrams; while Kim and Carrington [33] present a formal Object-𝑍 model of the UML state machine. However, they consider UML and not UML-RT with its architectural components. That is because 𝑍 and Object-𝑍 are suitable for capturing data and states, and not for capturing dynamic communication configurations. On the other hand, 𝜋-calculus is suitable to support dynamic communication, that is the focus of our UML-RT formalization proposal. Due to the 𝜋-calculus contribution, other formalisms propose the combination of a state-based formalism and a dynamic action-based calculus by integrating the mobility concepts of the 𝜋-calculus to 𝑍 and Object-𝑍 [34–36].

Terriza et al. [16] describe a mapping of UML-RT to CSP + T, whose objective is to provide time elements to UML-RT, making the mapping of the capsule state diagram and the class diagram to CSP + T definitions. CSP + T is a formal specification language that adds time interval description to CSP. Fischer et al. [17] propose the conversion of UML-RT structure diagram to CSP process algebra. Engels et al. [18] describe a translation from the UML-RT capsule state and structure diagrams to CSP. Ramos et al. [19] propose a mapping of UML-RT state, structure, and class diagrams to Circus, which is a formal method that combines concepts of CSP and 𝑍 [30].

The aforementioned related work deals with synchronous methods. In general, the information in the structure diagram is also provided in the class diagram, and then some authors use one or another. The capsule definition reuse is a criterion that indicates whether the generated definitions in the process algebra can reuse the definition of the capsules. For example, assuming that the capsule A has two subcapsules of type B, the definition of A in 𝜋-calculus references twice the B definition, but for each one, A sets different names as input due to the 𝜋-calculus mobility. In CSP and CCS, it would be necessary to write two equations of B, one for each configuration that B may have. An example of this in CSP is the traffic light system in [17].

Knapp et al. [23] compile UML-RT state diagram into timed automata and represent the timed-annotated UML collaborations as another timed automaton, using a prototype called HUGO/RT. Afterwards, the prototype calls the model checker UPPAAL to verify the model against the scenario specified by the UML collaboration. Some interesting characteristics include the representation of time considered in a UML-RT timeout and the mapping of the event queue that holds the events not already handled by the machine. However, there are two limitations of this approach. First, the events cannot transmit messages; second, the composite and the choice states are not represented.

Additionally, all the above related work considers only the wired ports in their mappings; that is, they do not map the UML-RT unwired ports, so mobility is not addressed.

In our previous work, we propose the UML-RT to 𝜋-calculus mapping rules using the 𝜋-calculus syntax version accepted by the HAL-JACK tool. The HAL-JACK syntax uses the monoadic 𝜋-calculus, which lead us to represent only the communication of one message at a time. Besides, the HAL-JACK syntax requires that all names used in a definition must be declared in its input list; this restriction causes complex mapping rules. In our proposal, we use the 𝜋-calculus syntax proposed by Milner and we represent the communication of more than one message through polyadic 𝜋-caculus. Other contribution comprises the mapping of the entry and the exit actions, the composite states, and the transition chains.

3. The UML-RT to Polyadic 𝜋-Calculus Mapping

In this section, we propose the mapping from the UML-RT to the 𝜋-calculus. We make some initial considerations regarding the mapping, and later we explain the mappings of the following elements of UML-RT: capsule, structure diagram, state diagram, state, and transition.

3.1. Initial Considerations

The processing of a single event at a time by a state machine is known as a run-to-completion (RTC) step, which means that a transition cannot be interrupted by the arrival of an event. When the transition is partitioned into different segments, in the case of the composite states, only the originating segment has a trigger defined, so there is only one event to be processed. So, even in this case, the transition chain (i.e., the sum of all transition segments) is executed in one RTC step. The communication model used by the 𝜋-calculus is the synchronized communication, which is suitable to the RTC step, because the object corresponding to the sender state diagram blocks until it receives the notification about the receipt of the event at the object corresponding to the receiver state diagram.

The polyadic 𝜋-calculus definitions resulted from the mapping follow the syntax proposed by Milner [24]. The UML-RT capsule state diagrams are used in the mapping to retrieve the behavior of the capsules, while the structure diagrams are used to retrieve the association between capsules. The base of the mapping is that a UML-RT port is represented by a 𝜋-calculus port; whereas the messages transmitted through the signal are represented by the 𝜋-calculus messages. In order to be able to represent the transmission of zero or more messages, our approach uses the polyadic 𝜋-calculus.

UML-RT offers a limited support for time annotations, there is one element to set a timer and simulate a timeout. In the RoseRT tool, this timer is allowed through a port that implements a built-in Timing protocol. In our mapping, the timeout is represented by the unobservable action 𝜏, because it is a private interaction inside the capsule.

The main elements of a transition are trigger, action, and guard condition. However, as the focus of the UML-RT to 𝜋-calculus mapping is on communication elements, guard condition is not considered. The transition is triggered by the receipt of a message. The considered transition actions are a message sending or a name reconfiguration, where a name reconfiguration is a way to reconfigure the unwired ports. We assume that the entry and exit actions are only the message sending statements.

The RoseRT tool allows the use of three programming languages, C, C++, and Java, to specify the transition and the state actions. Aiming to be independent from programming languages and simplify the notation used in the mapping rules, we propose the following pseudo codes.

(i)The message receipt statement is written as “𝑝𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑒(𝑚)”, which means that the port p receives the signal e with the list 𝑚 of messages.(ii)The message sending statement is represented as “𝑝𝑠𝑒𝑛𝑑𝑒(𝑚)”, that is, the port 𝑝 sends the signal e with the list 𝑚 of messages.(iii)The name reconfiguration statement is written as “name1 = name2”, that is, name1 is from now on used with the value of name2. In the RoseRT, this information is given through the commands SAP or SPP, for example, “name1·registerSAP(name2)”.

It is important to recall that the list 𝑚 of messages can be empty, when there exists only the synchronization between the ports and no message is transmitted.

Some notations used in the mapping rules need to be presented.

(i)The term 𝑃(𝐿) represents the 𝜋-calculus definition of P with its input set L.(ii)The term 𝑃⟨𝐿⟩ represents a reference to the 𝜋-calculus definition of P. The input set L is passed to the P definition. This notation is used in the syntax proposed by Milner and is commented in Section 2.2.(iii)The term P represents the 𝜋-calculus definition of a component without a defined input set. Each 𝜋-calculus reference to this component should be replaced by the definition P.(iv)The result of 𝐿₁−𝐿₂ is 𝐿₁ without the elements contained in 𝐿₂, where 𝐿₁ and 𝐿₂ are sets.(v)The symbol ⋃ is the union operator in sets. So, ⋃_𝑖∈𝑁𝐿_𝑖=𝐿₁∪𝐿₂∪⋯∪𝐿_𝑁.(vi)The symbol ∑ indicates the application of the choice operator in 𝜋-calculus processes. So, ∑_𝑖∈𝑁𝑃_𝑖=𝑃₁+𝑃₂+⋯+𝑃_𝑁. (vii)The symbol ∏ indicates the application of the sequence operator in 𝜋-calculus actions. So, ∏_𝑖∈𝑁𝜋_𝑖=𝜋₁⋅𝜋₂⋯𝜋_𝑁.

The result of UML-RT mapping is the 𝜋-calculus definition of the main capsule in UML-RT model. After introducing the essence of the mapping and the notations, we are able to present the capsule mapping.

3.2. Capsule Mapping

Each UML-RT capsule has its own state diagram and may contain other capsules in its structure diagram. So, the capsule definition in the 𝜋-calculus is composed by two parts: the structure diagram definition in the 𝜋-calculus and the state diagram definition in the 𝜋-calculus. These two definitions are arranged with the parallel composition operator of the 𝜋-calculus, as presented in Definition 1, because the behavior of the capsule and its subcapsules are executed concurrently in UML-RT.

Definition 1 (Capsule definition). Given a capsule P, its 𝜋-calculus definition is the parallel composition of its state diagram definition and its structure diagram definition. So, the 𝜋-calculus definition of the capsule P is given by 𝑃(𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃])=𝑛𝑒𝑤(𝑅𝑒𝑠𝑡𝑟𝑖𝑐𝑡𝑒𝑑𝑆𝑒𝑡[𝑃])⋅(𝑃_𝑆𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒𝐷𝑖𝑎𝑔𝑟𝑎𝑚∣𝑃_𝑆𝑡𝑎𝑡𝑒𝐷𝑖𝑎𝑔𝑟𝑎𝑚), (14) where
(i)𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃] is the input message set of the P capsule definition. It is defined as the set of the public wired ports of the capsule P.(ii)𝑅𝑒𝑠𝑡𝑟𝑖𝑐𝑡𝑒𝑑𝑆𝑒𝑡[𝑃] is the set of messages restricted to the context of the capsule P. Assuming that P has N subcapsules 𝑄_𝑖, the restricted set is defined as 𝑅𝑒𝑠𝑡𝑟𝑖𝑐𝑡𝑒𝑑𝑆𝑒𝑡[𝑃]=_𝑖∈𝑁(𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃,𝑄_𝑖])−𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃]. (15)(iii)𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃,𝑄_𝑖]: input set used by the parent capsule P to reference the definition of its subcapsule 𝑄_𝑖. It is defined in the structure diagram mapping.
In the example presented in Figure 1, using Definition 1, the main capsule is TopSystem and its 𝜋-calculus definition can be written as 𝑇𝑜𝑝𝑆𝑦𝑠𝑡𝑒𝑚(𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑇𝑜𝑝𝑆𝑦𝑠𝑡𝑒𝑚])=𝑛𝑒𝑤(𝑅𝑒𝑠𝑡𝑟𝑖𝑐𝑡𝑒𝑑𝑆𝑒𝑡[𝑇𝑜𝑝𝑆𝑦𝑠𝑡𝑒𝑚])(𝑇𝑜𝑝𝑆𝑦𝑠𝑡𝑒𝑚_𝑆𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒𝐷𝑖𝑎𝑔𝑟𝑎𝑚∣𝑇𝑜𝑝𝑆𝑦𝑠𝑡𝑒𝑚_𝑆𝑡𝑎𝑡𝑒𝐷𝑖𝑎𝑔𝑟𝑎𝑚)𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑇𝑜𝑝𝑆𝑦𝑠𝑡𝑒𝑚]={𝑜𝑢𝑡}𝑅𝑒𝑠𝑡𝑟𝑖𝑐𝑡𝑒𝑑𝑆𝑒𝑡[𝑇𝑜𝑝𝑆𝑦𝑠𝑡𝑒𝑚]={𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑇𝑜𝑝𝑆𝑦𝑠𝑡𝑒𝑚,𝑆𝑜𝑢𝑟𝑐𝑒]∪𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑇𝑜𝑝𝑆𝑦𝑠𝑡𝑒𝑚,𝑅𝑜𝑢𝑡𝑒𝑟]∪𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑇𝑜𝑝𝑆𝑦𝑠𝑡𝑒𝑚,𝐶𝑜𝑛𝑠𝑢𝑚𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡]∪𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑇𝑜𝑝𝑆𝑦𝑠𝑡𝑒𝑚,𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑑𝑇𝑎𝑟𝑔𝑒𝑡]}−{𝑜𝑢𝑡}. (16)
In order to specify the capsule definition, the next sections explain how to obtain the 𝜋-calculus definitions for the structure diagram and the state diagram.

3.3. Structure Diagram Mapping

A capsule may include subcapsules in its structure diagram. If the structure diagram of a capsule does not have subcapsules, this diagram is defined in the 𝜋-calculus as the stop process. In this case, the capsule definition is composed only by the state diagram definition, because the parallel composition between a process and a stop process is the first process. However, if the capsule has subcapsules, its structure diagram definition is the π-calculus parallel composition of the subcapsules’ definitions, as explained in Definition 2, because all UML-RT subcapsules execute concurrently. In this case, the definition of each subcapsule has to be written using Definition 1 and the connections between ports are used to specify how the parent capsule references its subcapsules.

Definition 2 (Structure diagram definition). Given a capsule P. If P does not have subcapsules, the 𝜋-calculus definition of the P structure diagram is the stop process: 𝑃_𝑆𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒𝐷𝑖𝑎𝑔𝑟𝑎𝑚=0. (17) Otherwise, if P has subcapsules, given a set N of subcapsules 𝑄_𝑖 of P. Given the 𝜋-calculus definition of each subcapsule 𝑄_𝑖 as 𝑄_𝑖(𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑄_𝑖. ]), the 𝜋-calculus definition of the P structure diagram is given by 𝑃_𝑆𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒𝐷𝑖𝑎𝑔𝑟𝑎𝑚=𝑄₁⟨𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃,𝑄₁]⟩∣⋯∣𝑄_𝑁⟨𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃,𝑄_𝑁]⟩, (18) where the 𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃,𝑄₁] is defined based on the connection between the wired ports as follows.
(a)If the port p of the parent capsule P is connected to the public port 𝑞₁ of the subcapsule 𝑄₁, the port q is renamed to p. So, 𝑝∈𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃,𝑄_𝑖].(b)If the public port 𝑞₁ of the subcapsule 𝑄₁ is connected to the public port 𝑞₂ of the subcapsule 𝑄₂, a new name z is generated dynamically to rename the ports 𝑞₁ and 𝑞₂. So, 𝑧∈𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃,𝑄₁],𝑧∈𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃,𝑄₂]. (19)

In the example shown in Figure 1, according to Definition 2, the 𝜋-calculus definition of TopSystem structure diagram is the parallel composition of the definition of the subcapsules: Source, Router, ConsumerTarget, and ExporterTarget. Considering the input sets used by TopSystem to reference its subcapsules, we have that the port setPort of ConsumerTarget is renamed to parent port setCT, the port setPort of ExporterTarget is renamed to parent port setET, and the new name z is created to rename the 𝑞₁ and 𝑟₁. So, TopSystem structure diagram is defined as 𝑇𝑜𝑝𝑆𝑦𝑠𝑡𝑒𝑚_𝑆𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒𝐷𝑖𝑎𝑔𝑟𝑎𝑚=𝑆𝑜𝑢𝑟𝑐𝑒⟨𝑧⟩∣𝑅𝑜𝑢𝑡𝑒𝑟⟨𝑧⟩∣𝐶𝑜𝑛𝑠𝑢𝑚𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡⟨𝑠𝑒𝑡𝐶𝑇⟩∣𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡⟨𝑠𝑒𝑡𝐸𝑇,𝑜𝑢𝑡⟩. (20)

In order to complete the capsule definition in 𝜋-calculus, the next section presents how to obtain the state diagram definition.

3.4. State Diagram Mapping

A capsule can specify or not an associated state diagram. If it is not specified, the 𝜋-calculus definition of the capsule state diagram is the stop process. Otherwise, if the capsule has a state diagram, it is composed by states and transitions between them. The first transition to be activated is the initial transition, which is connected to the initial state. As explained in Section 2.1, the initial transition does not have a trigger, it runs automatically when the state diagram initializes, but it can execute an action. So, the 𝜋-calculus definition of the state diagram is the sequence composition between the definition of initial transition action and the definition of the initial state, as explained in Definition 3.

Definition 3 (State diagram definition). Given a capsule P. If P does not have a state diagram, the 𝜋-calculus definition of the state diagram is the stop process: 𝑃_𝑆𝑡𝑎𝑡𝑒𝐷𝑖𝑎𝑔𝑟𝑎𝑚=0. (21) Otherwise, if P has a state diagram, assuming that InitialTransition is the initial transition and S1 is the initial state, the 𝜋-calculus definition of the state diagram is given by 𝑃_𝑆𝑡𝑎𝑡𝑒𝐷𝑖𝑎𝑔𝑟𝑎𝑚=𝑃_𝐼𝑛𝑖𝑡𝑖𝑎𝑙𝑇𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛_𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑃_𝑆1⟨𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃,𝐼𝑛𝑖𝑡𝑖𝑎𝑙𝑃𝑜𝑖𝑛𝑡,𝑆1]⟩. (22) where 𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃,𝐼𝑛𝑖𝑡𝑖𝑎𝑙𝑃𝑜𝑖𝑛𝑡,𝑆1] is the input message set used by the initial transition definition to reference the definition of the state 𝑆1. It is defined in the transition action mapping.

The definition of the initial transition action is explained in the transition action mapping, and the definition of the initial state is explained in the state mapping. Note that the initial transition trigger is not mentioned in Definition 3, because the initial transition does not have a trigger, it runs automatically when the state diagram initializes. The definitions of the other states reachable from the initial state, which are included in the capsule state diagram, are considered in the definition of the initial state.

In the example presented in Figure 2, the ExporterTarget state diagram is defined, using Definition 3 as 𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆𝑡𝑎𝑡𝑒𝐷𝑖𝑎𝑔𝑟𝑎𝑚=𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝐼𝑛𝑖𝑡𝑖𝑎𝑙_𝐴𝑐𝑡𝑖𝑜𝑛⋅𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆1⋅⟨𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡,𝐼𝑛𝑖𝑡𝑖𝑎𝑙𝑃𝑜𝑖𝑛𝑡,𝑆1]⟩. (23)

According to Definition 3, the state diagram definition references the initial state definition, which depends on the other states and transitions in the state diagram. So, the next section details the state and transition mapping.

3.5. State Mapping

The name of a UML-RT state in the 𝜋-calculus definition is specified as the concatenation of the UML-RT capsule name and the UML-RT state name to guarantee unique definitions in 𝜋-calculus. An entry action is executed whenever the state is entered; regardless of which incoming transition is taken. Besides, a state has multiple outgoing transitions which can be taken. So, the 𝜋-calculus definition of the UML-RT state, as explained in Definition 4, is the sequence composition between its entry action definition and the choice composition of each transition definition.

Definition 4 (Simple state definition). Given a simple state S in the state diagram of a capsule P, and given InputSet[P,S]. Assuming that the state S has an entry action and a set T of outgoing transitions, the 𝜋-calculus definition of the state S is given by 𝑃_𝑆(𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃,𝑆])=𝑃_𝑆_𝐸𝑛𝑡𝑟𝑦𝐴𝑐𝑡𝑖𝑜𝑛⋅_𝑖∈𝑇(𝑃_𝑆_𝑂𝑢𝑡𝑔𝑜𝑖𝑛𝑔𝑇𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛_𝑖), (24) where InputSet[P,S] is the input message set of the S definition. It is defined in the transition action mapping.

For instance, in Figure 2, the 𝑆1 definition can be written using Definition 4 as 𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆1(𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡,𝑆1])=𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆1_𝐸𝑛𝑡𝑟𝑦𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑃_𝑆1_𝑐𝑜𝑛𝑓𝑖𝑔𝑃𝑜𝑟𝑡. (25)

The UML-RT choice point is a special case of UML-RT state, where there is no entry and exit action, and the transition does not have a trigger, because it is enabled according to the condition specified in the choice point. So, Definition 4 can be used to provide the 𝜋-calculus definition of a choice point too.

According to Definition 4, the entry action definition is a part of the state definition. The exit action definition is used only in the transition definition. The entry (or exit) action may not exist in a UML-RT state, so its reference is omitted from the state (or transition) definition. Whether the state performs an entry or exit actions, they include message sending actions in UML-RT, then the 𝜋-calculus definition of the entry and exit actions are the sequence composition of the message sending actions. The definition of a state action is provided in Definition 5 and may represent the definition of an entry action or an exit action.

Definition 5 (State action definition). Given a state S in the state diagram of a capsule P, the state action can be an entry action and an exit action.
If the state action is not defined for S, the 𝜋-calculus reference to the state action definition is omitted from the parent definition.
Otherwise, if the state action is specified as a set N of message sending actions “p_i send 𝑒_𝑖(𝑚_𝑖)”, the 𝜋-calculus definition of the state action is given by 𝑃_𝑆_𝑆𝑡𝑎𝑡𝑒𝐴𝑐𝑡𝑖𝑜𝑛=_𝑖∈𝑁(𝑝_𝑖⟨𝑚_𝑖⟩). (26)

After presenting the state mapping, the next section explains the transition mapping.

3.6. Transition Mapping

In a UML-RT model, the transition has an associated trigger and may execute an action after being activated. Considering the state with its outgoing transitions, it is important to mention that the state exit action is taken whenever the control leaves the state from whatever outgoing transition; so the state exit action has to be computed after the transition trigger and before the transition action. Then, the outgoing transition definition in the 𝜋-calculus, as detailed in Definition 6, is a sequence composition of the transition trigger definition, the state exit action, the transition action definition, and the target state definition.

Definition 6 (Outgoing transition definition). Given the simple states 𝑆1 and 𝑆2 in the state diagram of a capsule P. Given an outgoing transition from 𝑆1 to 𝑆2, the 𝜋-calculus definition of the transition is 𝑃_𝑆1_𝑂𝑢𝑡𝑔𝑜𝑖𝑛𝑔𝑇𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛=𝑃_𝑆1_𝑂𝑢𝑡𝑔𝑜𝑖𝑛𝑔𝑇𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛_𝑇𝑟𝑖𝑔𝑔𝑒𝑟⋅𝑃_𝑆1_𝐸𝑥𝑖𝑡𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑃_𝑆1_𝑂𝑢𝑡𝑔𝑜𝑖𝑛𝑔𝑇𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛_𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑃_𝑆2⟨𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃,𝑆1,𝑆2]⟩, (27) where 𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃,𝑆1,𝑆2] is the input message set used by the state S1 to reference the definition of the state 𝑆2. It is defined in the transition action mapping.

For instance, the transition receiveMsg can be defined, using Definition 6, as 𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆4_𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑀𝑠𝑔=𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆4_𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑀𝑠𝑔_𝑇𝑟𝑖𝑔𝑔𝑒𝑟⋅𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆4_𝐸𝑥𝑖𝑡𝐴𝑐𝑡𝑖𝑜𝑛⋅𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆4_𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑀𝑠𝑔_𝐴𝑐𝑡𝑖𝑜𝑛⋅𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆5⟨𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡,𝑆4,𝑆5]⟩. (28)

A special case of a UML-RT transition is when the transition is a transition chain that transposes the boundaries of composite states. As it is explained in Section 2.1, this transition is partitioned into different segments by the junction pointers, and only the originating segment has a trigger defined, while all segments can execute actions. In this case, we have to compute in the right order the following aspects: the trigger of the first segment, the actions of all segments, the entry or the exit action of all the transposed parent states, as detailed in Definition 7.

Definition 7 (Definition of the outgoing transition chain). Given an outgoing transition chain from a state 𝑆1 to a state 𝑆2, where 𝑆1 and 𝑆2 belong to the state diagram of a capsule P. Assuming that the outgoing transition chain transposes the boundary of a set N of the parent states C 𝑆1’s of 𝑆1, and later transposes the boundary of a set M of the parent states C 𝑆2’s of 𝑆2, where N or M can be empty sets, the transition chain is composed by 𝑁+𝑀+1 segments. In this case, the 𝜋-calculus definition of the outgoing transition chain is given by 𝑃_𝑆1_𝑂𝑢𝑡𝑔𝑜𝑖𝑛𝑔𝑇𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛𝐶ℎ𝑎𝑖𝑛=𝑃_𝑆1_𝑆𝑒𝑔𝑚𝑒𝑛𝑡₁_𝑇𝑟𝑖𝑔𝑔𝑒𝑟⋅𝑃_𝑆1_𝐸𝑥𝑖𝑡𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑃_𝑆1_𝑆𝑒𝑔𝑚𝑒𝑛𝑡₁_𝐴𝑐𝑡𝑖𝑜𝑛⋅(𝑃_𝑆1_𝑂𝑢𝑡𝑔𝑜𝑖𝑛𝑔𝑇𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛𝐶ℎ𝑎𝑖𝑛_𝑈𝑝⋅𝑃_𝑆1_𝑂𝑢𝑡𝑔𝑜𝑖𝑛𝑔𝑇𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛𝐶ℎ𝑎𝑖𝑛_𝐷𝑜𝑤𝑛)⋅𝑃_𝑆2⟨𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃,𝑆,𝑆2]⟩, (29) where 𝑃_𝑆1_𝑂𝑢𝑡𝑔𝑜𝑖𝑛𝑔𝑇𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛𝐶ℎ𝑎𝑖𝑛_𝑈𝑝=_𝑖∈𝑁(𝑃_𝐶𝑆1_𝑖_𝐸𝑥𝑖𝑡𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑃_𝑆1_𝑆𝑒𝑔𝑚𝑒𝑛𝑡_𝑖+1_𝐴𝑐𝑡𝑖𝑜𝑛)𝑃_𝑆1_𝑂𝑢𝑡𝑔𝑜𝑖𝑛𝑔𝑇𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛𝐶ℎ𝑎𝑖𝑛_𝐷𝑜𝑤𝑛=_𝑗∈𝑀(𝑃_𝐶𝑆2_𝑗_𝐸𝑛𝑡𝑟𝑦𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑃_𝑆1_𝑆𝑒𝑔𝑚𝑒𝑛𝑡_𝑗+1+𝑁_𝐴𝑐𝑡𝑖𝑜𝑛). (30)

The ExporterTarget state diagram, illustrated in Figures 2 and 3, has the transition chain initiating with the segment consumeMsg. This transition chain originates at the state 𝑆5 and transposes the boundary of the composite state 𝑆2 until reaching the state 𝑆3. According to Definition 7, the transition chain consumeMsg is defined as 𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑑𝑇𝑎𝑟𝑔𝑒𝑡_𝑆5_𝑐𝑜𝑛𝑠𝑢𝑚𝑒𝑀𝑠𝑔=𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑑𝑇𝑎𝑟𝑔𝑒𝑡_𝑆5_𝑐𝑜𝑛𝑠𝑢𝑚𝑒𝑀𝑠𝑔_𝑇𝑟𝑖𝑔𝑔𝑒𝑟⋅𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑑𝑇𝑎𝑟𝑔𝑒𝑡_𝑆5_𝐸𝑥𝑖𝑡𝐴𝑐𝑡𝑖𝑜𝑛⋅𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑑𝑇𝑎𝑟𝑔𝑒𝑡_𝑆5_𝑐𝑜𝑛𝑠𝑢𝑚𝑒𝑀𝑠𝑔_𝐴𝑐𝑡𝑖𝑜𝑛⋅𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑑𝑇𝑎𝑟𝑔𝑒𝑡_𝑆2_𝐸𝑥𝑖𝑡𝐴𝑐𝑡𝑖𝑜𝑛⋅𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑑𝑇𝑎𝑟𝑔𝑒𝑡_𝑆5_𝑚𝑠𝑔𝐶𝑜𝑛𝑠𝑢𝑚𝑒𝑑_𝐴𝑐𝑡𝑖𝑜𝑛⋅𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑑𝑇𝑎𝑟𝑔𝑒𝑡_𝑆3⟨𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡,𝑆5,𝑆3]⟩. (31)

As commented in Section 3.1, the transition trigger is a message receipt statement and the transition action can be a message sending statement or a name reconfiguration statement. The transition trigger definition is provided in Definition 8, while the transition action definition is explained in Definition 9.

Definition 8 (Transition trigger definition). Given a transition from state 𝑆1 to state𝑆2 in the state diagram of a capsule P.
If there is no trigger specified to the transition, the 𝜋-calculus reference to the transition trigger definition is omitted from the parent definition.
Otherwise, assuming that the transition can be triggered by a set N of message receipt statements as “𝑝_𝑖𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑒_𝑖(𝑚_𝑖)”, the 𝜋-calculus definition of the transition trigger is given by 𝑃_𝑆1_𝑇𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛_𝑇𝑟𝑖𝑔𝑔𝑒𝑟=_𝑖∈𝑁(𝑝_𝑖(𝑚_𝑖)). (32) A special case occurs when e_i is a timeout signal. In this case, the trigger is represented by the unobservable action 𝜏. So, 𝑝_𝑖(𝑚_𝑖)=𝜏.

Analyzing Definition 8, the transition trigger definition considers all the messages that the capsule can receive in the current transition. However, it cannot be defined, for example, in an outgoing transition of a choice point and in the first segment of a transition chain.

In Definition 9, the transition action considers all the message sending and the reconfiguration statements. In case of a reconfiguration statement, it is important that the old name is the one used by the next state, while the new name is used to reference the next state definition. The input message set of the capsule definition is maintained in the other input sets to keep the consistence of the 𝜋-calculus definitions. Note that Definition 9 holds to the actions of all segments in a transition chain.

Definition 9 (Transition action definition). Given a transition from state 𝑆1 to state 𝑆2 in the state diagram of a capsule P.
If there is no action associated to the transition, the 𝜋-calculus reference to the transition action definition is omitted from the parent definition.
Otherwise, assuming that the transition action is composed of a set N of message sending statements as “𝑝_𝑖𝑠𝑒𝑛𝑑𝑒_𝑖(𝑚_𝑖)” and also by a set M of name reconfiguration statements as “𝑦_𝑗=𝑥_𝑗”, the 𝜋-calculus definition of the transition action is given by 𝑃_𝑆1_𝑇𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛_𝑇𝑟𝑖𝑔𝑔𝑒𝑟=_𝑖∈𝑁(𝑝_𝑖⟨𝑚_𝑖⟩),𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃,𝑆1,𝑆2]=_𝑗∈𝑀𝑥_𝑗∪𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃],𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃,𝑆2]=_𝑗∈𝑀𝑦_𝑗∪𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃], (33) where 𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑃] is the input message set of the P capsule definition, already defined in Definition 1.

For instance, the transition receiveMsg of the ExporterTarget state diagram, illustrated in Figure 3, has a trigger which can be defined using Definition 8 as follows: 𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆4_𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑀𝑠𝑔_𝑇𝑟𝑖𝑔𝑔𝑒𝑟=𝑡(𝑑1,𝑑2). (34)

It is an example of receiving two messages in a single synchronization, which shows the importance of using polyadic 𝜋-calculus in the mapping.

As an example to apply Definition 9, consider the transition segment exportMsg. So, 𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆5_𝑒𝑥𝑝𝑜𝑟𝑡𝑀𝑠𝑔_𝐴𝑐𝑡𝑖𝑜𝑛()=𝑒𝑥𝑝𝑜𝑟𝑡⟨𝑑1⟩. (35)

The next section presents three examples that illustrate how the mapping rules can be applied to obtain the 𝜋-calculus definitions from a UML-RT model, and how to manipulate the generated 𝜋-calculus definitions in order to verify some system requirements.

4. Examples of the Mapping

In this section, we develop three examples. The first one is the TopSystem, shown in Figure 1 and used in the previous sections to introduce the UML-RT and to exemplify the mapping rules application. The objective is to provide the entire UML-RT model of the TopSystem and to explain step by step how to obtain the 𝜋-calculus definition of its Source capsule. The example includes mobility and deals with some UML-RT concepts which were not previously addressed in our previous work, such as the entry and the exit actions, the composite states, and the transition chains.

The second example is a Heating System for Air Conditioning, which is an adaptation of [10], and the objective is to use the 𝜋-calculus definitions to verify if the UML-RT model correctly implements the system requirements. This example does not include mobility concept; however it is interesting to understand the possible manipulations using 𝜋-calculus reactions in order to verify the system behavior.

Finally, the third example is the Handover protocol, an example of mobile processes presented by Milner in [24]. It includes the communication of more than one message at a time, so it is suitable case for the polyadic 𝜋-calculus.

4.1. Router Example

In this section, we explain how to obtain the 𝜋-calculus definition of the entire capsule TopSystem, illustrated in Figure 1, using the mapping rules provided in Section 3. The capsule TopSystem comprises the following capsules: source (instance of the capsule Source), router (instance of the capsule Router), target1 (instance of the capsule ConsumerTarget), and target2 (instance of the capsule ExporterTarget). We provide the state diagram of the capsules TopSystem, Source, Router, and ConsumerTarget, respectively, in Figures 5, 6, 7, and 8.

Figure 5 

The state diagram of the capsule TopSystem.

Figure 6 

The state diagram of the capsule Source.

Figure 7 

The state diagram of the capsule Router.

Figure 8 

The state diagram of the capsule ConsumerTarget.

The entry and exit actions of the states in the capsule TopSystem and its subcapsules are detailed in Table 2. It is important to note that these actions are not considered as a sending message statement or a name reconfiguration statement, because they just set up an internal timeout, so the 𝜋-calculus definition of each action is the stop process.

Table 2 

Entry and exit actions of the states in the capsule TopSystem and its subcapsules.

The specification of the transitions inside the state diagrams of the capsule TopSystem and its subcapsules is provided in Table 3. Table 4 presented the pseudocode that represents the transition trigger and the transition action; the pseudocode helps to understand the application of the mapping rules to obtain the 𝜋-calculus definitions.

Table 3 

UML-RT transitions’ specification for the capsule TopSystem and its subcapsules.

Table 4 

Pseudocode of the transitions in the capsule TopSystem and its subcapsules.

The structure diagrams of the TopSystem subcapsules are not provided because the majority of ports are public, so they can be seen in TopSystem structure diagram (shown in Figure 1). The only exception is the protected port timer presented in all TopSystem subcapsules. The port timer implements the protocol Timing (a built-in protocol of the RoseRT tool) and receives the timeout signal.

In order to show how to apply the mapping rules to obtain the 𝜋-calculus definition of a UML-RT capsule, we detail the mapping of the capsule Source.

Using Definition 1, the 𝜋-calculus definition of the capsule Source is the parallel composition of its state diagram definition and its structure diagram definition: 𝑆𝑜𝑢𝑟𝑐𝑒(𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑆𝑜𝑢𝑟𝑐𝑒])=𝑛𝑒𝑤(𝑅𝑒𝑠𝑡𝑟𝑖𝑐𝑡𝑒𝑑𝑆𝑒𝑡[𝑆𝑜𝑢𝑟𝑐𝑒])(𝑆𝑜𝑢𝑟𝑐𝑒_𝑆𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒𝐷𝑖𝑎𝑔𝑟𝑎𝑚∣𝑆𝑜𝑢𝑟𝑐𝑒_𝑆𝑡𝑎𝑡𝑒𝐷𝑖𝑎𝑔𝑟𝑎𝑚), (36) where 𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑆𝑜𝑢𝑟𝑐𝑒]={𝑞},𝑅𝑒𝑠𝑡𝑟𝑖𝑐𝑡𝑒𝑑𝑆𝑒𝑡[𝑆𝑜𝑢𝑟𝑐𝑒]={}−{𝑞}={}. (37) So, we have 𝑆𝑜𝑢𝑟𝑐𝑒(𝑞)=(𝑆𝑜𝑢𝑟𝑐𝑒_𝑆𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒𝐷𝑖𝑎𝑔𝑟𝑎𝑚∣𝑆𝑜𝑢𝑟𝑐𝑒_𝑆𝑡𝑎𝑡𝑒𝐷𝑖𝑎𝑔𝑟𝑎𝑚). (38)

According to Definition 2, the structure diagram of the capsule Source is the parallel composition of its subcapsules. As the capsule Source does not have subcapsules, the 𝜋-calculus definition of its structure diagram is the stop process: 𝑆𝑜𝑢𝑟𝑐𝑒_𝑆𝑡𝑟𝑢𝑐𝑡𝑢𝑟𝑒𝐷𝑖𝑎𝑔𝑟𝑎𝑚=0. (39)

The 𝜋-calculus definition of the Source state diagram, according to Definition 3, can be written as 𝑆𝑜𝑢𝑟𝑐𝑒_𝑆𝑡𝑎𝑡𝑒𝐷𝑖𝑎𝑔𝑟𝑎𝑚=𝑆𝑜𝑢𝑟𝑐𝑒_𝐼𝑛𝑖𝑡𝑖𝑎𝑙_𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1⟨𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑆𝑜𝑢𝑟𝑐𝑒,𝐼𝑛𝑖𝑡𝑖𝑎𝑙𝑃𝑜𝑖𝑛𝑡,𝑆1]⟩. (40)

As the Initial transition does not have an action, using the Definition 9 it is omitted from the Source definition and we have 𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑆𝑜𝑢𝑟𝑐𝑒,𝐼𝑛𝑖𝑡𝑖𝑎𝑙𝑃𝑜𝑖𝑛𝑡,𝑆1]={𝑞},𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑆𝑜𝑢𝑟𝑐𝑒,𝑆1]={𝑞},𝑆𝑜𝑢𝑟𝑐𝑒_𝑆𝑡𝑎𝑡𝑒𝐷𝑖𝑎𝑔𝑟𝑎𝑚=𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1⟨𝑞⟩. (41)(42)(43)

Using the Definition 4 and (42), the 𝜋-calculus definition of state 𝑆1, in the capsule Source, can be written as the sequence composition of its entry action and its unique outgoing transition 𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1(𝑞)=𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1_𝐸𝑛𝑡𝑟𝑦𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1_𝑡𝑖𝑚𝑒𝑜𝑢𝑡. (44)

As the 𝑆1 entry action is not specified, according to Definition 5 it is omitted from the parent definition, so 𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1(𝑞)=𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1_𝑡𝑖𝑚𝑒𝑜𝑢𝑡. (45)

The 𝜋-calculus definition of the transition timeout is made based on Definition 6. So, from (45), we have 𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1(𝑞)=𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1_𝑡𝑖𝑚𝑒𝑜𝑢𝑡_𝑡𝑟𝑖g𝑔𝑒𝑟⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1_𝐸𝑥𝑖𝑡𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑃_𝑆1_𝑡𝑖𝑚𝑒𝑜𝑢𝑡_𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆2⟨𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑆𝑜𝑢𝑟𝑐𝑒,𝑆1,𝑆2]⟩. (46)

The trigger of the transition timeout is the unobservable action 𝜏, based on Definition 8, because the trigger in UML-RT is specified by the receiving of a timeout signal as stated in Table 4. The 𝑆1 exit action is not specified, so according to Definition 5 it is omitted from the parent definition. There is no action in transition timeout, so its definition is omitted from the parent definition and 𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑆𝑜𝑢𝑟𝑐𝑒,𝑆1,𝑆2]=𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑆𝑜𝑢𝑟𝑐𝑒,𝑆2]={𝑞}. From (46), the 𝑆1 definition in the 𝜋-calculus can be written as 𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1(𝑞)=𝜏⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆2⟨𝑞⟩. (47)

The 𝑆1 definition references the state 𝑆2. So, it is necessary to specify the 𝜋-calculus definition of state 𝑆2. So, by using Definition 4, we have 𝑆𝑜𝑢𝑟𝑐𝑒_𝑆2(𝑞)=𝑆𝑜𝑢𝑟𝑐𝑒_𝑆2_𝐸𝑛𝑡𝑟𝑦𝐴𝑐𝑡𝑖𝑜𝑛⋅(𝑆𝑜𝑢𝑟𝑐𝑒_𝑆2_𝑠𝑒𝑛𝑑𝑃𝑜𝑟𝑡𝑋+𝑆𝑜𝑢𝑟𝑐𝑒_𝑆2_𝑠𝑒𝑛𝑑𝑃𝑜𝑟𝑡𝑌). (48)

Using Definitions 5 and 6, from (48), we have 𝑆𝑜𝑢𝑟𝑐𝑒_𝑆2(𝑞)=((𝑆𝑜𝑢𝑟𝑐𝑒_𝑆2_𝑠𝑒𝑛𝑑𝑃𝑜𝑟𝑡𝑋_𝑡𝑟𝑖𝑔𝑔𝑒𝑟⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆2_𝐸𝑥𝑖𝑡𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑃_𝑆2_𝑠𝑒𝑛𝑑𝑃𝑜𝑟𝑡𝑋_𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆3⟨𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑆𝑜𝑢𝑟𝑐𝑒,𝑆2,𝑆3]⟩)+(𝑆𝑜𝑢𝑟𝑐𝑒_𝑆2_𝑠𝑒𝑛𝑑𝑃𝑜𝑟𝑡𝑌_𝑡𝑟𝑖𝑔𝑔𝑒𝑟⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆2_𝐸𝑥𝑖𝑡𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑃_𝑆2_𝑠𝑒𝑛𝑑𝑃𝑜𝑟𝑡𝑌_𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆3⟨𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑆𝑜𝑢𝑟𝑐𝑒,𝑆2,𝑆3]⟩)). (49)

Using Definitions 5, 8, and 9, from (49) the 𝜋-calculus definition of 𝑆2 is written as 𝑆𝑜𝑢𝑟𝑐𝑒_𝑆2(𝑞)=(𝑞⟨𝑥⟩⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆3⟨𝑞⟩)+(𝑞⟨𝑦⟩⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆3⟨𝑞⟩). (50)

However, the𝑆2 definition references the state 𝑆3. So, it is also necessary to specify the 𝜋-calculus definition of the state 𝑆3. So, by using Definition 4, we have 𝑆𝑜𝑢𝑟𝑐𝑒_𝑆3(𝑞)=𝑆𝑜𝑢𝑟𝑐𝑒_𝑆3_𝐸𝑛𝑡𝑟𝑦𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆3_𝑡𝑖𝑚𝑒𝑜𝑢𝑡2. (51) Using Definitions 5 and 6, from (51), we have 𝑆𝑜𝑢𝑟𝑐𝑒_𝑆3(𝑞)=𝑆𝑜𝑢𝑟𝑐𝑒_𝑆3_𝑡𝑖𝑚𝑒𝑜𝑢𝑡2_𝑡𝑟𝑖𝑔𝑔𝑒𝑟⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆3_𝐸𝑥𝑖𝑡𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑃_𝑆3_𝑡𝑖𝑚𝑒𝑜𝑢𝑡2_𝐴𝑐𝑡𝑖𝑜𝑛⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1⟨𝐼𝑛𝑝𝑢𝑡𝑆𝑒𝑡[𝑆𝑜𝑢𝑟𝑐𝑒,𝑆3,𝑆1]⟩. (52)

Finally, using Definitions 5, 8, and 9, from (51) the 𝜋-calculus definition of 𝑆3 is written as 𝑆𝑜𝑢𝑟𝑐𝑒_𝑆3(𝑞)=𝜏⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1⟨𝑞⟩. (53)

From (47), (50), and (53), the 𝜋-calculus definition of the state 𝑆1 is 𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1(𝑞)=𝜏⋅((𝑞⟨𝑥⟩⋅𝜏⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1⟨𝑞⟩)+(𝑞⟨𝑦⟩⋅𝜏⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1⟨𝑞⟩)). (54)

Finally, using (38), (39), (43), and (54), the 𝜋-calculus definition of the capsule Source is given by 𝑆𝑜𝑢𝑟𝑐𝑒(𝑞)=𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1⟨𝑞⟩𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1(𝑞)=𝜏⋅((𝑞⟨𝑥⟩⋅𝜏⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1⟨𝑞⟩)+(𝑞⟨𝑦⟩⋅𝜏⋅𝑆𝑜𝑢𝑟𝑐𝑒_𝑆1⟨𝑞⟩)). (55)

Using the mapping rules and the specifications of transitions in Table 4, it is possible to define the 𝜋-calculus definition of the other capsules that compose the TopSystem example, as written in 𝑅𝑜𝑢𝑡𝑒𝑟(𝑟)=𝑅𝑜𝑢𝑡𝑒𝑟_𝑆1⟨𝑟⟩𝑅𝑜𝑢𝑡𝑒𝑟_𝑆1(𝑟)=𝑟(𝑎)⋅𝑅𝑜𝑢𝑡𝑒𝑟_𝑆2⟨𝑎,𝑟⟩𝑅𝑜𝑢𝑡𝑒𝑟_𝑆2(𝑎𝑙𝑒𝑟𝑡,𝑟)=𝜏⋅𝑎𝑙𝑒𝑟𝑡⟨𝑏1,𝑏2⟩⋅𝜏⋅𝑅𝑜𝑢𝑡𝑒𝑟_𝑆1⟨𝑟⟩𝐶𝑜𝑛𝑠𝑢𝑚𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡(𝑠𝑒𝑡𝑃𝑜𝑟𝑡)=𝑠𝑒𝑡𝑃𝑜𝑟𝑡(𝑎𝑢𝑥)⋅𝐶𝑜𝑛𝑠𝑢𝑚𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆2⟨𝑎𝑢𝑥,𝑠𝑒𝑡𝑃𝑜𝑟𝑡⟩𝐶𝑜𝑛𝑠𝑢𝑚𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆2(𝑠,𝑠𝑒𝑡𝑃𝑜𝑟𝑡)=𝑠(𝑐1,𝑐2)⋅𝜏⋅𝐶𝑜𝑛𝑠𝑢𝑚𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆2⟨𝑠,𝑠𝑒𝑡𝑃𝑜𝑟𝑡⟩𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡(𝑠𝑒𝑡𝑃𝑜𝑟𝑡,𝑒𝑥𝑝𝑜𝑟𝑡)=𝑠𝑒𝑡𝑃𝑜𝑟𝑡(𝑎𝑢𝑥)⋅𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆4⟨𝑎𝑢𝑥,𝑠𝑒𝑡𝑃𝑜𝑟𝑡,𝑒𝑥𝑝𝑜𝑟𝑡⟩𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆4(𝑡,𝑠𝑒𝑡𝑃𝑜𝑟𝑡,𝑒𝑥𝑝𝑜𝑟𝑡)=𝑡(𝑑1,𝑑2)⋅(𝜏⋅𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆4⟨𝑡,𝑠𝑒𝑡𝑃𝑜𝑟𝑡,𝑒𝑥𝑝𝑜𝑟𝑡⟩+(∣𝑒𝑥𝑝𝑜𝑟𝑡⟨𝑑1⟩⋅𝜏⋅𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡_𝑆4⟨𝑡,𝑠𝑒𝑡𝑃𝑜𝑟𝑡,𝑒𝑥𝑝𝑜𝑟𝑡⟩))𝑇𝑜𝑝𝑆𝑦𝑠𝑡𝑒𝑚(𝑜𝑢𝑡)=𝑛𝑒𝑤𝑧,𝑠𝑒𝑡𝐶𝑇,𝑠𝑒𝑡𝐸𝑇⋅(𝑆𝑜𝑢𝑟𝑐𝑒⟨𝑧⟩∣𝑅𝑜𝑢𝑡𝑒𝑟⟨𝑧⟩∣𝐶𝑜𝑛𝑠𝑢𝑚𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡⟨𝑠𝑒𝑡𝐶𝑇⟩⋅∣𝐸𝑥𝑝𝑜𝑟𝑡𝑒𝑟𝑇𝑎𝑟𝑔𝑒𝑡⟨𝑠𝑒𝑡𝐸𝑇,𝑜𝑢𝑡⟩𝑠𝑒𝑡𝐶𝑇⟨𝑥⟩⋅𝑠𝑒𝑡𝐸𝑇⟨𝑦⟩). (56)(57)(58)(1)(2)(3)(4)(5)(6)(7)(59)

Through the definition of a capsule it is possible to capture the behavior of this capsule, for example, the capsule Source in (55) executes an unobservable action (i.e., a timeout), sends the message x or y along the port q, and returns to a state (in this case S1), where it is possible to repeat the same behavior. Due to the connection between the subcapsules Source and Router in the capsule TopSystem, the parent capsule references its subcapsule Source renaming the port q to z, and references its subcapsule Router renaming the port r to z. Therefore, the message x or y sent by the subcapsule Source is received by the subcapsule Router, and it is stored in the name a, according to (56). The definition of Router_ 𝑆1 references the definition of Router_ 𝑆2 renaming alert with a, so the subcapsule Router is now able to send the messages 𝑏1 and 𝑏2 through the port alert, which can be x or y.

The capsule TopSystem in (59) sends x to its subcapsule ConsumerTarget and sends y to its subcapsule ExporterTarget. According to (57), the subcapsule ConsumerTarget configures its port s with x to be able to receive the message from the capsule Router. Similarly, according to (58), the subcapsule ExporterTarget configures its port t with y to be able to receive the message from the capsule Router. After receiving the message from the Router, the control of the subcapsule ExporterTarget can return to ExporterTarget_ 𝑆4, or it can send the received message through its port export and later the control returns to ExporterTarget_ 𝑆4. Note that the port export is in fact renamed to out, which is a public interface of the capsule TopSystem, according to (59).

In the example, the 𝜋-calculus definitions corresponding to the UML-RT model were specified. Using the generated 𝜋-calculus definitions, it is possible to analyze the interactions between the system components, therefore some undesirable system behavior can be uncovered during the modeling phase.

4.2. Heating System

In this section, we use an example of a system, which was adapted from the example described in [10] and is called Heating System for Air Conditioning. In this example, the system requirements are provided as well as the UML-RT model that implements the requirements. Furthermore, the 𝜋-calculus definitions for the system are generated following the mapping rules. Some scenarios are proposed according to the system requirements. Later, we compose the 𝜋-calculus definitions of the system and the scenarios in order to verify if the model meets the requirements. The handlings are made manually.

The heating system consists of the standard heating subsystem and the additional heating subsystem that is used to shorten the time needed to increase the temperature in the car. The specification of the heating system is provided through the requirements R1 to R7. In the requirements’ descriptions we anticipate the UML-RT states of the state diagrams of this section. They are named between parentheses. The requirements are as follows.

R1
The heating system has two levels: level1 (Level1 state) and level2 (Level2 state). In level1 only the standard heating system is active, while in level2 the additional heating system is also active.

R2
An incoming init event changes the heating system’s status from shutdown (Shutdown state) to level1 and from start (Start state) to level2.

R3
The heating system automatically changes its status from level2 to level1 after 10 minutes.

R4
The heating system automatically changes its status from start to shutdown after 10 minutes.

R5
Exceptions regarding invalid voltage or ignition key in status “cold” immediately cause deactivation of the heating system for 10 seconds.

R6
As soon as there is no more exception, the heating system continues operating on the selected level.

R7
The heating system’ status changes to shutdown if the ignition key stays in status “cold” for 5 minutes, or if the key is removed.

The heating system model (Figure 9) was constructed using the RoseRT tool. It is a capsule called HeatingSystem composed of three subcapsules: low (instance of the capsule LowExceptions in Figure 10), high (instance of the capsule HighExceptions in Figure 11), and controller (instance of the capsule HeatingController in Figure 12). The interface of the HeatingSystem is the ports to receive the ignition status (KL15off, KL15radio, and KL15cold), the voltage invalid status (iVolt), the signal to start and shutdown the controller operation (startController and shutdownController, resp.). The specification of the transitions inside each capsule state diagram is in Table 5; whereas the entry and exit actions of the states are detailed in Table 6.

Table 5 

Transitions in the HeatingSystem subcapsules.

Table 6 

Entry and exit actions of the states in the HeatingSystem subcapsules.

Figure 9 

The structure diagram of the capsule HeatingSystem.

Figure 10 

The state diagram of the capsule LowExceptions.

Figure 11 

The state diagram of the capsule HighExceptions.

Figure 12 

The state diagram of the capsule HeatingController.

The capsule LowExceptions starts at the state OkayLPrio and changes to OffLPrio, if it receives a signal through the port ignitionCold or invalidVoltage. During this transition, the capsule sends a signal through the port off in order to shutdown the heating controller temporarily. After 10 seconds, the capsule LowExceptions is ready to receive more exception information, when it returns to the state OkayLPrio.

The capsule HighExceptions starts at the state OffHPrio and changes to OkayHPrio, if it receives a signal through the port ignitionRadio. This transition executes an action of sending a signal along the port on in order to start the heating controller, because there is no more high exception to be handled. After receiving a signal through the port ignitionCold at the state OkayHPrio, the capsule HighExceptions changes to the state WaitHPrio. At the state WaitHPrio, the capsule can change to the state OkayHPrio if the ignition returns to the status radio; or it can detect a high exception if the ignition exceeds 5 minutes in the status cold, or if the ignition changes to the status off. In case of detecting a high exception, the capsule sends a signal along the port off aiming to shutdown the heating controller.

The capsule HeatingController begins at the state Start and changes to Level2 if it receives a signal through the ports on or init. At the state Level2, the capsule can changes to the state Level1 after 10 minutes, or it can shutdown after receiving a signal along the ports off or end. At the state Level1, the capsule can shutdown too. The capsule is able to notify its status in each state sending a message through the port out.

Some system requirements can be verified by a visual inspection in the model, for example, the requirements R1 to R4 are addressed by the transitions specified in the state diagram of the capsule HeatingController. Other requirements are modeled, for example, R5 to R7, however we do not know if the behavior of the system interacting components complies with the requirements. In order to verify some properties originated immediately from the requirements, we can use the system formal specification in the 𝜋-calculus.

The 𝜋-calculus definitions of the heating system are provided below; however we omit the capsule name in each state name due to space limitation 𝐻𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑦𝑠𝑡𝑒𝑚(𝐾𝐿15𝑟𝑎𝑑𝑖𝑜,𝐾𝐿15𝑐𝑜𝑙𝑑,𝐾𝐿15off,𝑖𝑉𝑜𝑙𝑡,𝑠𝑡𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟,𝑠ℎ𝑢𝑡𝑑𝑜𝑤𝑛𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟,ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠)=𝑛𝑒𝑤𝑜𝑛,off(𝐻𝑒𝑎𝑡𝑖𝑛𝑔𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟⟨𝑆𝑒𝑡1Ref⟩∣𝐿𝑜𝑤𝐸𝑥𝑐𝑒𝑝𝑡𝑖𝑜𝑛𝑠⟨𝑆𝑒𝑡2Ref⟩∣𝐻𝑖𝑔ℎ𝐸𝑥𝑐𝑒𝑝𝑡𝑖𝑜𝑛𝑠⟨𝑆𝑒𝑡3Ref⟩), (60) where 𝑆𝑒𝑡1Ref={𝑠𝑡𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟,𝑠ℎ𝑢𝑡𝑑𝑜𝑤𝑛𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟,𝑜𝑛,off,ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠},𝑆𝑒𝑡2Ref={𝐾𝐿15𝑐𝑜𝑙𝑑,𝑖𝑉𝑜𝑙𝑡,𝑜𝑛,off},𝑆𝑒𝑡3Ref={𝐾𝐿15𝑟𝑎𝑑𝑖𝑜,𝐾𝐿15𝑐𝑜𝑙𝑑,𝐾𝐿15off,𝑜𝑛,off}. (61)

Declaring 𝑆𝑒𝑡1={𝑖𝑛𝑖𝑡,𝑒𝑛𝑑,𝑜𝑛,off,𝑜𝑢𝑡} as the input set of HeatingController definition, we have =𝐻𝑒𝑎𝑡𝑖𝑛𝑔𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟(𝐿𝑖𝑠𝑡1)=𝑆𝑡𝑎𝑟𝑡⟨𝑆𝑒𝑡1⟩𝑆𝑡𝑎𝑟𝑡(𝑆𝑒𝑡1)=(𝑜𝑛+𝑖𝑛𝑖𝑡)⋅𝐿𝑒𝑣𝑒𝑙2⟨𝑆𝑒𝑡1⟩+𝜏⋅𝑆ℎ𝑢𝑡𝑑𝑜𝑤𝑛⟨𝑆𝑒𝑡1⟩𝐿𝑒𝑣𝑒𝑙2(𝑆𝑒𝑡1)=𝑜𝑢𝑡⟨𝐿2⟩⋅((off+𝑒𝑛𝑑)⋅𝑆ℎ𝑢𝑡𝑑𝑜𝑤𝑛⟨𝑆𝑒𝑡1⟩+𝜏⋅𝐿𝑒𝑣𝑒𝑙1⟨𝑆𝑒𝑡1⟩)𝐿𝑒𝑣𝑒𝑙1(𝑆𝑒𝑡1)=𝑜𝑢𝑡⟨𝐿1⟩⋅((off+𝑒𝑛𝑑)⋅𝑆ℎ𝑢𝑡𝑑𝑜𝑤𝑛⟨𝑆𝑒𝑡1⟩)𝑆ℎ𝑢𝑡𝑑𝑜𝑤𝑛(𝑆𝑒𝑡1)𝑜𝑢𝑡⟨𝐵𝐴𝐷⟩⋅((𝑜𝑛+𝑖𝑛𝑖𝑡)⋅𝐿𝑒𝑣𝑒𝑙1⟨𝑆𝑒𝑡1⟩). (62)(8)(9)(10)(11)(12)(13)(14)(15)(16)

Declaring 𝑒𝑡2={𝑖𝑔𝑛𝑖𝑡𝑖𝑜𝑛𝐶𝑜𝑙𝑑,𝑖𝑛𝑣𝑎𝑙𝑖𝑑𝑉𝑜𝑙𝑡𝑎𝑔𝑒, 𝑜𝑛,  off} as the input set of LowExceptions definition, we have ⋅𝐿𝑜𝑤𝐸𝑥𝑐𝑒𝑝𝑡𝑖𝑜𝑛𝑠(𝑆𝑒𝑡2)=𝑂𝑘𝑎𝑦𝐿𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡2⟩𝑂𝑘𝑎𝑦𝐿𝑃𝑟𝑖𝑜(𝑆𝑒𝑡2)=(𝑖𝑔𝑛𝑖𝑡𝑖𝑜𝑛𝐶𝑜𝑙𝑑+𝑖𝑛𝑣𝑎𝑙𝑖𝑑𝑉𝑜𝑙𝑡𝑎𝑔𝑒)off⋅Off𝐿𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡2⟩Off𝐿𝑃𝑟𝑖𝑜(𝑆𝑒𝑡2)=𝜏⋅𝑜𝑛⋅𝑂𝑘𝑎𝑦𝐿𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡2⟩. (63)

Declaring 𝑆𝑒𝑡3 = {ignitionRadio, ignitionCold, ignitionOff, on, off} as the input set of HighExceptions definition, we have 𝐻𝑖𝑔ℎ𝐸𝑥𝑐𝑒𝑝𝑡𝑖𝑜𝑛𝑠(𝑆𝑒𝑡3)=Off𝐻𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡3⟩Off𝐻𝑃𝑟𝑖𝑜(𝑆𝑒𝑡3)=𝑖𝑔𝑛𝑖𝑡𝑖𝑜𝑛𝑅𝑎𝑑𝑖𝑜⋅⋅𝑜𝑛⋅𝑂𝑘𝑎𝑦𝐻𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡3⟩𝑂𝑘𝑎𝑦𝐻𝑃𝑟𝑖𝑜(𝑆𝑒𝑡3)=𝑖𝑔𝑛𝑖𝑡𝑖𝑜𝑛𝐶𝑜𝑙𝑑⋅𝑊𝑎𝑖𝑡𝐻𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡3⟩𝑊𝑎𝑖𝑡𝐻𝑃𝑟𝑖𝑜(𝑆𝑒𝑡3)=𝑖𝑔𝑛𝑖𝑡𝑖𝑜𝑛𝑅𝑎𝑑𝑖𝑜⋅𝑂𝑘𝑎𝑦𝐻𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡3⟩+𝑖𝑔𝑛𝑖𝑡𝑖𝑜𝑛Offoff⋅Off𝐻𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡3⟩+𝜏⋅off⋅Off𝐻𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡3⟩. (64)

After obtaining the definitions of the components in the model, it is desirable to verify its properties. In order to verify the requirements R5 and R6, we assume the scenario where an external actor sends a 𝑠𝑡𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟 event and, later, it sends an 𝑖𝑉𝑜𝑙𝑡 event. The scenario can be specified as 𝑆𝑐𝑒𝑛𝑎𝑟𝑖𝑜1=⋅𝑠𝑡𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠1)𝑖𝑉𝑜𝑙𝑡⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠2)⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠3). (65) After the 𝑠𝑡𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟 event, the information that the system is at the level2 is expected, so 𝑠1 will receive “𝐿2”. After the 𝑖𝑉𝑜𝑙𝑡 event, the information that the system is shutdown is due, so 𝑠2 will receive “BAD”. After the timeout of the low exception (in this case, the invalid voltage), the information that the system is at the level2 is waited, so 𝑠3 will be “𝐿2”, because the requirement R6 specifies that the system has to return to the selected level after the exceptions.

Composing the heating system and the scenario, we obtain 𝐻𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑦𝑠𝑡𝑒𝑚(𝐾𝐿15𝑟𝑎𝑑𝑖𝑜,𝐾𝐿15𝑐𝑜𝑙𝑑,𝐾𝐿15off,𝑖𝑉𝑜𝑙𝑡,𝑠𝑡𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟,𝑠ℎ𝑢𝑡𝑑𝑜𝑤𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟,ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠)∣𝑆𝑐𝑒𝑛𝑎𝑟𝑖𝑜1. (66)

Using (60) and (65), we have 𝑛𝑒𝑤𝑜𝑛,off(𝐻𝑒𝑎𝑡𝑖𝑛𝑔𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟⟨𝑆𝑒𝑡1Ref⟩∣𝐿𝑜𝑤𝐸𝑥𝑐𝑒𝑝𝑡𝑖𝑜𝑛𝑠⟨𝑆𝑒𝑡2Ref⟩∣𝐻𝑖𝑔ℎ𝐸𝑥𝑐𝑒𝑝𝑡𝑖𝑜𝑛𝑠⟨𝑆𝑒𝑡3Ref⟩)∣(⋅𝑠𝑡𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠1)𝑖𝑉𝑜𝑙𝑡⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠2)⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠3)). (67)

Replacing the definitions of the HeatingSystem subcapsules, we obtain 𝑛𝑒𝑤𝑜𝑛,off(((𝑜𝑛+𝑠𝑡𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟)⋅𝐿𝑒𝑣𝑒𝑙2⟨𝑆𝑒𝑡1Ref⟩+𝜏⋅𝑆ℎ𝑢𝑡𝑑𝑜𝑤𝑛⟨𝑆𝑒𝑡1Ref⟩)∣((𝐾𝐿15𝑐𝑜𝑙𝑑+𝑖𝑉𝑜𝑙𝑡)⋅off⋅Off𝐿𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡2Ref⟩)∣(𝐾𝐿15𝑟𝑎𝑑𝑖𝑜⋅𝑜𝑛⋅𝑂𝑘𝑎𝑦𝐻𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡3Ref⟩)∣(⋅𝑠𝑡𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠1)𝑖𝑉𝑜𝑙𝑡⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠2)⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠3))). (68)

After the reaction between 𝑠𝑡𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟 and startController, we have 𝑛𝑒𝑤𝑜𝑛,off(𝐿𝑒𝑣𝑒𝑙2⟨𝑆𝑒𝑡1Ref⟩∣((𝐾𝐿15𝑐𝑜𝑙𝑑+𝑖𝑉𝑜𝑙𝑡)⋅off⋅Off𝐿𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡2Ref⟩)∣(𝐾𝐿15𝑟𝑎𝑑𝑖𝑜⋅𝑜𝑛⋅𝑂𝑘𝑎𝑦𝐻𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡3Ref⟩)∣(ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠1)⋅𝑖𝑉𝑜𝑙𝑡⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠2)⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠3))). (69)

Replacing the definition of Level2 ⟨𝑆𝑒𝑡1Ref⟩, we obtain 𝑛𝑒𝑤𝑜𝑛,off((ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠⟨𝐿2⟩⋅((off+𝑠ℎ𝑢𝑡𝑑𝑜𝑤𝑛𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟)⋅𝑆ℎ𝑢𝑡𝑑𝑜𝑤𝑛⟨𝑆𝑒𝑡1Ref⟩+𝜏⋅𝐿𝑒𝑣𝑒𝑙1⟨𝑆𝑒𝑡1Ref⟩))∣((𝐾𝐿15𝑐𝑜𝑙𝑑+𝑖𝑉𝑜𝑙𝑡)⋅off⋅Off𝐿𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡2Ref⟩)∣(𝐾𝐿15𝑟𝑎𝑑𝑖𝑜⋅𝑜𝑛⋅𝑂𝑘𝑎𝑦𝐻𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡3Ref⟩)∣(ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠1)⋅𝑖𝑉𝑜𝑙𝑡⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠2)⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠3))). (70)

After the reaction between ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠⟨𝐿2⟩ and heatingStatus(𝑠1), the name 𝑠1 receives the message “𝐿2” as required in the scenario specification. So, 𝑛𝑒𝑤𝑜𝑛,off(((off+𝑠ℎ𝑢𝑡𝑑𝑜𝑤𝑛𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟)⋅𝑆ℎ𝑢𝑡𝑑𝑜𝑤𝑛⟨𝑆𝑒𝑡1Ref⟩+𝜏⋅𝐿𝑒𝑣𝑒𝑙1⟨𝑆𝑒𝑡1Ref⟩)∣((𝐾𝐿15𝑐𝑜𝑙𝑑+𝑖𝑉𝑜𝑙𝑡)⋅off⋅Off𝐿𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡2Ref⟩)∣(𝐾𝐿15𝑟𝑎𝑑𝑖𝑜⋅𝑜𝑛⋅𝑂𝑘𝑎𝑦𝐻𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡3Ref⟩)∣(𝑖𝑉𝑜𝑙𝑡⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠2)⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠3))). (71)

After the reaction between 𝑖𝑉𝑜𝑙𝑡 and iVolt, we have 𝑛𝑒𝑤𝑜𝑛,off(((off+𝑠ℎ𝑢𝑡𝑑𝑜𝑤𝑛𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟)⋅𝑆ℎ𝑢𝑡𝑑𝑜𝑤𝑛⟨𝑆𝑒𝑡1Ref⟩+𝜏⋅𝐿𝑒𝑣𝑒𝑙1⟨𝑆𝑒𝑡1Ref⟩)∣(off⋅Off𝐿𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡2Ref⟩)∣(𝐾𝐿15𝑟𝑎𝑑𝑖𝑜⋅𝑜𝑛⋅𝑂𝑘𝑎𝑦𝐻𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡3Ref⟩)∣(ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠2)⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠3))). (72)

After the reaction between off and off, we obtain 𝑛𝑒𝑤𝑜𝑛,off(𝑆ℎ𝑢𝑡𝑑𝑜𝑤𝑛⟨𝑆𝑒𝑡1Ref⟩∣Off𝐿𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡2Ref⟩∣(𝐾𝐿15𝑟𝑎𝑑𝑖𝑜⋅𝑜𝑛⋅𝑂𝑘𝑎𝑦𝐻𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡3Ref⟩)∣(ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠2)⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠3))). (73)

Replacing the definition of Shutdown and OffLPrio, we have 𝑛𝑒𝑤𝑜𝑛,off((ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠⟨𝐵𝐴𝐷⟩⋅((𝑜𝑛+𝑠𝑡𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟)⋅𝐿𝑒𝑣𝑒𝑙1⟨𝑆𝑒𝑡1Ref⟩))∣(𝜏⋅𝑜𝑛⋅𝑂𝑘𝑎𝑦𝐿𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡2Ref⟩)∣(𝐾𝐿15𝑟𝑎𝑑𝑖𝑜⋅𝑜𝑛⋅𝑂𝑘𝑎𝑦𝐻𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡3Ref⟩)∣(ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠2)⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠3))). (74)

After the reaction between ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠⟨𝐵𝐴𝐷⟩ and heatingStatus(𝑠2), the name 𝑠2 receives the message “BAD” as required in the scenario specification. So, 𝑛𝑒𝑤𝑜𝑛,off(((𝑜𝑛+𝑠𝑡𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟)⋅𝐿𝑒𝑣𝑒𝑙1⟨𝑆𝑒𝑡1Ref⟩)∣(𝜏⋅𝑜𝑛⋅𝑂𝑘𝑎𝑦𝐿𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡2Ref⟩)∣(𝐾𝐿15𝑟𝑎𝑑𝑖𝑜⋅𝑜𝑛⋅𝑂𝑘𝑎𝑦𝐻𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡3Ref⟩)∣ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠3)). (75)

After the 𝜏 reaction that represents the 10 seconds after the low exception, we obtain 𝑛𝑒𝑤𝑜𝑛,off(((𝑜𝑛+𝑠𝑡𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟)⋅𝐿𝑒𝑣𝑒𝑙1⟨𝑆𝑒𝑡1Ref⟩)∣(𝑜𝑛⋅𝑂𝑘𝑎𝑦𝐿𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡2Ref⟩)∣(𝐾𝐿15𝑟𝑎𝑑𝑖𝑜⋅𝑜𝑛⋅𝑂𝑘𝑎𝑦𝐻𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡3Ref⟩)∣ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠3)). (76)

After the reaction between 𝑜𝑛 and on, we have 𝑛𝑒𝑤𝑜𝑛,off(𝐿𝑒𝑣𝑒𝑙1⟨𝑆𝑒𝑡1Ref⟩∣𝑂𝑘𝑎𝑦𝐿𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡2Ref⟩∣(𝐾𝐿15𝑟𝑎𝑑𝑖𝑜⋅𝑜𝑛⋅𝑂𝑘𝑎𝑦𝐻𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡3Ref⟩)∣ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠3)). (77)

Replacing the definition of OkayLPrio, we obtain 𝑛𝑒𝑤𝑜𝑛,off((ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠⟨𝐿1⟩⋅(off+𝑠ℎ𝑢𝑡𝑑𝑜𝑤𝑛𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟)⋅𝑠ℎ𝑢𝑡𝑑𝑜𝑤𝑛⟨𝑆𝑒𝑡1Ref⟩))∣𝑂𝑘𝑎𝑦𝐿𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡2Ref⟩∣(𝐾𝐿15𝑟𝑎𝑑𝑖𝑜⋅𝑜𝑛⋅𝑂𝑘𝑎𝑦𝐻𝑃𝑟𝑖𝑜⟨𝑆𝑒𝑡3Ref⟩)∣ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠3)). (78)

Now there is the possibility of the reaction between ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠⟨𝐿1⟩ and heatingStatus(𝑠3), then the name 𝑠3 receives the message “𝐿1”. Note that the heating system is in level1, which is an active status, so the requirement R5 is satisfied. Otherwise, the requirement R6 is not met, because the heating system was at level2 before the low exception and now it is at level1, when it should continue in level2. In this example, the designer can uncover the error in the model analyzing the state diagrams; however in a more complex system, the visual analysis is very difficult, so the formal analysis is necessary.

Aiming to verify the requirement R7, we propose a scenario composed by the following steps: the ignition key is in status radio, an external event initiates the controller and, later, the ignition key is in status off. The scenario is specified as 𝑆𝑐𝑒𝑛𝑎𝑟𝑖𝑜2=𝐾𝐿15𝑟𝑎𝑑𝑖𝑜⋅⋅𝑠𝑡𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠1)𝐾𝐿15off⋅ℎ𝑒𝑎𝑡𝑖𝑛𝑔𝑆𝑡𝑎𝑡𝑢𝑠(𝑠2). (79)

After the 𝑠𝑡𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟 event, it is expected to be informed that the system is at the level2, so 𝑠1 will receive “𝐿2”. After the 𝐾𝐿15off event, it is expected to be informed that the system is shutdown, so 𝑠2 will receive “BAD”. Analyzing this scenario, we note that, after receiving the event 𝑠𝑡𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟, the HighExceptions capsule sends the event 𝑜𝑛 to initiate the heating controller. So, a component to manage exceptions can initiate the controller for the first time, before it has been initiated by the external event 𝑠𝑡𝑎𝑟𝑡𝐶𝑜𝑛𝑡𝑟𝑜𝑙𝑙𝑒𝑟. In this case, we obtain an unexpected behavior according to the proposed scenario; however we are not sure if it is an error in the model or a missing requirement specification.

Then, using the system specification in the 𝜋-calculus and the scenarios or properties proposed according to the system requirements, it is possible to analyze the interaction between the system components and find out the undesirable behavior due to errors in modeling or and a lack of specification.

4.3. Handover Protocol

In this section, we show the example of mobile processes called Handover Protocol presented by Milner in [24]. The Handover system (Figure 13) is composed by a control tower (Control capsule), two communicating towers (Trans capsules: trans1 and trans2), and a car (capsule Car). For a better visualization of Figure 13, the protocol type of each port is omitted. The control tower has fixed connections with the communicating towers; it is expressed through the wired ports between the capsule Control and the two capsules Trans. The car communicates with a Trans tower, but an event can make it communicates with the other Trans.

Figure 13 

The structure diagram of the capsule Handover.

The state diagrams of the capsules Car, Trans, and Control are presented in Figure 14. The state diagram of the top level capsule Handover is not shown; however it is composed only by the initial transition and an initial state called 𝑆1. The UML-RT specifications for the transitions of all capsules are available in Table 7.

Table 7 

Transitions in the capsule Handover and its subcapsules.

(a)

(b)

(c)

Figure 14 

The state diagrams of the capsules: (a) Car, (b) Trans, and (c) Control.

The overall behavior is the following. the transition Initial of the capsule Handover sends two messages talk1 and change1 along the protected setCar. The messages are received by the car in order to make the initial configuration of its unwired ports talk and change. On the other hand, when control initializes, it sends to trans1 the messages talk1 and change1 that are used by trans1 to configure the unwired ports talk and change. At this moment, the car is able to communicate to trans1 by sending a message through the port talk.

However, control can activate the trans2. In this case, the control sends the messages talk2 and change2 to trans1 (via the port lose1) and to trans2 (via the port gain2). The trans1 receives the messages talk2 and change2, and it sends to the car (via the port change). So, the car uses the messages to reconfigure its unwired ports talk and change. Besides, the trans2 receives the messages talk2 and change2 from the control to configure its unwired ports talk and change. At this moment, the car is able to communicate to trans2 by sending a message through the port talk.

The control continues its processing either activating trans1 or activating trans2. It allows the car always to communicate to some tower, that is, trans1 or trans2.

It is desirable to obtain the 𝜋-calculus definition of the Handover system, so it is important to analyze each capsule based on Figure 14 and Table 7in order to apply the mapping rules proposed in Section 3.

Analyzing the capsule Car, in the transition start, it receives the messages t and c in order to make the initial configuration of its unwired ports. After the initial configuration, Car in the state Operating is ready to send the message info to a tower through the port talk. However, Car can also receive from trans1 two messages (t and c) simultaneously along the port change, indicating a new name for the port talk and a new name for the port change, respectively. This is the step that the car reconfigures its ports to start to operate with the other tower. Then, the 𝜋-calculus definition of the capsule Car is written as 𝐶𝑎𝑟(𝑠𝑒𝑡𝐶𝑎𝑟)=𝐶𝑎𝑟_𝐼𝑑𝑙𝑒⟨𝑠𝑒𝑡𝐶𝑎𝑟⟩𝐶𝑎𝑟_𝐼𝑑𝑙𝑒(𝑠𝑒𝑡𝐶𝑎𝑟)=𝑠𝑒𝑡𝐶𝑎𝑟(𝑡,𝑐,𝑠𝑒𝑡𝐶𝑎𝑟)⋅𝐶𝑎𝑟_𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑛𝑔⟨𝑡,𝑐,𝑠𝑒𝑡𝐶𝑎𝑟⟩𝐶𝑎𝑟_𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑛𝑔(𝑡𝑎𝑙𝑘,𝑐ℎ𝑎𝑛𝑔𝑒,𝑠𝑒𝑡𝐶𝑎𝑟)=𝜏⋅𝑡𝑎𝑙𝑘⟨𝑖𝑛𝑓𝑜⟩⋅𝐶𝑎𝑟_𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑛𝑔(𝑡𝑎𝑙𝑘,𝑐ℎ𝑎𝑛𝑔𝑒,𝑠𝑒𝑡𝐶𝑎𝑟)+𝑐ℎ𝑎𝑛𝑔𝑒(𝑡,𝑐)⋅𝐶𝑎𝑟_𝑂𝑝𝑒𝑟𝑎𝑡𝑖𝑛𝑔(𝑡𝑎𝑙𝑘,𝑐ℎ𝑎𝑛𝑔𝑒,𝑠𝑒𝑡𝐶𝑎𝑟). (80)

The tower Trans begins in the state Idle, where it is possible to receive the configuration for its unwired ports talk and change via the transition activate. In the Active state, Trans can receive a message myinfo from Car using the transition communicate. However, Trans can also receive a message from Control with the new names t and c. These names are later sent to Car via the port change and indicate how its unwired ports must be reconfigured. Using the mapping rules, the capsule Trans is defined in the 𝜋-calculus as 𝑇𝑟𝑎𝑛𝑠(𝑔𝑎𝑖𝑛,𝑙𝑜𝑠𝑒)=𝑇𝑟𝑎𝑛𝑠_𝐼𝑑𝑙𝑒⟨𝑔𝑎𝑖𝑛,𝑙𝑜𝑠𝑒⟩𝑇𝑟𝑎𝑛𝑠_𝐼𝑑𝑙𝑒(𝑔𝑎𝑖𝑛,𝑙𝑜𝑠𝑒)=𝑔𝑎𝑖𝑛(𝑡,𝑐)⋅𝑇𝑟𝑎𝑛𝑠_𝐴𝑐𝑡𝑖𝑣𝑒(𝑡,𝑐,𝑔𝑎𝑖𝑛,𝑙𝑜𝑠𝑒)𝑇𝑟𝑎𝑛𝑠_𝐴𝑐𝑡𝑖𝑣𝑒(𝑡𝑎𝑙𝑘,𝑐ℎ𝑎𝑛𝑔𝑒,𝑔𝑎𝑖𝑛,𝑙𝑜𝑠𝑒)=𝑡𝑎𝑙𝑘(𝑚𝑦𝑖𝑛𝑓𝑜)⋅𝑇𝑟𝑎𝑛𝑠_𝐴𝑐𝑡𝑖𝑣𝑒(𝑡𝑎𝑙𝑘,𝑐ℎ𝑎𝑛𝑔𝑒,𝑔𝑎𝑖𝑛,𝑙𝑜𝑠𝑒)+𝑙𝑜𝑠𝑒(𝑡,𝑐)⋅𝑐ℎ𝑎𝑛𝑔𝑒⟨𝑡,𝑐⟩⋅𝑇𝑟𝑎𝑛𝑠_𝐼𝑑𝑙𝑒⟨𝑔𝑎𝑖𝑛,𝑙𝑜𝑠𝑒⟩. (81)

The state diagram of Control initiates (transition Initial) sending the messages talk1 and change1 along the port gain1. In the Control1 state, after a timeout (transition startControl2), Control can send the messages talk2 and change2 through the port lose1, and later through the port gain2. In a similar way, in the Control2 state, after a timeout (transition startControl1), Control can send the messages talk1 and change1 through the port lose2, and later through the port gain1. In this way, the transition startControl2 indicates that trans2 is apt to talk with the car; while the transition startControl1 indicates that trans1 is now ready to talk with the car. Then, the 𝜋-calculus definition of the capsule Control is written as =𝐶𝑜𝑛𝑡𝑟𝑜𝑙(𝑔𝑎𝑖𝑛1,𝑙𝑜𝑠𝑒1,𝑔𝑎𝑖𝑛2,𝑙𝑜𝑠𝑒2)𝑔𝑎𝑖𝑛1⟨𝑡𝑎𝑙𝑘1,𝑐ℎ𝑎𝑛𝑔𝑒1⟩⋅𝐶𝑜𝑛𝑡𝑟𝑜𝑙_𝐶𝑜𝑛𝑡𝑟𝑜𝑙1⟨𝑔𝑎𝑖𝑛1,𝑙𝑜𝑠𝑒1,𝑔𝑎𝑖𝑛2,𝑙𝑜𝑠𝑒2⟩𝐶𝑜𝑛𝑡𝑟𝑜𝑙_𝐶𝑜𝑛𝑡𝑟𝑜𝑙1(𝑔𝑎𝑖𝑛1,𝑙𝑜𝑠𝑒1,𝑔𝑎𝑖𝑛2,𝑙𝑜𝑠𝑒2)=𝜏⋅𝑙𝑜𝑠𝑒1⟨𝑡𝑎𝑙𝑘2,𝑐ℎ𝑎𝑛𝑔𝑒2⟩⋅𝑔𝑎𝑖𝑛2⟨𝑡𝑎𝑙𝑘2,𝑐ℎ𝑎𝑛𝑔𝑒2⟩⋅𝐶𝑜𝑛𝑡𝑟𝑜𝑙_𝐶𝑜𝑛𝑡𝑟𝑜𝑙2⟨𝑔𝑎𝑖𝑛1,𝑙𝑜𝑠𝑒1,𝑔𝑎𝑖𝑛2,𝑙𝑜𝑠𝑒2⟩𝐶𝑜𝑛𝑡𝑟𝑜𝑙_𝐶𝑜𝑛𝑡𝑟𝑜𝑙2(𝑔𝑎𝑖𝑛1,𝑙𝑜𝑠𝑒1,𝑔𝑎𝑖𝑛2,𝑙𝑜𝑠𝑒2)=𝜏⋅𝑙𝑜𝑠𝑒2⟨𝑡𝑎𝑙𝑘1,𝑐ℎ𝑎𝑛𝑔𝑒1⟩⋅𝑔𝑎𝑖𝑛1⟨𝑡𝑎𝑙𝑘1,𝑐ℎ𝑎𝑛𝑔𝑒1⟩⋅𝐶𝑜𝑛𝑡𝑟𝑜𝑙_𝐶𝑜𝑛𝑡𝑟𝑜𝑙2⟨𝑔𝑎𝑖𝑛1,𝑙𝑜𝑠𝑒1,𝑔𝑎𝑖𝑛2,𝑙𝑜𝑠𝑒2⟩. (82)

Finally, the Handover system is defined in the 𝜋-calculus as the parallel composition of the definition of its state diagram and its structure diagram definition. The state diagram definition is the possibility to send the messages talk1 and change1 along the port setCar. The structure diagram definition includes a reference to each subcapsule definition. So, the Handover definition is written as ∣𝐻𝑎𝑛𝑑𝑜𝑣𝑒𝑟()=𝑛𝑒𝑤(𝑠𝑒𝑡𝐶𝑎𝑟,𝑧𝑔𝑎𝑖𝑛1,𝑧𝑙𝑜𝑠𝑒1,𝑧𝑔𝑎𝑖𝑛2,𝑧𝑙𝑜𝑠𝑒2)(𝐶𝑎𝑟⟨𝑠𝑒𝑡𝐶𝑎𝑟⟩∣𝑇𝑟𝑎𝑛𝑠⟨𝑧𝑔𝑎𝑖𝑛1,𝑧𝑙𝑜𝑠𝑒1⟩∣𝑇𝑟𝑎𝑛𝑠⟨𝑧𝑔𝑎𝑖𝑛2,𝑧𝑙𝑜𝑠𝑒2⟩∣𝐶𝑜𝑛𝑡𝑟𝑜𝑙⟨𝑧𝑔𝑎𝑖𝑛1,𝑧𝑙𝑜𝑠𝑒1,𝑧𝑔𝑎𝑖𝑛2,𝑧𝑙𝑜𝑠𝑒2⟩𝑠𝑒𝑡𝐶𝑎𝑟⟨𝑡𝑎𝑙𝑘1,𝑐ℎ𝑎𝑛𝑔𝑒1⟩). (83)

It is important to understand each term in the parallel composition shown in (83). The first term represents the subcapsule car (instance of Car). The second and the third terms represent the subcapsules trans1 and trans2 (instance of Trans), respectively. The fourth term indicates the subcapsule control (instance of Control). The last term is the definition of the Handover state diagram. Besides, the names setCar, zgain1, zlose1, zgain2, zlose2 are used to represent the wired connections between the subcapsules in the 𝜋-calculus definitions. For example, the name zgain1 allows the communication between the port gain1 of control and the port gain of trans1, because the subcapsule’s ports are renamed to the same name zgain1.

The Handover system is an example of mobile processes, where the messages received by a process in a communication can be used to rename its ports and, consequently, to allow the reconfiguration of its connections with other processes. Besides, the present example includes the need of the communication of more than one message at a time between processes, which emphasizes the importance of the polyadic 𝜋-calculus approach.

5. Comments and Conclusions

We propose a formal semantics to the UML-RT communicating elements through the mapping from the UML-RT to the polyadic 𝜋-calculus. The UML-RT is a UML profile widely used for the real-time system modeling, and the 𝜋-calculus is one of the main formalisms of the concurrent systems modeling. The proposed mapping from the UML-RT to the 𝜋-calculus is a practical approach of 𝜋-calculus, and it enables the use of formal methods during system development.

We described three examples. In the first example, we explained how to obtain the 𝜋-calculus definition of a UML-RT model using the proposed mapping rules. In the second example, we illustrated the possibility to formally verify system requirements using the 𝜋-calculus definitions of the model and some scenarios specified from the requirements. During the verification process, we showed that we can uncover some undesirable behavior, which are consequences of a poor system specification or an error introduced during the modeling phase. Finally, in the third example, we present the Handover protocol. This example demonstrates the importance of the reconfiguration of the connections between processes and the need of modeling of communication of more than one message at a time, which is well addressed using the polyadic 𝜋-calculus.

A real-time system designer who desires to formally reason about a UML-RT model can apply the proposed mapping rules on the UML-RT model to obtain the corresponding 𝜋-calculus definitions. Afterwards, the designer can manipulate the 𝜋-calculus definitions to explore possible execution paths and find situations that can cause functional problems or inconsistencies with functional requirements. Problems and inconsistencies include deadlock and nonsatisfaction of safety properties. This practice increases the confidence in the system development, because it anticipates the detection of problems in the modeling phase.

Two main contributions of the mapping proposed in this paper are due to polyadic 𝜋-calculus mobility, which is provided by name reconfiguration. The first contribution is the reuse of the capsule definition. For example, if a parent capsule has three instances of the same subcapsule, it is necessary to write one definition in the 𝜋-calculus for the subcapsule, and this definition is referenced three times by the parent capsule. It helps to reduce the number of the 𝜋-calculus definitions for the system. The second contribution of the name reconfiguration is the ability to represent the dynamic configuration of the unwired ports. It is important because a UML-RT capsule can rename an unwired port during its state diagram execution, as it is shown in the first example.

Other contributions include the option for the polyadic 𝜋-calculus, which represents the communication of more than one message at a time. Besides, the proposed mapping deals with the following UML-RT concepts not yet addressed: the entry and the exit actions of a state, the composite states, and the transition chains.

In order to test the consistency of the mapping rules, we used the mapping to obtain π-calculus models of other UML models, besides the examples presented in this work. For instance, we have used the mapping on a system composed by a pair of semaphores to prove that two green lights of both semaphores cannot occur at the same time.

Future research directions include the improvement of the mapping rules to represent other UML-RT elements, such as history junction points, the guard conditions, and the capsule cardinalities. An interesting topic to investigate is to capture, from the UML-RT sequence diagram, the 𝜋-calculus definitions of the desirable scenarios to be met by the system under design. Another research issue is the study of formal approaches to represent the UML-RT timeouts, in order to be able to verify the time constraints of the modeled system.