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

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

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

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

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

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

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

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

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

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

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

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

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

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

surviving-oo-projects

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

Surviving Object-Oriented Projects


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

Note de lecture : Object-Oriented SSADM, par Keith Robinson & Graham Berrisford

Note : 4 ; Une vision d’un autre temps….

Je sais ce que vous allez me dire : « quel intérêt en 2012 de faire une note de lecture sur un vieux clou âgé de 18 ans et de toute façon obsolète ? ». L’histoire, mes amis, ceci est l’histoire. Cet ouvrage de 500 pages évoquant une méthode désormais délaissée fait partie de l’histoire des méthodes objet.

SSADM est une approche que l’on pourrait qualifier de « hautement structurée », voir même Tayloriste ! Elle s’appuie sur 3 schémas directeurs :

  • L’Internal Design : qui définit le schéma physique de la base de données, ainsi que les PDIs (process data interfaces).
  • L’External Design : Il comprend les définitions de format de données en I/O et les interfaces et dialogues utilisateurs
  • Le Conceptual Design : Définit les règles métier, le modèle comportemental de l’application et le modèle logique des données.

Les parties 2 à 5 de ce livre viennent étayer cette vision quelque peu complexe de la modélisation des systèmes d’information.

  • La seconde partie du texte « Le besoin d’avoir plus que la modélisation de données » nous présente les concepts classiques de la modélisation orientée objet, bien qu’avec des qualités pédagogiques assez moyennes, pour nous emmener vers la modélisation dynamique, plutôt pauvre d’ailleurs avec SSADM. Bref, ce n’est pas encore ici que l’on va crier au génie.
  • La troisième partie modestement appelée « Le besoin d’avoir plus que la modélisation OO » couvre les concepts classiques de la modélisation OO (encapsulation, héritage, etc..) pour terminer avec les besoins liés aux « grands » systèmes d’information. Chapitre peu convaincant au demeurant. Au suivant, donc.
  • La quatrième partie est consacrée au modèle conceptuel (c’est aussi la plus importante du livre). On y détaille donc finalement la notation SSADM dédiée à cet aspect. On y aborde la réutilisation (quelle blague !) et certains patterns liés à l’entity data modeling qui constitue des règles d’usage de SSADM, même si leur bien-fondé reste en partie assez mystérieux pour moi. L’event modeling qui y est abordé offre certaines perspectives mais me parait aussi assez difficile d’emploi en l’état.
  • La cinquième partie est dédiée à l’external design. Assez curieusement, c’est ici que je trouve le plus d’éléments intéressants, liés à l’utilisation de techniques « RAD » ou d’event-driven interfaces, bien que les notations soient parfois ardues.
  • La sixième partie est quand à elle consacrée aux autres discussions comme les besoins concernant les ateliers de modélisation ou la réutilisation (encore ?) à l’échelle de l’entreprise.

On ne peut reprocher à cet ouvrage le traitement de SSADM, ce qui lui vaut sa note. C’est à SSADM lui-même que l’on peut reprocher des choses : cette vision du développement logiciel appartient à une autre époque, pour autant que cela ait été applicable à une époque donnée ? Ce découpage en tâche avec un formalisme si peu adapté à l’esprit humain ne semble guère convenir. Toutes ces méthodes datant de la fin des années 80 nous packageaient ensemble notation et approche structurée. Qui plus est, ici, cette approche ne s’adapte qu’à des cas identifiés d’architectures logicielles.

Bref, dans le genre, je préfère Bertrand Meyer.

ObjectOriented-SSADM

Référence complète : Object-Oriented SSADM – Keith Robinson & Graham Berrisford – Prentice Hall 1994 – ISBN : 0-13-3094444-8

Object Oriented Ssadm


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

Rencontre avec Bertrand Meyer

Ce 9 Mai, Valtech nous avait invité à rencontrer Bertrand Meyer. Figure emblématique de l’objet à la fin des années 1980 / début des années 1990, j’avoue que je n’avais plus entendu parler de cette sommité depuis de nombreuses années. L’objet s’est effacé du devant de la scène dans la seconde moitié des années 90 tandis que le Web tractait toute l’attention, et le nom du créateur d’Eiffel a disparu des titres.

C’est donc avec grand plaisir que je suis venu l’écouter, entendre parler d’objet à nouveau et en savoir plus sur ses sujets d’investigation d’aujourd’hui.

