Projet

République Algérienne Démocratique et Populaire Ministère de
l’enseignement Supérieur et de la Recherche Scientifique Université

Constantine 2 - Abdelhamid Mehri
Faculté des Nouvelles Technologies de l’Information et de la Communication

Département d’Informatique Fondamentale et ses Applications
MASTER
EN
INFORATIQUES
OPTION
Réseaux et Systèmes Distribués
Génération automatique des types

inductifs Gallina et Vernacular à
partir de Méta-Méta-Modèle Ecore en
utilise TGG
Realisé(s) par :
Lemmou karima
Boustila Rihana
Dirigé(s) par :
Pr.Chaoui Allaoua
Dr.SeidAli Rehab
Session : juillet 2019

Remerciements
Nous tenons premièrement à remercier Dieu le tout puissant, qui nous a
donné la force et la patience d’accomplir ce modeste mémoire.
nous tenons à exprimer nos profonde gratitude à Allaoua CHAOUI ,
Professeur à l’Université de Constantine 2 – ABDELHAMID MEHRI , pour
son encadrement et ses conseils précieux.
Nos remerciement s’adresse à Mr Rehab SeidAli pour sa patience, sa
rigueur et sa disponibilité durant notre préparation de ce mémoire.
On remercie aussi Mr Jérémy BUISSON, pour son aide pratique .
Nos remerciements les plus distinguées vont également aux membres du
jury pour l’intérêt qu’ils ont porté à notre recherche en acceptant
d’examiner notre travail et de l’enrichir par leurs propositions.
Enfin, nous tenons également à remercier toutes les personnes qui ont
participé de près ou de loin à la réalisation de ce modeste travail.

Résumé
L’Ingénierie Dirigée par les Modèles(IDM) joue un rôle très important dans le dévelop-
pement des logiciels. Dans le contexte d’IDM, la transformation de modèle est une phase
important qui utilisée dans le processus de développement de logiciel elle permet d’aug-
menter la validation et la vérification d’une telle transformation des modèles .pour effectué
la transformation un utilise deux chose ,un environnement de modélisation et un outille
de transformation.
Dans notre travaille, nous proposons une transformation du Méta-Modèle Ecore en une
langage de Coq appelée Gallina / Vernacular. On utilise comme environnement Eclipse
Modeling Framework (EMF)) avec ca langage graphique(Ecore) qui permet de crée les
modèle, et comme un outil nous avons faire une transformation bidirectionnelle avec TGG-
Interpretre avec langage de transformation QVT qui vérifier la conformité des modèle par
langage OCL.
Mots Clés
L’Ingénierie Dirigée par les Modèles(IDM), Méta-Modéle Ecore, Coq, Gallina / Vernacular,
Eclipse Modeling Framework(EMF), TGG-Inerpretre, langage QVT, lagage OCL.
I
Abstract
Model Driven Engineering (IDM) plays a very important role in software development.
In the context of IDM, the model transformation is an important phase that used in the
software development process it allows to increase the validation and the verification of
such a transformation of the models. For carried out the transformation one uses two thing
, a modeling environment and a transformation tool. In our work, we propose a transfor-
mation of the Meta-Model Ecore into a Coq language called Gallina / Vernacular. We
use as environment Eclipse Modeling Framework (EMF)) with this graphical language
(Ecore) which makes it possible to create the model, and as a tool we have a bidirectional
transformation with TGG-Interpreter with language of transformation QVT which check
the conformance of the model by language OCL.
Key Words
Model Driven Engineering(MDI), Ecore Méta-Modèle, Coq, Gallina / Vernacular language,

Eclipse Modeling Frameworke(EMF), TGG-Interpretre , QVT language, OCL language.
II
Acronymes
— AGG : Attributed Graph Grammar.

