UML use case class2UML use case class2.ppt

1
Mme BENTOUATI
MḖTHODE DE CONCEPTION DES APPLICATIONS WEB
UML

Génie Logiciel
UML
 Introduction
 Cycle de vie d’un logiciel
 Historique d’UML
 Diagrammes UML
 Diagrammes de classes et d'objets
 Diagrammes des cas d'utilisation
 Autres diagrammes
 Passage vers le code
 De UML vers Java
 UML et les bases de données
 Langage de contraintes : OCL
 Études de cas
 De l’analyse des besoins au code
2

3
Cycle de vie d’un logiciel
 Processus (ensemble d’activités) nécessaire au
développement et à la maintenance d’un logiciel
 Composé de plusieurs phases autonomes mais
dépendantes (interdépendantes).
 Chaque étape se termine par la remise de un ou
plusieurs documents validé conjointement par
l’utilisateur et le développeur.
3

4
Étapes nécessaires à la réalisation d’un logiciel:
 Analyse
 Conception
 Codage (Implémentation)
 Tests
 Livraison
 Maintenance
4

5
Modèle en Cascade (WaterFall)
Analyse
Conception
Implémentation
Tests
Maintenance
5

6
Analyse
 Elle a pour but de dégager le problème à étudier.
 Le résultat de l'analyse est le cahier de charges
(exprimé dans une langue naturelle) contenant
les besoins du futur système.
 Cette spécification est informelle.
 3 phases:(Faisabilité, Spécifications des besoins,
Organisation du projet)
6

7
Faisabilité
 Première étape du cycle de vie d’un logiciel
 Répondre à deux questions :
 Est-ce que le logiciel est réalisable ?
 Est-ce que le développement proposé vaut la
peine d’être mis en œuvre ?
►► Étudier le marché pour déterminer s’il existe
un marché potentiel pour le produit.
7

8
Spécification des besoins
 Permet de définir ce que doit faire le logiciel et
non comment il le fait
 Quatre types de spécifications
 Spécifications générales
 Spécifications fonctionnelles
 Spécifications d’interface
 Spécifications techniques
8

9
La spécification générale consiste à identifier :
 Objectifs à atteindre
 Contraintes (utilisation du matériel et outils
existants)
 Règles de gestion à respecter
9

10
Spécification fonctionnelles est la description des
fonctionnalités du futur logiciel de manière
détaillée que possible
Spécification d’interface décrit les interfaces du
logiciel avec le monde extérieur : homme (IHM),
autres logiciel (Middleware), machines
10

11
Spécification technique :(Étude de l’existant)
 Moyens d’accès (local, distant, Internet, …)
 Temps de réponse acceptable (gestion des GAB, gestion
des emplois de temps, …)
 Plateforme (Windows, Unix, …)
 Quantité d’informations à stocker (choix du SGBDR, …)
11

12
Organisation du projet
 Appelée aussi Planification et gestion de projet
 Permet de déterminer la manière de développer le logiciel
 La phase de planification permet de :
 découper le projet en tâches
 décrire leur enchaînement dans le temps,
 affecter à chacune une durée et un effort
12

13
Organisation du projet
Plusieurs étapes :
 Analyse des coûts: estimation du prix du projet
 Planification: calendrier pour le développement (jours
ouvrables, jours fériés, nombre d’heures de travail par
jours, …)
 Répartition des tâches: distribuer les tâches et les sous
tâches (affectation des ressources aux tâches)
13

14
Conception
 Permet de fournir une description fonctionnelle
(formelle) du système en utilisant une méthode.
 Les méthodes proposent des formalismes (dans
la plupart des temps graphiques) pour concevoir
le système.
 Deux types de conception :
 Conception générale
 Conception détaillée
14

15
Conception générale
 Appelée aussi : ‘Conception architecturale’
 Se focaliser sur l’architecture générale du
système : décomposition du système en sous
système
Exemple, pour la gestion scolaire :
 Estudiantine (étudiants, notes, prof, filières, …)
 Administrative (personnel administratif, …)
 Bibliothèque (Ouvrages, auteurs, adhérents, …)
15

16
Conception détaillée
 Produire une description externe de chacune des
procédures, fonctions et des structures de
données (conception classique)
 Produire de manière précise les contenus des
objets en terme de propriétés et de méthodes
(conception Orientée Objet)
16

17
implémentation (Réalisation)
 Des programmes seront élaborés afin de mettre
