Qu'est-ce que le génie logiciel piloté par les modèles (MDSE)?

Je suis tombé sur l'accronym MDSE aujourd'hui sur infoq , et les informations que j'ai pu trouver ce qui n'était pas clair et la description était pleine de mots à la mode:

MDSE vise à permettre aux ingénieurs logiciels de travailler à un niveau d'abstraction où les exigences, l'architecture et les informations de conception sont ordonnées au maximum (en termes d'information "entropie") et préservées. (Appelez cela le "produit de travail de conception"). En outre, MDSE devrait fournir aux ingénieurs les moyens de vérifier et de valider leurs conceptions, principalement les termes de leur «produit de travail de conception»

Et apparemment, tout le monde le fait: (de l'article à nouveau)

Nous sommes à l'aube de l'ère du MDSE. Au cours des 5 à 10 prochaines années, nous assisterons à un virage significatif vers le MDSE, dans la mesure où je pense qu'à la fin de cette période, 60 à 80% des logiciels seront conçus à l'aide de techniques basées sur des modèles.

J'aimerais avoir une description concrète et sans mots à la mode de ce qu'est MDSE. Dessine-t-il des boîtes UML et génère-t-il du code, comme ils l'ont fait dans les années 90 avec Rational Rose?

(pendant que j'y étais, si quelqu'un a un exemple de logiciel généré à l'aide de ces techniques, j'aimerais vraiment voir un exemple concret).

«l'ingénierie logicielle pilotée par les modèles (MDSE)» est la promesse marketing des fabricants d'outils logiciels selon laquelle «bientôt» des parties significatives de logiciels peuvent être générées à partir de modèles logiciels.

Le partenaire interview dans l' article auquel vous faites référence , Robert Howe est un fabricant d'outils (voir http://www.verum.com/ pour plus de détails)

Mais contre les promesses du fabricant d'outils, mdse n'est pas encore devenu courant.

Le système de boutique en ligne hybris est un exemple pratique de "MDSE": en tant que développeur de logiciels, vous gérez des fichiers de modèle xml ("* -items.xml") et des générateurs de code / interprètes génèrent db-modell / java-code pour persistence / guis en dehors de ça. Si vous avez besoin d'un attribut supplémentaire, ajoutez-le simplement au modèle xml et une fois que le générateur / interprète a fait son travail, vous pouvez utiliser l'attribut pour implémenter la logique métier.

IMHO "model driven " est une grande exagération, en particulier lorsqu'il est utilisé en conjonction avec des mots à la mode comme "conception" ou "génie logiciel" (au lieu de "développement"). Il a probablement été inventé par certaines personnes ayant l'idée fausse que la "conception de logiciels" se fait en dessinant des modèles principalement graphiques avec UML, comme un architecte dessine un plan pour une maison, et le "codage", c'est comme poser les briques pour la maison, suivant le plan. (J'espère que je n'ai pas à expliquer ici pourquoi cela est faux, si vous avez une opinion différente, veuillez d'abord lire "Code as Design" de Jack Reeves avant de me voter.)

Il s'agit d'un excellent modèle mental pour les personnes se faisant appeler "architectes", "analystes commerciaux", "concepteurs", "ingénieurs logiciels", qui ont étudié cinq ans d'informatique, mais seulement six mois d'expérience réelle en programmation (au maximum ), et maintenant à la recherche d'un emploi dans l'industrie du logiciel qui comprend la "conception de logiciels" sans codage. Je suppose que c'est la vraie raison pour laquelle ces mots à la mode "axés sur le modèle" sont si populaires.

Ne vous méprenez pas, je suis un grand fan de modèles et de générateurs de code pour réduire le besoin d'écrire manuellement du code standard. Dans certains domaines restreints comme, par exemple, les bases de données, les modèles (de données) peuvent en effet être un bon instrument pour communiquer avec les personnes du domaine. L'esquisse du flux de données entre les composants par modèles est à mon humble avis l'une des techniques les plus importantes pour introduire la structure dans un système logiciel (malheureusement, les gens UML ont oublié de refuser d'inclure des diagrammes de flux de données dans leur notation; au lieu de cela, ils ont ajouté un tas de choses redondantes et inutiles que personne n'utilise dans la pratique).

Mais j'appellerais cela " le développement de logiciels pris en charge par les modèles ", et non "l' ingénierie logicielle guidée par les modèles ", ce qui indique, espérons-le, que la modélisation ne prend en charge que les principales activités de développement, au lieu d'être l'activité principale elle-même.

Cela me rappelle beaucoup de modèles Fat, concept de contrôleurs maigres .
L'idée principale de ce concept est de mettre autant de logique métier que possible dans le modèle et de garder le contrôleur et une vue très simplistes.
Personnellement, je trouve cette idée très intéressante, même si je n'ai pas eu l'occasion de l'utiliser.
Étonnamment, 8 des 10 principaux liens de la recherche Google s'y opposent.
Mais, si vous pensez à un modèle non pas comme une seule classe, mais comme une façade de plusieurs classes internes, il est parfaitement logique de conserver la logique métier dans le modèle.