Dans le monde des affaires, le rétroviseur est hélas toujours plus clair que le pare-brise.
Warren Buffet
Mois : août 2013
Agile Grenoble 2013
Organisé par le Club Agile Rhône-Alpes, cet évènement prévoit d’accueillir sur une journée plus de 500 professionnels et proposera plus de 40 sessions dans des domaines variés (Agilité, Lean, Management, Jeux, Ingénierie du logiciel).
Zenika est aussi présent à cet évènement en tant que sponsor, mais aussi nous l’espérons avec quelques interventions qui contribueront à la qualité de ce bel évènement !
Note de lecture : Object Engineering, par Philippe Desfray
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
La science ne connait pas de pays, car c’est la lumière qui illumine le monde.
Louis Pasteur
Aidez-moi à trouver un titre !
Comme je l’ai signalé hier, je m’attelle à la tâche de non pas traduire, mais adapter la prose de Tobias Mayer : The People’s Scrum !
A peine ai-je commencé que je dois déjà faire face à une première difficulté : traduire le titre de l’ouvrage ! L’idée n’est pas nécessairement de faire une traduction littérale, mais de préserver l’esprit du texte !
French Translation
There is now a fourth translation of The People’s Scrum in the works. Christophe Addinquy will be doing his “spirited translation" into French. Thanks, Christophe!
The People’s Scrum, c’est un livre sur Scrum pas comme les autres ! C’est grandement dans l’esprit de ce que j’essaie de faire avec certains des articles de ce blog. C’est pourquoi nous avons décidé de travailler ensemble sur ce qui sera bien plus qu’une traduction, une adaptation !
Je cherche en ce moment à traduire le titre du livre pour bien en refléter l’essence. Votre aide est la bienvenue !
The Software Preservation Group
The Software Preservation Group (SPG) of the Computer History Museum is exploring how to collect software in support of the museum’s overall mission.
http://www.softwarepreservation.com/
Notre discipline n’est plus si jeune. Elle accuse 65 ans, enfin à peu près en fonction de ce que l’on s’accorde à considérer comme l’informatique moderne…
Mémoriser, référencer les documents ayant trait à cette histoire devient une tâche importante à laquelle le SPG s’attelle. Cela reste très partiel, souvent Wikipedia fait même mieux, mais le SPG référence aussi de vieux documents introuvables ailleurs !
Le fer se rouille, faute de s’en servir, l’eau stagnante perd de sa pureté et se glace par le froid. De même, l’inaction sape la vigueur de l’esprit.
Léonard de Vinci
Note de lecture : The Annotated C++ Reference Manual, par Margaret A. Ellis & Bjarne Stroustrup
Note : 6 ; Extrêmement austère, mais indispensable pour connaître le détail de comportement du langage … avant la norme !
L’ARM est un ouvrage qui fait plus que dater (il a été écrit en 1991), et il aurait dû être relayé par un ouvrage équivalent traitant du langage tel qu’il a été standardisé. Des documents de standardisation du langage ont bien été publiés (pour le C++ 98 et le C++ 11), mais ce livre reste LE livre de référence sur le langage tel qu’il fut définit au départ. Il s’utilise comme tel, par conséquent sa lecture linéaire est extrêmement difficile, voire inutile. Il a servi de document de départ au comité de normalisation ANSI, et bien que certaines assertions soient désormais invalides, Il s’agit bien là de la description (sèche) la plus exhaustive du langage actuellement éditée. Ce livre ne peut aider que les développeurs très aguerris dans le langage, ayant besoins de lever des ambiguïtés à des fins de portabilité du code, de génération de code, etc..
Ouvrons un peu la bête pour voir ce qu’elle a dans le ventre. Malgré un volume apparemment modeste, le texte compte 440 pages sur 19 chapitres et aucune annexe. En fait, le livre lui-même pourrait être considéré comme une grosse annexe !
Je passe le chapitre 1 d’introduction qui replace le C++ dans son contexte historique. Le chapitre 2 évoque succinctement des éléments de syntaxe : les mots-clés, ce qu’est une constante littérale, etc..
Les choses sérieuses commencent au chapitre 3 où l’on traite des bases, à savoir des déclarations et des portées de celles-ci. En conséquence, on évoque bien entendu les déclarations static et extern et la façon dont elles sont appréhendées par le linker. Et on traite aussi de classes de stockage. Les types de base et leurs dérivés sont aussi évoqués.
Le chapitre 4 est très court et exclusivement dévolu aux conversions, qu’elles soient numériques ou qu’elles portent sur des pointeurs ou des références. On a droit à un des rares diagrammes du livre.
En comparaison, les 35 pages du chapitres 5 consacré aux expressions (et donc aux règles d’évaluation) en font une partie très dense de l’ouvrage. Il faut pas mal de concentration pour suivre le propos, mais ces règles restent valables aujourd’hui et sont un fondement de la façon dont le langage fonctionne !
Les « statements » évoqués au chapitre 6 concernent les instructions de débranchement (if, switch) et les instructions de boucles (for, while, do). C’est reposant et on apprends 2 ou 3 trucs au passage, comme les règles de résolution d’ambiguïté !
Le chapitre 7 revient sur les déclarations, mais plus précisément sur les spécifiers ! C’est l’occasion d’en apprendre plus sur les inline, friend, typedef et autres volatile (la bête noire des langages). Les annotations qui suivent donnent quelques lumières sur extern « C » et sur les fameux « name mangling » qui m’ont causé tant de tracas par le passé !
Le chapitre 8 sur les déclarations n’est pas d’un abord trop compliqué. Il traite aussi bien des déclarations de variables et de fonctions (et de classes), que ce soit par valeur, par pointeur ou par référence. Pas grand chose à en dire.
Le chapitre 9 était très attendu : il traite des classes ! Même si le sujet se poursuit au chapitre suivant, celui-ci fournit une bonne couverture du sujet, qui ne se limite pas aux déclarations mais couvre aussi (par exemple), la gestion du pointeur this, les déclarations friend ou les classes imbriquées. Les classes dérivées sont traitées au chapitre 9 et on rentre à fond dans le sujet, avec des héritages simples, multiples en branches ou en diamant et même circulaires ! Le chapitre 11 qui clos le sujet est une petite balade de santé traitant des fameux public, protected et private mais aussi de l’inénarrable « friend » !
Le chapitre 12 nous parle des fonctions membres spéciales. Elles forment des aspects alambiqués du langage mais leur connaissance est précieuse : destructeur, constructeur (par défaut, à un argument ou de copie), opérateurs de conversion et opérateurs d’allocation / désallocation. Un propos très complexe à suivre mais combien important !
La surcharge n’est pas mon mécanisme préféré, bien qu’il rende des services. Les 30 pages de ce chapitres 13 vous feront comprendre combien ce mécanisme n’est pas trivial, quand il s’agit de comprendre « l’argument matching ».
C’est une surprise de ne voir que 10 pages à peine consacrées aux templates dans ce chapitre 14, tant les déclinaisons de ce mécanisme s’avèrent complexes. Mais à cette époque, on en est qu’aux balbutiements du sujet. De nombreuses sources plus récentes donneront des informations plus complètes et à jour.
Les exceptions, traitées au chapitre 15 sont aussi un sujet « récent ». Il est plus simple et traité ici sur 13 pages, donc finalement plus décemment. Mais ce n’est pas encore formidable. Là aussi on trouvera sans peine de meilleures sources.
C’est une surprise de voir ici ce chapitre 16 consacré… au préprocesseur ! Il est vrai que ce vieux mécanisme du C perdure au C++ (on ne peut hélas l’éviter pour un certain nombre de choses…). Le point d’orgue de ce chapitre, c’est quand Bjarne Stroustrup nous montre l’apparence d’une chaine ANSI sur un terminal… Danois !
Le chapitre 17 sent la fin de l’ouvrage : il s’agit d’un résumé de la grammaire sous la forme d’une BNF. En fait celle-ci est incomplète : la seule partie concernant les expressions devrait à elle seule noircir une bonne dizaine de pages… Le chapitre 18 couvre quelques pages à évoquer la compatibilité entre le C++ et le C, mais aussi avec la version de C++ de 1985 !
La quinzaine de pages du chapitre 19 évoque les futures résolutions ANSI/ISO. On y trouve pêle-mêle la gestion des namespaces (et bien sûr la clause using) et aussi les nouveaux types de casts. Je dois certainement en oublier…
La lecture de ce livre est disons… challengeante ! Le style est tout sauf abordable, mais certains points de détail y sont abordés avec grande précision et restent valables aujourd’hui. Toutefois, l’utilité de ce livre est moins criante désormais, voire sans objet, car le document normatif peut le remplacer. Ce dernier est plus à jour et aussi plus complet et détaillé. Cet ouvrage n’a donc plus qu’un intérêt historique.
Référence complète : The Annotated C++ Reference Manual – Margaret A. Ellis & Bjarne Stroustrup – Addison Wesley 1991 – ISBN: 0-201-51459-1
Software Freethinker 