en œuvre des solutions techniques
précédemment retenues
 Plusieurs types langages sont utilisés:
 Langages classiques (C, Pascal, Fortran, …)
 Langages orientés objets (C++, Java, C#, …)
17

18
Codage et Tests
On distingue plusieurs types de tests :
 Test unitaire: tester les parties du logiciel par les
développeurs
 Test d’intégration: tester pendant l’intégration des modules
 Test système: tester dans un environnement proche à celui
de production
 Test alpha: tests faits par le client sur le site de
développement
 Test bêta: tests faits par le client sur le site de production
 Test de régression: enregistrer les résultats des tests et les
comparer avec ceux des anciens versions pour déterminer
si la nouvelle n’a pas apporté de dégradation de
performance.
18

19
Livraison
 Fournir au client une solution logiciel qui
fonctionne correctement.
 Plusieurs tâches :
 Installation: rendre le logiciel opérationnel sur le site du
client
 Formation: enseigner aux utilisateurs à se servir de ce
logiciel
 Assistance: répondre aux questions de l’utilisateur
19

20
Maintenance
 Mettre à jour et améliorer le logiciel
 La maintenance comprend :
 Corrective : correction des erreurs et anomalies
 Adaptative : adaptation à de nouveaux environnements
 Évolutive ou Perfective : ajout de nouvelles
fonctionnalités
20

21
Documents
 Cahier des charges : description des fonctionnalités
désirées (décrites par l’utilisateur)
 Spécifications : décrit ce que doit remplir le logiciel
(décrites par le développeurs) :
 Modèle Objet : Classes et objets
 Scénarios des cas d’utilisation : différents enchaînements possibles
du point de vue de l’utilisateur
 IHM : propositions des interfaces homme-machines
 …
21

22
Documents
 Calendrier du projet: indique les tâches, les
délais et les ressources
 Plan de test: indique les procédures de tests à
appliquer
 Manuel d’utilisateur: mode d’emploi du logiciel
dans sa version finale
22

23
Documents
 Code source: code complet du produit fini
 Rapport des tests: décrit les tests effectués et les
réactions du système
 Rapport des défauts: décrit les comportements
du système qui n’ont pas satisfait le client.
23

Historique
Deux approches
 Approche fonctionnelle
 1960 – fin 1970
 l'important c'est les traitements
 Séparation nette des données et traitements
 Approche objet
 1980 – début 1990 : premières génération
 L'important c'est l'objet
 Objet = données + traitements
24

Historique
Début des années 1990
 les premiers processus de développement OO
apparaissent
 prolifération des méthodes et notations étaient la cause
de grande confusion :
 méthode OOD de Grady Booch (1991)
 méthode OMT de James Rumbaugh (1991)
 méthode OOSE de Ivar Jacobson (1991)
 méthode OOA/OOD de Coad and Yourdon (1992)
 méthode de Schlaer and Mellor (1992)
 Etc.
25

Historique
Fin 1994
 J. Rumbaugh rejoint G. Booch chez Rational Software
 OMT + OOD  Unified Method (oct 1995)
Fin 1995
 I. Jacobson les rejoint chez Rational Software
 Unified Method + OOSE  UML 0.9 (juin 1996)
Début 1997
 Partenaires divers : Microsoft, Oracle, IBM, HP et autres leaders
collaborent
  UML 1.0 (jan 1997)
Fin 1997
 l’OMG (Object Management Group) retient UML 1.1 comme
norme de modélisation
26

Historique
Les versions se succèdent :
 Début 1998
 UML 1.2
 En 1998
 UML 1.3
 En 2001
 UML1.4
 En 2003
 UML 1.5
 En 2005
 UML 2.0
27

Qu’est ce que UML ?
UML(Unified Modeling Language) un langage de
modélisation unifié
 Langage = syntaxe + sémantique :
 syntaxe : notations graphiques consistant
essentiellement en des représentations conceptuelles
d'un système
 sémantique : sens précis pour chaque notation
28

 UML est caractérisé par :
 un travail d'expert
 utilise l’approche orientée objet
 normalisé, riche
 Formel : sa notation limite les ambiguïté et les
incompréhensions
 langage ouvert
 INDÉPENDANT du langage de programmation
 Domaine d'application : permet de modéliser n'importe quel
système
 Supporté par plusieurs outils (AGL) : Objecteering, Open
tools, Rational Rose, PowerAMC, WinDesign, …
29

Attention
UML est un langage (et non pas une méthode) qui :
 permet de représenter les modèles
 ne définit pas le processus d'élaboration des modèles.
30

Diagrammes d'UML
31
Diagramme
Classes
Composants Déploiement
Collaboration
Etats Transitions Séquence
Objets
Cas d ’utilisation
Cas d ’utilisation Classes États Transitions Séquence
Est sorte de
Activité
UML1.1 comprend 9 de diagrammes :

Diagrammes d'UML
UML définit deux types de diagrammes, structurels
(statiques) et comportementaux (dynamiques)
 Modélisation de la structure
 diagramme de classes
 diagramme d’objets
 diagramme de composants
 diagramme de déploiement
 Modélisation du comportement
 diagramme de cas d'utilisation
 diagramme d’états
 diagramme d’activités
 diagramme de collaboration
 diagramme de séquence
32

Diagramme d’UML
Les diagramme d’UML peuvent être utilisés pour
représenter différents points de vues :
 Vue externe : vue du système par ses utilisateurs
finaux
 Vue logique statique : structure des objets et leurs
relations
 Vue logique dynamique : comportement du système
 Vue d’implémentation : composants logiciels
 Vue de déploiement : répartition des composants
33

Diagramme d’UML
34
Composants
Déploiement
Cas d’utilisation
Activités
États transitions
Collaboration
Séquence
Vue Implémentation
(composants logiciels)
Vue déploiement
(Environnement
d’implantation)
Vue logique dynamique
(Comportement)
Vue logique statique
(Structure des objets)
Vue externe
(fonctions système)
Objets
Classes

Diagrammes de classes et d’objets
35

Diagramme de classes
 Permet de donner une vue statique du système en
terme de :
 Classes d'objets
 Relations entre classes
 Associations
 agrégation/composition
 héritage
 La description du diagramme de classes est centrée sur
trois concepts :
 Le concept d’objets
 Le concept de classes d’objets comprenant des attributs et des
opérations
 Les différents types de relations entre classes.
36

Concept d'objet
Objet = un concept, abstraction ou une chose autonome
qui a un sens dans le contexte du système à modéliser
 une personne : le client « El Alami M. »
 un objet concret : le livre intitulé « Initiation à… »
 un objet abstrait : le compte bancaire n° 1915233C
 …
37

Concept d'objet
Remarque
 Un objet doit :
 Être autonome
 Avoir une signification dans le système
 En relation avec d'autres objets
 Ne pas confondre "autonomie" avec "indépendance"!!
 Exemples
 Gestion de stock : Clients, Commandes, Articles, …
 Gestion scolaire : Étudiants, Modules, Filières, …
38

Concept d'attribut
 Un attribut est une propriété, caractéristique d’un
objet. Par exemple :
 un client a un nom, un prénom, une adresse, un code
client, …
 un compte bancaire a un numéro, un solde, …
 Un attribut doit (généralement) avoir une valeur
atomique
39

Concept d'attribut
La description d’un attribut comporte :
Visibilité attribut:type[= valeur initiale]
Où :
 Visibilité :
 + (publique, public) : visible par tous
 - (privée, private) : visible seulement dans la classe
 # (protégée, protected) : visible seulement dans la classe et
dans les sous-classes de la classe.
 Nom d’attribut
 Type de l’attribut
 Valeur initiale (facultative)
40

Concept d'attribut
Le type d’un attribut peut être :
 Un type de base : entier, réel, …
 Une expression complexe : tableaux, enregistrements, …
 Une classe
Exemples d’attributs :
 - couleur : enum{Rouge, Vert, Bleu}
 # b : boolean = vrai
 - Client : Personne
41

Concept d'attribut
Lorsqu’un attribut peut être dérivé ou calculé à partir
d'autres attributs, il est précédé d’un /. Par exemple,
une classe « Rectangle » peut contenir les attributs
suivants :
 longueur : réel,
 largeur : réel,
 /surface : réel.
42
Rectangles
-
-
-
Largeur
Longueur
/Surface
: float
: float
: float
= 10

Concept d'attribut
On distingue deux types d'attributs :
 Attribut d'instance :
 Chaque instance de la classe possède une valeur particulière
pour cet attribut
 Notation : Visibilité attribut:type[= valeur initiale]
 Attribut de classe
 Toutes les instances de la classe possède la même valeur pour
cet attribut
 Notation : Visibilité attribut:type[= valeur initiale]
 Équivalent en C++, Java : static
43

Concept d'attribut
44
Opérations d'instances
Opérations de classes
Window
-
-
-
-
taille
visibilité
taille_defaut
taille_max
: Rectangle
: boolean
: Rectangle
: Rectangle
= (100,100)
= true
+
+
+
+
+
<<Constructor>> Window ()
afficher ()
cacher ()
getTaille_max ()
getTaille_defaut ()
: void
: void
: Rectangle
: Rectangle
Attributs d'instances
Attributs de classes

Concept d'opération et méthode
Une opération est :
 un service offert par la classe
 une fonction ou une transformation qui peut être
appliquée aux objets d’une classe.
 permet de décrire le comportement d’un objet. Par
exemple, « Embaucher », « Licencier » et « Payer »
sont des opérations de la classe « Société ».
45

46
Une méthode est
 l’implémentation d’un service offert par la
classe (opération).
 de différents types :
 accesseurs (get...): renvoie une information sur
l'état d'un objet (fonction)
 modifieurs (set...): modifie l'état de l'objet
(procédure)
 constructeurs: initialise une nouvelle instance

La description d’une opération comporte :
Visibilité opération([arguments:type[=valeur
initiale]]):type de résultat
 Visibilité de l’opération (-, +, #)
 Nom de l’opération
 Liste des arguments avec leurs types et éventuellement
leurs valeurs par défaut
 Le type du résultat retourné
47

Exemples d'opérations :
48
Compte
-
-
-
N°Compte
Solde
Client
: String
: float
: Personne
+
+
+
+
<<Constructor>> Compte ()
Deposer (float somme)
Retirer (float somme)
AvoirSolde ()
: void
: float
: String

Concept de classes d’objets
 Classe = ensemble d’objets ayant les mêmes propriétés
(attributs) et le même comportement (opérations)
 tous les clients sont décrits par un nom, un prénom, … et
peuvent marcher, parler,courir, …
 tous les comptes bancaires ont un numéro, un solde, … et
sur lesquels on peut déposer ou retirer l'argent, ou les
consulter
 …
 Un objet est instance d’une classe, et le fait de créer
un objet d'une classe est dite instanciation.
49

Classe représentée par un rectangle à trois parties :
 Partie 1 : Nom de la classe
 Partie 2 : Attributs (propriétés, champs)
 Partie 3 : Méthodes (fonctions, opérations)
50

Compte
-
-
#
N°Compte
Solde
Client
: String
: float
: Personne
= 100
+
+
+
+
Deposer (float somme)
Retirer (float somme)
AvoirSolde ()
: void
: float
: String
51

Concept de classe d'objets
On peut ne pas visualiser les attributs et/ou les
opérations, afin de ne pas alourdir inutilement le
schéma.
52
Nom de la classe
Attributs
Opérations
Nom de la classe
Attributs
Nom de la classe Nom de la classe
Opérations

Encapsulation, visibilité et interface
 Encapsulation est le mécanisme de regrouper les
attributs et les opérations au sein d’une même entité
(classe)
 Ce regroupant permet d’empêcher d’accéder
directement aux données par un autre moyen que les
services proposés (opérations)
 Ces services offerts aux utilisateurs définissent ce que
l’on appelle l’interface de la classe.
53

Encapsulation, visibilité et interface
54
Données
Traitement
}
}
•Partie statique, passive
•Partie cachée, privée
•Partie dynamique, comportementale
•Partie visible, publique
•Interface avec l’extérieur
User

