Est-ce que vous faites MDA (Model Driven Architecture) en ce moment? Si oui, quels outils utilisez-vous, et comment est-il ELABORATION?

StackOverflow https://stackoverflow.com/questions/696021

  •  22-08-2019
  •  | 
  •  

Question

Model Driven Architecture est l'idée que vous créez des modèles qui expriment le problème que vous devez résoudre d'une manière qui est libre de tout (ou au moins la plupart) des technologies de mise en œuvre, et vous créez la mise en œuvre d'une ou de plates-formes plus spécifiques. La demande est que le travail à un niveau supérieur d'abstraction est beaucoup plus puissant et productif. En outre, vos modèles vivent plus longtemps que les technologies (donc vous avez encore quelque chose quand votre première langue / plate-forme devient obsolète que vous pouvez utiliser pour votre solution de nouvelle génération). Un autre avantage clé revendiqué est qu'une grande partie du passe-partout et « travail de base » peut être généré. Une fois que l'ordinateur comprend la sémantique de votre situation, il peut vous aider plus.

Certains soutiennent cette approche est 10 fois plus productive, et qu'il est la façon nous serons tous la construction de logiciels en 10 ans.

Cependant, tout cela est la théorie juste. Je me demande quels sont les résultats lorsque le caoutchouc rencontre la route. En outre, la version « officielle » de MDA est de la OMG , et semble très lourd. Il est fortement basée sur UML, ce qui pourrait être considéré comme bon ou mauvais en fonction de qui vous demandez (je penche vers « mauvais »).

Mais, malgré ces préoccupations, il est difficile d'argumenter avec l'idée de travailler à un niveau supérieur d'abstraction et « enseignement » l'ordinateur à comprendre la sémantique de votre problème et la solution. Imaginez une série de modèles ER qui expriment simplement la vérité, et imaginer l'utilisation de ces pour générer une partie importante de votre solution, d'abord dans un ensemble de technologies, puis de nouveau dans un autre ensemble de technologies.

J'aimerais entendre des gens qui font vraiment MDA en ce moment ( « officiel » ou non). Quels outils utilisez-vous? Comment est-il ELABORATION? Combien de la promesse théorique avez-vous été en mesure de capturer? Voyez-vous une véritable augmentation de l'efficacité 10X?

Était-ce utile?

La solution

Je l'ai essayé une fois. À peu près à mi-chemin du projet, j'ai réalisé que mes modèles étaient désespérément à jour de mon code et étaient si complexes que les garder à jour était prohibitif et me ralentir.

Le problème est que le logiciel est plein de cas de pointe. Les modèles sont parfaits pour capturer l'image plus grande, mais une fois que vous commencez à coder réellement la mise en œuvre vous continuez à trouver tous les cas de pointe et avant trop longtemps, vous remarquerez que le modèle est beaucoup trop granulaire et vous devez faire un choix entre le maintien du modèle ou d'obtenir un code écrit. Peut-être que la génération passe-partout est un avantage pour le démarrage, mais après que les bénéfices disparaissent rapidement et je trouve que je suis une baisse drastique de la productivité. Les modèles ont fini par disparaître de ce projet.

Autres conseils

L'absence de réponse à cette question est un peu inquiétant ... Je vais peut-être laisser champ de Dijkstra il.

  

... Parce que les ordinateurs sont apparus dans une décennie   quand la foi dans le progrès et   comestibilité de la science et   la technologie était pratiquement illimitée, il   peut-être bon de rappeler que, compte tenu   de ses objectifs initiaux, l'humanité de   efforts scientifiques sur, disons, la   cinq derniers siècles ont été   échec spectaculaire.

     

Comme vous souvenez, la première et   objectif premier était le développement   de l'Elixir qui donnerait une   qui bue la jeunesse éternelle. Mais depuis   il n'y a pas beaucoup d'intérêt éternel   la pauvreté, le monde de la science rapidement   lancé dans son deuxième projet, à savoir.   la pierre que de la philosophe   vous permettre de faire autant d'or que vous   nécessaire.

     

...

     

La recherche de la programmation idéale   la langue et l'homme-machine idéale   interface qui rendrait le logiciel   crise fondre comme neige au soleil avait   -et a encore - tous les   caractéristiques de la recherche de la   Elixir et la pierre. cette recherche   reçoit un fort soutien de deux   côtés, d'une part du fait que la   travail des miracles est le moins   que vous pouvez attendre d'ordinateurs,   et d'autre part de la crise financière et   soutien politique d'une société qui   avait toujours demandé l'Elixir et   la pierre en premier lieu.

     

Deux grands cours d'eau peuvent être   distingué, la recherche de la pierre   et la quête de l'Elixir.

     

