Outils et techniques pour la spécification d’un DSML

Télécharger le fichier pdf d’un mémoire de fin d’études

Les principes généraux de l’IDM

Suite à l’approche objet des années 80 et de son principe du « tout est objet », l’ingénierie du logiciel s’oriente aujourd’hui vers l’ingénierie dirigée par les mo-dèles (IDM) et le principe du « tout est modèle ». Cette nouvelle approche peut être considérée à la fois en continuité et en rupture avec les précédents travaux [Béz04b, Béz05]. Tout d’abord en continuité car c’est la technologie objet qui a déclenché l’évolution vers les modèles. En effet, une fois acquise la conception des systèmes informatiques sous la forme d’objets communicant entre eux, il s’est posé la question de les classifier en fonction de leurs différentes origines (objets métiers, techniques, etc.). L’IDM vise donc, de manière plus radicale que pouvaient l’être les approches des patterns [GHJ95] et des aspects [KLM+97], à fournir un grand nombre de modèles pour exprimer séparément chacune des préoccupations des utilisateurs, des concepteurs, des architectes, etc. C’est par ce principe de base fondamentalement différent que l’IDM peut être considérée en rupture par rapport aux travaux de l’approche objet.
Alors que l’approche objet est fondée sur deux relations essentielles, « Instan-ceDe » et « HériteDe », l’IDM est basée sur un autre jeu de concepts et de relations. Le concept central de l’IDM est la notion de modèle pour laquelle il n’existe pas à ce jour de définition universelle. Néanmoins, de nombreux travaux s’accordent à un relatif consensus d’une certaine compréhension. A partir des travaux de l’OMG 2, de Bézivin et al. [BG01] et de Seidewitz [Sei03], nous considérerons dans la suite de cette thèse la définition suivante d’un modèle.
Définition (Modèle) Un modèle est une abstraction d’un système, modélisé sous la forme d’un ensemble de faits construits dans une intention particulière. Un mo-dèle doit pouvoir être utilisé pour répondre à des questions sur le système modélisé.
On déduit de cette définition la première relation majeure de l’IDM, entre le modèle et le système qu’il représente, appelée représentationDe dans [AK03, Béz04a, Sei03], et nommée µ sur la figure 2.1.
Notons que même si la relation précédente a fait l’objet de nombreuses ré-flexions, il reste toutefois difficile de répondre à la question « qu’est ce qu’un bon modèle ? » et donc de formaliser précisément la relation µ. Néanmoins un modèle doit, par définition, être une abstraction pertinente du système qu’il modélise, c.-à-d. qu’il doit être suffisant et nécessaire pour permettre de répondre à certaines questions en lieu et place du système qu’il représente, exactement de la même fa-çon que le système aurait répondu lui-même. Ce principe, dit de substituabilité, assure que le modèle peut se substituer au système pour permettre d’analyser de manière plus abstraite certaines de ses propriétés [Min68].
Définition (Principe de substituabilité) Un modèle doit être suffisant et nécessaire pour permettre de répondre à certaines questions en lieu et place du système qu’il est censé représenté, exactement de la même façon que le système aurait répondu lui-même.
Sur la figure 2.1, nous reprenons l’exemple utilisé dans [FEB06] qui s’appuie sur la cartographie pour illustrer l’IDM. Dans cet exemple, une carte est un modèle (une représentation) de la réalité, avec une intention particulière (carte routière, administrative, des reliefs, etc.).
La notion de modèle dans l’IDM fait explicitement référence à la notion de langage bien défini. En effet, pour qu’un modèle soit productif, il doit pouvoir être manipulé par une machine. Le langage dans lequel ce modèle est exprimé doit donc être clairement défini. De manière naturelle, la définition d’un langage de modélisation a pris la forme d’un modèle, appelé métamodèle.

L’approche MDA