Méthodes et classes abstraites
 Une méthode est dite abstraite si on connaît son
entête, mais pas la manière dont elle peut être réalisée
 Une classe est dite abstraite lorsqu’elle définit au
moins une méthode abstraite
55
FormeGéométrique
{abstract}
-
-
abs
ord
: int
: int
+
+
+
+
{abstract}surface ()
getAbs ()
getOrd ()
... ()
: double
: int
: int

Classe « Interface »
 Une interface est une classe spéciale dont toutes les
méthodes sont abstraites
 Une interface se note en UML avec le stéréotype
<<interface>> ou symbole
56
Forme

Package
 Un package permet de regrouper des classes, des
interfaces et des packages.
 Les classes, les interfaces et les packages ne peuvent
qu’un seul package dans lequel ils sont regroupés
57

Package
 Un package est représenté par un rectangle possédant
un onglet dans lequel est inscrit le nom du package
58

Import des packages
 La relation d’import permet à une classe d’un package
d’utiliser les classes d’un autre package.
 La relation est monodirectionnelle : elle comporte un
package source et un package cible.
59

Import de packages
 La relation d’import s’exprime avec une flèche en
pointillé
 Dans l’exemple, la classe ‘Afficheur’ a besoin des
classes du package ‘Dessin’
60

Associations
 Relation existant entre une, deux ou plusieurs classes.
 Une association porte un nom (signification)
 Représentée par une ligne rectiligne
