Étiquette : archeoReview

Note de lecture : Le génie logiciel, par Ian Sommerville

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; Le tour du monde en 80 jours, version “méthodes” : bien écrit et qui permet d’avoir une vue d’ensemble, mais sans jamais approfondir un des aspects. Book of the year 1993 !

Le titre de l’ouvrage peut sembler pompeux… s’intituler ainsi « le génie logiciel » sous-entend que l’on a la prétention de faire le tour de la question. Il faut certes relativiser les choses (le texte original date de 1991), mais s’il y a bien un livre méritant ce nom, c’st celui-ci ! On pourrait dire que c’est une encyclopédie sur les méthodes de développement. Il aborde chacune des étapes de la réalisation du logiciel, depuis l’établissement du cahier des charges jusqu’aux tests, en exposant l’outillage méthodologique disponible à chaque étape. Voyons un peu ce qu’il a dans le ventre. Tout d’abord, le texte, c’est plus de 600 pages sur 31 chapitres en 5 parties. Il ne serait donc pas raisonnable de rentrer dans le détail de chacun des chapitres.

Ce ne sont pas un, mais deux chapitres introductifs qui précèdent la première partie. Et ils sont particulièrement avisés. Tout d’abord en présentant les différentes typologies de processus de développement (l’auteur les regroupent en 4 catégories), et ensuite en évoquant les facteurs humain : diversité des personnalités composant une équipe, dynamique de collaboration, etc… Nous ne sommes donc pas en présence d’un ouvrage abordant le développement logiciel d’un simple point de vue mécanistique. Très bien !

La première partie traite de la spécification logicielle. Ce ne sont pas moins de 7 chapitres et 170 qui sont consacrés au sujet. On commence par y aborder la définition du besoin sous l’angle du cahier des charges, cela permet de voir les composants qu’il regroupe et sert d’introduction pour les autres chapitres. Le volet modélisation accorde une place importante à l’analyse de points de vue, quelques approches complémentaires sont aussi abordées, mais ça reste un peu décevant. La spécification du besoin est passée rapidement, mais aborde quand même les besoins fonctionnels, non fonctionnels et la validation des besoins, mais il faut considérer ce chapitre 5 comme une simple introduction au sujet. Le prototypage est abordé dans une optique RAD au chapitre 6, mais je n’ai pas trouvé le propos très aiguisé. Spécification formelle et spécification algébrique sont les grands fantasmes des universitaires alors que leurs champs d’application sont anecdotiques. Bien qu’étant de bons compléments, je n’aurais pas consacré 2 chapitres au sujet, en fait 3 d’ailleurs car le chapitre 9 traitreusement intitulé « spécification basée sur les modèles » explore en fait le language Z…

La seconde partie consacrée à la conception du logiciel couvre 5 chapitres sur 110 pages. Si l’auteur voit juste sur les qualités attendues d’une bonne conception, sa vision strictement descendante du processus est erronée. La conception orientée objet, telle qu’exposée au chapitre 11 est par ailleurs en fait une approche d’analyse. L’auteur complète bien le tableau avec un volet « temps réel » logiquement focalisé sur les machines à états. C’est une bonne idée de terminer cette partie par la conception d’IHM, mais hélas ce chapitre 14 est bien peu solide. Bref, cette seconde partie est hélas bien faible.

La 3ème partie est consacrée à la programmation. Elle compte moins de 70 pages sur 4 chapitres. On commence de manière plutôt sympathique par un chapitre 15 dédié à la programmation de logiciels fiables. Il aborde quelques sujets chers au « code complete » et en est une bonne introduction. On passe ensuite à la réutilisation, un chapitre bien peu convainquant, comme l’est d’ailleurs le sujet lui-même. Les deux derniers chapitres sont dédiés à l’outillage (CASE tools et IDE), le livre a plus de 20 ans et le propos développé n’est plus d’actualité. Il n’était pas non plus excellent à l’époque. Comme dans beaucoup de traités sur le génie logiciel, cette partie est traitée de manière plutôt superficielle. Excepté le chapitre 15, on est loin d’un Code Complete ou d’un ouvrage orienté craftmanship…

