Cour 2020 UML

3/17/2020
Modélisation Orientée Objet

par UML
ZAKRANI Abdelali
ENSAM – CASABLANCA
Année universitaire 2019-2020
Plan
 Introduction
◦ Cycle de vie d’un logiciel
◦ Approche objet
◦ Historique d’UML
 Diagrammes de l’UML
 Modélisation Fonctionnelle
◦ Diagramme de cas d’utilisation
ENSAM – Casablanca
ZAKRANI / MOO par UML / 14-15 3
1
3/17/2020
Introduction
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.
2
3/17/2020

 La qualité du logiciel dépend des activités de
production (les étapes):
◦ Analyse – Est-ce que le programme va rencontrer les besoins
de l’utilisateur (client)?
◦ Conception– Est-ce que la conception est efficace? Est-ce
que j’ai fait une bonne décomposition et créé une hiérarchie qui
est “lisible” hiérarchie de modules (haut niveau) et fonctions
(bas niveau)? Aie-je choisis le bon design?
◦ Implémentation – Est-ce que le code est solide, bien
documenté et complet?
◦ Tests – Est-ce que les tests sont suffisants?
◦ Maintenance – Changements avec effets secondaires

 Les cinq étapes que nous venons de voir sont souvent
représentés graphiquement comme une chute d’eau;
donc le modèle en cascade:
Analyse
Design
Implémentation
Tests
Maintenance
3
3/17/2020
Modélisation
 Un modèle est “une description complète d’un
système à partir d’une vue particulière”. Un modèle
est une simplification de la réalité.
Intérêt de la modélisation
 Modéliser le processus de développement
permet de
◦ Bien répartir les tâches et d'automatiser certaines d'entre elles ;
◦ Réduire les coûts et les délais ;
◦ Assurer un bon niveau de qualité et une maintenance efficace.
4
3/17/2020
Intérêt de la modélisation
 Modéliser un système avant sa réalisation permet de
◦ Comprendre le fonctionnement du système ;
◦ Maîtriser sa complexité ;
◦ Assurer sa cohérence ;
◦ Pouvoir communiquer au sein de l'équipe de
réalisation.
10
Démarches de modélisation pour le

logiciel
 Approche fonctionnelle
◦ Approche traditionnelle utilisant des procédures et
des fonctions.
◦ Les grand programmes sont ainsi décomposés en
sous programmes.
11
5
3/17/2020
Modélisation par décomposition

fonctionnelle
Approche descendante :
 Décomposer la fonction globale jusqu'à obtenir des
fonctions simples à appréhender et donc à programmer.
 C'est la fonction qui donne la forme du système
12
Critique de l'approche fonctionnelle
 Avantages :
◦ Organisée, réfléchie, logique.
◦ Ordonnée, réduit la complexité.
 Inconvénients :
◦ Comment assurer l'évolution du logiciel ?
◦ Comment réutiliser les parties déjà développées ?
◦ Comment structurer les données ?
13
6
3/17/2020
Approche Objet
 1966 : une idée à Oslo
 1980 : Smalltalk
 1988 : Schlaer/Mellor (OOSA)
 Les objets sont des entités autonomes qui collaborent
afin de fournir les fonctionnalités du système
 Les objets représentent des entités du monde réel de
l’application
14
Objectifs de l’approche Objet

 Architecture flexible
 Evolution du système
 Réutilisation des objets
 Etc
De 1989 à 1994
Plus de 50 méthodes d’analyse

et de conception orientées objet
15
7
3/17/2020
Unification des langages de

modélisation orientés objets
 Méthode = Démarche + Langage
 La guerre des méthodes ne fait plus avancer la technologie
des objets méthodes
 Recherche d’un langage commun unique

◦ Utilisable par toutes les méthodes
◦ Adapté à toutes les phases de développement
◦ Compatible avec toutes les techniques de réalisation
ZAKRANI / MOO par UML / 14 -15 16
16
Historique de l’UML 2.4.1
17
8
3/17/2020
Historique de l’UML (suite)

 Basée sur les méthodes de BOOCH, OMT et OOSE
 Influencée par les bonnes idées des autres méthodes
 Mûrie par le travail en commun
Gamma et al. Harel
HP Fusion
Frameworks, State charts
Description des opérations,
patterns et notes numérotation des messages
Booch
Booch methods Embley
Classes singleton
UML Objets composites
Rumbaugh
OMT Wirfs-Brok
Responsabilités (CRC)
Odell
Jacobson Shlear-Mellor Classification
OOSE Cycle de vie des
objets
18
En résumé
 UML est langage de modélisation, pas une méthode
 UML est un langage de modélisation objet
 UML convient pour toutes les méthodes objet
 UML est dans le domaine public
UML est le langage standard de

modélisation orientée objet
19
9
3/17/2020
Diagrammes UML
20
Diagrammes UML
 Il existe 2 types de vues du système qui comportent
chacune leurs propres diagrammes :
 Les vues statiques:
◦ diagrammes de cas d'utilisation
◦ diagrammes d'objets
◦ diagrammes de classes
◦ diagrammes de composants
◦ diagrammes de déploiement
 Les vues dynamiques:
