Content uploaded by David Déharbe

Author content

All content in this area was uploaded by David Déharbe

Content may be subject to copyright.

arXiv:0907.2039v1 [cs.SE] 12 Jul 2009

Reﬁning interfaces: the case of the B method

David D´eharbe, Bruno E.G. Gomes, and Anamaria Martins Moreira

Universidade Federal do Rio Grande do Norte

Departamento de Inform´atica e Matem´atica Aplicada

Natal, RN, Brazil {david,bruno,anamaria}@dimap.ufrn.br

Abstract. Model-driven design of software for safety-critical applica-

tions often relies on mathematically grounded techniques such as the B

method. Such techniques consist in the successive applications of reﬁne-

ments to derive a concrete implementation from an abstract speciﬁcation.

Reﬁnement theory deﬁnes veriﬁcation conditions to guarantee that such

operations preserve the intended behaviour of the abstract speciﬁcations.

One of these conditions requires however that concrete operations have

exactly the same signatures as their abstract counterpart, which is not

always a practical requirement. This paper shows how changes of signa-

tures can be achieved while still staying within the bounds of reﬁnement

theory. This makes it possible to take advantage of the mathematical

guarantees and tool support provided for the current reﬁnement-based

techniques, such as the B method.

1 Introduction

Java Card [1] is a state-of-the-art technology that provides a programming en-

vironment for smart cards that is compatible with the Java programming lan-

guage and its underlying platform. Due to the limited processing power of the

chips found on smart cards, Java Card components are small and require few

resources. They thus provide an interesting testbed for formal approaches to

software design such as the B method [2]. The B method implements a rigorous

model-driven design approach to derive software from a functional speciﬁcation

through a series of stepwise reﬁnements. It has mature tool support and has

been successfully applied by, e.g. the railway industry, to develop the software

of safety-critical systems.

The goal of the Bsmart project [3] is to develop a customized version of the

B method for the development of Java Card software components, as well as the

corresponding tool support (as an Eclipse plug-in [4]). Applications using smart

cards have a client-server approach, where the server is a Java Card component

that provides access to the smart card services and the client is (usually) devel-

oped in Java and accesses such services through a mechanism such as a remote

method invocation. Although based on the same programming paradigms, the

type system of Java Card is much simpler and restricted than that of Java. Java

client software often requires services in a richer type system than that provided

by the Java Card services, and the APIs need to be adapted. So, in order to be

able to include a richer type system in Bsmart, it appears necessary to include

a reﬁnement step corresponding to such interface adaptation.

Unfortunately, the concept of reﬁnement used in the B method does not

allow for modiﬁcation of the signature of the operations that compose such

interfaces [2]. Retrenchment [5] is a much more ﬂexible concept of model trans-

formation, that includes changes in signature operations and, consequently, in

component interfaces. The scope of retrenchment is however much larger than

simple interface changes, and also includes handling much deeper model trans-

formations, such as, e.g. strengthening pre-conditions of operations. This ex-

tra ﬂexibility allows implementations that exhibit behaviours that are not in

the original functional speciﬁcation, which may not be desirable in a rigorous

model-based development. Also, although the proponents of retrenchment have

developed syntactic extensions to the B method to include such transforma-

tion, these extensions do not yet beneﬁt from the same level of tool support as

reﬁnement.

The goal of this paper is to show a solution to interface changes that ﬁts

within the classical theory of reﬁnement. Thus, it does not require employing

retrenchment and introducing model transformations that result in executions

that are not modeled in the initial functional speciﬁcation. In addition, the

solution proposed in this paper consists in model transformations that are fully

compatible with existing tool support for the B method. Indeed, we have deﬁned

the generic reﬁnement pattern, as well as an instance thereof, in B itself and have

used existing tools to prove their correctness.

Several authors have related interface changes with reﬁnement [6–9], however

none of thes works is related to the B method; also they change the veriﬁcation

conditions associated to reﬁnement. In [10], an approach similar to ours is pre-

sented in the context of component-based development; however they do not go

so far as to present a reﬁnement pattern as detailed as the one presented in this

paper.

Plan of the paper. Section 2 brieﬂy introduces the B method and introduces

an example that will be used throughout the paper to illustrate the diﬀerent

model transformations. Also, the main concepts of retrenchments are exposed

and discussed in Section 3. Section 4 then presents the reﬁnement pattern to in-

troduce interface changes and a model transformation instantiating this pattern

is presented in Section 5. Finally, conclusions and future work are presented in

Section 6.

2 Model-driven development with B

The B metho d for software development [2, 11] is a model-driven development

method based on formal models and formally veriﬁed derivations or reﬁnements.

It provides the B Abstract Machine Notation (AMN) to represent models at