Le consensus sur UML fut décisif dans cette transition vers des techniques de production basées sur les modèles. Après l’acceptation du concept clé de mé-tamodèle comme langage de description de modèle, de nombreux métamodèles ont émergés afin d’apporter chacun leurs spécificités dans un domaine particulier (développement logiciel, entrepôt de données, procédé de développement, etc.). Devant le danger de voir émerger indépendamment et de manière incompatible cette grande variété de métamodèles, il y avait un besoin urgent de donner un cadre général pour leur description. La réponse logique fut donc d’offrir un langage de définition de métamodèles qui prit lui-même la forme d’un modèle : ce fut le mé-tamétamodèle MOF (Meta-Object Facility) [OMG06b]. En tant que modèle, il doit également être défini à partir d’un langage de modélisation. Pour limiter le nombre de niveaux d’abstraction, il doit alors avoir la propriété de métacircularité, c.-à-d. la capacité de se décrire lui-même.
Définition (Métamétamodèle) Un métamétamodèle est un modèle qui décrit un langage de métamodélisation, c.-à-d. les éléments de modélisation nécessaires à la définition des langages de modélisation. Il a de plus la capacité de se décrire lui-même.
C’est sur ces principes que se base l’organisation de la modélisation de l’OMG généralement décrite sous une forme pyramidale (cf. figure 2.2). Le monde réel est représenté à la base de la pyramide (niveau M 0). Les modèles représentant cette réalité constituent le niveau M 1. Les métamodèles permettant la définition de ces modèles (p. ex. UML) constituent le niveau M 2. Enfin, le métamétamodèle, unique et métacirculaire, est représenté au sommet de la pyramide (niveau M 3).
L’approche consistant à considérer une hiérarchie de métamodèles n’est pas propre à l’OMG, ni même à l’IDM, puisqu’elle est utilisée depuis longtemps dans de nombreux domaines de l’informatique. Chaque hiérarchie définit un espace technique [KBA02, BJRV05, BK05]. Nous distinguons par exemple le modelware (espace technique des modèles), le grammarware (espace technique des grammaires définies par les langages tels que BNF 3 ou EBNF 4), le BDware (espace technique des bases de données), etc.
Définition (Espace technique) Un espace technique est l’ensemble des outils et techniques issus d’une pyramide de métamodèles dont le sommet est occupé par une famille de (méta)métamodèles similaires [FEB06].
L’OMG a défini le MDA (Model Driven Architecture) en 2000 [Sol00] pour promulguer de bonnes pratiques de modélisation et exploiter pleinement les avan-tages des modèles. En 2003, les membres ont adopté la dernière version de la spéci-fication [MM03] donnant une définition détaillée de l’architecture. Cette approche vise à mettre en valeur les qualités intrinsèques des modèles, telles que pérennité, productivité et prise en compte des plateformes d’exécution. Le MDA inclut pour cela la définition de plusieurs standards, notamment UML, MOF et XMI 5.
Le principe clé et initial du MDA consiste à s’appuyer sur le standard UML pour décrire séparément des modèles pour les différentes phases du cycle de dé-veloppement d’une application. Plus précisément, le MDA préconise l’élaboration de modèles (cf. figure 2.3) :
– d’exigence (Computation Independent Model – CIM) dans lesquels aucune considération informatique n’apparait,
– d’analyse et de conception (Platform Independent Model – PIM),
– de code (Platform Specific Model – PSM).

Historique des procédés de développement