La 4ème partie consacre un peu plus de 110 pages sur 6 chapitres à la validation. L’introduction au sujet est plutôt bonne, elle couvre les typologies et la compréhension illustrée de ce qu’est une stratégie de tests. Le chapitre 20 consacré à la fiabilité est assez pointu dans son propos, tout comme l’est le chapitre qui suit et lui fait écho sur la sureté de fonctionnement et la spécification de cette sureté. Le propos sur le test des défauts, quoique ancien pourrait être lu avec bénéfice par beaucoup d’équipes de développement, car il rappelle des fondamentaux. Outillage de test (circa 1990) et tests de vérification statiques ne sont pas mes sujets préférés, mais ils font partie de la culture informatique et ne sont pas mal traités.

La 5ème partie est dévolue à la gestion de projet. Ce sont 7 chapitre comptant une centaine de pages qui sont dédiées à ce sujet. Faut pas rêver, c’est du « à l’ancienne » ! On y parle organisation des équipes, planification et synchronisation des tâches (avec des Gant, et tout et tout…). Par contre le chapitre consacré à l’estimation avec le modèle COCOMO est pas mal, c’est une bonne introduction à ce model. Par contre le volet consacré à la maintenance est pratiquement sans intérêt. Le chapitre sur la gestion de configuration et la documentation sont assez ternes, tandis que si le sujet de l’assurance qualité sonne bien ses 20 ans, on y trouve quand même du propos de valeur.

Ce livre est construit à la base pour servir de support de cours. C’est en quelque sorte un tour du monde du génie logiciel en 80 jours. A ce titre, il est remarquable de complétude, bien qu’il pourrait être amélioré sur certains sujets (et il accuse aussi son âge). C’est ce que j’ai vu de mieux en la matière, et de loin ! Tel qu’il est, c’est une bonne introduction aux différents sujets et l’auteur fournit d’ailleurs des liens vers des ressources (livres ou articles) permettant de creuser chacun d’entre eux plus en profondeur. Le livre a été régulièrement réactualisé, il en est à sa 9ème édition (que je ne connais pas). Mais les avis sur ces mises à jour ultérieures semblent diverger…

Le Génie Logiciel

Référence complète : Le génie logiciel – Ian Sommerville – Addison Wesley 1992 (V.O. : Software Engineering) – ISBN : 2-87908-033-9

Le Génie Logiciel


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

Note de lecture : Programmation avancée en C++ styles et idiomes, par James Coplien

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Un ouvrage remarquable, historiquement le premier sur les idiomes.

Cet ouvrage figure parmi les titres de référence du C++. Il fut le premier à mettre en évidence les possibilités offertes par le langage afin de construire des idiomes. La plupart de ceux-ci sont maintenant institués en standards de fait du C++, tel « handle-body ». Le style est par ailleurs agréable, mais ainsi que le titre le suggère, ce n’est pas un « premier livre » pour aborder le C++. Ce n’est pas non plus une lecture de dilettante : le texte compte 360 pages structurées en 11 chapitres, auxquelles il convient d’ajouter les 100 pages consacrées aux annexes !

Après une courte introduction, le chapitre 1 s’attaque à ce que j’appellerais les fondamentaux de la POO et du C++ : qu’est-ce qu’une abstraction, que fait-on dans un constructeur et un destructeur, mais aussi des choses légèrement plus avancées comme les fonctions membres statiques ou les pointeurs sur fonction. C’est bien écrit, mais aussi sans concession pour le lecteur : ce n’est pas un livre de plage, le message est clair.

Le chapitre 3 aborde un volet moins connu des objets : les types concrets de données, ce qui permet à l’auteur d’aborder son premier idiome : la forme canonique orthodoxe. Un « must know » de tous les développeurs C++ ! Le chapitre est très riche, car il couvre bien évidemment les surcharges d’opérateurs (y compris new et delete) et présente un second idiome : le pointeur avec comptage de référence.

Le chapitre 4 traite des fondamentaux de l’héritage, c’est à dire de l’héritage simple et public. Il couvre bien les aspects de contrôle d’accès, cinématique des constructeurs et destructeur, etc… Mais dans cet exercice, James Coplien est plutôt moins efficace qu’un Stanley Lippmann, par exemple.

Avec 75 pages, le chapitre 5 est également un gros morceau. Il faut dire que son ambition est de traiter de la programmation objet. Il n’est donc pas étonnant qu’il ait d’avantage une odeur de conception. Il compte d’ailleurs pas moins de 3 idiomes au programme : enveloppe/lettre, constructeur virtuel (une dérivation du précédent, en quelques sortes…) et objet fonction (largement utilisé dans la STL). Plus curieusement, il couvre aussi les aspects avancés de l’héritage : héritage multiple et virtuel et héritages privé et protégé. Cela se raccorde mal au reste et aurait pu figurer dans un chapitre séparé.

