Efficient Operational Semantics for \( EB ^3\) for Verification of Temporal Properties

Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 8161)


\( EB ^3\) is a specification language for information systems. The core of the \( EB ^3\) language consists of process algebraic specifications describing the behaviour of the entity types in a system, and attribute function definitions describing the entity attribute types. The verification of \( EB ^3\) specifications against temporal properties is of great interest to users of \( EB ^3\). We give here an operational semantics for \( EB ^3\) programs in which attribute functions are computed during program evolution and their values are stored into program memory. By assuming that all entities have finite domains, this gives a finitary operational semantics. We then demonstrate how this new semantics facilitates the translation of \( EB ^3\) specifications to LOTOS NT (LNT for short) for verification of temporal properties with the use of the CADP toolbox.


Information Systems \( EB ^3\) Process Algebras Operational Semantics Bisimulation Verification Model Checking. 

1 Introduction

The \( EB ^3\) [10] method is an event-based paradigm for information systems (ISs) [17]. A typical \( EB ^3\) specification defines entities, associations, and their respective attributes. The process algebraic nature of \( EB ^3\) permits the explicit definition of intra-entity constraints. Yet its specificity against common state-space specifications, such as the B method [1] and Z, lies in the use of attribute functions, a special kind of recursive functions on the system trace, which combined with guards, facilitate the definition of complex inter-entity constraints involving the history of events. The use of attribute functions is claimed to simplify system understanding, enhance code modularity and streamline maintenance.

In this paper, we present part of our work regarding the verification of \( EB ^3\), i.e. the detection of errors inherent in \( EB ^3\) specifications. Specification errors in \( EB ^3\) can be detected with the aid of static properties also known as invariants or dynamic properties known as temporal properties. From a state-based point of view, an invariant describes a property on state variables that must be preserved by each transition or event. A temporal property relates several events. Tools such as Atelier B [7] provide methodologies on how to define and prove invariants. In [12], an automatic translation of \( EB ^3\)’s attribute functions into B is attempted. Although the B Method [1] is suitable for specifying static properties, temporal properties are very difficult to express and verify in B. Hence, in our attempt to verify temporal properties of \( EB ^3\) specifications we move our attention to model-checking techniques.

The verification of \( EB ^3\) specifications against temporal properties with the use of model checking has been the subject of some work in the recent years. [9] compares six model checkers for the verification of IS case studies. The specifications used in [9] derive from specific industrial case studies, but the prospect of a uniform translation from \( EB ^3\) program specifications is not studied. [6] casts an IS specification into LOTOS NT (LNT for short) [5] that serves as an input language to the verification suite CADP [11]. In short, the majority of these works treat specific case studies drawn from the information systems domain leading to ad-hoc verification translations, but nonetheless lacking in generalization capability.

But the main problem in verifying \( EB ^3\) specifications against temporal-logic properties relies in the difficulty to handle the recursive definition of attribute functions if one relies on the classical, trace-based semantics. This type of semantics necessitates an unbounded memory model, and therefore only bounded model-checking can be achieved, in the absence of good abstractions that allow constructing finite-state models. This restriction is present in the original approach [10] and the subsequent model-checking attempt [9] even if all the entities utilized in the specification are finite.

We propose a formal semantics for \( EB ^3\) that treats attribute functions as state variables (we call these variables attribute variables). This semantics will serve as the basis for applying a simulation strategy of state variables in LNT. Intuitively, coding attribute functions as part of the system state is beneficial from a model-checking point of view as the new formalisation dispenses with the system trace. Our main contribution is an operational semantics in which attribute functions are computed during program evolution and stored into program memory. We show that this operational semantics is bisimilar with the original, trace-based operational semantics.

Furthermore, we explore the implications of this result to the translation of \( EB ^3\) specifications into LNT. LNT is a process algebra specification that derived from LOTOS [4]. As a process algebra, it shares many common features with \( EB ^3\) and it is one of the input languages of CADP, a toolbox with state-of-the-art verification features. CADP permits the verification of system specifications against action-based temporal properties.

Translating \( EB ^3\) specifications to LNT is not evident. The fundamental difficulties for designing a compiler from \( EB ^3\) into LNT are summarized in [6]. In particular, LNT does not feature global variables. Accesses to local variables is restricted in parallel processes of the form “\(\mathbf{par } \ proc_1 \ \mathbf{|| }\ proc_2 \ \mathbf{end }\ \mathbf{par }\)”, so that every variable written in \( proc_1 \) cannot be accessed in \( proc_2 \). Although, \( EB ^3\) programmers cannot define global variables explicitly, \( EB ^3\) permits the use of a single state variable, the system trace, in predicates of guard statements. Attribute functions can express the evolution of entity attributes in time, option which introduces an indirect notion of state to the language. As a result, \( EB ^3\) expressions of the form “\( C(T) \Rightarrow E \)” can be written, where \( C(T) \) is a predicate that refers to the system trace (the history of events) and \( E \) is a valid \( EB ^3\) expression.

We then present how \( EB ^3\) specifications can be translated to LNT for verification with CADP through an intuitive example and give some conclusions and lines for future work. The automatic translation of \( EB ^3\) specifications into LNT is studied in the companion paper [18]. We note that the translation of our example into LNT is produced using the tool presented in [18].

