A Model Driven Engineering Approach for

Analyzing & Testing UML Activity Diagrams

A master project report submitted
to the School of Science and Engineering
of Al Akhawayn University in Ifrane
By
Abderrahmane Jaridi

In partial fulfillment of the requirements for the degree of

Master of Science in Computer Science
Supervised by
Dr. Bouchaib Falah

July 2015
Ifrane, Morocco

Abstract
The evolution of software systems is characterized by an increasing complexity. These
systems must respond correctly and particularly when facing critical situations. The
verification and validation of these systems is recognized as a difficult task and faces
many practical and theoretical burdens. A first obstacle arises at the specification and
design languages, although very expressive, but lack mathematical formalism, hence
automatic analysis becomes almost impossible. A second obstacle is the combinatorial
explosion of the possible States. Indeed, despite the spectacular advances in computer
technology, it happens that the full analysis of such systems is out of question, due to the
lack of space or time. The challenge is therefore to propose models that are sufficiently
expressive while remaining reasonably verifiable. Existing work have tried to reduce this
gap by proposing informal models mappings to formal models that support modelchecking, carried out in a transparent manner for the software engineer. This project
integrates into this theme and proposes a formal verification method of a dynamic
diagram of UML2.x: the activity diagram (AD) by transforming the latter to the formal
language: petri nets (PN) models that support formal verification, in accordance to the
OMG model driven architecture specifications.



. .
, .,
. . ,
, .
.
" ",
.
, , ,
.

Acknowledgements
Hello dear readers!
The crafting of this part of the manuscript marks the end of writing and the end of a long
and magnificent adventure during which I met many people who have given me much
and with whom I could share very good times. This is why I must pay tribute to them
across these lines.
First, I would like to thank my supervisor who guided me throughout the duration of this
project and who believed in me. Thanks to Dr. Fallah Bouchaib. You know that without
you, I would have never been able to finish this project. I am immensely grateful for
everything you have done for me, for everything you taught me, all your good advices, all
the good discussions and all the good times that you have allowed me to live. Thank you
from the bottom of my heart.
This project would have probably never started without the support of some people. Thus
I would like to thank the entire faculty who has taught me so far as well as all the
administrative team of the school of science and engineering.
Finally and most importantly, I thank my family without whom none of this would have
been possible. My parents, Moha and Aicha, whom have always supported me in my
projects and whom always believed in me. Thanks to you both, if I am here today is
because of you. I also thank my brothers and sisters, for their support and their attentions
during my studies. I also thank the rest of my family, my friends and colleagues.

Table of content
1.

2.

Introduction ............................................................................................................................. 9
1.1.

Background and motivation ............................................................................................ 9

1.2.

Objective ......................................................................................................................... 9

1.3.

Structure of the document ............................................................................................. 10

Background ........................................................................................................................... 11
2.1.

2.1.1.

The model concept ................................................................................................ 11

2.1.2.

The meta-model concept ....................................................................................... 13

2.1.3.

Why do we model? ................................................................................................ 17

2.1.4.

Modeling languages............................................................................................... 19

2.1.5.

MDE integration in software development life cycle ............................................ 23

2.1.6.

Tools to apply MDE .............................................................................................. 29

2.2.

3.

UML2 Activity Diagram ............................................................................................... 32

2.2.1.

Activity diagrams usage ........................................................................................ 32

2.2.2.

Composition of an activity diagram ...................................................................... 33

2.3.

Petri networks ................................................................................................................ 35

2.4.

Verification and Validation techniques ......................................................................... 35

2.4.1.

Validation by testing.............................................................................................. 36

2.4.2.

Model checking ..................................................................................................... 36

2.4.3.

Abstract interpretation ........................................................................................... 37

2.4.4.

Interactive proof .................................................................................................... 39

Activity2Petri: Concepts mapping ........................................................................................ 40

3.1.

The metaModels ............................................................................................................ 40

3.1.1.

Activity diagrams .................................................................................................. 40

3.1.2.

Petri Nets ............................................................................................................... 56

3.2.

4.

Model Driven Engineering ............................................................................................ 11

Concepts mapping ......................................................................................................... 59

3.2.1.

Overview ............................................................................................................... 59

3.2.2.

Activity diagram elements to petri net blocks ....................................................... 60

Activity2Petri: tool implementation ...................................................................................... 73

4.1.

Architectural overview .................................................................................................. 73

4.2.

4.2.1.

Transformation ...................................................................................................... 75

4.2.2.

Formal verification ................................................................................................ 77

4.3.
5.

Transformation: Activity2Petri ..................................................................................... 75

Application .................................................................................................................... 82

Conclusion and future work .................................................................................................. 89

References ..................................................................................................................................... 90
Appendix A: Unsound petri net of the vending machine case study ............................................. 96
Appendix B: Analyzing soundness formula ................................................................................ 101
Appendix C: Analyzing liveness formula ................................................................................... 102

Table of figures
Figure 2.1: OMG's Meta layers illustration . .................................................................... 15
Figure 2.2: programming language layered architecture .................................................. 16
Figure 2.3: the V model development life cycle ............................................................... 24
Figure 2.4: Verification activities and objectives of the DO-178C certification standard 38
Figure 3.1: Activity Diagram metamodel ......................................................................... 41
Figure 3.2: Activity Nodes in Activity Diagram metamodel ............................................ 42
Figure 3.3: Activity Edges in Activity Diagram metamodel ............................................ 43
Figure 3.4: Action Notation .............................................................................................. 43
Figure 3.5: Control and data flow into an action .............................................................. 44
Figure 3.6: Control and Data Flow out of an Action ........................................................ 45
Figure 3.7: Control Nodes................................................................................................. 45
Figure 3.8: Initial Node ..................................................................................................... 46
Figure 3.9: Decision Node ................................................................................................ 46
Figure 3.10: Merge Node with Alternate Flows ............................................................... 47
Figure 3.11: Fork Node ..................................................................................................... 47
Figure 3.12: Join Node...................................................................................................... 48
Figure 3.13: Flow Final Node ........................................................................................... 49
Figure 3.14: Activity Final Node ...................................................................................... 49
Figure 3.15: Activity edge ................................................................................................ 50
Figure 3.16: Object Nodes ................................................................................................ 50
Figure 3.17: Activity Parameter Nodes ............................................................................ 51
Figure 3.18: Input Pins ...................................................................................................... 52
Figure 3.19: Pins showing effect of actions on objects .................................................... 52
Figure 3.20: Token Competition ....................................................................................... 53
Figure 3.21: Central Buffer ............................................................................................... 53
Figure 3.22: Data Store Node .......................................................................................... 54
Figure 3.23: Partition Example, Swimlane Notation ........................................................ 55
Figure 3.24: Firing example .............................................................................................. 57
Figure 3.25: Petri Net metamodel ..................................................................................... 58
Figure 3.26: basic block definition. .................................................................................. 60
Figure 3.27: initial node mapping ..................................................................................... 62
Figure 3.28: final node mapping ....................................................................................... 62
Figure 3.29: flow final node mapping............................................................................... 63
Figure 3.30: Join node mapping........................................................................................ 64
Figure 3.31: fork node mapping........................................................................................ 64
Figure 3.32: decision node mapping ................................................................................. 65
Figure 3.33: Merge node mapping .................................................................................... 66
Figure 3.34: action node mapping. ................................................................................... 67
Figure 3.35: send signal mapping ..................................................................................... 67
7

Figure 3.36: Accept event mapping .................................................................................. 68

Figure 3.37: input pin mapping ......................................................................................... 69
Figure 3.38: output pin mapping ....................................................................................... 70
Figure 3.39: activity parameter node mapping ................................................................. 71
Figure 3.40: control flow arc mapping ............................................................................. 71
Figure 3.41: data control flow mapping ............................................................................ 72
Figure 4.1: Overall methodology ...................................................................................... 74
Figure 4.2: A complex activity diagram transformation result. ........................................ 77
Figure 4.3: basic temporal operators ................................................................................. 78
Figure 4.4: Model checking a system specification .......................................................... 81
Figure 4.5: vending machine unsound activity diagram ................................................... 83
Figure 4.6: Acitivity2Petri user interface.......................................................................... 85
Figure 4.7: unsound petri net obtained by transformation ................................................ 86
Figure 4.8: Control flow error trace on the activity diagram ............................................ 87

1. Introduction
1.1. Background and motivation
More and more industrials are interested in system engineering, which is defined as an
interdisciplinary scientific approach, whose purpose is to successfully formalize and to
understand the design of complex systems. A few years ago the complexity of the
systems has brought this new discipline that allowed better project management. Today
the complexity is such that sought to automate some phases of the product development
life cycle to significantly improve the time to market and thus reduce development costs.
The increasing functionalities supported by systems today justify the implementation of
verification and validation processes, as early as possible in the product development
cycle. The Validation and Verification (V&V) process is intended to ensure the earliest
possible that systems and products comply with the requirements and meet the expected
designs characteristics. This study aims to improve the V&V process by automating a
part of this cycle. This work is done under a model driven engineering (MDE)
framework, a recent branch of software engineering that has found its place in an industry
where hardware and software components reuse is commonplace (new car is 85% an old
car).
1.2. Objective
MDE allows reusing models of formalisms called meta-models, which are adaptable to
all platforms. Some organizations are interested in MDE and seek to standardize its
concepts: this is the case of the OMG (Object Management Group), the organization
behind the UML modeling language standard. This language is not formal, it is therefore
impossible to establish evidence on the correlation between the proposed solution and the
9

one that has been developed. This is why we are interested here in the transformation of
the UML and more particularly activity diagrams to a formal language, Petri networks.
In this light, we will try to establish the concepts needed for automatic transformation
from activity diagrams into Petri nets, in compliance with the specification defined by the
OMG, and formally verify the model generated by this transformation before using the
verification results to correct the UML activity diagrams and to make sure that the model
is correct in accordance with the initial requirements.
1.3. Structure of the document
This study will present in the second part the context and the tools, the languages used
and the approaches of model driven engineering and Meta-modeling. The third part will
deal with the development of the two meta-models: activity diagrams and Petri networks,
prior to establishing links at the model level between the main elements of the activity
diagrams and Petri nets. Part four will address all of the implementation of the
transformation of models following the concepts of the MDE before finishing with an
example case study, a vending machine system that will show the possibilities provided
by the solution proposed in this project.

10

2. Background
2.1. Model Driven Engineering
The abstraction from reality to be able to represent objects, concepts or problems is a
process that humans use naturally in everyday life. For example, if we ask someone to
represent an aircraft, he/she will draw more often a fuselage, wings etc. In fact, he/she
will describe his/her own abstraction of a plane, in other words its model. In engineering,
the models have always held an important place since ancient times. [10] noted that
Vitruvius, a Roman engineer of the first century BC discussed already the effectiveness
of models in his engineering manual. Today in computer science, the discipline mainly
associated with the modeling process is called model driven engineering (MDE). It
includes all the techniques of representing elements and concepts of reality in the form of
models. But it also includes the methods and tools for reasoning about these models.
2.1.1. The model concept
2.1.1.1. What is a model?
The model concept is central to MDE. Its definition varies according to the members of
the computer science community. Lets consider the definition in [11]: "A model is a
simplification of a system built with an intended goal in mind [...]. The model should be
able to answer questions in place of the actual system". This definition draws attention on
the purpose of the model and its ability to override the real system to be able to reason
about it. The definition given in [12], "A model is a representation in a certain medium of
something in the same or other medium. The model captures the important aspects of the
thing being modeled from a certain point of view and simplifies or omits the rest. ",

11

emphasizes the nature of the model and on the highlighting of aspects of the real system
and on simplification of the rest. In this project, we consider the following definition of a
model that unites the two previous ones: "a model is a partial representation of a real
system according a certain point of view. It allows abstracting this system to meet a given
problem".
Beyond this definition, a model is expressed using a modeling language. This language is
composed of syntax and semantics. The syntax corresponds to the representation of the
different concepts and elements of the language. These elements are visible and
exploitable by the user. In addition, the semantics is the meaning of each of these
elements or concepts. [12] Describes a model as directly consisting of semantics and
notation. Thus a modeling language is broken down to a concrete syntax, which is
manipulated by the user, and an abstract syntax, which is the syntax handled by the
machine and purified from user friendly syntactic add-ons. In addition, there is a
semantic domain that represents the set of reachable States of the system (i.e. all the
concepts expressible with this language) and the semantics of the language corresponds
to the relationship between the elements of the abstract syntax and the semantic domain.
The work of [13] describes a modeling language as syntax, semantic domain and the
semantic links between this syntax and this domain. In this work, we consider the basic
decomposition of a modeling language into syntax and semantics. This definition is
sufficient for the description of our work.
2.1.1.2. Contemplative models vs productive models
Although the modeling principles existed for many years in computer science, the first
approaches were mainly dedicated to human engineering activities, as for example the
12

