Journal Design by Contract

Posté par  (site web personnel) .
Étiquettes :
0
21
avr.
2004
Plop,

j'ai là quelques macros pour faire de la programmation par contrat en Objective-C, si ça intéresse quelqu'un : http://www.roard.com/contracts/(...)

c'est un peu bidouillatoire mais grosso modo ça marche... les fans de contrats sont encouragés à commenter et donner des idées :-) (je suis très loin d'être un expert en eiffel ou en design par contrats, c'est juste que j'aime bien l'idée et je voulais voir si on pouvait pas bidouiller un peu :-)

voilà voilà ... sinon ça marche sous linux (GNUstep) et osx (bref, il vous faut une implémentation OpenStep -- quoique rien n'empêche de modifier les macros pour adapter ça à du "pur" Objective-C, mais bon, quel intérêt ?).

  • # Re: Design by Contract

    Posté par  . Évalué à 1.

    Ca a l'air intéressant, mais je me pose la question: est-ce que ces contrats sont hérités?

    Snark sur #eiffel

    • [^] # Re: Design by Contract

      Posté par  . Évalué à 1.

      Apparement non, j'ai regardé, la macro etend la classe en ajoutant les pre/post condtions et invariants. Heriter de cette classe ne permettra pas apparement d'heriter des contrats. Me trompe-je ?

      • [^] # Re: Design by Contract

        Posté par  (site web personnel) . Évalué à 1.

        Non effectivement, les pre/post conditions sont ne sont pas hérités (les invariants devraient l'être par contre).

        Le problème c'est que pour que les pre/post conditions soient hérités, il faudrait les avoir dans des méthodes séparés, et là, je pense qu'on atteinds les limites de ce qu'on peut faire avec le preprocesseur C -- on pourrait faire un truc, mais la "syntaxe" serait assez atroce, vu qu'on a pas de variables pour jongler avec les noms, etc.

        Je pense que pour faire des choses plus complexes, il faut passer par un préprocesseur externe fait en ruby ou perl. Ce qui permettrait d'avoir une syntaxe plus agréable, et d'avoir éventuellement d'autres fonctions (style documentation automatique). Mais bon, preprocesseur externe.

    • [^] # Re: Design by Contract

      Posté par  (site web personnel) . Évalué à 1.

      t'es plus sur gnomemeeting toi ? :)

  • # Re: Design by Contract

    Posté par  . Évalué à 1.

    Vraiment symap ce concept. Je ne connaissais pas ce genre de design, je sens que je vais me documenter sur le sujet. Ca m'a l'air bien puissant...

    Merci cette page claire et simple à comprendre :)

    • [^] # Re: Design by Contract

      Posté par  . Évalué à 1.

      Dans le bouquin "The Pragmatic Programmer: From Journeyman to Master" de David Thomas, il y a un chapitre sur la programmation par contrat.

    • [^] # Re: Design by Contract

      Posté par  . Évalué à 1.

      Oui c'est sympa comme approche, hélas ça n'est pas assez mis en pratique à mon gout.

      Si tu veux un bon bouquin sur le sujet je te conseille "Design by Contract by Example" de Richard Mitchell et Jim McKim (edition Addison Wesley). Ça présente très bien les notions, et le gros plus, c'est qu'il apporte une "méthode" pragmatique aidant à définir et écrire les contrats. Cette méthode est basée sur la distinction des différents types de méthodes : les requêtes de base, les dérivés et les commandes (modifiant l'état de l'objet).

      Autrement, il faut savoir que si les contrats sont apparus dans le langage Eiffel, il existe plein de bibliothèques/plugins/bidouilles pour presque tous les autres langages. Je peux te conseiller STclass for Java (http://web.iu-vannes.fr/docinfo/produits_locaux/stclass/java/index.(...) ), qui est un produit de l'université de Vannes et qui a comme caractérisque (de mémoire) :
      - Les contrats sont écris dans les commentareis comme une extension de javadoc (mot clès @pre, @post, @inv);
      - Ils sont écrit dans une syntaxe proche de Java (ajout des instruction 'forall' et 'exists', et possibilité de faire référence à une valeur ancienne dans une postcondition en y concatenant '@pre' (ex: @post size=size@pre+1)
      - Gére l'héritage de contrats à partir des classes et/ou interface mères. C'est très pratique et propre surtout
      - possibilité lors de la compilation de prendre ou non les contrats (ou que les pré ou post conditions). En fait on utilise l'outil javacst pour interprété les contrats et les ajouter dans le source Java avant de compiler ces dernières avec javac.
      - permet d'ajouter la notion d'autotest (à la Junit) embarqués dans les comentaires, à utiliser avec JMutator (donc je ne retrouve plus de trace :/) pour vérifier la couverture de code (où il y a plein de mutants vivant, c'est que ça manque de tests/contrats :) et pour améliorer les contrats/tests (et le code en même temps :).

      Voila en gros ce que je peux dire sur STclass, j'ai surement oublié plein de truc, j'avais entendu parler d'un plugin pour Eclipse mais j'ai pas été voir ça depuis un certains temps. Pour ce qui est des alternatives, tu trouveras plein de choses en cherchant un peu (icontract ...).

      Pour finir, le mieux c'est une fois avoir écrit tes spécifications par exemple avec UML et OCL, tu écris les squelettes de tes classes/interfaces en y mettant que les signatures de tes méthodes avec les pré/postcondition qui vont bien ainsi que les suites d'autotests. Ensuite tu commences à développer le code des méthodes, et dès que tu as mis en place assez de méthodes pour exectuer une 'feature' , tu lances la suite de test correponsdante. Bien sûr tu auras des erreurs (contrat que se lève, résultat du test pas bon, exception levée ...), mais justement elles te permettront de consolider des contrats/tests/codes.

      • [^] # Re: Design by Contract

        Posté par  (site web personnel) . Évalué à 1.

        Ah ben je connaissais pas, mais je suis en train de regarder et ça m'a l'air très sympathique effectivement !

        merci.

        • [^] # Re: Design by Contract

          Posté par  . Évalué à 1.

          Ouais enfin ne t'emballe pas, je viens de me rendre compte que ce n'est encore que la version prototype en Python qui est disponilble et non pas la version "toute neuve" en Java/XML/ANTLR qui normalement me semblais à peu près prête (en tout cas assez fonctionnelle pour la rendre publique). De même je croyais que le projet devait être hébergé sur sourceforge, mais point de trace sur le site.

          Je vais donc ecrire au mainteneur du projet (un ancien prof) pour savoir ce qu'il en ai. J'espère qui voudra bien aussi mettre l'embryon de plugin pour Eclipse.

          De même pour JMutator, je n'ai retrouvé aucune archive alors que normalement y'a eu du travail de fait dessus l'année dernière. Donc je reposterais un message sur ce journal quand j'aurais de plus amples informations.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.