Le chapitre 6 se détache un peu du C++ pour parler conception : qu’est-ce qu’une classe ? Comment identifie-t-on ce qui doit être une classe ? Nature des relations entre objet et sémantique de l’héritage. Un gros morceau est la sémantique « est un » détaillé dans le principe de substitution de Liskov. Sans être un tour de force, ce chapitre est fort convenable. On notera l’utilisation de la notation Booch pour les diagrammes.

C’est le serpent de mer de l’objet qui est abordé au chapitre 7 : la réutilisation. Cela en fait un des chapitres les moins utiles du livre. Mais c’est aussi l’occasion d’introduire les templates.

Les templates, justement : parlons-en ! Ils sont l’objet du chapitre 8. On y retrouve la notation Booch et un nouvel idiome : la communauté de templates. Pas l’idiome le plus utile, hélas. Bref, ce court chapitre n’est pas spécialement grandiose.

Le chapitre 9 augmente le niveau de complexité de la lecture, car l’auteur se propose d’émuler les langages dynamiques (curieusement appelés ici « langages symboliques »). On y trouve un idiome, le « multi-méthodes » et des considérations d’implémentations concernant le garbage collecting et le chargement incrémentale de code, c’est à dire en fait la liaison tardive du code.

Le chapitre 10 est très court et poursuit sur la même lancée avec l’héritage multiple dynamique. Peu convainquant. En fait, je n’ai même pas compris où l’auteur voulait en venir…

Enfin le chapitre 11 se tourne vers des considérations plus système, comprenez : des considérations de structuration ! On y présente les diagrammes de transaction et on y évoque les modules, la distribution et la parallélisation, même si tous ces sujets ne sont pas excellemment traités.

Ce livre est très ancien. Il a eu le mérite en son temps d’ouvrir les yeux du programmeur en faisant comprendre qu’il existe un autre niveau de compréhension du langage que la simple bonne appréhension de la syntaxe. A ce titre, il a ouvert la voie à bien des ouvrages de C++ avancé ! Il reste la référence pour un certain nombre d’idiomes qui y sont présentés et ce avec une grande rigueur. En fait je pense que le livre aurait dû se focaliser exclusivement là-dessus ! Certains sujets sont abordé en mode plus introductifs. La question se pose de la pertinence de leur évocation ici, mais finalement ça valait probablement le coup. Bref, un très bon livre, très solide et pas « has been » finalement !

Programmation avancée en C++

Référence complète : Programmation avancée en C++, styles et idiomes – James Coplien – Addison Wesley 1992 (V.O. : Advanced C++ Programming Styles and Idioms ; Addison Wesley 1992) – ISBN : 2-87908-014-2

Programmation avancée en C++


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

Note de lecture : Ingénierie des systèmes d’information avec Merise, par D. Nanci, B. Espinasse, B. Cohen & H. Heckenroth

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Merise pour l’urbanisation du SI plus que pour les projets, même si Merise n’est pas votre business…

Voici une référence biblio avec laquelle je vais me faire “casser” allègrement. Ce n’est pas grave, j’en prends le risque. Amis fondus de l’objet, n’oubliez pas qu’il y a une vie au delà de l’objet. Plus concrètement, on est souvent amené à se connecter à des bases de données relationnelles, donc le plus souvent documentées à l’aide de Merise. Je vous recommande donc de posséder un verni culturel sur ce sujet. Cette référence est là pour couvrir ce besoin. Et on ne fait pas particulièrement dans la légèreté, avec un texte de 650 pages, subdivisé en 6 parties pour un total de 28 chapitres ! La moyenne par chapitre semble donc raisonnable. Passons cela en revue, partie par partie.

La première partie ne fait que 65 pages et s’intitule pompeusement « principes généraux et fondements théoriques de la méthode ». Elle compte 4 chapitres. Après un bref rappel historique, les auteurs replacent Merise dans ce qu’ils appellent la science des systèmes en structurant l’informatique d’entreprise en 3 sous-systèmes : opérant, système d’information et de pilotage. Vient ensuite une vue générale de la méthode et des fameux différents modèles : MCD, MCT, MOD, MOT, MLD, MLT, MPD et MPT (ouf !). Cette première partie se conclut sur la gestion des différents niveaux d’organisation du SI. Le tout est bien illustré, bien qu’avec des représentations un peu complexes et un style plutôt ampoulé, voir un peu prétentieux.

