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

2

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 model-

checking, 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.

3

ملخص

إن تطور األنظمة المعلوماتٌة موسوم بصعوبة متزاٌدة ألن هذه األنظمة من المفترض أن تستجٌب بشكل فعال و مضبوط عند

و التثبت من هذه األنظمة ٌعرف بصعوبته و قلة الخبرة النظرٌة و التطبٌقٌة. الصعوبة مواجهة المواقف الحرجة. التحقق

األولى تكمن فً مستوى لغات التصمٌم و التً رغم إمكانٌاتها التعبٌرٌة, إال أنها تفتقد إلى أساسٌات و ركائز الرٌاضٌات. لذا,

ن فً االنفجار التركٌبً للحاالت الممكنة. فبالفعل, و رغم التقدم التحقق األوتوماتٌكً منها شبه مستحٌل. الصعوبة الثانٌة تكم

الهائل فً مجال تكنولوجٌا الكومبٌوتر, قد ٌعتبر التحقق الكامل من هذه األنظمة ضربا من الخٌال بسبب قلة الذاكرة و الوقت.

التحدي ٌكمن إذا فً اقتراح تصامٌم معبرة بما فٌه الكفاٌة و معقولة فً إمكانٌة التحقق و التثبت األوتوماتٌكً. هنالك أعمال

سابقة عمدت إلى تقلٌل الفجوة باقتراح ترجمة التصامٌم غٌر الرسمٌة إلى تصامٌم ذات طابع رسمً تؤٌد "مودٌل شٌكٌن",

رف مهندس الكومبٌوتر. هذا المشروع ٌسٌر فً هذا المجال و ٌقترح طرٌقة رسمٌة للتحقق بطرٌقة شفافة و غٌر مرئٌة من ط

من رسم دٌنامٌكً بٌانً معروف ب آكتٌفٌتً دٌاكرام, بترجمته إلى لغة رسمٌة, أي شبكات بٌتري, و التً بدورها تمكن من

التصامٌم مسٌرة بة الالتثبت و التحقق الرسمً األوتوماتٌكً. و هذا باحترام مبادئ الهندس

4

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.

5

Table of content

1. Introduction ............................................................................................................................. 9

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

1.2. Objective ......................................................................................................................... 9

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

2. Background ........................................................................................................................... 11

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

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. 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

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

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

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

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

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

3.2.1. Overview ............................................................................................................... 59

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

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

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

6

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

4.2.1. Transformation ...................................................................................................... 75

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

4.3. Application .................................................................................................................... 82

5. 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

7

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

8

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

9

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

10

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.

11

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. Let’s 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. ",

12

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

13

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.

14

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 meta-

model. 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

15

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

16

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

17

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 code-

related 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.

18

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

19

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-meta-

model 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.

20

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

21

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

22

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

23

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).

24

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.

25

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.

26

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

27

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 phase’s 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

28

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 hand-

coding. 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.

29

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.

30

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].

31

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

32

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.

33

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

34

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.

35

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

doesn’t 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.

36

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

37

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

38

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 Astrée [96]

that are able to check thousands of critical embedded code lines, but focusing only on

certain types of properties.

39

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]).

40

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.

41

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]

42

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

43

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

44

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].

45

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].

46

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

47

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.

48

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.

49

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.

50

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]

51

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.

52

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.

53

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

54

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

55

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.

56

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

57

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.

58

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]

59

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

60

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.

61

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:

62

- 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.

63

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.

64

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:

65

-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.

66

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.

67

- 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:

68

-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:

69

-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.

70

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.

71

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

72

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].

73

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.

74

Figure 4.1: Overall methodology

75

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

76

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. That’s why the automated

generation of networks and formal verification is essential.

77

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, it’s 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

78

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]

79

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

80

property. One technique is to obtain a Büchi 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 Büchi 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.

81

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

82

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).

83

Figure 4.5: vending machine unsound activity diagram

84

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

85

resulting JSON file will be printed on zone 11. It’s possible the result of the verification

will contain a counter example path if the formula doesn’t 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).

86

Figure 4.7: unsound petri net obtained by transformation

87

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

88

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 user’s data.

89

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.

90

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.Bézivin 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 méthode MERISE-principes et outils,", 1984.

[15] J.Bézivin et al, "Rapport de Synthèse de l’AS CNRS sur le MDA (Model Driven

Architecture)." In CNRS, novembre, 2004.

[16] J.Bézivin, "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.

91

[22] OMG, ―Unified Modeling Language (UML) Infrastructure Specification 2.4.1‖, 2011.

[23] OMG, ―MDA Guide Version 1.0. 1‖, 2003.

[24] OMG, ―MDA success stories‖ http://www.omg.org/mda/products_success.htm

[25] D. Potier, ―Briques génériques du logiciel embarqué, ‖ in Technical report, Ministère de

l’industrie (France), 2010.

[26] 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.

[27] B. Meyer, "On formalism in specifications." In IEEE software, 1985, pp.6-26.

[28] 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.

[29] A.Gerber et al, "Transformation: The missing link of MDA," in Graph Transformation.

