THÈse présentée








télécharger 0.65 Mb.
titreTHÈse présentée
page26/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.7Analyse de testabilité des design patterns


Nous nous intéressons maintenant à la résolution des anti-patterns de testabilité à un niveau local, pour diminuer la complexité de la testabilité du système global (cf. section 5.3.7). Nous illustrons l'analyse de testabilité proposée (voir section ) sur deux microarchitectures, correspondant aux applications des design patterns Abstract Factory et State. Le choix d'utilisation des diagrammes UML/OMT pour décrire la structure du design pattern dans [Gamma''95] mène à plusieurs erreurs d'interprétation. Par ailleurs, l'introduction de stéréotypes appropriés pour clarifier la conception doit être faite à la main. Nous proposons ainsi d'employer des diagrammes de collaboration comme représentation pour décrire les design patterns [Le Guennec''00; Sunyé''00]. D’une part, cette représentation est plus adaptée à la description des aspects statiques et dynamiques des patterns. D’autre part, elle peut servir à une application automatique des design patterns sur un diagramme de classes. La définition des contraintes pour la testabilité au niveau méta permet alors une application automatique des stéréotypes sur le modèle.

5.7.1Analyse de testabilité de State




Figure 77 – Une application du Design Pattern State

Nous appliquons l’analyse de testabilité (section ) sur une instance du design pattern State dont le diagramme de classes est donné sur la Figure 77. Ceci nous permet de détecter avec plus de précision les problèmes de testabilité spécifiques à l'application du pattern State évoqués à la fin de la section 5.6. Dans cette application particulière l'association entre TCPConnection et TCPState est bidirectionnelle : TCPConnection garde une référence sur son état courant, et chacun des états concrets doit connaître son contexte pour changer la valeur de l’état courant. Cette association bidirectionnelle cause des interactions multiples d'auto utilisation autour de TCPConnection.

