Bien qu'aujourd'hui les sujets autour de l'Ingénierie Dirigée par les Modèles sus-citent beaucoup d'intérêt, les possibilités oertes par cette nouvelle branche du génie logiciel sont encore méconnues, et beaucoup de questions restent ouvertes. De plus, en tant que technologie émergente, les approches soutenant l'IDM ne sont pas encore ma-tures. Ainsi, comme le montre Schmidt [Sch06], il est dicile de trouver des solutions techniques solides des technologies IDM, des applications industrielles de ces techno-logies, ou encore des bénéces avérés de cette démarche. En eet, l'approche semble soulever certaines interrogations, notamment celles relatives à la synchronisation entre les modèles et le code généré (ou d'autres représentations des modèles), au débogage de la modélisation, à la compatibilité des outils IDM ou encore à la certication de pro-priétés de sûreté des modèles écrits dans les DSML. Pour aggraver la situation, l'IDM tout entier fait aujourd'hui face à un autre type de problème, celui d'une lutte interne entre les diérentes mouvances an de savoir quelle déclinaison est la plus à même de re-présenter l'IDM : aux pro-UML généralistes s'opposent les pro-DSML spéciques. Dans cette section, nous traitons donc des limites et des problèmes de l'approche de l'Ingé-nierie Dirigée par les Modèles, en se concentrant sur chacune des approches présentées précédemment.
2.3.1 Architecture dirigée par les modèles
À la lecture du guide proposé par l'OMG [Obj03], il apparaît évident que l'ap-proche MDA se veut généraliste, s'appuyant sur des dénitions (plate-forme, modèle, transformation), des standards et des outils eux aussi généralistes. Or, l'ensemble de l'approche est fondé sur le concept de plate-forme et sur la séparation des spécications fonctionnelles d'un système (PIM) et des spécications de son implémentation (PSM).
La généricité de cette démarche entraîne une ambiguïté de la dénition des concepts de l'architecture qui complexie sa mise en ÷uvre.
Une architecture ambiguë. Si les buts de l'approche MDA sont relativement clairs aujourd'hui et continuent à s'aner de jour en jour, il n'en est pas de même pour sa mise en ÷uvre. La technologie pour l'implémenter est, en eet, très vaguement spéciée, et les limites du cadre de la démarche ne sont pas clairement identiées. En forçant le
trait, n'importe quel outil de modélisation avec des fonctionnalités de génération de code peut prétendre implémenter l'approche MDA. De la même manière, l'architecture toute entière s'appuie sur la notion de plate-forme, mais à la lecture de la littérature, il demeure peu évident de savoir ce qui constitue exactement une plate-forme. Ainsi, selon la propre dénition de l'OMG [Obj03], la notion de plate-forme est sujette au but de la personne qui modélise, et si les utilisateurs considèrent qu'un middleware est une plate-forme, les développeurs considèrent eux que les systèmes d'exploitation sont des plates-formes. La notion de modèle n'est pas plus explicite, puisque l'organisme la dénit comme suit :
...une description ou une spécication d'un système et ses environne-ments en ce qui concerne certains buts. Un modèle est souvent représenté comme une combinaison de dessins et de texte. Le texte devrait être dans un langage de modélisation ou en langage naturel.
Tout cela rend la mise en ÷uvre de l'approche MDA très oue et très ambiguë. De plus, comme le suggèrent Muller et al. dans [MBS04], il n'est pas toujours simple, au sein d'une architecture donnée, de bien diérencier le caractère indépendant (PIM) d'un système de ses caractères spéciques (PSM), car cela dépend souvent du point de vue de l'utilisateur. Or, cette séparation apparaît comme un concept clé de la démarche.
Là encore, la dénition ne nous renseigne pas plus et vient conrmer les conclusions de Muller et al., reconnaissant que comme beaucoup de points, l'indépendance de la plate-forme est une aaire de degré. Par ailleurs, aucune fondation n'était jusqu'ici dénie pour transformer des modèles indépendants de plates-formes en modèles spéciques aux plates-formes [GLR+02]. Et si la recommandation QVT [JK06a] semble proposer un cadre normatif à la transformation de modèles, très peu d'outils implémentent réel-lement ce standard. An de cacher l'ambiguïté résultant de tout ceci, les concepteurs de langages de modélisation généralistes mettent en avant le caractère haut niveau de leurs abstractions, suggérant ainsi que ces dernières n'ont pas besoin d'être non-ambiguës, complètes, ou encore signicatives. Cependant, par dénition, une abstraction permet de cacher les détails inutiles pour l'utilisateur, mais ne les supprime en aucun cas. En eet, ces derniers doivent encore être présents, an d'éviter toute ambiguïté due à une sémantique incomplète notamment dans le cadre d'une génération automatique de code ou d'une transformation. La perte d'informations pourrait entraîner par exemple une impossibilité de vérication de propriétés, ou tout simplement interdire toute exécution.
Le piège de la généricité. Si les modèles permettent aux experts du domaine de résoudre plus facilement les problèmes, il est primordial que le langage de modélisa-tion représente clairement le domaine de problèmes. L'approche MDA privilégie un langage de modélisation généraliste (UML) et utilise ce langage dans tous les domaines en formant les experts du domaine à l'utilisation de ce langage généraliste. Un standard comme UML ne peut être utilisé comme une technique ecace de développement dirigé par les modèles ou comme un langage exécutable. Il lui manque, en eet, la spécia-lisation et la dénition sémantique nécessaires à la génération d'une implémentation [CESW04]. Pour pallier ce manque, la version 2.0 d'UML [FGDS06] inclut une facilité
de méta-modélisation puissante (Meta-Object Facility ou MOF), qui permet d'étendre UML de manière quasiment arbitraire. Ainsi, UML inclut un mécanisme de prol qui lui permet d'être contraint et spécialisé pour des domaines et des plates-formes spéciques [CESW04]. L'exemple le plus connu de spécialisation d'UML à un domaine particulier est SysML [Sys05], un langage de modélisation pour l'ingénierie des systèmes. Mal-heureusement, certaines constructions dans UML 2.0 restent encore sans sémantique [HT06, HR04]. Ce manque de dénition sémantique empêche l'usage précis des exten-sions UML, réduit leur pouvoir expressif et empêche d'assurer une certaine conformité au niveau des outils. Comme Thomas le note [Tho04], UML 2.0 manque à la fois d'une implémentation de référence et d'une explication sémantique compréhensible par un humain an de fournir une sémantique opérationnelle. Il est donc dicile d'interpréter et d'implémenter correctement des outils de transformation de modèles UML. De plus, de par son manque de spécication, les modèles écrits dans un tel langage informel sont ouverts à des interprétations erronées. Le dernier problème réside dans la complexité inhérente à UML et à l'utilisation de prols. Si UML présente incontestablement de nombreux avantages, notamment en termes de conception et de communication, la plu-part du temps, il ne permet pas de représenter les besoins réels des modèles [FS00].
Par ailleurs, la génération de code se limite dans la plupart des cas à la génération d'artéfacts, mais en aucun cas à une génération complète, à cause de son imprécision et sa généricité.
2.3.2 Modélisation spécique à un domaine
Selon Greeneld et Short [GSCK04], la généricité excessive et la construction mo-nolithique de générateurs de code font parties des freins majeurs au développement logiciel. Si le problème de la généricité est bien illustré par la démarche MDA, celui de la construction monolithique résume quant à lui parfaitement les limites liées à l'ap-proche de modélisation spécique. En eet, l'un des problèmes de la modélisation DSM se situe au niveau de la faiblesse des générateurs de code, symbolisée notamment par l'échec des outils de type CASE. Plus le langage de modélisation est haut niveau et plus les besoins de génération de code sont importants. En conséquence, cela peut rapidement introduire une grande complexité au niveau du générateur, le rendant dicile à main-tenir ou à faire évoluer. De la même manière, un point important de toute l'approche réside dans la séparation des tâches entre les modèles, le générateur et le framework.
Une mauvaise séparation peut là encore avoir des impacts sur la complexité du généra-teur, une impossibilité d'évolution ou un framework trop restrictif car trop haut niveau.
Un autre frein majeur de l'approche se situe autour de la spécicité de la démarche, et de la plate-forme d'exécution. Si cette approche facilite le développement, cela restreint également la solution à cet environnement et introduit de fortes dépendances avec la plate-forme au niveau du générateur de code. Ceci empêche donc toute réutilisabilité et implique la création d'un nouveau générateur (voire framework) pour chaque nouvel environnement. Comme dans le cas d'UML, un problème subsiste également au niveau sémantique. En eet, il est important que la sémantique du langage de modélisation, et donc du modèle, ne soit pas seulement dénie au travers du générateur. Le manque
de sémantique rend la production d'outils DSM automatisés dicile. Pour tenter de répondre à ce problème, les environnements d'implémentation DSM fournissent souvent un langage de règles pour limiter la sémantique du domaine. Néanmoins, sa mise en
÷uvre reste complexe et son impact limité à l'expressivité du langage de règles. En-n, le développement du langage et du générateur par l'organisation elle-même peut prêter à discussion et devenir un obstacle. Malgré l'aide d'outils de modélisation, cette approche nécessite tout de même de la part des développeurs une certaine expertise, méthodologie et tournure d'esprit.