The original publication is available at http://www.springer.

com/computer/swe/book/978-3-642-33169-5
In "Industrial Deployment of System Engineering Methods" © Springer-Verlag

An Introduction to the Event-B Modelling

Method

Thai Son Hoang

Abstract This chapter is a short introduction to the Event-B modelling method for
discrete transition systems. Important mechanisms for the step-wise development
of the formal models, such as context extension and machine refinement, are dis-
cussed. Consistency of the models are presented in terms of proof obligations and
are illustrated by concrete examples.

1 Introduction

Event-B [2] is a modelling method for formalising and developing systems whose
components can be modelled as discrete transition systems. An evolution of the
(classical) B-method [1], Event-B is now centred around the general notion of
events, which are also found in other formal methods such as Action Systems [4],
TLA [6] and UNITY [5].
Event-B models are organised in terms of the two basic constructs: contexts and
machines. Contexts specify the static part of a model whereas machines specify
the dynamic part. The role of the contexts is to isolate the parameters of a formal
model and their properties, which are assumed to hold for all instances. A machine
encapsulates a transition system with the state being specified by a set of variables
and transitions modelled by a set of guarded events.
Event-B allows models to be developed gradually via mechanisms such as con-
text extension and machine refinement. These techniques enable users to develop
target systems from their abstract specifications, and subsequently introduce more
implementation details. More importantly, properties that are proved at the abstract
level are maintained through refinement, hence are guaranteed to be satisfied also
by later refinements. As a result, correctness proofs of systems are broken down and
distributed amongst different levels of abstraction, which are easier to manage.

Thai Son Hoang

Institute of Information Security, ETH-Zurich, Switzerland e-mail: htson@inf.ethz.ch

1
2 Thai Son Hoang

The rest of this chapter is structured as follows. We give some brief overview of
the Event-B mathematical language in Section 2. In Section 3, we give an informal
description of our running example. Subsequently, we show the basic constructs of
Event-B in Section 4 (contexts) and Section 5 (machines). We present the mecha-
nisms for context extension in Section 6 and machine refinement in Section 7.

2 The Event-B Mathematical Language

The basis for the formal models in Event-B is first-order logic and a typed set-
theory. We are not going to give a full details of the Event-B logic here. For more
information, we refer the reader to [2, 8]. We present some main ingredients of the
Event-B mathematical language that are important for understanding the Event-B
models of the example in the sequel.
The first-order logic of Event-B contains standard operators such as conjunc-
tion (^), disjunction (_), implication ()), negation (¬), equivalence (,), univer-
sal quantification (8), and existential quantification (9). Two constants are defined,
namely > and ? denoting truth and falsity, respectively.

2.1 Set Theory

An important part of the mathematical language is its set theoretical notation, with
the introduction of the membership predicate E 2 S, meaning that expression E is a
member of set S. A set expression can be a variable (depending on its type). More-
over, a set can be explicitly defined by listing its members (set extension), e.g.,
{E1 , . . . , En }. Other basic set constructs include Cartesian product, power set, and
set comprehension. Given two set expressions S and T, the Cartesian product of S
and T, denoted as S ⇥ T, is the set of mappings (ordered pairs) x 7! y where x 2 S
and y 2 T. The power set of S, denoted as P(S), is the set of all sub-sets of S. Fi-
nally, given a list of variables x, a predicate P constraining x and an expression E
depending on x, the set comprehension {x·P | E} is the set of elements E, where P
holds.
A key feature of the Event-B set theoretical notation is the models of relations
as sets of mappings. Subsequently, different types of relations and functions are
also defined as sets of mappings with different additional properties. Given two set
expressions S and T, S $ T denotes the set of all binary relations from S to T.
Similarly, S ! 7 T denotes the set of all partial functions from S to T, and S ! T
denotes the set of all total functions from S to T. Definition of these relations can be
seen below, expressed using set memberships.
An Introduction to Event-B 3

Construct Definition
r 2 S$T r 2 P(S ⇥ T)
f 2 S!
7 T f 2 S $ T ^ (8x, y1 , y2 ·x 7! y1 2 f ^ x 7! y2 2 f ) y1 = y2 )
f 2 S!T f 2 S!
7 T ^ (8x·x 2 S ) (9y·x 7! y 2 f ))

Intuitively, a binary relation r from S to T is a set of mappings x 7! y where x 2 S

and y 2 T. A partial function f from S to T is a binary relation from S to T where
each element x in S has at most one mapping to T. A total function f from S to T is
a partial function from S to T where each element x in S has exactly one mapping to
T.

2.2 Types

Variables in Event-B are strongly typed. A type in Event-B can be some built-in
type (e.g., BOOL, Z) or some user-defined type. Moreover, given T, T1 and T2
being types, the Cartesian product T1 ⇥ T2 and the power set P(T) are also types. In
contrast with most strongly typed programming languages, the type of variables are
not presented when they are declared. Instead, they are inferred from constraining
properties of variables. Typically, a property of the form x 2 E where E is of type
P(T) allows us to infer that x has the type T.

2.3 Well-definedness

Event-B requires that every formula to be well-defined [7, 8]. Informally, one
has to prove that partial functions (either pre-defined, e.g., division ÷, or user-
defined) are never evaluated outside of their domain. Ill-defined expressions, (such
as x ÷ 0) should be avoid. A syntactic operator L is used to map formulae to their
corresponding well-definedness conditions. Table 1 shows the definition of well-
definedness condition using L for some formulae in Event-B. Here x is some vari-
able, P and Q are predicates, E, E1 , E2 are some expressions, and f is a binary
relation from S to T . Moreover dom( f ) denotes the domain of f , i.e., the set of all
elements in S that connect to some element in T .
Notice that by using L , we assume a well-definedness order from left to right
(e.g.,, for P ^ Q) for formulae (this is similar to evaluating conditional statements,
e.g., && or ||, in several programming languages).
4 Thai Son Hoang

Formula Well-definedness condition

