TOWARDS A FORMAL VERIFICATION OF PROCESS
MODEL’S PROPERTIES
SimplePDL and TOCL Case Study
Beno
ˆ
ıt Combemale, Pierre-Lo
¨
ıc Garoche, Xavier Cr
´
egut and Xavier Thirioux
Institut de Recherche en Informatique de Toulouse (CNRS UMR 5505), Toulouse, France
Francois Vernadat
Laboratoire d’Analyse et d’Architecture des Systemes (CNRS), Toulouse, France
Keywords:
Metamodelling, Properties Validation, Verification, Temporal OCL, Process Model, Petri Nets, LTL, Models
Semantics, Model Transformation.
Abstract:
More and more, models, through Domain Specific Languages (DSL), tend to be the solution to define complex
systems. Expressing properties specific to these metamodels and checking them appear as an urgent need.
Until now, the only complete industrial solutions that are available consider structural properties such as the
ones that could be expressed in OCL. There are although some attempts on behavioural properties for DSL.
This paper addresses a method to specify and then check temporal properties over models. The case study is
SIMPLEPDL, a process metamodel. We propose a way to use a temporal extension of OCL, TOCL, to express
properties. We specify a models transformation to Petri Nets and LTL formulae for both the process model
and its associated temporal properties. We check these properties using a model checker and enrich the model
with the analysis results. This work is a first step towards a generic framework to specify and effectively check
temporal properties over arbitrary models.
1 INTRODUCTION
Domain specific approaches tend to be the next ap-
proach for specifying complex systems, giving the
appropriate abstraction. They can be easily built by
domain experts and can then be integrated in generic
toolkits and frameworks. Nowadays, there exists
a bunch of environments allowing to define DSL
(EMF
1
, GME
2
...) mainly focusing on abstract and
concrete syntaxes.
Once a metamodel specific to a particular domain
has been defined, one wants to express properties that
have to be verified for models of this DSL. Such ex-
tensions are usually expressed in OCL and describe
structural properties of the model. Initially OCL con-
straints were applied to UML models. Therefore
many works and tools have been designed in order
to verify these constraints. Tools developed for UML
have been adapted to DSL.
However, for behavioural properties, there is a
1
http://www.eclipse.org/emf/
2
http://www.isis.vanderbilt.edu/projects/
gme/
lack of effective works that define all the steps from
the property specification to its effective verification.
Numerous current projects, such as Topcased
3
, con-
sider these problematics as a main topic.
The paper introduces a property-driven approach
for specifying and checking temporal properties. The
case study is process engineering. Our approach can
be described as simple steps. We first characterise
the properties. Then process states must be identi-
fied. The DSL metamodel is then extended to repre-
sent these states. We adapt an OCL temporal exten-
sion, formalized using a LTL semantics (Chaki et al.,
2004), to represent our temporal properties. The prop-
erties are then checked in another formalism: Petri
nets. A model transformation to Petri nets is given
and allows to apply model checking on an observa-
tional abstraction of the trace semantics of the given
model with respect to the properties. Finally the re-
sult of the analysis is used to enrich the model with
properties information.
3
Toolkit In OPen source for Critical Applications and
SystEms Development, http://www.topcased.org
80
Combemale B., Garoche P., Crégut X., Thirioux X. and Vernadat F. (2007).
TOWARDS A FORMAL VERIFICATION OF PROCESS MODEL’S PROPERTIES - SimplePDL and TOCL Case Study.
In Proceedings of the Ninth International Conference on Enterprise Information Systems - ISAS, pages 80-89
DOI: 10.5220/0002399800800089
Copyright
c
 SciTePress

