Utilisez-vous MDA/MDD/MDSD, tout type d'approche basée sur un modèle ?Est-ce que ce sera le futur ?

https://stackoverflow.com/questions/21091

09-06-2019
|

Question

Les langages de programmation ont connu plusieurs étapes (r)évolutionnaires dans leur histoire.Certains affirment que les approches basées sur des modèles constitueront la prochaine grande nouveauté.Il existe des outils comme openArchitectureWare, AndroMDA, Sculptor/Fornax Platform, etc.qui promettent des gains de productivité incroyables.Cependant, j'ai fait l'expérience qu'il est soit assez facile au début de démarrer, mais aussi de rester bloqué à un moment donné lorsque vous essayez quelque chose d'inattendu ou assez difficile de trouver suffisamment d'informations qui vous indiquent comment démarrer votre projet car il peut y avoir beaucoup de choses à considérer.

Je pense qu'une idée importante pour tirer quelque chose de quelque chose basé sur un modèle est de comprendre que le modèle n'est pas nécessairement un ensemble de belles images ou un modèle d'arbre ou UML, mais peut tout aussi bien être une description textuelle (par ex.une machine à états, des règles métier, etc.).

Qu’en pensez-vous et que vous dit votre expérience ?Existe-t-il un avenir pour le développement piloté par les modèles (ou quel que soit le nom que vous voudriez lui donner) ?

Mise à jour: Il ne semble pas y avoir beaucoup d'intérêt pour ce sujet.S'il vous plaît laissez-moi savoir si vous avez une (bonne ou mauvaise) expérience avec les approches basées sur des modèles ou pourquoi vous pensez que ce n'est pas intéressant du tout.

La solution

Je pense qu'il faudra du temps jusqu'à ce que les outils soient plus raffinés et que davantage de personnes acquièrent de l'expérience avec MDD.À l’heure actuelle, si l’on veut tirer quelque chose du MDD, il faut investir beaucoup, son utilisation reste donc limitée.

En regardant openArchitectureWare par exemple :Bien qu'il soit assez robuste et qu'une documentation de base existe, la documentation sur le fonctionnement interne manque et il existe encore des problèmes d'évolutivité, qui ne sont pas documentés - cela s'améliorera peut-être lorsque Xtext et Xpand seront réécrits.

Mais malgré ces limitations, la génération elle-même est assez simple avec oAW, vous pouvez naviguer dans vos modèles comme un charme dans Xtend et Xpand et en combinant plusieurs workflows en workflows plus grands, vous pouvez également faire des choses très complexes.Si nécessaire, vous pouvez recourir à Java, vous disposez ainsi d'une très grande flexibilité dans ce que vous pouvez faire avec vos modèles.L'écriture de votre propre DSL avec Xtext dans oAW est également rapide, mais vous obtenez votre méta-modèle, un analyseur et un très bel éditeur essentiellement gratuitement.Vous pouvez également obtenir vos modèles pratiquement partout, par ex.un composant capable de convertir une base de données en méta-modèle et les modèles correspondants peuvent être écrits sans gros effort.

Je dirais donc que MDD continue de se développer, à mesure que les outils et l'expérience augmentent.Il peut déjà être utilisé avec succès, si vous disposez de l’expertise nécessaire et êtes prêt à le promouvoir au sein de votre entreprise.En fin de compte, je pense que c'est une très bonne chose, car beaucoup de code de colle (c'est-à-dire copier-coller) peut et doit être généré.Faire cela avec MDD est une manière très agréable et structurée de procéder, qui facilite la réutilisation, à mon avis.

Autres conseils

Clause de non-responsabilité:Je suis développeur d'applications métiers.Le point de vue suivant est certainement façonné par mes expériences dans l’informatique d’entreprise.Je suis conscient qu'il existe d'autres domaines de développement de logiciels.En particulier dans le développement de systèmes industriels et/ou embarqués, le monde pourrait être différent.

Je pense que MDSD est encore trop lié à la génération de code.

La génération de code n'est utile que lorsque votre code contient beaucoup de bruit et/ou est très répétitif.En d’autres termes, lorsque votre code ne peut pas se concentrer principalement sur la complexité essentielle, mais est pollué par une complexité accidentelle.

À mon avis, la tendance des plates-formes et des frameworks actuels est précisément de supprimer la complexité accidentelle et de laisser le code de l'application se concentrer sur la complexité essentielle.

Ces nouvelles plates-formes/cadres coupent donc beaucoup de souffle au mouvement MDSD.

Les DSL (textuels) sont une autre tendance qui tente de se concentrer uniquement sur la complexité essentielle.Bien que les DSL puissent être utilisés comme source pour la génération de code, ils ne sont pas principalement liés à la génération de code.Les DSL (en particulier les DSL internes) le laissent essentiellement s'ouvrir pour être interprété/exécuté au moment de l'exécution.[la génération de code d'exécution se situe quelque part entre les deux].

Donc même si les DSL sont souvent évoqués avec MDSD, je pense qu’ils constituent vraiment une alternative au MDSD.Et étant donné le battage médiatique actuel, ils réduisent également l’élan du mouvement MDSD.

Si vous avez atteint l'objectif de supprimer finalement la complexité accidentelle de votre code (je sais que c'est fictif), alors vous êtes arrivé à un modèle textuel de votre problème commercial.Cela ne peut pas être davantage simplifié !

Les jolis encadrés et diagrammes n’offrent pas une autre simplification ou élévation du niveau d’abstraction !Ils peuvent être utiles pour la visualisation, mais même cela est discutable.Une image n’est pas toujours la meilleure représentation pour saisir la complexité !

De plus, l'état actuel des outils impliqués dans MDSD ajoute un autre niveau de complexité accidentelle (pensez :synchronisation, différence/fusion, refactoring...) ce qui annule fondamentalement le but ultime de la simplification !

Regardez le modèle ActiveRecord suivant, pour illustrer ma théorie :

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

Je ne pense pas que cela puisse être plus simplifié.De plus, toute représentation graphique avec des cases et des lignes ne serait pas une simplification et n'offrirait plus de commodité (pensez à la mise en page, à la refactorisation, à la recherche, à la comparaison...).

Le développement piloté par les modèles existe depuis très longtemps.

La plus réussie des premières tentatives a été celle de James Martins Integrated Engineering Facility, qui existe toujours et est commercialisée par CA sous la marque très peu cool « Coolgen ».

Alors pourquoi n’a-t-il pas conquis le monde si c’était si bon ?

Eh bien, ces outils sont efficaces pour simplifier les choses simples, mais ils ne rendent pas les choses difficiles plus faciles et, dans de nombreux cas, rendent les choses difficiles plus difficiles !

Vous pouvez passer des heures à essayer de persuader un langage de modélisation graphique L4G de « faire la bonne chose » quand vous savez que coder la bonne chose en Java/C/SQL ou autre serait trivial.

Je pense qu'il n'y a peut-être pas de réponse définitive - d'où le manque "d'intérêt" pour cette question.

Mais j’ai personnellement eu une expérience mitigée avec MDA.La seule fois où c'était une bonne expérience, c'était avec d'excellents outils - j'utilisais TogetherSoft (je crois qu'ils se sont retrouvés d'une manière ou d'une autre chez Borland) - ils ont été l'un des premiers à introduire l'édition qui n'était pas une "génération de code" mais une véritable édition du code/ modèle directement (pour que vous puissiez éditer le code, ou le modèle, c'était une seule et même chose).Ils ont également eu une refactorisation (c'était la première fois que je m'en souviens après les environnements smalltalk).

Depuis lors, je n'ai pas vu MDA gagner en popularité, du moins dans le grand public, donc en termes de popularité, cela ne semble pas être l'avenir (donc ce genre de réponse).

Bien sûr, la popularité n'est pas tout, et les choses ont tendance à revenir, mais pour le moment, je pense que les outils MDA+ sont considérés par beaucoup comme des outils de "génération de code basé sur un assistant" (indépendamment de ce qu'ils sont réellement), donc je je pense qu’il faudra un certain temps, voire jamais, pour que cela décolle vraiment.

L'un des problèmes de MDD est que, puisqu'il fonctionne à un niveau d'abstraction plus élevé, il nécessite des développeurs capables également de monter au niveau d'abstraction.Cela réduit considérablement l’univers des développeurs capables de comprendre et d’utiliser de telles méthodologies.

S'il vous plaît laissez-moi savoir si vous avez une (bonne ou mauvaise) expérience avec les approches basées sur des modèles ou pourquoi vous pensez que ce n'est pas intéressant du tout.

Je pense que les contributeurs ici font partie du camp "No Silver Bullet" (je le suis définitivement).Si MDA fonctionnait (ce qui équivaut à des « économies énormes »), nous le saurions, c'est sûr.La question est:jusqu'où pouvez-vous aller « méta » tout en gardant votre système gérable ?Ce fut le tournant dans UML 2.0 lorsqu'ils introduisirent un méta-méta-modèle plus formel.Jusqu'à présent, je n'ai pas vu d'utilisation réelle de la puissance de modélisation d'UML 2.0 (mais mon monde est plutôt limité).De plus, vous n’avez que deux choix avec une approche basée sur un modèle :générer du code, ou avoir un runtime exploitant votre modèle.Le générateur de code sans contrainte ultime est dit « humain », alors que les runtimes ultimes se trouvaient dans les L4G (quel est le nombre actuel ?).Cela expliquerait peut-être le manque d’enthousiasme.

Chez itemis (www.itemis.com), nous utilisons beaucoup le développement logiciel basé sur des modèles.Jusqu’à présent, nous avons eu de très bonnes expériences.Bien sûr, ce n'est pas une solution miracle, mais cela contribue à améliorer la qualité des logiciels, donc une plus grande utilisation pour nos clients.

Le développement piloté par modèle sera l'avenir si et seulement si les modèles qu'il utilise peuvent être aussi flexibles que l'écriture du code qu'il est censé générer.Je pense que la raison pour laquelle cela ne fonctionne pas si bien en ce moment est qu'il est difficile de faire le même "aller-retour" que les langages de programmation basés sur du texte font depuis des décennies.

Avec les langages de programmation textuels, modifier le modèle est aussi simple que de modifier quelques lignes de code.Avec un langage de programmation graphique (c'est-à-dire un diagramme MDD comme UML), vous devez trouver un moyen de traduire ce modèle jusqu'à son équivalent textuel (qui était déjà expressivement efficace en premier lieu) et il peut être très, très compliqué.

À mon humble avis, la seule façon pour MDD d'être utile s'il est conçu dès le départ pour être aussi expressif et flexible que son homologue textuel.Tenter d'utiliser des langages de conception graphique descendants existants (tels que UML) pour des outils qui sont intrinsèquement construits de bas en haut à l'aide d'abstractions en couches (tels que les langages de programmation) pose un énorme décalage d'impédance.Je n'arrive pas vraiment à mettre le doigt dessus, mais il manque encore quelque chose dans MDD qui le rendrait aussi utile que les gens le prétendent...

C'est une réponse très tardive, mais je recherche actuellement des outils MDD pour remplacer Rose RT, qui est malheureusement supplanté par Rhapsody.Nous sommes dans l’espace C++ en temps réel, intégré et distribué et nous tirons BEAUCOUP de MDD.Nous essayons de passer à un meilleur outil et de généraliser son utilisation dans notre très grande entreprise.C’est une bataille difficile pour certaines des bonnes raisons mentionnées ici.

Je considère MDD comme un niveau au-dessus du compilateur, tout comme le compilateur est au-dessus de l'assemblage.Je veux un outil qui me permette, en tant qu'architecte, de développer le cadre d'application et de modifier en profondeur la génération de code (scripts) pour utiliser ce cadre et le middleware que nous utilisons pour la transmission des messages.Je veux que les développeurs créent des classes UML complètes et des diagrammes d'état qui incluent tout le code nécessaire pour générer l'application et/ou la bibliothèque.

Il est vrai que vous pouvez tout faire avec du code, mais je résumerais grossièrement les avantages de MDD comme suit :

Quelques personnes créent le cadre d'application, les adaptateurs middleware et les collent à l'outil MDD.Ils construisent la « maison ».
D'autres personnes créent des classes complètes, des diagrammes et du code de transition de machine à états.Cela leur permet de se concentrer sur l'application plutôt que sur la « maison ».
Il est facile de voir quand les gens ont une conception étrange puisque le diagramme est le code.Nous n'avons pas tous des développeurs experts et c'est bien de former des jeunes de cette façon.
Il s’agit principalement du mauvais code machine à états qui peut se produire dans quelque chose comme un projet de robotique mobile.Je veux que les gens créent des diagrammes d'état que je puisse comprendre, critiquer et avec lesquels travailler.
Vous pouvez également avoir une refactorisation intéressante comme une opération de glissement et des attributs vers des chaînes d'héritage ou vers d'autres classes, etc.J'aime mieux ça que de fouiller dans des fichiers.

Même en écrivant ceci, je me rends compte que vous pouvez tout faire avec du code.J'aime un outil fin juste au-dessus du code pour assurer l'uniformité, documenter la conception et permettre une refactorisation un peu plus facile.

Le principal problème que je rencontre et auquel je n'ai pas de bonne réponse est qu'il n'existe pas d'ensemble standard de fonctionnalités et de format de fichier pour de tels modèles.Les gens craignent que le vendeur s’en aille et se retrouve ensuite bloqué.(C'est ce qui s'est produit avec Rose RT.) Vous n'avez pas cela avec le code source.Cependant, vous disposerez de la dernière version de l'outil et du code de cours que vous avez généré en dernier :).Je suis prêt à parier que les avantages l'emportent sur les risques.

Je n'ai pas encore trouvé un outil comme celui-ci, mais j'essaie de convaincre quelques fournisseurs de m'écouter et peut-être d'accepter de l'argent pour y parvenir.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow