Du bon usage de l'abstraction (2 Les difficultés liées à UML)

Peut on définir le niveau d’abstraction d’un modèle ? Quels sont les écueils à éviter dans la modélisation UML ? Comment susciter l’adhésion d’une entreprise à une démarche basée sur UML ? Comment combler les lacunes d’UML ? L’initiative MDA versus l’approche par DSL. Tels sont quelques-uns des thèmes abordés.

Du bon usage de l'abstraction (2)

Les difficultés liées à UML

Quiconque a un jour dispensé une formation UML sait à quel point il est difficile de transmettre, à des esprits vierges de tout concept objet, les notions d’ "objet métier", de "cas d'utilisation" ou encore "d'activité". Pourquoi ? Tout simplement car ces concepts sont par essence ambigus. Tout du moins si on les compare à la rigueur axiomatique qui convient au fondement d'autres formalismes comme la géométrie ou à l’algèbre par exemple.

En effet, on ne peut véritablement définir ce qu’est un « objet métier ». En revanche, à force d’exemples et en écoutant les avis autorisés des experts, on pourra s’y habituer ! Et après une ou deux tentatives, le novice parviendra, lui aussi à placer « objet métier » à bon escient dans une conversation avec ses pairs ou dans les réunions en clientèle. Ensuite il devra s'attaquer à la notion de « service » plus difficile encore à cerner qu' objet métier ! On voudra bien me pardonner un zeste d’ironie...

Pour autant, faut-il rejeter ces concepts ? Nullement ! Le flou conceptuel qui enrobe ces termes en garanti précisément leur utilité. Il en va d’ailleurs comme pour le langage naturel, lui aussi non axiomatisable. Les linguistes connaissent bien cette difficulté, qui s’y sont cassé les dents depuis des lustres en essayant, en vain, de construire des systèmes experts de traduction universels. Si ce problème d’axiomatisation était résolu il y a belle lurette que nous aurions la compagnie de machines qui pensent,  parlent, créent des algorithmes, de la poésie ou se mettent en grève.

Cependant, voilà que je m’égare… Revenons donc sur Terre et à UML. Une fois ingurgitées les notions de classes et d’objets, nos apprentis UML-iens ne sont hélas pas au bout de leur peine. Non pas que l’apprentissage des 13 diagrammes d’UML 2.0 relève de l’impossible, mais les contextes dans lesquels ceux-ci interviennent sont extrêmement variés. Le néophyte risque de se sentir rapidement perdu. C’est là, selon moi, le principal frein à un usage plus répandu d’UML au sein des entreprises: l'absence de définitions claires de niveaux d'abstractions dans les modèles UML.

Pour ma part je distingue l’usage de quatre niveaux d’abstraction dans un projet informatique typique qui met en œuvre UML :

1. Le niveau « ‘Quoi’  non formalisé ». C’est le niveau utilisé par les experts métiers qui expriment en langage humain un besoin métier, typiquement au moyen d’une liste indexée et priorisée d’exigences accompagnée d’un glossaire technique. Ce dernier évitera au concepteur, souvent prestataire, de se noyer dans le jargon local. En effet, les experts métiers on un penchant naturel à mitrailler les nouveaux venus de salves de sigles et de trigrammes, et ce sans aucune compassion. Dans une démarche itérative de type RUP (Rational Unified Process) c’est le niveau d’abstraction utilisé dans la « discipline » dite « Requirement ».
2. Le niveau « ‘Quoi’ formalisé  en UML». C’est le niveau d’abstraction utilisé par l’analyste UML, en phases de spécifications fonctionnelles générales et détaillées, quand il formalise le besoin et les règles métier. Pour cela il utilise surtout des diagrammes de cas d’utilisation, des scénarios et des classes d’objets métiers. Les cas d’utilisation partitionnent et organisent le besoin en unités réutilisables. Les classes d’objets métier constituent un glossaire qui doit permettre d’une part la formulation sans ambiguïtés des règles métiers et d’autre part de définir quelles seront les entités persistantes. Par comparaison, c’est le niveau d’abstraction du MLD dans Meurise ou de la « discipline » dite « Analyse » dans le processus RUP. A ce niveau aucun élément UML n’est connoté techniquement. Les « Hibernate », « EJB » et autres « ActionForm Struts » sont ici persona non grata !
3. Le niveau « ‘Comment’ formalisé  en UML».  C’est le niveau d’abstraction utilisé par l’architecte logiciel. C’est là qu’interviennent les designs patterns, les choix d’architecture logicielle et les frameworks. Les diagrammes UML sont ici les classes de conception avec une liste détaillée et typée des attributs et des opérations dont la signature est complète. Des diagrammes de composants peuvent être utilisé. Par comparaison, c’est le niveau d’abstraction du MCD dans Meurise ou de la « discipline » dite « Design» dans le processus RUP. Les « Hibernate », « EJB » et autres « ActionForm Struts » sont ici autorisés.
4. Le « Code exécutable ». C’est la formalisation ultime. Elle inclut l’ensemble des codes exécutables de Java, C# à SQL en passant par JavaScript. C’est le niveau de la « discipline » dite « Implementation» dans le processus RUP.

