Du bon usage de l'abstraction (1 Les enjeux)

Adulée par les uns, suspecte pour les autres, l’abstraction se niche au cœur de notre métier de concepteur de systèmes d’information. Selon moi, elle a partie liée avec les succès et les échecs de bien des projets informatiques. Cet article est le premier d’une série de quatre, consacrés à ce sujet. Les réflexions qu’ils contiennent sont pour la plupart issues de mon expérience d’analyste UML acquises ces deux dernières années chez SQLI.
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. Nombre de questions demeurent ouvertes et attendent vos commentaires avisés.
Un sujet de stage est proposé ainsi que quelques suggestions d’articles à écrire.

Partie 1: les enjeux.

L’abstraction c’est quoi ?

Chez PSA, ma mission actuelle consiste à recueillir et à formaliser, au moyen du langage UML, le besoin d’un ensemble d’applications de gestion classiques : facturation, suivi logistique, approvisionnement etc... Mon rôle est d’assurer le trait d’union entre, d'un côté les équipes techniques d’architectes Java / J2EE en charge de la conception et du développement de ces nouvelles applications et de l'autre, les équipes d’experts fonctionnels qui détiennent, souvent sous forme orale, les connaissances fonctionnelles détaillées.

L'objectif que je me fixe est de faire en sorte que les équipes de conception aient, dès le premier jour, accès à des spécifications fonctionnelles rigoureuses et centralisée sous forme d'un seul modèle UML d'analyse publié sous Rational Software Modeler. Parfois intense durant les ateliers de modélisation lorsqu’il s’agit de formaliser à la volée cette connaissance, cette mission m’amène à vous faire part de quelques réflexions, personnelles et subjectives, sur le rôle de l’abstraction dans notre métier de concepteurs de SI.

Si l’on me demandait de citer les deux principaux facteurs de succès ou d’échec des projets informatiques, je choisirais sans hésiter :

1. La qualité de la communication au sein l’équipe projet (=MOE). Celle-ci implique des enjeux de relations humaines difficilement quantifiables. En font partie : le degré de solidarité professionnelle, la motivation des individus à combler leurs propres lacunes techniques, le sentiment de réaliser un travail qui a un sens. Sens nourri par l’espoir de voir à terme des utilisateurs satisfaits qui, rêvons un peu, sauront se montrer reconnaissants. Si, si, je vous l’assure, ça existe !
2. La qualité de la communication entre la MOA et la MOE. Convenons que la réalisation dans la joie et la bonne humeur d’un système d’information parfaitement conçu dont personne n’a besoin sera du plus piteux effet. Si, si, ça aussi ça existe !
   

