Catégorie : Notes de lecture

Note de lecture : Analyse et conception orientées objet 2ème édition, par Grady Booch

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; Un grand classique, bien écrit, mais qui souffre de son âge.

Comme son édition précédente, ce livre souffre de l’arrivée de la trilogie UML C’est néanmoins un véritable livre méthodologique qui couvre les mêmes aspects que l’ouvrage de Rumbaugh. Son contenu informatif est plus faible et la notation plus éloignée d’UML que ne l’est OMT, mais le style de l’auteur est beaucoup plus agréable et vivant, ce qui en fait un ouvrage plus abordable pour les personnes encore peu familières avec les méthodes. La traduction Française qui figure dans ma bibliothèque compte 500 pages de texte principal, soit 12 chapitres (regroupés en 3 parties) auxquelles il faut ajouter 100 pages d’annexes. Il fut une époque où les traductions Françaises étaient particulièrement pitoyables, nous sortons juste de cette époque, mais cette traduction reste largement perfectible. Une troisième édition de cet ouvrage est sortie depuis, où vous ne trouverez hélas pas le plaisir des petits nuages de notation Booch (ce sera de l’UML) je vous la recommande cependant en lieu et place.

Mais voyons un peu ce que la bête a dans le ventre.

La première partie s’intitule « concepts », et ses 180 pages comprennent 4 chapitres. Le premier chapitre traite de la complexité, quelle est sa nature et comment se manifeste-t-elle dans un système logiciel, pour nous donner ensuite les clés de sa gestion : l’abstraction et les hiérarchies. C’est en quelque sorte une introduction aux chapitres suivants mais aussi une réflexion profonde particulièrement bien menée.

De l’abstraction au modèle objet, il n’y a qu’un pas. Et c’est de cela que traite le chapitre 2, en abordant la chose par l’histoire des langages, comment ils nous ont mené progressivement à ce concept. Le concept d’objet et de niveau d’abstraction (avec un curieux mélange entre abstraction et hiérarchies) est ensuite exploré et illustré.

Le chapitre 3 qui traite des objets et des classes est particulièrement important, en contenu comme en taille (65 pages). On y explores les différents aspects d’une classe : attributs, relations, états et interactions. Le tout abondement illustrés de diagramme Booch, mais aussi de fragment de code C++. Le parti pris de l’auteur se focalise en effet plus sur la conception que sur l’analyse.

La partie analyse, justement est abordée au chapitre 4, par les biais des classifications. Le traitement en est plus léger puisqu’il ne couvre que 25 pages !

La seconde partie du livre est consacrée à la méthode. On en prend pour 125 pages et 3 chapitres. Le premier d’entre eux (le chapitre 5, donc) est consacré à la notation. On y voit en détail les diagrammes de classes et leurs subtilités, les diagrammes d’état et les diagrammes d’interaction (ce sont ceux d’UML). Le chapitre se termine sur les « concepts avancés » : diagrammes de modules et sa variante en sous-systèmes et diagrammes de déploiement. Ils sont assez frustres et n’ont guère évolué après avoir été réutilisés tel quel dans UML.

Le chapitre 6 aborde la partie « processus » de la méthode. Grady Booch ne nous embête pas beaucoup avec cela car il évacue la chose en 37 pages ! L’approche de l’auteur est plus proche de celle d’UP que d’OMT en cela qu’elle identifie d’une part les principes généraux (approche itérative, vision architecturale) et un micro-processus lié à l’identification des objets, essentiellement à l’aide de cartes CRC. Vient ensuite l’identification des relations et de la dynamique. Le macro-processus reprends lui les grandes phases qui sont assez proches des phases d’UP mais pas complètement.

Les 25 pages du chapitre 7 « soyons pragmatiques » sont consacrées en fait à la gestion de projet : comment gérer les risques, quels sont les rôles, la gestion des versions, etc.. Sans être grandiose, ce chapitre contient quelques éléments intéressants, par exemple sur les métriques.

La 3ème partie, « applications » est longue de 90 pages et contient 5 chapitres. Au menu du premier d’entre-eux, donc au chapitre 8, un système de surveillance météorologique, qui va nous tenir éveillés 35 pages. L’exemple est un peu idéalisé. On le suit depuis la définition du contexte (et du contour du problème) jusqu’à l’implémentation. Disons que c’est une petite ballade sympathique.

L’exemple du chapitre 9 est très différent, on y suit sur 55 pages la construction d’une bibliothèque de classes, en l’occurrence une librairie de conteneurs. Si en suivre la conception progressive est en soi intéressant, l’apport de la démarche est ici au mieux en filigranes. Et en fait, même les diagrammes ne servent pas à grand chose.

Retour à un système plus classique au chapitre 10 : une gestion de stock en client-serveur. Si le diagramme de déploiement est bien utilisé au début, c’est surtout l’emploi des diagrammes d’interaction et le mapping objet-relationnel qui nous intéressent plus ici.

L’exemple du chapitre 11 est très loin d’être convainquant, car il a trait à l’intelligence artificielle (très en vogue à cette époque). Justement l’emploi d’une méthode paraît tout à fait artificielle ici, et cela ressemble plutôt à de la justification à postériori qu’une aide réellement délivrée par une approche structurée. Passons !

Le système de gestion de trafic du chapitre 12 ne semble pas apporter grand chose par rapport aux autres exemples. Ce qui est abordé ici ressemble beaucoup au chapitre 10. Passons également.

Grady Booch sait écrire et cela, lié aux réflexions qu’il soulève rend le livre intéressant. De mon point de vue, environ 70% du livre est aujourd’hui obsolète, de par UML d’une part et du fait de la montée des approches agiles d’autre part. Le texte consacre une majeure partie de la démarche à la conception, ce qui le place naturellement en complément (du moins en grande partie) d’OMT et rends une partie du propos toujours d’actualité et peut-être même à rapprocher de certains textes de Robert Martin. La traduction Française a grandement progressé sur cette édition mais reste largement perfectible, tandis que le texte de la première édition était lui parfaitement illisible ! Il existe une 3ème édition assez récente. Je serais assez curieux de voir comment le propos a évolué…

Analyse & Conception Orientées Objects

Référence complète : Analyse et conception orientées objet, 2ème édition – Grady Booch – Addison Wesley 1994 (V.O. : Object-Oriented Analysis & Design ; Benjamin-Cummings 1994 ; ISBN : 35340-2) – ISBN : 2-87908-069-X

Analyse et conception orientées objet


http://www.goodreads.com/book/add_to_books_widget_frame/287908069X?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : La qualité en C++, par Philippe Prados

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Un excellent ouvrage regroupant règles, conseils et nombre d’idiomes.