x >
¬P L (P)
P^Q L (P) ^ (P ) L (Q)
8x·P 8x·L (P)
E1 ÷ E2 L (E1 ) ^ L (E2 ) ^ E2 6= 0
E1  E2 L (E1 ) ^ L (E2 )
card(E) L (E) ^ finite(E)
f (E) L (E) ^ f 2 S !7 T ^ E 2 dom( f )
Table 1 Calculating well-definedness conditions using L

2.4 Sequents

Event-B defines proof obligations, which must be proved to show that formal mod-
els fulfil their specified properties. Often these verification conditions are expressed
in term of sequents. A sequent H ` G means that the goal G holds under the as-
sumption of the set of hypotheses H. The obligations are discharged using some
inference rules which we will not describe here. Instead, we will give some infor-
mal justifications on how the proof obligations can be discharged. The purpose of
presenting to proof obligations within this chapter is to illustrate various conditions
need to be proved to maintain consistency of the example.

3 Example. A Course Management System

The running example that we are going to use for illustrating Event-B is a course
management system. We describe a requirements document of the system as fol-
lows. A club has some fixed members, amongst them are instructors and partici-
pants. Note that a member can be both an instructor and a participant.

ASM 1 Instructors are members of the club.

ASM 2 Participants are members of the club.

There are pre-defined courses that can be offered by a club. Each course is asso-
ciated with exactly one fixed instructor.

ASM 3 There are pre-defined courses.

An Introduction to Event-B 5

ASM 4 Each course is assigned to one fixed instructor.

A course is either opened or closed and is managed by the system.

REQ 5 A course is either opened or closed.

REQ 6 The system allows to open a closed course.

REQ 7 The system allows to close an opened course.

The number of opened courses is limited.

The number of opened courses

REQ 8
cannot exceed a given limit.

Only when a course is opened, participants can register for the course. An im-
portant constraint for registration is that an instructor cannot attend his own courses.

REQ 9 Participants can only register for an opened course.

REQ 10 Instructors cannot attend their own courses.

In subsequent sections, we develop a formal model according to the above re-

quirements document. In particular, we will give backward pointers to the above
requirements, in order to justify how they are formalised in the Event-B model.

4 Contexts

A context may contain carrier sets, constants, axioms, and theorems. Carrier sets are
user-defined types. By convention, a carrier set s is non-empty, i.e., satisfying s 6= ?,
and maximal, i.e., satisfying 8x·x 2 s. Constants c denote static objects within the
6 Thai Son Hoang

development1 . Axioms are presumed properties of carrier sets and constants. Theo-
rems are derived properties of carrier sets and constants. Carrier sets and constants
model parameters of the development. Moreover, axioms state parameters’ proper-
ties which are assumed to hold for all possible instances of them. A context C with
carrier sets s, constants c, axioms A(s, c), and theorems T(s, c) can be presented as
follows.

axioms:
carrier sets: s constants: c axm : A(s, c)
thm : T(s, c)

Note that we present axioms and theorems using different labels, i.e., axm and thm.
Later on, we also use different labels for other modelling elements, such as, invari-
ants (inv), guards (grd) and actions (act).
Proof obligations are generated to ensure that the theorems are derivable from
previously defined axioms. This is captured by the following proof obligation rule
called THM.
A(s, c) ` T(s, c) . (THM)

4.1 Example. Context coursesCtx

In this initial model, we focus on the opening and closing of courses by the system.
As a result, our initial context coursesCtx contains a carrier set CRS denoting the set
of courses that can be offered by the club (ASM 3). Moreover, coursesCtx includes
a constant m denoting the maximum number of courses that the club can have at
the same time (with respect to requirement REQ 8). The context coursesCtx is as
follows.

axioms:
axm0 1 : finite(CRS)
carrier sets: CRS constants: m axm0 2 : m 2 N1
thm0 1 : 0<m
axm0 3 : m  card(CRS)

Note that we label the axioms and theorems with the prefixes denoting the role of the
modelling elements, i.e., axm and thm, with some numbers. For example, axm0 1
denotes the first (i.e., 1) axiom for the initial model (i.e., 0). We apply this systematic
labelling through out our development.
The assumption on CRS and m are captured by the axioms and theorems as fol-
lows. Axiom axm0 1 states that CRS is finite. Axiom axm0 2 states that m is a
member of the set of natural numbers (i.e., m is a natural number). Finally, axiom
axm0 3 states that m cannot exceed the number of possible courses that can be

1 When referring to carrier sets s and constants c, we usually allow for multiple carrier sets and
constants, i.e., they may be “vectors”.
An Introduction to Event-B 7

offered by the club, represented as card(CRS), the cardinality of CRS. A derived

property of m is presented as theorem thm0 1.

thm0 1/THM

A proof obligation is generated for thm0 1 as follows. Notice that axm0 3 does not
appear in the set of hypotheses for the obligation, since it is declared after thm0 1.
By convention, each proof obligation is labelled according to the element involved
and the name of the proof obligation rule. Here thm0 1/THM indicates that it is a
THM proof obligation for thm0 1.

finite(CRS)
m 2 N1 thm0 1/THM
`
0<m

The obligations can be trivially discharged since N1 is the set of all positive natural
numbers, i.e., {1, 2, . . .}.

axm0 3/WD

It is required to prove that axm0 3 is well-defined. The corresponding proof obliga-

tion is as follows.

finite(CRS)
m2N
0m thm0 1/WD
`
finite(CRS)

Since the goal appears amongst the hypotheses, the proof obligation can be dis-
charged trivially. Note that the order of appearance of the axioms is important. In
particular, axm0 1 needs to be declared before axm0 3.

5 Machines

Machines specify behavioural properties of Event-B models. In order to have access

to information of context C defined in Section 4, machine M must connect with C.
When machine M sees context C, it has access to C’s carrier sets s and constants c,
e.g., to refer to them when modelling, and C’s axioms A(s, c) and theorems T(s, c),
e.g., to use them as assumptions during proving. For clarity in the following presen-
tation, we do not refer explicitly to the modelling elements of C. Note that in general
a machine can see several contexts.
8 Thai Son Hoang

Machines M may contain variables, invariants, theorems, events, and a variant.