La quête de la pierre est basée sur   l'hypothèse que notre « programmation   outils » sont trop faibles est un exemple.   la croyance que la programmation actuelle   langues ne possèdent pas les « caractéristiques » dont nous avons besoin.   PL / I était l'un des plus spectaculaires   serait-être des pierres produites. Je reste   rappelez-vous la publicité en   Datamation, 1968, dans lequel un sourire   Susie Mayer annonce en couleur   qu'elle a résolu son tout   programmation des problèmes en passant à   PL / I. Il était trop prévisible   que, quelques années plus tard, pauvre Susie   Mayer souriait plus. Inutile   à-dire la recherche a continué et en temps   un temps prochain serait-être la pierre était   produite sous la forme d'Ada (derrière   le rideau de fer perceptivement appelé   comme PL / II). Même les plus élémentaires   l'astrologie pour les débutants suffit à   prédire que Ada ne sera pas la dernière   pierre de ce type.

     

...

     

Une autre série de pierres sous la forme   des « outils de programmation » est produit   sous la bannière de « logiciel   ingénierie », qui, au fil du temps,   a cherché à remplacer intellectuelle   discipline par discipline de gestion à   dans la mesure où il a maintenant accepté comme   sa charte « Comment programmer si vous   ne peut pas. "

Je suis en train de faire ma propre recherche indépendante dans le domaine de développement de logiciels dirigée par les modèles depuis 1999. Je l'ai finalement mis au point une méthodologie de modélisation générique en 2006 que j'étiquetée ABSE (Atom-Based Software Engineering).

Alors, ABSE construit sur deux aspects fondamentaux:

  • La programmation est la décomposition du problème
  • Tout peut être représenté sur un arbre

Certains ABSE caractéristiques:

  • Il peut prendre en charge toutes les autres formes d'ingénierie logicielle, de la traditionnelle des méthodes orientées sur des fichiers jusqu'à base de composants de développement, programmation orientée aspect, modélisation spécifique de domaine, logiciels et lignes de produits Software Factories.

  • Il est suffisamment générique pour être appliqué aux logiciels d'entreprise, embarqués, jeux, avionique, Internet, tout domaine en fait.

  • Vous n'avez pas besoin d'être un génie pour utiliser si efficacement. ABSE est accessible à la « simple mortel de développeur ». Il n'y a pas de complexité comme celle qui se trouve dans ÖAW / MDA / XMI / FMV / etc chaînes d'outils.

  • Sa méta-méta-modèle est conçu pour supporter la génération de code 100% par rapport au modèle. Non-retour nécessaire. Le mélange personnalisé / code généré est directement pris en charge par le métamodèle.

  • Le modèle peut être manipulé en même temps. Et le contrôle de flux de travaux version peut être appliquée (support d'outil nécessaire).

Il peut sembler comme il est sur le côté utopique, mais en fait je quitte la phase de recherche et je suis maintenant dans la phase de mise en œuvre d'un IDE qui met tout ce qui précède dans la pratique. Je pense que je vais avoir un prototype de base prêt dans quelques semaines (vers la fin d'Avril). L'IDE (nommé AtomWeaver) est en cours de construction par ABSE, donc AtomWeaver sera la première preuve de concept de la méthodologie ABSE.

Alors, ce n'est pas MDA (heureusement!), Mais au moins est une approche très facile à gérer. Comme l'inventeur de ABSE, je suis naturellement excité à ce sujet, mais je suis sûr que le développement du logiciel Model-Driven un coup de pouce en 2009!

Restez à l'écoute ...

Je commencé à travailler avec des technologies à base de modèles et DSLs en 1997, et je suis de plus en plus enthousiastes à l'idée MDE.

Je peux témoigner que, pour atteindre plus de 10 fois la productivité (et peut-être encore plus ;-) est possible dans certaines circonstances. Je l'ai mis en œuvre de nombreuses usines de logiciels à base de modèles qui ont été en mesure de générer des logiciels exécutables avec des modèles très simples, de la couche à la couche de persistance de l'interface utilisateur, associée à leur documentation technique générée.