diﬀerent levels of abstraction, based on ﬁrst order logic, integer arithmetic and

set theory. These diﬀerent levels of abstraction of a model must be related by

formally proved reﬁnements.

Industrial tools for the development of B based projects have been available

for a while now [12, 13], with speciﬁcation and veriﬁcation support as well as some

project management tasks and support for team work. More recently, various

academic and/or open source tools have spread, and Atelier B [12] has become

free of charge, increasing the popularity of the method and the variety of its

uses.

2.1 The B development process

A B speciﬁcation is structured in components. The initial model from which the

software development process initiates may be modularly composed of one or

more MACHINEs. Such models must be proved satisﬁable (i.e. that they have

an implementation) and consistent with respect to some speciﬁed properties

(namely, the INVARIANT of each MACHINE).

Once an abstract model is proved consistent, it may be used as input for

a series of (optional) reﬁnements. The result of each reﬁnement step for each

MACHINE is a new (usually less abstract) module classiﬁed as a REFINE-

MENT. The obtained reﬁned model is then proved correct with respect to the

abstract model. This is done modularly, by proving the correctness of each RE-

FINEMENT component with respect to its corresponding machine and to all

intermediate REFINEMENT components in between the abstract MACHINE

and the REFINEMENT being veriﬁed.

Eventually, a ﬁnal reﬁnement takes place, which gives origin to a B IMPLE-

MENTATION, a special kind of reﬁnement from which code in a programming

language can be generated. The veriﬁcation of the model at the IMPLEMEN-

TATION level is carried out similarly as for reﬁnements, with the addition of the

so-called B0 check, which is responsible for verifying that the constructs in each

IMPLEMENTATION module are compatible with the used code generator.

Finally, B IMPLEMENTATIONs are used as input for code generation in

some programming language (e.g., C, Ada or Java). If all veriﬁcations were

discharged, and assuming the correctness of the code generator, this generated

code satisﬁes the stated properties of the abstract model.

2.2 Components of a model in the B notation

A B component contains two main parts: a state space deﬁnition and a set of

transitions. The state space is speciﬁed as a logic formula called the invariant.

Transitions are speciﬁed by means of operations; generally, each operation may

take arguments and return results corresponding to a desired functionality of

the system. The set of initial states is speciﬁed as a special operation (without

parameters nor results) called the initialisation. A B component may additionally

contain clauses in many forms (parameters, constants, assertions). Such clauses

are not essential in the B language, but are useful to make speciﬁcations and

proofs shorter or more readable.

The speciﬁcation of the state components appears in the VARIABLES and

INVARIANT clauses. The former enumerates the state components, and the

latter deﬁnes restrictions on the possible values they can take.

For the speciﬁcation of a module’s operations, B oﬀers a language of so-called

generalized substitutions, “imperative-like” constructions with translation rules

that deﬁne their semantics as the eﬀect they have on the values of any expression

on the (global or local) variables to which they are applied. The semantics of the

substitutions is deﬁned by the substitution calculus, a set of rules stating how the

application of the diﬀerent forms substitution rewrite to formulas in ﬁrst-order

logic. Let Sdenote a substitution, Ean expression, then [S]Edenotes the result

of applying Sto E.

Operations are composed of a pre-condition Pand a substitution S. Syntac-

tically, this is expressed as PRE PTHEN SEND. In this construct, Pspeciﬁes

the bounds of application of the operation, and Sspeciﬁes what transformations

will be applied to the state, as well as how the operation results (if any) are com-

puted. Operations also have optional parameters and results. The pre-condition

Pmust establish at least typing constraints on the parameters and the sub-

stitution Sdeﬁne the value of the results. To establish that an operation does

not drive the component from a valid state to an invalid state, one must show

that the operation, whenever applied in a state that satisﬁes the pre-condition,

maintains the invariant, i.e.

I∧P⇒[S]I.

The simplest substitution in the B language is v:= Ewhere vis a variable

and Edenotes some expression. The semantics is deﬁned as:

[v:= E]P⇔Phv←Ei,

i.e. all free occurrences of vin Pare replaced by E.

Another substitution that is used in the rest of the paper is a form of non-

deterministic assignment v:∈V, where vis allowed to take any value in the set

V. The semantics is:

[v:∈V]P⇔ ∀x•(x∈V⇒Phv←xi),

where xis a fresh variable. Note that, for such substitution to be well-deﬁned,

one must show that Vis not an empty set.

2.3 Example of a B Machine

In this section, we present a simple example of a B model that will be used

throughout the paper. Our example is that of a simple counter (Figure 1). In

the next sections, this abstract speciﬁcation, which intends to specify the Ap-

plication Programming Interface (API) of a counter service, will be reﬁned with

the intention of having this service oﬀered by a Smart Card running Java Card.