Le sujet qui m’intéresse, l’abstraction, touche plus directement le second point : la qualité de la communication entre MOE et MOA. Le classique de l’ « humour de projet » traduira cet état de fait mieux qu’une laborieuse analyse (de haut en bas 'ce que le client a expliqué', 'ce que l'analyste a modélise', 'ce que le développeur à codé', 'ce que le commercial a vendu', 'ce que le CP a compris', 'ce que le client voulait') :

Alors qu’entend-on au juste par abstraction ? Wikipédia, hormis un vague salmigondis philosophique, ne dit rien hélas qui puisse éclairer notre sujet. Me voici donc contraint de me vous proposer une définition de mon crû :

Définition : L’abstraction, c’est la faculté mentale de faire porter la réflexion et l’analyse sur les bonnes catégories d’objets. C’est l’aptitude à créer de bons concepts ou de bons regroupements d’objets qui simplifient la formulation d’un problème à résoudre sans pour autant appauvrir la sémantique de la question originale.

Qui dit mieux ? Pas facile d’être clair, mais en dépit d’intenses cogitations c’est tout ce que j’ai à proposer.

Peut-on hiérarchiser les niveaux d’abstraction ?

Quelque soit sa fonction, l’informaticien est confronté au quotidien à une grande diversité de niveaux d’abstraction, de surcroit souvent mal définis. Selon son humeur, il considèrera cet état de fait tantôt comme une intarissable source d’ennuis et de conflits, tantôt comme le charme de son métier. Partant de ce constat, il est tentant de vouloir hiérarchiser ces niveaux pour désigner l’un comme étant situé au-dessus de l’autre.

A première vue, la finesse de détails d’un modèle peut sembler un critère de classification légitime. On conviendrait qu’un modèle qui contient moins d’information qu’un autre est aussi plus « abstrait ». A ce titre, un modèle UML d’analyse serait donc plus abstrait qu’un modèle UML de conception, lui-même plus abstrait que le code exécutable :

Abstr (Analyse UML) > Abstr (Conception UML) > Abstr(Code)  (1)

C’est la classification présentée dans beaucoup d’ouvrages consacrés à UML [1,2]. Mais alors, ou placer le langage usuel ? Est-il plus ou moins abstrait que le code ? Il est incontestable que le langage humain (utilisé par des experts métiers pour décrire un cas d’utilisation) omet une foultitude de détails contenus dans le code (et les choses sont très bien ainsi !) Nous devrions donc écrire :

Abstr(Langage humain) > Abstr(Code)  (2)

Le sens commun quant à lui, lie davantage l’abstraction à l’éloignement subjectif ressenti par rapport à une langue ou un formalisme usuel. Il commande donc plutôt d’écrire

Abstr(Code) > Abstr(Langage humain)  (3)

A l’évidence (2) et (3) sont incompatibles. On le voit, la comparaison des niveaux de détails trouve donc rapidement ses limites, ou en tout cas, ne rend pas justice au sens commun. Il n’y a là aucun mystère profond. Différents langages sont adaptés à des usages différents. L’un s’adresse aux humains, l’autre aux machines d'autres encore aux deux.

Une remarque encore. Deux modèles ou deux langages peuvent être assimilé à des niveaux différents d’abstraction bien qu’ils contiennent rigoureusement la même information. Pensons à Java et au bytecode par exemple ou encore au PSM et au code généré dans une approche MDA, nous y reviendrons plus loin.

De ces quelques arguments on voit que, si l’entreprise de classification des niveaux d’abstraction devait s’avérer possible, elle ne peut reposer sur la seul idée naïve qui consiste à comparer un contenu en information d’un modèle à celui d’un autre. Il y fort à parier qu’une classification qui tiendrait la route devrait impliquer une notion de « but à atteindre » pour un modèle. Par exemple être compréhensible par une machine, par un homme ou par les deux. Un sujet qui relève vraisemblablement d’un chapitre de la théorie de l’information et de la linguistique qui reste à écrire. L’excellent ouvrage de vulgarisation de J.-P. Delahaye [4] propose, sur le sujet connexe de la complexité, une passionnante introduction. Les esprits curieux des coulisses théoriques de notre métier y trouveront leur compte.

Une attitude moins ambitieuse et fondamentaliste serait d’accepter que la notion d’abstraction recouvre une large part de subjectivité. Ce qui apparait comme abstrait aux uns apparaitra concret aux autres. Question de culture et d’habitude en somme.

Un exemple : dans ma mission, il m’a fallut quelques heures d’effort pour cerner la notion de « remise » sur une « commande », qui décidément m’apparait comme bien « abstraite ». En revanche les notions d’interface Java et de fichier XML sont pour moi très « concrète ». Pour mon collègue expert fonctionnel il en va exactement à l’inverse.

« On est toujours dans l’abstraction de son voisin. »

Au sein d’une architecture logicielle en couche, on pourrait à la rigueur considérer les couches basses (persistance) comme moins abstraites que les couches intermédiaires (règles métier). Une telle convention reste cependant arbitraire. Il y a en ensuite les différents niveaux d’abstraction d’un langage lui-même. Je me suis largement exprimé sur ce sujet dans mon dernier post consacré à Java EE 5. Pour ceux d’entre vous qui auraient zappé (il y en a ?) mes dernières cogitations, je rappelle brièvement les deux points clés :

• Je soutiens qu’il est aujourd’hui devenu impératif de limiter le nombre de ces abstractions pour éviter l’inintelligibilité du code pour le commun des mortels. Mon article contient quelques propositions qui vont dans ce sens.

• Je prétends que lorsque le nombre d’abstraction (ou d’API si l’on préfère) croit exagérément, il est vain de vouloir les encapsuler dans un schéma de poupées russes. Il vaudrait mieux en inventer de nouvelles mieux adaptées. A ce titre, décrire une IHM (client lourd ou léger) avec des classes Java m’apparaît pour le moins incongru et artificiel. J’y vois surtout le fruit d’une pensée unique de l’ « objet » dont il conviendrait de tourner la page.

Mais laissons-là ces spéculations pour revenir plus spécifiquement à la communication MOA-MOE qui sera le sujet des deux prochains articles. L’un sera consacré aux difficultés liées à UML pour lequel il faudra palier à l’absence de définition claire de niveaux d’abstraction. Le second évoquera quelques aspects d’ordre plus culturels.

La suite bientôt sur cet écran...