This paper gives the following contributions:
• we propose a property-driven approach to identify
dynamic states of process models;
• we introduce a temporal extension of OCL based
on process states;
• we translate temporal constraints into LTL con-
straints on the Petri nets;
• we propose an observational trace semantics for
SIMPLEPDL;
• we define SIMPLEPDL denotational semantics
though a mapping to Petri nets;
• we define a front end for the Tina model checker.
This paper is organised as follows: the second
section introduces our DSL, a process metamodel, as
well as the natural expression of the user needs for
models validation. The third section develops our
proposition on our case study. The fourth section con-
siders related works then the last section concludes.
2 CASE STUDY: PROCESS
MODEL VALIDATION
Our contribution is introduced through a modelling
language example on which we would like to express
a set of properties that have to be verified on all possi-
ble models. Our DSL is a simple process description
language: SIMPLEPDL.
We first introduce the domain concepts of SIM-
PLEPDL and then the kind of properties we want to
check on models. The properties we are interested in
are properties specific to our DSL that must be satis-
fied for every model of our metamodel. In fact, our
approach of verification is driven by those properties.
Properties allows to caracterise SIMPLEPDL models
states and then refine the metamodel to capture them.
2.1 SIMPLEPDL
SIMPLEPDL is an experimental language for speci-
fying processes. The SPEM standard (Software Pro-
cess Engineering Metamodel) (omg, 2005) proposed
by the OMG inspires our work
4
, but we also take
ideas from the UMA metamodel (Unified Method Ar-
chitecture) used in the EPF Eclipse plug-in
5
(Eclipse
Process Framework), dedicated to process modelling.
It is simplified to keep the presentation simple.
4
We propose an analysis of the SPEM 1.1 standard
in (Combemale et al., 2006a)
5
http://www.eclipse.org/epf/
The SIMPLEPDL metamodel is given in Figure 1.
It defines the process concept (Process) composed of
a set of work definitions (WorkDefinition) represent-
ing the activities to be performed during the devel-
opment. One workdefinition may depend upon an-
other (WorkSequence). In such a case, an ordering
constraint (linkType) on the second workdefinition is
specified, using the enumeration WorkSequenceType.
For example, two workdefinitions WD1 and WD2
linked by a precedence relation of kind finishToStart
specify that WD2 will be able to start only when WD1
is finished (and respectively for startToStart, start-
ToFinish and finishToFinish). SIMPLEPDL does also
allow to explicitly represent resources (Resource) that
are needed in order to perform one workdefinition
(designer, computer, server, ...) and also time con-
straints (min
time and max time on WorkDefinition
and Process) to specify the minimum (resp. maxi-
mum) time allowed to perform the workdefinition or
the whole process.
One can remark that, for the sake of brevity, some
concepts are not presented here such as products
(WorkProduct) that workdefinitions handle, or roles
(Role) that can be assimilated to resources.
2.2 Properties
We now present the different kinds of properties spe-
cific to the proposed metamodel: structural ones, tem-
poral ones and quantitative ones. We will particularly
develop the second kind as a core concept for the rest
of the paper.
Structural properties: The expressivity of meta-
modelling languages (i.e. meta-metamodels) does not
allow to formally capture the whole set of the lan-
guage properties, i.e. the axiomatic semantics. They
mainly capture the cardinalities constraints
In programming languages, the axiomatic seman-
tics is usually based on mathematical logics and ex-
presses a proof method for some construction prop-
erties of a language (Cousot, 1990). It can be very
general, such as Hoare triples or restricted to ensure
construction consistency (e.g. typing).
In a modelling language, this second kind of use
is expressed using well formedness rules at the meta-
model level. Such rules have to be realised by all
models that are conform to this metamodel. One can
check these rules by static analysis on models.
In order to express the rules, the OMG advocates
the use of OCL (omg, 2003; Warmer and Kleppe,
2003). Applied at the metamodel level, OCL can add
properties, mostly structural, that could not have been
captured by the metamodel definition. It is a mean to
TOWARDS A FORMAL VERIFICATION OF PROCESS MODEL'S PROPERTIES SIMPLEPDL AND TOCL CASE
STUDY
81

Figure 1: SIMPLEPDL metamodel.
precise the metamodel semantics by limiting possible
conforming models.
There is an example of such a constraint:
One Worksequence could not have the same
Workdefinition as source and target.
That can be formalised as
context WorkSequence inv :
self.predecessor <> self.successor
In order to check that a particular model satis-
fies these constraints, one can use an OCL checker
such as USE (Richters and Gogolla, 2000), OSLO
6
,
or EMFT
7
.
Temporal properties: Many properties have to be
satisfied in every model execution. The expert of the
domain will formalise them when defining the meta-
model. In our process metamodel, any workdefinition
can be started and then be finished. One can then ask,
and therefore check, whether a given process model
effectively terminates, i.e. that every workdefinition
in it finishes. Taking into account time and resources,
some new properties appear that are independent of
any model. For a given set of resources, described in
the model, does the process terminate ? Is it possible
to satisfy every real time constraints expressed on the
workdefinition (attributes min
time and max time) ?
We could also express temporal properties depending
on the capability for a workdefinition to suspend its
work and free its resources to share them temporarily
with other workdefinitions.
6
Open Source Library for OCL,
http:
//oslo-project.berlios.de
.
7
The Eclipse Modeling Framework Technology project,
http://www.eclipse.org/emft/
Quantitative properties: The aim of such proper-
ties is to describe or compute critical paths of exe-
cutions in terms of minimal or maximal resource con-
sumption. WCET
8
or schedulability are typical exam-
ples of quantitative properties. For instance, time and
memory are standard resources the usage of which
one would wish to measure. In this respect, a con-
sumption (and production) model has first to be set.
In simple situations, a discrete and finite model may
fit the needs, as it is the case when we focus on a
single kind of resource, with a fixed and finite num-
ber of instances. Memory requirements alone usually
fall in this simple class and could be checked with
off-the-shelf model-checking techniques for discrete
models, nevertheless with possible minor adaptations.
Yet, for more involved models and resources, in order
to precisely represent what is happening, we may find
it mandatory to write down quite general arithmetical
constraints or to handle continuous quantities (as in
real-time systems specifications for instance). As dis-
cussions about relevance of such models and their ver-
ification issues are quite complex and out of the scope
of this present work, we choose for the time being to
simply rule out quantitative properties and postpone
their introduction for future works. Thus, we stick to
the presentation of the overall methodology without
delving upon details.
2.3 Dynamic Informations &
Property-Driven Approach
Expressing temporal properties that have to be
checked on each model execution implies the exis-
tence of an operational semantics that is not expressed
8
Worst Case Execution Time
ICEIS 2007 - International Conference on Enterprise Information Systems
82