On n’a pas l’habitude de chercher des livres allant au-delà du niveau initiatique chez les auteurs français. A juste titre, malheureusement. Celui-ci fait exception. Cet ouvrage à taille humaine (environ 300 pages), regroupe un ensemble de conseils et de règles en C++, intégrant des idiomes parfois créés par l’auteur. La bête se présente sous forme de 9 chapitres, donc en moyenne un peu plus conséquents que ce que j’escompte. J’oublie les 10 pages d’annexes.

Le premier chapitre parle de rappels. On y trouve pèle mêle des questions sur le partage d’objets pointés, d’ownership, de questions afférents à la destruction, à la notation ou au constructeur de conversion. Ca manque un peu de logique. On ne peut qu’espérer que le meilleur soit à venir.

Au chapitre 2, on trouve des conseils assez sibyllins sur la conception d’une classe. L’auteur ne développe pas les points, mais beaucoup sont pertinents au-delà du bon « bon sens intuitif » : pas d’attributs de type référence ou mettre à disposition la copie d’objet si aucun attribut ne stigmatise son identité (tout le monde ne sera pas d’accord là-dessus, mais je le suis).

Le chapitre 3 est nettement plus important : il adresse les « patterns de programmation », donc en fait les idiomes et taille 70 pages ! Ce chapitre, c’est un peu la trousse à outil de l’auteur avec son savoir-faire. Et ce savoir-faire est de bon niveau ! Il faudra ne pas être totalement néophyte toutefois pour en faire usage. D’abord parce que les explications, si elles tentent d’être didactiques sont plus empreintes du style IBM que du style Scott Meyers, disons… Ensuite, il faut garder un regard critique. Par exemple l’idiome sur le constructeur copie est erroné…

Au chapitre 4, on trouve quelques principes de codage orientés compilation qui ne sont pas sans rappeler le « large scale C++ design » de Lakos. J’aime bien le tableau sur l’usage des références, entre autre chose.

Le chapitre 5 nous parle de debug. On commence par les traces et l’auteur nous donne quelques conseils sur la surcharge de l’opérateur « >> ». Puis on aborde les choses sérieuses avec la surcharge de new pour traquer la mémoire. Là aussi la prudence s’impose car le programme peut ne plus se comporter à l’identique avec et sans debug (vous me direz que c’est déjà le cas…).

Les chapitre 6 et 7, c’est un peu le col du Galibier de ce livre. Du moins, le 7 est la première côte de l’ascension. L’auteur y énumère des règles de code « prêt à l’emploi » qui sont détaillées au chapitre au chapitre 8. Ce sont dans les 80 pages de ce chapitre que Philippe Prados déploie son expertise, et c’est ce chapitre qui justifie l’achat du livre. Si vous ne devez lire qu’un chapitre c’est celui-ci. J’approuve la plupart des règles, j’ai même parfois appris quelque chose (eh oui !) et les explications sont claires pour peu que vous ne soyez pas grand débutant.

Le chapitre 8 consacré aux tests accuse son âge. Il se focalise d’abord sur les notions de préconditions / postconditions et invariants tels qu’on les trouvent dans Eiffel. Puis l’auteur nous propose une implémentation de tests unitaires, qui n’a plus guère d’intérêt aujourd’hui avec des libraires telles que CppUnit.

Au chapitre 9, on démystifie certains mécanismes du C++. Bonne idée ! Au programme : les héritages simples, multiples et virtuels. Tout naturellement on voit dans la foulée le mécanisme des table vptr des méthodes virtuelles. La gestion des exceptions et des inlines complètent le tableau.

Les explications sont assez claires et l’auteur parvient tout à fait à faire passer son expertise (de niveau élevée) du langage. Les recommandations énoncées ont souvent un caractère subjectif, on y adhèrera ou pas mais même dans ce dernier cas on profite des raisonnements et de l’expertise de l’auteur. Disons le tout net, c’est le seul ouvrage d’un auteur Français sur le C++ qui soit d’un niveau honorable ! Un excellent livre, à classer dans la catégorie “manuels de référence”.

La Qualité en C++, par Philippe Prados

Référence complète : La qualité en C++ – Philippe Prados – Eyrolles 1996 – ISBN : 2-212-08917-1

La qualité en C++


http://www.goodreads.com/book/add_to_books_widget_frame/2212089171?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : OMT, Modélisation et conception orienté objet, par James Rumbaugh & al.

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Un livre dense, presque indigeste (tout comme le style), mais bourré d’information. Book of the year 1996 !

OMT est LA méthode sur laquelle a été construit UML, et doit constituer environ 70% de cette notation. Ce livre est évidemment la référence sur le sujet. Les 500 pages qui le constitue sont très dense (aussi bien du point de vue informatif que du point de vue typographique) et traite les aspects méthodologiques sur un spectre très large : notation, analyse des besoins, conception, développement, mapping vers les bases de données, etc… Cette masse d’information est structurée en 20 chapitres regroupés en 4 parties. 50 pages sont consacrées aux annexes.

Une courte introduction nous remet dans le contexte de l’appréhension de l’objet en ce début de décennie 90 : elle accorde moins de place à l’analyse fonctionnelle et dissocie fortement modèle d’analyse et modèle de conception (l’implémentation, c’est encore autre chose) avec une prédominance pour le modèle d’analyse ! Bien entendu, sur les modèles objets, une importance ridicule était aussi portée aux arbres d’héritages : plus ils sont profonds, plus ça fait virile !

La première partie aborde les concepts de modélisation. Le tarif est de 5 chapitres et 130 pages. On commence par un chapitre 2 ultra court qui nous donne les définitions des différents modèles. Ce qui doit être dedans et ce qui ne doit pas l’être est très clair. Ca rigole pas. Au chapitre 3, on passe en revue la notation des diagrammes de classes, mais surtout toutes les subtilités concernant les associations (multiplicités, noms d’association et de rôles, agrégations, généralisations, qualifiers, attributs et associations n-aires). S’il est complet, le texte reste très touffu et pas réellement prévu pour être pédagogique. Mais comme c’est ainsi tout au long du livre, je vais arrêter de le dire. Le chapitre 4 prolonge le 3 avec des concepts avancés que l’on retrouvera plus tard dans UML : notions d’héritage disjoint, de contraintes, etc… On aborde enfin le modèle dynamique au chapitre 5. On s’y focalise sur les diagrammes d’état et on n’y va pas avec le dos de la cuillère ! On y trouve tous les trucs tordus qui ne servent qu’à quelques zombies du temps réel (et qui a fait les beaux jours de certains cours Valtech). Enfin le chapitre 6 vaut le détour car on n’y parle du modèle fonctionnel (modèle de traitements, mais surtout flots de données) qui n’ont pas été du tout (heureusement) retenus dans UML. A mon humble avis, c’est inexploitable.

