INTRODUCTION A UML

Moussa LO
UFR de Sciences Appl. & de Technologie
UGB de Saint-Louis

M. Lo – Introduction à UML – 02/2008 1

 Bibliographie

• Intégrez UML dans vos projets, N. Lopez, J. Migueis, E.

Pichon, Eyrolles, 1998.
• Modélisation objet avec UML, P. Muller, Eyrolles, 1998.
• UML 2 en action, P. Roques, F. Vallée, Eyrolles, 2004
• UML 2, Initiation, exemples et exercices corrigés, L.
Debrauwer, F. V. der Heyde, ENI, 2005.
• UML 2, Entraînez-vous à la modélisation, L. Debrauwer, N.
Karam, ENI, 2005.

M. Lo – Introduction à UML – 02/2008 2

 Webographie

• UML @ site de l’OMG, http://www.uml.org/.

• UML en français, http://uml.free.fr/.
• UML @ developpez.com, http://uml.developpez.com/
• UML @.wikipedia, http://fr.wikipedia.org/wiki/Unified_Modeling_Language
• Support de cours UML de F. Julliard, Université de Bretagne
Sud, 2002.

• Support de cours UML de Y. Laloum, CNAM.

M. Lo – Introduction à UML – 02/2008 3

 UML (Unified Modeling Language )

• Résultat de la fusion de plusieurs modèles de

conception objet comme :

OMT (J. Rimbaugh),

BOOCH (G. Booch),

OOSE (I. Jacobson), etc.

• Adopté et normalisé par l’OMG (Object Management

Group) en 1997.
• Représentation standardisée d’un système orienté
objet.
M. Lo – Introduction à UML – 02/2008 4
 UML (Unified Modeling Language )

• UML ≠ Méthode de conception

• UML = notation graphique normalisée de présentation

de certains concepts pour modéliser des systèmes objets.

• Peut être utilisée avec tout processus de développement

objet.

M. Lo – Introduction à UML – 02/2008 5

 UML (Unified Modeling Language )

• La version actuelle de UML (2) s’articule autour de 13

diagrammes.

 4 ont été introduits dans UML 2, Juillet 2005.

• Chaque diagramme fournit une représentation du

système suivant un point de vue particulier.

M. Lo – Introduction à UML – 02/2008 6

 UML (Unified Modeling Language )

• UML modélise le système suivant 2 modes de

représentation (nécessaires et complémentaires):
 Mode statique (ou structurel) : concerne la structure
du système pris au repos.
 Mode dynamique (ou comportemental) : concerne la
dynamique de fonctionnement du système.

 UML schématise la manière dont le système est composé

et comment ses composantes sont liées.

M. Lo – Introduction à UML – 02/2008 7

 Les 7 diagrammes UML de structure
 Use cases : description des fonctionnalités du point de vue user
 Classes : structuration des entités manipulées par les
utilisateurs (classes, interfaces)
 Packages : hiérarchie des modules du système (UML 2)
 Objets : illustration des structures de classe complexes en
montrant des exemples d’instances et leurs relations
 Structure composite : description de la composition d’un objet
complexe lors de son exécution (UML 2)
 Composants : architecture des composants physiques du
système
 Déploiement : description de l’installation des composants du
système sur le matériel et sur le réseau
M. Lo – Introduction à UML – 02/2008 8
 Les 6 diagrammes UML de comportement

 Etats : représentation du cycle de vie commun aux objets d’une

même classe.
 Activités : règles d’enchaînement des activités du système.
 Séquences : description d’échanges de messages entre objets
dans le cadre d’un fonctionnement particulier du système;
représentation des scénarios d’utilisation du système.
 Communication (ou collaboration) : représentation simplifiée
du diagramme de séquence.
 Global d’interactions : association entre diagrammes de
séquence et d’activités (UML 2).
 De temps : description de contraintes tps-réel délicates (UML 2).
M. Lo – Introduction à UML – 02/2008 9
 Quelques outils UML

 Rational Rose, http://www-306.ibm.com/software/rational/

 WinDesign, http://www.win-design.com/

 Objecteering/UML, http://www.objecteering.com/
 Poseidon, http://www.gentleware.com/

 ArgoUML, http://argouml.tigris.org/

 EclipseUML, http://www.eclipsedownload.com/

M. Lo – Introduction à UML – 02/2008 10

 Les cas d’utilisation d’UML

