MDD : Dans quelle mesure le MDD est-il dynamique au moment de l'exécution ?

Question

Au fil des ans, j'ai étudié de nombreuses façons d'utiliser les générateurs de code et le MDD. J'ai toujours eu l'impression qu'il manquait quelque chose : Parcheando et les modifications du modèle au moment de l'exécution.

Parcheando : Si vous avez un générateur de code, toutes vos classes devraient se ressembler. Maintenant, vous avez une seule exception. Tous les générateurs de code jusqu'à présent exigeraient que je modifie le modèle ou le moteur de modèle pour que cela fonctionne.

Ne serait-il pas préférable que je puisse appliquer des correctifs au résultat de l'étape de génération du code pour corriger les exceptions ?

Answer 1

Eh bien, cela dépend de la façon dont vous construisez votre modèle. En fait, cela dépend du générateur de code que vous utilisez, de son approche et de ce qu'il vous permet de faire.

La création d'une exception à une règle (modèle) est plus ou moins contraire à la nature de la DDM, à moins que l'approche de modélisation appliquée ne vous permette d'ajouter des exceptions en tant qu'entités de modélisation.

Je pense que ABSE est la seule approche de modélisation qui accepte le "code personnalisé" comme une entité de première classe, tout comme un texte ou un nombre entier. Si vous créez un modèle qui contient un paramètre "CustomCode", vous pouvez ultérieurement ajouter votre code d'exception uniquement lorsque cela est nécessaire, sans enfreindre les règles de votre modèle. Ce paramètre peut être utilisé pour ajouter ou remplacer du code. Il vous suffit de le spécifier dans votre modèle.

AtomWeaver est une implémentation libre de la méthodologie de modélisation ABSE.

Answer 2

Le DDM ne fonctionne pas parce qu'il est basé sur une vue du domaine et non sur l'ensemble du domaine. Je veux dire qu'habituellement les MDD prennent une entrée XMI provenant d'un diagramme UML. Le problème est que ce diagramme n'est qu'une vue du domaine et que, par conséquent, il existe de nombreuses alternatives, alors que le monde réel est beaucoup plus complexe, en particulier au stade du déploiement.

La seule société qui m'a apporté une réelle valeur ajoutée dans mon projet est Omondo avec EclipseUML. EclipseUML n'essaie pas de faire du MDD mais de créer de l'UML au niveau du diagramme en direct synchronisé avec le code. Le déploiement est fait en utilisant des stéréotypes qui sont ajoutés dans l'annotation java dans le code. Je peux donc modéliser et si j'ajoute des stéréotypes de déploiement, alors mon application peut être déployée immédiatement/ Si je modifie manuellement mon code, alors mon modèle est refactorisé et toutes mes vues mises à jour. Si je veux ajouter une documentation, il me suffit d'ajouter des notes dans le métamodèle. Ces notes sont disponibles en direct lorsque je clique sur chaque élément. Plus besoin de documentation imprimée car la navigation en direct, les créations de vues dynamiques etc...

Mon modèle EclipseUML est toujours à jour, et je peux le déployer immédiatement car les annotations Java sont synchronisées en permanence entre le modèle, le métamodèle, les diagrammes et le code. Vraiment cool :-) :-)