Le document présente une phase de conception axée sur l'architecture et les composants d'un système, en détaillant divers diagrammes comme ceux d'état de transition, de communication et de classes. Il aborde également les patrons de conception GRASP, qui fournissent des directives sur l'attribution des responsabilités aux objets, tout en soulignant l'importance d'un faible couplage et d'une forte cohésion. En conclusion, il souligne l'importance de créer des diagrammes de conception pour guider l'implémentation en programmation orientée objet.

1. Phase de conception
Prof :Y.ABOUQORA

2. 2
Plan :
 Introduction
 Diagramme d’état de transition
 Diagramme de communication
 GRASP PATTERN (Designs)
 Diagramme de classe de conception
 Diagramme de package
 Conclusion

3. 3
Introduction
 Concevoir l’architecture du système et ses
composants pour faciliter son mise en œuvre ;
 Réalisation des diagrammes de communication pour
montrer comment les objets collaborent pour
exécuter les cas d’utilisation ;
 Elaboration des diagrammes d’état transition pour
étudier le comportement des classes complexes à
fin de déduire d’autres méthodes supplémentaire ;
 Réalisation du diagrammes de classe de conception,
en tenant compte des GRASP patterns, diagrammes
de communication et d ’états transition.

4. 4
Diagramme d’états de transition
◦ Représentation d’un cycle de vie d’une classe ;
◦ L’état d’une classe est observable pour une
durée limitée qui prétend un changement d’état
à la réception d’un événement ;
◦ un état définit un ensemble de valeurs aux
attributs de l’objet à un moment donné.
◦ L’état particulier d’une classe est l’état d’attente,
ou l’objet ne change pas et ne fait rien.
Etat initial Etat intermédiaire Etat final

5. 5
Diagramme d’états de transition
◦ Création du diagramme d’état des classes
complexes à fin de déterminer leurs transitions
par rapport à leurs interactions avec les autres
classes du domaine ;
◦ Analyser son comportement instable ;
◦ Compléter le diagramme de classe de
conception avec des méthodes qui
correspondent aux différentes actions et activités
du diagramme d’état.

6. 6
Diagramme d’états de transition
◦ Diagramme d’état de la classe véhicule (insertion
dans une file)

7. 7
Diagramme de communication
 Les collaborations se sont des interactions
entre objets, dont le but est de réaliser un
objectif du système (c'est-a-dire aussi de
répondre a un besoin d'un utilisateur).
 L‘élément de modélisation UML
"collaboration", représente les classes qui
participent à la réalisation d'un cas
d'utilisation.

8. 8
Diagramme de communication
 Les diagrammes de communication mettent
l’accent sur les relations spatiales entre
≪ ≫
objets ;
 Les messages peuvent être numérotés pour
introduire une dimension temporelle ;
 De nombreuses notations annexes permettent
de caractériser les messages. Ils sont souvent
utilisés pour décrire grossièrement la
réalisation des cas d’utilisation.

9. 9
Diagramme de communication
 Un objet B envoie un message X a un objet
A, puis l’objet A envoie un messageY a un
objet C, et enfin C s’envoie a lui même un
message Z.

10. 10
Diagramme de communication
 Diagramme de communication du contrat
d’opération « choisir solution » :

11. 11
Diagramme de communication
 Diagramme de communication du use case
« Résoudre conflit d’insertion dans la file» :

12. 12
Patrons de conception
GRASP (General Responsibility Assignment Software Patterns).
Ces patrons de conception donnent des conseils généraux sur
l'assignation de responsabilité aux classes et objets dans une
application. Ils sont issus du bon sens de conception, intuitifs et
s'appliquent de manière plus générale.
Une responsabilité est vue au sens conception (exemples :
création, détention de l'information, etc.) :
- elle est relative aux méthodes et données des classes,
- elle est assurée à l'aide d'une ou plusieurs méthodes,
- elle peut s'étendre sur plusieurs classes.
En UML, l'assignation de responsabilité peut être appliquée à la
conception des diagrammes de communication.

13. P.
Collet 13
GRASP: objectifs
• Penser systématiquement le logiciel en
termes de :
• Responsabilités
• Par rapport à des rôles (des objets)
• Qui collaborent
• Réduire le décalage entre
représentation
« humaine » du problème et
représentation informatique

14. P.
Collet 14
Responsabilité en GRASP
• Responsabilité imputée à :
• Un objet seul
• Un groupe d’objets qui collaborent pour
s’acquitter de cette responsabilité
• GRASP aide à :
• Décider quelle responsabilité assigner à
quel objet (à quelle classe)
• Identifier les objets et responsabilités du
domaine
• Identifier comment les objets interagissent
entre eux
• Définir une organisation entre ces objets

15. P.
Collet 15
Types de responsabilité
• Responsabilité de FAIRE
• Accomplir une action (calcul, création
d’un autre objet)
• Déclencher une action sur un
autre objet (déléguer à celui qui
SAIT faire)
• Coordonner les actions des autres
objets (déléguer à X, puis Y et en
fonction du résultat, etc.)

16. P.
Collet 16
Types de responsabilité
• Responsabilité de SAVOIR
• Connaître les valeurs de ses propriétés
(attributs privés)
• Connaître les objets qui lui sont
rattachés (références,
associations…)
• Connaître les éléments qu’il peut dériver
(la taille d’une liste)

17. 17
Patrons de conception
9 GRASP patterns
 Expert pattern
Celui qui sait qui fait, l'objet qui contient les informations c'est l'objet
qui doit renvoyer l'objet recherche ;
 Créateur pattern
Objet responsable de créer des objets, généralement c'est le
conteneur, sinon c'est l'objet le plus proche fonctionnellement ;
 Contrôleur pattern
Objet responsable d'accueillir les messages de l'extérieur ;
 Faible couplage :
Faible dépendance dans le but de faciliter la maintenance du code ;
 Forte cohésion :
Liaison forte entre classe (avoir des sous-classes terminales très
spécialisées) ;

18. 18
GRASP PATTERN
 Polymorphisme
Affecter un nouveau comportement à l'endroit de la hiérarchie
de classes où il change.
 Fabrication pure
Créer des classes séparées pour des fonctionnalités génériques
qui n'ont aucun rapport avec les classes du domaine applicatif.
 Indirection
Découpler des classes en utilisant une classe intermédiaire.
 Protection des variations
Ne pas communiquer avec des classes inconnues.

19. 19
1. Spécialiste de l’information
• Problème
– Quel est le principe général
d’affectation des responsabilités des
objets ?
• Solution
– Affecter la responsabilité à la classe
spécialiste de l’information, c’est-à-dire la
classe qui possède les informations
nécessaires pour s’acquitter de la

20. 1. Spécialiste de l’information
• Exemple du Monopoly
– Qui est responsable de l’accès à une case
donnée du jeu ?
Applying UML and Patterns – Craig
Larman
20

21. 1. Spécialiste de l’information
• Boar
d!
Le plus utilisé de tous les patterns GRASP
L’accomplissement d’une responsabilité nécessite
souvent que l’information nécessaire soit répartie entre
different objects
Applying UML and Patterns – Craig
Larman
21

22. 22
2.
Créateur
• Problème
– Qui doit avoir la responsabilité de créer une
nouvelle instance d’une classe ?
• Solution
– Affecter à une classe B la responsabilité de
créer une instance de A si :
• B contient ou agrège des objets A, ou
• B utilise étroitement des objets A, ou
• B connaît les données utilisées pour initialiser les
objets A

23. 2.
Créateur
• Exemple du Monopoly
– Qui crée les cases
(Square) ?
Applying UML and Patterns – Craig

24. 2.
Créateur
• On peut s’appuyer sur le
diagramme de séquences ou
l’enchaînement du code
Applying UML and Patterns – Craig
Larman
24

25. 2.
Créateur
• Et l’association est donc une composition
(les cases disparaissent avec le plateau) :
Applying UML and Patterns – Craig
Larman
P.
Collet 25

26. P.
Collet 26
3. Faible couplage
• Problème
– Comment minimiser les dépendances,
réduire l’impact des changements, et
augmenter la réutilisation ?
• Solution
– Mesurer le couplage « en continu »
– Identifier les différentes solutions à
l’affectation de responsabilité
– Affecter une responsabilité de sorte que le
couplage reste faible

27. P.
Collet 27
3. Faible couplage
• Exemples classiques de couplage de
TypeX vers TypeY en orienté objet :
– TypeX a un attribut qui réfère à TypeY
– TypeX a une méthode qui référence
TypeY
– TypeX est une sous-classe directe ou
indirecte de TypeY
– TypeY est une interface et TypeX
l’implémente

28. 3. Faible couplage
Applying UML and Patterns – Craig
Larman
P. Collet 28

29. P.
Collet 29
3. Faible couplage
• Couplage fort :
– Un changement force aux changements
dans les classes liées
– Les classes prises isolément sont
difficiles à comprendre
• Il n’y a pas de mesure absolue du
seuil d’un couplage trop fort…
• Un fort couplage n’est pas
dramatique avec des éléments très
stables (java.util)

30. 30
4. Forte cohésion
• Problème
– Comment maintenir la complexité
gérable ?
• Avoir des objets compréhensibles et facile
à gérer
• Solution
– Comme pour le couplage faible :
mesurer, caractériser, choisir

31. 4. Forte cohésion
Applying UML and Patterns – Craig
Larman
31

32. 32
4. Forte cohésion
• Problème de la faible cohésion sur les
classes
– Difficiles à comprendre
– Difficiles à réutiliser
– Difficiles à maintenir
– Fragiles (constamment affecter par le
changement)
• Une classe de forte cohésion a un petit
nombre de méthodes, avec des
fonctionnalités hautement liées entre
elles, et ne fait pas trop de travail
– Pouvez-vous décrire la classe en une seule

33. 33
5.
Contrôleur
• Problème
– Quel est le premier objet qui
coordonne le système (après l’interface
homme-machine) ?
• Solution
– Choisir (ou inventer) un objet qui
endosse explicitement le rôle
• Représente le système global ou un sous-
système majeur
• Représente un scénario d’un case
d’utilisation

34. 5.
Contrôleur
Applying UML and Patterns – Craig
Larman
34

35. 5.
Contrôleur
Applying UML and Patterns – Craig
Larman
35

36. 36
6. Polymorphisme
• Problème
– Comment gérer des alternatives
dépendantes des types ?
– Comment créer des composants logiciels
« enfichables » ?
• Solution
– Quand les fonctions varient en fonction
du type, affecter les responsabilités au
point de variation
– Pas de if/then/else sur des instanceOf

37. 37
6. Polymorphisme
• Les cases du Monopoly ?
– En fonction de la case sur laquelle le
joueur atterrit, le comportement est
différent…

38. P.
Collet 38
7. Pure invention
• Problème :
– Que faire quand les concepts du monde
réels (les objets du domaine) ne sont pas
utilisables vis-à-vis du respect d’un faible
couplage et d’une forte cohésion ?
• Solution :
– Fabriquer de toutes pièces une entité
fortement cohésive et faiblement
couplée

39. 7. Pure invention
P. Collet
28
Applying UML and Patterns – Craig

40. 40
8. Indirection
• Problème :
– Où affecter une responsabilité pour éviter le couplage entre
deux entités (ou plus) ?
– de façon à diminuer le couplage (objets dans deux
couches différentes)
– de façon à favoriser la réutilisabilité (utilisation d’une API
externe) ?
• Solution :
– Créer un objet qui sert d’intermédiaire entre d’autres
composants ou services
– l’intermédiaire crée une indirection entre les
composants

41. 41
8. Indirection
• Utilité
• Réaliser des adaptateurs, façades, etc. (pattern
Protection des variations) qui s’interfacent avec
des systèmes extérieurs
• Exemples : proxys, DAO, ORB
• Réaliser des inversions de dépendances entre
packages
• Mise en oeuvre
• Utilisation d’objets du domaine
• Création d’objets
• Classes : cf. Fabrication pure
• Interfaces : cf. Fabrication pure +
Polymorphisme

42. 42
8. Indirection
• Bibliothèque : accès à un système de
stockage propriétaire

43. 43
9. Protection des variations
• Problème
• Comment concevoir des objets, sous-
systèmes, systèmes pour que les variations
ou l’instabilité de certains éléments n’aient pas
d’impact indésirable sur d’autres éléments ?
• Solution
• Identifier les points de variation ou
d’instabilité prévisibles
• Affecter les responsabilités pour créer une
interface (au sens large) stable autour d’eux
(indirection)

44. 44
9. Protection des variations
• Mise en oeuvre
• Cf. patterns précédents (Polymorphisme,
Fabrication pure, Indirection)
• Exemples de mécanismes de PV
• Encapsulation des données, brokers,
machines virtuelles…
• Exercice
• Stockage de Prêt dans plusieurs systèmes
différents
• Utiliser Indirection + Polymorphisme

45. 45
Diagramme de classe de conception
 Réaliser à partir de diagramme de classe d’analyse,
de séquence « boite blanche», de communication
et d’état de transition ;
 Met l’accent sur le comportement de chaque objet
qui consiste à enrichir le diagramme de classe
d’analyse en lui ajoutant les méthodes déduites des
diagrammes d’interactions déjà réalisés ;
 Prendre en compte les choix techniques, comme
le choix du langage de programmation, le choix
des différentes librairies utilisées…

46. 46
Diagramme de classe de conception
L’objetVoie reçoit trois messages :
createVehicule
ajouterVehicule
createConflit
L’objetVoie doit posséder des méthodes correspondant à ces messages lui
permettant d’interagir avec l’objet ContrôleurConflit.
L’objet Conflit doit avoir deux methodes pour représenter les deux messages :
finConflit
resoudreConflit

47. 47
Diagramme de classe de conception
 En ajoutant ces méthodes aux classes créées
au phase d’analyse, on trouve :
 De même pour les autres classes métiers,
nous révélons les messages entrant à celles-ci,
à partir des diagrammes d’interaction pour en
déduire leurs méthodes.

48. 48
Diagramme de package
 Les paquetages divisent et organisent les
modèles de la même manière que les
répertoires organisent les systèmes de fichiers ;
 Un paquetage est un regroupement logique
d’éléments de modélisation(classes, use cases,
objets…)
 Un package peut inclure d’autres package ;
 Un package peut importer d’autres package ;
 L’héritage entre package est possible.

49. 49
Diagramme de package
Gestion
commerciale
Gestion
utilisateurs
« import »
Gestion
produits
« import »
Gestion
fournisseurs
« import »
« import »

50. 50
Conclusion
 Elaboration des différents diagrammes de
conception en s’appuyant sur les
techniques GRASP PATTERN ;
 Dans la phase d’implémentation, on va
implémenter cette conception en utilisant
un langage de programmation orienté
objet.