A formal component model for UML based on CSP aiming at compositional verification

Abstract

Model-based engineering emerged as an approach to tackle the complexity of current system development. In particular, compositional strategies assume that systems can be built from reusable and loosely coupled units. However, it is still a challenge to ensure that desired properties hold for component integration. We present a component-based model for UML, including a metamodel, well-formedness conditions and formal semantics via translation into BRIC; the presentation of the semantics is given by a set of rules that cover all the metamodel elements and map them to their respective BRIC denotations. We use our previous work on BRIC as an underlying (and totally hidden) component development framework so that our approach benefits from all the formal infrastructure developed for BRIC using CSP. Component composition, specified via UML structural diagrams, ensures adherence to classical concurrent properties: our focus is on the preservation of deadlock freedom. Automated support is developed as a plug-in to the Astah modelling tool. Verification is carried out using FDR (a model checker for CSP); we address scalability using compositional reasoning (inherent to the approach) and behavioural patterns. The formal reasoning is transparent to the user: a distinguishing feature of our approach is its support for traceability. For instance, when FDR uncovers a deadlock, a sequence diagram is constructed from the deadlock trace and presented to the user at the modelling level. The overall approach is illustrated with a running example and two additional case studies.

Appendices

Well-formedness conditions

In this appendix, we present all the remaining constraints that represent well-formedness conditions in our component metamodel.

Component Instance It is an individual element with its own internal state. Each component instance must be bounded to a type: Basic Component or Hierarchical Component. Component instances are represented by the UML part element in the EncapsuledClassifier of a hierarchical component, Constraint 4. Figure 9 illustrates two instances of the Fork component and two of the Phil component.

Multiplicities. Multiplicities with the * character are not allowed in the composite structure diagram because we are dealing with a bounded number of instances. This is important to make the formal analysis feasible, Constraint 5.

Ports. A port allows communication between component instances. Each port must realise one interface; components do not realise interfaces directly, Constraint 1, invariant RealisedPort. An interface can be realised as a provided or required interface. A connection is established between two compatible component ports, that is, ports that realise the same interface: one in a required mode and the other one in a provided mode, Constraint 6. We distinguish ports according to the components they belong to. BasicComponent ports are connected at most to another component port. On the other hand, a port from a HierarchicalComponent is connected at most to two other ports, one to a port of an inner component instance, and another to a port of an external component instance, Constraint 7.

Component Services. The contract of a component must be modelled using ports. Each component must have ports exposing the required and provided services. Then, ports describe the operations that a component needs or performs, Constraint 8.

Operations. Components can execute operations that are defined in interfaces that are realised by their ports. An operation can be asynchronous or synchronous. We define asynchronous operations as a signal; it is indicated by a stereotype signal in the operation declaration, Constraint 9. In our example, Fig. 8, picksup and putsdown are synchronous operations and do not need an explicit stereotype.

Operation Parameter. The parameter modes determine the behaviours of parameter passing. If an operation has parameters, its parameter modes have to be defined either as in (input) or as out (output), Constraint 10.

Port Multiplicity. If there is a connector between two ports where at least one of them has a multiplicity greater than one, the connector must be labelled to indicate the port being connected. The label must follow the pattern port1_name[j]$\leftrightarrow$port2_name[i], where port1_name and port2_name are the name of ports; j and i are the indices of the port of the connection, Constraint 12.

Additional semantic rules

In this appendix, we present all the remaining rules, in addition to those presented in Sect. 4.2, that are necessary for the generation of the complete BRIC semantics from a model that complies with the metamodel in Fig. 4.

We use required_provided_interface(p) as an auxiliary function to return all interfaces that are realised by port p. The symbol stands for power set.

As already explained, its purpose is to control the access to attributes and internal events of the component. The process for the component memory records local variables (attributes of the component). These variables/attributes are captured by the function . The function yields unique identifiers for variables formed of component name and attribute name. This function, , is used to define set and get channels.

By we denote the list of variables with the name replaced with the value , when the set event is communicated.

Guarded transitions in the process resulting from the semantic definition of a state machine (Rule 5) are also controlled by events of the memory process. This mechanism allows the atomicity for checking a guard that uses attributes of the component, thus, avoiding changes in the value of attributes while a guard is being evaluated.

The guards are translated by the function , Rule 12. Each iteration of the for each construct generates a process that captures the behaviour of a transition. The sep clause with the external choice operator () means that each pair of such processes is combined by external choice.

For each transition from the state machine, Rule 12 verifies if there is a guard and if there is a trigger. When both exist, a Boolean expression is formed of the semantics of a guard, ; then a trigger, , is available, and it is indexed by a number that identifies this statement as unique. This identifier is given by the function . Otherwise, if there is no trigger, an expression is formed of the semantics of the guard, as a prefix and an internal event that is indexed by the result from . This memory process enables or disables a particular event internal.x, where x comes from , depending on whether the guard for the transition with identifier x holds or not. This allows the synchronisation with the process that represents the state machine. Since the synchronisation involves the trigger channel that can be constrained by different guards in other transitions, the unique identification avoids ambiguity. On the other hand, when a transition includes only a guard, this guard is associated to a channel named internal and, in a similar way to guards and triggers, it has an identifier given by .

