Quelle est l'importance des diagrammes UML pour un projet réussi? [fermé]

Je suis au milieu d'un projet et on m'a demandé d'écrire des diagrammes UML (cas d'utilisation, diagramme de classe, etc.). Le projet n'est pas très complexe.

Je me demandais si c'était une perte de temps? Dois-je simplement faire d'autres choses amusantes comme écrire du code? Et quand n'est-il pas acceptable de construire quelque chose sans passer par toute la phase conceptuelle? Est-ce une question de complexité? Et si oui, comment le mesurer?

J'étais un grand fan d'UML il y a quelque temps. Je suis même certifié OMG. Je l'ai largement utilisé dans de grands projets d'entreprise auxquels j'ai participé.

Aujourd'hui, j'ai arrêté UML presque complètement. Parfois, j'utilise le diagramme de séquence que je trouve très utile pour décrire les interactions entre les systèmes, mais pas d'autres diagrammes.

Je préfère maintenant travailler avec des histoires d'utilisateurs, soutenues à la fois par la (seule) documentation nécessaire écrite par le propriétaire du produit (ou les analystes) ET son (leur) dévouement à l'équipe de développement pour donner plus de détails si nécessaire.

UML est un outil que vous pouvez utiliser, mais ce n'est certainement pas un facteur critique pour la réussite de vos projets. Après de nombreuses années, je pense maintenant que le facteur critique est l'équipe de développement, quels que soient les outils qu'elle utilise.

La planification est essentielle, mais comme le célèbre stratège Carl von Clausewitz le met en garde

Aucun plan de campagne ne survit au premier contact avec l'ennemi

Ce n'est donc pas une énorme perte de temps pour planifier la manière d'aborder les problèmes. Mais probablement une perte de temps pour documenter votre code pour les futurs programmeurs. Pour utiliser une métaphore militaire, vous avez besoin d'un plan de bataille, mais vous ne donneriez pas ce plan aux historiens pour l'utiliser comme un rapport après action.

Plus concrètement, vous pouvez utiliser ces diagrammes pour communiquer vos intentions au sein de votre équipe et réfléchir à votre plan d'attaque avant et pendant le projet. Mais les chances sont que ce que vous proposez devra être modifié au fur et à mesure que vous coderez et en apprendrez plus sur le problème. Presque toujours, votre plan / design initial doit être modifié car vous ne pouvez pas tout savoir à l'avance.

Je pense que les diagrammes UML ne peuvent être utiles que s'ils expriment quelque chose à un niveau d'abstraction plus élevé que votre code .

Écrire UML juste pour écrire UML devient une bureaucratie inutile et rend le projet et le code moins adaptables aux changements sans aucun avantage.

Par exemple, un diagramme de classes UML montrant toutes les classes d'un package, avec tous leurs attributs et méthodes - quelque chose qui peut être facilement généré automatiquement - ne fournit aucune valeur: il est au même niveau d'abstraction que votre code . De plus, le code sera très certainement une meilleure source pour ces informations car il sera toujours à jour, et il sera probablement documenté et organisé de manière à ce qu'il soit plus facile de savoir quelles méthodes / attributs / choses sont plus importantes.

D'un autre côté, si vous avez des concepts d'un niveau d'abstraction plus élevé que ce qui peut être exprimé exprimé dans le code, les documenter sur un diagramme peut être une bonne idée.

Par exemple, un diagramme montrant les modules abstraits de niveau supérieur sur un système complexe, avec leurs dépendances et peut-être une petite description de leurs responsabilités et le package / espace de noms auquel ils mappent dans le code source peut être vraiment utile pour un nouveau membre de l'équipe qui doit être introduit dans le projet, ou peut également être utilisé pour déterminer où une nouvelle classe / fonctionnalité doit être lancée.

Un autre exemple de diagramme utile pourrait être un diagramme de séquence montrant les étapes de haut niveau à effectuer dans un protocole de communication. Peut-être que chaque étape a ses petites bizarreries et complexités, mais c'est probablement suffisant pour les décrire dans le code lui-même. Le diagramme de niveau supérieur peut aider un programmeur à comprendre facilement la «vue d'ensemble» des choses sans avoir à se soucier de la complexité de chaque interaction.

Quoi qu'il en soit, ce ne sont que quelques exemples; il existe de nombreux cas où un schéma simple peut être très utile. N'oubliez pas que vous ne devriez les faire que lorsque vous ne pouvez pas exprimer quelque chose dans le code lui-même. Si vous vous retrouvez à utiliser des diagrammes UML pour expliquer le code source lui-même, rendez plutôt le code soruce plus auto-documenté.

