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

## Abstract.

\( 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.

## Keywords

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.

\(\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.

*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\} \).

*loan*.

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 \)”.

^{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 \).

\( 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 \).

*guarded expression*process “\(C\,(T)\!\Rightarrow \!E\)” can execute \(E\) if the predicate \(C\,(T)\) holds. The syntax of \( C(T) \) is given below:

*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 \).

^{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 \).

\( \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.

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

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

- 3.\(\forall (s_1, s_2)\in R:\)
- (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\) ;

- (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\) .

- (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.

*Proof.*

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}\!-\!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 \).

^{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:

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.

*Proof.*

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.

*Proof.*

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].

*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].

\(\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.

^{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).

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.

## Footnotes

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

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

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

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

- 5.
see Fig. 5

- 6.
Offers are not explicitely mentioned in the syntactic rules for

**par**and for procedural calls - 7.
see the definition of \( nbLoans \) in Fig. 1

## Supplementary material

## References

- Abrial, J.-R.: The B-Book - Assigning programs to meanings. Cambridge University Press (2005)Google Scholar
- Bergstra, J.A., Ponse, A., Smolka, S.A.: Handbook of Process Algebra. Elsevier (2001)Google Scholar
- Bergstra, J.A., Klop, J.W.: Algebra of Communicating Processes with Abstraction. Journal of Theor. Comput. Sci. 37, 77–121 (1985)MathSciNetMATHCrossRefGoogle Scholar
- Bolognesi, T., Brinksma, E.: Introduction to the ISO specification language LOTOS. Computer Networks and ISDN Systems 14(1), 25–59 (1987)CrossRefGoogle Scholar
- 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
- 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
- ClearSy. Atelier B, http://www.atelierb.societe.com
- De Nicola, R., Vaandrager, F.: Three logics for branching bisimulation (extended abstract). In: Proc. of LICS, pp. 118–129 (1990)Google Scholar
- 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
- 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
- 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
- Gervais, F.: Combinaison de spécifications formelles pour la modélisation des systèmes d’information. PhD thesis (2006)Google Scholar
- Kozen, D.: Results on the propositional mu-calculus. Journal of Theor. Comput. Sci. 27, 333–354 (1983)MathSciNetMATHCrossRefGoogle Scholar
- 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
- 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
- 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
- Symons, V., Geoff, W.: The Evaluation of Information Systems: A Critique. Journal of Applied Systems Analysis 15 (1988)Google Scholar
- Vekris, D., Lang, F., Dima, C., Mateescu, R.: Verification of EB\(^3\) specifications using CADP, http://hal.inria.fr/hal-00768310