UML et le principe de Pareto

Avec 20% d'UML, vous couvrirez probablement 80% de vos besoins : la loi de Pareto s'applique (presque) partout…

Énoncé du principe de Pareto

Comme beaucoup d’autres domaines, la modélisation UML se voit appliquer le fameux principe de Pareto (contextualisé depuis la loi originelle de Wilfredo Pareto par Joseph Juran).

Le phénomène empirique constaté est donc le suivant : on couvre généralement 80% des besoins de modélisation avec 20% de ce que propose UML. Tout comme les utilisateurs d’un logiciel genre Photoshop n’utilisent souvent que 20% des fonctionnalités du logiciel pour atteindre leurs objectifs…

Vous en doutez ? Écoutez ce qu’en dit lui-même l’un des fondateurs d’UML :

You need about 20% of the UML to do 80% of the kind of design you might want to do in a project (agile or not) but use the UML with a very light touch: use the notation to reason about a system, to communicate your intent to others… and then throw away most of your diagrams. Grady Booch

20%, mais lesquels ?

Il est clair que la majorité des concepteurs, analystes fonctionnels ou encore développeurs qui utilisent UML se passent rarement de certains artefacts.

Parmi eux, considérez les diagrammes suivants :

  • Diagramme de cas d’utilisation : le fameux diagramme qui est à la base de toute démarche « guidée par les cas d’utilisation », permettant de lister les fonctionnalités du système et les acteurs (rôles) qui y ont accès.
  • Diagramme de classes : le plus important des diagrammes structurels, permettant de poser les bases statiques du système en représentant les concepts en jeu (classes, attributs…) et les associations entre eux (généralisation, agrégation, composition…). Ils sont avantageusement complétés par les diagrammes d’objets, qui permettent de valider une modélisation en l’éprouvant sur des exemples (instances des classes et des associations).
  • Diagramme d’activité : le diagramme de modélisation comportementale le plus avancé (extension du diagramme d’états-transitions), permettant de rendre compte de la dynamique interne d’une activité en en détaillant de manière très fine des processus métiers ou techniques complexes.
  • Diagramme de composants : ce diagramme permettant de maintenir une cartographie rigoureuse des composants (back offices, API, back ends, front offices, etc.) d’un système d’information, il revêt une important particulière lorsqu’il est question de maintenir une suite logicielle composée de multiples élément qui cohabitent et sont inter-dépendants.

UML et le principe de Paerto

Au delà de ces diagrammes fondamentaux, certains ne se passent pas des diagrammes de séquence (qui expriment au mieux leur potentiel sur un périmètre technique, au niveau des appels de méthodes de classes, parfois même des paramètres de ces méthodes !). Ces diagrammes d’interaction sont donc plus adaptés pour la description de modèles proches de l’implémentation qu’à un niveau fonctionnel.

Certains autres types de diagrammes apportent certaines spécificités, mais se rapportent aux diagrammes mentionnés supra. Par exemple, les diagrammes de communication apportent une sorte de représentation simplifiée du diagramme de séquence, et expriment des choses proches du diagramme d’activité ! Les diagrammes de structure composite permettent quant à eux de lever certains doutes pouvant persister après représentation des classes et leur instanciation sous forme de diagramme d’objet.

Conclusion

Vous l’aurez compris : être opérationnel et efficace avec UML n’implique pas nécessairement de maîtriser l’ensemble des diagrammes que le langage propose.

Mieux vaut privilégier une bonne maîtrise de quelques diagrammes fondamentaux, qui permettront à eux seuls de couvrir une énorme majorité des cas d’utilisation (les bien nommés…) que vous ferez d’UML !

Commentaires