UML est-il pratique? [fermé]

Au collège, j'ai suivi de nombreux cours de conception et orientés UML , et je reconnais que UML peut être utilisé au profit d'un projet logiciel, en particulier la cartographie de cas d'utilisation , mais est-ce vraiment pratique? J'ai fait quelques stages de travail coopératif, et il semble que UML n'est pas très utilisé dans l'industrie. Vaut-il la peine de créer des diagrammes UML pendant un projet? De plus, je trouve que les diagrammes de classes ne sont généralement pas utiles, car il est simplement plus rapide de consulter le fichier d'en-tête d'une classe. Plus précisément, quels diagrammes sont les plus utiles?

Edit: Mon expérience est limitée à de petits projets de moins de 10 développeurs.

Edit: Beaucoup de bonnes réponses, et bien que ce ne soit pas la plus verbeuse, je crois que celle choisie est la plus équilibrée.

Dans un système suffisamment complexe, il y a des endroits où certains UMLsont considérés comme utiles.

Les schémas utiles pour un système varient selon l'applicabilité.
Mais les plus utilisés sont:

• Diagrammes de classes
• Diagrammes d'état
• Diagrammes d'activités
• Diagrammes de séquence

Il existe de nombreuses entreprises qui ne jurent que par elles et beaucoup les rejettent carrément comme une perte de temps et d'efforts.

Il est préférable de ne pas aller trop loin et de penser à ce qui est le mieux pour le projet sur lequel vous êtes et de choisir ce qui est applicable et qui a du sens.

Utiliser UML, c'est comme regarder vos pieds pendant que vous marchez. C'est rendre conscient et explicite quelque chose que vous pouvez généralement faire inconsciemment. Les débutants doivent réfléchir attentivement à ce qu'ils font, mais un programmeur professionnel sait déjà ce qu'ils font. La plupart du temps, l'écriture du code lui-même est plus rapide et plus efficace que l'écriture sur le code, car leur intuition de programmation est adaptée à la tâche.

Ce n'est pas seulement ce que vous faites. Qu'en est-il de la nouvelle recrue qui arrive dans six mois et doit se mettre au courant du code? Et dans cinq ans, alors que tous ceux qui travaillent actuellement sur le projet seront partis?

Il est extrêmement utile d'avoir une documentation de base à jour disponible pour quiconque rejoindra le projet plus tard. Je ne préconise pas de diagrammes UML complets avec des noms de méthodes et des paramètres (BEAUCOUP trop difficile à maintenir), mais je pense qu'un diagramme de base des composants du système avec leurs relations et leur comportement de base est inestimable. À moins que la conception du système ne change radicalement, ces informations ne devraient pas beaucoup changer même si la mise en œuvre est peaufinée.

J'ai trouvé que la clé de la documentation est la modération. Personne ne lira 50 pages de diagrammes UML complets avec de la documentation de conception sans s'endormir quelques pages. D'un autre côté, la plupart des gens aimeraient obtenir 5 à 10 pages de diagrammes de classes simples avec quelques descriptions de base de la façon dont le système est mis en place.

L'autre cas où j'ai trouvé UML utile est celui où un développeur senior est responsable de la conception d'un composant, mais remet ensuite la conception à un développeur junior pour l'implémenter.

Utiliser UML, c'est comme regarder vos pieds pendant que vous marchez. C'est rendre conscient et explicite quelque chose que vous pouvez généralement faire inconsciemment. Les débutants doivent réfléchir attentivement à ce qu'ils font, mais un programmeur professionnel sait déjà ce qu'ils font. La plupart du temps, l'écriture du code lui-même est plus rapide et plus efficace que l'écriture sur le code, car leur intuition de programmation est adaptée à la tâche.

L'exception est la raison pour laquelle vous vous retrouvez dans les bois la nuit sans torche et qu'il a commencé à pleuvoir - alors vous devez regarder vos pieds pour éviter de tomber. Il y a des moments où la tâche que vous avez assumée est plus compliquée que votre intuition ne peut gérer, et vous devez ralentir et énoncer explicitement la structure de votre programme. UML est alors l'un des nombreux outils que vous pouvez utiliser. D'autres incluent des pseudocodes, des diagrammes d'architecture de haut niveau et d'étranges métaphores.