Variables v define the state of a machine and are constrained by invariants I(v).
Theorems R(v) are additional properties of v derivable from I(v).

invariants:
variables: v inv : I(v)
thm : R(v)

A proof obligation (also called THM) is generated to prove that the theorem R(v) is
derivable from I(v).
I(v) ` R(v) (THM)
Possible state changes are described by events (see Section 5.1). The variant is used
to prove convergence properties of events (see Section 5.2).

5.1 Events

An event e can be represented by the term

b any x where G(x, v) then Q(x, v) end ,

e = (1)

where x stands for the event’s parameters2 , G(x, v) is the guard (the conjunction
of one or more predicates) and Q(x, v) is the action. The guard states the necessary
condition under which an event may occur. The event is said to be enable in some
state, if there exists some value for its parameter x that makes its guard G(x, v) holds
in that state. The action describes how the state variables evolve when the event
occurs. We use the short form

b when G(v) then Q(v) end

e = (2)

when the event does not have any parameters, and we write

b begin Q(v) end

e = (3)

when, in addition, the event’s guard always holds (i.e., equals to >). A dedicated
event in the form of (3) is used for the initialisation event (usually represented as
init). Note that events may be annotated with their convergence status, which we
will look at in Section 5.2.
The action of an event is composed of one or more assignments of the form

a := E(x, v) (4)

or
2 When referring to variables v and parameters x, we usually allow for multiple variables and
parameters, i.e., they may be “vectors”.
An Introduction to Event-B 9

a :2 E(x, v) (5)
or
a :| P(x, v, a0 ) , (6)
where a are some of the variables contained in v, E(x, v) is an expression, and
P(x, v, a0 ) is a predicate. Note that the variables on the left-hand side of the assign-
ments contained in an action must be disjoint. In (5), a must be a single variable,
whereas it can be a vector of variables in (4) and (6). In particular, in (4), if a is a
vector containing n > 0 variables, then E must also be a vector of expressions, one
for each of the n variables. Assignments of the form (4) are deterministic, whereas
the other two forms are nondeterministic. In (5), a is assigned an element of a set
E(x, v). (6) refers to P which is a before-after predicate relating the values v (before
the action) and a0 (afterwards). (6) is also the most general form of assignment and
nondeterministically selects an after-state a0 satisfying P and assigns it to a. Note
that the before-after predicates for the other two forms are as expected; namely,
a0 = E(x, v) and a0 2 E(x, v), respectively.
All assignments of an action Q(x, v) occur simultaneously, which is expressed by
conjoining together their before-after predicates. Hence each event corresponds to
a before-after predicate Q(x, v, v0 ) established by conjoining all before-after predi-
cates associated with each assignment and b = b0 , where b are unchanged variables.
Note that the initialisation init therefore corresponds to an after predicate K(v0 ),
since there are no states before initialisation.

5.1.1 Proof Obligations

We describe below some important proof obligation rules for Event-B machines,
namely, invariant establishment and preservation, and action feasibility.

Invariant Establishment and Preservation

An essential feature of an Event-B machine M is its invariant I(v). It shows proper-

ties that hold in every reachable states of the machine. Obviously, this does not hold
priori for any machines and invariants, therefore must be proved. A common tech-
nique for proving an invariant property is to prove it by induction: (1) to prove that
the property is established by the initialisation init (invariant establishment), and
(2) to prove that the property is maintained whenever variables change their values
(invariant preservation).
Invariant establishment states that any possible state after initialisation given by
the after predicate K(v0 ) must satisfy the invariant I. The proof obligation rule is as
follows.
K(v0 ) ` I(v0 ) (INV)
10 Thai Son Hoang

Invariant preservation requires to prove that every event occurrences re-establish

the invariants I. More precisely, for every event e, under the assumption of the in-
variants I and e’s guard G, we must prove that the invariants still hold in any possible
state after the event’s execution given by the before-after predicate Q(x, v, v0 ). The
proof obligation rule is as follows.

I(v), G(x, v), Q(x, v, v0 ) ` I(v0 ) (INV)

Note that in practice, by the property of conjunctivity, we can prove the estab-
lishment and preservation of each invariant separately.

Feasibility

Feasibility states that the action of an event is always feasible whenever the event
is enabled. In other words, there are always possible after values for the variables,
satisfying the before-after predicate. In practice, we prove feasibility for individual
assignment of the event action. For deterministic assignments, feasibility holds triv-
ially. The feasibility proof obligation generated for a non-deterministic assignment
of the form a :| P(x, v, a0 ) is as follows.

I(v), G(x, v) ` 9a0 ·P(x, v, a0 ) (FIS)

5.2 Event Convergence

A set of events can be proved to collectively converge. In other words, these events
cannot take control forever and hence one of the other events eventually occurs. We
call these events convergent. To prove this, one gives a variant V, which maps a state
v to a natural number. One then proves that each convergent event strictly decreases
V. More precisely, let e be a convergent event, where v is the state before executing
e and v0 is the state after. Then for each such e, v, and v0 , one proves that V(v0 ) <
V(v), under the additional assumptions of all invariants and of the guard of e. Since
the variant maps a state to a natural number, V induces a well-founded ordering
on system states given by the strictly less than order (<) of their images under V.
The following proof obligation rules apply to every convergent event, where VAR
concerns with the decrement of the variant and NAT ensures that the variant is a
natural number when the event is enabled.

I(v), G(x, v), Q(x, v, v0 ) ` V(v0 ) < V(v) (VAR)

I(v), G(x, v) ` V(v) 2 N (NAT)

Note that in some cases the convergence of some events cannot be immediately
shown, but only in a later refinement. In this case, their convergence is anticipated
An Introduction to Event-B 11

and we must prove that V(v0 )  V(v), that is, these anticipated events do not increase
the variant. Anticipated events must obey NAT, and the following proof obligation
rule, also called VAR.

