Le probleme du langage naturel c'est qu'il est ambigu. L'avantage de definir un DSL c'est justement d'avoir une base technique concrete deriere. Si tu utilises tel ou tel concepts c'est qu'il est definit et donc que tout le monde sait de quoi tu parles sans ambiguite. Apres libre a chacun d'en faire une utilisation special. Par exemple si tu decrit qu'un service sera accessible en TCP sur tel port et tel ip les actions aprendre sont de plusieurs ordre suivant ton interlocuteur :
- le fournisseur du service va ecouter sur ce port
- le client va se connecter sur ce port
- l'admin system va ouvrir le port dans un firewall par exemple
N'empeche que tout le monde va partager le meme modele pour avoir l'info. Et surtout le meme langage pour lever au maximum l'ambiguite. J'aime bien l'exemple de la micro bio dans un autre commentaire aussi. D'autre part c'est pas par ce qu'ont utilise un formalisme technique qu'il ne faut pas se parler. L'un ne remplace pas l'autre. C'est un outil parmi d'autres.
Les hommes n'ont pas attendu l'invention du briquet pour allumer un feu. Pourtant c'est plus pratique d'utiliser un briquet.
Pour ce qui est de la vente d'un projet ca fait partie de la vie du projet. Je pense pas qu'on lance la construction d'un viaduc si personne n'est pret a financer sa construction. Pour ce qui est du formalisme a apporter pour le construire je suis contant de voir que tu ne choisirais pas UML. Fait gaffe t'es en train de devenir un pro du MDA :)
Acceleo (et surement d'autres generateurs) propose la generation incrementale grace a un systeme de balise (les user code) typiquement ca sert a remplire le code des methodes, prevoir une zone pour ajouter des methodes, des attributs... Ces balises ont des identifiants qui permettent de les retrouver et de pas les ecraser lors d'une regeneration.
Apres si tu fais une modification hors de ces balise c'est mal. Pourquoi ? Il y a deux cas de figure :
- tu changes du code generee a partir du modele => au lieu de changer le code il faut changer le modele (un nom de methode par exemple get<nom attribut> il faut changer le nom de l'attribut dans le modele)
- tu change du code produit par un template => au lieu de changer le code il faut changer le template (par exemple changer le prototype d'un traitement pour passer un progress monitor)
Je vais essayer d'apporter mon point de vue sur le MDA et la generation de code. Ce n'est surement pas une verite absolue ni meme complete mais j'espere que ca aidera a y voir plus clair.
Deja la modelisation c'est pas forcement UML. Avec UML l'OMG a voulu apporte une solution generaliste pour modeliser le maximum de choses. L'autre approche est ce qu'on appelle les DSL (domain specific languages). L'idee dans le cas des DSL est de faire son propre langage qui manipule les concepts de son metier. On peut prendre l'exemple de l'application du langage Logos pour piloter la tortue (http://en.wikipedia.org/wiki/Logo_%28programming_language%29(...) C'est plus facile de manipuler directement un langage avec des actions comprises par l'utilisateur (un enfant dans cet exemple).
La premiere etape est donc de savoir si l'on veut aller vers tel ou tel type de modelisation.
La deuxieme etape est de savoir quoi modeliser. Pour certaines utilisation il faut avoir un grain tres fin pour d'autres ce n'est pas necessaire. Il faut donc savoir ce que l'on veut faire avec ses modeles. Un modele de retro ingenierie est beaucoup plus complexe qu'un modele de generation de squelettes d'application par exemple.
Dans le cas de la generation il faut aussi placer un curseur pour dire cette partie la on la modelise pour la generer et cella pas. Par exemple pour le cas d'un moteur de rendu 3D c'est illusoire de modeliser chaque instruction d'un algo de rendu. Par contre il est possible de definir l'architecture du moteur de rendu et de generer 10% ou 20% de l'application (par exemple). Pour une application plus traditionnelle de gestion il est possible de modeliser et donc de generer beacoup plus de chose.
Dans ces choses on va retrouver des regles metier et c'est la que le DSL est a mon sens plus interessant. Avec le bon DSL il est possible de laisser l'expert du metier manipuler son metier tout en assurant une base technique qui permet d'utiliser directement dans le systeme d'information (par exemple l'enfant et le robot tortue).
Une autre etape est de savoir comment presenter ces concepte a l'expert du metier. C'est ce qu'on appelle la syntaxe concrete par oposition a la description des concepts qui represente la syntaxe abstraite. Dans les syntaxes concretes on retrouve deux grandes familles les syntaxes textuelles et les syntaxes graphiques. Il faut donc choisir celle qui est la mieux addapter. Par exemple utiliser une syntaxe textuelle pour decrire des IHM c'est peut etre pas tres intuitif.
Pour en revenir a la generation il y a un point important a considerer c'est de savoir si l'on veut travailler en iteration ou en one shot. C'est a dire faire des aller retour entre la phase de modelisation et de generation/modification du code ou pas. Pour ce qui est de l'exemple du moteur 3D l'approche la plus plausible est le one shot. On lance une generation une fois que l'architecture est figee et on oublie les generateurs par la suite quand on implemente les algo de rendu. Mais le travail se fait le plus souvent par iteration modelisation / generation / ajout de code manuel / modification de la modelisation / regeneration / ...
On voit que le soit apporte aux generateurs ne sera probablement pas le meme dans les deux cas. Mais l'avantage de la generaration sur ce point c'est que les modifications du code sont centralisees. Une correction de bug dans un template de generation va s'appliquer plusieurs fois dans le code generer. De meme l'argument facile du genre "le code est moche" ne tient pas. Si le code est moche il faut changer le generateur pour le rendre beau. Une fois fait tout les utilisateurs du generateur profitent de l'amelioration.
Bref y a surement plein d'autres choses a dire mais si ce qu'il y a au dessus vous parle un minimum il faut continuer sur google. Et je dirais aussi que si une solution est trop belle pour etre vrai c'est qu'elle doit etre fausse... Si on modelise n'importe comment ou n'importe quoi on arrive sur le meme probleme que le code ecrit n'importe comment qui fait n'importe quoi. Faut juste etre un peu realiste :)
Et pour finir quelques projets qui utilisent la generation de code:
EMF (Eclipse Modeling Framwork) : il utilise JET (Java Emitter Templates) pour generer sont code a partir de sa propre specification (a quelques details technique pret).
EEF (Extended Editing Framework) qui permet de faire des vue propriete plus sexy pour les editeurs Eclipse. Il repose sur le projet Eclipse Acceleo. Ceci dit il est en incubation mais vu l'age du projet et ce qu'il permet deja de faire je pense que c'est juste impossible de faire la meme chose a la main...
Acceleo utilise JET aussi pour des questions de bootstrap.
La plus part des projets qui dependent d'EMF utilisent les generateurs JET d'EMF
Microsoft a aussi une plateforme de modelisation DSLTools... Je connais moins les projets qui gravitent autour.
J'ai aussi une liste de projet prives pour des SSII et autres integrateurs. Je pense qu'une recherche google devrait vous donner des resultats (Acceleo + <nom d'une SSII>). Elles utilisent surement d'autres generateurs d'ailleurs.
Pour les exemple d'utilisation du MDA il est possible de citer la migration et la modernisation d'application. Et tout ce qu'il est possible de faire avec un DSL. L'executer par exemple...
[^] # Re: Voilà une bonne nouvelle: plus besoin de programmeurs
Posté par ylussaud . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 2.
Le probleme du langage naturel c'est qu'il est ambigu. L'avantage de definir un DSL c'est justement d'avoir une base technique concrete deriere. Si tu utilises tel ou tel concepts c'est qu'il est definit et donc que tout le monde sait de quoi tu parles sans ambiguite. Apres libre a chacun d'en faire une utilisation special. Par exemple si tu decrit qu'un service sera accessible en TCP sur tel port et tel ip les actions aprendre sont de plusieurs ordre suivant ton interlocuteur :
- le fournisseur du service va ecouter sur ce port
- le client va se connecter sur ce port
- l'admin system va ouvrir le port dans un firewall par exemple
N'empeche que tout le monde va partager le meme modele pour avoir l'info. Et surtout le meme langage pour lever au maximum l'ambiguite. J'aime bien l'exemple de la micro bio dans un autre commentaire aussi. D'autre part c'est pas par ce qu'ont utilise un formalisme technique qu'il ne faut pas se parler. L'un ne remplace pas l'autre. C'est un outil parmi d'autres.
Les hommes n'ont pas attendu l'invention du briquet pour allumer un feu. Pourtant c'est plus pratique d'utiliser un briquet.
Pour ce qui est de la vente d'un projet ca fait partie de la vie du projet. Je pense pas qu'on lance la construction d'un viaduc si personne n'est pret a financer sa construction. Pour ce qui est du formalisme a apporter pour le construire je suis contant de voir que tu ne choisirais pas UML. Fait gaffe t'es en train de devenir un pro du MDA :)
cordialement,
Yvan.
[^] # Re: On est pas vendredi mais je m'en fous
Posté par ylussaud . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 2.
Apres si tu fais une modification hors de ces balise c'est mal. Pourquoi ? Il y a deux cas de figure :
- tu changes du code generee a partir du modele => au lieu de changer le code il faut changer le modele (un nom de methode par exemple get<nom attribut> il faut changer le nom de l'attribut dans le modele)
- tu change du code produit par un template => au lieu de changer le code il faut changer le template (par exemple changer le prototype d'un traitement pour passer un progress monitor)
Yvan
# Quelques informations
Posté par ylussaud . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 3.
Je vais essayer d'apporter mon point de vue sur le MDA et la generation de code. Ce n'est surement pas une verite absolue ni meme complete mais j'espere que ca aidera a y voir plus clair.
Deja la modelisation c'est pas forcement UML. Avec UML l'OMG a voulu apporte une solution generaliste pour modeliser le maximum de choses. L'autre approche est ce qu'on appelle les DSL (domain specific languages). L'idee dans le cas des DSL est de faire son propre langage qui manipule les concepts de son metier. On peut prendre l'exemple de l'application du langage Logos pour piloter la tortue (http://en.wikipedia.org/wiki/Logo_%28programming_language%29(...) C'est plus facile de manipuler directement un langage avec des actions comprises par l'utilisateur (un enfant dans cet exemple).
La premiere etape est donc de savoir si l'on veut aller vers tel ou tel type de modelisation.
La deuxieme etape est de savoir quoi modeliser. Pour certaines utilisation il faut avoir un grain tres fin pour d'autres ce n'est pas necessaire. Il faut donc savoir ce que l'on veut faire avec ses modeles. Un modele de retro ingenierie est beaucoup plus complexe qu'un modele de generation de squelettes d'application par exemple.
Dans le cas de la generation il faut aussi placer un curseur pour dire cette partie la on la modelise pour la generer et cella pas. Par exemple pour le cas d'un moteur de rendu 3D c'est illusoire de modeliser chaque instruction d'un algo de rendu. Par contre il est possible de definir l'architecture du moteur de rendu et de generer 10% ou 20% de l'application (par exemple). Pour une application plus traditionnelle de gestion il est possible de modeliser et donc de generer beacoup plus de chose.
Dans ces choses on va retrouver des regles metier et c'est la que le DSL est a mon sens plus interessant. Avec le bon DSL il est possible de laisser l'expert du metier manipuler son metier tout en assurant une base technique qui permet d'utiliser directement dans le systeme d'information (par exemple l'enfant et le robot tortue).
Une autre etape est de savoir comment presenter ces concepte a l'expert du metier. C'est ce qu'on appelle la syntaxe concrete par oposition a la description des concepts qui represente la syntaxe abstraite. Dans les syntaxes concretes on retrouve deux grandes familles les syntaxes textuelles et les syntaxes graphiques. Il faut donc choisir celle qui est la mieux addapter. Par exemple utiliser une syntaxe textuelle pour decrire des IHM c'est peut etre pas tres intuitif.
Pour en revenir a la generation il y a un point important a considerer c'est de savoir si l'on veut travailler en iteration ou en one shot. C'est a dire faire des aller retour entre la phase de modelisation et de generation/modification du code ou pas. Pour ce qui est de l'exemple du moteur 3D l'approche la plus plausible est le one shot. On lance une generation une fois que l'architecture est figee et on oublie les generateurs par la suite quand on implemente les algo de rendu. Mais le travail se fait le plus souvent par iteration modelisation / generation / ajout de code manuel / modification de la modelisation / regeneration / ...
On voit que le soit apporte aux generateurs ne sera probablement pas le meme dans les deux cas. Mais l'avantage de la generaration sur ce point c'est que les modifications du code sont centralisees. Une correction de bug dans un template de generation va s'appliquer plusieurs fois dans le code generer. De meme l'argument facile du genre "le code est moche" ne tient pas. Si le code est moche il faut changer le generateur pour le rendre beau. Une fois fait tout les utilisateurs du generateur profitent de l'amelioration.
Bref y a surement plein d'autres choses a dire mais si ce qu'il y a au dessus vous parle un minimum il faut continuer sur google. Et je dirais aussi que si une solution est trop belle pour etre vrai c'est qu'elle doit etre fausse... Si on modelise n'importe comment ou n'importe quoi on arrive sur le meme probleme que le code ecrit n'importe comment qui fait n'importe quoi. Faut juste etre un peu realiste :)
Et pour finir quelques projets qui utilisent la generation de code:
EMF (Eclipse Modeling Framwork) : il utilise JET (Java Emitter Templates) pour generer sont code a partir de sa propre specification (a quelques details technique pret).
EEF (Extended Editing Framework) qui permet de faire des vue propriete plus sexy pour les editeurs Eclipse. Il repose sur le projet Eclipse Acceleo. Ceci dit il est en incubation mais vu l'age du projet et ce qu'il permet deja de faire je pense que c'est juste impossible de faire la meme chose a la main...
Acceleo utilise JET aussi pour des questions de bootstrap.
La plus part des projets qui dependent d'EMF utilisent les generateurs JET d'EMF
Microsoft a aussi une plateforme de modelisation DSLTools... Je connais moins les projets qui gravitent autour.
J'ai aussi une liste de projet prives pour des SSII et autres integrateurs. Je pense qu'une recherche google devrait vous donner des resultats (Acceleo + <nom d'une SSII>). Elles utilisent surement d'autres generateurs d'ailleurs.
Pour les exemple d'utilisation du MDA il est possible de citer la migration et la modernisation d'application. Et tout ce qu'il est possible de faire avec un DSL. L'executer par exemple...
cordialement,
Yvan.