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


19

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.


21
Je crois vraiment en aucune méthodologie de programmation ou de développement. Presque tous sont utiles pour quelque chose; aucun n'est le meilleur pour tout. Je ne crois pas qu'une question "vrai croyant" soit constructive selon les normes de P.SE.
David Thornley

4
@David Thornley: Merci pour le commentaire mais je ne sais pas si le "vrai croyant" a quelque chose à voir avec le fait d'être constructif ou non. Je suis très content des réponses et cela a beaucoup aidé. De mon point de vue, c'était très constructif. Je crois aussi que beaucoup de réponses ont beaucoup de valeur pour beaucoup de gens intéressés par le MDD.
KeesDijk

1
@David Thornley merci pour le commentaire lors du vote négatif! J'apprécie vraiment quand les gens font des commentaires sur le moment de leur vote négatif.
KeesDijk

Comme le dit Martin Fowler ( martinfowler.com/bliki/ModelDrivenSoftwareDevelopment.html ): pas assez de support d'outillage ( martinfowler.com/bliki/ProjectionalEditing.html ).
minghua

Réponses:


54

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.


14
Fred Brooks l'a appelé «No Silver Bullet», mais l'essence de votre argument et son argument sont identiques: cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html
Adam Crossland

5
KeesDijk: IMO, la gestion de la répétition est le cœur même de la programmation elle-même. La plupart des éléments de structure dans les langages de programmation, des boucles, de la récursivité, des fonctions aux concepts OO, etc. sont faits pour gérer un type ou un autre de répétition.
user281377

3
Fred Brooks a des papiers des années 50 et 60 qui n'ont pas encore été démystifiés. Consultez le livre "Mythical Man Month" (qui comprend également l'essai "No Silver Bullet".
Berin Loritsch

4
1987? Heck, Fred Brooks a publié un livre en 1975 qui n'a rien perdu de son importance ou de sa précision ( en.wikipedia.org/wiki/The_Mythical_Man-Month ). Non, je ne pense pas que les principes de No Silver Bullet soient moins vrais aujourd'hui qu'auparavant. Comme @ammoQ l'a si succinctement dit: il y a une certaine complexité inhérente au développement de logiciels ... "Maintenant, vous pouvez essayer différentes approches et techniques, cadres, méthodologies, mais pour la plupart, ils essaient juste de pousser toute la complexité dans un seau en particulier. Il ne disparaît pas.
Adam Crossland

4
@KeesDijk: L'idée derrière "No Silver Bullet" ne sera pas obsolète de si tôt. Brooks divise les difficultés de programmation en l'essentiel et l'accidentel, en utilisant des termes de philosophie. Sa prémisse est qu'il y a beaucoup de difficultés essentielles dans la programmation, et toutes les nouvelles méthodes peuvent vraiment faire est d'éliminer les difficultés accidentelles. Dans cet essai, il dit que le développement le plus spectaculaire a été le logiciel sous film rétractable, qui, par rapport aux logiciels personnalisés ou personnalisés, représente beaucoup de programmation qui n'a tout simplement pas à être fait.
David Thornley

16

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.

Merci ! Grande liste! Je dois convenir que ces éléments doivent être pris en considération et si vous vous trompez, le coût de l'échec est en effet très élevé. Une question: votre expérience est-elle plus avec les outils de cas UML de plus d'outils DSL comme MetaEdit?
KeesDijk

@KeesDijk - UML, c'est sûr! Particulièrement Rational Rose, mais aussi un peu de Rational SW Architect.
bethlakshmi

12

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 ".


3
Brooks faisait valoir que quoi, il y a 30 ans?
Paul Nathan

Merci pour cette réponse bien posée. Votre dernier paragraphe résume assez bien mes sentiments également. Et lorsque vous avez identifié que «la programmation de niveau supérieur» peut vous aider, vous devez prendre en considération de nombreuses autres bonnes réponses à cette question.
KeesDijk

10

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.


Merci! La modélisation! = La programmation mérite une question à elle seule. Je connais beaucoup de gens qui ne sont pas d'accord. Les meilleurs résultats avec TDD et le modèle qui décrit une fonction pour moi signifie que le modèle utilisé n'est pas au bon niveau d'abstraction. Si vous écrivez le modèle au niveau du code, tous les avantages sont perdus. Les coûts ne sont plus et ne posent plus de problème, vous pouvez modéliser gratuitement dans eclipse, les outils MS dsl sont gratuits, il existe des outils UML gratuits et EA n'est pas si cher. Les détails entrent toujours dans le code, vous les mettez dans un cadre qu'un modèle peut utiliser, la deuxième fois que vous générez, vous en avez les avantages.
KeesDijk