Some diﬃculties in this process motivate our proposal.

MACHINE JCounter

SEES JInt

VARIABLES value

INVARIANT value ∈JINT

INITIALISATION value := jint of (0)

OPERATIONS

increment (vv)=

PRE vv ∈JINT ∧sum jint(value,vv)∈JINT

THEN value := sum jint(value,vv)

END;

decrement (vv) =

PRE vv ∈JINT ∧subt jint(value,vv)∈JINT ∧(value -vv)≥0

THEN value := subt jint(value,vv)

END;

cc ←getCounterValue =cc := value

END

Fig. 1. The counter machine

In the JCounter machine, the variable value is the state component that

stores the actual value of the counter. This variable is typed as JINT, an integer

set deﬁned in the JInt machine that corresponds to, e.g., the int type of Java

language (this machine belongs to a library of B models, under development by

our group, to support the formal development of Java and Java Card software).

The machine JInt, not shown in the paper, also deﬁnes arithmetic operations on

this set so that they operate within the range for a Java value of type int. The

included JInt machine uses these properties in the deﬁnition of functions that

can be used in substitution of the B operators in the body of an operation. The

speciﬁcation JCounter comprises three operations to increment, decrement and

query the counter. In the last operation, the pre-condition is omitted, which is

interpreted as a trivial pre-condition (i.e. TRUE). Note that, in the body of the

operations, we use the arithmetic functions deﬁned in JInt machine instead of

the B operators for integers. This means that we could be talking of any other

type of data not directly available in B.

2.4 Reﬁnements in B

Reﬁnements, which are central to the proposal of this paper, play a very impor-

tant role on the B method. They are responsible for the creation of a hierarchy

of models where each model is proved to be compliant, according to the B re-

ﬁnement rules [2], to the previous (more abstract) one in the chain. We brieﬂy

present these rules in the following.

1. exactly the same number of operations

2. exactly the same operation interfaces (names, parameters and results)

3. each concrete operation must satisfy the classical rules stating that:

(a) it must be applicable whenever its abstract counterpart is (the satis-

faction of the precondition of the abstract operation must lead to the

satisfaction of the precondition of the concrete operation).

(b) when the abstract operation is applicable and the concrete operation is

applied instead, the observed behavior must be compatible with one of

the behaviors speciﬁed in the abstract operation.

3 Retrenchment

The reﬁnement rules presented in the previous section aim to guarantee that

any implementation of the concrete model can be transparently used as an

implementation of the abstract model, but they are sometimes considered an

unnecessary burden to reﬁnement based development [5]. Reﬁnement rules can

hinder its adoption on the design of a wide range of real world applications, as

the diﬀerences between an elegant abstract model and a concrete model, where

implementation needs begin to show up, may not ﬁt the reﬁnement framework.

If we consider, for instance, our counter example of section 2.3 and the need

to implement it in a platform where only short integers are available (this may

happen in some smart cards), there will be a problem with the operations’ inter-

faces, which are supposed to communicate regular length integers. Changing the

abstract speciﬁcation to make the development ﬁt in the reﬁnement framework

is not a good approach, as it degrades reusability and requires verifying the ab-

stract level again. Retrenchment and the approach presented in this paper do

not need any changes in the abstract speciﬁcation.

With the main motivation of extending the applicability of formal develop-

ment techniques to a wider range of applications, Banach and Poppleton have

proposed a technique called retrenchment [5], a formal approach to model-driven

design that imposes less constraining rules than reﬁnement.

Indeed, with retrenchment it is possible to have stronger preconditions and/or

weaker post-conditions in an operation, to change an operation interface and to

transfer behavior from state components to I/O or vice-versa. In [5] the authors

present the theory and its applicability and demonstrate how to incorporate it as

an extension of the B method. In the following we present a brief explanation of

this extension, concentrating on the possibility to change an operation’s interface

during the development process, the feature which is the focus of this paper.

3.1 Retrenchment in B

In Banach and Poppleton proposal, a retrenchment is a B machine with the

addition of: (1) a RETRIEVES clause, to specify the retrieval relation, relating

abstract and concrete variables1, and (2) ramiﬁed generalized substitutions, con-

1Unlike B reﬁnements, where the local invariant and the relation between the abstract

and concrete states (retrieve relation) are both speciﬁed in the INVARIANT pred-

icate, in a retrenchment module, the INVARIANT only speciﬁes the more concrete

state variables. The relation between the retrenching and the retrenched states is

placed in the RETRIEVES clause.

structed with the clauses LVAR, WITHIN and CONCEDES, which extend each

operation’s generalized substitution, specifying the situations where the concrete

operation fails to reﬁne the abstract one (Figure 2).

All the elements to describe a B reﬁnement are available to deﬁne a retrench-

