Conception A Vance e

Conception Orientée
Objets Avancée
A.U. 2021-2022
Faculté des sciences économiques et de gestion de Sfax
1
Plan
❑ Chapitre 1 : Rappel (diagrammes de UC, d’activité, de classes,

d’interactions, de paquetages et d’états )
❑ Chapitre 2 : Les principes de COO
❑ Chapitre 3 : Patrons de conception
❑ Chapitre 4 : Architectures logicielles
2
Chapitre 1: Rappel
3
❑ Qu’est ce que UML?
❑ UML est un langage. Il ne spécifie ni méthodologie ni processus de
développement
❑ Il peut être utilisé de multiples manières comme support à une méthode
❑ Une notation unifiée standardisée par l’OMG
4
❑ Constituants d’UML : éléments et diagrammes.
❑ Les éléments sont les briques de base du langage. On distingue :
❑ Les éléments structurels (classe, interface, cas d’utilisation, composant,
nœuds, …) ,
❑ Ceux de comportements (message, état, activité, …),
❑ Ceux de regroupement (les paquetages)
❑ Ceux d’annotation (les annotations)
❑ Les relations : dépendance, association, héritage, réalisation.
5
❑Un diagramme est une représentation graphique d’une collection d’éléments
de modélisation, le plus souvent représentés comme un graphe connexe d’arcs
et de nœuds.
❑Les versions d’UML < 1.5 définissent 9 types de diagrammes
❑La version 2.0 définit 13 diagrammes.
❑Un type de diagramme UML véhicule une sémantique précise (un type de
diagramme offre toujours la même vue d'un système)
6
7
Le diagramme des cas d’utilisation
❑ Les cas d’utilisation sont
❑ inventés par Ivar Jacobson
❑ destinés à l ’expression des besoins
❑ centrés sur les utilisateurs
❑ Ils montrent les fonctionnalités du système comme vues par

l’utilisateur
❑ Ils pilotent le processus de développement
8
…Diagramme de cas d’utilisation
❑ Concepts de base
❑ Acteur :
▪ rôle joué par une personne ou une chose qui interagit avec le système
mais qui lui est extérieure
▪ est caractérisé par un nom qui exprime son rôle
▪ une même personne physique peut être modélisée par plusieurs acteurs
▪ un acteur représenter plusieurs personnes physiques
❑ Cas d’utilisation (UC)
▪ unité fonctionnelle cohérente assurée par le système ou une classe
▪ correspond à un certain type d’interaction entre le système et les acteurs
9
❑ Scénario
▪ Instance d’un cas d’utilisation, un chemin particulier dans sa combinatoire
▪ suite d'interactions entre les acteurs et le système
▪ Types : nominal, alternatif ou d’exception
❑ Relation entre acteurs

❑ Généralisation-Spécialisation
❑ Relation entre acteurs et UCs

❑ Relation de communication
10
❑ Relations entre Ucs
❑ Extension (<<extends>>) : comportement optionnel du système (variation
d’un comportement « normal »)
❑ Inclusion (<<includes>>) : un cas intègre le comportement d’un autre
(factorisation)
❑ Généralisation/spécialisation : spécialisation avec héritage (ajout ou
remplacement de comportement)
11
Exemple de diagramme de Ucs.
12
Diagramme de Ucs avec relations entre les Ucs.
13
Diagramme de classes
1. Définition
❖ Un diagramme de classes est un graphe
qui représente la structure statique d’un
système. Il contient principalement des classes
et leurs relations.
❖ Le diagramme de classes est le point central

dans un développement OO
◼ En analyse, il a pour objectif de décrire la
structure des entités manipulées par les
utilisateurs, ainsi que les liens sémantiques
entre elles.
◼ En conception, il représente la structure d’un

code orienté objet. 15
2. Classes
❖Définition
Une classe est une description abstraite d’un
ensemble d’objets du domaine; elle définit leur
structure, leur comportement et leurs relations.
◼ Notation
Nom de Classe Nom de Classe Nom de Classe

Attributs Attributs
Méthodes
16
◼ Exemple :
17
◼ Conventions
1. Les noms des classes sont toujours au singulier.
Exemples : Fichier, Client, Chat, …
2. Les noms de classes, des attributs et des méthodes doivent suivre la notation camel case.
Les attributs et les méthodes commencent par des minuscules.
3. Les noms des classes, des attributs et des méthodes doivent être expressifs ce qui
contribue à la bonne lisibilité et à la compréhension du modèle.
18
3. Attributs
◼ Définition :
Un attribut est une propriété nommée de classe qui
porte un ensemble de valeurs que les instances (les
objets) de la classe vont prendre.
La classe possède des attributs et les instances de la

classe des valeurs d’attributs.
19
◼ Exemple :
20
◼ Syntaxe de description des attributs :
Attribut ::=
[<visibilité>] [‘/’] <nomAttribut> [‘:’ <type>]
[‘[‘<multiplicité >‘]’] [‘=’<valeurInitiale>]
[‘{‘ <contrainte> [‘,’ <contrainte> ]* ’}’]
21
✓ Visibilité : C’est le type d'accessibilité :
+ : public, visible pour tous les clients de la classe
– : private, visible pour la classe seule
# : protected, visible pour toutes les sous-
classes de la classe
~ : package, visible pour toutes les classes du
même paquetage (valeur par défaut)
✓ Multiplicité : nombre minimum et nombre

maximum de valeurs possibles de l’attribut
pour une instance de la classe.
Grâce à la multiplicité, un attribut peut être

multivalué.
22
✓Type des attributs peut être :
▪ Un type primitif : Entier, chaîne, réel, …
▪ Une classe définie par le standard : Time
▪ Expression complexe non supportée par

UML
▪ Remarque : Dans un diagramme de

classes d’analyse, tous les attributs
doivent être de type primitif ou standard.
23
Diagramme de classes d’analyse
Diagramme de classes de conception

24
✓ Contrainte :
{readOnly} : l’attribut est en lecture seule.
{subsets <nomAttribut>} : l’attribut est un
sous-ensemble de l’attribut identifié par
<nomAttribut>.
{ordred} : l’attribut multivalué est ordonné et sans
duplications
{sequence} : l’attribut multivalué est ordonné et
peut contenir des duplicatas
{<contrainte>} : une expression qui spécifie une
contrainte qui s’applique à l’attribut.
25
◼ Exemple
26
◼ Attribut dérivé
Un attribut est, en général, primaire, c. à d.
correspond au plus petit niveau d’information que
l’on veut gérer. Cependant, par commodité de
gestion, on choisit de conserver dans un attribut
le résultat d’un calcul effectué à partir d’autres
attributs. On parle alors d’attribut dérivé. Le nom
d’un attribut dérivé est toujours précédé d’un "/".
• Exemple :
27
4. Opérations
◼ Les opérations mettent en œuvre les
responsabilités d’une classe. Elles modélisent le
comportement de ses objets.
◼ Exemple : pour gérer le solde, la classe

CompteBancaire offre les opérations getSolde(),
retirer(), déposer(), etc.
◼ Une opération possède une signature. La

signature est constituée du nom de l’opération,
de son type de retour et de la liste de ses
paramètres.
28
◼ Syntaxe de la signature d’une opération :
Opération::= [<visibilité>] <nom> ‘(‘[<ListeParam>] ‘)’
[‘:’ [<typeRetour>] [‘[‘ <multiplicité>‘]’]
[‘{‘ <propriété> [‘,’ <propriété>]* ‘}’]]
✓Visibilité : +, –, #, ~
✓Liste des paramètres :

<ListeParam> ::= <param> [‘,’<param>]*
<param> ::= [<direction>] <nomParam> ‘:’
<type> [‘[‘<multiplicité>’]’]
[‘=’<valeurParDéfaut>]
[‘{‘<propriété>[‘,’<propriété>]*‘}’]
<direction> ::=‘in’ | ‘out’ | ‘inout’ | return
29
• Remarques
▪ "in" est la direction par défaut d’un paramètre
▪ Un paramètre au plus peut avoir la direction "return" dans la liste des

paramètres d’une opération
▪ Le type de retour d’une opération est le type du paramètre ayant la

direction "return" si ce paramètre existe. Si ce paramètre n’existe pas,
alors l’opération n’a pas de type de retour (void).
▪ La multiplicité d’une opération est la multiplicité du paramètre ayant la

direction "return" si ce paramètre existe. Sinon, l’opération n’a pas de
multiplicité.
30
▪ Par convention, s’il existe un paramètre ayant la
direction "return", on ne le représente pas dans la
liste des paramètres. La présence d’un type de
retour renseigne sur la présence de ce paramètre.
Exemple :
toString([return] s : String)
a la même signification que :
toString() : String
31
✓Propriétés :
▪ {redefines <nomOp>} : l’opération redéfinie

une autre héritée d’une classe de base identifiée
par <nomOp>
▪ {query} : l’opération ne change pas l’état du

système
• Remarque :
méthode = implantation d’une opération
dont elle spécifie l’algorithme ou la
procédure associée
32
▪ Portée des attributs et des opérations:
Par défaut, la portée des attributs (et des
opérations) est l’instance. Toutefois, certains
attributs (et opérations) sont visibles
globalement dans toute la portée de la classe.
Ils sont partagés par toutes les instances de la
classe. On parle alors d’attribut (ou opération)
statique (static) ou attribut (opération) de
classe.
Exemple :
Attribut de classe
33
5. Objets
◼ Un objet est une instance (ou occurrence) d’une classe. Il possède
une identité, un état et un comportement.
◼ L’identité d’un objet est indépendante des valeurs de ses attributs.
◼ L’état d’un objet est l’ensemble des valeurs des attributs

caractérisant l’objet.
◼ Le comportement d’un objet est l’ensemble des opérations qui

peuvent être invoqués sur cet objet.
34
◼ Notation et exemple :
◼ Remarque :
• Les objets ne font pas partie du diagramme de classes. On les représente dans
un diagramme à part appelé diagramme d’objets.
35
6. Relations
UML définit plusieurs types de relations entre classes :
❑ Association
❑ Généralisation/Spécialisation
❑ Dépendance
❑…
❖ Associations :
• Une association est une relation statique qui
connecte n classes (n>=2). Le nombre n est
l’arité de l’association.
• Les instances d’une association sont des tuples des
instances des classes reliées par cette association.
On les appelle liens.
• Chaque lien d’une association peut apparaître au
plus une fois.
36
• L’extrémité (ou patte) d’une association peut
être enrichie par un nom appelé rôle qui décrit
comment une classe source voit une classe
destination au travers de l’association.
37
◼ Multiplicité
La multiplicité précise le nombre minimum et le nombre maximum
d’objets d’une classe qui peuvent être liées à un objet de l’autre.
▪ 1 ou 1..1 : un et un seul (multiplicité par défaut)
▪ 0 .. 1 : zéro ou un
▪ N (N entier naturel)
▪ M .. N : de M à N ( M et N entiers naturels)
▪ * ou 0 .. * : de 0 à plusieurs
▪ 1 .. * : de 1 à plusieurs
38
•Exemples :
fournir
Produit 1..* 1..3 Fournisseur
+produits +fournisseurs
fournis
On a attribué à chaque instance de produit entre 1
et 3 (instances de) fournisseurs et un fournisseur
doit fournir au moins un produit et éventuellement
plusieurs.
passer
Client Commande
0..*
Une instance de commande a été passée par un

et un seul client. En revanche, à un moment
donné, dans le SI, une instance de client peut
avoir passé zéro ou plusieurs commandes. 39
◼ Instances d’une association :
• Les instances d’associations sont appelés liens.
• Un lien d’une association est un tuple qui référence des
objets instances de classes reliées par cette association.
40
◼ Associations ternaires (et n-aire)
▪ Notation et exemple :
Département
*
Logiciel 1 Serveur
*
installer
Des logiciels sont installés sur des serveurs sur
l’initiative de départements.
41
▪ Lecture des multiplicités :
Pour une association ternaire, les multiplicités se
lisent de la façon suivante :
Pour un couple d’instances de la classe A et de
la classe B, il y a au minimum r1 instances
de la classe C et au maximum r2 instances.
p1..p2 q1..q2
Classe A Classe B
r1..r2
Classe C
42
Exemple
* *
Logiciel Département
1
Serveur
Un logiciel d’un département ne doit être installé

que sur un seul serveur.
43
▪ Autre alternative de représentation:
Département
1
*
<<Association ternaire>>
Installation
* *
1 1
Logiciel Serveur
Cette notation ne permet pas de montrer la

contrainte d’unicité. Pour la faire apparaître
explicitement, il faut décomposer l’association. 44
• Remarques
▪ Une association peut ne pas être nommée.
▪ L’indication des rôles est nécessaire pour les associations ambiguës.
1..* 0..*
Hotêl +clients Personne
0..1 +directeur
+parents
2
Personne
0..*
+enfants 45
◼Association
à navigabilité restreinte :
▪ La navigabilité indique si un rôle est accessible
à partir de la source
▪ Par défaut, une association est navigable dans
les deux sens.
▪ On peut la limiter à un seul sens dans un
modèle.
voter
Électeur Candidat
* 0..1
46
◼ Contraintes
▪ Ce sont des relations sémantiques définies sur
une relation ou sur un groupe de relations. Elles
permettent de restreindre le nombre d'instances
visées.
▪ Elles peuvent s'exprimer :
▪ en langage naturel ou
▪ graphiquement avec un {texte} ou
▪ en OCL (Object Constraint Language)
47
• Contraintes sur les rôles
▪ La contrainte {ordered} : elle est définie sur
un rôle de type collection et spécifie qu’une
relation d’ordre décrit les objets de la
collection.
Personne 1 0..* Compte

{ordered}
La collection des comptes d’une personne est

triée.
48
▪ La contrainte {subsets<nomRole>} : Elle
indique qu’une collection est incluse dans une
autre appelée <nomRole>.
Un employé qui dirige un service doit être affecté à

ce service.
49
• Contraintes sur les associations
▪ La contrainte {xor} : Elle indique que tout
objet d’une classe peut participer à l’une des
deux associations mais pas aux deux à la
fois.
Un contrat assure un individu ou une société

mais pas les deux à la fois.
50
▪ La contrainte {subset} : elle est définie entre deux associations. Elle
indique que l’ensemble des liens d’une association est inclus dans
l’ensemble des liens de l’autre.
Les chefs de services sont aussi des employés affectés aux services qu’ils
dirigent.
51
◼Classe-association
Une classe-association définit une association qui est
en même temps une classe.
Elle connecte des classes entre elles et possède aussi
ses propres caractéristiques.
Elle se comporte comme une vraie classe avec une
structure et un comportement et d’autres relations.
0..* 1..*
Commande Produit
LigneCommande
qtéCommandée
52
Remarques :
▪ Une association qui possède des attributs sans
participer à des relations avec d’autres classes est
appelée association attribuée. Dans ce cas la classe
attachée à l’association n’a pas de nom spécifique.
▪ UML interdit à une classe-association d’avoir à la fois

un nom sur l’association et un autre dans la classe.
53
▪ Une association ternaire avec contrainte se
modélise plus facilement à l’aide d’une classe-
association.
0..* 0..*
Departement Logiciel
Serveur 1 0..* Installation

dateInstallation
Une installation (constituée d’un logiciel et d’un

département) est en association avec un seul
serveur.
54
❖Agrégation
▪ C’est une forme d’association binaire non symétrique
dans laquelle l’une des extrémités joue un rôle
prédominant par rapport à l’autre extrémité.
▪ Elle peut représenter une relation de type
"ensemble/élément".
Exemple :
Jury est formé de Enseignant

0..* 3
▪ Les critères suivants impliquent une agrégation :
▪ une classe (un "élément") fait partie d'une autre
("l'agrégat"),
▪ un changement d'état d'une classe, entraîne un
changement d'état d'une autre,
▪ les objets d’une classe sont subordonnés aux objets
d’une autre classe
55
❖Composition
▪ C’est une agrégation forte.
▪ Les cycles de vie des éléments (les "composants")
et du composé coïncident :
▪ si le composé est détruit (ou copié), ses
composants le sont aussi.
▪ une instance de composant ne peut être liée
qu'à un seul composé.
▪ Les "objets composites" sont des instances de
classes composées.
▪ Exemples : 1..*
Livre Chapitre
0..1 Compte
Client
56
❖ Relation de généralisation
▪ Elle définit une relation de classification entre
une classe plus générale et une classe plus
spécifique. La classe spécifique contient par
héritage tous les attributs, les opérations et les
relations de la classe générale et peut en
contenir d’autres.
Classe mère,
classe de base ou Classe A
classe générale
Relation est-un
Classe fille, ou relation is-a
classe dérivée,
Classe B
classe spécialisée
ou classe descendante 57
▪ La généralisation peut être :
▪ simple : unicité du lien de généralisation pour un
objet de la classe spécialisée.
▪ multiple : liens de généralisation multiples pour
un objet de la classe spécialisée vis à vis des
objets des classes du niveau immédiatement
supérieur.
Produit Enseignant Chercheur
Angrais ProduitIndustriel EnseignantChercheur
Héritage simple Héritage multiple 58

▪ Remarques :
◼ Une classe peut être spécialisée selon plusieurs
discriminants (generalization sets).
discriminant Véhicule
Milieu Motorisation
Terrestre Marin AMoteur AVoile
◼ La généralisation est une relation non réflexive :

une classe ne peut pas dériver d’elle même.
◼ La généralisation est une relation non symétrique:
si B dérive de A alors A ne peut pas dériver de B.
Une hiérarchie d’héritage ne doit par contenir de
cycles.
59
▪ Contraintes et propriétés de la généralisation :
▪ La contrainte {disjoint} : Tout objet est au plus
instance d’une seule sous-classe.
Par défaut, la généralisation symbolise une
décomposition exclusive.
Employé
{disjoint}
DirecteurRégional IngénieurCommercial
Un directeur régional ne peut pas être en même

temps Ingénieur commercial, chacun a ses
fonctions. 60
▪ La contrainte {ovelapping} : Une instance de
l’une des spécialisations peut être simultanément
une instance d’une autre.
Personne
{overlapping}
Étudiant Salarié
Une personne peut être en même temps étudiant

et salarié.
61
▪ La contrainte {complete} :
▪ Elle indique que la généralisation est terminée.
Il n’est pas possible d’ajouter d’autres sous-
classes. Toute instance de la classe de base est
instance d’au moins une classe dérivée.
Personne
{complete}
Homme Femme
62
▪ La contrainte {incomplete} :
Elle désigne une généralisation extensible. Il existe des instances de la
classe de base qui ne sont pas instances d’une classe dérivée.
Personne
{incomplete, disjoint}
NordAfricaine SudAfricaine Européenne
63
• Classes abstraites
Les classes abstraites ne sont pas instanciables
directement.
Elles servent de spécification générale pour manipuler
les objets instances d’une de leurs sous-classes.
Exemple : Salarié
matricule
nom
adresse
salaireBrut() : Réel {abstraite}
getAdresse() : String {requête}
Mode de rémunération {complete}
Mensualisé Horaire
salaireBase nbHeuresMensuelles
heuresSupplémentaires tauxHoraire
salaireBrut() : Réel salaireBrut() : Réel 64
❖ Relation de dépendance
◼ Une dépendance signifie une relation fournisseur/client
entre des éléments d’un modèle où la modification d'un
fournisseur peut avoir un impact sur les éléments de
modèle client.
 Il y a une relation de dépendance entre une classe A et

une classe B ssi la classe A fait référence à la classe B.
C’est le cas lorsque :
▪ B est le type d’un paramètre d’une opération de A
▪ B est le type de retour d’une opération de A
▪ B est le type d’un attribut de A
65
◼ Notation et exemple
66
6. Stéréotypes
◼ Rappel :
Le stéréotype est un ensemble de critères. Il
permet de classifier les éléments de modélisation
selon des critères définis par le développeur.
◼ Stéréotypes de Jacobson :
Pour améliorer la lisibilité des diagrammes de
classes, Jacobson propose les stéréotypes suivants
qui sont par ailleurs prédéfinis dans UML :
▪ Boundary
▪ Entity
▪ Control
67
◼ Boundary (frontière) : classe dont les objets sont
visibles par les acteurs du système. Elle fournit le
moyen de communication du système avec
l’extérieur. Elle peut être une interface graphique, un
objet de protocole de communication (quand l’acteur
est un système informatique), …
Exemple :
<<boundary>>
Fenêtre Fenêtre
Fenêtre
Commande Commande
Commande
Cette classe a le stéréotype boundary car elle sert

de frontière entre l’acteur et le système pour la
saisie de commandes. 68
▪Entity : Elle représente et gère des objets qui sont
directement liés au domaine de l’étude. Ces classes sont
généralement persistantes.
▪Exemple :
<<entity>>
Commande Commande
Commande
69
▪ Control : classe interne du système qui contrôle le
comportement d’un ou plusieurs cas d’utilisation.
Ces classes représentent une activité de contrôle,
une règle de gestion, un chef d’orchestre, un
moyen de couplage entre des objets, etc.
Exemple :
<<control>>
Controleur
Controleur Controleur Commande
Commande Commande
70
7. Enumérations
◼ Une énumération est un type de données dont
les valeurs sont énumérées dans le modèle en
tant que littéraux d'énumération.
◼ Notation et exemple :
71
8. Interfaces
◼ Une interface est une spécification de comportement.
◼ Une interface est un contrat. En réalisant une interface, les classes
sont garantis pour supporter un comportement requis.
◼ Lorsqu'un objet client d'une interface collabore avec celle-ci, il ne
connait pas son type réel mais il sait comment le "manipuler" (quels
messages lui envoyer).
◼ Le but des interfaces est de diminuer le couplage entre deux
classes. L'interface permet de ne présenter au client "que ce qui
l'intéresse".
72
❖Représentation graphique et exemple
73
Diagrammes d’interaction
❑ Une interaction est une communication entre instances des éléments
d’une collaboration.
❑ Un diagramme d’interaction montre comment des instances au cœur
d’un système collaborent et communiquent pour réaliser une certaine
fonctionnalité.
❑ Il apporte un aspect dynamique à la modélisation du système.
❑ Il permet de suivre visuellement les interactions dynamiques entre
objets (instances de classes), et les traitements réalisés par chacun.
❑ Deux types de diagrammes d’interaction : Diagramme de séquence et
Diagramme de communication
74
…Diagrammes d’interaction
❑ Collaboration :
▪ représente un assemblage de rôles d’éléments qui interagissent en vue de réaliser une
fonction donnée.
▪ Exemple :
75
Diagramme de communication
❑ Concepts de base
Nom de l’interaction
Variable
Lignes de vie
Argument
Lien ou chemin de message Messages
76
Diagramme de séquence
❑ Concepts de base :
Période d’activité
77
…Diagramme de séquence
❑ Fragments d’interaction combinés
▪ Un fragment combiné est ensemble de séquences de messages.
▪ Il permet de décomposer une interaction complexe en fragments suffisamment
simples pour être compris.
▪ Les fragments combinés permettent de décrire des diagrammes de séquence de
manière compacte et concise.
▪ Il existe 13 opérateurs définis dans la notation UML 2.0.
78
▪ Un fragment combiné est défini par un opérateur et des opérandes.
▪ Les fragments combinés peuvent faire intervenir l’ensemble des objets participant au
scénario ou juste un sous-ensemble.
▪ Un port d’entrée et un port de sortie peuvent être indiqués pour connaître la manière
dont ce fragment peut être relié au reste du diagramme
79
❑ Opérateur « alt »
▪ Il correspond à une instruction de test avec une ou plusieurs alternatives possibles
▪ Il possède deux opérandes ou plus.
▪ Chaque opérande correspond à une alternative
▪ Chaque opérande détient une condition de garde.
▪ La condition « else » est vraie si aucune autre condition n’est vraie.
▪ Exactement un opérande dont la condition est vraie est exécuté.
▪ Si plusieurs opérandes prennent la valeur vraie, le choix est non déterministe.
80
▪ Exemple
81
❑ Opérateur « loop »
▪ L’opérateur loop correspond à une instruction de boucle qui permet d’exécuter une
séquence d’interaction tant qu’une condition est satisfaite.
▪ Il est possible aussi d’utiliser une condition portant sur un nombre minimum et
maximum d’exécution de la boucle.
82
▪ Exemple
83
❑ Opérateur « opt »
▪ Il correspond à une instruction de test sans alternative (sans "sinon").
▪ Exemple :
84
❑ Opérateur « ref »
▪ Il permet d’appeler une séquence d’interactions décrite par ailleurs constituant ainsi une
sorte de sous-diagramme de séquence.
85
86
86
❑ Opérateur « break »
▪ Il permet de représenter une situation exceptionnelle correspondant à un scénario de
rupture par rapport à l’interaction englobante.
▪ Le scénario de rupture s’exécute si la condition de garde est satisfaite.
87
Diagramme d’activité
❑ Le diagramme d’activité (DA) met l'accent sur les traitements. Il
représente les règles d’enchaînement des activités et actions dans
un système.
❑ Il peut être rattaché à n'importe quel élément de modélisation afin

de visualiser, spécifier ou documenter son comportement .
❑ Les DA permettent de « formaliser » les processus métier.
❑ Le DA peut être utilisé pour modéliser une opération. Dans ce

contexte, il constitue un organigramme des actions d’une opération.
88
…Diagramme d’activité
Diagramme d’activité représentant un processus de vente
89
❑ Action :
❑ Elle représente une unité de fonctionnalité distincte dans le diagramme d’activité
❑ Elle peut changer l'état du système ou en extrait une information
❑ Elle peut correspondre à un traitement élémentaire proche d’une instruction en
termes de programmation.
❑ Les actions sont des étapes à partir desquelles se construisent les comportements
❑ Notation et exemple :
90
❑ Transition et flot de contrôle
❑ Dès qu’une action est achevée, une transition automatique est déclenchée
vers l’action suivante. Il n’y a donc pas d’événement associé à la transition.
❑ L’enchaînement des actions constitue le flot de contrôle.
91
❑ Activité :
❑ Une activité représente le comportement d’une partie du système en
termes d’actions et de transitions.
❑ Elle est composée de trois types de nœuds :
▪ nœud d’exécution (actions)
▪ nœud de contrôle (décision, fusion, bifurcation, …)
▪ nœud d’objet.
❑ Elle peut recevoir des paramètres en entrée et en produire en sortie.
92
93
❑ Nœuds de décision et nœuds de fusion
❑ Un nœud de décision permet de faire un choix entre plusieurs flots sortants
en fonction des conditions de garde de chaque flot.
❑ Il n’a qu’un seul flot en entrée et peut avoir plusieurs flots en sortie.
❑ Un nœud de fusion permet d’avoir plusieurs flots entrants possibles et un
seul flot sortant. Le flot sortant est donc exécuté dès qu’un des flots
entrants est activé.
❑ Le nœud de fusion est le symétrique du nœud de décision.
94
❑ Exemple :
Nœud de décision
Nœud de fusion
Diagramme d’activité avec nœuds de décision et de fusion
95
❑ Nœud de bifurcation et nœud de jonction
❑ Un nœud de bifurcation (fourche) permet à partir d’un flot unique entrant
de créer plusieurs flots concurrents en sortie de la barre de
synchronisation.
❑ Un nœud de jonction permet, à partir de plusieurs flots concurrents en
entrée de la synchronisation, de produire un flot unique sortant. Le nœud
de jonction est le symétrique du nœud de bifurcation.
96
❑ Exemple
Nœud de jonction
Nœud de bifurcation
Diagramme d’activité avec nœuds de bifurcation et de jonction
97
…Nœuds de contrôle
❑ Nœud initial :
❑ C’est un nœud à partir duquel le flot débute lorsque l’activité est invoquée
❑ Il ne doit pas avoir d’arc entrant
❑ Une activité peut avoir plusieurs nœuds initiaux
❑ Nœud de fin d’activité :

❑ Lorsqu’on atteint un nœud final d’activité, tous les flots de l’activité sont stoppés
❑ Nœud de fin de flot

❑ Lorsqu’un flot d’exécution atteint un nœud de fin de flot, le flot en question est terminé
❑ La fin de flot n’a aucune incidence sur les autres flots actifs de l’activité enveloppante
❑ Un nœud de fin d’activité ou de fin de flot ne doit pas avoir d’arcs sortants
❑ Un nœud de fin d’activité ou de fin de flot doit avoir au moins une transition entrante
98
Nœud initial
Nœuds de fin de flot
Nœud de fin d’activité
Nœud initial, nœud de fin de flot et nœud de fin d’activité
99
❑ Partitions
❑ Il est possible d’organiser le diagramme d’activité en couloirs d’activités
appelés partitions
❑ Chaque partition contient un groupe d’actions ayant des caractéristiques
communes et les flux qui leurs sont reliés
❑ Les partions sont souvent utilisés pour représenter des unités
organisationnelles dans un modèle métier
100
Diagramme d’activité avec partitions
101
❑ Nœuds et flots d’objets
❑ Broches d’entrée et de sortie
▪ Pour spécifier les valeurs passées en argument à une action et les valeurs de retour, on
utilise des broches (pins) d’entrée ou de sortie.
▪ Un nom et un type de donnée peuvent être associés au pin.
▪ Un paramètre peut être de type objet.
▪ L’action ne peut débuter que si l’on affecte une valeur à chacune de ses pins d’entrée.
▪ Quand l’action se termine, une valeur doit être affectée à chacune de ses pins de sortie.
102
❑ Flot d’objets
▪ Un flot d’objets permet de passer des données d’une action à une autre.
▪ Un arc reliant un pin de sortie à un pin d’entrée est, par définition même des pins, un
flot d’objets
▪ Dans un flot d’objets, le type du pin récepteur doit être identique ou parent du type du
pin émetteur.
▪ Le nom d’un état, ou d’une liste d’états, de l’objet peut être précisé entre crochets après
ou sous le type de l’objet.
103
Pin de sortie
Pin d’entrée
Actions avec broches d’entrée et de sortie

104
❑ Types d’actions les plus courants
❑ Action opaque : est utilisée pour représenter des informations
d'implémentation ou comme marques de réservation jusqu'à ce que vous
déterminiez le type exact d'action à utiliser.
❑ Action d’appel de comportement : permet d’invoquer une activité (un autre
diagramme d’activité) ou un comportement spécifié par un diagramme de
séquence ou de communication.
❑ Action créer ( create ) : permet d'instancier un objet.
❑ Action détruire ( destroy ) : permet de détruire un objet.
105
❑ Action acceptation d'événement : est utilisé pour représenter le traitement
d'un événement externe. On attend qu'un événement remplissant les
conditions spécifiées se produise pour l’accepter et passer à l’action
suivante.
❑ Action acceptation d’événement temporel : Elle est utilisée pour
représenter l’attente de l’occurrence d’un événement temporel.
❑ Envoi de signal :
▪ Il crée une instance d'un signal à partir de ses entrées et l'envoie à l'objet cible
▪ L’objet cible doit être spécifié
▪ L'envoie à l'objet cible peut invoquer une transition d'états ou une autre activité
106
▪ Notation et exemples :
Acceptation d’événement
Envoi de signal
Objet cible
Acceptation d’événement temporel
107
❑ Activité structurée :
❑ Elle est utilisée pour créer des groupes logiques de nœuds et d'arcs
d'activité.
❑ L'exécution de ses nœuds d'activité ne commence pas tant que toutes les
données d'entrée ne sont pas reçues.
❑ Les données de sortie provenant d'une activité structurée ne sont pas
accessibles aux autres nœuds dans l'activité et le flux ne continue pas sa
progression dans l'activité tant que l'exécution de toutes les actions de
l'activité structurée n'est pas terminée.
108
▪ Notation et exemple :
109
Diagramme de paquetages
❑ Paquetage ou package :
❑ est un mécanisme général de regroupement d’éléments UML (diagrammes,
classes, UCs, paquetages, …)
❑ permet d’organiser les éléments d’un modèle pour qu’il soit plus
compréhensible.
❑ est utilisé pour modéliser l'architecture du système
❑ représente un espace de noms
110
…Diagramme de paquetages
❑ Exemples :
111
❑ Dépendance entre paquetages
❑ Les éléments d’un paquetage emboîté voient les éléments de leur
paquetage ou des paquetages englobants.
❑ L’accès d’un paquetage englobant aux éléments d’un paquetage emboîté
n’est possible que si une relation de dépendance est définie entre les
paquetages concernés.
❑ Une relation de dépendance doit exister dès qu’un paquetage importe des
éléments d’un autre paquetage.
112
113
Diagramme d’états-transitions
❑ Le diagramme d'états-transitions (ou machine à états) décrit le
comportement interne d'un objet à l'aide d'un automate à états finis.
❑ Il présente les séquences possibles d'états et d'actions qu'une instance
de classe peut traiter au cours de son cycle de vie en réaction à des
événements discrets (de type signaux, invocations de méthode, etc.).
❑ On peut l’utiliser aussi pour décrire le comportement de cas
d'utilisation, de sous-systèmes ou d’une méthodes.
❑ Il est le seul diagramme UML qui offre une vision complète et non
ambiguë de l'ensemble des comportements de l'élément auquel il est
attaché.
114
…Diagramme d’états-transitions
❑ Un DET est une machine à états liée à une entité (objet de classe,
système, sous-système, UC, …). Il décrit ses évolutions possibles :
❑ la liste des états que peut prendre l’objet durant son CV
❑ les événements déclenchant les changements d’états
❑ les éventuelles conditions qu’il doit vérifier avant de changer d’état
❑ les opérations qui le font passer d'un état à un autre, et l’ordre d’invocation de
ces opérations
❑ Un diagramme d’états transitions (DET) est un graphe qui
représente un automate à états finis.
Evt3
[ Condition ] Evt1
Etat1
Etat2
Evt2
Evt4
❑ Etat d’un objet
❑ L’état d’un objet est une situation donnée durant la vie de cet objet.
❑ Il a une durée finie, variable selon la vie de l’objet.
❑ Dans un état donné, l’objet est tout simplement en attente d’événements.
❑ L’état d'un objet est déterminé par l’ensemble des valeurs de ses attributs et
par la présence de liens avec d’autres objets.
❑ Dans un DET, on distingue deux états particuliers :

▪ L’état initial : état avant la création de l’objet
▪ L’état final : état après la destruction de l’objet.

❑ Transition :
❑ Une transition représente le passage instantané d'un état vers un autre.
❑ Elle indique qu’une instance dans l’état E1 peut entrer dans l’état E2 si un
événement déclencheur se produit et que les conditions de garde sont
vérifiées.
E1 [ cond.1] evt( a1, a2, ...,bn ) / [cond.2] E2
E3 evt( b1, b2, ...,bn ) [cond.3] E4

❑ Evénement
❑ Définition
Un événement correspond à l’occurrence d’une situation donnée dans le domaine du
problème. C’est une information instantanée.
❑ Typologie des événements :
▪ Evénement appel (CallEvent):

◦ Modélise la réception par un objet d’un message invoquant une opération.
◦ Peut provoquer l’exécution du comportement implémentant l’opération appelée.

◦ Peut provoquer la transition vers un autre état. Cette transition se produit après l’exécution
de l’opération appelée.
▪ Peut comporter des attributs qui correspondent à des paramètres de l’opération
appelée.
▪ Syntaxe :
<EvénementAppel>::=<nomOp>[‘(‘<attribut>[‘,’ attribut>]*’)’]
▪ Exemple :
Evénements appel
Diagramme d’états transition d’une commande

❑ Evénement temporel (TimeEvent):
▪ Spécifie un point dans le temps par une expression absolue ou relative à un

autre point.
▪ L’expression relative s’évalue en une durée écoulée depuis l’entrée dans l’état
source de la transition portant l’événement.
▪ Syntaxe :
<EvénementTemp> ::= <TmpRel> | <TmpAbs>
<TmpRel> ::= ‘après’ <expression> Evénement temporel
<TmpAbs> ::= ‘à’ <expression>
▪ Exemple : livrée après( 1 an )

❑ Evénement modification (ChangeEvent):
▪ Modélise un changement de l’état du système qui rend une condition vraie.
▪ Prend la forme d’un test continu, qui se déclenche à chaque changement de
valeurs des variables intervenant dans la condition
▪ Syntaxe :
<EvénementModif>::=‘quand’ <expBooléenne>
▪ Exemple :
disponible quand( dateSystème=dateLocation ) non disponible
Evénement modification
❑ Garde :
❑ Définition
Une garde (ou condition de garde) est une condition booléenne dont dépend le
déclenchement d’une transition lors de l’occurrence d’un événement.
Evt [Condition]
Etat A Etat B
Elle est évaluée dès l’arrivée de l’événement de déclenchement.

Exemple :
non régler( montant )[ montant=totalFacture ] payée
payée
Garde
❑ Types d’états :
❑ Etat de sous-machine
▪ Un état de sous-machine fait référence à une machine d’état (appelée aussi sous-
machine d’état) .
▪ Un sous-état est un état emboîté dans un état de sous-machine.
▪ Les sous-états peuvent être emboîtés à n’importe quel niveau.
▪ Les états de sous-machine apportent plus de clarté aux DET.
❑ Exemple :
Etat de sous-machine
Diagramme d’états/ transitions d’une fenêtre de Windows
125
❑ Exemple (suite) :
Sous-machine à états de l’état (de sous-machine) NonRéduite
126
❑ Etat composite
▪ Un état composite est un état décomposé en régions contenant chacune un ou plusieurs
sous-états.
▪ Quand un état composite comporte plus d’une région, il est qualifié d’état orthogonal.
▪ Lorsqu’un état orthogonal est actif, un sous-état direct de chaque région est
simultanément actif.
▪ Un état composite ne comportant qu’une région est qualifié d’état non orthogonal.
127
❑ Implicitement, tout diagramme d’états-transitions est contenu dans une
région.
❑ L’utilisation d’états composites et d’états de sous-machine permet de
développer une spécification par raffinements.
128
❑ Exemple:
Diagramme d’états transition d’un distributeur de boissons.

129
▪ Remarques :
◦ Une transition ayant pour cible la frontière d’un état composite est équivalente à une
transition ayant pour cible l’état initial de l’état composite.
◦ Une transition ayant pour source la frontière d’un état composite est équivalente à
une transition qui s’applique à tout sous-état de l’état composite source.
◦ Si la transition ayant pour source la frontière d’un état composite ne porte pas de
déclencheur explicite, elle est franchissable quand les états finaux de l’état composite
sont atteints.
◦ Les transitions peuvent également toucher des états de différents niveau d’imbrication
en traversant les frontières des états.
❑Pseudo-états
❑Points d’option et points de jonction
▪ Ils permettent de représenter des alternatives pour le franchissement d’une transition.
▪ Il permettent de définir des transitions composites qui factorisent et partagent des connexions :
◦ Plusieurs transitions peuvent se rejoindre puis partager des actions
◦ Une transition peut se séparer en des connexions mutuellement exclusives.
▪ On utilise pour cela des pseudo-états particuliers :
◦ Les points de jonction
◦ Les points d’option

❑ Point de jonction
▪ Un point de jonction permet de partager des segments de transition.
▪ Plusieurs transitions peuvent arriver et/ou quitter un point de jonction.
▪ Tous les chemins à travers le point de jonction sont potentiellement valides.
▪ Il permet de rendre plus visibles les chemins alternatifs.
❑ Exemple :
Etat1 [ b>0 ] Etat3
e1[ a>0 ]
b=0 Etat4
Etat2 e2[ a>0 ]

[ b<0 ]
Etat5
133
❑ Point d’option (dynamique) :
▪ Les gardes situées en aval du point d’option sont évaluées quand le point de choix est
atteint.
▪ Si, quand le point de choix est atteint, aucun segment en aval n’est franchissable, le
diagramme est mal formé.
▪ Si plusieurs segments sont franchissables, l’une d’entre elles est choisie aléatoirement.
❑ Exemple
135
❑ il est possible de masquer les sous-états d’un état ou d’un état de sous-
machine et de les définir dans un autre diagramme. Ceci nécessite parfois
l’utilisation de pseudo-états appelés points de connexion.
❑ Il est possible d’entrer ou de sortir d’un état composite de plusieurs façons.
❑ Les points de connexion sont des points d’entrée et de sortie portant un
nom, et situés sur la frontière d’un état composite.
136
❑ Point d’entrée
▪ Un point d’entrée peut être ajouté à une machine à état ou à un état composite.
▪ Dans chaque region d’une machine à état ou d’un état composite, le point d’entrée
possède une transition vers un noeud appartenant à la même region.
❑ Point de sortie
▪ Un point de sortie appartient à une machine à état ou à un état composite.
▪ L’entrée à un point de sortie d’une region d’état composite ou d’une machine à états
référencée par un état de sous-machine implique la sortie de cet état et le
déclenchement d’une transition qui a ce point de sortie comme source dans la machine
à état englobante.
137
❑ L’entrée au pseudo-état terminal implique que l’exécution de la machine à
état est terminée.
❑ Notation :
138
❑ Exemple :
Diagramme d’états transitions d’un distributeur de billets
139
❑ Exemple (suite) :
Diagramme d’états transitions de lecture d’un montant dans le

distributeur de billet
140
❑ Bifurcation et fusion
▪ Une bifurcation permet de subdiviser la transition entrante en deux ou plusieurs
transitions conduisant chacune à une region orthogonale (d’un état composite).
▪ Les segments sortant d’une bifurcation ne doivent porter ni guardes, ni déclencheurs.
▪ Une fusion sert à fusionner ensemble des transitions émanant de plusieurs regions
orthogonales.
▪ Les transitions entrant à une fusion ne doivent porter ni gardes, ni déclenceurs.
141
❑ Exemple :
142
❑ Remarques
❑ Toutes les classes du modèle statique ne requièrent pas nécessairement un
diagramme d’états-transitions. Il faut donc trouver celles qui ont un
comportement dynamique complexe nécessitant une description poussée
du comportement. Cela correspond à l’un des 2 cas :
▪ Les objets de la classe peuvent-ils réagir de façon différente à l’occurrence du même
événement ?
▪ La classe doit-elle organiser certaines opérations dans un ordre précis?
❑ Ne définissez pas des diagrammes d’états contenant moins de trois états.
143
❑ Utilisation des diagrammes états-transitions :
❑ En phase d'analyse :
▪ Description de la dynamique du système vu de l'extérieur
▪ Synthèse des scénarios liés aux cas d'utilisation
▪ Événements = action des acteurs
❑ En phase de conception :
▪ Description de la dynamique d'un objet particulier
▪ Evénements = appels d'opérations
144
Chapitre 2 : les principes
de conception SOLID
145
❑ Quand les besoins (fonctionnels ou techniques) des utilisateurs
changent ou évoluent , on sera amené à modifier la conception de
l’application
❑ La conception devient de moins en moins maintenable et évolutive

❑ Elle devient submergée par des "horreurs"
❑ les dégradations de la conception sont liées aux changements des

exigences envers l’application,
❑ Elle sont dues aux dépendances et à l’architecture des dépendances :

rigidité, fragilité et non réutilisabilité
146
Objectifs de la COO
❑ Objectifs d’une bonne conception OO :
❑ Produire des conceptions évolutives, maintenables
❑ Eviter d’obtenir un code rigide, fragile et/ou non réutilisable
❑ Atteindre ces objectifs nécessite de:

❑ suivre les principes de conception OO,
❑ Réutiliser l’expérience des autres (frameworks, patrons, …)
❑ Avoir de l’expérience
147
Couplage fort/Couplage faible
❑ Couplage fort
❑ Quand une classe A est lié à une classe B, on dit que la classe A est
fortement couplée à la classe B.
❑ La classe A ne peut fonctionner qu’en présence de la classe B.
❑ Si une nouvelle version de la classe B (soit B2), est créée, on est obligé de
modifier dans la classe A.
148
…Couplage fort/Couplage faible
❑ Modifier une classe implique :
❑ Il faut disposer du code source.
❑ Il faut recompiler, déployer et distribuer la nouvelle application aux clients.
❑ Risque de problèmes au niveau de la maintenance de l’application
149
❑ Exemple :
La méthode
calculerStatistique( )
appelle
getTempératures ( )
150
❑ Couplage faible :
❑ Pour utiliser le couplage faible, nous devons utiliser les interfaces.
❑ Considérons une classe A et une classe B qui implémente une interface IB.
Si A est liée à l’interface IB par une association, on dit que A et B sont liées
par un couplage faible.
151
❑ Exemple :
152
Principes de la COO
❑ Références :
Martin Fowler Barbara Liskov Robert C. Martin Bertrand Meyer

(Uncle Bob)
153
…Principes de la conception OO
154
…Principes de la conception OO
❑ Single Responsibility Principle : Principe de responsabilité unique
❑ Open-Closed Principle : Principe d'ouverture / fermeture
❑ Liskov Substitution Principle :Principe de substitution de Liskov
❑ Interface Segregation Principle :Principe de ségrégation des

interfaces
❑ Dependency Inversion Principle :Principe d'inversion des

dépendances
155
Principe de responsabilité unique
❑ Un module (classe, méthode, paquet, etc.) devrait n’avoir qu’une
responsabilité unique.
❑ Un module ne devrait jamais avoir plus d'une raison de changer.
156
157
❑ Une classe qui respecte le SRP est
❑ fortement cohésive. La cohésion (la cohésion fonctionnelle) est une mesure
de l’étroitesse des liens et de la spécialisation des responsabilités d’une
classe (ou d’élément).
❑ facile à comprendre
❑ facile à réutiliser
❑ facile à maintenir
❑ robuste (contrairement aux classes fragiles, constamment affectées par le
changement)
158
Principe d’ouverture-fermeture
❑ Un code doit être ouvert à l’extension mais fermée à la
modification
❑ Nous devons pouvoir ajouter une nouvelle fonctionnalité en

ajoutant du nouveau code et non en modifiant le code existant.
159
…Principe d’ouverture-fermeture
160
161
Principe de substitution de Liskov
❑ Les instances d’une classe doivent être remplaçables par des
instances de leurs sous-classes sans altérer l’application.
162
163
Principe de ségrégation des interfaces
❑ Les clients d’une interface ne doivent pas être obligés de dépendre
de méthodes (de cette interface) qu’ils n’utilisent pas.
❑ Un client doit avoir des interfaces avec uniquement ce dont il a

besoin
❑ Incite à avoir des interfaces petites pour ne pas forcer des classes à
implémenter les méthodes qu’elles ne veulent pas.
❑ Peut amener à une multiplication excessive du nombre d'interfaces!
❑ Incite à ne pas faire "extract interface" sans réfléchir
164
…Principe de ségrégation des interfaces
❑ Exemple :
165
166
167
Principe d’inversion des dépendances
❑ Il s’agit de réduire les dépendances entre les classes concrètes
❑ Les classes de haut niveau ne doivent pas dépendre de classes de

bas niveau. Les deux ne doivent dépendre que d’abstractions.
❑ Les abstractions ne doivent pas dépendre de details. Les details

doivent dépendre d’abstractions.
168
…Principe d’inversion des dépendances
❑ Exemple :
169
Chapitre 3 : les patrons
de conception
170
Patrons de conception
❑ Notion de « patron » d’abord apparue en architecture :
❑ l’architecture des bâtiments
❑ la conception des villes et de leur environnement
❑ L’architecte Christopher Alexander : «Un modèle (patron) décrit un

problème qui se manifeste constamment dans notre
environnement, et le cœur de la solution de ce problème, d’une
façon telle que l’on peut réutiliser cette solution des millions de
fois.» [Livre: The Timeless Way of Building, Oxford University Press
1979]
171
…Patrons de conception
❑ Un patron de conception est une solution générale et réutilisable
d’un problème récurrent ; (formalisation de bonnes pratiques)
❑ Premiers patrons à partir de 1987 (partie de la thèse de Erich

Gamma)
❑ puis Richard Helm, John Vlissides et Ralph Johnson («Gang of Four, GoF»)
❑ premier catalogue en 1993 : Elements of Reusable Object-Oriented Software
❑ design pattern = modèles de conception = patrons de conception =

motifs de conception
172
173
❑ Pourquoi définir des patrons de conception ?
❑ Construire des systèmes plus extensibles, plus robustes au changement
❑ Capitaliser l’expérience collective des informaticiens
❑ Réutiliser les solutions qui ont fait leur preuve
❑ Les patrons sont complémentaires aux API

❑ Une API propose des solutions directement utilisables
❑ Un patron explique comment structurer son application avec une API
174
❑ Patron de conception dans le cycle de développement
❑ Intervient en conception détaillée
❑ Reste indépendant du langage de programmation
❑ Types de patrons :
❑ Création
❑ Comportement
❑ Structure
175
❑ Comment décrire un patron de conception ?
❑ Nom du patron
❑ Problème : Description du sujet à traiter et de son contexte
❑ Solution : Description des éléments, de leurs relations/coopérations et de
leurs rôles dans la résolution du problème
▪ Description générique
▪ Illustration sur un exemple
❑ Conséquences : Effets résultant de la mise en œuvre du patron; complexité
en temps/mémoire, impact sur la flexibilité, portabilité, ...
176
Le patron Strategy
❑ Problème : Modéliser la validation de données dans un champ
texte. La validation peut être numérique, alphanumérique ou du
numéro de téléphone.
❑ Solution 1 :
177
…Le patron Strategy
❑ Critique de la solution :
❑ Autant de classes que d’algorithmes de validation
❑ Héritage de toutes les propriétés malgré que la différence est uniquement
dans la méthode de validation
❑ Que faire si l’on veut ajouter des champs texte sans validation ?
❑ Que faire si l’on veut changer la méthode de validation alphanumérique afin
d’inclure (ou d’éliminer) certain caractères ?
178
❑ Solution 2 :
❑ Extraire le comportement de validation et définir une interface commune à
tous les comportements possibles
❑ Créer les classes comportant les algorithmes de comportement à partir de
l’interface commune.
❑ Ajouter dans l’objet concerné (contexte) un attribut pour le comportement
179
Solution aux problèmes
180
❑ Le patron Strategy:
181
❑ Le patron Strategy cherche principalement à séparer un objet de
ses comportements/algorithmes en encapsulant ces derniers dans
des classes à part.
❑ Conséquences :
❑ Il est beaucoup plus facile de se retrouver dans le code principal
❑ Il est beaucoup plus facile d’enlever, d’ajouter et de modifier un
comportement
❑ On diminue l’utilisation de tests conditionnels
❑ On élimine la redondance et le couper/coller
❑ On accroît la réutilisabilité du code ainsi que sa flexibilité
182
Le patron Observer
❑ Problème :
❑ Ecrire une application pour suivre et afficher les conditions météorologiques
(température, humidité, pression)
❑ Mettre à jour et afficher les conditions actuelles , les statistiques
météorologique et les prévisions météo.
❑ Pouvoir étendre l’application par d’autres facteurs météorologiques
183
…Le patron Observer
❑ Solution 1 :
184
❑ Que faire si l’on veut ajouter un autre afficheur sans avoir la possibilité de
modifier le code de la classe DonneesMeteo?
❑ Comment notifier les afficheurs des modifications d’états sans connaitre
leurs types ?
❑ Comment supprimer des afficheurs sans toucher au code?
185
❑ Solution 2 :
186
L’observable
187
❑ Le patron Observer définit une dépendance 1-à-plusieurs entre
des objets de façon qu’à chaque changement de l’état de l’objet,
tous ces dépendants sont notifiés et mis à jour automatiquement.
❑ Conséquences :
❑ Deux objets, qui sont faiblement couplés, entrent en interaction avec très
peu de connaissance de l’un envers l’autre→ plus d’indépendance et de
flexibilité
❑ On peut ajouter/remplacer/supprimer un observateur à tout moment sans
toucher au sujet
❑ On peut réutiliser le sujet ou l’observateur facilement
188
Le patron State
❑ Problème :
❑ Le comportement des méthodes d’une commande dépendent de son état
actuel
❑ Comment faire passer une commande d’un état à un autre sans vérifier, à
chaque appel d’une opération, son état actuel?
❑ Comment concevoir les états d’une commande et les transitions entre eux?
189
…Le patron State
❑ Solution 1 :
❑ Il n’est pas possible de représenter les transitions légales et les transitions
illégales
❑ Il n’est pas possible de définir les
❑ s liées aux transitions entre les états
190
…Le patron State
❑ Solution 2 :
❑ Isoler les comportements dépendants des états dans des classes différentes.
❑ Faire corresponde à chaque état une classe qui décrit les activités et les
transitions attachées à l’état qu’elle représente.
191
…Le patron State
❑ Conception du diagramme d’états/Transitions :
192
…Le patron State
❑ Le patron State :
193
…Le patron State
❑ Le patron State est un patron de comportement
❑ Il permet de déléguer le comportement d’un objet (Contexte) à un

autre objet (IEtat). Cela permet de changer le comportement de
l’objet en cours d’exécution.
❑ Il est utilisé quand un objet a un fonctionnement différent selon

son état interne. Son état change selon les méthodes appelées.
❑ Il permet d’isoler les algorithmes propres à chaque état d’un objet.
194
Le patron Facade
❑ Problème :
❑ Le système contient un sous-système complexe avec plusieurs interfaces.
❑ Certaines de ces interfaces présentent des opérations qui ne sont pas utiles
au reste système
❑ Le nombre de liens de dépendance avec les éléments du sous système est
élevé
❑ Le code ressemble à un plat de spaghetti
195
…Le patron Façade
❑ Solution :
❑ Utiliser une interface présentant uniquement les opérations utiles
❑ Créer une classe, la façade, qui présente ces opérations réellement
nécessaires.
196
❑ Patron Façade :
❑ Objectifs :
▪ Fournir une interface unique en remplacement d’un ensemble d’interfaces d’un sous-
système
▪ Définir une interface de haut niveau pour rendre le sous-système plus simple
d’utilisation
❑ Consequence :
▪ Isoler les parties d’un sous-système, utiles à la partie cliente.
197
Sous-système
198
Le patron Singleton
❑ Problème :
❑ Créer un fichier de journalisation unique dans lequel seront conservés tous les
événements survenus au cours de l’exécution de notre application
❑ Solution 1 :
❑ Utiliser directement le constructeur va multiplier le nombre de fichiers de
journalisation.
199
…Le patron Singleton
❑ Solution 2 :
200
❑ Le patron Singleton
Constructeur privé pour

empêcher les classe clientes
de créer des instances de
cette classe
201
…Le patron Singleton
❑ Le patron Singleton est un patron de création
❑ Il garantit qu’une seule instance d’une classe sera créée tout le long
de l’exécution d’une application (Cas d’une ressource système,
d’une connexion à une base de données,…)
❑ La classe Singleton possède une seule instance d’elle-même et

fournit une méthode qui permet d’accéder à cette instance unique
❑ Elle empêche toute autre classe de l’instancier
202
Le patron Composite
❑ Problème :
❑ Modéliser les entités métier d’un petit magasin qui vend des équipements
sportifs : balles, ballons, serviettes, poids d’haltères et barres d'haltères. Les
produits se vendent soit en pièces détachées, soit en ensemble (l'haltère
avec un jeu de 5 paires de poids, 2 raquettes et 6 balles, etc).
❑ Le prix d'un ensemble est la somme des prix de ses parties (composées ou
non) moins 10% ;
❑ Le code barre est spécifique à chaque produit vendu qu'il soit composé ou
non ;
203
❑ Solution 1 :
204
❑ Des attributs inutiles (dont la valeur reste à null) vont être ajoutés à chaque
ensemble.
❑ L’ajout d’un nouveau composant nécessite la modification du code
205
❑ Solution 2 :
206
❑ Le patron Composite :
207
❑ Le patron Composite est un patron de structure
❑ L’objectif du patron Composite est de permettre aux clients de