61

Associations
Remarques
 une association fonctionne (généralement) dans les 2
sens (bidirectionnelle)
 termes associés : Nom, Sens de lecture, degré (arité),
Multiplicité, Rôle, navigabilité et le qualificateur
62

Associations
Nom et sens de lecture
 Décrit la nature (signification) de l’association
 Montre la direction de lecture de l’association
63

Associations
Rôle d’une association
Décrit le rôle d’une classe dans une association
64

Associations
Rôle d’une association
Utile surtout dans deux cas :
 Lorsqu’on a plusieurs associations entre deux classes
avec des rôles différents
 une relation réflexive : relation entre deux instances
d’une même classe
65
0..4
femme
0..1
mari
Personne
Pilote
Passager
Avion
Personne

Associations
Classe association
66
Une association peut avoir des attributs = classe-association

Associations
Classe association
 Les classes association sont utiles quand il y a des
attributs qui sont pertinents à l’association, mais à
aucune des classes impliquées.
67
1..*
0..1
Personne Entreprise
Emploi
-
-
Période
Salaire
: int
: float

Associations
68
 degré d’une association = nombre de classes participantes
Association unaire : relie 2 instances d'une classe
association binaire : relie 2 classes
 association ternaire : relie 3 classes
 association n-aire : relie n classes

Associations
69
Multiplicité = nombre de participations d’une classe dans une
association
 indiquée à chaque extrémité d’une association
 sous la forme min..max
 min, max = 0, 1, *
 Exemple général
 Exemple concret

Associations
70
 Exemple ternaire
 Pour un couple d’instances de la classe A et de la classe B,
il y a au min. r1 instances de la classe C et au max. r2 instances,
 …
 …

Associations
71
Notation abrégée des multiplicités :
1  1..1 (exactement 1)
*  0..* (0 ou plusieurs)
n  n .. n (exactement n)
1..*  1 ou plusieurs (1 ou plus)
0..1  0 ou 1 (au plus un)
1..100  entre 1 et 100
2,4,5  2, 4 ou 5

Association
Navigabilité
 Une association est par défaut bidirectionnelle.
 Cependant, il peut être utile de se limiter à une seule