ment: for instance, set deﬁnitions clause (SETS) and all the clauses for machine

composition (SEES, INCLUDES, USES, PROMOTES and EXTENDS) can be

used as in a traditional B module.

MACHINE MA(pmM)

CONSTRAINTS PA(pmA)

...

VARIABLES vA

INVARIANT

Inv(vA)

INITIALISATION

Init(vA)

OPERATIONS

rA←− OPA(pA) =

SA(vA, pA, rA)

END

MACHINE MR(pmR)

CONSTRAINTS PR(pmR)

...

VARIABLES vR

INVARIANT

Inv(vR)

RETRIEVES

Ret(vA, vR)

INITIALISATION

Init(vR)

OPERATIONS

rR←− OPR(pR) =

BEGIN

SR(vR, pR, rR)

LVAR

R

WITHIN

W(pA, pR, vA, vR, R)

CONCEDES

C(vA, vR, rA, rR, R)

END

Fig. 2. classical B machine (left) and retrenchment machine (right)

The LVAR clause is optional, and may be used to declare variables whose

scope is the WITHIN and CONCEDES clauses. When present, these variables

must be typed and restricted in the WITHIN clause, which may also strengthen

the operation’s precondition. The CONCEDES clause in turn possibly weakens

the post-condition of the operation.

The role of these additional clauses can be more precisely described through

the deﬁnition of retrenchment proof obligations, presented in the following sec-

tion. Then, in Section 3.1, we use a small example to illustrate how retrenchment

works in practice.

Retrenchment proof obligations Retrenchment proof obligations can be

classiﬁed as local proof obligations, when only dealing with local data, and joint

proof obligations, when addressing both the retrenched and retrenching compo-

nents.

The local proof obligations of a retrenchment module are the same as those

for a regular B machine: establishment of the invariant by the initialisation;

preservation of the invariant by the operations, when applied to states where

their preconditions are satisﬁed. By discharging these obligations, one guarantees

the internal consistency of the module.

The joint proof obligations concern initialization and operations. The ini-

tialisation joint proof obligation is similar to that of a reﬁnement, except for

the fact that it is the satisfaction of the RETRIEVES predicate, instead of the

INVARIANT, that is checked:

PA(pmA)∧PR(pmR)⇒[Init(vR)]¬[Init(vA)]¬Ret(vA, vR)

The proof obligations for the operations are the most relevant to the re-

trenchment framework. For each operation, correctness veriﬁcation is condi-

tioned to situations where: regular B constraints (PA(pmA) and PR(pmR)),

abstract and concrete invariants (Inv(vA) and I nv(vR)) and the retrieve relation

(Ret(vA, vR)) are satisﬁed; the concrete operation terminates (trm(SR(vR, pR, rR)))

and the conditions stated on the WITHIN clause W(pA, pR, vA, vR, A) are also

satisﬁed. The ﬁrst conditions are similar to those in a reﬁnement proof obliga-

tion. It is important to notice that, diﬀerently from reﬁnement, which requires

correctness in each situation where the abstract operation terminates, it is the

termination of the concrete operation that conditions the veriﬁcation.

On the other hand, on the right hand side, we have the option of not satisfying

the retrieve relation (i.e., having a concrete behaviour which does not correspond

to a speciﬁed abstract behaviour) as long as the predicate in the CONCEDES

clause is satisﬁed.

PA(pmA)∧PR(pmR)∧(Inv(vA)∧Ret(vA, vR)∧Inv(vR))∧

trm(SR(vR, pR, rR)) ∧W(pA, pR, vA, vR, R)) ⇒trm(SA(vA, pA, rA))∧

[SR(vR, pR, rR)]¬[SA(vA, pA, rA)]¬(Ret(vA, vR)∨C(vA, vR, rA, rR, R))

Retrenching JCounter In this section, we apply retrenchment in the formal

development of the counter service of section 2.3 for a version of the Java Card

platform without support for the Java type int (32-bit integers).

The architecture of a Java Card application is composed by host-side soft-

ware and server-side software. The host side is developed in standard Java and

requests the services supplied by the server application, called applet. The lat-

ter resides inside the smart card chip, which provides a computer with limited

memory resources and processing power. Moreover, the Java Card language is

much more limited than Java (for instance, it has a smaller set of basic types).

We assume that the smart card will provide the token counter service, that

will be used by host-side applications written in Java. The development starts

with the speciﬁcation of the Java API that will be available to host-side clients

(Figure 1). The obtained retrenchment, with diﬀerent operation signatures than

those of the abstract machine, is shown in Figure 3.

MACHINE JCounter ret

RETRENCHES JCounter

SEES JInt, JCInt, InterfaceContext

VARIABLES cvalue

