UML Sucks.

UML a connu un gros engouement au début des années 2000 mais semble accuser le coup de certaines critiques quant à son efficacité à apporter des solutions réelles aux problèmes que rencontrent les gestionnaires de projets et développeurs. Pourquoi donc ?

UML quoi ? Grossier personnage…

Sucks. En gros, UML ne fait pas l’affaire, pour certains. Mais il convient de décrypter un peu ce « message », pour justement séparer le bon grain de l’ivraie.

Tout d’abord, Big Boss à la rescousse, une (big) donnée qui ne trompe pas. Voici la tendance Google Trends de l’intérêt que manifestent les internautes envers UML via leurs recherches sur le plus grand moteur du monde :

Google Trends UML

Google Trends UML

C’est moche. Pourquoi ai-je donc investi tant d’argent dans ma certification OCUP ? Arf.

Voyons maintenant quelques morceaux choisis, rencontrés ça et là sur le Web.

Guys, let’s admit that UML was a complete failure. People who designed UML never looked at the problem(s) they were supposed to solve. UML should focus at a minimum on “visualizing” code if it can’t be helpful in the design phase. Total waste of people’s time. – Jean-Jacques Dubray, fondateur de xgen.io1

Il est ici question de la cible que veut atteindre UML : outil graphique de visualisation et de communication ou langage de « programmation », tout du moins langage suffisemment formel pour générer du code, gérer la cohérence code/modèles, etc.

Grady Booch, l’un des créateurs d’UML, donne des indications assez claires sur cette perspective :

I never intended UML to become a programming language. — Grady Booch2

OK. Le message est donc clair : espérer faire de la grande machinerie automatique avec UML est un non-sens, l’outil n’est pas fait pour ça.

UML doesn’t address interfaces (or at least poorly addresses them). It seems obsessed with minutiae in a parody of academic distraction. The only time I see UML in my daily development is in technical books and articles, and even then a Visio diagram would usually work better. – Alal Stevens3

Le message est ici : « UML est un truc d’universitaires, c’est moche et ça ne marche que dans les livres ». Il faut bien admettre que certaines facettes d’UML sont un peu obscures (vous vous souvenez de la fiche sur la méta-métamodélisation ?), néanmoins, il ne faut pas jeter le bébé avec l’eau du bain. Nous allons voir par la suite comment tout ceci peut s’agencer pour donner des éléments utiles et utilisables.

Les critiques sont vives, mais…

Ceci étant dit, à l’aube de 2017, on cherche toujours des gens pour faire de l’UML :

Voyons maintenant quels aspects d’UML peuvent concrètement le mener à rebuter les gens, et à rendre les projets qui l’utilisent peu efficaces.

Le mieux est l’ennemi du bien, trop d’UML tue UML

Le mieux est l’ennemi du bien, c’est bien connu.

Le bien, tout d’abord. Si vous suivez cette formation, que vous n’êtes pas encore complètement endormi, et que vous avez de l’expérience dans la conception de logiciels informatique, vous n’êtes pas sans avoir conscience que ne pas modéliser du tout mène quasi inévitablement à la débâcle.

Le mieux est l'ennemi du bien

Alors modélisons, vous dites-vous ! Modélisons le matin, le midi, le soir, la nuit ! Modélisons tout, ne laissons aucune zone d’ombre, bref, faisons au mieux !

Les excès ne sont généralement pas bons, et UML n’est pas l’exception qui confirme la règle !

Bon nombre d’entreprises ont juste abandonné UML pour en avoir trop attendu. Pour en avoir trop voulu. Le mirage du MDA est passé par là, les usines à gaz de la modélisation ont soulagé les bourses, et les modèles non maintenus ont fini en désuétude, sous le tapis du bureau des architectes logiciels éhontés.

Pour être efficace avec UML, il faut vous ranger dans une de ces catégories :

CatégorieCaractéristiques
Les acharnésLes acharnés d’UML parlent UML, vivent UML et font de l’UML tous les jours. Ils écrivent des modèles, les transcrivent en code, utilisent des outils qui leur permettent de garder leur code et leurs modèles synchronisés, et ne laissent aucune partie de leur SI non couverte par les modèles.
Les pragmatiquesLes pragmatiques utilisent UML pour mieux comprendre certains problèmes compliqués, pour communiquer une vision d’un problème ou d’une situation, ou encore pour archiver certaines descriptions essentielles de leur système. Et ils passent à autre chose.

Vous l’aurez compris : on peut réussir dans les deux catégories, mais pas au milieu

D’autre part, le fait de se ranger dans la première catégorie a un coût qui n’est pas négligeable (en matière de temps passé, et d’argent dépensé dans l’outillage…).

Le syndrome du métamodèle

Syndrome du métamodèle

Le syndrome du métamodèle est une des dérives potentielles des utilisateurs acharnés d’UML, mais ne découle pas directement de l’utilisation d’UML (on peut métamodéliser comme un malade avec un autre langage qu’UML…).

Cette pratique se caractérise par une propension à vouloir appréhender tous les problèmes avec un niveau de généricité extrême, à créer des modèles de modèles capables d’être utilisés dans une énorme variété de situations mais… qui ne sont finalement utiles qu’à faire la fortune des marchands de logiciels de modélisation. Hum.

Les composants logiciels produits par des personnes atteintes du syndrome du métamodèle sont en général très complexes, assez peu opérationnels et difficilement maintenables, bien que très léchés du point de vue de l’architecture.

Si vous avez par exemple travaillé avec les EJB et certains frameworks « poids-lourd » de l’écosystème Java dans le passé, vous avez probablement été en contact avec des professionnels infectés. Pas de panique, le syndrome n’est pas contagieux… pour peu que l’on prenne garde de toujours resté focalisé sur l’essentiel : l’efficacité de ce que l’on produit, et son utilité réelle. Les agilistes parlent de business value : la valeur de ce que l’on produit pour le client (ce qui n’empêche pas de soigner la qualité intrinsèque du produit). Et oui, une bonne démarche de modélisation peut aussi être un moyen de maximiser le ROI d’un projet !

The real danger is not that machines will begin to think like men, but that men will begin to think like machines. — Sydney J. Harris

Commentaires