direction  association navigable
72
1..*
1
Commandes Clients

Association
Navigabilité (Exemple)
 Spécification : on doit être en mesure de savoir le client
qui a fait la commande et non toutes les commandes
d’un client
 Conception :
 Implémentation : la classe commande doit avoir un
champ faisant référence à la classe client
73
1..*
1
Commandes Clients

Association
Navigabilité (Exercice)
Un étudiant peut avoir jusqu’à 5 copies d’examens. À un
étudiant sont associées ses copies d’examens, mais on
ne doit pas autoriser l’accès à l’auteur de la copie
(notamment avant la correction des copies)
74

Qualification d'une association
 La qualification d’une association permet de
restreindre la multiplicité d’une association.
 La qualification se représente par un rectangle placé au
niveau de la classe source du qualificatif.
75

Exemple : une banque contient plusieurs comptes, d'où
le diagramme :
76
Banque Compte
1 1..*
Banque
Compte
NCompte
1 1
Par contre, si on connaît le N°Compte, il y a un
et un seul compte, on obtient alors :

Exercice
 Un avion est composé de plusieurs sièges, mais dans
une rangée il y a seulement quatre sièges.
77

Agrégation
Type particulier d’association dans laquelle :
 Classe agrégat (composé), classes agrégée (composant)
 Entre les deux, il existe une relation de type « est composé de
»
78
Agrégat Agrégée

Agrégation
 Les parties (les composants) sont séparables de
L’agrégat (le tout)
 La suppression d’une équipe n’implique pas la
suppression des personnes qui la composent
79

Agrégation
1..*
* 0..*
0..*
1..1
0..1
1..1
0..1
Destinataire Fichier
Titre
Texte
E-Mail
Ici, on exprime qu'un fichier peut être attaché à un email (ou a
plusieurs, ou même à aucun) et qu'un email peut (ou non)
attacher (contenir une copie) une ou plusieurs fichiers.
80
Un agrégat (composé) peut être multiple.

Composition
 La composition est un cas particulier d’une agrégation
dans laquelle la vie des composants (élément) est liée à
celle de l’agrégat (composé) : si l’agrégat est détruit (ou
déplacé), ses composants le sont aussi.
 D’un autre côté, et contrairement à l’agrégation, une
instance de composant ne peut être liée qu’a un seul
agrégat.
 La composition se représente par un losange noir
(plein).
81

Composition
82
 la suppression d’un objet agrégat entraîne la suppression des
objets agrégés

Composition
 Un document est composé de plusieurs paragraphes,
qui, à son tour, est composé de plusieurs phrases
 Remarquer la propagation des opérations (copie,
suppression,…)
83

Généralisation / Spécialisation et héritage
 La généralisation est la relation entre une classe et une
ou plusieurs de ses versions raffinées.
 On appelle la classe dont on tire les précisions la
super-classe et les autres classes les sous-classes.
 C’est une relation de type « est un (is a) » ou « est une
sorte de ».
 La notation utilisée pour la généralisation est le
triangle
84

85
 généraliser = mettre en facteur des classes  « super-classe »
 spécialiser = décrire de nouveaux détails  « sous-classes »
 comparable à une association de type « est un, is a, kind of »
 une sous-classe hérite des attributs et opérations de sa super-classe
(classe mère)

La classe spécialisée (sous-classe)
 hérite les méthodes et les attributs de la classe
générale (super-classe)
 peut ajouter ses propres attributs et méthodes.
 peut redéfinir le comportement d’une méthode.
86

87
Compte
-
-
N°Compte
Solde
: String
: float
+
+
+
+
Déposer (float Somme)
Retirer (float Somme)
AvoirSolde ()
: void
: float
: String
CompteEpargne
- Taux : float
+ AvoirSolde () : String

Remarques
 La généralisation et la spécialisation sont deux façons
pour voir la même relation, top-down (spécialisation)
ou bottom-up (généralisation).
 L'héritage est l’implémentation de la relation de la
généralisation/spécialisation.
 Une classe peut hériter de plusieurs classes, on parle
alors d’un héritage multiple.
88

Personnes
-
-
Code
Nom
: int
: String
+
+
+
<<Constructor>> Personnes (int Code, String Nom)
getNom ()
getInf ()
: String
: String
Etudiants
- Salaire : float
+
+
+
<<Constructor>> Etudiants (int Code, String Nom, float Salaire)
getInf ()
getSalaire ()
: String
: float
Employes
- Filiere : String
+
+
+
<<Constructor>> Employes (int Code, String Nom, String Filiere)
getInf ()
getFiliere ()
: String
: String
89
Spécialisation
Généralisation
Super classe, classe mère
Sous classes
Classes filles
Classes dérivées

Généralisation / Spécialisation
90
 une classe peut hériter de plusieurs super-classes
= héritage multiple

Généralisation / Spécialisation
91
 polymorphisme = opérations de même nom, polymorphisme
= comportement spécifique

Contraintes sur les associations
 Concepts avancés des associations
 Permettent d’imposer des règles à respecter lors du
