Professional Documents
Culture Documents
A Model Driven Engineering Approach For Analyzing & Debugging UML Activity Diagrams
A Model Driven Engineering Approach For Analyzing & Debugging UML Activity Diagrams
A Model Driven Engineering Approach For Analyzing & Debugging UML Activity Diagrams
July 2015
Ifrane, Morocco
Abstract
The evolution of software systems is characterized by an increasing complexity. These
systems must respond correctly and particularly when facing critical situations. The
verification and validation of these systems is recognized as a difficult task and faces
many practical and theoretical burdens. A first obstacle arises at the specification and
design languages, although very expressive, but lack mathematical formalism, hence
automatic analysis becomes almost impossible. A second obstacle is the combinatorial
explosion of the possible States. Indeed, despite the spectacular advances in computer
technology, it happens that the full analysis of such systems is out of question, due to the
lack of space or time. The challenge is therefore to propose models that are sufficiently
expressive while remaining reasonably verifiable. Existing work have tried to reduce this
gap by proposing informal models mappings to formal models that support modelchecking, carried out in a transparent manner for the software engineer. This project
integrates into this theme and proposes a formal verification method of a dynamic
diagram of UML2.x: the activity diagram (AD) by transforming the latter to the formal
language: petri nets (PN) models that support formal verification, in accordance to the
OMG model driven architecture specifications.
. .
, .,
. . ,
, .
.
" ",
.
, , ,
.
Acknowledgements
Hello dear readers!
The crafting of this part of the manuscript marks the end of writing and the end of a long
and magnificent adventure during which I met many people who have given me much
and with whom I could share very good times. This is why I must pay tribute to them
across these lines.
First, I would like to thank my supervisor who guided me throughout the duration of this
project and who believed in me. Thanks to Dr. Fallah Bouchaib. You know that without
you, I would have never been able to finish this project. I am immensely grateful for
everything you have done for me, for everything you taught me, all your good advices, all
the good discussions and all the good times that you have allowed me to live. Thank you
from the bottom of my heart.
This project would have probably never started without the support of some people. Thus
I would like to thank the entire faculty who has taught me so far as well as all the
administrative team of the school of science and engineering.
Finally and most importantly, I thank my family without whom none of this would have
been possible. My parents, Moha and Aicha, whom have always supported me in my
projects and whom always believed in me. Thanks to you both, if I am here today is
because of you. I also thank my brothers and sisters, for their support and their attentions
during my studies. I also thank the rest of my family, my friends and colleagues.
Table of content
1.
2.
Introduction ............................................................................................................................. 9
1.1.
1.2.
Objective ......................................................................................................................... 9
1.3.
Background ........................................................................................................................... 11
2.1.
2.1.1.
2.1.2.
2.1.3.
2.1.4.
Modeling languages............................................................................................... 19
2.1.5.
2.1.6.
2.2.
3.
2.2.1.
2.2.2.
2.3.
2.4.
2.4.1.
Validation by testing.............................................................................................. 36
2.4.2.
2.4.3.
2.4.4.
3.1.1.
3.1.2.
3.2.
4.
3.2.1.
Overview ............................................................................................................... 59
3.2.2.
4.2.
4.2.1.
Transformation ...................................................................................................... 75
4.2.2.
4.3.
5.
Application .................................................................................................................... 82
References ..................................................................................................................................... 90
Appendix A: Unsound petri net of the vending machine case study ............................................. 96
Appendix B: Analyzing soundness formula ................................................................................ 101
Appendix C: Analyzing liveness formula ................................................................................... 102
Table of figures
Figure 2.1: OMG's Meta layers illustration . .................................................................... 15
Figure 2.2: programming language layered architecture .................................................. 16
Figure 2.3: the V model development life cycle ............................................................... 24
Figure 2.4: Verification activities and objectives of the DO-178C certification standard 38
Figure 3.1: Activity Diagram metamodel ......................................................................... 41
Figure 3.2: Activity Nodes in Activity Diagram metamodel ............................................ 42
Figure 3.3: Activity Edges in Activity Diagram metamodel ............................................ 43
Figure 3.4: Action Notation .............................................................................................. 43
Figure 3.5: Control and data flow into an action .............................................................. 44
Figure 3.6: Control and Data Flow out of an Action ........................................................ 45
Figure 3.7: Control Nodes................................................................................................. 45
Figure 3.8: Initial Node ..................................................................................................... 46
Figure 3.9: Decision Node ................................................................................................ 46
Figure 3.10: Merge Node with Alternate Flows ............................................................... 47
Figure 3.11: Fork Node ..................................................................................................... 47
Figure 3.12: Join Node...................................................................................................... 48
Figure 3.13: Flow Final Node ........................................................................................... 49
Figure 3.14: Activity Final Node ...................................................................................... 49
Figure 3.15: Activity edge ................................................................................................ 50
Figure 3.16: Object Nodes ................................................................................................ 50
Figure 3.17: Activity Parameter Nodes ............................................................................ 51
Figure 3.18: Input Pins ...................................................................................................... 52
Figure 3.19: Pins showing effect of actions on objects .................................................... 52
Figure 3.20: Token Competition ....................................................................................... 53
Figure 3.21: Central Buffer ............................................................................................... 53
Figure 3.22: Data Store Node .......................................................................................... 54
Figure 3.23: Partition Example, Swimlane Notation ........................................................ 55
Figure 3.24: Firing example .............................................................................................. 57
Figure 3.25: Petri Net metamodel ..................................................................................... 58
Figure 3.26: basic block definition. .................................................................................. 60
Figure 3.27: initial node mapping ..................................................................................... 62
Figure 3.28: final node mapping ....................................................................................... 62
Figure 3.29: flow final node mapping............................................................................... 63
Figure 3.30: Join node mapping........................................................................................ 64
Figure 3.31: fork node mapping........................................................................................ 64
Figure 3.32: decision node mapping ................................................................................. 65
Figure 3.33: Merge node mapping .................................................................................... 66
Figure 3.34: action node mapping. ................................................................................... 67
Figure 3.35: send signal mapping ..................................................................................... 67
7
1. Introduction
1.1. Background and motivation
More and more industrials are interested in system engineering, which is defined as an
interdisciplinary scientific approach, whose purpose is to successfully formalize and to
understand the design of complex systems. A few years ago the complexity of the
systems has brought this new discipline that allowed better project management. Today
the complexity is such that sought to automate some phases of the product development
life cycle to significantly improve the time to market and thus reduce development costs.
The increasing functionalities supported by systems today justify the implementation of
verification and validation processes, as early as possible in the product development
cycle. The Validation and Verification (V&V) process is intended to ensure the earliest
possible that systems and products comply with the requirements and meet the expected
designs characteristics. This study aims to improve the V&V process by automating a
part of this cycle. This work is done under a model driven engineering (MDE)
framework, a recent branch of software engineering that has found its place in an industry
where hardware and software components reuse is commonplace (new car is 85% an old
car).
1.2. Objective
MDE allows reusing models of formalisms called meta-models, which are adaptable to
all platforms. Some organizations are interested in MDE and seek to standardize its
concepts: this is the case of the OMG (Object Management Group), the organization
behind the UML modeling language standard. This language is not formal, it is therefore
impossible to establish evidence on the correlation between the proposed solution and the
9
one that has been developed. This is why we are interested here in the transformation of
the UML and more particularly activity diagrams to a formal language, Petri networks.
In this light, we will try to establish the concepts needed for automatic transformation
from activity diagrams into Petri nets, in compliance with the specification defined by the
OMG, and formally verify the model generated by this transformation before using the
verification results to correct the UML activity diagrams and to make sure that the model
is correct in accordance with the initial requirements.
1.3. Structure of the document
This study will present in the second part the context and the tools, the languages used
and the approaches of model driven engineering and Meta-modeling. The third part will
deal with the development of the two meta-models: activity diagrams and Petri networks,
prior to establishing links at the model level between the main elements of the activity
diagrams and Petri nets. Part four will address all of the implementation of the
transformation of models following the concepts of the MDE before finishing with an
example case study, a vending machine system that will show the possibilities provided
by the solution proposed in this project.
10
2. Background
2.1. Model Driven Engineering
The abstraction from reality to be able to represent objects, concepts or problems is a
process that humans use naturally in everyday life. For example, if we ask someone to
represent an aircraft, he/she will draw more often a fuselage, wings etc. In fact, he/she
will describe his/her own abstraction of a plane, in other words its model. In engineering,
the models have always held an important place since ancient times. [10] noted that
Vitruvius, a Roman engineer of the first century BC discussed already the effectiveness
of models in his engineering manual. Today in computer science, the discipline mainly
associated with the modeling process is called model driven engineering (MDE). It
includes all the techniques of representing elements and concepts of reality in the form of
models. But it also includes the methods and tools for reasoning about these models.
2.1.1. The model concept
2.1.1.1. What is a model?
The model concept is central to MDE. Its definition varies according to the members of
the computer science community. Lets consider the definition in [11]: "A model is a
simplification of a system built with an intended goal in mind [...]. The model should be
able to answer questions in place of the actual system". This definition draws attention on
the purpose of the model and its ability to override the real system to be able to reason
about it. The definition given in [12], "A model is a representation in a certain medium of
something in the same or other medium. The model captures the important aspects of the
thing being modeled from a certain point of view and simplifies or omits the rest. ",
11
emphasizes the nature of the model and on the highlighting of aspects of the real system
and on simplification of the rest. In this project, we consider the following definition of a
model that unites the two previous ones: "a model is a partial representation of a real
system according a certain point of view. It allows abstracting this system to meet a given
problem".
Beyond this definition, a model is expressed using a modeling language. This language is
composed of syntax and semantics. The syntax corresponds to the representation of the
different concepts and elements of the language. These elements are visible and
exploitable by the user. In addition, the semantics is the meaning of each of these
elements or concepts. [12] Describes a model as directly consisting of semantics and
notation. Thus a modeling language is broken down to a concrete syntax, which is
manipulated by the user, and an abstract syntax, which is the syntax handled by the
machine and purified from user friendly syntactic add-ons. In addition, there is a
semantic domain that represents the set of reachable States of the system (i.e. all the
concepts expressible with this language) and the semantics of the language corresponds
to the relationship between the elements of the abstract syntax and the semantic domain.
The work of [13] describes a modeling language as syntax, semantic domain and the
semantic links between this syntax and this domain. In this work, we consider the basic
decomposition of a modeling language into syntax and semantics. This definition is
sufficient for the description of our work.
2.1.1.2. Contemplative models vs productive models
Although the modeling principles existed for many years in computer science, the first
approaches were mainly dedicated to human engineering activities, as for example the
12
Merise method [14]. These approaches are based mainly on contemplative models. A
contemplative model is a model readable and an exploitable by a human being.
The use of contemplative models has had a limited impact on software production [15].
The emergence of the MDE offers new ways to consider software development models,
the goal is no longer to see the code as the main element of production but it is the
abstraction by means of models while remaining productive [16]. It is more than a
contemplative model but a productive model. The definition of a productive model is
given by [15]: a productive model is a human-readable and machine exploitable model.
2.1.2. The meta-model concept
2.1.2.1. The meta-modeling logic
So that a model is interpretable and executable by a machine, its modeling language must
be formally defined. In an approach such as MDE, the definition of this language is itself
naturally done using a model. This model is called a meta-model. This concept is defined
in [18] as: "A model that defines the language for expressing a model". However it
should not be assumed that the meta-model represents the semantics of the language. [13]
Recalls that this is a common mistake and that a meta-model describes only the syntax of
the language.
If it is possible to see the meta-model as a model, then this model can have by itself a
meta-model. This meta-model of the meta-model is then named the meta-meta-model.
During the emergence of the concept of modeling with the "everything is model", it was
necessary to establish a theoretical basis for the Meta-modeling to federate the creation of
meta-models [16] and avoid the proliferation of incompatible meta-models.
13
1st level (M0): the system: systems as they exist in the real world. It is
represented by the model defined at the M1 level.
2nd level (M1): the model: a representation of the system in a given modeling
language. It must comply with the meta-model defined in M2.
3rd level (M2): the meta-model: the definition of the modeling language. It shall
conform to the Meta-meta- model defined in M3.
4th level (M3): the meta-meta model: it defines the architecture of the metamodel. It has the property to define itself: it is the element with the highest level
of abstraction. Accordingly, it must be consistent with itself.
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".
They then consider the technical space of models, structured as shown on Figure 2.1. And
then give as an example the technical space of grammars as shown Figure 2.2. In this
technical area, the source code is located at the M1 level and it is the equivalent to a
model in MDE. It is expressed by a programming language grammar at the M2 level, this
grammar being equivalent to a meta-model in MDE. The M3 level contains a grammar
description language, equivalent to a meta-meta-model in MDE.
2.1.2.2. The Model Driven Architecture (MDA), an MDE premise
Although this hierarchical structure is not unique to the MDE, the latter however was
marked by an approach based on this type of structures. In 2000, [21] explained that the
15
16
Thus, its four levels architecture is based on a meta-meta-model named Meta Object
Facility (MOF) [18], which is a standard for Meta-modeling. The MDA approach is also
based on the Unified Modeling Language (UML) [22], whose meta-model is based on the
MOF, in order to express platform independent software models such as design patterns
and platform dependent components of the software, that is to say of the source coderelated models. The final version of this approach was published in 2003 [23]. It is still
evolving and there are many success stories of its application in the industry [24].
2.1.3.
Why do we model?
From a user point of view, the need for models can occur for several reasons. We
distinguish three.
2.1.3.1. The mastery of complexity
The increase in systems complexity in recent years is a reality. For example, in the field
of Aeronautics, [25] explains that the control system of the Airbus A310 in 1980 was 4
MB of codes and relied on 77 calculators and 136 digital buses. In comparison with 1990,
the Airbus A340 control system was 20 MB of code and relied on 115 calculators and
368 digital buses. For the control system of the A380 in 2005 the code would be
hundreds of MBs [26]. Thus, we can observe an approximate 2500% increase of the size
of their avionics code over these last 30 years. In order to master this complexity, it is
necessary to abstract and represent the system in a form different and adapted to the
features which the user wants to embed on the system.
17
The model-to-text transformation. First, it allows code generation. The same model
will thus allow generating code in different languages following transformations. It
also allows tests generation from a model [30]. Finally, this type of transformation
allows the generation of documents. It is indeed necessary in certain software
18
Modeling languages
The popularity of the MDE approach resulted in the proliferation of modeling languages,
each offering means to adapt to specific needs or specific areas.
2.1.4.1. UML
The UML standard is a modeling language defined by the Object Management Group. It
is a standard widely used in the software industry. It is based on the MOF meta-metamodel discussed previously and it represents the modeling language which the MDA
approach depends on.
UML aims to represent the behavior, architecture, data structures and the structure itself
of an application. These different representations are based on different diagrams, each
offering to represent the system according to a particular point of view. UML offers
thirteen different diagrams divided into three categories. The first category includes
structural diagrams with the class diagram, object diagram, component diagram,
composite structure diagram, package diagram and the deployment diagram. The second
category concerns behavioral diagrams with the activity diagram, the state machine
diagram and use case diagram. The last category comprises interaction diagrams with the
sequence diagram, communication diagram, timing diagram, and collaboration diagram.
19
Of course, it is not required to use all these diagrams in software development but only
those necessary for the development of the application. The meta-model of each of these
types of models is described in [22], the semantics is described in natural language and a
constraints language called OCL [34] which itself is a standard defined by the OMG and
applied to the UML standard.
Another ability of UML is the possibility to formally extend the language through its
mechanism for extension by profile. Thus, the user is free to create his own extension of
the language that corresponds to his needs. For example, the UML MARTE profile is a
standard specified by the OMG for embedded real-time systems modeling [35]. It
specifies concepts to characterize UML elements to represent the concepts of time,
concurrency, platform hardware and software, resources and quantitative characteristics
of a system, such as the execution time. It is organized hierarchically in the form of
packages, each comprising a particular aspect of the development of embedded real-time
software. We distinguish mainly packages dedicated to the design of the system and
others dedicated to analysis and verification. The specifics for the design include
modeling the temporal mechanisms, resources, components and their means of
communication. Packages dedicated to analysis and verification to annotate models and
to conduct analyses of schedulability and performance. The profile also provides the
ability to specify non-functional properties of the system.
2.1.4.2. SysML
The SysML standard [36] is a modeling language defined by the OMG. It is a
standardized UML profile in the form of an extension of an UML subset. Given the
success of UML, SysML purposes to do more than confine itself to the computer world
20
but it proposes a usable modeling language to describe any system or software. The
SysML standard includes specification, analysis, design and testing activities of systems
and systems of systems development.
The language is based on some UML diagrams and also adds new ones. The block
diagram replaces the class diagram and thereby it no longer represents software classes,
but items such as hardware, software, or other elements of a system. A requirement
diagram is also added to make the link between the modeled elements and the
requirements. The parametric diagram will represent constraints on elements of the
system such as performance or reliability constraints. This type of diagram is going to be
particularly useful in the context of models analysis.
Based on UML, SysML also offers a profile extension mechanism. AVATAR is a
SysML Profile [37] and which is an example of specialization to the embedded domain,
offering solutions for modeling and formal verification of real-time embedded systems. It
can support upstream activities of a development lifecycle, based on a subset of the
SysML language and stereotypes applied to the diagrams elements. It includes solutions
for the collection of requirements, system analysis, modeling and the expression of safety
and security properties.
2.1.4.3. Simulink
Simulink [38] is the modeling language from the Simulink modeling environment
developed by the MathWorks Company. It is a graphical language to represent the
functional model of a system using blocks and signals. The blocks are connected by
signals and each block represents a particular signal processing. A library of blocks is
21
available in the environment and will provide blocks for dynamic, algorithmic or
structural data processing. The signals in the model will carry data or events.
The use of Simulink models is mainly dedicated to the modeling of discrete and
continuous systems such as communication and signal processing systems.
2.1.4.4. Other modeling languages
Many other modeling languages exist but it would be futile to give an exhaustive list. We
may, however, cite some other standards.
From an architectural point of view, the AADL language [39] is a standard defined by
SAE for modeling and analysis of systems architecture. It is mainly used for modeling
embedded systems.
For processes representation, the BPMN standard [40] is a modeling language for the
representation of business processes and it is defined by the OMG. Examples include
also, the SDL language which allows modeling of telecommunication systems. It is
defined as a standard by the ITU.
2.1.4.5. Domain Specific languages (DSL)
Although standards have been defined, it is sometimes necessary to define a language
dedicated to our own specific needs. We have seen that the UML standard had an
extension system to meet such a need. In MDE, it also possible for each user to define his
own modeling language. These domain-specific languages, or more simply DSL, are
generally smaller, simpler to understand and easier to handle than generic standards such
as UML. They are also more expressive because of their domain specialization. In
addition, the use of a meta-meta-model standard such as the MOF in the context of the
22
definition of these modeling languages will also allow the definition of transformations
between models from different DSLs and thereby multiply the usage scenarios of these
DSLs. The definition and use of these DSLs can then be seen as the most direct
application of the MDE approach.
There are languages and tools enabling the creation of DSLs. For example, the Ecore
Meta-modeling language is available through the Eclipse EMF tool [41] and which
allows the definition of DSLs. The tool then offers means to manage and manipulate
these Ecore-based DSLs.
2.1.5. MDE integration in software development life cycle
In the industry, the development of software is mainly based on three constraints: the
delivery deadline, the product cost and the product quality. The issue of development
therefore is to produce a usable and a good enough system respecting costs and time
constraints [43], bearing in mind that it would probably take an infinite time to build a
perfect system. Software engineering defines engineering good practices or "rules of
thumb" to produce software systems. In this context, it describes the various stages that a
development process must follow to produce software. There are different software
development processes. The different stages of development are similar but the number
of iterations on certain steps or the links between them are likely to vary. For example,
Figure 2.3 represents one of the classical software development processes: the V-model.
It is composed of the most representative phases of software development: requirements
specification, software design, software implementation and testing phases (unit,
integration and system testing phases).
23
We have seen in section 2.1.3 that the MDE offers a number of activities to meet current
needs in terms of software development. Each of its activities can be integrated in the
steps of a development process. In the following paragraphs, we give an overview of
opportunities for each stage of the process as well as a sample industrial case on the gains
in productivity and quality brought by the use of MDE during software development.
2.1.5.1. Design and specification phase
The specification and design phases allow the definition and considerations of the
requirements for the creation of the expected product. In this context, the need of
complexity control, communication or formalization of ideas can be satisfied through the
use of models. Furthermore, the use of models will also offer other opportunities for these
phases of the development process. As explained in [43], each phase of the development
process involves the creation of artifacts, or what we call deliverables. For example, in
aeronautics, the DO-178C standard requires for each phase of the process, a number of
documents to be provided to the authorities in the context of the software certification.
24
Thanks to model transformations, MDE will allow the automatic generation of some of
these deliverables such as for example the generation of documentation as described in
Section 2.1.3.
The possibility of working with formal models at the level of the specification and design
phases will also allow performing and automating another important task: V&V. This
activity is the most important phase, [10] explains that it is crucial to provide verification
and tests as early as possible in the development cycle such that fundamental decisions
regarding the software design can be made.
In the literature, many works exist on the verification of models. For example, if we take
only models based on the UML standard, [45, 46, 47] proposed approaches to verify
UML models with the help of properties expressed as OCL constraints. The approach
which is presented in [45] relies on the use of the UML2Alloy tool, which implements a
transformation of the specification in UML and OCL constraints to a specification in
Alloy [48], in order to carry out their verification using the solver Alloy Analyzer. The
Alloy language is a modeling language for software design, based on first-order logic. In
comparison, the method presented in [47] is based on the transformation of UML class
diagrams and OCL constraints into Constraint Satisfaction Problem (CSP). The CSP
problem can then be solved using a Solver. This work includes the implementation of a
prototype, named UMLtoCSP, automating the transformation and the link to the
ECLiPSe Solver [49]. Verification of UML models presented in [45] relies on the
transformation of a UML class diagrams and OCL constraints to a SAT problem. The
SAT problem is then solved using the MiniSat Solver.
25
Finally more recent work are more limited to verify a model specification or design
phases, but tend to generate models based on a set of input requirements. For example,
[51, 52] proposed approaches to generate optimal and complete models from partial
models and constraints. Similar to the previously described approaches, these works are
based on transformations techniques that map models to constraints satisfaction
problems.
2.1.5.2. Implementation phase
The use of models in the upstream phases will allow the use of code generation
approaches for the implementation phase. It will be possible, from a model to partially or
completely generate the desired source code. This code generation offers several
advantages. According to [43], this technique allows flexibility to the evolution of
modeling languages: If the modeling language is changed, we just update the
transformations of models to code. This technique also allows staying flexible given the
diversity of target systems and platforms: as seen in 2.1.3 the same model can be used to
generate code in different languages depending on the model transformation.
Existing code generators, include the GeneAuto generator [53] that can automatically
generate C code given a Simulink model. This tool is a European project based on a
collaboration of academic actors such as IRIT and INRIA and manufacturers such as
Airbus, Thales and Continental. We should also mention generators present in the
SCADE Suite tool that allow generating C or Ada code from a Scade model. The C code
generator is qualified: the generated code needs no longer to be tested (correct by
construction); the generator ensures that it matches the input pattern, which is formally
verified. More recently, the P34 research project aims the creation of an open-source
26
code generator for embedded real time systems. It is designed to take UML, SysML or
Simulink models as input and generate C/C++ or Ada code.
2.1.5.3. Testing phase
The testing phases goal is to verify that the system produced has the expected behavior.
As [43] explains, this behavior is more often described in a specification document and
the system under test is most often an implementation. In the context of an MDE
approach, the specification document is expressed by models, so it is then possible to
automatically generate tests from the specification's model.
[43] Also refers to the model-based testing technique that uses a specification model,
describing the expected behavior of the implementation of the system, to generate the
tests. These tests consist of test cases, each representing a possible execution among all
the paths described in the specification's model. Test generation is then used to generate a
set of test cases that meet a goal of coverage of the specification's model. [54] Explains
that these test cases are first generated in the form of "abstract" test cases from the model.
An 'abstract' test case is a test case which is not directly executable. For example, an
abstract test case could be expressed in a UML sequence diagram. From these abstract
test cases it is then possible to generate executable test cases on the implementation of the
target system. [54] Gives an example of this type of generation from UML diagrams to
implementations in Java.
2.1.5.4. Industrial use
Theoretically switching to an MDE approach as part of a development process is
expected to bring gains, both at the level of productivity and product quality. However, it
27
is justified to ask if the industrial use of this approach actually keeps its promises. [55]
Describes a study carried out on about 20 articles on the feedback from the use of the
MDE in industrial case studies between 2000 and 2007. Here we revisit some results of
this study.
[55] First exposes the productivity gains made by the MDE from the work done by
Motorola [56, 57] in the context of development of telecommunication system. The MDE
is applied from the specification phase down to the code and tests generation. For
example, in [56], the authors estimate that productivity has increased between 2 and 8
times for the production of lines of code compared to the classical approach of handcoding. In [57], the authors explain that for a testing phase, that includes a model
correction step, a step for creating test cases, a corrected code generation step and a step
of regression testing, the duration of this cycle, measured for four versions of different
networks functions, was reduced from about 25-75 days to 24 hours. In another example
[58], The Middleware Company has completed a comparative study on 2 teams
developing the same application, one using MDE through the MDA and the other not.
The studies showed that the team using MDE was able to develop the application 35%
faster than the other team.
Regarding the quality gain, [55] explained that few quantitative data exist in the
literature. However, it presents the article [56] where the authors could observe an error
reduction of 1, 2 to 4 times during their experiments with the use of the MDE. They also
noted that most errors are found much earlier in the development process, resulting in a
decrease in debugging costs.
28
The limited numbers of available experiences feedback, quantitative data or just results
on the implementation failures of MDE make the results of the study of [55] insignificant
and do not give a generalizable view of the approach but they nevertheless provide an
overview of the possibilities and the gains brought by the MDE.
2.1.6. Tools to apply MDE
In order to offer MDE activities support tools, platforms integrating these activities and
their automations have emerged. Here is an overview.
2.1.6.1. Eclipse Modeling Project
Eclipse Modeling Project [59] is an Eclipse project that aims to promote MDE activities
in Eclipse environment. Specifically, it includes a set of unified tools for DSL modeling
and the standards implementation for the Eclipse community.
This project is organized into several sub-projects, each supporting a specific activity of
the MDE. First of all, it offers tools for the development of DSL abstract syntaxes. The
goal is to allow editing, checking and querying models. These activities are supported by
the Eclipse EMF subproject. The Eclipse Modeling Project then provides tools for the
development of DSL concrete syntaxes. The tool allows the creation of a textual or
graphical concrete syntax, from an abstract syntax. The Eclipse GMP (an EMF
subproject) [60] allows the creation of graphical editors and the Eclipse TMF [61] (an
EMF subproject) allows the creation of text editors. The Eclipse Modeling Project also
offers a set of tools for model transformation through Eclipse MMT [62] and Eclipse
M2T [63] tools. Finally, a set of modeling standards, such as UML and BPMN, are
implemented in Eclipse MDT [64]. These implementations are compatible with Eclipse
technologies, allowing the use of different existing MDE tools on the platform.
29
The Eclipse tool use is widespread in industrial environment which allows the Eclipse
Modeling project to take advantage of a very large community.
2.1.6.2. TOPCASED
Topcased [65] (Toolkit in Open Source for Critical Applications & Systems
Development) is an open source software framework to support MDE activities for the
development of critical systems. It was initiated in 2004 by the CNRT-AE and was
supported by more than thirty academic and industrial partners including Airbus, Thales
and ONERA.
It comes in the form of an Eclipse Rich Client Platform (RCP) and thus has a modular
architecture that allows it to gather a great number of tools. It is based particularly on
technologies derived from the Eclipse Modeling Project. This architecture promotes also
custom features and tools creation and addition in the form of Eclipse plugins.
Furthermore, the Eclipse technology, which is based on the Java language, also provides
its wide portability. The main advantage of Topcased is to provide, in the same
environment and for the community of critical systems, tools for modeling, requirements
traceability,
models
simulation,
models
verification,
models
transformation,
30
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.
UML allows representing graphically the dynamic aspects of systems using several
behavioral diagrams. Among these, there is the activity diagram that focuses on
processing. They are used to represent the behavior of a method or a use case processing
steps. [22]
An activity diagram is a variant of States-transitions diagrams, in which the States
correspond to the execution of actions or activities, and transitions are automatic (the
transitions are triggered by the end of activities and cause the immediate beginning of
another). An activity diagram can be attached to any modeling element in order to
visualize, specify, construct or document the behavior of this element [22].
UML activity diagrams are a tool for modeling systems workflows, service-oriented
models and business processes (they show the sequence of activities that contribute to the
process). An activity model consists of data and control flow related activities. An
activity can vary from a human task to a fully automated task.
The main difference between interaction diagrams and activity diagrams is that the first
tend to model control the flow between objects, while the latter are used to model the
control flow between activities.
2.2.1. Activity diagrams usage
Graphically represent the internal behavior of an operation, a class or a use case in
the form of a sequence of actions.
32
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]
33
34
2.3.
Petri networks
Petri networks (PN) or place/transition networks are a mathematical formalism. PNs have
a graphical representation and a (mathematical) matrix representation to help modeling in
many engineering fields. Appeared for the first time in the thesis of Carl Adam Petri in
1962, Petri nets have since declined in many classes:
Colored PN
Hierarchical PN
Stochastic PN
Predicate-Transition PN
Temporal PN
Object Oriented PN
Differential predicate-Transition PN
The goal is to apply the formalism of the PNs to different fields and more strictly to
discrete event systems. The possibility of managing complex systems with the PNs
doesnt need to be further proven, [107, 108]. A further study of PN will be presented
when extracting the meta-model.
2.4.
Verification and validation techniques are means that allow you to verify, to a certain
extent, that the code meets a specification. The aim is to increase the confidence that we
have on the developed system, which translates in practice by different approaches.
35
structure [80] or in petri nets [81] which describes what are the possible States of the
system, its evolutions (transitions between States) and atomic properties that checks each
state. More complex properties are given in temporal logic [82, 83] that allows
expressing causality relationships between the states. Model checking explores the entire
system states, making it a formal verification technique: all possible executions of the
system are considered. In addition, aside from the modeling of the system and the
expression of its specification, model checking is a fully automatic technique making it
widely used in industry today [84, 85]. However, combining systems multiplies their
states. A phenomenon of combinatorial explosion appears on large systems of many
subsystems. Model checking of such systems may then suffer more time or space
complexity. In recent years, the main work in model checking try to reduce this problem
by offering for example symbolic methods [86] with more compact representations for
states and atomic propositions, e.g. Binary Decision Diagram [87]. Many tools used in
the industry implement this technology and its derivatives (e.g. VMS [88], TINA and
SPIN [89] [90]).
2.4.3. Abstract interpretation
Abstract interpretation [91, 92] is a theoretical framework that provides definitions and
criteria to simplify or abstract an object while ensuring that abstraction is correct to a
class of properties: a property of this class unmet by the abstraction is not satisfied by the
original object. It relies on theories of fixpoint and approximations which reduce
computations that could potentially be infinitely long. In computer science, this translates
into tools [93] which calculate in finite time a superset of the behavior of a program,
while an exact computation of the behavior problem is untractable. The verification of a
37
property from behavior abstraction of the program may give three verdicts: Yes the
property is verified, no it is not or maybe but the abstraction does not verify it. In the
latter case, one speaks of false alarm when the property is effectively verified by the
program but the abstraction is unable to do so because of the approximations. The
challenge of an abstract interpreter is to find the right balance between accuracy and
computation complexity on one hand, and approximation and computation speed on the
other. More or less complex approaches are developed looking for good compromises
[92, 94, 95].
Figure 2.4: Verification activities and objectives of the DO-178C certification standard [117].
Abstract interpretation is now used successfully in the industry with tools like Astre [96]
that are able to check thousands of critical embedded code lines, but focusing only on
certain types of properties.
38
39
40
2. Object flow edges connect objects nodes to provide inputs to actions. Only
objects and data tokens can pass along object flow edges.
41
42
To begin executing, an action must know when to start and what its inputs are. These
conditions are called control and data, respectively. Figure 3.5 shows control and data
43
flow edges in UML2.0 directed towards an action. Data flow is distinguished from
control by small rectangles on the action to show the type of data flowing into the action.
These are called pins. An action may have sets of incoming and outgoing activity edges
that specify control flow and data flow from and to other nodes. An action will not begin
execution until all of its input conditions are satisfied. The completion of the execution of
an action may enable the execution of a set of successor nodes and actions that take their
inputs from the outputs of the action.
An action that has control and data outputs is notated in the same way as inputs, except
the flow arrows point in the other direction. An action terminates based on conditions
internal to itself, but when the action does terminate, data is posted to its output pins, and
control values are placed on all its outgoing control flows. An action that has no control
or data outputs can still terminate, but its termination cannot cause other actions to start
[4].
44
Initial Node
Initial nodes are used to show the start of an activity. They receive control when an
activity is started and pass it immediately along their outgoing edges. No other behavior
is associated with initial nodes in UML. Initial nodes cannot have edges coming into
them. An activity can contain more than one initial node. If an initial node has more than
one outgoing edge, only one of the edges will receive control, because initial nodes
cannot copy tokens [1].
45
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.
3.1.1.2.3.
Merge Node
Merge nodes are used to bring together multiple flows. All control and data arriving at a
merge node are immediately passed to the edge coming out of the merge. Merge nodes
46
have the same notation as decision nodes, but merges have multiple edges coming in and
one going out.
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.
3.1.1.2.5.
Join Node
Join node is used to synchronize multiple flows. Control or data must be available on
every incoming edge so that it can be passed to the outgoing edge. Join nodes have the
same notation as fork nodes, but joins have multiple edges coming in and one going out.
47
Flows coming into a join are usually concurrent flows from an upstream fork. Join nodes
take one token from each of the incoming edges and combine them according to these
rules:
1. If all the incoming tokens are control, then these are combined into a single
control token for the outgoing edge [5].
2. If some of the incoming tokens are control and others are data, then these are
combined to provide only the data tokens to the outgoing edge. The control
tokens are destroyed [5].
3.1.1.2.6.
Final Node
Flow in an activity ends at final nodes. There are two kinds of final nodes in UML2.0
activity diagrams
a) Flow Final: Each flow can have its own flow final. Final nodes cannot have
outgoing edges so there is no downstream effect of tokens going into a node,
which are simply destroyed. Activities terminate when all tokens in the graph
are destroyed, so the activity shown in Figure 3.13 will terminate when both
flows reach the flow final.
48
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.
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].
50
3.1.1.4.1.
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.
3.1.1.4.2.
Pins
Pins provide values to actions and accept result values from them and are connected as
inputs and outputs to actions. An example of input pins is shown in Figure 3.18, in two of
the notational forms. Whichever input value reaches a pin first is held there until the other
arrives. When both pins have a value, the values are passed into the action and it starts.
51
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.
A parameter node or pin may have multiple edges coming out of it, whereupon there will
be competition for its tokens, because object nodes cannot duplicate tokens like forks.
For example, Figure 3.20 shows parts being made, then painted at one of two stations, but
not both.
52
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.
3.1.1.4.4.
Data Store
A data store node is for non-transient information. UML2.0 data store nodes are an
attempt to support the earlier form of data flow and storage by providing a non-depleting
specialization of object node. Tokens flowing out of data store nodes are copies of tokens
that remain in the data store node. Tokens in a data store node cannot be removed, though
53
values do not remain in the store after the containing activity is terminated, and a token
arriving at a store that already has another token for the same object replaces that token.
3.1.1.4.5.
Partitions
Partitions are used to indicate what or who is responsible for actions grouped by the
partition. The term responsible has a wide variety of a meaning, but the one defined by
UML is that software class/component supports the behavior invoked by actions in the
partition. Partitions often correspond to organizational units in a business model. An
activity diagram may be divided visually into Partitions each separated from neighboring
Partitions by vertical solid lines on both sides. Partitions do not have execution
semantics. Partitions do not affect the token flow of the model. In UML2.0 the partitions
can be hierarchical.
3.1.1.5. Usage of Activity Diagrams
Like any other diagrams in UML, activity diagrams have also strengths and weaknesses.
The strength of activity diagrams lies on their ability to support parallel behavior, but
their great disadvantage is that they do not make clear the links between actions and
54
components, which are visualized better using interaction diagrams or state diagrams.
However they are suitable mostly when we deal with the following situations:
3.1.1.5.1.
Modeling an operation
Activity diagrams can be used to model an operation associated with a use case or a class.
In this case we are only interested in understanding what actions need to take place and
what the behavioral dependencies are. Using an activity diagram to model an operation is
simply like using it as a flowchart that supports concurrencies among threads in an
operation.
3.1.1.5.2.
Modeling a workflow
Activity diagrams are best suited to model workflows across use cases that involve many
actors or business organizations. In this case we focus on activities as seen by the actors
that collaborate with the system.
55
56
Petri nets are a formal language for describing and studying systems that are
characterized as concurrent, asynchronous, distributed, parallel, nondeterministic, and/or
stochastic. As a graphical tool, Petri nets can be used as a visual communication aid
similar to flow charts, block diagrams, etc. In addition, tokens are used in these nets to
simulate the dynamic and concurrent activities of systems. The use of Petri Nets leads to
a mathematical description of the system structure that can then be investigated
analytically. It is possible to set up state equations, algebraic equations, and other
mathematical models governing the behavior of systems. Timed Petri nets can be used for
studying the performance and dependability issues of systems. Petri nets can be used for
analyzing properties like reachability, boundedness, liveness, persistence, fairness etc [8].
3.1.2.2. Petri Nets metamodel
A simple Petri net is a set of places and transitions interconnected by directed arcs (an arc
goes from a place to a transition or from a transition to a place). These concepts like Petri
Net, Place, Transition and Arc have been used to define a Petri Net metamodel.
57
A Petri Net is composed of Transitions, Places, input and output arcs. Places can be
interface places or internal places of a Petri Net. The interface places are for Starting and
Ending a Petri Net. If a Transition represents a complex operation and needs to be
represented with more details, it can be represented as a Petri Net.
58
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.
60
Only ControlFlow and ObjectFlow artifacts use an Arc-Place-Arc diagram to connect the
blocks between them. This solution is simpler because it yields a reasonably simple Petri
networks that comply with the semantics of the ADs.
3.2.2.3. Activity diagram artifacts to Petri nets blocks
This paragraph will establish the concepts of transformation between the Atomic entities
of activity diagrams (nodes/arcs) and equivalent PN blocks. These blocks should respect
the (semantic) behavior of UML2 activity diagram advocated by the OMG [22].
At first glance, a Petri net may seem close to an activity diagram. Their graphic
representations and behavior (flow of tokens in the 'network', composition of graphs:
node, arc) can give an impression of having two very similar modeling techniques. The
following paragraphs show the non-apparent complexity of the semantics of the activity
diagrams and the transformation patterns.
3.2.2.3.1.
OMG specification: An initial node is a control node that is activated when the activity
is invoked.
OMG specification property:
-Tokens in an initial node are available to all outgoing arcs.
-If an activity has multiple initial nodes, each of them is activating their respective
control flows (implicit fork).
Solution:
61
3.2.2.3.2.
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.
3.2.2.3.3.
OMG specification: A flow final node is an end node that terminates a flow.
62
OMG specification property: The flow final node destroys tokens that reach the node.
Solution:
-A transition for each arc entering the FlowFinalNode.
3.2.2.3.4.
OMG specification: A join node is a control node that synchronizes multiple streams.
OMG specification property:
-If all available input tokens are control tokens, then a control token is provided as
output.
-If some of these input tokens are control tokens and others are data tokens, only
data tokens are provided as output. Tokens are available in the same order they
arrived.
Solution:
-Creation of a transition that has the same synchronization properties in the PN.
-The arrival management (buffers) will be not modeled by the generated PN.
63
3.2.2.3.5.
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.
3.2.2.3.6.
OMG specification: A decision node is a control node that chooses between outgoing
flows.
OMG specification property:
64
3.2.2.3.7.
OMG specification: A merge node is a control node that brings together streams/flows.
It is not used to synchronize concurrent flows, but to accept one among several.
OMG specification property:
-All incoming tokens are distributed in the output. There is no flow
synchronization or aggregations of tokens.
Solution:
- A place that directly receives a single token from incoming flows.
65
3.2.2.3.8.
-the execution of an action is fired when all the conditions on the objects flow and
control flow have been met (implicit join).
-At the end of the action all outgoing arcs receive a token (implicit fork).
-If multiple control tokens are available on a single incoming ControlFlow, they
are all consumed.
Solution:
- Creation of an input place and an output place for the management of the
implicit JoinNode and ForkNode.
66
- The last property is moved with the ControlFlow so that it does not store the
tokens but to work as information routing buffers: presence or not of a token.
3.2.2.3.9.
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).
3.2.2.3.10.
67
3.2.2.3.11.
OMG specification: An input pin is a pin that holds the input values to be consumed by
an action.
OMG specification property:
68
-An action cannot begin execution if an input pin has fewer values than the lower
multiplicity.
-The upper multiplicity determines the maximum number of values that can be
consumed by a single execution of the action.
Solution:
-Creation of a buffer that allows the management of the update of the data. The
presence of a single data is taken into account.
3.2.2.3.12.
OMG specification: An output pin is a pin that holds the output values produced by an
action.
OMG specification property:
-For each execution, an action cannot complete when there are at least as many
values on its output pins required by the lower multiplicity of these pins.
-The values are actually issued once the action is complete.
-An action cannot put more values in an output pin during a single execution than
the upper multiplicity of the pin.
69
Solution:
-The solutions are equivalent to that implemented for input pins.
3.2.2.3.13.
OMG specification: ActivityParameterNode are object nodes flow start and flow end
that provide the inputs and outputs to an activity through the parameters of an activity.
OMG specification property:
-In the course of the execution of the activity, tokens can flow into the activity in
the activity parameter nodes.
-When the activity execution is complete, the output values held by these return
ActivityParemeterNode shall be issued.
Solution:
-Creation of a communication place between the InputPin and the Activity of
lower level, all properties being redundant with pin nodes, they are carried over to
the corresponding Pin.
70
3.2.2.3.14.
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.
71
3.2.2.3.15.
The list of mappings defined here allows building relatively complex activity diagrams.
However the formalism of activity diagrams is rich, a total transformation of the UML2
activity diagrams to Petri networks would require substantial work without however to be
a major technical problem. This mapping has been carried out and validated by
verification through the LoLa model checker [9].
72
73
74
Our program is composed of rules that specify how the elements of the target model must
be created on the basis of the elements present in the source model. These rules are
always established according to the uml structure:
4.2.1.2. Transformation implementation
The transformation of the activity diagram is done through an xml parser (JDOM) and
java language. This transformation is done in two steps: first an auxiliary activity graph is
created which will hold the representation of the diagram elements in objects stored in the
main memory. This graph-diagram will serve as a traceability model for the generation of
the error trace in the initial input diagram. And it will also simplify the generation of the
75
LoLa petri-net files by storing the connections between the different nodes of the
diagram.
The files representing an input model for the LoLa model-checker have the following
EBNF grammar:
net ::= PLACE place_lists MARKING marking_list? ; transition+
place_lists ::= ( capacity? place_list ; )+
capacity ::= SAFE NUMBER? :
place_list ::= nodeident ( , nodeident )*
nodeident ::= IDENTIFIER | NUMBER
marking_list ::= marking ( , marking )*
marking ::= nodeident ( : NUMBER )?
transition ::= TRANSITION nodeident fairness?
CONSUME arc_list? ; PRODUCE arc_list? ;
fairness ::= ( STRONG | WEAK ) FAIR
arc_list ::= arc ( , arc )*
arc ::= nodeident ( : NUMBER )?
An example of the petri-net LoLa file of the vending-machine case is given in appendix
A to illustrate a file produced by this grammar.
Validation of a transformation composed of few PN nodes is trivial; however the
complexity of the systems to model today brings large PNs (hundreds of
places/arcs/transitions). You can see the result of the transformation of a complex activity
diagram (tens of activity diagram elements) figure 4.2. Thats why the automated
generation of networks and formal verification is essential.
76
Simulation.
Tests.
Formal verification.
This section will focus on formal verification based on formal models. Formal
verification is the exploration of all the states of the system to derive properties of
reachability, liveness and safety.
We have chosen to use the model-checking approach, which is suitable for the
verification of PNs [114]. To conduct a formal verification by model-checking, we must:
o Develop a model that describes the behavior of the system, here, its the
resulting PN model from the transformation.
o Express system properties in a formalism as the temporal logic, here CTL.
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.
78
79
property. One technique is to obtain a Bchi automaton that is "equivalent" to the model
and one that is "equivalent" to the negation of the property. The intersection of the two
non-deterministic Bchi automata is empty if the model satisfies the property.
4.2.2.2. State Space Verification with LoLA
LoLA [4] is a tool that decides numerous properties by an inspection of the state space of
a given Petri net. For making state-space inspection feasible, it offers several state-space
reduction techniques.
4.2.2.2.1.
Analyzing soundness
The activity diagrams have to be translated into Petri nets prior to the verification as
shown in 4.1. To verify soundness, LoLA works in two runs on the resulting Petri nets. In
the first run, it checks for local deadlocks and in the second run for lack of
synchronization.
A process has no deadlock iff a final state can be reached from every reachable state; a
state is final iff each token has reached an end node. The latter can easily be expressed as
a state predicate in LoLA. The former can be expressed as a CTL formula over this
predicate and checked by LoLA directly. LoLA checks the property on-the-fly, i.e., while
the state space is being generated. As soon as LoLA detects a violation, it stops and
returns the violating state. Once an error state has been found, a reachability check is
used to produce a trace to the error state.
80
4.2.2.2.2.
Analyzing safeness
LoLA has a switch that causes state-space generation to be stopped if an unsafe state is
generated. A state is unsafe if a single place contains more than one token, which
indicates a lack of synchronization in the original activity diagram. This simultaneous
check for lack of synchronization in the first run prevents that LoLA tries to generate an
infinite state space and also optimizes performance for finite state spaces. If an unsafe
state is found, a trace leading to it is returned immediately. However, the test for unsafe
states cannot detect all lack of synchronization errors. Therefore, if no error has been
detected during the first run, LoLA is invoked a second time on each net, this time
explicitly checking for lack of synchronization.
Lack of synchronization, i.e., unsafeness of states, can be expressed in LoLA as the state
predicate
( )
, where P is the set of places of the Petri net. As this set can
become very large. We can assert by construction for several places in the Petri net that
they cannot obtain more than one token unless a preceding place is also able to do so. In
essence, only places that represent a merge or an exit of a cycle need to be considered.
The resulting state predicate is checked for reachability by LoLA. If the predicate is
81
satisfied, a lack of synchronization is identified and LoLA produces a trace to the error
state.
4.3. Application
To better illustrate the goal of our project we will apply the concepts to a case study, a
vending machine. The latter will be able to only distribute PePsi and Coke sodas. The
machine should allow the user to choose his drink. We designed the corresponding
diagram so that it contains workflow errors, then we analyzed the design using our
methodology to check both deadlock freedom and safeness properties.
Figure 4.5 describes the initial activity diagram that contains workflow errors that must
be, conceptually, revealed by our proposed approach.
The transformation of the diagram is performed by directly processing the .uml file
representing the diagram, by first importing the file into our work space using the
import button of our user interface. After loading the file into the transformation engine
we can transform it using the transform to petri-net button. If the latter is successfully
executed a .lola file describing the generated PN, will be created, figure 4.5.
After transforming and exporting the diagrams we get the PN model shown in figure 4.7.
(A textual representation of the generated petri net for the vending machine case study is
provided in appendix A).
82
83
As already discussed in the previous section, formal verification of a model needs two
inputs:
-
In our case the transition model is a Petri Net generated by the instrumented
transformation from activity diagrams and the temporal property will be given as input by
the user as a CTL formula, and as contribution of this project soundness and safeness
properties can be generated automatically by our tool.
Figure 4.6 shows the user interface of the solution:
Zone 1 in the figure represents the path of the uml file chosen with a file picker when
clicking on the button in zone 2. In order to generate the corresponding LoLa petri-net,
one must click on the button transform to PetriNet represented in zone 3, and then the
result of the transformation will be printed in zone 4, the textual representation of the net
can be converted into a visual diagram using a tool called seda [113].
Now that we have the a transition model, the engineer must supplement a temporal
formula in order to be able to model-check the system, thus two automatically generated
properties of the diagram can be used on the fly, without any technical expertise. To do
that we should first choose the method of supplementing the formula in zone 6 (automatic
or manual for more experienced engineers), by choosing automatic two buttons will be
activated: soundness in zone 8 and safeness in zone 9. Clicking on one of these buttons
will print the generated CTL formula in zone 5 and will invoke the LoLa model-checker
which will generate a JSON file containing the result of the analysis. The content of the
84
resulting JSON file will be printed on zone 11. Its possible the result of the verification
will contain a counter example path if the formula doesnt hold, which will activate the
button generate feedback in order to map the error path to the original umldi file,
clicking on this button will create a file named XXXX_ErrorTrace.umldi in the folder
containing the uml file targeted by the analysis (where XXXX is any arbitrary name).
For some users with background on formal verification and CTL, a method to manually
edit more specific CTL formulas of the model was implemented (zone 6 and 5 of figure
4.6).
85
86
By processing the output generated by the LoLa model-checker we have the diagram in
figure 4.9, which shows the error trace corresponding to the PN nodes that contains
deadlock.
87
The deadlock happens in light of the fact that the vending machine can pick freely of the
user which drink it outputs. If the users and the machines choices are not the same, we
have a deadlock. The issue can be comprehended by making the machines choices
depend on the users data.
88
References
[1] UML, OMG, "2.0 superstructure final adopted specification," in OMG Document
reference ptc/03-08 2, 2003.
[2] C. Bock, "UML 2 activity and action models, Part 2: Actions," in Journal of Object
Technology 2.5, 2003, pp. 41-56.
[3] C. Bock, UML 2 Activity and Action Models, Part 4: Object nodes, in Journal of
Object Technology 3, 2004, pp. 27-41.
[4] C. Bock, UML 2 Activity and Action Models, in Journal of Object Technology 2,
2003, pp. 43-53.
[5] C. Bock, UML 2 Activity and Action Models Part 3: Control Nodes, in Journal of
Object Technology 2, 2003, pp. 7-23.
[6] C. Bock, UML 2 Activity and Action Models Part 5: Partitions, in Journal of Object
Technology 3, 2004, pp. 37-56.
[7] J.L. Garrido and G.Miguel, "A coloured petri net formalisation for a UML-based notation
applied to cooperative system modeling," in Lecture notes in computer science 2545,
2002, pp. 16-28.
[8] W. Reisigs and R.Grzegorz, "Informal introduction to petri nets," in Lectures on Petri
Nets I: Basic Models. Springer Berlin Heidelberg, 1998, pp. 1-11.
[9] LoLa, low level petri net analyzer http://service-technology.org/lola/index.html
[10] B. Selic, "The pragmatics of model-driven development," in IEEE software 5, 2003, pp.
19-25.
[11] J.Bzivin and G.Olivier, "Towards a precise definition of the OMG/MDA framework," in
Automated Software Engineering, 2001.(ASE 2001). Proceedings. 16th Annual
International Conference on. IEEE, 2001.
[12] J. Rumbaugh et al, Unified Modeling Language Reference Manual, Pearson Higher
Education, 2004.
[13] Harel, David, and Hillel Kugler. "The rhapsody semantics of statecharts (or, on the
executable core of the UML)." In Integration of Software Specification Techniques for
Applications in Engineering. Springer Berlin Heidelberg, 2004, pp. 325-354.
[14] H.Tardieu et al, "La mthode MERISE-principes et outils,", 1984.
[15] J.Bzivin et al, "Rapport de Synthse de lAS CNRS sur le MDA (Model Driven
Architecture)." In CNRS, novembre, 2004.
[16] J.Bzivin, "In search of a basic principle for model driven engineering,"in Novatica
Journal, Special Issue 5.2, 2004, pp. 21-24.
[17] V.J.R. Erstellt, How UML2 and MOF relate
http://bluedynamics.com/articles/johannes/how-uml2-and-mof-relate, 2009.
[18] OMG, OMG Meta Object Facility (MOF) specification v2.0,, 2006.
[19] J.M. Favre, "Foundations of Meta-Pyramids: Languages vs. Metamodels-Episode II:
Story of Thotus the Baboon1," in Language Engineering for Model-Driven Software
Development 4101, 2004.
[20] C. Atkinson and K.Thomas, "Model-driven development: a metamodeling
foundation," in Software, IEEE 20.5, 2003, pp. 36-41.
[21] R. Soley, "Model driven architecture," in OMG white paper 308.308, 2000.
90
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[38]
[39]
[40]
[41]
[42]
[43]
[44]
91
[68] N.Halbwachs et al, "The synchronous data flow programming language LUSTRE," in
Proceedings of the IEEE 79.9, 1991, pp.1305-1320.
[69] IBM Rational Rhapsody family, http://www-03.ibm.com/software/products/en/ratirhapfami
[70] IBM Rational System Architect, http://www-03.ibm.com/software/products/fr/ratisystarch
[71] Magic draw, www.nomagic.com/products/magicdraw.html
[72] "IEEE standard glossary of software engineering terminology." In Office 121990.1, 1990.
[73] J.M.Glenford, "The art of software testing," in John Wiley and Sons, ISBN10, 1979.
[74] B.Beizer, Software testing techniques in Dreamtech Press, 2003.
[75] B.Marre and A.Agnes, "Test sequences generation from lustre descriptions: Gatel," in
Automated Software Engineering, 2000. Proceedings ASE 2000. The Fifteenth IEEE
International Conference on. IEEE, 2000.
[76] N.Williams et al, "Pathcrawler: Automatic generation of path tests by combining static
and dynamic analysis," in Dependable Computing-EDCC 5. Springer Berlin Heidelberg,
2005, pp.281-292.
[77] E.W.Dijkstra, "Guarded commands, nondeterminacy and formal derivation of
programs," in Communications of the ACM 18.8, 1975, pp. 453-457.
[78] E.M.Clarke and E.E.Allen Design and synthesis of synchronization skeletons using
branching time temporal logic, in Springer Berlin Heidelberg, 1982.
[79] J.P.Queille and S.Joseph, "Specification and verification of concurrent systems in
CESAR," in International Symposium on Programming. Springer Berlin Heidelberg,
1982.
[80] M.C.Browne et al, "Characterizing Kripke structures in temporal logic," in TAPSOFT'87.
Springer Berlin Heidelberg, 1987.
[81] C.Girault and V.Rdiger, Petri nets for systems engineering: a guide to modeling,
verification, and applications, in Springer Science & Business Media, 2013.
[82] A.N.Prior, Past, present and future. Vol. 154, in Oxford: Clarendon Press, 1967.
[83] A.Pnueli, "The temporal logic of programs," in Foundations of Computer Science, 1977.,
18th Annual Symposium on. IEEE, 1977.
[84] T.A.Henzinger et al, "Temporal-safety proofs for systems code," in Computer Aided
Verification. Springer Berlin Heidelberg, 2002.
[85] T.Ball et al, "SLAM and Static Driver Verifier: Technology transfer of formal methods
inside Microsoft," in Integrated formal methods. Springer Berlin Heidelberg, 2004.
[86] K.L.McMillan, Symbolic model checking, in Springer US, 1993.
[87] R.E.Bryant, "Symbolic Boolean manipulation with ordered binary-decision diagrams," in
ACM Computing Surveys (CSUR) 24.3, 1992, pp.293-318.
[88] SMV model checker, http://www.cs.cmu.edu/~modelcheck/smv.html
[89] SPIN model checker, http://spinroot.com/spin/whatispin.html
[90] TINA model checker, http://projects.laas.fr/tina/manuals/selt.html
[91] P.Cousot and C.Radhia, "Abstract interpretation: a unified lattice model for static
analysis of programs by construction or approximation of fixpoints," in Proceedings of
the 4th ACM SIGACT-SIGPLAN symposium on Principles of programming languages.
ACM, 1977.
93
[92] P.Cousot and C.Radhia, "Abstract interpretation frameworks," in Journal of logic and
computation 2.4, 1992, pp.511-547.
[93] H.G.Rice, "Classes of recursively enumerable sets and their decision problems," in
Transactions of the American Mathematical Society, 1953, pp.358-366.
[94] A.Min, "The octagon abstract domain," in Higher-Order and Symbolic
Computation 19.1, 2006, pp.31-100.
[95] L.Chen et al, "A sound floating-point polyhedra abstract domain," Programming
Languages and Systems. Springer Berlin Heidelberg, 2008, pp. 3-18.
[96] B.Blanchet et al, "A static analyzer for large safety-critical software."ACM SIGPLAN
Notices. Vol. 38. No. 5. ACM, 2003.
[97] The Coq proof assistant, https://coq.inria.fr/
[98] Y.Bertot and C.Pierre "Interactive theorem proving and program development: CoqArt:
the calculus of inductive constructions, in Springer Science & Business Media, 2013.
[99] The HOL interactive proof assistant, http://hol.sourceforge.net/
[100] M.Archer, Proceedings of the 1991 International Workshop on the HOL Theorem
Proving System and Its Applications, August 28-30, 1991, Davis, California, in IEEE
Computer Society Press, 1992.
[101] The Isabelle proof assistant, https://www.cl.cam.ac.uk/research/hvg/Isabelle/
[102] J.C.Fillitre and M.Claude, "Multi-prover verification of C programs," in Formal
Methods and Software Engineering. Springer Berlin Heidelberg, 2004, pp.15-29.
[103] M.Claude et al, "The krakatoa tool for certificationof java/javacard programs annotated in
jml," in The Journal of Logic and Algebraic Programming 58.1, 2004, pp.89-106.
[104] C.A.R.Hoare, "An axiomatic basis for computer programming," in Communications of
the ACM 12.10, 1969, pp. 576-580.
[105] The Frama-C analyzer, http://frama-c.com/
[106] Activity Diagrams, http://www.uml-diagrams.org/activity-diagrams.html
[107] A.Semenov et al, "Designing an asynchronous processor using Petri nets," in IEEE
Micro 2, 1997, pp.54-64.
[108] Q.Qiu et al, "Dynamic power management of complex systems using generalized
stochastic Petri nets," in Proceedings of the 37th Annual Design Automation Conference.
ACM, 2000.
[109] F.Jouault and K.Ivan, "Transforming models with ATL," in satellite events at the
MoDELS 2005 Conference. Springer Berlin Heidelberg, 2006.
[110] K.Schmidt, "Lola a low level analyser," in Application and Theory of Petri Nets 2000.
Springer Berlin Heidelberg, 2000, pp. 465-474.
[111] OMG, XML Metadata Interchange (XMI), http://www.omg.org/spec/XMI/.
[112] Omg, Qvt. "Meta object facility (mof) 2.0 query/view/transformation specification," in
Final Adopted Specification November 2005, 2008.
[113] "Seda petri net editor," http://service-technology.org/seda/index.html
[114] S.Hinz et al, Transforming BPEL to Petri nets," in Business Process Management.
Springer Berlin Heidelberg, 2005, pp.220-235.
[115] Computational tree logic, http://resist.isti.cnr.it/free_slides/testing/bowen/w3_l1_ctl.pdf
[116] K.Wolf, "Generating Petri net state spaces," in Petri Nets and Other Models of
ConcurrencyICATPN 2007. Springer Berlin Heidelberg, 2007, pp.29-42.
94
[117] M.Yannick et al, "Testing or Formal Verification: DO-178C Alternatives and Industrial
Experience", IEEE Software, vol.30, no. 3, 2013, pp. 50-57.
[118] L.B.Edmundo, How to create a Petri net editor using GMF (Part 1),, 2014,
http://edmundo.lopezbobeda.net/blog/how-create-petri-net-editor-using-gmf-part-1
[119] Shlaer-Mellor and Executable UML Portal http://ooatool.com/ooa/fUML08/
[120] D.Bisztray et al, "Case study: UML to CSP transformation," in Applications of Graph
Transformation with Industrial Relevance (AGTIVE), 2007.
[121] Y.Dong and S.Zhang, "Using -calculus to formalize uml activity diagram for business
process modeling," in Engineering of Computer-Based Systems, 2003. Proceedings. 10th
IEEE International Conference and Workshop on the IEEE, 2003, pp. 47-54.
[122] H.Strrle and J. H. Hausmann, "semantics of uml 2.0 activities," in Proceedings of the
IEEE Symposium on Visual Languages and Human-Centric Computing, 2004.
95
MARKING
InitialNode1 :
;
TRANSITION ForkNode1
CONSUME
InitialNode1: 1;
PRODUCE
ForkNode1->ForkNode2:
ForkNode1->JoinNode1:
TRANSITION JoinNode1
CONSUME
ForkNode1->JoinNode1:
ForkNode3->JoinNode1:
PRODUCE
JoinNode1->await_coin:
1,
1;
1,
1;
1;
96
TRANSITION await_coin
CONSUME
JoinNode1->await_coin:
PRODUCE
DecisionNode2:
1;
TRANSITION JoinNode3
CONSUME
DecisionNode2:
1,
ForkNode5->JoinNode3:
PRODUCE
JoinNode3->dispose_coke:
TRANSITION dispose_coke
CONSUME
JoinNode3->dispose_coke:
PRODUCE
dispose_coke->ForkNode7:
TRANSITION ForkNode7
CONSUME
dispose_coke->ForkNode7:
PRODUCE
ForkNode7->JoinNode5:
MergeNode1: 1;
TRANSITION JoinNode7
CONSUME
MergeNode1: 1,
JoinNode6->JoinNode7:
PRODUCE
ActivityFinalNode1: 1;
TRANSITION JoinNode5
CONSUME
ForkNode5->JoinNode5:
ForkNode7->JoinNode5:
PRODUCE
JoinNode5->get_coke:
1;
1;
1;
1;
1;
1;
1,
1;
1,
1;
1;
TRANSITION get_coke
97
CONSUME
JoinNode5->get_coke:
PRODUCE
MergeNode2: 1;
TRANSITION JoinNode6
CONSUME
ForkNode3->JoinNode6:
MergeNode2: 1;
PRODUCE
JoinNode6->JoinNode7:
1;
1,
1;
TRANSITION JoinNode2
CONSUME
DecisionNode2:
1,
ForkNode4->JoinNode2:
1;
PRODUCE
JoinNode2->dispose_pepsi: 1;
TRANSITION dispose_pepsi
CONSUME
JoinNode2->dispose_pepsi: 1;
PRODUCE
dispose_pepsi->ForkNode6: 1;
TRANSITION ForkNode6
CONSUME
dispose_pepsi->ForkNode6: 1;
PRODUCE
ForkNode6->JoinNode4:
1,
MergeNode1: 1;
TRANSITION JoinNode4
CONSUME
ForkNode4->JoinNode4:
ForkNode6->JoinNode4:
PRODUCE
JoinNode4->get_pespi:
TRANSITION get_pespi
CONSUME
JoinNode4->get_pespi:
PRODUCE
1,
1;
1;
1;
98
MergeNode2:
1;
TRANSITION ForkNode2
CONSUME
ForkNode1->ForkNode2:
PRODUCE
ForkNode2->insert_coin:
DecisionNode1:
1;
TRANSITION choose_coke
CONSUME
DecisionNode1:
1;
PRODUCE
choose_coke->ForkNode5:
TRANSITION ForkNode5
CONSUME
choose_coke->ForkNode5:
PRODUCE
ForkNode5->JoinNode3:
ForkNode5->JoinNode5:
TRANSITION choose_pepsi
CONSUME
DecisionNode1:
1;
PRODUCE
choose_pepsi->ForkNode4:
TRANSITION ForkNode4
CONSUME
choose_pepsi->ForkNode4:
PRODUCE
ForkNode4->JoinNode2:
ForkNode4->JoinNode4:
TRANSITION insert_coin
CONSUME
ForkNode2->insert_coin:
PRODUCE
insert_coin->ForkNode3:
1;
1,
1;
1;
1,
1;
1;
1;
1,
1;
1;
1;
99
TRANSITION ForkNode3
CONSUME
insert_coin->ForkNode3:
PRODUCE
ForkNode3->JoinNode1:
ForkNode3->JoinNode6:
1;
1,
1;
100
101
102