Note de lecture : Conception orientée objet, par Peter Coad & Edward Yourdon

Note 3 ; Les principes embryonnaires de la conception objet

Il y a « l’avant » Design Patterns, et « l’après ». Cet ouvrage est dans la catégorie « avant ». Il fait aussi suit à « l’Analyse orientée objet » des mêmes auteurs. Et son âge respectable le classe parmi les livres qui ont servi de fondation à l’orienté objet. Bien sûr, depuis on a construit pas mal d’étages, et seul les férus d’histoire informatique auront à cœur de se replonger dans ces textes !

Le problème avec « l’avant » Design Patterns, c’est que l’on parle bien d’analyse et de conception (ici séparés en 2 livres) et que l’on prétend faire la différence clairement, mais en fait ce n’est pas le cas ! Au long des 160 pages du texte principal, les auteurs peinent à exposer des aspects clairement différents entre l’analyse et la conception. Voyons cela.

En plus du texte principal découpé en 10 chapitres, l’ouvrage  compte 24 pages d’annexes, elles-mêmes séparées en 3. Passé la quinzaine de pages d’avant-propos, ce sont les 10 pages du premier chapitre « améliorer la conception » qui ouvrent le bal. Bien que cela ne soit pas avoué ouvertement, la conception y est présenté comme quelque chose d’ajoutée « après coup » pour améliorer la qualité et la maintenance ! On y évoque aussi les principes d’encapsulation et l’organisation fonctionnelle.

Le chapitre 2 traite du passage au modèle en couche. Un modèle en couche bien rigide qui en possède nécessairement 5 ! Les auteurs posent aussi leur position sur le passage de l’analyse à la conception : c’est un continuum. J’aime tout particulièrement le passage où l’on explique que le modèle passe d’analyste aux concepteurs qui reviennent avec une matrice de traçabilité pour prouver qu’ils ont effectivement fait quelque chose !

Après voir tenté de nous faire admettre aux forceps qu’il y a une différence entre analyse et conception, le chapitre 3 en rajoute une couche. Oui, la COO est différente : on ajoute des abstractions, on optimise pour la vitesse, on ajoute des composants bas-niveau. Si vous n’avez pas été convaincus par le chapitre 2 (comme moi), il y a peu de chances que vous le soyez par les 20 pages de ce chapitre ci.

C’est de composants d’interaction humaine qu’il s’agit au chapitre 4. Les 15 pages de ce chapitre sont assez perturbantes, car il commence par une note résolument fonctionnelle (mais sans l’avouer) : identification des utilisateurs et les cas d’usage ! La partie résolument conception est un exposé de l’utilisation de l’outil OOATool ! Un chapitre à oublier.

Le chapitre 5 ne fait que 6 pages. C’est bien suffisant pour traiter le « composant de coordination des tâches ». Il s’agit du pattern Command (en moins bien).

C’est la gestion de données qu’est sensé traiter le chapitre 6 sur 15 pages. On connaît la complexité du sujet. Et les auteurs font leur possible pour l’esquiver. On aurait pu économiser du papier.

Plus de 30 pages sont consacrées au passage en revue des langages OO de l’époque et de la façon dont ils abordent les concepts OO : C++, Pascal Objet, Objective C (si, si), Eiffel et même Ada. Sans être un modèle du genre, cela reste mon chapitre préféré !

Au chapitre 8, on parle des critères de la conception OO. Disons que c’est mon deuxième chapitre préféré : couplage faible, forte cohésion, simplicité. Les prémisses de ce qui fera le succès des livres de Robert Martin est bien là !

L’avant-dernier chapitre est consacré aux outils. Donc un chapitre à peu près inutile. Heureusement il ne pèse que 5 pages. C’est à peu près la taille du dernier chapitre qui sert essentiellement à nous donner la bénédiction des auteurs pour partir sur la conception en objet !

Nous sommes ici encore dans le schéma des méthodologies rigides et de styles architecturaux qui sont de mêmes ! Ne perdez pas votre temps sur cet ouvrage si votre intérêt est autre qu’historique. Le texte ne recèle pas de pépites le gardant pertinent 25 ans plus tard…

