Présentation du concept de design pattern

Depuis les premiers temps de la programmation, les développeurs furent confrontés à différents problèmes de conception. Une partie de ces problèmes étant récurrente, en utilisant leurs expériences, des groupes de développement mirent au point des solutions génériques à ces problèmes. Ces solutions sont communément appelées design patterns. En français, il existe plusieurs appellations : motif de conception, modèle de conception ou encore patron de conception. Dans ce mémoire, nous utiliserons le terme de design pattern.

Les premiers design patterns sont proposés dans les années 70 par l’architecte Christopher Alexander dans son livre « A Pattern Language ». Ces design patterns sont alors appliqués à des problèmes d’architecture [Alex 77] (il n’est pas ici question d’architecture logicielle ou matérielle, mais de l’architecture de batiments). Puis, ces principes sont repris et appliqués au génie logiciel avec, en 1994, le livre « Design Patterns: Elements of Reusable ObjectOriented Software » [Gamm 95] écrit par le Gang Of Four (plus de détails sur ce sujet sont disponibles dans la section 2.2). Depuis, de nombreuses études et de nombreux travaux ont été réalisés sur le sujet. Beaucoup d’auteurs ont même publié leurs propres design patterns, par exemple les patterns GRASP [Larm 12].

De nombreuses définitions existent pour définir ce qu’est un design pattern. Le Gang Of Four reprend la définition proposée par Christopher Alexander qui dit que « chaque modèle décrit un problème qui se manifeste constamment dans notre environnement, et donc décrit le coeur de la solution de ce problème, d’une façon telle que l’on peut réutiliser cette solution des millions de fois, sans jamais le faire deux fois de la même manière » [Alex 77] .

Généralement, une description d’un design pattern comporte les informations suivantes :

1. Le nom du pattern.
2. Le problème que le pattern permet de résoudre.
3. La solution proposée pour résoudre le problème.
4. Les avantages et les inconvénients de cette solution.

L’utilisation des design patterns permet d’obtenir trois avantages [Ager 98, Larm 05] :
• Les design patterns offrent des solutions éprouvées et validées par des experts. Leur utilisation permet d’obtenir une bonne qualité de la conception.
• Les design patterns sont connus par un grand nombre de développeurs. Ils permettent donc de faciliter la communication entre les développeurs.
• Les design patterns permettent de faciliter la documentation des conceptions logicielles.

Le gang of four 

Le GOF (acronyme de Gang Of Four) désigne les quatre co-auteurs du premier des livres majeurs sur les design patterns [Gamm 95]. Richard Helm, Erich Gamma (un des fondateurs de l’IDE Eclipse et de l’environnement de test jUnit), Ralph Johnson (un des pionniers du langage Smalltalk) et John Vlissides ont mis en commun leurs expériences pour proposer 23 design patterns. Bien que publiés en 1994, ces 23 patterns restent encore aujourd’hui une référence .

Le GOF classe ces 23 patrons en 3 catégories :
• 5 patterns de construction qui définissent comment créer et configurer les objets: fabrique abstraite, créateur, fabrique , prototype et singleton.
• 7 patterns structuraux qui définissent comment organiser les classes d’un programme: adaptateur, pont, composite, décorateur, façade, poids-mouche et proxy.
• Il patterns comportementaux qui définissent comment répartir les responsabilités entre les objets: chaîne de responsabilité, commande, interpréteur, itérateur, médiateur, memento, observateur, état, stratégie, méthode et visiteur.

Les quatre sous sections suivantes présentent quatre patterns proposés par le GOF: Observer, Composite, Visitor et Prototype. Il est à noter que ces quatre patterns choisis en illustration sont · les quatre patterns considérés par l’étude présentée dans ce mémoire. Le choix de ces quatre patterns a été influencé par l’outil utilisé, permettant de détecter les patterns dans le code source. En effet, ce sont ces quatre patterns qui sont détectés avec la meilleure précision par cet outil .

Le pattern Observer 

Il peut exister une classe, dite « subject « , dont les valeurs changent régulièrement, Il peut aussi exister d’autres classes, les Il observer Il , qui doivent être informées des changements survenus sur le « subject « , Cette relation peut être illustrée par des tableaux qui affichent des statistiques sur la production d ‘une usine (les observers) et un système qui collecte et stocke ces statistiques (le sujet), Si des données sont ajoutées dans le système, les statistiques sont recalculées .

Le pattern Composite 

Il peut être nécessaire de manipuler des collections composées d’objets simples et d’objets composés d’objets simples. Par exemple, une collection d’articles à vendre dans un magasin: ce magasin vendrait des torchons (« leaf ») et des serviettes (« leaf »), mais aussi un kit spécial qui serait un mélange de torchons et de serviettes (« composite »). Le système du magasin (« client ») doit pouvoir manipuler les articles ( » component ») sans avoir à considerer s’il s’agit d’articles simples ou de kits composés d’articles simples.

Table des matières

1 Introduction
1.1 Contexte.
1.1.1 La maintenance .
1.1.2 Les design patterns .
1.2 Problématique
1.3 Organisation du mémoire
1 Éléments contextuels
2 Design patterns
2.1 Présentation du concept de design pattern
2.1.1 Historique.
2.1.2 Définition
2.1.3 Avantages.
2.2 Le gang of four ..
2.2.1 Le pattern Observer
2.2.2 Le pattern Composite
2.2.3 Le pattern Visitor ..
2.2.4 Le pattern Prototype.
3 La qualité logicielle
3.1 Introduction…
3.2 La norme ISO 9126 .
3.2.1 La maintenabilité .
3.3 Les métriques
II État de l’art
4 Évaluation de la changeabilité
4.1 Études qui introduisent des changements dans le code.
4.2 Études qui exploitent les données des dépôts
4.3 Autres études
4.4 Relation entre les études
4.5 Synthèse
5 Évaluation de la testabilité
5. 1 Études théoriques.
5.2 Études empiriques
5.3 Études qui proposent des modèles .
5.4 Relation entre les études ….. .
6 Comment évaluer l’impact des design patterns?
6.1 Études quantitatives ………. .
6.1.1 Introduction des design patterns
6.1.2 Analyse de code existant .
6.2 Études qualitatives
6.3 Conclusion …..
III Étude expérimentale
7 . Méthodologie de l’étude
7.1 Objectifs.
7.2 Questions
7.3 Métriques
7.3.1 N ombre de design patterns
7.3.2 Changeabilité et testabilité
7.4 Processus de collecte des données
· 7.4.1 Collecte pour les Questions 1.1′ et 1. 2′
7.4.2 Collecte pour les Questions 2.1′ et 2.2′
7.5 Outils
7.5.1 Logiciels tiers
7.5.2 Le logiciel créé pour cette étude : Eippoo .
7.6 Présentation des études de cas .
8 Etude de cas
8.1 Étude des Questions 1.1′ et 1.2′
8.1.1 Rappel des questions de recherche.
8.1.2 Hypothèses
8.1.3 Résultats
8.1.4 Évaluation des hypothèses .
8.1.5 Réponses aux Questions 1.1′ et 1.2′
8.2 Étude des Questions 2.1 ‘ et 2.2’
8.2.1 Rappel des questions de recherche.
8.2.2 Hypothèses
8.2.3 Résultats
8.2.4 Évaluation des hypothèses .
8.2.5 Réponses aux Questions 2.1 ‘ et 2.1 ‘
8.3 Conclusion.
IV Discussions et conclusion

Cours gratuitTélécharger le document complet

 

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *