UML est-il pratique ?[fermé]

https://stackoverflow.com/questions/18803

09-06-2019
|

Question

Au collège, j'ai eu de nombreux projets de design et UML cours orientés, et je reconnais qu'UML peut être utilisé au profit d'un projet logiciel, en particulier cas d'utilisation la cartographie, mais est-ce vraiment pratique ?J'ai effectué quelques stages coop et il semble qu'UML ne soit pas beaucoup utilisé dans l'industrie.Est-ce que cela vaut la peine de consacrer du temps lors d'un projet à créer des diagrammes UML ?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 ?

Modifier: Mon expérience se limite aux petits projets de moins de 10 développeurs.

Modifier: Beaucoup de bonnes réponses, et même si elles ne sont pas les plus verbeuses, je pense que celle sélectionnée est la plus équilibrée.

La solution

Dans un système suffisamment complexe, il existe certains endroits où certains UML sont considérés comme utiles.

Les diagrammes utiles pour un système varient selon l’applicabilité.Mais les plus largement utilisés sont les diagrammes d’états, les diagrammes d’activités et les diagrammes de séquence.

De nombreuses entreprises ne jurent que par elles et beaucoup les rejettent catégoriquement, les considérant comme une pure perte de temps et d’efforts.

Il est préférable de ne pas aller trop loin et de réfléchir à ce qui est le mieux pour le projet dans lequel vous vous trouvez et de choisir les éléments qui sont applicables et qui ont du sens.

Autres conseils

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

Il ne s’agit pas seulement de ce que vous faites.Qu’en est-il de la nouvelle recrue qui arrive dans six mois et qui doit se familiariser avec le code ?Qu’en sera-t-il dans cinq ans, lorsque tous ceux qui travaillent actuellement sur le projet auront disparu ?

Il est incroyablement utile de disposer d'une documentation de base à jour pour toute personne qui rejoint le projet ultérieurement.Je ne préconise pas les diagrammes UML complets avec les noms de méthodes et les paramètres (BEAUCOUP trop difficiles à 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 découvert que la clé de la documentation est la modération.Personne ne lira 50 pages de diagrammes UML complets avec documentation de conception sans s'endormir sur 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 confie ensuite la conception à un développeur junior pour qu'il l'implémente.

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

L'exception est la raison pour laquelle vous vous retrouvez la nuit dans les bois sans lampe de poche et qu'il commence à pleuvoir - vous devez alors regarder vos pieds pour éviter de tomber.Il y a des moments où la tâche que vous avez entreprise est plus compliquée que ce que votre intuition 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 du pseudocode, des diagrammes d’architecture de haut niveau et d’étranges métaphores.

Le flux de travail générique et les DFD peuvent être très utiles pour les processus complexes.D'après mon expérience, tous les autres diagrammes (surtout UML) ont été, sans exception, une douloureuse perte de temps et d'efforts.

Je ne suis pas d'accord, UML est utilisé partout - partout où un projet informatique est en cours de conception, UML sera généralement présent.

Maintenant, est-ce qu'il est utilisé Bien c'est une autre affaire.

Comme Stu l'a dit, 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 seul attribut ou une seule propriété, ils sont généralement excessifs, 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éingénierie UML à partir du code, et rares sont ceux qui le font correctement.

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 processus unifié rationnel c'est que c'est plus PARLER sur ce que tu vas faire qu'en réalité FAIRE ce que tu vas 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 de la même information et c'est là que ça explose généralement.Après le premier cycle de mise en œuvre, la majeure partie du code UML doit être générée à 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 niveau supérieur au cours de mes deux derniers semestres à l'école.Le projet était destiné à être utilisé dans un environnement de production avec des organisations locales à but non lucratif comme 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 cours é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.Les outils que nous avons trouvés les plus utiles lors de ces sessions de révision étaient les ERD, les diagrammes de classes et les diagrammes de séquence.Les ERD 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 diagrammes communiquaient beaucoup d’informations très rapidement.En ayant un aperçu rapide des conceptions des étudiants, nous avons pu rapidement isoler les zones problématiques dans leur code et effectuer un examen plus détaillé sur place.

Sans utiliser de schémas, il aurait fallu prendre le temps de parcourir un à un les fichiers de codes des élèves à la recherche de problèmes.

J'arrive sur ce sujet un peu tard et je vais juste essayer de clarifier quelques points mineurs.Demander si UML est utile car beaucoup trop large.La plupart des gens semblaient répondre à la question du point de vue de l'UML typique/populaire en tant qu'outil de dessin/communication.Note:Martin Fowler et d'autres auteurs de livres UML estiment qu'UML est mieux utilisé à des fins de communication uniquement.Cependant, il existe de nombreuses autres utilisations d’UML.Avant tout, UML est un langage de modélisation dont la notation et les diagrammes sont mappés aux concepts logiques.Voici quelques utilisations d’UML :

Communication
Documentation de conception/solution standardisée
Définition DSL (Langage Spécifique au Domaine)
Définition du modèle (profils UML)
Utilisation du modèle/des actifs
Génération de code
Transformations de modèle à modèle

Compte tenu de la liste des utilisations ci-dessus, la publication de Pascal n'est pas suffisante car elle ne concerne que la création de diagrammes.Un projet pourrait bénéficier d’UML si l’un des éléments ci-dessus constitue un facteur de réussite critique ou constitue un problème nécessitant une solution standardisée.

La discussion devrait s'étendre sur la façon dont UML peut être sur-tué 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 devrait être utilisé.Il existe des situations où UML pour un développeur pourrait également être pertinent, comme l'application de modèles ou la génération de code.

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