analyse

spécifications Use cases

tests

M. Lo – Introduction à UML – 02/2008 11

 Use cases d’UML
• Modélisation de processus métiers en les découpant
en cas d’utilisation.
• Représentation des fonctionnalités du système.
• Composé :
 d’acteurs :

utilisateurs du système à représenter

rôle joué par une personne ou une chose extérieure qui
interagit avec le système
 de cas d’utilisation :

fonctionnalités proposées par le système

« classes » dont les instances sont des scénarios

M. Lo – Introduction à UML – 02/2008 12

 Cas d’utilisation d’un GAB

Exemple tiré de « Introduction à UML, Y. Laloum, CNAM »

M. Lo – Introduction à UML – 02/2008 13

 Les acteurs
• Représentent la frontière entre :

les éléments constitutifs de l’application

les éléments extérieurs à l’application

• Un acteur est un élément extérieur au système qui

interagit avec ce dernier.
• L’identification des acteurs permet d’avoir une vue
orientée utilisateur du système.
• Acteurs primaires : utilisateurs du système
• Acteurs secondaires : administrateurs du système
• Un acteur possède un rôle.
M. Lo – Introduction à UML – 02/2008 14
 Représentation UML des acteurs / système
Exemple d’une application bancaire

Guichetier
(enregistre les
opérations Responsabl
courantes) e des

? devises
(fournit les
infos sur le
cours des
Directeur devises)
(fait le bilan
journalier)

RQ : On ne représente pas les relations entre les acteurs.

M. Lo – Introduction à UML – 02/2008 15

 Les acteurs
• Humains :
 Utilisateurs du logiciel (via l’interface graphique)

• Logiciels :
 Autres logiciels qui interagissent avec le logiciel

• Matériels :
 Matériels qui exploitent les données du logiciel ou qui sont
pilotés par le logiciel
 Ne pas confondre acteur et personne utilisant le système :
 Une même personne peut jouer plusieurs rôles
 Plusieurs personnes peuvent jouer un même rôle
M. Lo – Introduction à UML – 02/2008 16
 Définition d’un acteur
• Pour chaque acteur :
 choisir un identificateur représentatif du rôle
 mettre, éventuellement, une brève description textuelle

M. Lo – Introduction à UML – 02/2008 17

 Les use cases (cas d’utilisation)

• Quelles sont les vues que les acteurs identifiés ont du

système ?
 Identifier les fonctionnalités du système
• Use case :
 représente une fonctionnalité déclenchée suite à une action
initiée par un acteur.
 correspond à une manière spécifique d’utiliser le système.

 suite d’interactions entre un acteur et le système

 décrit un ensemble de scénarios

M. Lo – Introduction à UML – 02/2008 18
Acteur et use case

M. Lo – Introduction à UML – 02/2008 19

 Représentation textuelle d’un use case

• Pour documenter les CA, la description textuelle est

indespensable afin de communiquer facilement avec les
utilisateurs.

• Rubriques habituelles obligatoires :

 Nom : verbe à l’infinitif décrivant une intercation

entre un acteur et le système.

 Résumé : brève description du CA.

 Acteurs : liste des acteurs interagissant avec le CA.

 Description : texte explicatant le CA.

M. Lo – Introduction à UML – 02/2008 20

 Représentation textuelle d’un use case

• Rubriques habituelles optionnelles :

 Pré-conditions : conditions nécessaires pour
déclencher le CA.

 Post-conditions : conditions remplies après

l’exécution du CA (état du système après réalisation
du CA).

 Exceptions : décrit les éventuelles exceptions levées.

(Un CA décrit le comprtement du système lorsqu’il n’y a pas
d’exception.)

M. Lo – Introduction à UML – 02/2008 21

 Représentation textuelle d’un use case

 Use case “ Retrait en espèces “

• Nom : Retrait en espèces
• Acteurs : Guichetier
• Description :
 Le guichetier saisit le numéro de compte du client.
 L’application vérifie la validité du numéro de compte et
demande le type d’opération au guichetier.
 Le guichetier sélectionne un retrait d’espèces d’un certain
montant.
 L’application vérifie que le montant est disponible dans le
compte. Si oui, elle débite le compte et informe le guichetier
qu’il peut donner la somme au client.
M. Lo – Introduction à UML – 02/2008 22
Exemples de diagramme de use cases