La seconde partie va nous occuper sur 6 chapitre et couvre aussi 130 pages. Elle va traiter de méthode de conception. Comme pour la partie précédente, on commence par un chapitre 7 qui présente la méthode OMT dans ses grandes lignes. Car à cette époque, méthode et notation étaient deux concepts liés, tout le temps ! Le chapitre 8 aborde l’analyse, l’aspect le plus important d’OMT. Le recueil des besoins est balayé en 2 pages, pourtant on y trouve de petites remarques pleines de finesses mais qui ont disparu lors des mises en œuvre. La démarche est guidée et illustrée par une étude de cas : le guichet automatique de banque : on passe des classes candidates au modèle objet, que l’on raffine. Puis un modèle dynamique (un diagramme d’état) met en musique les scénarios évoqués. Et hop ! grâce à ça, on obtient les opérations que l’on n’a plus qu’à ventiler sur les classes ! Elle est pas belle la vie ? Le chapitre 9 parle de conception. En principe. On voit bien que ce n’est pas le trip des auteurs car ça part un peu dans tous les sens : sous-systèmes, partitionnement, couches, infrastructure matérielle ( ??). Bref, on s’est senti obligé d’y mettre quelque chose, sinon c’est pas crédible. Le chapitre 10 est un guide de conception des classes, pour les auteurs, c’est un retour en terrain connu, mais pour le lecteur c’est assez difficile d’emboiter cela avec le chapitre 8…  Le chapitre 11 résume les étapes de la méthode vu précédemment. C’est très clair et franchement une bonne idée. On conclu cette partie par une comparaison des méthodes. Je pensais voir un chapitre tarte à la crème, j’ai été (agréablement) surpris : les auteurs font un travail méticuleux de comparaison avec les approches structurées (SA/SD, Jackson), orientées entités (ER de Chen) et orientées objet (Booch, Yourdon, schlaer et Mellor). Ils mettent en avant chaque fois les atouts et les faiblesses, voir les complémentarité par rapport à OMT. J’ai rarement vu un travail de cette qualité.

La troisième partie nous parle d’implémentation, et sur 5 chapitres et 120 pages. Comme à l’accoutumée, le chapitre 13 sert d’introduction. On parlera d’implémentation par des langages de programmation, sur des bases de données et même au-delà des ordinateurs ! Le chapitre 14 va parler de style de programmation et je m’attends au pire. Et c’est le choc, car on n’y trouve rien de moins que ce que l’on trouvera bien des années plus tard sous la plume de Robert C. Martin ! Bravo ! Le chapitre 15 évoque la transformation de modèles vers des langages objet tels que C++, Eiffel et Smalltalk. Tout ce ci ne m’apprends rien, mais les auteurs ne prennent pas les chemins de traverse et font remarquablement bien le boulot ! C’est au tour des langages non objet au chapitre 16, en l’occurrence C, Ada et Fortran. Là aussi, un grands coup de chapeau pour la qualité du travail, qui est ici plus difficile. On se tourne vers les bases de données au chapitre 17. J’ai moins été impressionné ici, mais le boulot est fait.

La quatrième partie est plus courte, elle ne compte que 3 chapitres sur moins de 50 pages. Le chapitre 18 traite d’une application développée chez GE (où travaillait alors James Rumbaugh) : un compilateur de diagramme. J’avoue ne pas avoir été convaincu. Au chapitre 19 on voit rapidement un système de conception d’animation, l’occasion pour les auteurs de parler rapidement de la mise en œuvre de la méthode sur la partie analyse. Enfin, au chapitre 20, c’est une petite étude de cas sur la distribution d’électricité. Cette dernière partie ne m’aurait pas manquée si elle n’avait pas été là.

De nombreux aspects de ce livre sont d’un autre temps, comme le couplage indissociable entre méthode et notation, ou l’emphase exagérée sur le modèle d’analyse, un traitement grotesque du recueil des exigences et un quasi mépris pour la conception. Tout ceci ne me manquera pas, je n’ai jamais été en phase avec cette façon de voir. Pourtant le livre mérite l’intérêt à plusieurs égard. D’abord parce qu’il est simplement le meilleurs représentant de cette époque. Ensuite car de nombreux sujets sont traités avec finesse, rigueur et profondeur. Les auteurs ne mégottent pas sur la qualité de l’information. Enfin, OMT constitue la majeure partie de la notation UML. Et si des livres (de nombreux livres) couvrent la notation, cette seconde vie a en quelque sorte prolongé la pertinence de celui-ci. Toutefois, c’est surtout l’aspect historique qui nous retiendra aujourd’hui.

OMT, par James Rumbaugh

Référence complète : OMT, Modélisation et conception orienté objet – James Rumbaugh, Michael Blaha, Frederick Eddy, William Premerlani & William Lorensen – Masson 1995 (V.O. Prentice Hall 1991) – ISBN : 2-225-84684-7

Omt, Tome 1: Modélisation Et Conception Orientées Objet

http://www.goodreads.com/book/add_to_books_widget_frame/2225846847?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : The C++ Programming Language 3rd edition, par Bjarne Stroustrup

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; En net progrès depuis la 2nd édition, mais encore fort confus.

Bien que très abondamment vendue, la seconde édition de cet ouvrage de référence ne pouvait se vanter d’être un livre incontournable. Le propos de l’auteur étant à la limite de la confusion, et les références multidirectionnelles (aussi bien vers l’avant que vers l’arrière) incessantes ainsi que les exemples incomplets en faisaient un ouvrage pratiquement inabordable pour les nouveaux venus au langage. Bref, il était loin d’offrir un pendant au célèbre ouvrage de Kernighan et Ritchie. Cette nouvelle mouture (qui ne l’et plus désormaisn, car il existe une 4ème édition) s’est grandement améliorée, même si elle est loin de faire taire les critiques énoncées ci avant : le propos de l’auteur est devenu plus clair, l’ouvrage s’est étoffé, et pas qu’un peu avec ses 900 pages, et il traite du C++ standard (avec toutes les nouveautés) y compris la librairie standard. En venir à bout relève du marathon, fort heureusement l’auteur a pensé aux étapes : le livre se découpe en 25 chapitres regroupés en 4 parties.

Avant même la première partie, 3 chapitres d’introduction dont un « tour du C++ » et un « tour des librairies » donnent (ou devraient donner) un bon aperçu du langage. Las, on passe très vite de sujet en sujet sans forcément comprendre comment on en est arrivé là : des templates aux containers en passant par les Stream, on a effectivement un aperçu, mais en accéléré ! On rembobine pour se remettre sur la ligne de départ !