◦ diagrammes de collaboration
◦ diagrammes de séquence
◦ diagrammes d'états-transitions
◦ diagrammes d'activités
ZAKRANI / MOO par UML 21
21
10
3/17/2020
Diagrammes UML
 Il existe 2 types de vues du système qui comportent chacune leurs
propres diagrammes :
22
Diagrammes de cas d’utilisation
 Formalisés par Ivar Jacobson: Object-Oriented Software

Engineering (Addison-Wesley, 1992)
 Expression du comportement du système (actions et de
réactions), selon le point de vue de l’utilisateur
 Décrivent le système et les relations entre le système et
l’environnement
23
11
3/17/2020
Intérêts des cas d’utilisation
 Constituent un moyen de déterminer les besoins d’un

système
 Utilisés par les utilisateurs finaux pour exprimer leur
attentes et leur besoins
 Permettent d’impliquer les utilisateurs dès les premiers
stades du développement
 Constituent une base pour les tests fonctionnels
24
Cas d’utilisation
Représentation graphique
25
12
3/17/2020
Cas d’utilisation (Exemple)

Diagramme de cas d’utilisation modélisant
une borne d’accès à une banque
26
Les acteurs
 Un acteur est une personne ou un système qui
interagit avec le système, en échangeant
l’information (en entrée et en sortie)
« actor » Acteur humain

Acteur non-humain
 On trouve des acteurs en observant les

utilisateurs directs du système, ceux qui sont
responsables pour sa maintenance, ainsi que les
autres systèmes qui interagissent avec le système.
27
13
3/17/2020
Acteurs – Les utilisateurs -

 Un acteur représente un rôle joué par un utilisateur qui
interagit avec le système.
 La même personne physique peut jouer le rôle de
plusieurs acteurs (vendeur, client).
 D’autre part, plusieurs personnes peuvent également
jouer le même rôle, et donc agir comme le même
acteur (tous les clients)
28
Acteurs et cas d’utilisation

 Les cas d’utilisation représentent le dialogue entre
l’acteur et le système de manière abstraite
 Ensemble de scénarios au sein d’une description unique
 Les cas d’utilisation doivent être vus comme des classes
de scénarios.
Représentation des scénarios
d’un cas d’utilisation
29
14
3/17/2020
Détermination des cas d’utilisation

 Quelles sont les tâches de l’acteur?
 Quelles informations l’acteur doit-il créer, sauvegarder,
modifier, détruire ou simplement lire?
 L’acteur devra-t-il informer le système de changements
externes?
 Le système devra-t-il informer l’acteur de conditions
internes au système?
30
Fiche de description textuelle d’un

cas d’utilisation
Sommaire Inclut titre, résumé, dates de création et de
d’identification modification,
(obligatoire) version, responsable, acteurs...
Description des Décrit le scénario nominal, les scénarios (ou

scénarios enchaînements) alternatifs, les scénarios (ou
(obligatoire) enchaînements) d’erreur, mais aussi les préconditions
et les postconditions.
Exigences non Ajoute, si c’est pertinent, les informations suivantes :
fonctionnelles fréquence, volumétrie, disponibilité, fiabilité, intégrité,
(optionnel) confidentialité, performances, concurrence, etc.
Précise également les contraintes d’interface
homme-machine comme des règles d’ergonomie, une
charte graphique, etc.
31
15
3/17/2020
Relations
 Include
Le comportement de B est obligatoire pour réaliser

le comportement de A
Exemple:
32
Relations (suite)
 Extend
Le comportement de B est optionnel et ne se déclenche
que par une condition dans le comportement de A
Exemple:
33
16
3/17/2020
Relations (suite)
 Généralisation
Le cas A est une abstraction du cas B
Exemple:
34
Relations (Exemple)
35
17
3/17/2020
Exercice 1
Choisissez et dessinez les relations entre les cas suivants :
1. Une agence de voyages organise des voyages où l’hébergement se fait en hôtel.
Le client doit disposer d’un taxi quand il arrive à la gare pour se rendre à l’hôtel.
Diagramme incomplet des cas

d’utilisation d’une agence de voyages
2. Certains clients demandent à l’agent de voyages d’établir une facture détaillée.

Cela donne lieu à un nouveau cas d’utilisation appelé « Établir une facture
détaillée ». Comment mettre ce cas en relation avec les cas existants ?
3. Le voyage se fait soit par avion, soit par train. Comment modéliser cela ?
36
Solution
1. Relations entre cas d’utilisation et cas
internes
Include
Include
Include
37
18
3/17/2020
Solution
2. Relation d’extension
38
Solution
3. Relation de généralisation
39
19
3/17/2020
Etude d’un Guichet Automatique de