Un peu de Biographie

Diplomé de Polytechnique (X-Telecom), Bertrand Meyer a rejoint la direction des études d’EDF en 1974. Parti pour un an en Californie, à Santa Barbara, il y restera quatre, entre 1983 et 1986. Il y rencontrera des sommités de l’informatique, tel que Donald Knuth, mais il créera surtout le language Eiffel

Depuis 2001, Bertrand Meyer occupe une chaire de professeur à l’EPFL de Zurich, où il succède à Niklaus Wirth, le créateur du language Pascal.

Parlons maintenant d’Eiffel

Pour débuter, Mr Meyer nous propose de commencer… par évoquer les points négatifs !

Les points négatifs

  • Eiffel n’est supporté par aucun acteur majeur de l’industrie. C++ Le fut par AT&T, puis par Sun. Java l’a été par Sun et désormais par Oracle.
  • Mais il s’est fait sa place chez certains industriels qui lui sont fidèles.

Il s’agit d’une petite communauté. Toutefois cette communauté n’a jamais cessé d’exister depuis 25 ans. Donc si ce mouvement est discret il est solide.

  • De manière assez curieuse, après avoir essuyé les reproches d’être un langage “trop jeune”, Eiffel est presque directement passé au statut de “legacy” !

Pas de phénomène de mode autour du langage. A aucun moment, il n’a eu la réputation d’être le langage “dans le vent”. Absence de composants réutilisables. Ce dernier point est paradoxal, car le langage a été imaginé et créé au départ avec cette finalité en tête.

  • Aujourd’hui les librairies existent mais restent peu nombreuses comparées aux standards du marché.
  • Mais le langage est simplement interfaçable vers le C et le C++ (le compilateur fonctionne en “C front”). L’interfaçage se fait également sur la machine virtuelle .NET de Microsoft. L’interfaçage vers Java est possible, mais difficile.

Les points négatifs … qui n’en sont pas

  • “Cette fonctionnalité finira par arriver dans mon langage favori”. Les ajouts de fonctionnalités après coup dans les langages s’avèrent générallement boiteuses. Par exemple les “code contract” de .net fonctionnent comme des pièces rapportées.
  • “Il n’y a pas de programmeur Eiffel”. Eiffel n’est pas une religion. Tout développeur aguerri à l’objet peut se mettre aisément à Eiffel. Il est apte à être pris en main par des débutants, plus qu’il ne s’avère possible avec C++ qui est un langage difficile à maîtriser.
  • Pas de covariance pour l’instant. Il s’agit d’un problème avec le système de type sui sera résolu bientôt.
  • Pas fait pour le Web. Là aussi il s’agit d’un point en cours de résolution. Le framework EWF adressera cela.

Ce pour quoi Eiffel est fait

  • Il ne cible pas les réalisations “quick and dirty”. Les langages orientés script tels que Perl et Python sont mieux ciblés pour cela.
  • Il ne cible pas non plus le temps réel: la présence d’un garbage collector est une source d’alea trop importante pour répondre aux exigences du temps contraint

Et les types de développements ?

  • Les développements “casual” ne sont pas non plus le coeur de cible du langage (cf le “quick and dirty”)
  • Le développement professionnel en entreprise est clairelment la cible du langage. C’est par ailleurs la très grande majorité des développements informatiques.
  • Les développements critiques (money critical, life critical) : pas non plus la cible privilégiée du langage, malgré la présence de fonctionnalités adaptées (typage forts, contrats).

Quels sont les argumentaires d’Eiffel ?

Par rapport à sa cible, ce sont les arguments liés à la qualité sur le long terme:

  • Extensibilité
  • Fiabilité
  • Scalabilité
  • Portabilité (grâce au compilateur “C front”, il a le niveau de portabilité du C sous-jacent).
  • Intégration méthode / langage. Nous reviendrons sur ce point.

Cet argumentaire qualité passe hélas peu. Il est pourtant très aligné sur les principes sous-jacents à l’agilité au niveau du code, selon l’analyse qu’en fait Bertrand Meyer, suite à sa formation “Scrum Master”.

Alors quels sont les projets classiquement dévolus à Eiffel ?

  • Ceux pour lesquels tout le reste n’a pas marché !
  • Ceux qui sont soumis à des évolutions fréquentes.
  • Ceux pour lesquels il y a un “champion local” supportant ce choix.

Et justement, ces développeurs à quoi ressemblent-ils ?

  • Ce sont tout autant des concepteurs que des codeurs … et certainement pas de simples codeurs: comme dans tout langage objet, les principes de conception sont liés au langage, mais pour Bertrand Meyer, c’est encore plus le cas avec Eiffel !
  • Ce sont des développeurs dont la volonté de se perfectionner est plus importante que celle de suivre le plus grand nombre.
  • Il semblerait aussi que la pratique d’Eiffel rende beau et donne un charme irrésistible auprès des femmes ! Et voilà : Bertrand Meyer nous a pris par surprise, car sous une apparence disons classique, le créateur d’Eiffel a un sens de l’humour tout à fait aiguisé, et il nous délivre ses traits sous un air pince sans rire redoutablement efficace !

La réalité d’Eiffel aujourd’hui

Eiffel est à la fois une méthode, un langage et un environnement.

En tant que méthode

Eiffel suit les principes de la conception orientée objet, tels du moins que son auteur les a décrits dans son ouvrage disponible dans toutes les bonnnes librairies.

Eiffel suit le principe du “single model”, c’est à dire que le code du langage porte le code d’exécution, mais aussi des informations d’analyse, comme celles concernant les pré/post conditions et les invariants.

L’approche orientée obets est l’axe principal (unique ?) de l’approche d’Eiffel, la méthode (et le langage) supportent donc le paradigme des types abstraits de données, ce qui signifie :

  • Une description abstraite des propriétés des opérations.
  • Une organisation des types en hiérarchies supportant le polymorphisme (principe de substitution de Liskow).

En tant que language…

Eiffel a été normalisé par l’ISO en 2006. L’implémentation du compilateur est donc ouvert à la concurrence, du moins en principe.

La classe est le seule mécanisme de modularisation. Pas de “package”, de “namespace” ou de “module” !

Par ailleurs, Eiffel est un des rares langage qui supporte l’héritage multiple, position que Bertrand Meyer défend avec ardeur. Si je le suis sur ce terrain, l’exemple qu’il nous a présenté ne m’a pas paru terriblement percutant: le cas du vélo qui hérite de “véhicule” et de “Liste” me semble boiteux, car ces deux abstractions sont de niveaux très différents. Ainsi la liste devrait être un simple élément d’implémentation dans le vélo…

Eiffel supporte aussi depuis le départ la notion de générique. Contrairement à C++ et surtout par rapport à Java, cette fonctionalité n’est pas une pièce rapportée … surtout quand elle est aussi faible que le “type erasure” de Java !

… Toujours vivant !

Le langage est désormais “void safe”. Cet ajout arrivé il y a 6 ans interdit le déréférencement de pointeurs pouvant être nuls ! Et ceci est même vérifié à la compilation.

Les agents. Il permet de construire des clases qui sont des “observer” du pattern MVC. D’autres classes pouvant évidemment publier des évènements. C’est le MVC intégré dans le langage !

En tant qu’environnement

Eiffel Studio est le standard “de facto” du langage. Il intègre 2 compilateurs:

  • 1 compilateur “C front” qui est le compilateur historique d’Eiffel. Ce passage par le C est le couche qui assure au langage sa portabilité, comme je l’ai évoqué précédemment.
  • Un compilateur sur la machine virtuelle .NET de Microsoft.

Le compilateur utilise la technique dite de “la glace fondue”, en fait une compilation incrémentale qui rend les temps de compilation non pas dépendants de la taille du projet, mais de l’importance des changements depuis la dernière compilation.

Design by contracts

L’un des apports originaux (repris depuis par d’autres langages) est la notion de contrats. Ceux-ci sont intégrés au code selon le principe du “modèle unique” que nous avons évoqué plus haut. L’environnement dispose quand à lui d’outils pour extraire ces informations à différents niveaux (modèle, documentation, tests…). Il y a 3 types de contrats:

  • Les préconditions : Il s’agit des conditions que l’apellant doit respecter avant l’appel à la méthode.
  • Les postconditions : Il s’agit des conditions que l’apellé doit respecter avant de rendre la main.
  • Les invariants: Ils doivent être respectés à tout moments..

Dans le cas du polymorphisme, les préconditions appartenant à l’abstraction sus-jacente doivent être respectées au moment de la liaison tardive entre appelant et apellé.

Les contrats permettent de vérifier les domaines de validité des paramètres en entrée, de valeurs de retour en sortie et les conditions de stabilité des objets. Dans le cas de l’explosion d’Ariane 5, la vérification du domine de validité des paramètres d’entrée aurait suffit à prévenir l’explosion de la fusée !

En développement, la violation de contrat nous emmène directement dans le debugger, celui-ci précisant la nature du contrat non respecté et le contexte.

Eiffel et les tests unitaires

Bertrand Meyer s’inscrit dans la logique de mise en place des tests unitaire instillée par les pratiques agiles et plus particulièrement TDD ! Cependant il juge que ceux-ci souffrent encore de points faibles, parfois simplement passés sous silence dans la littérature:

  • Génération des tests unitaires: les tests passants et surtout les tests non-passants.
  • L’enrichissement des tests unitaires sur la base des échecs d’exécution.
  • La minimisation des tests afin d’en optimiser l’exécution.

L’environnement Eiffel propose un outil à cet effet nommé Autotest qui permet la génération des tests à partir de contrats, mais égallement leur enrichissement sur la base des échecs d’exécution. Bertrand Meyer n’a rien dit sur le volet de la minimisation, j’imagine donc que c’est toujours un sujet en cours de travail.

Le parallélisme avec SCOOP

Il s’agit d’une nouvelle extension d’Eiffel : Simple Concurrent OO Programming. Il s’agit bien d’une extension car au moins un nouveau mot-clé (separate) est introduit dans le langage avec SCOOP. Le problème de la concurence n’est pas nouveau et nous savons tous qu’il n’est pas simple à adresser. Son importance augmente pourtant de manière importante, avec la progression des processeurs “multi-coeurs”.

SCOOP met en avant les notions d’action, d’asynchronisme et surtout de “région”. SCOOP prend en charge les mécanismes de synchronisation de bas niveau afin de permettre ce que Bertrand Meyer juge important : pouvoir raisonner sur les programmes.

Le principe de base de SCOOP est le “wait rule”: une action ne démarre pas tant que toutes les ressources nécessaires ne sont pas disponibles.

Les développements en cours

Depuis qu’il a repris en 2001 la chaire de professeur de Niklaus Wirth, Bertrand Meyer poursuit ses travaux autour d’Eiffel:

  • La notion de “preuve” formelle, et de vérification statiques ou dynamiques des programmes.
  • La persistence
  • Le “cloud based developpement”. Dans cet environnement, le VCS (ou même le DVCS à la Git) disparait. Les changements se font et sont répercutés en temps réel, à la Google doc.
  • EVE: une évolution de l’environnement Eiffel permettant la vérification des programmes minute par minute.
  • Autofix, qui l’étape suivant d’Autotest: l’idée ici est de proposer des corrections automatiques des programmes pour les cas simples. Actuellement le ratio de succès de cet outil est de 2/3, testé sur les correctifs apportés au fil du temps sur les librairies Eiffel elle-mêmes.

En conclusion

Eiffel existe, il est toujours en cours d’évolution. Mais il ne deviendra jamais “mainstream”. L’auteur l’avoue et s’en accommode. Certaines choses qui sont acquises dans des langages modernes : la covariance, la présence de frameworks Web sont encore très récentes ici ou en cours de développement. Le langage reste ancré sur ses choix initiaux : purement objet, sans mécanisme de modularité à grande échelle ni intégration de paradigme tiers comme la programmation fonctionnelle. Ces choix ont nécessairement un impact pour rendre le langage attrayant pour le plus grand nombre, mais c’est une bataille que Bertrand Meyer ne cherche plus à mener.

Paradoxalement, cette position de niche lui confère certains avantage, comme la possibilité de ne pas rester fixé sur la stricte compatibilité ascendante lors des évolutions du langage. Et si la communauté est petite, elle est très fidèle à Eiffel. Car le langage reste remarquable, certes doté d’un ecosystème de librairies sans commune mesure avec Java, mais avec un design de base qui n’a rien à lui envier, bien au contraire !

Si vous voulez aller de l’avant avec Eiffel, vous pouvez rejoindre le Groupe des Eiffelistes Francophones (la page Google Group est ici). Merci à Jocelyn Batton de l’avoir créé !