Discussion :

[inconnu652000]

Developpeur depuis de nombreuses années, en service integré ou en SSII en PME/PMI, je n'ai jamais vu un projet integralement UML. J'entend par intégral, de l'analyse à la génération du code (au moins les carcasses).

Dans 90% des cas d'usages, cela se borne à la realisation de MCD, le plus souvent parce que cela permet de déterminer la nature des relations des tables. Dans d'autres cas, à un usage un peu plus étendu, sur la partie conception générale, la plupart du temps pour donner le change (du style, nous aussi on fait de l'UML), et/ou pour être dans la tendance du moment. La partie conception detaillée restant proche du langage naturel.

J'ai l'impression que l'usage d'UML en France en tous cas, dans le monde des PME/PMI relève plus du phénomene marketo/mode que du besoin réel. Même si je ne doute pas de l'usage d'UML sur les (trés ?) gros projet, je mettrais UML dans la même bassine que SOAP, CORBA, et dans une certaine limite JAVA (pour les applications clientes). Je sais que je viens de mélanger torchons et serviettes, UML étant un language de modélisation plus qu'une technologie.

Je ne souhaite pas lancer un troll, juste profiter de ce forum pour avoir d'autres points de vue de développeur.

Est-ce que vous avez déja utilisé UML, de A à Z dans des projets moyens ?

D'autres part, je cherche justement, ce type de dossier. Des analyses de systemes d'informations avec UML dans des contextes de gestions 'simple'. Gestion commerciale, gestion des achats, ou autres. J'ai beau chercher sur google, et je n'ai rien trouvé.

Pour finir. Je suis un developpeur qui a 18 ans d'expérience mais pas de diplômes. Je souhaitais profiter d'une période de chômage pour user mes jeans sur les bancs d'école mais je m'aperçois que l'UML est aujourd'hui omniprésent dans la plupart des cours liés à l'analyse, que ce soit au niveau de formations privés comme des formations publiques type CNAM, AFPA.

La question que je me pose, est-ce que ca vaut le coup d'apprendre l'UML si finalement son application dans le millieu du travail est rare.

Je l'ai utiliser dans le cadre d'une rétro-conception d'un existant java en faisant ceci :

1. Détection avec le client des cas d'utilisation

2. Détection du scénario nominal pour chaque "use case" en testant l'appli

3. Détection des scénarii avec erreurs ou alternatifs possibles.

4. Ecriture de diagrammes de séquences faisant intervenir uniquement les messages "importants" pour chaque scénario.

Je pense qu'UML peut intervenir a différents niveaux et a différents degré durant la conception. Cette documentation avait pour objectif de permettre aux développeurs d'intervenir plus rapidement dans le codepour corriger bug ou coder une évolution.

[el muchacho]

J'ai lu aussi que certains trouvent UML lourd. J'ai du mal à comprendre pourquoi vous avez ce ressenti : lourd par rapport à quoi ? Je préfère cent fois lire un diagramme de classes que du code source, même si c'est mon propre code et même si je dois passer 2h à faire le diagramme ! Maintenant, c'est peut être RUP que vous trouvez lourd... En ce cas je compare à Merise, qui n'est pas trop léger non plus

Le problème, c'est que l'usage d'UML mène parfois à un anti-pattern nommé "big design up front", autrement dit une architecture assez statique, voire monolithique. Pourquoi ? Je ne sais pas, mais je l'ai expérimenté, et c'est pas drôle.
Un truc que j'aurais codé de façon bcp plus souple et plus rapidement, on me l'a imposé en UML complet (avec quelques requis d'architecture assez ridicules, il faut bien le dire), et le résultat fonctionnait, mais était assez risible, lourd et moche. On devait faire le diagramme des classes et le diagramme de séquence détaillé pour chacun des use cases. Personnellement, je trouve curieusement l'exercice très difficile, et quand le chef me demande pourquoi je trouve ça difficile, j'ai du mal à l'expliquer.

Quand je code, les besoins sont incrémentaux. Comme c'est incrémental, je pratique le KISS ("Keep It Simple Stupid") sans le savoir (enfin si, quand même un peu), donc je code au plus simple, et de temps en temps, je refactorise quand je rajoute des fonctionnalités ou que je veux introduire un design pattern.
Avec UML, et si on suit le RUP, le processus n'est pas suffisamment incrémental, on a peu d'étapes, donc on crée le modèle quasi complet du produit final. Et c'est là que le KISS ne s'applique plus. D'où p-ê le résultat monolithique final. De plus, quand on code, le compilateur nous aide, ce qui n'est pas trop le cas de l'outil UML. Enfin, certains design patterns ne sont pas faciles à exprimer en UML, je trouve, alors que son codage, on le connait quasiment par coeur.

[hed62]

Je comprend ce que tu veux dire. Je ne peux que te conseiller XP
Cette méthode est beaucoup plus agile que RUP. Mais le plus dur reste à convaincre l'équipe de management.

Pour bien se former : Cours et tutoriels pour apprendre UML et : Cours complet pour apprendre UML 2.0, une série de tutoriels par Laurent Audibert

[lildadou]

Je me permet de déterrer ce topic. Je vais y contribuer en réalisant un état de l'art du point de vue de la communauté scientifique et à partir des précédentes contributions. Mes références principales seront les articles

1. Petre, M. (2013). UML in practice. 35th International Conference on Software Engineering. San Francisco, CA, USA.
2. Dobing, B., & Parsons, J. (2006). How UML is used. Communications of the ACM, 49(5), 109–113. doi:10.1145/1125944.1125949
3. Forward, A., & Lethbridge, T. (2010). Perceptions of software modeling: a survey of software practitioners. 5th workshop from code centric to model …. Retrieved from https://www.site.uottawa.ca/~tcl/gra...Lethbridge.doc

Nous allons commencer cet état de l'art par le rayonnement de UML. En effet, UML est un langage de modélisation graphique qui profite d'une grande :
- popularité croissante (40% des concepteurs déclaraient utiliser UML en 2005, 50% en 2010),
- attention scientifique (+ de 5400 articles scientifiques sur UML moins de 10 ans après son existence)
- et attention commerciale (30 éditeurs recensés lors d'une brève recherche, approche MDE mise en avant etc).
UML, même s'il fait l'objet de nombreuses critiques, garde donc une bonne vitalité.

Chez les concepteurs, c'est sans grande surprise que les 3 diagrammes les plus utilisés sont (dans l'ordre): de classes (à 80%!), de cas d'utilisation (accompagné des scénarios) et de séquence. Mon avis d'ingénieur est que le diagramme de classe est extrêmement efficace pour représenter les parties statiques d'un logiciel et le diagramme de séquence permet de montrer les parties dynamiques. Ils sont complémentaires et permettent de couvrir la plus part des aspects d'un système. Le diagramme de séquence me semble être un raffinement des diagrammes des cas d'utilisations. Les diagrammes de cas d'utilisations sont créer au tout début pour communiquer avec le client et bien analyser le problème.

Les clients sont, quand à eux, plus friands des diagrammes de cas (80%), des scénarios de cas et des diagrammes d'activité/séquence (50%). Il s'agit des diagrammes ayant la plus grande abstractions et reflète aussi la préoccupation principale du client: Comment vais-je interagir avec le logiciel censé répondre à mes besoins?

L'attractivité de ces différents type de diagramme semble être la même que ce qui a été exprimé dans ce topic. J'ai souvent lu que UML était utilisé pour communiquer avec le client et avec les autres développeurs (notamment pour de la maintenance). D'après des études scientifiques, communiquer avec d'autres est la première qualité d'UML.


Les pires défauts d'UML, selon la communauté scientifique sont:
- le manque de synchronisation code-modèle. Quand on effectue de la maintenance sur un système, il faut mettre à jour le modèle ou sinon il finit par ne plus refléter le système.
- un langage complexe. 50% des analystes-programmeurs avouent ne pas "bien comprendre" UML. Cette déclaration est à relativiser dans la mesure où très peu de diagrammes sont utilisés.
- des éditeurs trop lourds. Les études n'expliquent pas ce que ça signifie. En tout cas, la majorité des personnes qui utilisent UML le font sur papier/tableau. Si une personne fait un diagramme avec logiciel, très souvent c'est après l'avoir fait sur papier/tableau. Pour finir, si une personne fait un diagramme avec logiciel c'est souvent avec un logiciel de dessin (Vision, Dia, lucidchart etc). Au final, les gens veulent des diagrammes mais pas des modèles!

J'ai aussi lu dans ce topic, que les diagrammes ne soient pas dans le code, au contraire des commentaire/documentation. Ou encore, que la modélisation était une activité qui empêchait une approche incrémentale.


Pour conclure, UML semble être un langage efficace qui apporte quelque chose en plus à la documentation écrite. C'est probablement, le fait que les diagrammes soient très rapides à lire et efficace pour trouver une information. Cependant, pour rester rapide et efficace, un diagramme ne peut contenir tout les détails. UML ne se substitue donc pas à la documentation écrite. Par contre, UML échoue dans son rôle de modèle puisque les gens ne l'utilisent pas comme tel (évitement des éditeurs de modèles, peu de génération de code).

Quelqu'un pourrait-il illustrer le fait que les éditeurs UML soit "lourds" à utiliser? Qu'est ce qu'il faudrait faire pour que UML soit utilisé comme modèle et pas que comme notation?

Autre question, est-ce qu'il vous arrive de réutiliser des diagrammes UML existants, d'avoir des "diagrammes-type" prêt à l'emploi ou encore de faire du copier-coller depuis de l'existent? Ou de façon plus synthétique: quand on code, on réutilise souvent. Est-ce la même chose pour l'UML?