THÈse présentée








télécharger 0.65 Mb.
titreTHÈse présentée
page5/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   ...   28

2.3Méthodologie pour une conception testable


Le succès de l’approche objet tient beaucoup à la notion de composant réutilisable. La réutilisation de composants logiciels devient un enjeu crucial tant pour éviter de réécrire inutilement du logiciel, que pour réduire les coûts de développement. On cherche alors à développer la notion de composant objet « sur étagère », et il faut pour cela pouvoir mesurer la confiance que l’on peut avoir en un composant.

Nous introduisons ici une méthode pour la conception de composants fiables fondée sur le test. Cette méthode considère un composant comme l’agrégation d’une implantation, d’une spécification et d’un ensemble de cas de test. L’idée consiste alors à considérer qu’on peut avoir confiance dans un composant si ces trois aspects sont cohérents l’un vis-à-vis de l’autre. Pour vérifier cette cohérence, nous rendons la spécification partiellement exécutable grâce à des contrats embarqués dans le composant, et nous utilisons l’analyse de mutation pour vérifier la cohérence entre les trois aspects.

Nous commençons par présenter les principes de la conception par contrat, et comment cette méthode peut être appliquée avec UML. Nous détaillons ensuite la méthode proposée par Triskell pour concevoir des composants fiables appelés composants autotestables.

2.3.1La conception par contrat


La notion de contrat a été définie pour capturer les droits et obligations de chaque classe. L’expérience montre que le simple fait d’exprimer ces contrats de manière non ambiguë est une approche de conception valide [Jézéquel''97]. Bertrand Meyer a nommé cette approche de la construction de logiciel la conception par contrats (Design by Contract) [Meyer''92b]. Cette approche repose sur les théories des fonctions partielles et de la logique des prédicats. Elle offre aussi une méthodologie pour construire des systèmes modulaires, extensibles et réutilisables tout en prenant en compte la robustesse du système.

La conception par contrats est à l’opposé de la programmation défensive qui recommande de mettre autant d’assertions que possible dans le code [Liskov''86]. La programmation défensive complique la localisation d’une faute parmi les différents modules et augmente la complexité du logiciel ce qui peut entraîner des erreurs supplémentaires.

La conception par contrats conduit les développeurs à bien séparer les responsabilités de l’appelant d’une méthode (le client) et de l’implantation de cette méthode. Ces contrats sont définis par des expressions booléennes appelées précondition et postcondition pour les routines. On peut aussi définir un invariant de classe pour définir les propriétés globales de l’occurrence d’une classe qui doivent être vérifiées par toutes les routines. Un contrat définit les droits et obligations de chaque partie : le client doit appeler une méthode uniquement en respectant la précondition de la méthode et l’invariant de la classe à laquelle elle appartient. En échange, la méthode appelée garantit que la propriété définie par la postcondition ainsi que l’invariant de classe sont vérifiés.

Si un contrat n’est pas respecté, une erreur a été détectée. La violation d’une précondition signifie que le client n’a pas respecté le contrat : dans ce cas, la méthode appelée ne peut pas respecter sa part du contrat mais peut signaler la faute en soulevant une exception. La violation d’une postcondition signale une erreur dans l’implantation de la méthode appelée qui ne peut pas respecter sa part du contrat.

La conception par contrats est intégrée au système de typage des langages orientés objet grâce à la notion de sous-contrat fournie par le mécanisme d’héritage. En effet, la liaison dynamique permet à une routine de passer un contrat avec une redéfinition pour son implantation. La redéfinition est alors une transformation qui préserve la sémantique puisque la nouvelle définition doit au moins remplir le contrat de la méthode originale, et éventuellement en faire plus (c’est à dire qu’elle peut accepter des appels qui n’étaient pas acceptés par l’originale, et fournir un «meilleur » résultat). C’est pourquoi une précondition dans une sous-classe peut-être affaiblie (accepter plus), et une postcondition renforcée (faire plus).