passage à l’implémentation
 Il est possible d’attribuer toutes sortes de contraintes à
une association
 Les contraintes sont représentées entre accolades et
peuvent être exprimées dans n’importe quel langage (y
compris OCL)
92

Les contraintes (prédéfinies) souvent utilisées :
 {ordonné}
 {sous ensemble}
 {xor}
 {addOnly}
 {frozen}
93

contrainte {ordonné}
Indique que les objets seront ordonnés à chaque
opération de création, modification, suppression, …
94
1 0..*
{Ordonné}
Personne Compte
Les comptes d’une personne sont ordonnés

contrainte {sous-ensemble}
 Indique qu’une collection est incluse dans une autre
 Nécessite la présence d’au moins deux relations
95
1..*
1..*
{sous-ensemble}
Ecole Personnes
Les personnes qui jouent le rôle de délégué font partie des personnes
qui jouent le rôle de parents d’élèves
Parent d’élève
Délégué

contrainte {xor}
Indique que parmi un groupe d’associations, une seule
est valide à la fois
96
1
{xor}
1
1
1
PC Portable
Batterie
Secteur
Un PC Portable est alimenté soit à partir
d’une batterie, soit à partir d’un secteur

contrainte {addOnly}
La contrainte prédéfinie {addOnly} autorise l’ajout de
nouveaux objets, mais pas leur suppression ni leur
mise à jour.
97
1
1..*
1
0..*
Personne Liste
Enfants
{addOnly}

contrainte {frozen}
La contrainte prédéfinie {frozen} interdit l’ajout, la
suppression ou la mise à jour des liens d’un objet
vers les objets de la classe associée, après
l’initialisation du premier.
98
2
parent
0..*
enfant
Personne
{frozen}

Exercices
Modéliser sous forme de diagrammes de classes :
1. Le président d’un comité doit être membre du
comité
2. Une personne qui soumit un article à un journal ne
peut pas évaluer son propre article
99

Exercices
Modéliser sous forme de diagrammes de classes :
1. Un véhicule est composé d’au moins 2 roues. Le
nombre de roues d’un véhicule ne peut pas varier
2. Les employés de l’hôtel n’ont pas le droit de prendre
une chambre dans le même hôtel.
100

Exercices
Une personne
 Est née dans un pays (ce pays ne peut être modifiée)
 A visité un certain nombre de pays, dans un ordre
donné, et que le nombre de pays visités ne peut que
croître
 Aimerait encore visiter toute une liste de pays, et que
cette liste est ordonnée.
101

Exemple de diagramme de classes
(Distributeur Automatique de Banque : DAB)
102

Diagramme d’objets
 Représente les objets (instances de classes) et les liens
(instances de relations) à un instant donné
 Peut être utilisé pour :
 Illustrer le modèle de classes en montrant un exemple
qui explique le modèle
 Préciser certains aspects du système
 Exprimer une exception en modélisant des cas
particuliers
 Etc.
103

 Le nom d’un objet est souligné
 Nom : Classe
 Nom
 :Classe
104

Exemple :
 Une entreprise emploie au moins deux personnes
 Une personne travaille dans au plus deux entreprises
105

Exemple
:Entreprise
p1:Personne p2:Personne p3:Personne
e1:Entreprise
:Personne p4:Personne
106
0..2
2..*
Entreprise
Personne

Etapes pour établir un diagramme
107
A partir d’une description du système :
1. Identifier un premier ensemble de classes candidates
2. Identifier les associations et les attributs
3. Identifier les généralisations
4. Lister les traitements, choisir les opérations
5. Vérifier le modèle obtenu
6. Itérer jusqu’à satisfaction …
a. Supprimer les transitivités
b. S’assurer que le schéma répond à la demande

Diagrammes de cas d'utilisation
108

Diagramme des cas d’utilisation
 Décrit, sous forme d’actions et de réactions, le
comportement d’un système du point de vue d’un
utilisateur.
 Permet de définir les limites du système et ses relations
avec l’environnement.
109

Diagramme de cas d'utilisation
 Sert à modéliser les aspects dynamiques d'un système
(Contrairement aux diagrammes de classes).
 Fait ressortir les acteurs et les fonctions offertes par le
système.
 Utilisé pour modéliser les exigences (besoins) du client
110

Diagrammes des cas d'utilisation
Comportent plusieurs éléments :
 Acteurs
 Cas d'utilisation
 Relations de dépendances, de généralisations et
d'associations
111

Acteurs
 UML n’emploi pas le terme d’utilisateur mais d’acteur.
 Le terme acteur ne désigne pas seulement des
utilisateurs humains mais également les autres
systèmes (machines, programmes, …)
 Un acteur est un rôle joué par une entité externe qui
agit sur le système (Comptabilité, service commercial,
…), en échangeant de l’information (en entrée et en
sortie)
112

Acteurs
Remarques
 La même personne physique peut jouer le rôle de
plusieurs acteurs (Chef d’agence est un client de la
banque).
 D’autres part, plusieurs personnes peuvent jouer le
