Chapitre 3 - Analyse

COURS GÉNIE LOGICIEL
COURS 3 ANALYSE
Cours 3 :
Analyse
1
Cours 5 – Analyse OBJECTIFS DU COURS
Objectifs du cours
 Appréhender l’activité d’analyse

 Se familiariser avec les pratiques et les livrables de
l’analyse
 Utiliser UML pour exprimer les résultats de l ’analyse
 Découverte des diagrammes de classe, d ’activité, de
séquence et d’état
2
Section 1 : Section 2 : UML Section 3 :
Introduction Modélisation
Cours 3
Section 6 : Analyse
Section 4 : Les Section 5 : Les
réalisation des
classes classes d’analyse
cas
Section 7 : Section 8 : Section 9 :

Diagrammes de Diagrammes Diagramme
séquence d’activité d’états-
transitions
3
Cours N° 3
Analyse
Section 1 : Introduction
4
SECTION 1 -
Cours 3 – Analyse INTRODUCTION
L’activité d’analyse
 L’analyse et l’expression de besoins sont très dépendants
 Il y a une ambiguïté entre l’analyse et l’expression de
besoins
 L’analyse permet de clarifier les besoins d ’une manière
détaillée
 Il y a une ambiguïté entre l’analyse et la conception
 L’analyse et la conception répondent à la question
«comment »
 L’analyse se focalise sur l’aspect métier des
fonctionnalités tandis que la conception se focalise sur
l’aspect technique
 Dans UP, le gros de l’analyse se fait durant la phase
d’analyse de besoins et d’élaboration
5
SECTION 1 -
Modèle d’analyse
Classes(Vocabulair
e, aspect statique)
L’analyse Produit
Interactions
(aspect
dynamique)
6
SECTION 1 -
 L’analyse produit un modèle appelé modèle d’analyse

 Le modèle est composé de deux sous -modèles : le
vocabulaire et les interactions
 Le vocabulaire désigne les concepts du domaine. Il
concerne tous les acteurs et entités manipulées par ou
dans le systèmes
 Le vocabulaire ne concerne pas uniquement les concepts
mais aussi les relations entre concepts
 Les interactions représentent les activités impliquant
plusieurs entités ou acteurs (du vocabulaire) afin de
réaliser un objectif métier précis. Généralement, les
interactions détaillent les cas d’utilisation.
7
SECTION 1 -
L’activité d’analyse - Exemple
« à l’ESI, pour effectuer un stage, l’étudiant doit

chercher un encadreur interne ou dans une entreprise
externe et un sujet à réaliser. Une fois le sujet trouvé,
l’étudiant le dépose au niveau du service des stages. Ce
dernier s’occupe de la validation du sujet en faisant
appel à un enseignant de l’ESI ».
8
SECTION 1 -
L’activité d’analyse - Exemple
 Le vocabulaire devra contenir les concepts suivants :

enseignant, étudiant, encadreur, entreprise, sujet, service
de stage et stage
 Il y a plusieurs interactions à souligner :
 l’interaction de recherche de sujet qui implique l’étudiant,
l’entreprise, le sujet et l’encadreur.
 L’interaction de validation qui implique l’étudiant, le
service de stages et l’enseignant.
9
SECTION 1 -
Construire le modèle d ’analyse - Règles
 Se limiter aux concepts métier, s ’éloigner des

considérations techniques
 Le langage du modèle d’analyse utilise le même langage
que le métier
 Le modèle capture une vision globale sur un concept ou
un processus, ne pas aller trop dans le détail
 Le modèle doit toujours être compréhensible et utile au
client
 Plus le modèle est simple, plus il est meilleur
10
SECTION 1 -
Formalisation du modèle d ’analyse
 Le vocabulaire et les interactions peuvent être formalisés

de plusieurs manière (par exemple, en langage naturel)
 UML est un excellent moyen de formaliser le modèle
d’analyse
 Le diagramme de classes et le diagramme d’objets
permettent de formaliser le vocabulaire
 Les diagrammes d’interaction peuvent formaliser les
interactions
11
INTRODUCTI
ON AU
GÉNIE
LOGICIEL
Cours N° 3
Section 2 : UML: Unified Analyse
Modeling language
12
Cours 3 – Analyse SECTION 2 - UML
Unified Modeling Language
 Pourquoi et comment modéliser ?

 Modèle : représentation abstraite et simplifié d’une entité
du monde réel en vue de le décrire, de l’expliquer ou de le
prévoir
 cette représentation peut être sous forme physique,
graphique, mathématique ou verbale.
13
 Pourquoi et comment modéliser ?

 Intérêt "informatique" de la modélisation
 Les modèles aident à visualiser un système existant ou
futur (tel que l’on souhaite qu’il devienne)
 Les modèles permettent de spécifier la structure et le
comportement d’un système
 Les modèles documentent les choix effectués
14
 Langages de modélisation
Un langage de modélisation doit définir :
 La sémantique des concepts ;
 Une notation pour la représentation de concepts ;
 Des règles de construction et d’utilisation des concepts.
15
 Des langages à différents niveaux de formalisation :

 Langages formels (Z,B,VDM) : le plus souvent
mathématiques, au grand pouvoir d’expression et
permettant des preuves formelles sur les spécifications ;
 Langages semi-formels (MERISE, UML...) : le plus
souvent graphiques, au pouvoir d’expression moindre
mais plus faciles d’emploi.
16
 Historique
 1991 : première édition de Modélisation et conception
orientées objet basée sur OMT, Object Modeling Technique,
issue de la R&D de General Electric.
 1994 : James Rumbaugh rejoint Rational et travaille avec Grady
Booch à la fusion des notations OMT et Booch.
 1995 : Ivar Jacobson rejoint Rational et intègre Objectory au
travail d’unification.
 1997 : l’OMG (Object Management Group) accepte UML,
proposé par Rational, comme standard de modélisation objet.
 2001 : révision par l’OMG d’UML 1.
 2004 : adoption d’UML 2.0
17
18
19
Cours N° 3
Analyse
Section 3 : Modélisation
20
SECTION 3 -
Cours 3 – Analyse M O D É L I S AT I O N
Modélisation
 Modélisation par décomposition fonctionnelle descendante

 La forme la plus immédiate pour décrire un travail à
effectuer est de lister les actions à réaliser.
 On découpe une tâche complexe à effectuer en une hiérarchie
d’actions à réaliser de plus en plus simples, petites et
précises (Pour décrire, on utilise le verbe) :
21
SECTION 3 -
Modélisation
 Exemple :
1. Rouler En Voiture :
1. Mettre moteur en marche :
1. Mettre Contact
2. Démarrer Moteur
2. Démarrer Voiture :
1. Mettre Point Mort
2. Passer La Première
3. Embrayer En Accélérant
3. Rouler :
1. Accélérer
2. Freiner
3. Passer Vitesse
22
SECTION 3 -
Modélisation
23
SECTION 3 -
Modélisation
 L’implémentation en code source d ’une solution décrite

en terme d’actions est un code organisé en fonctions
(programmation procédurale) :
24
SECTION 3 -
Modélisation
 Dispersion données/fonctions :
 Lorsque le logiciel évolue, il faut faire évoluer les

structures de données et les fonctions en parallèle
(probablement dans des modules différents).
 Maintenir cette cohérence est laborieuse parce que

données et fonctions sont dispersées.
La dispersion données/fonctions nuit à l ’extensibilité !
25
SECTION 3 -
Modélisation
 Rappelez vous !
 Pour qu’un logiciel soit extensible et réutilisable, il faut
qu’il soit découpé en modules
 faiblement couplés, ainsi chaque entité peut être
modifiée en limitant l’impact du changement au reste de
l’application. Et
 à forte cohésion. Il faut réunir ce qui est impacté par une
même modification (« qui se ressemble s’assemble »)
26
SECTION 3 -
Modélisation
 Comment évaluer la découpe fonctionnelle descendante

