UNIVERSITY OF ECHAHID HAMMA LAKHDAR EL OUED · Abstract II Abstract FoCaLiZe is an object-oriented development environment which aims to ease software development through a proof-based

Algerian Democratic and Popular Republic

Ministry of Higher Education and Scientific Research

UNIVERSITY OF ECHAHID HAMMA LAKHDAR EL OUED

FACULTY OF SCIENCES END TECHNOLOGY Dissertation

Academic Master

Domain: Mathematics and computer science

Field: Computer Science

Specialty: Distributed system and artificial intelligence

Presented by:

GHENDIR MABROUK Nacira MENACEUR Khadija

Title

Session of Jun 2015

Under the supervision of:

Mr.MESSAOUD Abbas ATA Univ. Hamma Lakhdar Rapporteur

Mr.BERDJOUH Chafik ATA Univ. Hamma Lakhdar Examiner

Mr.BOUCHERIT Amar ATA Univ. Hamma Lakhdar Examiner

University year 2014 – 2015

Automatic transformation tool of

UML class diagrams into FoCaLiZe

N° d’ordre :

N° de série :

I

Acknowledges

We would like to express our sincere and

faithful thanks to professor Messaoud Abbas for his

ideal supervision, sage advices and continuous

encouragement. We would like to thank him deeply

for his great and valuable help without which this

work would not be possible. We would like to thank

those who have devoted their time to help us. As we

would like to present our respect to Mr.Youcef Faizi

and Mr.Sayah Zaoui for all the helps and supports

their offered us. Also we would like to thank our

family and our friends wishing a good luck to them

in their life.

Abstract

II

Abstract

FoCaLiZe is an object-oriented development environment which aims to ease software

development through a proof-based formal approach. On the other hand, the UML graphical

language is widely used to model systems in a synthetic and intuitive way, but lacks formal basis.

In this master thesis we studied the transformation rules of UML models expressed through class

diagrams into FoCaLiZe specifications (MDE), and then we propose an implementation of their

transformation rules. The proposed implementation directly supports most of UML features such as

inheritance, multiple inheritance, dependency, UML templates and template binding. We illustrate

our implementation with concrete examples.

Keywords: UML, FoCaLiZe, Transformation, Modeling, Model Driven Engineering (MDE).

Résumé

III

Résumé

FoCaLiZe est un environnement formel de développement orienté objet, permettent la

réalisation des ’application certifiés. D'autre part, le langage graphique UML est largement utilisé

pour modéliser les systèmes de manière synthétique et intuitive, mais il manque les bases

formelles. Dans ce thèse de master, nous avons étudié les règles de transformation de diagramme

de class UML vers spécifications FoCaLiZe (MDE), à fin de proposer une implémentation pour

ce modèle de transformation. L'implémentation proposée supporte directement la plupart des

fonctionnalités de UML telles que l'héritage, l'héritage multiple, la dépendance, le template UML

et le template binding etc. Nous illustrons notre implémentation par des exemples concrets.

Mots-clés: UML, FoCaLiZe, Transformation, Modélisation, Ingénierie Dirigée par les Modèles

(IDM).

ملخص

IV

ملخص

FoCaLiZe الخصائص عتماد طريقة لإلثباتإبتطوير البرمجيات و تسهيل ى, تهدف إلهكائنية التوج بيئة تطوير برامجهي بيئة

إلعداد تصاميم البرامج بطريقة نطاق واسع ىهي لغة يتم استخدامها عل UML, ى. و من ناحية أخرالمطلوبة لتصميم موحد

المعبر عنها من خالل UML. في هذه المذكرة درسنا قواعد التحويل من نماذج ات و براهين سهلة و بديهية,لكنها تفتقر إلثبات

class diagrams ىإل FoCaLiZe المقترح يدعم بشكل مباشر أغلب اإلنجازقواعد تحويلها. انجاز, و من ثم إقترحنا

inheritance, multiple inheritance, dependency, UML templates , template binding :مثل UMLميزات

.وإستخدمنا من أجل توضيح ذلك أمثلة واقعية

Model Driven Engineering (MDE) ,التحويل, النمذجة,UML ,FoCaLiZe: الكلمات المفتاحية

V

Table of Content Chapter I: Introduction………………………………………………………………………………………………………..10

Chapter II: UML concepts………………………………….................................................................13 2.1 UML Diagrams:............................................................................................................................. 13

2.2 Class diagram ................................................................................................................................ 15

2.2.1 Classes .................................................................................................................................... 16

2.2.2 Attribute (Property) .............................................................................................................. 17

2.2.3 Operations ............................................................................................................................. 19

2.2.4 Inheritance ............................................................................................................................. 20

2.2.5 Dependency ............................................................................................................................ 22

2.2.6 Parameterized class (Class Template) ................................................................................. 23

2.2.7 Associations ........................................................................................................................... 25

Chapter III: FoCaLiZe concepts …………………………………………………...29

3.1 Species ............................................................................................................................................ 29

3.2 Inheritance and late-binding ........................................................................................................ 32

3.3 Collection ....................................................................................................................................... 34

3.4 Parametrization ............................................................................................................................. 35

3.5 Proofs and compilation ................................................................................................................. 36

Chapter IV: From UML to FoCaLiZe………………………………………………………………………40

4.1 Comparison between UML and FoCaLiZe concepts ................................................................. 40

4.2 Transformation rules .................................................................................................................... 41

4.2.1 Transformation of class ........................................................................................................ 41

4.2.1.1 Transformation of attributes ........................................................................................... 41

4.2.2.2 Transformation of operations .......................................................................................... 42

4.2.3 Transformation of dependency relationship ...................................................................... 44

4.2.4 Transformation of inheritance ............................................................................................. 44

4.2.5 Transformation of Parameterized class (Class Template) ................................................ 45

4.2.6 Association transformation .................................................................................................. 46

4.3 Summary of transformation rules ............................................................................................... 47

Chapter V: Implementation…………………………………………………………………………………………….53

VI

5.1 XSLT ...................................................................................................................................... 53

5.2 Implementation process ........................................................................................................ 54

5.2.1 First step: creation of class diagram ................................................................................ 55

5.2.2 Second step: generating the ordered XMI document .................................................... 56

5.2.3 Third step: transformation .............................................................................................. 57

5.3 Case study .............................................................................................................................. 60

Conclusion ......................................................................................................................................... 65

References .......................................................................................................................................... 66

VII

List of Figures

Figure 2. 1: Classifier metamodel ............................................................................................................ 15

Figure 2. 2: Classes metamodel ................................................................................................................ 16

Figure 2. 3: Property metamodel ............................................................................................................. 17

Figure 2. 4: Multiplicity metamodel ........................................................................................................ 18

Figure 2. 5: Operation metamodel........................................................................................................... 19

Figure 2. 6: UML Class with Attributes and operations ....................................................................... 20

Figure 2. 7: Inheritance metamodel ........................................................................................................ 20

Figure 2. 8: Single inheritance ................................................................................................................. 21

Figure 2. 9: Multiple inheritance ............................................................................................................. 21

Figure 2. 10: Dependency metamodel ..................................................................................................... 22

Figure 2. 11: Dependency ......................................................................................................................... 22

Figure 2. 12: Template metamodel .......................................................................................................... 23

Figure 2. 13: Template binding metamodel ............................................................................................ 24

Figure 2. 14: Template and Template binding metamodel ................................................................... 24

Figure 2. 15: Association metamodel....................................................................................................... 25

Figure 2. 16: Association .......................................................................................................................... 27

Figure 3 .1: FoCaLiZe development ........................................................................................................ 29

Figure 5. 1: The sequence diagram of implementation process ............................................................ 54

Figure 5. 2: A UML class diagram ........................................................................................................... 55

Figure 5. 3: Example of XMI format ....................................................................................................... 56

Figure 5. 4: Implementation of the transformation process.................................................................. 59

Figure 5. 5: A UML class diagram ........................................................................................................... 60

Figure 5. 6: Java application interface .................................................................................................... 62

Figure 5. 7: Opening the XML file ........................................................................................................... 63

Figure 5. 8: the transformation of FoCaLiZe code ................................................................................ 63

Figure 5. 9: Compilation of FoCaLiZe source ........................................................................................ 64

VIII

List of Tables

Table2. 1: Multiplicity .............................................................................................................................. 18

Table2. 2: Association Multiplicity .......................................................................................................... 26

Table 3. 1: The general syntax of a species ............................................................................................. 30

Table 3. 2: The species Point .................................................................................................................... 31

Table 3. 3: Example of inheritance .......................................................................................................... 33

Table 3. 4: Example of parameter substitution ...................................................................................... 33

Table 3. 5: Example of Parametrization ................................................................................................. 35

Table 3. 6: Example of a Proof................................................................................................................. 37

Table 4.1: Correspondance between UML and FoCaLiZe concepts.................................................... 41

Table 4.2: UML class transformation ..................................................................................................... 41

Table 4.3: Transformation of a UML class with attributes .................................................................. 42

Table 4.4: Transformation of a UML class with operations ................................................................. 43

Table 4.5: class constractor transformation ........................................................................................... 43

Table 4.6 :Transformation of an enumeration UML class .................................................................... 44

Table 4.7: Transformation dependency of an UML class ..................................................................... 44

Table 4.8: UML inheritance transformation .......................................................................................... 45

Table 4.9 : Templat and template binding transformation ................................................................... 46

Table 4.10: Transformation of UML association ................................................................................... 47

Table 4.11: Summary of transformation rules ....................................................................................... 50

Table 5. 1: The generation of Xml ordered format ................................................................................ 57

Table 5. 2: XSLT stylesheet template ....................................................................................................... 58

Table 5. 3: The XMI format corresponding to the class diagram ......................................................... 62

Chapter I:

Introduction

Chapter 01: Introduction

10

The Unified Modeling Language (UML) [2] is the defecto standard to graphically and