La première partie « basic facilities » couvre 6 chapitres sur 150. Au programme : types et déclarations (chapitre 4), pointeurs, tableaux et structures (chapitre 5), expressions (chapitre 6), fonctions (chapitre 7), exceptions et namespaces (chapitre 8) et fichiers sources et programmes (chapitre 9). Déjà ça va mieux, la progression est moins décousue. La plupart des exemples de code sont assez courts et ils sont aussi très nombreux. Ils comptent pour environ la moitié du texte. Nonobstant, l’auteur ne peut s’empêcher d’utiliser des « petits trucs rigolos » dans ses exemples de code, qui ne font rire que lui : utilisation des iostreams, des références sur … eh bien on ne comprend pas trop quoi, des nommages façon vieil Unix sur une ou deux lettres qui rendent les exemples de code très hermétiques.

C’est aussi 6 chapitres pour la seconde partie « abstraction mechanisms », mais avec un tarif de 225 pages, cette fois. On a à l’affiche : classes (chapitre 10), surcharge d’opérateur (chapitre 11), classes dérivées (chapitre 12), templates (chapitre 13), gestion d’exception (chapitre 14) et hiérarchies de classes (chapitre 15). Ca recommence presqu’humainement au chapitre 10, n’était-ce l’incurable habitude du créateur du C++ de rentrer tout de suite dans les arcanes complexes du langage. Bien sûr le chapitre sur la surcharge d’opérateurs n’arrange rien, on côtoie rapidement le cas des opérateurs globaux friends, par exemple. L’héritage couvre non seulement les cas simples, mais aussi les classes abstraites (donc les méthodes virtuelles pures) et bien entendu l’héritage multiple. Les exemples me donnent surtout l’impression d’arriver à rendre ardu un sujet que je maitrise maintenant très bien. Tout cela me laisse craindre le pire quand au chapitre sur les templates. Mais si celui-ci ne fait pas de cadeau, il s’arrête à un niveau de complexité appréhendable par le commun des mortels. Les deux derniers chapitres de cette première partie sont une heureuse surprise. En fait, l’explication sur les hiérarchies de classes où l’on voit aussi l’héritage en diamant et l’héritage virtuel est même un exemple de pédagogie !

La 3ème partie aborde enfin la librairie standard : on en prends pour 7 chapitres et 260 pages. Des chapitres 16 à 19, on traite de la STL, puis viennent les String (chapitre 20), les Stream (chapitre 21) et les Numeric (chapitre 22). La STL est une librairie complexe et on ne peut reprocher à Bjarne Stroustrup de faire des impasses, mais s’y retrouver ici relève de la gageure. Heureusement j’ai en réserve d’autres références qui font mieux à cet égard ! Le chapitre sur les String nous permet de souffler… et même de comprendre ce que sont les traits ! Mais les Stream, sujet déjà difficile en soit nous assure la noyade. Avec les Numeric, c’est à peine mieux.

La dernière partie est dévolue à des considérations de conception. Elle se contente de 3 chapitres et 110 pages. Le chapitre 23 n’a même pas de code, et les deux suivant moins qu’il n’est de coutume. C’est le moment pour le père du C++ de dispenser un cours de programmation et de conception. Ce n’est pas sans intérêt, mais le Dr Stoustrup reste un pédagogue assez moyen…

Le grand mérite de cet ouvrage est d’avoir été le premier à paraître et à faire figurer ces éléments “up to date”. Depuis, est sorti la 3ème édition du “C++ primer” de Stan Lippmann (épaulé cette fois par Josée Lajoie), encore plus volumineux, et qui dépasse, sans coup férir, le livre de Bjarne Stroustrup par sa qualité. Bien sûr le « C++ 11 » est aussi arrivé depuis. L’occasion de publier 15 ans après une 4ème édition qui pèse le monumental volume de 1400 pages !

Difficile de recommander ce texte : il est difficile d’abord. Il nécessite souvent de relire 2 ou 3 fois un passage pour le comprendre. L’auteur n’a guère pitié de nous car les exemples, s’ils sont courts et nombreux surabondent en éléments connexes qui ne sont généralement pas connus et compliquent la compréhension. Il reste aussi un fervent de ce que j’appelle les « références en avant ». On ne pourra pas reprocher à l’auteur de faire l’impasse sur quoi que ce soit, mais que c’est dense. Chaque chapitre se termine par des conseils et des exercices. J’avoue ne pas avoir eu le courage de les faire. Par contre, les citations au début de chacun d’entre eux sont particulièrement pertinentes et savoureuses. Bref, une bonne lecture pour masochiste.

c++-prog-lang-stroustrup

Référence complète : The C++ Programming Language (3rd edition) – Bjarne Stroustrup – Addison Wesley 1997 – ISBN: 9780201700732

The C++ Programming Language


http://www.goodreads.com/book/add_to_books_widget_frame/0201700735?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : The Ingres Papers, Michael Stonebraker edt.

Le par addinquydans Notes de lectureLaisser un commentaire

Note 4 :Les principes fondamentaux d’architecture d’une base de données… d’il y a 30 ans !

Il fut un temps où la course entre les bases de données relationnelles se jouait entre Oracle et Ingres ! Ce temps est passé, Oracle a gagné. Ecrit par le père de Ingres (INteractive Graphics and REtrieval System), ce livre rassemble des articles détaillant l’architecture les problématiques et choix techniques d’Ingres. Comme on peut s’y attendre (Michael Stonebraker est professeur à Berkeley), les articles ont une coloration très académique. L’ensemble des 22 articles couvrant 425 pages sont regroupés en 6 sections :

  • Section 1 : Design of relational systems : Cette section relate les choix fondamentaux d’Ingres, la rétrospective sur les choix et erreurs faits durant la conception d’Ingres.
  • Section 2 : Supporting studies on relational systems : Cette section aborde des problématiques spécifiques sur les bases de données telles que le verrouillage, les performances, le système de gestion des requêtes et l’interface avec l’operating system. De nombreux point de recherches d’optimum sont abordés (granularité de verrouillage, taille de cache), d’optimisation de compilation, etc..
  • Section 3 : Distributed database systems : Cette section rassemble des articles sur des aspects avancées d’Ingres : répartition physique des données, gestion des requêtes distribuées redondance et commit sur plusieurs bases.
  • Section 4 : User interface for database systems : Cette section relate le développement d’un language de requête interactif (EQUEL) sur Ingres et d’un portail, sorte de buffer de requêtes prêtes à être utilisées. Les principes de construction de Schémas de base et de constructions d’applications à l’aide de formulaires (FADS) terminent cette section.
  • Section 5 : Extended semantics for the relational model : Cette section explore de nouvelles sémantiques au-dessus de la sémantique relationnelle, telles que la conception assistée par ordinateur ou la gestion de relations hypothétiques qui sont des sortes de « vues » sur les relations. Un autre sujet d’intérêt est la gestion des documents, permettant non seulement la gestion d’information de grande taille, mais également leur manipulation (recherche, division ou concaténation).
  • Section 6 : Database design : Cette section aborde quelques questions avancées tels que la conversion d’un modèle logique en modèle physique ou la recherche de chemins d’accès sur la base.

