Implementing Dynamic Aggregations of Abstract Machines in the B Method

1
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_at_dc.exa.unrc.edu.ar
• 2CCLRC - Rutherford Appleton Laboratory, UK
• J.C.Bicarregui_at_rl.ac.uk
• 3Department of Computing Software McMaster
  University
• Hamilton, Ontario, Canada
• tom_at_maibaum.org

2
Objectives

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

3
A Motivating Example
Consider the following abstract machine

• MACHINE
• MinMax
• VARIABLES
• y
• INVARIANT
• y ? F(NAT1)
• INITIALISATION
• y ?
• OPERATIONS
• ins(x) PRE x ?NAT1 THEN y y?x END
• x ? getMin PRE y?? THEN x min(y) END
• x ? getMax PRE y?? THEN x max(y) END
• END

4
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

5
A Motivating Example (3)

• MACHINE
• TwoMinMax
• EXTENDS
• m1.MinMax, m2.MinMax
• OPERATIONS
• syncMin PRE (m1.y ? m2.y)??
• THEN
• ANY v
• WHERE v min(m1.y ? m2.y)
• THEN m1.ins(v) m2.ins(v)
• END
• END
• syncMax
• END

6
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.

7
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.

8
A Sample Dynamic Machine in B

• MACHINE
• MultipleMinMax
• SETS
• MINMAXSET
• VARIABLES
• y, 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

9
A Sample Dynamic Machine in B(2)

• OPERATIONS
• x ? getMin(m) PRE m ? minmaxes THEN x
  min(y(m)) END
• x ? 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 nlty
• END

10
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.

11
A Notation for Dynamic Population Management of
Machines

• We 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.

12
Aggregating Machines

• Here is a machine illustrating aggregation

MACHINE DynamicMultipleMinMax AGGREGATES MinMax
OPERATIONS 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) END END
syncMax(m1,m2)
13
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.

14
Meaning of AGGREGATES
15
MinMaxManager
MACHINE MinMaxManager VARIABLES y,
MinMaxSet INVARIANT (?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
16
DynamicMultipleMinMax
MACHINE DynamicMultipleCells EXTENDS CellManager
OPERATIONS move(p,q) END
17
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_Mans
  invariant.
• The specifier only writes the extension

18
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.

19
Implementations of Abstract Machines in B

• B 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.

20
Assumptions for Building Implementations for
Managers

• In 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.

21
Building Implementations for managers

• implManager(M, I_M)
• begin
• create an empty implementation for I_MMan
• add REFINES MMan to I_MMan
• Let N1, , Nk be the machines imported by I_M
• For every Ni do
• Let NiMan be the manager of Ni
• if (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_MMan
• end
• relativise the invariant of I_M and add it to
  I_MMan
• relativise the operations of I_M and add them to
  I_MMan
• add operations for creation/deletion, with
  standard implementations
• end

22
An Example

• Consider the following implementation of MinMax

IMPLEMENTATION I_MinMax REFINES MinMax IMPORTS
Pair(maxint,0) INVARIANT first min(maxint?y)
? second max(0?y) OPERATIONS ins(x) VAR
v,w IN v lt- getFirst wlt- getSecond IF
xltv THEN setFirst(x) END IF wltx THEN
setSecond(x) END END
23
An Example (2)
IMPLEMENTATION I_Pair(x,y) REFINES Pair IMPORTS
xx.Scalar(x), yy.Scalar(y) INVARIANT first
xx.var ? second yy.var OPERATIONS setFirst(x)
BEGIN xx.chg(x) END setSecond(x) BEGIN
yy.chg(y) END fst lt- getFirst BEGIN fst
xx.val END snd lt- getSecond BEGIN snd
yy.val END END
24
An Example (3)
IMPLEMENTATION I_MinMaxManager REFINES MinMaxMan
ager IMPORTS PairManager(maxint,0) INVARIANT (Mi
nMaxSet PairSet) ? (?n . n MinMaxSet gt
n.first min(maxint?n.y) ? n.second
max(0?n.y)) OPERATIONS ins(x,n) VAR v,w
IN v lt- n.getFirst wlt- n.getSecond IF
xltv THEN n.setFirst(x) END IF wltx THEN
n.setSecond(x) END END
25
An Example (4)
IMPLEMENTATION I_PairManager(x,y) REFINES PairMa
nager IMPORTS xx.ScalarManager(x),
yy.ScalarManager(y) INVARIANT (PairSet
xx.ScalarSet ? yy.ScalarSet) ? (?n. n ? ScalarSet
gt n.first xx.var(n) ? n.second yy.var(n))
OPERATIONS setFirst(x,n) BEGIN xx.chg(x,n)
END setSecond(x,n) BEGIN yy.chg(y,n)
END fst lt- getFirst(n) BEGIN fst xx.val(n)
END snd lt- getSecond(n) BEGIN snd yy.val(n)
END END
26
Conclusions

• We 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.