et la programmation procédurale en termes de couplage
et cohésion ?
 Séparer données et fonctions sur ces données entraine :

 Un fort couplage par les données,
 Perte de cohésion (par dispersion).
 Le code est donc peu extensible et peu réutilisable !
27
SECTION 3 -
Modélisation
28
SECTION 3 -
Modélisation
 On ne raisonne plus en termes d ’actions mais plutôt en

concepts du monde physique.
 Puisqu’ils appartiennent au monde physique, ces
concepts peuvent être stables et réutilisables.
 On ne raisonne uniquement en verbes, mais davantage en
noms.
29
Cours N° 3
Analyse
Section 4 : Objets et classes
30
SECTION 4 – OBJETS
Cours 3 – Analyse ET CLASSES
L’objet
Etat Comportement Objet
31
L’objet
 Rumbaugh définit l’objet comme étant une entité discrète

ayant une limite bien définie qui possède un état et un
comportement
 Un objet représente une entité du monde réel
 L’état de l’objet est l’ensemble des valeurs de ses
attributs
 Le comportement d’un objet est représenté par les
opérations qu’il peut effectuer. Souvent les opérations
conduisent à un changement de l ’état d’un objet
 L’objet a un identifiant unique qui permet de le
distinguer des autres objets.
32
SECTION42 – OBJETS
L’objet
Etat Comportement
• Numéro de série (Identifiant) • Allumer()
• Marque • Eteindre()
• Modèle • Connecter()
• Allumée • Filmer()
• Mode (Photo / Vidéo) • PrendreUnePhoto()
• Connectée à un ordinateur
• Liste des photos en mémoire
• Capacité
• Photo en cours
33
Notation UML
 Le diagramme qui est utilisé pour la représentation des

objets est le diagramme d’objets
34
Notation UML des objets
Nom de l’instance compteTest :Compte

Cle = 80
Numero = 11256
Attributs Proprietaire = [Mokhtar]
Solde = 150000
35
SECTION 4– OBJETS
Notation UML des objets
 Les noms sont écrits en souligné

 Les noms des objets commencent par une minuscule. Si