image

Référence complète : Conception orientée objet – Peter Coad & Edward Yourdon – Masson 1993 (V.O.: Object Oriented Design – Prentice Hall 1991) – ISBN: 2-225-84212-4

Conception orientée objet

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

Note de lecture : Analyse orientée objets, par Peter Coad et Edward Yourdon

Note : 4 ; Typique de l’approche objet des années 80

Il s’agit ici de l’approche objet typique des années 80. L’emphase est mise sur l’identification “à priori” des objets, ainsi que des attributs et des services attenants, en ne prenant que faiblement en compte le contexte de leur utilisation. Avec 180 pages pour 10 chapitres, ce n’est pas un gros volume. Un second tome, dédié à la conception le complète.

Le premier chapitre est un très classique argumentaire de l’intérêt de l’objet par rapport à la décomposition fonctionnelle en rappelant les grands traits de l’objet : héritage et encapsulation principalement.

Les chapitres 2 et 3 s’articulent autour de l’identification des objets. On notera aussi passage l’évocation de Smalltalk par les auteurs. Les méthodes suggérées sont plutôt empiriques, et surtout on reste sur l’idée d’identifier les objets « à priori », symptomatique du courant de pensée de cette époque.

Le chapitre 4 consacré à l’identification des structures est en fait consacré à l’héritage. Il répond à la question : qu’est-ce qui est et qu’est-ce qui n’est pas un héritage. Question dont la réponse est : ce qui obéit à la relation « est un ». On n’avait pas besoin de 30 pages pour cela ! La notion de « sujet » qui est l’objet du chapitre 5 correspond plus ou moins à celle de package. Elle est curieusement mêlée avec l’idée d’une classe parent qui porterai le même nom… On est décidément dans la mouvance « montrez-moi votre arbre d’héritage !

Attributs et relations sont abordés au chapitre 6. J’ai trouvé que c’était le plus intéressant arrivé à ce point de la lecture, car il répond au moins à des questions de structuration concrètes.

La notion de « service » abordée au chapitre 7 correspond au volet dynamique de la modélisation. Son focus n’est pas très clair car assemble plusieurs concepts, y compris des notions d’architecture et de diagramme d’état. Bref, je n’ai pas accroché.

Le chapitre 8 consacre quelques pages futiles aux outils de modélisation. De même le chapitre 9 est succinct et prétend traiter le passage à la conception orientée objet. Si l’auteur disent bien qu’il s’agit d’un continuum, on ne voit rien de tangible. Le livre se conclut sur un chapitre 10 qui traite de considérations générales sur la mise en œuvre de l’analyse orientée objets.

Ce livre est symptomatique de l’approche objet de la fin des années 80 : une emphase sur les aspects objet liés à l’héritage, plus encore qu’à l’encapsulation (évoquée, mais pas vraiment mise en œuvre). On y voit beaucoup de formalisme et une grande rigidité dans la démarche, ce qui rend cette démarche (comme les autres) bien peu opérationnelle.

L’ouvrage, aujourd’hui ne présente plus qu’un intérêt historique, mais sa lecture ne présente plus d’intérêt pour lui-même. Qui plus est, la prose, du moins dans sa traduction est plutôt aride.

image

Référence complète : Analyse orientée objets – Peter Coad & Edward Yourdon – Masson 1993 (V.O.: Object Oriented Analysis, 2nd edition – Prentice Hall 1991) – ISBN: 2-225-82562-9

Analyse orientée objets

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

Note de lecture : Le génie logiciel orienté objet, par Ivar Jacobson, Magnus Christerson, Patrik Jonsson & Gunnar Övergaard

Note : 3 ; Trop théorique et trop volumineux

Voici un livre qui traite vraiment de méthodologie. Jacobson est le créateur des use cases, il était donc logique que son livre se focalise sur l’analyse. Au delà de ceci, il traite bien entendu des aspects processus et conception, cependant son propos reste souvent de très haut niveau. Mais voyons plus précisément ce que recèle l’ouvrage. Tout d’abord, il est volumineux, avec plus de 500 pages sur 16 chapitres regroupés en 3 parties.