INVARIANT cvalue ∈JCInt

RETRIEVES value =jint of jcint (value)

INITIALISATION cvalue := jcint of (0)

OPERATIONS

increment (cvv ) =

BEGIN

PRE cvv ∈JCINT ∧sum jcint(cvalue,cvv)∈JCINT

THEN cvalue := sum jcint(cvalue,cvv)

END

WITHIN vv =jint of jcint (cvv)

END;

decrement (cvv ) =

BEGIN

PRE cvv ∈JCINT ∧subt jcint(cvalue,cvv)∈JCINT ∧

subt jcint(cvalue,cvv)≥0

THEN cvalue := subt jcint(cvalue,cvv)

END

WITHIN

vv =jint of jcint (cvv)

END;

cc ←getCounterValue =

BEGIN

ccc =cvalue

CONCEDES

cc =jint of jcint (ccc)

END

END

Fig. 3. A retrenchment of JCounter

As in our example, the basic data type int is not available, one possible so-

lution is to represent it as a combination of available types, such as short. This

representation is deﬁned in the JCInt component (not shown) which deﬁnes the

JCINT type, operators such as addition (sum jcint) and subtraction (subt jcint),

and a type cast operation (jcint of) to generate JCINT values from regular B

integer values. The operations in JCounter ret machine of Figure 3 run com-

pletely on this domain. This can be seen when observing the substitutions that

specify the behaviour of each operation.

JCounter ret also imports, through the SEES construct, JINT and Inter-

faceContext (described in Section 5), which, as one can see, only appear in the

clauses related to retrenchment where they are used to specify the relation be-

tween speciﬁcations (JCounter and JCounter ret). jint of jcint is a bijection,

deﬁned in InterfaceContext associating each Java integer to its Java Card repre-

sentation. It is used in four diﬀerent places: to specify the retrieve relation as it

would regularly be done in a reﬁnement; and in each operation, to associate each

concrete parameter or result to its abstract counterpart. In a reﬁnement, because

there can be no changes in interfaces, this association is done automatically and

does not need to be stated.

3.2 Some Notes on Retrenchment

Although retrenchment could be an attractive alternative to strict reﬁnement for

some developments, its adoption is currently not expressive and there is not yet

a mature tool support for it. An academic initiative in this direction is the Frog

tool [14], developed as part of the PhD thesis of Frasier [15]. The tool proposes a

framework to mechanize the support for retrenchment. Initially the Z [16] nota-

tion was used as mathematical notation and the proof obligations were generated

to the Isabelle theorem prover. But as the proposal of the framework is to be

extensive, one can use it to conﬁgure its own formal model based development.

In the next section of the paper, we describe our solution to the problem of

interface adaptation and type changing between models without going out the

reﬁnement theory using the B method.

4 Interface adaptation as reﬁnement

This section describes a way how model transformations consisting of a modiﬁ-

cation in the signature of operations, can be performed by means of reﬁnement.

This transformation is presented as a reﬁnement pattern [17] written and devel-

oped with the B method itself. Such pattern will then be instantiated in Section 5

for a simple software development for the Java Card platform.

4.1 A schematic speciﬁcation in B

We ﬁrst present the schema of a speciﬁcation model in B. This schema is de-

scribed in the B language itself as a component named API A, that is presented

in Figure 4. The types, sets and relations employed in the machine API Aare

deﬁned in the component Context A, presented in Figure 5. Note that, for the

sake of conciseness, the API Amachine only includes the clauses that provide the

essence of what is a B model, namely a set of states, constrained by an invariant

predicate, a set of transitions and initial states, both speciﬁed by means of sub-

stitutions. So, while there is no parameters, constants and sets in this pattern

machine, the generality of the approach is thus not compromised.

A B component modelling a system has a state, and it is represented here as

a single variable vA, of type typeA(deﬁned in ContextA). The valid states are

identiﬁed by the set invAand the initial states by the set init A.

The transitions of the system are modelled by a single operation, named

operationA. The parameters of the operations are represented by pAand its

results by rA. In the general case, an operation may have a precondition that

depends on the state and parameters. It is here speciﬁed by means of the set preA.

The possible next states and output values are chosen non-deterministically

amongst the sets of values denoted stf Aand ouf Arespectively; both depend

on the state variable and the operation parameter.

MACHINE API A

SEES ContextA

VARIABLES vA

INVARIANT

vA∈typeA∧vA∈inv A

INITIALISATION

vA:∈initA

OPERATIONS

rA←− operationA(pA) =

PRE pA∈typeA∧(vA, pA)∈preATHEN

vA:∈stf (vA, pA)krA:∈ouf A(vA, pA)

END

END

Fig. 4. A pattern for an abstract speciﬁcation in B

