Rubrique « Info »

Cher Professeur Sévère :

     Votre assistant pour le cours de base OO m'a redirigé vers vous pour ce qui concerne mon D- [(6/20 ?)] que j'ai reçu pour ma rédaction sur "Une évaluation de la proposition de Langage de Modélisation Unifié (LMU)" [enfin... "Unified Modeling Language (UML) en anglais, quoi !]. J'espère que vous considérerez la possibilité de changer cette note en mieux (un D peut-être), surtout que cela serait un vrai coup porté à ma moyenne, déjà pas très brillante après ce "0" que vous m'aviez donné lors de votre dernière session. (Vous vous souvenez peut-être que dans l'examen final, j'avais écris : "Il y a peut-être autre chose dans la vie que les tranches de jambons et Java". Je réalise maintenant à quel point ce commentaire était déplacé et je m'excuse sincèrement si j'ai heurté quelqu'un).

    Je comprends bien sûr les raisons de ce D- et j'apprécie votre clémence à mon égard. Comme l'assistant me l'a fait remarqué, il n'y avait rien de positif sur UML dans mon papier ! Cela ne peut sûrement pas être correct. Tout le monde dit que UML est une réelle avancée dans l'univers de la conception de logiciel, et qui suis-je pour mettre en doute cela ? C'est pourquoi je ne vous demanderai pas de modifier ma note simplement pour améliorer ma moyenne, même si j'espère que vous prendrez en considération combien cela est désagréable de perdre sa bourse d'élève méritoire (LIEN) , sans compter ses petites amies et compagnie. Non. Je reconnais que j'étais dans l'erreur et je veux me racheter. Il doit y avoir quelque chose de bien à dire sur UML.

    Et je vous assure que je retiendrai ma leçon : positiver. Quelque soit le sujet, il est toujours possible de lui donner un éclairage favorable. Le journal de ce matin a même publié un qualificatif qui pourrait être interprété comme non désagréable concernant Newt Gingrich ! [et c'est vrai qu'il règne quelques allégations sulfureuses autours de cette homme de l'année 1995 selon le Times et un influent Speaker of the House of Representative de 1995 à 1999] Pourquoi pas UML ?

    J'ai donc suivi les conseils de votre assistant. Par exemple, il se pourrait qu'il y ait des choses sympathiques à dire au sujet de la notation elle-même. Et il existe en effet une telle notation pour l'analyse et la conception, dont l'ensemble complet de symboles tient sur une page et couvre pourtant toutes les bases des techniques de description des systèmes Orientés-Objet (OO) et qui est particulièrement efficace pour couvrir la description d'important système : la notion "Business Object" (BON : Business Object Notation) de Waldén et Nerson, comme elle est décrite dans leur bouquin [3]. Bien sûr, UML ne possède aucune de ces propriétés. Dans sa tentative de montrer qu'il inclut bien les petites idées de tout le monde, il affiche des tonnes de symboles les plus bizarres les uns après les autres. Rien que le "Résumé de Notation" prend 60 page et a sa propre table des matières ! [rq : bôôaaa, aujourd'hui, avec la version UML1.4, la même notation prend.. heu... 185 pages, index non-compris. Gloups] ! UML est en réalité aussi complexe qu'un gros langage cryptique [c'est-à-dire "secret" ou "codé"], avec une utilisation abondante de "$" et "#" et "-" et "*" et "triangle rempli sans queue" et rectangles et losanges et lignes pleines et lignes pointillées et ellipses remplies et ellipses pointillées [enfin, l'ellipse pointillée est, hélas, trop peu utilisée] et flèches de toutes sortes et mots-clés comme "const" et "sorted" (qui ne doit pas être confondu avec "ordered") et différent sens sémantiques pour une classe si son nom apparaît ou non en roman ou en italique [italique => classe abstraite !] ; Mais au moins un langage de programmation, même le pire des langages, est exécutable ! Là, vous devez vous apprendre cette complexité monstrueuse pour établir des diagrammes un possible futur système.
    Ce qui amène la question du développement d'un seul tenant [pour "seamless development"]. Une fois que vous avez vos jolis (ou pas si jolis) diagrammes, vous voudrez construire un système, sauf si le budget a déjà été engouffré par les outils d'AGL (un destin courant pour les entreprises qui prennent trop sérieusement la tendance "méthodologie", et qui se retrouve sans argent pour le vrai développement). Mais alors vous devrez tout recommencer avec un langage de programmation pour réaliser votre vrai métier. Et comment maintenez-vous la cohérence entre le programme et les diagrammes ? [d'où l'importance, depuis 1997, de la génération automatique de code multi-shot - c'est-à-dire qui n'écrase pas le code précédemment généré - et en cohérence avec le modèle, ou alors , depuis 2000, l'importance de la rétro-conception, maintenant bien au point surtout avec des langages comme Java]. Waldén et Nerson ont fait des propositions convaincantes concernant les aspects "d'un seul tenant" ( un process unique et continu) et réversible (capable de faire des aller-retours entre l'analyse, la conception et l'implémentation.[et cela n'est pas encore possible, même en 2002. J'en avais fait la remarque dès novembre 2000 dans l'article AGL : les grands écarts]. Des outils comme EiffelBench et EiffelCase répondent à ces besoins, mais cela ne semble pas poser le moindre problème à UML. Mais bien sûr, tous ceux qui utilisent UML doivent être très intelligent (ne serait-ce que pour apprendre les symboles), les analystes le deviendront également dès la première utilisation, ainsi que les concepteurs, et en conséquence nous n'aurons rien à modifier dans les 10 prochaines années de la vie du projet. A moins que peut-être UML ne s'adresse que au projets dont les spécifications ne changent jamais. Ma grand-mère me disait qu'elle avait entendu parler d'un tel projet dans sa jeunesse. Je pense que ce qu'elle évoquait avait quelque chose à voir avec la calcul du 6ème nombre de Fibbonacci.

    Il m'a donc fallu aller voir ailleurs pour trouver un point positif à UML. Je m'y emploie avec acharnement et j'espère que vous prendrez en compte tous ces efforts avant de rendre à l'administration vos notes finalisées (rappelez-vous que je ne demande que un D, bien sûr un C- serait très apprécié avec toute ma gratitude). Par exemple, j'ai essayé de voir si je pouvais caractérisé UML comme "orienté objet" ; ce qui est, comme nous le savons tous, un grand compliment. Pas de chance. Bien sûr, les auteurs ont fait un usage approprié des termes "objet" et "héritage" et etc. Mais un simple coup d'œil sur les diagrammes révélaient UML sous son vrai jour : une extension de la modélisation entité-relation. Les exemples de bases illustrent des associations binaires et ternaires, comme les associations de [1], page 16, entre "vol d'avion", "siège" et "personne". C'est à l'exact opposé de la modélisation orientée objet où, comme nous le savons tous, le monde est structuré en classe, construit à partir de type d'objet et toutes opération ou propriété n'appartient qu'à une classe. A l'évidence, dans une conception orientée-objet, vous ne pourriez pas avoir une relation "passager" qui concerne de façon symétrique " vol d'avion", "siège" et "personne" ! Dans un système orienté-objet, un "passager" appartiendrait à une des classes. C'est ainsi que vous obtenez consistance, simplicité, modularité et réutilisabilité des architectures orientées-objet ; considérez BON ou Eiffel pour en apprécier les avantages. Les auteurs d'UML savent cela, bien sûr ; pour bien comprendre pourquoi ils ont qualifié UML d'orienté objet, il faut apprécier leur fameux sens de l'humour. De toute évidence, ils entendaient cela comme une bonne blague. Est-ce suffisamment positif ?
    Des preuves supplémentaires de cette blague m'ont été fournies par les références répétées aux "Cas d'Utilisation" [Use Cases] comme étant un élément central de la méthode. A l'époque où "Cas d'utilisation" est le mot à la mode de l'année Web, j'avais essayé de comprendre de quoi il en retournait, et j'avais eu du mal jusqu'à ce que je demanda à mon grand-père qui m'expliqua tout : c'était le nouveau nom donné à la conception fonctionnelle descendante de son adolescence. Vous considérez ce que le système "doit faire" ("cas d'utilisation"), et en déduisez de cette analyse l'architecture du système. C'est à l'exact opposé de la conception orientée-objet qui refuse consciencieusement de payer trop d'attention, pendant les premières phases, aux principales fonctions du système parce que :
- elles sont encore sujettes à changement ;
- elles reproduisent le comportement d'anciens systèmes (ceux que l'on essaye de remplacer par un nouveau système) ;
- elles conduisent à des décisions prématurées quant à l'ordre des opérations (une des données les plus volatiles qui soient dans le monde du software) ;
- elles se concentrent trop sur les propriétés superficielles du systèmes (son interface avec le reste du monde) au dépend de ses propriétés fondamentales.
    Au lieu de tout cela, la conception orienté-objet se concentre sur les types d'objet manipulés par le système et définit chacun de ces types au travers de leurs opérations applicables et de leurs propriétés abstraites - les contrats - quelques soient leur ordre d'opérations.
[différences entre Type, Classe et Objet ? c'est par là]
    Mon grand-père est content que les cas d'utilisation soient présent dans UML parce que cela lui rappelle le bon vieux temps et qu'il n'a jamais aimé ces trucs objets [tiens, comme notre programmeur de 30 ans ? ], de toutes façons (je pense que cela est un commentaire positif).
[sacré Bertrand, il appuie la où cela fait mal, c'est-à-dire sur l'aspect le plus fonctionnel de cette notation objet. A noter qu'un lien est peut-être prévu par UML, cf. notre questionnaire UML]

    Manifestement UML ne sera d'aucune utilité à un développeur de logiciel. Peut-être serait-il utile à quelqu'un d'autre ? Des chefs de projets, peut-être ? Des dirigeants de compagnie ? La compagnie elle-même ? Bien sûr que non. En effet, les documents n'affichent aucune prétention à une telle utilité, et ce pour de bonnes raisons. Il est difficile d'imaginer quel bénéfice un business pourrait retirer de pages de diagrammes cryptiques [la structure d'intérêt peut s'avérer
cryptique, c'est à dire indétectable à partir de caractères visibles] aux propriétés hasardeuses d'un système mal compris.
     Donc je regarde plus loin. Parfois, une proposition offre une solution erronée, mais à le mérite de poser le bon problème. Peux-t-on dire cela à propos d'UML ? Je l'espère, ne serait-ce que parce que cela aiderait ma moyenne, et aider ma moyenne me permettrait de regagner ma amour-propre, sans parler de ma petite amie et du reste, mais je digresse. Au fait, de quel problème, s'il en existe un, UML est censé traité ? J'ai vraiment essayé avec la meilleure volonté du monde, parmi l'interminable liste des documents du site de Rational, de trouver une description du problème (qui aurait dû se trouver, comme on nous l'a appris dans nos cours d'ingeneering, en début de tout document technique); je crains de ne pouvoir rendre compte d'aucune trouvaille.

    Afin de voir quels objectifs auraient pu avoir été poursuivi, je me suis référé à la rédaction de mon amie Amanda-La-Chance, celle qui a eu 20/20 : "Les challenges qui attendent l'industrie du logiciel" (au fait, professeur, je ne veux pas avoir l'air de me plaindre, mais pourquoi Amanda obtient toujours les bons sujets ?). Ce rapport, très agréable, je dois l'avouer, est très efficace dans la description des obstacles que doivent surmonter les développeurs. 
- Les bons logiciels doivent être corrects. Oubliez une assertion dans une routine, et vous obtenez un désastre de 500 millions de $, dans le cas de la récente explosion d'Ariane 5 , résultat d'une tentative de réutilisation d'une routine Ada sans un mécanisme d'assertion tel que proposé par Eiffel (cf. le n° de janvier de IEEE Computer). Je ne vois rien dans UML qui permette l'exactitude [correctness]; quelques verbiages sont adressés au sujet de la notion de contrat, mais les auteurs démontrent qu'ils ne comprennent rien à l'idée de conception par contrat (par exemple, ils confondent les spécifications sémantiques et une simple déclaration de type!).
- Les bons logiciels doivent être robuste; comment UML y concourre-t-il ? 
- Les bons logiciels doivent être facile à modifier (Amanda qualifie cela "d'extensibilité"); mais la lourde machinerie d'UML ne garantie en rien qu'un développeur qui aura réussi une description d'un système ne sera pas trop terrorisé à l'idée de changer quoique ce soit. 
- Les bons logiciels doivent être réutilisables; rien dans UML ne répond aux challenges posés par la réutilisation, comme la standardisation des conventions d'interface, la séparation des opérandes optionnels, la séparation des commande de type requête, etc. [est-ce toujours aussi vrai ? l'interface a une vraie représentation, et la notion de composant se renforce et aura - enfin - une vraie légitimité et autonomie dans UML2.0!]. 
- Les bons logiciels doivent être performant - oh, pardon, c'est trop lié à l'implémentation, et l'on ne parle pas d'implémentation en compagnie policée. [marrant, ça... dès que l'on utilise UML dans un AGL, on se retrouve confronté, surtout en phase de conception, à devoir répondre justement au problème de la représentation logique d'une classe et de la façon d'y "cacher" des choix d'implémentation ! Cf. AGL : les grands écarts] (Si UML traitait de l'implémentation, cela aurait concerner des problèmes liés au logiciel; l'avantage des ronds et des flèches, à l'opposé des programmes, c'est qu'ils ne plantent jamais.).
    Au lieu de tout cela, UML ne semble avoir qu'un seul objectif : s'assurer encore et encore qu'il n'omet aucun mot technique à la mode, comme le montre cet extrait de la page 31 de [2] qui essaie d'explique que les patterns sont intéressants, mais couverts les concepts propres aux auteurs de "diagrammes d'interaction", quoique cela puisse être (je n'ai pas réussi à le comprendre).

L'aspect intéressant de la plupart des pattern réside dans leur comportement dynamique. On peut certainement illustrer cela avec des diagrammes d'interaction, mais seulement dans le contexte d'un modèle spécifique. Il est plus dur de rendre compte de l'aspect générique des patterns. En définitive, les patterns sont des templates en un sens, dans lequel les classes, associations, attributs et opérations pourraient tous être renommés ce qui (je me demande s'il ne s'agit pas plutôt de "tout en") conservant l'essence du pattern; nous avons besoin d'un moyen de paramétriser clairement les patterns. Toutefois, nous trouvons que nous avons suffisamment de moyens pour représenter les patterns via UML en les exprimant en terme d'interactions.

    Franchement, qui est intéressé par un tel méli-mélo ? Comment quiconque peut croire que cela ait un rapport (même "en un sens") avec l'industrie du logiciel ? Et je n'ai même pas cité l'extrait sur le "méta-modèle". Peut-être devriez-vous demander à Amanda de consacrer sa prochaine rédaction au "côté générique des patterns". Ca c'est un challenge! [et il a fallu attendre UML 1.3 puis 1.4, avec ses "profiles", pour en voir un dédié aux framework, ce qui permet déjà de se rapprocher de ce challenge : les points de paramétrisation des frameworks sont clairement représentés. Même si un pattern n'est pas un framework - en particulier, l'inversion du contrôle de l'exécution n'est pas toujours présente dans le pattern - cela peut donner une représentation convaincante de "l'aspect générique des patterns" via UML]
    Un ami qui avait assisté récemment à une conférence sur l'Orienté-Objet m'a parlé de toutes les blagues que les experts OO - parmi les plus respectés dans leur domaine - s'échangeaient pendant les pauses et dans le fond des salles de conférence. Il ne pouvait croire au contraste entre l'enthousiasme public et les critiques privées. Mais les dirigeants et autres preneurs de décisions n'entendaient que l'enthousiasme public. On leur dit que ULM est orienté objet, ou plus souvent encore que orienté objet signifie UML. Lorsque cela échouera à aider le développement de logiciel, cela ternira le domaine de l'orienté objet. Si l'on tient compte de tout l'excitation commerciale autours de lui, UML, en ne tenant pas ses promesses, a le pouvoir de retarder les progrès de la technologie objet de 10 ans [et 5 ans après, que constatons-nous ? 2 tendances : modélisation avec génération de code ou reverse engineering, les 2 contribuant à améliorer le développement des logiciel. Les design patterns en particulier sont devenu incroyablement populaires alors qu'ils bénéficiaient d'une représentation facile à partager, voire même à appliquer automatiquement sur un modèle.]

    Alors professeur, que puis-je dire, qu'est-ce que je peux dire ? Je suis aller voir votre assistante et lui ai demandé si "la page principale du site de Rational a vraiment de jolie couleur" pouvait passer pour un compliment acceptable. Mais elle a dit que non, je devrai trouver quelque chose de plus substantiel. J'ai essayé : "au moins, dans leur dernière révision, ils ont cessé d'appeler leur truc une méthode, ce qui montre qu'ils ont un certain sens du ridicule.". Ca ne l'a pas fait non plus. Alors j'ai cherché et cherché et finalement, j'en suis tout excité, j'ai trouvé! Oui, UML a un but, en fin de compte.
    La raison pour laquelle je ne l'ai pas découvert plus tôt et qu'il n'apparaît seulement que dans la conclusion. Une place étrange pour mentionner le sujet de ce que l'on rédigeait durant tout le document, mais mieux vaut là que nulle part. Bien sûr, ce que j'ai trouvé :
- n'est pas un objectif technique (UML, comme je l'ai déjà dit, ne sert aucun but relié au logiciel, et cela me va ; certaines personnes ont d'autres choses à faire de mieux dans leur vie que d'essayer d'améliorer la technologie du logiciel).
- n'est pas un objectif de management, ou tout du moins pas pour des managers de projets logiciels.
- n'est pas un objectif métier, du moins pas pour des métier utilisant UML. 
Mais c'est un objectif.
    Lorsque j'ai finalement découvert cet objectif, l'esprit généreux et noble des auteurs m'a presque tiré quelques larmes. Il serait injuste d'affirmer que les piles de documentation UML sont vides de toute substance, alors qu'en fait elles contiennent une authentique idée. Je l'ai trouvée dans le tout dernier paragraphe du tout dernier rapport décrivant la révision 0.91 [2]. Elle était là, dans toute sa simplicité, expliquant tout ce que j'avais mal compris dans ma jeune naïveté. Comment avais-je pu accuser la méthode de ne pas aider les développeurs ou managers alors qu'elle ne s'intéresse nullement au développement logiciel, mais uniquement au développement d'un marché pour les consultants et les formateurs ? Tout prenait un sens : la complexité et l'étrangeté de la notation, que j'avais imprudemment pris pour une tare, sont en fait ses qualités les plus attirantes, puisqu'elles favorisent des opportunités infinies de business pour Rational et peut-être même aussi pour les autres; il en va de même pour son adoption tiède des idées "orientées-objet", puisque cela signifie que les consultant n'auront même pas à aimer ou connaître la technologie objet pour enseigner UML.
    Ma longue recherche n'aura pas été vaine. Cela m'a conduis à une complète compréhension d'UML, de cette admirable machine se nourrissant elle-même, dévoué de A à Z à la création d'un nouveau marché, libre de toutes les difficultés associes au déplaisant business du développement logiciel : les livres UML ! les cours UML ! les cours sur les livres ! les livres sur les cours ! les livres sur les livres ! des cours d'introduction pour préparer aux cours avancés ! Les cours destinés à ceux qui enseignent les cours ! les révisions ! les journaux UML ! Les conférences ! les Workshops ! Tutoriaux ! Standards ! Comités ! Tee-shirt ! [là, je voudrais pouvoir dire que notre ami B. Meyer a pété une durite... le problème, c'est que tous les éléments qui viennent d'être cités existent sans doute! surtout les tee-shirt!]. Plus vous pensez aux possibilités, plus elles vous semblent éblouissantes. Et pour le lecteur suffisamment courageux ou ennuyé pour tout lire jusqu'à la fin, voici le grand projet, exposé dans le dernier paragraphe.
    Tout prenait un sens. Avec cet aspect inévitable qui est la marques des authentiques chef-d'œuvres,  dans toute la gloire de l'inimitable style de ce document, les six dernières lignes donnent soudainement un sens aux centaines de pages creuses avant elles : 

Il existe plusieurs cours publics et nous connaissons plusieurs livres traitant différents aspects d'UML, tous basés sur nos précédentes publications. Nous espérons une large diffusion d'outils de support, des cours de formations et du consulting. Nous encourageons fortement ce type de support [comme cela est aimable d'encourager le support de vos propres produits ! Quels désintéressement !] et nous travaillerons avec les auteurs, formateurs et consultants pour à s'assurer que leurs questions soient traitées de façon à être largement diffusées et en accord avec le support UML.

J'espère que ma requête retiendra favorablement votre attention,

Sincèrement votre,

Naïf Dupond

[1] Kim Waldén and Jean-Marc Nerson: Seamless Object-Oriented Software Architecture: Analysis and Design of Reliable Systems, Prentice Hall, 1995. (retour à l'article)

[2] Rational Software Corporation: 0.91 Addendum to the Unified Modeling Language, at http://www.rational.com [a priori, le document n'est plus en ligne... dommage!] (retour à l'article)

[3] Kim Waldén and Jean-Marc Nerson: Seamless Object-Oriented Software Architecture: Analysis and Design of Reliable Systems, Prentice Hall, 1995. (retour à l'article)