Pourquoi ne faisons-nous pas tous encore du développement basé sur des modèles? [fermé]

Je suis un vrai partisan du développement piloté par les modèles, je pense qu'il a la possibilité d'augmenter la productivité, la qualité et la prévisibilité. En regardant MetaEdit, les résultats sont incroyables. Aux Pays-Bas, Mendix se développe très très rapidement et donne d'excellents résultats.

Je sais aussi qu'il y a beaucoup de problèmes

• versioning des générateurs, des modèles et du framework
• projets qui ne conviennent tout simplement pas au développement axé sur les modèles (pas assez de répétition)
• des risques plus élevés (lorsque le premier projet échoue, vous avez moins de résultats que vous n'auriez avec un développement plus traditionnel)
• etc

Mais ces problèmes semblent toujours résolubles et les avantages devraient l'emporter sur les efforts nécessaires.

Question : Quels sont, selon vous, les plus gros problèmes qui vous empêchent même de considérer le développement piloté par les modèles?

Je veux utiliser ces réponses non seulement pour ma propre compréhension, mais aussi comme une source possible pour une série d'articles internes que je prévois d'écrire.

Il n'y a pas de marteau d'or. Ce qui fonctionne bien dans un domaine est assez inutile dans un autre. Il existe une certaine complexité inhérente au développement de logiciels, et aucun outil magique ne le supprimera.

On pourrait également affirmer que la génération de code n'est utile que si le langage lui-même (ou le framework) n'est pas suffisamment élevé pour permettre des abstractions puissantes qui rendraient MDD relativement inutile.

Question interessante! J'avoue que je ne suis pas un fan, mais j'ai ensuite essayé d'utiliser le développement piloté par les modèles à plusieurs reprises dans des projets qui correspondent à certains des problèmes que vous venez de soulever.

Voici ma liste de raisons:

• courbe d'apprentissage - les outils de modélisation ont évolué si rapidement que j'ai du mal à trouver des ingénieurs qui comprennent profondément l'outil. Je trouve toujours que vous êtes aussi bon que votre outil de modélisation. Certes, bon nombre des problèmes ci-dessous pourraient remonter à ce seul problème - chaque fois que vous pensez qu'un outil est trop limitatif, il est possible que vous ne le connaissiez pas assez bien.
• Trop structuré - Personnellement, j'ai été dans des situations où j'ai trouvé que l'outil de modélisation était tout simplement trop structuré pour me permettre de décrire tout ce dont j'avais besoin pour décrire. Et une fois que je suis passé à dessiner quelques morceaux du modèle à l'extérieur de l'outil, les choses se dégradent rapidement lorsque les gens commencent à dériver à l'extérieur de l'outil pour trouver les informations.
• Coût de l'optimisation de l'outil - chaque fois que j'ai essayé de générer automatiquement du code, j'ai fini par retravailler manuellement le code une fois que je voyais ce que l'outil pensait être juste. Je sais qu'après quelques détours, ce problème diminue, mais cela signifie que vous devez survivre aux premiers détours. J'ai généralement l'impression que nous jouions à un taupe - créer un modèle -> générer du code -> corriger le code -> mettre à jour le modèle -> corriger le modèle, rincer et répéter.
• Gestion de la configuration du modèle - puisque le modèle décrit de grandes parties du projet, à un certain niveau, le modèle CM sera plus transversal que le code construit. Compartimenter les fichiers de modélisation est un art en soi - faites-le mal et vous vous retrouvez souvent avec un blocage de développeur ou des modèles obsolètes lorsque les gens abandonnent et descendent vers le code.
• délai de mise sur le marché - J'ai rencontré des problèmes certains dans une situation où le besoin d'un logiciel fonctionnel était urgent. Si le projet et l'équipe sont suffisamment petits, je ne vois aucune raison de perdre du temps sur un outil de modélisation lorsque le temps peut être consacré au codage et aux tests. Tous les projets ne sont pas suffisamment importants pour nécessiter un tel investissement.
• Coût de l'échec - lorsque j'ai vu des projets fuir les outils de modélisation, c'est à cause du coût élevé de l'échec - pour utiliser les outils, vous avez besoin que chaque développeur soit impliqué. C'est un gros investissement dans la formation et l'apprentissage pratique, et une erreur très coûteuse si quelqu'un a mal configuré le modèle. D'après mon expérience, cela peut prendre deux ou trois versions pour obtenir le bon modèle - de nombreux projets ne survivent donc pas assez longtemps aux erreurs de modélisation pour en tirer les avantages.

Il a déjà été cité, mais No Silver Bullet aborde assez bien le point:

L'essence d'une entité logicielle est une construction de concepts imbriqués: ensembles de données, relations entre les éléments de données, algorithmes et invocations de fonctions. Cette essence est abstraite dans la mesure où une telle construction conceptuelle est la même sous de nombreuses représentations différentes. Il est néanmoins très précis et richement détaillé.

Je crois que la partie difficile de la construction d'un logiciel est la spécification, la conception et les tests de cette construction conceptuelle, pas le travail de la représenter et de tester la fidélité de la représentation. Nous faisons toujours des erreurs de syntaxe, bien sûr; mais elles sont floues par rapport aux erreurs conceptuelles dans la plupart des systèmes.

Si cela est vrai, la création de logiciels sera toujours difficile. Il n'y a intrinsèquement pas de solution miracle.

Plus tard, Brooks souligne ce qui suit au sujet du concept de "programmation automatique":

Depuis près de 40 ans, les gens anticipent et écrivent sur la «programmation automatique» ou la génération d'un programme pour résoudre un problème à partir d'un énoncé des spécifications du problème. Certains écrivent aujourd'hui comme s'ils s'attendaient à ce que cette technologie fournisse la prochaine percée.

Parnas implique que le terme est utilisé pour le glamour, pas pour le contenu sémantique, affirmant: "En bref, la programmation automatique a toujours été un euphémisme pour la programmation avec un langage de niveau supérieur à celui qui était actuellement disponible pour le programmeur."

Il fait valoir, en substance, que dans la plupart des cas, c'est la méthode de résolution, et non le problème, dont la spécification doit être donnée.

Fondamentalement, je dirais que MDD n'est qu'un autre euphémisme pour la programmation avec un langage de niveau supérieur à celui qui était auparavant disponible.

Cela ne veut pas dire que la programmation dans un langage de niveau supérieur ne peut pas aider - en fait, c'est souvent le cas. Mais l' essence du problème reste le même: peu importe la qualité d'un outil ou la qualité d'une langue que vous utilisez, à la fin de la journée, vous devez réfléchir à tous les problèmes et résoudre les problèmes. Le mieux que tout outil ou processus puisse faire est de supprimer le "fuzz" afin que vous puissiez vous concentrer sur la question importante, qui est, comme l'a dit Brooks, "la spécification , la conception et les tests de cette construction conceptuelle ".

Parce que toute la programmation n'est pas orientée objet, ce que tous les outils MDD semblent attendre. UML lui-même est basé sur la présomption d'objets. Bien sûr, vous pouvez utiliser des diagrammes de séquence pour modéliser des fonctions, mais cela est souvent maladroit.

Parce qu'il y a des programmeurs comme moi qui obtiennent plus de progrès et de résultats avec TDD qu'avec MDD.

Parce que la modélisation! = Programmation.

Parce que le rapport coût / bénéfice était trop élevé du côté des coûts et pas assez du côté des avantages. Cela a probablement changé depuis la dernière fois que j'ai examiné MDD, à l'époque, vous seriez tenu de payer> 6 000 $ / siège (USD) pour un outil qui serait modérément capable de MDD.

Parce qu'un modèle qui décrit suffisamment une fonction pour générer le code n'est plus utile comme modèle.

Parce qu'il y a des programmeurs comme moi qui n'utilisent que des modèles à un niveau élevé, puis travaillent les détails avec du code. Vous voyez les choses différemment dans le code que dans les logiciels de modélisation.

Ce sont quelques-unes des raisons pour lesquelles je ne fais pas personnellement de MDD. J'y ai été exposé, mais rien n'a pu faire de moi un converti. Je suis peut-être trop vieille école. Peut-être que je suis trop nouvelle école (quoi que ce soit). Ce n'est tout simplement pas un outil que j'ai réussi à rentabiliser.

Microsoft / Apple / Google ne le pousse pas :)

