Mes recherches actuelles s'intéressent à l'interopérabilité entre systèmes hétérogènes. Dans un contexte tel qu'un système hospitalier, l'ensemble des composants logiciels sont dédiés à une activité précise et indépendante, les contraintes de confidentialité imposant un cadre strict de fonctionnement. Cependant, le couplage des résultats produits par ces composants peut présenter un intérêt non négligeable.

Mon objectif actuel est de définir des paradigmes de composition et de transformation destinés à autoriser la communication entre composants logiciels, même si rien n'a été prévu pour, et en considérant les composants comme des boîtes noires non modifiables.

Mes recherches durant mon PostDoc ont concerné le concept de typage de modèle, qui n’est finalement qu’une simple extension du système de typage dans les langages orientés objets. Concrètement, un modèle peut être typé en effectuant un mapping entre les éléments qui le composent, ainsi que leurs relations, et les éléments d’un « Model Type ». Ce dernier se caractérise par un ensemble de classes MOF, ainsi que leurs références. Typer un modèle permet de lui définir un socle de travail qui peut être commun avec un autre modèle, même si son méta-modèle est différent (la différentiation se faisant au moment du mapping). Deux modèles typés par le même Model Type partagent donc, au niveau du Model Type, un ensemble d’éléments et de relations sur lesquels il est possible d’effectuer diverses opérations, telles que des transformations, des vérifications, ou des compositions.

La composition de modèles grâce au Model Type constituait l’un des axes de recherches de mon PostDoc. Deux modèles typés sont composables par le biais des éléments partagés au niveau de leur Model Type. Dans le contexte du projet OPEES, qui se caractérise par un ensemble de composants, l’expression de la composition entre composants est possible par le biais de Model Types.

L’ingénierie des modèles considère les modèles comme des entités de première classe pour le développement logiciel. Les processus dirigés par les modèles se doivent d’être capables de prendre en compte le savoir-faire d’experts, généralement exprimé en termes de patrons, qu’ils soient d’analyse, de conception ou d’architecture. Choisir le bon patron et assurer sa bonne intégration au sein d’une modélisation constitue des freins à l’utilisation systématique des bonnes pratiques de conception. Afin d’alléger ces tâches, j’ai proposé une approche basée sur l’inspection automatique des modèles. J’ai ainsi outillé une activité de revue de conception identifiant, expliquant et corrigeant les mauvaises pratiques de conception dans un modèle.

Un patron abîmé est comparable à un patron de conception, ses contextualisations résolvant les mêmes types de problèmes, mais avec une architecture différente et certainement améliorable. Des expérimentations ont été menées afin de collecter des patrons abîmés, m’amenant à proposer un catalogue de mauvaises pratiques, complémentaire au catalogue du GoF. La détection des contextualisations de patrons abîmés dans un modèle UML est apparentée à un morphisme de graphe étendu. Les graphes UML ayant des sommets typés, la détection s’appuie sur des particularités structurelles locales et globales permettant de résoudre ce problème NP-Complet par des filtrages successifs. Cet algorithme est ainsi capable de détecter toutes les contextualisations possibles d’un patron abîmé, en gérant de plus les arcs interdits et facultatifs. La sémantique d’un fragment de modèle est donnée par son intention et celle-ci est validée par le concepteur. L’intention des fragments détectés et les bénéfices d’un remplacement par le patron adéquat sont déduits par des requêtes sur une ontologie conçue à cet effet. La transformation des fragments en contextualisations de patrons de conception est réalisée grâce à des restructurations de modèles déduites automatiquement des différences structurelles entre un patron abîmé et un patron de conception.

Il est intéressant de remarquer que la collecte des patrons abîmés a permis de découvrir une nouvelle manière d’enseigner les patrons de conception. En effet, j’ai demandé à des étudiants de concevoir certains problèmes spécifiques avec leur propres connaissances et de la meilleure manière possible. Leurs résultats ont constitué ma base de travail, mais également une base de départ pour leur enseigner comment ils auraient pu mieux faire. Au lieu de leur présenter les patrons de conception comme « meilleures solutions pour résoudre un problème », je leur ais fait améliorer leurs propres solutions jusqu’à ce qu’elles deviennent « les meilleures possibles ». Ainsi, ils ont découvert de manière progressive et séquentielle quels étaient les points forts des patrons.