Implementing Dynamic Aggregations of Abstract Machines in the B Method

N. Aguirre1, J.C. Bicarregui2, L. Guzman1 and T. Maibaum3

1Departmento de Computacion,Universidad Nacional de Rio Cuarto, Argentina

{naguirre,lucio}@dc.exa.unrc.edu.ar2CCLRC - Rutherford Appleton Laboratory, UK

J.C.Bicarregui@rl.ac.uk3Department of Computing & Software – McMaster

UniversityHamilton, Ontario, Canada

tom@maibaum.org

ObjectivesTo allow for more expressive ways of specifying systems in terms of components in BTo incorporate support for some common software engineering practices into the B language and its refinement processTo extend the available structuring mechanisms in the B method with more powerful OO like constructs

A Motivating Example

MACHINEMinMax

VARIABLESy

INVARIANTy F(NAT1)

INITIALISATIONy:=

OPERATIONSins(x) = PRE x NAT1 THEN y:= y{x} ENDx getMin = PRE y≠ THEN x:= min(y) ENDx getMax = PRE y≠ THEN x:= max(y) END

END

Consider the following abstract machine:

A Motivating Example (2)

Suppose we want to define a machine composed of two instances of MinMax, with extra operations for “synchronising” the minima or maxima values of the included MinMax machines.

This is possible to achieve straightforwardly in the B method, by using some of the available structuring mechanisms:

A Motivating Example (3)MACHINE

TwoMinMaxEXTENDS

m1.MinMax, m2.MinMaxOPERATIONS

syncMin = PRE (m1.y m2.y)≠ THEN

ANY vWHERE v = min(m1.y m2.y)THEN m1.ins(v) || m2.ins(v)END

ENDsyncMax = …

END

A Need for Aggregation

Suppose that instead of TwoMinMax, we want a machine aggregating a varying set of MinMax “instances”, and where synchronisations could be applied to any two machines.

That is not possible to achieve directly in B. All the structuring mechanisms of B are static, i.e., they only allow to define machines whose architectural structure does not dynamically change.

Dynamic Population Management: The Standard B Approach

Machines showing a behaviour similar to what we wanted can be specified in B.

The approach for achieving dynamism consists of defining a new flat machine, that:defines a set of identifiers, denoting live instances,defines operations for the management of populations,includes all the operations, variables, etc of the machine we want to aggregate (e.g., MinMax in our case), adapted to cope with instance names.

A Sample “Dynamic” Machine in B

MACHINEMultipleMinMax

SETSMINMAXSET

VARIABLESy, minmaxes

INVARIANT(y minmaxes NAT1) (minmaxes MINMAXSET)INITIALISATION

minmaxes:= || y:= OPERATIONS

ins(x,m) = PRE (m minmaxes) (x NAT1) THEN y(m):=y(m) {x} END

…

A Sample “Dynamic” Machine in B(2)OPERATIONS…x getMin(m) = PRE m minmaxes THEN x:= min(y(m)) ENDx getMax(m) = PRE m minmaxes THEN x:= max(y(m)) END

add_minmax(m) = PRE m (MINMAXSET – minmaxes) THEN minmaxes:= minmaxes {m} || y(m):= END

del_minmax(m) = PRE m minmaxes THEN minmaxes:= minmaxes - {m} || y:= {n}<+y END

Features of this Approach

The specification of the component machine (MinMax in our case) has to be discarded, diminishing reuse.

The opportunity to structure the specifications is lost.

Proofs cannot be localised to relevant specification parts. The whole system specification is less understandable.

A Notation for Dynamic Population Management of MachinesWe suggested a new notation, to

avoid these problems.We added a new structuring

mechanism, called AGGREGATES, which intuitively allows us to aggregate a varying number of machines.

Aggregating MachinesHere is a machine illustrating aggregation:MACHINE

DynamicMultipleMinMaxAGGREGATES

MinMaxOPERATIONS syncMin(m1,m2) =

PRE m1, m2 MinMaxSet (m1.y m2.y ≠ ) THEN ANY v

WHERE v = min(m1.y m2.y)THEN m1.ins(v) ||| m2.ins(v)

ENDEND

syncMax(m1,m2) = …dot notation

instance set

Interpreting AGGREGATES

The AGGREGATES clause is interpreted via the generation of a manager.

The manager M_Man of a basic machine M is composed of:

- The definition of a set of live instances of type M,

- the relativisation of the operations of M,

- operations for creation and deletion of instances.

MinMax

DynamicMultipleMinMax

MinMax

DynamicMultipleMinMax

Automatic generation

MinMaxManager

EXTENDSdenotesAGGREGATES

Meaning of AGGREGATES