Du point de vue d'un ingénieur QA, les diagrammes UML soulignent les failles potentielles de la logique et de la pensée.Cela me facilite le travail :)

Je pense que l'UML est utile, même si 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 car ils comblent un vide...

Apprendre à utiliser efficacement UML demande un peu de pratique.Le point le plus important est de communiquer clairement, de modéliser en cas de 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 véritable tableau blanc.

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

Violette - Si c'était plus simple, ce serait un morceau de papier
Altova UModel - Bon outil pour la modélisation Java et C#
MagicDraw - Mon outil commercial préféré pour la modélisation
Poséidon - Outil décent avec un bon rapport qualité-prix
StarUML – Meilleur outil de modélisation open source

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

Du sujet: Utiliser des modèles dans le processus de développement à 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 les l’architecture de votre système, analysez le code et assurez-vous 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 » ? à https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489

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

Le code buggy est une chose.Si on les laisse dériver en aval, des erreurs de conception peuvent très gonflé et laid en effet.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 visualisation.Si, par exemple, ITIL V3 (assez simple au fond) 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 en plusieurs tomes aux proportions véritablement bibliques, engendrant toute une industrie, des coûts époustouflants et un choc catatonique généralisé.

Je vois des diagrammes de séquence et des diagrammes d'activités 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 créer des diagrammes de cas d'utilisation, mais je n'ai pas rencontré beaucoup de personnes qui pensent qu'ils sont utiles.

Je me suis souvent demandé si Rational Rose était un bon exemple du type d'applications que l'on obtient grâce à 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é aux plus grands.

En fait, peu importe ce que vous utilisez, il vous suffit de garder deux choses à l’esprit :

Vous voulez une sorte de planification architecturale
Vous voulez être sûr que tous les membres de l'équipe utilisent réellement la même technologie pour la planification du projet.

Donc UML c'est juste ça :Une norme sur la façon dont vous planifiez vos projets.Si vous embauchez de nouvelles personnes, elles sont plus susceptibles de connaître les normes existantes - que ce soit UML, Flowchard, Nassi-Schneiderman, etc. - plutôt que vos éléments internes existants.

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

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

Réfléchir sur la manière dont un logiciel devrait fonctionner.Cela facilite la communication de ce que vous pensez.
Documenter l'architecture d'un système, ses modèles et les principales relations de ses classes.Cela aide lorsque quelqu'un entre dans votre équipe, lorsque vous partez et que vous voulez vous assurer que votre successeur le comprendra, et lorsque 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 que celles mentionnées ci-dessus

Je suis seulement en désaccord avec Michael quand il dit ça utiliser UML pour un seul développeur et/ou un simple projet logiciel semble excessif à lui.Je l'ai utilisé sur mes petits projets personnels, et les documenter en utilisant UML m'a fait gagner beaucoup de temps lorsque j'y suis revenu sept mois plus tard et que j'avais complètement oublié comment j'avais construit et assemblé toutes ces classes.

Je crois qu’il peut y avoir un moyen d’utiliser les cas d’utilisation du poisson, du cerf-volant et du niveau de la mer UML de style Cockburn, tels que décrits par Fowler dans son livre « UML Distilled ». Mon idée était d’utiliser les cas d’utilisation de Cockburn comme aide à la lisibilité du code.

J’ai donc fait une expérience et il y a un article ici à ce sujet avec le Tag « UML » ou « FOWLER ». C’était une idée simple pour c#.Trouvez un moyen d'intégrer les cas d'utilisation de Cockburn dans les espaces de noms des constructions de programmation (tels que 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 que d'autres la vérifient.Cela pourrait être utile pour les programmes simples qui nécessitent une sorte de langage pseudo-spécifique au domaine qui peut exister en plein milieu du code C# sans aucune extension de langage.

Veuillez consulter l'article si vous êtes intéressé.Aller ici.

L'un des problèmes que j'ai avec UML est la compréhensibilité de la spécification.Lorsque j’essaie de vraiment comprendre la sémantique d’un diagramme particulier, je me perds vite dans le dédale des méta-modèles et 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, l’objectif n’est pas atteint.

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 suffisamment mature pour se suffire à elle-même.

Venant d'un étudiant, je trouve qu'UML a très peu d'utilité.Je trouve ironique que les PROGAMERS n'aient pas encore développé un 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 capable d'extraire des éléments de données, de rechercher des définitions et des réponses produit suffisantes pour que tout le monde puisse les consulter, grands ou petits, et comprendre le programme.Cela le maintiendrait également à 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 grandit.Si vous avez un projet de longue durée, il est préférable de tout documenter en UML.

UML semble convenir aux grands projets impliquant de grandes équipes de personnes.Cependant, j'ai travaillé dans de petites équipes où la communication est meilleure.

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

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 pointillée ou un point final de cercle - n'est pas aussi nécessaire, mais reste utile.

Je pense qu'UML est utile simplement parce qu'il amène les gens à réfléchir aux relations entre leurs classes.C’est un bon point de départ pour 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 en fonction de la situation dans laquelle travaille l'équipe de développement.

UML est utile de deux manières :

Côté technique :beaucoup de gens (manager et certains 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 le miroir des exigences du client qui sont inexactes :si vous codez sans UML, vous pourrez peut-être trouver un bug dans require après de nombreuses heures de travail.Les schémas UML vous permettent de trouver les éventuels points de controverse et de les résoudre avant le codage =>aider votre planification.

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

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

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

UML non merci.

UML est définitivement 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 UML car il est connecté à votre code, c'est-à-dire que lorsque vous mettez à jour les 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 plaisir de le faire.

UML a définitivement sa place dans l'industrie.Imaginez que vous créez 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 entre les personnes.Le tableau blanc est meilleur.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow