Nol NOVELLI ; Universit dAix-Marseille; LIF et Dpartement dInformatique Case 901 ; 163 avenue de Luminy 13 288 MARSEILLE cedex 9

Gnie Logiciel

Merise

Modlisation objet

UML

Ce support nest quune adaptation des supports rdigs par Isabelle VALEMBOIS
(Thales-services)
 MERISE
Les modles de la mthode Merise :
Le modle de flux
Le modle conceptuel de donnes
Le modle conceptuel de traitements
Le modle organisationnel de traitements
Le modle logique de donnes
Le modle oprationnel des traitements
Le modle physique des donnes
En savoir plus sur Merise :
La mthode MERISE - H. Tardieu, A. Rochefeld, R.
Colletti
 MODELISATION OBJET (1/6)
Principaux concepts objet :
Classe
Type dobjet caractris par sa structure de donnes (attributs)
et son comportement (mthodes)
Objet
Un objet reprsente un individu, une entit identifiable relle ou
conceptuelle avec un rle bien dfini dans le domaine du
problme ou dans un systme (instance de classe)
Attribut
Un attribut est une proprit, une caractristique, une qualit
inhrente ou distinctive dun objet (exemples : la couleur ou
limmatriculation dune voiture)
Mthode
Une mthode est une action quun objet effectue de sa propre
initiative ou la demande (raction un vnement ou un
envoi de message). Ces mthodes dcrivent les proprits
dynamiques dun objet.
 MODELISATION OBJET (2/6)
Principaux concepts objet :
Quelques mthodes "classiques" :
Un constructeur est une mthode qui permet de construire et
dinitialiser un objet (instanciation dun objet)
Par opposition, un destructeur est une mthode qui permet de
dtruire un objet instanci
Un accesseur est une mthode qui permet de rcuprer la valeur
dun attribut dun objet (get et is)
Un modificateur est une mthode qui permet de modifier la
valeur dun attribut dun objet (set)
Un observateur est une mthode qui permet de retrouver des
informations sur lhistoire (ltat) dun objet
Un itrateur est une mthode qui permet dappliquer chaque
partie dun objet (par exemple dans le cas dun objet de type
collection) une action dtermine
 MODELISATION OBJET (3/6)
Principaux concepts objet :
Association
Une association permet de prciser une relation entre diffrents
objets. Une association possde gnralement un nom qui sert
dcrire la nature de la relation
Une association est galement caractrise par le nombre dobjets
pouvant tre relis par lintermdiaire dune instance dassociation :
0..1, 0..n, 1..n, n..n
Agrgation
Une agrgation est une relation binaire entre deux objets qui
spcifie une inclusion entre une partie et un tout. Une partie peut
appartenir dautres agrgations et exister indpendamment
Composition
Une composition est un type particulier dagrgation qui spcifie
une inclusion entre une partie et un tout plus forte que lagrgation :
quand on supprime llment composite, il y a obligatoirement
suppression des composants
 MODELISATION OBJET (4/6)

Principaux concepts objet :

Hritage
Mcanisme permettant une classe dobjets de bnficier de la
structure de donnes et du comportement dune classe "mre",
tout en lui permettant de les affiner et ce, afin de prendre en
compte les spcificits de la classe "fille", sans avoir cependant
redfinir ce que les deux classes ont de commun

Gnralisation
Dans le cas dun hritage, on dit quune classe "mre" est une
gnralisation des proprits de ses classes "fille"

Spcialisation
Dans le cas dun hritage, on dit quune classe "fille" est une
spcialisation des proprits de sa classe "mre"
 MODELISATION OBJET (5/6)
Principaux concepts objet :
Encapsulation (interface)
Mcanisme permettant de dissimuler les dtails du
fonctionnement interne dune classe aux autres classes
Abstraction (classe abstraite)
Mcanisme permettant la dissociation entre la dclaration dune
classe et son implmentation (interface)
Polymorphisme
Mcanisme permettant dassocier un comportement, une
implmentation diffrente en fonction de lobjet auquel on se
rfre (par exemple : dessiner lcran un carr ou un cercle).
Lmetteur na pas besoin de connatre la classe du receveur,
seulement que la smantique du message sera la mme pour
toutes les classes similaires (par exemple : la mthode toString
en JAVA, les injecteurs en C++)
 MODELISATION OBJET (6/6)
Principaux concepts objet :
Message
Mcanisme caractristique des langages objet. Le message est
lunique support de communication entre objets. Larrive dun
message provoque lexcution dune mthode de lobjet
Type daccs, porte, visibilit
Public
Private
Protected
Surcharge de mthode
Mcanisme permettant de dclarer plusieurs constructeurs ou
plusieurs fois une mme mthode (mme nom) dans une classe,
condition que tous aient une signature diffrente (valeur de
retour et/ou paramtres diffrents)
 UML (1/24)

UML (Unified Modeling Language) :

Auteurs
James Rumbaugh, Grady Booch et Yvar Jacobson

Objectifs
Faciliter la communication entre les diffrents acteurs dun
projet
Faciliter la communication avec la machine
Documenter un projet de bout en bout
Spcifier et donc limiter les ambiguts
Construire (interprter les diagrammes pour code)

Dfinition
Langage de description des objets permettant une
modlisation rigoureuse des systmes complexes
Langage Unifi pour la Modlisation objet
 UML (2/24)

UML nest pas une mode :

Issu du terrain et dun large consensus (industriels,
informaticiens, mthodologistes), fruit dun travail dexperts
(HP, Microsoft)
Norme riche (permet de spcifier du dbut la fin) et
ouverte (en constante volution depuis sa cration)
Indpendant de la cible
Adapt la programmation orient objet
Industrialis (il existe de nombreux doutils)
Plus dinformations sur UML :
http://uml.free.fr (<1.1)
http://fr.wikipedia.org/wiki/Unified_Modeling_Language
 UML (3/24)

Avantages dUML :
Formel et normalis (garantit stabilit et performance
dun projet, rduit les risques)
Support de communication performant et prouv
(permet de cadrer lanalyse et de faciliter la
comprhension de reprsentations abstraites : cest
lesperanto de lanalyse)
Inconvnients dUML :
Priode dapprentissage
Processus de production non couvert
 UML (4/24)

Historique
 UML (5/24)

Diagrammes
UML :
 UML (5/24)
Dcouverte des besoins
Diagramme de cas dutilisation : dcrit les fonctions du
systme (point de vue de ses futurs utilisateurs -Jacobson)
Diagramme de squence : reprsentation des interactions
temporelles entre objets dans la ralisation dune IHS
Analyse
Diagramme de classes : structure des donnes
Diagramme dobjets : illustration
Diagramme collaboratif : reprsentation des interactions
entre objets
Diagramme dtats : reprsentation du comportement des
objets dune classe en terme dtats et de transitions dtats
Diagramme dactivits : structure dune opration en
actions
 UML (5/24)
Conception
Diagramme de squence : reprsentation des interactions
temporelles entre objets dans la ralisation dune opration
Diagramme de dploiement : description du dploiement
des composants sur les dispositifs matriels
Diagramme de composants : architecture des composants
physiques dune application
 UML (6/24)

Le diagramme de cas dutilisation :

Il permet didentifier et de dcrire les utilisateurs du
systme (acteurs) et leur interaction avec le systme
Dmarche :
Identification des acteurs

Acteur

Identification des cas dutilisation

CU
 UML (7/24)

Les relations dans un diagramme de cas

dutilisation :
Utilisation : la relation include indique quun CU utilise un
autre CU. Si le CU source est vide, alors dcomposition
<< include >>
Imprimer solde
Consulter compte

<< include >>

Imprimer ticket

Extension : la relation extend du CU A vers le CU B indique que

le CU B peut aussi faire A. Ceci permet aussi les CU avec garde.
<< extend >>
retirer de largent retirer des Francs

<< extend >> Au moins un

des deux et
retirer des Euros pas les deux
 UML (8/24)

Exemple de diagramme de cas dutilisation :

 UML (9/24)
Les Classes

+ attributs drivs
ou calculables
 UML (10/24)

Le diagramme de classes :
Il permet de dcrire les classes dun systme ainsi que les
associations et les relations dhritage entre ces classes
Les associations (forme verbale)

active, Personne
Travaille
Socit
pour >

rles, Employ
Personne Socit
Employeur

cardinalit, Personne 1..* Socit

*

qualification Universit N tudiant Etudiant

ou restriction
 UML (11/24)
Le diagramme de classes :
Il permet de dcrire les
classes dun systme ainsi
que les associations et les
relations dhritage entre
ces classes

Composition et agrgation

Lhritage
 UML (12/24)

Le diagramme dobjets :
Le diagramme dobjets est un cas illustr dun
diagramme de classes. Selon le contexte, il montre la
relation entre les objets
 UML (13/24)

Le diagramme de collaboration :
Le diagramme
de collaboration
est une extension
des diagrammes
de classes
Il montre les
interactions entre objets
et vise reprsenter
du point de vue statique
et dynamique les objets
impliqus dans la mise en
place dune fonction
applicative
 UML (14/24)

Le diagramme dtats (transitions) :

Il permet de dcrire les changements d'tats d'un objet,
en rponse aux interactions avec d'autres objets ou avec
des acteurs
Etat initial Etat final
Etat

Un diagramme dtats possde

Un tat initial
Au moins un tat final
 UML (15/24)

Exemples de diagrammes dtats :

Evnement
Perte demploi()
En activit Au chmage
Embauche()

+ de 60 ans + de 60 ans
En retraite

Transition garde
A

Il fait trop chaud [t] Il fait trop chaud [hiver]

climatise are
 UML (16/24)

Le diagramme dtats (suite) :

Actions dans un tat

Synchronisation
 UML (17/24)

Le diagramme dtats (suite) :

Gnralisation

A E1 B

E2
C

A E1 B

E2 E2
C
 UML (18/24)

Le diagramme de squences :
Il permet de reprsenter des interactions entre les
objets selon un point de vue temporel
Reprsentation dun objet :
classe
Classe (grand rectangle)

Axe chronologique (ligne)

Dbut et fin de linteraction

(petit rectangle sur laxe)

NB : Il prsente un certain nombre

danalogies avec le diagramme de collaboration
 UML (19/24)

Le diagramme de squences :
Les messages :

simples

synchrones

asynchrones

rflectifs

avec dlai
 UML (20/24)

Le diagramme de squences :
Ajout de pseudo-code
Branche conditionnel

Objet : classe Autre objet

If

else

end if
 UML (20/24)

Le diagramme de squences (UML 2.0) :

Branche conditionnel
ALT pour if..then..else ou switch et OPT pour if..then

Objet : classe Autre objet Window: color

getColor()

ALT
setState( white )
[noir]

[blanc] setState( gray )

[gris] setState( black )

 UML (20/24)

Le diagramme de squences (UML 2.0) :

LOOP : boucle
Et aussi Break, par

Objet : classe Window:color Autres

getX()

LOOP
setValue( t[i], i )
[i < x]
 UML (21/24)

Exemple de
diagramme de
squences :
 UML (22/24)

Le diagramme
dactivits :
Il sagit dune variante
du diagramme dtat-
transition reprsentant
la dynamique du
systme
Il sert reprsenter le
comportement interne
dun cas dutilisation.
Son intrt rside dans
la reprsentation
simplifie des activits.
 UML (23/24)

Le diagramme de
composants :
Il dcrit les
lments
physiques et leurs
relations dans
lenvironnement
de ralisation
Il montre les choix
de ralisation
 UML (24/24)

Le diagramme de
dploiement :
Il montre la disposition
physique des diffrents
matriels (nuds) qui
entrent dans la
composition dun
systme et la rpartition
des programmes
excutables sur ces
matriels
Il montre les choix de
ralisation
 OUTILS (1/3)
Outils Merise :
Power AMC
MS-Designer
Outils UML :
Rational Rose (rachet et intgr par IBM)
Objecteering
Together ControlCenter
ArgoUML, Posidon
Outils de gestion de tests :
Mercury TestDirector
Compuware QADirector
Rational TestManager
 OUTILS (2/3)
Critres de slection des outils UML :
Respect des normes UML
OS supports
Stabilit
Exhaustivit des diagrammes
Correspondance relationnel
Gnration de code
Format de documentation
Gestion de configuration
Reverse engineering
Gestion de tests
 OUTILS (3/3)

Caractristiques des principaux produits de

modlisation :
 SPECIFICATIONS (1/5)

La spcification des besoins (ou des exigences)

Point de dpart
Dans les activits de spcification des exigences, il
convient dabord de considrer le systme comme une
bote noire part entire, afin dtudier sa place
dans le systme mtier plus
global quest lentreprise.
On dveloppe
pour cela
un modle de
niveau contexte,
qui va prciser
les frontires
fonctionnelles
du systme.
 SPECIFICATIONS (2/5)

La spcification des besoins (suite)

Cette activit met donc en uvre un mode de
reprsentation fonctionnel sappuyant sur :
Les diagrammes de cas dutilisation qui permettent
didentifier et de formaliser les diffrents acteurs ainsi
que les services attendus de la future application.
La maquette pour sa part, permet de prsenter de
manire concrte ces services via les IHM (Interface
Homme Machine) de lapplication. Elle est destine plus
particulirement faire ragir les utilisateurs de la
future application afin dy apporter les mises au point
ncessaires une complte adquation entre les
services rendus par lapplication et les besoins des
utilisateurs.
 SPECIFICATIONS (3/5)

La spcification des besoins (suite)

Exemple de diagramme de cas dutilisation :
 SPECIFICATIONS (4/5)

La spcification des besoins (suite)

Exemple de
description
pour le cas
dutilisation
sauthentifier
 SPECIFICATIONS (5/5)

La spcification des besoins (suite)

Exemple de
maquette :
 ANALYSE (1/8)

Lanalyse
tape
intermdiaire
entre la
spcification
des besoins
et la
conception
du systme
 ANALYSE (2/8)

Lanalyse statique
Pour identifier les classes de conception intervenant dans les
diagrammes dinteraction du modle conceptuel, deux sous-
tapes sont ncessaires :
Construire le modle du domaine. Sorte de glossaire formalis
des concepts fondamentaux de lespace du problme, ce modle
fournit une partie des classes de conception : celles
correspondant directement aux concepts mtier manipuls
par les experts du domaine et les utilisateurs. Ces concepts,
leurs attributs et leurs relations vont tre dcrits en UML par des
diagrammes de classes simplifies.
Construire les diagrammes de classes participantes. Afin de
prendre en compte galement lIHM et la cinmatique de
lapplication, les diagrammes de classes participantes font la
jonction entre les cas dutilisation, le modle du domaine, la
maquette et les diagrammes de conception logicielle. Il sagit
de diagrammes de classes qui dcrivent, par cas dutilisation,
les trois principales classes danalyse et leurs relations.
 ANALYSE (3/8)

Lanalyse statique (suite)

Les diagrammes de classes participantes :
Les classes de type dialogue : elles permettent les
interconnections entre lIHM et ses utilisateurs. Ce sont
typiquement les crans proposs lutilisateur : les
formulaires de saisie, les rsultats de recherche Elles
proviennent directement de lanalyse de la maquette.
Les classes de type mtier : elles reprsentent les
rgles mtier et proviennent directement du modle du
domaine mais sont confirmes et compltes pour
chaque cas dutilisation.
Les classes de type contrle : elles contiennent la
cinmatique de lapplication et font la transition entre
les dialogues et les classes mtier, en permettant aux
crans de manipuler des informations dtenues par un ou
plusieurs objets mtier.
 ANALYSE (4/8)

Lanalyse statique (suite)

Exemple de modle du domaine pour le CU
sauthentifier :
 ANALYSE (5/8)

Lanalyse statique (suite)

Exemple de diagramme de classes participantes pour le
CU sauthentifier :
 ANALYSE (6/8)

Lanalyse dynamique
Le modle dynamique permet de dcrire :
Pour chaque cas dutilisation, la squence des
interactions entre les acteurs et le systme vue comme
une bote noire, reprsente par les diagrammes de
squence systme. Ce sont ces diagrammes qui feront le
lien entre les cas dutilisation et les diagrammes
dinteraction du niveau conceptuel.
Dautre part, pour reprsenter de manire formelle
lensemble des chemins possibles entre les principaux
crans proposs lutilisateur, et partir des informations
fournies par la maquette, il reste dtailler les
diagrammes dactivits de navigation.
Si ncessaire, le cycle de vie commun aux objets dune
mme classe, peut tre explicit par les diagrammes
dtats.
 ANALYSE (7/8)

Lanalyse dynamique (suite)

Exemple de diagramme de squence systme pour le
CU sauthentifier :
 ANALYSE (8/8)

Lanalyse dynamique (suite)

Exemple de diagramme
dactivits de navigation
pour le CU
sauthentifier :
 CONCEPTION (1/3)

La conception du systme
Cible
Dans les activits de
conception, le modle
correspond aux
concepts
informatiques
utiliss par les
outils, les langages
ou les plates-formes
de ralisation. Le
modle sert ici
tudier, documenter,
communiquer et anticiper la solution logicielle.
 CONCEPTION (2/3)

La conception du systme (suite)

Dans le cadre de systmes orients objet, la structure du code
est dfinie par des classes logicielles et leurs regroupements en
ensemble (appels packages). La conception reprsente deux
points de vue : la structure statique et le comportement
dynamique, deux perspectives qui compltent la comprhension
du systme dvelopper.
Le modle statique, qui permet de dcrire les diffrents
composants logiciels structurant le systme, est reprsent
laide de diagrammes de classes de conception.
Le modle dynamique, permet quant lui de dcrire lattribution
des bonnes responsabilits (services) aux bonnes classes. Tout le
comportement du systme est ainsi rparti entre les classes de
conception. Cest le rle des diagrammes dinteraction
(diagrammes de squence ou de collaboration) de
reprsenter graphiquement ces dcisions dallocation de
responsabilits ainsi que les collaborations induites.
 CONCEPTION (3/3)

La conception du systme (suite) 1 - 2

Exemple de diagramme de classes de conception de
Struts :
 CONTENU DU DAF (1/2)
Introduction
Objectifs du document
Cible du document
Terminologie et acronymes
Structure du document
Documents de rfrence
Spcifications des besoins
Acteurs
Diagramme des cas dutilisations
Pour chaque CU : description du cas dutilisation
Contraintes fonctionnelles
 CONTENU DU DAF (2/2)
Analyse
Pour chaque CU :
Modle du domaine
Diagramme de classes participantes
Diagramme de squence systme
Diagramme dactivits de navigation
Diagramme dtats le cas chant

Conception
Pour chaque CU :
Diagramme de classes de conception
Diagramme de squence ou de collaboration

Annexes
MCD et MPD (le cas chant)
 STRATEGIE DE TESTS (1/4)

Enjeux de lactivit de tests

Enjeux mtier :
Adquation aux besoins
Non rgression

Enjeux techniques :
Niveau de service
o Performance
o Tolrance aux pannes
o Exploitabilit
Scurit
Prennit et volutivit

Enjeux conomiques
Rduction des cots de recette
Rduction de cots de maintenance
 STRATEGIE DE TESTS (2/4)

Les 6 bonnes pratiques de lactivit de tests

Lactivit de test doit tre anticipe
Les responsables de lactivit doivent tre identifis
Des ressources doivent tre ddies lactivit
Lutilisation doutils doit tre favoris
Lexhaustivit tant bien souvent utopique, il faut
viser la reprsentativit des cas de tests
Les tests doivent tre formaliss dans un dossier de test.
Celui-ci comportera 5 parties :
Prsentation du plan de test
Le cahier de test
Le rfrentiel des cas et scnarios de tests fonctionnels
Le rfrentiel des cas et scnarios de tests techniques
Le journal des tests
 STRATEGIE DE TESTS (3/4)

Prsentation du plan de tests

Objectif : dtecter un maximum danomalies
susceptibles de perturber le fonctionnement dun logiciel.
Les anomalies tant de nature diverse, il est ncessaire
de dfinir une stratgie en fonction de chaque type de
tests. La dmarche consiste :
dfinir chaque type de test (fonctionnels en excution attendue,
fonctionnels en excution dgrade, de performance)
tablir pour chacun les objectifs
assigner une priorit ces objectifs

construire une matrice de couverture

estimer le plan de charges et planifier
 STRATEGIE DE TESTS (4/4)

Cahier de test
Il a pour objectif de prsenter les modles de rfrence
en terme de tests pour le projet. A ce titre, il contient
tous les modles de documents utiliss dans le cadre de
lactivit de tests :
cas de test
scnario de tests
fiche danomalie
tableau de bord des anomalies

Rfrentiel des cas et scnarios de tests

fonctionnels
Il a pour objectif de rassembler les lments suivants :
Cas et scnarios de tests formaliss sur les fiches correspondantes
Prsentation de la logique dordonnancement des tests et planning
 REUTILISABILITE (1/11)

Dfinitions :
La rutilisabilit est laptitude dun logiciel tre
rutilis en tout ou en partie pour de nouvelles
applications
La rutilisabilit consiste se servir dun composant
pour en crer un nouveau
Objectifs :
Optimiser les cots de dveloppement
Optimiser les cots de maintenance
Fiabiliser les dveloppements
Favoriser lvolutivit, ladaptabilit, lutilisabilit
 REUTILISABILITE (2/11)
Techniques de rutilisabilit :
La duplication (inconvnient : la maintenabilit).
Le pr-processing : trs similaire la technique prcdente, il
intgre un outil spcialis, le pr-processeur. Ainsi, les
corrections d'erreurs comme les volutions apportes la
partie rutilise profitent l'application d'origine
(inconvnient : si des modifications sont faites sur le code
rutilisable et si tous les utilisateurs ne sont pas informs de ces
modifications, ceci peut altrer le fonctionnement peru par les
autres utilisateurs).
Les bibliothques de composants : cette technique consiste
appeler un composant excutable et d'en exiger un certain
comportement l'aide de paramtres.
Les frameworks : dans les bibliothques de composants, c'est
l'application qui invoque une routine de la bibliothque et c'est
l'application qui fait le contrle. Dans les frameworks, la
situation est inverse, c'est le framework qui dirige les
tches et qui fait des appels l'application si ncessaire
(Exemple : Struts).
 REUTILISABILITE (3/11)

Techniques de rutilisabilit (suite) :

Les techniques cites prcdemment ne
sapplique qu la phase dimplmentation
La rutilisabilit peut galement tre applique tous
les niveaux de dveloppement dun projet
Les patterns de conception : ils dcrivent des
problmes rcurrents, les solutions ces problmes
et les contextes dans lesquels ces solutions sont
considres. Un pattern nomme une technique, dcrit
ses cots et ses avantages. Il permet, une quipe,
de mettre un vocabulaire en commun pour dcrire des
modles (Exemple : Model View Controler II)
 REUTILISABILITE (4/11)
Les trois grandes familles de design patterns :
Les patterns de cration : ces patterns crent les objets
pour vous, au lieu de les instancier directement :
Le pattern Factory Method dfinit une interface pour
crer un objet, mais laisse les sous classes dcider
quelle classe instancier
Le pattern Abstract Factory fournit une interface pour
crer des familles d'objets lis sans spcifier leurs
classes concrtes
Le pattern Builder spare la construction d'un objet
complexe de sa reprsentation, de telle sorte que
plusieurs reprsentations diffrentes peuvent utiliser le
mme processus de construction
Le pattern Prototype spcifie le type d'objet crer en
utilisant une instance "prototype", et cre un nouvel
objet en effectuant une copie de cet objet
Le pattern Singleton assure qu'une classe a
uniquement une instance, et fournit un accs cette
instance
 REUTILISABILITE (5/11)

Diagramme de classe du pattern

singleton :
 REUTILISABILITE (6/11)
Les trois grandes familles de design patterns :
Les patterns structurel : ces patterns composent des
groupes d'objets en de larges structures, telles que des
interfaces graphiques complexes :
Le pattern Adapter convertit l'interface d'une classe
en une autre interface
Le pattern Bridge dcouple une abstraction de sa
reprsentation pour que les deux puissent voluer
indpendamment
Le pattern Composite compose les objets dans une
structure arborescente qui reprsente une hirarchie
"partie-de"
Le pattern Decorator attache de nouvelles
responsabilits un objet dynamiquement
Le pattern Facade fournit une interface unifie un
ensemble d'interfaces dans un sous-systme
Le pattern Proxy fournit un supplant pour un objet afin
de contrler son accs
 REUTILISABILITE (7/11)
Les trois grandes familles de design patterns :
Les patterns comportementaux : ces patterns dfinissent la
communication entre les objets du systme et comment le flot de
donnes est contrl dans un programme complexe :
Le pattern Chain of responsability vite de coupler l'metteur d'une
requte et son receveur, en donnant la possibilit plusieurs objets d'y
rpondre
Le pattern Command encapsule une requte dans un objet, pour
permettre de paramtrer des clients avec diffrentes requtes, de grer
des queues ou des traces de requtes, ou de permettre des oprations
annulables
Le pattern Iterator fournit un moyen d'accder squentiellement
aux lments d'une agrgation d'objets sans dvoiler sa reprsentation
Le pattern Mediator dfinit un objet qui encapsule les interactions
dun ensemble dobjets
Le pattern Memento, sans violer l'encapsulation, capture et
externalise l'tat interne d'un objet pour permettre de restaurer cet
tat plus tard
Le pattern Observer dfinit une relation un--plusieurs telle que
lorsqu'un objet change, tous les objets lis sont notifis de ce
changement et mis jour automatiquement
 REUTILISABILITE (8/11)

Pour utiliser les patterns de conception :

Se familiariser avec lutilisation des patterns de
conception
Apprendre identifier les bons patterns de
conception
Comprendre leur applicabilit
Apprendre adapter un pattern ses besoins
Apprendre valuer efficacement les compromis
durant la conception
 REUTILISABILITE (9/11)
Exemple dutilisation des patterns de conception : MVC 1 - 2
Lide de dcoupler modle et vues permet de conserver une
sparation nette entre le modle et la faon de le reprsenter.
Cette ide est applicable un problme plus gnral : dcoupler
des objets de faon ce quun changement dun objet
puisse affecter un nombre variable dautres objets sans
que lobjet qui a chang ait connatre en dtail les autres
objets.
Ce problme plus gnral est dcrit par le patron de conception
Observer.
Une autre caractristique du modle MVC est de permettre
limbrication de vues les unes dans les autres, afin de permettre
la construction de vues plus complexes. MVC supporte les vues
imbriques laide de la classe CompositeView, une sous-
classe de View. Un objet de la classe CompositeView se
comporte exactement comme un objet de la classe View, et
peut tre utilis partout o un objet de la classe View est utilis,
mais en plus, un objet de la classe CompositeView permet de
grer des vues imbriques.
 REUTILISABILITE (10/11)
Exemple dutilisation des patterns de conception :
Encore une fois, lide dimbriquer des objets et de traiter
lobjet rsultant comme un seul objet individuel correspond
un problme de conception plus gnral.
Ce problme plus gnral est dcrit par le patron de conception
Composite.
Le modle MVC permet galement de modifier la faon dont
ragit une vue une entre faite par lusager sans
changer son apparence visuelle. MVC encapsule le mcanisme
de rponse dans un objet Controler. Les diffrents types de
Controler sont organiss dans une hirarchie de classe, et
une vue utilise une instance dune des sous-classes de
Controler.
La relation View-Controler est dcrite par le patron de
conception Strategy.
 REUTILISABILITE (11/11)

Pour dcrire un pattern de conception :

Le nom du patron
Son intention
Une motivation
Son applicabilit
Sa structure
Les classes ou objets participants
Les collaborations entre les participants
De mme que des commentaires sur les consquences
dutilisation, sur certains compromis possibles, sur
limplmentation et sur les patrons relis.
 REUTILISABILITE
Principes de rutilisabilit (suite)
Les patterns de conception :
MVC pour la couche prsentation
DAO pour la couche accs aux donnes
Les frameworks techniques :
Struts, Barracuda, Expresso, Turbine, Avalon
log4J pour la gestion de log
Castor pour le mapping relationnel
Les bibliothques de composants techniques :
taglibs
javamail
jaxp...
 Modle Vue Contrle (1/2)
MVC (Model - View - Controller) est un pattern destin la
conception dapplications GUI. Son principe de base est la
sparation des composants suivants :
Le modle : il conserve toutes les donnes relatives lapplication
(sous quelque forme que ce soit : base de donnes, fichiers) et
contient la logique mtier de lapplication.
La vue : elle a pour rle doffrir une prsentation du modle (IHM).
On peut avoir de nombreuses vues pour un mme modle,
chacune prsentant les informations de manire diffrente (on pourrait
ainsi imaginer une liste darticles prsentable la fois sur lcran dun
navigateur web, sur un PALM, sur un minitel ou sur une imprimante)
Le contrleur : cest le composant qui rpond aux actions de
lutilisateur. Il traduit les vnements de lIHM en modifications du
modle et dfinit galement la manire dont lIHM doit ragir face aux
interactions de lutilisateur.
 Modle Vue Contrle (2/2)

Les avantages du modle MVC sont les suivants :

Les 3 parties de lapplication logique de prsentation, logique
mtier et logique applicative sont parfaitement indpendantes.
Ainsi, la programmation de chacune peut tre distribue des
quipes de dveloppement diffrentes.
La maintenance de lapplication est plus souple. Ce dcoupage
permet par exemple de modifier la prsentation sans toucher la
structure du site ni la logique mtier.

Linconvnient du modle MVC est le suivant :

Une architecture de type MVC ncessite un temps dapprentissage
non ngligeable.
Au final, cet inconvnient est largement contrebalanc par le
temps gagn lors des volutions et de la maintenance.
STRUTS (1/2)

1-2
STRUTS (2/2)

1-2