THÈse présentée








télécharger 0.65 Mb.
titreTHÈse présentée
page7/28
date de publication09.06.2018
taille0.65 Mb.
typeThèse
ar.21-bal.com > droit > Thèse
1   2   3   4   5   6   7   8   9   10   ...   28

2.5Conception par contrat et test


Dans cette thèse nous insistons sur l’intérêt des contrats tant pour la qualité d’un composant que pour assurer une qualité de l’assemblage (c’est le thème du chapitre 4). Pour avoir une idée de l’impact des contrats sur cette qualité nous proposons une étude de l’apport d’une conception par contrat [Meyer''92b] pour la robustesse et la diagnosabilité d’un système orienté objet. Au cours de ces travaux nous avons étudié des méthodes pour l’écriture des contrats, essayé de distinguer différentes qualités pour ces contrats en vue d’une classification, et enfin nous nous sommes intéressés aux contrats pour aider le test de logiciel. Cette section dresse l’état de l’art sur différents points : les méthodes pour la conception par contrat, la classification des contrats et enfin, les contrats et plus généralement, les assertions, pour le test de logiciel.

Plusieurs articles traitent du problème de la rédaction des contrats, en se concentrant sur différents aspects de cette rédaction pour proposer une méthode ou une classification. Le but de tous ces travaux est de proposer une aide pour écrire des contrats de manière efficace.

Les auteurs de [Collet''96] proposent une classification des contrats sur deux critères, d’ordre plus méthodologique que syntaxique. Le premier critère prend en compte les entités utilisées par les contrats, pour aider à placer les contrats de manière efficace. Le second critère se réfère à l’intention du programmeur, c'est-à-dire à la granularité jugée nécessaire par le programmeur. David Rosenblum propose aussi une classification empirique des contrats dans [Rosenblum''95]. Les critères choisis dans cet article sont spécifiques au langage C, et le but est de classifier les types d’erreur détectée par les contrats, plus que de fournir une méthode de rédaction de ces contrats.

D’autres équipes se sont intéressées à des règles minimales pour la rédaction de contrats efficaces. McKim [McKim''95] établit une liste minimale de points qui doivent être vérifiés lors d’une conception par contrats. Cette liste est complétée dans [Mitchell''99], à partir de l’observation de l’application du design pattern Observateur [Gamma''95], les auteurs de cette étude repèrent des problèmes qui apparaissent lors de la rédaction de contrats pour un ensemble de classes plutôt que pour une classe isolée. Le but de ces travaux est d’améliorer les performances, et l’extensibilité des composants.

Concernant les méthodes pour utiliser les contrats pour le développement d’un logiciel, Nordby, Blom et Brunstrom présentent une méthode de développement de logiciel fondée sur les contrats dans [Nordby''02]. Ils distinguent des contrats forts et des contrats faibles, qui correspondent à deux niveaux de granularité : les contrats forts établissent des obligations que le client doit vérifier pour utiliser la routine, la post-condition se contente alors d’exprimer le résultat dans le cas où la routine est utilisée correctement. Pour un contrat faible, la pré-condition sera typiquement à vrai, relâchant ainsi les contraintes sur le client. La post-condition devra alors exprimer le résultat attendu dans le cas d’une utilisation correcte et d’une utilisation incorrecte (message d’erreur, exception…). Les deux types de contrat sont utilisés à des moments différents du développement : les contrats forts pour le développement des unités et la découverte d’erreurs internes, les contrats sont ensuite affaiblis au moment de l’intégration pour tester la robustesse du composant. Dans [Nordby''02], les auteurs présentent une manière sûre d’affaiblir des contrats, et donnent des résultats d’application de cette méthode dans un cadre industriel. Les contrats forts ont permis de détecter rapidement les erreurs au cours du développement de deux composants. Les contrats ont ensuite été affaiblis, et cette opération pour passer des contrats forts aux contrats faibles n’a pas introduit d’erreur.

De manière générale, la conception contrats peut être vue comme une méthode particulière pour placer des assertions dans un programme. Lorsque ces assertions sont exécutables, elles fournissent un moyen puissant de détection d’erreurs. Cependant, peu de travaux se sont intéressés aux assertions pour tester un programme.