traiter de façon uniforme des objets individuels et des
compositions d’objets.
❑ Il construit des structures complexes d’objets en composant

récursivement sous forme d’arbres des objets de même nature.
❑ La composition est factorisée au maximum.
208
Le Patron Decorator
❑ Problème :
❑ Mettre en œuvre un système de gestion des réservation de terrains de
tennis. Il existe deux types de terrains : les terrains en dur et les terrains en
gazon. Le client peut aussi réserver des balles de tennis et des raquettes.
Leurs prix s’ajoute alors au prix du terrain.
209
…Le Patron Decorator
❑ Solution 1 :
210
❑ Critique de la solution 1 :
❑ Le nombre de classes augmente avec le nombre d’options. Avec 3 types de
terrains et 4 options on aura 30 classes → Explosion du nombre de classes.
❑ Il n’est pas possible de choisir plusieurs fois la même option
211
❑ Solution 2 :
❑ Critique de la solution 2 :
❑ Tout ajout d’une nouvelle option va entrainer la modification des trois
classes → Code ouvert à la modification.
212
❑ solution 3 :
213
t est un terrain en
gazon sans options
TerrainGazon t (non décoré)
calculerPrix()
t1 est un terrain. C’est
l’objet t enveloppé Objet TerrainGazon
dans un objet Balle
Balle t1 calculerPrix()
calculerPrix() TerrainGazon t
Objet TerrainGazon enveloppé par un décorateur Balle
214
t2 est un terrain. C’est l’objet t1
enveloppé dans un objet Raquette.
Raquette t2 Balle t1 TerrainGazon t