Ces niveaux d’abstraction ne doivent être confondus ni avec la notion de phase d’un cycle projet de type RUP ni avec la notion d’activité. Une même phase peut faire intervenir simultanément plusieurs niveaux d’abstraction.

Dans l’idéal, il serait possible de faire l’économie du niveau « ‘Quoi’ non-formalisé » à condition qu’UML fasse partie intégrante de la culture d’entreprise, aussi bien pour les experts métiers de la MOA que pour les équipes MOE. En réalité, c'est rarement le cas. L’un de mes objectifs chez PSA est de promouvoir une telle culture transverse dans toutes les équipes fonctionnelles et techniques. Sur une échelle d'un ou deux ans, cette ambition n'apparaît pas totalement irréaliste, au vu des premiers succès enregistrés et étant donné qu'il existe une volonté politique affirmée dans ce sens.

Le niveau « ‘Comment’ formalisé avec UML» peut être omis si aucun enjeu d’architecture logicielle ou technologique n’est présent. Cela peut être le cas pour des applications de gestion de petite taille ou une application dont les fonctionnalités sont très standards. La mise au point d’une console d’administration d’un référentiel de données sont des exemples.

Enfin, concernant le  niveau « 4. Code exécutable » notons qu’il est souvent panaché avec le niveau 1 lorsque le développeur commente son code. Il y a alors violation de la séparation des niveaux d’abstraction, ce qui n’est pas souhaitable selon moi. J’estime qu’il est préférable d’investir l’effort dans l’écriture d’un code clair et auto explicatif plutôt que de rédiger, après-coup, de longs commentaires sensés palier son inintelligibilité. 

Un code qui nécessite des commentaires est du code mal écrit ! 

Sur cette question il n’y a pas de consensus et je n’exprime ici que ma modeste opinion.

Pas plus de 4 de niveaux d’abstraction svp !

Qu’un certain flou autour règne autour des concepts UML ne devrait toutefois pas empêcher de définir les différents niveaux d’abstraction de manière aussi précise que possible. En indiquant d'une part le niveau d’information requis dans les différents diagrammes UML et d'autre part en proposant un canevas complet de modélisation qui prescrit explicitement comment doivent s'articuler entre eux les différentes catégories de diagrammes.

C’est la condition indispensable, selon moi, pour susciter un minimum d’adhésion parmi une population souvent réticente à ingurgiter un n-ième formalisme.

L’approche guidée à la modélisation UML est celle que j’essaie de promouvoir chez PSA. Deux autres points sur lesquels j’insiste particulièrement sont :

• Les commentaires systématiques pour un certains nombre d’éléments UML (en particulier les cas d’utilisation et les classes d’objets métier).
• L’ergonomie du modèle UML qui doit être entièrement navigable à l’aide d’hyperliens à partir d’un point d’entrée constitué par un diagramme de cas d’utilisation global. Il s'agit pour le coup de convaincre les équipes qu'un seul modèle UML vaut mieux qu'un ensemble disparate de documents de spécifications au format Word ou Excel éparpillés dans d'obscurs répertoires.