Les assertions placées dans le code d’un programme peuvent être utilisées comme fonction d’oracle pour le test. Elles vérifient la cohérence de l’état du logiciel à certains points précis. La violation d’une assertion signifie donc que le programme est passé dans un état erroné, et qu’une opération a rendu un résultat en contradiction avec sa spécification. Dans [Fenkam''02] les auteurs étudient la dérivation d’assertions pour l’oracle de test de composants CORBA à partir d’une spécification formelle du programme. Les auteurs de [Cheon''02] utilisent les post-conditions de méthodes et les invariants de classe exprimés avec JML (Java Modeling Language) pour générer des oracles pour le test de classes Java. JML est un langage pour écrire des pré et post conditions et des invariants pour des programmes écrits en Java. Les oracles sont automatiquement générés dans une classe au format JUnit. Edwards propose aussi d’utiliser les assertions embarquées dans le logiciel comme oracle pour le test de composants logiciels [Edwards''01], sans cependant étudier leur efficacité ou leur complétude.

Un autre aspect du test pour lequel les assertions s’avèrent utiles, est la testabilité. La testabilité est un facteur de qualité qui exprime la difficulté pour tester un programme (tant du point de vue de l’effort de test que de la difficulté de détecter les erreurs). Un des points essentiels, pour découvrir des erreurs au cours du test, est de pouvoir observer le comportement du programme à différents moments de l’exécution. En effet, si on observe une erreur au milieu de l’exécution, on sait que l’erreur se trouve dans la partie du programme exécutée avant ce moment, alors que si on n’observe l’erreur qu’à la fin, la localisation de l’erreur est plus difficile. Voas a beaucoup étudié ces problèmes d’observabilité, et propose une méthode pour placer des assertions de manière efficace pour améliorer la testabilité du programme [Voas''99].

Enfin, Korel [Korel''96] utilise les assertions pour générer des données de test automatiquement. Son idée est de générer des données en entrée qui violent des assertions dans le programme. S’il trouve de telles données, qui sont conformes à la spécification des données en entrée du programme sous test, elles ont forcément détecté une erreur qui peut être de l’un de trois types suivants : une erreur dans le programme, une erreur dans une assertion, une pré-condition trop faible. Pour générer de telles données, il ramène le problème à celui de la génération de données de test qui atteignent un point particulier du programme et le résout comme dans [Korel''92].

En conclusion, il existe d’une part des travaux sur des aspects précis de la rédaction de contrats pour un programme, et d’autre part des travaux sur l’utilisation des assertions exécutables pour aider le test. Cependant, il semble qu’aucune étude ne se soit consacrée sur l’impact des contrats sur le test. Dans la suite de cette thèse (chapitre 4), nous proposons une évaluation de l’apport des contrats pour la détection et la localisation d’erreurs.
1   2   3   4   5   6   7   8   9   10   ...   28

similaire:

THÈse présentée iconThèse Présentée à la Faculté de Pharmacie de Montpellier

THÈse présentée iconThèse présentée pour l’obtention du grade de Docteur

THÈse présentée iconThèse soutenue publiquement par Sang-Ha suh le 10 Juillet 2006
«avec projection», de cette thèse aux membres du Conseil scientifique et à leurs expliquer pourquoi cette thèse ne devait pas être...

THÈse présentée iconThèse soutenue publiquement par Sang-Ha S. le 10 Juillet 2006 Le...
«avec projection», de cette thèse aux membres du Conseil scientifique et à leurs expliquer pourquoi cette thèse ne méritait pas d’être...

THÈse présentée iconQuestionnaire sur les Cathédrales Quelle est le nom de la cathédrale...

THÈse présentée iconCommuniqué de presse
«L’homme et la matièRE» de Don Darby que l’année prenait son envol. L’exposition est présentée à la Salle Principale du cne jusqu’au...

THÈse présentée iconCatégorie de Grand Prix présentée (cocher la case correspondante)
«Les Grands Prix simi immobilier de Bureaux» du 17 juin au Vendredi 7 octobre 2016

THÈse présentée iconThèse

THÈse présentée iconCommuniqué de presse
«Komuna Fundamento» présentée lors de la xiiie exposition internationale d’architecture «Common Ground» qui se déroule dans le cadre...

THÈse présentée iconAutomne 2013 plan de cours
«Unified», combinée à l'apprentissage du langage uml, est présentée et mise en pratique dans un projet de conception et d'implantation...








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com