Note de lecture : C++ Programming style, par Tom Cargill

Note : 7 ; De bons conseils d’experts pour ceux qui pratiquent déjà le C++. Moins indispensable que les 2 livres de Scott Meyers.

Ce livre fait partie de la série d’ouvrages dont fait également partie “Effective C++”, qui constitue chacun des avis d’experts sur le développement en C++. Dans son volume, Tom Cargill s’attache à prodiguer des conseils sur la conception des classes en C++ : surcharge d’opérateur contre fonction membre, utilisation de l’héritage, etc… Il adresse donc des préoccupations différentes de celles de Scott Meyers. Un aspect non négligeable est la relative concision du texte qui noircit juste un peu plus de 220 pages avec une proportion de code je pense un peu supérieure à 30%. Le contenu, justement est divisé en 9 chapitre, le 10ème étant un résumé des règles établies au fil du texte.

Le premier chapitre couvre la notion d’abstraction. C’est réellement un fondamental de cet aspect de la conception, dans le principe indépendant de C++, mais illustré avec C++. Le second complète harmonieusement le propos en traitant de la consistance. Une approche intéressante qui consiste ici à s’intéresser à différentes facettes de la consistance d’une classe : contractuelle, sémantique et physique. Je mets dans le même lot de chapitres ayant d’avantage trait à la conception qu’au C++, le chapitre 3 traitant de « l’héritage inutile ». En gros, ce sont les cas où la délégation est préférable à l’héritage. Un chapitre un tout petit peu plus faible que les deux précédents.

On est d’avantage dans le C++ au chapitre 4 qui évoque les méthodes virtuelles. C’est un peu brouillon, difficile de voir où l’auteur veut en venir, Mais les conseils sont valables. J’ai préféré le chapitre 5 qui couvre la surcharge d’opérateurs, sujet délicat s’il en est.

Retour à des questions de conception au chapitre 6 qui est dédié au wrapping, en l’occurrence l’enrobage de familles de fonctions C dans des classes. Un sujet qui m’était important à l’époque et très bine traité ici.

Arrivée au choses sérieuse au chapitre 7 : l’efficacité. Un chapitre hélas un peu moins palpitant que ce que j’aurais escompté : ça tourne beaucoup autour de l’allocation dynamique, sur un cas d’étude « BigInt ». Les 35 pages de l’étude de cas qui suit ne sont pas mes préférées du livre. Un peu comme au chapitre 4, je ne vois pas trop où on veut en venir. Par contre le chapitre 9 sur l’héritage multiple est à lire absolument : il permet de bien appréhender les subtilités des différents cas de figure où l’héritage multiple peut vous entrainer.

C’est un livre moins indispensable que le Scott Meyers, mais d’une lecture agréable. Une des originalité du format de Tom Cargill est de proposer en fin de chapitre des références bibliographiques pour approfondir les sujets, et des exercices (hélas, sans les corrections). Comme je l’ai dit, le texte est concis : le lecteur non marathonien peur en venir à bout en une semaine ou deux. Si l’on peut s’estimer déçu en premier abord, je pense que ce texte permet surtout de renforcer les fondamentaux. A ce titre, c’est une très bonne lecture.

C++ Programmin Style

Référence complète : C++ Programming style – Tom Cargill – Addison Wesley 1992 – ISBN: 0-201-56365-7

C++ Programming Style


http://www.goodreads.com/book/add_to_books_widget_frame/0201563657?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

MariaDB, plus fort que MySQL

On ne peut pas dire qu’Oracle se soit attiré la réputation d’une société ayant bien compris le modèle Open-Source. Parmi d’autres, MySQL en est une bonne illustration.

Ayant acquis la base Open Source par le biais de l’acquisition de Sun Microsystems, il me parait que le géant de la base de données a cherché avant tout à en faire un produit, plutôt qu’un projet open source. 3 éléments me confortent dans cette opinion :

  • Oracle seul décide de la roadmap MySQL
  • MySQL est positionné par l’éditeur en alternative à Microsoft SQL Server. Une stratégie perdante, car les produits ont un positionnement très différent.
  • Oracle verrouille les développements (patch ou fork) en ne releasant plus les cas de tests depuis plus d’un an !

La fondation MariaDB

