-
BART(B AUTOMATIC REFINEMENT TOOL)
-USER MANUAL
Réf. : Version : 1.0 Date :
CLEARSY Société par Actions Simplifiée au Capital de 266 880
Euros. - RCS Aix-en-Provence 433 901 402 - Code NAF 721 Z320,
Avenue Archimède – Les Pléiades III - Bât A - 13857 AIX EN PROVENCE
CEDEX 3
Tél : 04 42 37 12 70 – Fax : 04 42 37 12 71
-
BART – USER MANUAL
RE V I S I O N S
Version Date Comment1.0 Initial version
Version: 1.0 Page : 2 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
IN D E X
Revisions
.................................................................................................
2 Index
......................................................................................................
3 I Introduction
............................................................................................
6 II Usage
..................................................................................................
7
II.1 Usage with AtelierB tool
......................................................................
7 II.2 Advanced users – Bart command line
................................................... 7
II.2.1 Command usage
...........................................................................
8 II.2.2 Input files
....................................................................................
8 II.2.3 Visibility for loaded components
...................................................... 8 II.2.4
Bart standard output verbosity
....................................................... 9 II.2.5
Bart rule trace
............................................................................
10
III Automatic refinement principles
............................................................. 11
III.1 Refined elements
............................................................................
11
III.1.1 Abstract variables
......................................................................
11 III.1.2 Operations
................................................................................
11 III.1.3 Initialisation
..............................................................................
12 III.1.4 Process
.....................................................................................
12
III.2 Pattern-Matching
............................................................................
12 III.2.1 Jokers syntax
............................................................................
13 III.2.2 Pattern matching
.......................................................................
13
III.3 Refinement rules
............................................................................
14 III.3.1 Introduction
..............................................................................
14 III.3.2 Constraints
...............................................................................
14 III.3.3 Guards
.....................................................................................
15 III.3.4 Rule checking process
................................................................ 16
III.3.5 Jokers use in result
....................................................................
16
III.4 Hypothesis stack – Environment analysis
........................................... 17 III.5 Result
production and writing
........................................................... 18
IV Bart guards – Predicate synonyms
.......................................................... 19 IV.1
Guards
...........................................................................................
19
IV.1.1 Expression guards
......................................................................
19 IV.1.2 Predicate guards
........................................................................
20 IV.1.3 Substitution guards
....................................................................
21
IV.2 Predicate synonyms
.........................................................................
21 V Pragmas and comments
.........................................................................
23
V.1 EMPILE_PRE, DEPILE_PRE
.................................................................
23 V.2 Magic
..............................................................................................
24
V.2.1 For variables
...............................................................................
24 V.2.2 For substitutions
..........................................................................
24
V.3 CAND
..............................................................................................
24
Version: 1.0 Page : 3 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
VI Rule files
.............................................................................................
26 VI.1 Syntax
...........................................................................................
26 VI.2 Using rule files
................................................................................
27
VI.2.1 Providing rule files on command line
............................................. 27 VI.2.2 Rule file
associated to the component
........................................... 27 VI.2.3 Bart
refinement rule base
............................................................ 27
VII Variables refinement
............................................................................
28 VII.1 Variable theories syntax
..................................................................
28 VII.2 Variable rule research
.....................................................................
29 VII.3 Storing information predicates about found variable rules
.................... 31 VII.4 Invariant for refined abstract
variables .............................................. 31 VII.5
Specifying variable refinement results
............................................... 32
VII.5.1 Using CONCRETE_VARIABLES clause
........................................... 32 VII.5.2 Using
REFINEMENT_VARIABLES clause
......................................... 33
VIII Substitution refinement
......................................................................
35 VIII.1 Rule syntax
..................................................................................
35 VIII.2 Rule research
...............................................................................
36 VIII.3 Refinement process
.......................................................................
37 VIII.4 Default refinement behaviours
........................................................ 41 VIII.5
Special refinement substitutions
...................................................... 43
VIII.5.1 Iterators
.................................................................................
43 VIII.5.2 Using operations from seen machines - SEEN_OPERATION
............ 49 VIII.5.3 Defining imported operations -
IMPORTED_OPERATION ................. 50 VIII.5.4 Controlling the
refinement process ............................................. 53
VIII.5.5 Local variable declarations
........................................................ 55
VIII.6 Declaring operation refinement variables
.......................................... 56 VIII.7 Usage of
substitution rules
.............................................................
56
VIII.7.1 Structural and operation rules - Operation refinement
................... 57 VIII.7.2 Initialisation rules
....................................................................
60
IX Tactic and user pass theories
.................................................................
63 IX.1 User pass theory
.............................................................................
63
IX.1.1 Syntax
......................................................................................
63 IX.1.2 Usage
.......................................................................................
63
IX.2 Tactic theory
..................................................................................
64 IX.2.1 Syntax
......................................................................................
64 IX.2.2 Usage
.......................................................................................
64
IX.3 Priority of Tactic and User pass theories
............................................. 65 X Result
production and writing
..................................................................
67
X.1 Formatting the result
........................................................................
67 X.2 Implementing results
........................................................................
68
X.2.1 Splitting operations in output components
..................................... 68 X.2.2 Resolving deadlocks
.....................................................................
69
XI Appendix A – Figures table
....................................................................
73 XII Appendix B – Syntax elements table
...................................................... 75 XIII
Appendix C – Rule files complete syntax
............................................... 76
XIII.1 Rule files
......................................................................................
76 XIII.2 Variables refinement rules
..............................................................
76
Version: 1.0 Page : 4 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
XIII.3 Initialisation refinement rules
......................................................... 77 XIII.4
Operation refinement rules
............................................................. 77
XIII.5 Structural refinement rules
............................................................. 78
XIII.6 User pass theory
...........................................................................
78 XIII.7 Tactic theory
................................................................................
78 XIII.8 Predicate synonyms theory
............................................................. 79
XIII.9 Substitutions
................................................................................
79 XIII.10 Predicates
..................................................................................
81 XIII.11 Expressions
................................................................................
82 XIII.12 Diverse
......................................................................................
83
Version: 1.0 Page : 5 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
I IN T R O D U C T I O N
BART is a tool that can be used to automatically refine B
components. This process is rule based so that the user can drive
refinement. Its own rule language has been defined in this
purpose.
Version: 1.0 Page : 6 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
I I US AG E
This section describes different ways to launch Bart for
processing automatic refinement.
Note: For all launching methods, Bart is supposed to work on
type-checkable components. So user should ensures, if it is not
automatically done (as with AtelierB, which does not allow
launching refinement on a component that is not type-checked), that
components are correct.
II.1 Usage with AtelierB tool
Usual way to use automatic refiner Bart is to launch it from the
AtelierB GUI. It integrates automatic refinement in the whole B
development process. Components generated by automatic refinement
are added to project component list, and can then be type-checked
and proved.
In AtelierB 4, automatic refinement can be simply launched by
selecting a component and choosing “Automatic refinement” in menu
“Component”. AtelierB then uses Bart executable, with suitable
values for parameters described in section II.2).
Settings used for launching Bart from AtelierB are:• Automatic
setting of directories containing component to refine
environment (seen machines)• Automatic selection of Bart rule
file associated to the component if any
(file with same name as the component and the .rmf extension,
which must be present in source directory)
• Automatic selection of Bart predefined rule base which comes
with AtelierB (file PatchRaffiner.rmf)
• Generation of the trace file with rs extension, but no
generation of rule trace inside generated component
• Displaying errors messages coming from Bart output
II.2 Advanced users – Bart command line
Besides launching automatic refiner from the AtelierB GUI, it is
also possible to use directly the Bart executable in command line.
It gives the user more possibilities, as providing more rule files,
customizing the way to look for seen machines, using trace
modes…
This section describes how the command should be used.
Version: 1.0 Page : 7 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
II.2.1 Command usageThe Bart command syntax is as follow (help
message displayed by
command launching without parameters):
Bart { -r rule_file } -m machine_file
Options:
Parameter Comment-h Displays this help message-d Debug. This
forces Bart to display back all the loaded
data-I dir Adds the given directory to the list of
directories
searched for machine files-v Displays more information-V
Displays more information than –v-s machine_name Adds a seen
machine-o operation_name Only refine the given operation-a
file_name Visibility file-e Handles duplicate names in rmf files as
error instead
of warning-p project Name of the project that should be loaded
(requires -b)-b path Path to the bdp of the project-H file
Indicates a file containing the header that should be
inserted in the generated machines-t Writes rule trace in the
result-g file Writes the list of generated files to file-D dir
Writes the generated files to the given directory-x Displays output
as Xml-X file Writes input machine as Xml-l Displays guards list-f
name Use given resolving information for finding path of
given component file
Figure 1 : Bart command line parameters
II.2.2 Input filesAs an input, Bart must be given at least the
machine or refinement (.mch
or .ref file) to refine. This file path must be given to Bart
using –m parameter. This given file path can be relative or
absolute. There must be exactly one component to refine.
Furthermore, user may provide rule files to process refinement
of given component. These files are .rmf suffixed, and are given
using –r parameter. User can provide zero, one or more rule files.
Their path can be relative or absolute.
II.2.3 Visibility for loaded componentsWhen Bart must load seen
machines, given component abstraction or
definition files, it must be able to find their associated files
on the file system. So at the command launching user must provide
necessary information. There are three ways to do this:
Version: 1.0 Page : 8 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
• -I dir: This option allows the user to directly specify
directories components to load must be searched in. So there can be
several –I parameters on command line.
• -a file_name: This is used to give Bart a visibility file.
Each line of this file is a research directory. This option could
be used together with –I option, in this case file directories and
command line directories are added
• -b path and –p project: With these options, information about
an AtelierB project is provided for searching components. –p option
indicates the project name, and –b is the project bdp path. –b and
–p must be present together.
All these options can not be used at the same time. Only
AtelierB project resolving is used if all these parameters are
given on command line.
II.2.4 Bart standard output verbosity
In standard output mode, Bart prints result of variables,
operations and initialisation refinement on standard output.
Variable refinement result is the list of found rules associated
to their variables. In standard output mode, operation and
initialisation refinement result is symbolized with “+” (rule
found) and “-“ (no rule could be found) characters.For example:
Refining operation operation_test++++++
Refinement of operation_test finished
Figure 2 : Example of Bart standard output
On the command line, the detail level of output can be increased
with –v (verbose mode) and –V (very verbose mode) options.
In verbose mode, the output for previous operation refinement
would be as follow:
Refining operation operation_test Rule found: theory1.rule1 Rule
found: theory1.rule2 Rule found: theory1.rule3 Rule found:
theory2.rule1 Rule found: theory2.rule2 Rule found:
theory2.rule3Refinement of operation_test finished
Version: 1.0 Page : 9 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
Figure 3 : Example of Bart verbose output mode
The failure character “-“ is replaced by a “No rule could be
found” message when launching Bart in verbose mode.
II.2.5 Bart rule traceThere are two ways to keep a trace of
rules applied by Bart.
Each time a component is refined with Bart, the tool generates a
file with same name as the component with a .rs extension (example:
machine.rs for machine.mch or machine_r.ref). This file contains
name of the rules used to refine each element.
Furthermore, user may add –t parameter on command line. This
option indicates to Bart that it must write used rule names in
comments in generated components.
Version: 1.0 Page : 10 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
I I I AU TO M AT I C R E F I N E M E N T P R I N C I P L E S
Automatic refinement is a rule based refinement process for B
components (abstractions or refinements). The tool is given a
component, and it searches, for each element to refine, some rules
that specify how it must be treated.
This section describes basic principles of automatic
refinement.
III.1 Refined elements
III.1.1 Abstract variablesFirst elements treated by Bart tool
are abstract variables of component to
refine (content of the ABSTRACT_VARIABLE clause). The tool must
produce, for each one of them, one or more abstract or concrete
variables that implement it.
III.1.2 OperationsBart processes operations of given component
in order to refine them. It
must produce, for each operation, a substitution body concrete
enough to be put in the component implementation.
Refined operations are considered for the whole component
abstraction. It means that Bart refines most concrete version of
each operation. Here is an example of this process:
Figure 4 : Example of selection of operations to refine
For this example, if the given component to refine is
Machine_2r, operations processed by Bart will be:
• Op1 from Machine• Op2 from Machine_r• Op3 from Machine_2r
Version: 1.0 Page : 11 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
• Op4 from Machine_2r
III.1.3 InitialisationBart also refines content of
initialisation clause of given component.
Typically, it produces a concrete result by specifying
initialisation substitutions for concrete variables refining
content of ABSTRACT_VARIABLES clause.
III.1.4 Process
The following draw presents the order of previously described
refinement steps.
Figure 5 : Refinement process order
Abstract variables are refined first, as other parts of the
process need its output to find suitable rules for operations and
initialisation. It is necessary at these steps to know how
variables have been refined.
This variable information is stored as predicates in Bart
hypothesis stack (cf. III.4).
As it will be described later, refinement process uses rules to
determine how each element is refined. A same rule can apply for
several elements, so it must be general. In this purpose, the rule
language uses jokers, so that rules can contain variable parts.
III.2 Pattern-Matching
A large part of the refinement process uses the concept of
pattern-matching. In Bart rule language, user can define patterns,
containing jokers, which will be matched against real B
elements.
Version: 1.0 Page : 12 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
III.2.1 Jokers syntax
In Bart, jokers are ‘@’ character followed by a single letter.
For example, @a, @x and @t are valid Bart jokers.
@_ is a special joker, used for special treatments in
pattern-matching.
III.2.2 Pattern matchingBart jokers can be used to write general
expression, predicate or
substitution patterns. These patterns can be matched against B
elements.Each pattern-matching action has a result status, as it
may be either a
success or a failure, and instantiates jokers that it
contains.
A simple joker matches with any B element. A complex pattern
matches a B element if each of its contained jokers can be
instantiated with a subpart of the element. If a joker appears
several times in a pattern, it has the same value in a unique
instantiation
If the pattern-matching is a success, jokers contain element
subparts that made the match successful. The @_ joker is a special
one, as it means that its instantiation has not to be stored. So @_
joker can stand for different elements in a same pattern if it
appears several times.
The following table shows examples of successful or failed
pattern-matching, with their status and associated jokers
instantiation.
Pattern Element Status Jokers instantiation@a aa Success {@a =
aa}@a aa + bb Success {@a = aa + bb}@a + @c yy + 2 Success {@a =
yy, @c = 2}@a + @c yy - 2 Failure -@a + @c (aa + 1) + f(3) Success
{@a = aa + 1, @b = f(3)@a + @b * @a aa + bb * 2 Failure -@a + @b *
@a aa + bb * aa Success {@a = aa, @b = bb}not(@p) not(vv < 0)
Success {@p = vv < 0}@a IF val THEN
aa := 0ELSE aa := 1END
Success {@a = IF val THEN aa := 0ELSE aa := 1END }
IF @p THEN @tELSE @eEND
IF val THEN aa := 0ELSE aa := 1END
Success {@p = val, @t = aa :=0, @e = aa := 1}
IF @_ THEN @tELSE @eEND
IF val THEN aa := 0ELSE aa := 1END
Success {@t = aa :=0, @e = aa := 1}
Version: 1.0 Page : 13 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
Figure 6 : Examples of pattern-matching without previous
instantiation
In some cases, some jokers may already be instantiated when the
pattern matching is done. An instantiated joker matches an element
if its stored value is equal to the element.
For example, if pattern is @a + @b, following table shows how
pattern-matching is done if some jokers are already
instantiated.
Element Original instantiation Status Result instantiation1 + 3
{@a = 2} Failure -1 + 3 {@a = 1} Success {@a = 1, @b = 3}aa + (1 +
bb) {@b = bb} Failure -aa + (1 + bb) {@b = 1 + bb} Success {@b = 1
+ bb, @a = aa}var1 + (var2 – 1)
{@a = var1, @b = var2 – 1}
Success {@a = var1, @b = var2 – 1}
Figure 7 : Examples of @a + @b pattern-matching with previous
instantiation
III.3 Refinement rules
III.3.1 IntroductionBart uses rules for refining variables,
operations and substitutions. These
rules belong to different types: variables rules, or
substitution rules, which can be used for both operations and
initialisation. Rules of same type are gathered in theories.
Rules usually contain a pattern, and may contain a constraint.
These two elements are used to know if a rule can be applied to
refine a certain element. Rules also contain clauses that express
the refinement result.
III.3.2 ConstraintsRules may have constraints, expressed in
their WHEN clause. A constraint
is a predicate, which may contain jokers. It may be a complex
predicate, built with “&” and “or” operators.
Bart contains a stack of hypothesis (cf. III.4), which is built
from the machine to refine and its environment. A constraint is
successfully checked if its elementary elements (element not
containing “&” or “or”) can be pattern-matched with a predicate
of the stack so that the complex constraint is true. According to
operators, Bart uses backtracking to try every combination of
instantiation that should be a success.
If several instantiations can make the constraint be
successfully checked, Bart uses one of them. In this case, it is
better to write a more detailed constraint to have only one result.
If there are several results, Bart could choose one which is not
what the user had planned.
Version: 1.0 Page : 14 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
Usually, when checking a constraint, some jokers have already
been instantiated.
Here are some examples of constraint checking, if the hypothesis
stack contains the following predicates:
Stack = {bb
-
BART – USER MANUAL
It checks that @b is an abstract variable (predicate present in
the stack), that a predicate @a
-
BART – USER MANUAL
can be reused to build new identifiers. For instance, if @i
joker was present in pattern and its value is “ident”’, user can
provide @i_r value in the result. This value will be “ident_r”
after instantiation.
For substitution rules, result pattern is a substitution. For
variable rules, it is a list of refinement variables identifiers,
invariant and initialisation. For building the result, Bart
replaces in this pattern all joker occurrences with their values
previously calculated.
III.4 Hypothesis stack – Environment analysis
At launch, Bart builds an hypothesis stack with predicates
coming from the machine to refine and its environment, and with
guards, which are predicates giving more information about
environment.
This section shows which parts of the environment are analysed
to fill the predicate stack.
Machine Predicate stackAll machines (component to refine,
abstraction, seen machines)
I &
A &
P &
SET(S) &ENUM(E) & v1 : E &…& vn : E
&COCON(v1) & …… & COCON(vn) &
COCON(CC1) & COCON(CC2) &
COVAR(CV1) & COVAR(CV2) &
ABVAR(AV1) & ABVAR(AV2) &
ABCON(AC1) & ABCON(AC2) &
DECL_OPERATION(par1 op1(par2) | body1) &
DECL_OPERATION(op3(par3) | body2)
REFVAR(AV3) & REFVAR(AV4)
INVARIANT IASSERTIONS ASeen Machines onlyPROPERTIES PSETS S; E =
{v1, …., vn}
CONCRETE_CONSTANTS CC1, CC2CONCRETE_VARIABLES CV1,
CV2ABSTRACT_VARIABLES AV1, AV2ABSTRACT_CONSTANTS AC1, AC2
OPERATIONS par1 op1(par2) = body1 ; op3(par3) = body2Component to
refine onlyABSTRACT_VARIABLES AV3, AV4
Figure 11 : Hypothesis stack filling with environment
This table presents only how parts of given component
environment are used to fill the stack. Bart doesn’t necessarily
add predicates in this exact order.
Some others stack guards will be added to the stack during
refinement process. These guards will be only presented in IV, as
they are not a part of the
Version: 1.0 Page : 17 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
initial environment analysis. Variables refinement also adds
type predicates to the stack (cf. VII.3).
III.5 Result production and writing
Once every element (variables, operations and initialisation)
has been refined, Bart must write the result. For a unique
component, there may be several output components.
Operation refinement process may define new operations called in
original ones refinement results. Furthermore, sometimes some
operations can’t be implemented in the same component. So Bart
output is actually a chain of output components, each
implementation importing the following machine. Original variables
and operations, and new operations, are implemented along the
chain.
For instance, following figure shows what could be a Bart
output, when refining the component “Machine”:
Figure 12 : Example of Bart output components
Thinnest arrows are importation links, and thick ones are
refinement links.
If an operation refinement result calls a new imported
operation, the new one must be defined and implemented further in
the chain.
Version: 1.0 Page : 18 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
IV BAR T G U AR D S – PR E D I C AT E S Y N O N Y M S
IV.1 Guards
Following tables describe Bart predefined guards, with their
name, type (stack guard or calculated guard) and short descriptions
of their meaning and side effects.
Guards description is available on command-line using the –l
parameter with bart executable. Users can add new guards, by adding
suitable classes to Bart library. Using the command line will
display all registered guards, so it may print more information
than this section.
Calculated guards usually must have all their joker instantiated
to be used, except if the description explicitly says not. Most of
stack guards should have their joker instantiated, although it is
not mandatory.
For example, user could write a simple constraint as ABVAR(@a)
where @a joker is not instantiated by rule pattern matching. This
means the constraint checks if at least one abstract variable is
present in seen machines, and @a is instantiated with one of seen
machines abstract variables identifiers, if any.
IV.1.1 Expression guards
Guard Type DescriptionABCON(expr) Stack Checks if given
expression is an identifier of a
seen machine abstract constantABVAR(expr) Stack Checks if given
expression is an identifier of a
seen machine abstract variableB0EXPR(expr) Calculated Checks if
given expression is a B0 expressionbident(expr) Calculated Checks
if given parameter is an identifierbnum(expr) Calculated Checks if
given expression is a numeric literalbpattern(expr1,expr2)
Calculated Tries to make expr2 match with expr1. expr2 may
be not fully instantiated
If the match is successful, jokers of expr2 are instantiated
COCON(expr) Stack Checks if given expression is an identifier of
a seen machine concrete constant
COVAR(expr) Stack Checks if given expression is an identifier of
a seen machine concrete variable
ENUM(expr) Stack Checks if given expression is an enumerated set
identifier from a seen machine
match(joker,expr) Calculated “joker” must be a single joker.
This guard makes
Version: 1.0 Page : 19 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
joker match with expr. Joker may be uninstantiated.
If joker is not instantiated, the guard is true and joker value
is now expr
If joker is instantiated, guard is true if g can match with
joker instantiation.
PAR_IN(expr) Stack Checks if given expression is an identifier
of a currently refined operation input parameter.
These guards are added to the stack when a new operation
refinement begins
PAR_OUT(expr) Stack Checks if given expression is an identifier
of a currently refined operation output parameter.
These guards are added to the stack when a new operation
refinement begins
REFINED(expr) Stack Checks if given expression is an identifier
of a variable introduced by another variable refinement.
These guards are added after variables refinement phase
REFVAR(expr) Stack Checks if given expression is an abstract
variable of the component to refine
SET(expr) Stack Checks if parameter is a non-enumerated set
identifier from seen machines
VAR_G(expr) Stack Checks if given parameter is a concrete
variable introduced by the operation refinement process.
Added when the concrete variable is introducedVAR_LOC(expr)
Stack Checks if given parameter is a local variable
introduced by current operation refinement.
Added when the local variable is introduced
Figure 13 : Bart expression guards
IV.1.2 Predicate guards
Guard Type DescriptionPR(pred) Calculated Checks if given
predicate is true using AtelierB prover
pred must be a simple predicate with no guardsbisfalse(pred)
Calculated Checks if not(pred) is present within the hypothesis
stack.
pred must be a simple predicate with no guardsbistrue(pred)
Calculated Checks if pred constraint can be matched against
Version: 1.0 Page : 20 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
hypothesis
pred must be a simple predicate with no guardsbnot(pred)
Calculated Checks if given constraint can not be checked
against
hypothesis
pred can contain guards
Figure 14 : Bart predicate guards
IV.1.3 Substitution guardsSome of following guards are called
substitution guards because their
parameter is internally represented as substitution by the
tool.
Guard Type DescriptionDECL_OPERATION(oper) Stack “oper” must be
an operation description that can
contain jokers.The shape of the parameter is prototype separated
of operation body with a “|”, for example: @h
-
BART – USER MANUAL
“END” .
PredicateDefinition=
ident “(“ JokerList “)” “ ” Predicate.
Syntax 1 : Predicate theory
Here is an example of this special theory:
THEORY_PREDICATES IS test(@a) bnum(@a) | NumOrIdent(@a)
bident(@a) or test(@a) | belongs(@a,@b) (@a : @b) |
ElementOfSet(@d) < => @d : @s END
Figure 16 : Predicate theory example
Left part of each line is a synonym. It is a predicate
identifier with a list of jokers between parentheses. Right part is
the value, it’s a predicate containing jokers. When these keywords
are found in a rule file, they are replaced by predicates described
on the right part. Jokers present in the value and in the synonym
are replaced by the element given at use. Others jokers are left
unchanged.
For example, if the preceding predicate theory is used and a
rule has the following constraint:
belongs(@c,INT) & 0
-
BART – USER MANUAL
V PR AG M AS AN D C O M M E N T S
In most cases, Bart tries to keep comments from original B
component elements, and to rewrite them beside suitable refinement
results.
Pragmas are special comments that the user writes in the B
component to refine in order to impact the refinement process.
These elements are not processed by AtelierB, but only by Bart.
AtelierB processes them as simple comments. Each pragma begins with
/* pragma_b.
V.1 EMPILE_PRE, DEPILE_PRE
These two pragmas are used to modify the top of Bart predicate
stack. They must be written before a substitution of an operation
from the machine to refine. They are used when the refinement of
the substitution they are written before begins.
/* pragma_b EMPILE_PRE(predicate) */ is used to add predicate at
the top of the hypothesis stack.
/* pragma_b DEPILE_PRE */ is used to remove last predicates
added to the stack.
For example, if Bart must refines following substitution:
IF valeur > 100 THEN/* pragma_b EMPILE_PRE(valeur > 0)
*/Substitution1
ELSE/* pragma_b DEPILE_PRE */Substitution2
END
Figure 17 : Substitution for EMPILE_PRE and DEPILE_PRE
example
Let’s assume that Bart adds the if condition for refining the
THEN branch, and the negation of the condition for refining the
ELSE branch. Following table presents the stack state depending on
pragmas presence.
Branch StackWithout pragma With pragma
Then branch valeur > 100 &Previous predicates
valeur > 0 &valeur > 100 &Previous predicates
Else branch Not(valeur > 100) & Previous predicates
Version: 1.0 Page : 23 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
Previous predicates
Figure 18 : Example of stack evolution with EMPILE_PRE and
DEPILE_PRE
V.2 Magic
Pragma MAGIC can be used to directly specify in B components
which rules must be used to refine certain elements (variables or
substitutions). It is useful to force use of a certain rule. The
given one is used even if suitable rules could be found before it
in a regular rule research. Bart checks that the given rule can be
applied to the element (pattern matching and constraint
checking).
V.2.1 For variablesMagic pragma is used to specify which rule
should be used to refine a
certain variable. The syntax is /* pragma_b
MAGIC(theory.rule,variable) */. It means that given rule from given
theory will be used to refine the variable.
Variable magic pragmas must be put at the machine beginning.
There can be several magic pragmas at the machine beginning. As the
rule file is not specified, Bart processes rule files in the
classic rule research order to find the rule in the suitable
theory. If no such rule is found, a refinement error occurs.
V.2.2 For substitutions
Magic pragma can also be used for refining substitutions. The
pragma must be written directly before the involved substitution in
the B model. The syntax is /* pragma_b MAGIC(theory.rule) */
For example:
/* pragma_b MAGIC(theory_operation.r_affect_bool) */bool_value
:= TRUE
will refine the substitution using r_affect_bool rule in theory
theory_operation.
V.3 CAND
This pragma has a particular shape. It must be written /* CAND
*/, and be put just before a “&” operator in B model.
It means that this operator is a conditional and (right part is
not evaluated if left part is false).
Version: 1.0 Page : 24 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
A “&” operator from B model that has a /* CAND */ pragma
will match with cand operator of Bart rule files.
Version: 1.0 Page : 25 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
VI RU L E F I L E S
VI.1 Syntax
Rule files are files containing theories, each theory containing
one or several rules used to refine given component. Rule file
extension is usually .rmf.
A rule file can contain variable, operation, structure and
initialisation theories. It can also contain utility theories such
as tactic, user pass, or definition of predicates synonyms.
Syntax of rule files is:
RuleFile = [ Theory { "&" Theory } ].
Theory=VariableTheory| OperationTheory| StructureTheory|
InitialisationTheory| UserPassTheory| TacticTheory|
PredicateTheory.
Syntax 2 : Rule files
The rule file syntax must also respect certain constraints:•
User pass can be present at most once• Tactic can be present at
most once• Predicate theory can be present at most once
Order between theories has no syntactical impact, expect for
predicates theory: it must be defined before its elements are used
in the rule.
Order between theories has an impact on the rule research, as
the standard process (no user pass or tactic) reads theories from
bottom to top.
User pass and tactic can be defined anywhere in the file, even
before theories they refer to have been defined.
Version: 1.0 Page : 26 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
VI.2 Using rule files
VI.2.1 Providing rule files on command lineAs it was previously
described, user provides rules files when lauching Bart
by using –r parameter. This parameter can be present several
times, and is not mandatory.
When it searches for rules, Bart processes rule files from right
to left, according to command line order.
Let’s consider following command line:./bart –m machine.mch –r
rule2.rmf –r rule1.rmf
For a given element to refine, the tool will search first in
rule1.rmf, and then in rule2.rmf if the first file did not contain
a suitable rule.
VI.2.2 Rule file associated to the componentIf directory that
contains the given machine file also contains a rule file
with same name, it has not to be specified on the command line,
Bart will automatically load it.
If such a file is present, it will be used in priority (as it
had been given last using –r parameter on command line).
For this command line:./bart –m machine.mch –r rule.rmf
, Bart will look for machine.rmf in current directory. If it is
present, rule files will be used in this order: machine.rmf, then
rule.rmf.
VI.2.3 Bart refinement rule baseThe tool comes with a set of
predefined rule base, contained in the file
PatchRaffiner.rmf present in Bart distribution. It provides
rules that permit to refine most of the classical B
substitutions.
When Bart is used on command line, the rule base must be
provided using –r parameter.
The classical automatic refinement scheme is the following: most
elements of given component can be refined using the rule base. If
an element can not be refined with it, or needs a more specific
treatment, user should write suitable rules in rmf files that will
be provided after the rule base on command line, or in the
component associated rule file.
Version: 1.0 Page : 27 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
VII VAR I AB L E S R E F I N E M E N T
VII.1 Variable theories syntax
VariableTheory=
"THEORY_VARIABLE" ident"IS" VariableRule { ";" VariableRule
}"END" ident
.
VariableRule=
"RULE" ident ["(" JokerList ")" ]"VARIABLE" JokerList[ "TYPE"
ident "(" JokerList ")" ][ "WHEN" Predicate ]"IMPORT_TYPE"
Predicate(VariableImplementation | VariablesRefinement )"END"
.
VariableImplementation ="CONCRETE_VARIABLES" JokerList[
"DECLARATION" Predicate ]"INVARIANT" Predicate
.
VariablesRefinement ="REFINEMENT_VARIABLES"VariableRefinement {
"," VariableRefinement }"GLUING_INVARIANT" Predicate
.
VariableRefinement ="CONCRETE_VARIABLE" joker"WITH_INV"
Predicate"END"| "ABSTRACT_VARIABLE" joker"REFINED_BY" ident “.”
ident "(" Expression ")""WITH_INV" Predicate"END"
.
Syntax 3 : Variable rule theories
Each theory has an identifier, which must be repeated after the
END keyword. A theory can contain several rules, each rule having
its own unique identifier. Each following subsection will associate
a variable refinement functionality with one or more clauses of
variable rules.
Version: 1.0 Page : 28 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
VII.2 Variable rule research
Variable rule research is different from rule research for
operations and initialisation. Instead of processing each variable
and finding a suitable rule for it, it processes each rule of
considered theories (all variable theories or a subset if tactic or
user pass is used, cf. IX) and checks if it can be used to refine
some variables.
This is necessary because a single variable rule can be used to
refine several variables. Once a rule has been selected for one (or
several) variable, resulting refinement variables can be calculated
from its clauses.
The principle of rule research is the following:
• At the beginning the tool considers the set of abstract
variables to refine• It processes every theory that could be used
(according to tactic, user pass or
neither) from bottom to top. For each theory:o The tool
processes all rules of theory from bottom to top. For each
variable
rule: Bart determines which variables can be refined by current
rule Refined variables are removed from the set of remaining
variables
Figure 19 : Processing variable theories to find rules
This process stops when there are not variables to refine
anymore, or when all variable rules to consider have been treated.
Variable refinement is successful if all variables have been
associated with a rule. It is a failure if all rules have been
treated and some variables could not be refined.
For a certain rule, Bart determines which variables it can
refine as follow:
• The tool tries every combination of values to instantiate
joker list of VARIABLE clause. For each instantiation:
o Bart checks constraint expressed in WHEN clause against
hypothesis stack, with jokers of VARIABLE clause instantiated
If WHEN constraint could be checked, variables used to
instantiate VARIABLE clause can be refined by this rule
Variable refined by the rule are removed from set of remaining
variables, to be sure they won’t be used in following tried
instantiation
Figure 20 : Searching variables refined by a particular rule
If current rule has several jokers in VARIABLE clause, there are
more combinations to try than for simple variable rules.
Following example presents results of a variable rule research,
with given theories and predicates stacks. Variable to refine are
{aa, bb, cc, dd, ee}.
Theories StackTHEORY_VARIABLE t1 IS aa : INT &
bb : INT &
Version: 1.0 Page : 29 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
RULE r1 VARIABLE @a WHEN @a : INT & @b < @a &
ABCON(@b) […] END;
RULE r2 VARIABLE @a, @b WHEN @a : INT & @b : NAT & @a
< 0 & 0
-
BART – USER MANUAL
VII.3 Storing information predicates about found variable
rules
Bart allows specifying, in variable rules, predicates that will
be added in the stack if the rule is selected. These predicates
will be called “Type predicates” and are specified in TYPE clause
of variable rules.
Type predicates are constituted of an identifier and a joker
list between parentheses. They are added to the stack after
variables refinement, to be reused in operations and initialisation
refinement (in substitution rules constrains). Jokers of the joker
list must be have been present in VARIABLE or WHEN clauses, because
they have to be instantiated for the type predicate to be added to
the stack.
If we reuse previous example and complete rules with these TYPE
clauses:
RULE r1 VARIABLE @a TYPE COMP(@a,@b) WHEN @a : INT & @b <
@a & ABCON(@b) […] END
RULE r2 VARIABLE @a, @b TYPE DOUBLE(@a,@b) WHEN @a : INT &
@b : NAT & @a < 0 & 0
-
BART – USER MANUAL
VII.5 Specifying variable refinement results
Refinement results for abstract variables are specified in
REFINEMENT_VARIABLES or CONCRETE_VARIABLES clauses of variables
rules. These two clauses can not be used at the same time.
VII.5.1 Using CONCRETE_VARIABLES clauseUsing CONCRETE_VARIABLE
clause is simpler than using
REFINEMENT_VARIABLES, but it is less powerful as it is
impossible to specify abstract refinement variables. This clause
corresponds to the VariableImplementation element of the syntax
presented in VII.1.
This clause contains a list of jokerized identifiers
(CONCRETE_VARIABLES clause), which will be concrete variables
refining abstract variable treated by the rule, and the invariant
that will be added for these concrete variables (INVARIANT clause).
Jokers in the invariant must have been instantiated during the rule
selection. Expressions designating new concrete variable must be
built on previously instantiated jokers.
As the result is a joker list, and not a single joker, it is
possible to specify several refinement variables for a unique
rule.
For example, if the rule:
RULE r_ensVARIABLE
@aTYPE
raffinement_ensemble(@a, @b, @c)WHEN
SET(@c) &@a BOOL & ee = ee_r~[{TRUE}].
Version: 1.0 Page : 32 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
VII.5.2 Using REFINEMENT_VARIABLES clause
Using this clause allows specifying both concrete and abstract
variable to refine the abstract variable treated by the rule. It
corresponds to VariablesRefinement element of syntax described in
VII.1.
This clause must contain a list of VariableRefinement elements
as described in the syntax in VII.1. Each one of these elements
specify a refinement variable (abstract or concrete), and its
associated invariant. For refinement abstract variables, rule that
will be used to refine it must also be provided, with its
parameters (cf. example). Jokers contained in subparts of these
elements must all have been previously instantiated.
After the list of refinement variables, the GLUING_INVARIANT
clause must be written. This predicate is the invariant that will
be put in output components when all refinement variables will have
been implemented. This predicate must only contain previously
instantiated jokers.
Following rule using REFINEMENT_VARIABLES clause is equivalent
to the previously described one:
RULE r_ensVARIABLE
@aTYPE
raffinement_ensemble(@a, @b, @c)WHEN
SET(@c) &@a
-
BART – USER MANUAL
REFINEMENT_VARIABLESABSTRACT_VARIABLE @a_rREFINED_BY
theory.abstract_rule(@a_r)WITH_INV @a_r : @c --> BOOL
&END
GLUING_INVARIANT@a = @a_r~[{TRUE}]
END
Figure 27 : Variable refinement rule with abstract variable
Here we directly specify which rule will be used to refine the
new variable in REFINED_BY clause. The syntax is
theory.rule(parameters). Values specified between parentheses after
the rule name are parameters. This means that the given rule must
have parameters, like this:
RULE abstract_rule(@a)VARIABLE @a[…]END
When a rule is given for a new refinement variable, the VARIABLE
and WHEN clause jokers are instantiated with the variable name and
the parameters. Then the regular rule checking process goes on as
the WHEN constraint is verified.
If new abstract variables are introduced, a REFINEMENT component
will be introduced in output chain.
Version: 1.0 Page : 34 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
VII I SU B S T I T U T I O N R E F I N E M E N T
Substitution refinement gathers operation, initialisation and
structural rules. Operation and structure rules are identical.
Initialisation rules are simpler versions of operation rules.
Syntax and principles of substitution refinement will be
presented through operations rules. A further section will be
dedicated to the different kind of substitution rules, their usage
and differences. So in first sections of this chapter, “refining a
substitution” will stand for “refining a substitution from an
operation”.
Substitution refinement is more complex than variable
refinement, as it can be recursive, i.e. result of refinement for a
given substitution may have to be refined too. Furthermore, for a
given substitution, refinement may need several sub-processes (cf.
SUB_REFINEMENT clause or default refinement behaviours for parallel
or semicolon). So refinement sub-branches are created and the
underlying structure that can be used to represent substitution
refinement is in fact a tree.
VIII.1Rule syntax
Here is the syntax of operation theories:
OperationTheory=
"THEORY_OPERATION" ident"IS" OperationRule { ";" OperationRule
}"END" ident
.
OperationRule=
"RULE" ident"REFINES" Substitution[ "WHEN" Predicate ][
"SUB_REFINEMENT" SubRefinementRule { "," SubRefinementRule } ](
"REFINEMENT" | "IMPLEMENTATION")
{ RefinementVarDecl } Substitution
["IMPLEMENT" IdentOrJokerList ]"END"
.
RefinementVarDecl =("VARIABLE" | “ABSTRACT_VARIABLE” |
“CONCRETE_VARIABLE”) joker[ "REFINED_BY" ident "(" Expression ")"
]
Version: 1.0 Page : 35 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
"WITH_INV" Predicate"WITH_INIT" Substitution"IN"
.
SubRefinementRule ="(" Substitution ")" "->" "(" Joker
")"
.
Syntax 4 : Operation rule theories
Syntax for others kinds of substitution rules will be presented
further.
As for variable theories, an identifier must be present after
THEORY_OPERATION keyword and repeated after the END keyword.
VIII.2Rule research
The substitution rule research process is simpler than for
variables.
• For a substitution to refine, Bart processes each rule file as
long as he could not find a rule.
• For each rule file it processes operation theories to consider
(all theories, or a subset if tactic or user pass is used, cf. IX)
from bottom to top.
• For each theory it processes operation rules from bottom to
top• For each rule, Bart checks if it can be used to refine
currently treated
substitution.
If each rule file was processed by Bart and no rule could be
found for a certain substitution, an operation refinement may occur
(cf. VIII.3).
Each operation rule has a pattern (REFINES clause) and may have
a constraint (WHEN clause). The process used to check if a rule can
be applied to a substitution is as described in III.3.4.
First the tool tries to match the rule pattern with the
substitution. If it is successful, the rule can be applied under
the condition it has no WHEN constraint or its WHEN constraint can
be checked against hypothesis stack.
For example, if par_out := par_in1 + par_in2 must be refined,
with following theories and stack:
Theories StackTHEORY_OPERATION assign_plus IS RULE
r_assign_plus_par_in REFINES @a := @b + @c WHEN PAR_OUT(@a) &
PAR_IN(@b) & PAR_IN(@c) […]
PAR_OUT(par_out) &PAR_IN(par_in1) &PAR_IN(par_in2)
Version: 1.0 Page : 36 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
END;
RULE r_assign_plus_const REFINES @a := @b + @c WHEN PAR_OUT(@a)
& ABCON(@b) & ABCON(@c) […] ENDEND assign_plus &
THEORY_VARIABLE assign_minus IS RULE assign_minus_1 REFINES @a
:= @b - @c […] ENDEND assign_minus
Figure 28 : Theories and stack for operation rule research
Let’s suppose that for this rule file there is no tactic or user
pass. The rule research will be as follow:
• First tried rule is assign_minus.assign_minus_1. Its pattern
doesn’t match the substitution, so it can not be used
• Second tried rule is assign_plus.assign_plus_const. Its
pattern matches the substitution, but its WHEN constraint can not
be checked, so it can not be used
• Third tried rule is assign_plus.assign_plus_par_in. Its
pattern matches the substitution, and its WHEN constraint can be
checked, so this rule is selected.
Figure 29 : Example of operation rule research
VIII.3Refinement process
The substitution refinement process depends, for given rule and
substitution, on the presence and content of SUB_REFINEMENT,
IMPLEMENTATION and REFINEMENT clauses.
SUB_REFINEMENT clause corresponds to SubRefinementRule element
of syntax described in VIII.1. It contains a “,” separated list of
sub-elements.
Each sub-element left part is a substitution that may contain
jokers. These jokers must all have been instantiated by pattern
matching and constraint checking. Right part of the sub-element
must be a single and still uninstantiated joker.
This clause is used to refine the given substitution and store
the result in given joker. This is done before calculation of the
rule substitution result, so the sub-refinement can be used to
express the result.
IMPLEMENTATION clause expresses the result of current rule. It
contains a substitution which may contain jokers. All these jokers
must have been
Version: 1.0 Page : 37 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
instantiated during pattern matching, constraint checking or
sub-refinement processing. IMPLEMENTATION clause may also contain
concrete operation refinement variable declaration (cf.
VIII.6).
Using IMPLEMENTATION clause means that given result is the final
result of current branch and doesn’t need to be refined again.
REFINEMENT clause expresses the result of current rule. It
contains a substitution which may contain jokers. All these jokers
must have been instantiated during pattern matching, constraint
checking or sub-refinement processing. REFINEMENT clause may also
contain abstract or concrete operation refinement variable
declaration (cf. VIII.6).
Using REFINEMENT clause means that given result is not the final
result of current branch. The result of rule must be refined.
IMPLEMENTATION and REFINEMENT clause can not be both used in a
same rule. When a rule has been selected (and eventual
sub-refinements have been processed), the rule result is calculated
by instantiating jokers of its result clause.
A rule can contain both SUB_REFINEMENT and REFINEMENT clauses.
In this case, each subrefinement is calculated and stored in its
joker. Then content of REFINEMENT clause is instantiated and
refined.
For a substitution to refine, if no rule could be found, Bart
will check if it can be refined using a “predefined behaviour”. For
some kinds of substitutions, Bart may know how to refine them if no
rule is present. Predefined behaviour can be the end of current
branch (skip substitution refinement) or a simple node of
refinement tree. In this case, Bart may create one (BEGIN
substitution refinement) or several (semicolon refinement) subnodes
in refinement tree for current substitution. For each new subnode
created by predefined refinement behaviour, the recursive
refinement process is restarted as a rule or predefined behaviour
will be searched for each one.
Following figure summarizes the process:
Version: 1.0 Page : 38 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
Figure 30 : Process of substitution refinement
Rectangles are actions processed by Bart. Ellipses are
decisions. Error and success boxes represent error and success for
current branch (an error in current branch means error in the whole
refinement process).
Subrefinement computations are represented aside because they
must be calculated for the result to be instantiated, but
refinement of substitutions contained in left part of
SUB_REFINEMENT clauses sub-elements uses the same process.
For example, if we consider following substitution to
refine:
IF in < 0 THENaa := aa + 1
ELSEaa := 0
END
and the following theories:
THEORY_OPERATION theory IS
RULE assignREFINES @a := @bIMPLEMENTATION
Version: 1.0 Page : 39 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
@a := @bEND;
RULE r_assign_plus_2REFINES @a := @b + @cIMPLEMENTATION @a := @b
+ @cEND;
RULE r_assign_plusREFINES @a := @b + @cWHEN
bnot(B0EXPR(@a))REFINEMENT #1 := @b + @c ; @a := #1
END ;
RULE r_ifREFINES IF @a THEN @b ELSE @c ENDSUB_REFINEMENT (@b)
-> (@d), (@c) -> (@e)IMPLEMENTATION #1 := bool(@a); IF #1 =
TRUE THEN @d ELSE @e ENDEND
END theory
Figure 31 : Substitution and theories for rule tree example
#x expressions written in rules result clauses are used to
introduce local variables (cf. VIII.5.5).
For this example the resulting rule tree will be:
Version: 1.0 Page : 40 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
Figure 32 : Example of refinement rule tree
Each rectangle (except the first one which shows only the first
found rule) shows the substitution to refine at current node, and
the found rule.
First rule (r_if) has its result described in an IMPLEMENTATION
clause but the refinement goes on as it contains SUB_REFINEMENT
clauses. The refinement of r_assign_plus_rule_2 rule result uses
the predefined refinement behaviour for semicolon.
For the refinement of this substitution, the result will be:
l_1 := bool(in < 0);IF l_1 = TRUE THEN
l2 := bb + 1; aa := l_2ELSE
aa := 0END
VIII.4Default refinement behaviours
When a substitution must be refined and no rule could be found
for it, Bart may apply a predefined behaviour to process refinement
further.
If both a rule and a predefined behaviour are suitable for a
substitution, the rule will be applied. For example Bart knows by
default how to refine a semicolon substitution. But if a rule is
present with @a;@b pattern and a WHEN constraint that can be
checked for current substitution, Bart will use the rule.
Version: 1.0 Page : 41 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
Following table show which kind of substitutions can be refined
by Bart even if no rule could be found in rule files. Here are only
shown regular B substitutions that can be refined by predefined
behaviours. Some Bart specific substitutions use this mechanism to
control the refinement process, they will be described later.
In this table result(sub) means refinement result of
substitution sub.
Substitution Refinement result CommentSemicolon :sub1 ; sub
2
result(sub1); result(sub2)
-
Parallel:sub1 || sub2
sequentialization(result(sub1) ;result(sub2))
Result is sequentialized. Variables modified in left part and
read in right part are stored in local variables
Bloc substitution:BEGIN subEND
BEGIN result(sub)END
-
Guarded substitution:PRE predicateTHEN subEND
BEGIN result(sub)END
“predicate” is added to the hypothesis stack for refining
“sub”
Assertion substitution:ASSERT predicateTHEN subEND
ASSERT predicateTHEN result(sub)END
“predicate” is added to the hypothesis stack for refining
“sub”
Operation call Refined by itself -Skip Refined by itself -Local
variables :VAR listIN subEND
VAR listIN result(sub)END
VAR_LOC hypothesis is added to the stack for each element of
“list”
Loop substitution:WHILE condition DO bodyINVARIANT IVARIANT
VEND
WHILE condition DO result(sub)INVARIANT IVARIANT VEND
“condition” is added to the hypothesis stack for refining
“body”
Figure 33 : Bart predefined refinement behaviours
Version: 1.0 Page : 42 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
As described in the table, a sequentialization is done when a
parallel substitution is refined. For example if aa := bb || cc :=
aa must be refined and each branch is refined by itself, result
without sequentialization would be aa := bb ; cc := aa, which is
incorrect. So Bart makes sequentialization, and the real produced
result will be l_1 := aa; aa := bb; cc := l_1, where l_1 is a local
variable declared for the sequentialization. The local variable
will be declared with others ones coming from # declaration in
rules (cf. VIII.5.5).
VIII.5Special refinement substitutions
In operation rules result clauses, it is possible to use Bart
specific substitutions to control the refinement process or add
elements to the produced result.
These substitutions don’t exist in regular B models, and they
can only be written in REFINEMENT or IMPLEMENTATION clauses of
substitution rules and used to express the rule result. As they are
present only in result clauses, all jokers contained in these
substitutions must have been instantiated before. They are
presented in following sections.
VIII.5.1 IteratorsSeveral substitutions can be used in Bart to
manage iterators. These
substitutions become WHILE loops when the result of rule they
are written in is calculated. At the same time, some of them
generate iterator machines that contains operations called in
generated while loops. These generated machines are then refined by
Bart using predefined rules.
VIII.5.1.1 TYPE_ITERATION
TYPE_ITERATION substitution allows specifying loops iterating on
all elements of a set. In the produced implementation, this
substitution is replaced by an automatically built WHILE loop which
calls operations from an iteration machine created by Bart.
TYPE_ITERATION substitution syntax is as follow:
"TYPE_ITERATION" "("[ ("tant_que"|"while") "=>"
IdentOrJokerOrVarDecl "," ]"index" "=>" Expression ",""type"
"=>" Expression ",""body" "=>" "(" Substitution ")"
",""invariant" "=>" Predicate
")"
Version: 1.0 Page : 43 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
Syntax 5 : Type iteration
The different clauses meaning is:• while: It must be given a
variable (instantiated or not). This clause may be
used if the iteration might be stopped before all elements of
the set have been processed. If while clause is present, the loop
continues as long as there are still more elements in the set, and
given variable is TRUE. Given variable should be set to FALSE in
the user defined loop body part to stop the loop
• index : Name of the variable that will contain each element of
the given set
• type : Set the loop is iterating on• body : User defined part
of the loop body • invariant : User defined part of the loop
invariant
This shows how Bart generates the WHILE loop for a
TYPE_ITERATION substitution (with no while clause):
vg_loop
-
BART – USER MANUAL
END
Figure 35 : Type iteration generated loop, with while
parameter
In these generated loops, called operations are defined in the
following generated machine:
MACHINEiterator_name
ABSTRACT_VARIABLESTYPE_remaining, TYPE_done
INVARIANTTYPE_remaining
-
BART – USER MANUAL
VIII.5.1.2 INVARIANT_ITERATION
As TYPE_ITERATION, this substitution allows to automatically
generate loops. But here, iteration is done on the image of a
relation element.
INVARIANT_ITERATION syntax is:
"INVARIANT_ITERATION" "("[ ("tant_que"|"while") "=>"
IdentOrJokerOrVardecl "," ]"1st" "index" "=>" Expression
",""2nd" "index" "=>" Expression ",""constant" "=>"
Expression ",""1st" "type" "=>" Expression ",""2nd" "type"
"=>" Expression ",""body" "=>" "(" Substitution ")"
",""invariant" "=>" "(" Predicate ")"
")"
Syntax 6 : Invariant iteration syntax Clauses meaning is:
• while : If present, provides a variable which permits to
interrupt the loop before its natural ending
• constant : Defines the relation which will be used to iterate•
1st index: Defines original element of iteration. Iteration will be
done on
constant[{1st index}]• 2nd index : Element storing current
element of the loop• 1st type : Type of constant domain elements•
2nd type : Type of constant range elements• body : User defined
part of the loop body• invariant : User defined part of the loop
invariant
Generated loop for an INVARIANT substitution is:
vg_loop
-
BART – USER MANUAL
As for TYPE_ITERATION, vg_loop := bool(vg_loop = TRUE &
while = TRUE) will be added to the loop body if a while
substitution is added.
Generated iteration machine for a single INVARIANT_ITERATION
is:
MACHINEiterator_name
ABSTRACT_VARIABLESCONSTANT_remaining,CONSTANT_done
INVARIANTCONSTANT_remaining
-
BART – USER MANUAL
VIII.5.1.3 CONCRETE_ITERATION
CONCRETE_ITERATION substitution also produces automatically
generated WHILE loops. Unlike TYPE_ITERATION or
INVARIANT_ITERATION, these loops don’t use any iteration
machine.
Syntax for CONCRETE_ITERATION substitution is:
"CONCRETE_ITERATION" "(""init_while" "=>" "(" Substitution
")" ","("tant_que"|"while") "=>" Expression ",""body" "=>"
"(" Substitution ")" ",""invariant" "=>" "(" Predicate ")"
",""variant" "=>" Expression ",""flag" "=>" IdentOrJoker
")"
Syntax 7 : Concrete iteration
The generated loop for this substitution is:
init_while;vg_loop := bool( while );WHILE vg_loop = TRUE DO
/*? Flag iteration: flag ?*/body ;vg_loop := bool( while )
INVARIANTinvariant
VARIANTvariant
END
Figure 39 : Concrete iteration generated loop
VIII.5.1.4 Iteration components
During refinement process, Bart stores information about
iteration machines used by operations refinement and defined by
TYPE_ITERATION or INVARIANT_ITERATION substitutions.
After splitting refinement results in output components (cf. X),
Bart creates an iteration machine associated to each generated
implementation, if necessary. Each iteration machine generated
contains variables and operations for all iterators defined and
used by refinement of operations implemented in associated
implementation.
Following table presents which abstract variables and operations
are generated in iteration machines for the refinement of a
component “Machine”, according to TYPE_ITERATION and
INVARIANT_ITERATION substitutions used during refinement.
Version: 1.0 Page : 48 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
Iterators used by operations refinement
Associated iteration machine
Machine_i -Operation1: No iterator definedMachine1_i
Machine1_itOperation2: Type iterator on type 1 Invariant iterator
on const1Operation3: Type iterator on type2Operation4: Invariant
iterator on const1
Abstract variables: type1_remaining, type1_done,
const1_remaining, const1_done, type2_remaining,
type2_doneOperations: init_iteration_type1 ;
continue_iteration_type1; init_iteration_const1;
continue_iteration_const1; init_iteration_type2;
continue_iteration_type2
Machine2_i Machine2_itOperation5: Type iterator on
type2Operation6: Invariant iterator on const2
Abstract variables: type2_remaining, type2_done,
const2_remaining, const2_doneOperations: init_iteration_type2;
continue_iteration_type2; init_iteration_const2;
continue_iteration_const2
Figure 40 : Example of generated iterators
If a same iterator is used by several operations of
implementation, it is only created once in iteration machine. Bart
gathers all iteration variables and operations necessary for all
refinement results written in the implementation. Invariant and
initialisation are generated according to defined variables. Real
iteration machines are actually merges of iteration machines
presented in VIII.5.1.1 and VIII.5.1.2.
VIII.5.2 Using operations from seen machines -
SEEN_OPERATION
SEEN_OPERATION substitution is used to insert a call to an
operation from a seen machine in the rule result. Its syntax
is:
"SEEN_OPERATION" "(""name" "=>" IdentOrJoker ",""out" "=>"
"(" [ IdentJokerVardeclList ] ")" ",""in" "=>" "(" [
IdentJokerVardeclList ] ")" ","“ body “ “ => “ “(“ Substitution
“)“
" ) "
Syntax 8 : Seen operation
• name : Name of the operation to use• out : Output parameters
of the operation call
Version: 1.0 Page : 49 / 83 Ce document est la propriété de
ClearSy - TOUTE REPRODUCTION OU UTILISATION PARTIELLE OU TOTALE DE
CELUI-CI EST INTERDITE SANS SON ACCORD PRÉALABLE.
-
BART – USER MANUAL
• in : Input parameters of the operation call• body:
Substitution that may be used by Bart to control in seen
machines
that it corresponds to the given identifier. For now the control
is not done, so the clause can be filled with @_ joker
For example, SEEN_OPERATION(
name => operation,out => (out1),in => (in1),body =>
(@_) )
will be converted in out1
-
BART – USER MANUAL
• input: Input call parameters. Formal input parameters for the
operation definition will also be generated from this list
• pre : User defined part of the precondition for the new
operation• body : The new operation body
VIII.5.3.1 Naming new operations
If name clause is given in IMPORTED_OPERATION, Bart will
generate a unique name from it by adding a number suffix to the
identifier.
Else Bart will use current operation name as a base, and will
add number suffix to it. For example, IMPORTED_OPERATION
substitution used in refinement of operation1 may generate
operation1_1, operation1_2, etc.
As there can be several level of overlapped operations (ex:
operation generates operation1 which generates others operations),
Bart may add several numbers to an original pattern. To avoid
conflicts in naming, it adds underscore after the first counter and
before each counter greater than 10.
For example :
operation -> operation1 -> operation1_1 ->
operation1_1_11operation -> operation1 -> operation1_1 ->
operation1_11 -> operation1_111
Figure 41 : Imported operation naming example
VIII.5.3.2 Operation parameters
The user can provide input or output parameters for the
operation.
Following table presents an IMPORTED_OPERATION treatment in a
simple case where instantation is {@a = aa, @b = bb, @c= cc}. For
this example we do not consider operation abstraction and
hypothesis stack (cf. VIII.5.3.3).
Rule Operation call Generated operationIMPORTED_OPERATION(
name => addout => (@a),in => (@b,@c),pre => (@b :
INT &
@c : INT),body => (@a := @b +
@c) )
aa
-
BART – USER MANUAL
In these cases, generated operation would be incorrect, as these
identifiers would be unknown in the machine the new operation will
be declared in. So in these particular cases, Bart automatically
adds inputs (for read ones) or output (modified ones) parameters to
give these values to the newly defined operation.
Let’s consider a new example with instanciation {@a = aa, @e =
bb + cc}, in which bb and cc are input parameters of current
refined operation, and without considering the hypothesis stack or
operation abstraction:
Rule Operation call Generated operationIMPORTED_OPERATION(
name => addout => (@a),body => (@a := @e) )
aa
-
BART – USER MANUAL
Bart, when adding those predicates, doesn’t check if user has
put some of them in its “pre” clause, so sometimes predicates can
appear several times. Basic typing predicates are often
automatically added as they are normally present in previous
abstractions. “pre” clause of the substitution should better be
used for more complex and specific predicates.
Here is an example of Bart automatic predicate adding. The
instantiation is {@a = aa, @b = bb, @c = cc}. bb and cc are input
parameters of current operation, and the stack contains bb :
INTEGER & cc : INTEGER (coming for example from operation
precondition).
Rule Operation call Generated operationIMPORTED_OPERATION(
name => addout => (@a),in => (@b,@c),body => (@a :=
@b +
@c) )
aa
-
BART – USER MANUAL
Usage of IMPLEMENT only makes sense in a REFINEMENT clause, as
refinement stops when result is expressed in an IMPLEMENTATION
one.
For example if IMPLEMENT(aa := 1) is present in a rule clause,
aa := 1 will be written without being more refined, while others
parts of the result clause may have their refinement processed
further.
VIII.5.4.2 LH
LH stands for “Local Hypothesis” substitution. Its syntax
is:
"LH" Predicate "THEN" Substitution "END"
Syntax 11 : LH
It is not translated in B substitution by Bart when the result
clause is instantiated, but it allows the user to add a hypothesis
for refining given substitution.
As IMPLEMENT, LH usage doesn’t make sense in IMPLEMENTATION
clause. It can be used in REFINEMENT, an