M. Lo – Introduction à UML – 02/2008 23

Exemples de diagramme de use cases

M. Lo – Introduction à UML – 02/2008 24

 Relations entre use cases
 2 types de relations :
• Extension (extends)
• Utilisation (uses ou include)

M. Lo – Introduction à UML – 02/2008 25

 La Relation extends
• Tous les use cases fils
• sont des cas particuliers du use case père
• héritent des caractéritisques du père

M. Lo – Introduction à UML – 02/2008 26

 La Relation uses
• Permet de décomposer un use case complexe
en plusieurs use cases plus simples.

M. Lo – Introduction à UML – 02/2008 27

Relations entre use cases : exemple tiré de Y. Laloum

M. Lo – Introduction à UML – 02/2008 28

 Les use cases (cas d’utilisation)

 L’ensemble des cas d’utilisation d’un système

contient:

les exigences fonctionnelles attendues ou existantes

les acteurs

les relations qui unissent acteurs et fonctionnalités.

 Les cas d’utilisation servent de support pour les étapes

de modélisation, de développement et validation.
 Référentiel du dialogue entre les informaticiens et les
clients.
 Base pour l’élaboration du cahier des charges.
M. Lo – Introduction à UML – 02/2008 29
 Exemple : distributeur automatique

On considère un distributeur automatique de produits

courants (bonbons, boissons, etc.).

Une fois qu’il a choisi les produits qu’il désire acheter, le

client doit ensuite payer ses achats, soit en espèces,
soit par carte bancaire.

Lors de l’achat d’un produit alimentaire, le client verifier

la date limite de consommation du produit.

M. Lo – Introduction à UML – 02/2008 30

Exemple : distributeur automatique

M. Lo – Introduction à UML – 02/2008 31

Les scénarios

M. Lo – Introduction à UML – 02/2008 32

 Scénarios

• “Série d’évènements ordonnés dans le temps simulant

une éxécution particulière du système”, Lopez, Migueis,
Pichon.

• “Ensemble ordonné de messages échangés par des

objets (instance de classe ou d’acteur)”, Roques, Vallée.
• Instance de cas d’utilisation.
• Permettent d’expérimenter les exécutions du système
 très utiles lors des tests.

M. Lo – Introduction à UML – 02/2008 33

 Scénarios

Pour chaque cas d ’utilisation, il existe un ou plusieurs
scénarios dont la description permet d’expliciter le
comportement du système pour une situation donnée.
Exemple (tiré de Y. Laloum)

M. Lo – Introduction à UML – 02/2008 34

 Représentation d’un scénario
Un scénario peut être représenté par un diagramme de
séquence.

Exemple de diagramme de séquence

Le diagramme de séquence se focalise sur les aspects temporels.

M. Lo – Introduction à UML – 02/2008 35

 Représentation d’un scénario
Un scénario peut être aussi représenté par un diagramme
de communication (diagramme de collaboration dans
UML 1).

Exemple de diagramme de communication

Le diagramme de communication se focalise sur la représentation

spatiale.
M. Lo – Introduction à UML – 02/2008 36
Le diagramme de séquence

M. Lo – Introduction à UML – 02/2008 37

 Diagramme de séquence

• Décrit la dynamique d’une sous-fonction du système.

• La dynamique globale d’un système nécessite

plusieurs diagrammes de séquences.

• Modélise les messages échangés entre objets en

mettant l’accent sur la chronologie des messages.

• Décrit les interactions entre un groupe d’objets en

montrant, de façon séquentielle, les envois de message
qui interviennent entre les objets.
M. Lo – Introduction à UML – 02/2008 38
 Diagramme de séquence : messages

• Pour interagir entre eux, les objets s’envoient des

messages.

Lors de la réception d’un message, un objet devient actif et
exécute la méthode appropriée.

Envoi de message = appel de méthode

• Message : spécification d’une communication

unidirectionnelle entre objets qui transporte de
l’information avec intention de déclencher une réaction
chez le récepteur.
M. Lo – Introduction à UML – 02/2008 39
 Diagramme de séquence : ligne de vie

• Le diagramme de séquence fait entrer en action les

instances des classes intervenant dans la réalisation de
la sous-fonction qui lui est liée.

• A chaque instance est associée une ligne de vie qui

montre ses actions et réactions, ainsi que les périodes
durant lesquelles elle est active.

M. Lo – Introduction à UML – 02/2008 40

Diagramme de séquence : ligne de vie

nom de l’objet et Le nom de l’objet est

de sa classe optionnel

nom objet : Classe

période d’activité
de l’objet

ligne de vie de l’objet

Un diagramme de séquence contient plusieurs lignes de vie.

M. Lo – Introduction à UML – 02/2008 41

 Diagramme de séquence : messages

• Les envois de message sont représentés par des

flèches horizontales reliant la ligne de vie de l’objet
émetteur à celle de l’objet destinataire.

objet_1 : Classe objet_2 : Classe

message

M. Lo – Introduction à UML – 02/2008 42

 Diagramme de séquence : messages

• La transmission d’informations est possible.

objet_1 : Classe objet_2 : Classe

message (donnee1, donnee2)

M. Lo – Introduction à UML – 02/2008 43

 Diagramme de séquence : messages
3 catégories de messages :

• Synchrone (appel) : invocation d’une opération;

l’émetteur donne la main au récepteur et est bloqué jusqu’au
traitement effectif du message.

• Asynchrone (signal) : communication explicite entre 2

objets; l’émetteur n’est pas bloqué et peut poursuivre son
exécution. (cas des systèmes multi-thread).

• De retour : retour du résultat d’une fonction

M. Lo – Introduction à UML – 02/2008 44

 Diagramme de séquence : messages

Auto-envoi de message :

Un objet peut s’envoyer un message.

objet : Classe

M. Lo – Introduction à UML – 02/2008 45

 Diagramme de séquence : messages

Creation et destruction d’un objet :

• Création d’objet : message spécifique qui donne

lieu au début de la ligne de vie du nouvel objet.

• Destruction d’objet : message envoyé à un objet

existant et qui donne lieu à la fin de sa ligne de vie.
Représenté par une croix.

M. Lo – Introduction à UML – 02/2008 46

 Diagramme de séquence : messages

Creation et destruction d’un objet :

objet_1 : Classe

objet_2 : Classe

M. Lo – Introduction à UML – 02/2008 47

Exemple : distributeur automatique

M. Lo – Introduction à UML – 02/2008 48

Le diagramme de classes

M. Lo – Introduction à UML – 02/2008 49

 Diagramme de classes

• Permet de définir l’ensemble des classes et leurs

relations.

• Une classe est représentée par un rectangle séparé en 3

parties :
 La 1ière partie contient le nom de la classe
 La 2e partie contient les attributs de la classe
 La 3e partie contient les méthodes de la classe

• Pour des raisons de lisibilité, on peut masquer ou non

une de ces parties
M. Lo – Introduction à UML – 02/2008 50
 Diagramme de classes : représentation d’une classe

public class Etudiant {

public String nom;
public String prenom;
private String numero_ins;

public Etudiant(String nom) {

this.nom = nom;
}

public String getNumIns() { return this. numero_ins; }

public void setNumIns(String numero_ins) {
if (numero_ins==null || numero_ins.length!=11) return;
this.numero_ins = numero_ins;
}

public void afficher(){

System.out.println(“etudiant :”+ nom);
}
}
M. Lo – Introduction à UML – 02/2008 51
Diagramme de classes : représentation d’une classe

Nom Classe
attribut1 : type
attribut2 : type = valeur
methode1(args)
methode2():type

M. Lo – Introduction à UML – 02/2008 52

 Diagramme de classes : visibilité

• (+) public : accessible par toutes les classes.

• (-) private : accessible que par les seules méthodes de

sa classe.