Merise method [14]. These approaches are based mainly on contemplative models. A
contemplative model is a model readable and an exploitable by a human being.
The use of contemplative models has had a limited impact on software production [15].
The emergence of the MDE offers new ways to consider software development models,
the goal is no longer to see the code as the main element of production but it is the
abstraction by means of models while remaining productive [16]. It is more than a
contemplative model but a productive model. The definition of a productive model is
given by [15]: a productive model is a human-readable and machine exploitable model.
2.1.2. The meta-model concept
2.1.2.1. The meta-modeling logic
So that a model is interpretable and executable by a machine, its modeling language must
be formally defined. In an approach such as MDE, the definition of this language is itself
naturally done using a model. This model is called a meta-model. This concept is defined
in [18] as: "A model that defines the language for expressing a model". However it
should not be assumed that the meta-model represents the semantics of the language. [13]
Recalls that this is a common mistake and that a meta-model describes only the syntax of
the language.
If it is possible to see the meta-model as a model, then this model can have by itself a
meta-model. This meta-model of the meta-model is then named the meta-meta-model.
During the emergence of the concept of modeling with the "everything is model", it was
necessary to establish a theoretical basis for the Meta-modeling to federate the creation of
meta-models [16] and avoid the proliferation of incompatible meta-models.
13

In order to limit the levels of abstraction, the hierarchical structure of a modeling

historically revolves around an architecture of 4 levels. These 4 levels of abstraction are:

1st level (M0): the system: systems as they exist in the real world. It is
represented by the model defined at the M1 level.

2nd level (M1): the model: a representation of the system in a given modeling
language. It must comply with the meta-model defined in M2.

3rd level (M2): the meta-model: the definition of the modeling language. It shall
conform to the Meta-meta- model defined in M3.

4th level (M3): the meta-meta model: it defines the architecture of the metamodel. It has the property to define itself: it is the element with the highest level
of abstraction. Accordingly, it must be consistent with itself.

The most classic representation of this architecture is given in Figure 2.1.

This hierarchical approach is widely adopted in the MDE context. It can be represented in
different forms [19]. For example, [20] describes this architecture by adding linguistic
and ontological dimensions at each level. Another view of this approach is given in [16],
which describes this architecture as being in fact a 3 + 1 type architecture: it gives an
extra dimension to this architecture by bringing together the last three levels (M1 to M3)
to form a set named "the world of modeling" and the last level (M0) in the form of the set
named the real world. The common ground of these versions is the presence of a
hierarchical meta-modeling architecture.
This hierarchical structure is not unique to the MDE since it is used for a long time in
other computer science fields. For example, [19] explains that this type of hierarchy is
14

unique to any technical space. The authors define a technical space as "a set of tools and
techniques of pyramidal meta-models whose summit is occupied by a family of similar
meta-meta-models".

Figure 2.1: OMG's Meta layers illustration [17].

They then consider the technical space of models, structured as shown on Figure 2.1. And
then give as an example the technical space of grammars as shown Figure 2.2. In this
technical area, the source code is located at the M1 level and it is the equivalent to a
model in MDE. It is expressed by a programming language grammar at the M2 level, this
grammar being equivalent to a meta-model in MDE. The M3 level contains a grammar
description language, equivalent to a meta-meta-model in MDE.
2.1.2.2. The Model Driven Architecture (MDA), an MDE premise
Although this hierarchical structure is not unique to the MDE, the latter however was
marked by an approach based on this type of structures. In 2000, [21] explained that the
15

proliferation of middlewares in industry became problematic. It was difficult for a

company to rely on a single middleware platform. And even when a company was able to
rely on a single platform in-house, the need for interoperability with partner companies
most often required working with a different technology. In order to control and manage
this multiplicity of middleware platforms, and specifically the need for interoperability,
the Object Management Group (OMG) has proposed an approach applying modeling
techniques: the Model Driven Architecture [21] (MDA).
The objective of the MDA is to allow the creation of productive, permanent, stable and
platform independent software models. It is possible to take advantage of these models to
generate the code for a targeted platform, platforms that evolve continuously. The core of
the MDA approach is based on a set of standards created by the OMG.

Figure 2.2: programming language layered architecture

16

Thus, its four levels architecture is based on a meta-meta-model named Meta Object
Facility (MOF) [18], which is a standard for Meta-modeling. The MDA approach is also
based on the Unified Modeling Language (UML) [22], whose meta-model is based on the
MOF, in order to express platform independent software models such as design patterns
and platform dependent components of the software, that is to say of the source coderelated models. The final version of this approach was published in 2003 [23]. It is still
evolving and there are many success stories of its application in the industry [24].
2.1.3.

Why do we model?

From a user point of view, the need for models can occur for several reasons. We
distinguish three.
2.1.3.1. The mastery of complexity
The increase in systems complexity in recent years is a reality. For example, in the field
of Aeronautics, [25] explains that the control system of the Airbus A310 in 1980 was 4
MB of codes and relied on 77 calculators and 136 digital buses. In comparison with 1990,
the Airbus A340 control system was 20 MB of code and relied on 115 calculators and
368 digital buses. For the control system of the A380 in 2005 the code would be
hundreds of MBs [26]. Thus, we can observe an approximate 2500% increase of the size
of their avionics code over these last 30 years. In order to master this complexity, it is
necessary to abstract and represent the system in a form different and adapted to the
features which the user wants to embed on the system.

17

2.1.3.2. The need to formalize

The need to formalize is also a motivation for modeling. Natural language can be source
of ambiguities. How to interpret a phrase varies according to the person who reads it. In
the context of software development, [27] reported that specifications expressed in
natural language are often source of ambiguities and it is necessary to formally express
these requirements. In addition, in the context of current enterprise level projects, it is
essential to communicate in a formal and common language. The use of models in this
context is a way of formalization.
2.1.3.3. Model transformation
It is also possible to model with the aim of transforming. In the literature [28, 29], two
main types of transformation are characterized:

The model-to-model transformation. It will particularly be effective to map from one

formalism to another. For example this type of processing can be used as part of a
software migration from one platform to another. It also allows refining an abstract
model to a more specific model. For example it is possible to transform an abstract
model (e.g. UML class diagram) to a more detailed implementation model (e.g. java
source code). Note also the possibility of mapping from platform independent
models (PIM) to platform specific models (PSM) as proposed by the MDA approach
described earlier.

The model-to-text transformation. First, it allows code generation. The same model
will thus allow generating code in different languages following transformations. It
also allows tests generation from a model [30]. Finally, this type of transformation
allows the generation of documents. It is indeed necessary in certain software
18

development projects to provide documentation. For example in [31], documentation

is generated from a model by using the Eclipse based Model-To-Text tool GenDoc2,
in order to perform requirements traceability. In [32], the authors use this same tool
to generate documentation from models to meet a software development standard.
2.1.4.

Modeling languages

The popularity of the MDE approach resulted in the proliferation of modeling languages,
each offering means to adapt to specific needs or specific areas.
2.1.4.1. UML
The UML standard is a modeling language defined by the Object Management Group. It
is a standard widely used in the software industry. It is based on the MOF meta-metamodel discussed previously and it represents the modeling language which the MDA
approach depends on.
UML aims to represent the behavior, architecture, data structures and the structure itself
of an application. These different representations are based on different diagrams, each
offering to represent the system according to a particular point of view. UML offers
thirteen different diagrams divided into three categories. The first category includes
structural diagrams with the class diagram, object diagram, component diagram,
composite structure diagram, package diagram and the deployment diagram. The second
category concerns behavioral diagrams with the activity diagram, the state machine
diagram and use case diagram. The last category comprises interaction diagrams with the
sequence diagram, communication diagram, timing diagram, and collaboration diagram.

19

Of course, it is not required to use all these diagrams in software development but only
those necessary for the development of the application. The meta-model of each of these
types of models is described in [22], the semantics is described in natural language and a
constraints language called OCL [34] which itself is a standard defined by the OMG and
applied to the UML standard.
Another ability of UML is the possibility to formally extend the language through its
mechanism for extension by profile. Thus, the user is free to create his own extension of
the language that corresponds to his needs. For example, the UML MARTE profile is a
standard specified by the OMG for embedded real-time systems modeling [35]. It
specifies concepts to characterize UML elements to represent the concepts of time,
concurrency, platform hardware and software, resources and quantitative characteristics
of a system, such as the execution time. It is organized hierarchically in the form of
packages, each comprising a particular aspect of the development of embedded real-time
software. We distinguish mainly packages dedicated to the design of the system and
others dedicated to analysis and verification. The specifics for the design include
modeling the temporal mechanisms, resources, components and their means of
communication. Packages dedicated to analysis and verification to annotate models and
to conduct analyses of schedulability and performance. The profile also provides the
ability to specify non-functional properties of the system.
2.1.4.2. SysML
The SysML standard [36] is a modeling language defined by the OMG. It is a
standardized UML profile in the form of an extension of an UML subset. Given the
success of UML, SysML purposes to do more than confine itself to the computer world
20

but it proposes a usable modeling language to describe any system or software. The
SysML standard includes specification, analysis, design and testing activities of systems
and systems of systems development.
The language is based on some UML diagrams and also adds new ones. The block
diagram replaces the class diagram and thereby it no longer represents software classes,
but items such as hardware, software, or other elements of a system. A requirement
diagram is also added to make the link between the modeled elements and the
requirements. The parametric diagram will represent constraints on elements of the
system such as performance or reliability constraints. This type of diagram is going to be
particularly useful in the context of models analysis.
Based on UML, SysML also offers a profile extension mechanism. AVATAR is a
SysML Profile [37] and which is an example of specialization to the embedded domain,
offering solutions for modeling and formal verification of real-time embedded systems. It
can support upstream activities of a development lifecycle, based on a subset of the
SysML language and stereotypes applied to the diagrams elements. It includes solutions
for the collection of requirements, system analysis, modeling and the expression of safety
and security properties.
2.1.4.3. Simulink
Simulink [38] is the modeling language from the Simulink modeling environment
developed by the MathWorks Company. It is a graphical language to represent the
functional model of a system using blocks and signals. The blocks are connected by
signals and each block represents a particular signal processing. A library of blocks is

21

available in the environment and will provide blocks for dynamic, algorithmic or
structural data processing. The signals in the model will carry data or events.
The use of Simulink models is mainly dedicated to the modeling of discrete and
continuous systems such as communication and signal processing systems.
2.1.4.4. Other modeling languages
Many other modeling languages exist but it would be futile to give an exhaustive list. We
may, however, cite some other standards.
From an architectural point of view, the AADL language [39] is a standard defined by
SAE for modeling and analysis of systems architecture. It is mainly used for modeling
embedded systems.
For processes representation, the BPMN standard [40] is a modeling language for the
representation of business processes and it is defined by the OMG. Examples include
also, the SDL language which allows modeling of telecommunication systems. It is
defined as a standard by the ITU.
2.1.4.5. Domain Specific languages (DSL)
Although standards have been defined, it is sometimes necessary to define a language
dedicated to our own specific needs. We have seen that the UML standard had an
extension system to meet such a need. In MDE, it also possible for each user to define his
own modeling language. These domain-specific languages, or more simply DSL, are
generally smaller, simpler to understand and easier to handle than generic standards such
as UML. They are also more expressive because of their domain specialization. In
addition, the use of a meta-meta-model standard such as the MOF in the context of the
22

definition of these modeling languages will also allow the definition of transformations
between models from different DSLs and thereby multiply the usage scenarios of these
DSLs. The definition and use of these DSLs can then be seen as the most direct
application of the MDE approach.
There are languages and tools enabling the creation of DSLs. For example, the Ecore
Meta-modeling language is available through the Eclipse EMF tool [41] and which
allows the definition of DSLs. The tool then offers means to manage and manipulate
these Ecore-based DSLs.
2.1.5. MDE integration in software development life cycle
In the industry, the development of software is mainly based on three constraints: the
delivery deadline, the product cost and the product quality. The issue of development
therefore is to produce a usable and a good enough system respecting costs and time
constraints [43], bearing in mind that it would probably take an infinite time to build a
perfect system. Software engineering defines engineering good practices or "rules of
thumb" to produce software systems. In this context, it describes the various stages that a
development process must follow to produce software. There are different software
development processes. The different stages of development are similar but the number
of iterations on certain steps or the links between them are likely to vary. For example,
Figure 2.3 represents one of the classical software development processes: the V-model.
It is composed of the most representative phases of software development: requirements
specification, software design, software implementation and testing phases (unit,
integration and system testing phases).

23

Figure 2.3: the V model development life cycle [42].

We have seen in section 2.1.3 that the MDE offers a number of activities to meet current
needs in terms of software development. Each of its activities can be integrated in the
steps of a development process. In the following paragraphs, we give an overview of
opportunities for each stage of the process as well as a sample industrial case on the gains
in productivity and quality brought by the use of MDE during software development.
2.1.5.1. Design and specification phase
The specification and design phases allow the definition and considerations of the
requirements for the creation of the expected product. In this context, the need of
complexity control, communication or formalization of ideas can be satisfied through the
use of models. Furthermore, the use of models will also offer other opportunities for these
phases of the development process. As explained in [43], each phase of the development
process involves the creation of artifacts, or what we call deliverables. For example, in
aeronautics, the DO-178C standard requires for each phase of the process, a number of
documents to be provided to the authorities in the context of the software certification.