Enfin, certaines des règles générales qui s'appliquent au code peuvent également s'appliquer aux diagrammes: évitez de vous répéter, restez simple, ne craignez pas de changer les choses (ce n'est pas parce qu'un document est documenté sur un diagramme UML qu'il ne peut pas être changé) et pensez toujours à qui lira / maintiendra ces diagrammes à l'avenir (probablement votre futur) lors de leur écriture :)

UML a de la valeur si les membres de l'équipe le comprennent collectivement et le considèrent comme un moyen utile de résumer et de communiquer les décisions de conception. Vous n'avez pas besoin de tout savoir, juste ce sous-ensemble que l'équipe trouve utile.

De plus, vous n'avez pas besoin de dessiner des diagrammes parfaits et polis. Un diagramme de séquence grossièrement esquissé sur un tableau blanc ou un diagramme de classe dans lequel les classes sont post-it, des notes collées sur ce tableau blanc peuvent être suffisants, selon le contexte.

J'ai déjà travaillé sur un concert où j'avais besoin de gérer une équipe de développeurs sous contrat à l'étranger.

Certaines des choses qu'ils produisaient étaient assez horribles (un symptôme courant des codeurs de contrats à distance - ils ne se soucient pas vraiment de votre code, ils veulent juste être fait rapidement).

Pour gérer le projet, je me suis retrouvé à produire des diagrammes UML et à les remettre au code. Ce fut un grand succès - il ne m'a pas fallu longtemps pour écrire un programme en UML, beaucoup plus rapidement qu'en Java, et c'était quelque chose que les entrepreneurs pouvaient suivre et mesurer.

Une mise en garde - ils voulaient parfois devenir créatifs et s'écarter de mes modèles, mais dans ces cas, ils étaient en fait corrects et, dans l'ensemble, l'UML a amélioré la qualité du produit final

Si quelqu'un vous a demandé de préparer des diagrammes UML et que quelqu'un paie votre salaire, ce n'est pas vraiment une perte de temps. Cela peut ou non être une perte de temps pour cette personne.

Si quelqu'un envisage de comprendre votre projet en lisant vos diagrammes UML, ce n'est probablement pas une perte de temps.

Je trouve utile au stade de la conception initiale d'avoir des idées sur papier ou sur le tableau blanc. J'ai principalement utilisé des diagrammes de classes UML, sans respecter strictement les normes. Il est utile de revoir votre conception originale UML lorsque vous êtes à mi-chemin et également à la fin du projet. Cela m'a aidé à examiner une base de code à un niveau d'abstraction plus élevé que vous ne pouvez jamais simplement en lisant le code, et a même aidé à repérer les bogues potentiels.

Ragu.pattabi fait une bonne remarque ici en distinguant deux types d'UML ...

Je pense que la saveur agile d'UML (par exemple, un croquis rapide de tableau blanc) est plus réussie que la saveur en cascade d'UML (par exemple, un diagramme élaboré avec tous les détails sanglants pour la documentation, la génération de code, etc. pour rendre les gestionnaires avertis de documents heureux).

Quand UML était considéré comme une compétence incontournable (il y a 10 ans ou plus), j'étais probablement contre en raison des opinions d'opinion de ses nombreux fans à l'époque. Mais maintenant qu'il est tombé en disgrâce, je me retrouve à le voir pour ce qu'il est - un outil utile qui a du mérite mais n'est pas la solution miracle du développement logiciel.

J'utilise UML (ou quelque chose de similaire à UML :)) lorsque je parle à des amis de quelque chose que nous allons faire. Pour discuter des idées. Ne pas préparer de projet UML qui générera automatiquement du code pour moi. Je ne peux pas imaginer créer mes classes en UML puis générer du code et ne pas le modifier plus tard. Cela n'arrive jamais. Vous devrez donc apporter des modifications du code à UML. Et lorsque j'utilise UML, je dessine sur un tableau blanc ou du papier. Jamais dans un outil comme Enterprise Architect.

La seule raison de documenter tout mon code en UML serait un contrat où le client l'exige. Par exemple, quand il veut avoir la possibilité de changer de magasin de logiciels après la fin d'une partie du logiciel.

La documentation de travail du projet est un livrable fondamental d'un projet professionnel. Combien en faut-il? Eh bien, cela dépend bien sûr de nombreux facteurs. Cependant, à mon avis, les cas d'utilisation, les diagrammes de classes, les diagrammes de flux de processus, etc. ne sont pas du tout une perte de temps. Ils ont de la valeur dans différentes phases du projet. Le seul problème avec la documentation est généralement les ressources.

Certains programmeurs considèrent la documentation comme une perte de temps. Mais ce n'est pas vrai. Si vous voyez la documentation comme un affichage de votre conception et de vos règles système d'une manière élégante et claire, vous pourriez l'apprécier davantage. De plus, il faut se mettre à la place des personnes qui ont besoin de maintenir le système. Être jeté 500 fichiers de code et être invité à résoudre les problèmes avec eux est un peu mauvais mais pas rare.

Je vous suggère d'allouer du temps à votre projet et de produire les diagrammes en cycles. Le premier couvrirait les aspects de haut niveau de votre projet et les niveaux suivants pourraient insister davantage sur les détails.

Les cas d'utilisation en particulier ne peuvent pas être déduits facilement du code (contrairement à de nombreux autres aspects d'un système). Assurez-vous de les faire.

UML est un outil, rien de plus, et s'il est utile ou même crucial dépend uniquement de votre flux de travail de développement et de conception. Il existe de nombreuses façons de se rendre à Rome, et certaines impliquent UML, d'autres non.

Si votre flux de travail repose sur UML pour documenter ou planifier votre architecture, il serait stupide de le supprimer. Si UML est le meilleur moyen possible de communiquer la structure du projet aux autres membres de l'équipe (au sens large), utilisez-la par tous les moyens. Mais si le projet fonctionne bien sans UML, faire des diagrammes UML juste pour le plaisir est un non-sens.

J'ai quelques réflexions à ce sujet. Le langage peut être utilisé et abusé, contraindre et distraire, déclencher et calmer. UML est juste une autre langue adaptée à un ensemble spécifique de problèmes et, comme toute autre langue, il faudra du temps et des efforts pour apprendre à la parler couramment et à la comprendre correctement.

La décision sur quoi communiquer est incroyablement plus importante que la langue dans laquelle elle est communiquée. UML ne rendra pas comme par magie vos mauvaises conceptions compréhensibles. Comme toute autre langue, il est facile de se perdre dans les détails ou de trop laisser à l'imagination.

UML a obtenu une mauvaise réputation en raison des nombreux horribles IDE, permettant le prototypage aller-retour, la manipulation de graphiques intensive en clics et la difficulté de changer quoi que ce soit. UML 2.0 peut être suffisamment complexe pour satisfaire certains universitaires, mais son méta-modèle ne semble pas attirer de nombreuses applications pratiques.

Pourtant, j'utilise UML de temps en temps. Évaluer une conception de haut niveau (une bonne conception a de la complexité sur les franges et de la simplicité au centre). Communiquer une idée à un collègue et recevoir des commentaires. Trouver des relations cachées, normaliser, etc. Mais c'est toujours le reflet de quelque chose qui est déjà dans ma tête. En général, je dessine UML avec un stylo et du papier, de préférence loin de tout ordinateur. Si nécessaire, quand un dessin se cristallise, je fais une représentation visuelle dans un programme de dessin.

UML est absolument fantastique pour obtenir une vue graphique de votre architecture à l'aide d'un diagramme de classes. L'interaction à l'aide du diagramme de séquence est magique pour moi. Le problème n'est donc pas UML mais MDD pour moi.

Je veux dire que si UML est une visionneuse du code, il est vraiment utile à des fins de documentation, mais certainement pas pour la génération de code. Le projet doit être centré sur le code et certainement pas centré sur le modèle. UML doit être utilisé au stade de la mise en œuvre en utilisant un code en direct et une synchronisation de modèle, je veux dire non seulement au niveau des exigences, ce qui nécessite trop d'investissement pour un faible rendement en productivité et en qualité.

Je les trouve très surfaits. Je les considère comme les seules images qui ne peignent pas mille mots.

UML n'a de valeur que si les personnes qui conçoivent le système ne peuvent pas écrire le code elles-mêmes. c'est-à-dire que UML est un «langage» qui communique les concepts architecturaux à quelqu'un d'autre, maintenant si vous êtes la personne qui conçoit le code et l'implémente, alors pourquoi auriez-vous besoin de vous montrer ce que vous allez faire ?! Montez et dirigez-vous directement vers le codage à la place. Vous devrez toujours documenter ce que vous avez fait plus tard, mais l'efficacité globale est plus rapide.

Mais, si vous étiez un architecte système voulant dire à votre équipe de développeurs externalisée ce que vous vouliez, alors vous devriez leur dire d'une manière ou d'une autre, et c'est là qu'UML entre en jeu. Cependant, je pense qu'il existe de nombreux autres moyens d'effectuer cette tâche de nos jours, et franchement, la complexité du diagramme UML signifie que tout le monde doit comprendre comment le lire, ce qui est quelque peu voué à l'échec s'ils ne le font pas.