within a metamodelling language such as the MOF.
In our case, the execution of a process model con-
sists in performing the different work definitions of
the process. When executing a model, every work
definition must be started and the overall process must
finally reach a state where all of them are in the state
finished.
The real semantics can be arbitrary complex, and
sometimes non computer-representable in case of
complex continuous systems.
Our previous works have investigated the use of
operational semantics (Combemale et al., 2006b) and
translational semantics (Combemale et al., 2007). In
this paper we present a generic approach to define the
abstract dynamic semantics, a semantics of observ-
able events, built upon the properties expressed at the
metamodel level.
The temporal properties expressed for every
model conform to the metamodel are built over a
notion of states. The formal semantics associated
to the system can be seen as the set of maximal fi-
nite traces which elements are model states. If the
metamodel has a well defined operational semantics,
it can be easily expressed as a modification of in-
stances’ attributes or a modification of the topology
(dynamically creating or killing instances). On the
contrary, if the associated semantics is not formally
defined, the states characterised by properties allow to
define an observable operational semantics. Follow-
ing this idea, if state properties rely on notions that
cannot be directly expressed in the model (classical
OCL queries), then the metamodel must be enriched
to express these notions. The dynamic operational se-
mantics, i.e. the Kripke structure that allows to build
trace semantics, must then be approximated by defin-
ing transition between characterised states. It is the
work of the domain expert to describe them.
This approach has mainly three advantages:
• it gives a method to define a formal semantics for
metamodel that could not always initially describe
it;
• this approach is incremental: the domain expert
can specify a property, that characterises new
states. Then he will extend the metamodel to rep-
resent this new dynamic information. The expert
can then introduce another property and extend
again the metamodel.
• it allows to easily define an “observable” approxi-
mation of the trace semantics. One such approach
allows to check the properties defined, because the
semantics were defined depending on the needs
expressed by these properties. It can also help in
defining a minimal abstract semantics that gives
access to formal tools allowing to check proper-
ties on a reasonably-sized state space.
3 AN APPROACH TO
VALIDATION THROUGH
PETRI NETS AND LTL
In this section, we will follow all the steps that al-
low us to express temporal constraints on our SIM-
PLEPDL metamodel.
3.1 Characterising Properties
This first step must be realised by the expert. As
expert of processes, we say that every SIMPLEPDL
model must verify the following properties. We sep-
arate them in two classes: universal properties that
have to be satisfied by every execution and existential
properties that must be true in at least one execution.
Our universal properties are:
• every workdefinition must start,
• all started workdefinitions must finish,
• once a workdefinition is finished, it has to stay in
this state,
• a workdefinition is able to start depending on
worksequences constraints. All workdefinitions
that are linked to it using a startToStart workse-
quence are started. Reciprocally all workdefini-
tions that are linked to it using a finishedToStart
worksequence are finished.
The same kind of properties apply for finishing
each workdefinition.
Our existential properties are:
• every workdefinition must take more than
min
time and less than max time to be performed,
• the overall process is able to finish, i.e. when all
workdefinitions are finished in a good state (i.e.
between min
time and max time).
3.2 Characterising States
The second step consists in characterising different
states for the metamodel elements from the proper-
ties. From the aforementioned temporal properties,
we can identify two orthogonal ideas for the workdef-
inition element. First, a workdefinition can be not
started, started and finally finished. Secondly, there is
a notion of time and clock associated to each workdef-
inition; but this time is only relevant for transition
enabling conditions (in our case transitions that start
TOWARDS A FORMAL VERIFICATION OF PROCESS MODEL'S PROPERTIES SIMPLEPDL AND TOCL CASE
STUDY
83

and finish a workdefinition) and is not explicit in state
properties. Thus it can be represented into the finite
set of states { tooEarly, ok , tooLate }. This second
orthogonal idea is only relevant when the progress is
finished. Therefore we add a fourth state: notFin-
ished.
3.3 Extending the Metamodel to
Represent Dynamic Information
We now have to express these states by extending
the WorkDefinition elements in order to introduce at-
tributes that reflect dynamic information, i.e. the state
of the current workdefinition. We choose to add three
variables: state ∈ {notStarted, started, finished},
time
state ∈ {notFinished, tooEarly, ok, tooLate}
and clock ∈ R
+
.
An observational abstraction of the operational se-
mantics of our processes with respect to our proper-
ties can now be defined.
The expert has again to formalise the initial states
and the transition relation. In our case, it is quite
natural: the initial states are the singleton {w 7→
(notStarted, notFinished)|w ∈
W D }. We define the
transition relation for one workdefinition in
W D in
Figure 2.
3.4 Expressing Temporal Properties:
Temporal OCL
A few temporal extensions of OCL have already been
proposed in a UML context (see related works sec-
tion). We have chosen the proposal of (Ziemann and
Gogolla, 2002) for two main reasons:
1. The semantics of the temporal expressions is for-
mally defined on a trace semantics. Such traces
are finite sequences of system states, describing a
snapshot of the running system. Even if this work
was initially defined on UML models, the trace se-
mantics can be easily generalised to arbitrary state
sequences while keeping the original semantics of
temporal operators.
2. The syntax of this OCL extension is quite natural.
It introduces usual future-oriented temporal oper-
ators such as next, existsNext, always, sometimes
as well as their past-oriented duals. We will only
use the future-oriented ones because we intend to
effectively check properties using the Tina model
checker (Berthomieu et al., 2004), which does not
support past-oriented operators.
Let us go back to our process example to intro-
duce our generalisation. A snapshot of our process
has to describe precisely the state of each workdefini-
tion. We take as given a finite set
S of such states. Let
W D be the set of workdefinitions of the model. Let
Σ be the set of the process state: Σ =
W D 7→ S .
A trace
ˆ
σ of the process is a maximal finite se-
quence of process states hσ
0
, . . . , σ
n
i, σ
i
∈ Σ, where
σ
0
denotes the initial process state. Semantically,
we have two kinds of transitions. First, continuous
time-passing transitions that are here unobservable
and consist in incrementing all workdefinition clocks
by a quantity dt simultaneously. Second, event-based
transitions that change the states of workdefinitions as
defined by the expert above. Two consecutive events
in a sequence are related through a combination of the
time-passing transition followed by an event-based
transition.
In order to ease the definition of our properties we
introduce the new operator precedes. Such an opera-
tor can be described using the previous ones:
e
1
precedes e
2
= always!(e
2
) until e
1
Expressions of our TOCL extension are now OCL
expressions over the model elements using these tem-
poral operators. We also allow these expressions to be
built over state names defined in the aforementioned
set
S . The universal temporal properties can now be
expressed as:
always (
notStarted =⇒ sometime started )
always (
started =⇒ sometime finished )
finished =⇒ always finished
always ((preds
s
.state = started &&
pred
f
.state =
finished &&
notStarted ) =⇒ sometime started )
The existential ones have to be rewritten in order
to be checked: we will verify the negation of each for-
mula. If the analysis gives a correct answer, there is
no trace satisfying the property. On the contrary, if
the analysis gives a negative answer with a counter-
example, the existential property is verified and the
counter-example is one of the traces satisfying the
temporal property. We only give here the first exis-
tential property.
always (not wd.time
state = ok)
≡ always (wd.time
state = tooEarly
||wd.time
state = tooLate)
We have given the textual concrete syntax and the as-
sociated semantics of our extension of TOCL. In or-
der to integrate it into a metamodelling approach (i.e.
defining properties at the metamodel level), it is nec-
essary to define, at the MOF level, the OCL abstract
syntax and its temporal extension. To give the abil-
ity for any DSL to use TOCL, we start from the OCL
ICEIS 2007 - International Conference on Enterprise Information Systems
84

Let w be the considered Work Definition.
∀ws = w. predecessor, (ws.linkType = startToStart&&ws.linkToPredecessor.state = started)
||(ws.linkType = finishedToStart&&ws.linkToPredecessor.state = finished)
notStarted, notFinished, clock → started, notFinished, 0
∀ws = w. predecessor, (ws.linkType = startToFinished&&ws.linkToPredecessor.state = started)
||(ws.linkType = finishedToFinished&&ws.linkToPredecessor.state = finished)
started, notFinished, clock < min
time → finished,tooEarly, clock
started, notFinished, clock ∈ [min
time, max time] → finished, ok, clock
started, notFinished, clock > max
time → finished,tooLate, clock
Figure 2: Event-based Transition Relation for WorkDefinitions.
MOF::Core::Basic
Type
Property
constrainedElement
1..*
properties
0..*
OCL::Expression
OclExpression
body
0..1
TOCL
ToclOperator
arguments
1..2
{ordered}
Figure 3: Temporal OCL integration to MOF.
metamodel defined in (Richters and Gogolla, 1999)
and promote it at the MOF level (omg, 2006) (fig.
3). We also add the set of temporal operators defined
in (Ziemann and Gogolla, 2002) and in the aforemen-
tioned extension (fig. 3).
We have now introduced the concrete and abstract
syntax and semantics of our temporal OCL extension.
With these temporal constraints we are now able to
express complex properties on the behaviour of the
model to be checked. One immediate application of
these constraints is the transformation of every invari-
ant as defined in OCL as the first kind of properties.
We now consider executing models and each invariant
has to be checked in every process state of all possible
traces. Therefore, we rename invariant expressions e
to always e.
The next part introduces how these model states
can be built using OCL over model attributes.
3.5 Denotational Semantics to Petri Net
and LTL
In this study, we choose to use the technical space
of Petri nets as the target representation for formally
expressing our process models. We also choose to ex-
press our temporal formulae as LTL formaluae (Lin-
ear Temporal Logic) over the Petri net associated to
a process model. Then we manipulate Petri nets and
LTL formulae within the Tina
9
toolkit.
9
http://www.laas.fr/tina/
TINA (TIme Petri Net Analyser). is a software en-
vironment to edit and analyse Petri nets and timed
nets (Berthomieu et al., 2004). The different tools
constituting the environment can be used alone or to-
gether. Some of these tools will be used in this study:
• nd (NetDraw) : nd is an editing tool for automatas
and timed networks, under a textual or graphi-
cal form. It integrates a “step by step” simulator
(graphical or textual) for the timed networks and
allows to call other tools without leaving the edi-
tor.
• Tina : this tool builds the state space of a Petri
net, timed or not. Tina can perform classical con-
structs (marking graphs, covering trees) and also
allows abstract state space construction, based on
partial order techniques. Tina proposes, for timed
networks, all quotient graph constructions dis-
cussed in (Berthomieu and Vernadat, 2006).
• selt: usually, it is necessary to check more specific
properties than the ones dedicated to general ac-
cessibility alone, such as boundedness, deadlocks,
pseudo liveness and liveness already checked by
tina. The selt tool is a model-checker for for-
mulae of an extension of temporal logic seltl
(State/Event LTL) of (Chaki et al., 2004). In case
of non satisfiability, selt is able to build a read-
able counter-example sequence or in a more com-
pressed form usable by the TINA simulator, in or-
der to execute it step by step.
3.5.1 Denotational Semantics of SIMPLEPDL
PetriNet. In this case study, we use timed Petri nets
as a paradigm to express the semantics of our pro-
cesses, models of SIMPLEPDL. The semantics is now
a denotational one defined as a mapping from SIM-
PLEPDL to Petri nets. The Petri nets metamodel is
given in Figure 4. A Petri net (PetriNet) is com-
posed of nodes (Node) that denote places (Place) or
transitions (Transition). Nodes are linked together by
TOWARDS A FORMAL VERIFICATION OF PROCESS MODEL'S PROPERTIES SIMPLEPDL AND TOCL CASE
STUDY
85

Figure 4: Petri Nets Metamodel.
arcs (Arc). Arcs can be normal ones or read-arcs (Ar-
cKind). The attribute tokensNb specifies the number
of tokens consumed in the source place or produced
in the target one (in case of a read-arc, it is only used
to check whether the source place contains at least the
specified number of tokens). Petri nets markings are
defined by the tokensNb attributes of places. Finally,
a time interval can be expressed on transitions.
Mapping. The translation schema that trans-
forms a process model into a Petri nets model
(SIMPLEPDL2PETRINET) is given in Figure 5. Each
workdefinition is translated into four places charac-
terising its state (NotStarted, Started, InProgress or
Finished). A WorkSequence becomes a read-arc from
one place of the source workdefinition to a transition
of the target workdefinition. The state Started records
that the workdefinition has been started.
We also add five places that will define a local
clock. The clock will be in state TooEarly when the
workdefinition ends before min
time and in the state
TooLate when the workdefinition ends after max
time.
Our transformation has been written in ATL, AT-
LAS Transformation Language (Jouault and Kurtev,
2005). A first rule expresses one workdefinition in
terms of places and transitions. A second one trans-
lates a work sequence into a read-arc between the ad-
equate place of the source workdefinition and the ap-
propriate transition of the target workdefinition. Fi-
nally a third rule considers the whole process and
builds the associated Petri net.
In order to manipulate the obtained Petri net in-
side a dedicated tool such as Tina, we have com-
posed the preceding transformation with a transfor-
mation PETRINET2TINA that translates a PetriNet
model into the textual syntax of the Tina tool.
Traceability. The set of translation choices (i.e.
the mapping) defined in the SIMPLEPDL2PETRINET
transformation is captured in the ATL source code.
The benefit of this language is that it is itself defined
as a metamodel. It allows to obtain a model (conform
to the ATL metamodel) corresponding to the trans-
formation. This transformation model can be reused
as an entry model for another transformation (Higher
Order Transformation). We can remark that it is pos-
sible to enrich traceability information as proposed
by (Jouault, 2005).
3.5.2 Denotational Semantics of TOCL
The transformation model defined during the trans-
lation to Petri nets is used to instantiate a generic
transformation that defines LTL properties from the
initial metamodel properties, instantiated relatively to
the initial process model.
Our experiments show a lack in current MDE
technology that does not allow to parameterise a
model transformation. The use of a programming lan-
guage such as Java, as well as a specific library such
as EMF, is necessary to handle such a transformation.
3.6 Models Validation and Feedback
Model checking results have to be interpreted at the
SIMPLEPDL model level in order to provide a com-
plete front-end to the end-user. Properties verified in
the Petri net correspond to a double instantiation of
the properties expressed at the metamodel level. The
interpretation of the results must be the conjunction
of the results obtained for the different instantiations
of a metamodel property.
The feedback of properties results (catching in a
first time the truth value of the property) in the model,
can be automatically computed using the transfor-
mation model defined during the translation SIM-
PLEPDL2PETRINET. This translation captures the
set of choices that have been done during the transfor-
mation (i.e. the mapping table). This technique uses a
Higher Order Transformation that takes a transforma-
tion model and allows to trace back the model checker
interpretation into the DSL model.
In a first time, we only handle the boolean value
returned by the Tina analyser. When the LTL proper-
ties associated to one SIMPLEPDL properties are sat-
isfied, the property is satisfied. In the other case, the
transformation model allows to identify in the model
the faulty element and to update its dynamic informa-
tion in order to visualise the state in which the prop-
erty failed. We have to take care of the kind (universal
or existential) of temporal properties expressed. In
case of an existential one, the negation of the result
has to be returned.
The next step consists in handling counter-
examples. Such counter-examples generated by the
ICEIS 2007 - International Conference on Enterprise Information Systems
86