24

Thanks to model transformations, MDE will allow the automatic generation of some of
these deliverables such as for example the generation of documentation as described in
Section 2.1.3.
The possibility of working with formal models at the level of the specification and design
phases will also allow performing and automating another important task: V&V. This
activity is the most important phase, [10] explains that it is crucial to provide verification
and tests as early as possible in the development cycle such that fundamental decisions
regarding the software design can be made.
In the literature, many works exist on the verification of models. For example, if we take
only models based on the UML standard, [45, 46, 47] proposed approaches to verify
UML models with the help of properties expressed as OCL constraints. The approach
which is presented in [45] relies on the use of the UML2Alloy tool, which implements a
transformation of the specification in UML and OCL constraints to a specification in
Alloy [48], in order to carry out their verification using the solver Alloy Analyzer. The
Alloy language is a modeling language for software design, based on first-order logic. In
comparison, the method presented in [47] is based on the transformation of UML class
diagrams and OCL constraints into Constraint Satisfaction Problem (CSP). The CSP
problem can then be solved using a Solver. This work includes the implementation of a
prototype, named UMLtoCSP, automating the transformation and the link to the
ECLiPSe Solver [49]. Verification of UML models presented in [45] relies on the
transformation of a UML class diagrams and OCL constraints to a SAT problem. The
SAT problem is then solved using the MiniSat Solver.

25

Finally more recent work are more limited to verify a model specification or design
phases, but tend to generate models based on a set of input requirements. For example,
[51, 52] proposed approaches to generate optimal and complete models from partial
models and constraints. Similar to the previously described approaches, these works are
based on transformations techniques that map models to constraints satisfaction
problems.
2.1.5.2. Implementation phase
The use of models in the upstream phases will allow the use of code generation
approaches for the implementation phase. It will be possible, from a model to partially or
completely generate the desired source code. This code generation offers several
advantages. According to [43], this technique allows flexibility to the evolution of
modeling languages: If the modeling language is changed, we just update the
transformations of models to code. This technique also allows staying flexible given the
diversity of target systems and platforms: as seen in 2.1.3 the same model can be used to
generate code in different languages depending on the model transformation.
Existing code generators, include the GeneAuto generator [53] that can automatically
generate C code given a Simulink model. This tool is a European project based on a
collaboration of academic actors such as IRIT and INRIA and manufacturers such as
Airbus, Thales and Continental. We should also mention generators present in the
SCADE Suite tool that allow generating C or Ada code from a Scade model. The C code
generator is qualified: the generated code needs no longer to be tested (correct by
construction); the generator ensures that it matches the input pattern, which is formally
verified. More recently, the P34 research project aims the creation of an open-source
26

code generator for embedded real time systems. It is designed to take UML, SysML or
Simulink models as input and generate C/C++ or Ada code.
2.1.5.3. Testing phase
The testing phases goal is to verify that the system produced has the expected behavior.
As [43] explains, this behavior is more often described in a specification document and
the system under test is most often an implementation. In the context of an MDE
approach, the specification document is expressed by models, so it is then possible to
automatically generate tests from the specification's model.
[43] Also refers to the model-based testing technique that uses a specification model,
describing the expected behavior of the implementation of the system, to generate the
tests. These tests consist of test cases, each representing a possible execution among all
the paths described in the specification's model. Test generation is then used to generate a
set of test cases that meet a goal of coverage of the specification's model. [54] Explains
that these test cases are first generated in the form of "abstract" test cases from the model.
An 'abstract' test case is a test case which is not directly executable. For example, an
abstract test case could be expressed in a UML sequence diagram. From these abstract
test cases it is then possible to generate executable test cases on the implementation of the
target system. [54] Gives an example of this type of generation from UML diagrams to
implementations in Java.
2.1.5.4. Industrial use
Theoretically switching to an MDE approach as part of a development process is
expected to bring gains, both at the level of productivity and product quality. However, it

27

is justified to ask if the industrial use of this approach actually keeps its promises. [55]
Describes a study carried out on about 20 articles on the feedback from the use of the
MDE in industrial case studies between 2000 and 2007. Here we revisit some results of
this study.
[55] First exposes the productivity gains made by the MDE from the work done by
Motorola [56, 57] in the context of development of telecommunication system. The MDE
is applied from the specification phase down to the code and tests generation. For
example, in [56], the authors estimate that productivity has increased between 2 and 8
times for the production of lines of code compared to the classical approach of handcoding. In [57], the authors explain that for a testing phase, that includes a model
correction step, a step for creating test cases, a corrected code generation step and a step
of regression testing, the duration of this cycle, measured for four versions of different
networks functions, was reduced from about 25-75 days to 24 hours. In another example
[58], The Middleware Company has completed a comparative study on 2 teams
developing the same application, one using MDE through the MDA and the other not.
The studies showed that the team using MDE was able to develop the application 35%
faster than the other team.
Regarding the quality gain, [55] explained that few quantitative data exist in the
literature. However, it presents the article [56] where the authors could observe an error
reduction of 1, 2 to 4 times during their experiments with the use of the MDE. They also
noted that most errors are found much earlier in the development process, resulting in a
decrease in debugging costs.

28

The limited numbers of available experiences feedback, quantitative data or just results
on the implementation failures of MDE make the results of the study of [55] insignificant
and do not give a generalizable view of the approach but they nevertheless provide an
overview of the possibilities and the gains brought by the MDE.
2.1.6. Tools to apply MDE
In order to offer MDE activities support tools, platforms integrating these activities and
their automations have emerged. Here is an overview.
2.1.6.1. Eclipse Modeling Project
Eclipse Modeling Project [59] is an Eclipse project that aims to promote MDE activities
in Eclipse environment. Specifically, it includes a set of unified tools for DSL modeling
and the standards implementation for the Eclipse community.
This project is organized into several sub-projects, each supporting a specific activity of
the MDE. First of all, it offers tools for the development of DSL abstract syntaxes. The
goal is to allow editing, checking and querying models. These activities are supported by
the Eclipse EMF subproject. The Eclipse Modeling Project then provides tools for the
development of DSL concrete syntaxes. The tool allows the creation of a textual or
graphical concrete syntax, from an abstract syntax. The Eclipse GMP (an EMF
subproject) [60] allows the creation of graphical editors and the Eclipse TMF [61] (an
EMF subproject) allows the creation of text editors. The Eclipse Modeling Project also
offers a set of tools for model transformation through Eclipse MMT [62] and Eclipse
M2T [63] tools. Finally, a set of modeling standards, such as UML and BPMN, are
implemented in Eclipse MDT [64]. These implementations are compatible with Eclipse
technologies, allowing the use of different existing MDE tools on the platform.

29

The Eclipse tool use is widespread in industrial environment which allows the Eclipse
Modeling project to take advantage of a very large community.
2.1.6.2. TOPCASED
Topcased [65] (Toolkit in Open Source for Critical Applications & Systems
Development) is an open source software framework to support MDE activities for the
development of critical systems. It was initiated in 2004 by the CNRT-AE and was
supported by more than thirty academic and industrial partners including Airbus, Thales
and ONERA.
It comes in the form of an Eclipse Rich Client Platform (RCP) and thus has a modular
architecture that allows it to gather a great number of tools. It is based particularly on
technologies derived from the Eclipse Modeling Project. This architecture promotes also
custom features and tools creation and addition in the form of Eclipse plugins.
Furthermore, the Eclipse technology, which is based on the Java language, also provides
its wide portability. The main advantage of Topcased is to provide, in the same
environment and for the community of critical systems, tools for modeling, requirements
traceability,

models

simulation,

models

verification,

models

transformation,

implementation, code generation, reverse engineering, collaborative work and

documentation generation. It supports UML, SysML and AADL standards but also
allows the definition of DSL through the Ecore Eclipse technology language.
Topcased is a living and widely popular tool. It recently recorded an average rate of over
6000 downloads per month for the period from july 2014 to June 2015 [66].

30

2.1.6.3. SCADE Suite

SCADE Suite [67] is a commercial tool developed by Esterel Technologies. It is a model
based development environment for critical software. It is based on Scade graphical
modeling language which allows the representation of synchronous states machines and
data flow models. This language is itself based on an underlying language named
LUSTRE [68], which is a synchronous data flow programming language.
SCADE Suite offers model based activities throughout the software development
process. For example, during the design phase, it allows the user to model his system and
verify it, using simulations or verifications of dependability properties. During the
implementation phase, it offers the possibility of code generation from the model, in C or
Ada. This code is qualified following certification standards.
SCADE Suite is also linked to other SCADE products such as SCADE Display which
allows to quickly creating simple prototypes of control systems for the simulation and
verification the system and its interface. Scade Suite is widely used in the industry.
Among thses users: Airbus, EADS Astrium, Sagem, Eurocopter and the U. S. Army.
2.1.6.4. Other tools
Many other tools offer MDE activities support, from design to code generation,
unfortunately we cannot mention all of them. For example, the Simulink environment,
which we have described the in 2.1.4 allows the creation, simulation and C code
generation of signal processing and communication systems functional models. IBM has
also developed its own toolset for the support of the MDE approach. The Rational tools
such as Rhapsody [69] enables modeling and verification of models, and code generation
for software applications. They take into account the UML standard. Rational Software
31

Architecture (RSA) [70] allows the modeling of business processes. Finally another
example is the tool MagicDraw [71] which supports MDE activities, and which is also
based on the UML standard.
2.2.

UML2 Activity Diagram

UML allows representing graphically the dynamic aspects of systems using several
behavioral diagrams. Among these, there is the activity diagram that focuses on
processing. They are used to represent the behavior of a method or a use case processing
steps. [22]
An activity diagram is a variant of States-transitions diagrams, in which the States
correspond to the execution of actions or activities, and transitions are automatic (the
transitions are triggered by the end of activities and cause the immediate beginning of
another). An activity diagram can be attached to any modeling element in order to
visualize, specify, construct or document the behavior of this element [22].
UML activity diagrams are a tool for modeling systems workflows, service-oriented
models and business processes (they show the sequence of activities that contribute to the
process). An activity model consists of data and control flow related activities. An
activity can vary from a human task to a fully automated task.
The main difference between interaction diagrams and activity diagrams is that the first
tend to model control the flow between objects, while the latter are used to model the
control flow between activities.
2.2.1. Activity diagrams usage
Graphically represent the internal behavior of an operation, a class or a use case in
the form of a sequence of actions.

32

Use the synchronization mechanism to represent the sequence of synchronous

states, while States-transition diagrams are used mainly to represent asynchronous
states sequences.

Using automatic transitions avoids the necessity of transitional event existence to

have a change of states.

Modeling a workflow in a use case or between several use cases.

Define precisely the system operations (although some algorithms or

computations require a thorough description by the designer).

Specify an operation (describe the logic of an operation).

The activity diagram is the most appropriate to model the dynamics of a task or a
use case, when the class diagram is not yet stabilized. [106]

2.2.2. Composition of an activity diagram

The definitions given in this part are based mainly on the OMG specification [22].
The elements that can be contained in an activity diagram are:
1. nodes
a. activity nodes
b. object nodes
i. Input/output pin.
ii. Activity parameter node.
iii. Central buffer node.
iv. Expansion node.
c. control nodes
i. initial node

33

ii. Final node.

iii. Merge node.
iv. Decision node.
v. Fork node.
vi. Join node.
d. Executable node.
e. Activity score.
f. Interruptible activity region.
g. Expansion area.
h. Local pre-condition and post-condition.
i. Parameter set.
2. Edges
a. Control flow.
b. Object flow.
c. Exception handler.
UML 2.x activity diagrams are tools for modeling systems workflows, service-oriented
models and business processes. In section 3.1.1 we will further develop these concepts
when establishing our meta-model insisting on activity nodes and arcs, which will be
modeled in the transformation formalism that constitute the object of our work.
Activity diagrams have mechanisms to express sequencing, decision, and parallelism. But
they suffer the lack of behavior verification ability, which are available in a language like
petri nets.

34

2.3.

Petri networks

Petri networks (PN) or place/transition networks are a mathematical formalism. PNs have
a graphical representation and a (mathematical) matrix representation to help modeling in
many engineering fields. Appeared for the first time in the thesis of Carl Adam Petri in
1962, Petri nets have since declined in many classes:

Colored PN

Hierarchical PN

Stochastic PN

Predicate-Transition PN

Temporal PN

Object Oriented PN

Differential predicate-Transition PN

The goal is to apply the formalism of the PNs to different fields and more strictly to
discrete event systems. The possibility of managing complex systems with the PNs
doesnt need to be further proven, [107, 108]. A further study of PN will be presented
when extracting the meta-model.
2.4.

Verification and Validation techniques

Verification and validation techniques are means that allow you to verify, to a certain
extent, that the code meets a specification. The aim is to increase the confidence that we
have on the developed system, which translates in practice by different approaches.

35

2.4.1. Validation by testing

The dynamic testing consist on submitting a program to a set of inputs and run the
program to verify that it is acting on these entries as described in its specification [72].
The testing phase is normally done at the end of the development of the system or
subsystem, to make sure that this deliverable is correct. It adapts well to the descriptions
of systems validation because each component can be tested separately (unit testing), and
we can also test a collection of valid components (integration testing) [73, 74]. This fits
so well in modular validation logic, making it the most used technique in the industry for
programs validation. There are two types of testing: functional testing (or black box) and
the structural testing (or glass box). Functional testing validates a program by subjecting
it to inputs which verifies that the program meets its specification (e.g. GATeL tool [75]).
More testing of different input values, means greater confidence in the program. The
structural testing analyses program code, in order to establish suitable tests combinations
and cover a maximum of possible cases in a minimum of tests (e.g. Pathcrawler tool
[76]). But we can never test a system completely as explained in [77]: "Program Testing
can be used to prove the presence of bugs, but never their absence", that is, the tests can
find errors, but cannot verify that there are not. Today, systems safety standards require
more than just the testing trust criteria, for example the DO-178C certification, as shown
in figure 2.4, requires that the specification is verifiable.
2.4.2. Model checking
Model checking [78, 79] a system is a technique that is based on three concepts: a system
model, a system specification in the form of (temporal) properties and algorithms that
allow to verify that the model meets its specification. The model is given by a Kripke
36

structure [80] or in petri nets [81] which describes what are the possible States of the
system, its evolutions (transitions between States) and atomic properties that checks each
state. More complex properties are given in temporal logic [82, 83] that allows
expressing causality relationships between the states. Model checking explores the entire
system states, making it a formal verification technique: all possible executions of the
system are considered. In addition, aside from the modeling of the system and the
expression of its specification, model checking is a fully automatic technique making it
widely used in industry today [84, 85]. However, combining systems multiplies their
states. A phenomenon of combinatorial explosion appears on large systems of many
subsystems. Model checking of such systems may then suffer more time or space
complexity. In recent years, the main work in model checking try to reduce this problem
by offering for example symbolic methods [86] with more compact representations for
states and atomic propositions, e.g. Binary Decision Diagram [87]. Many tools used in
the industry implement this technology and its derivatives (e.g. VMS [88], TINA and
SPIN [89] [90]).
2.4.3. Abstract interpretation
Abstract interpretation [91, 92] is a theoretical framework that provides definitions and
criteria to simplify or abstract an object while ensuring that abstraction is correct to a
class of properties: a property of this class unmet by the abstraction is not satisfied by the
original object. It relies on theories of fixpoint and approximations which reduce
computations that could potentially be infinitely long. In computer science, this translates
into tools [93] which calculate in finite time a superset of the behavior of a program,
while an exact computation of the behavior problem is untractable. The verification of a
37

property from behavior abstraction of the program may give three verdicts: Yes the
property is verified, no it is not or maybe but the abstraction does not verify it. In the
latter case, one speaks of false alarm when the property is effectively verified by the
program but the abstraction is unable to do so because of the approximations. The
challenge of an abstract interpreter is to find the right balance between accuracy and
computation complexity on one hand, and approximation and computation speed on the
other. More or less complex approaches are developed looking for good compromises
[92, 94, 95].

Figure 2.4: Verification activities and objectives of the DO-178C certification standard [117].

Abstract interpretation is now used successfully in the industry with tools like Astre [96]
that are able to check thousands of critical embedded code lines, but focusing only on
certain types of properties.

38

2.4.4. Interactive proof

The interactive proof techniques gave birth to tools like coq [97, 98], HOL [99, 100] or
Isabelle [101] which use very expressive logics. In these tools, the user communicates
with the environment to build the proof of propositions he wants to verify. Several
studies were conducted in order to use the expressive power of the underlying logic for
proving programs [102, 103]. For this it annotates the source code of the programs by
inserting assertions, in a Hoare logic [104] fashion, a calculation of weakest precondition
[77] then establishes which proposition must be verified in order to prove programs
correctness. We call these propositions proof obligations. Interactive proof allows
proving a large class of properties on programs but requires an expert hand to annotate
and certify programs. The lack of automation is also a problem, even though some work
is put in place in order to combine interactive proof with other verification techniques
(example: Frama-C [105]).

39

3. Activity2Petri: Concepts mapping

3.1. The metaModels
3.1.1. Activity diagrams
Activity diagrams are one of the behavioral diagrams in UML as already mentioned.
They focus on the sequence, conditions, inputs and outputs for invoking other behaviors.
Activity Diagrams are primarily used to describe behavior of systems. They can be used
to model an operation associated with a use case or a class. Figures 3.1, 3.2 and 3.3 show
the meta-model of Activity Diagram [1]. Activities contain nodes connected by edges to
form a complete flow graph. Control and data values flow along the edges and are
operated on by the nodes, routed to other nodes, or stored temporarily.
There are three kinds of nodes in activity models:
1. Executable/Action nodes operate on control and data values that they receive,
and provide control and data to other actions.
2. Control nodes route control and data tokens through the graph.
3. Object nodes hold data tokens temporarily as they wait to move through the
Activity diagram.
Activity nodes are connected by two kinds of directed edges:
1. Control flow edges connect actions to indicate that the action at the target end
of the edge cannot start until the source action finishes. Only control tokens can
pass along control flow edges.

40

2. Object flow edges connect objects nodes to provide inputs to actions. Only
objects and data tokens can pass along object flow edges.

Figure 3.1: Activity Diagram metamodel [119]

41

Figure 3.2: Activity Nodes in Activity Diagram metamodel [1]

42

Figure 3.3: Activity Edges in Activity Diagram metamodel [1]

Important notations introduced in UML2 are:

3.1.1.1. Action Nodes
An action as shown in the meta-model in Figure 3.2 is the only executable node in UML
Activity Diagrams. It has been defined for invoking behaviors, either directly or through
an operation. Actions are directly contained only in activities. Actions are notated with
round-cornered rectangles. The names can be written inside the action.

Figure 3.4: Action Notation [2]

To begin executing, an action must know when to start and what its inputs are. These
conditions are called control and data, respectively. Figure 3.5 shows control and data
43

flow edges in UML2.0 directed towards an action. Data flow is distinguished from
control by small rectangles on the action to show the type of data flowing into the action.
These are called pins. An action may have sets of incoming and outgoing activity edges
that specify control flow and data flow from and to other nodes. An action will not begin
execution until all of its input conditions are satisfied. The completion of the execution of
an action may enable the execution of a set of successor nodes and actions that take their
inputs from the outputs of the action.

Figure 3.5: Control and data flow into an action [2]

An action that has control and data outputs is notated in the same way as inputs, except
the flow arrows point in the other direction. An action terminates based on conditions
internal to itself, but when the action does terminate, data is posted to its output pins, and
control values are placed on all its outgoing control flows. An action that has no control
or data outputs can still terminate, but its termination cannot cause other actions to start
[4].

44

Figure 3.6: Control and Data Flow out of an Action [2]

3.1.1.2. Control Nodes

There are seven kinds of control node, with five notations, as shown in Figure 2.17.
Contrary to the name, control nodes route both control and data/object flow.

Figure 3.7: Control Nodes [5]

Each of these items is described briefly below.

3.1.1.2.1.

Initial Node

Initial nodes are used to show the start of an activity. They receive control when an
activity is started and pass it immediately along their outgoing edges. No other behavior
is associated with initial nodes in UML. Initial nodes cannot have edges coming into
them. An activity can contain more than one initial node. If an initial node has more than
one outgoing edge, only one of the edges will receive control, because initial nodes
cannot copy tokens [1].

45

Figure 3.8: Initial Node [5]

3.1.1.2.2.

Decision Node

Decision nodes guide flow in one direction or another, but exactly which direction is
determined by the constraints over the edges coming out of the node. Usually edges from
decision nodes have guards, which are Boolean value specifications evaluated at runtime
to determine if control and data can pass along the edge [4]. The guards are evaluated for
each individual control and data token arriving at the decision node to determine exactly
one edge the token will traverse. Decision node has one incoming edge and multiple
outgoing edges.

Figure 3.9: Decision Node [5]

3.1.1.2.3.

Merge Node

Merge nodes are used to bring together multiple flows. All control and data arriving at a
merge node are immediately passed to the edge coming out of the merge. Merge nodes

46

have the same notation as decision nodes, but merges have multiple edges coming in and
one going out.

Figure 3.10: Merge Node with Alternate Flows [5]

3.1.1.2.4.

Fork Node

Fork node is used to split a flow into multiple concurrent flows. Data and control tokens
arriving at a fork are duplicated and sent to the outgoing edges. There is no other
behavior associated with fork nodes. In UML 2.x it is not necessary to synchronize the
behavior on concurrent flows which was required in UML 1.x activities [4]. A fork node
has one incoming edge and multiple outgoing edges.

Figure 3.11: Fork Node [5]

3.1.1.2.5.

Join Node

Join node is used to synchronize multiple flows. Control or data must be available on
every incoming edge so that it can be passed to the outgoing edge. Join nodes have the
same notation as fork nodes, but joins have multiple edges coming in and one going out.

47

Flows coming into a join are usually concurrent flows from an upstream fork. Join nodes
take one token from each of the incoming edges and combine them according to these
rules:
1. If all the incoming tokens are control, then these are combined into a single
control token for the outgoing edge [5].
2. If some of the incoming tokens are control and others are data, then these are
combined to provide only the data tokens to the outgoing edge. The control
tokens are destroyed [5].

Figure 3.12: Join Node [5]

3.1.1.2.6.

Final Node

Flow in an activity ends at final nodes. There are two kinds of final nodes in UML2.0
activity diagrams
a) Flow Final: Each flow can have its own flow final. Final nodes cannot have
outgoing edges so there is no downstream effect of tokens going into a node,
which are simply destroyed. Activities terminate when all tokens in the graph
are destroyed, so the activity shown in Figure 3.13 will terminate when both
flows reach the flow final.

48

Figure 3.13: Flow Final Node taken from [5]

b) Activity Final: nodes are like flow final nodes, except that control or data
arriving at them immediately terminates the entire activity. This makes a
difference if more than one control or data token might be flowing in the
graph at the time the activity final is reached.

Figure 3.14: Activity Final Node [5]

N.B: There may be several final nodes in an activity.

3.1.1.3. Activity Edges
There are two kinds of activity edges in UML2.0:
a) Control Flow Edge: A control flow is an activity edge that only passes control tokens.
Tokens offered by the source node are all offered to the target node.
b) Object Flow Edge: An object flow is an activity edge that can have objects or data
passing along it.
49

An activity edge is notated by a stick-arrowhead line connecting two activity nodes. If the
edge has a name it is notated near the arrow [1].

Figure 3.15: Activity edge [5]

3.1.1.4. Object Nodes

There are four kinds of object node in UML2.0 activity diagrams, as shown in Figure
3.16. All object nodes specify the type of value they can hold and if no type is specified,
they can hold values of any type. Object nodes can hold more than one value at a time,
and some of these values can be the same. Each object node specifies the maximum
number of tokens it can hold, including any duplicate values, which is called the upper
bound.

Figure 3.16: Object Nodes [3]

50

3.1.1.4.1.

Activity Parameter Node

Activity parameters are for accepting inputs to an activity and providing outputs from it.
Activity parameter nodes must have either no incoming edges or no outgoing edges.
When an activity in invoked, the inputs values are placed as tokens on the input activity
parameter nodes. When the activity has finished the outputs of the activity must flow to
output activity parameter nodes.

Figure 3.17: Activity Parameter Nodes [3]

3.1.1.4.2.

Pins

Pins provide values to actions and accept result values from them and are connected as
inputs and outputs to actions. An example of input pins is shown in Figure 3.18, in two of
the notational forms. Whichever input value reaches a pin first is held there until the other
arrives. When both pins have a value, the values are passed into the action and it starts.

51

Figure 3.18: Input Pins [3]

A special kind of input pin called a value pin is defined for providing constant values
such as numbers, or values.
Pins can be notated with the effect that their actions have on objects that move through
the pin. Effect is one of the four values CREATE, READ, UPDATE, or DELETE.

Figure 3.19: Pins showing effect of actions on objects [3]

A parameter node or pin may have multiple edges coming out of it, whereupon there will
be competition for its tokens, because object nodes cannot duplicate tokens like forks.
For example, Figure 3.20 shows parts being made, then painted at one of two stations, but
not both.

52

Figure 3.20: Token Competition [3]

3.1.1.4.3.

Central Buffer

Central buffers are for situations where tokens under competition arrive from multiple
sources [2]. For example, Figure 3.21 shows parts arriving at a central buffer from two
factories, which are then painted at two other factories. Pins cannot be used as central
buffers, because pins have flows coming or going out, but not both.