Je n'ai jamais été un fan d'UML, mais j'en suis venu à apprécier un bon diagramme de séquence pour décrire les interactions entre les systèmes ou les tâches.

Cependant, le diagramme de classes est obsolète avant sa naissance. Une conception approximative ne nécessite pas UML, et une documentation complète est mieux extraite automatiquement (en direct) de la base de code. Javadoc et Doxygen ont complètement obsolète le besoin de diagrammes de classes manuels.

La chose à propos de la documentation est qu'il existe deux niveaux:

• les décisions (architecturales) de haut niveau doivent être documentées manuellement
• les faits de bas niveau (relations d'entités) doivent être extraits automatiquement

J'itère généralement entre le code et les diagrammes UML. Je trouve que les diagrammes aident à montrer la grande image et un chemin solide à suivre et ils peuvent être modifiés assez rapidement lorsque des problèmes sont découverts. De plus, lorsque j'ai les diagrammes, le codage a tendance à devenir trivial.

À l'inverse, lorsque je dessine le code en images, il expose des problèmes de dépendance et rend les opportunités d'amélioration de la conception manifestement évidentes, ce qui n'aurait probablement pas été remarqué si nous n'avions eu que le code à partir duquel travailler. En particulier, si c'est une douleur à dessiner, alors ça va aussi être une douleur à coder et un cauchemar à entretenir.

J'ai trouvé que l'itération est nécessaire, car le simple dessin des images manque toujours des aspects importants, tandis que le codage entraîne des conceptions problématiques.

Cependant, comme l'a dit une autre affiche, tout se résume au peuple. S'ils savent "utiliser" les diagrammes UML, alors UML est inestimable. S'ils ne le sont pas, les diagrammes sont sans valeur.

Ainsi, la réponse à votre question est vraiment "ça dépend". Dans ce cas, cela dépend des personnes, de la complexité du projet et de l'importance du bon fonctionnement du système.

D'après mon expérience, l'UML est important pour la communication entre les développeurs sur les modèles de code et pour l'architecture en général de l'application.

J'adore les diagrammes, mais si on me demandait d'en faire un (surtout UML!), Je poserais deux questions:

1. C'est pour qui?
2. En ont-ils besoin maintenant?

Les diagrammes deviennent immédiatement obsolètes. Donc, à moins que vous ne l'utilisiez pour communiquer avec quelqu'un maintenant, il ne fera que pourrir. Et si la personne avec laquelle vous communiquez ferait mieux avec une description textuelle, un appel téléphonique ou un digramme informel sur un tableau blanc - suggérez-le à la place.

L'un des principaux reproches que je fais des diagrammes UML que j'ai vus jusqu'à présent est qu'ils n'ont généralement tendance à servir que de "jolies images" sur le mur de quelqu'un ou comme une page pliée dans une reliure quelque part et servent rarement de référence. pour un code de production.

Dans ce type de scénario - les diagrammes UML (ou quelle que soit la saveur du langage de modélisation que vous utilisez) sont rarement utiles à long terme, car ils ont tendance à souffrir d'une perte de pertinence au fil du temps et du projet. Ces premiers dessins sont pour la plupart inutiles et incorrects dans quelques années et les avoir autour est surtout nocif.

Cela dit, l'utilisation d'outils de modélisation (pas nécessairement UML) n'est pas une pratique entièrement inutile, si les modèles fournissent une entrée réelle et pertinente réelle au code en cours d'exécution. Si la description du modèle est un artefact utile du code, il doit être traité comme du code:

Soit en l'utilisant comme source directe de métadonnées pour prendre des décisions dynamiques basées sur les concepts modélisés, soit en utilisant la génération de code pour générer des artefacts de code statique qui seront utilisés dans le code de travail réel.

Je ne sais pas si la question porte sur le mérite d'UML, ou sur le mérite de concevoir l'architecture de programmes.

À propos d'UML. Vous n'avez généralement besoin que de: cas d'utilisation, diagrammes de classes et diagrammes de séquence. Simple et facile, bien que vous puissiez certainement le faire avec vos propres types de diagrammes. À cet égard, UML est une norme que tout le monde comprendra.

À propos de la conception de programmes.

1. Chaque programme a un design, même si vous ne le planifiez pas. Lorsque le code est écrit, il suffit de procéder à une rétro-ingénierie. Si vous ne l'avez pas planifié, pariez que ce sera un mauvais design.

2. La conception vous fera gagner du temps, en utilisant des modèles connus pour les problèmes récurrents.

3. Si vous travaillez en équipe, le design est nécessaire pour discuter des solutions, pour transmettre des idées, et très pratique mais nécessaire, pour répartir le travail.