Note : 4 ; Une vue extrêmement “analyse” de l’objet, dépassée et sans intérêt aujourd’hui.
Philippe Desfray est le directeur technique de Softeam et de son produit : Objecteering. Cet ouvrage, qui est ici dans sa seconde édition, décrit la notation « classe relation » et la méthode qu’elle sous-tend. Cette notation était en grande partie supportée par la version 3 d’Objecteering (au développement de laquelle j’ai participé) avant d’être abandonnée au profit d’UML dans la version 4. J’ai également trempé dans l’affaire. A l’époque, on croyait beaucoup à l’association notation-méthode, et Classe-Relation (dont le nom rappelle Entité-Relation de Chen) se pose alors en concurrent direct d’OMT ou de Booch !
Ce livre a donnée à Classe-Relation une audience internationale. Et cela a certainement aidé Softeam a être une société phare dans le milieu des années 90. Mais voyons comment se présente le contenu. Celui-ci compte un peu plus de 300 pages divisées en 14 chapitres auxquelles il faut ajouter une quinzaine de pages d’annexes. Si le volume bénéficie d’une couverture dure, la qualité du papier et de l’impression ne suivent pas. Dommage !
Le premier chapitre campe le décors. Plus exactement quel rôle pour le modèle lors des phases successives d’analyse et de conception, c’est à dire un même modèle, mais enrichi… avec en plus l’aide de l’hypergénéricité.
Le second chapitre a trait à la nature des objets. Pour Philippe Desfray, ils doivent exclusivement être issus du domaine de travail, quel que soit la phase de travail. Ce qui sera un point de désaccord avec moi quand sonnera l’heure des design patterns !
Le 3ème chapitre est le premier qui ait réellement trait à Classe-Relation. C’est une courte introduction au métamodèle de cette notation.
Le chapitre 4 est conséquent car il couvre près de 40 pages. Il est totalement consacré au modèle structurel, d’un point de vue notation graphique et syntaxe textuelle. Car Classe-Relation possède une représentation sous forme de syntaxe textuelle (supportée par Objecteering 3) ! Globalement, la prose n’est pas passionnante à lire, mais n’est pas non plus imperméable à la compréhension.
Le terme « operating model » employé en titre du chapitre 5 n’évoque rien de prime abord. En fait, il regroupe deux notions. D’une part, les pré / post conditions et invariants, et d’autre part les automates d’état associables aux classes. Ce n’est pas ma partie préférée, disons et la prose est parfois même confuse.
Le modèle dynamique décrit au chapitre 6 est assez rigolo. D’abord il n’existe dans aucune autre notation. Il est vrai que l’object flow qui se veut le remplacement du code des méthodes n’est pas réellement une alternative viable à la simple écriture de code. Et le modèle d’évènements n’a pas non plus subi l’épreuve du feu et ne permet pas réellement de supporter la représentation d’un modèle asynchrone. Aucune de ces notations n’est d’ailleurs supportée par l’outil de l’époque.
Le chapitre 7 traite de structuration en « schémas » (les packages d’UML). J’avoue que les règles de dépendances et les règles de transformations permettant de respecter ces règles de dépendances sont parmi les choses qui m’ont le plus servi par la suite. De plus je trouve le métamodèle Classe-Relation très complet par rapport à ce que l’on peut faire avec les schémas, plus complet que ce qu’offre UML. Un bon point pour le chapitre 7 !
Le chapitre 8 sur les règles de modélisation est assez étrange. Tout d’abord on voit que Classe-Relations se calque pas mal sur le C++ car il supporte le concept de « classes élémentaires ». Ensuite l’auteur nous assène les règles de normalisations… du modèle relationnel ! Vraiment étrange…
Le chapitre 9 est en quelque sorte le chapitre introductif à la seconde partie du livre (bien qu’il n’y ait pas de seconde partie physiquement), on va y parler processus. Et ici, même s’il fait mine d’être mâtiné de cycle itératif, c’est vraiment tout pensé « cycle en V » ! La véritable vertu de ce chapitre c’est d’être court.
Donc logiquement, c’est de phase d’analyse que parle le chapitre 10 ! La démarche proposée est très prescriptive, et ça ne fait pas briller les yeux. Comme toute approche prescriptive, de mon point de vue, ça ne marche pas dans le monde réel…
Au chapitre 11, on aborde bien entendu la conception. Classe-Relation a une vue très réductionniste de la phase de conception : c’est la prise en compte des contraintes physiques d’implémentation, et c’est tout ! On y est moins prescriptif, mais c’est aussi plus décousu. Et pour parfaire le tout : on évoque bien entendu la bonne vieille plaisanterie de l’étape d’intégration ! Bref, après seulement la traversée de ces deux phases, on sait déjà que la méthode est complètement dépassée.
Le chapitre est important en volume (35 pages) et en thème, car il traite d’un aspect cher à Philippe Desfray : l’hypergénéricité et le langage H. C’est MDA avant l’heure. Et je dois dire que techniquement ça marche. Et ça marchait en 1995 dix fois mieux que n’importe quoi d’autre. Hélas je n’adhère pas au postulat méthodologique : On peut ajouter les aspects de conception sur un modèle d’analyse « pur » et les règles d’hypergénéricité fabriqueront les classes techniques de conception qui sont finalement jetables ! On peut (et on a) tiré quelque chose de cette mécanique, mais cette vue intégriste du monde est simplement impraticable.
Le chapitre 13 consacré à la phase d’implémentation (car il y a une phase d’implémentation !) est très peu convainquant. On y parle vaguement de règles de génération de code et des mérites comparés des différents langages orientés objet de l’époque : C++, Eiffel et Smalltalk.
Plus amusant le chapitre 14, qui est également le dernier, compare Classe-Relation avec OMT. Je vous laisse deviner lequel gagne. Ce travail est loin du sérieux avec lequel les auteurs d’OMT se sont livrés au même exercice. On est loin aussi du niveau de technicité de leur analyse. Bref, une belle blague.
Cet ouvrage est probablement à lire pour les propos sur l’hypergénéricité. La notation Classe-Relation recèle quelques trouvailles intéressantes qui n’ont hélas pas été reprises dans UML. Mais sinon, la notation sent très fort le C++. La seconde partie du livre dédiée à la méthode est non seulement dépassée mais était même sans intérêt à l’époque. Elle accumule les erreurs : depuis le phasage analyse-conception implémentation jusqu’au mépris par lequel est traité la conception en passant par une démarche prescriptive digne du Taylorisme. Le texte est lisible sans être spécialement plaisant et les positions intégristes de l’auteur ont parfois tendance à me hérisser le poil.
La 3ème édition, en français à nouveau cette fois, et fait progresser (un peu) le propos de l’auteur. Mais c’est une lecture qui n’a plus d’intérêt aujourd’hui, de toute façon.
Référence complète : Object Engineering, the fourth dimension – Philippe Desfray – Addison Wesley 1994 – ISBN: 0-201-42288-3
Software Freethinker 