Mais je ne suis pas la norme MDA pour plusieurs raisons. La promesse MDA est d'exprimer votre logiciel dans un modèle de PIM, et ont la capacité de transformer automatiquement en une ou plusieurs piles techniques (PSM).

  • qui a besoin de cibler plusieurs piles techniques dans la vie réelle? qui a besoin de cibler une seule architecture et bien définie?
  • la magie de MDA se trouve dans le PIM-> PSM transformation, mais la transformation model2model de manière itérative et incrémentale est difficile:
    • model2model est beaucoup plus compliqué que model2text à mettre en œuvre, debug, maintenir.
    • car il est rarement possible de générer 100% d'un logiciel, les détails doivent être ajoutés au modèle de PSM résultant, et préservé la transformation après transformation. Cela signifie une opération de fusion (3 voies, de se rappeler les détails ajoutés). Et lorsqu'ils traitent avec des modèles, graphique fusion des objets est beaucoup plus complexe que la fusion textuelle (qui fonctionne assez bien).
    • vous devez faire face à un modèle de PSM (c'est-à-dire un modèle qui semble très proche de votre code source généré final). Il est intéressant pour le fournisseur d'outils, car les profils de PSM prêts à utiliser et générateurs de code associés peuvent être expédiés selled et avec l'outil MDA.

Je préconise des stratégies MDE où le PIM est un DSL qui parle de votre architecture logique (indépendamment de toute pile technique), et générer le code de ce PIM avec une commande et un générateur de code spécifique.

Avantages:

  • vous ne pas faire face à un modèle de PSM complexe et technique. Vous avez votre code à la place.
  • en utilisant des techniques DSL, le PIM est plus efficace, durable, expressive et facile à interpréter par des générateurs de code et de documents. Les modèles doivent être simples et précis.
  • il fait l'obligation de définir vos exigences architecturales et des concepts très tôt (car il est votre PIM métamodèle), indépendamment de toute pile technique. En règle générale, il est sur l'identification des différents types de données, le service, les composants ui, avec leur définition, les capacités et les caractéristiques (attributs, liens vers d'autres concepts, ...).
  • le code généré correspondent à vos besoins, car il est personnalisé. Et vous pouvez le garder encore plus simple si votre code généré étend certaines classes supplémentaires cadres maintenus manuellement.
  • vous capitalisez la connaissance de plusieurs façons orthogonales:
    • modèles capitalisent les fonctionnalités / entreprise
    • générateurs de code capitalisent les décisions de cartographie technique de vos composants architecturaux logiques à une pile technique particulière.
    • DSL PIM capitalise une définition de votre architecture logique
  • avec le PIM orienté-architecture logique, il est possible de générer tout le code technique et d'autres fichiers non-code (configs, propriétés, ...). Les développeurs peuvent se concentrer sur la mise en œuvre des fonctionnalités d'entreprise qui ne pouvait pas être pleinement exprimé avec le modèle, et généralement ne pas faire face à la pile technique plus.
  • fusionne les opérations sont sur les fichiers de code source plat, et cela fonctionne assez bien.
  • vous pouvez toujours définir plusieurs générateurs de code si vous ciblez plusieurs piles techniques.

Inconvénients:

  • vous devez mettre en œuvre et maintenir votre propre code spécifique et générateurs de documents
  • d'une manière générale, pour tirer le meilleur de l'approche DSL, vous devez enacquises dans un outillage spécifique (validation des modèles, des assistants spécifiques, les dialogues, menus, import / export ...).
  • lors de la mise à jour / améliorer votre DSL, vous devez parfois faire migrer vos modèles. Habituellement, cela peut être fait avec un code de migration à usage unique, ou manuellement (en fonction de l'impact).
  • tous ces inconvénients ont besoin d'une équipe de développement spécifique des compétences à base de modèles

Cette approche particulière peut être mise en œuvre sur le dessus d'un modeleur UML extensible avec des profils UML ou avec des éditeurs de modèles spécifiques (textuelles ou graphiques).

La grande différence entre MDA et MDE pourrait se résumer comme:

  • MDA est un ensemble d'outils à usage général et langues, fournissant impromptu profils et de l'outillage pour md tout le monde a besoin. C'est parfait pour les fournisseurs d'outils, mais je suppose que tout le monde a besoin et les contextes sont différents.
  • Avec MDE + DSL spécifique et de l'outillage, vous avez besoin des développeurs axée sur des modèles qualifiés supplémentaires qui permettront de maintenir votre usine de logiciels personnalisés (modeleur, extensions modeleur, générateurs ...), mais vous capitalisez partout et gérer très simple precise- modèles durables.

Il y a une sorte de conflit d'intérêts entre les deux approches. On préconise de réutiliser impromptu composants orienté modèle-precapitalized, et dans l'autre, vous faites votre propre capitalisation avec la définition et de l'outillage associé DSLs.

Nous utilisons MDA et EMF comme des outils. Il nous permet d'économiser beaucoup d'heures de travail par la génération de code au lieu de codage manuel. Il nécessite une haute qualification de l'analyse, mais il est ce qu'il en est. Nous avons donc principalement concentré sur les problèmes elle-même et aussi des outils / cadres qui font la génération de code et d'exécution support du code généré. Enfin, je peux confirmer que nous avons 10x augmentation de la productivité avec MDA.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top