THÈse présentée








télécharger 0.65 Mb.
titreTHÈse présentée
page25/28
date de publication09.06.2018
taille0.65 Mb.
typeThèse
ar.21-bal.com > droit > Thèse
1   ...   20   21   22   23   24   25   26   27   28

5.6Design Patterns pour la testabilité du modèle


Jusqu'a récemment, une architecture OO finale apparaissait souvent comme un ensemble complexe de classes agissant l'une sur l'autre en l’absence de sous-ensembles logiques émergeant du modèle global. Cependant, grâce à UML, des méthodologies systématiques telles que CatalysisSM [D'Souza''98] offrent maintenant une approche de décomposition de l'architecture. Ces méthodologies aident à concevoir un logiciel orienté objet comme une succession de raffinements, depuis les premières étapes de l’analyse jusqu’à l'exécution. En particulier, les design patterns [Gamma''95] peuvent servir comme base pour une telle amélioration. À partir d'un diagramme de classes d'analyse, les design patterns aident le concepteur en proposant des solutions de conception pour résoudre des problèmes dans un contexte particulier, et ainsi transformer le diagramme en un autre plus orienté vers l'implantation. Les design patterns correspondent alors a des sous-ensembles dans le diagramme de classes, et peuvent être considérés comme une structure intermédiaire entre l'architecture globale et la classe simple. Cette décomposition du système fournit une solution intéressante pour résoudre certains problèmes à un niveau local quand la solution au niveau global est trop complexe.

5.6.1Concevoir par cristallisation de patterns


Design patterns. Les design patterns représentent des solutions aux problèmes qui surgissent quand un logiciel est développé dans un contexte particulier. Les design patterns peuvent être considérés en tant que microarchitectures réutilisables qui contribuent à une architecture du système globale; ils saisissent les structures dynamiques et statiques et les collaborations entre les principaux participants du modèle de conception.