In order to be able to prove the validity of the veriﬁcation conditions of the

component API A, the objects deﬁned in Context Aneed to satisfy a number of

constraints, that are stated in its PROPERTIES clause.

The ﬁrst ﬁve constraints are typing conditions, the next two constraints state

that the domain of the state transition and output relations must contain the

valid states and operation parameters. The last two constraints must be also

satisﬁed to guarantee that all the reachable states of the component are also

valid states (i.e. in the set representing the invariant).

Assume now that the component API Ais to be reﬁned by a component API C

such that the data carried by state variables, operations parameters and results

may be diﬀerent. In the following, the objects in the component API Cwill be

here designated as the ob jects in the component API A, with the Asubscript

substituted by the Csubscript. For instance, the signature of the operation in

the machine API Cis:

rC←− operationC(pC) =

where pCsatisﬁes pC∈typeC∧pC∈preC. Since the reﬁnement of operations

must preserve their signature, it is necessary to propose a workaround, such as

MACHINE ContextA

SETS typeA

CONSTANTS

stf A,(* state transition function *)

ouf A,(* output function *)

invA,(* state invariant *)

initA,(* initial states *)

preA(* operation precondition: depends on state and parameter *)

PROPERTIES

invA⊆typeA∧

initA⊆typeA∧

preA⊆typeA×typeA∧

stf A⊆(typeA×typeA)↔typeA∧

ouf A⊆(typeA×typeA)↔typeA∧

invA⊳preA⊆dom(stf A)∧

invA⊳preA⊆dom(ouf A)∧

initA⊆inv A∧

stf A[invA⊳preA]⊆inv A

END

Fig. 5. Component deﬁning the objects used in component API A

retrenchment does. In the next section we show a reﬁnement pattern that makes

it possible to use operations with a diﬀerent signature in a reﬁnement.

4.2 A reﬁnement pattern for signature changes

The main idea that underlies the pattern is to use an interface adapter (see

Figure 6). Note that this reﬁnement is solely responsible for interfacing the two

components and is not meant to introduce other design decisions such as reducing

non-determinism, or precondition weakening.

The API Acomponent is reﬁned by a component API r. This reﬁnement

includes an instance of the component API C, and the gluing invariant establishes

the relationship between the state of API Aand the state of API C. In API r,

the operation has the same signature as in API A. It consists of a three-step

sequence. First the value of the parameter pAis translated to corresponding

value of type typeCand the result is stored in variable to. Second, operationC

is applied to to and the result is stored in a variable from. The value of from is

then converted back to typeAand returned.

The conversion functions between typeAand typeCare declared and speciﬁed

in the component Context I, shown in Figure 7. The ﬁrst two properties deﬁne

the conversion functions AofC and CofA as total bijective functions. The third

property constrains that they inverse each other. The properties numbered 4 to

7 constrain the translation functions to preserve the invariant states, the initial

states, and the legal operation parameter values. The properties 8 to 11 further

constrain that they preserve the state transition and output relations.

REFINEMENT API r

REFINES API A

SEES ContextA,ContextC,ContextI

INCLUDES API C

INVARIANT vA=AofC(vC)

OPERATIONS

rA←− operationA(pA) =

VAR to,from IN

to := CofA(pA);

from ←− operationC(to );

rA:= AofC (from)

END

END

Fig. 6. Schematic reﬁnement that accommodates signature changes

Atelier B [12], an IDE for the B method, has been used to develop this

pattern. To show the correctness of the development with the provers of Atelier-

B, we introduced (and proved) the properties listed in “assertions” section.

5 Case study

In this section, we apply the reﬁnement pattern described in Section 4 in the

formal development of a Java Card implementation of the Counter speciﬁcation

presented in Section 2.3 and contrast it to the retrenchment approach exposed

in Section 3.1.

As seen, a change in the interface of the operations is required, and in this

section the reﬁnement pattern of Section 4 is applied.

The JCCounter machine (Figure 8) provides the same services as the JCounter

machine, but with its interface and typing restrictions compatible with the types

of Java Card. In Java Card, the type int is not built-in and needs to be pro-

grammed, e.g. as a pair of short integers. This representation is deﬁned and

named by JCINT in a library machine called JCInt (not detailed in this paper).

Note that the machine JCCounter is also the initial model of a B development

to provide an implementation of the card-side component.

The functions mapping the values of the abstract (Java) and concrete (Java

Card) types are deﬁned in the InterfaceContext machine (see Figure 5). This

machine also contains some corollaries in the assertions clause. These additional

properties are useful to simplify interactive proofs of the development. These

functions are essential to instantiate the reﬁnement pattern to JCounter.

Finally, as a last step, the reﬁnement itself, called JCCounter ref, is also