Les sujets abordés dans ce livre accusent clairement le poids des ans ! Il n’en reste pas moins que lorsque l’on a un peu la fibre du chercheur, ces sujets font envie et donnent envie d’aller regarder comment ces problèmes sont abordés dans les bases de données modernes ! Le niveau du propos reste souvent obscur au béotien, hélas, dû au fait qu’il s’agit d’articles de recherche. Aussi décroche-t-on souvent du texte et c’est dommage ! C’est aussi ce qui justifie ma note un peu sévère. J’aurais préféré un texte reformulé afin de le rendre plus abordable, ceci sans dégrader sa teneur technique. Les texte universitaires se font trop souvent un point d’honneur à être hermétiques !

Ingres-papers

Référence complète : The Ingres Papers, Anatomy of a relational database system – Michael Stonebraker edt. – Addison Wesley 1986 – ISBN : 0-201-07185-1

The Ingres Papers: Anatomy of a Relational Database System

http://www.goodreads.com/book/add_to_books_widget_frame/0201071851?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Stratégies & tactiques C++, par Robert B. Murray

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Des conseils d’expert sur l’utilisation avancée du C++, pour le développeur émérite. N’est toutefois pas à la hauteur des ouvrages de Scott Meyers.

Ce livre fait également partie de la série à laquelle appartiennent les ouvrages de Tom Cargill et Scott Meyers. Il s’agissait à l’époque de produire une série d’ouvrage donnant des avis d’experts. Si « effective C++ » donna non seulement naissance à une série de texte mais aussi inspira d’autres auteurs, celui-ci reste plus qu’honorable. Ecrit par le créateur de C++ Report et chroniqueur de “C++ obfuscated” dans cette même revue, ce livre s’attaque à des préoccupations très techniques : effet de bord des initialisations, de l’héritage virtuel, etc… Chaque chapitre se termine par un paragraphe “En bref” qui résume celui-ci, et par un paragraphe “Questions” qui permet au lecteur de faire le point sur ses connaissances acquises.

C’est la traduction Française que j’ai acquise. Dans cette version, le livre compte quand même 280 pages réparties en 11 chapitres.

Plus que de langage, c’est de conception dont nous parle le chapitre 1 et plus particulièrement d’abstraction (et aussi d’héritage, donc). Mais point de code C++ ou à peine, mais un bref aperçu des cartes CRC.

Long de plus de 40 pages, le chapitre 2 évoque les classes et de nombreux aspects de conception et de comportements qui tournent autour : constructeurs par défaut ou de copie (et donc forcément opérateur d’affectation), on y traite précisément la différence entre initialisation et affectation. Bien d’autres subtilités (constance, membres de type référence, etc…) sont couvertes. Je trouve un peu dommage que l’auteur, s’il présente avec brio le comportement du langage ne prenne pas plus position.

Le titre du chapitre 3 est un peu abscons car il parle de « descripteurs », en fait il s’agit de stratégies de pointeurs intelligents tels que le « copy on write » ou le comptage de références. L’utilité pratique de ces techniques a baissé avec le temps, du fait de la baisse des coûts d’allocation, de l’augmentation des tailles mémoire, mais surtout de l’avènement du multi-threading et des architectures multi-cœurs. Mais la compréhension de ces mécanismes reste un excellent exercice, lui-même excellemment expliqué.

Le chapitre 4 traite en profondeur le cas de l’héritage simple, qu’il soit public, privé… ou protégé. C’est l’un des rares ouvrages de ma connaissance traitant de ce dernier cas il est vrai pas très utile. L’auteur n’oublie pas de parler des méthodes virtuelles et virtuelles pure et explique précisément le fonctionnement des constructeurs et destructeurs dans ces situations. Rien à redire.

C’est à l’héritage virtuel qu’est consacré le chapitre 5 et seulement à cela. Bob Murray utilise abondamment les diagrammes de Venn pour expliquer les principes sous-jacents. Bien sûr on n’échappe pas à l’héritage en diamant et à son corolaire : l’héritage virtuel. Si le cas de classes de bases héritées différemment (public, protégé, privé) est mentionné, l’auteur ne rentre pas dedans plus avant, par contre il évoque la dominance d’héritage ce qui est rare. Ici aussi, l’auteur excelle à expliquer les choses en détail, mais moins à prendre position.

C’est toujours d’héritage dont il est question au chapitre 6. Ici l’auteur rentre dans des questions de conception : quand et comment concevoir pour l’héritage ? L’héritage peut-il induire des comportements erronés ? Et plus précisément comment se comportent constructeurs et destructeurs. J’ai été surpris de ne pas voir évoqué l’héritage privé dans le cas de classes fournissant des services non virtuels aux classes dérivées, et de ne pas voir trace de l’usage du « template method ».

Le chapitre 7 est le premier à évoquer les templates. On reste en zone de sécurité avec la démonstration de template sur des smart pointeurs ou sur des fonctions. Les exemples de code deviennent aussi non triviaux. A l’époque où le texte fut écrit, le comportement des templates était peu spécifié, on n’est donc pas étonné de ne pas voir l’auteur y entrer en profondeur. L’impact sur l’instanciation de code est toutefois débattue.

C’est encore de templates dont parle le chapitre 8. Faisant suite au chapitre précédent, celui-ci est entièrement dévolu aux problématiques d’implémentation de conteneurs avec des éléments homogènes ou non et aux sémantiques de conteneurs par valeur ou par référence. Une lecture franchement difficile à suivre.

On passe aux questions de réutilisabilité au chapitre 9. Ici on se situe plus au niveau des pratiques permettant la réutilisation au niveau d’une classe : celle-ci est-elle bien documentée, avec de bons nommages ? Qu’en est-il de sa robustesse, celle-ci est-elle éprouvée avec des assertions (on ne parlait pas de tests unitaires à cette époque) ? Une grande partie du chapitre est dédiée aux questions de débogage et comment rendre son code monitorable dans ces conditions. La partie consacrée aux allocateurs et à la façon de les rendre parlant est particulièrement intéressante, y compris aujourd’hui.

On ne pouvait échapper à un chapitre consacré aux exceptions. C’est le chapitre 10. La prose n’est pas exceptionnelle, si je puis dire, même si c’est la première fois qu’on y évoque le « les exceptions doivent être exceptionnelles ».

Le livre se termine avec un chapitre sur la migration d’applications vers C++. Il s’agit en fait de considérations et d’un ensemble de conseils (de bons conseils) pour ceux passant du C au C++.