• (#) protected : accessible par les classes du même

package.

M. Lo – Introduction à UML – 02/2008 53

 Diagramme de classes : association

• Une association représente une relation structurelle

entre classes d’objets.

• On représente une association en traçant une ligne

entre les classes associées.

M. Lo – Introduction à UML – 02/2008 54

 Diagramme de classes : association

• Association ternaire :

Classe1 Classe2

Classe3

M. Lo – Introduction à UML – 02/2008 55

 Diagramme de classes : association

Types de multiplicité des associations

1 : un et un seul
0 .. 1 : zéro ou un
m .. n : de m à n
* : de zéro à plusieurs
0 .. * : de zéro à plusieurs
1 .. * : de un à plusieurs
N : exactement N

M. Lo – Introduction à UML – 02/2008 56

 Diagramme de classes : association

• Classe Association :

Classe1 Classe2

ClasseAssociation

M. Lo – Introduction à UML – 02/2008 57

 Diagramme de classes :
composition/agregation

• Composition :

Les composants font partie de l’objet composé.

Chaque composant ne peut être partagé entre
plusieurs objets composés.
• Agregation :

Composition faible.

Les composants peuvent être partagés par plusieurs
composés.
M. Lo – Introduction à UML – 02/2008 58
Diagramme de classes :
composition/agregation

M. Lo – Introduction à UML – 02/2008 59

Diagramme de classes : héritage

M. Lo – Introduction à UML – 02/2008 60

Diagramme de classes : interfaces

M. Lo – Introduction à UML – 02/2008 61

 Les diagrammes d’objets et
de structure composite

• Complètent le diagramme de classe.

• Les diagrammes d’objets servent à illustrer des

structures de classes compliquées en montrant des
exemples d’instance.

• Les diagrammes de structure composite permettent

de décrire la composition d’un objet complexe lors
de l’exécution.

M. Lo – Introduction à UML – 02/2008 62

 Diagramme de packages

• Un package est un ensemble de classes et d'autres

packages regroupés sous un nom.
• C'est l'adaptation du concept de librairie ou de
bibliothèque.
• Servent à structurer l’ensemble des classes et
interfaces.
• Permet de structurer un système en plusieurs parties,
chacune représentée par un package .

M. Lo – Introduction à UML – 02/2008 63

Diagramme de packages

M. Lo – Introduction à UML – 02/2008 64

Diagramme de packages

M. Lo – Introduction à UML – 02/2008 65

 Le diagramme d’états
Représente le cycle de vie commun aux objets d’1 même classe.

Exple : Situation
professionnelle
d’une personne

M. Lo – Introduction à UML – 02/2008 66

 Le diagramme d’états : état

• Moment du cycle de vie d’un objet.

• Dans un état, un objet peut être Actif ou Inactif :

• Inactif : attend un signal provenant d’autres objets

• Actif : réalise une activité (exécution d’une série de

méthodes liée à un objectif)

• Le changement d’état est déclenché par un

évenement : réception d’un message.

M. Lo – Introduction à UML – 02/2008 67

 Le diagramme d’états : transition

• Lien orienté entre 2 états qui exprime le fait que

l’objet a la possibilité de passer d’un état d’origine à
un état de destination.
• Généralement associée à un évènement.

M. Lo – Introduction à UML – 02/2008 68

 Le diagramme d’états : exemple

Lettre recommandée

M. Lo – Introduction à UML – 02/2008 69

 Le diagramme d’activités

• Permet de représenter graphiquement le comportement

d’une méthode ou le déroulement d’un cas
d’utilisation.
• Il est composé :
• d’un noeud initial
• d’activités liées entre elles par des évènements
• se termine par un noeud final

M. Lo – Introduction à UML – 02/2008 70

 Le diagramme d’activités

• Forme spécifique du diagramme d’états-transitions

dans lequel :
 chaque état est associé à une activité
 toutes les transitions sont automatiques (enchaînements)

• Activité : série d’actions.

• Action :
 Affecter une valeur à un attribut,
 Créer ou détruire un objet,
 Effectuer une operation, etc.
M. Lo – Introduction à UML – 02/2008 71
 Le diagramme d’activités : exemple

• Authentification d’un utilisateur.

M. Lo – Introduction à UML – 02/2008 72

 Le diagramme de composants

• Décrit les composants et leurs dépendances dans

l’environnement de réalisation.

• Vue statique de l’implémentation des systèmes qui

montrent les choix de réalisation.

• En général, il n’est utilisé que pour des systèmes

complexes.

M. Lo – Introduction à UML – 02/2008 73

 Diagramme de composants
Modélisation de l’architecture logicielle et sa
structuration en composants.

M. Lo – Introduction à UML – 02/2008 74

 Les diagramme de déploiement

• Montre la disposition physique des différents matériels

– les noeuds – qui entrent dans la composition d’un
système et la répartition des instances de composants,
processus et objets qui « fonctionnent » sur ces
matériels.

• Modélisation de l’architecture matérielle.

• Très utile pour des systèmes distribués.

M. Lo – Introduction à UML – 02/2008 75

Le diagramme de déploiement

M. Lo – Introduction à UML – 02/2008 76