même rôle, et donc agir comme un même acteur
(plusieurs personnes peuvent jouer le rôle
d’administrateur).
113

Acteurs
Peut être représenté de deux manières différentes :
 Petit personnage (stick man)
 Classe stéréotypée
114
Nom Acteur
<<Acteur>>
Nom Acteur

Acteurs
Les acteurs peuvent être de trois types :
 Humains : utilisateurs du logiciel à travers son
interface graphique, par exemple.
 Logiciels : disponibles qui communiquent avec le
système grâce à une interface logicielle (API, ODBC,
…)
 Matériels : exploitant les données du système ou qui
sont pilotés par le système (Imprimante, robots,
automates, …)
115

Acteurs
116
Secrétaire
Etudiant
Système de Gestion
Scolaire
<<acteur>>
Imprimante
<<acteur>>
Site Web de l'établissement

Acteurs
Mais du point de vue système on distingue deux types :
 Acteurs principaux : utilisent les fonctions principales
du système. Par exemple, le client pour un distributeur
de billets.
 Acteurs secondaires : effectuent des tâches
administratives ou de maintenance. Par exemple, la
personne qui recharge la caisse contenue dans le
distributeur.
117

Acteurs
Un acteur peut être une
spécialisation d'un autre acteur
déjà défini.
Dans ce cas, on utilise la relation de
118
Acteur général
Acteur spécialisé

Cas d'utilisation
 Introduit par Ivar Jacobson en 1992 dans sa méthode
Object-Oriented Software Engineering (OOSE).
 Technique de description du système étudié
privilégiant le point de vue de l'utilisateur.
 Repris par UML dans la but de :
 Effectuer une bonne délimitation du système
 Améliorer la compréhension de son fonctionnement
interne
119

Cas d'utilisation
Les cas d’utilisations
 Permettent de modéliser les attentes (besoins) des
utilisateurs
 Représentent les fonctionnalités du système
 Suite d’événements, initiée par des acteurs, qui
correspond à une utilisation particulière du système
 L’image d’une fonctionnalité du système, déclenchée
en réponse à la stimulation d’un acteur externe.
120

Cas d'utilisation
Un cas d'utilisation est représenté par une ellipse en trait
plein, contenant son nom.
121
Nom Cas Utilisation

Structuration des cas d'utilisation
Après avoir identifié les acteurs et les cas d'utilisation, il
est utile de restructurer l'ensemble des cas d'utilisation
que l'on a fait apparaître afin de rechercher les :
 Comportements partagés
 Cas particuliers, exceptions, variantes
 Généralisations/spécialisations.
122

Structuration des cas d'utilisation
UML définit trois types de relations standardisées entre
cas d'utilisation :
 Une relation d'inclusion, formalisée par la dépendance
«include»
 Une relation d'extension, formalisée par la dépendance
«extend»
 Une relation de généralisation/spécialisation
123

Relation d'inclusion
Lors de la description des cas d'utilisation, il apparaît
qu'il existe des sous-ensembles communs à plusieurs
cas d'utilisation, il convient donc de factoriser ces
fonctionnalités en créant de nouveaux cas d'utilisation
qui sont utilisés par les cas d'utilisation qui les avaient
en commun.
124

 A inclut B : le cas A inclut obligatoirement le
comportement définit par le cas B; permet de
factoriser des fonctionnalités partagées
 Le cas d'utilisation pointé par la flèche (dans notre cas
B) est une sous partie de l'autre cas d'utilisation (A,
dans notre exemple).
125
<<include>>
A
B

<<include>>
<<include>>
<<include>>
<<include>>
Retirer de l'argent
Déposer de l'argent
Effectuer des virements
Consulter solde
S'authentifier
126
Les cas d'utilisation "Déposer de l'argent",
"Retirer de l'argent", "Effectuer des
virements" et "Consulter solde" incorporent
de façon explicite le cas d'utilisation
"S'authentifier", à un endroit spécifié dans
leurs enchaînements.

On utilise cette relation pour éviter de décrire plusieurs
fois un même enchaînement d'actions. Ainsi, on est
amené à factoriser un comportement commun à
plusieurs cas d'utilisation dans un cas d'utilisation à
part.
127

Remarques
 La relation include n’a pour seul objectif que de
factoriser une partie de la description d’un cas
d’utilisation qui serait commune à d’autres cas
d’utilisation.
 Le cas d’utilisation inclus dans les autres cas
d’utilisation n’est pas à proprement parlé un vrai cas
d’utilisation car il n’a pas d’acteur déclencheur ou
receveur d’évènement. Il est juste un artifice pour faire
de la réutilisation d’une portion de texte.
128

Résumé
 Une instance du cas source inclut obligatoirement le
comportement décrit par le cas d’utilisation
destination
 Permet de décomposer des comportements et de
définir les comportements partagées entre plusieurs
cas d’utilisation
▬► Factoriser
129

Relation d'extension
La relation stéréotypée «extend» permet d'étendre les
interactions et donc les fonctions décrites dans les cas
d'utilisation, mais sous certaines contraintes.
130

 Le CU source (B) ajoute, sous certaines conditions, son