La Figure 72 montre un premier modèle orienté objet (étape d'analyse) pour un client de messagerie instantanée. La Figure 73 illustre une conception détaillée finale possible après plusieurs étapes d'amélioration, et montre des instances de design patterns dans des ellipses selon la norme UML.



Figure 72 – Un client de messagerie instantanée (diagramme d'analyse)



Figure 73 – Un modèle « final » possible pour le client de messagerie instantanée

L'architecture de la Figure 73 est une conception orientée objet typique obtenue après des étapes de cristallisation. Une étape de cristallisation comporte l'adaptation d'un design pattern à un diagramme de classes.

Cette approche est une méthode largement répandue pour passer d'un premier diagramme d'analyse vers un autre plus orienté vers l’exécution. Après l'application d'un design pattern, les classes principales d'analyse demeurent sur le diagramme. De nouvelles classes et liens apparaissent et quelques relations d'associations sont supprimées. Dans l’exemple de la Figure 73, le diagramme de classes d'analyse a été modifié à travers trois étapes indépendantes qui correspondent à l'adaptation et la combinaison du pattern Abstract Factory et de deux patterns State. Les nouvelles relations et classes introduites pendant le raffinage du modèle en employant des design patterns semblent rendre la conception très dure a tester ; en particulier chaque classe peut potentiellement interagir avec toute autre. Cependant, la méthodologie de développement (cristallisation des design patterns à partir d'une première analyse) nous permet réellement de considérer la totalité du modèle plus comme une composition de microarchitectures que comme un ensemble monolithique de classes inter-connectées. Par conséquent, la complexité globale est décomposée en une combinaison de complexités de microarchitectures, et la tâche de test est ainsi simplifiée. En effet, une fois que les sous-ensembles sont identifiés dans le modèle, plusieurs problèmes de test peuvent être résolus à un niveau local (microarchitecture). Les questions sont:

  • Quelles sont les améliorations pour la testabilité obtenues en utilisant les design patterns?

  • Les problèmes de testabilité peuvent-ils être localisés (confinés) au sous-ensemble du diagramme qui correspond à l'application d'un design pattern?

Nous répondons à la première question dans le contexte d'une comparaison de testabilité entre l'utilisation isolée du design pattern State et l'implantation procédurale classique d'une machine d'états en utilisant une seule classe.

Nous discutons de la deuxième question - définition de règles/contraintes sur le modèle qui évitent des anti-patterns de testabilité - à travers une solution qui attache des contraintes à un modèle telles que l'implantation soit testable.

5.6.2Application du design pattern State pour améliorer la testabilité


Nous distinguons la programmation orientée objet de la programmation procédurale par l'effort consacré à la modélisation. Nous considérons le logiciel orienté objet comme un logiciel pour lequel la majeure partie de l'effort est consacrée à la conception de l'architecture, la décomposition modulaire (classe), et le couplage entre les classes (en utilisant autant que possible des constructions orientées objet particulières telles que l'héritage et le polymorphisme). Nous illustrons les différences entre programmation fonctionnelle et OO grâce à deux implantations d'une machine d'états.

L'exemple, pris dans [Jézéquel''99], implante la machine d'états liée à la classe mailer (Figure 74). Cette classe définit une interface publique pour envoyer et recevoir des messages indépendamment du statut de la connexion réseau. Quand la connexion réseau est disponible, les messages sont simplement expédiés. Si elle est indisponible, les messages à diffuser sont stockés dans le serveur de messagerie en attendant la transmission quand la connexion réseau sera restaurée.



Figure 74 – Machine d'états pour la classe Mailer

Une implantation procédurale de cette machine d'états consiste à coder la machine comme une seule classe. Par exemple, le corps de chacune des méthodes dépendantes de l’état courant est une grande conditionnelle. De telles méthodes (par exemple send()) vérifient la valeur de l'état courant, et exécutent un traitement différent en fonction de cette valeur. Ceci est illustré sur la Figure 75. Il y a au moins deux arguments contre l'emploi de ce type de mise en œuvre. D'abord, il tend à rendre le code peu clair, difficile à lire, à maintenir ou réutiliser. En second lieu, il rend le logiciel difficile à étendre: dans ce cas particulier, l’ajout d’un nouvel état impose l'ajout d'un nouveau cas dans chacune des méthodes dépendantes de l’état, c’est-à-dire que des changements sont exigés au niveau du code de plusieurs méthodes. Par conséquent, le risque de commettre une erreur augmente.



Figure 75 – Machine d'états implantée dans une seule classe

Par ailleurs, cette implantation doit être testée pour valider chaque méthode. Une fois que l'instance de la classe est dans un état particulier, chaque méthode est examinée pour cet état et pour chaque transition existant depuis cet état. Ainsi, le nombre d'instructions pour examiner cette classe est de l'ordre du nombre moyen d'instructions requis pour mettre la classe dans un état donné, multiplié par le nombre moyen de transitions sortantes, plus le nombre d'instructions dont on a besoin pour tester son comportement.



Figure 76 – Machine d'états implantée avec le design pattern state

Maintenant, implantons la machine d'états avec le pattern state [Gamma''95], l'architecture est donnée Figure 76. Elle contient la classe mailer et l'interface mailerstate. Le mailerstate rassemble chaque méthode dont le traitement dépend de l'état courant. Il y a une classe concrète d'état pour chaque état possible. Dans la classe mailer, le traitement des méthodes dépendantes de l'état courant est délégué à l'objet currentState, qui peut être lié dynamiquement à n'importe quel classe héritant de la classe mailerstate. Par conséquent, le contrôle de la valeur de l'état ne se fait plus explicitement dans la classe mailer. Le bon traitement d'une méthode est fait grâce à la liaison dynamique. Ceci rend la classe mailer beaucoup plus claire, et complètement indépendante de sa machine d'états. Les deux problèmes détectés dans la solution précédente sont résolus. Le code de chaque méthode est maintenant beaucoup plus petit (chaque méthode exécute seulement une opération), et ainsi plus lisible. De plus, l'architecture facilite le changement de la machine d'états. Par exemple, ajouter un nouvel état consiste à ajouter une nouvelle classe concrète pour cet état.

Plusieurs éléments rendent la conception "pattern" plus testable que la conception "classique", même si elle semble plus compliquée en termes de nombre de classes ou en termes de couplage entre ces classes. D'abord, la structure de contrôle complexe de l'implémentation précédente a disparu. Le contrôle n'a pas besoin d'être testé en tant que tel, puisqu'il est implanté grâce à la liaison dynamique. Ensuite, le test est simplifié puisque les comportements spécifiques pour chaque état sont isolés dans différentes classes. Ainsi, il n’y a plus besoin du préambule qui met l'objet dans un état particulier avant de le tester. En effet, l’exécution d'une méthode pour un état donné se fait directement en exécutant cette méthode sur une instance de la classe correspondant à cet état.

Cependant, de nouveaux problèmes de test surgissent, qui semblent spécifiquement liés à la conception orientée objet, et plus particulièrement, à la microarchitecture correspondant à l’application du design pattern.
1   ...   20   21   22   23   24   25   26   27   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