Je pense que pour tout le monde que vous pouvez trouver qui est d'accord avec vous, je peux au moins trouver un match qui soit d'accord avec moi sur la programmation! = Modélisation. La programmation concerne l'abstraction et la modélisation peut aider à l'abstraction, mais ce n'est pas toujours le bon outil pour le travail à accomplir.
Berin Loritsch

D'accord !
KeesDijk

7

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)


D'accord, je dois être d'accord. Bien que Microsoft essaie un peu avec le SDK Visualisation et modélisation Visual Studio, archive.msdn.microsoft.com/vsvmsdk ne pousse pas.
KeesDijk

7

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.


En ce qui concerne DDD: je dois admettre que j'aime vraiment les DSEL. Je suis (de loin) le développement de Barrelfish OS ( barrelfish.org ) et ils ont créé Filet-o-Fish, qui est un outil pour créer des DSL, puis travaillent à un niveau d'abstraction plus élevé directement dans le code.
Matthieu M.

6
  • 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.


+1 pour "Semble comme un tracas gigantesque pour très peu d'avantages."
rreeverb

5

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.


Merci! Je pense que le refactoring est en cours d'élaboration dans plusieurs domaines et MetaEdit peut déboguer le modèle graphique, mais oui, je n'ai pas vu beaucoup de bonnes choses dans ce domaine.
KeesDijk

3

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.


2

À 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?


Merci ! J'ai assisté à CodeGeneration à Cambridge ( codegeneration.net/cg2010 ) et l'accord général était que le monde embarqué est particulièrement adapté au MDD. Aux Pays-Bas, Thales ( thalesgroup.com ) fait également de grands progrès en utilisant MDD dans les systèmes radar. Le fonctionnement général des systèmes est modélisé, les blocs de construction individuels sont codés à la main pour chaque nouvelle pièce de matériel. Cela rend le remplacement du matériel beaucoup plus rapide.
KeesDijk

Le modèle ne doit rien savoir des modèles de conception. Vous avez une architecture logicielle de référence logicielle qui a des modèles. Les générateurs interprètent le modèle et génèrent selon l'architecture logicielle de référence. Lorsqu'un nouveau modèle doit être utilisé, l'architecture et les générateurs sont modifiés.
KeesDijk

@KeesDijk: Lorsque vous déclarez que le monde embarqué est particulièrement adapté au MDD, faites-vous référence aux applications de téléphonie cellulaire ou au µController SW que l'on trouve dans les voitures et les appareils électroménagers.
oosterwal

Moniteurs de fréquence cardiaque, systèmes radar, matériel d'imprimante. Mais regardez le lien metaedit et voyez ce qu'ils ont fait. J'ai seulement entendu parler de µController SW trouvé dans les voitures et que c'est vraiment complexe, je n'ai jamais entendu parler de MDD là-bas, mais que je n'en ai pas entendu parler n'est pas une bonne mesure :)
KeesDijk

Il y a quelque temps, un type de Matlab / Simulink a essayé de nous vendre le générateur de code. Visait carrément les contrôleurs intégrés. N'a pas fait MISRA-C et n'était pas certifié, donc un peu triste, cela a peut-être changé. Jetez un oeil, il générait C.
Tim Williscroft

2

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.


2

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.


Merci pour votre contribution. Je dois accepter et ne vois pas de solution dans un avenir proche.
KeesDijk

2

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 :-)


1

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.


1

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.


1

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.


0

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.


1
Je pense que nous parlons de différents types de répétition. Vous parlez de répétition au sein d'un même logiciel, je parle de la construction de plusieurs logiciels similaires qui partagent par exemple la même architecture logicielle mais exposent une fonctionnalité différente. La fonctionnalité est modélisée et l'architecture est générée. Merci d'avoir répondu.
KeesDijk

@Kees: qu'entendez-vous par «architecture»? Si c'est du code, je pourrais factoriser la répétition, et simplement instancier l'architecture, en spécifiant les choses qui sont propres à chaque instanciation. Avec une bonne langue, TOUTES les répétitions peuvent être éliminées.
Kevin Cline du

Il n'y a pas de bons ou de mauvais langages de programmation, seuls de bons ou de mauvais développeurs, de tels exemples que vous donnez peuvent être faits avec n'importe quel framework web. Qu'est-ce que MDA / MDD / etc. essaye de résoudre est de maintenir un modèle afin que la génération de plusieurs composants puisse être effectuée automatiquement comme la base de données, les contrôleurs, les vues, les services, etc. pourrait être exporté vers Rails, Spring, Zend, etc.
Cenobyte321
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.