— ATL : Atlas Transformation Language.
— ATOM : A Tool for Multi-formalism and Meta-Modelling.
— CCS : Calculus of Communicating Systeme.
— CIM : Computation Independent Model.
— CSP : Communicating Sequetial Processes.
— CWM : Common Warehouse Metamodel.
— EMF : Eclipse Modeling Framework.
— ETL : Epsilon Transformation Language.
— GMF : Graphical Modeling Framework.
— GrGen : Graph Rewrite Generator.
— GROOVE : GRaph of Object Oriented VErification.
— IBM : International Business Machines.
— IDM : Ingénierie Dirigée par les Modèles.
— LHS : Left Hand Side.
— MDA : Model driven architecture.
— MOF : Méta Objecte Facility.
— M2M : Model to Model.
— M2T : Model to Text.
— OCL : Object Constraint Language.
— OMG : Object Management Group.
— PDM : Platform Description Model.
— PIM : Platform Independent Model.
— PSM : Plate-forme Specific Model.
— QVT : Query, Views, Transformation.
— RHS : Right Hand Side.
— Spin : Simple Promela INterpreter.
— TGG : Triple Graph Grammar.
— UML : Unified Modeling Language.
— VIATRA : VIsual Automated model Transformations.
— XMI : XML Metadata Interchange.
— XML : eXtended Markup Language.
III
Table des matières
Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I
Acronymes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . III
Table des matiéres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX
Table des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XII
Intrudction Générale XIII
1 EMF Eclipse Modeling Framework 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Généralité sur Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Eclipse Modeling Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3.2 Organisation d’EMF dans la plate-forme d’intégration . . . . . . . . 3
1.3.3 Fonctionnalités du Framework EMF . . . . . . . . . . . . . . . . . . 4
1.3.4 Les Étapes de modélisation avec EMF . . . . . . . . . . . . . . . . . 5
1.3.5 Objectif d’EMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.6 Eclipse Modeling Framework et UML . . . . . . . . . . . . . . . . . 6
1.3.7 Architecture d’EMF . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
IV
1.3.8 Avantages d’EMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Ecore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.1.1 Langage OCL . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4.2 La hiérarchie des classes Ecore . . . . . . . . . . . . . . . . . . . . . 10
1.4.3 Représentation textuelle pour les Méta-Modèles . . . . . . . . . . . 13
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 les méthodes formelles et Coq 14
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Les Méthodes Formelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 les avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2.1 Approches orientées états : . . . . . . . . . . . . . . . . . . 15
2.2.2.2 Approche axiomatique : . . . . . . . . . . . . . . . . . . . . 17
2.2.2.3 l’approche hybride : . . . . . . . . . . . . . . . . . . . . . . 17
2.2.3 techniques pour la preuve de propriétés . . . . . . . . . . . . . . . . 17
2.2.3.1 Model-checking . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.3.2 Preuve de théorèmes . . . . . . . . . . . . . . . . . . . . . . 18
2.3 L’assistant de preuve Coq . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.2 domaines d’application . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.3 comparaison des différents assistants de preuves . . . . . . . . . . . 20
2.3.4 Vérification du programme en Coq . . . . . . . . . . . . . . . . . . . 21
V
2.3.5 Termes de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.5.1 Types et sortes . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.5.2 Les constantes . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.6 Tactiques de Coq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.7 Composition de tactiques . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.8 Le lambda calcul en Coq . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.8.1 calculs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.9 les utilisations de Coq . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4 conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3 L’IDM et la transformation des graphes 28
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Présentation de l’IDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Les standards liés à l’lDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.1 MOF : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.2 QVT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.3 UML : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.4 XMI : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.5 CWM : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Les approches de l’IDM : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5.1 Architecture MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5.2 Les modèles MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5.2.1 CIM : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
VI
3.5.2.2 PIM : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5.2.3 PSM : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5.2.4 PDM : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6 Transformation de modèles . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6.1 Les Approches pour la transformation de modèles . . . . . . . . . . 36
3.6.1.1 Transformation de modèle vers modèle . . . . . . . . . . . 36
3.6.1.2 Transformations Modèle à code . . . . . . . . . . . . . . . . 37
3.7 Transformation de graphes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7.1 Rappel sur les graphes . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7.1.1 Graphe orienté . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.7.1.2 Graphe non orienté . . . . . . . . . . . . . . . . . . . . . . 39
3.7.1.3 Un sous graphe . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.7.1.4 Graphes étiquetés . . . . . . . . . . . . . . . . . . . . . . . 39
3.7.2 Grammaire de graphes . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.7.3 Le principe de règles de transformation . . . . . . . . . . . . . . . . 41
3.7.4 L’application des règles . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.7.5 Système de transformation de graphes . . . . . . . . . . . . . . . . . 42
3.8 Outils et langage de transformation . . . . . . . . . . . . . . . . . . . . . . 43
3.8.1 Acceleo : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.8.2 AGG : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.8.3 AtoM3 : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.8.4 GROOVE : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.8.5 GrGen : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
VII
3.8.6 TGG-Interpreter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.8.6.1 Spécification des transformations . . . . . . . . . . . . . . . 45
3.9 conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4 Contribution 47
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Approche proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.1 Phase de Méta-Modélisation . . . . . . . . . . . . . . . . . . . . . . 48
4.2.1.1 Méta-Modèle source . . . . . . . . . . . . . . . . . . . . . . 49
4.2.1.2 Méta-Modèle Ciple . . . . . . . . . . . . . . . . . . . . . . 51
4.2.1.3 Correspondance . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.2 Spécification des règles de transformation . . . . . . . . . . . . . . . 55
4.2.2.1 Règle01 : Axiom . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.2.2 Régle02 : def2cmd() . . . . . . . . . . . . . . . . . . . . . . 56
4.2.2.3 Régle03 : ind2ind() . . . . . . . . . . . . . . . . . . . . . . 56
4.2.2.4 Régle04 : simple2def() . . . . . . . . . . . . . . . . . . . . . 56
4.2.2.5 Règle05 :typedef2def() . . . . . . . . . . . . . . . . . . . . . 57
4.2.2.6 Règle06 :simple2ind() . . . . . . . . . . . . . . . . . . . . . 58
4.2.2.7 Régle07 : ind2body() . . . . . . . . . . . . . . . . . . . . . 59
4.2.2.8 Régle08 :ctor2ctor() . . . . . . . . . . . . . . . . . . . . . . 59
4.2.2.9 Régle09 : makeBinder() . . . . . . . . . . . . . . . . . . . 59
4.2.2.10 Régle10 : makeBinder() . . . . . . . . . . . . . . . . . . . . 60
VIII
4.2.2.14 Régle14 : typ2term() . . . . . . . . . . . . . . . . . . . . . 63
4.2.2.15 Régle15 : typ2term() . . . . . . . . . . . . . . . . . . . . . 63
4.2.2.16 Régle16 :typ2term() . . . . . . . . . . . . . . . . . . . . . . 64
4.2.2.17 Régle17 : typ2term() . . . . . . . . . . . . . . . . . . . . . 64
4.2.2.18 Règle18 :typ2term() . . . . . . . . . . . . . . . . . . . . . . 64
4.2.2.19 Règle19 : typ2term() . . . . . . . . . . . . . . . . . . . . . 65
4.3 Etude de cas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3.1 Etapes d’exécutions sur le fichier XMI . . . . . . . . . . . . . . . . . 68
4.3.2 Les fichiers résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Conclusion Générale 71
Table des figures
1.1 Les fichier traiter par EMF[14] . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Organisation d’EMF dans la plate-forme d’intégration[15] . . . . . . . . . . 4
1.3 Géneration d’éditeur graphique de modèle . . . . . . . . . . . . . . . . . . . 4
1.4 Les Étapes de l’utilisation d’EMF . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 l’architecture d’EMF[11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 La hiérarchie des classes Ecore[19] . . . . . . . . . . . . . . . . . . . . . . . 12
2.1 Classification des méthode formelles . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Term de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 l’architecture du MDA [50] . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Principe du Processus MDA . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 la transformation de modèles [53] . . . . . . . . . . . . . . . . . . . . . . . 35
3.4 les approches de transformation de modèle . . . . . . . . . . . . . . . . . . 38
3.5 graphe orienté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6 graphe non orienté . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.7 un sous-graphe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.8 graphes étiquetés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
X
3.9 Application d’une règle de transformation . . . . . . . . . . . . . . . . . . . 42
3.10 Système de réécriture de graphe . . . . . . . . . . . . . . . . . . . . . . . . 42
3.11 Transformation dans les espaces techniques IDM et TGG . . . . . . . . . . 46
4.1 Approche proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 Méta-Modèle source (Ecore) . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3 Modèle Cible (Coq) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.4 Correspondance entre Ecore et Coq . . . . . . . . . . . . . . . . . . . . . . . 54
4.5 Règle TGG de Axiom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.6 Règle TGG de ind2ind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.7 Règle TGG de simple2def . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.8 Règle TGG de typedef2def() . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.9 Règle TGG de simple2ind() . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.10 Règle TGG de ind2body() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.11 Règle TGG de ctor2ctor() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.12 Règle TGG de makeBinder()1 . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.17 Règle TGG de typ2term()2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
XI
4.22 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.23 le fichier Exemple.interpreterconfiguration. . . . . . . . . . . . . . . . . . . . 68
4.24 fenetre de terminaison d’execution de transformation des règles avec succés. 69

Introduction Général
Aujourd’hui, l’informatique est appliquée à la plupart des activités humaines( Les sys-
tèmes actuels de transport, de télécommunications, d’administration, de soins médicaux,
la gestion de paiements électroniques, etc.). Dans ce genre d’application les enjeux sont
énormes, une erreur dans le logiciel peut être très coûteuse. Pour cette raison que ces sys-
tèmes doivent être conçus de sorte à atteindre la qualité zero-erreur. Ces derniers,doivent
être vérifiés d’une manière fiable et performante avant leur mise en œuvre.
La vérification du fonctionnement de ces systèmes avec Les méthodes traditionnelles uti-
lisées pour détecter les erreurs contenue dans un programme ne sont pas suffisantes pour
démontrer que ce dernier est correct, c’est-à-dire qu’il ne contient pas d’erreurs. Il faut donc
faire appel à des approches plus rigoureuses qui garantissent de façon absolue l’absence de
toute défaillance dans certains logiciels. C’est ce que proposent les méthodes formelles. Les
méthodes formelles sont des techniques qui permettent un raisonnement rigoureux, à l’aide
d’une sémantique et de modèle formel, sur des systèmes informatique ou même du matériel
électronique afin de prouver leur validité par rapport à un certain ensemble de propriétés
bien définies. Il existe essentiellement deux approches dans le domaine de la vérification
formelle : celle basée sur les modèles (model-checking) [1] pour des systèmes à ensemble
d’états fini, et celle basée sur la preuve de théorèmes (theorem-proving) qui permettent
de traiter des systèmes ayant un nombre infini d’états. Cette approche consiste à spécifier
et à démontrer les propriétés du système à l’aide d’un assistant de preuves tels que PVS
[2], HOL [3] et Coq [4] que nous avons utilisé dans notre travail. Coq est un assistant de
preuve qui permet d’exprimer les spécifications et le développement de programmes co-
hérents avec leur spécification. Cet outil s’applique alors parfaitement au développement
de programmes en lesquels une confiance absolue est requise. Dans plusieurs domaines,
la nécessité de programmes rigoureusement conformes à leur spécification exprime l’effort
demandé par leur validation.
XIII
Notre mémoire est une approche de transformation de modèle Ecore vers l’assistant de
preuve Coq basée sur la grammaire de graphes qui est automatisée grâce à l’outil de méta-
modélisation EMF et L’outil de transformation TGG Interpreter.
Dans le reste, nous détaillons ces idées à travers le plan du présent manuscrit :
Le premier chapitre : nous présentons le langage de méta-méta-modélisation Ecore qui
sera le modèle source pour notre approche de transformation.
Le deuxième chapitre : nous présentons la méthode de vérification formelle et ces dif-
férentes classifications et la notion de lambda calcul. Ensuite, nous présentons en détaille
l’assistant de preuve Coq et ces concepts de base.
Le troisième chapitre :nous présentons les notions de base de l’ingénierie Dirigée par les
Modèles, ainsi l’architecture dirigée par les modèles, en présentant les principaux notions
de l’IDM corresponds à la méta-modélisation et la transformation des modèles. Par la
suite, nous présentons les définitions de base de grammaires de graphes, et ces différentes
approches et outils pour la transformation de graphes, ainsi nous présentons le langage de
méta-méta-modélisation Ecore qui sera le modèle source pour notre approche de transfor-
mation.
Le quatrième chapitre : nous présentons notre approche de transformation qui com-
mence par la méta-modélisation de modèle Ecore avec le langage OCL. Ensuite, nous
présentons la génération des spécifications Coq en se basant sur le TGG à l’aide de l’outil
TGG Interpreter.
Et finalement, nous clôturons, notre mémoire par une conclusion générale qui résumera
ce qui a été réalisé et nous proposons éventuellement les travaux qui peuvent être réalisés
comme perspectives du présent manuscrit.
XIV
Chapitre 1
EMF Eclipse Modeling Framework
1.1 Introduction
Pour effectuée la transformation des modèles soit la transformation modèle vers mo-
dèle ou modèle vers code (génération du code), ou bien pour faire la modélisation ou la
Méta-Modélisation, nous avons besoin des environnements de modélisation comme l’EMF,
GMF[5]..etc, et de transformation comme TGG-Interpréter[6], AGG[7], AToM3[8], VIA-
TRA2[9]..etc. Permis les outils les plus importants dans ce domaine, nous avons choisi de
travailler avec Ecore, le langage de base d’Eclipse Modeling Framework (EMF). qui fournit
un cadre et une fonction de génération de code permettant de créer des applications ro-
bustes basées sur des modèles étonnamment simples. EMF offre une modélisation à faible
coût pour le grand public Java en utilisant le modèle intrinsèque dans une application .
Ce chapitre est analysé deux partie : EMF comme un outil de modélisation des modèle
après une définition plus détaillée d’Ecore comme un langage qui permet de décrire le mo-
dèle EMF. avant de faire sa , nous commençons par une présentation générale d’éclipse.
Ensuite nous précisons la relation entre UML[10] et EMF et les Méta-Modèle Ecore .
1.2 Généralité sur Eclipse
Eclipse[11] est un projet créé en 2001 par IBM .C’est un logiciel open source, extensible
et polyvalent en s’appuyant principalement sur Java. Il fournit une plate-forme des outils
hautement intégrée pour le développement logiciel sous forme d’activité, modélisation..etc.
1
Son architecture est basée sur la notion de plug-in. Chaque plug-in fournit un certain type
et un certain nombre des fonctionnalités dans le contexte d’Eclipse Workbench.[12]
1.3 Eclipse Modeling Framework
1.3.1 Definition
EMF est un Framework qui peut être utilisés pour modéliser un modèle de données et
générer du code ou toute autre sortie basée sur ce modèle. Permet de construire rapide-
ment des applications basées sur un modèle de données structurées. Elle fournit des outils
permettant de générer un ensemble des classes Java pour le modèle à partir d’une spéci-
fication décrite généralement sous la forme d’un modèle en XMI . Elle offre un langage
de description de modèle (Méta-Modèle Ecore). la figure 1.1 se montrée les trois types de
fichiers qui peut traiter par EMF[13] :
• UML
• XML
• Code Java.
2
Figure 1.1 – Les fichier traiter par EMF[14]
1.3.2 Organisation d’EMF dans la plate-forme d’intégration
Dès la conception de la plate-forme, plusieurs niveaux ont été mis en place. Tout d’abord,
Eclipse constitue l’ infrastructure technique de base. Il accueille les différents services sous
forme de composants (plug-ins) et permet de construire une interface graphique pour les
différentes activités. Il constitue la base d’atelier. Ensuite, EMF introduit un socle de pro-
grammation pour traiter des modèles. Ainsi, tous les modèles manipulés dans le cadre de
cette plate-forme ont au minimum un Méta-Modèle décrit en Ecore. Ceci assure une com-
patibilité technique après Les autres outils de la plate-forme sont montrés dans la figure
1.2 qui illustré organisation de EMF dans la plate-forme d’intégration.
3
Figure 1.2 – Organisation d’EMF dans la plate-forme d’intégration[15]
1.3.3 Fonctionnalités du Framework EMF
Figure 1.3 – Géneration d’éditeur graphique de modèle
EMF est un Framework Open Source dont l’objectif dépasse la simple génération des
interfaces de manipulation des modèles, le but de ce framework est de faciliter la mani-
pulation des modèles afin de permettre leur intégration dans la plate-forme Éclipse. C’est
dans cet objectif que plusieurs fonctionnalités ont été améliorées pour permettre le déve-
loppement de nouveaux Méta-Modèles et assurer la manipulation des modèles instances
de ces Méta-Modèles dans la plate-forme Éclipse. Parmi ces fonctionnalités, celle qui est
certainement la plus agréable est la génération automatique d’un simple éditeur graphique
4
permettant l’édition des modèles sous forme arborescente. L’idée sous-jacente est de gé-
nérer automatiquement, à partir d’un Méta-Modèle, un éditeur graphique offrant une vue
arborescente d’un modèle. Chacun des nœuds de l’éditeur représentées une instance d’une
méta classe. Cette fonctionnalité s’utilise très simplement dans le framework EMF. Il suffit
de demander la génération des classes Java composant l’éditeur graphique correspondant
à un Méta-Modèle puis d’exécuter ces classes dans la plate-forme Éclipse afin de visua-
liser l’éditeur graphique. Nous avons utilisé cette fonctionnalité sur notre Méta-Modèle
exemple et avons pu élaborer notre modèle grâce à cet éditeur graphique, comme l’illustre
la figure1.3
1.3.4 Les Étapes de modélisation avec EMF
Figure 1.4 – Les Étapes de l’utilisation d’EMF
5
EMF est une boı̂te des outils d’amélioration Java Éclipse au monde du développement
dirigé par les modèles, et pour modéliser avec EMF nous suivis les étapes qui illustrée
dans la figure1.4, au départ il faut définir Le Méta-Modèle (modèle de domaine) à l’aide
de l’éditeur de diagramme Ecore telle que son extension est .ecore, et a partir de ce modèle
on peut générer le code java et avant ca la génération nécessite la création des modèle de
génération qui appelée genmodele qui contient les information comme package, chemin
de génération.etc. Enfin, Personnalisation du code avec supplément fonctionnalité.
1.3.5 Objectif d’EMF
EMF propose plusieurs services :

• Un environnement de développement à base de modèle.
• Un outillage qui permet de passer du modèle au code Java automatiquement
• Permet de construire rapidement des application basées sur un modèle de données struc-
turées.
• Offre un langage de description de modèles (Méta-Modèle) ”Ecore”.
• Transformation des modèles d’entrées, présentés sous diverses formes, en Core Model.
• Possibilité de définir un Méta-Modèle et de générer les interfaces afin de pouvoir mani-
puler les instances du Méta-Modèle dans Eclipse.
1.3.6 Eclipse Modeling Framework et UML
UML est devenu le langage dirigée par les modèles. Il englobe plusieurs diagrammes uti-
lisés pour représenter chaque vue, parmi les diagrammes les plus utilisés nous avons le
diagramme de classe qui représente l’aspect structurel de MOF[16] qui normalisée par
OMG[17]. Ecore est comparable pour MOF mais assez simple. Nous pouvons trouver
des similitudes dans leur capacité à spécifier des classes, caractéristiques structurelles et
comportementales, héritage et paquet.[18]
6
1.3.7 Architecture d’EMF
EMF se compose de trois pièces fondamentales illustrer dans la figure.1.5suivant : Run-

time Emf
• Cadre de notification
• Méta-Modèle Ecore
• Persistance (XML / XMI), validation, changement de modèle
Outils EMF
• Prise en charge des éditeurs et des visualiseurs basés sur des modèles
• Éditeur de réflexion par défaut
Codegen
• Générateur de code pour modèles d’application et éditeurs
• Cadre extensible modèle importateur / exportateur
Trois niveaux de génération de code sont pris en charge :
• Modèle : fournit des interfaces Java et des classes d’implémentation pour toutes les
classes du modèle, ainsi qu’une classe d’implémentation d’usine et de package (métadon-
nées).
• noyau : génère des classes d’implémentation (appelées ItemProviders) qui adaptent les
classes de modèle à l’édition et à l’affichage.
• Editeur : produit un éditeur correctement structuré, conforme au style recommandé
pour les éditeurs de modèles Éclipse EMF et servant de point du départ pour la person-
nalisation.
7
Figure 1.5 – l’architecture d’EMF[11]
1.3.8 Avantages d’EMF
• EMF est un terrain d’entente dans la modélisation par rapport au monde de la program-
mation.
• L’accent est mis sur le sous-ensemble de diagrammes de classes de UML modélisation
(modèle d’objet).
• Transforme les modèles en modèles efficaces, corrects et code Java facilement personna-
lisable
• Fournit l’infrastructure pour utiliser des modèles efficacement dans le code
• Coût d’entrée très bas
• Outil de modélisation graphique à grande échelle non requis
• EMF est gratuit
8
1.4 Ecore
1.4.1 Définition
Le langage Ecore est un langage de Méta-Modélisation graphique et textuelle défini par

IBM et utilisé dans le framework de modélisation d’Éclipse EMF (Éclipse Modeling Fra-
mework). Il est utilisé pour définir les Méta-Modèles et le langage OCL est intégré pour
d’écrire les contraintes dans le but de vérifier la conformité des modèles à leurs Méta-
Modèles.[19]
• Le langage Ecore est un langage graphique et textuel. La représentation graphique du
langage permet de manipuler directement les concepts, sans passer par une formalisation
textuelle abstraite et difficile à acquérir.
• Ecore intègre le langage formel OCL qui facilite l’implémentation et permet de d’écrire
les contraintes.
1.4.1.1 Langage OCL
Le langage OCL (object Constraint Language) a été développé en 1997 par Jos Warmer
(IBM). Il a été officiellement incorporé dans UML 1.1 en 1999. OCL est un langage formel
qui est basé sur la notion des contraintes. cette dernier est une expression booléenne qui
peut être attachée à tout élément d’UML. Ce langage indique généralement une restriction
ou donne des informations sur un modèle. Les contraintes sont notamment utilisées pour
décrire la sémantique d’UML et ses différentes extensions, en participant à la définition
des profils UML. Le choix de ce langage est justifié par :
• OCL est un langage formel volontairement simple d’accès.
• OCL représente en fait un bon milieu entre un langage naturel et un langage très tech-
nique (langage mathématique, informatique, ...).
• Il permet ainsi de limiter les ambiguı̈tés, tout en restant accessible.
• Langage OCL est intégré dans le langage Ecore, donc il est facile à utiliser pour implé-
menter les contraintes.
•Intégré dans des AGLs, utilisé ou étendu dans des langages de transformations (ATL,
QVT...).
Dans ce qui suit, nous présentons deux contraintes en langage OCL. La première exprime
que les noms sont obligatoire. Pour la deuxième, explique le nom ambiguı̈té des transi-
9
tions c-à-d on ne peut pas trouver deux transitions avec le même nom, la même source et
destination et la même condition.
1.4.2 La hiérarchie des classes Ecore
La figure 1.6 illustre la hiérarchie complète des classes des méta-modèle Ecore :
On va définis quelque classe :

EObject : elle est la racine de Méta-Modèle, elle contient des instance des classes.
EModelElement : elle hérite la classe racine EObject.
EAnnotation : elle hérite EModelElement, en ajout ici des commentaire, identifier par
le nom de source de l’entité a commenter.
ENamedElement : elle hérite aussi EModelElement, identifier par un nom.
EFactory : elle hérite EModelElement, permis de créer des instances de EClasses et EDa-
taTypes contenus dans le paquet. Il est possible d’accéder à un EFactory uniquement à
partir d’un EPackage via l’instance eFactory.
EPackage : désigne les packages des modèle qui sont des contneur des EClassifier(class
et type),identifier par un nom et URI pour l’identification lors de la sérialisation.
EClassifier : est une classe de base commune pour EClass et EDataType. elle assemble
les caractéristiques qui apparaissent dans ces deux classes. En fait, ces classes ont des
similitudes : les deux est la cible Références eType. Cette référence permet à EStructu-
ralFeatures de définir des classes ou des données types comme leurs types. L’opération
isInstance fournie par EMF vérifie si un programme Java Object est une instance de la
classe EClass ou EDataType représentée par le classificateur .
EClass : désigne les classe de , identifiée par nom qui peuvent contient de StructuralFea-
tures(Attributs ou Référence).
EdataType : représente le type d’un attribut. Un type de données peut être primitif ou
de type objet. Les EDataType en Ecore sont (EBoolean, Echar, EFloat, EString, EBy-
teArray, EBooleanObject, EFloatObject, EJavaObject).
EStructural Features : EStructuralFeature est une base commune pour les deux classes
EReference et EAttribute. qui définit l’état d’une instance de EClass. Les deux classes ont
des similitudes : les deux ont un nom et un type de type eType de référence ayant une
cible à un EClassifier). Ils comptent également les limites inférieure et supérieure pour
déterminer le nombre de fonctionnalité qui compose l’instance EClass.
10
EOperation : désigne les opération d’une classe pouvant étre invoqué, cette méta-classe
identifiée par un nom et un type de retour et des paramétrés ,EOperations peut avoir des
paramètres représentés par les EParameters.
EAttributs : Les attributs sont des composants structurels d’une classe, identifiée par un
nom et un type.
EReference : représente une extrémité d’une association entre classe. Elle a un nom, un
flag booléen pour indiquer si elle a du contenu ou non et une référence type.
entre eAttributeType et EAttributes. Il définit que chaque attribut doit être saisi et plu-
sieurs attributs peuvent être typés avec un EDataType.
EEnum : Désigne le type énumérés parmi un ensemble de EenumLiteral .
11
EObject
eClass() : EClass
eIsProxy() : EBoolean
eResource() : EResource
eContainer() : EObject
eContainingFeature() : EStructuralFeature
eContainmentFeature() : EReference
eContents() : EEList
eAllContents() : ETreeIterator
eCrossReferences() : EEList
eGet(EStructuralFeature) : EJavaObject
eGet(EStructuralFeature,EBoolean) : EJavaObject
eSet(EStructuralFeature,EJavaObject)
eIsSet(EStructuralFeature) : EBoolean
eUnset(EStructuralFeature)
EModelElement
getEAnnotation(EString) : EAnnotation
EFactory ENamedElement EAnnotation

name : EString source : EString
create(EClass) : EObject
createFromString(EDataType,EString) : EJavaObject
convertToString(EDataType,EJavaObject) : EString
EPackage EClassifier EEnumLiteral ETypedElement

nsURI : EString instanceClassName : EString value : EInt ordered : EBoolean
nsPrefix : EString instanceClass : EJavaClass<?> instance : EEnumerator unique : EBoolean
getEClassifier(EString) : EClassifier defaultValue : EJavaObject literal : EString lowerBound : EInt EStringToStringMapEntry
instanceTypeName : EString upperBound : EInt key : EString
isInstance(EJavaObject) : EBoolean many : EBoolean value : EString
getClassifierID() : EInt required : EBoolean
EClass EDataType
abstract : EBoolean serializable : EBoolean EStructuralFeature EOperation EParameter
interface : EBoolean
changeable : EBoolean
isSuperTypeOf(EClass) : EBoolean volatile : EBoolean
getEStructuralFeature(EInt) : EStructuralFeature transient : EBoolean
getEStructuralFeature(EString) : EStructuralFeature defaultValueLiteral : EString
getFeatureCount() : EInt defaultValue : EJavaObject
getFeatureID(EStructuralFeature) : EInt unsettable : EBoolean
EEnum derived : EBoolean
getEEnumLiteral(EString) : EEnumLiteral getFeatureID() : EInt
getEEnumLiteral(EInt) : EEnumLiteral getContainerClass() : EJavaClass
getEEnumLiteralByLiteral(EString) : EEnumLiteral
EAttribute EReference
iD : EBoolean containment : EBoolean
container : EBoolean
resolveProxies : EBoolean
Figure 1.6 – La hiérarchie des classes Ecore[19]
12
1.4.3 Représentation textuelle pour les Méta-Modèles
Il important de représenter ces constructions à la manière d’une grammaire. Dans cette

grammaire, chaque règle correspond à un élément du sous-ensemble avec lequel nous tra-
vaillons. La règle EPackage dérive un nom de package suivi d’un ensemble de classificateurs
EC. Un EClassifier peut donner une EClass ou un EEnum. Chaque classe EC a un nom
et définit un ensemble de EStructuralFeatures. Ce sont soit EAttributes, soit EReferences.
Enum la règle fournit un ensemble de valeurs de chaı̂ne précédées du mot clé littéral. Nous
définissons dans cette grammaire quatre types prédéfinis possibles : int, float, string et
boolean.
1.5 Conclusion
EMF est un projet open-source d’Eclipse.org fournissant un cadre et une fonction de gé-
nération de code permettant de créer des applications robustes basées sur des modèles
étonnamment simples. Les modèles peuvent être définis de différentes manières (interfaces
Java, schémas XML, UML) à partir desquels EMF générera une grande partie de l’appli-
cation. Le code généré est propre, efficace et facilement modifié à la main. Vous pouvez
même régénérer le modèle après avoir modifié le code, sans effacer vos modifications.
EMF fournit une modélisation à faible coût pour le grand public Java en utilisant le modèle
intrinsèque dans une application. Avec EMF, aucun outil de modélisation de haut niveau
n’est requis. L’utilisation des EMF présente deux avantages fondamentaux. Premièrement,
il en résulte un gain de productivité en fournissant un moyen agréable et de haut niveau
(UML) de communiquer la conception, puis de générer une partie du code d’implémen-
tation. Deuxièmement, EMF permet aux applications de s’intégrer avec une granularité
beaucoup plus fine qu’il n’est autrement possible. Les concepteurs d’EMF estiment qu’il
combine la bonne quantité de modélisation à la programmation afin de maximiser l’effica-
cité des deux.
13
Chapitre 2
les méthodes formelles et Coq
2.1 Introduction
Le développement de logiciels, d’équipements ou de systèmes présente du nombreux dé-

fis, et en pratique des problèmes résiduels sont malheureusement très fréquents dans les
versions déployées. Pour pallier à ce problème, plusieurs approches ont été proposées pour
assurer une meilleure maitrise des systèmes, la validation et la vérification des systèmes
informatiques, ces deux approches sont adaptées pour la détection et la correction des
erreurs, ainsi pour assurer une bonne production du logiciel. Les méthodes formelles sont
le plus souvent désignées lorsqu’on parle sur ce type d’approches.
Ce chapitre est destiné en premier lieu à proposer un survol des méthodes formelles,
afin d’avoir une idée générale sur leurs principes, techniques d’analyse, classes ainsi que
leurs principales techniques de vérification, pour ensuite montrer leurs intérêts et difficul-
tés. Deuxièmement, décrire de façon un peu exhaustive et précise le langage Coq et ses
concepts de base nécessaires pour la compréhension de la suite de cet mémoire.
2.2 Les Méthodes Formelles
En génie logiciel, les méthodes formelles sont des techniques et des outils basés sur les
mathématiques pour la synthèse (c’est-à-dire le développement) et l’analyse de systèmes
logiciels. Les méthodes formelles peuvent être appliquées à différents moments du cycle
de développement du logiciel. Des méthodes formelles peuvent également être utilisées
14
en ingénierie inverse pour modéliser et analyser des systèmes existants. Les méthodes
formelles ne sont généralement utilisées que dans le développement de logiciels critiques
pour la sécurité, les affaires et la mission, où le coût des défauts est élevé.
En ce qui concerne le terme méthodes formelles, nous utilisons la définition suivante : une
méthode formelle est un ensemble d’outils et de notations (avec une sémantique formelle)
utilisés pour spécifier sans ambiguı̈té les exigences d’un système informatique qui prend
en charge la preuve des propriétés de cette spécification et les preuves de la justesse d’une
éventuelle mise en œuvre par rapport à celle.
2.2.1 les avantages
Les principaux avantages des méthodes formelles peuvent être résumés dans les points
suivants :
• l’utilisation d’une méthode formelle basée sur des notations mathématiques et précises
permet d’éviter les ambiguı̈tés et les redondances dans la phase de spécification.
• La détection d’erreurs : garantie la détection des bugs de conception le plus tôt possible
dans ce processus.
• le raffinement des spécifications formelles et leurs décompositions successives permettent
de mettre des niveaux d’abstraction intéressants pour la résolution du problème et pour
promouvoir la réutilisation des spécifications.
2.2.2 Classification
Il y a plusieurs approches dans les méthodes formelles J.M.Wing [20] montrées dans La
Figure.2.1
• approches orientées données décrivant les états du système.
• approches orientées opérations décrivant le comportement du système par des axiomes.
• approches hybrides qui combinent les deux orientations.
2.2.2.1 Approches orientées états :
Le développement est basé sur la description d’un système par un modèle qui a les pro-
priétés du système. Vérification des propriétés sur le modèle. Des raffinements corrects
15
Figure 2.1 – Classification des méthode formelles
successifs sont effectués sur le modèle. On caractérise deux sortes d’approches dans ce
contexte : l’approche dynamiques et l’approche par modèle abstrait .
• Approche dynamique : Cette approche s’intéresse à la modélisation des systèmes en
s’appuyant sur le concept de processus.Cette catégorie de spécifications a été développée
au sein des algèbres de processus comme CSP [21] ou CCS [22], dans les systèmes de tran-
sitions (automates, réseaux de Pétri, arbres JSD) [23] .
• Approche par modèle abstrait : Cette approche est constructive dont le système
formel est décrit par une syntaxe attribuée par les types et les opérations du modèle abs-
trait et dont la sémantique est attribuée.Nous citons comme exemple de cette catégorie
les langages de spécification VDM [24][25], Z [26][27].
16
2.2.2.2 Approche axiomatique :
Le développement est basé sur axiomatisation qui d’écrit le comportement du système.

Des vérifications des propriétés sont effectuées, raffinements possibles. En utilisant une
approche algébrique ou une approche logique [28].
• Approche algébrique : Cette approche les module sont définis en se Basant sur des
types abstraits de données ou des types abstraits Algébriques Aucune structure de données
n’est représentée pour un type de données, il n’y a que des opérations décrites les unes en
fonction des autres par des axiomes.Nous pouvons évoquer comme exemple de langages
de spécification algébriques SACSO [29], LARCH [30], LPG [31], OBJ [32].
• Approche logique : elle est concentrée sur la théorie des types et les logiques d’ordre
supérieur.Nous avons comme exemple de ce type le système PVS [33], Isabelle/HOL [34][35
] et Coq [36][37].Dans notre travail nous allons traiter de façon plus exhaustive l’assistant
de preuve Coq.
2.2.2.3 l’approche hybride :
Les approches hybrides enrichissent un modèle de données par une axiomatisation ou in-
versement [38]. LOTOS [39] est classifié comme étant l’un des langages algébriques puisque
ses expressions de contrôle sont spécifiées par une algèbre dont les termes sont des pro-
cessus. Tandis que les données sont spécifiées par une algèbre de types abstraits dont les
termes sont des expressions fonctionnelles [40]. Parmi les prédécesseurs de LOTOS, on
peut distinguer le langage CCS [41] et le langage ACT ONE [42].
2.2.3 techniques pour la preuve de propriétés
Techniques pour la preuve de propriétés s’effectue par deux méthodes différentes : la vé-
rification de modèle (model checking) et la preuve de théorèmes (theorem proving).
17
2.2.3.1 Model-checking
C’est une approche qui permet de vérifier qu’un modèle de système à états finis (généra-
lement simultané, réactif) satisfait à une spécification formelle des exigences du système.
Dans cette approche, les modèles décrivent comment l’état du système peut évoluer avec
le temps, et les exigences sont quelques contraintes sur la manière dont l’état du système
est autorisé à évoluer dans le temps. Les outils qui effectuent automatiquement une véri-
fication de modèle sont appelés des vérificateurs de modèle.
L’avantage majeur de cette approche est sa grande automatisation. Le processus de vé-
rification de modèle permet de décider de la validité des propriétés à vérifier sans avoir
besoin d’aucune intervention d’utilisateur. Le rôle de l’utilisateur se réduit à modéliser le
système, spécifier les propriétés à vérifier et finalement lancer le calcul. Cette approche a
aussi l’avantage de pouvoir exhiber un modèle de comportement invalidant la propriété à
vérifier(un contre-exemple) quand celle-ci est insatisfaite.
Parmi les différents outils de la vérification de Model-checking on cite SPIN et UPPAAL
(a) SPIN : Spin (Simple Promela INterpreter) est un outil général permettant de
vérifier des systèmes distribués. Cet outil utilisé comme un langage de spécification. Il a
été écrit par Gerard J. Holzmann et d’autres personnes du groupe Unix de Centre du
recherche en sciences informatiques des Bell Labs, à partir de 1980.
(b) UPPAAL : UPPAAL est un environnement d’outils intégré pour la modélisation,
la validation et la vérification de systèmes temps réel modélisés sous la forme de réseaux
d’automates temporisais, étendus avec des types de données (entiers liés, tableaux, etc.).
développé par une collaboration entre le département technologie de l’information de l’uni-
versité d’Uppsala (Suède) et le département de d’informatique de l’université D’Aalborg
au Danemark et beaucoup d’autres.
2.2.3.2 Preuve de théorèmes
Cette méthode consiste à spécifier et à démontrer les propriétés du système à l’aide d’outils
logiciels appelés assistants de preuves tels que Coq, HOL, Isabelle, LEGO, NuPRL. Toute
preuve est effectuée par l’utilisateur mais sa validité est garantie par ce système.
Cette approche a l’avantage d’être indépendante de la taille de l’espace d’états du système,
et peut donc s’appliquer sur des modèles avec un très grand nombre d’états, potentielle-
18
ment indéterminé ou infini. Néanmoins, son inconvénient est quelle nécessite l’intervention
et la créativité de l’utilisateur pour compléter la preuve, ce qui est parfois un processus as-
sez laborieux. Un autre inconvénient est son incapacité à fournir un contre-exemple lorsque
la propriété à vérifier est prouvée insatisfaite.
Parmi les outils de preuve semi-automatique :
(a) Assistant de preuve Coq : Coq est un système de manipulation de preuves
mathématiques formelles. Il est possible d’énoncer des théorèmes, des spécifications de
programme, et de développer interactivement leurs preuves à l’aide de tactiques.
(b) Assistant de preuve Isabelle : C’est un système de preuves basés sur un unique
calcul formel, en général la logique d’ordre supérieur.
(c) Assistant de preuve PVS : PVS (Prototype Vérification System) assistant de
preuves est écrit dans le langage de programmation Lisp. C’est un outil de vérification
intégrant le langage de spécification PVS qui se base sur la logique classique d’ordre su-
périeur.
2.3 L’assistant de preuve Coq
Le système Coq est développé à l’INRIA dans le cadre du projet TypiCal. Coq est un
assistant de preuve permettant l’expression de spécifications et le développement de pro-
grammes cohérents avec leur spécification. Ce dernier se base sur le calcul des constructions
inductives [43]. Coq est avant tout un système permettant de faire des preuves dans une
logique très expressive, dite d’ordre supérieur. Ces preuves sont construites de façon inter-
active, assistée par des outils de recherche automatique de preuves dans des domaines où
cela est possible. Donc, Coq n’est pas seulement un assistant de preuve, mais également
un atelier de construction de programmes corrects par extraction depuis la spécification
vérifiés. Les preuves sont construites impérativement à l’aide des tactiques, qui sont des
outils préalablement existants dans l’assistant de preuve.
2.3.1 Architecture
Les composantes essentielles du système Coq sont :

• Le noyau relativement petit basé sur un langage avec peu de constructions primitives.
19
• Un nombre limité de règles de vérification de type et de calcul.
• Un langage de développement de théories mathématiques qui est utilisé pour représenter
des objets, des fonctions, des propositions et des preuves : Gallina .
2.3.2 domaines d’application
nous pouvons citer quelques domaines d’application de Coq :

• Arithmétique des ordinateurs (flottants)
• Cryptographie (certicrypt)
• Mathématiques (constructives ou non)
• Sémantique des langages
• Algorithmes avances
• Outils certifies(compilateurs, analyse statique, outils de vérification) .
• Cible pour des outils de vérification (Why3, edukera)
• Calcul scientifique (continu)
2.3.3 comparaison des différents assistants de preuves
Il existe différents assistants de preuves, parmi les plus connus on trouve :

– ACL2
– Coq
– HOL
– HOL Light
– Isabelle
– PVS
Le point fort de HOL est l’exibilité donnée aux utilisateurs au moyen du métalangage,tandis
que Coq La démonstration théorique repose sur la puissance du calcul des constructions
inductive, le système PVS a été utilisé pour prouver la correction d’un algorithme pour la
détection et la résolution des confits dans l’espace aérien, Isabelle utilise la logique clas-
sique d’ordre supérieur et Coq utilise une logique intuitionniste basée sur la théorie du
calcul des constructions inductives, mais peut être étendu à la logique classique en assu-
mant l’axiome du tiers exclu.
20
2.3.4 Vérification du programme en Coq
Le Coq peut être utilisé de différentes manières pour la vérification du programme :

• On peut exprimer la propriété ” le programme p est correct ” comme une déclaration
mathématique en Coq et prouver que c’est correct. Cela peut être difficile mais la preuve
est garanti.
• On peut développer un analyseur de programme spécifique (vérification de modèle, ana-
lyse abstraite interprétation )C’est un investissement énorme, mais on obtient un résultat
automatique garanti pour chaque instance de programme.
• On peut représenter le programme p par un terme de Coq t et la spécification par Taper
T(qui est coché automatiquement) implique que p est correct. Cela fonctionne bien pour
les programmes fonctionnels .
• On peut également utiliser un outil externe pour générer des obligations de preuve, puis
utiliser Coq pour résoudre les obligations. C’est une approche moins sûre, mais elle peut
traiter des spécifications indécidables où l’automatisation.Complète ne fonctionnera pas.
2.3.5 Termes de base
Le système Coq dispose d’une interface via laquelle l’utilisateur introduit toutes défini-
tions. Ceci en utilisant un langage précis, comportant un certain nombre de commandes et
de conventions syntaxiques. Les développeurs du système Coq ont choisi GALLINA pour
nom de ce langage de commandes. La syntaxe de ce langage est détaillée dans le manuel de
Coq [44]. Nous nous contentons d’aborder ici certains points liés à notre travail, à travers
une suite d’exemples.
L’assistant de preuve Coq utilise le langage Gallina dans lequel les définitions sont des
termes qui sont eux-mêmes typés, leurs types sont appelés Sortes. Coq fait la distinction
entre deux catégories de types : le type Prop pour les propositions (formules logiques)
et le type Set pour les types de données. Ces deux types sont aussi typés et leurs type
commun est nommé Type. La figure 2.1 illustre un résumé de la syntaxe de Coq pour les
propositions logiques et les quantificateurs. Comme il existe des fonctions prédéfinis on
cite : la fonction « if else » pour définir une condition, la fonction « match with » pour
21
définir les conditions multiples, la fonction « case » et la fonction « while ».
Figure 2.2 – Term de base
2.3.5.1 Types et sortes
Coq distingue deux sortes de base Set et Prop : le type Prop pour les propositions (for-
mules logiques) et le type Set pour les types de données. Ces deux types sont aussi typés
et leurs type commun est nommé Type.
Set : la sorte des types de données destinée à contenir tous les objets ayant un contenu
calculatoire
Prop : la sorte des propriétés, pour rôle de contenir tout ce qui a trait à la logique pure,
comme par exemple les justifications diverses, pré- et post- conditions, autrement dit tout
ce qui peut être ignoré pendant des calculs.
La commande ”Check” permet d’obtenir le type d’un objet en Coq :
Check nat.
nat
: set
Check le.
le
: nat− > nat− > P rop
Par exemple, la sorte de nat (type des naturels) est Set tandis que celui de la relation le
(inférieur ou égal à) entre deux naturels est Prop.
Check Set.
Set
: Type
22
Check Prop.
Prop
: Type
Check Type.
Type
: Type
Les types inductifs
Les types inductifs permettent de définir par récurrence des ensembles de termes. A chaque
type de données inductif correspond une structure de calcul, basée sur le filtrage et la
récursion.
Les fonctions récursives
Pour définir une fonction récursive dans Coq, l’utilisateur doit déterminer les valeurs prises
par la fonction dans un ordre précis qui suit l’ordre dans lequel sont construits les termes
des types inductifs. Pour les nombres naturels, par exemple, on est obligé de construire 0
avant (S 0), (S 0) avant (S (S 0)) et ainsi de suite.
Pour la définition d’une fonction récursive sur les naturels, on utilise la valeur (f 0) pour
définir la valeur (f (S 0)), la valeur (f (S 0)) pour définir la valeur (f (S (S 0))) et de
manière générale, on utilise la valeur (f n) pour définir la valeur (f (S n)). La construction
des fonctions récursives se fait dans Coq avec la commande ”Fixpoint”.
Exemple Soit la fonction récursive plus qui calcule la somme de deux nombres naturels
n et m :
F ixpointplus(nm : nat)structn : nat :=
matchnwith
|O => m
23
|Sp => S(pluspm)
end.
La syntaxe Fixpoint permet de définir un terme avec la construction fix du CCI. La re-
présentation interne d’un objet en Coq peut être obtenue en utilisant la commande ”Print” :
P rintplus.
plus =
f ixplus(nm : nat) : nat := matchnwith
|O => m
|Sp => S(pluspm)
end
: nat− > nat− > na
2.3.5.2 Les constantes
Comme la taille des spécifications en Coq augmente relativement vite, il est souhaitable
de pouvoir factoriser les parties communes de la spécification dans un alias. Cet alias est
une constante dans le système et est définie en Gallina par la syntaxe suivante :
Definition c := t.
c is defined
2.3.6 Tactiques de Coq
Le Système Coq est fourni avec un grand nombre de tactiques, nous présentons ci-dessous
quelques une de ces tactiques :
intro(s) : : la tactique intro permet d’introduire des hypothèses dans le contexte du but
courant et de transformer un but quantifié universellement en un but sans quantification
24
universelle.
apply terme : cette tactique essaie de faire correspondre le but courant avec la conclusion
du type de terme (un terme dans le contexte local). Si elle réussit, elle retourne autant de
sous buts qu’il y a de prémisses dans term.
left :Cette tactique permet de remplacer un but de la forme A B par un seul but de la
forme A. Lorsque on cherche à prouver une expression de la forme A B il suffit parfois de
prouver A. C’est cette étape de raisonnement qui est fournie par la tactique left.
right : le comportement de cette tactique est exactement symétrique de celui de la tactique
left. Elle permet de transformer un but de la forme A B en un but de la forme B.
induction term : elle permet de faire une preuve par induction. L’argument term doit
être une constante inductive. Cette tactique génère un sous but pour chaque constructeur
du type inductif concerné et remplace chaque occurrence de term dans la conclusion et les
hypothèses du but en rajoutant au contexte local des hypothèses d’induction.
Simpl : son but est d’appliquer des définitions pour simplifier des calculs.
2.3.7 Composition de tactiques
Coq propose une collection d’opérateurs permettant de composer les tactiques préexis-
tantes pour en former de nouvelles tactiques. Ces opérateurs sont appelés tacticielles. On
distingue deux variantes de composition :
• Composition simple : : la composition simple permet d’enchainer l’application de plu-
sieurs tactiques sans s’arrêter aux sous-buts intermédiaires, sous la forme tac1 ;tac2 ;... ;tacn.
• Composition généralisée : la composition généralisée notée tac [ tac1..tac2|...tacn]
s’apparente à la composition simple, excepté le fait que la tactique tac i s’applique au
i-ème sous-but(en supposant que la tactique tac engendre exactement n sous-buts).
2.3.8 Le lambda calcul en Coq
Le lamda-calcul a été inventé par le logicien américain Alonzo Church[45][46] dans les
années 1930, dans l’espoir de fournir un fondement au mathématiques plus simple que la
théorie des ensembles, et fondé sur la notion de fonction. Ce programme a échoué, car le
lamda-calcul a un pouvoir d’expression beaucoup plus faible ,en revanche, le lamda calcul
a exactement le même pouvoir d’expression que les machines de Turing par exemple, ce
qui en fait un bon choix pour fonder la notion de fonction calculable.
25
Les trois constructions principales du lamda-calcul sont :
- Si x est une variable, alors c’est également un lamda-terme ;
- Si x est une variable et u un lamda-terme déjà construit, alors lamdax.u est un lamda-
terme, nous appelons un tel lambda-terme une abstraction. Intuitivement, lamda x.u est
la fonction qui envoie x vers u ;
- Si u,v sont des lamda termes déjà construits, alors uv(la juxtaposition des termes) est
un lamda-terme, nous appelons un tel lamda-terme une application
2.3.8.1 calculs
On impose souvent au lamda-calcul un système de types. Il s’agit d’associer aux termes

du lamda-calcul un type. On impose ensuite de ne construire de termes que si on peut leur
associer un type. par exemple, le lamda-calcul simplement typé. On part d’un ensemble
de types atomiques et on type les termes du lamda-calcul à l’aide des règles suivantes :
La règle d’abstraction (Abs) autorise à former une fonction x.v d’un type U vers un
type V si on peut créer un terme v de type V en utilisant le terme x supposé de type U.
La règle d’application (App) autorise à appliquer un argument de type V à une fonc-

tion du type V vers le type T. On obtient alors un terme de type T.
26
2.3.9 les utilisations de Coq
l’assistant de preuve coq est utilisé dans :

1 - il est facile de traduire les programmes écrits en Gallina vers des programmes exécu-
tables .
2 - Coq a été utilisé dans différents domaines d’application. Comme exemple, il a été
utilisé pour certifier le compilateur du langage C.
3 - Coq, il est flexible puisqu’il se base sur le lambda calcul et le calcul d’ordre supérieur.
4 - il se base sur la preuve manuelle des utilisateurs et permet d’ajouter des tactiques afin
de faciliter l’automatisation de la preuve avec une interaction continue avec l’utilisateur.on
peut dire que Coq est un assistant de preuve interactif semi-automatique. En général,
5 - l’assistant de preuve Coq fait partie des assistants de preuve les plus utilisés . En plus
il est similaire à Hol, Agda et Isabelle.
2.4 conclusion
Dans ce chapitre nous avons rappelé l’importance de l’utilisation des techniques for-
melles,leurs différentes classifications de techniques de vérification formelle dans le cadre de
l’approche IDM ensuite nous avons présenté de maniéré plus détaille l’assistant de preuve
Coq .
27
Chapitre 3
L’IDM et la transformation des