Dans le domaine du génie logiciel, il est depuis longtemps reconnu qu’une application est un produit manufacturé complexe dont la réalisation doit s’inté-grer dans une démarche méthodologique : le procédé de développement 1. Pour améliorer la qualité du produit développé, il est important de maîtriser son pro-cédé de développement dont la problématique s’apparente à celle du logiciel lui-même [Ost87, Est05]. Plusieurs cycles de vie du logiciel (Software Development Life Cycle – SDLC) ont été proposés comme le cycle en cascade [Roy87], en spi-rale [Boe86] ou incrémental. Cependant, la communauté de la modélisation des procédés logiciels n’a pas été satisfaite de l’utilisation de ces descriptions de cycles de vie. La granularité des SDLC n’est pas assez fine et ne permet pas de décrire les parties élémentaires du procédé [CKO92]. Rapidement, le besoin a émergé de décrire avec plus de détails les procédés actuellement suivis pour le développement ou la maintenance de logiciel. L’idée a été de détailler la description de ces SDLC par les informations qui fournissent plus d’aide pour exécuter un projet de développement logiciel. Ces travaux ont permis de faire apparaître la notion de modèle de procédé (Process Model – PM). Dans les années 90, de nombreux travaux ont porté sur la modélisation de ce procédé à des fins de compréhension, d’évaluation, d’amélioration ou d’exécution. De nombreux AGL-P, Ateliers de Génie Logiciel centré Procédé, ont été propo-sés. Il s’agit alors de piloter un développement réel en fonction d’un procédé de développement défini dans un langage dédié [BEM94, CHL+94a, BFL+95, CC97, Bre02].
Les procédés peuvent être exprimés sous la forme d’un modèle décrit selon un langage de modélisation de procédé (Process Modeling Language – PML). Un mo-dèle de procédé est une représentation des activités du monde réel. Le modèle de procédé est développé, analysé, raffiné, transformé et/ou exécuté conformément au métamodèle du procédé. Les PML et leurs Environnements de Génie Logiciel Sen-sibles au Procédé (PSEE) peuvent être classés en trois catégories suivant l’élément central du modèle de procédé :
– Les PML centrés Produits se concentrent surtout sur les données échangées, et ont développé d’importantes propriétés concernant ces données (données orientées objet, transactions, persistance, versionnement, etc.). Ces PML ont eu beaucoup de succès dans l’industrie, surtout dans le domaine de la gestion de configuration. Nous citons par exemple les systèmes ADELE [BEM94] et EPOS [CHL+94b].
– Les PML centrés Rôles mettent l’accent sur les rôles et leurs collaborations. Ces PML ont surtout eu du succès dans le domaine du travail coopératif.
– Les PML centrés Activités s’appuient sur les activités qui représentent les tâches à réaliser. Cette catégorie a eu beaucoup de succès dans le domaine de la recherche (p. ex. SPADE [BFGL94], MARVEL [KFP88], APEL [DEA98], etc.). Du côté industriel, la construction de workflows a commencé vers la fin des années 90, et ceci indépendamment de tous les travaux de recherche qui ont été faits sur les procédés. Les workflows sont des procédés exécutables, centrés activités et généralement simples.

SPEM, le standard de l’OMG pour la modélisation des procédés

À l’instar d’UML pour les notations objets, la tendance actuelle est à l’uni-fication des PML dans l’optique industrielle indispensable de la réutilisation. Ci-tons par exemple SPEM [OMG07a], le métamodèle défini par l’OMG pour la mo-délisation des procédés de développement, ou les langages basés sur XML tels que XPDL [WfM05] proposé par le WfMC (Workflow Management Coalition) ou BPML [Ark02] proposé par le BPMI (Business Process Management Initiative). Ces approches constituent pour l’essentiel une unification des concepts mais leur sémantique reste décrite informellement.
SPEM (Software & Systems Process Engineering Metamodel) est le standard de l’OMG dédié à la modélisation des procédés logiciels et systèmes. Il vise à offrir un cadre conceptuel pour modéliser, échanger, documenter, gérer et présenter les processus et méthodes de développement.
Ses concepts sont décrits par un métamodèle qui repose sur l’idée qu’un pro-cédé de développement est une collaboration entre des entités actives et abstraites, les rôles, qui représentent un ensemble de compétences et qui effectuent des opé-rations, les activités, sur des entités concrètes et réelles, les produits. Les différents rôles agissent les uns par rapport aux autres ou collaborent en échangeant des pro-duits et en déclenchant l’exécution de certaines activités. Ce modèle conceptuel est synthétisé sur la figure 3.1.
Après la version 1 de SPEM [OMG05a], dont nous proposons une évaluation dans [CCOP06] et une formalisation dans [CCCC06, Com05], l’OMG est actuel-lement en train de finaliser la version 2 [OMG07a]. En plus de fournir un moyen standard pour représenter l’expertise et les procédés d’une organisation, SPEM2.0 est défini selon une vision attractive. Celle-ci consiste à séparer les aspects conte-nus et données relatifs aux méthodologies de développement, de leurs possibles instanciations dans un projet particulier. Ainsi, pour pleinement exploiter ce frame-work, la première étape devrait être de définir toutes les phases, activités, produits, rôles, guides, outils, etc., qui peuvent composer une méthode pour ensuite, dans une deuxième étape, choisir en fonction du contexte et du projet, le contenu de la méthode appropriée pour l’utiliser dans la définition du procédé.
SPEM2.0 est défini sous la forme d’un métamodèle MOF [OMG06b] qui s’ap-puie sur les spécifications UML2.0 Infrastructure [OMG07b] et UML2.0 Diagram Interchange [OMG06a]. Il réutilise de UML2.0 infrastructure les concepts de base comme Classifier ou Package. Aucun concept de UML2.0 Superstructure [OMG07b] n’est réutilisé. Le standard est défini également sous la forme d’un profil UML où chaque élément du métamodèle de SPEM2.0 est défini comme un stéréotype de UML2.0 Superstructure.

Vers une exécutabilité des modèles de procédé

Même si l’exécution des modèles de procédé était une des principales exi-gences de l’appel à proposition (Request For Proposal – RFP) de la version 2 de SPEM [OMG04], la récente adoption de la spécification ne répond pas au problème de l’exécutabilité. Néanmoins, la spécification suggère clairement deux solutions pour exécuter un modèle de procédé SPEM2.0. Nous présentons dans la suite de cette section ces deux solutions et donnons quelques remarques sur leur faisabilité.

Traduction d’un modèle de procédé SPEM2.0 dans un outil de planification

Dans la première solution, le standard propose de traduire un modèle de pro-cédé dans un outil de planification et d’exécution comme IBM Rational Portfo-lio Manager ou Microsoft Project. Les procédés SPEM2.0 définis en utilisant les structures de décomposition (c.-à-d. Activity, Role Use et WorkProduct Use du pa-quetage Process Structure) offrent les attributs clés pour fournir le planning du projet à partir des aides (Guidance) nécessaires aux décisions pour l’instancia-tion du procédé. Des exemples de ces attributs sont hasMultipleOccurrence, qui indique qu’une activité (Activity) ou un produit (WorkProduct) devra être traduit plusieurs fois ; L’attribut isRepeatable pour une activité indique qu’elle devra être itérée plusieurs fois avant d’obtenir le résultat escompté ; L’attribut isOptional in-dique qu’une activité est optionnelle et pourra donc ne pas être réalisée au cours de l’exécution du procédé. Une fois que les procédés SPEM2.0 sont traduits dans un outil de planification celui-ci peut être utilisé pour affecter les ressources concrètes allouées au projet (ressources humaines, matérielles, logicielles, etc.).
Cependant, même si cette approche est très utile pour la planification de pro-jet, elle ne peut pas être considérée comme une réelle exécution du procédé. Il est nécessaire d’affecter les durées de chaque tâche, les compétences de chaque per-sonne, afin d’avoir à la fin de l’exécution (prédictive) une estimation des ressources et du temps pour la réalisation du procédé. Ces planifications sont utilisées par le chef de projet afin d’estimer si le procédé sera réalisable ou non, s’il est nécessaire d’affecter plus de ressources aux activités, etc. Il n’y a pas de support de l’exécution du procédé, pas d’affectation automatique des tâches aux rôles responsables, pas de contrôle automatique du flot de données et de l’état des produits après chaque activité, pas de moyen pour supporter la communication dans l’équipe, etc. En plus du fait que cette approche n’offre pas de support concret de l’exécution, elle pré-sente le manque majeur de ne pas avoir de lien clair avec les outils de planification. Un autre aspect qui doit être pris en compte est l’impact d’une modification ou d’un ajout d’information dans l’outil de planification et comment cette modifica-tion peut être répercutée ou tracée dans le modèle de procédé SPEM2.0. Enfin, le modeleur de procédé doit s’assurer de la compatibilité du format de fichier de la définition du procédé de l’outil de planification.

Expression avec un autre formalisme du comportement des élé-ments de procédé SPEM2.0