c’est un nom composé, le début de chaque mot suivant
commence par une majuscule. Par exemple :
compte11256:Compte ou clientFavori:Client. Le symbole
« : » sépare le nom de l’instance du nom de sa classe.
 Le nom de l’objet peut être anonyme (ne comporte que le
nom de la classe. Par exemple : :Compte ou :Client.
 L’objet peut ne pas avoir de classe : par exemple amine ou
compteTest.
36
Notation UML des objets - Liens
 Un lien lie deux instances entre objets

 L’objet est une instance d’une classe et le lien est une
instance d’une association
37
Notation UML des objets - Liens
Objets
compteTest :Compte
Cle = 80
Numero = 11256
Proprietaire = [Mokhtar]
Solde = 150000
Possède
amine :Personne
Lien
38
Notation UML des objets - Exemple
azouaou :Enseignant
mostefai :Enseignant
Nom = Mostefai
Prenom = Mohammed Amine
igl :Module conduiteDeProj et : mcsi :Module

Annee = 3csc Module
39
Objets – Notation UML - Diagrammes
 Un diagramme d’objets présente des objets et leurs

relations à un instant T
 Le diagramme d’objets est idéal pour donner des
exemples sur des situations particulières
 Les liens bidirectionnels entre A B quand A et B
s’envoient des messages
 Un lien unidirectionnel entre A vers B indique que A
peut envoyer un message vers B mais pas l ’inverse
40
Objets – Notation UML - Diagrammes

Grade
EXEMPLE
EstGradé
Employe
Emploie
*
Departement
1
EstConstituéeDe
Ecole 1
41
Objets – Notation UML - Diagrammes Diagramme
object Pédagogie Nom du diagramme
mca :Grade
Lien Unidirectionnel
cherid :Employe balla :Employe mostefai :Employe
+Directrice Etudes +Responsable CPI +Enseignant
pg :Departement directionDesEtudes :Departement
esi :Ecole
Lien Bidiectionnel Rôle

42
Diagramme d ’objet – Quand l’utiliser ?
 Les diagrammes d’objets sont utilisés pour donner des

exemples sur des situations complexes mettant en
relation plusieurs concepts
 Les diagrammes d’objet sont facultatifs et souvent les

diagrammes de classes sont suffisants pour décrire le
domaine.
43
Les classes
 Rumbaugh définit la classe comme étant un descripteur

d’un ensemble d’objets qui partagent les mêmes
attributs, méthodes, relations et comportement
 La classe est le modèle d’un ensemble d’objets similaires
 Dans l’exemple précédent : Mostefai et Azouaou sont
deux instances de la classe « Enseignant »
 Un objet appartient à une seule classe
 La classe définit la structure d ’un objet (aspect statique)
, son comportement (aspect dynamique) et ses relations
44
Les classes
 Rumbaugh définit la classe comme étant un descripteur

d’un ensemble d’objets qui partagent les mêmes
attributs, méthodes, relations et comportement
 La classe est le modèle d’un ensemble d’objets similaires
 Dans l’exemple précédent : Mostefai et Azouaou sont
deux instances de la classe « Enseignant »
 Un objet appartient à une seule classe
 La classe définit la structure d ’un objet (aspect statique)
, son comportement (aspect dynamique) et ses relations
45
Modélisation orientée objet
Comment classifier ces animaux ? 46

Modélisation orientée objet
 Ce n’est pas facile d’avoir une conception objet du monde

réel
 Les classes résultantes proviennent du point de vue de
travail
 Les classes de l’exemples précédent peuvent être :
(Animal) ou (AnimalTerrestre / AnimalMarin) ou
(AnimalDomestique / AnimalSauvage) ou
(AnimalComestible / AnimalNonComestible) ou (Poisson
/ Mammifière / Crustacé …)
47
Classes et objets
 L’objet instancie la classe

 UML définit l’instanciation comme une relation de
dépendance avec le stéréotype « instantiate »
48
Classes et objets
Module
- Annee: string
- AssurePar: Enseignant
- Nom: string
«instantiate» «instantiate» «instantiate»
mcsi :Module igl :Module conduiteDeProj et :

Module
Annee = 3csc
49
Classes – Notation UML
Stéréotype
«entity»
Nom de la classe Compte
- cle: string
- numero: string
Attributs - proprietaire: Personne
- solde: double = 0
Opérations + retirer(double) : boolean

+ verser(double) : boolean
tags
Métadonnées Auteur = Amine
Date = Octobre 2011
50
Classes – Notation UML - Nom
 De préférence, utiliser la convention UpperCamelCase. Le

nom de classe est en minuscules et la première lettre en
majuscules. Si le nom de la classe est composite, le nom
de chaque mot composant est en minuscule et la
première lettre en majuscule. Par exemple : Agent,
Compte, LigneFacture, MandatPostalValide.
 Eviter les abbrévitiations : par exemple utiliser
FactureValideDetaillee au lieu de FactureVD.
 Ne pas utiliser des noms verbaux car les classes
représentent des « choses ».
51
Classes – Notation UML - Visibilité
 La visibilité s’applique aussi bien aux attributs qu ’aux

opérations
 Durant la phase d’analyse, la visibilité n’est pas
importante
 Les langages de programmation peuvent avoir une
interprétation différente de la visibilité
52
Classes – Notation UML - Visibilité
 Le tableau suivant liste les visibilités utilisées dans UML

Visibilité Nom Description
+ Visibilité Accès depuis la même classe et à l’extérieur de

publique la classe
- Visibilité privée Accès depuis la même classe uniquement
# Visibilité Accès depuis la même classe et les classes

protégée descendantes
~ Visibilité paquet Accès depuis la même classe et toutes les
classes appartenant au même paquet
53
Classes – Notation UML - Types
 Le type peut être un type défini par UML ou l ’un des

types suivants : boolean, byte, char, double, float, int,
long, short
54
Classes – Notation UML - Attributs
 Les attributs sont formulés en utilisant la syntaxe

suivante :
Visibilité Nom_Attribut : type [multiplicité] = valeur_initiale
55
 Le type peut être un type défini par UML ou l ’un des

types suivants : boolean, byte, char, double, float, int,
long, short
 La valeur initiale indique la valeur de l ’attribut quand
une instance de la classe est créée
 Un attribut est dit statique s ’il appartient à la classe, pas
à une instance en particulier. Les attributs statiques sont
noté en souligné.
56
C l a s s e s – N o t a t i o n U M L – At t r i b u t s , m u l t i p l i c i té
 La multiplicité indique les attributs multiples.

 Les multiplicités sont équivalentes aux tableaux mais ont
plus de sémantique.
 Exemple 1 : int valeurs[7]. La classe contient exactement
7 valeurs.
 Exemple 2 : int valeurs[2..*] : la classe contient au moins
2 valeurs.
 Exemple 3 : int valeurs[2..7] la classe contient au
minimum 2 valeurs et au maximum 7 valeurs.
 Exemple 4 : int valeurs [0..1] la classe contient une
valeur ou null.
57
EXEMPLE
Etudiant
+ matricule : int
# nom : string
# prenom : string
~modules : int [2..9]
- age :int = 18
- chambreAffectee : Chambre [0..1]
+ tuteursDeSuivi : Tuteur [2]
+ nombreEtudiants : int
+ inscriptions : Inscription [1..*]
58
Classes – Notation UML - Opérations
 Les opérations sont formulés en utilisant la syntaxe

suivante :
Visibilité Nom_Operation (direction nom_paramètre:

type = valeur_défaut,….) : type_retour
59
 Les opérations sont nommées en utilisant une formulation

lowerCamelCase
 De préférence, utiliser des expressions verbales pour les
opérations
 Les paramètres sont nommés en utilisant lowerCamelCase
 Ne pas utiliser des expressions verbales pour les paramètres
 Des valeurs par défaut peuvent être renseignées pour une
opération.
 Les opérations statiques sont soulignées
60
DIRECTION DES PARAMÈTRES

Direction Description
in p Le paramètre p est un paramètre d’entrée. p est utilisé par

l’opération mais n’est pas modifié par l’opération.
inout p Le paramètre p est un paramètre d’entrée / sortie. p est utilisé
par l’opération et sa valeur peut être changée par l’opération.
out p Le paramètre p est un paramètre de sortie. La valeur de p
pourrait être modifiée par l’opération.
return p Le paramètre p est un paramètre de retour. L’opération doit
retourner la valeur de p.
61
EXEMPLE
Compte
+ verser(montant :double, soldeApres :double*) : void

+ retirer(montantOperation :double, soldeApres :double*) : void
~ caclulerCharges(tauxCalcul :double) : double
62
Classes – Notation UML - Stéréotypes
 Les stéréotypes représentent un mécanisme pouvant

étendre UML
 Un stéréotype peut cibler une classe, un attribut ou une
opération
 Plusieurs dizaines de stéréotypes sont utilisés mais les
plus connus sont : actor, boundary, entity et control.
 Le stéréotype « acteur » représente un acteur
 Le stéréotype « entity » représente une entité. Une entité
est un concept métier, par exemple
« Compte », « Client », « Fournisseur »,…
63
 Le stéréotype « control » représente un contrôleur. Un

contrôleur est un intermédiaire entre les limites et les
entités. Le contrôleur se charge de l ’exécution des
commandes provenant de la limite.
 Le stéréotype « boundary » représente une limite du
système qui s’interface avec l’acteur. Par exemple,
interface utilisateur.
64
InterfaceWeb GestionnaireCommandes Commande Utilisateur
«control»
«entity» «actor»
«boundary» GestionnaireCommandes
InterfaceWeb Commande Utilisateur
65
Commande LigneCommande Produit Client
GestionnaireCommandes
InterfaceWeb
Utilisateur 66
Classes – Notation UML - Associations
 Une association est une relation entre deux classes

 Une association entre deux classes se traduit par un lien
entre deux instances de ces classes
 Une association décrit une relation qui a une
sémantique entre les deux classes
 Une association peut être entre une classe et elle -même.
L’association est dite réflexive.
 La direction détermine la navigation d’un objet vers un
autre.
67
EXEMPLE
Enseignant Enseigne Module
* *
«instantiate» «instantiate»
Mostefai :Enseignant IGL :Module
68

Direction
Nom de l’association
Employe Module
Enseigne
* *
Multiplicité
69
Societe +Employeur +Employé Personne
1 *
Rôle
70
NOMS DES ASSOCIATIONS

 Utiliser des phrases verbales
 Il n’est pas recommandé d’utiliser les noms et les rôles.
Utiliser soit le nom soit le rôle.
 Donner des noms explicites et lisibles.
71
MULTIPLICITÉ
Multiplicité Signification
0..1 Zéro ou 1
1 Exactement 1
0..* Zéro ou plusieurs
* Zéro ou plusieurs
1..* 1 ou plusieurs
1..9 1à9
9 Exactement 9
1.5, 8, 20..* 1 à 5, exactement 8 ou plus de 20
72
MULTIPLICITÉ
 La multiplicité détermine le nombre d ’objets impliqué
dans une association à un instant T
73
MULTIPLICITÉ – EXEMPLE 1
Une voiture possède exactement 4 pneus
Voiture Pneu
1 4
Un pneu appartient à exactement une voiture
74
Une société peut avoir 0, 1 ou plusieurs employés
Société Employe
1 *
Un employé est employé par exactement 1 société
75
Une société doit avoir au moins un employé
Société Employe
0..1 1..*
Un employé peut être employé dans une seule société ou aucune
76
Une société peut avoir plusieurs employés (ou zéro)
Société Employe
1..* *
Un employé peut être employé dans au moins une société
77
Université Enseignant
Emploie
1 *
1 1
AssurerCours AssurerTD
0..3 0..4
Module
78
Un employé a un ou 0 supérieur
Employe
+Subordonnes 0..*
+Superieur 0..1
Un employé peut avoir 0 ou plusieurs subordonnés
79
Un employé a un ou 0 supérieur
Employe
+Subordonnes 0..*
+Superieur 0..1
Un employé peut avoir 0 ou plusieurs subordonnés
80
koudil :Employe
balla :Employe
mostefai :Employe batata :Employe azouaou :Employe
81
Navigation – Exemple 1
Société vers Employé est navigable
Societe Employe
1 *
Employé vers Société est navigable
82
Employé vers Grade est navigable
Employe Grade
* 1
Grade vers Employé n’est pas navigable
83
Employé vers Grade est navigable
Employe Grade
*
X 1
Grade vers Employé n’est pas navigable
84
Société vers Employé est navigable
Societe Employe
1 *
Employé vers Société est navigable
85
Associations et attributs
 Les attributs peuvent être un autre moyen de représenter
une association
 Les associations à multiplicité multiple peuvent être
représentées par des tableaux ou des collections
 Lors de la génération de code, les associations sont
générées en tant qu’attributs
86
Associations et attributs – Exemple 1

Employe
+ grade: Grade
Employe Grade
* 1
Grade
87
Associations et attributs – Exemple Employe

+ grade: Grade
Employe +grade Grade + societe: Societe
* 1
+employes *
Grade
+societe 1
Societe
Societe
+ employes: Employe [0..*]
88
public class Adresse {...}

public class Client {
private Adresse livraison ;
public void setAdresse ( Adresse adresse ){
this.livraison = adresse ;
}
public Adresse getAdresse (){
return livraison ;
}
}
89
public class Client {

Adresse facturation ;
public void setAdresse ( Adresse uneAdresse ){
if( uneAdresse != null ){
this.facturation = uneAdresse ;
facturation.client = this ; // correspondance
}
}
}
public class Adresse {
Client client ;
public void setClient ( Client unClient ){
this.client = client ;
client.facturation = this ; // correspondance
}
}
90
public class Commentaire {...}

public class Article {
private ArrayList avisInternaute = new
ArrayList();
public void addCommentaire(Commentaire
commentaire){
avisInternaute.addElement (commentaire );
}
public void removeCommentaire(Commentaire
commentaire){
avisInternaute.removeElement (commentaire );
}
}
91
Classes d’association
 Parfois, quand il y a une association entre deux classes,
l’attribut ne peut être dans aucune des classes.
 Exemple ci-dessous : où mettre la note ?
Etudiant Module
* *
92
Classes d’association
 Les classes d’association sont de vraies classes qui
peuvent avoir des attributs, opérations et même d ’autres
opérations
Etudiant Module
* *
Note
+ valeur: double
93
Classes d’association - Exemple
Etudiant Module
* *
Note Enseignant
+ valeur: double
* *
94
Cours 3 – Analyse SECTION 4 – OBJETS
ET CLASSES
Associations n-aires
 Une association n-aire lie plus de deux classes.

 Notation avec un losange central pouvant éventuellement
accueillir une classe-association.
 La multiplicité de chaque classe s'applique à une instance du
losange.
 Les associations n-aires sont peu fréquentes et concernent

surtout les cas où les multiplicités sont toutes « * » . Dans la
plupart des cas, on utilisera plus avantageusement des
classes-association ou plusieurs relations binaires.
95
ET CLASSES
Associations Qualifiée
 L’association entre deux classes donne peu d ’indications sur

l’implication effective des classes dans la relation, ce qui rend
la modélisation imprécise. Cette imprécision concerne, en
particulier, la multiplicité d ’une extrémité de l’association
et/ou la portée de l’association par rapport aux classes
associées.
 La qualification d’une association permet, dans certains cas,
de transformer une multiplicité indéterminée ou infinie en une
multiplicité finie.
 Changement de multiplicité avec un qualificateur
 Qualification d’une association pour limiter son impact sur

les classes associées
96
ET CLASSES
Association de type agrégation
 Une agrégation est une forme particulière

d'association. Elle représente la relation
d'inclusion d'un élément dans un ensemble.
 Onreprésente l'agrégation par l'ajout d'un

losange vide du côté de l'agrégat.
Une agrégation dénote une relation d'un

ensemble à ses parties. L'ensemble est
l'agrégat et la partie l'agrégé.
97
ET CLASSES
Association de type composition
• La relation de composition décrit une contenance structurelle

entre instances. On utilise un losange plein.
• La destruction et la copie de l'objet composite (l'ensemble)