graphes
3.1 Introduction
L’ingénierie dirigée par les modèles (IDM, ou MDE en anglais Model Driven Engineering)
est une méthodologie de développement logiciel qui permet aux entreprises d’économiser
beaucoup de temps et d’argent ainsi que de rationaliser leurs opérations. Grâce à la colla-
boration de toutes les parties au sein d’un même modèle, l’IDM améliore la coordination
entre les différentes parties prenantes, ce qui se traduit par une solution logicielle plus
robuste, avec moins des bugs donc, l’ingénierie dirigée par les modèles est parfaite pour
les entreprises ayant besoin de logiciels complexes et protégés contre les erreurs.
Ce chapitre se divise en deux grandes parties, dont nous proposons un tour d’horizon sur
l’IDM en mettant l’accent sur la transformation de modèles. Dans un premier temps, nous
entamons à décrire les concepts de base de l’IDM, en s’intéressant à l’architecture dirigée
par les modèles(MDA), en décrivant son processus et les différentes principales transforma-
tions existantes. Dans la deuxième partie de ce chapitre, nous passons en revue le principe
de la transformation des graphes, pour ensuite décrire les outils de transformation, en
choisissant l’outillage nécessaire pour nos transformations (TGG-Interpréter).
28
3.2 Présentation de l’IDM
L’IDM est une approche de développement logicielle proposée et soutenue par le groupe
OMG3. L’IDM se rapporte au développement de logiciels qui se réfère à une gamme d’ap-
proches de développement qui sont basées sur l’utilisation de la modélisation de logiciels
comme une forme primaire d’expression. Avec son développement rapide, l’IDM est devenu
une approche prometteuse du génie logiciel qui attire beaucoup d’attention dans l’indus-
trie et dans le milieu universitaire. Avec le développement de l’IDM, le modèle est devenu
le paradigme majeur par lequel l’industrie a apporté des améliorations significatives dans
le développement des systèmes complexes en fournissant les moyens permettant de passer
d’un niveau d’abstraction à un autre ou d’un espace de modélisation à un autre.
3.3 Concepts
La définition de l’IDM est basée sur trois notions clés : le modèle, Méta-Modèle et le
Méta-Méta-Modèle :
a- Modèles : Un modèle est un ensemble de faits caractérisant un aspect d’un système
dans un objectif donné. Un modèle représente donc un système selon un certain point de
vue, à un niveau d’abstraction facilitant la compréhension et la validation de cet aspect
particulier du système [47].
b- Un Méta-Modèle : Un Méta-Modèle définit l’ensemble des concepts, des relations et
des règles sémantiques régissant la manière dont les modèles peuvent être dénotés dans une
définition de langage particulière. Notez qu’un méta modèle peut également être vu comme
une syntaxe abstraite, qui peut être complétée par une ou plusieurs syntaxes concrètes (les
représentations graphiques ou textuelles que les concepteurs utilisent pour exprimer des
modèles dans ce langage) afin de fournir un langage de modélisation complet.
c- Un Méta-Méta-Modèle : Un Méta-Méta-Modèle est un modèle qui décrit un langage
de Méta-Modélisation, c’est-à-dire les éléments de modélisation nécessaires à la définition
des langages de modélisation. Il a de plus la capacité de se décrire lui-même.
29
3.4 Les standards liés à l’lDM
nous présentons dans cette section quelques standards de l’OMG relatifs à l’IDM :MOF
(Méta Objecte Facility), le standard pour la création de nouveaux langages de modélisa-
tion ; QVT (Query, Views, Transformation), le standard pour la modélisation des transfor-
mations de modèles ; UML (Unified Modeling Language), le standard pour la modélisation
orientée-objet ; XMI (XML Metadata Interchange), le standard afin de représenter les mo-
dèles sous forme de documents XML dont le but est toujours l’interopérabilité ; CWM
(Common Warehouse Metamodel),Metamodel), le standard pour la représentation des
techniques liées au entrepôts de données .
3.4.1 MOF :
Le MOF est un standard de l’Object Management Group (OMG) s’intéressant à la repré-

sentation des méta-modèles et leur manipulation. Ces fonctions ne sont pas limitées à des
modèles structurels, ou même à des modèles définis dans UML, des modèles de compor-
tement et des modèles de données participent également à cet environnement. D’autres
langages de modélisation (non seulment UML) peuvent participer aussi, tant qu’ils sont
basés-MOF.
3.4.2 QVT
Les transformations de modèles étant au coeur de l’IDM, un standard appelé QVT a été
défini afin de modéliser ces transformations. Ce standard décrit le méta-modèle qui per-
met d’élaborer des modèles de transformation. Nous pouvons citer comme exemple,une
transformation d’un diagramme de classes UML vers un schéma de base de données re-
lationnelle qui est élaborée sous le principe d’un modèle de transformation conforme au
méta-modèle QVT [48].
3.4.3 UML :
Uml est un langage visuel permettant de modéliser des systèmes à l’aide de diagrammes
et de textes. Les diagrammes UML sont regroupés dans deux classes principales :
30
* Les diagrammes dynamiques : regroupent les diagrammes de séquence, les dia-
grammes de communication (nouvelle appellation des diagrammes de collaboration d’UML),
les diagrammes d’activités, les machines à états, les diagrammes de vue d’ensemble d’in-
teraction, et les diagrammes de synchronisation.
* Les diagrammes statiques : regroupent les diagrammes de classes, les diagrammes
d’objets, les diagrammes de structure composite, les diagrammes de composants, les dia-
grammes de déploiement, et les diagrammes de paquetages.
3.4.4 XMI :
XMI est le langage d’échange entre le monde des modèles et le monde XML (eXten-
sible Markup Language). XMI décrit comment utiliser les balises XML pour représenter
un modèle UML en XML.Cette représentation facilite les échanges de données entre les
différents outils ou plateformes de modélisation.
3.4.5 CWM :
CWM définit à présent les méta-modèles les types d’entrepôts de données les plus impor-
tants (Relationnel, Objet, XML,etc.) en proposant ainsi des règles de transformation entre
ceux-ci. Les méta-modèles de données permettent la modélisation des ressources tels que
les bases de données relationnelles et les bases de données orientées objets [49].
3.5 Les approches de l’IDM :
Il existe différentes approches concrétisant différentes façons d’utiliser les modèles dans
leur processus de développement des systèmes. L’approche la plus connue et peut-être la
plus développée est l’approche MDA. Nous présentons cette approche dans la sous-section
suivante :
31
3.5.1 Architecture MDA
L’OMG a déjà défini plusieurs standards pour le MDA : nous en dressons ici une liste des
plus. La figure 3.1 illustre l’architecture du MDA
Niveau M3 (méta-méta-Niveau modèle) : Le niveau M3 définit les concepts, les at-
tributs et la relations pour les éléments de niveau M2, tandis que les éléments placés au
niveau M2 sont les instances des éléments au niveau M3. Dans ce niveau, l’OMG à défini
un langage qui est utilisé pour décrire tous les éléments du niveau M2, appelée (MOF).
Niveau M2 (méta-modèle) :Ce niveau représente les éléments du modèle au niveau
M1. Dans le cas d’un méta modèle tel que UML. Le niveau M2 définit les éléments valides
dans un modèle spécifique au niveau M1, alors que les éléments placés au niveau M1 sont
les instances des éléments au niveau M2.
Niveau M1(modèle) : Le niveau M1 définit les classifications des éléments au niveau
M0, alors que les éléments placés au niveau M0 sont les instances des éléments au niveau
M1.
Niveau M0 (réalité) : Niveau des instances des modèles. Il définit des informations pour
la modélisation des objets du monde réel.
Figure 3.1 – l’architecture du MDA [50]
32
3.5.2 Les modèles MDA
Le MDA propose quatre points de vue,des modèles d’exigences (CIM), d’analyse et de

conception (PIM), de code (PSM) et d’exécution (PDM).Nous donnons une brève descrip-
tion de chacun de ces modèles dans ce qui suit.
3.5.2.1 CIM :
Le CIM est l’abréviation anglaise de Computation Independent Model. Les exigences du

système sont modélisées dans ce modèle qui décrit la situation dans laquelle le système sera
utilisé, un tel modèle est parfois appelé Business Model ou Domain Model. Il ne montre
pas les détails de la structure du système. Typiquement ce modèle est indépendant de
l’implémentation du système. Le CIM correspond à la modélisation de l’entreprise sans
parler encore de système informatique[51].
3.5.2.2 PIM :
Le terme PIM est l’abréviation anglaise de Platform Independent Model. Cela signifie que
ce type de modèle n’a pas de dépendance Avec la plate-forme technique. Il décrit le sys-
tème mais ne montre pas les détails de son utilisation sur la plate-forme. Le PIM représente
ainsi le logique métier, spécifique au système, mais indépendant de la technique et de la
technologie. Le PIM correspond à la modélisation du système de manière indépendante à
la plate-forme [52].
3.5.2.3 PSM :
Le terme PSM est l’abréviation anglaise de Plate-forme Specific Model. Ce modèle décrit
les détails et les caractéristiques supprimés du PIM. Il doit être adapté pour spécifier l’im-
plémentation du système dans une seule et unique plateforme technologique.Il correspond
au modèle de conception et d’implémentation d’une application par rapport à une plate-
forme spécifique.
33
3.5.2.4 PDM :
Ce modèle est désigné par l’acronyme PDM pour Platform Description Model. Il corres-
pond à un modèle de transformation du PIM vers un PSM d’implémentation. L’architecte
doit choisir une ou plusieurs plates-formes pour l’implémentation du système avec les
qualités architecturales désirées. Ce modèle propre à la plate-forme est utile pour la trans-
formation du PIM en PSM. La démarche MDA est ainsi basée sur le détail des modèles
dépendant de la plate-forme. Il représente les particularités de chaque plate-forme. Il de-
vrait être fourni par le créateur de la plate-forme, le principe du processus MDA est montré
dans la Figure.3.2. [53]
Figure 3.2 – Principe du Processus MDA
3.6 Transformation de modèles
Une transformation de modèles est la génération d’un ou de plusieurs modèles cibles à

partir d’un ou de plusieurs modèles sources. Dans l’approche par modélisation, cette
transformation se fait par l’intermédiaire de règles de transformations qui décrivent la
34
correspondance entre les entités du modèle source et celles du modèle cible. En réalité, la
transformation se situe entre les méta-modèles source et cible qui décrivent la structure
des modèles cible et source. Le moteur de transformation de modèles prend en entrée un
ou plusieurs modèles sources et crée en sortie un ou plusieurs modèles cibles.
Une transformation des entités du modèle source met en jeu deux étapes. La première
étape permet d’identifier les correspondances entre les concepts des modèles source et
cible au niveau de leurs méta-modèles, ce qui induit l’existence d’une fonction de transfor-
mation applicable à toutes les instances du méta-modèle source. La seconde étape consiste
à appliquer la transformation du modèle source afin de générer automatiquement le mo-
dèle cible par un programme appelé moteur de transformation ou d’exécution. la figure
3.3 illustre ces deux étapes d’une transformation de modèles.
Figure 3.3 – la transformation de modèles [53]
En général, il existe trois types de transformations : les transformations verticales, les

transformations horizontales et les transformations obliques
Les transformations verticales : Ces transformations se jouent sur les niveaux d’abs-
tractions.Une transformation qui baisse le niveau d’abstraction est appelée un raffinement.
Une transformation qui élève le niveau d’abstraction est appelée une abstraction.
Les transformations horizontales : Ces transformations gardent le même niveau d’abs-
traction en modifiant les représentations d’informations du modèle source (ajout,peut être
l’ajout,la modification, la suppression ou la restructuration d’informations.
Les transformations obliques : Une transformation oblique combine une transforma-
tion horizontale et une verticale. C’est à dire elle sont le résultat de la combinaison des
35
deux premiers types de transformations.
3.6.1 Les Approches pour la transformation de modèles
Nous classons ces approches en deux grandes familles : les approches modèle à modèle et
les approches modèle à code. Pour chacune de ces deux catégories, on distingue plusieurs
sous-catégories. La figure.3.4 résume cette classification d’approches de transformation de
modèles.
3.6.1.1 Transformation de modèle vers modèle
Dans la catégorie de la transformation de modèle vers modèle. On peut globalement distin-

guer cinq types d’approches , nous distinguons : les approches relationnelles,à manipulation
directe, hybrides,à structure dirigée, à transformation de graphes.
• Approches relationnelles : Cette catégorie regroupe les approches déclaratives dans
lesquelles le concept principal est constitué par les relations mathématiques. En général,
les approches relationnelles peuvent être considérées comme une forme de résolution de
contraintes.
• Approches manipulant directement les modèles : Ces approches se basent sur
l’utilisation des langages de programmation où elles utilisent les APIs qui permettent de
manipuler la représentation interne des modèles. La combinaison JMI (Java Metadata In-
terface) et Java sont souvent utilisées dans la mise en œuvre de cette approche,axée sur la
structure est le cadre de transformation de modèle à modèle fourni par OptimalJ [54].
• Approches basées sur la structure : Les approches de cette catégorie comportent
deux phases distinctes : la première phase consiste à créer la structure hiérarchique du
modèle cible, alors que la deuxième phase définit les attributs et références dans la cible.
Le cadre général détermine la stratégie de planification et d’application. Les utilisateurs
ne sont concernés que par la fourniture des règles de transformation.
• Approches basées sur la transformation de graphes : Cette catégorie d’approches
de transformation de modèle s’appuie sur les travaux théoriques sur les transformations de
graphes. En particulier, cette catégorie fonctionne sur graphes typés, attribués ou étique-
tés qui peuvent être considérés comme des représentations formelles de modèles de classe.
36
Viatra [55], ATOM [56] et GrGen [57] sont des exemples.
• Approches hybrides Les approches hybrides combinent différentes techniques des
catégories précédentes. Les différentes approches peuvent être combinées en composants
séparés ou de manière plus fine, au niveau des règles individuelles. On peut notamment
retrouver des approches utilisant à la fois des règles à logique déclarative et des règles à lo-
gique impérative. ATL , ETL , QVTop et ModTransf sont des approches de cette catégorie.
3.6.1.2 Transformations Modèle à code
Dans cette catégorie, on retrouve les approches basées sur le parcours de modèles et celles
basées sur l’utilisation de templates.
• Approches basées sur le parcours de modèles : La transformation consiste à
fournir un certain mécanisme de parcours de la représentation interne du modèle source
et l’écriture du code dans un flux en sortie.
• Approches basées sur les templates : Ces approches sont les plus couramment
utilisées dans les outils MDA actuels de génération de code. Un template consiste en un
fragment de texte contenant des bouts de méta-code permettant :
• d’accéder aux modèles sources.
• d’effectuer une sélection de code.
• de réaliser des expansions itératives.
La structure du template est généralement très proche du code à générer. JET , Codagen
Architect , OptimalJ et ModTransf sont des exemples dans cette catégorie.
3.7 Transformation de graphes
Dans cette partie, nous allons présenter quelques notions sur les graphes, ensuite nous
allons décrire avec détaille les transformations et les grammaires de graphes.
3.7.1 Rappel sur les graphes
Un graphe est constitué d’un ensemble de sommets reliés par des arêtes, L’ordre d’un
graphe est le nombre de ses sommets. Le degré d’un sommet est le nombre d’arêtes dont
37
Figure 3.4 – les approches de transformation de modèle
le sommet est une extrémité.
3.7.1.1 Graphe orienté
Un graphe orienté G est un ensemble de sommets pouvant être connectés par des arcs.
Dans un graphe orienté, une arête est appelée arc. La figure3.5 représente exemple d’une
graphe orienté.
Figure 3.5 – graphe orienté
38
3.7.1.2 Graphe non orienté
Un graphe non orienté G est un ensemble de sommets pouvant être connectés par des
arêtes. On parlera de cycle au lieu de circuit, et de chaı̂ne au lieu de chemin. Un graphe
non orienté est connexe si tous ses sommets sont connectés, Sinon chaque groupe de som-
mets connectés forme une composante connexe du graphe. Un Arbre est un graphe non
orienté connexe sans Cycle. La figure 3.6 représente un graphe non orienté.
Figure 3.6 – graphe non orienté
3.7.1.3 Un sous graphe
Un sous-graphe d’un graphe G est un graphe G’ composé de certains sommets de G, ainsi

que toutes les arêtes qui relient ces sommets . La figure 3.7 illustre un exemple où le graphe
(b) est un sous-graphe du graphe (a)
3.7.1.4 Graphes étiquetés
Les graphes étiquetés sont des graphes orientés, dont les arcs possèdent des étiquettes. Si
toutes les étiquettes sont des nombres positifs, on parle de graphe pondéré. La figure.3.8
représente un exemple d’un graphe étiqueté.
39
Figure 3.7 – un sous-graphe
Figure 3.8 – graphes étiquetés
3.7.2 Grammaire de graphes
Une grammaire de graphe [58] est généralement définie par un triplet : GG = (P, S, T)
Où :
- P : ensemble de règles.
- S : un graphe initial.
- T : ensemble de symboles.
Une grammaire de graphes distingue les graphes non terminaux, qui sont les résultats
intermédiaires sur lesquels les règles sont appliquées, des graphes terminaux sur lesquels
on ne peut plus appliquer aucune règle. Ces derniers sont dans le langage engendré par
la grammaire de graphe. Pour vérifier si un graphe G est dans le langage engendré par
une grammaire de graphe, il doit être analysé. Le processus d’analyse va déterminer une
séquence de règles dérivant G.
L’application de R à un graphe G pour fournir un graphe H est appelée une dérivation
directe depuis G vers H à travers R .
40
3.7.3 Le principe de règles de transformation
Une règle de transformation de graphe est définie par : R = (L ;R ;K ; glue ; emb ;cond).Elle
consiste en :
1 - LHS(L) graphe de côté gauche, et RHS(R) graphe de côté droit .
2 - Un sous graphe K de L.
3 - Une occurrence glue de K dans R qui relie le sous graphe avec le graphe de côté droit.
4 - Une relation d’enfoncement emb qui relie les sommets du graphe de côté gauche et
ceux du graphe du côté droit.
5 - Un ensemble cond qui spécifie les conditions d’application de la règle.
3.7.4 L’application des règles
L’application d’une règle R = (L; R; K; F cond) à un graphe G produit un graphe résultant

H. Le graphe H peut être obtenu depuis le graphe d’origine G en passant par les cinq étapes
suivantes :
1 - le choix d’une occurrence du graphe du coté gauche LHS dans G, selon la règle à
appliquer.
2 - la vérification des conditions d’application selon la condition cond.
3 - la suppression de l’occurrence de LHS (jusqu’à K) de G ainsi que les arcs pendillés,
c’est-à-dire tous les arcs qui ont perdu leurs sources et/ou leurs destinations. Ce qui fournit
le graphe de contexte D de L qui a laissé une occurrence de K.
4 - Coller le graphe de contexte D et le graphe du coté droit RHS suivant l’occurrence de
K dans D et dans R. C’est la construction de l’union de disjonction de D et RHS et, pour
chaque point dans K, identifier le point correspondant dans D avec le point correspondant
dans RHS.
5 - l’enfoncement du graphe de coté droit dans le graphe de contexte de L suivant la
relation d’enfoncement emb.
L’application de R sur un graphe G pour fournir un graphe H est appelée une dérivation
directe depuis G vers H à travers R. Plusieurs formalismes permettent de représenter les
règles de transformation. Une transformation visuelle est illustrée dans la figure 3.9
41
Figure 3.9 – Application d’une règle de transformation
3.7.5 Système de transformation de graphes
On définit un système de transformation de graphes [58] comme un système de réécriture

de graphe qui applique les règles de la grammaire de graphe sur son graphe initial de façon
itérative jusqu’à ce que plus aucune règle ne soit plus applicable. La figure.3.10 illustre le
principe du système de réécriture de graphes.
Figure 3.10 – Système de réécriture de graphe
42
3.8 Outils et langage de transformation
De nombreux outils visent ou se reposent sur la manipulation de graphes, implémentant

en particulier des règles de réécritures. Parmi ces outils on peut par exemple citer :
3.8.1 Acceleo :
Acceleo est un langage de transformation de modèles pour lequel les modèles cible ont
une syntaxe concrète textuelle. Il suit une approche de transformation par template. Le
template correspond au modèle cible qui prend la forme d’un texte avec des espaces réser-
vés aux informations provenant des modèles source. Acceloo utilise OCL pour accéder au
modèles source.
3.8.2 AGG :
AGG (Attributed Graph Grammar)[59] est un outil de transformation de graphes déve-

loppé à la Technische Universität Berlin. Contrairement à d’autres outils de transforma-
tion. AGG propose deux modes d’exécution (pour l’application des règles de transforma-
tion) : le mode interactif et le mode interprète. Dans le premier mode, l’utilisateur peut
choisir les règles à appliquer, tandis que dans le second, le moteur de transformation choi-
sit les bonnes règles à appliquer. Dans ce cas, les règles de transformation peuvent être
classées par couches .
3.8.3 AtoM3 :
ATOM3 ”Domain Specific Visual Languages” [60] est un outil pour la conception de Do-
main Specific Visual Languages (DSML). Il permet de définir la syntaxe abstraite et
concrète d’un langage visuel au moyen de la métamodélisa- tion et d’exprimer la ma-
nipulation du modèle en utilisant la transformation de graphe. Avec les informations de
métamodèle, ATOM3 génère un environnement de modélisation personnalisé pour le lan-
gage décrit. Récemment, ATOM3 a été étendu avec des fonctionnalités pour générer des
environnements avec des vues multiples de langages visuels (tels que UML) et Triple Graph
43
Grammar (TGG) [61]. Ce dernier est utile pour exprimer l’évolution de deux modèles dif-
férents liés par un modèle intermédiaire
3.8.4 GROOVE :
GROOVE ”GRaph of Object Oriented VErification” est un outil d’usage général basé sur
la transformation de graphes pour modéliser la conception, la compilation et la struc-
ture d’exécution des systèmes orienté objet. La transformation de graphes avec GROOVE
se base sur la transformation de modèles et la sémantique opérationnelle. Cela implique
l’usage d’un fondement formel de transformation de modèles et de sémantique dynamique,
et aussi la capacité de vérifier la transformation de modèle en utilisant le model checking.
L’outil GROOVE a un éditeur pour la création des règles de production graphiques, un si-
mulateur pour calculer visuellement les transformations de graphe induit par un ensemble
de règles de production graphique .
3.8.5 GrGen :
GrGen est un outil de transformation de graphes utilisé dans différents domaines tels que
la transformation de données graphiques complexes, la linguistique informatique, ou la
construction de compilateur moderne. GrGen permet de travailler à un niveau très abstrait
en utilisant le modèle déclaratif. Le code généré par GrGen s’exécute très rapidement. En
termes de performance par rapport aux autres outils GrGen permet la manipulation et
la transformation des systèmes complexes. Le système GrGen est écrit en Java et C. Son
noyau est un générateur de grammaires de graphe.
3.8.6 TGG-Interpreter
L’approche des grammaires de graphes triples (Triple Graph Grammar : TGG), intro-
duite par Andy Schürr ) est une tentative de créer une méthode pour connecter différents
systèmes/modèles par rapport à certains règles/critères prédéfinis, de sorte que les change-
ments dans un système/modèle conduirait inévitablement à des changements dans l’autre.
TGG peut être utilisé dans différents transformation de modèles et les scénarios de syn-
44
chronisation. TGG est spécifié pour les transformations bidirectionnelles (transformation
à l’avant et en arrière). TGG est un triplet de grammaires de graphes où on a une gram-
maire de graphe source, une grammaire de graphe cible et une grammaire de graphe de
correspondance ainsi que deux morphismes le premier relie la grammaire de graphe source
et de correspondance et le deuxième relie la grammaire de graphe de correspondance et
cible.
L’avantage de TGG est permettant de faire la transformation de façons déclarative, et
l’exécution dans les deux sens. Lorsque l’un des modèles est modifié, l’autre peut être mo-
difié en conséquence, ce qui signifie que les transformations ou les synchronisations peuvent
être appliquées de manière incrémentielle.
3.8.6.1 Spécification des transformations
Modelware est l’espace technique des modèles, des méta-modèles et leurs transformations
dans l’IDM. Grammarware est l’espace technique des grammaires. Le pont technologique
sert à trouver une communication ou une connexion entre l’espace technique des modèles
et l’espace technique des grammaires. le méta-modèle a une relation avec le concept d’une
grammaire où un modèle conforme à un méta-modèle est comme une chaı̂ne reconnue par
une grammaire. En outre, les propriétés syntaxiques et sémantiques en relation avec la
conformité d’un modèle à un méta-modèle, peuvent être prises en considération dans la
sémantique d’une grammaire.
La figure.3.11 sert à lier l’espace technique de l’IDM et l’espace technique des gram-
maires, où la transformation d’un méta-modèle en une grammaire se fait d’une manière
automatique. Les deux méta-modèles source et cible sont transformé automatiquement
en grammaires de graphes qui permettent de créer d’une manière graduelle les règles de
transformation et aussi la grammaire de correspondance. Un moteur de transformation
sera généré à partir des correspondances, qui lient en entrée un modèle source et produit
en sortie un modèle cible.
Pour mieux comprendre l’approche TGG, nous détaillerons le formalisme TGG dans le
chapitre 4.
45
Figure 3.11 – Transformation dans les espaces techniques IDM et TGG
3.9 conclusion
Dans ce chapitre , nous avons exploré les composants de base des techniques MDE et ainsi
l’architecture MDA avec ces différents modèles, dabord nous avons présenté le concept
de transformation de modèles et Dans ce contexte, nous avons présenté les différentes
approches, méthodes et outils existants dans la littérature et plus précisément la transfor-
mation de graphes.
46
Chapitre 4
Contribution
4.1 Introduction
Dans ce chapitre, nous proposons notre approche intégrée qui sert à traduire des modèles
Ecore vers des spécifications formelles en langage Coq, en s’appuyant sur des règles de
réécriture de graphes.
Ce chapitre est structurée comme suit : la première partie est présentée un vue générale
de notre approche, après on définie la phase de Méta-Modèles (Ecore, Coq et la corres-
pondance entre les deux) qui sont implémentés par l’outil de la modélisation EMF. la
troisième partie nous spécifions toutes les règles TGG. Enfin en termine avec une etude
de cas sur exemple d’un Méta-Modèle.
4.2 Approche proposée
Dans notre approche qui illustrée dans la figure 4.1, nous définissons des règles de trans-
formation de graphes M2M au moyen de l’outil TGG-Interpreter, pour obtenir un langage
47
intermédiaire en XMI équivalent aux Méta-Modèle Ecore à transformer.
L’objectif de cette transformations est d’obtenir des spécifications formelles Gallina de
l’assistant de preuve Coq, elle est vérifiées par des preuves automatiques et interactives
au moyen de n’importe quel outil de vérification Coq.
Figure 4.1 – Approche proposée
4.2.1 Phase de Méta-Modélisation
La définition d’un langage de modélisation, nécessite non seulement d’une description de
sa syntaxe abstraite (éléments du langage, attributs, relations et contraintes), mais aussi
des informations propres à sa syntaxe concrètes (l’apparence graphique de ses éléments
et leurs relations). Dans cette phase de notre approche, nous avons utilisé un outils d’im-
plémentation pour la Méta-Modélisation. L’outil est celui du standard EMF (plug-in sous
Eclipse) qui a pour objectif de Méta-Modéliser les parties visées dans la première sous-
48
approche de transformation réalisée en TGG.
Grâce à l’outil standard de Méta-Modélisation EMF, nous implémentons les Méta-Modèles
pour :
les modèles sources constituant la partie LHS des règles de transformation TGG ; les
modèles cibles de ces règles (partie RHS), ainsi que ceux de la correspondance entre les
deux parties (LHS et RHS).Pour cela, nous proposons d’implémenter trois Méta-Modèles
suivant :
— Méta-Modèle Ecore.
— Méta-Modèle Coq.
— Méta-Modèle correspondance.
4.2.1.1 Méta-Modèle source
Le Méta-Modèle d’Ecore illustré dans la figure 4.2, se compose de vingt-deux classes
les classes SIAnnotations et SINamedElement et SIGtype hérite la classe SIMode-
leElement qui représente la classe mère du Méta-Modèle Ecore afin de pouvoir disposer
du même contenu statique et dynamique de celle-ci. SINamedElement désignant le nom
de chaque élément du Méta-Modèle, est seulement réalisée pour ne pas répéter l’attribut
nom au sein des autres classe)est dérivé à six sous classe :
— SIPackage : représente le point de dépare de notre travaille, désigne les packages
des modèle. Possède un nom (name)et ainsi un URI et Prefix pour l’identification
lors de la sérialisation.La class SIPackage dérivé de la classe SINamedElement.elle
Compose aussi des definition () SIDefinition.
— SIDefinition : Elle possède un nom et elle dérive à deux autre classe SIIndicti-
49
veGroupDefinition qui compose d’inductive(SIInductive),et SISimpleDefini-
tion.Cette dernière a un type (SItype).
— SItype : posséde aussi un nom et compose de trois classe : SIInductive et SI-
TypeDef et SIDatatype,Ces trois composants sont décrits comme suit :
— SIInductive : qui contient des constructors (SIConstructors).
— SIDatatype
— SITypeDef contient un type de SIGtype.
— SITypeParameter : possède un nom dérivé de la classe SINamedElement et
contient eBounds de SIGtype.
— SITypedElement : possède un nom dérivé de la classe SINamedElementonet
un type de SIGtype et dériver à SIParameter.
— SIConstuctor : countient un nom et parametre de SIParameter et son
type(SITypeParamete).
SIGtype dériver à cinq sous classe :
— SIGAnyType.
— SIGLowerBoundType : contient un eLowerBound de SIGtype.
— SIGUpperBoundType : contient un eUpperBound de SIGtype.
— SIGClassifierType : contient eArguments de SIGtype.
— SIGVariableType
50
Figure 4.2 – Méta-Modèle source (Ecore)
4.2.1.2 Méta-Modèle Ciple
Le Méta-Modèle Coq est illustré dans la figure 4.3. Elle compose de 19 classe, la classe
racine est appelée Fille qui caractériser par un nom et compose de commands de la classe
Command, cette dernière classe dériver on deux notre classe : Inductive ou Definition,
Inductive qui prend un nom, et un bodies de la classe InductiveBody. et Definition qui
caractériser aussi par un nom et un term de la classe Term et un binder de la classe
Binder.
51
InductiveBody prend comme un attribut un nom et peut contient des constuctors(classe
Constuctor) et un binder(classe Binder). La classe Constuctor caractériser par un
nom et un binder. Binder identifier (classe Ident par un nom et peut contient un type
de term).
cette dernière classe dériver on six classe : Sort( dériver on Set, Prop, Type) , Literal(
Z, String), Apply( contient un term right et un term left), Fun et Forall ( contient les
deux un binder et un term), Ident.
[1..1] term
Term
[1..1] left
[1..1] term
[1..1] right
[0..1] type
Sort Literal Apply Fun Forall
File Command
[0..*] commands
name : EString
[1..1] binder
Binder
[1..1] binder name : EString
[1..1] term
Inductive Definition Set Prop Type
[1..1] binder
name : EString name : EString Ident
[1..1] binder
Constructor
Z String name : EString
value : EInt value : EString [1..1] binder
[1..1] binder
[0..*] constructors
InductiveBody
name : EString
[1..*] bodies
Figure 4.3 – Modèle Cible (Coq)
52
4.2.1.3 Correspondance
Méta-Modèle illustré dans la figure 4.4 décrit la correspondance entre le Méta-Modèle
Ecore et Coq. Nous établissons cette correspondance par des nœuds additionnels qui se
rapportent à des éléments méta des deux Méta-Modèle source et cible. Ces nœuds de
correspondance signifient plus précisément la correspondance entre les parties LHS et
RHS dans chaque règle TGG, tous ces nœuds hériter la même racine Root qui indique que
les deux Méta-Modèles représentent un seul Méta-Modèle. ces nœuds sont :
— pkg2file() : pour exprimer la correspondance entre les racines des deux Méta-
Modèles de Ecore et de Coq (respectivement SIPackage et Fille).
— def2cmd() : désigne la correspondance entre SIDefinition et Command.
— ind2ind() : indique la correspondance entre SIInductiveGroupDefinition et
Inductive.
— simple2def() : exprime la correspondance entre SISimpleDefinition et Definition.
— typedef2def() : pour faire la correspondance entre SISimpleDefinition et De-
finition
— simple2ind() : indique la correspondance entre SISimpleDefinition et Induc-
tive.
— ind2body() : réalise la correspondance entre SIInductive et InductiveBody.
— ctor2ctor() : faire la correspondance entre SIConstructor et Constructor.
— makeBinder() : indique la correspondance entre SIDataType et Binder.
— makeBinder() : désigne la correspondance entre SIInductive et Binder.
— makeBinder() : pour décrire la correspondance entre SITypeDef et Binder.
53
— makeBinder() : signifie la correspondance entre SITypeParameter et Binder.
— makeBinder() : la correspondance entre SIParameter et Binder.
— typ2term() : décrit la correspondance entre SIGType et Term.
— typ2term() : exprime la correspondance entre SIGClassifierType et Term.
— typ2term() : pour faire la correspondance entre SIGVariableType et Ident.
— typ2term() : indique la correspondance entre SIGAnytype et Type.
— typ2term() : faire la correspondance entre SIGUpperBoundType et Term.
— typ2term() : désigne la correspondance entre SIGLowerBoundType et Type.
Figure 4.4 – Correspondance entre Ecore et Coq
54
4.2.2 Spécification des règles de transformation
Dans cette phase, nous proposons une grammaires de graphes pour la transformation des
Méta-Modèle Ecore vers Coq, cette grammaire est définie sous forme des règles TGG qui
implémentée sous l’outil TGG-Interpreter pour faire une transformation M2M vers un
langage intermédiaire représentant le langage Gallina(Coq) (transformation PIM-PSM)
exprimé en langage XMI à partir de Méta-Modéle source.
Dans la section suivantes, nous décrivons en détail ces règle de transformation.
4.2.2.1 Règle01 : Axiom
C’est la règle de départ de toute les règle de transformation qui nommée axiom dans TGG.
Cet axiom est montré dans la figure 4.5, sur la coté gauche (LHS) nous trouvons la racine
de Méta-Modèle source, et sur la coté droite (RHS) il y a la racine de Méta-Modèle cible,
et dans la partie médiane on trouve la correspondance entre les deux.
à partir de cette axiome, en transforme une SIPackage de partie LHS vers File de partie
RHS, et le nom de File dans le modèle de sortie prend le même nom(name)que le SIPackage.
55
Figure 4.5 – Règle TGG de Axiom
4.2.2.2 Régle02 : def2cmd()
nous réalisons le passage SIDefinition (LHS) vers Command (RHS)par quatre règles
sont : ind2ind,simple2def,simple2ind,typedef2def pour trouver la première qui est appli-
cable.
4.2.2.3 Régle03 : ind2ind()
SIInductiveGroupDefinition (LHS)de la Méta-Modèle Ecore est transformé formel-
lement en un type Coq (Inductive) (RHS) : le nom de l’Inductive prend le même nom
de l’attribut nom-classe SIInductiveGroupDefinition, cela est effectué à l’aide de l’ex-
pression OCL (sindi.name).la figure 4.6 montrée cette règle.
4.2.2.4 Régle04 : simple2def()
Selon la figure 4.7, SISimpleDefinition (LHS)de la Méta-Modèle Ecore est transformé
en Definition(RHS), le nom de Definition prend le méme nom de l’attribut nom-classe
SISimpleDefinition), le mot clé OclAsType (Dans le code QVT ) est utilisé pour
envoyer les caractéristiques de l’élément SIDataType.
56
Figure 4.6 – Règle TGG de ind2ind
Figure 4.7 – Règle TGG de simple2def
4.2.2.5 Règle05 :typedef2def()
Même principe de règle 04, sauf le mot clé OclAsType (Dans le code QVT ) est utilisé
pour envoyer les caractéristiques de l’élément SITypeDef.Cette règle est montré dans la
figure 4.8
57
Figure 4.8 – Règle TGG de typedef2def()
4.2.2.6 Règle06 :simple2ind()
La figure 4.9 représente la transformation SISimpleDefinition(LHS)de la Méta-Modèle
Ecore vers Inductive(RHS), le nom de Inductive prend le méme nom de l’attribut nom-
classe SISimpleDefinition).
Figure 4.9 – Règle TGG de simple2ind()
58
4.2.2.7 Régle07 : ind2body()
Dans la figure 4.10, SIInductive(LHS) de la Méta-Modèle Ecore est transformé en In-
ductive(RHS), le nom de InductiveBody prend le méme nom de l’attribut nom-classe
SIInductive.
Figure 4.10 – Règle TGG de ind2body()
4.2.2.8 Régle08 :ctor2ctor()
Selon la figure 4.11, SIConstructor(LHS)de la Méta-Modèle Ecore est transformé en
Constructor(RHS), le nom de Constructor prend le même nom de l’attribut nom-class
SIConstructor.
4.2.2.9 Régle09 : makeBinder()
Cette règle illustré dans la figure 4.12. exprime la transformation de la SIDataType dans
le Méta-Modèle Ecore (partie LHS) vers Binder (partie RHS), en ajoutons dans la partie
LHS eTypeParameters et type en partie RHS(Coq).
59
Figure 4.11 – Règle TGG de ctor2ctor()
Figure 4.12 – Règle TGG de makeBinder()1
Dans cette règle, la transformation de l’élément SIInductive(LHS) vers son équivalent
en Coq(Binder)(RHS), son principe et le même que la règle 08. la figure 4.13 montrée
cette transformation.
60
Cette règle qui est montré dans la figure 4.14 ,elle est comme objective de transformer en
Coq SITypeDef dans la partie LHS est transformé en Binder(RHS). en ajoutons le type
de Binder, et par la déclaration OCL le nom de Binder prend le même nom de l’attribut
nom-classe SITypeDef.
61
Cette règle est illustrée par la figure 4.15. Elle réalise la transformation de SITypePara-
meter (partie LHS) vers Binder(partie RHS) en spécifie formellement en Coq et utilisons
le même principe dans la règle précédant.
62
Cette règle est illustré dans la figure 4.16. Elle permet de transformé SIParameter vers
Binder. et par OCL le nom de Binder prend le même nom de l’attribut nom-classe
SIParameter.
4.2.2.14 Régle14 : typ2term()
nous réalisons le passage SIGType vers Term par les cinq règles de typ2term pour trouver
la première qui est applicable.
La figure 4.17 décrit cette règle qui réalise la transformation d’une classe SIGClassifier-
Type vers Term, et on ajoutons le successeur de Term (left et right).
63
Figure 4.17 – Règle TGG de typ2term()2
4.2.2.16 Régle16 :typ2term()
La figure 4.18 montré la règle de transformation de SIGVariableType dans la partie
LHS vers Ident dans la partie RHS, on utilisons le même principe de la règle précédant.
Dans cette règle qui illustrée dans la figure 4.19, on réalisée la transformation entre SI-
GAnyType vers Term.
4.2.2.18 Règle18 :typ2term()
L’idée de transformation est montrée dans la figure 4.20. Elle sert à la formalisation en
Coq de la partie LHS appelé SIGUpperBoundType vers Term de la partie RHS .
64
4.2.2.19 Règle19 : typ2term()
Selon la figure 4.21, cette règle est appliquée pour transformer SIGLowerBoundType
de la partie LHS vers Term de la partie RHS.
65
4.3 Etude de cas
Dans cette partie nous présentons une étude de cas d’un exemple de Méta-Modéle, afin
d’illustrer notre approche de transformation et pour pouvoir concrétiser l’utilité de la
66
grammaire définie qui a était proposé dans cet chapitre. en suivant tous les règles de
transformation.
Figure 4.22 – Exemple
67
4.3.1 Etapes d’exécutions sur le fichier XMI
Premièrement, on sélectionne le fichier Exemple.Xmi() et le fichier pkg2file.tgg avec un
clic droit en choisissant TGG-Interpreter forward transformation interpreter configuration,
ensuite choisissant correspondance (used packages :correspondance) et avec ça on arrive à
la création de fichier Exemple :interpreterconfiguration montré dans la 4.23.
Figure 4.23 – le fichier Exemple.interpreterconfiguration.
Lors de l’application des règles proposées dans notre approche sur le fichier
Exemple.interpreterconfiguration, on obtient le fichier XMI(c’est une partie d’xmi).
68
Figure 4.24 – fenetre de terminaison d’execution de transformation des règles avec succés.
4.3.2 Les fichiers résultats
69
4.4 Conclusion
Dans ce chapitre, Nous avons proposé une approche intégrée Ecore/Coq pour la modéli-
sation et la transformation d’un modèle Ecore vers la spécification Coq en Eclipse .
L’implémentation de cette approche nécessite l’utilisation de la plateforme Eclipse Mo-
deling Framework (EMF) pour mettre en œuvre les Méta-Modèles, les modèles et les
transformations à partir de l’outil TGG Interpreter, en utilisons la notion de grammaire
de graphes TGG .
Dans ce chapitre, nous avons transformer le modèle Ecore vers Coq,danc nous avons in-
tégré un langage de méta-métamodélisation avec une méthode formelle dans le but de la
vérification des applications.
Finalement, nous avons donné une étude de cas pour illustrer cette transformation.
70
Conclusion Général
Le travail que nous avons présenté est se concentre sur le cadre de la modélisation et la
vérification et validation qui basé sur le principe de l’Ingénierie Dirigé par les Modèle,
ce dernier joue un rôle centrale sur le développement logicielle et elle a plusieurs avan-
tage dans la production et la maintenance des Système, elle n’est intéressante que si la
transformation de modèle qui occupe place très important est partiellement ou complète-
ment automatisée dans le processus de développement. Cette transformation basé sur des
langage et des outils son rôle principale est de faciliter le concept de programmation et
minimiser le cout de développement
Dans cette recherche nous avons contribué au développement contenant deux apparences
Ecore et Coq par la définition de règles de transformation de graphes en se basant sur
l’approche MDA. Notre utilisation de la théorie de transformation de graphes permettant
de transformer le Ecore vers Coq, se justifie par son caractère intuitif et algébrique en
même temps.
Le résultat de notre travail est une approche automatique pour cette transformation , l’
approche est intégré sur le plateforme EMF telle que les deux Méta-Modèle source(Ecore)
et Ciple(Coq) est implémenter en EMF, les règles de transformation proposées servant en
l’automatisation de la traduction d’Ecore à son équivalent Coq, la transformation faite

par TGG-Interpretre (transformation bidirectionnelle) en appliquons 19 règle . L’étude de
la conformité des modèle en utilisant la langage OCL, l’utilisation de ce langage permet
d’ajouter un aspect formel à la sémantique de Méta-Modèle.
Les travaux accomplis durant ce projet de recherche ouvrent un certain nombre de Perspec-
tives, qui liée à la transformation des modèle, nous avons proposée quelque développements
possibles :
1. Réaliser la transformation modèle vers texte (M2T) des modèles Coq qui générés a
partir de langage intermédiaire en XMI de la spécification Coq. Cette étape peut
être réalisé avec l’outil Xpand.
2. Notre approche permet de faite le passage entre Ecore et Coq,ce dernier elle nous a
permis de réaliser des preuves et de trouver des erreurs. parfois les changements sur
la spécification de départ doivent être effectués à la main malgré la bidirectionnalité
de notre approche, il serait très important de compléter notre approche par des
techniques permettant aux utilisateurs de revenir en arrière.
3. Dans les travaux futurs, nous étudierons comment du Méta-Modèle Ecore peut être
automatiquement dérivé de telles infrastructures, de manière à ce que l’ingénierie
dirigée par les modèles s’intègre mieux aux assistants de preuve.
72
Bibliographie
[1] Christel Baier and Joost-Pieter Katoen. Principles of Model Checking. The MIT
Press.Cambridge, Massachusetts, London, England.
[2] Francisco José CHÁVES ALONSO. Utilisation et certification de l’arithmé- tique d’in-
tervalles dans un assistant de preuves. École Normale Supérieure de Lyon. Septembre
2007.
[3] The HOL Light theorem prover. http ://www.cl.cam.ac.uk/users/jrh/hol- light
[4] The Coq Proof Assistant Reference Manual - Version 8.2. Technical report, INRIA,
September 2008. http ://coq.inria.fr.
[5] MFGraphical Modeling Framework (GMF, Eclipse Modeling subproject),
http ://www.eclipse.org/gmf/
[5] TGG interpreter. Site web : http ://www-old.cs.uni-paderborn.de/en/research-
group/softwareengineering/research/projects/tgg-interpreter.html, (Consulté No-
vembre 2017).
[6] AGG. . . Taentzer, G : AGG : A Graph Transformation Environment for Modeling and
Validation of Software. Application of Graph Transformations with Industrial Rele-
vance (AGTIVE’03), Vol. 3062, Springer LNCS, 2004.
73
[7] Atom3. . . .de Lara, J., Vangheluwe, H., Alfonseca, M. : Meta-Modelling and Graph
Grammars for Multi-Paradigm Modelling in AToM3. Software and System Modeling,
3(3), 2004, pp. 194–209
[8] Vietra2. . . Visual Automated Model Transformations (VIA-
TRA2), GMT subproject, Budapest University of Technology
and Economics. http ://dev.eclipse.org/viewcvs/indextech.cgi/gmt-
home/subprojects/VIATRA2/index.html.
[9] Thèse de Doctorat en Sciences Présentée par ”Seidali REHAB” « Une approche de
transformation des diagrammes UML vers les spécifications B» .
[10] livre « Éclipse » Steve Holzner, l’édition générale de ce livre(ISBN 0-596—00641-
1).O’REILLY MEDIA Inc, 2004.
[11] EMF : Éclipse Modeling Framework. « Dave Steinberg ; Frank Budinsky ; Marcelo
Paternostro ; Ed Merks », Second Edition, Addison-Wesley Professional. December
16, 2008.
16, 2008.
16, 2008.page31. [
[14] ] Éclipse Platform Technical Overview.” Object Technology International, Inc. Fe-
bruary 2003, http ://www.eclipse.org/whitepapers/eclipse-overview.pdf.
74
[15] MOF. . . .Meta-Object Facility (MOF), http ://www.omg.org/mof/
[16] omg .Meta Object Facility (MOF)Query/View/Transformation Specification Version
1.0 http ://www.omg.org/spec/Qvt/1.0/PDF.avril 2008.
[17] OMG. UML Profil for COBRA, v1.0. 2002.
[18] : Eclipse Modeling Framework. « Dave Steinberg ; Frank Budinsky ; Marcelo Pater-
nostro ; Ed Merks », Second Edition, Addison-Wesley Professional. December 16, 2008
[19] Wirsing M. Wirsing. Algebraic Specification. Volume B of Handbook of Theoretical
Computer Science. Chapter 13.,V. Leeuwen. vol. B. Elsevier, 1990.
[20] Hoare C. A. R. Hoare. Communicating Sequential Processes. International Series en
Computer Science. Prentice-Hall, 1985. ISBN : 0-13-153289-8.
[21] Milner 89 R. Milner. Communication and Concurrency. C.A.R. Hoare Series. Prentice-
Hall International, 1989.
[22] T. Murata, Petri nets : Properties, Analysis and Applications, In Proceedings of the
IEEE,Vol. 77, No 4, April 1989.
[23] J. Cliff, Systematic Software Development Using VDM, Prentice-Hall ISBN 978-
0138807252, 1986.
[24] C. B. Jones and C. A. R. Hoare. Systematic Software Development using VDM. 2
edition. Prentice Hall, 1990.
[25] J. M. Spivey. The Z Notation : A Reference Manual. Prentice Hail International Series
in Computer Science, 2nd edition, 1992. ISBN 013-978529-9.
75
[26] J. Christian Attiogbé, Contributions aux approches formelles de développement de
logiciels : Intégration de méthodes formelles et analyse multifacette, In HDR, Université
de Nantes, Nantes Atlantique Université, 13 septembre 2007.
[27] J.P. Finance, N. Levy, Souquières and A. Valdenaire. SACSO : un environnement
d’aide à la spécification. Technique et Science Informatique, 9(3) :245-261, 1990.
[28] J. V. Guttag. The Larch Approach to Specification. VDM ’91 : Formal Software
DevelopmentMethods. Springer-Verlag, 1991, pp. 10.
[29] D. Bert and P. Drabik. LPG : structuration des spécifications et validation sémantique
automatisée. IMAG RR 648-I-IMAG, 1987.
[30] J.A. Goguen and G. Malcolm. Algebraic Semantics of Impertive Programs. MIT Press,
1996. ISBN : 0-262-07172-X.
[31] N. Shankar, S. Owre, and J. M. Rushby. PVS Tutorial. Computer Science Laboratory,
SRI International,Menlo Park, CA, February 1993. Also appears in Tutorial Notes,
FormalMethods Europe ’93, Odense, Danmark, April 1993., 1993.
[32] L. C. Paulson. Isabelle : A Generic Theorem Prover. Numéro 828 in LNCS. Springer
Verlag, 1994.
[33] G. Smith, F. Kammuller and T. Santen, Encoding Object-Z in Isabelle/HOL, In la
revue Lecture Notes in Computer Science, vol.2272, pp.82-99, 2002.
[34] G. Huet, G. Kahn, and c. Paulin-Mohring. The Coq Proof Assitant : A Tutorial. Coq
Project. Release 6.3.1., December 1999.
[35] G. Behrmann, A. David and K. G. Larsen. A tutorial on UPPAAL, In Proceedings
on the International School on Formal Methods for the Design of Computer, Commu-
76
nication, and Software Systems, volume 3185 of Lecture Notes in Computer Science,
pages 200-236, Bertinora, Italy, Springer-Verlag.2004.
[36] J. Christian Attiogbé, Contributions aux approches formelles de développement de
logiciels : Intégration de méthodes formelles et analyse multifacette, In HDR, Université
de Nantes, Nantes Atlantique Université, 13 septembre 2007.
[37] K. J. Turner, Representing and analysing composed web services using CRESS, in
Journal of network and computer applications, ISSN 1084-8045 vol. 30, n 2, pp. 541-
562, 2007.
[39] . T. Truong, Utilisation de B pour la vérification de spécifications UML et le dévelop-
pement formel orienté objets, Dans la thèse de doctorat en Informatique de l’Université
Nancy2, au LORIA à Vandoeuvre, 2006.
[38] N. T. Truong, Utilisation de B pour la vérification de spécifications UML et le dévelop-
pement formel orienté objets, Dans la thèse de doctorat en Informatique de l’Université
Nancy2, au LORIA à Vandoeuvre, 2006.
[39] R.Milner, ”A calculus of communicating systems”, in LectureNotes in Computer
Science, vol.92, Springer-Verlag, Berlin, 1980.
[40] N. Charles, H. Bowman and S. J. Thompson, ”FromAct-one toMiranda, a Translation
Experiment”, In Computer Standards and Interfaces Journal, 19(1), May 1997.
[41] Thierry Coquand and Gerard Huet. The calculus of constructions. Information and
computation, 76(2) :95–120, 1988.
[42] The Coq Proof Assistant Reference Manual - Version 8.2. Technical report, INRIA,
September 2008. http ://coq.inria.fr.
77
[43] Tomasz BLANC. Propriétés de sécurité dans le lambda-calcul. Thèse de doctorat.
Ecole polytechnique. Novembre 2006.
[44] Nicolas OURY. Egalité et filtrage avec types dépendants dans le calcul des construc-
tions inductives. Thèse de doctorat. Université de Paris XI Orsay. Sepembre 2006.
[45] Jean-Marc Jezequel, Benoit Combemale et Didier Vojtisek. Ingénierie dirigée par les
modèles : des concepts à la pratique. Editions ellipses, Paris, 2012.
[46] OMG-QVT 2.0 08, Transformation Spec, http
[47] OMG-CMW03, http ://www.omg.org/cwm, 2003 ://www.omg.org/spec/QVT/1.0/PDF/,
Avril 2008
[48] NGUYEN Viet HOA, Capitalisation des architectures métiers pour une implémenta-
tion sur Différentes plates –formes techniques en utilisant la démarche MDA, Hanoı̈,
Juin 2008.
[51] ean Bézivin 2003. La transformation de modèles. INRIA-ATLAS, Université de
Nantes.
[49] TOPCASED-WP5, staff, Guide méthodologique pour les transformations de mo-
dèles.Rapport de recherche, version 0.1, 18 Novembre 2008, IRIT/MACAO
[50] VIATRA. Web site. http ://www.eclipse.org/gmt/VIATRA2/.
[51] ATOM3. Web site. http ://atom3.cs.mcgill.ca/. MSDL : Modelling, Simulation and
Design Lab.
[52] GrGen. Web site. http ://www.info.uni-karlsruhe.de/software/grgen/.
[53] GrGen. Homepage. http ://www.info.uni-karlsruhe.de/software/grgen/ .
[54] ATLAS Group et al. ATL User Manual Version 0.7, 2006. LINA , INRIA.
78
[55] Marc Andries, Gregor Engels, Annegret Habel, Berthold Hoffmann, Hans-Jorg
Kreowski, Sabine Kuske, Detlef Pump, Andy Schürr and Gabriele Taentzer, ”Graph
transformation for specification and programming”, Science of Computer programming,
vol 34, NO 1, pages 1-54, Avril 1999.
[56] Gabriele Taentzer. AGG : A tool environment for algebraic graph transformation.
In Applications of Graph Transformations with Industrial Relevance. Springer, 2000.
[57] ATOM3. Web site. http ://atom3.cs.mcgill.ca/. MSDL : Modelling, Simulation and
Design Lab.
79

