Biomedical Engineering Reference
In-Depth Information
The translation tool uses a similar kind of fashion to translate each event of the
Event-B model. Event-B is a very rich modelling language for representing for-
mal notation of a specification, but translation tool supports only subset of formal
notations of Event-B. Event-B expressions and statements are code generated,
such that the generated code behaves like it is expected from the specification.
A set of translation rules and basic syntactic architecture is defined in Tables
7.2
,
7.3
and
7.4
. During the code translation process, a run-time exception function
is generated if an undefined expression or an error statement is occurred. A gen-
erated error invokes an exception function, which terminates the code translation
process and reports that an undefined expression into a code generation log file.
The next level of the translation tool presents the scheduling techniques to pro-
duce an executable code.
7.3.6 Events Scheduling
This phase is not producing any translation part of the translation tool. This section
introduces to generate a function for organising all event functions. There are two
ways to organise all the event functions:
1.
Optimise
: An optimised code is used to make a group of calling event functions
into a new function. An incremental refinement-based structure of events within
an Event-B model provides grouping information about the events. A recursive
algorithm is used in the translation tool to discover structuring information from
current Rodin project, and could exploit it to recursively generate nesting call-
ing a set of functions corresponding to the abstract events. Merging of common
event guards is currently avoided in order to preserve direct mapping between
Event-B statements and translated code, at the cost of possible performance opti-
misations. However, if translatable guards are already placed in an abstract level,
then guards are forming a group of concrete events. An event group is inserted for
execution in place of multiple events for improving the run-time performance.
Figure
7.2
shows a basic architecture of event scheduling using optimisa-
tion approach. This figure represents a tree structure of the refinement develop-
ment, where an abstract model is represented as
AM
and refinement models are
represented through
RM
1
, RM
2
...
, and finally concrete models are represented
by
CM
. All refinement models (
RM
i
) are parts of the single abstract refinement
(
AM
). This figure has two groups
G
1
and
G
2
.
G
1
makes a group of a set of
events at first refinement level and
G
2
makes a group of events at the second
refinement level. A user can select the refinement level for making a group of
events before code generation. Each group has a set of events, which are only
executable when abstract guards are
true
. If a user select higher number of re-
finement level for optimisation then the number of groups may be increased. For
instance, in Fig.
7.2
group
G
1
has refinement level 1, therefore there are three
possible number of groups, while in the group
G
2
has refinement level 2 and
possible number of maximum groups are five corresponding to the number of
blocks in each refinement level.
Search WWH ::
Custom Search