MinMaxManager

MACHINE MinMaxManagerVARIABLES y, MinMaxSetINVARIANT (n . n MinMaxSet y(n) F(NAT1)) (MinMaxSet NAME) (var CellSet NAT)INITIALISATION y, MinMaxSet:= ,OPERATIONS add_MinMax(p) = … dell_MinMax(p) = … ins(x,m) = PRE m MinMaxSet (x NAT1)

THEN y(m):=y(m) {x}END

…END

DynamicMultipleMinMax

MACHINEDynamicMultipleCells

EXTENDSCellManager

OPERATIONSmove(p,q) = …

END

Differences with the Standard Approach

The generation of the manager is standardised and automated.The manager of M is internally consistent (by construction), provided M is internally consistent. add and del preserve the M_Man

invariant, relativised operations from M preserve

M_Man’s invariant.

The specifier only writes the extension

Implementing Machines with Aggregation

The manager should be hidden from the specifier/developer when using aggregation at the specification stage. However, in principle, one has to deal explicitly with the managers when trying to implement machines involving aggregations. We propose a mechanism for keeping the managers hidden at implementation, based on the following idea:

If a machine M’ aggregates a machine M, and we count on a (proved correct) implementation of M, we systematically construct a correct implementation for MManager, on which an implementation of M’ can be based.

Implementations of Abstract Machines in BB counts on a set of library machines,

for which there exist proved correct implementations.

During a development in B, the whole state (i.e., the variables) of an implementation must be imported from other simpler machines, which will need to be subsequently implemented.

Assumptions for Building Implementations for ManagersIn order to be able to build

implementations for managers, we assume that for every library machine Ml, there exists a proved correct implementation of its manager MlManager.

BUT, managers of library machines should not be considered library machines.

Building Implementations for managersimplManager(M, I_M)begin

create an empty implementation for I_MManadd “REFINES MMan” to I_MManLet N1, …, Nk be the machines imported by I_MFor every Ni do

Let NiMan be the manager of Niif (Ni is not a library machine & NiMan is not implemented) then

create an impl. of NiMan via implManager(Ni, I_Ni)

add “IMPORTS NiMan” to I_MManendrelativise the invariant of I_M and add it to I_MManrelativise the operations of I_M and add them to I_MManadd operations for creation/deletion, with standard implementations

end

An ExampleConsider the following implementation of MinMax:

IMPLEMENTATIONI_MinMax

REFINESMinMax

IMPORTSPair(maxint,0)

INVARIANTfirst = min({maxint}y) second = max({0}y)

OPERATIONSins(x) = VAR v,w IN

v <- getFirst; w<- getSecond;IF x<v THEN setFirst(x) END;IF w<x THEN setSecond(x)

ENDEND

…

An Example (2)

IMPLEMENTATIONI_Pair(x,y)

REFINESPair

IMPORTSxx.Scalar(x), yy.Scalar(y)

INVARIANTfirst = xx.var second = yy.var

OPERATIONSsetFirst(x) = BEGIN xx.chg(x) END;setSecond(x) = BEGIN yy.chg(y) END;fst <- getFirst = BEGIN fst:= xx.val END;snd <- getSecond = BEGIN snd:= yy.val END;

END

An Example (3)

IMPLEMENTATIONI_MinMaxManager

REFINESMinMaxManager

IMPORTSPairManager(maxint,0)

INVARIANT(MinMaxSet = PairSet) (n . n MinMaxSet =>

n.first = min({maxint}n.y) n.second = max({0}n.y)) OPERATIONS

ins(x,n) = VAR v,w INv <- n.getFirst; w<- n.getSecond;IF x<v THEN n.setFirst(x) END;IF w<x THEN n.setSecond(x)

ENDEND …

An Example (4)

IMPLEMENTATIONI_PairManager(x,y)

REFINESPairManager

IMPORTSxx.ScalarManager(x), yy.ScalarManager(y)

INVARIANT(PairSet = xx.ScalarSet yy.ScalarSet) (n. n ScalarSet => n.first = xx.var(n) n.second = yy.var(n))

OPERATIONSsetFirst(x,n) = BEGIN xx.chg(x,n) END;setSecond(x,n) = BEGIN yy.chg(y,n) END;fst <- getFirst(n) = BEGIN fst:= xx.val(n) END;snd <- getSecond(n) = BEGIN snd:= yy.val(n) END;

END

ConclusionsWe defined an extension of B to deal with a

very common modelling practice, namely, dynamic population management of “instances”.

The extension has the following characteristics:it requires just simple machinery to be built on top of standard B,it allows us to specify systems using naturally the notion of dynamic aggregation,It supports facilities for implementing these aggregations within the B method.