<<WorkDefinition>>
Conception
--------------------
temps_min = 10
temps_max = 16
<<Ressource>>
Machine
--------------------
nbOccurence = 4
2
<<WorkSequence>>
ws
wd1_started wd2_start
ws.linkType = startToStart
wd1_finished wd2_start
ws.linkType = finishToStart
wd1_started wd2_finish
ws.linkType = startToFinish
wd1_finished wd2_finish
ws.linkType = finishToFinish
Figure 5: Translation schema from SIMPLEPDL to PetriNet.
model checker could be expressed on the model and
be then injected in the model animator (in our case,
the one defined on SIMPLEPDL) defined in the Top-
cased project.
4 RELATED WORKS
4.1 Models Semantics
The formal semantics definition of modelling lan-
guages is an active research field in the MDE commu-
nity. Beside our previous works presented in (Combe-
male et al., 2006b) and (Combemale et al., 2007), we
have identified other projects that consider this impor-
tant subject.
The ISIS laboratory of the Vanderbilt University
focuses on MDE for many years. They proposed
the MIC approach (Model-Integrated Computing), in
which models are at the heart of the integrated soft-
ware development. Recently, they propose, in (Chen
et al., 2005), a semantics anchored to a model of for-
mal semantics built upon ASM (Abstract State Ma-
chine) (Gurevich, 2001), using the transformation
language GReAT (Graph Rewriting And Transforma-
tion language) (Agrawal et al., 2005).
Xactium
10
is a company created in 2003. Its ob-
jectives are to provide practical solutions for the de-
velopment of systems based on MDE principles. It
developed the XMF-Mosaic tool (Clark et al., 2004)
that allows to define a DSL, to simulate and to vali-
date models using a extension of the OCL language
named xOCL (eXecutable OCL). XMF-Mosaic also
provides means to transform models and to define
translations to other technical spaces.
These works are very near to the objectives of the
TOPCASED environment, i.e. to propose a modular
modelling environment based on a modular genera-
tive approach (like GME, XMF), as well as a formal
semantics that provides simulation and model valida-
tion tools. Our works based on Kermeta follow an ap-
proach similar to the ones of xOCL inside the XMF-
Mosaic tool.
The semantics anchoring proposed by the ISIS
laboratory is similar to the denotational semantics
such as the mapping to Petri nets we propose. The
main difference is that we want to give more flexibil-
ity in the choice of the semantics model and to allow
easier feedbacks from simulations or verifications in-
side a particular model. However, they do not propose
the use of models rewriting rules to define the opera-
10
http://www.xactium.com
TOWARDS A FORMAL VERIFICATION OF PROCESS MODEL'S PROPERTIES SIMPLEPDL AND TOCL CASE
STUDY
87

tional semantics.
4.2 Models Verification
Verification of UML models. In order to specify
structural properties on UML models, OCL was in-
troduced. It is therefore accepted as the standard lan-
guage to express structural properties on UML mod-
els. There also exists a bunch of tools to check OCL
properties for any model.
As for temporal properties, some recent works in-
tend to extend the usual OCL syntax and semantics
to give the capability to express temporal constraints.
All these works address OCL extensions in an UML
context. They do not address how the transition sys-
tem is derived from the model.
The aforementioned work of (Ziemann and
Gogolla, 2002) proposed to extend OCL with usual
temporal operators and defined their semantics on the
trace semantics of the UML model. This work is a
first step towards the simulation of temporal proper-
ties over traces using the USE tool.
Some works, such as (Flake, 2003) and (Flake
and Mueller, 2003), are focused on the expression of
real time constraints while keeping the original OCL
syntax. They relied on StateChart states to express
the dynamic constraints of the system. Then, they
mapped their constraints into Clocked-CTL.
(Cengarle and Knapp, 2002) proposed to express
real time constraints using two new classes Time and
Events. A new OCL template is introduced and the
usual ones (pre-post, inv and action) are translated in
it. The semantics is also defined as a trace semantics.
In (Distefano et al., 2000), the authors expressed
non temporal OCL constraints into their object-
oriented version of CTL. They defined formally what
is a state of the UML model. They are able to check
whether a property expressed in OCL can be checked
in every reachable state.
The work of (Bradfield et al., 2002) intro-
duced new OCL templates. They mapped them
into
O µ(OCL)-calculus, an observational µ-calculus,
which expressions are OCL expressions. The seman-
tics of their
O µ(OCL)-calculus is defined over the
states of (Distefano et al., 2000). Using model check-
ing tools, the author intends to check the property on
a CCS term modelling their UML system.
All the previous works only specify the way OCL
must be extended to deal with temporal formulae in
order to verify or simulate them later but do not reach
this last step, at least not in an automatic manner. For
instance, the point of generating the transition system
from the initial UML is not solved.
Verification of DSL models. OCL was initially de-
fined on UML but was quickly defined for every meta-
model. It is the main tool to express structural prop-
erties in DSL. Existing OCL checkers are also model
independent.
5 CONCLUSION & FUTURE
WORKS
The context of this article was to integrate formal
methods for refining DSL semantics. DSL seman-
tics is usually restricted to structural properties and
dynamic aspects are often only informally described
or are even implicit. As our aim is to express and
validate behavioural and operational properties within
a metamodelling framework, the first step was to in-
troduce and handle an operational semantics, instan-
tiated in this article to our process metamodel SIM-
PLEPDL. This semantics is introduced with respect
to properties of interest, given by an expert of the do-
main. First, a notion of state is introduced, followed
by the definition of transitions and executions. Tem-
poral operators, forming temporal properties, are also
introduced. In order to check these properties, first a
denotational semantics is provided as a mapping from
SIMPLEPDL processes to Petri nets, second a front
end to the Tina model-checker is defined.
Few things still remain to be done. In particular,
the current presentation is focused on SIMPLEPDL,
it still needs to be abstracted away to get a more gen-
eral approach. The formal connection between the
observational operational semantics and the denota-
tional semantics induced by the ATL transformation
have to be validated.
Currently, we are implementing a prototype al-
lowing us to define metaproperties through an Ecore
modelling language extension given by the Eclipse
EMF plugin. The expression of temporal properties
uses an extension of OCL metamodel provided by the
EMFT plugin on which we add the set of temporal
operators described above, in the article. An interface
associated to the TOCL textual concrete syntax will
be integrated using generators such as Sintaks (Muller
et al., 2006) or TCS (Jouault et al., 2006). Our pro-
totype must also integrate the set of ATL transforma-
tions and provide a front end to Petri nets using the
Tina toolkit, through the SIMPLEPDL language. We
still have, in case of a negative answer from the model
checker, for a given property, to retrieve the gener-
ated counter-example. It can then be injected within
both the model animator currently developed with
the TOPCASED project and the SIMPLEPDL model
graphical editor defined with TOPCASED.
ICEIS 2007 - International Conference on Enterprise Information Systems
88