Une solution pour améliorer la testabilité du diagramme de classes de la Figure 77 est d’employer autant que possible des interfaces à la place des classes abstraites ; ceci évite les liens partant des classes filles vers les classes mères. Si seules les classes feuilles dans la hiérarchie d’héritage (classes qui n'ont aucun descendant) sont des classes concrètes, la complexité de l'interaction traversant cette hiérarchie est réduite (il n'y a plus d'interactions entre les classes dans la hiérarchie).

Le test de l'application du pattern State consiste à vérifier que les méthodes de la classe TCPConnection dépendant de l’état courant ne font pas autre chose qu'une délégation vers l’attribut currentState. Par ailleurs, il faut vérifier si les états concrets n'appellent pas les méthodes du contexte qui sont déléguées à l'attribut currentState. Si ces contraintes sont vérifiées, il n'y a aucune interaction puisque nous pouvons assurer qu'il n’y aura pas d'interactions d’auto utilisation.

En appliquant le pattern State comme dans [Gamma''95], trois anti-patterns de testabilité sont détectés (des interactions potentielles d'AU). Si toutes les classes abstraites sont converties en interfaces, les trois interactions demeurent mais sont moins complexes. Enfin, si la contrainte de délégation du modèle est vérifiée, il n'y aura plus d'interaction dangereuse.

5.7.2Analyse de testabilité d'Abstract Factory


La Figure 78 montre une application du design pattern Abstract Factory prise de [Gamma''95]. Une interaction de classes apparaît entre la classe Client et chaque classe produit concret (Window ou ScrollBar concrètes) : la classe Client peut utiliser un produit concret directement ou à travers la hiérarchie d'héritage de WidgetFactory.

Comme pour le pattern State, une règle informelle pour améliorer la testabilité du diagramme de classes de la Figure 78 consiste à employer autant d'interfaces que possible. Pour tester l'application du pattern Abstract Factory, nous devons vérifier si la délégation de Client à WidgetFactory crée tous les objets et ne fait pas autre chose. Si l'application du design pattern est correcte, la classe Client doit employer les méthodes de création des produits concrets a travers la hiérarchie d'héritage de WidgetFactory et les autres méthodes par appel direct aux instances des produits concrets. Dans ce cas il n'y a aucun anti-pattern puisque les chemins concurrents entre le client et les produits sont utilisés pour différents buts. En appliquant l'Abstract Factory telle que décrite dans [Gamma''95] (Figure 78), quatre interactions de classe peuvent être détectées. Si toutes les classes abstraites sont converties en interfaces, les quatre interactions demeurent mais sont moins complexes. Enfin, si la délégation est bien appliquée, toutes les interactions de classe sont résolues.



Figure 78 – Une application du Design Pattern Abstract Factory

Pour ce qui concerne la bonne implémentation de la délégation, la solution serait d'exprimer des contraintes d'implantation sur le modèle pour spécifier clairement la délégation. Cependant, de telles contraintes devraient être exprimées au niveau du méta modèle, puisqu'elles concernent des éléments UML et des concepts non modélisés. Plus précisément, il est impossible d'exprimer avec l’OCL qu'une méthode a tout au plus une action à exécuter et que cette action devrait appeler une autre méthode. Un stéréotype «delegation» pourrait être un contournement possible pour ce problème, puisqu'un stéréotype peut avoir des contraintes de méta niveau. Cependant, cette solution n'est pas satisfaisante, puisqu'un stéréotype n'a pas de paramètres et ainsi ne pourra identifier la méthode déléguée. Pour résoudre ce problème, nous employons une autre représentation de design patterns, qui permet d’exprimer des contraintes sur leur implantation, et ainsi de supprimer les anti-patterns.

5.7.3Définir des contraintes de testabilité au niveau méta


Le diagramme de structure UML/OMT du design pattern dans [Gamma''95] représente des modèles et peut ainsi décrire uniquement une occurrence (ou instance) d'un design pattern. Il ne peut saisir leur vraie structure, exprimée en termes de "rôles", joués par les éléments du modèle (classes, attributs, associations et méthodes).

Nous détaillons ici deux solutions pour exprimer des design patterns au méta niveau, la première est fondée sur des collaborations paramétrés UML, et la seconde consiste à étendre le méta modèle UML. L'idée est que des contraintes de testabilité peuvent être attachées à ce méta niveau de sorte que les stéréotypes appropriés soient automatiquement ajoutés chaque fois qu'un concepteur crée une instance d’un pattern. Nous illustrons cette approche sur le design pattern Factory



Figure 79 – Collaboration paramétrée

L'utilisation des collaborations paramétrées dans UML est une approche prometteuse pour décrire la structure d'un pattern. Un exemple de cette notation pour modéliser l'Abstract Factory pattern est présenté sur la Figure 79. Ce pattern est composé de deux rôles classificateurs (Factory et Product) et une contrainte de relation «create». Cependant, d’après [Sunyé''00], les collaborations présentent toujours un manque et ne peuvent représenter avec précision ce pattern. Plus précisément, les concepteurs ne peuvent pas indiquer que ce ne sont pas des rôles de classes individuelles, mais de hiérarchies de classes. Le concepteur ne peut pas non plus indiquer que Factory devrait avoir une méthode "créatrice".



Figure 80 – Le design pattern Abstract Factory

La Figure 80 présente le même pattern, en utilisant une notation différente, proposée dans [Le Guennec''00], où des patterns sont décrits en tant que collaborations du niveau méta, complétées par des contraintes. Ici, ce modèle se compose de trois rôles : Factory, Product and Creator. Le premier rôle est une " hiérarchie", i.e. un ensemble de classes liées par une relation de généralisation. Le second est un ensemble de « hiérarchies ». Finalement, le troisième rôle décrit un ensemble de "tribus". Une "tribu" [Eden''99] est un ensemble d’éléments partageant une signature commune. Chaque élément est possédé par un élément de la hiérarchie Factory. Une contrainte est attachée au rôle creator : il doit effectuer une action simple, l'instanciation d'un product (cette contrainte est concrétisée par le lien «create»). Ceci implique que la multiplicité de Creator est équivalente à celle des hiérarchies de product.

Un exemple de ce modèle est présenté sur la Figure 81. Window et ScrollBar jouent le rôle de products, et la hiérarchie de classe WidgetFactory joue le rôle de Factory. Il y a deux clans de méthodes de création dans la hiérarchie WidgetFactory (CreateScrollBar() et CreateWindow()). Cette instance de Factory en combinaison avec une des représentations du méta niveau des Figure 79 ou Figure 80 implique que n'importe quelle dépendance entre WidgetFactory (qui crée une instance du rôle Factory) et Window ou ScrollBar (qui crée une instance du rôle Product) est stéréotypée «create». Ainsi, les stéréotypes pour l’amélioration de la testabilité de l’application du pattern sont automatiquement ajoutés pour éviter l'interaction de classe de la classe client vers les classes product. La tâche suivante est une vérification (qui peut être effectuée statiquement par un CASE tool) de la contrainte «create» sur l’implantation.



Figure 81 – Un exemple du design pattern Abstract Factory

5.7.4La grille de testabilité des design patterns


Pour guider les concepteurs, nous proposons la grille suivante qui résume les problèmes de testabilité potentiels pour chaque design pattern lorsque le rôle des associations entre les classes n’est pas défini explicitement. Nous adoptons les instanciations du modèle proposées par Gamma [Gamma''95] puisque nous sommes convaincus que la plupart des concepteurs les prennent comme références. Ceci nous permet de paramétrer chaque pattern comme une fonction des éléments principaux qu'il implique.

Nous nous concentrons sur les design patterns fondamentaux sélectionnés par [Agerbo''98] : Abstract Factory, Bridge, Builder, Composite, Decorator, Flyweight, Proxy, Iterator, Mediator, Memento et State. Il apparaît que les modèles les moins testables sont Mediator et Visitor. Mediator est très semblable au pattern Observer, dont la testabilité a était exhaustivement étudiée par Mc Gregor [McGregor''99]. Quant au pattern Visitor, il est particulièrement difficile à tester à cause d'une utilisation étendue du polymorphisme et une exécution fondée sur le « double renvoi ».

Design Pattern

nombre de participants

nombre d’interactions de classes

nombre d’interactions d’auto-utilisation

Abstract Factory

1 client

1 classe factory abstraite

n classes factory concrètes

m produits abstraits

p produits concrets



p X n*p



aucun

Bridge

les parametres n’ont pas d’influence

aucun

aucun

Builder

1 client

1 classe builder abstraite

n builder concrets

p produits

p X n*p

(même type que Abstract Factory)


aucun

Composite

1 client

1 classe composant abstraite

n classes composant concrètes


aucun


n


Decorator

1 interface

1 classe composant

1 classe decorator abstraite

n classes decorator concrètes


aucun



aucun


Flyweight

Comme abs. fact.

Comme abs. fact.

Comme abs. fact.

Iterator

1 client

n ConcreteAggregate

n ConcreteIterator



aucun

2*n

(n du client au ConcreteIterator, n du client au ConcreteAggregate)

Proxy

1 classe subject abstraite

1 proxy

1 sujet réel


aucun


aucun

Chain of responsibility

1 client

1 classe handler abstraite

n classes handler concrètes


aucun


n

Mediator

1 classe mediator abstraite

1 classe colleague abstraite

n classes colleague concrètes

m classes mediator concrètes


aucun


m*n

Memento

1 memento

1 originator

1 caretaker


aucun


aucun

State

1 classe context

1 classe abstraite state

n classes state concrètes

(délégation implicite des classes state concrètes vers context)



no



aucun

Visitor

n éléments visités

(ConcreteElement)

p visiteurs

(ConcreteVisitor)


aucun


n*p
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