La première partie traite des concepts objet. On en prend pour 5 chapitres sur 110 pages. Le premier chapitre est représentatif du livre : de bons vieux concepts « industriels », avec un processus en phase et une grande croyance dans la réutilisation sortie des cartons… Le second chapitre est une variation de celui-ci et ne nous apprend pas grand chose. C’est avec le chapitre 3 que l’on aborde l’orientation objet. Une vue très conceptuelle et analyse de l’objet, qui fait écho à ce qui est développé dans OMT (mais sans être aussi bien formalisé). Le chapitre 4 est le prolongement « conception » de ce chapitre. J’avoue avoir du mal à distinguer en quoi il apporte quelque chose au propos. En toute logique, le 5ème chapitre traite de l’implémentation orientée objet. C’est une nouvelle illustration de l’incapacité des ouvrages méthodologiques de cette époque de traiter décemment d’implémentation !

La seconde partie parle des « concepts », c’est à dire en fait des grands domaines d’ingénierie. Ce sont 7 chapitres qui constituent cette partie, la plus longue du livre avec près de 240 pages. Et l’on commence par évoquer l’architecture. En fait d’architecture, les auteurs développent plutôt une représentation en vues du système, ce qui permet d’introduire chemin faisant les cas d’utilisation. Mais tout ceci est bien abstrait. C’est de modèle d’analyse qu’il est ensuite question, en quelque sorte une reprise des chapitres 3 et 4. Puis c’est au tour de la « construction ». Pas plus que le chapitre 5, celui-ci n’est convainquant. Mais c’est l’occasion de présenter quelques diagrammes : diagramme d’interaction, d’activité et d’état-transition. Les auteurs tentent aussi de décliner quelques spécialisations , comme le temps réel avec un focus particulier sur les stimuli et la communication entre objets. On s’occupe également des bases de données, sujet mal traité qui semblait plutôt facile à aborder pourtant. On parle aussi de composants, on en parle toujours. Et c’est toujours aussi peu convainquant. Viennent finalement les tests, dont on se dit que le chapitre ne sert qu’à occuper le terrain…

La dernière partie est consacrée aux études de cas. Elle s’étend sur 150 pages et 4 chapitres. Le premier d’entre eux est une étude de cas sur la gestion d’entrepôts. On y développe un peu de cas d’utilisation, un peu de modèle d’analyse et une structuration en bloc. Pas de quoi bien comprendre la démarche de Jacobson. Une seconde étude de cas dans le domaine des télécommunications n’apporte pas grand chose. Les deux derniers chapitres traitent d’une part de la transition vers Objectory (vague et abstrait) et de la comparaison avec les autres méthodes, ce qui étonnamment s’avère intéressant.

Si le propos des auteurs est souvent assez vague, il est peu efficace, et la substance utile de ce livre (indéniable) ne justifie pas son volume. Je trouve aussi que l’aspect processus est trop idéalisé : il est rare qu’un développement se situe dans un cadre aussi idéal que celui décrit.

Aujourd’hui, ce livre présente certainement un intérêt “historique”, car le livre écrit par ce même Jacobson avec Rumbaugh et Booch, The Unified Software Development Process, traite le même sujet tout en étant plus d’actualité.

image

Référence complète : Le génie logiciel orienté objet – Ivar Jacobson, Magnus Christerson, Patrik Jonsson & Gunnar Övergaard – Addison Wesley 1993 – ISBN : 2-87908-042-8 (VO : 0-201-54435-0)

Le génie logiciel orienté objet

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

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

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 : Ingénierie des systèmes d’information avec Merise, par D. Nanci, B. Espinasse, B. Cohen & H. Heckenroth

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 : SADT, un langage pour communiquer, par I.G.L. Technology

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

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 : Analyse et conception orientées objet 2ème édition, par Grady Booch

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 : OMT, Modélisation et conception orienté objet, par James Rumbaugh & al.

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 : Conception orientée objet, pratique de la méthode HOOD par Michel Lai

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