La seconde partie traite de la conception du système d’information organisationnel ( !).  Ce sont 145 pages et 6 chapitres qui couvrent ce sujet. Cette partie aborde la méthode Merise dans l’ordre logique d’utilisation. D’abord le modélisation de l’organisation en domaines et en flux, puis le modèle conceptuel des traitements (MCT), qui équivaut, à ce niveau, à un business model. Le modèle conceptuel des données (MCD) est traditionnellement un gros morceau de Merise, c’est pourquoi 60 pages lui sont consacré. Le modèle organisationnelle des traitements (MOT) est traité ensuite, ce qui fait peu de sens, car je l’aurais plutôt vu à la suite de l’organisation des traitements en flux… Le modèle organisationnel des données (MOD) qui est vu ensuite a une finalité qui ne me semble pas claire, j’ai du mal à le distinguer du MCD. Pour les auteurs, cela paraît évident et ils ne font aucun effort pour nous éclairer. Cette partie se clos par la confrontation traitements / données qui était latente sur toute la partie. Les grilles de cohérences proposées sont fort peu convaincantes.

En troisième partie on aborde la « conception du système d’information informatisé ». Drôle de titre. Avec 180 pages sur 4 chapitre, c’est la partie la plus importante de l’ouvrage en terme de volume. Si la partie 2 pouvait être assimilée à la première couche du modèle de Longépé, cette 3ème partie peut l’être sans aucun doute par rapport à la couche 2. On traite le Modèle logique de Traitement de données, pour ensuite s’intéresser au MCD, tout le chapitre 12 est en fait consacré à la modélisation des données suivant les formes normales de Codd. S’en suit un chapitre particulièrement bâclé sur les modèles physique des données et des traitements. On termine par un chapitre sur l’optimisation du modèle de données qui n’est ni convainquant ni cohérent avec le reste de l’ouvrage.

Les 110 pages de la quatrième partie traitent de la démarche Merise et couvrent 8 chapitre. C’est assez troublant car cela signifie que les parties précédentes n’étaient pas spécialement liées à Merise … de quoi être perdu ! Il s’agit en fait de décrire le cycle de vie du système d’information. Il part du sacro-saint schéma directeur, abordé dans la dizaine de pages du chapitre 15 où il n’est pas question de Merise pour aborder ensuite les études préalables (chapitre 16). Cela couvre le rétro-engineering de l’existant et le dimensionnement. Le lien avec Merise est fait, mais il est ténu et peu convainquant. L’étape suivante, l’étude détaillée évoque au chapitre 17 des « extensions du MCD » mais sans rentrer dans le détail. Le chapitre 18 dédié aux études techniques est pire, il est aussi très superficiel, on voit bien que ce n’est pas la tasse de thé des auteurs. Pour rester cohérent, les auteurs se sont sentis obligé de consacrer un chapitre à la production du logiciel (le moment où l’on programme) : il fait une page et demi. La mise en exploitation n’est pas occultée, mais si l’on écarte le fait que Merise n’y intervient pas, on voit bien également que ce n’est pas le domaine des auteurs. Quelques pages sont finalement consacré à la maintenance, ou plus exactement à un processus de gestion des changements.

Trente pages et 3 chapitres, c’est ce qui est dévolu à la cinquième partie qui évoque les moyens à mettre en œuvre avec Merise. C’est un volet très méthodologique, qui évoque en premier lieu les rôles et la structure organisationnelle, puis les activités et la façon dont les responsabilités se ventilent, pour terminer avec les outils et artefacts avec un gros focus sur les fonctions attendues d’un AGL.

La sixième et dernière partie est consacrée à l’étude de cas d’une société X. En fait, il s’agit plutôt de la présentation du domaine fonctionnel de cette société qui est utilisée comme support sur un certain nombre des exemples. Il est très malencontreux d’avoir structuré cela ainsi : il aurait mieux valu mettre cette partie beaucoup plus en amont et utiliser ce cas d’étude tout au long du livre, en tant que fil rouge. Ni l’un ni l’autre n’ont été fait et celui nuit grandement à la qualité pédagogique de l’ouvrage.