Banque
Cette étude de cas concerne un système simplifié de Guichet Automatique de
Banque (GAB). Le GAB offre les services suivants :
1. Distribution d’argent à tout Porteur de carte de crédit, via un lecteur de
carte et un distributeur de billets.
2. Consultation de solde de compte, dépôt en numéraire et dépôt de
chèques pour les clients porteurs d’une carte de crédit de la banque
adossée au GAB.
N’oubliez pas non plus que :
3. Toutes les transactions sont sécurisées.
4. Il est parfois nécessaire de recharger le distributeur, etc.
À partir de ces quatre phrases, nous allons progressivement :
 identifier les acteurs ;
 identifier les cas d’utilisation ;
 construire un diagramme de cas d’utilisation ;
 décrire textuellement les cas d’utilisation ;
 compléter les descriptions par des diagrammes dynamiques ;
 organiser et structurer les cas d’utilisation.
40
Diagramme de cas d’utilisation complet du GAB
41
20
3/17/2020
Structuration des cas d’utilisation en packages
42
Description textuelle des cas d’utilisation
43
21
3/17/2020
Description scénario nominal
44
Description scénario nominal
45
22
3/17/2020
Description scénario alternatif
46
Description scénario d’échec
47
23
3/17/2020
Diagramme de séquence
48
Diagrammes d’interaction
 Les diagrammes d’interaction montrent comment des
instances au cœur du système communiquent pour
réaliser une certaine fonctionnalité.
 Les interactions sont nombreuses et variées
UML propose plusieurs diagrammes :

▪ diagramme de séquence,
▪ diagramme de communication,
▪ diagramme de timing.
Ils apportent un aspect dynamique à la modélisation du
système.
49
24
3/17/2020
 Diagramme de séquence permet de représenter les
interactions entre objets en indiquant la chronologie
des échanges. Cette représentation peut se réaliser par cas
d’utilisation en considérant les différents scénarios associés.
Les diagrammes de séquences présentent les intérêts
suivants :
▪ permettre de mieux comprendre le fonctionnement du
système; modéliser la vie des objets dans le temps et leur
chronologie ;
▪ d’être très utiles dans la description des cas d’erreur et
des cas limites d’utilisation du système
▪ d’être une aide précieuse pour documenter les méthodes
des classes.
50
Diag. Séq.: concepts de base

Nom du diagramme: Rôle de l’objet et le
Diagramme 1 nom de sa classe
sd: Sequence Diagram
Période
d’activité
de l’objet
Message
synchrone
Message
asynchrone
Message de
retour
Ligne de vie
51
25
3/17/2020

 Ligne de vie
Une ligne de vie représente l’ensemble des opérations
exécutées par un objet. Un message reçu par un objet
déclenche l’exécution d’une opération.
 Message synchrone et asynchrone
▪ Message synchrone: l’émetteur reste en attente de
la réponse à son message avant de poursuivre ses
actions.
▪ Message asynchrone: l’émetteur n’attend pas la
réponse à son message, il poursuit l’exécution de ses
opérations.
52

Création et destruction d’un objet
 La création d’objet est représentée par un message spécifique qui
donne lieu au début de la ligne de vie du nouvel objet.
 La destruction d’objet est un message envoyé à un objet existant et
qui donne lieu à la fin de sa ligne de vie. Il est représenté par une
croix.
53
26
3/17/2020

Contrainte temporelle
 Des contraintes de
chronologie entre les
messages peuvent être
spécifiées.
 De plus lorsque
l’émission d’un message
requiert une certaine
durée, il se représente
sous la forme d’un trait
oblique.
54
Diag. Séq.: Exemple

 Réalisons un diagramme de séquence système qui décrit le
scénario nominal du cas d’utilisation RETIRER DE L’ARGENT.
55
27
3/17/2020
Diag. Séq.: Exemple (suite)
56
Diag. Séq.: Exemple (suite)
57
28
3/17/2020
Fragment d’interaction
 Dans un diagramme de séquence, il est possible de
distinguer des sous-ensembles d’interactions qui
constituent des fragments.
 Un fragment d’interaction se représente
globalement comme un diagramme de séquence dans
un rectangle avec indication dans le coin à gauche du
nom du fragment.
 Un port d’entrée et un port de sortie peuvent être
indiqués pour connaître la manière dont ce fragment
peut être relié au reste du diagramme
58
 Exemple fragment d’interaction avec port d’entrée
et de sortie
Fragment
d’interaction
Port d’entrée
et port de
sortie
59
29
3/17/2020
 Fragment d’interaction combiné
Un fragment d’interaction dit combiné correspond à un
ensemble d’interaction auquel on applique un opérateur.
Treize opérateurs ont été définis dans UML :

 alt, opt, loop, par, strict/weak, break, ignore/consider, critical,
negative, assertion et ref.
60
Opérateur alt
L’opérateur alt correspond à une instruction de test avec
une ou plusieurs alternatives possibles. Il est aussi permis
d’utiliser les clauses de type sinon.
Alternative 1
Alternative 2
61
30
3/17/2020
Opérateur opt
L’opérateur opt (optional) correspond à une instruction
de test sans alternative (sinon).
62
Opérateur loop
 L’opérateur loop correspond à une instruction de
boucle qui permet d’exécuter une séquence
d’interaction tant qu’une condition est satisfaite.
63
31
3/17/2020
Opérateur par
 L’opérateur par (parallel) permet de représenter deux
séries d’interactions qui se déroulent en parallèle.
64
Opérateur strict/weak sequencing
Les opérateurs strict et weak permettent de représenter une série
d’interactions dont certaines s’opèrent sur des objets indépendants :
 L’opérateur strict est utilisé quand l’ordre d’exécution des opérations doit
être strictement respecté.
 L’opérateur weak est utilisé quand l’ordre d’exécution des opérations n’a
pas d’importance.
65
32
3/17/2020
Opérateur break
 L’opérateur break permet de représenter une situation exceptionnelle
correspondant à un scénario de rupture par rapport au scénario général.
Le scénario de rupture s’exécute si la condition de garde est satisfaite.
66
Opérateur ignore/consider
 Les opérateurs ignore et consider sont utilisés pour des fragments
d’interactions dans lesquels on veut montrer que certains messages
peuvent être soit absents sans avoir d’incidence sur le déroulement des
interactions (ignore), soit obligatoirement présents (consider).
67
33
3/17/2020
Opérateur critical
 L’opérateur critical permet d’indiquer qu’une séquence d’interactions ne
peut être interrompue compte tenu du caractère critique des opérations
traitées. On considère que le traitement des interactions comprises dans la
séquence critique est atomique.
68
Opérateur neg
 L’opérateur neg (negative) permet d’indiquer qu’une séquence
d’interactions est invalide.
69
34
3/17/2020
Opérateur assert
 L’opérateur assert (assertion) permet d’indiquer qu’une séquence
d’interactions est l’unique séquence possible en considérant les messages
échangés dans le fragment. Toute autre configuration de message est
invalide.
70
Opérateur ref.
 L’opérateur ref permet d’appeler une séquence d’interactions décrite par
ailleurs constituant ainsi une sorte de sous-diagramme de séquence.
71
35
3/17/2020
Opérateur ref. (Exemple)
72
du comportement du client banque
73
36
3/17/2020
Diagramme de classes
74
Concepts de l’approche Objet
Concept d’Objet
Un objet représente une entité du monde réel (ou du monde virtuel
pour les objets immatériels) qui se caractérise par un ensemble de
propriétés (attributs), des états significatifs et un comportement.
 L’état d’un objet correspond aux valeurs de tous ses attributs à un
instant donné.
 Les propriétés sont définies dans la classe d’appartenance de
l’objet.
 Le comportement d’un objet est caractérisé par l’ensemble des
opérations qu’il peut exécuter en réaction aux messages provenant
des autres objets. Les opérations sont définies dans la classe
d’appartenance de l’objet.
75
37
3/17/2020

Exemple:
Considérons l’employé Morad, n° 1245, embauché en tant qu’ingénieur
travaillant sur le site N.
 n° employé : 1245,
 nom : Morad,
 qualification : ingénieur,
 lieu de travail : site N.
➢ La liste des attributs: n° employé, nom, qualification et lieu de travail

➢ Les valeurs de ses attributs (1245, Morad, ingénieur, site N) est son
état.
➢ Son comportement est caractérisé par les opérations qu’il peut
exécuter.
 entrer dans l’organisme,  changer de lieu de travail
 changer de qualification,  sortir de l’organisme
76
Encapsulation
L’encapsulation consiste à regrouper dans une même classe
de la description de la structure des attributs et de la description des
opérations.
Les données ne sont accessibles qu’à partir d’opérations

définies dans la classe. Le principe d’encapsulation:
➢ renforce l’autonomie et l’indépendance de chaque classe
➢ donne une potentialité accrue de définition de classe réutilisable
77
38
3/17/2020
Concept de Classe
 Une classe est l’abstraction d’un ensemble d’objets qui possèdent
une structure identique (liste des attributs) et un même
comportement (liste des opérations).
 Un objet est une instance d’une et une seule classe. Une classe
abstraite est une classe qui n’a pas d’instance. Les concepts de
classe et d’objet sont interdépendants.
78

Exemple:
Considérons la classe Employé qui représente l’ensemble des employés
d’une entreprise.
La description de la classe Employé comportera les éléments suivants :
 Nom de classe : Employé.
 Attributs:
– numéro,
– nom,
– qualification,
– site de travail.
 Opérations :
– engager un employé,
– consulter un employé,
– modifier un employé,
– départ d’un employé.
79
39
3/17/2020

 Exemple d’objets physiques et d’objets de
gestion
Employé Morad Commande N° 22
80
Classes
 Une classe se représente à l’aide d’un rectangle comportant
plusieurs compartiments
Nom de la classe Voiture Employé

Marque
Attributs Puissance Exemple d’une
Opérations Exemple d’une description
Classe réduite à deux réduite à la
Responsabilités et compartiments désignation de la
/ ou exception classe
Description complète
81
40
3/17/2020
Classes
 Attribut:
Attribut est une propriété élémentaire d’une classe. Pour chaque
objet d’une classe, l’attribut prend une valeur.
Nom de la classe
Formalisme d’attributs de classe
Nom et caractéristique attribut1
…
Voiture Etudiant
Num_immatriculation: texte CNE: entier
Exemples d’attributs de classe
82
Classes
 Caractéristiques d’attribut:
Visibilité/Nom attribut : type [= valeur initiale {propriétés}]
– Visibilité : {+ (public), # (protégé), - (privé), ~ (package)}
– Nom d’attribut : nom unique dans sa classe.
– Type : type primitif (entier, chaîne de caractères…)– Valeur
initiale : valeur facultative donnée à l’initialisation d’un objet de la
classe.
– {propriétés} : valeurs marquées facultatives (ex. : «interdit» pour
mise à jour interdite).
 Attribut dérivé: est un attribut dont la valeur peut être calculer à
partir d’autres attributs de la classe. Il se note «/nom de l’attribut
dérivé ».
83
41
3/17/2020
Classes
 Opération
Une opération est une fonction applicable aux objets d’une classe.
Une opération permet de décrire le comportement d’un objet. Une
méthode est l’implémentation d’une opération.
Nom de la classe
Formalisme d’opérations de classe
…
Nom et caractéristique opération1
Nom et caractéristique opération2
…
Voiture Employé
marque: texte nom: texte
rouler(vitesse) consulter()
Exemples d’opérations de classe
84
Classes
 Caractéristique d’opération
Visibilité Nom d’opération (paramètres) [:[type résultat]
{propriétés}]
– Visibilité : {+ (public), # (protégé), - (privé), ~ (package)}
– Nom d’opération : utiliser un verbe représentant l’action à
réaliser.
– Paramètres : liste de paramètres (chaque paramètre peut être
décrit, en plus de son nom, par son type et sa valeur par défaut).
L’absence de paramètre est indiquée par ( ).
– Type résultat : type de (s) valeur(s) retourné(s) dépendant des
types disponibles dans le langage d’implémentation. Par défaut,
une opération ne retourne pas de valeur, ceci est indiqué par
exemple par le mot réservé « void » dans le langage C++ ou Java.
– {propriétés} : valeurs facultatives applicables (ex. : {query} pour
un comportement sans influence sur l’état du système).
85
42
3/17/2020
Classes
 Exemple de représentation d’une classe
Voiture
Nom de la classe
marque: texte
puissance: entier
Attributs
cylindrée: entier
année: entier
/ancienneté: entier
démarrer() Attribut dérivé
Opérations rouler() Ancienneté=
freiner() diff(année courante, année)
arrêter()
86
Classes
 Formalisme de représentation d’un objet
Nom de l’objet (1)
Nom de l’objet
souligné Valeur attribut 1
Valeur attribut 2 Valeurs des attributs
Valeur attribut N
Exemples de représentation d’objets

mavoiture mavoiture:Voiture :Voiture
renault renault
10 CV 10 CV
2L 2L
2001 2001
87
43
3/17/2020
Classes
 Visibilité des attributs et opérations
Les droits associés à chaque niveau de confidentialité sont :
 Public (+) – Attribut ou opération visible par tous.
 Protégé (#) – Attribut ou opération visible seulement à l’intérieur
de la classe et pour toutes les sous-classes de la classe.
 Privé (-) – Attribut ou opération seulement visible à l’intérieur de
la classe.
 Paquetage (~) – Attribut ou opération ou classe seulement
visible à l’intérieur du paquetage où se trouve la classe.
88
Classes
 Visibilité des attributs et opérations
89
44
3/17/2020
Classes
 Exemples de représentation des symboles de
visibilité
Voiture
- marque: texte
- puissance: entier
- cylindrée: entier
- année: entier
+ démarrer()
- rouler()
+ freiner()
# arrêter()
90
Lien et association
 Un lien est une connexion physique ou conceptuelle
entre instances de classes donc entre objets
 Une association décrit un groupe de liens ayant une
même structure et une même sémantique
 Un lien est une instance d’une association. Chaque
association peut être identifiée par son nom.
 Une association entre classes représente les liens
qui existent entre les instances de ces classes
91
45
3/17/2020
Lien et association
 Formalisme
Nom de la classe A Nom de la classe B

Nom de l’association 
 Exemple
Personne Voiture
Posséder 
92
Rôle de l’association
 Exemples
Personne Entreprise
Travailler dans
nom nom entreprise
prénom employé employeur adresse
Etudiant Université
Etudier à
CNE nom université
nom adresse
93
46
3/17/2020
Multiplicité
 La multiplicité indique un domaine de valeurs pour préciser le
nombre d’instance d’une classe vis-à-vis d’une autre classe pour
une association donnée
A * 0..1 B
A 2..10 1..* B
A 1,3 2..4 B
94
Multiplicité
 Exemples de multiplicité
Personne 1..* 0..1 Entreprise
Voiture 1 4 Roue
Etudiant 1..* 4..6 Module
95
47
3/17/2020
Navigabilité
 Exemples de navigabilité
Personne Copie
1 produit 1..5 d’examen
nom
X numéro copie
prénom
* vote 0..1
Electeur X Candidat
conduit
Conducteur train
96
Contraintes
 Les contraintes sont des propriétés proposées dans
l’UML pour préciser la sémantique d’une association
▪ Contrainte {ordered}
Pour une association de multiplicité supérieure à 1, les liens peuvent
être :
 non ordonnés (valeur par défaut),
 ordonnés ou triés lorsque l’on est au niveau de l’implémentation
(tri sur une valeur interne).
97
48
3/17/2020
Contraintes
 Exemples de contraintes: ordered, frozen, subset, xor,
98
Classe-association
 Classe d’association = Elément ayant à la fois les
propriétés d’une classe et d’une association
99
49
3/17/2020
Association n-aire
 Association n-aire = Une association parmi 3 classes
ou plus. Chaque instance de l’association est un n-tuple
de valeurs des classes respectives
100
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.
 On repré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é
Classe A Classe B
Agrégat Agrégé
101
50
3/17/2020
Agrégation
 Exemples d’agrégation Document
Pièce Equipe
1..*
1..*
1..* 1 Paragraphe
1..* 1..*
1..*
Mur Joueur 1..*
Phrase
102
Composition
Une composition est une agrégation plus forte impliquant
que :
 un élément ne peut appartenir qu’à un seul agrégat
composite (agrégation non partagée) ;
 la destruction de l’agrégat composite entraîne la
destruction de tous ses éléments (le composite est
responsable du cycle de vie des parties).
Classe A Classe B
Agrégat Agrégé
103
51
3/17/2020
Composition
 Exemples de composition
Répertoire Commande
1 1
1 1..*
0..*
En-tête Ligne
Fichier commandes
104
Généralisation et héritage
 La généralisation décrit une relation entre une classe
générale (classe de base ou classe parent) et une classe
spécialisée (sous-classe). La classe spécialisée est
intégralement cohérente avec la classe de base
Classe A Spécialisation Généralisation
(héritage)
Sous-classe A1 Sous-classe A2
105
52
3/17/2020
 L’héritage est la propriété qui fait bénéficier à une sous
classe de la structure et du comportement de sa
surclasse. Employé
nom
Exemple de prénom
date naissance
relation de
calcuerAge()
spécialisation
Employé horaire Employé salarié Vacataire

Taux horaire Taux hebdomadaire Taux journalier
Taux horaire
supplémentaire
Calculer paie() Calculer paie()
Calculer paie()
106
 Héritage multiple
Amphibie
107
53
3/17/2020
 Classe abstraite
Une classe abstraite est une classe qui n’a pas
d’instance directe mais dont les classes descendantes ont
des instances. Dans une relation d’héritage, la super-classe
est par définition une classe abstraite
108
Correspondance UML Java C#
109
54
3/17/2020
110
111
55
3/17/2020
112
113
56
3/17/2020
114
115
57
3/17/2020
116
117
58
3/17/2020
118
119
59
3/17/2020
120
121
60
3/17/2020
Diagramme d’états-transitions
122
 Les diagrammes d’états-transitions (ou statecharts)
d’UML décrivent le comportement interne d’un objet à
l’aide d’un automate à états finis
 Ils présentent les séquences possibles d’états et
d’actions qu’une instance de classe peut traiter au cours
de son cycle de vie en réaction à des événements
discrets (de type signaux, invocations de méthode).
 Ils sont bien adaptés à la description d’objets ayant un
comportement d’automate.
123
61
3/17/2020
Concepts de base
État-transition et événement
 L’état d’un objet est défini, à un instant donné, par
l’ensemble des valeurs de ses propriétés.
 Le passage d’un état à un autre état s’appelle transition.
Un événement est un fait survenu qui déclenche une
transition.
124
Concepts de base
État-transition et événement
Il existe quatre types d’événements :
 Type appel de méthode (call) – C’est le type le plus
courant que nous traiterons dans la suite de la
présentation.
 Type signal – Exemple : clic de souris, interruption
d’entrées-sorties…
 Type changement de valeur (vrai/faux) – C’est le
cas de l’évaluation d’une expression booléenne.
 Type écoulement du temps – C’est un événement
lié à une condition de type after(durée) ou when(date).
125
62
3/17/2020
Concepts de base
Exemple d’état-transition
Pour un employé donné d’une entreprise, nous pouvons

considérer les deux états significatifs suivants: état recruté,
état en activité.
126
Concepts de base
Action et activité
 Une action est une opération instantanée qui ne peut
être interrompue ; elle est associée à une transition.
 Une activité est une opération d’une certaine durée
qui peut être interrompue, elle est associée à un état
d’un objet.
Formalisme d’état-transition avec activité et action
Exemple d’état-transition avec activité et action
127
63
3/17/2020
Le diagramme d’états-transitions:
 Est l’enchaînement de tous les états caractéristiques
d’un objet
 Il débute toujours par un état initial et se termine par
un ou plusieurs états finaux sauf dans le cas où le
diagramme d’états représente une boucle
 À un événement peut être associé un message composé
d’attributs.
128
Exemple d’un diagramme d’état-transition de
l’objet client d’une gestion commerciale
129
64
3/17/2020
Composition et décomposition d’état
Il est possible de décrire un diagramme d’état-transition à
plusieurs niveaux
 Un premier niveau, le diagramme comprendra des états
élémentaires et des états composites.
 Les états composites seront ensuite décrits à un
niveau élémentaire dans un autre diagramme.
130
Exemple d’une composition et décomposition
d’état
131
65
3/17/2020
Point d’entrée et point de sortie
 Sur une sous-machine d’état, il est possible de repérer
un point d’entrée et un point de sortie particuliers.
132
Point de jonction
 Un point de jonction permet de décomposer une transition en
deux parties en indiquant si nécessaire les gardes propres à chaque
segment de la transition.
 À l’exécution, un seul parcours sera emprunté, c’est celui pour
lequel toutes les conditions de garde seront satisfaites.
133
66
3/17/2020
Point de choix
 Le point de choix se comporte comme un test de type : si
condition faire action1 sinon faire action2.
134
Etat historique
 La mention de l’historisation d’un état composite permet de
pouvoir indiquer la réutilisation du dernier état historisé en cas de
besoin.
135
67
3/17/2020
Diagramme d’activité
136
136
Diagramme d’activité (activity diagram)

Utilisation / objectifs
❖ Décrire des scénarios d’exécutions sous forme de
processus
▪ Enchainements non linéaire d’actions (diagramme de séquence =
scénario globalement linéaire)
▪ Point de vue centré sur des actions (un diagrammes de séquence
illustre des interactions)
❖ Permet d’identifier les principales actions à implémenter
et les enchainements entre ces actions
▪ Enchainement simple : fin d’une action, début d’une autre
▪ Décision : choix entre plusieurs enchainements possibles
▪ Synchronisation : enchainements en parallèle
137
137
68
3/17/2020
Contenu d’un diagramme d’activité
❖ Notation UML (1/2)

▪ Un seul point de départ (initial node)
▪ Action (non décomposable) ou activité
(décomposable)
▪ Flot de contrôle (control flow edge)
▪ Point d’arrivée (activity final)
❖ Attention
: apparence proche d’un
diagramme d’états mais contenu différent
▪ Nom des actions = verbes ou toute forme
désignant une d’action
▪ Nom d’un état = adjectifs ou toute forme
caractérisant un état
▪ Par défaut, une action démarre dès la fin de
l’action précédente
138
138
Contenu d’un diagramme d’activité

❖ Notation UML (2/2)
▪ Partitions
▪ Décision
▪ Synchronisation
▪ Début (fork node)
▪ Fin (join node)
▪ Objet avec un état
139
139
69
3/17/2020
Notion du diagramme d’activité

•Etat de départ
•Etat de terminaison
•Transition
•Transition Alternative
142
142
Synchronisation
disjonctive et
conjonctive
143
143
70
3/17/2020
Itération
144
144
Swimlanes
145
145
71
3/17/2020
Construction un diagramme d’activité

1. Identifiez la portée (« scope ») du diagramme d'activité
Commencez en identifiant ce que vous allez modéliser. Un seul use
case? Une partie d'un use case ? Un « workflow » qui inclut
plusieurs use cases ? Une méthode de classe ?
2. Ajouter l’état de départ et de terminaison
3. Ajouter les activités
Si vous modélisez un use case, introduisez une activité pour chaque
use case principal. Si vous modélisez un « workflow », introduisez
une activité pour chaque processus principal, souvent un use case.
Enfin, si vous modélisez une méthode, il est souvent nécessaire
d’avoir une activité pour chaque grand étape de la méthode.
4. Ajouter des transitions (séquentielles), des transitions
alternatives (conditionelles), des synchronisations entre
des activités, des itérations.
5. Identifier des swimlanes et répartir des activités
identifiées dans ces swimlanes.
146
146
Exercice 1: Cafetière
 Construire un diagramme d’activité
représentant l’utilisation d’une cafetière
électrique:
◦ Premier état: chercher du café
◦ Dernier état: Servir du café
147
147
72
3/17/2020
148
Exercice 2: Commander un produit

 Construire un diagramme d’activité pour modéliser le
processus de commander d’un produit. Le processus
concerne les acteurs suivants:
◦ Client: qui commande un produit et qui paie la facture
◦ Caisse: qui encaisse l’argent du client
◦ Vente: qui s’occupe de traiter et de facturer la commande du
client
◦ Entrepôt: qui est responsable de sortir les articles et
d’expédier la commande.
150
150
73
3/17/2020
MonAuto : Use Case

Le logiciel de gestion des réparations est destiné en priorité au chef d'atelier,
il devra lui permettre de saisir les fiches de réparations et le travail
effectué par les divers employés de l'atelier.
Pour effectuer leur travail, les mécaniciens et autres employés de l'atelier
vont chercher des pièces de rechange au magasin. Lorsque le logiciel sera
installé, les magasiniers ne fourniront des pièces que pour les véhicules
pour lesquels une fiche de réparation est ouverte; ils saisiront directement
les pièces fournies depuis un terminal installé au magasin.
Lorsqu'une réparation est terminée, le chef d'atelier va essayer la voiture. Si
tout est en ordre, il met la voiture sur le parc clientèle et bouclera la fiche
de réparation informatisée. Les fiches de réparations bouclées par le chef
d'atelier devront pouvoir être importées par le comptable dans le logiciel
comptable.
Créer un diagramme d’activité pour tout le traitement d’une réparation.
152
152
MonAuto : Use Case

Exercice 2. Créer un diagramme d’activité pour le use case
« Créer une fiche de réparation »
Pour créer une fiche de réparation, le chef d’atelier saisit les
critères de recherche de voitures dans le système. Le logiciel
de gestion des réparation lui donne la liste des voitures
correspondant aux critères entrés. Si la voiture existe, le chef
d’atelier va sélectionner la voiture. Le logiciel va, ensuite,
fournir les informations sur le véhicule. Si la voiture est sous
garantie, le chef devra saisir la date de demande de réparation.
Si la voiture n’existe pas, le chef va saisir les informations
concernant ce nouveau véhicule. Dans tous les cas, le chef
d’atelier devra saisir la date de réception et de restitution. Si
le dommage de la voiture est payé par l’assurance, le logiciel
va fournir une liste d’assurances au chef d’atelier. Ce dernier
sélectionnera l’assurance adéquate. Enfin, le logiciel enregistre
la fiche de réparation.
154
154
74
3/17/2020
Exercice
Recette simplifiée : commencer par casser le chocolat
en morceaux, puis le faire fondre.
En parallèle, casser les œufs en séparant les blancs des
jaunes.
Quand le chocolat est fondu, ajouter les jaunes d’œuf.
Battre les blancs en neige jusqu’à ce qu’ils soient bien fermes.
Les incorporer délicatement à la préparation chocolat sans
les briser.
Verser dans des ramequins individuels.
Mettre au frais au moins 3 heures au réfrigérateur avant de
servir.
Représentez par un diagramme d’activité la recette de la
mousse au chocolat… Proposez d’abord une version simple,
en supposant que vous avez des ressources illimitées, puis
une version avec deux personnes. Complétez ensuite le
diagramme en ajoutant soit des flots d’objets
156
Exercice GAB
Réalisez un diagramme d’activité qui décrit la
dynamique du cas d’utilisation RETIRER DE
L’ARGENT.
161
75

Cour 2020 UML

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cour 2020 UML

Transféré par

Droits d'auteur :

Formats disponibles

3/17/2020

Modélisation Orientée Objet

Cycle de vie d’un logiciel

Cycle de vie d’un logiciel

Cycle de vie d’un logiciel

Démarches de modélisation pour le

Modélisation par décomposition

Critique de l'approche fonctionnelle

Objectifs de l’approche Objet

Plus de 50 méthodes d’analyse

Unification des langages de

 Recherche d’un langage commun unique

Historique de l’UML 2.4.1

Historique de l’UML (suite)

UML est le langage standard de

Diagrammes de cas d’utilisation

 Formalisés par Ivar Jacobson: Object-Oriented Software

Intérêts des cas d’utilisation

 Constituent un moyen de déterminer les besoins d’un

Cas d’utilisation (Exemple)

« actor » Acteur humain

 On trouve des acteurs en observant les

Acteurs – Les utilisateurs -

Acteurs et cas d’utilisation

ZAKRANI / MOO par UML 29

Détermination des cas d’utilisation

ZAKRANI / MOO par UML 30

Fiche de description textuelle d’un

Description des Décrit le scénario nominal, les scénarios (ou

ZAKRANI / MOO par UML 31

Le comportement de B est obligatoire pour réaliser

ZAKRANI / MOO par UML 32

ZAKRANI / MOO par UML 33

ZAKRANI / MOO par UML 34

ZAKRANI / MOO par UML 35

Diagramme incomplet des cas

2. Certains clients demandent à l’agent de voyages d’établir une facture détaillée.

ZAKRANI / MOO par UML 37

ZAKRANI / MOO par UML 38

ZAKRANI / MOO par UML / 13-14 39

Etude d’un Guichet Automatique de

ZAKRANI / MOO par UML 40

ZAKRANI / MOO par UML / 14-15 41

Structuration des cas d’utilisation en packages

ZAKRANI / MOO par UML 42

Description textuelle des cas d’utilisation

ZAKRANI / MOO par UML 43

Description scénario nominal

ZAKRANI / MOO par UML / 14-15 44

ZAKRANI / MOO par UML 45

Description scénario alternatif

ZAKRANI / MOO par UML 46

ZAKRANI / MOO par UML / 14-15 47

ZAKRANI / MOO par UML 48

UML propose plusieurs diagrammes :

ZAKRANI / MOO par UML 49

ZAKRANI / MOO par UML 50

Diag. Séq.: concepts de base

ZAKRANI / MOO par UML 51

Diag. Séq.: concepts de base

ZAKRANI / MOO par UML 52

Diag. Séq.: concepts de base

ZAKRANI / MOO par UML 53