Springer Berlin Heidelberg, 2002, pp. 90-105.

[30] A. Hartman, "Model based test generation tools," in Agedis Consortium, 2002.

[31] 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.

[32] J.Pouly and J.Sylvain, "Model-based specification of the flight software of an

autonomous satellite,", 2012.

[33] L.Apfelbaum and D.John, "Model based testing." In Software Quality Week Conference,

1997.

[34] OMG, ―Object Constraint Language (OCL) 2.3.1,‖, 2012.

[35] S.Gérard 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.

[36] OMG, ―Systems Modeling Language (SysML) Specification 1.3,‖, 2012.

[37] 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.

[38] Simulink. ―Simulation and Model-Based Design‖

http://www.mathworks.fr/products/simulink

[39] 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.

[40] OMG, ―Business Process Model and Notation (BPMN) 2.0‖, 2011.

[41] D.Steinberg et al, "Merks, EMF: Eclipse Modeling Framework 2.0,", 2009.

[42] M.V. Andre, ―Design Authority – Architecture and Design Standards‖

https://portfoliodiagnostic.wordpress.com/2011 /09/15/design-authority-%E2%80%93-

architecture-and-design-standards/

[43] J.M. Favre et al, "L'ingénierie dirigée par les modèles: au-delà du MDA,", 2006.

[44] S.Kent, "Model driven engineering," in Integrated formal methods. Springer Berlin

Heidelberg, 2002.

92

[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.Bézivin, "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 (ERTS’08), 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 Architecture–Foundations and

Applications. Springer Berlin Heidelberg, 2008.

[56] P.Baker et al, "Model-Driven engineering in a large industrial context—motorola 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 Middleware-

RESEARCH.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

93

[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.Rüdiger, ―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.

94

[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: Coq’Art:

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.Filliâtre 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

Concurrency–ICATPN 2007. Springer Berlin Heidelberg, 2007, pp.29-42.

95

[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.Störrle and J. H. Hausmann, "semantics of uml 2.0 activities," in Proceedings of the

IEEE Symposium on Visual Languages and Human-Centric Computing, 2004.

96

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 : 1 ; TRANSITION ForkNode1 CONSUME InitialNode1: 1; PRODUCE ForkNode1->ForkNode2: 1, ForkNode1->JoinNode1: 1; TRANSITION JoinNode1 CONSUME ForkNode1->JoinNode1: 1, ForkNode3->JoinNode1: 1; PRODUCE JoinNode1->await_coin: 1;

97

TRANSITION await_coin CONSUME JoinNode1->await_coin: 1; PRODUCE DecisionNode2: 1; TRANSITION JoinNode3 CONSUME DecisionNode2: 1, ForkNode5->JoinNode3: 1; PRODUCE JoinNode3->dispose_coke: 1; TRANSITION dispose_coke CONSUME JoinNode3->dispose_coke: 1; PRODUCE dispose_coke->ForkNode7: 1; TRANSITION ForkNode7 CONSUME dispose_coke->ForkNode7: 1; PRODUCE ForkNode7->JoinNode5: 1, MergeNode1: 1; TRANSITION JoinNode7 CONSUME MergeNode1: 1, JoinNode6->JoinNode7: 1; PRODUCE ActivityFinalNode1: 1; TRANSITION JoinNode5 CONSUME ForkNode5->JoinNode5: 1, ForkNode7->JoinNode5: 1; PRODUCE JoinNode5->get_coke: 1; TRANSITION get_coke

98

CONSUME JoinNode5->get_coke: 1; PRODUCE MergeNode2: 1; TRANSITION JoinNode6 CONSUME ForkNode3->JoinNode6: 1, MergeNode2: 1; PRODUCE JoinNode6->JoinNode7: 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: 1, ForkNode6->JoinNode4: 1; PRODUCE JoinNode4->get_pespi: 1; TRANSITION get_pespi CONSUME JoinNode4->get_pespi: 1; PRODUCE

99

MergeNode2: 1; TRANSITION ForkNode2 CONSUME ForkNode1->ForkNode2: 1; PRODUCE ForkNode2->insert_coin: 1, DecisionNode1: 1; TRANSITION choose_coke CONSUME DecisionNode1: 1; PRODUCE choose_coke->ForkNode5: 1; TRANSITION ForkNode5 CONSUME choose_coke->ForkNode5: 1; PRODUCE ForkNode5->JoinNode3: 1, ForkNode5->JoinNode5: 1; TRANSITION choose_pepsi CONSUME DecisionNode1: 1; PRODUCE choose_pepsi->ForkNode4: 1; TRANSITION ForkNode4 CONSUME choose_pepsi->ForkNode4: 1; PRODUCE ForkNode4->JoinNode2: 1, ForkNode4->JoinNode4: 1; TRANSITION insert_coin CONSUME ForkNode2->insert_coin: 1; PRODUCE insert_coin->ForkNode3: 1;

100

TRANSITION ForkNode3 CONSUME insert_coin->ForkNode3: 1; PRODUCE ForkNode3->JoinNode1: 1, ForkNode3->JoinNode6: 1;

101

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)

102

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)