I(v), G(x, v), Q(x, v, v0 ) ` V(v0 )  V(v) (VAR)

As mentioned above, the variant V is a natural number. Alternatively, V can be

a finite set expression. In this case, for convergent events, one has to prove that it
decreases the variant according to the strict subset-inclusion ⇢ ordering. For antici-
pated events, we ensure that these events do not increase the variant by proving that
V(v0 ) ✓ V(v). The proof obligation rule VAR is adapted accordingly.
For proving that the variant V is a finite set, the following proof obligation rule
called FIN applies.
I(v) ` finite(V(v)) (FIN)
Note that FIN needs to be proved once, i.e., does not depend on the set of convergent
and anticipated events (cf. NAT).
The convergence attribute of an event is denoted by the keyword status with
three possible values: convergent, anticipated, and ordinary (for events which are
neither convergent nor anticipated). Events are ordinary by default.

5.3 Deadlock-freeness

A machine M is said to be deadlocked in some state if all of its events are disabled
in that state. Deadlock-freeness for M ensures that there are always some enabled
events during M’s execution. Assume that M contains a set of n events ei (i 2 1 . . . n)
of the following form.

b any xi where Gi (xi , v) then Qi (xi , v) end

ei =

The proof obligation rule for deadlock-freeness3 is as follows.

I(v) ` (9x1 ·G1 (x1 , v)) _ . . . _ (9xn ·Gn (xn , v)) (DLF)

5.4 Example. Machine m0

We develop machine m0 of the initial model, focusing on courses opening and clos-
ing. This machine sees context coursesCtx as developed in Section 4.1, hence as a
result has access to the carrier set CRS and constant m. We model the set of opened
courses by a variable, namely crs (REQ 5). Invariant inv0 1 states that it is a subset
of available courses CRS. A consequence of this invariant and of axiom axm0 1 is
3 Typically, this is encoded as a theorem in the machine after all invariants.
12 Thai Son Hoang

that crs is finite, and this is stated in m0 as theorem thm0 2. Requirement REQ 8 is
directly captured by invariant inv0 2: the number of opened courses, i.e., card(crs)
is bounded above by m. Initially, all courses are closed hence crs is set to the empty
set (?).

invariants: init
inv0 1 : crs ✓ CRS begin
variables: crs thm0 2 : finite(crs) crs := ?
inv0 2 : card(crs)  m end

We model the opening and closing of courses using two events OpenCourses and
CloseCourses as follows (REQ 6 and REQ 7).

OpenCourses CloseCourses
status ordinary status anticipated
when any cs where
grd0 1 : card(crs) 6= m grd0 1 : cs ✓ crs
thm0 3 : crs 6= CRS grd0 2 : cs 6= ?
then then
act0 1 : crs :| crs ⇢ crs0 ^ card(crs0 )  m act0 1 : crs := crs \ cs
end end

We choose purposely to model these events using different features of Event-B. In

OpenCourses, we use a nondeterministic action to model the fact that some new
courses are opened, i.e., crs ⇢ crs0 , as long as the number of opened courses will not
exceed its limit, i.e., card(crs0 )  m. The guard of the event states that the current
number of opened courses has not yet reached the limit.
CloseCourses models the set of courses that are going to be closed using pa-
rameter cs. It is a non-empty set of currently opened courses which is captured by
CloseCourses’ guard. The action is modelled straightforwardly by removing cs out
of the set crs.
We set the convergence status for OpenCourses and CloseCourses to be ordi-
nary and anticipated, respectively. We delay the reasoning about the convergence of
CloseCourses to later refinements. Our intention is to prove that there can be only
finitely many occurrences of CloseCourses between any two OpenCourses events.

5.4.1 Proof obligations

We present some of the obligations to illustrate what needs to be proved for the
consistency of m0. We applied the proof obligation rules as showed earlier in this
Section. Notice that we can take the axioms and theorems of the seen context
coursesCtx as hypotheses in the proof obligations. For clarity, we show only parts
of the hypotheses that are relevant for discharging the proof obligations. Moreover,
we also show the proof obligations in their simplified form, e.g., when the events’
assignments are deterministic.
An Introduction to Event-B 13

thm0 2/THM

This obligation corresponds to the rule THM, in order to ensure that thm0 2 is
derivable from previously declared invariants.

...
finite(CRS)
crs ✓ CRS thm0 2/THM
`
finite(crs)

The proof obligation holds trivially since crs is a subset of a finite set, i.e., CRS.

init/inv0 2/INV

This obligation ensures that the initialisation init establishes invariant inv0 2.

...
0m init/inv0 2/INV
`
card(?)  m

Since the cardinality of the empty set ? is 0, the proof obligation holds trivially.

OpenCourses/thm0 3/THM

This obligation ensures that thm0 3 is derivable from the invariants and the previ-
ously declared guards of OpenCourses.

...
m  card(CRS)
crs 2 P(CRS)
card(crs)  m OpenCourses/thm0 3/THM
card(crs) 6= m
`
crs 6= CRS

Informally, we can derive from the hypotheses that card(crs) < card(CRS), hence
crs must be different from CRS.

OpenCourses/act0 1/FIS

This obligation corresponds to rule FIS and ensures that the nondeterministic as-
signment of OpenCourses is feasible when the event is enabled.
14 Thai Son Hoang

...
crs 6= CRS
card(crs)  m OpenCourses/act0 1/FIS
card(crs) 6= m
`
9crs0 ·crs ⇢ crs0 ^ card(crs0 )  m

The reasoning about the proof obligation is as follows. Since crs is different from
CRS, there exists an element c which is closed, i.e., not in crs. By adding c to the set
of opened courses, we strictly increase the number of opened courses by 1. More-
over, the number of opened courses after executing the event is still within the limit
since originally it is strictly below the limit.

CloseCourses/inv0 2/INV

This obligation corresponds to rule INV and is simplified accordingly since the as-
signment is deterministic. The purpose of the obligation is to prove that CloseCourses
maintains invariant inv0 2.

...
card(crs)  m CloseCourses/inv0 2/INV
`
card(crs \ cs)  m

Since removing some courses cs from the set of opened courses crs can only reduce
its number, the proof obligation can be trivially discharged.

DLF/THM

The deadlock-freeness condition is encoded as theorem DLF of machine m0, which

results in the following proof obligation.

