![](bg2.png)
paper is structured as follows. Section 2 presents the
kernel of our proposal, it presents the proposed ap-
proach UML AD and Event B. Section 3 discusses
the interest of this approach for the verification and
the validation of distributed and parallel applications.
2 THE PROPOSED APPROACH
The purpose of our approach is to produce a B spec-
ification from a giving UML AD in order to verify
and check its dynamic properties (Bjorner, 1987) such
as deadlock freeness. The proposed translation gives
not only a syntactical translation, but also a formal
semantic using the Event B method semantic. Conse-
quently, we have to focus both on the activity diagram
and its meta-model in order to have a coherent trans-
lation (Vidal, 2006).
UMLActivity Diagram +Meta‐model
Identificationofthestaticpartofthe
resultingBspecificationbyapplyingrules.
Identificationofthedynamicpartof
theresultingBspecification
Step1
Bspecificationrepresentingthe
activitydiagram.
Informaldescriptionof
requiredproperties.
DescriptionofrequiredpropertiesintheEventBmodel.
Bconstraintshavetobeprovedontheobtainedspecification.
IntroductionofinvariantsdescribingrequiredpropertiesintheEventBmodel.
Step2
BspecificationrepresentingtheactivitydiagramandpropertiesdescribingUMLADcorrectness.
Proving those properties using a B tool (B4free).
Figure 1: Overview of the translation process.
The translation process illustrated in 1, proceeds
in three steps. The first one consists of identifying the
body of the B specification from an UML AD by ap-
plying a set of rules divided into structural rules and
semantics ones. The second step enriches the result-
ing model by relevant properties that will be proved
in the third step using a B prover (Pllana and Fahring,
2002). The verification of these properties ensures the
correctness and the validation of the UML AD.
2.1 The Translation Approach: Step1
The main goal of this step 1 is to translate an activity
diagram into a B specification, this translation deals
with both the syntactical and semantics of UML
AD. The syntactical translation is based on the UML
Activity diagram and its meta-model. We associate
to each activity diagram concept a translation rule
describing its equivalent construction in event B.
Rule 1. An activity diagram is translated into a B
model.
ActivityNode can be described by their type (ac-
tion node, initial node, decision node .) and an at-
tribute id to verify their uniqueness, consequently.
This abstract class can be seen as a description of
a set of objects identified by two attributes: id and
type. We suggested so to translate an abstract class
ActivityNode into an abstract set and all the derived
classes are transformed into data included in this ab-
stract set. The most appropriate B expression is the B
record (Abrial, 1996).
rec(ident1 : x, ident2 : y, , identn : t)
Where (x, y, ..t, E
1
, E
2
, , E
N
) are respectively the
values and type of fields (ident
1
, ident
2
, ident
n
). Since
the derived nodes are identified by their identifier and
their type, we propose to specify two fields for the
record: field Id
n
ode to identify the node and field and
Type to indicate its type. The abstract class is so trans-
lated into the following B record:
Nodes = Struct(Id − node : integer, Type : String).
In that manner, each node is considered as
data record of Nodes and then is translated into
rec(Id = a, Type = b).
Rule 2. The abstract class ActivityNode is trans-
lated into a B record: Nodes = Struct(Id − node :
integer, Type : String), in the clause DEFINITION of
the B model, and having as elements the different
nodes defined in the activity diagram that we aim to
translate. The nodes are then translated into vari-
ables node
i
, declared in the VARIABLES clause and
typed in the INVARIANT clause: node
i
∈ Nodes.
The abstract class ActivityEdge is related with
the class ActivityNode by two relations: target
and source. Hence, each edge has only one target
node and one source node. Besides to this relation,
the activity diagrams meta-model specifies other
relation with the class ValueSpeci f ication : guard, to
indicate that an edge is carrying tokens or not. We
propose so to specify four fields to describe those
relations:Id-edge, Id-source, Id-target and Ready to
indicate if the edge is carrying tokens or not.
Rule 3. The abstract class ActivityEdge is translated
into a B record: Edges = (Id
e
dge : integer, id
s
ource :
integer, Id
t
arget : integer, ready : boolean), declared
in the clause DEFINIT ION of the B model, and hav-
ing as elements the different edges defined in the ac-
tivity diagram that we aim to translate. The edges
are then translated into variables edge
i
, declared in
the VARIABLES clause and typed in the INVARIANTS
clause: arc
i
∈ Edges.
ICSOFT 2010 - 5th International Conference on Software and Data Technologies
330