Je pensais avoir acquis un livre pour comprendre l’utilisation de Merise dans un projet. Il n’en est rien et cet aspect est en fait peu ou mal appréhendé. C’est un peu de ma faute, car en fait, le titre du livre est clair : il s’agit plutôt d’une démarche d’urbanisation du système d’information avec Merise ! Hélas, en tant que tel, cela n’est pas non plus très convainquant. Il n’en reste pas moins que l maîtrise de l’outil Merise par les auteurs, leur expertise devrais-je dire, est incontestable. La façon plutôt académique dont ils abordent le processus en fait un texte assez peu opérationnel à mon goût. Ce n’est probablement pas ma pire acquisition, d’autant plus que celui-là, je l’ai eu en fin de série, chez Gibert, à 60 balles.

Ingénierie des systèmes d'information avec Merise

Référence complète : Ingénierie des systèmes d’information avec Merise, vers une deuxième génération – D. Nanci, B. Espinasse, B. Cohen & H. Heckenroth – Sybex 1992 – ISBN : 2-7361-0747-7

Ingénierie des systèmes d'information avec Merise


http://www.goodreads.com/book/add_to_books_widget_frame/18301390?atmb_widget%5Bbutton%5D=atmb_widget_1.png

Note de lecture : Object oriented I/O using C++ iostreams, par Cameron Hughes, Thomas Hamilton & Tracey Hughes

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 5 ; Une source d’information sur les Iostreams moins médiocre que le Teale. Vaut le détour (même si le sujet aurait pu être mieux traité) pour la bibliothèque GDI développée à base de streams !

Très déçu par le médiocre « C++ iostreams handbook » et vu la rareté des ouvrages sur le sujet, il ne m’a pas fallu à l’époque beaucoup de temps pour m’intéresser à celui-ci : il ne pouvait qu’être meilleurs ! En fait, il s’est surtout avéré très différent !

On pourrait appeler ce livre “variations sur les iostreams”. Les auteurs abordent le sujet en développant une bibliothèque iostream pour la GDI Windows. Voyons de plus près le contenu.

Le texte principal de l’ouvrage couvre 300 pages. A hauteur de 10 chapitres, cela nous fit une moyenne un peu élevée de 30 pages par chapitre, mais il faut tenir compte de la proportion importante de code. Il ne faut pas non plus oublier les annexes qui ne sont pas anecdotiques, car elles tiennent 70 pages.

Entrée en douceur pour ce premier chapitre qui présente le concept de streams en commençant par exposer son équivalent avec la bibliothèque C. Bien sur les iostreams sont comparées (aventageusement) par rapport à cette approche et on termine sur quelques perspectives qui annoncent les chapitres futur. Peu de code pour cette introduction de 33 pages, du texte qui se laisse lire, essentiellement.

Le but des 30 pages du chapitre est de faire le lien entre l’approche orienté objet et la bibliothèque iostream. Ce n’est pas tellement réussi et je pense qu’il aurait fallu simplement faire l’impasse sur la description du modèle objet. Les concepts en sont connus du public visé par le texte.

Heureusement les 80 pages du chapitre 3 vient à la rescousse. C’est sans conteste le chapitre le plus utile du livre pour comprendre la librairie iostream, du moins l’ancienne, celle d’avant le standard 98. La structure et l’architecture de la librairie sont très bien expliqués. En fait, c’est la première référence que jai l’heur de croiser qui m’ait apporté une telle clarté. Par contre les détails sont expliqués sinon moins clairement, du moins plus laborieusement.

Les chapitres 4 et 5 nous offrent des interludes d’une dizaine de pages chacun. Le premier pour expliquer simplement le mécanisme de friendship qui permet d’étendre la librairie iostream de manière externe. Le second pour nous présenter un autre concept clé de la librairie : les manipulateurs. C’est mieux fait que dans le Teale, mais hélas encore une fois un peu court.

Etendre la librairie iostream afin de permettre de manipuler les devices graphiques Windows comme des streams est le véritable objectif du livre ! C’est ce qui est abordé dans les 4 chapitres suivants. Le chapitre 6, le premier d’entre eux est là pour expliquer le mécanisme d’évolution de la librairie iostream sur la base des classes ios et streambuf. Hélas c’est loin d’être claire et franchement abstrait. Et bien entendu c’est aussi un pau à réviser avec la norme.

