Bon je vais m'essayer à un petit laïus sur le sujet bien que ne faisant pas autorité en la matière.
Attention ! victoire au Business Loto garantie
Dans les MDA, MDE, MDSD, ... et consorts, ce qui revient est le modèle qui est placé au coeur du processus de développement d'où le MD (Model Driven)
Déjà il faut voir un intérêt dans la modélisation pour le génie logiciel.
Les modèles permettent de s'abstraire de la complexité des systèmes réels pour n'en retenir que certains aspects qui nous intéressent. Le réel ne pouvant souvent pas être appréhendé dans sa globalité par un être humain.
Les modèles, on en trouve un peu partout. On a les standards: UML pour l'objet, SysML, le BPMN pour les services, .... mais aussi certains outils, métiers ou entreprises ont développé leur propre formalisme. Les projets EMF/GMF d'Eclipse visent d'ailleurs à faciliter la vie de celles-ci. Plutôt que d'utiliser un langage généraliste comme UML qui devient gigantesque et dont seule une partie nous est utile , ils permettent de se fabriquer une notation graphique sur mesure. Mais ils permettent de décrire UML aussi (plugin uml2 au dessu de EMF/GMF). On parlera de DSL (Domain Specific Language). A un certain niveau les langages de programmation eux-même peuvent être perçus en tant que modèles. Tout ca est bien beau mais si j'utilise une notation pour représenter mes écrans d'IHM, que je rajoute un formalisme pour la modélisation des données relationnelles (MCD Merise) , un peu d'UML par ci et encore une notation propriétaire pour la description des mes processus métiers par là. Comment je fais pour vérifier la cohérence de l'ensemble et surtout pour la maintenir lorsque je fais le moindre changement. A la mimine ca décourage un peu.
Et c'est là que l'OMG a sorti sa grande idée. Déjà on a les modèles.
Chaque modèle est décrit par un langage. Et si on décrivait chacun de ces langages de modélisation par un modèle (le metamodèle) en utilisant un seul et même langage de description ? Et voici que le MOF (Meta Object Facility) fait son apparition. Il permet d'unifier tous les langages de modélisation et il s'auto-décrit. (Voir la fameuse pyramide 4 layers qui décrit tout ça - pas trouvé la photo). MOF étant une spec ,Eclipse avait donc besoin de l'implementer pour son projet EMF. Il s'agit d'Ecore (un sous-ensemble de MOF en fait). A partir de là on devient capable de faire des transformations de modèles entre 2 modèles d'un même langage mais aussi entre 2 modèles exprimé avec des formalismes différents puisqu'on maitrise la description de leur métamodèles. On parle de transformation M2M (Model 2 Model). Soyons joueur et décrivons la spec de ce langage de transformation. Nous l'appellerons QVT. ATL c'est une impléméntation de QVT même si elle en a un peu dérivé car QVT trainait un peu.
Reste un problème: Comment à partir d'un modèle peut on arriver à générer du code ? En soi, le code est décrit par un langage qui dispose de sa propre grammaire et donc de son métamodèle.
Toutefois écrire une transformation de M2M en considérant le code comme un modèle n'est pas chose aisée.
On préfère souvent utiliser d'autres techniques comme des langages à base de template décrivant le code généré par un fichier d'exemple qui contient des balises. Elles pointent sur des éléments du métamodèle associé au modèle à partir duquel on génère. Un peu à la manière des JSPs par exemple. On parle alors de langages de transformation M2T (Model 2 Text)
Acceleo par exemple joue dans cette catégorie et c'est pourquoi avec ATL, ils sont souvent complémentaires.
OpenArchitectuware propose les 2 types de langages ainsi que d'autres outils propriétaires comme MIA. Certains préfèrent s'appuyer sur un tooling pour les transfo M2M comme par exemple Rational Software Architect.
Dernière problématique. Passer d'un modèle à un autre n'est pas toujours évident car parfois on souhaite orienter la transformation ou lui rajouter des informations. Par exemple, passer d'un modèle UML d'analyse à un modèle de conception ou d'un modèle de conception à du code. Quitte a faire, ces infos de transfo ca n'est ni plus ni moin qu'un modèle . Appelons le modèle de marquage. Mais comment faire ? Soit on rajoute cette information dans le modèle de départ mais ca le pollue avec des informations inutiles pour ce niveau d'abstraction. C'est à ca que servent par exemple les profils UML qui sont des regroupements de stéréotypes.
On peut aussi les rajouter au modèle d'arrivée. Là la difficulté est de les placer dans le modèle alors que celui-ci n'existe pas. La troisième
est de l'associer à la transformation elle-même.
On se retrouve avec une jolie querelle de chapelle entre les protagoniste de UML et ses profils et les zélotes des DSL.
UML est standardisé et répandu. Il dispose d'outils graphiques et les profils sont faciles à mettre en oeuvre. Toutefois, il est trop riche pour les besoins et la mise au point des transformations ne s'en trouve pas facilitée. Les DSL quant à eux ne fournissent que le strict nécessaire. Mais on ne dispose pas encore de moyens simple pour en créer et notamment au niveau graphique même si ca s'améliore.
Autre reproche ca nécessite à chaque fois de s'approprier un nouveau formalisme.
[^] # Re: Ca a l'air vachement bien
Posté par Bozo_le_clown . En réponse à la dépêche Sortie de ATL 2. Évalué à 10.
Attention ! victoire au Business Loto garantie
Dans les MDA, MDE, MDSD, ... et consorts, ce qui revient est le modèle qui est placé au coeur du processus de développement d'où le MD (Model Driven)
Déjà il faut voir un intérêt dans la modélisation pour le génie logiciel.
Les modèles permettent de s'abstraire de la complexité des systèmes réels pour n'en retenir que certains aspects qui nous intéressent. Le réel ne pouvant souvent pas être appréhendé dans sa globalité par un être humain.
Les modèles, on en trouve un peu partout. On a les standards: UML pour l'objet, SysML, le BPMN pour les services, .... mais aussi certains outils, métiers ou entreprises ont développé leur propre formalisme. Les projets EMF/GMF d'Eclipse visent d'ailleurs à faciliter la vie de celles-ci. Plutôt que d'utiliser un langage généraliste comme UML qui devient gigantesque et dont seule une partie nous est utile , ils permettent de se fabriquer une notation graphique sur mesure. Mais ils permettent de décrire UML aussi (plugin uml2 au dessu de EMF/GMF). On parlera de DSL (Domain Specific Language). A un certain niveau les langages de programmation eux-même peuvent être perçus en tant que modèles. Tout ca est bien beau mais si j'utilise une notation pour représenter mes écrans d'IHM, que je rajoute un formalisme pour la modélisation des données relationnelles (MCD Merise) , un peu d'UML par ci et encore une notation propriétaire pour la description des mes processus métiers par là. Comment je fais pour vérifier la cohérence de l'ensemble et surtout pour la maintenir lorsque je fais le moindre changement. A la mimine ca décourage un peu.
Et c'est là que l'OMG a sorti sa grande idée. Déjà on a les modèles.
Chaque modèle est décrit par un langage. Et si on décrivait chacun de ces langages de modélisation par un modèle (le metamodèle) en utilisant un seul et même langage de description ? Et voici que le MOF (Meta Object Facility) fait son apparition. Il permet d'unifier tous les langages de modélisation et il s'auto-décrit. (Voir la fameuse pyramide 4 layers qui décrit tout ça - pas trouvé la photo). MOF étant une spec ,Eclipse avait donc besoin de l'implementer pour son projet EMF. Il s'agit d'Ecore (un sous-ensemble de MOF en fait). A partir de là on devient capable de faire des transformations de modèles entre 2 modèles d'un même langage mais aussi entre 2 modèles exprimé avec des formalismes différents puisqu'on maitrise la description de leur métamodèles. On parle de transformation M2M (Model 2 Model). Soyons joueur et décrivons la spec de ce langage de transformation. Nous l'appellerons QVT. ATL c'est une impléméntation de QVT même si elle en a un peu dérivé car QVT trainait un peu.
Reste un problème: Comment à partir d'un modèle peut on arriver à générer du code ? En soi, le code est décrit par un langage qui dispose de sa propre grammaire et donc de son métamodèle.
Toutefois écrire une transformation de M2M en considérant le code comme un modèle n'est pas chose aisée.
On préfère souvent utiliser d'autres techniques comme des langages à base de template décrivant le code généré par un fichier d'exemple qui contient des balises. Elles pointent sur des éléments du métamodèle associé au modèle à partir duquel on génère. Un peu à la manière des JSPs par exemple. On parle alors de langages de transformation M2T (Model 2 Text)
Acceleo par exemple joue dans cette catégorie et c'est pourquoi avec ATL, ils sont souvent complémentaires.
OpenArchitectuware propose les 2 types de langages ainsi que d'autres outils propriétaires comme MIA. Certains préfèrent s'appuyer sur un tooling pour les transfo M2M comme par exemple Rational Software Architect.
Dernière problématique. Passer d'un modèle à un autre n'est pas toujours évident car parfois on souhaite orienter la transformation ou lui rajouter des informations. Par exemple, passer d'un modèle UML d'analyse à un modèle de conception ou d'un modèle de conception à du code. Quitte a faire, ces infos de transfo ca n'est ni plus ni moin qu'un modèle . Appelons le modèle de marquage. Mais comment faire ? Soit on rajoute cette information dans le modèle de départ mais ca le pollue avec des informations inutiles pour ce niveau d'abstraction. C'est à ca que servent par exemple les profils UML qui sont des regroupements de stéréotypes.
On peut aussi les rajouter au modèle d'arrivée. Là la difficulté est de les placer dans le modèle alors que celui-ci n'existe pas. La troisième
est de l'associer à la transformation elle-même.
On se retrouve avec une jolie querelle de chapelle entre les protagoniste de UML et ses profils et les zélotes des DSL.
UML est standardisé et répandu. Il dispose d'outils graphiques et les profils sont faciles à mettre en oeuvre. Toutefois, il est trop riche pour les besoins et la mise au point des transformations ne s'en trouve pas facilitée. Les DSL quant à eux ne fournissent que le strict nécessaire. Mais on ne dispose pas encore de moyens simple pour en créer et notamment au niveau graphique même si ca s'améliore.
Autre reproche ca nécessite à chaque fois de s'approprier un nouveau formalisme.