Je n'aime pas la MDD mais j'aime UML - pourquoi devrais-je utiliser la MDD si je pense qu'elle est inutile ?

Question

Je suis développeur/architecte de logiciels Java et j'aime UML.

Cela dit, je déteste aussi le code généré par Java.

Je ne vois pas l'intérêt d'essayer de générer le squelette de mon application :

• créer des classes vides est très facile et je n'ai pas besoin d'un outil pour le faire
• Je ne peux pas non plus réutiliser le code généré parce que la façon dont il est généré le rend impossible à réutiliser.

Le dilemme pour moi est que mes exigences ont changé si rapidement que je dois être en mesure de mettre en œuvre la nouvelle demande immédiatement dans un code existant.

Mon problème est que si je génère mon code à partir de mon modèle et que je développe ensuite manuellement dans la base de code générée, je ne peux pas générer à nouveau du code en utilisant un modèle car mes modifications seraient effacées.

Sauf que je copie/colle les modifications dans les deux sens. C'est un effort énorme pour trop peu de résultats. C'est pourquoi je n'utilise pas la MDD, mais j'utilise encore beaucoup UML.

La méthode UML peut-elle être utilisée avec succès dans le cadre d'un projet sans génération de code MDD ?

Je pose cette question parce que j'ai un nouveau patron qui veut introduire un processus MDD complet avec IBM RSA et aujourd'hui je préfère avoir une synchronisation ou une fusion en direct du code et du modèle avec Omondo.

• Pourquoi changer un système qui fonctionne et qui a fait ses preuves ?
• Pourquoi générer systématiquement du code à partir d'un modèle alors que je peux le faire directement dans le code et le fusionner plus tard avec le modèle ?
• Pourquoi générer un code de base de données merdique qui ne peut même pas être déployé alors que je peux ajouter un stéréotype afin d'obtenir des annotations Java et les utiliser avec Hibernate pour générer ma base de données ?

L'une des raisons du changement de patron est d'obtenir une meilleure documentation de projet au format HTML. J'en doute fortement et je pense qu'il cherche à mieux contrôler la livraison et qu'il ne sait pas quoi inventer d'autre !

Autres raisons argumentées :

• Utilisez un produit provenant d'une entreprise importante et stable.
• Disposer d'un modèle complet qui pourrait être déployé dans n'importe quelle autre langue.
  (C'est pourquoi, pour moi, MDD est stupide car il est impossible de déployer sur n'importe quelle plateforme, n'importe quel serveur, n'importe quelle base de données juste à partir d'un modèle. Alors pourquoi perdre mon temps ?)

Merci de me donner des arguments pour revenir à la prochaine réunion et écraser ce stupide nouveau fan de DDM qui veut réorganiser la façon dont nous travaillons aujourd'hui !

Answer 1

Je pense que votre message contient la réponse.

La DDM est confrontée à deux problèmes fondamentaux :

1. Une entrée (langage de modélisation) qui n'est pas suffisamment expressive pour rendre compte de l'ensemble du problème. Résultat : vous devez compléter la spécification avec un autre langage (code).
2. Les générateurs - c'est-à-dire les règles qui convertissent les modèles en code - sont généralement incomplets et/ou ne peuvent pas être modifiés par l'équipe de développement et/ou génèrent un code de mauvaise qualité.

Mettez ces deux choses ensemble et vous obtiendrez l'horrible gâchis que vous mentionnez. Conséquence : on essaie d'assembler du code écrit à la main avec du code généré de mauvaise qualité. Résultat : ce n'est pas beau à voir.

Cependant. N'en déduisez pas que je suis anti-MDD. Ce n'est pas le cas, bien au contraire. MAIS : l'outillage et le processus doivent répondre aux deux questions fondamentales susmentionnées.

J'en ai rencontré très peu qui le font. J'ai utilisé RSA il y a plusieurs années et ce n'était certainement pas l'un d'entre eux. (Cependant, il a eu le temps de s'améliorer depuis, donc il est possible qu'il en fasse partie maintenant).

Un simple "contrôle de température" consiste à demander si l'outil fournit un langage d'action complet. Si ce n'est pas le cas, le problème (1) se posera. S'il n'y parvient pas, il y a de fortes chances qu'il vous fasse souffrir.

Si tout ce que veut votre patron, c'est une bonne documentation HTML, intégrez simplement UMLGraph ou apiviz dans votre construction.

Pour répondre à votre question spécifique :

UML peut-il être utilisé avec succès sans MDD ? Oui. Généralement de deux manières :

1. En tant que notation informelle ou semi-formelle pour les croquis sur tableau blanc lors de l'élaboration du problème et/ou de la solution (ce que Martin Fowler appelle UML en tant qu'esquisse )
2. En tant que documentation générée automatiquement à partir du code dans le cadre du processus de construction.

La création de diagrammes UML formels (souvent à l'aide d'un outil coûteux) qui n'ont pas de lien direct avec le code vous fera perdre du temps.

hth.

Answer 2

Si vous ne pouvez pas contrôler la génération, vous n'utilisez probablement pas les bons outils.

Ce que vous générez - squelettes ou code spécifique au cadre - dépend également de l'outil. Utilisez des outils qui vous permettent de créer vos propres modèles.

Il est faux de penser que l'ingénierie des allers-retours ne fonctionnera jamais. Il n'est pas possible de transformer un modèle moins détaillé en un code plus détaillé et vice-versa sans perdre des informations. Une façon de résoudre ce problème serait d'avoir le même niveau de détail dans les modèles que dans le code, ce qui n'est pas une bonne chose.

La meilleure approche consiste à utiliser une génération à sens unique à partir de modèles, combinée à quelques bonnes pratiques pour combiner le code généré et le code écrit manuellement.

Vous pouvez utiliser des régions protégées pour le code écrit manuellement :

• que vous spécifiez dans les modèles - par exemple, les corps des méthodes, qui ne doivent pas être écrasés lors de la régénération.

Ou le modèle du fossé entre les générations :

• vous générez des classes abstraites et du code à l'aide de squelettes de classes concrètes, que vous complétez manuellement).

Il existe encore une autre façon d'aborder cette question : la génération de code complet.

Cela peut ressembler à la mauvaise pratique qui consiste à coder à l'aide de modèles, mais il s'agit de se spécialiser dans la création de certains types d'applications - applications web, applications intégrées. Ce que vous générez est alors essentiellement un code spécifique au cadre, qui peut souvent être exprimé et maintenu à l'aide de modèles.

N'oubliez pas que la modélisation ne se limite pas aux diagrammes, vous pouvez également utiliser des DSL textuels.

Pour répondre à votre question, UML n'a pas été conçu à l'origine pour le MDD (de nombreux praticiens du MDD n'utilisent pas du tout UML...), vous pouvez donc l'utiliser pour l'analyse et la conception OO comme vous le souhaitez.

En ce qui concerne votre patron et l'ASR, essayez de découvrir ce dont il a réellement besoin et ce qu'il souhaite, puis essayez de lui fournir de meilleurs outils ou pratiques.

Comme indiqué dans l'autre réponse, il existe de nombreux outils de documentation.

Answer 3

Avec la DDM, il est à espérer que les modifications apportées à la conception deviennent moins coûteuses : si les exigences changent, dans votre approche, vous devez mettre à jour la documentation basée sur l'UML et le code. Or, si le code pouvait être généré automatiquement, les modifications du code devraient découler automatiquement des modifications du modèle, et vous n'auriez pas à le faire manuellement (du moins là où vous n'ajoutez pas de nouveaux éléments ou n'avez pas besoin de modifier la logique commerciale).

En supposant que la MDD fonctionne (oui, c'est vrai ;), pourriez-vous justifier le double coût de maintenance du modèle (pour la documentation et la conception) et du code ?

Un argument en votre faveur pourrait être que si le projet n'est pas trop important (quoi que cela signifie), il ne vaut pas la peine d'avoir tous les frais généraux.