obtained by instantiation of the pattern and is presented in Figure 10. The de-

velopment of this case study was also performed and veriﬁed with Atelier B [12].

MACHINE ContextI

SEES ContextA,ContextC

CONSTANTS AofC ,CofA

PROPERTIES

AofC ∈typeC→typeA∧1

CofA ∈typeA→typeC∧2

CofA−1=AofC ∧3

∀a•(a⊆typeA∧a⊆invA⇒CofA[a]⊆inv C)∧4

∀c•(c⊆typeC∧c⊆inv C⇒AofC [c]⊆invA)∧5

∀c•(c⊆typeC∧c⊆init C⇒AofC [c]⊆initA)∧6

∀va, pa•(va⊆typeA∧pa⊆typeA∧va×pa⊆preA⇒CofA[va×pa]⊆preC)∧7

∀v, p •(v∈typeA∧p∈typeA∧(v, p)∈dom(stf A)⇒8

(CofA(v),CofA(p)) ∈dom(stf C)) ∧

∀v, p •(v∈typeA∧p∈typeA∧(v, p)∈dom(stf A)⇒9

CofA[stf A[{(v, p)}]] = stf C[{(CofA(v),CofA(p))}]) ∧

∀v, p •(v∈typeA∧p∈typeA∧(v, p)∈dom(ouf A)⇒10

(CofA(v),CofA(p)) ∈dom(ouf C)) ∧

∀v, p •(v∈typeA∧p∈typeA∧(v, p)∈dom(ouf A)⇒11

CofA[ouf A[{(v, p)}]] = ouf C[{(CofA(v),CofA(p))}])

ASSERTIONS

AofC −1=CofA ∧

dom(AofC ) = typeC∧

dom(CofA) = typeA∧

∀a, c •(a∈typeA∧c∈typeC⇒((AofC (c) = a)⇔(c=CofA(a)))) ∧

∀vA, pA•(vA∈typeA∧pA∈typeA∧(vA, pA)∈inv A⊳preA⇒

CofA[stf A[{(vA, pA)}]] ⊆invC)∧

∀s•(s⊆typeA⇒AofC [CofA[s]] = s)∧

∀s•(s⊆typeC⇒CofA[AofC [s]] = s)

END

Fig. 7. Constraints to establish the reﬁnement pattern for signature changes

MACHINE JCCounter

SEES JCInt

VARIABLES jc value

INVARIANT jc value ∈JCINT

INITIALISATION jc value := jcint of(0)

OPERATIONS

jc increment (vv)=

PRE vv ∈JCINT ∧sum jcint(jc value,vv)∈JCINT

THEN jc value := sum jcint(jc value,vv)

END; ...

cc ←jc getCounterValue =

cc := jc value

END

Fig. 8. The JCCounter machine

MACHINE InterfaceContext

SEES JInt,JCInt

CONCRETE CONSTANTS jint of jcint,jcint of jint

PROPERTIES

jint of jcint ∈

JCINT 7→ JINT ∧

jint of jcint =λ(hi,lo).( (hi ,lo )∈JCINT |hi ×65536 + lo)∧

jcint of jint ∈

JINT 7→ JCINT ∧

jcint of jint =λ(ii).(ii ∈JINT |((ii ÷65536 ), (ii mod 65536)))

ASSERTIONS

jint of jcint −1=jcint of jint ∧

dom (jint of jcint) = JCINT ∧

dom (jcint of jint) = JINT

END

Fig. 9. The InterfaceContext machine

6 Conclusions

The B method provides a simple yet rigorous approach to model-driven design

of software. Starting from an initial functional model of the requirements, addi-

tional requirements and implementation decisions are introduced as a sequence

of reﬁnements. For each reﬁnement, proof obligations are generated; proving such

veriﬁcation conditions provides a formal guarantee that the initial speciﬁcation

is indeed an abstract of model of each successive reﬁnement.

In the B method, the operations of a reﬁnement must have the same sig-

nature as that of the reﬁned module, and by transitivity, to that of the initial

model. This limitation causes problems in software developments where com-

REFINEMENT JCounter ref

REFINES JCounter

SEES JInt,JCInt,InterfaceContext

INCLUDES JCCounter

INVARIANT value =jint of jcint(jc value)

OPERATIONS

increment (vv ) =

VAR to

IN to := jcint of jint(vv);

jc increment(to )

END;

...

cc ←getCounterValue =

VAR from

IN from ←jc getCounterValue;

cc := jint of jcint(from)

END

END

Fig. 10. The adapter reﬁnement of counter machine

ponent interfaces must be adapted to accommodate, e.g. incompatibilities in

programming languages.

Retrenchment provides a formal framework to perform model transforma-

tion that is much more ﬂexible than reﬁnement and, in particular, accommo-

dates interface changes. However one may argue that the ﬂexibility oﬀered by

retrenchment is too generous, to the point that it may produce implementations

that do not conform to the initial functional speciﬁcation. Indeed retrenchment

is currently not oﬀered by commercial tools that support the B method. More

generally, tool support for retrenchment as not yet reached the same level of

maturity as reﬁnement.

This paper presents a reﬁnement pattern to accommodate operation signa-

tures that is fully compatible with the B method. An abstract instance of this

reﬁnement has been developed and veriﬁed with Atelier B [12]. The paper also

shows how the pattern can be applied in a software development project where

diﬀerent execution platforms are employed (namely Java and Java Card). This

instance has also been mechanically proved correct.

Future work include:

1. Proof that the constraints on the interface (or a weaker version thereof),

listed as properties in the component Context I, are necessary conditions to

establish the reﬁnement.

2. Automation of the proposed reﬁnement pattern in existing tools supporting

the B method [4] (this includes generating veriﬁcation conditions based on

the properties of Figure 7 instead of the more complex veriﬁcation conditions

for a generic reﬁnement).

Both lines of work require the construction of an embedding of the B method in

a proof system such as Isabelle [18], using an approach similar to that of HOL-

Z [19]. Such embedding is necessary to obtain veriﬁed results on the B method

(instead of its artifacts as we have done in this paper).

References

1. Chen, Z.: Java Card Technology for Smart Cards: Architecture and Programmer’s

Guide. Addison Wesley, Boston (2000)

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

Press, Cambridge (1996)

3. D´eharbe, D., Gomes, B.E.G., Moreira, A.M.: Automation of Java Card component

development using the B method. In: 11th IEEE International Conference on

Engineering of Complex Computer Systems, IEEE Computer Society (2006) 259–

268

4. Gomes, B., Moreira, A., D´eharbe, D., Moraes, K.: A ferramenta BSmart para

o desenvolvimento rigoroso de aplica¸c˜oes Java Card com o m´etodo formal B. In:

XIV Sess˜ao de Ferramentas do XXI Simp´osio Brasileiro de Engenharia de Software.

(2007) 11–17

5. Banach, R., Poppleton, M.: Retrenchment: An engineering variation on reﬁnement.

In: B’98: Proceedings of the Second International B Conference, London, UK,

Springer-Verlag (1998) 129–147

6. Hayes, I., Sanders, J.: Speciﬁcation by interface separation. Formal Aspects of

Computing 7(1995) 430–439

7. Mikhajlova, A., Sekerinksi, E.: Class reﬁnement and interface reﬁnement in object-

oriented programs. In: FME-97. Number 1313 in LNCS, Springer (1997) 82–101

8. Stepney, S., Cooper, D., Woodcock, J.: More powerful Z data reﬁnement: Pushing

the state of the art in industrial reﬁnement. In: ZUM-98. Number 1493 in LNCS,

Springer (1998)

9. Boiten, E., Derrick, J.: IO-reﬁnement in Z. In: Third BCS-FACS Northern Formal

Method Workshop. (1998)

10. Colin, S., Lanoix, A., Souquires, J.: Trustworthy interface compliancy: Data model

adaptation using B reﬁnement. Electronic Notes in Theoretical Computer Science

203(7) (2009) 23 – 35

11. Clearsy: B language reference manual: version 1.8.6. http://www.atelierb.eu

(2007)

12. ClearSy: Atelier B User Manual Version 4.0. http://www.atelierb.eu.

13. B-Core Ltd: The B-Toolkit. http://www.b-core.com/btoolkit.html last access:

april 2009.

14. Fraser, S., Banach, R.: Conﬁgurable proof obligations in the Frog toolkit. In:

Software Engineering and Formal Methods, London, UK, IEEE Computer Society

(2007) 361–370

15. Fraser, S.: Mechanized Support for Retrenchment. PhD in computer science, Fac-

ulty of Engineering and Physical Sciences of University of Manchester, Manchester,

UK (2008)

16. Spivey, J.: The Z Notation: a Reference Manual. 2nd edn. Prentice-Hall Interna-

tional Series in Computer Science. Prentice Hall (1992)

17. Lecomte, T., M´ery, D., Cansell, D.: Patrons de conception prouv´es. Journ´ees

Neptune (2007) ANR-006-SETIN-015.

18. Tobias Nipkow, Lawrence C. Paulson, M.W.: Isabelle/HOL A Proof Assistant for

Higher-Order Logic. Volume 2283 of LNCS. Springer (2005)

19. Brucker, A.D., Rittinger, F., Wolﬀ, B.: Hol-z 2.0: A proof environment for z-

speciﬁcations. Journal of Universal Computer Science 9(2) (2003) 152–172