impliquent respectivement la destruction ou la copie de ses
composants (les parties).
• Une instance de la partie n'appartient jamais à plus d'une
instance de l'élément composite.
98
ET CLASSES
Composition et agrégation
 Dès lors que l'on a une relation du tout à sa partie, on a une

relation d'agrégation ou de composition.
 La composition est aussi dite agrégation forte .
 Pour décider de mettre une composition plutôt qu'une
agrégation, on doit se poser les questions suivantes :
Est-ce que la destruction de l'objet composite (du tout)

implique nécessairement la destruction des objets
composants (les parties) ? C'est le cas si les composants
n'ont pas d'autonomie vis -à-vis des composites.
Lorsque l'on copie le composite, doit -on aussi copier les

composants, ou est-ce qu'on peut les réutiliser , auquel cas
un composant peut faire partie de plusieurs composites ?
• Si on répond par l'affirmative à ces deux questions, on doit

utiliser une composition.
99
Classes – Notation UML - Dépendance
 En plus des associations, les classes peuvent être liées

par des relation de dépendance
 Plusieurs cas peuvent induire à une dépendance entre
une classe A et une classe B : A manipule B dans une
opération, B est un paramètre dans une opération de A, B
est le type de retour d’une opération, A appelle une
méthode B, …etc.
 La dépendance n’est pas réservée aux classes, elle peut
être utilisée avec les paquets et les cas d’utilisation
100
Classes – Notation UML - Dépendance
101
Classes – Notation UML Reflexive
 L'association la plus utilisée est l'association binaire

(reliant deux classes).
 Parfois, les deux extrémités de l'association pointent vers
le même classeur. Dans ce cas, l'association est dite
« réflexive » .
102
Classes – Notation UML - Héritage
 L’héritage est une relation entre une classe générale et

une classe plus spécifique
 Entre les deux, une relation de substitution : on peut
substituer toute utilisation de l’élément général par
l’élément plus spécifique
 L’héritage est symbolisé par le lien de généralisation
 La classe spécialisée hérite de tous les attributs et les
opérations de la classe parente
103
EXEMPLE 1
Engin
+ marque: string
+ modele: string
Généralisation
+ getPoids() : double
Voiture Camion Bus

+ nombrePlaces: int
VoitureTouristique VoitureUtilitaire
+ chargeUtile: double
104
 Parfois une classe ne peut exister que par l ’existence des

classes descendantes
 Une classe peut aussi déférer l ’implémentation d’une
opération à ses classes descendantes
 Une opération qui est sans implémentation dans la classe
actuelle est une opération abstraite
 Une classe qui contient une ou plusieurs opérations
abstraites est dite classe abstraite
105
LE POLYMORPHISME
 Une opération polymorphique est une opération qui
possède plusieurs implémentations
 Par exemple, n’importe quel compte accepte les retraits
et les versements. Par contre, les comptes entreprises ont
un comportement différent des comptes particuliers. Les
comptes entreprises acceptent les soldes négatifs.
106
EXEMPLE – Polymorphisme
Compte
+ Verser() : void
+ Retirer() : void
CompteParticulier CompteEntreprise
+ Verser() : void + Verser() : void

+ Retirer() : void + Retirer() : void
107
• Une classe enfant peut redéfinir (même signature) une ou

plusieurs méthodes de la classe parent.
– Sauf indications contraires, un objet utilise les opérations les
plus spécialisées dans la hiérarchie des classes.
– La surcharge d'opérations (même nom, mais signatures des
opérations différentes) est possible dans toutes les classes.
• Toutes les associations de la classe parent s'appliquent, par
défaut, aux classes dérivées (classes enfant).
• Principe de substitution : une instance d'une classe peut être
utilisée partout où une instance de sa classe parent est attendue.
– Par exemple, toute opération acceptant un objet d'une classe
Animal doit accepter tout objet de la classe Chat (l'inverse
n'est pas toujours vrai)
108
Méthodes abstraites
EXEMPLE – Classes abstraites
Photo
+ points: Point [1..*]
Méthodes concrètes
+ getNombrePoints() : int
+ Dessiner() : void
+ getTaille() : int
PhotoJPEG PhotoPNG PhotoTIFF

+ Dessiner() : void + Dessiner() : void + Dessiner() : void
+ getTaille() : int + getTaille() : int + getTaille() : int
109
Héritage multiple
• Une classe peut avoir plusieurs classes parents. On parle alors

d'héritage multiple.
• Le langage C++ est un des langages objet permettant son
implantation effective.
• Java ne le permet pas .
110
Interface
• Le rôle d'une interface est de regrouper un ensemble

d'opérations assurant un service cohérent offert par un
classeur et une classe en particulier.
• Une interface est définie comme une classe, avec les mêmes
compartiments. On ajoute le stéréotype interface avant le nom
de l'interface.
• On utilise une relation de type réalisation entre une interface
et une classe qui l'implémente.
• Les classes implémentant une interface doivent implémenter

toutes les opérations décrites dans l'interface
111
Interface
• Quand une classe dépend d'une interface (interface requise)

pour réaliser ses opérations, elle est dite « classe cliente de
l'interface »
• On utilise une relation de dépendance entre la classe cliente et
l'interface requise. Toute classe implémentant l'interface
pourra être utilisée.
112
Exemple d’Interface
113
Eléments dérivés
• Les attributs dérivés peuvent être calculés à partir

d'autres attributs et des formules de calcul.
– Les attributs dérivés sont symbolisés par l'ajout d'un

« / » devant leur nom.
– Lors de la conception, un attribut dérivé peut être
utilisé comme marqueur jusqu'à ce que vous puissiez
déterminer les règles à lui appliquer.
• Une association dérivée est conditionnée ou peut être
déduite à partir d'autres autres associations. On utilise
également le symbole « / » .
114
Paquets
QU’EST-CE QU’UN PAQUET ?

 Un paquet UML est un élément de groupage qui contient
plusieurs éléments UML dont éventuellement d ’autres
paquets
 Les paquets servent à organiser les éléments UML
 Les paquets définissent des « frontières sémantiques »
du modèle
 Chaque élément UML appartient à exactement un paquet.
Les éléments de haut niveau appartiennent à un paquet
implicite appelé « root » ou « topLevel »
115
Paquets – Notation UML
Paquet
116
Paquets – Notation UML
117
Paquets – Espaces de noms
 Le paquet définit une frontière où les noms des éléments

doivent être uniques
 Si un élément doit référer à un autre élément se trouvant
dans un autre paquet, il doit utiliser un « nom qualifié ».
 Le nom qualifié se fait en préfixant le nom de l ’élément
par les noms des paquets qui le contiennent
 Par exemple, si un paquet P1 contient un sous-paquet P2
contenant une classe C1, le nom qualifié de C1 est
P1:P2:C1.
118
Paquets – Dépendance
 Un paquet P1 dépend de P2 si un élément de P1 utilise

d’une manière ou d’une autre un élément de P2
119
Commun::Personne
Employe
120
121
Attributs de classe
• Par défaut, les valeurs des attributs dé finis dans une

classe diffèrent d'un objet à un autre. Parfois, il est
nécessaire de définir un attribut de classe qui garde une
valeur unique et partagée par toutes les instances.
• Graphiquement, un attribut de classe est souligné
122
Opérations de classe
• Semblable aux attributs de classe
– Une opération de classe est une propriété de la classe,

et non de ses instances.
– Elle n'a pas accès aux attributs des objets de la classe
123
Classe paramétrée
• Pour définir une classe générique et paramétrable en
fonction de valeurs et/ou de types :
• Définition d'une classe paramétrée par des éléments
spécifiés dans un rectangle en pointillés ;
• Utilisation d'une dépendance stéréotypée « bind» pour
définir des classes en fonction de la classe paramétrée.
Java5 :
généricité
C++ :
templates
124
Construction d'un diagramme de classes
• On peut utiliser les diagrammes de classes pour

représenter un système à différents niveaux d'abstraction :
– Le point de vue spécification met l'accent sur les
interfaces des classes plutôt que sur leurs contenus.
– Le point de vue conceptuel capture les concepts du
domaine et les liens qui les lient. Il s'intéresse peu ou
peu à la manière éventuelle d'implémenter ces concepts
et relations et aux langages d'implantation.
– Le point de vue implantation, le plus courant, détaille le
contenu et l'implantation de chaque classe.
• Les diagrammes de classes s'étoffent à mesure qu'on va de
hauts niveaux à de bas niveaux d'abstraction (de la
spécification vers l'implantation)
125
Construction d'un diagramme de classes
1. Trouver les classes du domaine étudié ;

– Souvent, concepts et substantifs du domaine.
2. Trouver les associations entre classes ;
– Souvent, verbes mettant en relation plusieurs
classes.
3. Trouver les attributs des classes ;
– Souvent, substantifs correspondant à un niveau de
granularité plus n que les classes. Les adjectifs et les
valeurs correspondent souvent à des valeurs
d'attributs.
4. 4 Organiser et simplifier le modèle en utilisant
l'héritage ;
5. Tester les chemins d'accès aux classées ;
6. Itérer et raffiner le modèle.
126
Cours N° 3
Analyse
Section 5 : Classes d’analyse
127
SECTION 5 –CLASSES
Cours 3 – Analyse D ’A N A LY S E
Les classes d ’analyse
 Les classes d’analyse sont les classes découvertes durant

l’activité d’analyse
 Les classes d’analyse correspondent à des concepts
« réels »
 L’analyse fait ressortir les éléments suivants d ’une classe :
Nom, Attributs les plus importants, Opérations les plus
importantes, stéréotypes (non techniques)
 Les éléments suivants ne sont pas importants dans
l’analyse : métadonnées, paramètres des opérations,
visibilité
128
SECTION 5 – CLASSES
Sources de recensement
Modèle de Modèle des cas

spécifications d’utilisation
Toute autre source

d’information
relative au
domaine
129
Représentation d ’une classe d ’analyse
 Les classes d’analyse sont représentés en utilisant le

diagramme des classes
 L’ensemble des classes sont appelés « vocabulaire »,
« glossaire métier » ou « taxonomie du domaine »
 Les classes d’analyse sont une représentation de haut
niveau : elles sont caractérisées par un nom, des attributs
et éventuellement des opérations.
 Le nom de la classe est obligatoire.
 Les noms des attributs sont obligatoires. Leurs types
facultatifs.
 Les paramètres et les types de retour des opérations ne
sont montrés que s’ils apportent une compréhension au
système
130
 La visibilité est généralement omise

 Les stéréotypes ne sont montrés que s’ils augmentent la
représentativité
 Les métadonnées ne sont montrés que s’ils augmentent
la représentativité
131
EXEMPLE
Compte
numero
proprietaire
solde
verser()
retirer()
132
CARACTÉRISTIQUES D’UNE BONNE CLASSE D’ANALYSE

 Son nom reflète son objectif
 C’est une abstraction d’un élément clairement
identifiable dans le domaine
 A un ensemble limité et clair de responsabilités
 A une grosse cohésion
 A un faible couplage
133
Techniques de recensement
Technique Technique
des noms / des
verbes stéréotypes
134
Technique des noms / verbes
 Technique simple qui analyse du texte pour trouver des

classes, des attributs et des opérations
 Les noms et les phrases nominales représentent les
classes et les attributs
 Les verbes et les phrases verbales représentent les
opérations
 Difficultés avec les termes difficiles, les synonymes et les
homonymes
 Difficulté à trouver les classes « cachées »
 S’il y a des termes qui ne sont pas compris, voir avec les
experts du domaine
135
Technique des noms / verbes
Collecte d’information Analyse des

• Spécifications formelles informations
• Cas d’utilisation • Noms et phrases
• … nominales
• Verbes et phrases verbales
136
Technique des noms / verbes - Exemple
Spécifications
Le système doit permettre à
Noms
l’utilisateur de consulter le
solde de son compte Système
Verbes
Le système doit permettre à Compte
Verser
l’utilisateur de verser de Utilisateur
l’argent dans son compte Retirer
Argent
Le système doit permettre à Consulter
l’utilisateur de retirer
l’argent de son compte
137
Technique des noms / verbes - Exemple
Compte
+ solde: double
+ verser(double) : void
+ retirer(double) : void
+ consulter() : double
«Actor»
Utilisateur
138
Technique des stéréotypes
 Cette technique se concentre sur trois stéréotypes :

« boundary », « entity » et « control »
 Cette technique est complémentaire avec la technique
des verbes / noms
139
Technique des stéréotypes
Trouver les
Trouver les Trouver les
limites
contrôleurs entités
(boundary)
140
Technique des stéréotypes - Limites
 Les classes « boundary » représentent les limites du

système
 Ces classes communiquent avec les acteurs
 Trois types de classes « boundary » : classes d’interface
utilisateur, classes qui s’interfacent avec d’autres
systèmes et des classes qui s’interfacent avec un
matériel externe (périphérique,…)
 Ces classes doivent rester de haut niveau (ne pas
s’occuper des détails)
141
Technique des stéréotypes - Contrôleurs
 Les contrôleurs sont responsable de la coordination des

action permettant d’accomplir un cas d’utilisation
 Si un contrôleur est trop compliqué, il est suggéré de le
diviser en plusieurs contrôleurs
142
Technique des stéréotypes - Entités
 Représentent les concepts manipulés par le système

 Utilisés par plusieurs cas d’utilisation et plusieurs
contrôleurs
 Ces classes sont souvent persistantes (enregistrées dans
des fichiers ou des BDD)
143
Technique des stéréotypes - Exemple
1. Le système doit permettre à l’utilisateur de s’inscrire

2. Le système doit permettre à l’utilisateur connecté de
consulter les formations assurés, leurs dates et les
formateurs associés
3. Le système doit envoyer un message mensuellement qui
avertit les utilisateurs inscrits des nouvelles formations
144
Technique des stéréotypes - Exemple
Acteurs Entités Contrôleurs Limites
InscriptionManager
Formation
Utilisateur
InterfaceInscription
NotificationManager
Formateur
145
Paquets d’analyse
 Les classes d’analyse sont regroupées dans des « paquets

d’analyse »
 Les classes se trouvant dans le même paquet sont des
classes ayant un certain lien sémantique
 Un bon regroupement des paquets produit une haute
« cohésion » à l’intérieur d’un paquet et un faible
« couplage » entre paquets
146
Paquets d’analyse - Exemple
147
Cours N° 3
Analyse
Section 6 : Interactions
148
SECTION 6 –
Cours 3 – Analyse INTERACTIONS
Introduction
 Les classes d’analyse représentent la structure statique

du système
 Les interactions expriment comment les instances de ces
classes interagissent pour réaliser une fonction du
système
 Les interactions expriment l’aspect dynamique du
système
149
SECTION 6 –
Cours 3 – Analyse INTERACTIONS
Objectifs des interactions
 Trouver quelles classes qui interagissent pour un cas

d’utilisation donné
 Trouver les messages envoyés entre les classes pour
réaliser un certain comportement (attributs, opérations,
relations)
 Eventuellement, mettre à jour les modèles de besoins et
d’analyse
 Ne pas créer d’interactions pour tous les cas d ’utilisation,
Uniquement pour les CUs les plus importants et les plus
complexes
150
SECTION 6 –
Cours 3 – Analyse R É A L I S AT I O N D E S C A S
D ’ U T I L I S AT I O N
Diagrammes comportementaux
 Les diagrammes comportementaux est la meilleure

façon de représenter les interactions
 Les diagrammes de séquence illustrent une séquence de
messages ordonnée dans le temps
 Le diagramme de communication décrit les relations
entre objets dans un contexte donné
 Le diagramme d’activité décrit le flux d’actions menant
à la réalisation d’une fonction métier
 Le diagramme d’état démontre le changement d’état
d’une entité dans le temps
151
COURS IGL
Cours N° 3
Section 7 : Diagrammes de Analyse
séquence
152
SECTION 7 –
Cours 3 – Analyse DIAGRAMMES DE
SÉQUENCE
Présentation
 Les diagrammes de séquence (DSQ) décrivent une action

ordonnée dans le temps
 Les DSQ document les CU et font partie du modèle
d’analyse
 Les DSQ sont composés de trois concepts principaux : les
lignes de vie, les messages et les fragments
153
SECTION 7 –
SÉQUENCE
Lignes de vie
 Une ligne de vie représente un seul participant dans une

interaction
 Une ligne de vie peut représenter un objet, une instance
d’une classe ou un acteur
 Pour représenter une interaction, des messages lient les
lignes de vie
154
SECTION 7 –
SÉQUENCE
Lignes de vie – Représentation UML
Objet :Employe
Utilisateur
155
SECTION 7 –
SÉQUENCE
Messages
 Un message représente une communication entre deux

lignes de vie durant une interaction
 Un message peut s’agir de l’appel d’une opération
 Un message peut s’agir de la création ou de la
destruction d’instance
 Un message peut s’agir d’envoi d’un signal
 Quand une ligne de vie reçoit un message, ça correspond
généralement à l’appel d’une opération ayant la même
signature
 Quand une ligne de vie reçoit un message, elle obtient
sont activation. L’activation change de ligne de vie à
travers le temps.
156
SECTION 7 –
SÉQUENCE
Messages
Type de message Description
Message synchrone L’émetteur attend que le récepteur termine l’opération

pour passer à l’étape suivante
Message asynchrone L’émetteur envoie le message puis continue son
exécution sans attendre la fin chez le récepteur
Message de retour L’émetteur récupère l’activation suite à l’avoir perdu en
envoyant un message au destinataire
Message de création Le message provoque la création du destinataire
Message de destruction Le message provoque la destruction du destinataire
Message found L’émetteur de ce message ne fait pas partie de

l’interaction.
Message lost Le destinataire ne reçoit jamais ce message. Peut
indiquer des situation d’erreur. 157
SECTION 7 –
SÉQUENCE
Messages
158
SECTION 7 –
SÉQUENCE
Messages
LV1 LV2
Message
Synchrone
MessageSynchrone(P1, P2, P3)
Message de
retour
MessageRetour()
Message
Asynchrone MessageAsynchrone(P4, P5)
Activation
159
SECTION 7 –
SÉQUENCE
Messages
LV
Message De
Création
object:Classe
AppelOperation()
Message De
Destruction
Suppression()
160
SECTION 7 –
SÉQUENCE
Messages
LV1 LV2
Message Found
AppelExterne()
Appel()
Message Lost
AppelPerdu()
161
SECTION 7 –
SÉQUENCE
DSQ - Exemple
AppliquerUnEffet
Utilisateur AjouterUnAlbum
ConsulterUnAlbum
DupliquerAlbum
162
SECTION 7 –
SÉQUENCE
DSQ - Exemple
MiseAjourStatistiqueAlbums
Temps
163
SECTION 7 –
SÉQUENCE
DSQ - Exemple
«actor»
Utilisateur
Album
1 *
Photo
AlbumManager
InterfaceAlbums
StatManager
164
SECTION 7 –
SÉQUENCE
Diagrammes de séquences - Exemple
CU: AppliquerUnEffet
ID: 1
Description brève : Appliquer un effet spécial à une photo d’un album. Chaque effet est identifié
par un numéro.
Acteurs primaires : Utilisateurs
Acteurs secondaires : Aucun
Préconditions : le client doit être authentifié
Enchaînement principal
1. L’utilisateur sélectionne un album
2. L’utilisateur sélectionne la photo désirée de l’album
3. L’utilisateur applique l’effet désiré en indiquant son numéro.
Postconditions :
Enchaînement s alternatifs :
165
SECTION 7 –
SÉQUENCE
DSQ – Appliquer un effet

Lignes de vie
:Album :Photo
Utilisateur
AlbumManager
getAlbum(id:int)
:Album Activation
getPhoto(idPhoto :int) :Photo
:Photo
appliquerEffet(idEffet :int)
Messages
166
SECTION 7 –
SÉQUENCE
DSQ – Appliquer un effet
:Album :Photo
Utilisateur
AlbumManager
getAlbum(id:int)
:Album
getPhoto(idPhoto :int) :Photo
:Photo
appliquerEffet(idEffet :int)
167
SECTION 7 –
SÉQUENCE
DSQ – Ajouter un album
CU: AjouterUnAlbum
ID: 2
Description brève : Création d’un nouvel album par l’utilisateur
1. Le CU démarre quand l’utilisateur clique sur le bouton « nouveau »
2. L’utilisateur donne un nom à l’album
3. L’utilisateur enregistre l’album
Postconditions :
168
SECTION 7 –
SÉQUENCE
DSQ – Ajouter un album
Utilisateur
AlbumManager
ajouterAlbum() :Album
:Album
:Album
renommer(String)
enregistrerAlbum(Album)
169
SECTION 7 –
SÉQUENCE
DSQ – Consulter un album
CU: Consulter un album

ID: 3
Description brève : L’utilisateur consulte un album et les photos qui le composent
1. Le CU démarre quand l’utilisateur clique sur l’album sélectionné
2. L’album adapte son affichage selon la résolution
3. L’album affiche les photos le composant selon la résolution
Postconditions :
170
SECTION 7 –
SÉQUENCE
:Album
Utilisateur
InterfaceAlbums AlbumManager
clic(album :Album)
getAlbum(id :int) :Album

Activations
:Album réflexives
getResolution() :int
afficher(resolution :int)
adapter(resolution :int)
171
SECTION 7 –
SÉQUENCE
:Album
Utilisateur
InterfaceAlbums AlbumManager
clic(album :Album)
getAlbum(id :int) :Album
:Album
getResolution() :int
afficher(resolution :int)
adapter(resolution :int)
172
SECTION 7 –
SÉQUENCE
Fragments
 Un DSQ peut être composé de plusieurs fragments

 Un fragment est caractérisé par un nom
 Un fragment peut contenir un ou plusieurs messages
 Un fragment est composé d’un opérateur et de un ou
plusieurs opérandes
 L’opérateur décide comment les opérandes sont
exécutées
 Un fragment peut être caractérisé par une ou plusieurs
conditions
 Les fragments peuvent être imbriqués
173
SECTION 7 –
SÉQUENCE
Fragments – Opérateurs
Opérateurs Nom Description
opt optionnel L’opérande n’est exécutée que si la

condition est vérifiée
alt Alternatives Plusieurs alternatives. Uniquement
l’opérande dont la condition est vérifiée
s’exécute
loop Itération Itère l’ exécution tant que la condition est
vérifiée
ref Référence Réfère à une autre interaction
174
SECTION 7 –
SÉQUENCE
DSQ – Dupliquer un album
CU: DupliquerUnAlbum
ID: 4
Description brève : L’utilisateur crée un nouvel album portant le même nom et contenant les
mêmes photos
1. Le CU démarre quand l’utilisateur clique sur le bouton dupliquer
2. Le système crée un nouvel album
3. Le système donne le même nom au nouvel album
4. Si l’album original contient des photos et s’il n’est pas verrouillé
4.1 Copier les photos de l’album original vers la copie
Postconditions :
175
SECTION 7 –
SÉQUENCE
original :Album
Nom
Utilisateur
AlbumManager
dupliquerAlbum(int)
getAlbum(int) :
Opérateur Album Fragment
getPhotos() :Photo[*]
liste= :Photo[*]
Copie :Album
Condition
renommer(String)
opt Copier
Opérande [Si liste n'est pas vide est si l'album n'est pas verrouillé]
copierPhotos(liste)
176
SECTION 7 –
SÉQUENCE
original :Album
Utilisateur
AlbumManager
dupliquerAlbum(int)
getAlbum(int) :
Album
getPhotos() :Photo[*]
liste= :Photo[*]
Copie :Album
renommer(String)
opt Copier
[Si liste n'est pas vide est si l'album n'est pas verrouillé]
copierPhotos(liste)
177
SECTION 7 –
SÉQUENCE
DSQ – MA J Statistiques Album
CU: MAJ statistiques

ID: 5
Description brève : Chaque jour, des statistiques sont mises à jour pour tous les albums. Si
l’album est public, on prend le nombre de visite et les miniatures sinon on prend uniquement le
nombre de visites.
1. Le CU démarre chaque fin de journée
2. Le système récupère la liste des albums
3. Pour chaque album
3.1 si l’album est public,
3.1.1 prendre le nombre de visites et les miniatures
3.2 sinon
3.1.2 prendre le nombre de visites
Postconditions :
178
SECTION 7 –
SÉQUENCE
DSQ – MA J Statistiques Album
:Album
StatManager AlbumManager
getAllAlbums() :Album[*]
:Album[*]
loop iterationAlbums
[pour chaque album]
alt albumCond
[Album public]
getNombreVisites() :int
getMiniatures() :Photo[*]
[Album privé]
getNombreVisites() :int
179
SECTION 7 –
SÉQUENCE
DSQ – Exemple
«actor»
Utilisateur
Album
+ getPhoto(int) : Photo
+ renommer(String) : void
+ afficher(int) : void
+ adapter(int) : void
+ getPhotos() : Photo[*]
+ copierPhotos(Photo[*]) : void
+ getNombreVisites() : int *
1
+ getMiniatures() : Photo[*]
Photo
AlbumManager + appliquerEffet(int) : void
InterfaceAlbums
StatManager
180
SECTION 7 –
SÉQUENCE
Messages
SECTION 7 –
SÉQUENCE
Messages
class C {
class B { op2 (p: Type ){
C c; ...
op1 (p: Type ){ }
c. op2 (p); op3 (){
c. op3 (); ...
} }
} }
SECTION 7 –
SÉQUENCE
Messages
SECTION 7 –
SÉQUENCE
Messages
COURS IGL
Cours N° 3
Section 8 : Diagrammes Analyse
d’activité
185
SECTION 8 –
Cours 3 – Analyse DIAGRAMME
D ’A C T I V I T É
Présentation
 Les diagrammes d’activité (AD) représentent des

processus en tant qu’une activité composée de plusieurs
nœuds connectés.
 Dans UML 1, les AD étaient des sous-ensembles des
diagrammes d’état. Dans UML 2, c’est des diagrammes à
part entière.
 Une activité peut être attachée à n’importe quel élément
du modèle (cas d’utilisation, classe, …). Une activité
modélise essentiellement un comportement.
186
SECTION 8 –
Présentation
 Les diagrammes d’activité sont idéaux pour représenter

des processus métier.
 Les ADs n’ont pas besoin de connaître la structure
statique du modèle (classes, objets) ce qui permet leur
utilisation dans les premiers moments de l ’analyse.
 Les ADs sont très simples à comprendre par le client.
187
SECTION 8 –
Activités
 Les activités sont des réseaux composés de nœuds et de

connecteurs.
 Il y a trois types de nœuds : des nœuds d’action, des
nœuds de contrôle et des nœuds d’objet.
 Un « nœud d’action » représente une unité de travail
atomique (indivisible)
 Un « nœud de contrôle » contrôle le flux au sein d’une
activité
 Un « nœud d’objet » représente un objet manipulé dans
l’activité.
188
SECTION 8 –
Activités
 Les connecteurs représentent le flux entre les nœuds.

 Il y a deux types de connecteurs : des connecteurs de
contrôle et des connecteurs d’objet.
 Un connecteur de contrôle représente le flux d’activité
 Un connecteur d’objet représente le flux d’objet
 Une activité démarre avec un nœud spécial appelé nœud
initial
 L’activité se termine avec un nœud spécial appelé nœud
final
189
SECTION 8 –
Activités
EffectuerUneCommande
Acheteur
ValiderUneCommande
Vendeur
190
SECTION 8 –
Diagramme d ’activité
Nœud initial
Chercher Des Produits
Nœuds d’action Connecteurs

Sélectionner Les Produits
Enregistrer La Commande
Nœud final
191
SECTION 8 –
Diagramme d ’activité
Chercher Des Produits
Sélectionner Les Produits
Enregistrer La Commande
192
SECTION 8 –
Fonctionnement
 Le diagramme d’activité suit une séquence déterminée

par un jeton
 Le jeton transite du nœud initial vers le nœud final
 Le jeton peut être un des éléments suivants : le flux
actuel, un objet ou des données
 L’état d’un AD est déterminé par ses jetons
 Les jetons transitent d’un nœud à l’autre via les
connecteurs
193
SECTION 8 –
Partitions
 Les activités sémantiquement liées peuvent être

regroupées en « partitions »
 Une partition désigne généralement le rôle exécutant
l’action en cours
 Les partitions rendent les ADs plus faciles à lire et plus
expressifs
 Les partitions peuvent être représentées d ’une manière
horizontale ou verticale
 Exemple : pour valider une facture, le gestionnaire lance
la validation, le magasinier prépare le stock et enfin, le
comptable vérifie le paiement
194
SECTION 8 –
Partitions
Partitions
Gestionnaire Magasinier Comptable
Lancer la validation
Préparer le stock
Vérifier le virement
195
SECTION 8 –
Partitions
Gestionnaire Magasinier Comptable
Lancer la validation
Préparer le stock
Vérifier le virement
196
SECTION 8 –
Décisions et fusions
 Un nœud de décision a un connecteur en entrée et deux

(ou plusieurs e sortie)
 Le chemin à suivre par le jeton est celui de la condition
vérifiée du nœud de décision
 Plusieurs chemins sortent du nœud de décision
 Un nœud de fusion fusionnent les connecteurs sortis d ’un
nœud de décision
 Exemple : une fois une commande reçue, si le stock est
disponible faire l’inventaire du reste, sinon lancer un
approvisionnement
197
SECTION 8 –
Recevoir Commande
Nœud de
décision Stock disponible
[Non]
[Oui]
Mettre à jour
inventaire
Approvisionner
Nœud de fusion
Notifier
198
SECTION 8 –
Recevoir Commande
Stock disponible
[Non]
[Oui]
Mettre à jour
inventaire
Approvisionner
Notifier
199
SECTION 8 –
Activités parallèles
 Dans un AD, on peut créer des flux parallèles en utilisant

le nœud « fork »
 Pour fusionner les flux parallèles, un nœud « join » est
utilisé
 Exemple : après réception d’une commande, deux activité
sont lancées en parallèle, une pour la vérification du
paiement et l’autre pour la préparation du stock
200
SECTION 8 –
Nœud fork
Recevoir Commande
Préparer Stock Vérifier Paiement
Nœud join
201
SECTION 8 –
Recevoir Commande
Préparer Stock Vérifier Paiement
202
SECTION 8 –
Nœuds d’objet
 Les nœuds d’objet sont des nœuds spéciaux qui indiquent

que des instances d’une classe données sont disponible à
un point donné du temps
 Exemple, dans une activité industrielle, la spécification
produit un cahier de charges et le développement produit
un prototype
203
SECTION 8 –
Nœuds d’objet
Spécification
Nœud d’objet cahier des charges
Développement
prototype
204
SECTION 8 –
Nœuds d’objet
 Lorsque les activités produisent beaucoup d ’objets, il

serait intéressant de les organiser en PINS
 Par exemple, pour l’authentification, le username et le
mot de passe sont des objets produits
205
SECTION 8 –
Nœuds d’objet
Authentifier
Entrer
Utilisateur
Utilisateur
Vérifier
Utilisateur
Entrer Mot De
Mot De Passe
Passe
Vérifier Mot DePasse
Sans utilisation des PINs
206
SECTION 8 –
Nœuds d’objet
Entrer Authentifier
Utilisateur
Utilisateur
Vérifier
Utilisateur
Entrer Mot De
Passe
Mot de Vérifier Mot DePasse
passe
Avec utilisation des PINs
207
SECTION 8 –
Quand utiliser le diagramme d ’activité ?
 Pour modéliser des processus parallèles

 Pour modéliser des processus métier indépendamment
de la structure statique (classes d ’analyse)
208
COURS IGL
Cours N° 3
Section 9 : Diagrammes Analyse
d’états-transitions
209
SECTION 9 –
Cours 3 – Analyse D I A G R A M M E D ’ É TAT S
TRANSITIONS
Introduction
 Un diagramme d’états-transitions (DET) modélise le

cycle de vie d’un objet dit objet réactif
 Un objet réactif est un objet qui change d ’état suite à un
évènement donné
 Une machine d’état représente un nombre fini de ces
états
210
SECTION 9 –
TRANSITIONS
Introduction
 Les DETs sont composés de trois éléments principaux :

états, transitions et évènements
 Un état représente une condition dans laquelle se trouve
un objet à un instant T
 Un évènement est une action particulière qui se
déclenche sous des conditions spécifiques
 Une transition est le mouvement d’un état vers un autre
suite à un évènement donné
211
SECTION 9 –
TRANSITIONS
Exemple
 Une lampe est initialement éteinte. Si on l ’allume, elle

passe dans l’état allumée. Si on l’éteint, elle repasse dans
l’état éteinte. Si elle saute, elle passe définitivement à
l’état final défectueux
212
SECTION 9 –
TRANSITIONS
Exemple
Etat initial Etat
[Allumer]
Eteinte Allumée
[Eteindre]
[Sauter]
Transition Etat final
213
SECTION 9 –
TRANSITIONS
Etats
 Durant le temps, un objet peut envoyer un message à un

autre objet qui peuvent changer sont état
 L’état d’un objet est déterminé par ses attributs, ses
relations à d’autres objets et les activités dans
lesquelles il est impliqué
 Il ne faut modéliser que les états qui ajoutent de
l’expressitivité au système
 Les états de jonction (pseudo-états) peuvent connecter
plusieurs transitions
 Un pseudo-état de choix exprime un ou plusieurs choix
mutuellement exclusifs
214
SECTION 9 –
TRANSITIONS
Etats
Pseudo-état de
jonction
Disponible [déterioration] Indisponible
[rendu] [prêté]
En prêt
Pseudo-état de
choix
Perdu
215
SECTION 9 –
TRANSITIONS
Etats
Disponible [déterioration] Indisponible
[rendu] [prêté]
En prêt
Perdu
216
SECTION 9 –
TRANSITIONS
Quand utiliser le DET ?
 Pour modéliser des entités réactives (dont les états

changent)
217

Chapitre 3 - Analyse

Transféré par

Informations du document

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

Chapitre 3 - Analyse

Transféré par

Droits d'auteur :

Formats disponibles

COURS GÉNIE LOGICIEL

 Appréhender l’activité d’analyse

Section 7 : Section 8 : Section 9 :

 L’analyse produit un modèle appelé modèle d’analyse

L’activité d’analyse - Exemple

« à l’ESI, pour effectuer un stage, l’étudiant doit

L’activité d’analyse - Exemple

 Le vocabulaire devra contenir les concepts suivants :

Construire le modèle d ’analyse - Règles

 Se limiter aux concepts métier, s ’éloigner des

Formalisation du modèle d ’analyse

 Le vocabulaire et les interactions peuvent être formalisés

Unified Modeling Language

 Pourquoi et comment modéliser ?

Unified Modeling Language

 Pourquoi et comment modéliser ?

Unified Modeling Language

Unified Modeling Language

 Des langages à différents niveaux de formalisation :

Unified Modeling Language

Unified Modeling Language

Unified Modeling Language

 Modélisation par décomposition fonctionnelle descendante

 L’implémentation en code source d ’une solution décrite

 Lorsque le logiciel évolue, il faut faire évoluer les

 Maintenir cette cohérence est laborieuse parce que

La dispersion données/fonctions nuit à l ’extensibilité !

 Comment évaluer la découpe fonctionnelle descendante

 Séparer données et fonctions sur ces données entraine :

 Le code est donc peu extensible et peu réutilisable !

 On ne raisonne plus en termes d ’actions mais plutôt en

Etat Comportement Objet

 Rumbaugh définit l’objet comme étant une entité discrète

 Le diagramme qui est utilisé pour la représentation des

Notation UML des objets

Nom de l’instance compteTest :Compte

Notation UML des objets

 Les noms sont écrits en souligné

Notation UML des objets - Liens

 Un lien lie deux instances entre objets

Notation UML des objets - Liens

Notation UML des objets - Exemple

igl :Module conduiteDeProj et : mcsi :Module

Objets – Notation UML - Diagrammes

 Un diagramme d’objets présente des objets et leurs

Objets – Notation UML - Diagrammes

Objets – Notation UML - Diagrammes Diagramme

object Pédagogie Nom du diagramme

cherid :Employe balla :Employe mostefai :Employe

+Directrice Etudes +Responsable CPI +Enseignant

pg :Departement directionDesEtudes :Departement

Lien Bidiectionnel Rôle

Diagramme d ’objet – Quand l’utiliser ?

 Les diagrammes d’objets sont utilisés pour donner des

 Les diagrammes d’objet sont facultatifs et souvent les

 Rumbaugh définit la classe comme étant un descripteur

 Rumbaugh définit la classe comme étant un descripteur

Modélisation orientée objet

Comment classifier ces animaux ? 46

Modélisation orientée objet

 Ce n’est pas facile d’avoir une conception objet du monde

 L’objet instancie la classe

«instantiate» «instantiate» «instantiate»

mcsi :Module igl :Module conduiteDeProj et :