comportement au CU destination (A)
 En d’autres termes, le CU B peut être appelé au cours
de l’exécution du CU A
 Le comportement ajouté s’insère au niveau d’un point
d’extension définit dans le CU destination
131
<<extend>>
B
A
Point d'insertion

 Le cas d'utilisation de destination peut fonctionner
tout seul, mais il peut également être complété par un
autre cas d'utilisation, sous certaines conditions.
 On utilise principalement cette relation pour séparer le
comportement optionnel (les variantes) du
comportement obligatoire.
132

Exemple :
Au moment de l'authentification, il se peut que le
guichet retient la carte.
133
<<extend>>
Retenir la carte
S'authentifier

Relations d’inclusion VS
d'extension
 La relation « extend" montre une possibilité
d'exécution d'interactions qui augmenteront les
fonctionnalités du cas étendu, mais de façon
optionnelle, non obligatoire,
 La relation "include" suppose une obligation
d'exécution des interactions dans le cas de base.
134

Relation d'héritage
 Il peut également exister une relation d'héritage entre
cas d'utilisation.
 Cette relation exprime une relation de
spécialisation/généralisation au sens classique.
135

Relation d'héritage : Exemple
Dans un système d'agence de voyage, un acteur
"Touriste" peut participer à un cas d'utilisation de
base qui est "Réserver voyage", qui suppose par
exemple, des interactions basiques au comptoir
de l'agence. Une réservation peut être réalisée
par téléphone ou par Internet.
136

 On voit qu'il ne s'agit pas d'une relation "extend", car la
réservation par Internet n'étend pas les interactions ni
les fonctionnalités du cas d'utilisation "Réserver voyage".
 Les deux cas d'utilisation "Réservation voyage" et
"Réserver voyage par Internet" sont liés : la réservation
par Internet est un cas particulier de réservation.
 De façon générale en objet, une situation de cas
particulier se traduit par une relation de
137

138
Reserver voyage
Réserver voyage par téléphone Réserver voyage par Internet

Structuration entre cas d’utilisation
Résumé
Les cas peuvent être structurées par des relations :
 A inclut B : le cas A inclut obligatoirement le
comportement définit par le cas B; permet de
factoriser des fonctionnalités partagées
 A étend B : le cas A est une extension optionnelle du
cas B à un certain point de son exécution.
 A généralise B : le cas B est un cas particulier du cas A.
139

Relations entre cas d’utilisation : Exemple
Un client peut effectuer un retrait bancaire. Le retrait
peut être effectué sur place ou par Internet. Le
client doit être identifié (en fournissant son code
d’accès) pour effectuer un retrait, mais si le montant
dépasse 500DH, la vérification du solde de son
compte est réalisée.
140

Relations entre cas d’utilisation
141
<<include>>
<<extend>>
Virement
Virement par Internet
Virement sur place
Identification
Vérification solde compte
Client distant
Client local
Montant > 500 DH

Description des cas d’utilisation
 Le diagramme de cas d’utilisation décrit les grandes
fonctions d’un système du point de vue des acteurs.
 Mais il n’expose pas de façon détaillée le dialogue entre
les acteurs et les cas d’utilisation.
  nécessité de décrire ce dialogue
142

Deux façons sont couramment utilisées pour décrire les
cas d’utilisation :
 Description textuelle
 Description à l’aide d’un diagramme de séquence (voir
chapitre suivant)
143

Description des cas d’utilisation (description
textuelle)
 Identification
 Nom du cas : retrait d’argent
 Objectif : détaille les étapes permettant à un guichetier
d’effectuer des opérations de retrait par un client
 Acteurs : Guichetier (Principal), Système central
(Secondaire)
144

(description textuelle)
 Scénarios
 Scénario nominal
1. Le Guichetier saisit le numéro de compte client
2. L’application valide le compte auprès du SC
3. L’application demande le type d’opération au Guichetier
4. Le Guichetier sélectionne un retrait de 200 DH
5. Le système interroge le SC pour s’assurer que le compte est
suffisamment approvisionné.
6. Le SC effectue le débit du compte
7. Le système notifie au guichetier qu’il peut délivrer le
montant demandé
145

(description textuelle)
 Scénarios
 Scénario alternatif (exception)
1. En (5) : si le compte n’est pas suffisamment
approvisionné ….
146

Description des cas d’utilisation (description
par diagramme de séquence)
147
Saisie du numéro de compte client
Demande de validité de compte
OK
Demande type opération
Retrait(somme)
Compte suffisamment approviosionné
Débiter le compte
Compte débité
Autorisation de délivrer somme
Vérfification
Guichetier Système Central
Système

Intérêts des cas d’utilisation
Les CU obligent les utilisateurs à :
 Définir la manière dont ils voudraient interagir avec le
système
 Préciser quelles informations ils entendent échanger
avec le système
 Décrire ce qui doit être fait pour obtenir le résultat
escompté
148

UML use case class2UML use case class2.ppt

Contenu connexe

Similaire à UML use case class2UML use case class2.ppt

UML use case class2UML use case class2.ppt