Devez-vous créer des diagrammes de classes avant ou après l'implémentation?

La façon dont je le vois si vous en créez un avant d'obtenir l'avantage de:

• Planifier à l'avance
• Aperçu du projet

mais vous perdez:

• Temps (en faisant du travail, vous finirez probablement par répéter lors de l'écriture de code)

D'un autre côté, je pourrais simplement les créer tous après avoir écrit mon code juste pour le garder comme référence pour les futurs développeurs.

Lequel sert le but des diagrammes de classes et lequel est le plus avantageux?

Si vous les créez avant, ils feront partie de la phase de conception.

Si vous les créez après, vous pouvez simplement les utiliser pour la documentation. Mais la documentation est meilleure et plus rapide si vous le faites lors de la conception et du codage.

Soit dit en passant, vous ne perdez pas de temps à faire du design! La partie codage sera plus rapide. Et mieux.

Après tout, vous pensez que la conception d'un gratte-ciel ou d'un pont est une perte de temps au lieu de simplement commencer à le construire?

Un compromis est de commencer à créer du code factice pendant la phase de conception (juste des prototypes de classes / fonctions) et d'utiliser ce squelette de code pour construire les diagrammes de classes.

Lorsque je les ai créés avant de les coder, nous les considérons comme des documents "temporaires". Autrement dit, nous créons les diagrammes et mettons nos réflexions sur papier. Nous commençons à coder à partir de ces diagrammes de classes. Nous les jetons ensuite. Cela ne vaut pas la peine de passer du temps à les maintenir une fois que le codage a commencé. Et si vous voulez des modèles de classe à jour, utilisez un outil pour les créer à partir du code.

Dans les deux cas, ils resteront dans la documentation. Personne ne les mettra à jour lorsque des modifications seront apportées à l'implémentation. Les diagrammes n'auront pas de date dessus, vous ne saurez même pas à quelle version du code ils se réfèrent. Lorsqu'une nouvelle personne est ajoutée au projet, vous lui donnerez les diagrammes indiquant "Voici quelques diagrammes qui ont été créés à un moment donné pendant la conception ou la mise en œuvre. Nous ne savons pas à quel point ils sont à jour."

Cela fait partie de la conception et doit donc être créé avant la mise en œuvre. Cela ne veut pas dire qu'ils ne peuvent pas être affinés pendant / après la mise en œuvre pour refléter l'état actuel des mises en œuvre.

Fournir une conception après la mise en œuvre est ce que j'appellerais du «codage cowboy», et bien sûr, vous pouvez prospérer dans le Far West sauvage, mais souvenez-vous que les cowboys finissent généralement morts à un moment ou à un autre.

Cela dépend de la profondeur de la conception. Certaines personnes insistent pour écrire des diagrammes de classes, même pour les classes les plus triviales, car «c'est une bonne pratique». Je pense que c'est une perte de temps de dessiner quelque chose alors que vous savez déjà exactement comment cela va être mis en œuvre. Lorsque vous créez un nouveau design, quelque chose qui ne vous est pas familier, il est certainement utile de dessiner d'abord des diagrammes.

Cependant, je n'utilise jamais d'outils UML, car la conception change généralement tellement au cours de la mise en œuvre que je dois redessiner le diagramme. Je suppose qu'un bon outil bidirectionnel gérerait ces changements, mais je n'en ai jamais utilisé un bon (je n'en ai utilisé que des gratuits, cependant). Au lieu de cela, je dessine sur du papier ou sur un tableau blanc pour m'aider à trier le dessin. Après l'avoir implémenté et être raisonnablement sûr qu'il est sain, je ferai un diagramme plus formel.

N'oublions pas non plus les autres types de diagrammes. J'ai toujours trouvé que les diagrammes de séquence étaient parmi les plus utiles, et je les utilise souvent lorsqu'il y a beaucoup de communication entre les composants.

Avant la mise en œuvre. Comme un de mes anciens collègues l'a dit un jour: «J'aime faire autant de programmation que possible avant de commencer à coder», et je pense que c'est une bonne approche.

Je trouve que le fait de dessiner un diagramme me prévient généralement des informations manquantes. Cela se produira également si je tape simplement dans un éditeur de code sans avoir dessiné le diagramme, mais les instances seront plus espacées (car je passerai du temps à écrire des algorithmes, des calculs et des tests, etc.) et donc je pourrais accorder plus de temps à passer avant d'obtenir mes informations manquantes.

De plus, si la conception que vous avez vaguement dans votre tête se révèle être de la merde, vous le remarquerez plus rapidement si vous la schématisez d'abord. Par conséquent, je dessine au moins quelque chose de rapide et informel. Qu'il se transforme en diagramme électronique que d'autres peuvent utiliser comme référence dépendra du projet.

La création du diagramme de classes doit être effectuée, pendant et après, car le modèle doit être interactif avec le code et les modifications des exigences. Vous devez d'abord créer un diagramme de classes pour démarrer votre projet. Cela aiderait à visualiser à un niveau d'abstraction plus élevé vos objets. Vous pourrez créer une architecture logicielle stable et intelligente. Ensuite, vous devez coder et parfois vous remarquerez que l'architecture qui semble bien en UML n'est pas vraiment possible dans le code. Vous changez ensuite votre code et votre architecture. Enfin, vous mettez à jour votre modèle avec la modification du code et générez de la documentation.

Dans mon dernier projet, les décideurs ont changé mes exigences plus de 50 fois au cours de la dernière année. C'est vraiment douloureux et UML m'aide à garder la traçabilité des changements et pourquoi. UML devrait permettre la fusion du modèle et du code à tout moment de manière itérative (par exemple, du code au modèle, du modèle au code, des deux, du code après refactorisation, etc.) J'utilise Omondo EclipseUML pour Helios et je suis vraiment satisfait de cet outil. Ma fonctionnalité préférée est la fusion de modèles qui me permet de mettre à jour mon modèle à tout moment sans perdre d'informations sur le modèle. J'aime aussi la modélisation d'entités directement dans le diagramme de classes et créer la base de données en utilisant le stéréotype et l'hibernation. Vraiment puissant et complet de l'objet à la base de données !!

Avant : cela vous aidera à organiser vos pensées et à communiquer votre intention. N'entrez pas dans les détails ici.

Après : il est automatiquement généré à partir du code dans le cadre du processus de construction, évidemment (j'espère que vous n'êtes pas trop attaché à uml)

Les deux sont utiles, mais ce qui précède peut être jeté dès qu'il est implémenté ... il est déjà dépassé de toute façon à ce stade.

Avec Topcased , je crée mes diagrammes de classes pendant la phase de conception. Je clique ensuite sur le bouton "Générer du code" pour produire un canevas de mon implémentation. Ensuite, je remplis les espaces réservés avec du code.

Je vais voter pour la réponse (C) Ne vous embêtez pas.

Ils sont largement inutiles. Personnellement, je n'ai jamais pris la peine de les regarder lorsqu'ils sont fournis.

Ils sont inutiles avant le développement, car la conception changera de toute façon. Et si vous ne pensez pas que la conception de vos cours changera, vous vous menotez déjà et vous empêchez votre futur moi de résoudre correctement le problème. Si vous pensez que vous devez vous en tenir à certains diagrammes de classe préexistants, alors vous travaillez pour la NASA ou vous vous tirez une balle dans le pied.

Ensuite, ce sont des documents inutiles. Si vous ne pouvez pas comprendre ce que font les classes ou comment elles sont liées les unes aux autres avec une petite inspection de code, alors vous avez un trou dans votre ensemble de compétences en tant que développeur de logiciels.

Bien sûr, cette réponse semble vraiment arrogante et opiniâtre; tant pis.

Avec Eiffel et les outils associés, ce n'est qu'une différence de point de vue pointant tous vers les mêmes fichiers sous-jacents.