Prix calculerPrix() calculerPrix()
calculerPrix()
Objet TerrainGazon enveloppé par un décorateur Balle, lui-

même enveloppé dans un décorateur Raquette.
215
❑ Le patron Decorator :
216
❑ Le patron Decorator est un patron de structure
❑ Objectifs du patron Decorator
❑ Ajouter dynamiquement des responsabilités (non obligatoires) à un objet.
❑ Eviter de sous-classer la classe pour rajouter ces responsabilités.
❑ Conséquence :
❑ Les responsabilités des classes sont isolées
❑ L’héritage est une forme d’extension qui n’est pas nécessairement la
meilleure pour obtenir la flexibilité d’une conception
217
❑ Les classes de décorations sont utilisées pour envelopper les composants
concrets.
❑ Les décorateurs changent le comportement de leurs composants tout en
ajoutant des nouvelles fonctionnalités
❑ On peut envelopper un composant dans n’importe quel nombre de
décorateurs.
218
Le patron Abstract Factory
❑ Problème :
Que faire pour obtenir un code

qui satisfait le principe OCP?
219
❑ Solution :
Partie
standard
Partie variable
Factory
Method
Product
Concrete
Product
220
…Le patron Abstract Factory
❑ Le patron Abstact Factory
221
…Le patron Abstract Factory
❑ Le patron Factory Method est un patron de création
❑ Objectif : Fournir une interface pour créer des objets d'une même
famille sans préciser leurs classes concrètes.
❑ L’application utilise des objets regroupés en famille. Selon certains

critères, elle utilise les objets d'une famille ou d'une autre. Elle doit
utiliser ensemble les objets d'une même famille.
❑ Le Design Pattern permet d'isoler l'appartenance à une famille de

classes.
222
Chapitre 4 : Patrons
d‘architecture logicielle
223
Architectures logicielles
❑ Qu’est ce qu’une architecture logicielle ?
❑ Une architecture logicielle définit la structuration d'un système informatisé
en termes de composants et d'organisation de ses fonctions.
❑ Contrairement aux spécifications produites par l’analyse fonctionnelle, le
modèle d'architecture ne décrit pas ce que doit réaliser un système
informatique ("le quoi") mais plutôt comment il doit être conçu de manière
à répondre aux exigences.
224
❑ Comment décrire une architecture logicielle ?
❑ Décrire l’organisation générale d’un système et sa décomposition en sous-
systèmes ou composants
❑ Déterminer l’interfaçage entre les sous-systèmes en termes de classes
(façade par exemple) et d’interfaces
❑ Décrire les interactions et le flot de contrôle entre les sous-systèmes
❑ Décrire également les composants utilisés pour implanter les
fonctionnalités des sous-systèmes
▪ Les propriétés de ces composants
▪ Leur contenu (e.g., classes, autres composants)
▪ Les machines ou dispositifs matériels sur lesquels ces modules seront déployés
225
❑ Pourquoi concevoir une architecture logicielle ?
❑ Construction : fournir un plan pour le développement et l’intégration des
modules d’une application en mettant en évidence les composants et les
dépendances entre eux. Ainsi les développeurs peuvent travailler sur des
parties individuelles du système
❑ Compréhension : facilite la compréhension des grands systèmes complexes
en donnant une vue de haut-niveau de leur structure et de leurs
contraintes. Les motivations des choix de conception sont ainsi mis en
évidence
226
❑ Évolution : mettre en évidence les points où un système peut être modifié et
étendu. La séparation composant/connecteur facilite une implémentation de type
« plug-and-play»
❑ Réutilisation : favoriser l’identification des éléments réutilisables, parties de
conception, composants, caractéristiques, fonctions ou données communes
❑ Analyse : offrir une base pour l’analyse plus approfondie de la conception du
logiciel, analyse de la cohérence, test de conformité, analyse des dépendances
❑ Gestion : contribuer à la gestion générale du projet en permettant aux différentes
personnes impliquées de voir comment les différents morceaux seront agencés.
L’identification des dépendance entre composants permet d’identifier où les délais
peuvent survenir et leur impact sur la planification générale
227
❑ Quelles sont les différentes vues (structurelles) d’une architecture
logicielle ?
❑ Vue logique : Description logique du système décomposé en sous-systèmes
(modules + interface)
❑ Vue d’implémentation : Description de l’implémentation (physique) du
système logiciel en termes de composants et de connecteurs
❑ Vue de déploiement : Description de l’intégration et de la distribution de la
partie logicielle sur la partie matérielle
❑ La vue logique est décrite à l’aide de diagrammes de paquetages et

