L’Ingénierie Dirigée par les Modèles (IDM) place les modèles au cœur des processus d’ingénierie logicielle et système. L’hypothèse est que différents modèles d’un même système, correspondant à différentes vues et/ou niveaux d’abstraction, peuvent cohabiter au sein d’un processus de développement. Chaque modèle fournit une abstraction adaptée à un type d’exploitation particulier tel que l’analyse d’ordonnancement, la validation, la génération de code, etc., l’ensemble permettant idéalement de maitriser la complexité des logiciels et d’améliorer la rapidité et la qualité des processus de développement.

Le Model Driven Architecture (MDA) est une initiative de l’Object Management Group (OMG) définissant un cadre conceptuel, méthodologique et technologique pour la miseen-œuvre de flots de conception basés sur l’IDM. Le cadre conceptuel identifie la nature des modèles impliquées (modèles de plateforme, modèles indépendants ou spécifiques à une plateforme) et des relations qui les unissent (abstraction, raffinement, etc.). Le cadre méthodologique préconise une approche générative par transformations de modèles pour le raffinement des différents modèles impliqués, jusqu’à la production d’un code exécutable. Le cadre technologique s’appuie sur une utilisation des formalismes normalisés par l’OMG pour la mise-en-œuvre du flot (UML pour la modélisation, QVT pour les transformations, etc.).

Confrontée à une complexité croissante des systèmes à concevoir (toujours plus de fonctionnalités à intégrer face à des contraintes impondérables de temps de mise sur le marché), l’industrie des systèmes temps-réels embarqués a naturellement identifié dans l’IDM, et dans le MDA en particulier, une opportunité pour rationaliser les flots de conception. D’une part, la structuration des flots en niveaux d’abstractions et la mise en-œuvre d’approches génératives permettent d’éviter un certain nombre d’écueils, en automatisant (au moins partiellement) des tâches de raffinement systématiques et facilement sujettes à erreurs lorsqu’elles sont accomplies manuellement. D’autre part, le fait de s’appuyer sur un cadre technologique commun facilite (même s’il ne suffit pas pour le garantir) une forme d’interopérabilité entre les différents acteurs et domaines de compétence du flot.

Dans les deux cas, les qualités intrinsèques des formalismes préconisés par le MDA, notamment en termes d’expressivité et d’extensibilité (cf. UML et ses profils ch. 2), favorisent la mise-en-œuvre des flots en permettant la prise en compte des particularités liées au domaine ou à l’acteur. En pratique, cette vision s’est déjà concrétisée sous la forme d’investissements significatifs de la part d’acteurs majeurs du domaine, ayant débouchés sur des réalisations concrètes tant au niveau des outilleurs [1] que des grands systémiers (Airbus, Renault, etc.). Si ces réalisations peuvent être considérées comme des avancées significatives pour le domaine (SCADE System lauréat du prix Best of show « Embeddy » à Embedded World 2011 [1][2]), un certain nombre de verrous scientifiques et technologiques persistent.

Dans le domaine des systèmes temps-réel embarqués, que l’on vise des systèmes à prépondérance logicielle ou matérielle, on cherche à produire des systèmes exécutables au sens informatique du terme. Dans les flots traditionnels basés sur le MDA, les premières formes exécutables du système sont généralement obtenues par génération de code, après une ou plusieurs étapes de raffinement manuel et/ou automatique par transformation de modèles. Ces formes exécutables sont utilisées pour mettre en œuvre des phases d’expérimentation avant obtention du système final. En d’autres termes, le comportement attendu du système final est simulé au niveau d’abstraction capturé par la forme exécutable. Pour les systèmes temps-réels embarqués, par nature contraints en ressources et en temps, la simulation est utilisée pour tester le comportement du système non seulement d’un point de vue fonctionnel, mais aussi d’un point de vue temporel et concurrentiel.

Cet état de fait signifie que, dès les niveaux d’abstraction les plus élevés du flot (donc avant raffinement), des hypothèses sur la sémantique d’exécution des différents modèles existent nécessairement, dans le sens où elles orientent la définition des règles de raffinement menant à l’obtention du code exécutable. En pratique, on constate que :

a. ces hypothèses peuvent être sous-exploitées. En effet, le niveau de détail requis pour obtenir une représentation exécutable par génération de code implique que les phases de simulation arrivent relativement tard dans le flot de conception. En exploitant effectivement les hypothèses liées à la sémantique d’exécution des différents modèles intermédiaires, la simulation pourrait intervenir plus tôt dans le flot, et pourrait donc contribuer à améliorer les flots de conception.

b. si ces hypothèses sont effectivement exploitées, leur exploitation est sujette à caution. Une pratique usuelle consiste en effet à transformer les modèles vers différents formalismes, chaque formalisme cible bénéficiant d’une sémantique bien définie, et étant adapté à un type d’exploitation particulière. Le problème est que, quelle que soit la rigueur et le soin apporté à la mise-en-œuvre des transformations, elles partent toujours d’une spécification en langage naturel (pratique usuelle pour décrire les aspects sémantiques dans les spécifications OMG), nécessairement sujette à interprétation. En d’autres termes, la projection ne peut être considérée comme valide que par rapport à l’interprétation du formalisme en entrée. La critique s’applique également lorsque la transformation concerne le raffinement d’un modèle au sein même du flot de conception.

L’ingénierie dirigée par les modèles [3] est un paradigme de développement logiciel qui préconise une utilisation intensive et systématique des modèles. Les modèles sont placés au cœur du processus de développement afin de faire face à la complexité croissante de la conception et de la production du logiciel. L’IDM est distinguée par sa capitalisation du savoir faire non plus au niveau du code source, mais plutôt au niveau des modèles. Cela ne signifie pas une rupture technique avec les solutions de développement existantes telles que les langages de programmation, mais au contraire, elle est complémentaire. En effet, l’utilisation des techniques de transformation de modèles, permet de générer le code source des applications automatiquement ou semi automatiquement depuis les modèles réalisés lors de la conception. De nombreux travaux [4, 5, 6, 7] se sont intéressés à cette nouvelle discipline informatique émergente. Ils ont aidé à clarifier et dégager ses concepts. Par la suite, à partir de ces travaux, nous allons définir les notions fondamentales liées à l’IDM. Nous allons d’abord donner la définition d’un modèle. Nous retiendrons la définition tirée de [8] :

Définition 1 Un modèle est une abstraction d’un système, construite dans une intention particulière. Cette abstraction devrait être représentative afin de répondre à des questions sur le système modélisé.

Pour que le modèle soit efficacement manipulable par des outils informatiques, il doit respecter certaines qualités. Dans [9], Bran Selic avait identifié les caractéristiques essentielles qu’un modèle devrait avoir, ce sont principalement :

➤ L’abstraction : le modèle doit assurer un certain niveau d’abstraction et cacher les détails que l’on ne souhaite pas considérer pendant l’étude.

➤ La compréhensibilité : le modèle doit être compris intuitivement par les personnes qui l’utilisent. Donc, il doit être exprimé dans un formalisme assez compréhensible dont la sémantique est intuitive.

➤ La précision : le modèle doit fournir une représentation fidèle et précise des propriétés du système à étudier.

➤ L’économie : le modèle doit rester peu coûteux en comparaison aux coûts du développement du système réel.

Cette liste n’est pas exhaustive et elle peut contenir également d’autres caractéristiques telles que la prédiction, la maintenabilité, la traçabilité, l’exécution, etc. Ainsi, l’obtention de modèles qui respectent toutes ces caractéristiques est une tâche non évidente.