Le standard SPEM2.0 n’offre pas de concept ou de formalisme pour exprimer le comportement ou l’exécution précise d’un procédé. Toutefois, prétendant à plus de flexibilité, SPEM2.0 offre, à travers le paquetage ProcessBehavior, le moyen d’associer aux éléments de procédé SPEM2.0 un comportement exprimé avec un autre formalisme. L’objectif est de ne pas imposer un modèle comportemental pré-cis mais de donner la possibilité, au concepteur des procédés, de choisir celui qui répond le mieux à ses besoins. Une activité SPEM2.0 peut, par exemple, être liée à un diagramme BPMN afin de représenter avec plus de détails les étapes de l’ac-tivité, le flot de contrôle, etc. Le moteur d’exécution BPMN est alors réutilisé. Une traduction vers BPEL (Business Process Execution Language) est également envisageable afin de réutiliser un moteur d’exécution BPEL existant. Par ailleurs, un produit peut par exemple être lié à un diagramme de machine à états UML afin de décrire les différents états d’un produit et les transitions entre ces états. Ici aussi, un moteur d’exécution de machines à états doit être intégré au moteur d’exécution du procédé. SPEM2.0 définit différents types de classe proxy (Acti-vity_ext, ControlFlow_ext, Transition_ext et State_ext) afin de lier aux éléments de procédé SPEM2.0 (c.-à-d. WorkProductUse, WorkDefinition, RoleUse, Activity et WorkSequence) un comportement externe. Le concepteur du procédé doit alors lier les éléments du procédé avec leurs équivalents dans le modèle comportemen-tal choisi. Puisqu’un modèle comportemental peut ne pas être assez expressif pour tous les aspects comportementaux d’un processus, plusieurs formalismes peuvent être combinés.
Même si cette approche peut offrir plus de flexibilité dans la représentation des aspects comportementaux des procédés SPEM2.0, elle présente différents manques. Le premier est que le standard n’est pas vraiment clair sur les moyens de lier les élé-ments de procédé avec un modèle comportemental. Il offre juste des classes proxy qui font référence à d’autres éléments dans un modèle comportemental externe. Nous supposons que cette tâche est alors à la charge des outilleurs. Ils auront donc à définir un modèle comportemental spécifique qui sera engendré automatiquementà partir du modèle de procédé. C’est déjà le cas dans l’outil du projet Eclipse EPF 2 qui est défini comme une implémentation de SPEM2.0. Dans EPF, un diagramme d’activité propriétaire est partiellement généré à partir de la définition du procédé. Il peut ensuite être raffiné afin d’offrir plus de détails sur les activités du procédé et leurs coordinations (flots de contrôle). Cependant, aucune exécution n’est fournie.
Le deuxième manque est que la traduction des éléments de procédé SPEM2.0 dans le modèle comportemental spécifique peut être différente d’une organisation à une autre, en fonction de l’interprétation du modeleur du procédé. Donc, un effort de standardisation est nécessaire afin d’harmoniser les règles de traduction entre les concepts de SPEM2.0 et un modèle comportemental. Nous citerons par exemple les travaux de Bendraou et al. [BSGB07] qui proposent une traduction vers BPEL.
Le troisième manque, qui est relatif au précédent, est que le plus souvent les concepts des modèles comportementaux sont plus riches que les concepts de SPEM2.0. Cela est dû au fait que la modélisation du comportement et de l’exécu-tion offre des concepts supplémentaires relatifs au support technique et l’exécution du procédé tandis que SPEM2.0 se concentre sur les préoccupations « métiers » des procédés ou méthodologies de développement (c.-à-d., Roles, Activities, Gui-dance, etc.). En conséquence, une génération complète du code exécutable à partir de SPEM2.0 n’est pas possible sans des étapes préalables de raffinement. Ceci pose alors le problème de la traçabilité et de comment ces raffinements (changements) peuvent être répercutés dans le modèle de procédé SPEM2.0.

Taxonomie des sémantiques dans l’IDM

