Generating Distributed Programs from Event-B Models
LL. Fribourg and M. Heizmann (Eds.): VPT/HCVS 2020EPTCS 320, 2020, pp. 110–124, doi:10.4204/EPTCS.320.8 c (cid:13)
H. Cirstea, A. Grall & D. MéryThis work is licensed under theCreative Commons Attribution License.
Generating Distributed Programs from Event-B Models
Horatiu Cirstea
LORIA UMR 7503Université de LorraineVandœuvre-lès-Nancy, France [email protected]
Alexis Grall
LORIA UMR 7503Université de LorraineVandœuvre-lès-Nancy, France [email protected]
Dominique Méry
LORIA UMR 7503Telecom Nancy, Université de LorraineVandœuvre-lès-Nancy, France [email protected]
Distributed algorithms offer challenges in checking that they meet their specifications. Verificationtechniques can be extended to deal with the verification of safety properties of distributed algorithms.In this paper, we present an approach for combining correct-by-construction approaches and transfor-mations of formal models (E
VENT -B) into programs (D
IST A LGO ) to address the design of verifieddistributed programs. We define a subset LB (Local E
VENT -B) of the E
VENT -B modelling languagerestricted to events modelling the classical actions of distributed programs as internal or local com-putations, sending messages and receiving messages. We define then transformations of the variouselements of the LB language into D
IST A LGO programs. The general methodology consists in startingfrom a statement of the problem to program and then progressively producing an LB model obtainedafter several refinement steps of the initial LB model. The derivation of the LB model is not describedin the current paper and has already been addressed in other works. The transformation of LB modelsinto D
IST A LGO programs is illustrated through a simple example. The refinement process and thesoundness of the transformation allow one to produce correct-by-construction distributed programs. E VENT -B is a formal modelling language developed by Abrial [1] offering key features such as theuse of set theory as a data modelling notation, the use of refinement to relate system models at dif-ferent abstraction levels and the use of mathematical proofs to verify consistency between refinementlevels. Moreover, the language is supported by the environment R
ODIN [2] which is extensible throughthe mechanism of plugin. Previous works [3, 14, 10, 11] illustrate the correct-by-construction design ofdistributed algorithms using E
VENT -B models and refinements; those works show that at an adequatelevel of concretization of models, one can derive a distributed algorithm in a pseudo algorithmic nota-tion. However, the derivation of concrete E
VENT -B models requires to develop a methodology relatedto a given class of problems. For instance, we have produced a plugin EB2RC [12, 5] which automat-ically generates a recursive algorithm from an E
VENT -B model derived by analysis of a problem suchas Floyd’s algorithm, or search algorithms, or sorting algorithms. The transformation of an E
VENT -Bmodel into a recursive algorithm was based on the definition of a class of (concrete) E
VENT -B modelssatisfying constraints making the transformation automatic.In the current paper, we study the systematic transformation of concrete E
VENT -B models into theD
IST A LGO [8] programming language. In fact, the design of a distributed algorithm using the correct-by-construction approach starts by expressing the required computations in a very abstract E
VENT -Bmodel (AM) and then progressively refining the model into a final concrete model (CM) very close toan algorithmic expression of the distributed algorithm. The main advantage of such a refinement-basedprocess is the preservation of safety properties of the different models: the refinement is checked bydischarging a list of proof obligations. We do not describe the process for developing the model CMwhich is supposed to be a local E
VENT -B model and which could be translated into an algorithmic . Cirstea, A. Grall & D. Méry AM Service machine
ServicecontextInMInduction machine InductioncontextCoMComm. machine Communicationcontext... ...CMImplementationmachine CONTEXT-CMImplementationcontext
Event-B specification problem ( contract ) C1.da , . . . ,
Cn.da
DistAlgo
Components program.da
DistAlgo
ProgramREFINES specification
REFINESREFINESREFINES transformation configuration verificationSEESSEESSEESSEESEXTENDSEXTENDSEXTENDSEXTENDS
Figure 1:
The global methodology for correct-by-construction distributed algorithms.distributed notation. We focus on the transformations required for obtaining a D
IST A LGO program froma local E
VENT -B model as indicated in Figure 1: the program program.da is generated from CM andCONTEXT-CM. We will not provide the proof of correctness of the translation but we will give enoughdetails for trusting it. The proof will be given in a future work.
An overview of the integrated development framework
Figure 1 provides an overview of our inte-grated development framework for refinement-based program verification of distributed algorithms. Thegeneral methodology starts by stating the problem to solve by listing the requirements ( i.e. the contract)attached to the problem; the requirements can be either expressed in a formal language or in an informaltextual language. One has then to specify the E
VENT -B machine AM translating the main requirementsfor the given problem. Then a list of formal E
VENT -B refined machines are produced to obtain a fi-nal E
VENT -B machine and context, CM and CM-CONTEXT. Finally, the translations of these finalcontext and machine into D
IST A LGO components and programs are generated in two main steps: theautomatic compilation of CM and CM-CONTEXT into a D
IST A LGO program, and the manual tuningof the obtained D
IST A LGO components (if some configurations were not specified in the model).The refinement block (with nodes AM, CONTEXT-AM, CM and CONTEXT-CM) in Figure 1, il-lustrates the mechanism for deriving machines via refinement. The result of the refinement is the E
VENT -B machine CM, which contains the refined events and the proof obligations that must be discharged inorder to prove that the refinement is correct.Transformations of this E
VENT -B machine CM into a D
IST A LGO program is based on the extractionof information concerning the network and the process classes from the context CONTEXT-CM, andon the analysis of the localization of the different variables. The events of CM are supposed to be local12
Generating Distributed Programs from Event-B Models which means that they are using only local instances of variables. For instance, pc will be a local variablewith an instance pc ( p ) for the process p . We will define precisely the localization process from the codeof E VENT -B models. Finally, some constants whose values are not defined in the context are instantiatedduring the configuration phase.
Related work
We described a simple extension of the call-as-event paradigm [9, 12] to handle thedesign of concurrent programs in the coordination -based approach but we do not target a specific pro-gramming language as D
IST A LGO . The EB2ALL (http://eb2all.loria.fr) framework provides a list oftransformations of E
VENT -B models into classical programming languages (C, C++, Java, . . . ) but itdoes not consider distributed algorithms. The current work can be considered as adding a new tar-get programming language but with the target of a distributed program like it was proposed in Visidia(http://visidia.labri.fr) together with E
VENT -B with the plugin B2VISIDIA relating the local E
VENT -Bmodel and a VISIDIA program. However, the VISIDIA approach addresses distributed programs de-fined as set of rewriting rules of graphs, which is less concrete and effective than D
IST A LGO
ODIN has been developed for translating any E
VENT -B specification into (se-quential) JML or Java code. Finally, a Tasking E
VENT -B [7] for R
ODIN extends the E
VENT -B languageto provide features for specifying concurrent multi-tasking systems. A model is decomposed into sev-eral tasking machines which schedule and perform tasks involving shared machines which correspondto protected resources accessed by tasking machines. The plugin provides a tool support for translatinga tasking specification into A DA code. The generated programs are not distributed ones and consideronly a subclass of the ADA language. Our work focuses on generating D IST A LGO programs from localE
VENT -B models and provides a way to preserve powerfull safety properties from the local models.
Overview of the paper
In the next section, we briefly present the two languages E
VENT -B and D IS - T A LGO . Section 3 shows how distributed programs can be modelled in the sub-language called LB forLocal E
VENT -B. Finally, in Section 4 we define the transformation of LB models into D
IST A LGO pro-grams. Our paper then concludes with the results and future work. A more detailed description of thetranslation as well as the complete definition of the LB models and of the D
IST A LGO program of ourexample are available in [6].
We describe briefly in this section the E
VENT -B modelling language and the D
IST A LGO programminglanguage. We will show later on how the corresponding specifications are implemented following themethodology described in Figure 1.
VENT -B The E
VENT -B language [1] contains two main components, the context which describes the static prop-erties of a system using carrier sets s , constants c , axioms A ( s , c ) and theorems T c ( s , c ) , and the ma-chine which describes behavioural properties of a system using variables v , invariants I ( s , c , v ) , theoremsT m ( s , c , v ) , variants V ( s , c , v ) and events evt . A context can be extended by another context, a machinecan be refined by another machine and a machine can use the sees relation to include other contexts. . Cirstea, A. Grall & D. Méry VENT -B machine defines a set of state variables Var , taking their values in a set
Val , andpossibly modified by a set of events Events . A set of invariants I i ( s , c , v ) contains typing informa-tion and required safety properties that must be satisfied by the defined system. Each event evt = ANY x WHERE G evt ( s , c , v , x ) THEN v : | P evt ( s , c , v , x , v (cid:48) ) END is composed of parameter(s) x , guard(s) G evt ( s , c , v , x ) and action(s) v : | P evt ( s , c , v , x , v (cid:48) ) . Unprimed variables refer to the state variables beforethe event occurs and primed variables refer to the state variables after observation of the event. The before-after predicate BA ( evt )( s , c , v , v (cid:48) ) for evt is defined by ( ∃ x · G evt ( s , c , v , x ) ∧ P evt ( s , c , v , x , v (cid:48) )) .A state st of a machine is an element of the set St EB = Var → Val . The value of a variable u ∈ Var in the state st is st ( u ) and is denoted st (cid:74) u (cid:75) . The notation (cid:74) . (cid:75) is extended to the list of variables v =( v , . . . , v n ) by stating st (cid:74) ( v , . . . , v n ) (cid:75) = ( st ( v ) , . . . , st ( v n )) . Finally, (cid:74) . (cid:75) is extended to handle (arithmeti-cal, boolean) expressions by inductive definition: st (cid:74) exp ( v ) (cid:75) = exp ( st (cid:74) v (cid:75) / v ) . For two states st , st andan expression exp ( v , v (cid:48) ) on primed variables v (cid:48) and unprimed variables v , st (cid:74) exp ( v , v (cid:48) ) (cid:75) st is defined by exp ( st (cid:74) v (cid:75) / v , st (cid:74) v (cid:75) / v (cid:48) ) the value of expression exp where unprimed variables are evaluated in state st and primed variables are evaluated in state st . When an event evt is observed between two states st and st , then st (cid:74) BA ( evt )( s , c , v , v (cid:48) ) (cid:75) st holds. In this paper, we write deterministic actions of the form v : = E ( s , c , v , x ) that are equivalent to v : | v (cid:48) = E ( s , c , v , x ) . Using the transition relation over the set ofstates, we can define state properties as safety or invariance and traces properties.The E VENT -B modelling language supports the correct-by-construction approach to design an ab-stract model and a series of refined models for developing any large and complex system. R
ODIN [2] isan integrated development environment for the E
VENT -B modelling language based on Eclipse. It in-cludes project management, stepwise model development, proof assistance, model checking, animationand automatic code generation.
IST A LGO
Distributed Programming Language D IST A LGO [8] is a programming language used to develop distributed algorithms by providing high levelprogramming mechanisms such as communication primitives for the exchange of messages between aset of processes.A D
IST A LGO program is composed of several process classes managed by a main module (seeExample 4.1). A process class is made of a setup method which initializes the class attributes, a run method for carrying out the main execution flow, several receive methods for handling the receptionof messages and other user defined methods that may be called by the run method. For each processclass PC , the main module uses a statement of the form pset= new (PC, num =n) to build the set pset of n processes running the algorithm specified for PC . The setup method is called for the processes ineach class and the start directive is eventually used to trigger the run method of all processes.A process can send a message to another process q with a statement send (message, to =q) .When a message arrives at the receiving process, it is put in a message queue waiting to be receivedby the process. To receive messages, the process control flow must be at a yield point and this enablesthe receiving of every message in the message queue. When a message is received, the receive message handlers matching the message are executed. A yield point is a labeled statement --l ifawait b1:s1 elif b2:s2 elif . . . elif bn:sn waiting for one of the conditions bi tohold in order to execute the corresponding branch si . The history of sent and received messages canbe accessed in D IST A LGO using the sent and received primitives. A graphical representation ofthe message exchanges is given in Figure 2. Since D
IST A LGO is implemented as a P
YTHON moduleall the data structures and primitives of the latter can be used. In our translation we use, in particular, list s, sometimes built using the function range which creates a list interval of integers, and set s,14
Generating Distributed Programs from Event-B Models sent ⊕ ( m, q ) ch ( p, q ) ch ( p, q ) ⊕ m mq ⊕ ( m, p ) yield point ch ( p, q ) received ⊕ ( m, p ) send(m,to=q) exec. receive handlersprocess p process q Figure 2:
Comunications in D
IST A LGO : the communication channels ch , as well as the message queues mq cannot be accessed explicitly in D IST A LGO ; only the sent and received messages can be accessedusing the sent and received primitives.which can be built from a list or using the function setof ( expr ( x , . . . , x n ) , x in S , . . . , x n in S n , pred ( x , . . . , x n ) ) which is a set comprehension with expr essions built out of elements in the sets S , . . . , S n and satisfying a pred icate. P YTHON dictionaries are also used; these can be updated withthe elements of another dictionary using the method update and cloned with the function deepcopy which copies an object and the objects it contains recursively. The D
IST A LGO boolean functions each and some acting as a universal quantifier and an existential quantifier respectively, are also used.
VENT -B We use the modelling technique of G. Tel [13] and express a distributed algorithm as a set of localalgorithms, each local algorithm being able to do an internal action, or to send a message, or to receivea message. The final context CONTEXT-CM and machine CM in Figure 1 model such a distributedalgorithm using a subset of the modelling language E
VENT -B, denoted LB (Local E
VENT -B). We usethe simple distributed algorithm introduced in Example 3.1 to explain the methodology for modellingalgorithms following Tel’s technique and the restrictions imposed on LB.
Example 3.1.
We consider a distributed algorithm where each process q in a set of processes Q sends itsstored value to a central process p who previously made the corresponding requests. The local algorithmof the requester process p has three states:srINITIALISATION wa done sendRequest stopSendingreceiveAnswer terminateWhile in state sr, p sends a request to each of the processes in Q and moves to state wa, when all requestshave been sent. In the state wa, it awaits for answers from the processes in Q. When all answers arereceived, process p has terminated its local algorithm and moves to state done .wrINITIALISATION done receiveRequestSendAnswer terminateEach process in Q is initially in a state wr in which it waits for a request from p and moves to state done after receiving the request and sending its stored value. . Cirstea, A. Grall & D. Méry
CONTEXT
CONTEXT-CM
EXTENDS
C00
SETS
Nodes States Messages // General sets
MessagePre f ixes // Algorithm specific sets
CONSTANTS network // The topology (general)
Channels emptyChannel sent received inChannel // Communication channels (general) send receive lose // Communication primitives (general)
P p Q // Process classes and processes (specific to the algorithm) request answer // Algorithm specific constants availableResources // Algorithm specific constant sr wa wr done // Process states (specific to the algorithm except for done , general)
AXIOMS
Nodes : partition ( Nodes , P , Q ) // Partition of the set of processes P : partition ( P , { p } ) // Partition of the classes of processes network_typing : network ∈ Nodes → P ( Nodes ) // Network specification network_value : network = { proc · proc ∈ P | proc (cid:55)→ Q } ∪ { proc · proc ∈ Q | proc (cid:55)→ { p }} // States of the processes
States : partition ( States , { sr } , { wa } , { wr } , { done } ) // Communication channels
Channels : Channels = Nodes × Nodes → ( Messages → N × N × N ) // Algorithm specific constants (types of exchanged messages, process resources)
MessagePrefixes : partition ( MessagePre f ixes , { request } , { answer } ) //@P@Q availableResources_typing : availableResources ∈ Q → N // Communication axioms (general to all algorithms)
END Figure 3:
Sets and constants for the Example 3.1The general architecture of the distributed algorithm (processes, topology, channels, communica-tions) is specified in the E
VENT -B context CONTEXT-CM while the list of events of the machine CMinduces the specifications of the local algorithms as labelled transition systems. In the sequel, the pairCM and CONTEXT-CM defining the LB distributed model is called simply CM.
Sets, constants and corresponding axioms defined in the context of a distributed model are of two cat-egories: the general ones present in the context of any algorithm and those which are specific to themodeled algorithms. The most important elements of the context corresponding to the algorithm de-scribed in Example 3.1 is given in Figure 3:For every distributed algorithm, the set
Nodes of processes is defined axiomatically as a partition intoprocess classes, the processes of each class featuring a similar local algorithm:
Nodes : partition ( Nodes , PCl , . . . , PCl n ) For each process class
PCl i one can enumerate explicitly its processes using an axiom PCl i : partition ( PCl i , { proc } , . . . , { proc m } ) These partitions depend of course on the specific algorithm modeled and, in general, the processes arenot explicitly enumerated.16
Generating Distributed Programs from Event-B Models ( s, i, r ) ( s + 1 , i + 1 , r ) ( s + 1 , i, r + 1) send ( channels ( p q ) m ) receive ( channels ( p q ) m ) channels ( p q )( m ) : Figure 4:
We suppose that m has been already sent, resp. received, s , resp. r times, and that i copiesare in the channel: channels ( p (cid:55)→ q )( m ) = ( s , i , r ) . When we send the message m we increment thesent counter and the number of messages in the channel; when we receive it we increment the receivedcounter and decrement the number of messages in the channel.The topology, denoted network , is specified by a function associating to each process its neighbours: network ∈ Nodes → P ( Nodes ) . The concrete definition of the topology specific to the distributed algo-rithm under consideration is specified using an axiom whose general form should be network_value : network = { proc · proc ∈ PCl | proc (cid:55)→ expr }∪· · · ∪ { proc · proc ∈ PCl n | proc (cid:55)→ expr n } In the example, the topology is defined as a star with the process p in the center.As we will see later on, the control states in States are used for structuring the observation of eventsin the local algorithms. The set of all possible control states of all processes is defined as a partition byan axiom
States .The context should also define a constant
Channels modelling the set of all possible values of com-munication channels between processes and the set
Messages of messages exchanged through thesechannels. The current state of a channel between two processes is defined as a multiset, correspondingto the messages that were sent, received and in transition, i.e. sent but not yet received or lost. Forinstance, sent (channel,p,q,mes) is returning how many times the message mes has been sent by p to q.Hence, for each channel we can retrieve the exchanged messages using the functions sent , received and inChannel of type Channels × ( Nodes × Nodes ) × Messages → N . The functions send , receive and lose of type Channels × ( Nodes × Nodes ) × Messages → Channels describe the transformation of a channelbetween two processes ( i.e. adding or removing a message) when one operation (send, receive or lose) isobserved. More precisely, we consider that the channels do not preserve the order in which messages aresent, and sending a message consists in incrementing the inChannel part and the sent part of a channel be-tween two processes. The evolution of the channel between two processes p and q concerning a message m is modeled in LB by the variable channels ( p (cid:55)→ q )( m ) , as depicted in Figure 4. This variable modelsthe channel ch and the message queues mq as well as the sent and received D IST A LGO primitivesdescribed in Section 2.2 (Figure 2); the transfer of the message from the channel to the message queuewhich is builtin in D
IST A LGO is not explicitly modeled in LB.Sets and constants mentioned above should be present in the context of any distributed algorithmmodeled in LB. Other enumerated sets defined necessarily as the disjoint union of singletons using the partition construct as well as constants specific to the modeled algorithm can be defined in the context.The type of such a constant cst is defined by an axiom of name cst_typing while its value may bedefined by an axiom of name cst_value . For instance, in our example we require that each processof Q has a non-negative integer availableResources . For the purpose of our example, we also define anenumerated set MessagePre f ixes consisting of request and answer which correspond to the two kindsof messages exchanged between the processes.Annotations of the form @
PCl . . . @ PCl n are used to specify that the annotated elements are local tothe processes in the corresponding class. This is done either in the axiom cst_typing to indicate the . Cirstea, A. Grall & D. Méry MACHINE CM SEES
CONTEXT-CM
VARIABLES channels pc result
INVARIANTS channels_typing : channels ∈ Channels pc_typing : pc ∈ Nodes → STAT ES result_typing : result ∈ P → ( Nodes (cid:55)→ N ) EVENTSInitialisation (cid:98) = begin act1 : channels : = emptyChannel act2 : pc : = { proc · proc ∈ P | proc (cid:55)→ sr } ∪ { proc · proc ∈ Q | proc (cid:55)→ wr } act3 : result : = { proc · proc ∈ P | proc (cid:55)→ ∅ } endEND Figure 5: Variables, invariants and initialisation for the Example 3.1process classes concerned by the constant cst , or in the axiom S specifying the partition of an enumeratedset S to indicate the process classes concerned by the elements of the set; the latter applies for the axiom MessagePrefixes in our example.
Definition 1 (Local constants) . Given a process proc ∈ PCl and a constant cst, we say that cst is local to proc when it is a function whose evaluation depends on proc (i.e. of type PCl → cstType or Nodes → cstType) or when it is (an element of an enumerated set whose partition is) annotated by @ PCl. Wedenote LC ( PCl ) the set of local constants for (the processes of) PCl. In our example, the elements of
MessagePre f ixes are local to both p and q ∈ Q , network ( r ) is localto any r ∈ P ∪ Q and availableResources ( q ) is local to any q ∈ Q . We specify now the algorithms for the set of processes. Recall that all processes in a process class runthe same algorithm, the one associated to the class.The machine CM in Figure 1 declares the types and initializes the local variables of each processclass of the distributed algorithm. The variable pc identifying the current state of each local algorithmand the communication variable channels of type Channels are defined for any algorithm, the definitionof other variables depends on the modeled algorithm. The variables together with their initialization inthe machine CM modelling the algorithm described in Example 3.1 is given in Figure 5.
Definition 2 (Local variables) . Given a process proc ∈ PCl and a variable var, we say that var is local to proc when it is a function whose evaluation depends on proc (i.e. of type PCl → varTypeor Nodes → varType). We denote LV ( PCl ) the set of local variables for (the processes of) PCl and LV ( proc ) = LV ( PCl ) the set of local variables for a process proc ∈ PCl.
Every variable is initialised as usual by a deterministic assignment which specifies the value ofthe variable for the processes of each concerned class using statements of the form { proc · proc ∈ PCl | proc (cid:55)→ expr } with the expression expr using only local constants and variables of the processproc . For example, the algorithm specific variable result concerns only the process p ∈ P with theexpression result ( p ) corresponding to the values received from the processes of Q .18 Generating Distributed Programs from Event-B Models
Events of the machine CM correspond to state transitions of the local algorithms of the processes.Process events are observed for a specific process of a process class.
Definition 3 (LB events, states) . An event evt in LB is such that • it features one parameter proc typed by a guard proc ∈ PCl with PCl ∈ Nodes ; • all actions are assignments x ( proc ) : = pExpr or channels : = cExpr with cExpr of the form – send ( channels (cid:55)→ ( proc (cid:55)→ pExpr ) (cid:55)→ mExpr ) – receive ( channels (cid:55)→ ( pExpr (cid:55)→ proc ) (cid:55)→ mExpr ) If the event contains an action send , resp. receive , then it is called a send event , resp receive event ;it is called internal otherwise. • it features a guard pc ( proc ) = st which specifies the event is enabled in state st ∈ States ; • it features a typing guard t ∈ tExpr for each parameter; • if it is an internal or a send event, it can feature general guards gExpr or guards of the form – sent ( channels (cid:55)→ ( proc (cid:55)→ pExpr ) (cid:55)→ mExpr ) = nExpr – received ( channels (cid:55)→ ( pExpr (cid:55)→ proc ) (cid:55)→ mExpr ) = nExpr • if it is a receive event, it can feature matching guards for the parameters source and message whichshould be always present for such an event;with all expressions tExpr , gExpr , pExpr , mExpr , nExpr built over local constants, local variables, pa-rameters of the event, literal integers and booleans.We say that the event is observed for a process proc and moreover, that is observable in state st. Wedenote by Events ( PCl ) and Events ( proc ) the set of local events for the set of processes PCl and for theprocess proc respectively, and by Events ( PCl , st ) and Events ( proc , st ) the events in Events ( PCl ) and Events ( proc ) respectively, that are observable in state st.Given a process class PCl, the set of states of processes of PCl, denoted by StatesSet ( PCl ) , consistsof the states st such that there exists a parameter proc and a guard pc ( proc ) = st for some event evt ∈ Events ( PCl ) . The events of the E
VENT -B machine CM corresponding to the algorithm for the process p introducedin Example 3.1 are presented in Figure 6. Note that sendRequest is a send event and does not modify pc ( p ) , stopSending is an internal event with a guard verifying if p has sent a request to all its neighbours, receiveAnswer is a receive event for answers to the requests (the internal event terminate not presentedhere verifies that an answer has been received from every neighbour and terminates the local algorithm ofprocess p ). The processes of Q feature similar events: we have a receive and a send event which modelrespectively the reception of requests from p and the dispatching of an answer. We also have an internalevent for terminating the local algorithm of a process of Q once it has sent the answer. IST A LGO
A pair of a machine and a context compliant with the form described in the previous section is translatedtowards a D
IST A LGO program composed of a set of process classes. The main function and the processclass definitions are generated from the (axioms in the) context while the process class methods aregenerated from the (invariants and events in the) machine. . Cirstea, A. Grall & D. Méry
Event sendRequest (cid:98) = any proc q where grd1 : proc ∈ P grd2 : q ∈ network ( proc ) grd3 : pc ( proc ) = sr grd4 : sent ( channels (cid:55)→ ( proc (cid:55)→ q ) (cid:55)→ request ) = then act1 : channels : = send ( channels (cid:55)→ ( proc (cid:55)→ q ) (cid:55)→ request ) endEvent stopSending (cid:98) = any proc where grd1 : proc ∈ P grd2 : pc ( proc ) = sr grd3 : ∀ q · ( q ∈ network ( proc ) ⇒ sent ( channels (cid:55)→ ( proc (cid:55)→ q ) (cid:55)→ request ) > ) then act1 : pc ( proc ) : = wa endEvent receiveAnswer (cid:98) = any proc source message r where grd1 : proc ∈ P grd2 : source ∈ Nodes grd3 : message ∈ Messages grd4 : r ∈ Z grd5 : pc ( proc ) = wa grd7 : message = answer (cid:55)→ r then act1 : result ( proc ) : = result ( proc ) (cid:67) − { source (cid:55)→ r } act2 : channels : = receive ( channels (cid:55)→ ( source (cid:55)→ proc ) (cid:55)→ message ) end Figure 6: Events for the Example 3.1
We first define a translation function, denoted T −→ x () , which transforms a well-formed E VENT -B ex-pression (or predicate) expr into the corresponding D
IST A LGO code T −→ x ( expr ) w.r.t. a set −→ x of boundvariables.Arithmetic expressions are translated in an obvious way. Set expressions are also translated straight-forwardly with sets built using the P YTHON primitives set and setof , and the set operations encodedby corresponding P
YTHON operations. Finite functions are translated using P
YTHON dictionaries. Pred-icates are translated into boolean expressions with the quantifiers encoded using the each and some D IST A LGO functions.The action for the sending of a message is translated using the D
IST A LGO function send : T −→ x ( channels : = send ( channels (cid:55)→ ( proc (cid:55)→ dest ) (cid:55)→ msg )) (cid:52) = send ( T −→ x ( msg ) , to = T −→ x ( dest ) ) Note that channels and proc are not present in the resulting code since channels is implicit in D
IST A LGO and proc corresponds to the process executing the send statement.The sent and received events defined in E
VENT -B are translated as D
IST A LGO queries on messagehistory. D
IST A LGO allows patterns inside queries on messages and any plain variable x in such a query20 Generating Distributed Programs from Event-B Models is considered free and is potentially instantiated by a value following a successful matching. To indicatethat a variable is bound in a query it should be of the form _x . We consider thus the translation function T b −→ x () which is defined exactly as the function T −→ x () except for variables for which we have T b −→ x ( x ) (cid:52) = _x when x ∈ −→ x T b −→ x ( x ) (cid:52) = T −→ x ( x ) when x (cid:54)∈ −→ x The two expressions involving sent or received events supported by our approach are translated using T −→ x ( sent ( channels (cid:55)→ ( proc (cid:55)→ dest ) (cid:55)→ msg ) > ) (cid:52) = some ( sent ( T b −→ x ( msg ) , to = T b −→ x ( dest ) )) T −→ x ( received ( channels (cid:55)→ ( source (cid:55)→ proc ) (cid:55)→ msg ) > ) (cid:52) = some ( received ( T b −→ x ( msg ) , from_ = T b −→ x ( source ) )) The main function of the generated D
IST A LGO program defines different local constants as well asthe different processes to execute, and starts the local algorithms of all the processes. This functionis generated using exclusively the context CONTEXT-CM and more precisely, only the axioms of thecontext. The (identifiers of these) axioms should thus respect the rules given in Section 3.1 and the namesof the variables and constants are inferred correspondingly.The code of the main function contains a fixed part independent of the algorithm and specifying,for example, the behaviour of the communication channels. We omit here the fixed part and the variousimports that might be needed and focus on the part generated from the E
VENT -B model.The axiom
Nodes allows us to infer the set { PCl , . . . , PCl n } of process classes and to generate, foreach process class, a fresh variable PClSet i corresponding to the set of processes in PCl i . We can thusinitialize each variable PClSet i as a set of NPCl i processes of class PCl i (generated later on) and then,the variable Nodes corresponding to the set of all processes:
PClSet = new (PCl , num =NPCl ) . . . PClSet n = new (PCl n , num =NPCl n )Nodes = set .union(PClSet , . . . ,PClSet n ) We use the axioms
PCl i to initialize the variables for each set and NPCl i to the cardinal of the corre-sponding set ( NPCl i should be configured manually if the axiom is not present): (proc1, . . . ,procm) = list (PClSet i )NPCl i = |{ proc , . . . , proc m }| Starting from the axiom network_value we generate the map network for the topology network = {proc: T ∅ ( expr ) for proc in PClSet }network. update ({proc: T ∅ ( expr ) for proc in PClSet }) . . . network. update ({proc: T ∅ ( expr n ) for proc in PClSet n }) In fact, for each (local) constant cst in the context which is a function ( cst ∈ PCl → cstType ) andfeatures an axiom cst_value : cst = { proc · proc ∈ PCl | proc (cid:55)→ expr } for some PCl we generate aninitialization: cst = {proc: T ∅ ( expr ) for proc in PClSet}
For each process class
PCl i the following code is generated for the initialisation: for proc in PClSet i : setup ({proc}, (cst_1[proc], . . . ,cst_n[proc]) . Cirstea, A. Grall & D. Méry { cst , . . . , cst n } = LC ( PCl i ) .Finally, the processes are executed with the D IST A LGO command start (Nodes) . Example 4.1.
Given the context in Section 3.1 the following main function is generated. def main():NP = 1NQ =
PSet = new (P, num =NP)(p,) = list (PSet)QSet = new (Q, num =NQ)Nodes = set .union(PSet, QSet)network = {proc:QSet for proc in PSet}network. update ({q:{p} for q in QSet})availableResources = for proc in PSet: setup ({proc}, (network[proc],)) for proc in QSet: setup ({proc}, (network[proc], availableResources[proc])) start (Nodes)
In the same time with the main class we generate the code corresponding to the enumerated setsdefined in the context using an axiom S : partition ( S , { el } , { el } , . . . ) like, e.g. , MessagePre f ixes . Forall these sets we generate a separate file (imported when needed) containing the corresponding code: class
S(Enum): el = " el " el = " el "... The access to the elements of the respective set is done as expected: T −→ x ( el i ) (cid:52) = S. el i , for any member el i of the enumerated set. For each process class
PCl we generate a D
IST A LGO process class
PCl featuring the necessary methods.For the purpose of the translations presented in this section we consider the function T l −→ x () whichbehaves exactly like T −→ x () except for one case: T l −→ x ( f ( proc )) (cid:52) = self.f when f ∈ LV ( PCl ) ∪ LC ( PCl ) , proc ∈ PCl .The setup method gets the values of the local constants as parameters and initializes the localvariables. We have thus for each process class
PCl in the context a D
IST A LGO class: class
PCl( process ) : def setup ( cst , . . . , cst n ):self. var = T l ∅ ( expr ) ...self. var m = T l ∅ ( expr m ) Generating Distributed Programs from Event-B Models with { cst , . . . , cst n } = LC ( PCl ) , { var , . . . , var m } = LV ( PCl ) , and { expr , . . . , expr m } the correspondingexpressions var i : = { proc · proc ∈ PCl | proc (cid:55)→ expr i } in the Initialisation section of the machine. For avariable var (resp. constant cst ), the translation of var ( proc ) (resp. cst ( proc ) ) is then self.var (resp. self.cst ).For each state st ∈ StatesSet ( PCl ) a method st describing the behavior on reception of an eventobservable in state st is generated as explained below. The run method defining the control flow ofthe program for the respective process consists of a loop which calls at each iteration the method st corresponding to the current value of self.pc and terminates when self.pc reaches the terminationstate done . When StatesSet ( PCl ) = { st , . . . , st n } the following code is generated: def run ():stateFunctions = {"st1":st1, . . . ,"stn":stn} while (self.pc!=done):stateFunctions[self.pc]() Given an event evt ∈ Events ( PCl ) we denote by Guards ( evt ) the set of its guards, by Actions ( evt ) the set of its actions and by Params ( evt ) the set of its parameters. The translation G i () of a set of guardsof an internal or a send event is as follows: G i ( { proc ∈ PCl , t ∈ S , . . . , t l ∈ S l , (cid:52) = self.pc=="st" and some ( t in T l ∅ ( S ) , . . . , t l in T l ∅ ( S l ) , pc ( proc ) = st , g , . . . , g n } ) has = T l Params ( evt ) ( g ) and . . . and T l Params ( evt ) ( g n ) ) where Params ( evt ) = { t , . . . , t l } and S , . . . , S l are finite sets. The translation A −→ x ( Actions ( evt )) of aset of actions of an internal or send event evt is defined as the juxtaposition of the translations T l −→ x ( a j ) of each action in the set Actions ( evt ) . Since the actions of Actions ( evt ) are observed concurrently buttranslated as a sequence of assignments, fresh temporary variables are defined as copies of the localvariables prior to the event and are used to access the old values of the local variables. However, forsimplicity, we omit these temporary fresh variables in our example.For each state st ∈ StatesSet ( PCl ) we use the set { evt , . . . , evt m } ⊆ Events ( PCl , st ) of all internal and send events observable in state st to generate the method st : def st():--st if await ( G i ( Guards ( evt )) ): A Params ( evt ) ( Actions ( evt )) ... elif ( G i ( Guards ( evt m )) ): A Params ( evt m ) ( Actions ( evt m )) elif (self.pc != "st"): pass with the label --st and the keyword await added only if there is a receive event in Events ( PCl , st ) ;this statement is used to enable the reception of messages. When an await statement is reached everymessage that has arrived to destination but has not been processed yet, i.e. messages in the messagequeue of this process, is handled (using the receive methods) before the if conditions are evaluated.Messages are received until the message queue is empty and one of the guard conditions is satisfied. Example 4.2.
In our example, we have
Events ( P , sr ) = { sendRequest , stopSending } and thus the fol-lowing code is generated for the method sr . . Cirstea, A. Grall & D. Méry def sr(): sendRequest if (self.pc == "sr" andsome (q in self. network , has = not ( some ( sent ((MessagePrefixes.request,), to =_q))))): send ((MessagePrefixes.request,), to =q) stopSending elif (self.pc == "sr" andeach (q in self. network , has = some ( sent ((MessagePrefixes.request,), to =_q)))):self.pc = "wa" elif (self.pc != "sr"): pass For each receive event evt in Events ( PCl , st ) we generate a receive method in the class PCl : def receive ( G r ( Guards ( evt )) ): A Params ( evt ) ( Actions ( evt )) where the translation G r ( Guards ( evt )) of a set of guards of a receive event evt is as follows: G r ( { proc ∈ PCl , msg ∈ Messages , source ∈ Nodes , t ∈ S , . . . , t l ∈ S l , (cid:52) = msg =( T ∅ ( msgExpr ) ), pc ( proc ) = st , msg = msgExpr , source = procExpr ) } ) from_ = T ∅ ( procExpr ) , at =(st,) If procExpr is empty, i.e. not specified in the model then a free variable it is used in the translation(to indicate the source of the message is not specified). We proceed similarly when msgExpr is empty.The actions of a receive event are translated in the same way as the actions of an internal or send event. Example 4.3.
The following code corresponds to the receive event receiveAnswer. def receive ( msg =(MessagePrefixes.answer, r), from_ =source, at =(wa,)):self.result[source] = r The translation has been implemented in
Java as a R
ODIN plugin and the source code together withthe installation instructions are available at https://gitlab.inria.fr/agrall/eb2da . The localization of E
VENT -B has been used when a distributed algorithm [3, 1] has been developedusing the correct-by-construction paradigm and especially the refinement relationship among levels ofabstractions. The translation of local E
VENT -B models was a manual process and the current workprovides a systematic way to produce a D
IST A LGO program from a local E
VENT -B model.We claim the LB modelling language is sufficiently powerful to model a large variety of distributedalgorithms and abstract enough to be considered as the basis for the translation towards different tar-get distributed programming languages. A couple of algorithms have been modelled and the programsobtained by translation allowed the simulation of the algorithms for different numbers of nodes. Wecontinue to develop more and more elaborated case studies.In the short term we plan of course to produce the proof of soundness of the translation. The com-munication model used for the algorithms implemented so far although reliable does not guarantee the24
Generating Distributed Programs from Event-B Models order of messages; we intend to provide the model for other communications models together with thecorresponding translation. At the implementation level, we should first provide an automatic packag-ing and facilitate the installation as a R
ODIN plugin. The definition of transformations for other targetdistributed programming languages is a more long term objective.
References [1] Jean-Raymond Abrial (2010):
Modeling in Event-B: System and Software Engineering . Cambridge Univer-sity Press, doi:10.1017/S0956796812000081.[2] Jean-Raymond Abrial, Michael Butler, Stefan Hallerstede, Thai Son Hoang, Farhad Mehta & Laurent Voisin(2010):
Rodin: an open toolset for modelling and reasoning in Event-B . International Journal on SoftwareTools for Technology Transfer
A Mechanically Proved and Incre-mental Development of IEEE 1394 Tree Identify Protocol.
Formal Aspects of Computing
EventB2Java: A Code Generator for Event-B . In Sanjai Rayadurgam& Oksana Tkachuk, editors:
NASA Formal Methods , Springer International Publishing, Cham, pp. 166–171,doi:10.1007/978-3-319-40648-0_13.[5] Zheng Cheng, Dominique Méry & Rosemary Monahan (2016):
On Two Friends for Getting Correct Pro-grams - Automatically Translating Event B Specifications to Recursive Algorithms in Rodin . In:
LeveragingApplications of Formal Methods, Verification and Validation: Foundational Techniques - 7th InternationalSymposium, ISoLA 2016, Imperial, Corfu, Greece, October 10-14, 2016, Proceedings, Part I , pp. 821–838,doi:10.1007/978-3-319-47166-2_57.[6] Horatiu Cirstea, Alexis Grall & Dominique Méry (2020):
Generating Distributed Programs from Event-BModels . Research Report, LORIA UMR 7503 CNRS, INRIA, Université de LORRAINE. Available at https://hal.inria.fr/hal-02572971 .[7] Andrew Edmunds & Michael Butler (2011):
Tasking Event-B: An extension to Event-B for generating concur-rent code . In:
PLACES 2011 . Available at http://eprints.soton.ac.uk/id/eprint/272006 .[8] Yanhong A Liu, Scott D Stoller, Bo Lin & Michael Gorbovitski (2012):
From clarity to efficiency for dis-tributed algorithms . In:
ACM SIGPLAN Notices , 47, ACM, pp. 395–410, doi:10.1145/2384616.2384645.[9] Dominique Méry (2009):
Refinement-based guidelines for algorithmic systems . International Journal ofSoftware and Informatics
Modelling by Patterns for Correct-by-Construction Process . In:
Leveraging Ap-plications of Formal Methods, Verification and Validation. Modeling - 8th International Symposium, ISoLA2018, Limassol, Cyprus, November 5-9, 2018, Proceedings, Part I , pp. 399–423, doi:10.1007/978-3-030-03418-4_24.[11] Dominique Méry (2019):
Verification by Construction of Distributed Algorithms . In:
Theoretical Aspects ofComputing - ICTAC 2019 - 16th International Colloquium, Hammamet, Tunisia, October 31 - November 4,2019, Proceedings , pp. 22–38, doi:10.1007/978-3-030-32505-3_2.[12] Dominique Méry & Rosemary Monahan (2013):
Transforming Event B Models into Verified C . In Alexei Lisitsa & Andrei P. Nemytykh, editors:
First International Workshop on Verification andProgram Transformation, VPT 2013, Saint Petersburg, Russia, July 12-13, 2013 , EPiC Series in Comput-ing
16, EasyChair, pp. 57–73.[13] Gerard Tel (2000):
Introduction to distributed algorithms . Cambridge University Press,doi:10.1017/CBO9781139168724.[14] Mohamed Tounsi, Mohamed Mosbah & Dominique Méry (2016):