...
0<m DLF/THM
`
(card(crs) 6= m) _ (9cs·cs ✓ crs ^ cs 6= ?)

We reason as follows. If card(crs) 6= m, the goal trivially holds. Otherwise, i.e.,

card(crs) = m, since m 6= 0, we have that crs 6= ?. As a result, we can prove that
9cs·cs ✓ crs ^ cs 6= ? by instantiating cs with crs itself.
An Introduction to Event-B 15

6 Context Extension

Context extension is a mechanism for introducing more static details into an Event-
B development. A context can extend one or more contexts. When mentioning that
a context D extends another context C, we call C and D the abstract context and
concrete context, respectively. By extending C, D “inherits” all the abstract elements
of C, i.e., carrier sets, constants, axioms and theorems. This means that (1) a context
extending D also implicitly extends C, (2) a machine seeing D also implicitly sees
C. As a result, proof obligation rule THM for D also has additional assumptions in
the form of the axioms and theorems from the abstract context C.
Subsequently, we present three new contexts that we use in the next refinement
of our running example.

6.1 Context membersCtx

This is an initial context (i.e., does not extend any other context) containing a carrier
sets MEM. MEM represents the set of club members, with an axiom stating that it
is finite.
axioms:
carrier sets: MEM axm1 1 : finite(MEM)

6.2 Context participantsCtx

This context extends the previously defined context membersCtx and is as follows.

axioms:
constants: PRTCPT axm1 2 : PRTCPT ✓ MEM
thm1 1 : finite(PRTCPT)

Constant PRTCPT denotes the set of participants which must be members of the
club as specified in ASM 2 (axm1 2). Theorem thm1 1 states that there can be
only a finite number of participants, which gives rise to the following trivial proof
obligation.

finite(MEM)
PRTCPT ✓ MEM thm1 1/THM
`
finite(PRTCPT)

An important point is that axiom axm1 1 of the abstract context membersCtx ap-
pears as a hypothesis in the proof obligation.
16 Thai Son Hoang

6.3 Context instructorsCtx

This context extends two contexts coursesCtx and membersCtx, and introduces two
constants, namely INSTR and instrs. INSTR models the set of instructors which are
members of the club as specified by ASM 1 (axm1 3). Constant instrs models the
relationship between courses and instructors and is constrained by axm1 4: it is a
total function from CRS to INSTR, hence directly formalises requirement ASM 4.
Recall the definition of a total function f from a set S to a set T: f is a relation from
S to T where every element in S has exactly one mapping to some element in T.

axioms:
constants: INSTR, instrs axm1 3 : INSTR ✓ MEM
axm1 4 : instrs 2 CRS ! INSTR

The hierarchy of context extensions for our example is summarised in the fol-
lowing diagram.
coursesCtx membersCtx

instructorsCtx participantsCtx

7 Machine Refinement

Machine refinement is a mechanism for introducing details about the dynamic prop-
erties of a model [2]. For more details on the theory of refinement, we refer the
reader to the Action System formalism [4], which has inspired the development of
Event-B. We present here the proof obligations defined in Event-B related to refine-
ment. When speaking about a machine N refining another machine M, we refer to
M as the abstract machine and N as the concrete machine.
Despite the fact that the formal definition of Event-B refinement does not distin-
guish between superposition refinement and data refinement, we illustrate them in
separate sections to show different aspects of the two. In superposition refinement,
the abstract variables of M are retained in the concrete machine N, with possibly
some additional concrete variables. In data refinement, the abstract variables v are
replaced by concrete variables w and, subsequently, the connection between M and
N are represented by the relationship between v and w. In fact, more often, Event-B
refinement is a mixture of both superposition and data refinement: some abstract
variable are retained, while the others are replaced by new concrete variables.
An Introduction to Event-B 17

7.1 Superposition Refinement

As mentioned earlier, in superposition refinement, variables v of the abstract ma-

chine M are kept in the refinement, i.e., as part of the state of N. Moreover, N can
have some additional variables w. The concrete invariants J(v, w) specify the rela-
tionship between the old and new variables. Each abstract event e is refined by a
concrete event f (later on we will relax this one-to-one constraint). Assume that the
abstract event e and the concrete event f are as follows.

b any x where G(x, v) then Q(x, v) end

e =
b any x where H(x, v, w) then R(x, v, w) end
f =

We assume now that e and f have the same parameters x. The more general case,
where the parameters are different, is presented in Section 7.2.
Somewhat simplifying, we say that f refines e if the guard of f is stronger than that
of e (guard strengthening), concrete invariants J are maintained by f, and abstract
action Q simulates the concrete action R (simulation). These conditions are stated
as the following proof obligation rules.

I(v), J(v, w), H(x, v, w) ` G(x, v) (GRD)

I(v), J(v, w), H(x, v, w), R(x, v, w, v0 , w0 ) ` Q(x, v, v0 ) (SIM)

I(v), J(v, w), H(x, v, w), R(x, v, w, v0 , w0 ) ` J(v0 , w0 ) (INV)
In particular, if the guard and action of an abstract event are retained in the concrete
event, the proof obligations GRD and SIM are trivial, hence we only need to consider
INV for proving that the gluing invariants are re-established.
Proof obligations are generated to ensure that each assignment of concrete event
f is feasible. In the case where the action of the abstract event is retained in f, we
only need to prove the feasibility of any additional assignment.
In the course of refinement, new events are often introduced into a model. New
events must be proved to refine the implicit abstract event SKIP, which does nothing,
i.e., does not modify abstract variables v.

7.1.1 Machine m1

Machine m1 sees contexts instructorsCtx and participantsCtx. As a result, it im-

plicitly sees coursesCtx and membersCtx. Variable crs is retained in this refine-
ment. An additional variable prtcpts representing information about course partici-
pants is introduced. Invariant inv1 1 models prtcpts as a relation between the set of
opened courses crs and the set of participants PRTCPT. Requirement REQ 10 is di-
rectly modelled by invariant inv1 2: for every opened course c, the instructor of that
course, i.e., instrs(c), is not amongst its participants, represented by prtcpts[{c}].
18 Thai Son Hoang

invariants:
variables: crs, prtcpts inv1 1 : prtcpts 2 crs $ PRTCPT
inv1 2 : 8c · c 2 crs ) instrs(c) 2
/ prtcpts[{c}]

init
begin
...
prtcpts := ?
end

Initially, there are no opened courses hence prtcpts is assigned to be ?.

The original abstract event OpenCourses stays unchanged in this refinement,
while an additional assignment is added to CloseCourses to update prtcpts by re-
moving the information about the set of closing courses cs from it.

CloseCourses
status anticipated
any cs where
...
then
...
act1 2 : prtcpts := cs C prtcpts
end

A new event is added, namely Register, to model the registration of a participant

p for an opened course c. The guard of the event ensures that p is not the instructor
of the course (grd1 3) and is not yet registered for the course (grd1 4). The action
of the event update prtcpts accordingly by adding the mapping c 7! p to it.

Register
status convergent
any p, c where
grd1 1 : p 2 PRTCPT
grd1 2 : c 2 crs
grd1 3 : p 6= instrs(c)
grd1 4 : c 7! p 2/ prtcpts
then
act1 1 : prtcpts := prtcpts [ {c 7! p}
end

We attempt to prove that Register is convergent and CloseCourses is anticipated

using the following variant.

variant: (crs ⇥ PRTCPT) \ prtcpts

The variant is a set of mappings, each links an opened course to a participant who
has not registered for the respective course.
We present some of the important proof obligations for m1. For events OpenCourses
and CloseCourses, proof obligations GRD and SIM are trivial. Consequently, we
only need to consider INV for these old events.
An Introduction to Event-B 19

CloseCourses/inv1 2/INV

This obligation is to ensure that inv1 2 is maintained by CloseCourses. The obliga-

/ cs, we have (cs C prtcpts)[{c}] is the same
tion is trivial, in particular, given that c 2
as prtcpts[{c}].

...
8c · c 2 crs ) instrs(c) 2
/ prtcpts[{c}] CloseCourses/inv1 2/INV
`
/ (cs C prtcpts)[{c}]
8c · c 2 crs \ cs ) instrs(c) 2

Register/inv1 1/INV

This obligation is to guarantee that inv1 1 is maintained by the new event Register.

...
prtcpts 2 crs $ PRTCPT
p 2 PRTCPT Register/inv1 1/INV
c 2 crs
`
prtcpts [ {c 7! p} 2 crs $ PRTCPT

FIN

This obligation is to ensure that the declared variant used for proving convergence
of events is finite (FIN). This is trivial, since the set of opened course crs and the set
of participants PRTCPT are both finite.

...
finite(crs)
finite(PRTCPT) FIN
`
finite((crs ⇥ PRTCPT) \ prtcpts)

CloseCourses/VAR

This proof obligation corresponds to rule VAR ensuring that anticipated event
CloseCourses does not increase the variant.
20 Thai Son Hoang

...
`
((crs \ cs) ⇥ PRTCPT) \ (cs C prtcpts) CloseCourses/VAR
✓
(crs ⇥ PRTCPT) \ prtcpts)

Register/VAR

This proof obligation corresponds to rule VAR to ensure that the convergent event
Register decreases the variant. This is trivial since a new mapping c 7! p is added to
prtcpts, effectively increasing prtcpts, hence strictly decreasing the variant.

...
c 7! p 2
/ prtcpts
` Register/VAR
(crs ⇥ PRTCPT) \ (prtcpts [ {c 7! p}))
⇢
(crs ⇥ PRTCPT) \ prtcpts)

7.2 Data Refinement

In data refinement, abstract variables v are removed and replaced by concrete vari-
ables w. The states of abstract machine M are related to the states of concrete ma-
chine N by gluing invariants J(v, w). In Event-B, the gluing invariants J are declared
as invariants of N and also contain the local concrete invariants, i.e., those constrain-
ing only concrete variables w.
Again, we assume the one-to-one correspondence between an abstract event e
and a concrete event f. Let e and f be as follows4 .

b any x where G(x, v) then Q(x, v) end

e =
b any y where H(y, w) then R(y, w) end
f =

Similar to superposition refinement, we can say that f refines e if the guard of f is

stronger than the guard of e (guard strengthening), and the gluing invariants J(v, w)
establish a simulation of f by e (simulation). This condition is captured by the fol-
lowing proof obligation rule.

4 Concrete events may be annotated with abstract events name and witnesses, which we will show
later.
An Introduction to Event-B 21

I(v)
J(v, w)
H(y, w)
(7)
R(y, w, w0 )
`
9x, v0 ·G(x, v) ^ Q(x, v, v0 ) ^ J(v0 , w0 )

In order to simplify and split the above proof obligation, Event-B introduces the
notion of “witnesses” for the abstract parameters x and the after value of the ab-
stract variables v0 . Witnesses are predicates of the form W1 (x, y, v, w, w0 ) (for x), and
W2 (v0 , y, v, w, w0 ) (for v0 ), which are required to be feasible. The corresponding proof
obligations are as follows.

I(v), J(v, w), H(y, w), R(y, w, w0 ) ` 9x·W1 (x, y, v, w, w0 ) (WFIS)

I(v), J(v, w), H(y, w), R(y, w, w0 ) ` 9v0 ·W2 (v0 , y, v, w, w0 ) (WFIS)
Typically, the witnesses are declared deterministically, i.e., of the form x = . . . or
v0 = . . .. In these cases, the witnesses are trivially feasible, hence the corresponding
proof obligations are omitted.
Given the witnesses, the refinement proof obligation (7) is replaced by three dif-
ferent proof obligations as follows.

I(v), J(v, w), H(y, w), W1 (x, y, v, w, w0 ) ` G(x, v) (GRD)

I(v), J(v, w), H(y, w), R(y, w, w0 ), W1 (x, y, v, w, w0 ), W2 (v0 , y, v, w, w0 ) ` Q(x, v, v0 )

(SIM)
I(v), J(v, w), H(y, w), R(y, w, w0 ), W1 (x, y, v, w, w0 ), W2 (v0 , y, v, w, w0 ) ` J(v0 , w0 )
(INV)
The concrete event f can be denoted with the abstract event e (using keyword
refines) and the witnesses (using keyword with), as follows.