Dans la suite de cette thèse, nous nous intéressons à l’apport qualitatif de la conception par contrat. Nous étudions comment et à quel moment dans le développement les contrats permettent d’améliorer la qualité d’un composant. Par exemple, de nombreux travaux soulignent l’importance des contrats pour la détection et la localisation des erreurs. Dans le chapitre 3, nous proposons un modèle pour évaluer l’apport des contrats pour le diagnostic (phase de localisation des erreurs), en fonction de leur qualité et de leur répartition dans le système. Nous étudions aussi l’apport des contrats pour la détection d’erreur en proposant une mesure de la robustesse d’un système orienté-objet.

2.3.2Les contrats et UML : le langage OCL


Le langage OCL (Object Constraint Language, [OMG''97]) est un langage formel pour exprimer des contraintes sur des diagrammes UML. Il permet de décrire un invariant pour une classe, et des pré et post conditions pour des méthodes. OCL permet donc de décrire des contrats sur un modèle UML, et sera utilisé dans la suite pour illustrer certains points lors de l’étude de la qualité des contrats pour un composant ou un assemblage de composants.



Figure 7 – Diagramme de classes pour une banque

Dans la suite de cette section, nous illustrons les différents types de contraintes OCL, ainsi que leur syntaxe, sur l’exemple de la Figure 7. Un invariant peut être exprimé pour chacune des classes Bank et BankAccount. Une contrainte de type invariant est désignée par le mot-clé inv, et le type sur lequel la contrainte doit être appliquée est désigné par le mot-clé context. Par exemple, un invariant pour la classe BankAccount, spécifiant que la valeur de balance doit supérieure ou égale à la valeur de overdraft, pour tout instance de BankAccount, s’écrit de la manière suivante :

context bankAccount inv:

self.balance >= self.overdraft

OCL permet de naviguer les associations à partir d’un objet particulier, le nom du rôle désigne l’ensemble des objets de l’autre côté de l’association. Par exemple, un invariant qui contraint toute instance de Bank à avoir au moins un compte s’écrit de la manière suivante :

context Bank inv :

self.accounts->size>0

Les contraintes de type pré et post condition sont désignées par les mots-clé pre et post dans OCL. Dans les postconditions, OCL permet d’accéder à la valeur de l’état avant l’opération grâce à l’opérateur @pre. Une précondtion pour la méthode deposit de la classe BankAccount consiste à vérifier que le montant passé en paramètre est positif. Une postcondition vérifie que la valeur de balance après l’opération est égale à la valeur avant l’opération plus le montant passé en paramètre. Ces contraintes s’expriment de la manière suivante :

context BankAccount::deposit(sum:real):void

pre sum > 0

post self.balance = self.balance@pre + sum

2.3.3Les composants autotestables


La solution envisagée dans le cadre du projet Triskell, pour la conception de composants de confiance, consiste à considérer chaque composant comme un tout possédant une spécification, une implantation et un ensemble de cas de test mémorisés et pouvant être activés (Figure 8). Des composants conçus avec cette méthode sont dits autotestables [Jézéquel''01]. Cette approche conceptuelle est généralisable à des échelles plus grandes que le composant : des assemblages de composants autotestables sont autotestables. A tous les niveaux de complexité, les composants ont la possibilité d’exécuter les cas de test qui leur sont associés.

Avec la conception par contrat [Meyer''92a; Jézéquel''99], des contrats exécutables sont dérivés de la spécification. De cette manière, les trois aspects du composant autotestable sont exécutables, et peuvent être confrontés l’un à l’autre et améliorés de manière incrémentale pour augmenter la confiance dans le composant.

Un point important lors de la conception de composants logiciels destinés à être utilisés dans différents environnements, est d’être capable de leur associer une mesure de confiance. Le terme anglais « trustability » [Howden''70], désigne cette propriété qu’il est difficile d’estimer directement : on ne peut l’évaluer qu’en analysant certains facteurs qui influencent cette propriété. Dans le cadre de la méthode des composants autotestables, nous considérons la qualité de l’ensemble des cas de test associé au composant comme le facteur principal pour l’évaluation de la confiance. En effet, un ensemble efficace de cas de test doit permettre d’améliorer l’implémentation et les contrats, et d’obtenir ainsi une forte cohérence entre ces aspects, ce qui permet d’avoir confiance – de manière indirecte – dans le composant.



Figure 8 – Composant autotestable – la vue en triangle

Méthodologiquement, on souhaite donc renforcer la cohérence entre les trois facettes d’un composant (spécification/implantation/cas de test) en les confrontant l’un à l’autre. Une fois qu’un ensemble de cas de test efficaces est disponible, la correction des erreurs détectées améliore la facette implantation. Pour l’amélioration de la partie spécification exprimée à l’aide de contrats, l’idée est la suivante : si les contrats sont complets, ils devraient être violés quand une erreur est présente dans l’implantation, et qu’un cas de test exécute la partie erronée, et déclenche l’erreur. De plus si les contrats sont corrects, ils ne devraient être violés que dans ces cas-là. Donc, si on exécute un ensemble de cas de test efficaces sur une version du programme dans laquelle on a placé une erreur, et qu’aucun contrat n’est violé, alors une faiblesse dans les contrats a été détectée. Les contrats qui auraient dû détecter l’erreur doivent alors être complétés. D’autre part, lorsque l’ensemble de cas de test est exécuté sur l’implantation et qu’un contrat est violé, si aucune erreur n’est trouvée dans le programme, il faut vérifier que ce n’est pas dû à une erreur dans un contrat.

Un critère pour évaluer l’efficacité d’un ensemble de cas de test est donc nécessaire à l’application de cette méthodologie. Nous aurions pu, dans un premier temps, recourir à un critère de couverture (type couverture de code), mais cela ne reflèterait que de manière très lointaine la capacité des cas de test à révéler des erreurs [Voas''92a]. Dans cette optique, la technique –certes plus lourde – qui nous a paru la plus proche de l’activité effective du test, est l’analyse de mutation, à condition de l’adapter aux langages OO et de permettre le passage à l’échelle (test d’un assemblage de composants).

L’analyse de mutation est la technique centrale qui a été choisie pour tout ce processus d’amélioration, et elle présentée en détail dans la section 2.1.3. Bien que ce soit avant tout une technique pour améliorer et valider un ensemble de cas de test, nous venons d’évoquer comment elle pourrait être utilisée pour valider les contrats.

La conception de composants autotestables permet aussi de résoudre des problèmes de test dans le cas de l’évolution et de la réutilisation de composants. En effet, comme les cas de test sont une partie intégrante du composant, il porte la capacité de se tester (autotest), et ses cas de test peuvent être appelés depuis le système. Trois cas de figures peuvent être pris en compte pour un composant C dans un système S :

  • modification de l’implémentation de C : l’autotest permet de tester la nouvelle implémentation, la spécification ne change pas,

  • ajout de nouvelles fonctionnalités à C : l’autotest doit être lancé pour assurer le test de non-régression, puis l’ensemble de cas de test et la spécification doivent être complétés pour prendre en compte les nouvelles fonctionnalités. Enfin, tous les composants clients de C doivent s’autotester pour garantir la non-régression.

  • réutilisation du composant dans un système S : lors de l’ajout d’un composant C dans un système, l’autotest de C doit être lancé depuis le système pour vérifier sa bonne intégration (héritage et clientèle).

L’approche développée apporte donc un support pour aider à résoudre le problème du test d’intégration, du test de non-régression, de l’évolution des composants et de leur réutilisation. Elle a pour principale limitation le fait qu’elle ne permet pas le test fonctionnel du système, et qu’elle ne modélise pas explicitement les aspects comportementaux, dynamiques du système. C’est ce dernier aspect, qu’il faudrait prendre en compte de manière explicite (aspects de communication entre objets) en proposant des modèles et des méthodes de test spécifiques.

2.3.4Conclusion


Au cours de cette section, nous avons présenté la conception par contrats. Cette technique est utilisée pour rendre une partie de la spécification exécutable, ce qui permet de confronter l’implantation et la spécification grâce au test dynamique. Le test permet donc d’améliorer la cohérence entre ces deux aspects d’un composant et ainsi d’augmenter la confiance dans ce composant. Nous avons présenté une méthode proposée par l’équipe Triskell, et fondée sur la cohérence entre les cas de test, l’implantation et la spécification d’un composant, pour assurer un certain niveau de confiance dans le composant.

Les trois sections suivantes détaillent l’état de l’art spécifique aux trois volets de cette thèse.
1   2   3   4   5   6   7   8   9   ...   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