Cette ouvrage est d’une lecture aisée, du moins pour le développeur déjà expérimenté en C++, et se consomme rapidement en une semaine ou deux, ce qui n’est pas la moindre de ses qualités. La petite surprise est que le texte ne se focalise pas uniquement sur le langage mais aussi sur son usage et sur une bonne compréhension de la conception : qu’est-ce qu’une bonne classe, une bonne abstraction, etc… Le texte mériterait un bon rafraichissement car il accuse maintenant 2 décennies, mais il reste de très bonne tenue.

cpp-strategies-tactics

Référence complète : Stratégies & tactiques C++ – Robert B. Murray – Addison Wesley 1994 (V.O. : C++, Strategies & Tactics ; Addison Wesley 1993 ; ISBN : 9780201563825) – ISBN : 2-87908-066-5

C++ Strategies and Tactics

http://www.goodreads.com/book/add_to_books_widget_frame/0201563827?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Conception orientée objet, pratique de la méthode HOOD par Michel Lai

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 3 ; Dense et pas très engageant

Bien sûr, aller regarder aujourd’hui un texte aussi ancien n’a pas forcément beaucoup de valeur (quoique certains textes vieillissent fort peu). Non, ici la motivation est historique, car ce livre est l’un des seuls traitant de la méthode Hood, spécifiquement développée pour le langage Ada.

L’ouvrage débute par une introduction à la conception objet et aux objets, assez formelle je dois dire, mais illustrée de code Ada. Vient ensuite la présentation de la méthode Hood proprement dite. Celle-ci n’est pas didactique à mon goût, car les éléments sont présentés sous l’angle de leur définition, c’est difficile à digérer, même si je dois admettre que ce n’est certainement pas une approche superficielle. Curieusement, si des exemples de syntaxe Hood sont fréquemment fournis, ce n’est pas le cas de la notation graphique ! Petite curiosité : en plein milieu de l’ouvrage, un chapitre est consacré à un outil : HyperHood ! Généralement, ce genre de chapitre est mis en fin d’ouvrage, voir en annexe, mais comme on dit : on va survivre à ça. La lecture reprend avec un chapitre complémentaire sur la méthode, que j’aurai vu personnellement en tête d’ouvrage, car elle illustre (enfin) la méthode avec un cas d’utilisation : le poste de conduite d’une voiture. Hood+ et H+ complètent le tour d’horizon de la méthode avec ce faisant un retour au style rébarbatif, accompagnés de chapitres sur des métriques et des retours d’expérience.

On ne saurait prétendre que ce livre est creux : au contraire, il y a pas mal de matière, c’est même un peu dense à la matière d’un porridge. Et tout aussi indigeste, d’ailleurs. Si vous souhaitez vous cultiver, et avoir juste une idée de Hood, vous trouverez ce livre peu engageant : il n’y a pas de doute, pour rentrer dans ce livre, il faut de la volonté. Je soupçonne que celui-ci ait été conçu comme complément à un cours magistral, ce qui expliquerai bien des choses… Bref : pas très engageant, mail il y a pire…

hood

Référence complète : Conception orientée objet, pratique de la méthode HOOD – Michel Lai – Dunod 1991 – ISBN : 2-10-000250-3

Conception orientée objet, pratique de la méthode HOOD


http://www.goodreads.com/book/add_to_books_widget_frame/2100002503?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Surviving Object-Oriented Projects, a manager’s guide, par Alistair Cockburn

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Beaucoup de clairvoyance et de clarté dans l’illustration de cas réels, une pertinence du texte qui résiste mais s’est érodée avec le temps.

Ce livre est rédigé de façon pragmatique, c’est probablement pourquoi il ne compte que 200 pages, volume au delà duquel il faut planifier du temps pour lire entièrement l’ouvrage. L’auteur s’est attaché à décrire comment une organisation pouvait basculer vers l’objet, les stratégies possibles et comment mettre le maximum d’atouts de son coté. Les cas de figure sont abondamment illustrés de cas de figure réels, aussi bien en succès qu’en échecs. Mais voyons plus avant son contenu. Les 200 pages de son contenu sont réparties sur 8 chapitres, mais il faut aussi évoquer les 40 pages d’annexes.

Le premier chapitre est un rappel des concepts de base de l’objet : encapsulation, polymorphisme, etc.. Rien de vraiment original, surtout en 98 où l’objet est quand même un acquis. Mais le propos a le mérite d’être clair.

Le second chapitre est plus original, car il reprend de manière très succincte 11 projets avec leurs facteurs clés de succès, d’échecs ou simplement de difficultés. Chaque cas est exposé sur moins d’une page avec un cartouche caractérisant le projet. En synthèse de ce chapitre l’auteur expose les avantages et les coûts liés aux projets objet. Le contenu est original et reste intéressant, même maintenant.

Les 40 pages du chapitre 3 sont dédiées aux choix et au setup du projet. Quel type de projet doit-on choisir pour faire son premier projet objet ? Avec quelles personnes et surtout avec quel langage ? Certains des points évoqués font largement sourire aujourd’hui. Comme par exemple la question d’un nouveau venu « périphérique » : Java. Aujourd’hui c’est surtout avec ce regard historique que l’on lira ce chapitre dont le propos a perdu de sa pertinence au fil du temps.

Au chapitre 4, on discute méthodologie et plus exactement ce que l’auteur appelle « big-M » versus « little-m » methodologies. Le big-M, ce sont les vrais processus, alors que les little-m ce sont les notations dérivant vers des méthodes/processus d’usage de ces notations. L’auteur exhorte d’abandonner le little-m et de se consacrer au big-M en statuant sur le choix d’un « big shop » ou « small shop » methodologies. Ce qui deviendra plus tard sa « cristal family of methods ». Même si l’auteur conseille de ne pas faire trop lourd, on reste quand même dans la logique rôles / activités / outils, sans compter le plan, les milestones, etc.. On reste assez loin de l’agilité quand même.

Justement, le très long chapitre 5 (près de 50 pages) est exclusivement consacré aux aspects itératifs et incrémentaux des projets. L’auteur y explique par le menu la différence entre les deux et l’avantage des les combiner et compare l’utilisation de ce mode à une « correction de trajectoire ». Cette lecture reste pertinente, même aujourd’hui.

Par comparaison, le chapitre 6 est très court, car il ne compte que 10 pages. L’auteur y évoque les phrases qu’il aurait souhaité de ne jamais entendre. Ce que j’appelle de mon côté les tartes à la crème. Certaines de ces idées reçues sont passées de mode (du moins je crois) mais d’autres ont la vie dure… On passe un bon moment à passer cela en revue !

Le chapitre 7 traite le cas des gros projets et se focalise spécifiquement sur les facteurs de réduction de risque. Là encore, il s’agit d’une lecture qui ne se démode pas.

Le dernier chapitre revisite l’un des cas exposé au premier chapitre et montre comment un échec aurait pu être évité à la lumière des éléments exposés dans le livre.

N’oublions pas non plus l’annexe A, la plus importante qui reprend sous forme de patterns, les stratégies de réduction de risques. Pas mal.

