Architectures Logicielles: Modélisation et Analyse - Partie II : Les design patterns

Institut Supérieur d'Informatique
1/29
100%
Rendu du PDF...
Page 1 sur 29Lecteur de document UniversityLib

Architectures Logicielles: Modélisation et Analyse - Partie II : Les design patterns

Institut Supérieur d'Informatique · Software Engineering · course

Voir tous les documents en génie logiciel

Architectures Logicielles

Modélisation et Analyse

Partie II : Les design patterns

Rania MZID KEBEILI

Maitre-assistante à l’institut Supérieur d’informatique

Docteur en Ingénierie des Systèmes Informatiques

Ingénieur en Informatique

Membre de l’unité de recherche CES

Contact: [email protected]

R. MZID KEBEILI

Architectures Logicielles

Les patrons

Introduction

--Motivation/Historique --

 Problème (origine)

o Problème

commun

(récurrent)

dans

le

processus

de

développement de plusieurs logiciels

o Pas de standard, pas de méthode pour mettre en œuvre cette prise

de conscience

o Un nouveau membre dans l’équipe => le problème est plus grave!

 Solution

o 1994-1995: Utilisation des patrons

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons

Introduction

--Définition --

 “ Each pattern describes a problem which occurs over and over again in

our environment, and then describes the core of the solution to that

problem, in such a way that you can use this solution a million times

over, without ever doing it the same way twice “ Christopher Alexander

 C’est une description d’un problème et une solution bien connue

o <problème, solution> validée par l’expérience

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons

Introduction

--Description--

Mon pattern

 Nom

 Description générale

 Problème

 Solution (description de diagrammes)

 Suggestion d’implantation

 Avantages et limites

 Exemple

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons

Introduction

--Classification/Portée--

 Différents niveaux d’abstraction

o Patron architecturaux (style)

 In software development, architectural style refers to the general

shape of the system

 Choosing the appropriate style is important because all the later

design decisions are made in the context of this style and in concert

with the style.

o Patron de conception

 Design patterns solve individual design problems within a particular

context

R. MZID KEBEILI

Architectures Logicielles

1

Publicité

Les patrons

Introduction

--Portée--

 Différents niveaux d’abstraction

o Patron de conception

 They address problems across a system, but instead of involving the

entire system, as architectural patterns do, they affect only a few

components

o Langage patterns (idioms)

 Recurrent problems related to a specific language

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons de conception

Objectifs

 La thèse de Erich Gamma éditée en livre « Design Patterns:

Elements of Reusable Object-Oriented Software » Addison

Wesley, 1995

 Une solution classique à un problème de conception récurrent

o Solution éprouvée

o Solution indépendante du contexte

 Ces patrons sont proposés afin d’etre appliquer dans une

approche OO  Réutilisation

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons de conception

Familles

 23 Design patterns

 Création

 Structure

o Initialisation et configuration des classes et des objets

o Séparation des préoccupations et abstraction pour

réutilisation

 Comportement

o Combiner interactions et structure

R. MZID KEBEILI

Architectures Logicielles

la

1

Les patrons de conception

Exemples de patron

--Singleton--

 Le problème

 La solution

o Assurer qu’une classe n’a qu’une seule instance

o Le constructeur est privé

o Une méthode renvoie la seule instance existante (i.e. Instance crée

si il n’en existe pas encore)

o Exemple de situation : Réalisation d’un jeux de cricket

o Dans un tournoi, chaque équipe doit choisir un capitaine pour

commencer le jeu . Donc, si votre équipe n’a pas de capitaine, vous

devez d’abord choisir un capitaine. Votre équipe ne peut pas avoir

plus d’un capitaine .

1

R. MZID KEBEILI

Architectures Logicielles

Les patrons de conception

Exemples de patron

--Singleton--

 Exemple de mise en œuvre en java

o UML Class Diagram

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons de conception

Exemples de patron

--Singleton--

 Exemple de mise en œuvre en java

o Package Explorer view

R. MZID KEBEILI

Architectures Logicielles

1

Publicité

Les patrons de conception

Exemples de patron

--Simple Factory (Concrete Factory) --

 Problème

 Solution

o Logique de création d’instance avec If-else-statement (coté client)

o  extension  changer le code

o  duplication du code : cas plusieurs client

1. Séparation fabrique/fabriquant

 Une entité fabrique qui se charge de la création des objets

(Dependency injection)

 Les clients reçoivent un objet fabrique et s’en servent pour

créer le produit, pas de new produit dans leur code

1

R. MZID KEBEILI

Architectures Logicielles

Les patrons de conception

Exemples de patron

--Simple Factory (Concrete Factory) --

 Solution

2. La Fabrique dépend de l’interface (couplage faible)

 Programmer par rapport aux interfaces

 Code fermé á la modification/ouvert á l’extension

Factoriser le code de

Construction de sorte que

les évolutions dans la

hiérarchie n’auront

d’impact que sur la

fabrique

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons de conception

Exemples de patron

--Factory Method --

 Le problème

 Solution

o Même problème que simple factroy

o Une méthode pour créer les objets au niveau de la fabrique

implémentée dans la fabrique concrète

o Une méthode par fabrique concrète qui crée un seul objet (produit)

The factory method pattern aims to create an object without

knowing How, Why and what parameters we need to create

this object

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons de conception

Exemples de patron

--Factory Method --

 Solution : Diagramme UML

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons de conception

Exemples de patron

--Abstract Factory --

 Le problème

o Plusieurs logique de création sont possibles (avec possibilité de

combinaison)

 Solution

o La classe fabrique encapsule cette logique de création  plusieurs

méthodes factory

o Chaque factory implémente les combinaisons ayant un sens

o Les produits sont organisés en familles

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons de conception

Exemples de patron

--Abstract Factory --

Solution : Diagramme

UML

Publicité

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons de conception

Exemples de patron

--Abstract Factory --

 Exemple d’utilisation

o UI control for platform-independance

 Avantages

 Décharger le client de la tache d’instanciation (contrôle particulier

pour des combinaisons significatives des produits) : c’est la factroy

qui encapsule cela

 Totalement extensible pour des mises á jour

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons de conception

Exemples de patron

--Observer--

 Le problème

o Assurer la séparation Observable/Observer

o Observable : un objet (subject) qui change d’état

o Observer : une entité intéressée par le changement d’état d’un

objet (on peut avoir plusieurs : *observers)

o POLL architecture : the observer demande l’état de l’observable

chaque dt  Problème si plusieurs observers 

 Solution

o PUSH architecture : quand l’objet change d’état, il informe tous les

subcribed clients (observers) par une notification (push a

notification)  One to many dependencies

1

R. MZID KEBEILI

Architectures Logicielles

Les patrons de conception

Exemples de patron

--Observer--

 Exemple de situation

o Séparation Vue/donnée (Model)

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons de conception

Exemples de patron

--Observer--

 UML Diagram

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons de conception

Exemples de patron

--Composite--

 Le problème

o Une relation d’héritage entre plusieurs objets qui forment une hiérarchie

(arbre)

o Éviter

les

if-else statement pour

le traitement des nœuds pour

l’implémentation d’une méthode => Gérer un objet comme un groupe

d’objets

 Solution

o Une interface qui définit la méthode concernée

o Deux types de nœuds (Leaf and composite) qui implémentent cette

interface (cette opération)

o Le client exécute la méthode concernée en faisant abstraction du type du

nœud

1

R. MZID KEBEILI

Architectures Logicielles

Les patrons de conception

Exemples de patron

--Composite--

 UML Diagram

Publicité

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons de conception

Exemples de patron

--Adapter--

 Problème

o Deux interfaces incompatibles qui doivent communiquer

o Un client cherche á utiliser un service fourni par une interface qui est

différent du service implémenté

 Solution

o Créer un adapter (Wrapper) qui permet de rendre deux interfaces

compatibles en adaptant leurs comportements

 Exemple de situation

o Une utilisation d’une librairie qui peut changer par la suite

o Une mise á jour des fonctionnalités d’un framework, etc.

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons de conception

Exemples de patron

--Adapter--

 UML Diagram

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons de conception

Exemples de patron

--Strategy--

 Problème

o Un algorithme (ou un comportement) qui varie selon le type de client 

relation d’héritage en adaptant le traitement au sous classes

o Découpler le traitement du client

 Solution

o Créer des stratégies qui implémentent les algorithmes

o Le client ne change pas si l’algorithme change (le client ne dépend pas de

la stratégie)

=> L’utilisation de la composition au lieu de l’héritage qui est dans ce

contexte plus adapté pour la réutilisation que l’héritage (des algorithmes

qui changent)

1

R. MZID KEBEILI

Architectures Logicielles

Les patrons de conception

Exemples de patron

--Strategy--

 UML Diagram

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons de conception

Exemples de patron

--Bridge--

 Problème

o Un problème de produit cartésien entre deux relations de hiérarchie

o Nombre de combinaison augmente exponentiellement avec le nombre de

sous classes

o Risque de violation du principe d’agrégation d’interface (en cas de

comportements différents)

 Solution

o Découpler l’abstraction de l’implémentation

=> L’abstraction se charge d’instancier la ressource en cas de besoin

R. MZID KEBEILI

Architectures Logicielles

1

Les patrons de conception

Exemples de patron

--Bridge--

 UML Diagram

R. MZID KEBEILI

Architectures Logicielles

1