THÈse présentée

télécharger 0.65 Mb.

titre	THÈse présentée
page	27/28
date de publication	09.06.2018
taille	0.65 Mb.
type	Thèse

ar.21-bal.com > droit > Thèse

1 ... 20 21 22 23 24 25 26 27 28

5.8Conclusion

Au cours de ce chapitre, nous avons étudié la question de la testabilité d’un assemblage de composants. Deux configurations ont été identifiées sur un diagramme de classes, comme pouvant générer des relations entre objets difficiles à tester, et sont appelées des anti-patterns de testabilité. Nous avons donc défini un critère de test pour couvrir ces anti-patterns, et proposé une mesure de complexité associée. Cette mesure, qui est évaluée sur un diagramme de classes, correspond à la testabilité d’un assemblage. En effet, cette mesure permet d’évaluer l’effort nécessaire pour vérifier le critère de test sur un assemblage.

Comme la mesure est évaluée sur une spécification du programme, et pas sur le programme réel, la testabilité obtenue est une valeur prédictive « au pire », i.e., qui sera effective si toutes les relations entre classes détectées deviennent des relations entre objets. Il apparaît alors qu’une façon d’améliorer la testabilité est d’ajouter de l’information sur le diagramme pour se prémunir contre une implantation dure à tester. La seconde contribution de ce chapitre consiste à préciser cette information à l’aide de trois stéréotypes spécifiques qui détaillent le rôle de la dépendance d'un point de vue test (creation only, use consult only ou use definition), dans la logique du test classique de flux de données.

Au cours de la seconde partie de cette étude nous nous sommes concentrés sur les design patterns comme des sous-ensembles logiques dans un diagramme global. En effet, les problèmes de testabilité à un niveau global impliquent souvent un grand nombre de classes et d'interactions et peuvent être ainsi très difficiles à résoudre. Il semblait donc intéressant de trouver un niveau intermédiaire pour améliorer la testabilité. L'analyse de testabilité appliquée sur des instances de design patterns a montré que les problèmes pourraient être résolus à la main ou bien paramétrés grâce aux diagrammes de collaboration (une solution de types transformation de modèles). Comme résultat de l'étude des design patterns, nous avons proposé une grille contenant le nombre d'anti-patterns pouvant apparaître si aucune spécification supplémentaire n'est ajoutée sur les liens d'association du diagramme de classes.

6
Conclusions et perspectives

Au cours de cette thèse, nous nous sommes intéressés à certains mécanismes et constructions particuliers du paradigme objet pour proposer des solutions adaptées au test de ces programmes. Les différentes études décrites dans ce document se sont inscrites dans le cadre d’une méthodologie originale pour la conception de composants logiciels fiables. Cette méthodologie considère le test comme le moyen principal pour la validation d’un programme. Elle impose donc de prendre en compte l’activité de test tout au long des phases d’analyse, de conception et d’implantation. Les travaux présentés dans ce document se sont articulés autour de trois points principaux se rapportant à trois aspects différents du développement d’un composant.

6.1Contributions majeures

Les trois contributions majeures de cette thèse s’articulent autour de deux axes complémentaires : la conception testable de systèmes orientés objet par assemblage de composants et la validation des composants et assemblages. Les deux sections suivantes résument ces contributions.

6.1.1Validation de composants

Les chapitres 3 et 4 se sont intéressés à la validation de composants et d’assemblages dans le cadre de la méthode des composants autotestables. Nous avons tout d’abord étudié l’optimisation des cas de test pour un composant, puis la conception par contrat pour la validation d’assemblages de composants.

Au cours du chapitre 3 nous avons proposé une solution pour le problème de la génération et de l’optimisation automatique d’un ensemble de cas de test pour un composant. Nous avons étudié un algorithme génétique pour résoudre ce problème. L’analyse des résultats expérimentaux plutôt décevants nous a conduit à proposer une adaptation de l’algorithme que nous appelons un algorithme bactériologique. Le développement d’un outil nous a permis d’effectuer plusieurs expériences qui ont confirmé la pertinence de l’approche pour le test d’un composant.

Le chapitre 4 propose une étude de la conception par contrat pour le test d’un système OO. Nous avons analysé l’apport de cette méthode pour deux aspects du test : la détection et la localisation des erreurs. Pour cela, nous avons défini respectivement, les mesures de robustesse et de diagnosabilité pour des systèmes OO conçus par contrat. Ceci nous a ensuite permis d’estimer l’impact de la densité et de la qualité des contrats sur ces deux mesures. Les résultats ont montré que la simple introduction de contrats réduit rapidement l’effort de détection et de localisation des erreurs, et qu’au-delà d’une densité minimale, la qualité des contrats (leur capacité à détecter un état erroné du système) est le facteur le plus important pour renforcer la robustesse et faciliter le diagnostic.

Figure 82 – Processus global pour la conception d’un composant fiable

A partir de ces deux études, nous proposons une approche itérative de la conception de composants autotestables. Cette approche consiste à améliorer les trois facettes du composant autotestable, en six étapes (Figure 82) :

une version initiale de l’implantation, des contrats et des cas de test est disponible
une analyse de mutation permet d’améliorer les cas de test. Nous avons étudié deux algorithmes évolutionnistes pour automatiser cette étape.
les cas de test sont exécutés sur l’implantation. Si des erreurs sont détectées, elles doivent être localisées et corrigées. Dans ce cas, il faut revenir à l’étape 1, puisqu’une modification du programme initial, modifie la génération de mutants, et donc la génération de cas de test.
l’efficacité des contrats est mesurée, de nouveau à l’aide d’une analyse de mutation. Cette fois, on n’utilise que les contrats comme oracles pour détecter les mutants. Le score de mutation obtenu correspond à la qualité des contrats.
les contrats sont améliorés si nécessaire.
l’ensemble des cas de test est minimisé, et exécuté sur le composant. L’état du composant est sauvegardé après l’exécution de chaque cas de test, et c’est ce qui sert d’oracle global.

6.1.2Testabilité d’un assemblage de composants

La troisième contribution de cette thèse concerne la testabilité des systèmes orientés objet. Cette étude consiste à prendre en compte l’impact des structures de contrôle particulières engendrées au cours d’un assemblage de composants sur la testabilité des systèmes. En effet, l’utilisation de mécanismes tels que la délégation et le polymorphisme entraîne une forte répartition du contrôle à travers tout le système, et implique des interactions complexes entre les objets du système. Nous avons donc défini un critère de test qui vise à couvrir ces interactions. Associée à ce critère, nous proposons une mesure de complexité, calculable à partir d’un diagramme de classes et qui permet d’évaluer la testabilité d’un assemblage dés la conception. Au cours de cette étude de testabilité, nous avons aussi observé le comportement particulier de l’application des design patterns pour le test. Nous avons montré comment, en forçant une utilisation importante de l’héritage et de la délégation, ils suppriment certains problèmes de testabilité des programmes procéduraux, mais introduisent incidemment d’autres difficultés. Or, ces difficultés peuvent être décelées à partir d’un diagramme de classes et peuvent être évaluées avec le critère de test proposé.