de diagrammes de classes.
228
❑ Comment développer la vue logique de l’architecture ?
❑ Commencer par une esquisse de l’architecture
▪ En se basant sur les cas d’utilisation, décomposer le système en sous-systèmes
▪ Déterminer les principaux composants requis (paquetages, classes, interfaces)
▪ Sélectionner un style architectural (patrons, framework)
❑ Raffiner l’architecture
▪ Identifier les principales interactions entre les composants et les interfaces requises
▪ Décider comment distribuer les données et les fonctionnalités entre les différents
composants
229
❑ Considérer chacun des cas d’utilisation et ajuster l’architecture pour qu’il
soit réalisable
❑ Détailler l’architecture et la faire évoluer
230
Patron MVC
❑ Modèle-Vue-Contrôleur (MVC) :
❑ Modèle d’architecture logicielle destiné aux interfaces graphiques
❑ Il est inventé en 1978 par Trygve Reenskaug (Univ. Oslo). Il a été utilisé la première
fois pour créer des interfaces graphiques avec le langage de
programmation Smalltalk en 1980.
❑ Il propose une solution générale au problème de la structuration du code d’une
application (web)
❑ Il définit des règles qui déterminent dans quelle couche de l’architecture, et dans
quelle classe de cette couche, doit être intégrée une fonctionnalité spécifique
❑ Il est très répandu et accepté comme un des patrons menant à une organisation
rigoureuse et logique du code.
❑ Il est utilisé par de nombreux frameworks pour applications web tels que ASP.NET
MVC, Spring ou Angular Js.
231
Description
❑ Une application conforme au patron MVC doit comporter trois
types de modules : les modèles, les vues et les contrôleurs
❑ Les trois éléments sont indépendants les uns des autres
232
❑ Le modèle
❑ Il contient les données ainsi que de la logique en rapport avec les données:
validation, lecture et enregistrement
❑ Il représente les objets métier du domaine de l’application
❑ Il est indépendant de la vue et du contrôleur et ne les utilise pas.
233
❑ La vue
❑ Il s’agit d’une IHM (Interface Homme Machine)
❑ Elle représente ce que l'utilisateur a sous les yeux
❑ Elle se sert du modèle
❑ Elle contient des éléments visuels nécessaires pour afficher les données provenant
du modèle
❑ Elle peut être :
▪ une application graphique Swing, AWT, SWT pour Java (Form pour C#…) ;
▪ une page web ;
▪ un terminal Linux ou une console Windows ;
▪ etc.
234
❑ Le contrôleur
❑ C'est cet objet qui a pour rôle de contrôler les données.
❑ Il traite les actions de l'utilisateur et modifie les données du modèle et de la
vue  Il permet de faire le lien entre la vue et le modèle
235
❑ Le modèle ne se sert ni de la vue ni du contrôleur,
❑ Le modèle peut leur envoyer des messages.
❑ Il y a deux liens entre la vue et le modèle:
❑ la vue lit les données du modèle
❑ La vue reçoit des messages provenant du modèle (notification de changement)
❑ Un même modèle peut être utilisé par plusieurs vues (dans la mesure où une
vue est associée à un modèle et un modèle est indépendant).
❑ Le contrôleur dépend de la vue et du modèle :
❑ la vue comporte des éléments visuels que l'utilisateur peut actionner
❑ Le contrôleur répond aux actions effectuées sur la vue et modifie les données du modèle
236
❑ Dans le modèle MVC, il est généralement admis que la vue puisse
consulter directement le modèle (lecture) sans passer par le
contrôleur. Par contre, elle doit nécessairement passer par le
contrôleur pour effectuer une modification (écriture).
237
❑ Le patron MVC est la composition de trois patrons : Composite,
Strategy et Observer :
❑ Composite : La vue est un ensemble imbriqué de composants (fenêtres,
panneaux, boutons, champs de texte, …). Ces composants sont soit des
composites, soit des feuilles (leaf dans le patron)
❑ Strategy : La vue constitue le contexte du patron. Elle n’est concernée que
par les aspects visuels de l’application et délègue son comportement au
contrôleur. Donc, c’est le contrôleur qui implémente la stratégie.
❑ Observer : le modèle étant l’observable, il notifie les vues et les contrôleurs
des changements qu’il subit.
238
Le patron MVP
❑ Le patron MVP (Model View Presenter) est dérivé du patron MVC
❑ Il sépare les responsabilités en quatre composants:

❑ la vue est responsable de fournir les éléments de l'interface utilisateur
❑ l'interface de la vue est utilisée pour établir un couplage faible entre le
présentateur et la vue,
❑ le présentateur est responsable de l'interaction entre la vue et le modèle
❑ le modèle est responsable du comportement métier et la gestion de l'État
des objets métier.
239
240
Le patron MVVM
❑ Il a été créé en 2004 par Microsoft.
❑ Il est adapté pour le développement d’applications basées sur les

technologies WPF (Windows Presentation Foundation) et Silverlight
via l'outil MVVM Light par exemple.
❑ Il permet de séparer la vue de la logique du métier et de l'accès aux

données.
❑ Le lien entre la vue et le modèle de données est fait par des

mécanismes de binding.
241
242
❑ Le modèle : le modèle reste le même que celui de MVC. C'est la
couche qui décrit et qui se porte responsable de l'intégrité des
données manipulées par l'application. L'interaction avec la base de
données serait l'une de ses responsabilités.
❑ La vue/contrôleur :
❑ Son rôle est de présenter les données qui lui sont fournies par
le ViewModel et gérer les interactions utilisateur. Chaque vue est couplée
avec un ViewModel.
❑ Les vues n'ont pas de référence vers le modèle, mais les contrôleurs non
plus. Le seul vis-à-vis qui garantira la connexion entre les vues et leurs
modèles c'est le ViewModel
243
❑ Le View Model :
❑ C'est plutôt une représentation logique de la vue.
❑ Il contient des propriétés qui détaillent l'état de chaque composant
d'interface utilisateur. Par exemple, le texte formaté d'un champ TextField,
ou l'état d'un Switch (activé ou pas). Il expose également les actions que la
vue peut effectuer, comme les Buttons et les GestureRecognizer.
❑ Il est responsable de récupérer les données à partir du modèle et de les
rendre disponibles à la vue sous une meilleure forme.
244
❑ La vue/contrôleur possède une référence vers le ViewModel, mais
pas l'inverse ;
❑ La vue/contrôleur ne communique pas avec le modèle. L'unique

accès est assuré à travers le ViewModel ;
❑ Le ViewModel possède une référence vers le modèle, mais pas

l'inverse ;
❑ Le modèle ne communique avec aucune couche, comme en MVC.
245
❑ Pour mettre à jour l'interface utilisateur quand le modèle change,
le patron MVVM utilise le mécanisme de Data-Binding.
❑ Le Data-Binding est un concept extrêmement puissant qui

connecte automatiquement des propriétés d'objets à des
contrôles UI.
246
247
❑ Comparaison des trois patrons architecturaux.
248
Architecture trois tiers
❑ On l’appelle aussi architecture à trois niveaux ou architecture à
trois couches
❑ C'est une architecture basée sur l'environnement client-serveur.
❑ Il s'agit d'un modèle logique d'architecture applicative qui vise à
modéliser une application comme un empilement de trois
couches logicielles :
❑ couche de présentation ;
❑ couche de traitement ;
❑ couche d'accès aux données.
249
❑ la présentation des données, correspondant à l'affichage, la
restitution sur le poste de travail, le dialogue avec l'utilisateur ;
❑ le traitement métier des données, correspondant à la mise en

œuvre de l'ensemble des règles de gestion et de la logique
applicative ;
❑ l'accès aux données persistantes : correspondant aux données qui

sont destinées à être conservées sur la durée, voire de manière
définitive.
250
❑ Chaque couche propose un ensemble de services rendus.
❑ Les services d'une couche sont mis à disposition de la couche

supérieure.
❑ On s'interdit qu'une couche invoque les services d'une couche plus

basse que la couche immédiatement inférieure ou plus haute que
la couche immédiatement supérieure
❑ Les fonctionnalités de chaque couche peuvent évoluer sans

induire de changement dans les autres couches
251
❑ Objectifs de l’architecture 3 tiers :
❑ l'allègement du poste de travail client et l'introduction de clients dits
« légers »
❑ la prise en compte de l'hétérogénéité des plates-formes
❑ l'amélioration de la sécurité des données
❑ la rupture du lien de propriété exclusive entre application et données
252
❑ Dans MVC, le flux de contrôle est inversé par rapport au modèle en
couches, le contrôleur peut alors envoyer des requêtes à toutes les
vues de manière qu'elles se mettent à jour.
❑ Dans le modèle MVC, il est admit que la vue puisse consulter

directement le modèle (en lecture) sans passer par le contrôleur.
253

Conception A Vance e

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Conception A Vance e

Transféré par

Droits d'auteur :

Formats disponibles

Conception Orientée

❑ Chapitre 1 : Rappel (diagrammes de UC, d’activité, de classes,

❑ Chapitre 2 : Les principes de COO

❑ Chapitre 3 : Patrons de conception

❑ Chapitre 4 : Architectures logicielles

❑Les versions d’UML < 1.5 définissent 9 types de diagrammes

❑La version 2.0 définit 13 diagrammes.

❑ Ils montrent les fonctionnalités du système comme vues par

❑ Relation entre acteurs

❑ Relation entre acteurs et UCs

❖ Le diagramme de classes est le point central

◼ En conception, il représente la structure d’un

Nom de Classe Nom de Classe Nom de Classe

1. Les noms des classes sont toujours au singulier.

Exemples : Fichier, Client, Chat, …

La classe possède des attributs et les instances de la

[<visibilité>] [‘/’] <nomAttribut> [‘:’ <type>]

[‘[‘<multiplicité >‘]’] [‘=’<valeurInitiale>]

[‘{‘ <contrainte> [‘,’ <contrainte> ]* ’}’]

✓ Multiplicité : nombre minimum et nombre

Grâce à la multiplicité, un attribut peut être

▪ Un type primitif : Entier, chaîne, réel, …

▪ Une classe définie par le standard : Time

▪ Expression complexe non supportée par

▪ Remarque : Dans un diagramme de

Diagramme de classes de conception

◼ Exemple : pour gérer le solde, la classe

◼ Une opération possède une signature. La

✓Liste des paramètres :

▪ Un paramètre au plus peut avoir la direction "return" dans la liste des

▪ Le type de retour d’une opération est le type du paramètre ayant la

▪ La multiplicité d’une opération est la multiplicité du paramètre ayant la

a la même signification que :

▪ {redefines <nomOp>} : l’opération redéfinie

▪ {query} : l’opération ne change pas l’état du

◼ L’identité d’un objet est indépendante des valeurs de ses attributs.

◼ L’état d’un objet est l’ensemble des valeurs des attributs

◼ Le comportement d’un objet est l’ensemble des opérations qui

Une instance de commande a été passée par un

Un logiciel d’un département ne doit être installé

Cette notation ne permet pas de montrer la

▪ L’indication des rôles est nécessaire pour les associations ambiguës.

Personne 1 0..* Compte

La collection des comptes d’une personne est

Un employé qui dirige un service doit être affecté à

Un contrat assure un individu ou une société

▪ UML interdit à une classe-association d’avoir à la fois

Serveur 1 0..* Installation

Une installation (constituée d’un logiciel et d’un

Jury est formé de Enseignant

Produit Enseignant Chercheur

Angrais ProduitIndustriel EnseignantChercheur

Héritage simple Héritage multiple 58

◼ La généralisation est une relation non réflexive :

Un directeur régional ne peut pas être en même

Une personne peut être en même temps étudiant

NordAfricaine SudAfricaine Européenne

 Il y a une relation de dépendance entre une classe A et

▪ B est le type d’un paramètre d’une opération de A

▪ B est le type de retour d’une opération de A

▪ B est le type d’un attribut de A

Cette classe a le stéréotype boundary car elle sert

Lien ou chemin de message Messages