intuitively describe systems in an object oriented way. A UML is defined by Object Management

Group (OMG1) as a modeling standard. Currently, it is supported by a wide variety of tools,

ranging from analysis, testing, and simulation to code generation for example: StarUML,

Enterprise Architect, visual paradigm. Using UML, we can only describe systems, because UML

semantics is still informal and allows ambiguities. No formal verification is available within UML

context to check the consistency of UML models.

In the last few years several approaches have been carried out in order to provide supporting tools

to check the properties of a UML model. Among these approaches, those interested in the

transformation of UML models into formal methods. This transformation enables to derive a

formal specification in the target language [23].

Several works like [3], UML2B [4], UML-B [5], [7], [6] and [8] are based on a translation from

UML into the B language [16] in order to use formal verification available in B. In [10] we find a

framework for formalizing UML models with rCOS (Refinement of Component and Object

Systems) formal tool, [12] propose a transformation from UML into SBVR (Semantics of Business

Vocabulary and Rules) specifications, [13] suggests a translation of UML model into the Maude

system [14], based on rewriting logic. Some other related works like [15] and [9] are interested in

endowing UML with a formal semantics.

In this document, we have studied a transformation from a UML into the FoCaLiZe environment

[17] [24] based on works [22-23], in order to propose an implementation for this transformation.

FoCaLiZe is a development environment which aims to build applications step by step using object

oriented features. Verification FoCaLiZe is based on its automated theorem prover Zenon [20] and

its proof checker Coq [21]. The choice of FoCaLiZe does not solely rely on its formal aspects. In

fact, FoCaLiZe supports most of a UML design features [18-19].

In particular, most of UML conceptual and architectural features like inheritance

(generalization/specialization) and multiple inheritance, function redefinition, late-binding,

dependency, UML template (parametrized classes) and template binding are supported by

FoCaLiZe.

1OMG: Object management group http://www.omg.org/

Chapter 01: Introduction

11

FoCaLiZe is also motivated by the functional aspect of its language. It is based on Ocaml1

language, to avoid any side effects.

To implement the transformation from a UML to FoCaLiZe we have used the XSLT 2(Extensible

Stylesheet Language transformation). We have defined an XSLT stylesheet, which implements the

transformation rules from an XMI document (XML standard format for UML models) into

FoCaLiZe sources.

This document is organized as follows: chapter 2 and 3 present UML and FoCaLiZe concepts. In

chapter 4 we study the transformation rules from UML into FoCaLiZe. Finally, in chapter 5 we

present our implementation process.

2 http://www.w3.org/Style/XSL/translations.html

http://www.w3.org/Style/XSL/translations.html

Chapter II:

Uml concepts

Chapter 02: UML concepts

13

A model construction is the heart of object-oriented problem solving. The model abstracts

the essential details of the underlying problem from its usually complicated real world. Moreover,

a model is a description of (part of) a system written in a well-defined language. A well-defined

language is a language with well-defined form (syntax) and meaning (semantics), which is suitable

for automated interpretation by a computer [1].

In 1996 the three methodologists Grady Booch, Ivar Jacobson and James Rumbaugh decided to

unify their works within a single method: the Unified Method, which is known now as UML. In

1997 it was adopted as a standard by the Object Management Group (OMG), and has been

managed by this organization ever since.

UML is a visual language for specifying, constructing and documenting the artefacts of systems.

It is a general purpose modelling language that can be used with all major object and component

methods and can be applied to all application domains (e.g. health, finance, telecom, aerospace)

and implementation platforms (e.g., CORBA – Common Object Request Broker Architecture ,

J2EE – Java 2 Enterprise Edition , .NET).

In this chapter, we describe UML concepts and we restrict on using of class diagrams to represent

the static view of a system, particularly we describe class diagram and we go deep in relative

concepts of class diagram.

We choose using the class diagrams because it provides an overview of a system by describing the

objects and classes inside a system and the relationships between them. It provides a wide variety

of usages, from modeling to detailed design of a system.

2.1 UML Diagrams:

A UML diagram is graphical a model representation of a system under design, implementation,

or already in existence. UML specification defines two major kinds of UML diagram: structural

diagrams and behavior diagrams.

Depending on (OMG Unified Modeling Language (OMG UML), Superstructure) [2] source, we

took a resumes on UML diagrams.

Structural diagrams: show the static structure of the system and their elements represent the

meaningful concepts of a system, and may include abstract, real world and implementation

concepts.

http://en.wikipedia.org/wiki/Grady_Booch

http://en.wikipedia.org/wiki/Ivar_Jacobson

http://en.wikipedia.org/wiki/James_Rumbaugh

http://en.wikipedia.org/wiki/Object_Management_Group

http://www.uml-diagrams.org/uml-24-diagrams.html#structure-diagram


http://www.uml-diagrams.org/uml-24-diagrams.html#behavior-diagram



14

The four structural diagrams:

Class Diagram: Class diagrams are the most common diagrams used in UML. They consists

of classes, interfaces, associations and collaboration. Class diagrams basically represent

the object oriented view of a system, so it is generally used for development purpose. This is

the most widely used diagram at the time of system construction

Object Diagram: Object diagrams can be described as an instance of class diagram. So these

diagrams are more close to real life scenarios where we implement a system. Object diagrams

are a set of objects and their relationships just like class diagrams and also represent the static

view of the system. The usage of object diagrams is similar to class diagrams but they are used

to build prototype of a system from practical perspective.

Component Diagram: Component diagrams represent a set of components and their

relationships. These components consist of classes, interfaces or collaborations. So Component

diagrams represent the implementation view of a system.

During design phase, software artifacts (classes, interfaces etc.) of a system are arranged in

different groups depending upon their relationship. Now these groups are known as

components, which are used to visualize the implementation.

Deployment Diagram: Deployment diagrams are a set of nodes and their relationships. These

nodes are physical entities where the components are deployed. Deployment diagrams are used

for visualizing deployment view of a system. This is generally used by the deployment team.

Behavior diagrams: show the dynamic behavior of the objects in a system, which can be

described as a series of changes to the system over time.

The five Behavior diagrams are:

Use Case Diagram: Use case diagrams are a set of use cases, actors and their relationships.

They represent the use case view of a system. A use case represents a particular functionality

of a system. So use case diagram is used to describe the relationships among the functionalities

and their internal/external controllers. These controllers are known as actors.

Sequence Diagram: A sequence diagram is an interaction diagram. As it is name indicates,

it deals with some sequences, which are the sequence of messages flowing from one object to

another to perform a specific functionality.

State Machine Diagram (State chart Diagram): Any real time system is expected to be

reacted by some kind of internal/external events. These events are responsible for state change

http://creately.com/blog/diagrams/uml-diagram-types-examples/#ClassDiagram

http://creately.com/blog/diagrams/uml-diagram-types-examples/#ObjectDiagram

http://creately.com/blog/diagrams/uml-diagram-types-examples/#ComponentDiagram

http://creately.com/blog/diagrams/uml-diagram-types-examples/#DeploymentDiagram



http://creately.com/blog/diagrams/uml-diagram-types-examples/#UseCaseDiagram

http://creately.com/blog/diagrams/uml-diagram-types-examples/#SequenceDiagram

http://creately.com/blog/diagrams/uml-diagram-types-examples/#StateMachDiagram


15

of the system. State chart diagram is used to represent the event driven state change of a system.

It basically describes the state change of a class, interface etc.

Activity Diagram: shows sequence and conditions for coordinating lower-level behaviors,

rather than which classifiers own those behaviors. These are commonly called control flow

and object flow models.

Communication Diagram: (previously known as Collaboration Diagram) is a kind

of interaction diagram, which focuses on the interaction between lifelines where the

architecture of the internal structure and how this corresponds with the message passing is

central. The sequencing of messages is given through a sequence numbering scheme.

2.2 Class diagram

We show the notion of Class diagram components through their UML metamodels as they are

specified in UML 2.x, and explain them with examples.

A Class diagram is an instance of classifier (Figure 2.1), gives an overview of a system by showing

its classes and the relationships between them such as inheritances, associations, dependencies and

other. Class diagram display what interacts but not what happens when they do interact.

Figure 2. 1: Classifier metamodel

http://creately.com/blog/diagrams/uml-diagram-types-examples/#ActivityDiagram

http://creately.com/blog/diagrams/uml-diagram-types-examples/#CommDiagram


16

2.2.1 Classes

Figure 2. 2: Classes metamodel

Classes are the most important building block of any object-oriented system. In UML, a class is a

classifier (see Figure 2.1) that describes a set of objects, which share the same specifications in

terms of features, constraints and semantics. A class may have a visibility (we restrict on using

only the Public class visibility) and can include constraint, attribute, and operation.

A stereotype (class-stereotype) it represents a subclass of an existing modeling element with the

same form (attributes and relationships) but with a different intent. Generally a stereotype

represents a usage distinction and represent one of the built-in extensibility mechanisms of UML.

For example, modeling a type of enumeration using the stereotype enumeration.

A class can use the definition of another class to define its own attributes and operations. This

usage relationship between classes is called dependency (dependent).

A class can be defined by inheritance from other classes. Inheritance is usually defined as a

mechanism by which more specific classes (subclasses) incorporate structure and behavior of more

general classes (superclasses).

A class (template) can be specified with a list of formal template parameters, a class may also

contain template bindings (binds) to other template classes. These template bindings specify how


17

the class is constructed by substituting the formal template parameters of the target template

classes with actual parameters.

2.2.2 Attribute (Property)

Figure 2. 3: Property metamodel

A property is a structural feature that specifies an attribute for a given classifier. A property

has a name, a visibility, a type and a multiplicity.

Attribute Type: is the data type of the attribute. The type of each attribute should be a primitive

type (String, Integer, Real, Boolean, UnlimitedNaturel), or a non-primitive (i.e. another class in

model).

Visibility: attribute visibility defines which classes can directly access the attribute (in their

operations).

There are four Visibilities:

_ Public (+): The attribute is visible by any class that can see the class containing the attribute.

_ Package (~): Visible to all classes of the package.

_ protected (#): Visible to the class itself and its subclasses.

_ Private (-): Visible only to the class itself.


18

For our concern, an attribute is either Public (+) or Private (-).

Multiplicity: Multiplicity specifies how many instances of the attribute type are referenced by this

attribute. Multiplicity is an inclusive interval of non-negative integers to specify the allowable

number of instances of described element. Multiplicity interval has some lower bound and

(possibly infinite) upper bound:

Lower and upper bounds could be natural constants or constant expressions evaluated to natural

(non negative) number. Upper bound could be also specified as asterisk "*" which denotes

unlimited number of elements. Upper bound should be greater than or equal to the lower bound.

Figure 2. 4: Multiplicity metamodel

Some typical examples of multiplicity:

Multiplicity Cardinality

0..1 No instances or one instance

0..* | * Zero or more instances

1..* At least one instance

5..5 | 5 Exactly 5 instances

m..n At least m but no more than n instances

Table2. 1: Multiplicity


19

2.2.3 Operations

Figure 2. 5: Operation metamodel

An operation represents a behavioral feature of a classifier that specifies the name, type,

parameters, constraints and a visibility (see Attributes visibility).A parameter of an operation

specifies the argument to be passed in or out during an invocation. For our concern, a parameter

is characterized by a name, a direction and a type. Furthermore, an operation can have at most one

return parameter.

Example: The Figure 2.6, shows an example of a UML class with attributes and operations.

The class Point has two attributes X and Y of integer type it also has three operations. getX() and

getY() they do not have an in parameter but they have a return parameter of integer type, and

movePoint() has in parameter X and Y of integer type but has not a return parameter .


20

Figure 2. 6: UML Class with Attributes and operations

2.2.4 Inheritance

Figure 2. 7: Inheritance metamodel

In UML, There are various types of inheritance, we focused on two types of inheritances: Single

and multiple. The Single inheritance designates the mechanism to define a new class (subclass)

from an existing class (the superclass) by taking its attributes and operations. All attributes and

operations of the superclass also become members of the subclass .And moreover, the subclass

may define attributes and operations specific to it, as it can redefine the attributes and operations

even if they were already defined in the superclass level.

Example: Figure 2.8, shows the class ColoredPoint that inherits the class Point in order to

manipulate colored points, The class ColoredPoint inherits all methods and properties of the class

Point and introduces the method getColor (which does not exist in the species Point) to get the

color of a point.


21

Figure 2. 8: Single inheritance

Multiple inheritance is an extension to single inheritance model where we allow a class to hold

multiple superclasses, the Figure 2.9 shows the multiple inheritance.

Figure 2. 9: Multiple inheritance


22

2.2.5 Dependency

Figure 2. 10: Dependency metamodel

A dependency relationship (supplier / client relationship) between two classes specifies that a

client class needs a supplier class to define its own attributes and operations. This implies that

the definition of the Client class is semantically and structurally dependent on the definition of

the supplier class (see Figure 2.10).

Example: Figure 2.11, shows how the class Circle requires to the class Point to define its center.

This expresses a dependency relationship between the classes Circle (the client) and Point (the

supplier).

Figure 2. 11: Dependency


23

2.2.6 Parameterized class (Class Template)

Figure 2. 12: Template metamodel

In UML standard, a template is a model element parameterized by other model elements. To

specify its parameterization, a template element owns a signature. A template signature

corresponds to a list of formal parameters.


24

Figure 2. 13: Template binding metamodel

A template can be used to generate other model elements using template binding relationship. A

bind relationship links a “bound” element to the signature of a target template and specifies a set

of template parameter substitutions that associate actual elements to formal parameters.

Example: Figure 2.14, shows how the class Year (a list of months) is constructed through

substitutions of the formal parameters T: Class of the class List by the actual parameters Month

(T -> Month), where Month is the class that models the months of the year.

Figure 2. 14: Template and Template binding metamodel


25

2.2.7 Associations

Figure 2. 15: Association metamodel

An association describes a set of tuples whose values refer to typed instances. An instance of an

association is called a link. A link is a tuple with one value for each end of the association, where

each value is an instance of the type of the end. [2]

An association represents a relationship between two instances of classes. An association between

two classes is shown by a line joining the two classes. Association indicates which one class

utilizes an attribute or methods of another class.

A unidirectional association is indicated by an arrow pointing from the object which holds to the

object that is held. A bidirectional association is indicated by a line without arrow connecting two

classes, both classes hold information about the other class. In our study we only focus on binary

association (between two classes) the metamodel of a binary association is expressed as in

Figure 2.15.


26

Multiplicity of an association

Associations have a multiplicity (cardinality) that indicates how many objects of each class can

legitimately be involved in a given relationship. Multiplicity is expressed by the interval

[lower bond ..upper bond] the lower and the upper bond show the minimum and the maximum

number of classes instance in the tow ends of the association line that may be involved in the

association,

Multiplicity (Cardinality) UML symbol

Exactly one 1| 1..1

from one to six 1..6

at least one 1..*

Several * | 0..*

With lower bound k and upper bound u k..u

With lower bound k and no upper bound k..*

Table2. 2: Association Multiplicity

Navigations of an association

The navigability of a binary association, graphically expressed as an open arrow at the end of the

association line that connects two classes, specifies the ability of an instance of the source class to

access the instances of the target class by means of the association instances (links) that connect

them. If the association can be traversed in both directions, then it is bidirectional (two-way),

otherwise it is unidirectional (one-way).


27

Example: Figure 2.16 shows the Review association between the classes Person and Paper. The

Person end carries multiplicity 3 to specify that all instances of the Paper class must be reviewed

exactly by 3 persons. The Paper end has multiplicity * to express that one person may review an

arbitrary number of papers.

Figure 2. 16: Association

Chapter III:

FoCaLiZe concepts

Chapter 03: FoCaLiZe concepts

29

The FoCaLiZe project (initially Foc, then Focal Project) began in 1997 under the leadership

of T.Hardin and R.Rioboo [25] . It is an environment in which it is possible to build step-by-step

applications, starting from abstract specifications, and going to concrete implementations by

successive stages of refinement. It also allows to state properties and to prove that the programs

meet their specifications.

The compiler produces OCaml code for execution, Coq code for formal certification, but also

XML for documentation. Zenon [Bonichon et al. 2007] is the automatic proofer tool to first order,

allows automates some of the proof.

The species and its components are restricted from [24-25].

3.1 Species

In FoCaLiZe, the main entity of a development is the species. Which corresponds to the highest

level of abstraction in a specification. Species are the nodes of the hierarchy of structures that make

up a development. A species can be seen as a set of “things”, called methods, related to the same

concept. Like in most modular design systems (i.e. objected oriented, algebraic abstract types), the

idea is to group a data structure with the operations that operate on it. The next figure shows the

general structure of FoCaLiZe developments

Figure 3 .1: FoCaLiZe development


30

The general syntax of a species is the following:

species species_name[(P1 is species_name1, p2 is species_name2, …)]

=[inherit species_names;]

representation = rep_type;] (*representation *)

signature function name : function type; ( * declaration *)

[local/logical] let [rec] function_name = function_body;(*definition *)

property property_name : property_specification; ( * property *)

theorem theorem_name : theorem_specification (* theorem *)

proof = theorem_proof ;

end ;;

Table 3. 1: The general syntax of a species

Where species_name is simply a given name, rep_type and function_type are FoCaLiZe type

expressions, function_body a function code, property_specification and theorem_specification

are logical formulas. Theorem_proof is a proof written in FoCaLiZe proof language to be

ultimately checked by the Coq proof assistant.

The keyword local indicates that the function is only to use inside the species and the keyword

logical introduces a parameterized logical expression, which can be applied to effective arguments

to obtain a logical proposition. Recursive definitions are also available through the let rec keyword.

Statements, definitions and proofs can freely use names of other methods of the species (denoted

by Self!m or shorter m if there is no ambiguity in the scope). Species can be created from scratch

or by multiple inheritance (using the keyword inherit from other species), and it can be

parametrized by other species (using the keyword is).

There are several kinds of method:

Representation: The carrier type, called representation, which is the type of the entities that

are manipulated by the functions of the species, the representation can be either abstract or

concrete. The species representation types, denoted by keyword Self inside the species and by the

name of their species outside of them. And we note that each species has a unique method

representation.

Functions: the functions denote the operations allowed on the entities of the species. The

functions can be either definitions (when a body is provided), it is specify by the keyword "let" or

declarations (when only a type is given), it is specify by the keyword "signature".


31

Signature: function declarations are composed of the keyword signature followed by a

name and a type. It serves to announce a method to be defined later. Such methods are

especially dedicated for specification or design purposes since declared names may be used

to define others methods while delaying their definition.

Let: function definitions are made of the keyword let, followed by a name, an optional

type, and an expression. They serve to introduce constants or functions. Mutually recursive

definitions are introduced by let rec. Hence, definitions serve for implementation purposes.

Properties: the properties that must be verified by any further implementation of the species,

the properties can be either simply declared properties (when only the proposition is given) or

theorems (when a proof is also provided).

Declared properties: They are first order properties statement which are composed of

the keyword property followed by a name and by a first order l formula. They serve to

express requirements. Formula can use methods names known within the species context,

especially to state requirements on these methods. Proof of properties are in fact delayed.

Like for signatures, properties can be used to prove theorems.

Theorems: Made of the keyword theorem, a name, a logical statement and a proof. The

proof of a theorem may use properties available in the context of the species, even they are

not proved yet.

Table 3.2 shows the example of the species Point which models points on a Cartesian plan (with

two axis: x-axis and y-axis).

species Point =

signature getX : Self -> int;

signature getY : Self -> int;

signature move : Self -> int -> int -> Self;

let distance (a:Self, b: Self):float = if (a = b) then 0.0 else

#sqrt( float_of_int( ((getX(a) - getX(b))*(getX(a) - getX(b)) ) +

((getY(a) - getY(b))*(getY(a) - getY(b)) )) );

property distanceSpecification: all p :Self, distance(p, p) = 0.0;

end;;

Table 3. 2: The species Point


32

Plan (with two axis: x-axis and y-axis). Each point has two coordinates: an x-coordinate

and an y-coordinate. In this example, we start by giving an abstract view of the specification. The

representation of the species Point is left undefined. It will be defined through inheritance by other

species. The methods getX, getY and move are declared (no computational body provided). The

method distance is defined to calculate the distance between two given points. The keyword Self

refers to entities of the species. The logical statement distanceSpecification is a declared property

which specifies that the distance between one point and itself equals to 0.0.

3.2 Inheritance and late-binding

We can create a new species by inheritance of an already defined one. We can make this new

species more “complex” by adding new operations and properties, or we can make it more concrete

by providing definitions to signatures and proofs to properties, without adding new features. [24]

A species can inherit the declarations and definitions of one or several already defined species and

is free to define or redefine an inherited method as long as such (re)definition does not change the

type of the method.[26]

When building by multiple inheritance some signatures can be replaced by functions and

properties by theorems. It is also possible to associate a definition of function to a signature or a

proof to a property. In the same order, it is possible to redefine a method even if it is already used

by an existing method. All these features are relevant of a mechanism known as late-binding.

Table 3.3 shows the species ColoredPoint that inherits the species Point in order to manipulate

colored (graphical) points.

type color = | Red | Green | Blue ;;

species ColoredPoint = inherit Point;

representation = (int * int) * color;

let getColor(p:Self):color = snd(p);

let newColoredPoint(x:int, y:int, c:color):Self = ((x, y), c);

let getX(p) = fst(fst(p));

let getY(p) = snd(fst(p));

let move(p, dx, dy) = newColoredPoint(getX(p) + dx, getY(p) + dy,

getColor(p));

let printPoint (p:Self):string =

let printColor (c:color) = match c with

| Red -> "Red"

| Green -> "Green"


33

| Blue -> "Blue"

in ( " X = " ^ string_of_int(getX(p)) ^

" Y = " ^ string_of_int(getY(p)) ^

" COLOR = " ^ printColor(getColor(p)) );

proof of distanceSpecification = by definition of distance;

end;;

Table 3. 3: Example of inheritance

The species ColoredPoint inherits all methods and logical properties of the species Point, plus

the following enrichment:

It defines its representation type by the expression (int * int) * color which models the

type of the x-coordinate (int), the type of the y-coordinate (int) and the type of the color

(color) of a point. The type color is defined as sum type in the example.

It defines the methods: getX, getY and move that were only declared in the species Point.

It introduces the method getColor (which does not exist in the species Point) to get the

color of a point, the method newColoredPoint allows us to create a new instance (as the

new method in the Object Oriented Programming) and the method printPoint to print the

coordinates and the color of a given point.

It provides the proof of the property distanceSpecification. Proofs of properties and

theorems will be detailed at the end of the current section.

(* species Data *)

species Data = inherit Basic_object ;

end;;

(* species Queue *)

species Queue(T is Basic_object) = inherit Basic_object ;

end;;

(* species Data_queue *)

species Data_queue(T is Data ) = inherit Queue(L) ;

end;;

Table 3. 4: Example of parameter substitution

In Table 3.4, the species Data_queue is created by inheritance (from the species queue) and by

substitution of formal parameter T is Basic_object by the actual parameter T is Data.


34

3.3 Collection

A species is said to be complete if all declarations have received definitions and all properties

have received proofs.

The representations of complete species are encapsulated through species interfaces. The

interface of a complete species is the list of the declarations of its underlying species methods

(function signatures and logical statements). It corresponds to the end-user point of view, who

wants to know which functions he can use, and which properties these functions have, but doesn’t

care about the details of the implementation. When complete, a species can be implemented

through the creation of a collection. Thus, a collection is a kind of abstract data type, only usable

through the methods of its interface, with the additional guarantee that all the declarations have

been defined and all the statements have been proved.

A collection can hence be seen as an abstract data type, only usable through the methods of its

interface. The syntax to define collections is:

collection collection_name = implement species_ name; end;;

where species_ name is the application of a defined species over its parameters.

The species ColoredPoint (see Table 3.3) is a complete species since all its declarations have

been defined and all its statements have been proved. So, it can be implemented by the collection

ColoredPointCollection as follows:

collection ColoredPointCollection = implement ColoredPoint; end;;

To create a new instance p = (2, 5, Blue) of the species ColoredPoint and to print its coordinates

and its color, we use the collection ColoredPointCollection as follows:

let p = ColoredPointCollection!newColoredPoint(2, 5, #Bleu);;

basics#print_string(ColoredPointCollection!printPoint(p));;

We remark that the “!” notation is equivalent to the common dot notation of message sending in

object-oriented programming.


35

3.4 Parametrization

Besides inheritance, another important feature of FoCaLiZe is the ability to parametrize a species

by collections parameters (whose “types” are given species) or by entities of a collection. This

mechanism allows using a species, not to integrate its methods, but rather to use it as an

“ingredient” to build a new structure by calling its methods explicitly.

The formal parameter is introduced by a name C and an interface I. Any other collection CO

having an interface including I can be used as actual parameter for C. Consider the example in

Table 3.5 to clarify this concept.

The species Circle is parametrized by the species Point. The representation of the species Circle

has form P * float, where P is a variable type. It models the type of the center of a Circle. The

type float represents the radius type of a Circle.

species Circle (P is Point) =

representation = P * float ;

let newCircle(centre:P, rayon:float):Self = (centre, rayon);

let getCenter(c:Self):P = fst(c);

let getRadius(c:Self):float = snd(c);

let belongs(p:P, c:Self):bool = (P!distance(p, getCenter(c)) =

getRadius(c));

theorem belongs_specification : all c:Self, all p:P,

belongs(p, c) <-> (P!distance(p, getCenter(c)) = getRadius(c))

proof = ... ;

end;;

Table 3. 5: Example of Parametrization

The method belongs is a logical method (returns Boolean results) to decide whether a given point

p:P belongs to a given circle c:Self. The theorem belongs specification specifies that for all point

p and all circle c, if the distance between p and the center of the circle c equals to the radius of c,

then p belongs to c and vice-versa.

To implement the species Circle, we have to substitute the parameter P (P is Point) by a concrete

collection which implements the species Point as follows:

collection CircleCollection = implement Circle(ColoredPointCollection); end;;

Here, we substitute the parameter P by the collection ColoredPointCollection given above.


36

The inheritance and parametrization features complete the general form of a species declaration

as follows:

species species_name (collection name is species app, entity name in collection name , ...)

= inherit species_app , . . . ; . . . end;;

where species_app is the application of a defined species over its parameters.

3.5 Proofs and compilation

Conduct a FoCaLiZe development requires to prove that the set properties are valid. It is necessary

to demonstrate them. To do this, an automatic proof tool to first order (based on the methods of

tables), called Zenon, helps the user to achieve the proof. The language for interacting with Zenon

is a declarative proof language. To prove a property it is also possible to directly give a Coq proof.

[25]

This option is useful when the proof uses some logical aspects that Zenon can’t handle.

Coq proofs are directly inserted into the Coq specification file generated by the compiler.

A proof is either a leaf proof or a compound proof. A leaf proof (introduced with the by or

conclude keywords) invokes Zenon with the assumptions being the given facts and the goal being

the goal of the proof itself (i.e. the statement that is proved by this leaf proof).

The conclude keyword is used to invoke Zenon without assumptions.

A compound proof is a sequence of steps that ends with a qed step. The goal of each step is stated

in the step itself, except for the qed step, which has the same goal as the enclosing proof. [24]

Proof steps:

Proof_step ::= proof_ bullet statement proof

A proof step starts with a proof bullet, which gives its level of nesting. The top level of a proof

is 0. In a compound proof, the steps are at level one plus the level of the proof itself.

As an example of a proof, Table 3.6 shows the proof of the theorem belongs_specification of the

species Circle.

species Circle (P is Point) =

representation = P * float ;

let newCircle(centre:P, rayon:float):Self = (centre, rayon);

let getCenter(c:Self):P = fst(c);

let getRadius(c:Self):float = snd(c);

let belongs(p:P, c:Self):bool =

(P!distance(p, getCenter(c)) = getRadius(c));


37

theorem belongs_specification : all c:Self, all p:P,

belongs(p, c) <-> (P!distance(p, getCenter(c)) = getRadius(c))

proof =

<1>1 assume c : Self, p : P,

prove belongs(p, c) <-> (P!distance(p, getCenter(c))= getRadius(c))

<2>1 hypothesis h1 : belongs(p, c),

prove belongs(p, c) -> (P!distance(p, getCenter(c))= getRadius(c))

by hypothesis h1 definition of belongs

<2>2 hypothesis h2 : (P!distance(p, getCenter(c)) = getRadius(c)),

prove (P!distance(p, getCenter(c)) = getRadius(c))-> belongs(p, c)

by hypothesis h2 definition of belongs property basics#beq_symm

<2>3 qed by step <2>1, <2>2

<1>2 conclude ;

end;;

Table 3. 6: Example of a Proof

In Table 3.6, the steps <1>1 and <1>2 are at level 1 and form the compound proof of the

top-level theorem. Step <1>1 also has a compound proof (whose goal is belongs (p, c) <->

(P!distance(p, getCenter(c)) = getRadius(c))), made of steps <2>1 and <2>2. These latter are at

level 2 (one more than the level of their enclosing step). After the proof bullet comes the statement

of the step, introduced by the keyword prove. This is the proposition that is asserted and proved

by this step.

At the end of this proof step, it becomes available as a fact for the next steps of this proof and

deeper levels sub-goals. In our example, step <2>1 is available in the proof of <2>2, and <1>1 is

available in the proof of <1>2.

Following the statement comes the proof of the step. This is where either we ask Zenon to do the

proof from facts (hints) we give it, or we decide to split the proof in "sub-steps" on which Zenon

will finally be called and that will serve to finally prove the current goal by combining these "sub-

steps" lemmas. For instance, the proof of the whole theorem (which is itself a statement) is split

in the sub-goals <2>1 and <2>2. In the proof of sub-goal <2>1, appears a fact: by hypothesis h1

definition of belongs. Here Zenon is asked to find a proof of the current goal, using hints it is

provided with. The fact definition of belongs refers to the definition of the method belongs. The

sub-goal of the step <2>2 is resolved by using of the hint property basics#beq_symm of the

FoCaLiZe basics library in addition to the definition of the method belongs and the hypothesis h2.


38

The property beq_symm expresses the symmetric property of the basics equality operator (∀a , b

: T, a = b ⇒ b = a).

A FoCaLiZe development contains both "computational code" (i.e. code performing operations

that lead to an effect, a result) and logical properties.

When Compilation of FoCaLiZe sources, two outputs are generated:

The "computational code" is compiled into OCaml source that can then be compiled with

the OCaml compiler to lead to an executable binary. In this pass, logical properties are

discarded since they do not lead to executable code.

Both the "computational code" and the logical properties are compiled into a Coq model.

This model can then be sent to the Coq proof assistant who will verify the consistency of

both the "computational code" and the logical properties (whose proofs must be obviously

provided) of the FoCaLiZe development.

This means that the Coq code generated is not intended to be used to generate an OCaml source

code by automated extraction. As stated above, the executable generation is preferred using

directly the generated OCaml code. In this idea, Coq acts as an assessor of the development

instead of a code generator.

More accurately, FoCaLiZe first generates a pre-Coq code, i.e. a file containing Coq syntax plus

"holes" in place of proofs written in the FoCaLiZe Proof Language. This kind of files is suffixed

by ".zv" instead of directly ".v". When sending this file to Zenon these "holes" will be filled by

effective Coq code automatically generated by Zenon (if it succeed in finding a proof), hence

leading to a pure Coq code file that can be compiled by Coq. [24]

Chapter IV:

From UML to FoCaLiZe

Chapter 04: From UML to FoCaLiZe

40

The structural aspect of our UML model consists of classes and relationships between classes.

Each class can be specified by a list of attributes and operations, possibly empty. Generally,

relations between classes are the inheritances, dependencies and binary associations. A class can

also be specified with a list of formal template parameters, it may also be a bind model derived

thought template bindings form other template classes.

In this Chapter, we propose an automatic transformation of UML class diagrams to FoCaLiZe. To

justify the transformation rules, we first make a comparison between the design features of the

UML concepts presented in Chapter 2 and the FoCaLiZe concepts presented in chapter 3. In this

comparison we describe similarities as well as the conceptual differences between the UML class

diagrams and FoCaLiZe.

The presented transformation are based on studies and works of Abass.M [22] [23].

4.1 Comparison between UML and FoCaLiZe concepts

From the above studies of UML and FoCaLiZe concepts (see chapter 2 and 3), we conclude the

following similarities between the UML and FoCaLiZe concepts:

A UML class corresponds to a FoCaLiZe species. The class attributes play the same role as the

representations of FoCaLiZe species. Operations of UML classes correspond to functions of

FoCaLiZe species.

Relationships between UML classes are also similar to relationships between FoCaLiZe species.

The dependency between UML classes corresponds to the parameterization within FoCaLiZe. The

multiple inheritance is supported by both UML and FoCaLiZe. FoCaLiZe as UML, allows

methods redefinition and late binding mechanisms. UML templates (parametrized classes) are

equivalent to parametrized species. The template binding (the substitution of class formal

parameters with actual ones) is corresponding to species parameter substitution in FoCaLiZe.

The following table summarizes the main corresponding between UML and FoCaLiZe:


41

UML FoCaLiZe

Class Species

Attributes Representations

Operations Functions

Instances(object) Instances(entities)

Inheritance + multiple inheritance Inheritance + multiple inheritance

Parametrized class Parametrized species

Late binding Late binding

Data encapsulation Data encapsulation

Table 4.1: Correspondance between UML and FoCaLiZe concepts

4.2 Transformation rules

In this section, we present transformation rules from UML class diagram to FoCaLiZe. In our

transformation process, we will correspond to each UML graphical notation its FoCaLiZe

semantics.

4.2.1 Transformation of class

A UML class is transformed into a FoCaLiZe species. Here, we preserve the class identifier

(class name) for the generated species.

UML class FoCaLiZe species

species Class_name =

…

end;;

Table 4.2: UML class transformation

As we mentioned before, a class can contain a list of attributes and operations. Next, we will see

the transformation of these latters.

4.2.1.1 Transformation of attributes

Each class attribute is formalized by a "getter" function (that returns the value of the attribute) in

the corresponding species.


42

For an attribute attr: attr_type, the function that models the attribute attr in the corresponding

species is:

signature get_attr: Self -> ⟦𝒂𝒕𝒕𝒓_𝒕𝒚𝒑𝒆⟧;

Where ⟦𝒂𝒕𝒕𝒓_𝒕𝒚𝒑𝒆⟧shows the transformation of attr_type in FoCaLiZe.

There exists two possibilities to translate attributes type:

1- If attr_type is a UML primitive types (integer, real, String and Boolean) we directly use

FoCaLiZe primitive types (int, float, string and bool).

2- If attr_type is not a primitive types (a class type), we use the corresponding species.

The following table shows the transformation of UML class with attributes:

Class attributes Species signature

species Class_name(C is Class1) =

signature get_attr1: Self -> attr_type1 ;

signature get_attr2: Self -> C ;

signature get_attr2: Self -> list(type2) ;

end;;

Table 4.3: Transformation of a UML class with attributes

If the multiplicity of attr_type is greater than one (attr3): we use FoCaLiZe type list, its

transformation is:

signature get_attr: Self -> list( ⟦𝒂𝒕𝒕𝒓_𝒕𝒚𝒑𝒆⟧) ;

4.2.2.2 Transformation of operations

The Class operations will be reported to the corresponding species functions. So, each UML

operation is transformed into a declared function (signature).

The derived signature from a UML operation depends on the input and output parameters of the

original operation, the parameters types of operations can be UML primitive types or class types.

The transformation of operations types is similar as transformation of attributes types (see section

4.2.1.1). We distinguish the following cases:

1- If the operation has several "in" parameters and one "out" parameter:

op_name (p_name1:type1, …, p_namen: typen): return_type, its transformation is:


43

signature op_name: self -> type1 -> … -> typen -> return_type ;

2- If the operation has several "in" parameters and without "out" parameter:

op_name (p_name1:type1, …, p_namen: typen), its transformation is:

signature op_name: self -> type1 -> … -> typen -> self ;

3- If the operation without parameters at all.

op_name (), it is transformed into a signature of the corresponding species:

signature op_name: self -> self ;

The following table shows the transformation of class with operations.

operations of class Signatures of species

species Class_name =

signature op_name1: Self -> type1 ->

type2 -> return_type ;

signature op2_name: Self ->type1 ->

type2 -> Self;

signature op3_name: Self -> Self;

end;;

Table 4.4: Transformation of a UML class with operations

When a UML class specified without a constructor, we add an additional function to

corresponding species which must correspond to the "new" method (of the object oriented

programing) as follows:

new species_name: type1 ->…-> typen -> self ;

Where type1, …, typen are the class attributes types. For example: We transform the constructor of

Class_name as follows:

UML class FoCaLiZe species

species Class_name(C is Class1) =

signature get_attr1: Self -> attr_type1 ;


new Class_name: attr_type1 -> C -> self ;

end;;

Table 4.5: class constractor transformation


44

An enumeration class is transformed into a FoCaLiZe sum type and a FoCaLiZe species, in

order to use it as parameter of other species. The derived sum type will be used for typing methods

of species.

The following table shows an example of an enumeration transformation:

Enumeration class type Sum type

type enum_Name = | Item1 | Item2 | Item3 | … ;;

species Enum_Name =

representation = enum_Name;

signature new_Enum_Name : enum_Name -> Self;

signature to_Enum_Name : Self -> enum_Name;

end;;

Table 4.6 :Transformation of an enumeration UML class

4.2.3 Transformation of dependency relationship

A dependency link between two classes is modeled by the parameterization in FoCaLiZe. For

example, for a class C1 depends on class C2, the species C1 (derived from the class C1) will be

parameterized by the species C2 (derived from the class C2).

The next table presents an example of a dependency Transformation:

Dependency relationship Parameterization

species Class_name1(C is Class_name2) =


signature op_name1 : Self -> C -> Self ;

new Class_name: C -> self;

end ;;

Table 4.7: Transformation dependency of an UML class

4.2.4 Transformation of inheritance

Because the FoCaLiZe specification supports inheritance and multiple inheritance [3] (see chapter

03), we directly transform UML inheritance relationship into FoCaLiZe inheritance relationship.

Multiple inheritance between classes is transformed into multiple inheritance between species.


45

The following table shows an example of a UML inheritance transformation:

UML_Single inheritance FoCaLiZe_Single inheritance

species Class_name1 = inherit Class_name2;

signature get_attr1: Self -> type1 ;

signature op_name1: Self -> type1 -> Self;

signature new_ Class_name1:type1 -> Self;

end;;

UML_Multiple inheritance FoCaLiZe_Multiple inheritance

species Class_name3 = inherit Class_name1,

Class_name2 ;

signature get_attr1: Self -> type1 ;

signature op_name1: Self -> Self;

signature new_ Class_name1:type1 -> Self ;

end;;

Table 4.8: UML inheritance transformation

4.2.5 Transformation of Parameterized class (Class Template)

Parameterized species are the same as template classes (See section 4.1). The formal parameters

substitution of a class by actual parameters, in order to create a new more concrete class (binding),

is formalized by the parameter substitution mechanism in FoCaLiZe.

Indeed, FoCaLiZe offers great flexibility in the substitution of formal parameters by actuals

parameters. Parameters of class type are formalized by parameters of Basic_object type to enable

their substitutions by any species of the model. Standard constraints impose that the type of each

actual parameter (in the bound model) must be a sub-type of the corresponding formal parameter.

The structure of the bound model is based on the structure of the template, where any element used

as a formal parameter is substituted by the actual element species in the binding relationship [22].


46

An example of class template and template banding transformation is the following:

Parametrized class Parametrized species

Species Class_name(T is Basic_object, Y is

Basic_object) = inherit Basic_object ;

…

end;;

Template Binding Parameter substitution

Species Class_name1(T is Class_name2, Y is

Class_name3) = inherit Class_name(A , B) ;

end;;

Table 4.9 : Templat and template binding transformation

4.2.6 Association transformation

A binary association between two classes A and B is modeled, by a parametrized species by the

two corresponding species (derived from classes A and B), the multiplicities of A, the multiplicity

of B, the direction of the association navigation and by entities modeling sets from the two species.

To transform these parameters, we use the predefined species in our library transformation: Range,

an entity of the species Range has a lower and upper functions which return the maximum and

minimum values of a multiplicity, Direction for navigation direction and Set for sets of entities the

both species.

The following table shows the transformation of a UML association into FoCaLiZe.


47

Association Parametrized species

species Assoc_name

(Left is Class_name1, Left_Set is Set(Left),Right is

Class_name2, Right_Set is Set(Right) )

= inherit Association (Range_collection, Left, Left_Set,

multl,Right, Right_Set, multr, Direction_collection, d );

end;;

let d = Direction_collection!make_direction(Both);;

let multl =

Range_collection!make_range(Unlimited_Nat!make(I(1)),

Unlimited_Nat!make(I(1)));;

let multr =

Range_collection!make_range(Unlimited_Nat!make(I(1)),

Unlimited_Nat!make(I(1)));;

Table 4.10: Transformation of UML association

Where, Assoc_name represents the association name, [mltl] represents the multiplicity of

association left side and [mltr] represents the multiplicity of association right side.

4.3 Summary of transformation rules

The following table shows a synthesis of all the above transformation rules using concrete

examples:

UML FoCaLiZe

Class with attributes Species with signatures

species Rectangle = inherit Basic_object ;

signature get_width: Self -> float ;

signature get_height: Self -> float ;

signature new_Rectangle :float -> float -> Self ;

end ;;


48

UML FoCaLiZe

Operation Signatures (Functions)

species Rectangle = inherit Basic_object ;

signature perimeter : Self -> float ;

signature surface : Self -> float ;

end ;;

Enumeration Sum type + Species

type sex= | Men | Women ;;

species Sex =

representation = sex ;

signature new_sex : sex -> Self ;

signature to_sex : Self -> sex ;

end;;

Dependency relationship Parameterization

species Key = inherit Basic_object ;

end;;

species Car(K is Key) = inherit Basic_object ;

signature get_size: Self -> int;

signature get_type: Self -> string;

signature accelerate : Self -> Self;

signature curb : Self -> int -> Self;

signature start : Self -> K -> Self;

signature new_Car :int -> string -> Self ;

end;;


49

UML FoCaLiZe

Single inheritance Single inheritance

species Animal = inherit Basic_object ;

end ;;

species Mammal = inherit Animal ;

end;;

species Oviparous = inherit Animal ;

end ;;

Multiple inheritance Multiple inheritance

species Person = inherit Basic_object ;

end ;;

species Employee = inherit Basic_object ;

end ;;

species Teacher = inherit Employee, Person ;

end ;;

Template class Parametrized species

Species Stack(T is Basic_object )= inherit

Basic_object ;

signature push : Self -> T -> Self;

signature pop : Self -> T;

end;;


50

UML FoCaLiZe

Template Binding Parameter substitution

species A = inherit Basic_object ;

end;;

species MystackA(T is A ) = inherit Stack(T) ;

end ;;

Association Parametrized species

species Lectures

(Left is Teacher, Left_Set is Set(Left),Right is

Course, Right_Set is Set(Right) ) = inherit

Association (Range_collection, Left, Left_Set,

multl, Right, Right_Set, multr,

Direction_collection, d );

end;;

let d =

Direction_collection!make_direction(Both);;

let multl =

Range_collection!make_range(Unlimited_Nat!make

(I(0)), Unlimited_Nat!make(Infini));;

let multr =

Range_collection!make_range(Unlimited_Nat!make

(I(0)),Unlimited_Nat!make(Infini));;

Table 4.11: Summary of transformation rules

Chapter V:

Implementation

Chapter 05: Implementation

52

In this chapter, we describe the different steps of our transformation process in order to

transform UML model (class diagram) into FoCaLiZe. Our transformation process consists of

three steps: firstly, we use a UML graphical environment that supports the OMG metamodel to

create our UML model and generate its corresponding XMI format(XML meta data exchange).

The next step, consists to determine dependencies between classes and the generation of the new

XMI reflecting the dependency hierarchy. The last step consists to apply our transformation rules

to generate the FoCaLiZe source.

To implement our transformation process we have used eclipse environment with Papyrus plugin.

This specific chose of eclipse and papyrus is because the large flexibility of eclipse environment,

and because the complete implementation of all a UML2 features by Papyrus.

https://www.google.dz/url?sa=t&rct=j&q=&esrc=s&source=web&cd=10&cad=rja&uact=8&ved=0CF8QFjAJ&url=https%3A%2F%2Fgithub.com%2Flibgdx%2Flibgdx%2Fwiki%2FSetting-up-your-Development-Environment-%2528Eclipse%2C-Intellij-IDEA%2C-NetBeans%2529&ei=yepHVZ-dIcGvUa7UgOAC&usg=AFQjCNHRCavjrMf-hU1QPWiNfsiO8eTRUw&sig2=rDyKDC7c_dPSPkAtrG1MqQ&bvm=bv.92291466,d.ZGU


53

5.1 XSLT

XSLT (Extensible Stylesheet Language Transformation) is a W3C recommendation. It is a

declarative language that enables the transformation of XML documents into various other XML

(with a different structure), HTML document or text document. To perform a transformation we

need to an XSLT Stylesheet that describes the transformation rules and XSLT processor [27]. This

latter is implemented in most of development environments (java, c#, php, ...). In the last decade

several transformation languages have been developed. In particular we fined the following

transformation languages:

ATL: The ATLAS Transformation Language [28] is a hybrid model-to-model transformation

language.

ETL: The Epsilon Transformation Language [29] is a hybrid model-to-model transformation

language. It is part of the Epsilon model management infrastructure.

QVT: the Query/View/Transformation is a standardized language for model transformation

[30-31] established by the Object Management Group (OMG).

In this work, our choice is put on XSLT, since it allows us to directly transform a UML model to

FoCaLiZe source (text), so we do not need to define a metamodel for FoCaLiZe (as it is required

by ATL and ETL).

https://www.google.dz/url?sa=t&rct=j&q=&esrc=s&source=web&cd=10&cad=rja&uact=8&ved=0CF8QFjAJ&url=https%3A%2F%2Fgithub.com%2Flibgdx%2Flibgdx%2Fwiki%2FSetting-up-your-Development-Environment-%2528Eclipse%2C-Intellij-IDEA%2C-NetBeans%2529&ei=yepHVZ-dIcGvUa7UgOAC&usg=AFQjCNHRCavjrMf-hU1QPWiNfsiO8eTRUw&sig2=rDyKDC7c_dPSPkAtrG1MqQ&bvm=bv.92291466,d.ZGU


54

5.2 Implementation process

Figure 5. 1: Sequence diagram of the implementation process


55

The Figure 5.1 shows the different steps of our implementation process, starting by the creation of

class diagram and the generation of its XMI format, which is not ordered. Then we use our

application: firsts we use the ordering component, which is responsible for the ordering of the XMI

document. After we use the XSLT stylesheet which implements our transformation rules to

generate FoCaLiZe source. Finally we compile the FoCaLiZe source to ensure the correctness of

the output.

5.2.1 First step: creation of class diagram

First we start by creating a UML class diagram using Eclipse3 and Papyrus4, and generating its

XMI format.

For create a UML class diagram, the entities (nodes and edges) can be dragged and dropped from

the palette at the right side of the screen. The following figure shows an example of Class Diagram,

it consists of some classes with relationships between them.

Figure 5. 2: A UML class diagram

To generate the XMI file we save the project, then the XMI file is automatically saved under the

name model.uml file.

3A fallible at https://www.eclipse.org/downloads/packages/release/Kepler/SR2.

4 A fallible at http://www.eclipse.org/papyrus/downloads/index.php.

https://www.eclipse.org/downloads/packages/release/Kepler/SR2

http://www.eclipse.org/papyrus/downloads/index.php


56

The next figure shows the XMI format for the provirus class diagram.

Figure 5. 3: Example of XMI format

5.2.2 Second step: generating the ordered XMI document

FoCaLiZe is a formal language that does not support the jump and return property. So, we need to

make the classes in the correct order before their transformation. For example, if the class C1

depends on another class C2, in FoCaLiZe we must define the species C2 (derived from the class

C2) before species C1 (derived from the class C1). To respect dependency order, we generate a

new XMI format (from the original one) in which we order nodes (each node in XMI format

represents a class) according to their dependencies. For this, we have developed a java application

that automatically generates the new XMI format.

To generate this new XMI format, we follow this process:

Firstly, we have analyzed the dependencies order of the classes in the original XMI format, and

determine for each node (class) its parents and its children. Each node may have several parents.

That's way, we developed a recursive function, which returns the list of parents for each node

having multi-parents. Then we create new XMI file has the same root of the original XMI format.

Finally, for each node with a list of parents, we moved its parents to the new XMI file and then we

moved the node itself, to assure the dependencies order between the node and its parent classes.


57

The next table shows an example of the generation of an XMI ordered format using our java

application.

UML class diagram

XMI before ordering XMI after ordering

<?xml version="1.0" encoding="UTF-8"?> <uml:Model xmi:version="20110701"

xmlns:xmi="http://www.omg.org/spec/XMI/2011

0701"

xmlns:uml="http://www.eclipse.org/uml2/4.0.

0/UML" xmi:id="_WXRQEPjtEeS97YWmYteiaw"

name="Model"> <packageImport

xmi:type="uml:PackageImport"

xmi:id="_WXRQEfjtEeS97YWmYteiaw"> <importedPackage xmi:type="uml:Model"

href="pathmap://UML_LIBRARIES/UMLPrimitiveT

ypes.library.uml#_0"/> </packageImport> <packagedElement xmi:type="uml:Class"

xmi:id="_D4W2APjzEeS97YWmYteiaw"

name="Class1"> <generalization

xmi:type="uml:Generalization"

xmi:id="_jVvC4PjzEeS97YWmYteiaw"

general="_Js3yUPjzEeS97YWmYteiaw"/> </packagedElement> <packagedElement xmi:type="uml:Class"

xmi:id="_Js3yUPjzEeS97YWmYteiaw"

name="Class2"/> </uml:Model>

<?xml version="1.0" encoding="UTF-8"?> <uml:Model xmi:version="20110701"

xmlns:xmi="http://www.omg.org/spec/XMI/201

10701"

xmlns:uml="http://www.eclipse.org/uml2/4.0

.0/UML" xmi:id="_WXRQEPjtEeS97YWmYteiaw"

name="Model"> <packageImport

xmi:type="uml:PackageImport"

xmi:id="_WXRQEfjtEeS97YWmYteiaw"> <importedPackage xmi:type="uml:Model"

href="pathmap://UML_LIBRARIES/UMLPrimitive

Types.library.uml#_0"/> </packageImport> <packagedElement xmi:type="uml:Class"

xmi:id="_Js3yUPjzEeS97YWmYteiaw"

name="Class2"/> <packagedElement xmi:type="uml:Class"

xmi:id="_D4W2APjzEeS97YWmYteiaw"

name="Class1"> <generalization

xmi:type="uml:Generalization"

xmi:id="_jVvC4PjzEeS97YWmYteiaw"

general="_Js3yUPjzEeS97YWmYteiaw"/> </packagedElement> </uml:Model>

Table 5. 1: The generation of Xml ordered format

5.2.3 Third step: transformation

The last step consist to apply transformation rules (see Chapter 4) to generate a FoCaLiZe source.

We have developed an XSLT stylesheet that specifies the transformation rules to transform a UML

class diagram into FoCaLiZe, based on the ordered version of XMI file.

An XSLT stylesheet contains a set of templates, and each template represents transformation rules.

The following table summarizes all the templates of our XSLT stylesheet:


58

XSLT stylesheet templates Description

Template1:” Enumeration

transformation”

This template defines the transformation rule that

transforms a UML enumeration class into a FoCaLiZe

type.

Template2:” owned literal

Enumeration”

This template defines the transformation rule that

transforms a UML enumeration literal into a FoCaLiZe

type elements.

Template3:” Class transformation” This template defines the transformation rule that

transforms a UML class into a FoCaLiZe species.

Template4:” ownedAttribute

transformation”

This template defines the transformation rule which

transforms a UML class attributes into a FoCaLiZe

signatures (getters).

Template5:”ownedOperation

transformation”


transforms a UML class operations into a FoCaLiZe

functions.

Template6:” constructor

transformation”


transforms a UML class constructor into a FoCaLiZe

species constructor.

Template7:” generalization

transformation”


transforms a UML inheritance and multiple inheritance

into FoCaLiZe inheritance and multiple inheritance.

Template8:” Dependency

transformation”


transforms a UML dependency into a FoCaLiZe

parameterization.

Template9:” ownedTemplateSignature” This template defines the transformation rule which

transforms a UML class template into FoCaLiZe

Parameterized species.

Template10:” templateBinding” This template defines the transformation rule which

transforms a UML template banding into a FoCaLiZe

Parameters substitution.

Table 5. 2: XSLT stylesheet template


59

Figure 5. 4: Implementation of the transformation process

The Figure 5.4 resumes our implementation of the transformation process.


60

5.3 Case study

To illustrate our transformation, we have constructed a UML class diagram containing all sorts of

UML features: inheritance, multiple inheritance, template, template banding, dependency and

enumeration. The next figure represents the class diagram which we will use during this case study.

The UML class diagram:

Figure 5. 5: A UML class diagram

Generation of the XMI format: From the previous class diagram we generate the

corresponding XMI format, the next table shows partial flash of this document.

<?xml version="1.0" encoding="UTF-8"?> <uml:Model xmi:version="20110701" xmlns:xmi="http://www.omg.org/spec/XMI/20110701"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:uml="http://www.eclipse.org/uml2/4.0.0/UML" xmi:id="_WXRQEPjtEeS97YWmYteiaw"

name="Model"> <packageImport xmi:type="uml:PackageImport" xmi:id="_WXRQEfjtEeS97YWmYteiaw"> <importedPackage xmi:type="uml:Model"

href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#_0"/> </packageImport> <packagedElement xmi:type="uml:Class" xmi:id="_m5Vv8PrJEeS0RoqB8SEhNg"

clientDependency="_G1C3kPrKEeS0RoqB8SEhNg" name="cercle"> <ownedAttribute xmi:type="uml:Property" xmi:id="__-BVYPrJEeS0RoqB8SEhNg"

name="center" visibility="public" type="_l0PwIPrJEeS0RoqB8SEhNg"> <lowerValue xmi:type="uml:LiteralInteger" xmi:id="_BihOAPrKEeS0RoqB8SEhNg"

value="1"/> <upperValue xmi:type="uml:LiteralUnlimitedNatural"

xmi:id="_BiicIPrKEeS0RoqB8SEhNg" value="1"/> <defaultValue xmi:type="uml:LiteralString" xmi:id="_BimGgPrKEeS0RoqB8SEhNg"> <value xsi:nil="true"/>


61

</defaultValue> </ownedAttribute> <ownedAttribute xmi:type="uml:Property" xmi:id="_CmM4kPrKEeS0RoqB8SEhNg"

name="radius" visibility="public"> <type xmi:type="uml:PrimitiveType"

href="pathmap://UML_LIBRARIES/UMLPrimitiveTypes.library.uml#Real"/> <lowerValue xmi:type="uml:LiteralInteger" xmi:id="_EytMYPrKEeS0RoqB8SEhNg"


xmi:id="_EyvBkPrKEeS0RoqB8SEhNg" value="1"/> <defaultValue xmi:type="uml:LiteralString" xmi:id="_EyyE4PrKEeS0RoqB8SEhNg"> <value xsi:nil="true"/> </defaultValue> </ownedAttribute> </packagedElement> <packagedElement xmi:type="uml:Class" xmi:id="_u29GwPrJEeS0RoqB8SEhNg" name="colored_

object"> <generalization xmi:type="uml:Generalization" xmi:id="_pT9okP2YEeSbiYzxNN01Vw"

general="_mxjWMP2YEeSbiYzxNN01Vw"/> <ownedAttribute xmi:type="uml:Property" xmi:id="_VAtsEPrKEeS0RoqB8SEhNg"

name="color" visibility="public" type="_oy2OoPseEeS0RoqB8SEhNg"> <lowerValue xmi:type="uml:LiteralInteger" xmi:id="_YYA_EPrKEeS0RoqB8SEhNg"


xmi:id="_YYC0QPrKEeS0RoqB8SEhNg" value="1"/> <defaultValue xmi:type="uml:LiteralString" xmi:id="_YYFQgPrKEeS0RoqB8SEhNg"> <value xsi:nil="true"/> </defaultValue> </ownedAttribute> <ownedOperation xmi:type="uml:Operation" xmi:id="_J60foPsgEeS0RoqB8SEhNg"

name="setColor"/> </packagedElement> <packagedElement xmi:type="uml:Dependency" xmi:id="_G1C3kPrKEeS0RoqB8SEhNg" name=""

client="_m5Vv8PrJEeS0RoqB8SEhNg" supplier="_l0PwIPrJEeS0RoqB8SEhNg"/> <packagedElement xmi:type="uml:Class" xmi:id="_3IM4sPsgEeS0RoqB8SEhNg"

name="Collection"> <ownedTemplateSignature xmi:type="uml:RedefinableTemplateSignature"

xmi:id="_UDCQUPshEeS0RoqB8SEhNg" name="RedefinableTemplateSignature1"

parameter="_VDuRQPshEeS0RoqB8SEhNg"> <ownedParameter xmi:type="uml:ClassifierTemplateParameter"

xmi:id="_VDuRQPshEeS0RoqB8SEhNg" parameteredElement="_aE328PshEeS0RoqB8SEhNg"> <ownedParameteredElement xmi:type="uml:Class" xmi:id="_aE328PshEeS0RoqB8SEhNg"

name="T" templateParameter="_VDuRQPshEeS0RoqB8SEhNg"/> </ownedParameter> </ownedTemplateSignature> <ownedAttribute xmi:type="uml:Property" xmi:id="_cBX_4PshEeS0RoqB8SEhNg"

name="group" visibility="public" type="_aE328PshEeS0RoqB8SEhNg"> <lowerValue xmi:type="uml:LiteralInteger" xmi:id="_c7_1EPshEeS0RoqB8SEhNg"


xmi:id="_c8BqQPshEeS0RoqB8SEhNg" value="*"/> <defaultValue xmi:type="uml:LiteralString" xmi:id="_c8VMQPshEeS0RoqB8SEhNg"> <value xsi:nil="true"/> </defaultValue> </ownedAttribute> </packagedElement> <packagedElement xmi:type="uml:Class" xmi:id="_1p-xwPshEeS0RoqB8SEhNg"

name="Point_Collectio">


62

<templateBinding xmi:type="uml:TemplateBinding" xmi:id="_8Frp4PshEeS0RoqB8SEhNg"

signature="_UDCQUPshEeS0RoqB8SEhNg"> <parameterSubstitution xmi:type="uml:TemplateParameterSubstitution"

xmi:id="_AvyokPsiEeS0RoqB8SEhNg" actual="_l0PwIPrJEeS0RoqB8SEhNg"

formal="_VDuRQPshEeS0RoqB8SEhNg"/> </templateBinding> </packagedElement> </uml:Model>

Table 5. 3: The XMI format corresponding to the class diagram

Where for each packageElement represents a corresponding UML class in previous UML class

diagram.

Generation of the ordered XMI format: at this stage, we use our java application to

reorder the aforementioned XMI document to generate the ordered XMI document according to

semantic and syntactic dependencies between the classes. The next figure shows our java

application interface.

Figure 5. 6: Java application interface

To perform the transformation we first open the XMI source in the left side window.

Transformation

Button

Compilation Button of

FoCaLiZe code

Open an

XMI file

Output earia

XMI side FoCaLiZe side


63

Figure 5. 7: Opening the XML file

After that, we press on the transformation button, the FoCaLiZe source automatically appears in

the right side window.

Figure 5. 8: the transformation of FoCaLiZe code


64

Finally we press on the compilation button to check the generated focalize code: the next figure

represents the result of the final step.

Figure 5. 9: Compilation of FoCaLiZe source

In this example, we get the above compilation messages with no error: this means that the

compilation, code generation and Coq verification were successful. When a FoCaLiZe compiler

detects errors, it indicates the responsible lines

Conclusion

65

Conclusion

In this document, we have presented a study and an implementation for the transformation

of a UML class diagrams into a FoCaLiZe specification. We resume the correspondents between

a UML and FoCaLiZe as follows: A UML class correspond to a FoCaLiZe species. The class

attributes play the same role as the representations of FoCaLiZe species. Operations of UML

classes correspond to functions of FoCaLiZe species. Relationships between UML classes are also

similar to relationships between FoCaLiZe species. The dependency between UML classes

correspond to the parameterization within FoCaLiZe. The multiple inheritance is supported by

both UML and FoCaLiZe. FoCaLiZe as UML, allows methods redefinition and late binding

mechanisms. UML templates (parametrized classes) are equivalent to parametrized species. The

template binding is corresponding to the parameter substitution in FoCaLiZe. From this

comparison we have proposed a transformation rules for each UML construct, using the XMI

technology (XML Metadata Interchange) which provides as standard format for describing UML

model elements. We parse the XMI document into FoCaLiZe by applying our transformation rules

that we have defined by XSLT stylesheet.

The presented implementation allows to derive a formal FoCaLiZe specification expressed through

species hierarchy that keeps the same incremental modeling provided by UML.

In the present work we have also studied UML association, but we have not implemented its

transformation into FoCaLiZe. OCL constrains are largely used to specify properties on UML

models (classes, attributes, operation). In the proposed implementation OCL constraints are also

not supported. As extension of this implementation, we would like to expand our wok to deal with

all kinds of UML association and OCL constrains.

References

66

References

[1] A. Kleppe, J. Warmer and W. Bast. "MDA Explained: The Model Driven Architecture™:

Practice and Promise", Addisson-Wesley, 2003.

[2] OMG :UML:Superstructure, version 2.4(2011).Available at

http://www.omg.org/spec/UML/2.4/Infrastructure

[3] Lilius.J, Paltor.I.P : UML: A tool for verifying UML models. In: Automated Software

Engineering, 1999. 14th IEEE International Conference, on pp. 255–258. IEEE (1999)

[4] Hazem. L, Levy.N, Marcano-Kamenoff.R : UML2B : Un outil pour la génération de modelés

formels. AFDL (2004)

[5] Snook. C, Butler. M: UML-B: Formal modeling and design aided by UML. ACM Transactions

on Software Engineering and Methodology (15), 92–122 (2006)

[6] Truong. N, J. S: Verification of UML model elements using B. Information Science and

Engineering (22), 357–373 (2006)

[7] Truong. N, Souquieres. J, et al: Validation des propriétés d’un scenario UML/OCL à partir de sa

dérivation en B. Proc. Approches Formelles dans l’Assistance au Développement de Logiciels,

France (2004)

[8] GU. J, CHEN. M, ZHOU. X: Formal language B and UML/OCL comparison. Computer

Knowledge and Technology 34, 044 (2009)

[9] Yang. M, Michaelson. G, Pooley. R: Formal action semantics for a UML action language. Journal

of Universal Computer Science 14(21), 3608–3624 (2008)

[10] Yang. J: A framework for formalizing UML models with formal language rCOS. In: Frontier of

Computer Science and Technology, 2009. FCST’09. Fourth International Conference on, pp.

408–416.IEEE (2009)

[11] Ayrault. P, Hardin, T. Pessaux. F: Development life-cycle of critical software under FoCaL.

Electronic Notes in Theoretical Computer Science 243, 15–31 (2009)

[12] Cabot. J, Pau. R, Raventos. R.: From UML/OCL to SBVR specifications: A challenging

transformation. Information systems 35(4), 417–440 (2010)

[13] Duran. F, Gogolla. M, Roldan. M: Tracing properties of UML and OCL models with Maude.

arXivpreprint arXiv:1107.0068 (2011)

[14] Brucker. A, Wolff. B: The HOL-OCL tool (2007). http://www.brucker.ch/

http://www.omg.org/spec/UML/2.4/Infrastructure

http://www.brucker.ch/

References

67

[15] Broy. M, Crane. M, Dingel. J, Hartman. A, Rumpe. B, Selic. B: Formal semantics for UML.

Models in Software Engineering pp. 318–323 (2007)

[16] Abrial, J: The B book. (1996). Cambridge University Press

[17] Team. F.D: FoCaLiZe: Tutorial and reference manual, version 0.9.0. CNAM/INRIA/LIP6

(2014).Available at: http://focalize.inria.fr

[18] Fechter. S: Sémantique des traits orientés objet de FoCaL. Ph.D, thesis, Université PARIS 6

(2005)

[19] Delahaye. D, Etienne. J.F, Donzeau-Gouge. V.V: Producing uml models from focal

specifications: an application to airport security regulations. In: Theoretical Aspects of Software

Engineering, 2008.TASE’08. 2nd IFIP/IEEE International Symposium on, pp. 121–124. IEEE

(2008)

[20] Doligez .D: ”the Zenon tool” Software and documentations freely available at

http://focal.inria.fr/zenon/

[21] Coq: The Coq proof assistant, Tutorial and reference manual. INRIA – LIP – LRI – LIX – PPS

(2010).Distribution available at: http://coq.inria.fr/.

[22] Messaoud Abbas, Choukri-Bey Ben-Yelles, and Renaud Rioboo. Modeling UML Template

Classes with FoCaLiZe. In The International Conference on Integrated Formal Methods (IFM

2014, Bertinoro Italy). Published in LNCS, volume 56, pages 87–102.

[23] Messaoud Abbas, Choukri-Bey Ben-Yelles, and Renaud Rioboo. Generating FoCaLiZe

Specifications from UML Models. In The International Conference on Advanced Aspects of

Software Engineering (ICAASE 2014, Constantine Algeria). Conference proceedings, pages

157–164.

[24] Thérése Hardin, François Pessaux, Pierre Weis, Damien Doligez. FoCaLiZe Reference

Manual.version 0.9.0.(October 2014)

[25] Damien Doligez, Mathieu Jaume, Renaud Rioboo. Development of secured systems by mixing

programs, specifications and proofs in an object-oriented programming environment. A case

study within the FoCaLiZe environment. PLAS - Seventh Workshop on Programming

Languages and Analysis for Security, Jun 2012, Beijin, China. <hal-00773654>

[26] David Delahaye , Catherine Dubois , Pierre-Nicolas Tollitte. Génération de code fonctionnel

certifié à partir de spécifications inductives dans l'environnement Focalize at JFLA 2010

http://focalize.inria.fr/

http://focal.inria.fr/zenon/

References

68

[27] Matthias Biehl, Literature Study on Model Transformations, Embedded Control Systems, Royal

Institute of Technology, Stockholm, Sweden, July 2010

[28] F. Jouault, F. Allilaire, J. B_ezivin, and I. Kurtev, \ATL: a model transformation tool," Science

of Computer Programming, vol. 72, pp. 31-39, June 2008.

[29] D. Kolovos, R. Paige, and F. Polack, \The epsilon transformation language," in Theory and

Practice of Model Transformations, ser. Lecture Notes in Computer Science, A. Vallecillo, J.

Gray, and A. Pierantonio, Eds.Berlin, Heidelberg: Springer Berlin Heidelberg, 2008, vol. 5063,

ch. 4, pp.46-60. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-69927-9_4.

[30] I. Kurtev, \State of the art of qvt: A model transformation language standard," Applications of

Graph Transformations, pp. 377-393, 2008. [Online]. Available:

http://www.springerlink.com/content/2g55gw5260q2740h/fulltext.pdf.

[31] _MOF 2.0 Query / View / Transformation," OMG, Tech. Rep.,December 2009. [Online].

Available: http://www.omg.org/spec/QVT.

http://dx.doi.org/10.1007/978-3-540-69927-9_4

http://www.springerlink.com/content/2g55gw5260q2740h/fulltext.pdf

http://www.omg.org/spec/QVT

Documents

UNIVERSITY OF ECHAHID HAMMA LAKHDAR EL OUED · Abstract II Abstract FoCaLiZe is an object-oriented development environment which aims to ease software development through a proof-based