As the Dining Philosopher example does not have attributes, we illustrate Rule 12 with the memory process of the Control component from the Ring Buffer case study presented in Sect. 5.1. It is parameterised by id and the other component attributes. We present a fragment of this process. The $get\_size.id!size$ event communicates the current value of the attribute size for this instance identified by id, after which the process recurses preserving the values of all attributes in the memory. The event set_size.id?vl receives the new value (vl) of the size attribute so that the memory is updated with this value in the subsequent recursive call. Events get e set for the other attributes are similar. When the attribute size is greater than zero and the event $port\_env.id.retrieve\_data\_I$ is performed, and when the size is equal to one, and the event internal.3 is engaged, the memory process is called recursively preserving all attributes.

We consider only simple states. Therefore, in the definition of each transition from the source state is evaluated using ; the transitions are composed in external choice.

The semantics of a transition, Rule 14, is given by the evaluation of str_transition that is formed of the translation of guards, trigger and action of a transition; it behaves as a process that has the name of the target state of the transition and is parameterised by the component identifier. The auxiliary function yields a number that indexes the transition. Note that, in Rule 14, if an action is not present, then the process str_action behaves like SKIP. The process str_trigger_action captures the semantics of a trigger, if it exists, and then behaves as the process that captures the behaviour of str_action. Finally, str_transition behaves as str_trigger_action, but preceded by an internal event that represents the guard evaluation, if there is a guard and no trigger. This internal event synchronises the memory the event described in Rule 12.

This process is defined by STM_c.name(id) composed in parallel with memory_c.name(id, ) where returns the default values of the attributes. The synchronisation set provided by the function includes get and set channels and internal events. In order to keep only the channels that represent ports visible to other components, channels as get, set and internal channels are hidden; this set is obtained by the function .

In the Dining Philosophers example, neither Fork nor Phil components have attributes. Therefore, there is no need for a memory to record state information. They are represented only by their state machine processes.

$$\begin{aligned} FORK(id) = STM\_Fork(id) \\ PHIL(id) = STM\_Phil(id) \end{aligned}$$

The ports from a HierarchicalComponent are described as a process yielded by the function portProcess, Rule 16, that relays the communication according to its direction.

The buffer in Rule 17 copies information from its input channel (ci) to its output channel (co), without loss or ordering. In our example, the BFIO process has as arguments the channels that represent the ports of this particular connection. That is, channels $port\_fork\_right.2$ (i.port[1]) and $port\_phil\_left.1$ (i.port[1]) form the synchronisation set for connection 1.

In a similar way, other connections can be established between instances. For example, a connection 2 between fork1 and phil1 produces CON(2) that is given by parallel composition of CON(1) and a buffer, synchronising on $port\_fork\_left.1$ and $port\_phil\_right.1$.

The intermediary buffer maps outputs from an instance of FORK into inputs to an instance of PHIL, and vice versa. These internal buffers perform asynchronous bidirectional communication, which conveys information in both directions, Rule 18.

Theoretical foundation for protocol implementation

Here, we present the theoretical basis for the protocol implementation. First, we detail three CSP semantic models. Next, we explain LTS and weak bisimulation. Finally, we present the definitions for protocol implementation.

1.1 CSP semantic models

A process in CSP can be understood in terms of several semantic models.

The Traces Model denotes a CSP process according to its traces, which are defined as the set of sequences of events in which the process may engage.

In the Traces Model for CSP, a process P is a trace refinement of a process Q (written as ) if, and only if, Q contains all traces within P: $traces(P) \subseteq traces(Q)$. These processes are trace equivalent if refinement holds in both directions. This model it is confined to express safety properties.

The Stable Failures Model gives more information about processes. For instance, it allows distinguishing between internal and external choice. It also allows one to detect deadlocked processes. A failure of a process is a pair (s, X) that describes a set of events X which a process can fail to accept after performing the trace s; and X is a refusal set. The stable in this model means that the sequences represented by s are those that reach a stable state where no internal transition ($\tau$) is possible.

A process P is a stable failures refinement of process Q (written as ) if, and only if, Q contains all traces within P, and P presents a subset of the stable failures of Q: and $failures(P) \subseteq failures(Q))$. Again, equality means refinement in both directions.

The Failures/Divergence Model allows one to detect not only deadlocked but also livelocked (divergent) processes.

In the Failures/Divergence Model, the processes are represented by two sets of behaviours: the failures and the divergences. We say that a process is divergent if it has at least one infinite sequence of internal events. Each process P is modelled by the pair: , where is the set of traces s after which a process can diverge, and represents all the stable failures of P extended by all the pairs (s, X) for and $X \subseteq \Sigma$, allowing the process to refuse anything after diverging.

