Les défauts d’UML (formellement)

Ce topic est ouvert pour discuter des défauts d’UML, mais pas n’importe comment. Le plus simple pour expliquer ce que signifie « pas n’importe comment », est d’expliquer ce qui ne va pas avec les critiques habituelles : répéter un même argument à l’identique 10 milles fois, ne change rien à cet argument et ne le rend pas plus justifié qu’un autre qui n’aura été dit qu’une seule fois. Je dis ça, parce que bien que je trouve qu’UML a beaucoup de défauts, je trouve dans le même temps qu’il y a un biais par la représentativité, dans les critiques qui en sont faite. La représentativité, c’est une chose, la raison, c’en est une autre.

Par exemple une critique qui revient souvent, est que « c’est un truc chiant inventé par des gens qui veulent tout étudier avant, alors que moi je veux réaliser tout de suite, c’est mieux ». Il y a un biais ici, les gens qui préfèrent étudier ou représenter les caractéristiques, avant de réaliser étant bien moins nombreux que les gens qui veulent réaliser tout de suite, et ce n’est pas parce que cet argument est répété des milliers de fois, qu’il est plus justifié qu’il ne l’est. Bref, ce sujet est ouvert pour faire des critiques d’UML, formellement, et non pas sur la base de qui crie le plus fort ou de quelle critique remporte le plus de voix ; parce que du constat qu’une critique remporte 1000 fois plus de voix qu’une autre, on ne peut en conclure formellement que… ben seulement que cette critique remporte 1000 fois plus de voix qu’une autre, qu’elle est plus populaire, et rien d’autre. Comme ce n’est pas toujours la chose la plus intéressante à savoir ou à conclure (sauf si vous devez faire adopter UML quelque part), même si c’est aussi important au regard d’autres préoccupations, il faudra éviter ce genre de biais ici. Si nécessaire, un autre sujet sera ouvert, plus dans le genre « vote » ou « sondage » ou « expression libre », parce que évidemment, cette dimension existe aussi, mais c’est seulement qu’il ne faut pas tout mélanger.

Voilà, le sujet est juste ouvert pour l’instant. Je repasse plus tard pour essayer de l’alimenter, en espérant que d’ici là, il intéressera quelqu’un(e) (ne pas hésiter à s’inscrire sur le forum pour ça).

Un défaut de la notation d’UML à mon avis, c’est la trop grande importance donnée à la notation graphique, ce qui la rend facilement illisible. Il y a d’autre caractéristiques qui rendent difficile la lecture des diagrammes UML, c’est juste que je voulais seulement souligner ce point, par opposition à HOOD.



HOOD n’est pas une notation, c’est une méthode et une notation (UML, lui, n’est pas une méthode, seulement une notation), et sa notation est moins graphiquement chargée et utilise le texte quand le texte convient mieux.

Cette utilité qu’il y a équilibrer notation graphique et textuelle, est au moins partagée par quelques gens :

3. Overview of HOOD (adalog.fr)



En savoir plus sur HOOD :

• HOOD — An Industrial Approach for Software Design (adalog.fr)
• A Survey of Object-Oriented Methods (cs.byu.edu), dans la section “1.3 HOOD [Hood93]”

Un document sur la migration de HOOD vers UML, qui peut être intéressant pour le sujet des différences et similitudes entre les deux :

From HOOD to UML: A Smooth Migration Path (harvard.edu).

Pour l’obtenir en PDF, plus commode que cette version en ligne plutôt mal faite, suivez le lien en haut à droite, nommé “Print this article”, qui n’est en fait pas un lien pour imprimer, mais pour récupérer la version PDF.

La question de la notation trop graphique, a inspiré à des gens de créer une version d’UML textuelle. Chacune de ces gens y est allé de sa propre notation, toutes incompatibles entre elles, et c’est volontairement à cause de cette raison d’être non‑standard, que je n’en mentionnerai aucune, pour ne pas donner de mauvais exemples.

Pourtant si ces gens avaient cherché un peu et/ou avaient bien voulu se donner la volonté d’appliquer un standard, ils/elles auraient put apprendre qu’il existe une notation textuelle standard pour UML. Cette notation s’appelle HUTN, pour “Human‑Usable Textual Notation”. C’est ce que faisait aussi remarquer un blog :

Textual UML (thebootstrap.blogspot.fr). Juin 2004.

Remarquez que le nom ne mentionne pas UML ; c’est que cette notation s’étend au delà et s’applique plus généralement à MOF, “MetaObject Facility”, un cadre sémantique, qui sert de méta‑modèle à UML autant que UML lui sert de méta‑modèle. Comme UML est conforme à MOF, une notation de MOF est mécaniquement également une notation applicable à UML. C’est ainsi que HUTN peut être appliqué à UML, et je crois d’ailleurs a été créé en pensant à UML d’abord, même si la notation n’a, par conception, rien de spécifique à UML.

La spécification officielle peut être consultée ici :

UML Human-Usable Textual Notation — HUTN (omg.org).

Pour aborder concrètement HUTN, il est nécessaire de connaitre les bases d’UML (chapitre 7 et 13 du document spécifiant UML 2.5, ou le document spécifiant l’infrastructure d’UML 2.4), de MOF et XMI (avec un i, pas un L). HUTN est en fait une version textuelle assez humainement lisible de XMI, qui est un format XML (avec un L), certes textuel aussi, mais dont le dialecte XMI n’est pas fait pour être humainement lisible sur la longueur.