Figure 3.21: Central Buffer [3]

3.1.1.4.4.

Data Store

A data store node is for non-transient information. UML2.0 data store nodes are an
attempt to support the earlier form of data flow and storage by providing a non-depleting
specialization of object node. Tokens flowing out of data store nodes are copies of tokens
that remain in the data store node. Tokens in a data store node cannot be removed, though

53

values do not remain in the store after the containing activity is terminated, and a token
arriving at a store that already has another token for the same object replaces that token.

Figure 3.22: Data Store Node [3]

3.1.1.4.5.

Partitions

Partitions are used to indicate what or who is responsible for actions grouped by the
partition. The term responsible has a wide variety of a meaning, but the one defined by
UML is that software class/component supports the behavior invoked by actions in the
partition. Partitions often correspond to organizational units in a business model. An
activity diagram may be divided visually into Partitions each separated from neighboring
Partitions by vertical solid lines on both sides. Partitions do not have execution
semantics. Partitions do not affect the token flow of the model. In UML2.0 the partitions
can be hierarchical.
3.1.1.5. Usage of Activity Diagrams
Like any other diagrams in UML, activity diagrams have also strengths and weaknesses.
The strength of activity diagrams lies on their ability to support parallel behavior, but
their great disadvantage is that they do not make clear the links between actions and

54

components, which are visualized better using interaction diagrams or state diagrams.
However they are suitable mostly when we deal with the following situations:

Figure 3.23: Partition Example, Swimlane Notation [6]

3.1.1.5.1.

Modeling an operation

Activity diagrams can be used to model an operation associated with a use case or a class.
In this case we are only interested in understanding what actions need to take place and
what the behavioral dependencies are. Using an activity diagram to model an operation is
simply like using it as a flowchart that supports concurrencies among threads in an
operation.
3.1.1.5.2.

Modeling a workflow

Activity diagrams are best suited to model workflows across use cases that involve many
actors or business organizations. In this case we focus on activities as seen by the actors
that collaborate with the system.

55

3.1.2. Petri Nets

3.1.2.1. Definitions
Petri net is a graphical and mathematical modeling and analysis language which consists
of places, transitions, and arcs. They were introduced by Carl Adam Petri in 1962 at the
Technische University Darmstadt, Germany.
Transitions are active components. They model activities which can occur, thus changing
the state of the system. Transitions are only allowed to fire if they are enabled, which
means that all the preconditions for the activity have been fulfilled.
Places are place holders for tokens. The current state of the system being modeled is
called marking which is given by the number and type (if the tokens are distinguishable
by type) of tokens in each place [7].
Arcs are of two types: input and output. Input arcs start from a places and ends at a
transitions, while output arcs start at a transition and end at a place.
When the transition fires, it removes tokens from its input places and adds some at all of
its output places. The number of tokens removed / added depends on the cardinality of
each arc. The interactive firing of transitions in subsequent markings is called token
game. Figure 3.24 shows firing of an enabled transition. Transition t removes two token
from place H2 and one token from place O2 and generate two H2O tokens,
2H2 + O2 2H2O

56

Figure 3.24: Firing example [7].

Petri nets are a formal language for describing and studying systems that are
characterized as concurrent, asynchronous, distributed, parallel, nondeterministic, and/or
stochastic. As a graphical tool, Petri nets can be used as a visual communication aid
similar to flow charts, block diagrams, etc. In addition, tokens are used in these nets to
simulate the dynamic and concurrent activities of systems. The use of Petri Nets leads to
a mathematical description of the system structure that can then be investigated
analytically. It is possible to set up state equations, algebraic equations, and other
mathematical models governing the behavior of systems. Timed Petri nets can be used for
studying the performance and dependability issues of systems. Petri nets can be used for
analyzing properties like reachability, boundedness, liveness, persistence, fairness etc [8].
3.1.2.2. Petri Nets metamodel
A simple Petri net is a set of places and transitions interconnected by directed arcs (an arc
goes from a place to a transition or from a transition to a place). These concepts like Petri
Net, Place, Transition and Arc have been used to define a Petri Net metamodel.

57

A Petri Net is composed of Transitions, Places, input and output arcs. Places can be
interface places or internal places of a Petri Net. The interface places are for Starting and
Ending a Petri Net. If a Transition represents a complex operation and needs to be
represented with more details, it can be represented as a Petri Net.

Figure 3.25: Petri Net metamodel [118]

58

3.2. Concepts mapping

