[MODEL 2012] UML, un langage pour les amener tous et dans les ténèbres les lier

Qui n’a jamais entendu cette célèbre phrase tirée d’Hamlet : “To be, or not to be, that is the question”. Ce passage hautement célèbre de la littérature anglaise n’est cependant que le début d’une longue et magnifique tirade traitant de la vie, de la mort, et du courage des hommes qui affronteront ces forces tout au long de leur existence [1]. Mais ce courage a ses limites, et peu d’entre nous ont lu la tirade dans son ensemble, préférant les histoires de vampires du crépuscule aux lourdes tournures de Shakespeare.

Heureusement, des outils existent pour transmettre et simplifier l’information, comme UML (Unified Modeling Language).
UML est un langage de modélisation graphique basé sur des pictogrammes [2], respectant des standards définis par l’OMG (Object Management Group ou Oh My God pour les intimes), et destiné à représenter des spécifications, des architectures ou des concepts sous une forme visuelle plus facile à appréhender pour l’esprit humain.

N’ayant pu présenter comme prévu la modélisation UML d’un trombone à coulisse à ma grand-mère pour étudier sa réaction (cf l’article précédent si vous ne l’avez pas encore lu [3]), je vous propose aujourd’hui de découvrir la représentation du discours d’Hamlet avec le même outil.

Source : Victoriya Sklyar – http://www.umljokes.com

Que remarque t-on dès les premiers instants où notre regard se porte sur ce diagramme ? Sa simplicité, sa clarté, et son ergonomie. Cette dernière caractéristique, très importante, fait la force d’UML : tout le monde peut lire un tel diagramme et en comprendre l’essence sans avoir jamais eu de cours sur ce langage.

Mais comment se fait-il, me direz-vous, que ce langage n’ait pas réussi à envahir le monde ? Pourquoi n’avons-nous pas su rassembler ce que Babel avait cassé, par la magie d’un tel outil ? Pourquoi n’enseigne t-on pas la GELOL de facto dès l’enseignement secondaire ?

La raison est bien simple : ce langage est loin d’être parfait, et nous allons maintenant étudier ses défauts (tirés des références [4] et [5]).

  • Peu de personnes sont capables de rédiger un diagramme UML : tout le monde peut les lire, mais peu ont suffisamment confiance en leurs connaissances pour oser en écrire ;
  • UML est trop complexe : à force d’augmenter le nombre de possibilités offertes par le langage, le nombre d’outils disponibles est devenu trop grand pour l’esprit humain et peu de personnes pensent que le retour sur investissement soit intéressant ;
  • La phase d’analyse n’est que trop rarement approfondie : beaucoup de professionnels passent à côté de la phase d’analyse et préfèrent directement entrer dans le coeur de l’action ;
  • Le niveau d’abstraction proposé par UML n’est pas adapté à un gain de productivité : cette abstraction reste trop orientée architecture logicielle, et un ingénieur travaillant avec UML pensera souvent à la façon d’implémenter son système tout en réalisant son modèle, ce qui est contre-nature ;
  • UML manque de formalisme et ne peut donc pas être transformé en code informatique de façon propre et unique : l’intérêt de tels modèles d’abstraction est de pouvoir les vérifier et tester par des moyens informatiques, avant même de passer à l’implémentation. UML manque de cette fonctionnalité.
Heureusement, UML dispose aussi de grandes qualités, et nous finirons sur une note positive en les énumérant (tiré de la référence [4]) :
  • UML est une norme : ce langage est devenu le standard de facto pour la modélisation des systèmes ;
  • UML dispose d’une large communauté : ce langage est très soutenu par les professionnels, ce qui a permis le développement de nombreux logiciels de modélisation ;
  • UML est flexible : il est facile d’adapter UML à ses besoins et à des domaines spécifiques. Dans le pire des cas, des langages proches d’UML permettent de modéliser des domaines très particuliers.

En conclusion, Unified Modeling Language est un outil intéressant pour des travaux de modélisation basiques, mais l’utilisateur préférera parfois prendre un langage plus spécialisé pour communiquer, ou au contraire développer une solution “maison” que tous ses interlocuteurs seront capables de comprendre.

Comme le disait Paul Ricoeur, “il ne peut y avoir de totalité de la communication”. A chacun de trouver les outils adaptés pour transmettre son message.

[1] : http://fr.wikipedia.org/wiki/Hamlet#To_be_or_not_to_be
[2] : http://fr.wikipedia.org/wiki/Unified_Modeling_Language
[3] : http://veille-techno.blogs.ec-nantes.fr/index.php/2012/10/19/model2012-comparaison-semantique-de-langages-haut-niveau-prelude/
[4] : http://www.blog-nouvelles-technologies.fr/archives/1038/les-raisons-dutiliser-ou-non-luml-dans-vos-phases-de-conception-pour-un-developpeur/
[5] : http://lispy.wordpress.com/2008/10/29/why-uml-fails-to-add-value-to-the-design-and-development-process/

Licence Creative Commons
Comparaison sémantique de langages haut niveau de Maxime Alay-Eddine est mis à disposition selon les termes de la licence Creative Commons Attribution 3.0 non transposé.