English
 |
 |
 |
|
|
|
 |
|
 |
|
 |
|
|||||||||||||||||||
|
|
|
|||||||||||||||||||
|
 |
|
|||||||||||||||||||
|
|
|
|
||||||||||||||||||
|
|
|
|
||||||||||||||||||
|
Millan Thierry
Thèmes de rechercheValidation de modèles UML avec le langage OCL
Recherches actuellesDe très nombreuses raisons contribuent à la justification de vérifier et de transformer des modèles. On peut ainsi citer trois exemples : aider à la réflexion lors des phases de spécification et de conception, s’adapter à la projection sur différentes plates-formes cibles sous le contrôle des concepteurs/développeurs et être ouverts au travail collaboratif. Dans le cas d’une opération de fusion par exemple, il s’agit d’être capable de manipuler au moins deux modèles en entrée et un modèle en sortie. En référence à la composante « View » de la norme QVT (Query / View / Transformation), la création de vues entre également dans le périmètre de ces besoins. La plate-forme NEPTUNE II s’inscrit dans cette logique de vérification et de transformation de modèles. Elle utilise une extension du langage OCL (Object Constraint Language) lui permettant aussi bien de respecter la norme de l’OMG lors des vérifications que de la relâcher pour effectuer des transformations. Notre approche vise à étendre le langage OCL vers la manipulation simultanée de plusieurs modèles et vers la transformation de modèles. Le choix d’OCL résulte pour l’essentiel de sa position en tant que standard intégré à UML et de ses facilités de navigation au sein des métamodèles dont les modèles sont issus. On peut donc ainsi imaginer l’écriture en OCL étendu d’opérations telles que la fusion ou la comparaison d’éléments de modélisation, justifiant l’existence de contrats après une étape de transformation. L’extension du langage OCL, que nous noterons pOCL (procedural OCL), est donc composée de deux fonctionnalités : l’une pour l’accès et la manipulation simultanés de plusieurs modèles conformes à des métamodèles différents et l’autre pour l’introduction de primitives de transformation. La mise en œuvre des transformations et des vérifications inter-modèles n’est possible que par l’utilisation d’un synthétiseur de types qui permet de typer et de contrôler les différentes expressions manipulées. La structure des types OCL est organisée selon trois treillis de types, complémentés par un type bottom commun : OclVoid. Ces trois treillis sont respectivement le treillis des types atomiques OCL (types primitifs d’OCL et métaclasses des métamodèles manipulés), le treillis des types associés aux collections homogènes (set, bag, sequence par exemple) et le treillis des collections hétérogènes (tuples). Cette structuration des types permet de vérifier dynamiquement que les données manipulées et générées ont un type conforme au métamodèle dont-elles sont issues. Le typage dynamique des expressions permet de calculer au fur et à mesure le type du résultat ; ce typage dynamique évite au programmeur OCL de « forcer » les types avec la primitive OCL oclAsType, ce qui simplifie l’écriture des règles sans pour autant affaiblir le contrôle des expressions. L’utilisation simultanée de plusieurs métamodèles s’intègre parfaitement à cette structuration car toute métaclasse appartient au premier treillis. Il en résulte que deux classes issues de deux métamodèles disjoints ont au moins une métaclasse commune, la métaclasse OCL oclAny, et une métaclasse OCL qui les spécialise, la métaclasse oclVoid. Ces deux classes sont essentielles pour le synthétiseur de types car elles définissent respectivement le type top et le type bottom du treillis, ce dernier étant le type de référence lors du calcul du type des éléments d’une collection. Le système de types ainsi défini est homogène et n’est nullement perturbé par la manipulation simultanée de plusieurs métamodèles. Il en résulte donc une intégration simple de l’aspect multi-méta-modèles au système de types.
Développement d'Outils :Développement de l'atelier NEPTUNE
Organisation de journées thématiques :Co-organisateur avec la société CS & Communication et Système des journées NEPTUNE qui se déroulent à Paris tous les ans
Participations à des projets :2005 – 2010 : Projet ANR/DGE : TOPCASED http://www.topcased.org/L'objectif de Topcased est de couvrir l'ensemble des besoins de développement logiciel et système (la branche descendante du cycle en V), ainsi que les besoins transverses comme la gestion de configuration, la gestion des changements ou l'ingénierie des exigences. L'atelier suit une approche de type MDE (Model Driven Engineering, ou Ingénierie dirigée par les modèles) au niveau de ses fonctionnalités et de ses méthodes de développement. 2007 – 2009 : Projet ANR : DOMINO http://www.domino-rntl.orgLe projet DOMINO (DOMaINes et prOcessus méthodologique) propose une démarche basée sur la description d’un système par divers modèles exprimés dans des langages de modélisation dédiés différents, en exploitant l'Ingénierie Des Modèles (IDM ou en anglais MDA/MDE pour Model Driven Architecture/Engineering) pour fiabiliser tout processus d'ingénierie accompagnant le développement de logiciels. Le terme de processus fiable, fondamental dans le contexte d’une modélisation multi-formalisme, doit être compris comme l’ensemble des techniques permettant de concevoir et fiabiliser des logiciels ayant des contraintes importantes de continuité de service en opérationnel. Fiabiliser un processus de développement est la première étape essentielle pour délivrer un service de confiance justifié. 2000 – 2003 : Projet National : ADELFE https://www.irit.fr/ADELFE/Le but de ce projet est de réaliser un Atelier de DEveloppement de Logiciels à Fonctionnalité Emergente (ADELFE). Ces logiciels sont basés sur les techniques des systèmes multi-agents adaptatifs et auto-organisateurs développés à l'IRIT et à ARTAL. Par leur capacité d'adaptation, ces systèmes multi-agents sont aptes à fonctionner dans un environnement à très forte dynamique et à faire face à des imprévus. Ces logiciels sont adaptés pour résoudre des problèmes complexes, distribués pour lesquels un contrôle global est impossible à mettre en œuvre. Avec l'essor des technologies du futur comme Internet, l'évolution des réseaux de machines, ce type de logiciels apporte des solutions aux problèmes de conception de logiciels adaptés à des applications dans ces environnements. Actuellement, il n'existe pas de méthodologie et d'aide à la conception pour ces systèmes adaptatifs. La réalisation de cet atelier de développement consiste à donner :
1999 – 2002 : Projet Européen : NEPTUNE IST-1999-20017 http://neptune.irit.frLe projet NEPTUNE vise principalement à améliorer l'utilisation de la notation UML dans le cadre de l'ingénierie du logiciel. Le projet NEPTUNE a permis, d'une part, la réalisation d'outils permettant la vérification de la cohérence entre les différents diagrammes UML et la génération de documentations. Ces outils supportent la définition d'une méthodologie d'analyse et de conception avec la méthode UML dans le cadre de deux activités : Le génie logiciel et les processus d'affaire. 1999 – 2002 : Projets Régional : MERCURELe projet MERCURE est une extension du projet NEPTUNE. La première extension concerne la partie démarche. Cette première extension vise à étendre la démarche NEPTUNE à la phase d’analyse de l’existant. Pour ce faire, cette extension est basée sur la méthode Merise. La seconde extension vise à réaliser un compilateur OCL pour l’outil TAU UML Suite 2 de notre partenaire Telelogic. Ce compilateur transforme du code OCL en TCL.
Enseignements au département informatique de l'IUT "A"Diplôme Universitaire de Technologie
Vacataire au Conservatoire Nationnal des Arts et Métiers
|
|
|||||||||||||||||||
 |
|
|
|||||||||||||||||||
|
|
|
|
||||||||||||||||||