Le livre mérite sans contestation possibles son titre. Il accuse par pas mal de facettes le poids des ans. Il devient difficile de le conseiller, surtout quand de l’excellente littérature agile peut vous montrer la voie. Quelques chapitres méritent le détour, même aujourd’hui. Mais on en est plus à considérer les projets orientés objet comme de la technologie d’avant-garde…

surviving-oo-projects

Référence complète : Surviving Object-Oriented Projects, a manager’s guide – Alistair Cockburn – Addison Wesley / Object Technology Series 1998 – ISBN: 0-201-49834-0

Surviving Object-Oriented Projects


http://www.goodreads.com/book/add_to_books_widget_frame/0201498340?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : La pratique du Lean Management dans l’IT, par Marie-Pia & Christian Ignace, Régis Medina & Antoine Contal

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; Comprendre l’application du Lean à l’informatique. Vraiment.

Il ne faut pas se leurrer : comprendre le Lean, c’est difficile. On nous parle de la maison Toyota, d’un certain nombre de pratiques, le tout cimenté avec des mots Japonais … Très bien. Mais ça reste très flou. Et comme de plus, le Lean passe pour être un peu l’aristocratie de l’agilité, ça ne fait pas très bien de dire qu’on a pas pigé ! Ce que l’on appelle parfois le « Lean Software Development » n’aide pas non plus tant que ça. Difficile de comprendre en quoi cela est différent de nos pratiques actuelles.

Il y a peu de textes qui m’ont permis de prendre conscience de la nature du Lean. En fait, il n’y en a que deux. Le premier est le « système Lean » de Womack et Jones, mais il portait sur l’application du Lean à la production. Le second est celui-ci !

On dit que l’on apprends mieux quand on nous raconte des histoires. C’est ce que font les auteurs ici. Au long des 11 chapitres complétant les 240 pages de cet ouvrages, ils nous enseignent par l’exemple les pratiques Lean au service de l’IT.

En Lean, tout part de la valeur et c’est ce que les auteurs abordent au premier chapitre. S’il ne s’appuie pas sur des exemple il expose efficacement les deux facettes de la valeur (on oublie souvent que pour le Lean il y en a deux) et les sources de gaspillage.

Le chapitre 2 « un idéal de fonctionnement » poursuit sur cette description du Lean qui reste ici encore un peu théorique en décrivant la « maison Toyota ». Un grand classique, serait-on tenté de dire, mais présenté avec une grande clarté. Même si je vois le sujet abordé pour la 3 ou 4ème fois, j’ai eu l’impression de voir la lumière s’allumer…

Le chapitre 3 « la pratique du Lean » est à lire et à relire, tel un kata que l’on répète afin de s’imprégner du message sans qu’il ne soit plus besoin d’y réfléchir. On n’y évoque pas seulement les différentes pratiques, mais aussi de la façon dont elles s’articulent, par où on commence… Une vingtaine de pages de pur enseignement.

Notre premier cas pratique arrive au chapitre 4, avec la gestion d’incidents. On y part d’une situation à laquelle on applique une démarche Lean. On expose celle-ci, notre plan d’action. Puis on déroule celui-ci avec ses découvertes ses progrès etc.… Le tout abondamment illustré est parfaitement limpide.

L’amélioration venant de la répétition, nous abordons un nouveau cas client au chapitre 5, une équipe support plus précisément. Si le chapitre 4 avait mis en pratique certains concepts comme le lead time ou le bac rouge, le chapitre 5 permet de voir plus précisément le PDCA.

De la réparation de la valeur, on passe à la création de valeur au chapitre 6 qui aborde la question du projet. D’autres outils sont illustrés ici comme l’Obeya room, la voix du client ou encore la résolution de problèmes (bien que le A3 soit mis de côté) ou encore le takt time. On le voit, un chapitre bien rempli !

C’est à la mise en flux que se consacre le chapitre 7. Parmi les thèmes qui y sont abordés, on trouve la restauration de la confiance avec le client et le management visuel.

Le chapitre 8 est entièrement consacré à l’un des piliers du Lean : le Kaisen, c’est à dire l’amélioration continue. C’est dans le cadre de l’amélioration de l’expérience utilisateur que le sujet est abordé. On y croise chemin faisant le modèle des 5 attentes client du Lean. Aspect déjà largement abordé dans les autres chapitres, le « go & see », prends une large part ici. Les concepts de « get out of the building » et d’expérimentation nous sont plus familiers dans la littérature Lean Startup mais ils figurent aussi au programme.

Il aurait été difficile de traiter pour cet ouvrage d’éluder le sujet de l’agilité. D’autant qu’Antoine et Régis sont parmi les plus anciens praticiens de l’agilité de l’hexagone car ils ont débuté avec XP dans les années 90 ! Lean y est présenté comme une approche permettant de doper la mise en œuvre de l’agilité avec XP et Scrum.

Le chapitre 10 est une occasion de reprendre de la hauteur. On y passe en revue les pratiques essentielles du Lean et ce qu’elles apportent.

Déployer le Lean ne se fait pas d’un coup de baguette magique. C’est au contraire un chemin difficile. Les auteurs évoquent leur expérience de la chose et les différents biais par lesquels cela peut être fait.

La pratique du Lean Management dans l’IT est un texte qui se lit très bien. Ne soyez pas surpris de le boucler dans la semaine. La plupart des chapitres racontent une histoire, une introduction du Lean dans un contexte particulier avec les actions menées par les coaches. Mais lecture aisée ne signifie pas texte creux ou chemin facile. De nombreuses pratiques sont mises en œuvre, beaucoup de concepts sont expliqués et nécessitent de revenir sur le contenu.

J’ai coutume d’aller écouter Régis et Antoine quand j’en ai l’occasion. Les sujets qu’ils présentent sont riches et intéressants. Mais comme disent les jeunes : on prends cher ! Les coaches Lean qui ont écrit cet ouvrage ont un très haut niveau de maturité, ils nous montrent le chemin et nous laissent comprendre que nous avons encore beaucoup à progresser en plaçant la barre très haut. Cela aussi nous vient du Lean. Et cela peut nous aider à progresser mais aussi nous décourager. C’est probablement le prix à payer.

La discrétion avec laquelle ce livre est sorti ne doit pas en occulter la valeur. Il a raté de peu mon classement du “book of the year”. C’est un texte de haut niveau dont la matière est illustrée avec talent par des cas réels et le déroulement d’une véritable transformation. Ne le ratez pas !

pratique-lean-IT

Référence complète : La pratique du Lean Management dans l’IT, agilité et amélioration continue – Marie-Pia Ignace, Christian Ignace, Régis Medina & Antoine Contal – Pearson France 2012 – ISBN : 978-2-7440-6544-6

