UML est-il pratique?

Dans un système suffisamment complexe, il existe des 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’état, les diagrammes d’activité et les diagrammes de séquence.

Il y a beaucoup d’entresockets qui ne jurent que par elles et beaucoup qui les rejettent carrément comme une perte de temps et d’efforts totale.

Il est préférable de ne pas aller trop loin et de penser à ce qui convient le mieux au projet dans lequel vous vous trouvez et de choisir ce qui est applicable et qui a du sens.

Utiliser UML, c’est comme regarder ses pieds en marchant. Cela rend conscient et explicite quelque chose que vous pouvez habituellement faire inconsciemment. Les débutants doivent bien réfléchir à ce qu’ils font, mais un programmeur professionnel sait déjà ce qu’ils font. 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 vient dans six mois et doit se familiariser avec le code? Qu’en est-il de cinq ans à partir du moment où tout le monde travaille actuellement sur le projet?

Il est extrêmement utile d’avoir une documentation de base à la disposition de tous ceux qui rejoindront le projet ultérieurement. Je ne préconise pas des diagrammes UML complets avec des noms et des parameters de méthode (WAY trop difficile à gérer), mais je pense qu’un diagramme de base des composants du système avec leurs relations et leur comportement de base est inestimable. A moins que la conception du système ne change radicalement, cette information ne devrait pas beaucoup changer, même si l’implémentation est modifiée.

J’ai trouvé que la clé de la documentation est la modération. Personne ne va lire 50 pages de diagrammes UML complets avec la documentation de conception sans s’endormir de 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 le système est mis en place.

L’autre cas où j’ai trouvé UML utile, c’est quand un développeur senior est responsable de la conception d’un composant, puis remet la conception à un développeur junior pour l’implémenter.

Utiliser UML, c’est comme regarder ses pieds en marchant. Cela rend conscient et explicite quelque chose que vous pouvez habituellement faire inconsciemment. Les débutants doivent bien réfléchir à ce qu’ils font, mais un programmeur professionnel sait déjà ce qu’ils font. 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.

La seule exception est que vous vous retrouvez dans les bois la nuit sans lampe de poche et qu’il commence à pleuvoir, puis vous devez 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 l’un des nombreux outils que vous pouvez utiliser. D’autres incluent des pseudocodes, des diagrammes d’architecture de haut niveau et des métaphores étranges.

Le workflow et les DFD génériques peuvent être très utiles pour les processus complexes. Tous les autres diagrammes (ESPECIALLY UML) ont, selon mon expérience, été une perte de temps et d’efforts douloureuse.

Je ne suis pas d’accord, UML est utilisé partout – partout où un projet informatique est conçu, UML sera généralement là.

Maintenant, si elle est bien utilisée est une autre affaire.

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

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

L’un des problèmes les plus importants 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 le font bien.

Je qualifierai ma réponse en mentionnant que je n’ai pas d’expérience dans de grands environnements de développement d’entreprise (comme IBM).

La façon dont je vois UML et le processus Rational Unified est que vous ne parlez plus de ce que vous allez faire que de faire ce que vous allez faire.

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

Jetez seulement à mon avis. UML est un excellent outil pour communiquer des idées, le seul problème est lorsque vous stockez et conservez-le, car vous créez essentiellement deux copies de la même information et c’est là que ça souffle généralement. Après la phase initiale d’implémentation, la majeure partie du langage UML doit être générée à partir du code source, sinon sa mise à jour sera très rapide ou nécessitera beaucoup de temps (avec des erreurs manuelles) pour restr à jour.

J’ai co-enseigné un cours de développement de haut niveau mes deux derniers semestres à l’école. Le projet devait être utilisé dans un environnement de production avec des organismes locaux à 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 passé en classe était limité, tout comme le temps passé en dehors de la classe. En tant que tel, nous avons dû effectuer des revues de code à chaque réunion de classe, mais avec 25 étudiants inscrits, le temps d’examen était très court. L’outil que nous avons trouvé le plus précieux dans ces sessions de révision était la DRE, 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 nécessaire pour les créer était donc insignifiant pour les étudiants.

Les diagrammes ont communiqué de très nombreuses informations très rapidement. En ayant un aperçu rapide des conceptions des étudiants, nous pourrions rapidement isoler les zones problématiques dans leur code et effectuer une parsing plus détaillée sur-le-champ.

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

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

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

Étant donné que la liste des utilisations au-dessus de la publication par Pascal ne suffit pas, cela ne concerne que la création du diagramme. Un projet pourrait bénéficier d’UML si l’un des facteurs ci-dessus est un facteur de réussite critique ou s’il s’agit d’une zone à problèmes nécessitant une solution standardisée.

La discussion devrait se développer à partir de la manière dont UML peut être trop puissant ou appliqué à de petits projets pour discuter de la pertinence du langage UML ou de l’amélioration du produit / de la solution. Il existe des situations où UML pour un développeur peut également détecter, comme Pattern Application ou Code Generation.

UML travaille pour moi depuis des années. Quand j’ai commencé, je lisais UML Distilled de Fowler où il disait: “faites assez de modélisation / architecture / etc.” Utilisez simplement ce dont vous avez besoin !

Je pense que l’UML est une idée utile. Je pense que la spécification 2.0 a rendu ce qui était autrefois une spécification claire, un peu lourd et encombrant. Je suis d’accord avec l’édition des chronogrammes, car ils ont rempli un vide …

Apprendre à utiliser le langage 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 a 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. Poséidon – Outil décent avec un bon rapport qualité-prix

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

Du sharepoint vue de l’ingénieur QA, les diagrammes UML indiquent les failles potentielles de la logique et de la pensée. Facilite mon travail 🙂

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 à 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, à parsingr le code et à vous assurer que votre code répond aux exigences.

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

