UNDERSTANDING B SPECIFICATIONS WITH UML CLASS
DIAGRAM AND OCL CONSTRAINTS
B. Tatibou¨et
Laboratoire d’Informatique de l’universit´e de Franche-Comt´e
16, route de Gray 25030 Besanc¸on cedex
I. Jacques
Laboratoire d’Informatique de l’universit´e de Franche-Comt´e
16, route de Gray 25030 Besanc¸on cedex
Keywords: B Formal Method, UML notation, object constraint language.
Abstract: B is a formal method (and a specification language) which enables the automatic generation of an executable
code through a succession of refinements stemming from an abstract specification. A B specification requires
a certain knowledge of mathematical notations (Classical logic and sets) as well as specific terminology (gen-
eralized substitutions, B keywords) which may in all likelihood leave a non-specialist of the B notation in the
dark. To address this problem, we will extract graphic elements from B specification in an effort to render it
more understandable. In a previous work, these visual elements are illustrated in a UML class diagram. These
visual elements being insufficient they are completed by OCL constraints allowing to present the invariant and
the operations of a B abstract machine.
1 INTRODUCTION
Formal methods are nowadays the most rigorous way
to produce software. They provide techniques to en-
sure the consistency of a specification and to guaran-
tee that some piece of code implements a given speci-
fication. Also many studies (Sekerinski, 1998; Meyer
and Souquieres, 1999; Laleau and Mammar, 2000)
have been carried out over the past few years regard-
ing the generation of B (Abrial, 1996) specifications
from OMT or UML (Unified Modeling Language) di-
agrams.
Given the fact that several significant formal devel-
opment in B (For example industrial railway (Behm
et al., 1999) and smard cards (Casset, 2002) applica-
tions) are mainly based on formal approach, we in-
vestigate the reverse approach : using graphical no-
tations, such as UML diagrams, as a way to docu-
ment B formal developments. Such critical applica-
tions must usually be accepted by independent certi-
fication authorities that are not necessarily expert in
formal methods. Therefore, it makes sense to con-
struct a graphical view from formal development as
an additional documentation. It is expected that these
more intuitive representations will be easier to accept
by certifiers.
In our previous works (Hammad et al., 2002; Tat-
ibouet et al., 2002; Jacques et al., 2005) concerning
this extraction we particularly described a static view
of B specification by a set of generation rules of UML
class diagram completed by constraints written with
the OCL language (Object Constraint Language).
In this article we will start by revisiting (Section
2) our approach. In the Section 3 we will show how
to transform B invariants and B operations into OCL
constraints. To conclude, we will examine the limits
of our work as well as the prospects of their develop-
ment.
2 FROM B SPECIFICATION TO
UML CLASS DIAGRAM ON
THE SCHEDULER’S EXAMPLE
2.1 Abstract Machines
Given that a specification of B is composed of ab-
stract machines, the concept of the machine must find
its counterpart in UML. In the techniques generating
B from UML, the solution consists in representing a
class with an abstract machine. This is a natural so-
lution where the class in UML and the abstract ma-
chine in B make up an elemental granularity merging
data and operations. This solution, then, is the one we
475
Tatibouët B. and Jacques I. (2006).
UNDERSTANDING B SPECIFICATIONS WITH UML CLASS DIAGRAM AND OCL CONSTRAINTS.
In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 475-478
DOI: 10.5220/0002490504750478
Copyright
c
 SciTePress

MACHINE
Scheduler
SETS
PID
CONCRETE
VARIABLES
active, ready, waiting
INVARIANT
active ⊆ PID ∧ ready ⊆ PID ∧
waiting ⊆ PID ∧
ready ∩ waiting = ∅ ∧
(active = ∅ or (active ⊂ ready ∪ waiting)) ∧
card (active) ≤ 1 ∧
active = ∅ ⇒ ready = ∅
INITIALISATION
...
END
Figure 1: Static part of the B scheduler example.
have chosen for the passage from a B specification to
UML.
We present the result of these transformations
through the scheduler’s example : The three variables
of the machine (figure 1) are waiting, ready and ac-
tive which represent respectivelythe waiting, ready to
be activated and active processes.
2.2 Abstract Sets and Sets Variables
In B, the abstract sets as well as the enumerated sets
are defined in the clause SETS. From these sets it is
possible to declare set variables or element of set vari-
ables when jointly using the VARIABLES clause to
define a name and the INVARIANT clause to type
this variable. For example, in the machine of Figure
1, PID is an abstract set and active a set included in
PID (active is a subset of PID).
An abstract set such as PID is represented by a
class (indicated here as E
PID in Figure 2) corre-
sponding to the type of elements of the set and by
an association between this class and the class repre-
senting the machine. The extremity of the association
on the side of the class corresponding to the type of
elements has a name (role) which is that of the set (in
this case, PID). The set variables constitute associa-
tions, with their name acting as the role name on the
side corresponding to the type of element.
An OCL constraint enables to express the inclusion
between sets PID and active that does not appear on
the class diagram. In constraint 1, the context within
which the constraint is expressed is the Scheduler
class and where inv means invariant. By using the
PID role from that class, we obtain a set. The pre-
defined function includesAll assures one that all the
elements of the set in parameter (obtained from active
Scheduler E_PID
+am 1 +waiting*
+ am1 +active *
1
+PID
*
+am1 +ready *
Figure 2: The class diagram corresponding to the Scheduler
machine.
role) are included in the set obtained from PID role.
Constraint 1
context Scheduler inv :
PID → includesAll (active)
and PID → includesAll (ready)
and PID → includesAll (waiting)
3 OBTAINING THE OCL
CONSTRAINTS FROM B
INVARIANTS AND
OPERATIONS
3.1 Transforming B Invariants Into
OCL Constraints
The rules, which allow to transform B predicates, B
arithmetical expressions, B set expressions, B rela-
tions in OCL constraints, are presented in (Jacques
et al., 2005).
In B, the invariant consists of a number of pred-
icates separated by the conjunction operator ∧ (See
figure 1). Each B predicates are transformed in OCL
constraints separated by the OCL keyword and. The
constraint is thus obtained:
Constraint 2
context Scheduler inv :
and ready→intersection(waiting)→isEmpty()
and active→isEmpty() or
not (ready→union(waiting)→includesAll(active))
and active→size() <= 1
and active→isEmpty() implies ready→isEmpty()
3.2 Transformation of a B Operation
in OCL
3.2.1 Presentation of B Operations
We will deal here with the translation in OCL of
the clause INITIALISATION and the operations an-
ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
476

nounced in the clause OPERATIONS. An operation
is composed of a heading and a body as follows :
ResultsList ← OperationName (ParametersList) =
body
The body of the operations and the initialization are
expressed through substitutions which are mathemat-
ical notations making possible the modeling of predi-
cate transformation. The heading includes an optional
list of results implicitly typed in the body of the op-
eration and an optional list of parameters which are
explicitly typed if they exist thanks to the precondi-
tion substitution (PRE Predicate THEN Substitutions
END). The latter allows, too, to establish the precon-
dition on which an operation is called. That substi-
tution makes up the body of the B operation and the
other substitutions are included in the Substitutions
part. The parameter typing and the preconditions are
carried out in the Predicate.
The example of the Scheduler enables one to see
the initialization (in the initial state, the three sets are
empty) and two operations :
• new to create a new process and add it to waiting
• activate to activate a process of waiting and put it
in active if the set is empty, add it to ready other-
wise.
3.2.2 General Principle of Transformation
Each operation of an abstract B machine is associated
to an operation of a class representing the machine.
The initialization is represented by a specific method
called INITIALIZATION. OCL allows one to asso-
ciate an operation of a class to a precondition and a
postcondition whose syntax is as follows :
context Class::Operation(Parameters): Type
pre : precondition
post : postcondition
The OCL precondition for an operation is obtained
from the predicate of the precondition substitution.
The postcondition is obtained in two stages :
1. The B postcondition is calculated from B substitu-
tions through the mechanism of transformation into
before-after predicate (Chapters 6.3.3 and 7.1.1. in
(Abrial, 1996)).
2. The B postcondition is rewritten in OCL postcondi-
tion through the mechanism described in (Jacques
et al., 2005).
The constraints obtained through the Scheduler
example for the initialization and the operations new
and activate are as follows:
MACHINE
Scheduler
...
INITIALISATION
active, ready, waiting := ∅, ∅, ∅
OPERATIONS
new(pp) =
PRE
pp ∈
PID ∧
pp ∈ active ∧
pp ∈ (ready ∪ waiting)
THEN
waiting := waiting ∪{pp}
END;
activate(qq) =
PRE
qq ∈ waiting
THEN
waiting := waiting - {qq}||
IF (active = ∅) THEN
active := {qq}
ELSE
ready := ready ∪{qq}
END
END;
...
END
Figure 3: Dynamic part of the B scheduler example.
Constraint 3
context Scheduler::INITIALIZATION()
post : active→isEmpty() and ready→isEmpty()
and waiting→isEmpty()
context Scheduler::new(pp : Elt
PID)
pre : active→excludes (pp)
and ready→union(waiting)→excludes(pp)
post : waiting = waiting@pre→including(pp)
context Scheduler::activate(qq : Elt
PID)
pre : waiting→ includes (qq)
post : waiting = waiting@pre→excluding(qq)
and if active@pre→isEmpty() then
active = Set{qq}
else ready = ready@pre→including(qq)
endif
Actually, the postconditions have been obtained in-
tuitively. As far as the operation activate is con-
cerned, an equivalent postcondition is calculated in
3.3.
Remark 3.1 In B, an operation can produce several
results. In the UML-OCL translation the first result
is considered as the result of the operation and the
others are passed into parameters with out as passage
type.
UNDERSTANDING B SPECIFICATIONS WITH UML CLASS DIAGRAM AND OCL CONSTRAINTS
477

3.3 Example of a Postcondition
Obtained From Substitutions
The body of the activate operation is used again and
the rules defined in (Abrial, 1996) are applied to find
the B postcondition. The variables primed in B ex-
press the value of the variable after realizing the sub-
stitutions. In OCL, the before value is expressed by
suffixing the variable with @pre.
prd(waiting := waiting - {qq}||
IF (active = ∅) THEN active := {qq}
ELSE ready := ready ∪{qq}
END)
⇔
prd(waiting := waiting - {qq}) ∧
prd(IF (active = ∅)
THEN active := {qq}
ELSE ready := ready ∪{qq}
END)
⇔
waiting’ = waiting - {qq}) ∧
prd((active = ∅ =⇒ active := {qq})
[] (¬ (active = ∅) =⇒ ready := ready ∪{qq})
)
⇔
waiting’ = waiting - {qq}) ∧
(prd(active = ∅ =⇒ active := {qq})
∨ prd(¬ (active = ∅) =⇒ ready := ready ∪{qq}
)
)
⇔
waiting’ = waiting - {qq}) ∧
((active = ∅ ∧ prd(active := {qq}))
∨ (¬ (active = ∅) ∧ prd(ready := ready ∪{qq}))
)
⇔
waiting’ = waiting - {qq}) ∧
((active = ∅ ∧ active’ = {qq}))
∨ (active = ∅ ∧ ready’ = ready ∪{qq}))
)
The constraint is deduced of this postcondition :
waiting = waiting@pre→excluding(qq) and
((active@pre→isEmpty() and active = Set{qq})
or (active@pre→notEmpty()
and ready = ready@pre→including(qq))
)
4 CONCLUSIONS AND
PROSPECTS
On the whole, the passage from a B specification to an
UML-OCL modeling has proved possible throughout
the sample of examples that we processed.
The OCL constraints generated seem readable and
understandable to us though less expressive and con-
cise than the predicates expressed in B. That is partly
due to the operators directly available in B.
The next stage of our work consists in assessing
the possibility to jump forth and back between B and
UML specifications.
REFERENCES
Abrial, J. (1996). The B-Book -Assigning Programs to
Meanings. Cambridge University. Press. ISBN 0-521-
49169-5.
Behm, P., Benoit, P., A.Faivre, and J-M.Meynadier (1999).
METEOR : A successul application of B in a large
project. In FM’99 : World Congress on Formal Meth-
ods, pages 369–387. LNCS 1709.
Casset, L. (2002). Development of an Embedded Verifier
for Java Card Byte Code Using Formal Methods. In
FME’02 : Formal Methods Europe. LNCS 2391.
Hammad, B., Tatibouet, A., Voisinet, J., and Wu, W. (2002).
From a B Specification to UML Statechart Diagrams.
In 4th International Conference on Formal Engineer-
ing Methods, ICFEM’2002, pages 511–522, Shangai,
China. LNCS 2495.
Jacques, I., Tatibouet, B., and Voisinet, J. (2005). Gener-
ation of OCL Constraints from B Abstract Machines.
In SERP’05, 2005 International Conference on Soft-
ware Engineering Research and Practice, Las Vegas,
Nevada, USA.
Laleau, R. and Mammar, A. (2000). An Overview of a
Method and its support Tool for Generating B Speci-
fications from UML Notations. In The 15th IEEE Int.
Conf. on Automated Software Engineering, Grenoble
(F).
Meyer, E. and Souquieres, J. (1999). A Systematic Ap-
proach to Transform OMT Diagrams to a B Spec-
ification. In FM’99, LNCS 1708, pages 875–895.
Springer-Verlag.
Sekerinski, E. (1998). Graphical design of reactive systems.
In B’98 : Recent Advances in the Development and
Use of the B-Method, LNCS 1393. Springer-Verlag.
Tatibouet, B., Hammad, A., and Voisinet, J. (2002). From
a B Specification to UML Class Diagrams. In 2nd
IEEE International Symposium on Signal Processing
and Information Technology, ISSPIT’2002, pages 5–
10, Marrakech, Morocco. IEEE.
ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
478