3.2.1. Overview
Validation of requirements specifications is undoubtedly an integral part of requirements
engineering. Validation and verification is the process of checking whether the
requirements specifications meet the intentions and expectations of the stakeholders.
There are different approaches for validation of the requirements. One of the approaches
is based on simulation/execution of system models that are derived from initial
requirements specifications. As already mentioned in Chapter 2, Petri Nets is a formal
language which can be used for verification of requirements by simulating/executing the
system models.
Several approaches have been suggested in the literature to transform and analyze UML
Activity Diagrams. A transformation from Activity diagram to CSP (Communicating
Sequential Processes was proposed in [120], in order to formalize the execution
semantics of the diagram. [121] suggests using -calculus to analyze UML AD. The
common issue of these approaches is that they do not necessarily respect the OMG
specification for Activity diagram semantics. Another problem found in the said
approaches is that they lack the visual aspects of the Petri Nets. That is why we have
adopted the latter in our project. Furthermore, Activity diagram execution semantics in
UML2.0 specification have been adopted from Petri Nets (the token-game) [122], which
make PNs the most suitable formalism to describe ADs semantics in a formal way.
As UML2 Activity Diagrams lack a universally agreed semantics, the transition from
specification to implementation usually faces a semantical impedance caused by different
interpretation of the same diagram. A well-defined formal semantics for the specification
59

language determines the interpretation of a diagram and allows for reasoning about as
well as validating and verifying a given specification on common (formal) grounds.
We adapt approaches for formalizing semantics of UML2 Activity Diagrams for purpose
of formal verification. We provide a parameterized Petri net pattern for each language
concepts. A diagram is translated by instantiating a pattern for each use of a concept,
merging the resulting Petri net fragments according to the structure of the original
diagram yields a Petri net that specifies the behavioral semantics of the diagram.
3.2.2. Activity diagram elements to petri net blocks
3.2.2.1. Concepts mapping
This contribution seeks to automate the activity diagrams to Petri networks
transformation. It is essential to have a vision at the model level of the expected results,
in order to preserve the properties and behavior of activity diagrams, in the equivalent
PN. It is a transition from a semi-formal language to a standardized formal language.
3.2.2.2. Establishment of complex networks
The adopted approach for this work was to develop basic blocks before interconnecting
them. This solution has the advantage of being generic. All PN blocks are created
according to the same scheme (Place-Transition-place), see figure 3.26.

Figure 3.26: basic block definition.

60

Only ControlFlow and ObjectFlow artifacts use an Arc-Place-Arc diagram to connect the
blocks between them. This solution is simpler because it yields a reasonably simple Petri
networks that comply with the semantics of the ADs.
3.2.2.3. Activity diagram artifacts to Petri nets blocks
This paragraph will establish the concepts of transformation between the Atomic entities
of activity diagrams (nodes/arcs) and equivalent PN blocks. These blocks should respect
the (semantic) behavior of UML2 activity diagram advocated by the OMG [22].
At first glance, a Petri net may seem close to an activity diagram. Their graphic
representations and behavior (flow of tokens in the 'network', composition of graphs:
node, arc) can give an impression of having two very similar modeling techniques. The
following paragraphs show the non-apparent complexity of the semantics of the activity
diagrams and the transformation patterns.
3.2.2.3.1.

Initial node (figure 3.27)

OMG specification: An initial node is a control node that is activated when the activity
is invoked.
OMG specification property:
-Tokens in an initial node are available to all outgoing arcs.
-If an activity has multiple initial nodes, each of them is activating their respective
control flows (implicit fork).
Solution:

61

- Create a marked place.

Figure 3.27: initial node mapping

3.2.2.3.2.

Activity Final node (figure 3.28):

OMG specification: An activity final node is an end node that stops all flows in an
activity.
OMG specification property:
-It stops all executing procedures in the activity, and destroys all tokens in the
running nodes, except in "parameter" exit nodes of the activity.
Solution:
- Create an unmarked place.

Figure 3.28: final node mapping

3.2.2.3.3.

Flow Final node (figure 3.29):

OMG specification: A flow final node is an end node that terminates a flow.

62

OMG specification property: The flow final node destroys tokens that reach the node.
Solution:
-A transition for each arc entering the FlowFinalNode.

Figure 3.29: flow final node mapping

3.2.2.3.4.

Join node (figure 3.30)

OMG specification: A join node is a control node that synchronizes multiple streams.
OMG specification property:
-If all available input tokens are control tokens, then a control token is provided as
output.
-If some of these input tokens are control tokens and others are data tokens, only
data tokens are provided as output. Tokens are available in the same order they
arrived.
Solution:
-Creation of a transition that has the same synchronization properties in the PN.
-The arrival management (buffers) will be not modeled by the generated PN.

63

Figure 3.30: Join node mapping

3.2.2.3.5.

Fork node (figure 3.31)

OMG specification: A fork node is a control node that separates a flow into multiple
simultaneous flows.
OMG specification property: Incoming tokens are available to all outgoing arcs of the
node.
Solution:
-Creation of a transition that allows redistributing as many tokens as outgoing arcs
synchronously.

Figure 3.31: fork node mapping

3.2.2.3.6.

Decision node (figure 3.32)

OMG specification: A decision node is a control node that chooses between outgoing
flows.
OMG specification property:
64

-Each token arrived at a decision node can be redistributed to a single output.

Solution:
- A place marked with one token.

Figure 3.32: decision node mapping

3.2.2.3.7.

Merge node (figure 3.33)

OMG specification: A merge node is a control node that brings together streams/flows.
It is not used to synchronize concurrent flows, but to accept one among several.
OMG specification property:
-All incoming tokens are distributed in the output. There is no flow
synchronization or aggregations of tokens.
Solution:
- A place that directly receives a single token from incoming flows.

65

Figure 3.33: Merge node mapping

3.2.2.3.8.

Action node (figure 3.34)

OMG specification: An action represents a single step in an activity. An action is a

named item that is the basic unit of the executable function. The execution of an action
represents a computing or a processing in the modeled system, be it a computer or other
system.

OMG specification property:

-the execution of an action is fired when all the conditions on the objects flow and
control flow have been met (implicit join).
-At the end of the action all outgoing arcs receive a token (implicit fork).
-If multiple control tokens are available on a single incoming ControlFlow, they
are all consumed.
Solution:
- Creation of an input place and an output place for the management of the
implicit JoinNode and ForkNode.

66

- The last property is moved with the ControlFlow so that it does not store the
tokens but to work as information routing buffers: presence or not of a token.

Figure 3.34: action node mapping.

3.2.2.3.9.

Send signal node (figure 3.35)

OMG specification: SendSignalAction is an action that creates a signal when all its
inputs are active and send it to the target object.
OMG specification property: Identical to an action, it inherits directly from Action
Solution:
-A place of asynchronous communication is added (here p0).

Figure 3.35: send signal mapping

3.2.2.3.10.

Accept event action node (figure 3.36)

OMG specification: AcceptEventAction is an action that awaits the arrival of a signal.

OMG specification property:

67

-Identical to an action, it inherits directly from Action

-If information is received but unread, the arrival of information will come to
override the first, (limitation of the specification of the OMG.)
-Important: An AcceptEvent node communicates through a Port and a Trigger
with the SendSignalAction node. Need to ensure their presence in order to
establish the link between these two nodes.
Solution:
-same as Action
-creation of an action input buffer connected to the communication SendSignal
place.

Figure 3.36: Accept event mapping

3.2.2.3.11.

Input pin (figure 3.37)

OMG specification: An input pin is a pin that holds the input values to be consumed by
an action.
OMG specification property:

68

-An action cannot begin execution if an input pin has fewer values than the lower
multiplicity.
-The upper multiplicity determines the maximum number of values that can be
consumed by a single execution of the action.
Solution:
-Creation of a buffer that allows the management of the update of the data. The
presence of a single data is taken into account.

Figure 3.37: input pin mapping

3.2.2.3.12.

Output pin node (figure 3.38)

OMG specification: An output pin is a pin that holds the output values produced by an
action.
OMG specification property:
-For each execution, an action cannot complete when there are at least as many
values on its output pins required by the lower multiplicity of these pins.
-The values are actually issued once the action is complete.
-An action cannot put more values in an output pin during a single execution than
the upper multiplicity of the pin.

69

Solution:
-The solutions are equivalent to that implemented for input pins.

Figure 3.38: output pin mapping

3.2.2.3.13.

Activity Parameter node (figure 3.39)

OMG specification: ActivityParameterNode are object nodes flow start and flow end
that provide the inputs and outputs to an activity through the parameters of an activity.
OMG specification property:
-In the course of the execution of the activity, tokens can flow into the activity in
the activity parameter nodes.
-When the activity execution is complete, the output values held by these return
ActivityParemeterNode shall be issued.
Solution:
-Creation of a communication place between the InputPin and the Activity of
lower level, all properties being redundant with pin nodes, they are carried over to
the corresponding Pin.

70

Figure 3.39: activity parameter node mapping

3.2.2.3.14.

Control Flow arc (figure 3.40)

OMG specification: A control flow arc is an arc that starts an activity node after the
previous one is completed.
OMG specification property:
- Control flow is an arc that routes control tokens.
- The tokens offered by the source node are all available to the target node. Any
number of tokens can pass the arc, in groups, or individually.
Solution:
-A simple PN arc seems sufficient, but some properties were deported on the arc
during our transformation (in an activity diagram an action consumes all present
tokens on the arc). We therefore model the ControlFlow by a place to avoid
storage of tokens and keep only the information of presence of tokens.

Figure 3.40: control flow arc mapping

71

3.2.2.3.15.

Data Control arc (figure 3.41)

OMG specification: An object flow is an arc that circulates data.

OMG specification property: Same as ControlFlow
Solution:
-An ObjectFlow is always preceded and followed by an input or output Pin, the
solution adopted is therefore not the same as for the ControlFlow. A single arc
would have prevented a generic construction. The ARC-PLACE-ARC solution
allows connecting the Pin between them.

Figure 3.41: data control flow mapping

The list of mappings defined here allows building relatively complex activity diagrams.
However the formalism of activity diagrams is rich, a total transformation of the UML2
activity diagrams to Petri networks would require substantial work without however to be
a major technical problem. This mapping has been carried out and validated by
verification through the LoLa model checker [9].

72

4. Activity2Petri: tool implementation

This chapter discusses all the work carried out after the Meta-modeling stage,
transformations and verification with LoLa model checker [110]. It also illustrates the
possibilities offered by these works through an example illustrating the whole process
with an application to a vending machine activity diagram.
4.1. Architectural overview
In this section, we describe our methodology for verifying UML2 requirements on
activity diagrams. First, the UML designer creates activity diagrams to specify the
system. Then, drives from functional requirements, which are related to the activity
diagram by a Verify relationship, temporal requirements described as properties about
activity diagram elements. After that, an automatic translation process is used to
transform this UML specification into a formal specification, (Petri Nets). The UML
activity diagram is transformed into Petri net and formal properties described as
Computational tree logic formulas (CTL) [115]. A Model checker (LoLa) will be used to
check if these requirements are verified in the derived Petri net model. Finally, a
feedback is given to the UML designer to correct his specification. As our approach is
automated, in the case of the non-satisfaction of a requirement, the generated feedback
can give a more accurate indication about the sub activity and the actions which are
related to the design error. The Figure 4.1 summarizes the steps of our methodology.

73

Figure 4.1: Overall methodology

74

4.2. Transformation: Activity2Petri

This part is about all the implementation work for this study: the transformations and
formal verification of the generated PNs through the LoLa "model-checker".
4.2.1. Transformation
Following the creation of the MDA of the OMG standard, many tools based on this
approach have emerged. In order to limit the file formats of the UML files the OMG
defined the XML Metadata Interchange (XMI) [111] that is used as an interchange
format for UML models, although it can also be used for serialization of models of other
languages (meta-models). This specification dictates that the models and diagrams (visual
aspects) should be defined in different files (.uml and .umldi files respectively in
topcased).
4.2.1.1. Establishing transformation rules

Our program is composed of rules that specify how the elements of the target model must
be created on the basis of the elements present in the source model. These rules are
always established according to the uml structure:
4.2.1.2. Transformation implementation

The transformation of the activity diagram is done through an xml parser (JDOM) and
java language. This transformation is done in two steps: first an auxiliary activity graph is
created which will hold the representation of the diagram elements in objects stored in the
main memory. This graph-diagram will serve as a traceability model for the generation of
the error trace in the initial input diagram. And it will also simplify the generation of the

75

LoLa petri-net files by storing the connections between the different nodes of the
diagram.
The files representing an input model for the LoLa model-checker have the following
EBNF grammar:
net ::= PLACE place_lists MARKING marking_list? ; transition+
place_lists ::= ( capacity? place_list ; )+
capacity ::= SAFE NUMBER? :
place_list ::= nodeident ( , nodeident )*
nodeident ::= IDENTIFIER | NUMBER
marking_list ::= marking ( , marking )*
marking ::= nodeident ( : NUMBER )?
transition ::= TRANSITION nodeident fairness?
CONSUME arc_list? ; PRODUCE arc_list? ;
fairness ::= ( STRONG | WEAK ) FAIR
arc_list ::= arc ( , arc )*
arc ::= nodeident ( : NUMBER )?

An example of the petri-net LoLa file of the vending-machine case is given in appendix
A to illustrate a file produced by this grammar.
Validation of a transformation composed of few PN nodes is trivial; however the
complexity of the systems to model today brings large PNs (hundreds of
places/arcs/transitions). You can see the result of the transformation of a complex activity
diagram (tens of activity diagram elements) figure 4.2. Thats why the automated
generation of networks and formal verification is essential.

76

Figure 4.2: A complex activity diagram transformation result.

4.2.2. Formal verification

There are several methods of analysis:

Simulation.
Tests.
Formal verification.

This section will focus on formal verification based on formal models. Formal
verification is the exploration of all the states of the system to derive properties of
reachability, liveness and safety.
We have chosen to use the model-checking approach, which is suitable for the
verification of PNs [114]. To conduct a formal verification by model-checking, we must:
o Develop a model that describes the behavior of the system, here, its the
resulting PN model from the transformation.
o Express system properties in a formalism as the temporal logic, here CTL.

Model Checking involves a strong limitation, behavioral models must be finite. In

practice it is often possible to easily obtain a finite PN. Our PN model is then
77

ready for formal verification and we have seen previously that other
transformations are necessary. One of them is used to automate the generation of
the CTL properties (AD2CTL).
4.2.2.1. Temporal logic and CTL language
Temporal logics are languages used to describe properties, so it's a description language.
The properties described in temporal logic are verified on a model. The time is not
expressed explicitly, but sought to see if a property will always be checked or will never.
Basic properties are: next, until, eventually and always. From these basic properties one
seeks to establish general properties, figure 4.3 summarizes the set of basic temporal
operators.

Figure 4.3: basic temporal operators [115]

78

The EBNF grammar of the CTL specification in LoLa is the following:

formula ::= FORMULA? statepredicate ;?
statepredicate ::= ( statepredicate )
| atomic_proposition
| NOT statepredicate
| statepredicate boolean_operator statepredicate
| path_quantifier statepredicate
| unary_temporal_operator statepredicate
| ( statepredicate binary_temporal_operator statepredicate )
boolean_operator ::= AND | OR | XOR | -> | <->
unary_temporal_operator ::= ALWAYS | EVENTUALLY | NEXTSTATE
| REACHABLE | INVARIANT | IMPOSSIBLE
binary_temporal_operator ::= UNTIL | RELEASE
path_quantifier ::= ALLPATH | EXPATH
atomic_proposition ::= term term_comparison_operator term
| TRUE
| FALSE
| FIREABLE ( IDENTIFIER )
| INITIAL
| DEADLOCK
term_comparison_operator ::= = | != | > | >= | < | <=
term ::= ( term )
| IDENTIFIER
| NUMBER
| term + term
| term - term
| NUMBER * term
| oo
An important way to model check is to express desired properties (such as the ones
described above) using CTL Formulas and actually check if the model satisfies this

79

property. One technique is to obtain a Bchi automaton that is "equivalent" to the model
and one that is "equivalent" to the negation of the property. The intersection of the two
non-deterministic Bchi automata is empty if the model satisfies the property.
4.2.2.2. State Space Verification with LoLA
LoLA [4] is a tool that decides numerous properties by an inspection of the state space of
a given Petri net. For making state-space inspection feasible, it offers several state-space
reduction techniques.
4.2.2.2.1.

Analyzing soundness

The activity diagrams have to be translated into Petri nets prior to the verification as
shown in 4.1. To verify soundness, LoLA works in two runs on the resulting Petri nets. In
the first run, it checks for local deadlocks and in the second run for lack of
synchronization.
A process has no deadlock iff a final state can be reached from every reachable state; a
state is final iff each token has reached an end node. The latter can easily be expressed as
a state predicate in LoLA. The former can be expressed as a CTL formula over this
predicate and checked by LoLA directly. LoLA checks the property on-the-fly, i.e., while
the state space is being generated. As soon as LoLA detects a violation, it stops and
returns the violating state. Once an error state has been found, a reachability check is
used to produce a trace to the error state.

80

Figure 4.4: Model checking a system specification [115]

4.2.2.2.2.

Analyzing safeness

LoLA has a switch that causes state-space generation to be stopped if an unsafe state is
generated. A state is unsafe if a single place contains more than one token, which
indicates a lack of synchronization in the original activity diagram. This simultaneous
check for lack of synchronization in the first run prevents that LoLA tries to generate an
infinite state space and also optimizes performance for finite state spaces. If an unsafe
state is found, a trace leading to it is returned immediately. However, the test for unsafe
states cannot detect all lack of synchronization errors. Therefore, if no error has been
detected during the first run, LoLA is invoked a second time on each net, this time
explicitly checking for lack of synchronization.
Lack of synchronization, i.e., unsafeness of states, can be expressed in LoLA as the state
predicate

( )

, where P is the set of places of the Petri net. As this set can

become very large. We can assert by construction for several places in the Petri net that
they cannot obtain more than one token unless a preceding place is also able to do so. In
essence, only places that represent a merge or an exit of a cycle need to be considered.
The resulting state predicate is checked for reachability by LoLA. If the predicate is
81

satisfied, a lack of synchronization is identified and LoLA produces a trace to the error
state.
4.3. Application
To better illustrate the goal of our project we will apply the concepts to a case study, a
vending machine. The latter will be able to only distribute PePsi and Coke sodas. The
machine should allow the user to choose his drink. We designed the corresponding
diagram so that it contains workflow errors, then we analyzed the design using our
methodology to check both deadlock freedom and safeness properties.
Figure 4.5 describes the initial activity diagram that contains workflow errors that must
be, conceptually, revealed by our proposed approach.
The transformation of the diagram is performed by directly processing the .uml file
representing the diagram, by first importing the file into our work space using the
import button of our user interface. After loading the file into the transformation engine
we can transform it using the transform to petri-net button. If the latter is successfully
executed a .lola file describing the generated PN, will be created, figure 4.5.
After transforming and exporting the diagrams we get the PN model shown in figure 4.7.
(A textual representation of the generated petri net for the vending machine case study is
provided in appendix A).

82

Figure 4.5: vending machine unsound activity diagram

83

As already discussed in the previous section, formal verification of a model needs two
inputs:
-

A transition model abstracting the behavior of the model

And a logical property to be verified on the model.

In our case the transition model is a Petri Net generated by the instrumented
transformation from activity diagrams and the temporal property will be given as input by
the user as a CTL formula, and as contribution of this project soundness and safeness
properties can be generated automatically by our tool.
Figure 4.6 shows the user interface of the solution:
Zone 1 in the figure represents the path of the uml file chosen with a file picker when
clicking on the button in zone 2. In order to generate the corresponding LoLa petri-net,
one must click on the button transform to PetriNet represented in zone 3, and then the
result of the transformation will be printed in zone 4, the textual representation of the net
can be converted into a visual diagram using a tool called seda [113].
Now that we have the a transition model, the engineer must supplement a temporal
formula in order to be able to model-check the system, thus two automatically generated
properties of the diagram can be used on the fly, without any technical expertise. To do
that we should first choose the method of supplementing the formula in zone 6 (automatic
or manual for more experienced engineers), by choosing automatic two buttons will be
activated: soundness in zone 8 and safeness in zone 9. Clicking on one of these buttons
will print the generated CTL formula in zone 5 and will invoke the LoLa model-checker
which will generate a JSON file containing the result of the analysis. The content of the
84

resulting JSON file will be printed on zone 11. Its possible the result of the verification
will contain a counter example path if the formula doesnt hold, which will activate the
button generate feedback in order to map the error path to the original umldi file,
clicking on this button will create a file named XXXX_ErrorTrace.umldi in the folder
containing the uml file targeted by the analysis (where XXXX is any arbitrary name).

Figure 4.6: Acitivity2Petri user interface

For some users with background on formal verification and CTL, a method to manually
edit more specific CTL formulas of the model was implemented (zone 6 and 5 of figure
4.6).

85

Figure 4.7: unsound petri net obtained by transformation

86

By processing the output generated by the LoLa model-checker we have the diagram in

figure 4.9, which shows the error trace corresponding to the PN nodes that contains
deadlock.

Figure 4.8: Control flow error trace on the activity diagram

87

The deadlock happens in light of the fact that the vending machine can pick freely of the
user which drink it outputs. If the users and the machines choices are not the same, we
have a deadlock. The issue can be comprehended by making the machines choices
depend on the users data.

88

5. Conclusion and future work

The objective of this work was to propose a transformation of activity diagrams to Petri
nets in an MDE framework in accordance to the OMG specifications. It appeared difficult
to comply with all the specifications, because the lack of specification tools or their lack
of maturity is a major barrier to the development of a solution fully compatible with the
OMG. We tried to make our approach the most generic possible in order to transform into
Petri nets the majority of activity diagrams elements, which sometimes leads to complex
solutions but which are transparent to the user.
Many shortcuts (simplification) in the development of the concepts transformation were
ignored in order to comply with the OMG specifications. The use of the concepts
mapping allows saving time during the establishment of the rules. The development of
basic rules is trivial if the two meta-models are close (a source meta-class corresponds to
one or two target meta-classes) but it becomes heavy and complex to develop complex
transformations. The goal of this project was in its infancy to transform activity diagrams
into Petri nets, over the study it seemed interesting to look at how the properties can be
derived automatically, thus new transformations came to complete this work in order to
better adapt our solution for users with no experience in formal models.
One possible extension of the project will be the support of data-flow in activity
diagrams, but with the standard form of PetriNets we could not verify data-flow, thus we
have to develop the same approaches by using colored petri nets, where colors are
different data types. We should also use SySML instead of UML because of the presence
of a special diagram called requirement diagram that will serve as a source model for a
detailed generation of atomic temporal formulas.
89

References
[1] UML, OMG, "2.0 superstructure final adopted specification," in OMG Document
reference ptc/03-08 2, 2003.
[2] C. Bock, "UML 2 activity and action models, Part 2: Actions," in Journal of Object
Technology 2.5, 2003, pp. 41-56.
[3] C. Bock, UML 2 Activity and Action Models, Part 4: Object nodes, in Journal of
Object Technology 3, 2004, pp. 27-41.
[4] C. Bock, UML 2 Activity and Action Models, in Journal of Object Technology 2,
2003, pp. 43-53.
[5] C. Bock, UML 2 Activity and Action Models Part 3: Control Nodes, in Journal of
Object Technology 2, 2003, pp. 7-23.
[6] C. Bock, UML 2 Activity and Action Models Part 5: Partitions, in Journal of Object
Technology 3, 2004, pp. 37-56.
[7] J.L. Garrido and G.Miguel, "A coloured petri net formalisation for a UML-based notation
applied to cooperative system modeling," in Lecture notes in computer science 2545,
2002, pp. 16-28.
[8] W. Reisigs and R.Grzegorz, "Informal introduction to petri nets," in Lectures on Petri
Nets I: Basic Models. Springer Berlin Heidelberg, 1998, pp. 1-11.
[9] LoLa, low level petri net analyzer http://service-technology.org/lola/index.html
[10] B. Selic, "The pragmatics of model-driven development," in IEEE software 5, 2003, pp.
19-25.
[11] J.Bzivin and G.Olivier, "Towards a precise definition of the OMG/MDA framework," in
Automated Software Engineering, 2001.(ASE 2001). Proceedings. 16th Annual
International Conference on. IEEE, 2001.
[12] J. Rumbaugh et al, Unified Modeling Language Reference Manual, Pearson Higher
Education, 2004.
[13] Harel, David, and Hillel Kugler. "The rhapsody semantics of statecharts (or, on the
executable core of the UML)." In Integration of Software Specification Techniques for
Applications in Engineering. Springer Berlin Heidelberg, 2004, pp. 325-354.
[14] H.Tardieu et al, "La mthode MERISE-principes et outils,", 1984.
[15] J.Bzivin et al, "Rapport de Synthse de lAS CNRS sur le MDA (Model Driven
Architecture)." In CNRS, novembre, 2004.
[16] J.Bzivin, "In search of a basic principle for model driven engineering,"in Novatica
Journal, Special Issue 5.2, 2004, pp. 21-24.
[17] V.J.R. Erstellt, How UML2 and MOF relate
http://bluedynamics.com/articles/johannes/how-uml2-and-mof-relate, 2009.
[18] OMG, OMG Meta Object Facility (MOF) specification v2.0,, 2006.
[19] J.M. Favre, "Foundations of Meta-Pyramids: Languages vs. Metamodels-Episode II:
Story of Thotus the Baboon1," in Language Engineering for Model-Driven Software
Development 4101, 2004.
[20] C. Atkinson and K.Thomas, "Model-driven development: a metamodeling
foundation," in Software, IEEE 20.5, 2003, pp. 36-41.
[21] R. Soley, "Model driven architecture," in OMG white paper 308.308, 2000.
90

[22]
[23]
[24]
[25]
[26]

[27]
[28]

[29]
[30]
[31]

[32]
[33]
[34]
[35]

[36]
[37]

[38]
[39]
[40]
[41]
[42]

[43]
[44]

OMG, Unified Modeling Language (UML) Infrastructure Specification 2.4.1, 2011.

OMG, MDA Guide Version 1.0. 1, 2003.
OMG, MDA success stories http://www.omg.org/mda/products_success.htm
D. Potier, Briques gnriques du logiciel embarqu, in Technical report, Ministre de
lindustrie (France), 2010.
P. Froment, "LES TECHNOLOGIES D'INFORMATION ET DE COMMUNICATION
ET LEURS APPLICATIONS-Les applications-L'architecture avionique de l'A380." In
Realites Industrielles-Annales des Mines, 2005, pp.45-50.
B. Meyer, "On formalism in specifications." In IEEE software, 1985, pp.6-26.
K. Czarnecki and H.Simon, "Classification of model transformation approaches," in
Proceedings of the 2nd OOPSLA Workshop on Generative Techniques in the Context of
the Model Driven Architecture. Vol. 45. No. 3, 2003.
A.Gerber et al, "Transformation: The missing link of MDA," in Graph Transformation.
Springer Berlin Heidelberg, 2002, pp. 90-105.
A. Hartman, "Model based test generation tools," in Agedis Consortium, 2002.
P.A. Fernandes et al, "Use of modelling methods and tools in an industrial embedded
system project: works and feedback," in Embedded Real-time Software and Systems
(ERTS2), France, 2012.
J.Pouly and J.Sylvain, "Model-based specification of the flight software of an
autonomous satellite,", 2012.
L.Apfelbaum and D.John, "Model based testing." In Software Quality Week Conference,
1997.
OMG, Object Constraint Language (OCL) 2.3.1,, 2012.
S.Grard et al, "6 Modeling Languages for Real-Time and Embedded Systems," in
Model-Based Engineering of Embedded Real-Time Systems. Springer Berlin Heidelberg,
2010, pp. 129-154.
OMG, Systems Modeling Language (SysML) Specification 1.3,, 2012.
G.Pedroza et al, "Avatar: A sysml environment for the formal verification of safety and
security properties," in New Technologies of Distributed Systems (NOTERE), 2011 11th
Annual International Conference on. IEEE, 2011.
Simulink. Simulation and Model-Based Design
http://www.mathworks.fr/products/simulink
H.F. Peter and D.P. Gluch. Model-Based Engineering with AADL: An Introduction to
the SAE Architecture Analysis & Design Language, in Addison-Wesley, 2012.
OMG, Business Process Model and Notation (BPMN) 2.0, 2011.
D.Steinberg et al, "Merks, EMF: Eclipse Modeling Framework 2.0,", 2009.
M.V. Andre, Design Authority Architecture and Design Standards
https://portfoliodiagnostic.wordpress.com/2011 /09/15/design-authority-%E2%80%93architecture-and-design-standards/
J.M. Favre et al, "L'ingnierie dirige par les modles: au-del du MDA,", 2006.
S.Kent, "Model driven engineering," in Integrated formal methods. Springer Berlin
Heidelberg, 2002.

91

[45] M. Soeken et al, "Verifying UML/OCL models using Boolean satisfiability," in

Proceedings of the Conference on Design, Automation and Test in Europe. European
Design and Automation Association, 2010.
[46] K.Anastasakis et al, "UML2Alloy: A challenging model transformation," Model Driven
Engineering Languages and Systems. Springer Berlin Heidelberg, 2007, pp. 436-450.
[47] J.Cabot et al, "Verification of UML/OCL class diagrams using constraint
programming," in Software Testing Verification and Validation Workshop, 2008.
ICSTW'08. IEEE International Conference on. IEEE, 2008.
[48] alloy: a language & tool for relational models http://alloy.mit.edu/alloy/
[49] The ECLiPSe Constraint Programming System http://eclipseclp.org/
[50] J.Bzivin, "Model driven engineering: An emerging technical space," in Generative and
transformational techniques in software engineering. Springer Berlin Heidelberg, 2006,
pp. 36-64.
[51] R.Delmas et al, "Supporting model based design," in Model and Data Engineering.
Springer Berlin Heidelberg, 2011, pp. 237-248.
[52] R.Delmas et al, "IDM: Vers une aide la conception," in INFORSID, 2011.
[53] A.Toom et al, "Gene-auto: an automatic code generator for a safe subset of
simulink/stateflow and scicos," in European Conference on Embedded Real-Time
Software (ERTS08), 2008.
[54] M.Utting and L.Bruno, Practical model-based testing: a tools approach, Morgan
Kaufmann, 2010.
[55] P.Mohagheghi and D.Vegard, "Where is the proof?-a review of experiences from
applying MDE in industry," in Model Driven ArchitectureFoundations and
Applications. Springer Berlin Heidelberg, 2008.
[56] P.Baker et al, "Model-Driven engineering in a large industrial contextmotorola case
study," in Model Driven Engineering Languages and Systems. Springer Berlin
Heidelberg, 2005, pp. 476-491.
[57] T.Weigert and W.Frank, "Practical experiences in using model-driven engineering to
develop trustworthy computing systems," in Sensor Networks, Ubiquitous, and
Trustworthy Computing, 2006. IEEE International Conference on. Vol. 1. IEEE, 2006.
[58] D.Herst and E.Roman, "Model Driven Development for J2EE Utilizing a Model Driven
Architecture (MDA)-Approach: A Productivity Analysis," in MiddlewareRESEARCH.com, 2003.
[59] R.C.Gronback, Eclipse modeling project: a domain-specific language (DSL) toolkit, in
Pearson Education, 2009.
[60] Graphical Modeling Project. www.eclipse.org/modeling/gmp
[61] Textual Modeling Framework www.eclipse.org/modeling/tmf
[62] Model to Model Transformation www.eclipse.org/mmt
[63] Model To Text www.eclipse.org/modeling/m2t
[64] Modeling Development Tools www.eclipse.org/modeling/mdt
[65] P.Farail et al, "The TOPCASED project: a toolkit in open source for critical aeronautic
systems design," Embedded Real Time Software (ERTS)781, 2006, pp.54-59.
[66] Topcased indicators, www.topcased.org/index.php?indicators
[67] Scade suite, www.esterel-technologies.com/products/scade-suite
92

[68] N.Halbwachs et al, "The synchronous data flow programming language LUSTRE," in
Proceedings of the IEEE 79.9, 1991, pp.1305-1320.
[69] IBM Rational Rhapsody family, http://www-03.ibm.com/software/products/en/ratirhapfami
[70] IBM Rational System Architect, http://www-03.ibm.com/software/products/fr/ratisystarch
[71] Magic draw, www.nomagic.com/products/magicdraw.html
[72] "IEEE standard glossary of software engineering terminology." In Office 121990.1, 1990.
[73] J.M.Glenford, "The art of software testing," in John Wiley and Sons, ISBN10, 1979.
[74] B.Beizer, Software testing techniques in Dreamtech Press, 2003.
[75] B.Marre and A.Agnes, "Test sequences generation from lustre descriptions: Gatel," in
Automated Software Engineering, 2000. Proceedings ASE 2000. The Fifteenth IEEE
International Conference on. IEEE, 2000.
[76] N.Williams et al, "Pathcrawler: Automatic generation of path tests by combining static
and dynamic analysis," in Dependable Computing-EDCC 5. Springer Berlin Heidelberg,
2005, pp.281-292.
[77] E.W.Dijkstra, "Guarded commands, nondeterminacy and formal derivation of
programs," in Communications of the ACM 18.8, 1975, pp. 453-457.
[78] E.M.Clarke and E.E.Allen Design and synthesis of synchronization skeletons using
branching time temporal logic, in Springer Berlin Heidelberg, 1982.
[79] J.P.Queille and S.Joseph, "Specification and verification of concurrent systems in
CESAR," in International Symposium on Programming. Springer Berlin Heidelberg,
1982.
[80] M.C.Browne et al, "Characterizing Kripke structures in temporal logic," in TAPSOFT'87.
Springer Berlin Heidelberg, 1987.
[81] C.Girault and V.Rdiger, Petri nets for systems engineering: a guide to modeling,
verification, and applications, in Springer Science & Business Media, 2013.
[82] A.N.Prior, Past, present and future. Vol. 154, in Oxford: Clarendon Press, 1967.
[83] A.Pnueli, "The temporal logic of programs," in Foundations of Computer Science, 1977.,
18th Annual Symposium on. IEEE, 1977.
[84] T.A.Henzinger et al, "Temporal-safety proofs for systems code," in Computer Aided
Verification. Springer Berlin Heidelberg, 2002.
[85] T.Ball et al, "SLAM and Static Driver Verifier: Technology transfer of formal methods
inside Microsoft," in Integrated formal methods. Springer Berlin Heidelberg, 2004.
[86] K.L.McMillan, Symbolic model checking, in Springer US, 1993.
[87] R.E.Bryant, "Symbolic Boolean manipulation with ordered binary-decision diagrams," in
ACM Computing Surveys (CSUR) 24.3, 1992, pp.293-318.
[88] SMV model checker, http://www.cs.cmu.edu/~modelcheck/smv.html
[89] SPIN model checker, http://spinroot.com/spin/whatispin.html
[90] TINA model checker, http://projects.laas.fr/tina/manuals/selt.html
[91] P.Cousot and C.Radhia, "Abstract interpretation: a unified lattice model for static
analysis of programs by construction or approximation of fixpoints," in Proceedings of
the 4th ACM SIGACT-SIGPLAN symposium on Principles of programming languages.
ACM, 1977.
93

[92] P.Cousot and C.Radhia, "Abstract interpretation frameworks," in Journal of logic and
computation 2.4, 1992, pp.511-547.
[93] H.G.Rice, "Classes of recursively enumerable sets and their decision problems," in
Transactions of the American Mathematical Society, 1953, pp.358-366.
[94] A.Min, "The octagon abstract domain," in Higher-Order and Symbolic
Computation 19.1, 2006, pp.31-100.
[95] L.Chen et al, "A sound floating-point polyhedra abstract domain," Programming
Languages and Systems. Springer Berlin Heidelberg, 2008, pp. 3-18.
[96] B.Blanchet et al, "A static analyzer for large safety-critical software."ACM SIGPLAN
Notices. Vol. 38. No. 5. ACM, 2003.
[97] The Coq proof assistant, https://coq.inria.fr/
[98] Y.Bertot and C.Pierre "Interactive theorem proving and program development: CoqArt:
the calculus of inductive constructions, in Springer Science & Business Media, 2013.
[99] The HOL interactive proof assistant, http://hol.sourceforge.net/
[100] M.Archer, Proceedings of the 1991 International Workshop on the HOL Theorem
Proving System and Its Applications, August 28-30, 1991, Davis, California, in IEEE
Computer Society Press, 1992.
[101] The Isabelle proof assistant, https://www.cl.cam.ac.uk/research/hvg/Isabelle/
[102] J.C.Fillitre and M.Claude, "Multi-prover verification of C programs," in Formal
Methods and Software Engineering. Springer Berlin Heidelberg, 2004, pp.15-29.
[103] M.Claude et al, "The krakatoa tool for certificationof java/javacard programs annotated in
jml," in The Journal of Logic and Algebraic Programming 58.1, 2004, pp.89-106.
[104] C.A.R.Hoare, "An axiomatic basis for computer programming," in Communications of
the ACM 12.10, 1969, pp. 576-580.
[105] The Frama-C analyzer, http://frama-c.com/
[106] Activity Diagrams, http://www.uml-diagrams.org/activity-diagrams.html
[107] A.Semenov et al, "Designing an asynchronous processor using Petri nets," in IEEE
Micro 2, 1997, pp.54-64.
[108] Q.Qiu et al, "Dynamic power management of complex systems using generalized
stochastic Petri nets," in Proceedings of the 37th Annual Design Automation Conference.
ACM, 2000.
[109] F.Jouault and K.Ivan, "Transforming models with ATL," in satellite events at the
MoDELS 2005 Conference. Springer Berlin Heidelberg, 2006.
[110] K.Schmidt, "Lola a low level analyser," in Application and Theory of Petri Nets 2000.
Springer Berlin Heidelberg, 2000, pp. 465-474.
[111] OMG, XML Metadata Interchange (XMI), http://www.omg.org/spec/XMI/.
[112] Omg, Qvt. "Meta object facility (mof) 2.0 query/view/transformation specification," in
Final Adopted Specification November 2005, 2008.
[113] "Seda petri net editor," http://service-technology.org/seda/index.html
[114] S.Hinz et al, Transforming BPEL to Petri nets," in Business Process Management.
Springer Berlin Heidelberg, 2005, pp.220-235.
[115] Computational tree logic, http://resist.isti.cnr.it/free_slides/testing/bowen/w3_l1_ctl.pdf
[116] K.Wolf, "Generating Petri net state spaces," in Petri Nets and Other Models of
ConcurrencyICATPN 2007. Springer Berlin Heidelberg, 2007, pp.29-42.
94

[117] M.Yannick et al, "Testing or Formal Verification: DO-178C Alternatives and Industrial
Experience", IEEE Software, vol.30, no. 3, 2013, pp. 50-57.
[118] L.B.Edmundo, How to create a Petri net editor using GMF (Part 1),, 2014,
http://edmundo.lopezbobeda.net/blog/how-create-petri-net-editor-using-gmf-part-1
[119] Shlaer-Mellor and Executable UML Portal http://ooatool.com/ooa/fUML08/
[120] D.Bisztray et al, "Case study: UML to CSP transformation," in Applications of Graph
Transformation with Industrial Relevance (AGTIVE), 2007.
[121] Y.Dong and S.Zhang, "Using -calculus to formalize uml activity diagram for business
process modeling," in Engineering of Computer-Based Systems, 2003. Proceedings. 10th
IEEE International Conference and Workshop on the IEEE, 2003, pp. 47-54.
[122] H.Strrle and J. H. Hausmann, "semantics of uml 2.0 activities," in Proceedings of the
IEEE Symposium on Visual Languages and Human-Centric Computing, 2004.

95

Appendix A: Unsound petri net of the vending machine case study

PLACE
InitialNode1,
ActivityFinalNode1,
ForkNode1->ForkNode2,
ForkNode1->JoinNode1,
JoinNode1->await_coin,
DecisionNode2,
JoinNode3->dispose_coke,
dispose_coke->ForkNode7,
ForkNode7->JoinNode5,
MergeNode1,
JoinNode5->get_coke,
MergeNode2,
JoinNode6->JoinNode7,
JoinNode2->dispose_pepsi,
dispose_pepsi->ForkNode6,
ForkNode6->JoinNode4,
JoinNode4->get_pespi,
ForkNode2->insert_coin,
DecisionNode1,
choose_coke->ForkNode5,
ForkNode5->JoinNode3,
ForkNode5->JoinNode5,
choose_pepsi->ForkNode4,
ForkNode4->JoinNode2,
ForkNode4->JoinNode4,
insert_coin->ForkNode3,
ForkNode3->JoinNode1,
ForkNode3->JoinNode6
;

MARKING
InitialNode1 :
;

TRANSITION ForkNode1
CONSUME
InitialNode1: 1;
PRODUCE
ForkNode1->ForkNode2:
ForkNode1->JoinNode1:

TRANSITION JoinNode1
CONSUME
ForkNode1->JoinNode1:
ForkNode3->JoinNode1:
PRODUCE
JoinNode1->await_coin:

1,
1;

1,
1;
1;

96

TRANSITION await_coin
CONSUME
JoinNode1->await_coin:
PRODUCE
DecisionNode2:
1;

TRANSITION JoinNode3
CONSUME
DecisionNode2:
1,
ForkNode5->JoinNode3:
PRODUCE
JoinNode3->dispose_coke:

TRANSITION dispose_coke
CONSUME
JoinNode3->dispose_coke:
PRODUCE
dispose_coke->ForkNode7:

TRANSITION ForkNode7
CONSUME
dispose_coke->ForkNode7:
PRODUCE
ForkNode7->JoinNode5:
MergeNode1: 1;

TRANSITION JoinNode7
CONSUME
MergeNode1: 1,
JoinNode6->JoinNode7:
PRODUCE
ActivityFinalNode1: 1;

TRANSITION JoinNode5
CONSUME
ForkNode5->JoinNode5:
ForkNode7->JoinNode5:
PRODUCE
JoinNode5->get_coke:

1;

1;
1;

1;
1;

1;
1,

1;

1,
1;
1;

TRANSITION get_coke

97

CONSUME
JoinNode5->get_coke:
PRODUCE
MergeNode2: 1;

TRANSITION JoinNode6
CONSUME
ForkNode3->JoinNode6:
MergeNode2: 1;
PRODUCE
JoinNode6->JoinNode7:

1;

1,

1;

TRANSITION JoinNode2
CONSUME
DecisionNode2:
1,
ForkNode4->JoinNode2:
1;
PRODUCE
JoinNode2->dispose_pepsi: 1;

TRANSITION dispose_pepsi
CONSUME
JoinNode2->dispose_pepsi: 1;
PRODUCE
dispose_pepsi->ForkNode6: 1;

TRANSITION ForkNode6
CONSUME
dispose_pepsi->ForkNode6: 1;
PRODUCE
ForkNode6->JoinNode4:
1,
MergeNode1: 1;

TRANSITION JoinNode4
CONSUME
ForkNode4->JoinNode4:
ForkNode6->JoinNode4:
PRODUCE
JoinNode4->get_pespi:

TRANSITION get_pespi
CONSUME
JoinNode4->get_pespi:
PRODUCE

1,
1;
1;

1;

98

MergeNode2:

1;

TRANSITION ForkNode2
CONSUME
ForkNode1->ForkNode2:
PRODUCE
ForkNode2->insert_coin:
DecisionNode1:
1;

TRANSITION choose_coke
CONSUME
DecisionNode1:
1;
PRODUCE
choose_coke->ForkNode5:

TRANSITION ForkNode5
CONSUME
choose_coke->ForkNode5:
PRODUCE
ForkNode5->JoinNode3:
ForkNode5->JoinNode5:

TRANSITION choose_pepsi
CONSUME
DecisionNode1:
1;
PRODUCE
choose_pepsi->ForkNode4:

TRANSITION ForkNode4
CONSUME
choose_pepsi->ForkNode4:
PRODUCE
ForkNode4->JoinNode2:
ForkNode4->JoinNode4:

TRANSITION insert_coin
CONSUME
ForkNode2->insert_coin:
PRODUCE
insert_coin->ForkNode3:

1;
1,

1;

1;
1,
1;

1;

1;
1,
1;

1;
1;

99

TRANSITION ForkNode3
CONSUME
insert_coin->ForkNode3:
PRODUCE
ForkNode3->JoinNode1:
ForkNode3->JoinNode6:

1;
1,
1;

100

Appendix B: Analyzing soundness formula

EF (InitialNode1 = 0
AND ForkNode1->ForkNode2 = 0
AND ForkNode1->JoinNode1 = 0
AND JoinNode1->await_coin = 0
AND DecisionNode2 = 0
AND JoinNode3->dispose_coke = 0
AND dispose_coke->ForkNode7 = 0
AND ForkNode7->JoinNode5 = 0
AND MergeNode1 = 0
AND JoinNode5->get_coke = 0
AND MergeNode2 = 0
AND JoinNode6->JoinNode7 = 0
AND JoinNode2->dispose_pepsi = 0
AND dispose_pepsi->ForkNode6 = 0
AND ForkNode6->JoinNode4 = 0
AND JoinNode4->get_pespi = 0
AND ForkNode2->insert_coin = 0
AND DecisionNode1 = 0
AND choose_coke->ForkNode5 = 0
AND ForkNode5->JoinNode3 = 0
AND ForkNode5->JoinNode5 = 0
AND choose_pepsi->ForkNode4 = 0
AND ForkNode4->JoinNode2 = 0
AND ForkNode4->JoinNode4 = 0
AND insert_coin->ForkNode3 = 0
AND ForkNode3->JoinNode1 = 0
AND ForkNode3->JoinNode6 = 0
AND ActivityFinalNode1 = 1)

101

Appendix C: Analyzing liveness formula

AGEF FIREABLE(ForkNode1)
AND FIREABLE(JoinNode1)
AND FIREABLE(await_coin)
AND FIREABLE(JoinNode3)
AND FIREABLE(dispose_coke)
AND FIREABLE(ForkNode7)
AND FIREABLE(JoinNode7)
AND FIREABLE(JoinNode5)
AND FIREABLE(get_coke)
AND FIREABLE(JoinNode6)
AND FIREABLE(JoinNode2)
AND FIREABLE(dispose_pepsi)
AND FIREABLE(ForkNode6)
AND FIREABLE(JoinNode4)
AND FIREABLE(get_pespi)
AND FIREABLE(ForkNode2)
AND FIREABLE(choose_coke)
AND FIREABLE(ForkNode5)
AND FIREABLE(choose_pepsi)
AND FIREABLE(ForkNode4)
AND FIREABLE(insert_coin)
AND FIREABLE(ForkNode3)

102