f
refines e
any y where
H(y, w)
with
x : W1 (x, y, v, w, w0 )
v0 : W2 (v0 , y, v, w, w0 )
then
R(y, w)
end

The action of the concrete event is required to be feasible. The corresponding

proof obligation FIS is similar to the one presented for the abstract machine, with
the exception that both abstract and gluing invariants can be assumed.
22 Thai Son Hoang

For newly introduced events, similar to superposition refinement, they must be

proved to refine the implicit abstract event SKIP, which is unguarded and does noth-
ing, i.e., does not modify abstract variables v. In this case, GRD is trivial, since the
abstract guard is >. For SIM and INV, we omit references to W1 (since there are no
parameters for the abstract SKIP event). Moreover, the witness W2 for v0 is trivial:
v0 = v.
As mentioned earlier, in general, Event-B refinement is a mixture of both super-
position and data refinement. Often, some (not all) abstract variables are retained
in the refinement, while the other abstract variables are replaced by new concrete
variables. Similarly, some abstract parameters can be present in the concrete event,
where other parameters are replaced by some new concrete parameters. In general,
we only need to give witnesses to disappearing variables and parameters.
The one-to-one correspondence between the abstract and concrete events can be
relaxed. When an abstract event e is refined by more than one concrete event f,
we say that the abstract event e is split and prove that each concrete f is a valid
refinement of the abstract event. Conversely, several abstract events e can be re-
fined by one concrete f. We say that these abstract events are merged together. A
requirement for merging events is that the abstract events must have identical ac-
tions. When merging events, we need to prove that the guard of the concrete event
is stronger than the disjunction of the guards of the abstract events.
The concrete machine N can be proved to be relatively deadlock-free with respect
to the abstract machine M. It means that if M can continue in some state, so can N.
Assume that M contains a set of n events ei (i 2 1 . . . n) of the following form.

b any xi where Gi (xi , v) then Qi (xi , v) end

ei =

Assume that N contains a set of m events f j ( j 2 1 . . . m) of the following form.

b any yi where Hi (yi , w) then Ri (yi , w) end

fj =

The proof obligation rule for relative deadlock-freeness5 is as follows.

I(v)
J(v, w)
(9x1 ·G1 (x1 , v)) _ . . . _ (9xn ·Gn (xn , v)) (REL DLF)
`
(9y1 ·H1 (y1 , w)) _ . . . _ (9ym ·Hm (ym , w))

7.2.1 Machine m2

We perform a data refinement by replacing abstract variables crs and prtcpts by a

new concrete variable atnds. This machine does not explicitly model any require-
5 Typically, this is encoded as a theorem in N after declaration of all invariants.
An Introduction to Event-B 23

ments from Section 3: it implicitly inherits requirements from previous abstract ma-
chines. As stated in invariant inv2 1, atnds is a partial function from CRS to some
set of participants (i.e., member of P(PRTCPT)). Invariants inv2 2 and inv2 3 act
as gluing invariants, linking abstract variables crs and prtcpts with concrete vari-
able atnds. Invariant inv2 2 specifies that crs is the domain atnds. Invariant inv2 3
states that for every opened courses c, the set of participants attending that course
represented abstractly as prtcpts[{c}] is the same as atnds(c).

invariants:
inv2 1 : atnds 2 CRS ! 7 P(PRTCPT)
variables: atnds inv2 2 : crs = dom(atnds)
inv2 3 : 8c·c 2 crs ) prtcpts[{c}] = atnds(c)
thm2 1 : finite(atnds)

init
begin
atnds := ?
end

We illustrate our data refinement by the following example. Assume that the avail-
able courses CRS are {c1 , c2 , c3 }, with c1 and c2 being opened, i.e., crs = {c1 , c2 }.
Assume that c1 has no participants, and p1 and p2 are attending c2 . Abstract vari-
able prtcpts hence contains two mappings as follows {c2 7! p1 , c2 7! p2 }. The
same information can be represented by the concrete variable atnds as follows
{c1 7! ?, c2 7! {p1 , p2 }}.
We refine the events using data refinement as follows. Event OpenCourses is
refined by OpenCourse where one course (instead of possibly several courses) is
opened at a time. The course that is opening is represented by the concrete parameter
c.

OpenCourse
refines OpenCourses
OpenCourses
any c where
when
grd2 1 : c 2 / dom(atnds)
grd0 1 : card(crs) 6= m
grd2 2 : card(atnds) 6= m
thm0 1 : crs 6= CRS
with
then
crs0 = crs [ {c}
act0 1 : crs :| crs ⇢ crs0 ^ card(crs0 )  m
then
end
act2 1 : atnds(c) := ?
end

The concrete guards ensure that c is a closed course and the number of opened
course (card(atnds)) has not reached the limit m. The action of OpenCourse sets the
initial participants for the newly opened course c to be the empty set. In order to
prove the refinement relationship between OpenCourse and OpenCourses, we need
to give the witness for the after value of the disappearing variable crs0 . In this case, it
is specified as crs0 = crs [ {c}, i.e., adding the newly opened course c to the original
set of opened courses crs.
24 Thai Son Hoang

Abstract event CloseCourses is refined by concrete event CloseCourse, where one

course c (instead of possibly several courses cs) is closed at a time. The guard and
action of concrete event CloseCourse are as expected.

CloseCourse
CloseCourses
refines CloseCourses
status anticipated
status convergent
any cs where
any c where
grd0 1 : cs ✓ crs
grd2 1 : c 2 dom(atnds)
grd0 2 : cs 6= ?
with
then
cs = {c}
act0 1 : crs := crs \ cs
then
act2 : prtcpts := cs C prtcpts
act2 1 : atnds := {c} C atnds
end
end

We need to give the witness for the disappearing abstract parameter cs. It is specified
straightforwardly as cs = {c}. Notice also that we change the convergence status of
CloseCourse from anticipated to convergent. We use the following variant to prove
that CloseCourse is convergent.

variant: card(atnds)

The variant represents the number of mappings in atnds, and since it is a par-
tial function, it is also the same as the number of elements in its domain, i.e.,
card(atnds) = card(dom(atnds)). As a result, the variant represent the number of
opened courses.
Event Register is refined as follows6 , such that references to crs and prtcpts in
guard and action are replaced by references to atnds.

(cnc )Register
(abs )Register
refines Register
any p, c where
any p, c where
grd1 1 : p 2 PRTCPT
grd2 1 : p 2 PRTCPT
grd1 2 : c 2 crs
grd2 2 : c 2 dom(attendees)
grd1 3 : p 6= instrs(c)
grd2 3 : p 6= instrs(c)
grd1 4 : c 7! p 2/ prtcpts
grd2 4 : p 2/ atnds(c)
then
then
act1 1 : prtcpts := prtcpts [ {c 7! p}
act2 1 : atnds(c) := atnds(c) [ {p}
end
end

We now show some proof obligations for proving the refinement of m1 by m2.

OpenCourse/act0 1/SIM

This proof obligation corresponds to rule SIM, to ensure that the action act0 1 of
abstract event OpenCourses can simulate the action of concrete event OpenCourse.
Notice the use of the witness for crs0 as a hypothesis in the obligation.

6 We use prefixes (abs ) and (cnc ) to denote the abstract and concrete version of the event,
accordingly.
An Introduction to Event-B 25

...
atnds 2 CRS ! 7 P(PRTCPT)
crs = dom(attendees)
c2/ dom(attendees) OpenCourse/act0 1/SIM
card(attendees) 6= m
crs0 = crs [ {c}
`
crs ⇢ crs0 ^ card(crs0 )  m

CloseCourse/grd0 1/GRD

This proof obligation corresponds to rule GRD, to ensure that the guard of con-
crete event CloseCourse is stronger than the abstract guard grd0 1 of abstract event
CloseCourses. Note the use of the witness for cs as a hypothesis in the obligation.

...
crs = dom(atnds)
c 2 dom(atnds) CloseCourse/grd0 1/GRD
cs = {c}
`
cs ✓ crs

CloseCourse/NAT

This proof obligation corresponds to rule NAT on page 10, it ensures that the variant
is a natural number when CloseCourse is enabled.

...
finite(atnds) CloseCourse/NAT
`
card(atnds) 2 N

CloseCourse/VAR

This proof obligation corresponds to rule VAR on page 10, it ensures that the vari-
ant is strictly decreased by CloseCourse. The obligation is trivial since the variant
represents the number of opened courses and CloseCourse closes one of them.

...
atnds 2 CRS !
7 PRTCPT
c 2 dom(atnds) CloseCourse/VAR
`
card({c} C atnds) < card(atnds)
26 Thai Son Hoang

8 Summary of the Development

The summary of the hierarchy of the development is illustrated in Figure 1.

coursesCtx m0

membersCtx instructorsCtx m1

participantsCtx m2

Legend

: extends : refines : sees

Fig. 1 Development hierarchy

Table 2 summarises how assumptions and requirements are taken into account in
our formal development. Note that the last refinement m2 does not explicitly take
into account any requirements. Indeed, the requirements are implicitly inherited
from the abstract machines through the refinement relationship.

Requirement Models Requirement Models

ASM 1 instructorsCtx REQ 6 m0
ASM 2 participantsCtx REQ 7 m0
ASM 3 coursesCtx REQ 8 m0
ASM 4 instructorsCtx REQ 9 m1
REQ 5 m0 REQ 10 m1
Table 2 Requirements Tracing

The development is formalised and proved using supporting Rodin platform7 for
Event-B [3] and is available on-line8 . The summary of the proof statistics for the
development is showed in Table 3. Around 50% of the proof obligations appear in
m2, where we perform data refinement. Typically, data refinement involves radical

7 At the time of writing, we use Rodin version 2.4.0.

8 http://deploy-eprints.ecs.soton.ac.uk/371/
An Introduction to Event-B 27

changes to developments, since by replacing abstract variables with concrete vari-

ables, it is also necessary to adapt the events accordingly.

Constructs Proof obligations Automatic (%) Manual (%)

coursesCtx 2 2 (100%) 0 (0%)
membersCtx 0 0 (N/A) 0 (N/A)
instructorsCtx 0 0 (N/A) 0 (N/A)
participantsCtx 1 1 (100%) 0 (0%)
m0 11 8 (73%) 3 (27%)
m1 14 13 (93%) 1 (7%)
m2 29 26 (90%) 3 (10%)
Total 57 50 (88%) 7 (12%)
Table 3 Proof statistics

References

1. J-R. Abrial. The B-Book: Assigning Programs to Meanings. Cambridge University Press, 1996.
2. J-R. Abrial. Modeling in Event-B: System and Software Engineering. Cambridge University
Press, May 2010.
3. J-R. Abrial, M. Butler, S. Hallerstede, T.S. Hoang, F. Mehta, and L. Voisin. RODIN: An open
toolset for modelling and reasoning in Event-B. Internation Journal on Software Tools for
Technology Transfer (STTT), April 2010.
4. R-J. Back. Refinement Calculus II: Parallel and Reactive Programs. In J. W. deBakker, W. P.
deRoever, and G. Rozenberg, editors, Stepwise Refinement of Distributed Systems, volume 430
of LNCS, pages 67–93, Mook, The Netherlands, May 1989. Springer-Verlag.
5. K. Chandy and J. Misra. Parallel Program Design: a Foundation. Addison-Wesley, 1989.
6. L. Lamport. The temporal logic of actions. Transactions on Programming Languages and
Systems (TOPLAS), 16(3):872–923, May 1994.
7. F. Mehta. Proofs for the Working Engineer. PhD thesis, ETH-Zurich, 2008.
8. M. Schmalz. The logic of Event-B. Technical Report 698, Institute of Information
Security, October 2010. http://www.inf.ethz.ch/research/disstechreps/
techreports/show?serial=698&lang=en.