Content uploaded by David Déharbe

Author content

All content in this area was uploaded by David Déharbe on Jun 15, 2020

Content may be subject to copyright.

Existence Proof Obligations

for Constraints, Properties and Invariants

in Atelier B

H´ector Ru´ız Barradas, Lilian Burdy, and David D´eharbe(B

)

CLEARSY Systems Engineering, Aix-en-Provence, France

david.deharbe@clearsy.com

Abstract. Proof obligations of the B method and of Event B use

predicates in the Constraints, Sets, Properties and Invariant clauses

as hypotheses in proof obligations. A contradiction in these predicates

results in trivially valid proof obligations and essentially voids the devel-

opment. A textbook on the B method [3] presents three “existence proof

obligations” to show the satisﬁability of the Constraints, Properties and

Invariant clauses as soon as they are stated in a component. Together

with new existence proof obligations for reﬁnement, this prevents the

introduction of such contradictions in the reﬁnement chain. This paper

presents a detailed formalization of these existence proof obligations,

specifying their implementation in Atelier B.

1 Introduction

The vaunted rigour of formal methods, such as B and Event-B, not only come

from the use of a formal notation, but also from the generation and subsequent

veriﬁcation of proof obligations (POs). For instance, in Event-B [2], the model

of a system is considered sound only when all POs have been demonstrated. In

the B method [1], they guarantee that the reﬁnement-based construction results

in implementations faithful to their speciﬁcation.

Typically, POs are generated at key steps of the design process. Invalid POs

reveal errors in the source artefact. By inspecting these proof obligations, the

user then identiﬁes, possibly, remaining errors and ﬁxes the source artefact. The

process is repeated until all POs are discharged. To conduct the demonstrations,

these methods demand that they are conducted with tools. In practice, this is

accomplished by a mix of automatic proof and interactive proof. POs are thus

the cornerstone of every such formal development.

A PO has the form HG, with Ha set of hypotheses, and Gthe goal.

Its validity may stem from a contradiction in H, i.e. have nothing to do with

the goal. In the context of B and Event-B, a component with contradictory

hypotheses in its POs will be (trivially) correct. In large developments, a contra-

diction may stay undetected. B addresses this issue with POs associated at the

implementation level, i.e. at the very end of the development. At that point, this

requires ﬁxing the reﬁnement chain up to the source of the contradiction, which

c

Springer Nature Switzerland AG 2020

A. Raschke et al. (Eds.): ABZ 2020, LNCS 12071, pp. 255–259, 2020.

https://doi.org/10.1007/978-3-030-48077-6_20

256 H. Ru´ız Barradas et al.

is costly. Also, components in a B project that do not have an implementation

(e.g., foreign interfaces) are not protected. Event-B does not fully address this

issue.

Such situations can be easily avoided by adding so called “existence” POs

whenever a contradiction may be introduced. An existence PO has the form

Γ⇒∃V·(ϕ), where Γis the context predicate, ϕthe predicate that shall not

be contradictory, and Va list of identiﬁers. A textbook on B [3] presents these

POs, but without considering component visibility, inclusion and reﬁnement.

Existing tools for B and Event-B do not generate these, and we decided to add

it to Atelier B. We present the formalization of the POs for the speciﬁcation

(Sect. 2) and the reﬁnement (Sect. 3) levels. We discuss the case of standalone

components, and generalize to components with dependencies.

2 Existence Proof Obligations in Speciﬁcations

Existence for Parameters. In B, speciﬁcation components may have sets and

scalar parameters. The constraints clause can be used to constrain these

parameters. When the machine is instantiated, a PO asks to prove the establish-

ment of the constraints clause, thus guaranteeing the absence of contradic-

tions. If the parametrized machine is not instantiated, the constraints clause

can contain undetected contradictions because no PO exists to detect them. Let

pdenote the parameters, Cthe predicate in the constraint clause, the existence

PO given by [3] for parameters is ∃p·C. It has been implemented as such in

Atelier B.

Existence for Sets and Constants. The properties clause state constraints on

sets and constants declared respectively in the sets and constants clauses.

Enumerated sets have a single possible valuation, and abstract sets must satisfy

the implicit constraint that they are ﬁnite non-empty sets of integers. In this

way, in order to prove the absence of contradictions in the predicate Pof the

properties clause of a single machine, with no seen or included components,

we deﬁne the following PO: esets ⇒∃(c, s)·(P∧asets ), where esets is the

conjunction of declarations of enumerated sets in the sets clause, cis the list of

abstract and concrete constants, sis the list of abstract sets, and asets is the

conjunction of predicates t∈FIN 1(INTEGER) for each variable tin s. Notice

that the visibility rules of the language prohibit parameters in the predicate P,

so it is useless to have predicate Cas an antecedent.

If there are seen components in the machine, the predicates in the prop-

erties clause from the seen components and their included components are in

the antecedent of the PO. Moreover, for each abstract set udeclared in the seen

machine or declared in a machine included by the seen machine, the antecedent

of the PO contains a predicate u∈FIN 1(INTEGER). The deﬁnition of each

enumerated set wdeclared in these machines is also in the antecedent.

If the machine includes components, the deﬁnition of their enumerated sets

are in the antecedent of the PO, their abstract and concrete constants and the

Existence Proof Obligations for B and Event-B 257

identiﬁers of their abstract sets are existentially quantiﬁed in the consequent

and the predicates of their properties clauses, together with the corresponding

asets predicates, are in the body of the existential quantiﬁer.

Following is an example of the existence PO for the sets,constants and

properties clauses for a standalone component:

sets

S1; S2={UM ,DOIS ,TRES };

S3={UN ,DEUX }

constants

c1,e1,e2,e3

properties

c1∈NAT ∧e1∈INT ∧

e2∈S2∧e3∈S1∧

(e2=UM ⇒e1 = 1))

PO:

S2={UM ,DOIS ,TRES }∧

S3={UN ,DEUX }

⇒

∃(c1,e1,e2,S1) ·(

S1∈FIN (INTEGER)− {{}} ∧

c1∈NAT ∧e1∈INT ∧

e2∈S2∧e3∈S1∧

(e2=UM ⇒e1 = 1))

Existence for State Variables. The predicate invariant may also contain con-

tradictions. To prevent this, the existence PO of the invariant clause for a

standalone machine is C∧P∧all sets ⇒∃(v)·(I). The antecedent of this

PO contains the predicates Cand Pfrom the constraints and properties

clauses. The predicate all sets is the conjunction of esets and asets seen above.

The quantifed variable vdenotes the list of abstract and concrete variables of

the machine.

If there are seen or included components, the antecedent is strengthened

with the conjunction of their properties, assertions, invariants and their all sets

predicates. In this conjunction, we also consider the clauses of the components

possibly included by the seen machines. Moreover, for the included components,

the consequent of the PO quantiﬁes over their variables and invariants.

3 Existence Proofs in Reﬁnements

Reﬁnement in B or Event B is used for stepwise development. Reﬁnement POs

are designed to be monotonic: If a component Sis reﬁned by a component T,

these POs guarantee that the invariant of Sis also preserved by operations in T.

However, existence POs in a reﬁnement are not monotonic in that sense. When

an abstract constant or variable is reﬁned by a concrete one, we still need to

prove that the properties or invariants speciﬁed in the abstraction hold in the

reﬁnement.

Existence for Sets and Constants. For a reﬁnement with no seen or included

components and no seen or included components in any of its abstractions, the

existence PO is intended to avoid contradictions in the predicate Pof the prop-

erties clause of the reﬁnement and all properties of the previous reﬁnements,

denoted by the following predicate:

258 H. Ru´ız Barradas et al.

esets ∧abs e sets ⇒∃(c, ca,s,s

a)·(P∧asets ∧abs P ∧abs a sets )

The predicates esets and asets are deﬁned as before, abs e sets denotes the

conjunction of declarations of enumerated sets, and abs asets denotes the con-

junction of t∈FIN 1(INTEGER), for abstract sets tin previous reﬁnements.

Predicate abs Pis the conjunction of the properties predicates in the previous

reﬁnements. The variable lists cand scontain the constants of the reﬁnement

and its abstract sets. Finally, the lists caand sadenote all constants and abstract

sets in previous reﬁnements. If the reﬁnement or any of its abstractions contains

seen or included components, the antecedent and the consequent are strength-

ened with the clauses of these components as it was done in the corresponding

PO of the speciﬁcation.

Existence for State Variables. The corresponding PO deﬁned for speciﬁcation

components guarantees the absence of contradictions in the invariant. Also, the

PO of the establishment of the invariant by the initialization Initaguarantees

the existence of values of the abstract variables vasatisfying the abstract invari-

ant I(va). The PO of the reﬁnement of Initaby the initialization of a reﬁned

component Initcis not suﬃcient to guarantee the absence of contradictions in

the reﬁned invariant J(vc,v

a). Therefore, in order to prove the absence of con-

tradictions in the invariant J(vc,v

a) we need to show that the assignment of

some concrete values vto the concrete variables vcis a reﬁnement of Inita.For-

mally this reﬁnement is stated by ∃v·([vc:= v]¬[Inita]¬Jwhich must be proved

under the context of the reﬁnement. After simpliﬁcation, the existence PO for

a standalone reﬁnement and only standalone components in its abstractions is

deﬁned as follows:

C∧P∧all sets ∧abs all sets ∧abs P ⇒∃(vc)·(¬[Init a]¬J)

where abs all sets is the conjunction of predicates all sets of previous reﬁne-

ments, vcis the list of abstract and concrete variables of the reﬁnement and J

is its invariant.

If there are seen or included components, the antecedent and consequent of

the PO are strengthened with the corresponding clauses of these components.

4 Conclusion

This paper presents details of the generation of existence POs for the formal

methods B and Event-B. These POs detect inconsistencies that would make

trivial, but useless, the correctness of the components, as soon as they are intro-

duced in the development. Their generation has been implemented and will be

available in a future release of Atelier B.

Existence Proof Obligations for B and Event-B 259

References

1. Abrial, J.-R.: The B-Book, Assigning Programs to Meanings. Cambridge University

Press, Cambridge (1996)

2. Abrial, J.-R.: Modelling in Event-B, System and Software Engineering. Cambridge

University Press, Cambridge (2010)

3. Schneider, S.: The B-Method. Macmillan International, New York (2001)