Quels diagrammes UML sont encore largement utilisés?
J'enseigne le génie logiciel au premier cycle et j'ai une question pour les praticiens UML.
La plupart des manuels de génie logiciel prennent un effort sérieux pour couvrir les diagrammes UML. Mais d'un autre côté, j'ai entendu de nombreux diplômés dire que UML ne semble plus être utilisé dans les tranchées.
Quels diagrammes UML sont encore largement utilisés dans la pratique professionnelle, et pourquoi? Y a-t-il des diagrammes qui ne sont plus utilisés et pourquoi?
N.B: Afin d'éviter les débats et discussions basés sur l'opinion, veuillez illustrer votre réponse avec des éléments factuels et objectifs (si possible, vérifiables) ou des observations neutres sur l'expérience personnelle
Parmi les nombreux diagrammes proposés par UML, les diagrammes de classes et les diagrammes de séquence sont encore largement utilisés, certainement suivis par les diagrammes d'état:
- ils peuvent facilement être utilisés sur des tableaux blancs pour élaborer et discuter de la conception avant de sauter dans le code
- ils permettent de transmettre très rapidement un aperçu que le code à lui seul ne donne pas si facilement, et il n'y a pas de substitut viable.
Je pense que les cas d'utilisation dans la vie réelle sont utilisés de manière plus occasionnelle. Dans les grands projets, avec plusieurs centaines de cas d'utilisation, les diagrammes sont difficiles à dessiner et offrent peu d'avantages par rapport à une forme tabulaire. BPMN pour la conception de processus, mappage d'histoires utilisateur , ou la décomposition tabulaire d'événements dans un style Cockburn sont beaucoup plus utilisé. Pourquoi ? Parce qu'ils sont plus facilement partagés avec les utilisateurs professionnels pour déterminer efficacement les exigences.
Je suis sûr que ce sont des endroits où UML est encore largement et systématiquement utilisé. Je n'imagine pas que logiciel aérospatial ou que les systèmes de contrôle des centrales nucléaires soient produits sans l'ensemble complet de la documentation UML. Mais je crois que c'est plus l'exception que la règle.
Je me sens confirmé dans cette déclaration en regardant dans les librairies. Il y a quelques années, vous pouviez trouver de nombreux livres sur UML 2.0. De nos jours, si vous recherchez UML 2.5, le choix est plutôt restreint. Pire: de nombreux auteurs ne font même pas l'effort de réviser leurs anciens livres pour les garder à jour (exemple: Fowler's Nice " ML distilled " introduction qui date toujours de 2003 avec UML 2.0 et idem pour Ambler "Eléments de style UML 2.0"!).
Je ne pense pas que cette tendance à la baisse va changer, en regardant la généralisation de agile et sa promotion de "logiciel de travail sur une documentation complète".
En fin de compte, je dirais de façon très provocante que les méthodes de modélisation semblent suivre un schéma darwiniste: seule la technique de diagramme la plus appropriée survivra, celles qui offrent un net avantage sur les approches informelles (par exemple l'illustration de la serviette) et le code détaillé (par exemple pourquoi dessiner un diagramme d'activité A1, alors que le code correspondant pourrait tenir sur une feuille A4?) ;-)
D'un autre côté, j'ai entendu de nombreux diplômés dire que UML ne semble plus être utilisé dans les tranchées.
Ils sont tous utilisés dans la pratique. Mais tout le monde ne les utilise pas. Certaines personnes évitent complètement la conception et passent directement au codage. Vous ne pouvez pas vous fier à des preuves anecdotiques pour savoir ce que "tout le monde" fait.
Des outils comme UML fonctionnent mieux si vous utilisez lorsqu'ils ajoutent de la valeur; par exemple.
- pour les grands projets
- pour les parties compliquées d'un projet
- lorsque la conception du projet nécessite la contribution de plusieurs personnes
Les créer juste pour le plaisir de les faire (ou parce que le processus le dit) n'est pas productif. La meilleure pratique consiste à être sélectif sur ce que vous schématisez et sur les types que vous utilisez. Utilisez UML quand et où cela vous aide ... et cela inclut la sélection des types de diagrammes UML que vous utilisez.
Aussi ... UML a été principalement conçu comme un outil de conception. Il n'est pas aussi efficace (de nos jours) qu'un outil de documentation. Les IDE typiques vous aident à visualiser de nombreux aspects d'une structure de base de code à la volée. C'est souvent mieux que de s'appuyer sur des diagrammes UML qui peuvent être devenus obsolètes/inexacts.
UML est toujours utilisé dans les tranchées. Mais, comme toujours, les gens en utilisent un sous-ensemble. Quel sous-ensemble est soumis aux problèmes actuels.
UML est disponible en plusieurs versions. Mais, comme toujours, les gens utilisent ses symboles de manière informelle et inconstante.
UML est la façon dont nous comprenons la plupart des livres de modèles. C'est aussi l'une des façons dont nous communiquons sur le tableau blanc. Ce n'est pas parti. Mais il ne sera jamais utilisé aussi formellement que du code.
Plutôt que de produire des étudiants capables de corriger n'importe quel diagramme UML pour se conformer à ML version 2.5 , ou quoi que ce soit de plus récent, produisez des étudiants qui peuvent comprendre ce que le diagramme essaie de communiquer même s'il n'est pas entièrement cohérent avec une version UML particulière, car c'est ainsi que UML est utilisé dans les tranchées. Il vient dans des dialectes locaux étranges, mélangés à d'autres systèmes, et parfois nous créons juste nos propres symboles.
Apprenez-leur qu'il est normal de demander ce que les choses signifient. Ne leur apprenez pas à corriger les autres qui enfreignent certaines règles imaginaires. Nous essayons juste de communiquer ici.
La meilleure utilisation que j'ai vue de l'uml est de laisser un nouveau programmeur nous montrer son plan pour résoudre un problème. Il nous a rapidement montré les parties du système qu'ils ont négligées ou dont ils ne se rendaient pas compte qu'elles existaient.
J'ai également travaillé dans des endroits qui nécessitaient UML même lorsqu'ils n'étaient pas nécessaires. Nous utilisions toujours le même modèle, donc c'était juste une formalité. Nous sommes arrivés au point que nous venons de faire des photos de nouveaux noms dans de vieux diagrammes. N'encouragez pas ce type d'utilisation.
Mais je pense que nous savons tous qu'il y a une différence entre la tête de flèche normale et la tête de flèche ouverte. Droite?
Je vais être précis en fonction de mon expérience: - Diagramme de déploiement - Diagramme de séquence - Diagramme de classe Ces trois sont les plus utilisés dans tout projet, ils fournissent une réelle valeur de communication avec l'équipe à différents niveaux.