REFERENCES
(2003). UML Object Constraint Language (OCL) 2.0 Spec-
ification. Object Management Group, Inc. Final
Adopted Specification.
(2005). Software Process Engineering Metamodel (SPEM)
1.1 Specification. Object Management Group, Inc.
formal/05-01-06.
(2006). Meta Object Facility (MOF) 2.0 Core Specifica-
tion. Object Management Group, Inc. Final Adopted
Specification.
Agrawal, A., Karsai, G., Kalmar, Z., Neema, S., Shi, F.,
and Vizhanyo, A. (2005). The design of a language
for model transformations. Technical report, Institute
for Software Integrated Systems, Vanderbilt Univer-
sity, Nashville, TN 37235, USA.
Berthomieu, B., Ribet, P.-O., and Vernadat, F. (2004). The
tool TINA – construction of abstract state spaces for
Petri nets and time Petri nets. International Journal of
Production Research, 42(14):2741–2756.
Berthomieu, B. and Vernadat, F. (2006). R
´
eseaux de Petri
temporels : m
´
ethodes d’analyse et v
´
erification avec
TINA. Trait
´
e IC2.
Bradfield, J. C., Filipe, J. K., and Stevens, P. (2002). En-
riching OCL using observational mu-calculus. In Fun-
damental Approaches to Software Engineering, pages
203–217.
Cengarle, M. V. and Knapp, A. (2002). Towards OCL/RT.
In International Symposium of Formal Methods Eu-
rope on Formal Methods (FME) - Getting IT Right,
pages 390–409, London, UK. Springer-Verlag.
Chaki, S., E, M., Clarke, Ouaknine, J., Sharygina, N., and
Sinha, N. (2004). State/event-based software model
checking. In 4th International Conference on Inte-
grated Formal Methods (IFM), volume 2999 of LNCS,
pages 128–147.
Chen, K., Sztipanovits, J., Abdelwalhed, S., and Jackson, E.
(2005). Semantic anchoring with model transforma-
tions. In Model Driven Architecture - Foundations and
Applications, First European Conference (ECMDA-
FA), volume 3748 of LNCS, pages 115–129.
Clark, T., Evans, A., Sammut, P., and Willans, J. (2004).
Applied metamodelling - a foundation for language
driven development. version 0.1.
Combemale, B., Cr
´
egut, X., Berthomieu, B., and Verna-
dat, F. (2007). SimplePDL2Tina : Mise en oeuvre
d’une Validation de Mod
`
eles de Processus. In 3ieme
journ
´
ees sur l’Ing
´
enierie Dirig
´
ee par les Mod
`
eles
(IDM), Toulouse, France.
Combemale, B., Cr
´
egut, X., Ober, I., and Percebois,
C. (2006a). Evaluation du standard SPEM de
repr
´
esentation des processus. G
´
enie Logiciel, Mod
`
eles
et Processus de d
´
eveloppement, 77:25–30.
Combemale, B., Rougemaille, S., Cr
´
egut, X., Migeon, F.,
Pantel, M., Maurel, C., and Coulette, B. (2006b). To-
wards a rigorous metamodeling. In 2nd International
Workshop on Model-Driven Enterprise Information
Systems (MDEIS), Paphos, Cyprus. INSTICC.
Cousot, P. (1990). Methods and logics for proving pro-
grams. In Handbook of Theoretical Computer Sci-
ence, Volume B: Formal Models and Sematics (B),
pages 841–994.
Distefano, D., Katoen, J.-P., and Rensink, A. (2000). To-
wards model checking OCL. In ECOOP Workshop on
Dening a Precise Semantics for UML.
Flake, S. (2003). Temporal OCL extensions for specifica-
tion of real-time constraints. In Workshop Specifica-
tion and Validation of UML models for Real Time and
Embedded Systems (SVERTS) at UML’03, San Fran-
cisco, CA, USA.
Flake, S. and Mueller, W. (2003). Formal semantics of static
and temporal state-oriented OCL constraints. Journal
on Software and System Modeling (SoSyM), 2(3).
Gurevich, Y. (2001). The abstract state machine paradigm:
What is in and what is out. In Ershov Memorial Con-
ference.
Jouault, F. (2005). Loosely Coupled Traceability for ATL.
In Proceedings of the European Conference on Model
Driven Architecture (ECMDA) workshop on trace-
ability, Nuremberg, Germany.
Jouault, F., B
´
ezivin, J., and Kurtev, I. (2006). TCS: a DSL
for the Specification of Textual Concrete Syntaxes in
Model Engineering. In Proceedings of the fifth inter-
national conference on Generative programming and
Component Engineering (GPCE), Portland, Oregon.
Jouault, F. and Kurtev, I. (2005). Transforming models with
ATL. In Proceedings of the Model Transformations
in Practice Workshop at MoDELS, Montego Bay, Ja-
maica.
Muller, P.-A., Fleurey, F., Fondement, F., michel Hassen-
forder, Schneckenburger, R., G
´
erard, S., and J
´
ez
´
equel,
J.-M. (2006). Model-driven analysis and synthesis of
concrete syntax. In 9th International Conference on
Model Driven Engineering Languages and Systems
(MoDELS), volume 4199 of LNCS, Genova, Italy.
Richters, M. and Gogolla, M. (1999). A metamodel for
OCL. In France, R. and Rumpe, B., editors, UML’99
- The Unified Modeling Language. Beyond the Stan-
dard. Second International Conference, Fort Collins.,
volume 1723 of LNCS, pages 156–171, USA.
Richters, M. and Gogolla, M. (2000). Validating UML
models and OCL constraints. In UML 2000 - The
Unified Modeling Language. Advancing the Stan-
dard. Third International Conference, volume 1939 of
LNCS, pages 265–277, York, UK.
Warmer, J. and Kleppe, A. (2003). The Object Constraint
Language: Getting Your Models Ready for MDA.
Addison-Wesley Longman Publishing Co., Inc.
Ziemann, P. and Gogolla, M. (2002). An extension of OCL
with temporal logic. In Critical Systems Development
with UML – Proceedings of the UML’02 workshop,
volume TUM-I0208, pages 53–62.
TOWARDS A FORMAL VERIFICATION OF PROCESS MODEL'S PROPERTIES SIMPLEPDL AND TOCL CASE
STUDY
89