Le type de développement qui se popularise a beaucoup à voir avec les outils, le soutien et l'évangélisation. Il est très difficile de percer avec quelque chose sans avoir un gros bailleur de fonds (Ruby on rails étant peut-être l'exception, mais il est toujours petit par rapport à Java / C # / Python)

En raison d'une loi simple qui a affecté tous ces outils de modélisation, vous savez, CASE, UML et autres:

Se déplacer entre un programmeur et son code est très coûteux.

Si vous le faites, vous devez construire un compilateur / interprète approprié, les générateurs de code entraînent un flux de travail terrible et des commentaires terribles pour le programmeur (messages d'erreur et autres).

L'un des grands enseignements de la conception pilotée par domaine est que les modèles doivent être en code, et non en quelque chose d'extérieur au code.

En fin de compte, la question est: pourquoi vos modèles ne correspondent-ils pas au code? Si vous faites du développement intégré et que vous êtes coincé avec C ou si vous devez générer du code pour différentes plates-formes, la génération de code peut en valoir le coût. Pour tout le monde, un langage de programmation plus puissant et une meilleure conception de code sont généralement meilleurs que de concevoir le code dans autre chose que le code.

• On dirait un tracas gigantesque pour très peu d'avantages.
• J'ai toujours l'air de penser aux cas de bord et aux choses étranges, les trucs magiques ne semblent jamais vraiment fonctionner correctement.
• OO n'est pas une balle d'argent; blobbing une méthodologie de génération de logiciels sur OO ne le rend pas argent.

Mais je n'aime pas les solutions d'entreprise en général.

J'ai eu la discussion et j'aimerais faire du MDA, mais le plus gros inconvénient est le support d'outils pour l'instant. J'utilise une dérivation de MDA que j'aime appeler «évaluation du modèle d'exécution», mais plus à ce sujet plus tard.

Les inconvénients de MDA sont, comme je le sais:

• Support de refactoring manquant: laisse deviner que je veux modéliser les entités de mon modèle de données avec MDA (cas d'utilisation typique n ° 1). Si j'ai mon modèle dans, disons, un diagramme UML, et que je le change, rien de mon code ne change avec lui (au moins les classes générées), et au lieu d'avoir toujours une application qui fonctionne avec des attributs mieux nommés, j'obtiens un beaucoup d'erreurs que je dois corriger manuellement.
• Prise en charge du débogage manquante: généralement, les traductions du modèle au code sont effectuées en ayant un langage de transformation à portée de main. Ce ne serait généralement pas un problème, mais lorsque nous déboguons, nous ne devrions pas, de manière optimale, nous soucier du code que nous générons, et un débogueur devrait entrer dans le modèle de transformation. Au lieu de cela, il pénètre dans le code généré, et comme nous le savons tous, les transformations devraient bien paraître, pas le code généré. Okey, nous pouvons assez l'imprimer, mais dans un monde optimal, le code généré est un artefact du compilateur, et ne devrait jamais avoir à être ouvert dans un éditeur pour une session de débogage (je pourrais vivre avec, et cet argument est un peu théoriquement, mais c'est une raison contre MDA)
• Les modèles codés sont faciles: dans d'autres exemples, le modèle pourrait modéliser un aspect de domaine, et qui est ensuite compilé en code. Oui, c'est MDA, mais la plupart des modèles MDA ne sont que des fichiers de configuration sophistiqués, qui pourraient facilement être manipulés au moment de l'exécution.
• Les transformations sont difficiles à tester: si vous utilisez des transformations dans un IDE spécialisé, elles sont effectuées par le "compilateur" des IDE. Mais les transformations doivent être considérées comme faisant partie du code de l'application, et en tant que telles doivent également subir les exigences de test et de couverture de code de l'application.

Ce que je préfère actuellement, c'est «Évaluation du modèle d'exécution» (si quelqu'un connaît un nom accepté pour cela, veuillez m'éclairer). Mes entités sont stockées dans des classes Java ordinaires, et tout ce dont j'ai besoin pour "modéliser" est fait par des annotations que j'ai lues au début de l'application. Aucune transformation nécessaire, il était juste un peu difficile d'obtenir mon bon modèle de méta.

Tout le reste se fait soit avec des fichiers de propriétés, soit avec XML pour les données hiérarchiques. Si vous avez un modèle, il est toujours hiérarchique, il n'y a donc rien que vous puissiez modéliser que vous ne puissiez pas également exprimer avec XML. Et si vous avez besoin d'un éditeur de modèle spécial, que vous devrez probablement écrire également, vous pouvez également créer un éditeur qui fonctionne même au moment de l'exécution de l'application et rend l'application plus configurable que tout ce que vous pourriez modéliser.

Je pense que la plupart des gens qui utilisent No Silver Bullet de Fred Brooks pour expliquer pourquoi les gens ne font pas de TDM manquent l'argument avancé par Brooks. Bien sûr, la conclusion finale est que la complexité intrinsèque réelle du développement de logiciels ne disparaîtra jamais et que MDD ne résoudra pas cela.

Mais une des raisons pour lesquelles Brooks discute même de cette complexité intrinsèque est de la comparer à la grande quantité de temps que nous passons généralement à nous battre avec les langages, les bibliothèques et les outils, c'est-à-dire à ne pas traiter la complexité intrinsèque du problème que nous essayons de résoudre. C'est donc exactement là où MDD brille: couper tout le fuzz et créer un langage, un modèle ou un autre formalisme sur mesure pour faire face à la complexité réelle à portée de main.

De ce point de vue, No Silver Bullet est donc une excellente raison d'investir dans MDD. Autrement dit, si ce n'était pas le problème qui, je crois, entrave l'adoption du MDD: le développement réel d'un environnement piloté par un modèle qui vous permet de vous concentrer complètement sur la complexité intrinsèque du problème que vous essayez de résoudre est beaucoup plus difficile que il suffit de résoudre le problème directement dans un langage général. Principalement parce que l'outillage MDD existant est extrêmement complexe.

Comparez-le comme ceci: il est beaucoup plus facile d'écrire un programme en C que d'écrire un compilateur C. Au lieu de simplement résoudre un problème et de traiter la cruauté dans un langage général, créer un environnement MDD pour d'autres développeurs vous oblige à écrire un programme qui résout tous les problèmes liés à la cruauté dans l'espace des problèmes à l'avant. C'est assez difficile.

À ma connaissance, MDE et MDA ne répondent pas suffisamment aux besoins du développeur de contrôleur intégré. Les modèles peuvent certainement être utilisés pour décrire un système, mais je ne pense pas que le développeur intégré soit prêt à faire confiance au modèle pour fournir le meilleur code source, voire correct.

Il existe un certain nombre de plug-ins pour Eclipse qui permettent à un développeur d'utiliser soit le modèle pour créer / mettre à jour le code Java, soit le code Java pour créer / mettre à jour le modèle. Cela semble être un outil pratique. Malheureusement, tout mon développement se fait en ANSI / ISO C, et il n'y a pas de plugins, à ma connaissance, qui me permettraient de faire la même chose.

En outre, comment un développeur peut-il demander au modèle d'implémenter le code en tant que HSM piloté par les événements, ou tout autre modèle de conception, par rapport à tout autre modèle de conception (ou anti-modèle)? Si le code est mis à jour manuellement pour utiliser un modèle de conception inconnu, le modèle peut-il représenter cela avec précision?

Comment implémentez-vous ces fonctions qui ne rentrent pas dans un modèle?

Réponse courte… parce que le modèle est souvent lié à la génération de code et que le code est fragile; ce dont nous avons besoin, c'est de l'élimination du code et du modèle est certainement la voie à suivre.

Certains ont rejeté la question en faisant valoir qu'il n'y a pas de marteau d'or et que le développement de logiciels est intrinsèquement complexe.

Je suis tout à fait d'accord avec eux qu'il n'y a pas de marteau en or mais je ne pense pas que le modèle piloté soit une quête de marteaux en or ou de balles en argent!

Je voudrais aller plus loin dans la complexité; il y a deux sortes de complexité, que j'appelle la complexité organique ou naturelle, complexité inhérente à l'entreprise et à ses processus, mais nous avons aussi la complexité cérémonielle.

Une complexité qui s'introduit jour après jour dans le système, instruction par instruction. La complexité cérémonielle - complexité inutile - émerge essentiellement de la manipulation incontrôlée du code technique avec le code orienté métier, mais aussi du manque de structure et d'uniformité du système.

Aujourd'hui, toute la complexité qui hante le développement des systèmes d'information et provoque l'échec et la taille est une complexité cérémonielle; complexité qui peut être éliminée.

La complexité cérémonielle est un gaspillage, un gaspillage causé par un code, une valeur moindre, un changement défavorable, un code invariant; code qui doit être réduit à son strict minimum.

Comment faire ça? Facile, il suffit de ne pas l'écrire et de ne pas le générer, en premier lieu!

Code technique nécessaire et invariant; code utilisé pour lire / écrire, afficher, communiquer… Les données.

C'est comme un système d'exploitation, vous ne le réécrivez pas pour chaque projet que vous utilisez. Donc, ce qu'il faut, c'est un moteur technique qui gère les aspects invariants du logiciel étant donné un modèle. Je l'appelle un moteur AaaS (Architecture as a Service).

En ce qui concerne le code inutile, il s'agit bien d'un code inutile, il est donc préférable de le laisser non écrit.

Cela nous laisse avec le code nécessaire, orienté métier qui devrait être écrit, les données orientées métier nécessaires qui devraient être conçues et l'interface utilisateur et l'expérience nécessaires qui devraient être conçues et imaginées.

En éliminant le code fragile, nous pouvons adopter l'architecture en tant que service, un nouveau paradigme pour le développement logiciel basé beaucoup plus sur la modélisation et la conception que sur le code.

Je crois qu'il y a plusieurs raisons, mais l'une est sûre que MDD n'est pas dans le programme des universités. Typiquement, le plus proche est un cours qui enseigne la modélisation et là les modèles restent sous forme d'esquisses (pas de vérification, génération de code, débogage au niveau du modèle). Ce cours de «modélisation» présente souvent également UML et les étudiants ne savent pas pourquoi apprendre une notation aussi grande et complexe lorsque la valeur des modèles créés est faible.

Comparez cela à d'autres domaines de l'ingénierie comme les développeurs de matériel embarqué ou les ingénieurs de contrôle où les étudiants obtiennent une expérience très différente. Avec des outils comme Simulink ou Labview, les élèves peuvent dessiner un modèle puis il vous a généré le code, ou au moins vous pouvez l'exécuter en simulation.

Dans le passé, les universités enseignaient les compilateurs et les analyseurs, mais maintenant elles devraient apprendre à fabriquer des générateurs, à mettre en œuvre des DSL, etc.

Le développement piloté par les modèles est un non-sens car il s'agit d'une approche descendante du modèle au code. Il est impossible de créer une application en cours d'exécution uniquement à partir d'un modèle et donc MDD est inutile !!

Ce que je fais, c'est d'utiliser uniquement UML à un niveau d'abstraction plus élevé pour créer le squelette de mon application. Je veux dire créer des packages, des classes etc ... puis commencer immédiatement à coder en langage Java.

J'ai trouvé que la synchronisation en direct avec des outils tels que Togethersoft, Omondo était vraiment utile lorsque j'ai commencé à modéliser pour la première fois en 2004. Une nouvelle étape a été récemment introduite par Omondo qui est une sorte de mappage entre Java, le modèle et l'ID de la base de données. Vraiment puissant et ça marche bien dans mes projets.

Mes diagrammes UML m'aident maintenant à accélérer mon projet et ne sont plus inutiles :-)

MDD ajoute une autre étape au processus de développement, qui est un inconvénient dans les situations où il n'y a pas de bon modèle et la première solution partielle imprévisible ou presque cassée sur le marché pourrait bien gagner le plus de billes.

Il a été très difficile d'avoir des modèles de processus opérationnels exécutables. En théorie, vous n'auriez pas du tout besoin de programmeurs pour cela. La pratique montre qu'avec MDE, obtenir un modèle réel est tout aussi compliqué que d'écrire du code.

Je dirais que pour un développeur expérimenté, il serait beaucoup plus facile de remplir des classes générées à partir d'UML, que de se soucier par exemple d'ExecutableUML. D'un autre côté, pour ExecutableUML, vous avez besoin d'une quantité importante de connaissances en informatique, vous ne pouvez donc pas compter sur le chef d'entreprise pour le créer lui-même. En théorie, il ne ferait que combiner des blocs prêts à l'emploi (classes), mais en fait la "colle" est ce qui cause des problèmes.

De plus, l'utilité de MDE est limitée aux systèmes avec beaucoup de réutilisation de composants.

MBSE - Model Based Software Engineering est le terme le plus pertinent.

En posant la question des différents outils qui sont en effet des solutions ponctuelles, MBSE nécessite un workflow de projet différent. Le DSML (langage de modélisation spécifique au domaine) doit être au niveau d'abstraction requis pour communiquer efficacement les exigences de révision avec les parties prenantes. Ensuite, vous devez transformer le modèle en augmentant sans cesse les niveaux de raffinement pour éventuellement générer du code.

Lorsque vous avez le DSML et les processus de transformation / génération entièrement et correctement mis en œuvre, la génération d'artefacts a un coût très faible. Mais jusqu'à ce que vous atteigniez ce stade de l'outillage débogué, c'est très douloureux.

La plupart des réussites de MDD se situent dans le domaine de l'ingénierie de gamme de produits (PLE), où une succession de produits similaires est générée à l'aide d'outils établis. Bien sûr, la plupart des générateurs de code Java sont des versions vraiment simplifiées de MDD. Du XML en entrée et du code généré en sortie.

Tu as écrit:

Je sais aussi qu'il y a beaucoup de problèmes ... des projets qui ne sont tout simplement pas adaptés au développement basé sur un modèle (pas assez de répétition)

Si votre code est répétitif, alors soit vous avez choisi un mauvais langage de programmation, soit vous l'utilisez mal. Avec de meilleures langues, il n'est pas nécessaire de répéter. Considérez la bibliothèque Ruby Active Record. Les tables de base de données sont créées en écrivant des migrations. Il n'est pas nécessaire de répéter la définition du schéma à tout autre endroit. Vous n'avez pas besoin de définir une classe avec des membres de données correspondant aux colonnes de la table. Une seule ligne de code connecte une classe à une table.

Je considère le développement piloté par les modèles comme une solution de contournement complexe et inefficace pour les langages de programmation faibles.