Projet

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Projet

Transféré par

Droits d'auteur :

Formats disponibles

République Algérienne Démocratique et Populaire Ministère de

l’enseignement Supérieur et de la Recherche Scientifique Université

Faculté des Nouvelles Technologies de l’Information et de la Communication

Génération automatique des types

Session : juillet 2019

Nous tenons premièrement à remercier Dieu le tout puissant, qui nous a

donné la force et la patience d’accomplir ce modeste mémoire.

nous tenons à exprimer nos profonde gratitude à Allaoua CHAOUI ,

Professeur à l’Université de Constantine 2 – ABDELHAMID MEHRI , pour

son encadrement et ses conseils précieux.

Nos remerciement s’adresse à Mr Rehab SeidAli pour sa patience, sa

rigueur et sa disponibilité durant notre préparation de ce mémoire.

On remercie aussi Mr Jérémy BUISSON, pour son aide pratique .

Nos remerciements les plus distinguées vont également aux membres du

jury pour l’intérêt qu’ils ont porté à notre recherche en acceptant

d’examiner notre travail et de l’enrichir par leurs propositions.

participé de près ou de loin à la réalisation de ce modeste travail.

Model Driven Engineering(MDI), Ecore Méta-Modèle, Coq, Gallina / Vernacular language,

— AGG : Attributed Graph Grammar.

Table des matiéres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IX

Table des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XII

Intrudction Générale XIII

1 EMF Eclipse Modeling Framework 1

1.2 Généralité sur Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Eclipse Modeling Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3.2 Organisation d’EMF dans la plate-forme d’intégration . . . . . . . . 3

1.3.3 Fonctionnalités du Framework EMF . . . . . . . . . . . . . . . . . . 4

1.3.4 Les Étapes de modélisation avec EMF . . . . . . . . . . . . . . . . . 5

1.3.5 Objectif d’EMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.6 Eclipse Modeling Framework et UML . . . . . . . . . . . . . . . . . 6

1.3.7 Architecture d’EMF . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.1.1 Langage OCL . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.4.2 La hiérarchie des classes Ecore . . . . . . . . . . . . . . . . . . . . . 10

1.4.3 Représentation textuelle pour les Méta-Modèles . . . . . . . . . . . 13

2 les méthodes formelles et Coq 14

2.2 Les Méthodes Formelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.1 les avantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.2.1 Approches orientées états : . . . . . . . . . . . . . . . . . . 15

2.2.2.2 Approche axiomatique : . . . . . . . . . . . . . . . . . . . . 17

2.2.2.3 l’approche hybride : . . . . . . . . . . . . . . . . . . . . . . 17

2.2.3 techniques pour la preuve de propriétés . . . . . . . . . . . . . . . . 17

2.2.3.2 Preuve de théorèmes . . . . . . . . . . . . . . . . . . . . . . 18

2.3 L’assistant de preuve Coq . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.2 domaines d’application . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.3 comparaison des différents assistants de preuves . . . . . . . . . . . 20

2.3.4 Vérification du programme en Coq . . . . . . . . . . . . . . . . . . . 21

2.3.5.1 Types et sortes . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.5.2 Les constantes . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3.6 Tactiques de Coq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.3.7 Composition de tactiques . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3.8 Le lambda calcul en Coq . . . . . . . . . . . . . . . . . . . . . . . . 25

2.3.9 les utilisations de Coq . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 L’IDM et la transformation des graphes 28

3.2 Présentation de l’IDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.4 Les standards liés à l’lDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5 Les approches de l’IDM : . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5.1 Architecture MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.5.2 Les modèles MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.6 Transformation de modèles . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.6.1 Les Approches pour la transformation de modèles . . . . . . . . . . 36

3.6.1.1 Transformation de modèle vers modèle . . . . . . . . . . . 36

3.6.1.2 Transformations Modèle à code . . . . . . . . . . . . . . . . 37

3.7 Transformation de graphes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.7.1 Rappel sur les graphes . . . . . . . . . . . . . . . . . . . . . . . . . . 37