La pratique du Lean Management dans l'IT


http://www.goodreads.com/book/add_to_books_widget_frame/17911905?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Open Source ESBs in Action, par Tijs Rademakers & Jos Dirksen

Le par addinquydans Notes de lectureLaisser un commentaire

Note 5 : Un propos qui serait clair s’il n’était alourdi par la présentation de 2 ESBs et qui a prématurément vieilli.

Pour bien comprendre ce qu’est un ESB, le mieux reste encore de le mettre en pratique. C’est l’objet de ce livre : mettre en œuvre non pas un mais deux ESB et de comparer leurs cas d’utilisation. 11 chapitres sur 235 pages regroupées en 3 parties auxquelles il faut ajouter les 50 pages d’annexes sont nécessaires à ce défi.

La première partie est dévolue à la découverte du monde de l’intégration en général et de l’ESB en particulier. Le premier chapitre nous parle des cas d’utilisation des ESBs dans le monde des architectures J2EE. En fait, il va plus loin que cela en nous proposant un « hello world » avec chacun d’entre eux. C’est une bonne mise en jambe.

Après la présentation générale, vient l’architecture. Mule et ServiceMix (car c’est d’eux dont on parle) sont présentés du point de vue des concepts architecturaux, en empruntant largement les représentations officielles. Mais les auteurs montrent aussi les différents concepts en illustrant avec des fragments de code. Là aussi, c’est tout bon.

Présenter 2 ESBs présente aussi des difficultés. Ce chapitre 3 consacré à la mise en œuvre jongle entre les 2 plateformes. Cela rends la lecture compliquée et les 35 pages de ce chapitres semblent denses, sinon fouillis. Il eut été préférable de consacrer un chapitre à chacune des cibles.

Cette première partie se conclut par le chapitre 4 au cours duquel on va réaliser un mini-projet d’intégration avec Mule et avec ServiceMix. On y trouve aussi une évocation de Spring Intégration, encore balbutiant au moment de l’écriture de l’ouvrage mais qui soulève apparemment l’enthousiasme des auteurs.

La seconde partie est une plongée en profondeur dans les fonctionnalités des ESB. Il compte également 4 chapitres. On débute par le chapitre 5 où il est question de traitements sur les messages. On y évoque bien entendu le content-based routing, la validation et la transformation des messages. Le tout abondamment illustré de code avec en complément de Mule et surtout de ServiceMix : Apache Synapse et Camel.

Le chapitre 6 traite des connecteurs, de la manière dont ils s’intègrent et ils s’utilisent. On y passe en revue la connexion aux fichiers, à JMS, l’accès aux données via JDBC au mail, à JNDI ou au FTP. Chaque fois ServiceMix semble un peu mieux traité que son rival. Les 50 pages de ce chapitre ont un peu des allures de catalogue mais tout est clairement expliqué, illustré de schémas et de code, donc c’est O.K.

Le sujet peut paraître désuet aujourd’hui, pourtant il reste important : l’accès aux services Web SOAP est le thème du chapitre 7. Les deux plateformes s’appuient sur CXF aussi bien pour invoquer que pour être appelés. Le WSDL est déjà lui-même un peu touffu, il ne faut pas s’étonner que ce chapitre ne soit pas très simple d’accès. Last but not least, ce chapitre évoque aussi quelques normes WS telles que WS-Security ou WS-Adressing. Ca ne fait rien pour alléger le propos.

Cette seconde partie se conclut par un chapitre dévolu à la gestion d’erreurs et à la sécurisation des ESBs. C’est pratiquement un challenge d’y comprendre quelque chose. Mais c’est surement un sujet sur lequel on peut revenir plus tard, une fois que l’on s’est réellement approprié le sujet. Car les explications ne sont pas évidentes quand on débarque…

La 3ème partie est consacrée à des « case studies » qui s’avèrent en fait être un peu plus que des études de cas, mais des sujets avancés dans la mise en œuvre d’ESB. Le premier chapitre de cette dernière partie qui en compte 3 est consacrée aux Enterprise Integration Patterns de Gregor Hope. Après une courte introduction au sujet, on plonge dans la réalisation d’un système de réservation pour 3 restaurants en intégrant progressivement différents patterns des EIP. On passe ainsi du CBR au publish-subscribe tout en allant chercher des données en base… cela devient plutôt complexe surtout qu’il faut de surcroit faire cela sur 2 plateformes.

Je me demandais à quel moment on allait parler de monitoring. La réponse est : c’est au chapitre 10 ! On continue avec notre cas d’utilisation sur les restaurants et c’est aussi l’occasion d’aborder d’autres patterns comme le Message Store (c’est une base de données XML, eXist qui est utilisée ici). Comme on pouvait s’y attendre, on aborde aussi JMX. Là aussi devoir traiter 2 plateformes complique terriblement le propos. C’est d’ailleurs Mule qui tient la corde ici, il est mieux outillé pour gérer les instances de production. Pour ServiceMix, il faut en gros se tourner vers JConsole…

L’ouvrage se conclut sur le chapitre 11 et l’intégration d’un moteur de workflow ! Ca ne rigole plus et c’est même un peu trop pour le livre. Logiquement, c’est jBPM qui a été choisi. Mais on consacre aussi quelques pages à Apache ODE (qui semble aujourd’hui moribond). Je pense qu’on aurait pu faire l’économie de ce chapitre pour mieux traiter séparément les deux ESBs dans le reste du livre.

Les sujets abordés deviennent parfois ardus, mais le texte est globalement de bonne qualité et bien illustré. Comme je l’ai dit, il est rendu complexe par le traitement parallèle, je dirais presque schizophrénique de deux plateformes. Plus gênant, les exemples de code ne semblent pas fonctionner directement. Ils demandent au minimum un peu de bricolage. Trop pour que l’on s’amuse à tous les tester. Autre grand regret : la vitesse d’obsolescence. Le texte traite de ServiceMix 3.x au moment même ou ServiceMix (qui est très différent) apparaît. On en est aujourd’hui à la version 4.5.x ! Il en va de même pour Mule qui était en version 2.0 au moment de la rédaction et qui est aujourd’hui en 3.4 !

Pour ces raisons, je ne saurais conseiller ce texte aujourd’hui. Il mériterait une mise à jour, car les évolutions de ces deux ESBs sont maintenant en rythme de croisière, avec le travail de fond nécessaire sur les exemples. Malheureusement, je ne pense pas que cela arrivera…

open-source-esb-inaction-manning

Référence complète : Open Source ESBs in Action – Tijs Rademakers & Jos Dirksen – Manning 2009 – ISBN : 1933988215 ; EAN13: 9781933988214

Open-Source ESBs in Action: Example Implementations in Mule and ServiceMix

http://www.goodreads.com/book/add_to_books_widget_frame/1933988215?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on