Les 35 pages du chapitre 7 ont pour objectif d’aborder le wrapping des GDI Windows et OS2 en iostream. La plus grande partie de ce chapitre est consacrée à en expliquer le fonctionnement. Il finit par aborder timidement l’implémentation d’une classe de wrapping : textspace (qui étends ostream).

Ce sont 45 pages qui cette fois sont consacrées à la classe ioscontext qui étends ios, au chapitre 8. Ce chapitre est construit sur le même modèle que le précédent.

Le chapitre 9 consacré aux Blobstreams aurait été fort intéressant s’il était allé jusqu’au bout du propos, à savoir l’implémentation sous forme d’extention de la librarie iostream. Mais il fait un boulot décent à présenter les différents formats images et son.

Un peu à part, le chapitre 10 nous présente le wrapping de la gestion du port série RS 232C sous forme d’iostream. C’est original et intéressant (bien que l’on utilise plus guère cette norme). Mais on est hélas frustré car le chapitre ne va pas au bout de la question.

Les annexes, quoi que volumineuses ne s’avèrent guère utiles. Les deux premières expliquent la notation graphique bizarre utilisée tout au long de l’ouvrage, tandis que la troisième se veut un guide de réfernce de la librairie iostream. A l’usage elle ne s’avère guère opérationnelle.

Au final se livre cherche à atteindre 2 cibles :

  • Faire comprendre la librarie iostream. Cet objectif est plutôt bien atteint par la première partie du livre. En tout cas, c’est mieux que le Teale !
  • Présenter une étude de cas de librarie utilisable sous forme d’interfaces stream. C’est original et même très intelligent et pourrait servir de source d’inspiration pour bon nombre de librarie. Mais le livre est un peu court sur le volet pédagogique pour expliquer la construction de la librarie. Il se noie dans pas mal de sujets connexes comme l’explication de la GDI.

Bref, un avis un peu mitigé au final. Bien sûr l’aspect « manuel de référence » a trouvé mieux depuis, je pense surtout au livre d’Angelika Langer. L’étude de cas aurait mérité un traitement plus structuré, probablement en 3 partie, avec une pour chaque environnement système (Windows et OS2) expliquent le fonctionnement des contexte graphique et permettant d’aborder des wrappers. Et une troisième partie pour construire les extensions de la librarie iostream et des exemples de mise en œuvre.

Le livre échoue finalement à bien sélectionner son objectif. Il y en 2 ici et il ne me semblait guère possible de bien les traitre tous les deux en 300 pages.

Object-Oriented I/O using C++ iostreams

Référence complète : Object oriented I/O using C++ iostreams – Cameron Hughes – Thomas Hamilton & Tracey Hughes – John Wiley & sons 1995 – ISBN: 0-471-11809-5

Object-Oriented I/O Using C++ Iostreams


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

Note de lecture : SADT, un langage pour communiquer, par I.G.L. Technology

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 2 ; Rébarbatif et de peu d’intérêt

Hé oui, j’ai décidé de vous faire lire mes fonds de tiroir ! Celui-ci n’est pas le plus glorieux, je le crains. Mais au début de ma carrière, mon boss a décidé de nous faire suivre une méthode pour le développement de notre projet, et il ne connaissait que SADT ! Ci-git le livre par défaut dont j’ai fait l’acquisition pour me mettre à niveau.

Il y a d’autres méthodes au delà des méthodes objet. Celle-ci, employée dans le monde industriel (sur les automates, entre autre) s’adapte particulièrement mal aux concepts objet. Pour gâter le tout, ce livre qui se rapproche plus du mode d’emploi coréen traduit depuis le serbo-croate, n’a rien pour rendre la méthode sympathique. Voyons ce qu’il a dans les tripes.

La bête accuse un peu plus de 330 pages séparées en 11 chapitres. Mais outre le format légèrement réduit par rapport à la moyenne, il faut notre que le texte est imprimé avec une taille de police assez importante et qu’il s’émaille de tout plein de diagrammes SADT bien sympa. Ce n’est donc pas une lecture très lourde.

Le premier chapitre est une introduction de 3 pages. L’une d’entre-elle est entièrement occupée par un beau diagramme de cycle en V. On sait où on habite ! Le second chapitre est à peine plus long et introduit SADT avec un ensemble de définitions bien chiantes. Pardon ! Le 3ème chapitre rentre un peu plus dans le vif car il introduit les différents concepts et notamment les actigrammes et datagrammes, mais aussi l’équipe SADT … car il y a un concept d’équipe SADT ! Le propos n’est pas palpitant mais au moins est-il raisonnablement clair.