Les flux de travail génériques et les DFD peuvent être très utiles pour les processus complexes. Tous les autres schémas (EN PARTICULIER UML) ont, d'après mon expérience, sans exception été une perte de temps et d'efforts douloureux.

Je ne suis pas d'accord, UML est utilisé partout - partout où un projet informatique est conçu, UML sera généralement présent.

Maintenant, s'il est bien utilisé, c'est une autre question.

Comme l'a dit Stu, je trouve que les cas d'utilisation (ainsi que les descriptions de cas d'utilisation) et les diagrammes d'activités sont les plus utiles du point de vue du développeur.

Le diagramme de classes peut être très utile lorsque vous essayez d'afficher des relations, ainsi que des attributs d'objet, tels que la persistance. Lorsqu'il s'agit d'ajouter un attribut ou une propriété unique, ils sont généralement exagérés, d'autant plus qu'ils deviennent souvent rapidement obsolètes une fois le code écrit.

L'un des plus gros problèmes avec UML est la quantité de travail nécessaire pour le maintenir à jour une fois le code généré, car il existe peu d'outils capables de réorganiser UML à partir du code, et peu encore le font bien.

Je nuancerai ma réponse en mentionnant que je n'ai pas d'expérience dans les grands environnements de développement d'entreprise (de type IBM).

La façon dont je vois UML et le Rational Unified Process est qu'il s'agit plus de PARLER de ce que vous allez faire que de FAIRE réellement ce que vous allez faire.

(En d'autres termes, c'est en grande partie une perte de temps)

Jeter seulement à mon avis. UML est un excellent outil pour communiquer des idées, le seul problème est lorsque vous le stockez et le maintenez, car vous créez essentiellement deux copies des mêmes informations et c'est là que cela souffle généralement. Après la première phase d'implémentation, la plupart des UML devraient être générés à partir du code source, sinon il deviendra obsolète très rapidement ou nécessitera beaucoup de temps (avec des erreurs manuelles) pour rester à jour.

J'ai co-enseigné un cours de projet de développement de haut niveau mes deux derniers semestres à l'école. Le projet était destiné à être utilisé dans un environnement de production avec des organisations à but non lucratif locales en tant que clients payants. Nous devions être certains que le code faisait ce que nous attendions et que les étudiants capturaient toutes les données nécessaires pour répondre aux besoins des clients.

Le temps de classe était limité, tout comme mon temps en dehors de la classe. En tant que tel, nous devions effectuer des révisions de code à chaque réunion de classe, mais avec 25 étudiants inscrits, le temps de révision individuelle était très court. L'outil que nous avons trouvé le plus précieux au cours de ces séances d'examen était les DRE, les diagrammes de classes et les diagrammes de séquence. Les DRE et les diagrammes de classes ont été réalisés uniquement dans Visual Studio, le temps requis pour les créer était donc insignifiant pour les étudiants.

Les schémas communiquaient très rapidement beaucoup d'informations. En ayant un aperçu rapide des conceptions des étudiants, nous pourrions rapidement isoler les zones problématiques dans leur code et effectuer une révision plus détaillée sur place.

Sans utiliser de diagrammes, nous aurions dû prendre le temps de parcourir un par un les fichiers de code des élèves à la recherche de problèmes.

J'arrive à ce sujet un peu tard et je vais simplement essayer de clarifier quelques points mineurs. Demander si UML est utile car beaucoup trop large. La plupart des gens semblaient répondre à la question à partir de l'UML typique / populaire en tant qu'outil de dessin / communication. Remarque: Martin Fowler et d'autres auteurs de livres UML estiment qu'UML est mieux utilisé uniquement pour la communication. Cependant, il existe de nombreuses autres utilisations pour UML. Par-dessus tout, UML est un langage de modélisation qui a une notation et des diagrammes mappés aux concepts logiques. Voici quelques utilisations de UML:

• la communication
• Documentation standardisée de conception / solution
• Définition DSL (Domain Specific Language)
• Définition de modèle (profils UML)
• Utilisation des modèles / actifs
• Génération de code
• Transformations de modèle en modèle

Compte tenu de la liste des utilisations ci-dessus, la publication par Pascal n'est pas suffisante car elle ne parle que de la création de diagrammes. Un projet peut bénéficier d'UML si l'un des facteurs ci-dessus est un facteur de réussite critique ou des domaines problématiques nécessitant une solution standardisée.

La discussion devrait s'étendre sur la façon dont UML peut être sur-kill ou appliqué à de petits projets pour discuter du moment où UML a du sens ou améliorera réellement le produit / la solution, car c'est à ce moment-là qu'UML doit être utilisé. Il existe des situations où UML pour un développeur peut également être détecté, comme l'application de modèle ou la génération de code.

UML travaille pour moi depuis des années. Quand j'ai commencé, j'ai lu UML Distilled de Fowler où il dit "faites assez de modélisation / architecture / etc.". Utilisez simplement ce dont vous avez besoin !

Du point de vue d'un ingénieur QA, les diagrammes UML soulignent les failles potentielles dans la logique et la pensée. Rend mon travail plus facile :)

Je pense que l'UML est utile, je pense que la spécification 2.0 a rendu ce qui était autrefois une spécification claire quelque peu gonflée et encombrante. Je suis d'accord avec l'édition des chronogrammes, etc. puisqu'ils ont rempli un vide ...

Apprendre à utiliser efficacement l'UML demande un peu de pratique. Le point le plus important est de communiquer clairement, de modéliser au besoin et de modéliser en équipe. Les tableaux blancs sont le meilleur outil que j'ai trouvé. Je n'ai vu aucun "logiciel de tableau blanc numérique" qui ait réussi à capturer l'utilité d'un tableau blanc réel.

Cela étant dit, j'aime les outils UML suivants:

1. Violet - Si c'était plus simple, ce serait un morceau de papier

2. Altova UModel - Bon outil pour la modélisation Java et C #

3. MagicDraw - Mon outil commercial préféré pour la modélisation

4. Poseidon - Outil décent avec un bon rapport qualité-prix

5. StarUML - Meilleur outil de modélisation open source

Les diagrammes UML sont utiles pour capturer et communiquer les exigences et s'assurer que le système répond à ces exigences. Ils peuvent être utilisés de manière itérative et à différentes étapes de la planification, de la conception, du développement et des tests.

À partir de la rubrique: Utilisation de modèles dans le processus de développement à l' adresse http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

Un modèle peut vous aider à visualiser le monde dans lequel votre système fonctionne, à clarifier les besoins des utilisateurs, à définir l'architecture de votre système, à analyser le code et à vous assurer que votre code répond aux exigences.

Vous voudrez peut-être également lire ma réponse au message suivant:

Comment apprendre la «bonne conception / architecture logicielle»? à /programming/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Bien que cette discussion soit restée longtemps inactive, j'ai quelques points - à mon sens importants - à ajouter.

Le code buggy est une chose. Laissées à la dérive vers l'aval, les erreurs de conception peuvent devenir très gonflées et laides. UML, cependant, s'auto-valide. J'entends par là qu'en vous permettant d'explorer vos modèles dans des dimensions multiples, mathématiquement fermées et se vérifiant mutuellement, cela engendre une conception robuste.

UML a un autre aspect important: il "parle" directement à notre capacité la plus forte, celle de la visualisation. Si, par exemple, ITIL V3 (au fond assez simple) avait été communiqué sous forme de diagrammes UML, il aurait pu être publié sur quelques dizaines de dépliants A3. Au lieu de cela, il est sorti dans plusieurs tomes aux proportions vraiment bibliques, engendrant toute une industrie, des coûts à couper le souffle et un choc catatonique généralisé.

Je vois des diagrammes de séquence et des diagrammes d'activité utilisés assez souvent. Je travaille beaucoup avec des systèmes "temps réel" et embarqués qui interagissent avec d'autres systèmes, et les diagrammes de séquence sont très utiles pour visualiser toutes les interactions.

J'aime faire des diagrammes de cas d'utilisation, mais je n'ai pas rencontré trop de gens qui pensent qu'ils sont utiles.

Je me suis souvent demandé si Rational Rose était un bon exemple des types d'applications que vous obtenez de la conception basée sur un modèle UML. C'est gonflé, bogué, lent, moche, ...

J'ai trouvé UML pas vraiment utile pour les très petits projets, mais vraiment adapté pour les plus grands.

Essentiellement, ce que vous utilisez n'a pas vraiment d'importance, il vous suffit de garder deux choses à l'esprit:

• Vous voulez une sorte de planification de l'architecture
• Vous voulez être sûr que tout le monde dans l'équipe utilise réellement la même technologie pour la planification de projet

Donc UML est juste cela: une norme sur la façon dont vous planifiez vos projets. Si vous embauchez de nouvelles personnes, il y a plus de chances de connaître une norme existante - que ce soit UML, Flowchard, Nassi-Schneiderman, peu importe - plutôt que vos affaires internes existantes.

Utiliser UML pour un seul développeur et / ou un simple projet logiciel me semble exagéré, mais lorsque je travaille dans une plus grande équipe, je voudrais certainement une norme pour un logiciel de planification.

UML est utile, oui en effet! Les principales utilisations que j'en ai faites étaient:

• Brainstorming sur la manière dont un logiciel devrait fonctionner. Il est facile de communiquer ce que vous pensez.
• Documenter l'architecture d'un système, ses modèles et les principales relations de ses classes. Cela aide quand quelqu'un entre dans votre équipe, quand vous partez et que vous voulez vous assurer que votre successeur le comprendra, et quand vous finissez par oublier à quoi sert ce petit cours.
• Documenter tout modèle architectural que vous utilisez sur tous vos systèmes, pour les mêmes raisons du point ci-dessus

Je ne suis pas d'accord avec Michael quand il dit qu'utiliser UML pour un seul développeur et / ou un simple projet logiciel lui semble exagéré . Je l'ai utilisé sur mes petits projets personnels, et les avoir documentés en utilisant UML m'a fait gagner beaucoup de temps quand je suis revenu sept mois plus tard et j'avais complètement oublié comment j'avais construit et assemblé toutes ces classes.

Je crois qu'il y a peut-être un moyen d'utiliser les cas d'utilisation du poisson, du cerf-volant et du niveau de la mer UML de style Cockburn comme décrit par Fowler dans son livre "UML Distilled". Mon idée était d'utiliser les cas d'utilisation de Cockburn pour améliorer la lisibilité du code.

J'ai donc fait une expérience et il y a un article ici à ce sujet avec la balise "UML" ou "FOWLER". C'était une idée simple pour c #. Trouvez un moyen d'incorporer les cas d'utilisation de Cockburn dans les espaces de noms des constructions de programmation (comme les espaces de noms de classe et de classe interne ou en utilisant les espaces de noms pour les énumérations). Je pense que cela pourrait être une technique viable et simple, mais j'ai encore des questions et j'ai besoin d'autres personnes pour la vérifier. Cela pourrait être bon pour les programmes simples qui ont besoin d'une sorte de pseudo-langage spécifique au domaine qui peut exister au milieu du code c # sans aucune extension de langage.

Veuillez consulter le message si vous êtes intéressé. Allez ici .

L'un des problèmes que j'ai avec UML est la compréhensibilité de la spécification. Quand j'essaie de vraiment comprendre la sémantique d'un diagramme particulier, je me perds rapidement dans le labyrinthe des méta-modèles et des méta-méta-modèles. L'un des arguments de vente d'UML est qu'il est moins ambigu que le langage naturel. Cependant, si deux ingénieurs ou plus interprètent un diagramme différemment, il échoue à atteindre l'objectif.

De plus, j'ai essayé de poser des questions spécifiques sur le document de super-structure sur plusieurs forums UML et aux membres de l'OMG lui-même, avec peu ou pas de résultats. Je ne pense pas que la communauté UML soit encore assez mature pour se soutenir.

Venant d'un étudiant, je trouve que UML a très peu d'utilité. Je trouve ironique que les PROGAMERS n'aient pas encore développé de programme qui générera automatiquement les choses que vous avez dites nécessaires. Il serait extrêmement simple de concevoir une fonctionnalité dans Visual Studio qui pourrait extraire des morceaux de données, rechercher des définitions et des réponses produit suffisantes pour que tout le monde puisse la regarder, grande ou petite, et comprendre le programme. Cela permettrait également de le maintenir à jour car cela prendrait les informations directement du code pour produire les informations.

UML est utilisé dès que vous représentez une classe avec ses champs et ses méthodes, bien qu'il ne s'agisse que d'une sorte de diagramme UML.

Le problème avec UML est que le livre des fondateurs est trop vague.

UML n'est qu'un langage, ce n'est pas vraiment une méthode.

Quant à moi, je trouve vraiment ennuyeux le manque de schéma UML pour les projets OpenSource. Prenez quelque chose comme Wordpress, vous avez juste un schéma de base de données, rien d'autre. Vous devez vous promener dans l'API du codex pour essayer d'avoir une vue d'ensemble.

UML a sa place. Cela devient de plus en plus important à mesure que la taille du projet augmente. Si vous avez un projet de longue date, il est préférable de tout documenter en UML.

UML semble bon pour les grands projets avec de grandes équipes de personnes. Cependant, j'ai travaillé dans de petites équipes où la communication est meilleure.

L'utilisation de diagrammes UML est cependant une bonne chose, en particulier lors de la phase de planification. J'ai tendance à penser en code, donc je trouve difficile d'écrire de grandes spécifications. Je préfère écrire les entrées et les sorties et laisser les développeurs concevoir le bit au milieu.

Je pense qu'UML est utile uniquement parce qu'il amène les gens à réfléchir aux relations entre leurs classes. C'est un bon point de départ pour commencer à réfléchir à de telles relations, mais ce n'est certainement pas une solution pour tout le monde.

Ma conviction est que l'utilisation d'UML est subjective par rapport à la situation dans laquelle l'équipe de développement travaille.

Dans mon expérience:

La capacité de créer et de communiquer des diagrammes de code significatifs est une compétence nécessaire pour tout ingénieur logiciel qui développe un nouveau code ou tente de comprendre le code existant.

Connaître les spécificités d'UML - quand utiliser une ligne en pointillé ou un point de terminaison de cercle - n'est pas aussi nécessaire, mais il est toujours bon d'avoir.

UML est utile de deux manières:

• Côté technique: beaucoup de gens (manager et quelques analystes fonctionnels) pensent qu'UML est une fonctionnalité de luxe car Le code est la documentation: vous commencez à coder, après avoir débogué et corrigé . La synchronisation des diagrammes UML avec le code et les analyses vous oblige à bien comprendre les demandes du client;

• Côté gestion: les diagrammes UMl sont un miroir des demandes du client qui sont inexactes: si vous codez sans UML, peut-être pourrez-vous trouver un bug dans le requiert après de nombreuses heures de travail. Les schémas UML vous permettent de trouver les éventuels points controversés et de les résoudre avant le codage => aidez votre planning.

Généralement, tous les projets sans diagrammes UML ont une analyse superficielle ou ils ont une taille courte.

si vous êtes dans le groupe LinkedIn INGÉNIEURS SYSTÈMES , consultez mon ancienne discussion .

En fin de compte, UML n'existe qu'à cause de RUP. Avons-nous besoin d'UML ou de tout autre élément connexe pour utiliser Java / .Net? La réponse pratique est qu'ils ont leur propre documentation (javadoc, etc.) qui est suffisante et nous permet de faire notre travail!

UML pas merci.

UML est vraiment utile tout comme junit est essentiel. Tout dépend de la manière dont vous vendez l'idée. Votre programme fonctionnera sans UML comme il fonctionnerait sans tests unitaires. Cela dit, vous devez créer do UML au fur et à mesure qu'il est connecté à votre code, c'est-à-dire que lorsque vous mettez à jour des diagrammes UML, il met à jour votre code, ou lorsque vous mettez à jour votre code, il génère automatiquement l'UML. Ne faites pas juste pour le faire.

UML a définitivement sa place dans l'industrie. Imaginez que vous construisez un logiciel pour un avion Boing ou un autre système complexe. UML et RUP seraient d'une grande aide ici.

UML n'est qu'une des méthodes de communication au sein des personnes. Le tableau blanc est meilleur.