La sémantique des langages de programmation est formalisée depuis de nom-breuses années et il semble pertinent de profiter de l’expérience acquise pour ex-plorer les moyens d’exprimer la sémantique des langages de modélisation. La sé-mantique d’un langage définit de manière précise et non ambiguë la signification des constructions de ce langage. Elle permet ainsi de donner un sens précis aux programmes construits à partir de celui-ci. On dit qu’une sémantique est formelle lorsqu’elle est exprimée dans un formalisme mathématique et permet de vérifier la cohérence et la complétude de cette définition. On distingue la sémantique sta-tique qui correspond à des propriétés indépendantes de l’exécution ou valables pour toutes les exécutions. Celle-ci est en général vérifiée statiquement lors de la compi-lation des programmes (et exprime des règles, comme le typage, qui ne peuvent pas être exprimées par la syntaxe) et la sémantique dynamique (ou comportementale) qui permet de décrire le comportement des programmes à l’exécution. Pour aller de la plus concrète à la plus abstraite, une sémantique comportementale peut être opérationnelle, dénotationnelle ou axiomatique [Win93]. Une sémantique opéra-tionnelle donne une vision impérative en décrivant un programme par un ensemble de transitions (ou transformations) entre les états du contexte d’exécution (p. ex. de la mémoire). Une sémantique dénotationnelle décrit, sous forme de fonctions, l’effet d’un programme et non la manière dont celui-ci est exécuté. Une sémantique axiomatique propose une vision déclarative en décrivant l’évolution des caractéris-tiques d’un élément lors du déroulement d’un programme.
Par analogie avec l’approche suivie pour les langages de programmation, le défi actuel dans l’IDM consiste à donner les moyens d’exprimer une sémantique précise pour les concepts de la syntaxe abstraite des langages de modélisation (de int x; void decr () { System if ( x>0 ) X:INT x = x − 1; DECR() } (b) Modèle manière à pouvoir en exécuter les modèles). Tel que nous avons défini un DSML (cf. section 2.2), l’expression d’une sémantique correspond à définir un mapping de chaque état du modèle, capturé par la syntaxe abstraite, vers un domaine séman-tique qui définit l’ensemble des états possibles du système. Dans le contexte de l’IDM, cette fonction prend naturellement la forme d’un modèle (cf. Mas, figure 2.4) et il est donc indispensable d’étudier le langage de modélisation adéquat pour le définir. Notons que ce langage (La2s) doit permettre de manipuler à la fois la syntaxe abstraite du DSML considéré et celle du domaine sémantique choisi. Cette propriété peut être formalisée de la manière suivante : LAS , LSD ⊆ La2s [HR04].
On peut classer les différentes sémantiques selon les catégories définies pour les langages de programmation (sémantique axiomatique, dénotationnelle et opé-rationnelle), et appliquer celles-ci selon les besoins (vérification de modèle, anima-tion de modèle, etc.) et les outils disponibles. Nous les présentons dans la suite de cette partie en les illustrant à travers l’exemple simple de la fonction decr dont le programme et un de ses modèles sont fournis sur la figure 4.1. Ce programme décrit une fonction qui décrémente de un la valeur de x à condition qu’elle soit stricte-ment positive. Nous exprimons par la suite la sémantique selon les trois niveaux d’abstraction cités.
La sémantique axiomatique ainsi que la sémantique statique (également appe-lée context condition par l’OMG et correspondant à une sémantique axiomatique très simple pouvant être vérifiée statiquement 11) peuvent être exprimées sur la syntaxe abstraite, soit à l’aide du langage de métamodélisation lui-même (p. ex. les multiplicités) soit en la complétant de contraintes exprimées à l’aide d’un lan-gage comme OCL (invariant, pré- ou post-condition). Les pré- et post-conditions supposent d’avoir identifiées des opérations sur le modèle. Une spécification axio-matique de la sémantique de la fonction decr peut, par exemple, être définie par la propriété OCL donnée sur le listing 4.1.

Table des matières