Le chapitre 4 compte 30 pages dont de nombreux diagrammes. On y traite le modèle SADT, donc la notation avec la sémantique associée. Il faut du courage pour aller au bout du texte, car il n’y a apparemment aucune volonté pédagogique sous-jacente ! Cela me rappelle les plus beaux manuels de référence écrits sous la menace…

Le chapitre 5 « création d’un modèle SADT » est la partie processus de la méthode, et plus exactement elle décrit les activités de « l’auteur ». C’est un processus parfaitement prescriptif et les auteurs s’évertue a bien le traiter de manière Tayloriste en décrivant de manière détaillée et décomposée ce que l’Auteur a à faire. Pas de quoi faire briller les yeux. C’est vrai pour la prose aussi, d’ailleurs.

Après les 30 pages du chapitre 5, le chapitre 6 nous offre un interlude d’une douzaine de pages sur le cycle auteur / lecteur. C’est moins pénible à lire, et pas seulement parce que le chapitre est plus court. Je ne parles pas du fond, de toute façon de ce côté, il n’y a rien à sauver.

Le chapitre 7 « comment créer un modèle SADT » couvre 90 pages. C’est simplement le chapitre le plus indigeste que j’ai rencontré dans ma carrière. Apparemment, il s’agit d’une étude de cas. Je dis apparemment, car il n’y a pas un mot d’explication (au sens littéral) simplement une suite de diagramme avec laquelle on doit se débrouiller et dont la séquence doit présenter une logique. Je pense que c’est la photocopie de ce que l’on des auteurs a du produire sur un projet (et dont il a été content car il n’a eu aucune remarque, vu que c’est illisible). Bonne affaire, on a produit une partie du livre à pas cher. Mais comment dire ? Ah oui, je sais : c’est de la merde !

A contrario, le chapitre 8 veut expliquer en 5 pages la notion de « mécanisme SADT ». 3 de ces pages sont occupés par de gros diagrammes incompréhensibles. D’ailleurs, j’ai rien compris.

Le chapitre 9 nous donne un « exemple de kit » sur 55 pages. C’est reparti pour une suite de diagrammes sans explications. C’est pas possible : ce doit être le même larron qu’au chapitre qui a produit cela. Cela n’améliore pas l’odeur de l’ouvrage.

Le chapitre 10 évoque le modèle Entité-Relation pour lever les ambiguïtés du modèle SADT. Et visiblement le marier à SADT ajoute encore à la complexité de la méthode. A moins que ce soit le propos qui ne soit confus. Mais je pense qu’en fait le problème est des deux côtés.

Le chapitre 11 est en fait une annexe qui propose quelques templates SADT, au cas où vous n’en auriez pas bouffé assez…

Je ne me suis pas marré quand je l’ai lu (car je l’ai lu !). La prose est déroulée sans aucun talent ni même une quelconque qualité d’expression. Et je ne parle pas des fameux chapitres 7 et 9 qui atteignent des sommets de nullité. J’ai oublié d’évoqué l’emploi pour le moins excessif des majuscules et du gras (et souvent des deux combinés) qui ajoutent encore un peu plus à l’illisibilité. Vous pensez que j’ai été un peu dur en notant avec un 2 ? Je pense au contraire avoir été assez sympa.

SADT, un langage pour communiquer

Référence complète : SADT, un langage pour communiquer – I.G.L. Technology – Eyrolles 1989 – ISBN : 9782212081855

Harry Potter and the Goblet of Fire (Harry Potter, #4)

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

Note de lecture : Object Engineering, par Philippe Desfray

Le par addinquydans Notes de lectureLaisser un commentaire

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.

Object Engineering, the fourth dimension

Référence complète : Object Engineering, the fourth dimension – Philippe Desfray – Addison Wesley 1994 – ISBN: 0-201-42288-3

Object Engineering: The Fourth Dimension

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

Note de lecture : The Annotated C++ Reference Manual, par Margaret A. Ellis & Bjarne Stroustrup

Le par addinquydans Notes de lectureLaisser un commentaire

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.

The Annotated C++ Reference Manual

Référence complète : The Annotated C++ Reference Manual – Margaret A. Ellis & Bjarne Stroustrup – Addison Wesley 1991 – ISBN: 0-201-51459-1

The Annotated C++ Reference Manual


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

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