Les premiers retours sont plutôt encourageants.

Dans l’idéal, je pense qu'il faut viser sur le long terme, 3 niveaux d’abstractions, pas d’avantage. Ceci, tout en sachant que la phase transitoire durant laquelle le langage naturel continuera à être utilisé peut durer plusieurs années. Mais limiter le nombre de niveaux d’abstraction, facilitera d'autant leur définition et évitera d’interminables palabres sur le fait de savoir ce qui est du ressort de tel diagramme ou non.

Combler les lacunes d’UML

Outre l’ambiguïté des niveaux d’abstraction, UML est entaché de quelques lacunes notoires qu’il faudra nécessairement combler. Par chance, UML prévoit plusieurs mécanismes standards d’extension : le plus usité est l’usage de stéréotypes. Un stéréotype est à UML ce que l’adjectif est au langage usuel. Un profil UML est un regroupement cohérent de stéréotypes, dédiés à un aspect métier ou technique bien spécifique. Certains profils sont définit dans UML lui-même. Certains sont propres à une méthodologie, comme RUP par exemple. D’autre encore, peuvent être définit pas l’analyste lui-même en vue d’adapter sa modélisation au contexte de l’entreprise.

Dans trois domaines les lacunes d'UML m'apparaissent particulièrement criants.

La logique de navigation d’une IHM

Conçu à l’ère pré-web, UML n’a jamais disposé d’une notation reconnue pour représenter la logique de navigation d’une application web. Il n’existe pas d’avantage de standard UML pour les tâches aussi coutumières que :

• Décrire les contrôles de surfaces (format, cohérence etc.) à effectuer par un navigateur.
• Décrire quelle données doit être affichée par quel composant graphique ?
• Décrire quelle action ouvre ou ferme une fenêtre ou une popup.
• Quelle donnée doit être affichée ou masquée en fonction de quel profil utilisateur ?

Le plus souvent des solutions ad-hoc sont adoptées, à base de jolis dessins PowerPoint agrémentés de quelques fichiers Excel improvisés. Mais ce sont ne sont là que des pis-aller qui devraient être bannis d’une démarche industrielle.

Ce manque de formalisme se fera d’ailleurs sentir avec plus d’acuité encore avec la multiplication des technologies RIA :

Quelques profils UML existent dans la littérature [3]. Je m’en suis inspiré pour créer la mienne. Ceci fera l’objet d’un prochain billet qui sera soumis à la sagacité de vos esprits critiques, l’idée étant de l’enrichir pour alimenter notre boite à outils CMM-I niveau 5 !

Par ailleurs, la mise au point d’un tel profil, tenant compte largement des nouvelles possibilités offertes par les applications RIA pourrait constituer un beau sujet de stage.

Conception de base de données

Un autre secteur où UML brille par son absence est celui de la conception de bases de données relationnelles. Il n’y a pas, à ma connaissance, de stéréotypes standards pour des notions aussi courante que « table », « clé étrangère » ou « trigger ».

Des produits commerciaux, tel Rational Software Modeler proposent leur propre solution. Cependant les concepteurs de SGBDR lui préfèrent en général des outils de conception plus ancienne et ayant fait leurs preuves. Le bon vieux PowerDesigner détient la palme de popularité. Sur ce sujet l’avis des experts bases de données chez SQLI serait intéressant.

Topologie de déploiement

Devant la pauvreté sémantique presque risible des diagrammes UML de déploiement, l’usage d’une autre notation s’impose. La plus courante à ma connaissance, est le vaste panoplie de diagrammes proposé par Microsoft Visio. C’est affligeant pour un langage, je parle d’UML, qui se voudrait universel, mais c’est la réalité.

Prochainement sur cet écran : Quelques réflexions sur les difficultés d’ordre culturel liées à l’abstraction.