Comment apprendre «bonne conception / architecture logicielle»? sur https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Bien que cette discussion ait longtemps été inactive, j’ai quelques points importants à append.

Le code de buggy est une chose. Laissées à la dérive en aval, les erreurs de conception peuvent devenir très lourdes et laides. UML, cependant, s’auto-valide. J’entends par là que, en vous permettant d’explorer vos modèles dans des dimensions multiples, mathématiquement fermées et vérifiées 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) avait été communiquée sous forme de diagrammes UML, il aurait pu être publié sur quelques dizaines de dépliants A3. Au lieu de cela, il est apparu dans plusieurs tomes de proportions vraiment bibliques, engendrant une indussortinge entière, 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é assez souvent utilisés. Je travaille beaucoup avec les systèmes “temps réel” et les systèmes intégré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é beaucoup de gens qui pensent qu’ils sont précieux.

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

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

Essentiellement, peu importe ce que vous utilisez, il vous suffit de garder deux choses en tête:

• Vous voulez une sorte de planification de l’architecture
• Vous voulez être sûr que tous les membres de l’équipe utilisent la même technologie pour la planification de projet.

UML n’est donc que cela: un standard sur la façon dont vous planifiez vos projets. Si vous embauchez de nouvelles personnes, il est plus probable que vous sachiez quelle norme existe – que ce soit UML, Flowchard, Nassi-Schneiderman, etc.

L’utilisation d’UML pour un seul développeur et / ou un simple projet logiciel me semble exagéré, mais lorsque je travaille dans une équipe plus importante, je souhaiterais sans aucun doute disposer d’un logiciel de planification standard.

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 relations principales 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 finirez par oublier à quoi était destiné ce petit groupe.
• Documenter tout motif architectural que vous utilisez sur tous vos systèmes, pour les mêmes raisons que le point ci-dessus

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

Je crois qu’il y a peut-être un moyen d’utiliser les cas d’utilisation des poissons, des cerfs-volants et du niveau de la mer dans le style UML de Cockburn, comme l’a décrit Fowler dans son livre “UML Distilled”. Mon idée était d’utiliser les cas d’utilisation de Cockburn comme aide pour la lisibilité du code.

J’ai donc fait une expérience et il y a un post à ce sujet avec le tag “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 (tels que les espaces de noms de classes et de classes internes ou en utilisant les espaces de noms pour les énumérations). Je crois que cela pourrait être une technique simple et viable, mais que vous avez encore des questions et que vous avez besoin d’autres pour le vérifier. Cela peut être utile pour des programmes simples nécessitant un type de langage spécifique à un pseudo-domaine qui peut exister au milieu du code c # sans aucune extension de langage.

S’il vous plaît vérifier le post si vous êtes intéressé. Allez ici

L’un des problèmes que j’ai avec UML est la compréhension de la spécification. Lorsque j’essaie vraiment de 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, cela échoue à l’objective.

Aussi, 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 suffisamment mature pour se prendre en charge.

Venant d’un élève, je trouve que UML est très peu utilisé. Je trouve ironique que PROGAMERS n’ait 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 chercher des définitions et des réponses de produit suffisantes pour que tout le monde puisse les voir, grands ou petits, et comprendre le programme. Cela permettrait également de le tenir à jour car il prendrait les informations directement à partir du code pour produire les informations.

UML est utilisé dès que vous représentez une classe avec ses champs et méthodes, bien que ce soit juste 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.

En ce qui me concerne, je trouve très gênant l’absence de schéma UML pour les projets Opensource. Prenez quelque chose comme WordPress, vous avez juste un schéma de firebase database, rien d’autre. Vous devez vous promener autour de l’API du codex pour essayer d’avoir une vue d’ensemble.

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

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

L’utilisation de diagrammes UML-esque est 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 écrire 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 codes significatifs est une compétence nécessaire pour tout ingénieur logiciel qui développe un nouveau code ou tente de comprendre un code existant.

Connaître les spécificités de UML – quand utiliser une ligne pointillée, ou un point final de cercle – n’est pas tout à fait nécessaire, mais il est toujours bon d’avoir.

Je crois que UML est utile pour le simple fait que cela amène les gens à réfléchir aux relations entre leurs classes. C’est un bon sharepoint départ pour commencer à penser à de telles relations, mais ce n’est certainement pas une solution pour tout le monde.

Je pense que l’utilisation de UML est subjective par rapport à la situation dans laquelle travaille l’équipe de développement.

UML est utile de deux manières:

• Côté technique: beaucoup de personnes (manager et analyste fonctionnel) pensent que 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 parsings vous obligent à bien comprendre les requêtes du client;

• Côté gestion: les diagrammes UMl sont un miroir des exigences du client qui est inexact: si vous codez sans UML, vous pouvez peut-être trouver un bogue après de nombreuses heures de travail. Les diagrammes UML vous permettent de trouver les points controversés possibles et de résoudre avant le codage => aider votre planification.

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

Si vous êtes dans le groupe linkedin SYSTEMS ENGINEERS , consultez mon ancienne discussion .

A la fin, UML n’existe qu’à cause de RUP. Avons-nous besoin d’UML ou de l’un de ses éléments associés 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 pas de merci.

UML est vraiment utile tout comme le junit est essentiel. Tout dépend de la façon dont vous vendez l’idée. Votre programme fonctionnera sans UML comme s’il fonctionnait sans tests unitaires. Cela dit, vous devez créer do UML car il est connecté à votre code, c’est-à-dire que lorsque vous mettez à jour des diagrammes UML, il met à jour votre code ou génère automatiquement le code UML. Ne fais pas juste pour le faire.

UML a définitivement sa place dans l’indussortinge. 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.