2 \( EB ^3\)

The \( EB ^3\) method has been specially designed to specify the functional behaviour of ISs. A standard \( EB ^3\) specification comprises (1) a class diagram representing entity types and associations for the IS being specified, (2) a process algebra specification, denoted by main, describing the IS, i.e. the valid traces of execution describing its behaviour, (3) a set of attribute function definitions, which are recursive functions on the system trace, and (4) input/output rules, to specify outputs for input traces, or SQL used to specify queries on the business model. We limit the presentation to the process algebra and the set of attribute functions used in the IS.

We then give three operational semantics for \( EB ^3\). The first, named Trace Semantics (\( Sem_{T} \)), is the standard semantics defined in [10]. The second, called Trace/Memory Semantics (\( Sem_{T/M} \)), is the alternative semantics, where attribute functions are computed during program evolution and their values are stored into program memory. By removing the trace from each state in \( Sem_{T/M} \), we obtain the third semantics for \( EB ^3\) specifications, which we name Memory Semantics, \( Sem_{M} \). The relevance of the \( Sem_{T/M} \) semantics stems from the fact that it is pivotal in proving the bisimulation between \( Sem_{T} \) and \( Sem_{M} \).
Fig. 1

\( EB ^3\) Specification and Attribute Function Definitions

\(\mathbf{Case \;Study }\). We start by providing a simple case study which serves for introducing both the syntax and the semantics of \( EB ^3\). In Fig. 1, we give the functional requirements of a library management system and the corresponding \( EB ^3\) specification.The library system contains two entity types: \( books \) and \( members \). The process \( main \) is the parallel interleaving between \( m \) instances of process \( book \) and \( p \) instances of processes describing operations on \( members \). To avoid confusion, action names begin with uppercase letters, while process and attribute function names begin with lowercase letters.

The member \( mId \) registers to the library in order to start borrowing books, i.e. the action \( Register(mId) \). By the action \( Unregister(mId) \), (s)he relinquishes membership from the library. The book \( bId \) is acquired by the library so as to become available for lending, i.e. \( Acquire(bId) \). The inverse operation is expressed by the action \( Discard(bId) \). The member \( mId \) borrows the book \( bId \), i.e. \( Lend(bId,mId) \) and returns it to the library after use, i.e. \( Return(bId) \). The process \( book(bId) \) denotes the lifecycle of the \( book \) entity \( bId \) from the moment of its acquisition until its eventual discard from the library. The process \( member(mId) \) denotes the lifecycle of the \( member \) entity \( mId \) from the point of its registration up until its membership drop. In the body of \( member(mId) \), the process expression “\( ||| bId: BID: loan(mId, bId)^* \)” denotes the interleaving of \( m \) instances of the process expression \( loan(mId, bId)^* \) that, according to the standard semantics of the Kleene Closure operator \( (^*) \), denotes the execution of \( loan(mId, bId) \), \( bId=\{b_1,\ldots ,b_m\} \) an arbitrary, but bounded number of times. The attribute function \( borrower(T,bId) \), where \( T \) is the current trace, returns the current borrower of book \( bId \) or \( \bot \) (meaning undefined) if the book is not lent, by looking for actions of the form \( Lend(bId,mId) \) or \( Return(bId) \) in the trace. In process \( book(bId) \), the action \( Discard(bId) \) is thus guarded by \( borrower(T,bId) = \bot \) to guarantee that the book \( bId \) cannot be discarded if it is currently lent.

The use of attribute functions is not adherent to standard process algebra practices as it may naively trigger the complete traversal and inspection of the system trace. Alternatively, one may come up with simpler specifications based solely on process algebra operations (without attribute functions) when the functional requirements imply loose interdependence between entities and associations. For instance, if all books are acquired by the library before any other action occurs and are eventually discarded (given that there are no more demands), \( main \)’s code can be modified in the following manner:
$$\begin{aligned} \begin{array}{ll} main = &{} (\;|||\; bId: \text {BID}:Acquire(bId)\;).\;(\;|||\; mId: \text {MID}: member(mId)^*\;).\\ &{} (\;|||\; bId: \text {BID}:Discard(bId)\;) \end{array} \end{aligned}$$
Note that the functional requirements are not contradicted, though the system’s behaviour changes dramatically. Programming naturally in a purely process-algebraic style without attribute functions in \( EB ^3\) may not always be obvious. In some cases, ordering constraints involving several entities are quite difficult to express without guards and lead to less readable specifications than equivalent guard-oriented solutions in \( EB ^3\) style. For instance in the body of \( loan(mId: MID,bId:BID) \), writing the specification without the use of the guard:
$$\begin{aligned} \begin{array}{ll} borrower(T,\;bId) = \bot \wedge nbLoans(T, mId) < \text {NbLoans} \\ \end{array} \end{aligned}$$
that illustrates the conditions under which a Lend can occur (notably when the book is available and nbLoans is less than the fixed bound NbLoans), is not trivial.

\(\mathbf{Execution }\). As a means to provide the operational intuition behind the three semantics introduced later in this section, we show how the \( EB ^3\) specification above is transformed through a four-step trace, assuming that the library may contain at most two books and at most two members, that is, \( BID=\{b_1,b_2\} \) and \( MID=\{m_1,m_2\} \).

First, we associate with the attribute function \( borrower \) two “memory cells”, \( bor[b_1] \) and \( bor[b_2] \), meant to encode the value computed by the function for each book ID after each trace \( T \). Similarly, we associate two memory cells \( nbL[m_1], nbL[m_2] \) to the attribute function \( nbLoans \). We also set \( NbLoans=2 \) for the constant used in the definition of the process term loan.
Fig. 2

Sample execution

Fig. 3

States for the sample execution

Figure 2 shows how the process term main evolves by executing the valid trace \( T_D= Acq(b_2).Acq(b_1).Reg(m_2).Reg(m_1).Lend(b_1,m_1) \), in which \( Acq \) stands for \( Acquire \) and \( Reg \) for \( Register \), respectively. During this evolution, the two attribute functions are computed according to their specifications in Fig. 2, inductively on the length of the trace. Hence, initially and after the execution of actions \( Acq(b_2).Acq(b_1) \), the two attribute functions are undefined for both their arguments, while after the execution of the sequence of actions \( Reg(m_2).Reg(m_1) \) we have “\( nbLoans(T[C],m_1) = nbLoans(T[C],m_2) = 0 \)” and \( borrower(T,.) \) remains undefined. These values are employed in order to check “\({ borrower}(T,b_1) = \bot \wedge { nbLoans}(T,m_1) < 2\)”, which leads to the possibility for member \( m_1 \) to lend book \( b_1 \), and therefore to transform the process term at (C) in the process term at (D).

On the other hand, the table in Fig. 3 indicates the memory status after each (pair of) actions in the given trace. Initially, all memory cells carry the undefined value. After the trace \( T[C] \), the value of memory cell \( nbL_C[m_1] \) equals \( nbLoans(T[C],m_1) \), and, similarly, “\( nbL_C[m_2] = nbLoans(T[C],m_2) \)”. Note that the constraint checked at step \( C \rightarrow D \) gives the same value regardless of the utilization of the value computed recursively for the attribute functions \( borrower \) and \( nbLoans \), or by using the corresponding memory cells. Furthermore, the execution of action \( Lend(b_1,m_1) \) triggers the update of the memory cell \( bor[b_1] \) to \( m_1 \) and the incrementation of \( nbL[m_1] \) to 1. This is modeled by the application of a function \( next \), which defines the evolution of the system memory, and which is defined as follows: “\( bor_D[b_1]=next(bor_C[b_1]) \) 1= \( m1 \) 2”,“\( bor_D[b_2]=bor_C[b_2]=\bot \)”, “\( nbL_D[m_1]=nbL_C[m_1]+1=1 \)” and also “\( nbL_D[m_2]=0 \)”.

\(\mathbf{EB }^{\mathbf{3 }} \; \mathbf{Syntax } \; \mathbf{and } \; \mathbf{Sem }_{\mathbf{T }}\). We proceed with the formal definition of \( EB ^3\). We define a set of attribute function names \( AtFct=\{f_1,\ldots ,f_n\} \) and a set of process function names \( PFct=\{P_1,\ldots ,P_m\} \). Let \( \rho \in Act \) stand for an action of either form \( \alpha (p_1\!:\!T_1,\ldots ,p_n\!:\!T_n) \), where \( \alpha \in lab \) 3 is the label of the action and \( p_i,\, i \in 1..n \) are elements of type \( T_i \), or \( \lambda \), which stands for the internal action. To simplify the presentation, we assume that all attribute functions \( f_i \) have the same formal parameters \( \overline{x} \). An \( EB ^3\) specification is a set of attribute function definitions \( AtF \) and a set of process definitions \( ListPE \).
Fig. 4

\( EB ^3\) Syntax and \(Sem_{T}\)

\( Sem_T \) [10] is given in Fig. 4 as a set of rules named \( R_T\!-\!1 \) to \( R_T\!-\!11 \). Each state is represented as a tuple \( (E,T) \), where \( E \) stands for an \( EB ^3\) expression and \( T \) for the current trace. An action \(\rho \) is the simplest \( EB ^3\) process, whose semantics are given by rules \( R_T-1,1' \). Note that \(\lambda \) is not visible in the \( EB ^3\) execution trace, i.e., it does not impact the definition of attribute functions. The symbol \( \surd \) denotes successful execution. \( EB ^3\) processes can be combined with classical process algebra operators such as the sequence (\( R_T\!-\!2,3 \)), the choice (\( R_T\!-\!4 \)) and the Kleene Closure (\( R_T\!-\!5,6 \)) operators. Rules (\( R_T\!-\!7,8,9 \)) refer to the parallel composition \( E_1 \arrowvert [ \Delta ] \arrowvert E_2 \) of \( E_1, E_2 \) with synchronization on \( \Delta \!\subseteq \! lab \). The condition \( in(\rho ,\Delta ) \) is true, iff the label of \( \rho \) belongs to \( \Delta \). The symmetric rules for choice and parallel composition have been omitted. Expression \( E_1 ||| E_2 \) is equivalent to \( E_1 \arrowvert [ \emptyset ] \arrowvert E_2 \) and \( E_1 || E_2 \) to \( E_1 \arrowvert [ lab ] \arrowvert E_2 \).

In \(R_T\!-\!10\), the guarded expression process “\(C\,(T)\!\Rightarrow \!E\)” can execute \(E\) if the predicate \(C\,(T)\) holds. The syntax of \( C(T) \) is given below:
$$\begin{aligned} C\,(T)\,{::}\,{=}\,true \ | \ false \ | \ op\,( C\,(T),\ldots , C\,(T)) \ | \ f_i\,(T,\ldots ),\,i\in 1..n,\,op\in \{\wedge , \vee \} \end{aligned}$$
This syntax is simplified in the sense that certain expressions cannot be supported in practice, e.g. “\( nbLoans(T, mId) < NbLoans \)” in Fig. 1. To palliate this, we need to add an attribute function name \( nbLoans\_lt\_NbLoans \) to \( AtFct \) and a corresponding attrribute function definition that implements this inequality. Finally, “\( nbLoans(T, mId) < NbLoans \)” has to be replaced by \( nbLoans\_lt\_ \) \({NbLoans}\) in the \( EB ^3\) specification. Note also that this syntax makes strictly use of those “\( f_i\,(T,\ldots ),\,i\in 1..n \)” with Boolean return-type. Thus, the interpretation function of guarded expressions \( \parallel .\parallel \) is the standard Boolean interpretation.

Quantification is permitted for choice and parallel composition. If \( V \) is a set of attributes \( \{t_1, \dots , t_n\} \), \( \arrowvert x \!:\! V \!:\! E \) and \(\arrowvert [\Delta ] \arrowvert x \!:\! V \!:\! E\) stand respectively for \( E[x\!:=\!t_1] \arrowvert \ldots \arrowvert E[x:=\!t_n] \) and \( E[x\!:=\!t_1] \arrowvert [\Delta ]\arrowvert \ldots \arrowvert [\Delta ]| E[x:=\!t_n] \), where \( E[x:=\!t] \) denotes the replacement of all occurrences of \( x \) by \( t \). For instance, \( || x\!:\!\{1,2,3\}\!:\! \) \({a(x)}\) stands for \( a(1) || a(2) || a(3) \). By convention, \( \arrowvert x \!:\! \emptyset \!:\! E = \arrowvert [\Delta ] \arrowvert x \!:\! \emptyset \!:\! E\!=\surd \).

Attribute functions are defined in \( AtFDef \) 4 in Fig. 4, where \( exp_i^{j,k} \) are expressions, \( cond_i^{j,k} \) are boolean expressions, \( hd(T) \) denotes the last element of the trace, and \( tl(T) \) denotes the trace without its last element. Expressions can be constructed from objects and operations of user-defined domains, such as integers, booleans and more complex domains that we do not give formally. We also assume that for each \( 1 \le i \le n \), all calls to an attribute function \( f_l \) occurring in \( exp_i^{j,k} \) or \( cond_i^{j,k} \) are parameterized by \( T \) if \( l \le i \) or by \( tl(T) \) if \( l > i \). Such an ordering can be constructed if the \( EB ^3\) specification does not contain circular dependencies between function calls, which would lead to infinite attribute function evaluation. This restriction on \( AtFct \) is satisfied in our case study as both \( nbLoans \) and \( borrower \) contain calls to \( nbLoans \) and \( borrower \) parameterized on \( tl(T) \). Also, \( nbLoans \) makes call to \( borrower \) parameterized on \( T \). Hence, \( f_1 = borrower \) and \( f_2 = nbLoans \).
Fig. 5


\( \mathbf{Sem }_{\mathbf{T/M }} \). \( Sem_{T/M} \) is given in Fig. 5 as a set of rules named \( T_{T/M}\!-\!1 \) upto \( T_{T/M}\!-\!11 \). Each state is represented as a tuple \( (E,T,M) \). \( M_i(\overline{x}) \) is the variable that keeps the current valuation for attribute function \( f_i \) with parameter vector \( \overline{x} \). \( M_i \) refers to attribute function \( f_i \). Given that the \( EB ^3\) specification is valid, there is at least one \( cond_{i}^{j,k} \) that is evaluated true on every run. The action \( \rho _j \) to occur “chooses” the corresponding \( cond_{i}^{j,k} \) non-deterministically (in the sense that there may be many \( k \) that make \( cond_{i}^{j,k} \) evaluate to true). Function \( next \) updates \( M_i \) by making use of \( M_l \) for \( l \ge i \) and the freshly computed \( next(M_l)(\rho _j) \) for \( l < i \). The classic intepretations for Peano Arithmetic, Set Theory and Boolean Logic suffice to evaluate them. In \( (T_{T/M}\!-\!10) \), \( C[f_i \leftarrow M_i] \) denotes replacing all calls to \( f_i \) in \( C \) by \( M_i \). The notation \( \parallel \!.\!\parallel \) in \( \parallel \!C[f_i \leftarrow M_i]\!\parallel \) corresponds to the standard interpretation of Boolean operators.
Fig. 6


\( \mathbf{Sem }_{\mathbf{M }} \). \( Sem_{M} \) is given in Fig. 6 as a set of rules named \( S_{M}\!-\!1 \) to \( S_{M}\!-\!11 \). \( Sem_{M} \) derives from \( Sem_{T/M} \) by simple elimination of \( T \) from each tuple \( (E,T,M) \) in rules \( T_{T/M}\!-\!1 \) upto \( T_{T/M}\!-\!11 \). It gives a finite state system. Intuitively, this means that the information on the history of executions is kept in \( M \), thus rendering the presence of trace \( T \) redundant.

3 Bisimulation Equivalence of \( Sem_T \), \( Sem_{T/M} \) and \( Sem_M \)

We present the proof of the bisimulation equivalence for the three semantics: Sem \(_T\), Sem \(_{T/M}\) and Sem \(_M\).

\(\mathbf{LTSs }\). We consider finite labeled transition systems (LTSs) as interpretation models, which are particularly suitable for action-based description formalisms such as \( EB ^3\). Formally, an LTS is a triple \( (S, \{\xrightarrow {a}\}_{a\in Act}, I) \), where: (1) \(S\) is a set of states, (2) \(\xrightarrow {a} \subseteq S \times S\), for all \(a \in Act\), (3) \(I\) \(\subseteq \) S is a set of initial states.

\(\mathbf{Bisimulation }\). Bisimulation is a fundamental notion in the framework of concurrent processes and transition systems. A system is bisimilar to another system if the former can mimic the behaviour of the latter and vice-versa. In this sense, the associated systems are considered indistinguishable. Given two LTSs \( TS_i = (S_i, \{\xrightarrow {a}_i\}_{a\in Act}, I_i) \), where \( i=1, 2 \) and a relation \( R \subseteq S_1 \times S_2 \), \( R \) is said to be a bisimulation and \( TS_i \) are said to be equivalent w.r.t. bisimulation iff
  1. 1.

    \(\forall \; s_1 \in I_1 \; \exists s_2 \in I_2\) such that \((s_1,s_2)\in R\).

  2. 2.

    \(\forall \; s_2\in I_2 \; \exists s_1 \in I_1\) such that \((s_1,s_2)\in R\) .

  3. 3.
    \(\forall (s_1, s_2)\in R:\)
    1. (a)

      if \(s_1 \xrightarrow {a}_1 s_1'\) then \(\exists s_2' \in S_2\) such that \(s_2 \xrightarrow {a}_2 s_2'\) and \((s_1',s_2') \in R\) ;

    2. (b)

      if \(s_2 \xrightarrow {a}_2 s_2'\) then \(\exists s_1' \in S_1\) such that \(s_1 \xrightarrow {a}_1 s_1'\) and \((s_1',s_2') \in R\) .

\(\mathbf{LTS \; Construction }\). For a given \( EB ^3\) process \( E \), we associate three LTSs w.r.t. \( Sem_T \), \( Sem_{T/M} \) and \( Sem_M \) respectively. These correspond to the LTSs generated inductively by the rules given in Fig. 46. The whole process mimicks the construction of a transition system associated with a transition system specification, as in [16]. For the rest, we denote \( TS_T \), \( TS_{T/M} \) and \( TS_M \) for \( TS_E \) w.r.t. \( Sem_{T} \), \( Sem_{T/M} \) and \( Sem_M \) respectively.

Theorem 1.

\( TS_T \) and \( TS_{T/M} \) are equivalent w.r.t. bisimulation.


Let \( \rightarrow _1 \) be the transition relation for \( TS_T \) and \( \rightarrow _2 \) be the transition relation for \( TS_{T/M} \). The relation, which will give the bisimulation between \( TS_T \) and \( TS_{T/M} \), is: \( R=\{\langle (E,T,M),(E,T)\rangle \, \arrowvert \, (E,T,M) \in S_{T/M} \wedge (E,T) \in S_{T} \} \). Note first that \( \langle (E^0,[\;],M^0), (E^0,[\;])\rangle \!\in \!R \). We show that for any \(\langle (E,T,M),(E,T)\rangle \!\in \) \( R \) and \((E,T,M)\!\xrightarrow {\rho }_1\!(E',T',M') \in \delta _{T/M}\), we obtain \((E,T)\!\xrightarrow {\rho }_2\!(E',T')\!\in \!\delta _{T}\) and vice-versa. We proceed with structural induction on \( E \) and present the proof for some cases.

For \({(T_{T/M}\!-\!1)}\), suppose \((\rho ,T,M)\!\xrightarrow {\rho }_1\!(\surd ,T\cdot \rho ,next(M)(\rho )) \in \delta _{T/M}\). The rule \({(R_T\!-\!1)}\) allows us to conclude that also \((\rho ,T)\!\xrightarrow {\rho }_2\!(\surd ,T\cdot \rho ) \in \delta _{T}\). Conversely, suppose \((\rho ,T)\!\xrightarrow {\rho }_2\!(\surd ,T\cdot \rho ) \in \delta _{T}\). Note that each state \((E,T,M)\!\in S_{T/M}\) is of the form:
$$\begin{aligned} \begin{array}{c} (E,T,next'(T,M^0)), \mathrm{where} \\ next'\,(T, M)=\mathbf{match } \ T \ \mathbf{with } \ [\ ] \rightarrow \ M \ \arrowvert \ T' \cdot \rho \rightarrow next'\,(T', next\,(M,\rho )) \end{array} \end{aligned}$$
Thus, there exists \((\rho ,T,next'\,(T,M^0))\xrightarrow {\rho }_1(\surd ,T \cdot \rho ,next'\,(T\cdot \rho ,M^0))\in \delta _{T/M}\), which establishes rule \( (T_{T/M}\!-\!1) \) by replacing \( next'(T,M^0) \) with \( M \) as well as \( next'(T\cdot \rho ,M^0) \) with \( next\left( M\right) (\rho ) \).

For \( (T_{T/M}\!-\!2) \), suppose \( (E_1.E_2,T,M)\xrightarrow {\rho }_1(E_1'.E_2,T',M') \in \delta _{T/M} \), which relies on the existence of a transition \( (E_1,T,M)\xrightarrow {\rho }_1(E_1',T',M') \in \delta _{T/M} \). By the induction hypothesis, \( (E_1,T)\xrightarrow {\rho }_2(E_1',T') \in Sem_{T} \) and by \( (R_{T}\!-\!2) \), we get \( (E_1.E_2,T)\!\xrightarrow {\rho }_2\!(E_1'.E_2,T')\in \delta _{T} \). Vice-versa, by virtue of \( (R_{T}\!-\!2) \) a transition \( (E_1.E_2,T)\xrightarrow {\rho }_2(E_1'.E_2,T')\in \!\delta _{T} \) necessitates \( (E_1,T)\xrightarrow {\rho }_2(E_1',T') \in \delta _{T} \). Using the induction hypothesis, \( (E_1,T,M)\xrightarrow {\rho }_1(E_1',T',M') \). Finally, by \( (T_{T/M}\!-\!2) \) we obtain \( (E_1.E_2,T,M)\xrightarrow {\rho }_1(E_1'.E_2,T',M') \).

For \( (T_{T/M}\!-\!10) \), we must prove that \( \parallel \!C\,(T)\!\parallel = \parallel \!C[f_i \leftarrow M_i]\!\parallel \). Making use of the syntactic definition of \( C(T) \) and the interpretation of \( \parallel . \parallel \), it suffices to prove that \( f_i\,(T,\overline{x})=M_i(\overline{x}), i\in 1..n \) for any parameter vector \( \overline{x} \) and trace \( T \). We prove this by induction on \( T \).

For \( T=[\,] \), it is trivially \( f_i\,(T,\overline{x}) = M_i^0(\overline{x}) = \parallel \!exp_i^0(\overline{x})\!\parallel \), as \( exp_i^0(\overline{x}) \) contains no calls to other attribute functions. If \( f_i\,(tl\,(T),\overline{x})=M_i(\overline{x}),\,i\in 1..n \), we need to prove that:
$$\begin{aligned} f_i\,(T,\overline{x})=next\,(M_i)(hd\,(T))(\overline{x}),\,i\in 1..n. \end{aligned}$$
which we do again by induction on \(i\).
Starting with \( i=1 \), \( next\,(M_i)(hd\,(T))(\overline{x}) \), can be written as:
$$\begin{aligned} \parallel exp_1^{j,k}(\overline{x}) [ f_l \leftarrow \text {if } l<1 \text { then } next(M_l)(hd\,(T)) \text { else } M_l] \parallel , \end{aligned}$$
where \( k \) is specified by \( hd(T) \) 5 and all calls to \( f_l,\,l\in 2..n \) are replaced by \( M_l \). Thus, due to the inductive hypothesis, it will be:
$$\begin{aligned} \parallel exp_1^{j,k}(\overline{x})\parallel = \parallel exp_1^{j,k}(\overline{x}) [ f_l \leftarrow M_l] \parallel \end{aligned}$$
A similar result holds for \( cond_1^{j,k} \).

For \( i>1 \), we rely on \( f_l = next(M_l)(\rho _j),\,l<i \), which guarantees that the property 1 holds for all values \( l< i \).

This completes the proof of the case \( (T_{T/M}\!-\!10) \). \(\square \)

Theorem 2.

\( TS_{T/M} \) and \( TS_{M} \) are equivalent w.r.t. bisimulation.


The proof is straightforward, because the effect of the trace on the attribute functions and the program execution is coded in memory \( M \). Hence, intuitively the trace is redundant. \(\square \)

Corollary 1.

\(TS_T\) and \(TS_{M}\) are equivalent w.r.t. bisimulation.


Combining the two Theorems and the transitivity of bisimulation.\(\square \)

4 Demonstration in LNT

The translation of \( EB ^3\) specifications is formalized in [18]. We show here how \(Sem_M\) facilitates the translation of \( EB ^3\) specifications to LNT for verification with the toolbox CADP. To this end, we present the translation of the \( EB ^3\) specification of Fig. 1 into LNT for BID=\(\{b_1\}\) and MID=\(\{m_1,m_2\}\) as was produced by the \(EB^32LNT\) compiler [18].

\(\mathbf{ LNT }\). LNT combines, in our opinion, features of imperative and functional programming languages and value-passing process algebras. It has a user-friendly syntax and formal operational semantics defined in terms of labeled transition systems (LTSs). LNT is supported by the LNT.OPEN tool of CADP, which allows the on-the-fly exploration of the LTS corresponding to an LNT specification. We present the fragment of LNT that is useful for this translation. Its syntax is given in Fig. 7. LNT terms denoted by B are built from actions, choice (\(\mathbf{select }\)), conditional (\(\mathbf{if }\)), sequential composition (\(\mathbf{; }\)), breakable loop (\(\mathbf{loop }\) and \(\mathbf {break} \)) and parallel composition (\(\mathbf{par }\)). Communication is carried out by rendezvous on gates G with bidirectional transmission of multiple values. Gates in LNT (denoted with letter G with or without subscripts) correspond to the notion of labels in \( EB ^3\). Their parameters are called offers 6. An offer O can be either a send offer (!) or a receive offer (?). Synchronizations may also contain optional guards (\(\mathbf{where }\)) expressing boolean conditions on received values. The special action \(\delta \) is used for defining the semantics of sequential composition. The internal action is denoted by the special gate \(i\), which cannot be used for synchronization. The parallel composition operator allows multiway rendezvous on the same gate. Expressions \(E\) are built from variables, type constructors, function applications and constants. Labels L identify loops, which can be stopped using “\(\mathbf{break }\) L" from inside the loop body. The last syntactic construct defines calls to process P that take gates G \(_1, \ldots ,G_n\) and variables \(E_1, \ldots ,E_n\) as actual parameters. The semantics of LNT are formally defined in [5].
Fig. 7

Syntax of LNT

\(\mathbf{Formalization }\). The principal gain from \( Sem_{M} \) lies in the use of attribute variables, the memory that keeps the values to all attribute functions. We need a mechanism that simulates this memory in LNT. The theoretical foundations of our approach are developed in [18]. In particular, we explicitly model in LNT a memory, which stores the attribute variables and is modified each time an action is executed. We model the memory as a process \(\mathsf{M}\) placed in parallel with the rest of the system (a common approach in process algebra). To read the values of attribute variables, processes need to communicate with the memory \( M \), and every action must have an immediate effect on the memory (so as to reflect the immediate effect on the execution trace). To achieve this, the memory process synchronizes with the rest of the system on every possible action of the system, and updates its attribute variables accordingly. Additional offers are used on each action, so that the current value of attribute variables can be read by processes during communication, and used to evaluate guarded expressions wherever needed.

These ideas are implemented in a tool called \( EB ^3\)2LNT, presented in the companion paper [18]. We provide here the translation of the case study of library (with two members and two books) into LNT, obtained using \( EB ^3\)2LNT.
Fig. 8

Memory in LNT

Process \(\mathsf{M}\) is given in Fig. 8. It runs an infinite loop, which “listens" to all possible actions of the system. We define two instances of the attribute variable \( nbLoans \) (one for each member) and one instance for \( borrower \) (one book). In the LNT expression \( nbLoans[\mathbf{ord } \ (mid)] \), \( \mathbf{ord } \ (mid) \) denotes the ordinate of value \( mid \), i.e., a unique number between 0 and the cardinal of \( mid \)’s type minus 1. \( nbLoans[\mathbf{ord } \ (mid)] \) is incremented after a \( Lend \) and decremented after a \( Return \) 7. The action \( Lend(mId, bId) \) takes, besides \( mid \) and \( bid \), \( nbLoans \) and \( borrower \) as parameters, because the latter are used in the evaluation of the guarded expression preceding \( Lend \) (\(\mathbf{where }\) statement in Fig. 8). Note how upon synchronisation on \( Lend \), \( nbLoans \) and \( borrower \) are offered (!) by \(\mathsf{M}\) and received (?) by \( loan \) (Fig. 8).
Fig. 9

Main program and the process associated with the computation of the attribute function Loan in LNT

The main program is given in Fig. 9. All parallel quantification operations have been expanded as LNT is more structured and verbose than \( EB ^3\). For most \( EB ^3\) operators, there are equivalent LNT operators [18]. Making use of the expansion rule \({E}^*= \lambda \,\mathtt | \,E. {E}^*\), the Kleene Closure (as in member(mId) \(^*\) in Fig. 1) can be written accordingly. The full LNT program is in the appendix.

5 Conclusion

In this paper, we presented an alternative, traceless semantics \( Sem_{M} \) for \( EB ^3\) that we proved equivalent to the standard semantics Sem \(_T\). We showed how \( Sem_{M} \) facilitates the translation of \( EB ^3\) specifications to LNT for verification of temporal properties with CADP, by means of a translation in which the memory used to model attribute functions is implemented using an extra process that computes at each step the effect of each action on the memory. We presented the LNT translation of a case study involving a library with a predefined number of books and members, translation obtained with the aid of a compiler called \( EB ^3\)2LNT. The \( EB ^3\)2LNT tool is presented in detail in [18].

A formal proof of the correctness of the \( EB ^3\)2LNT compiler is under preparation. The proof strategy is by proving that the memory semantics of each \( EB ^3\) specification and its LNT translation are bisimilar, and works by providing a match between the reduction rules of \( Sem_{M} \) and the corresponding LNT rules [5].

As future work, we plan to study abstraction techniques for the verification of properties regardless of the number of components e.g. members, books that participate in the IS (Parameterized Model Checking). We will observe how the insertion of new functionalities to the ISs affects this issue. Finally, we will formalize this in the context of \( EB ^3\) specifications.


  1. 1.

    here notation \( next(x_C) \) denotes the modification on \( x \)’s value in state (C) after executing transition \( C \rightarrow D \)

  2. 2.

    see \( borrower \)’s script for “\( T=T'.Lend(bId, mId) \)” in Fig. 1

  3. 3.

    we assume \( lab=\{\alpha _1,\ldots ,\alpha _q \} \)

  4. 4.

    This notation is different from the standard pattern-matching notation for attribute functions [10], but more compact

  5. 5.

    see Fig. 5

  6. 6.

    Offers are not explicitely mentioned in the syntactic rules for par and for procedural calls

  7. 7.

    see the definition of \( nbLoans \) in Fig. 1

Supplementary material


  1. Abrial, J.-R.: The B-Book - Assigning programs to meanings. Cambridge University Press (2005)Google Scholar
  2. Bergstra, J.A., Ponse, A., Smolka, S.A.: Handbook of Process Algebra. Elsevier (2001)Google Scholar
  3. Bergstra, J.A., Klop, J.W.: Algebra of Communicating Processes with Abstraction. Journal of Theor. Comput. Sci. 37, 77–121 (1985)MathSciNetMATHCrossRefGoogle Scholar
  4. Bolognesi, T., Brinksma, E.: Introduction to the ISO specification language LOTOS. Computer Networks and ISDN Systems 14(1), 25–59 (1987)CrossRefGoogle Scholar
  5. Champelovier, D., Clerc, X., Garavel, H., Guerte, Y., McKinty, C., Powazny, V., Lang, F., Serwe, W., Smeding, G.: Reference Manual of the LOTOS NT to LOTOS Translator - Version 5.4. INRIA/VASY (2011)Google Scholar
  6. Chossart, R.: Évaluation d’outils de vérification pour les spécifications de systèmes d’information. Master’s thesis, Université de Sherbrooke (2010)Google Scholar
  7. ClearSy. Atelier B, http://www.atelierb.societe.com
  8. De Nicola, R., Vaandrager, F.: Three logics for branching bisimulation (extended abstract). In: Proc. of LICS, pp. 118–129 (1990)Google Scholar
  9. Frappier, M., Fraikin, B., Chossart, R., Chane-Yack-Fa, R., Ouenzar, M.: Comparison of model checking tools for information systems. In: Dong, J.S., Zhu, H. (eds.) ICFEM 2010. LNCS, vol. 6447, pp. 581–596. Springer, Heidelberg (2010)Google Scholar
  10. Frappier, M., St.-Denis, R.: EB\(^3\): an entity-based black-box specification method for information systems. In: Proc. of Software and System Modeling (2003)Google Scholar
  11. Garavel, H., Lang, F., Mateescu, R., Serwe, W.: CADP 2010: A toolbox for the construction and analysis of distributed processes. In: Abdulla, P.A., Leino, K.R.M. (eds.) TACAS 2011. LNCS, vol. 6605, pp. 372–387. Springer, Heidelberg (2011)Google Scholar
  12. Gervais, F.: Combinaison de spécifications formelles pour la modélisation des systèmes d’information. PhD thesis (2006)Google Scholar
  13. Kozen, D.: Results on the propositional mu-calculus. Journal of Theor. Comput. Sci. 27, 333–354 (1983)MathSciNetMATHCrossRefGoogle Scholar
  14. Löding, C., Serre, O.: Propositional dynamic logic with recursive programs. In: Aceto, L., Ingólfsdóttir, A. (eds.) FOSSACS 2006. LNCS, vol. 3921, pp. 292–306. Springer, Heidelberg (2006)Google Scholar
  15. Mateescu, R., Thivolle, D.: A model checking language for concurrent value-passing systems. In: Cuellar, J., Sere, K. (eds.) FM 2008. LNCS, vol. 5014, pp. 148–164. Springer, Heidelberg (2008)Google Scholar
  16. Mousavi, M.R., Reniers, M.A.: Congruence for Structural Congruences. In: Sassone, V. (ed.) FOSSACS 2005. LNCS, vol. 3441, pp. 47–62. Springer, Heidelberg (2005)Google Scholar
  17. Symons, V., Geoff, W.: The Evaluation of Information Systems: A Critique. Journal of Applied Systems Analysis 15 (1988)Google Scholar
  18. Vekris, D., Lang, F., Dima, C., Mateescu, R.: Verification of EB\(^3\) specifications using CADP, http://hal.inria.fr/hal-00768310

Copyright information

© IFIP International Federation for Information Processing 2013

Authors and Affiliations

  1. 1.LACL, Université Paris-EstCréteilFrance

Personalised recommendations