Dès le rachat de Sun, le créateur de MySQL Michael “Monty” Widenius a créé le projet MariaDB. Comme il l’explique son but à l’origine était de conserver la communauté historique des développeurs du noyau MySQL, noyau qui était en passe de disparaitre.

J’avoue que bien que ce fork ait maintenant plus de 3 ans, il a échappé à mon radar. Pas seulement au mien visiblement, car il semble que son existence fut jusqu’à une date récente assez discrète. Il aura fallu la création de la fondation MariaDB pour booster sa visibilité.

Aujourd’hui MariaDB offre une alternative à MySQL

  • Compatible au niveau binaire
  • Offrant de nouvelles fonctionnalités marquantes.
  • Plus active que la base historique sur le volet des bus fixes.

MySQL semble avoir un peu perdu de vue sa nature première : non pas une base de données, mais un conteneur de moteur de bases de données. Tandis que MySQL vogue avec ses vieillissants MyISAM et Innodb, MariaDB nous propose de nouveaux engines: Aria, XTraDB (une évolution d’InnoDB), FederatedX (un engins utilisant d’autres SGBD en back-end), OQGRAPH (un moteur optimisé pour gérer les hiérarchies et les graphes) et SphinxSE.

Google à la rescousse

La communauté open source n’est pas la seule à s’inquiéter de la mainmise d’Oracle sur MySQL. Des sociétés de taille respectables pour lesquelles MySQL est une brique importante ont eu la même démarche.

L’annonce la plus marquante est sans aucun doute celle de Google annonçant un support au projet. Concrètement il s’agit d’y consacrer un développeur. Par rapport aux moyens dont dispose le géant du Web et l’importance structurelle de MySQL dans ses infrastructures, cela parait anecdotique, mais le message est là. D’après Widemius, d’autres société sont prêtes à aller dans le même sens, mais on n’a pas de noms…

Une alternative encore verte

Pour assoir une emprise sur le marché, il faut un packaging de bonne qualité. La fondation MariaDB propose des packaging prêts à l’emploi pour les plateformes Linux (Red Hat, Fedora, Debian, Ubuntu…) et Windows.

Mais point de distribution Mac ! Il faut passer par Homebrew avec compilation des sources et quelques petites manipulations … Ca ne va pas tout seul, autant le dire. Bref, ça va en rebuter quelques un. La fondation MariaDB explique que cette absence est due à leurs moyens limités.

Autre point faible : la documentation. Bon, elle existe, toutefois. Mais elle n’est pas vraiment au niveau. Pas de vrai autorail et les informations d’installations et de configurations sont assez éparses. Dans l’ensemble, les informations sont rassemblées sur le site ask monty. Bref, il y a encore à faire.

Côté bouquins, j’ai trouvé 2 titres sur MariaDB. Rien à voir avec la pléthore de livres sur MySQL.

Y aller ou pas ?

Aujourd’hui, je ne conseillerais à personne d’aller volontairement vers du MySQL, à moins que ce choix soit subordonné à un autre. Nombreux sont en effet les projets pour lesquels MySQL est sinon le choix par défaut, du moins un choix “pré-packagé”.

D’un autre côté, des distributions Linux commencent à venir avec MariaDB comme base par défaut en lieu et place de MySQL. De plus, il y a la “compatibilité binaire” revendiquée par MariaDB. Mais celle-ci doit encore se vérifier de contexte en contexte.

Côté Java, à priori MariaDB est toujours compatible avec le connecteur JDBC de MySQL. Mais il existe aussi un connecteur JDBC natif Maria DB.

La situation pour les autres langages est moins claire. Il existe bien un connecteur C dans ce qui est produit par la fondation, mais pour Python, Perl, etc… Il faut à priori utiliser les utilitaires gravitant autour de MySQL et faire des essais. Si l’on va faire un tour du côté de Stackoverflow, on voit que les choses ne sont pas si simples.

La tendance actuelle est un passage vers PostgreSQL (). Cette base est mieux qu’une alternative et est de plus en plus privilégiée à MySQL, non comme solution de replis mais en tant que solution techniquement meilleure.

Il me semble cependant qu’au vu de la roadmap déjà réalisée par MariaDB et de celle à venir, que cette alternative mérite considération, malgré les faiblesses dont il est fait mention.

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

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

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