1 Introduction générale 
1.1 Évolution du génie logiciel
1.2 Les défis actuels
1.3 Objectifs de la thèse
1.4 Contexte des travaux
1.5 Contenu du mémoire
I Vers une opérationalisation des modèles dans l’IDM 
2 L’ingénierie dirigée par les modèles 
2.1 Les modèles au coeur du développement de système
2.1.1 Les principes généraux de l’IDM
2.1.2 L’approche MDA
2.1.3 Les langages dédiés de modélisation
2.2 La métamodélisation
2.2.1 Qu’est-ce qu’un langage ?
2.2.2 Outils et techniques pour la spécification d’un DSML
2.3 La transformation de modèle
2.3.1 Historique
2.3.2 Standards et langages pour la transformation de modèle
2.4 Discussion et synthèse
3 Ingénierie des procédés de développement 
3.1 Historique des procédés de développement
3.2 SPEM, standard pour la modélisation des procédés
3.3 Vers une exécutabilité des modèles de procédé
3.3.1 Traduction d’un modèle de procédé SPEM2.0 dans un outil de planification
3.3.2 Expression avec un autre formalisme du comportement des éléments de procédé SPEM2.0
3.4 Discussion et synthèse
4 Définition de la sémantique d’exécution 
4.1 Taxonomie des sémantiques dans l’IDM
4.2 Sémantique opérationnelle : expérimentations
4.2.1 Mise en oeuvre avec Kermeta
4.2.2 Mise en oeuvre avec ATL
4.2.3 Mise en oeuvre avec AGG
4.3 Sémantique par traduction : expérimentations
4.4 Discussions et problématiques
4.4.1 Autres taxonomies des sémantiques
4.4.2 Sémantique opérationnelle Vs. sémantique par traduction
4.4.3 Modifications du métamodèle
4.4.4 Approche outillée pour la définition d’une sémantique
II Contributions pour la simulation & la vérification de modèle 
5 Définition d’un DSML exécutable 
5.1 XSPEM, une extension eXécutable de SPEM2.0
5.1.1 XSPEM Core
5.1.2 XSPEM ProjectCharacteristics
5.1.3 Exemple : modèle XSPEM de la méthode MACAO
5.2 Définition des informations dynamiques
5.2.1 Caractérisation des propriétés temporelles
5.2.2 Caractérisation des états possibles
5.2.3 Extension de la syntaxe abstraite : XSPEM ProcessObservability
5.2.4 Formalisation des propriétés temporelles avec TOCL
5.3 Explicitation du comportement de référence
5.3.1 Extension de la syntaxe abstraite : XSPEM EventDescriptions
5.3.2 Définition du système de transition du DSML
5.3.3 Métamodèle pour la gestion des traces et scénarios
5.4 Architecture générique d’un DSML exécutable
5.5 Discussion et synthèse
6 Vérification de modèle 
6.1 Présentation générale de l’approche
6.2 Application à la vérification de modèle XSPEM
6.2.1 Réseaux de Petri, logique temporelle et boîte à outils TINA
6.2.2 Traduction XSPEM2PRTPN
6.2.3 Expression des propriétés sur les réseaux de Petri
6.3 Validation de la sémantique par traduction
6.4 Discussion et synthèse
7 Simulation de modèle 
7.1 Description des besoins et des approches
7.1.1 Objectifs de la simulation de modèle
7.1.2 Exigences pour la simulation dans l’atelier TOPCASED
7.1.3 Simulation à événements discrets
7.1.4 Ateliers de simulation existants
7.2 Architecture générique d’un simulateur
7.2.1 Éditeur graphique
7.2.2 Constructeur de scénario
7.2.3 Moteur de simulation
7.2.4 Panneau de contrôle
7.2.5 Animateur de modèle
7.2.6 Outils d’analyse
7.3 Prototype de simulateur de modèle XSPEM
7.4 Discussion et synthèse
8 Cadre formel pour la métamodélisation 
8.1 Fonction et Nature des modèles
8.2 Description du cadre proposé
8.2.1 Model & Model Class
8.2.2 Conformité
8.2.3 Promotion
8.3 Formalisation de MOF et de la pyramide de l’OMG
8.3.1 Définition du ModelClass EMOF_Core
8.3.2 Vérification de la métacircularité du MOF
8.3.3 Formalisation de la pyramide de l’OMG
8.4 Intégration dans un environnement de métamodélisation
8.5 Discussion et synthèse
9 Transfert des contributions 
9.1 TopProcess
9.2 Tina Bridges
9.3 TOPCASED Model Simulation
9.3.1 Métamodèle retenu dans TOPCASED pour la simulation de machine à états UML2.0
9.3.2 Prototype du simulateur de machines à états de TOPCASED 152
10 Conclusion générale 
10.1 Bilan et applications des travaux
10.2 Démarche de métamodélisation exécutable
10.3 Élargissement des résultats
10.3.1 Environnement d’expression des propriétés temporelles
10.3.2 Analyse des résultats de vérification
10.3.3 Extension du cadre de simulation
10.3.4 Sémantique d’exécution avec création dynamique
10.3.5 Environnement de métamodélisation formelle
10.3.6 Administration de systèmes dirigée par les modèles
Bibliographie

Télécharger le rapport complet