Similar to the previous models, a process P is a refinement of a process Q (written as if, and only if: and . These processes are failures/divergences equivalent if refinement holds in both directions.

1.2 LTS and weak bisimulation

In this section, we define the concepts of a LTS and Weak Bisimulation, which are essential to understand the protocol implementation of BRIC contracts described in Sect. 4.3.1.

The operational semantics of a CSP process is given by labelled transition system (LTS).

A LTS, Definition 3, is a directed graph with a label on each edge representing what happens when we take the action which the edge represents. Most LTSs have a distinguished node $q_0$ that is the one we are assumed to start from [11].

Definition 3

(LTS) A labelled transition system is a 4-tuple $\langle Q, A \cup \{\tau \},T,q_0 \rangle$ where Q is a set of states; A is a set of labels and $\tau$ is an internal action, and $\tau \notin A$; T is the transition relation, which satisfies $T \subseteq Q \times (A \cup \{\tau \}) \times Q$; and $q_0 \in Q$ is the initial state.

The FDR model checker interprets a process by expanding it into a finite LTS.

There are many bisimulation relations for process algebras that are used to characterise equivalences between nodes of LTSs and used to calculate the reduction of LTS states that represent equivalent processes [47].

Two states in a LTS are bisimulation equivalent if they can simulate each other’s transitions.

A weak bisimulation is a relation in which chains of $\tau$ actions are compressed into a singular $\tau$, and chains of $\tau$ actions before and after a visible action $\alpha$ are absorbed into $\alpha$, as explained in Definition 4 [47].

Definition 4

(Weak Bisimulation) For a LTS $\langle Q,A \cup \{\tau \},T,$$q_0 \rangle$, where $\tau \notin A$, a weak bisimulation is a relation $R \subseteq (Q \times Q)$ such that if $(q_1, q_2) \in R$ then for all $\alpha \in A$

• $\forall q'_1$ such that , $\exists q'_2$ such that and $(q'_1, q'_2) \in R$,

• $\forall q'_2$ such that , $\exists q'_1$ such that and $(q'_1, q'_2) \in R$.

where if $\alpha \ne \tau$, then means that from s one can get to t by doing zero or more $\tau$ actions, followed by the action $\alpha$, followed by zero or more $\tau$ actions. On the other hand, if $\alpha = \tau$, then means that from s one can reach t by doing zero or more $\tau$ actions.

1.3 Protocol implementation

Protocols can represent the entire observable behaviour of the component, or the behaviour associated to an interaction point of the component; this observable behaviour is defined as a projection over a set of channels. Projections restrict the behaviour of a process to a set of events. This restriction, however, might introduce divergence in the protocol implementation, which must be avoided.

Communication protocols are commonly associated to specifications of component behaviours at a specific abstraction level, with an exclusive focus on a portion of the communicated events. They are used in local analyses of component interaction before their composition.

Definition 5

(Projection). Let P be a process, and C a set of communication channels. The projection of P over C (denoted by ) is defined as:

Projections restrict the behaviour of a process to a set of events. It behaves as the hiding of all events, except those in C. This restriction, however, might introduce divergence in the protocol implementation, which must be avoided.

Definition 6

(Protocol implementation). Let P be an I/O process, and C a set of communication channels. The communication protocol, named ProtIMP(P, C) and implemented by P over C, is a protocol that satisfies the following properties;

and

ProtIMP(P, C) is a process that is related, via refinement, to . However, the former cannot have divergences. When projecting a process into a set of channels, divergence might be introduced, due to the use of the hiding operator. Thus, may diverge. In place of the divergences of , ProtIMP(P, C) is allowed to exhibit stable failures, as explained in the failure model. Hence, ProtIMP(P, C) may have more failures than (first refinement statement of Definition 6). Moreover, as ProtIMP(P, C) cannot diverge, then, it has less or equal divergences than , and the same set concerning (unstable failures). That is the reason we need the second refinement of Definition 6.

One of the important contributions of this paper is that, rather than asking the user to propose a valid protocol implementation from a projection over a set of channels, we constructively derive ProtIMP(P, C) from .

To illustrate why simply projecting a process over a set of channels can lead to divergent behaviour, consider in this way, a protocol implementation for the fork1 process over the channel $fork\_right.1$ is given by:

By expanding this process, we have the following result, where all events will be hidden, except the ones related to channel $fork\_right.1$.

In this case, the projection is directly obtained by hiding the relevant events, but the resulting process has the following livelock sequence: $STM\_ FORK(1)$; Available(1); Busy2(1); Available(1). Thus, this process cannot be used as a valid protocol implementation.

In the same way, if we project fork1 over the channel $fork\_left.1$, this also results in a divergent behaviour. However, by excluding such divergence sequences from both projections, results in the process $PROT\_FORK(ch)$ that represents the protocol related to each channel ch from component FORK, and it is divergence free. This process is given by: