Introduction au langage de

modélisation UML (Unified

Modeling Language)
PR. MAHRAZ MED ADNANE
Sommaire

1. Généralités : Modélisation et
approche O.O.

2. UML : Langage de modélisation

3. RUP : Processus de modélisation

INTRODUCTION

L‘ingénierie des systèmes d’information

INGENIERIE DES BESOINS

Élucidation des besoins

Système
réel modélisation INGENIERIE DU LOGICIEL
conception
validation Schéma
conceptuel production

vérification Système
logiciel
Domaine du problème

Domaine de la solution
INTRODUCTION
Point de vue historique

(milieu des années 60)

"Crise du logiciel" : L'ingénierie du logiciel comme
une discipline
Facteurs d‘évolution
 Coût du logiciel / coût du matériel
 Le logiciel considéré comme un produit ayant son cycle de vie
 Nécessité d’avoir des Méthodes
INTRODUCTION
Composants d’une méthode de construction d’un systèmes d’information

MODÈLES
Décrire
les données et
les traitements
OUTILS
DÉMARCHE
manuels
Les étapes
automatisés

Méthode de
construction
d’un S.I
 Processus de développement

Conception
• Comprendre le • Réaliser la
problème en • Concevoir une solution
solution en
terme de métier informatique en terme terme de
du client. de responsabilité programme.
fonctionnelle.

Analyse Implémentation
INTRODUCTION
Des méthodes fonctionnelles aux méthodes Objet

 L’orientation fonctionnelle (années 1970)

 Programmation structurée, méthodes d’analyse structurées.

 L’orientation conceptuelle (années 1980)

 méthodes de conception systémique (Données et traitement)

 L’orientation Objet (les années 1990)

 Programmation Objet, SGBD Objet, méthodes d’analyse et de
conception orientée Objet
INTRODUCTION
La prolifération des méthodes objets
 1990: Naissance d'une cinquantaine de
méthodes orienté objet.
 Confusion autour de l’analyse et de la conception.
 Idée: Examen des méthodes dominantes pour
permettre de dégager un consensus autour
d’idées communes.
Rapprochement de 2 méthodes : OOAD de
Grady Booch et OMT de Rumbaugh & Al
 L’unification des méthodes :
Principales étapes de la définition d’UML
Standardisation par l’OMG UML 1.3

1997, Soumission à l’OMG UML 1.0

OOPSLA’96
UML 0.9

OOPSLA’95 Méthode unifiée 0.8

Booch’93 OMT-2

OMT-1 OOSE Partenaires

Autres méthodes Booch’91
Rumbaugh’91 Jacobson’92 Rational
L’orientation Objet
 Les principes de base de l’orientation objet :
 Les objets, les classes, envoi de messages, l’encapsulation
 l’héritage, le polymorphisme
 Organisation d’un système en une collection d’objets
dissociés mais collaborant entre eux
OBJET CLASSE
Classe 2
Classe 3
objet2
Classe 1
objet1

objet3
Classe 4
Classe 31 Classe 32

objet4

Une architecture logicielle

Pourquoi l’approche objet ?

 But
 modélisation des propriétés statiques et dynamiques de
l’environnement dans lequel sont définis les besoins (domaine
du problème),
 formalisation de la perception du monde et des phénomènes
qui s’y déroulent,

 Avantages
 capacité de regrouper ce qui a été séparé,
 construire le complexe à partir de l’élémentaire,
 intégrer statiquement et dynamiquement les constituants d ’un
système.
Qu’est-ce qu’un Objet ?
 Définition Générale:
«Ce sur quoi porte notre connaissance »
 Pour les technologies objet:
«C’est une abstraction du monde réel »
 Pour l’analyse du domaine:
«C’est une entité pertinente du domaine »
 Dans un langage de programmation orientée objets:
«C’est un ensemble de fonctions associées à une
structure de données »
Les Objets
 Définition
 Concept, abstraction ou entité ayant des liens et un sens pour
une application donnée
 Exemples:
 Objets matériels (table, chaise, crayon, avion…)
 Objets immatériels, concepts (compte en banque, équation, match
de boxe…)
 Objets virtuels (groupe de travail, division…)
 …

 Tout objet possède les caractéristiques suivantes:

Objet = État + Comportement + Identité

Les Objets : L'état

 Regroupe des valeurs instantanées de tous les attributs d'un

objet.
 L’état d’un objet est décrit par l ’ensemble de ses attributs et
liens et est exprimé au travers des opérations.
 Exemple

Ma Voiture

Bleu Couleur
979 kg Masse
12 CV Puissance fiscale
30 litres Quantité de carburant
Les Objets: L'état
 L'état évolue au cours du temps:
 Certaines valeurs d'attribut vont évoluer
 D'autres vont rester constantes
 Exemple

Ma Voiture Ma Voiture

Bleu Après un parcours Bleu

979 kg de 100 km. 979 kg
12 CV 12 CV
30 litres 20 litres
Les Objets: Le Comportement
 Regroupe toutes les compétences d'un objet, l’ensemble
des opérations applicables à cet objet
 Décrit les actions et les réactions de l'objet.
 Concept d'opérations (méthodes) ; une opération a une
signature et s ’applique à un objet
 Une opération est déclenchée suite à une stimulation
externe: message envoyé par un autre objet.
Un autre objet
Opération 1
Un message {…}

Un objet Opération 2
{…}
Les Objets: Caractéristiques
 L'état et le comportement sont liés:
 Le comportement, à un instant donné, dépend de l'état
courant.
 L'état peut être modifié par le comportement.
 Exemple: Un avion ne peut atterrir que s'il est en vol.
 atterrir représente un comportement de l'avion.
 en vol correspond à un état de l'avion.

:Avion
Atterrir En vol

:Avion
: Tour de contrôle Décoller
Au sol
Les Objets: L'identité

 L’identité caractérise l’existence propre de l’objet:

 immuable
 permanente (permet de distinguer tout objet de
façon non ambiguë indépendamment de son
état)
 concept qui ne se représente pas de manière
spécifique mais qui peut être rajoutée dans l'état
des objets comme un artifice de réalisation.
Les classes d’objet
Définitions
Une classe est la description d’un ensemble d ’objets qui
ont les mêmes attributs, les mêmes opérations, les mêmes
relations et des sémantiques communes
ex : Personne, Etudiant, Compagnie
 Un attribut est une propriété nommée d’une classe qui
décrit un ensemble de valeurs, il représente une propriété
de l’élément modélisé
 Une opération est l ’implantation d’un service qui peut
être demandé aux objets d ’une même classe dans le but
de déclencher un comportement
 Représentation graphique des
classes

Nom de Classe
Attributs
Opérations ()
Moyen de transport
Type
Poids
Couleur
Démarrer ()
Accélérer ()
Freiner ()
 21
L’encapsulation
 22
L’encapsulation
 23
L’encapsulation
L’encapsulation
Interface / Implémentation
LIRE_NOM MAJ_NOM AGE
Interface
PARTIE VISIBLE

Implémentation structures de données

corps des méthodes
PARTIE CACHEE
age peut être implémenté par un
attribut stocké ou par un calcul
utilisant la date de naissance)

Abstraction : les objets clients ne peuvent accéder à un

objet que via son interface
Ils ne connaissant pas tout le détail de l'objet
Masquage d'information :
Indépendance des clients vis à vis des
structures de données et des algorithmes
 Les relations entre classes : L’héritage
Le lien d’héritage entre classes est une relation entre un élément
général et un élément dérivé
Polygone
Super classe
Sommets
Translater (a,b:réel)
périmètre():réel
La classe Rectangle hérite
Sous-classe de la classe Polygone
Rectangle
Tous les attributs et toutes les opérations
longueur
de la classe Polygone sont applicables de
largeur
la même façon à la classe Rectangle
diagonale
On n ’indique dans la sous classe que les
Propriétés spécifiques
Les relations entre classes :
L’héritage
Principe de la redéfinition et Polymorphisme
 La règle de calcul du périmètre d'un rectangle peut être
optimisée selon la formule p = 2*(longueur+largeur))
La méthode périmètre peut être redéfinie dans la classe
Rectangle afin d'avoir un corps différent (ici la redéfinition est
utilisée pour une meilleure efficacité)
 Le même nom "périmètre" désigne deux corps différents, une
opération peut avoir plusieurs formes (Polymorphisme)
 La redéfinition est un mécanisme sémantique qui assure que le
même nom fait référence à des codes différents selon le type de
l'objet auquel il s'applique
Les relations entre classes :
l’association
 Connexion sémantique bidirectionnelle entre classes
 Abstraction des liens qui existent entre les objets
instances des classes associées (en général, un
objet ne peut pas agir seul, il a besoin de l ’aide
d ’autres objets).
 Dés qu’un objet a un lien vers un autre objet, il peut
lui envoyer un message pour déclencher une de ses
opérations
Les relations entre les classes:
L’agrégation ou la composition

 Connexion bidirectional dissymétrique.

 Un train est composé de wagons, un wagon contient
des sièges...
 Une voiture possède quatre roues, un châssis, un
moteur…
 Les relations exprimées ici sont des relations de
composition (ou d ’agrégation)
 Chapitre 2
UML : Unified Modelling Language
 Objectifs d’UML
 Proposer un langage visuel de modélisation
 Utilisable par toutes les méthodes
 Adapté à toutes les phases du développement
 Compatible avec toutes les techniques de réalisation
 Proposer des mécanismes d’extension et de
spécialisation pour pouvoir étendre les concepts de base
 Être indépendant des langages particuliers de
programmation
 Proposer une base formelle pour comprendre le langage
de modélisation
Les Briques de Base

 Les briques de base de UML sont :

 Les éléments de modèle (classes, interfaces,

composant, etc.)
 Les relations (associations, généralisation,
dépendences, etc.)
 Les diagrammes (diagramme de classe, diagramme de
cas d’utilisation, diagramme d’interaction, etc.)

 Les briques de base simples sont utilisés pour construire

des structures plus complexes et plus grandes
Les modèles UML

 Modèle d’approche : décrit le comportement du système à

un haut niveau
les cas d’utilisation, les scénarios

 Modèle de structure : décrit l’aspect statique du système

les objets, les classes et leurs relations

 Modèle de la dynamique : décrit les échanges entre objets

interaction, communication, message
Modèles d’approche: les cas d’utilisation

 Le modèle des UC : une vue du système qui met l’accent sur le

comportement du système tel qu’il apparaît aux utilisateurs
externes. Il permet la représentation des fonctionnalités du
système.

 Les diagrammes de cas d’utilisation sont élaborés pour

visualiser les relations entre les acteurs et les cas d’utilisation

 Les diagrammes de cas d’utilisation présentent une vue

extérieure du système
 Acteurs et cas d’utilisation

 Acteurs et cas d’utilisation permettent de décrire le

système:
 Les acteurs interagissent directement avec le système

<<acteur>>
Un autre acteur

Un acteur

 Les cas d’utilisation représentent l’utilisation du

système par les acteurs

Un cas d’utilisation
 Les Acteurs

Un Acteur représente un rôle joué par une personne ou une chose

qui interagit avec le système

guichetier Conseiller financier

Un acteur a besoin d’échanger des informations avec le système.

Même si on les utilise dans les modèles, les acteurs ne font pas partie
du système puisqu’ils résident en dehors de celui ci.
 Les Acteurs
Trois types d ’acteurs :

• les personnes, ce sont des utilisateurs du système

(acteurs principaux, acteurs secondaires)

• le matériel externe, dispositif utilisé par le système

ex: l’imprimante d’un distributeur de billet

• les autres systèmes, qui communiquent avec le système

ex: Le groupement bancaire dans un système
de distributeur de billets
 Les Cas d’utilisation
Un cas d ’utilisation modélise une fonctionnalité du système

Ex :

Traiter Prêt
Traiter un Valider Mot
versement de passe

Un cas d ’utilisation décrit ce que fait un système mais ne

précise pas comment il le fait

La réalisation d’un cas d’utilisation se traduit par un

échange de messages entre le système et ses acteurs
 Diagramme de cas d’utilisation
Application bancaire

Traiter un
versement

guichetier Conseiller
Traiter Prêt
financier

Un cas d’utilisation définit un comportement du système sans

révéler sa structure interne; il spécifie les services que le système
fournit à ses utilisateurs et les interactions acteurs/système
 Relations entre cas d’utilisation
 Relation « include »
 inclusion d’un cas d’utilisation dans un autre
à utiliser quand on répète plusieurs fois la même
séquence dans différents cas d’utilisation

 Relation « extends »
 ajout optionnel de comportement dans un cas
d’utilisation
àutiliser quand on décrit une variation sur un
comportement normal
 Relation d‘inclusion : définition
La relation d ’inclusion signifie que le cas d'utilisation source comprend le
comportement décrit par le cas d'utilisation destination en un point
d’insertion bien déterminé

Cas Cas
d ’utilisation d’utilisation
source <<include>> destination

exemple
<<include>> Valider
Passer
Utilisateur
commande

La relation d ’inclusion est un exemple de délégation. Un cas d’utilisation

est partagée par plusieurs cas d ’utilisation
 Relation d'extension : définition
Une relation d'extension entre cas d’utilisation signifie que le cas
d'utilisation source ajoute son comportement au cas d'utilisation
destination.

Cas Cas
d’utilisation d’utilisation
source <<extend>> destination
Condition d ’extension

exemple
Passer
commande <<extend>> Passer
urgente commande
Fixer priorité Fixer priorité
 Relation de généralisation : définition
Une relation de généralisation entre cas d’utilisation signifie que le
cas d'utilisation enfant est une spécialsation du cas d’utilisation
parent. Le cas d’utilisation parent peut être abstrait.

Cas
d’utilisation Valider
Utilisateur
Parent

Cas Vérifier
d’utilisation mot de Scanner
passe rétinien
Enfant
 Un diagramme de cas d'utilisation

Virement
Vérification supplém.
Après identification

Virement par
minitel <<extend>>
<<Include>> Client local

Client distant Vérification

solde compte
Identification
 Construction des cas d'utilisation

 Un cas d'utilisation doit avant tout être simple,

intelligible, décrit de manière claire et concise.

 Lors de la construction, il faut se demander:

 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 des changements externes ?
 Le système devra- t-il informer l'acteur des conditions internes ?
 Les modèles de structure

 Montre la structure statique d’un modèle

(e.g., classes, interfaces, composants, noeuds)

 Types de diagrammes
o diagrammes structurels statiques
– Diagramme de classes
– Diagramme d’objets
o Diagrammes d’implantation
– Diagramme de composant
– Diagramme de déploiement
 Le Modèles de structure

 Représentation de la structure statique du système

 Les composants du système
 Les liens sémantiques entre ces composants
 Contenu
 Objets et classes
 Liens et associations
 Généralisation
 Modules ou paquetages
 Objet et Classe : définitions
 Objet
 Une abstraction
 Une entité qui a un sens propre dans le domaine ou dans l'application
 Un objet est une instance d'une classe
 Classe
 Représente un groupe d'objets qui ont une même sémantique et des
caractéristiques communes :
 attributs, opérations, relations avec d'autres objets

Personne Ali:Personne Mohamed :Personne

Classe Objet de classe

 Les Classes d’objet
Exemples:

Nom de classe Nom de classe

Attributs

Opérations

Personne
Personne
nom
prénom
dateNaissance
Poste de travail

age() Département
 Objet et Classe : les Attributs

 Définissent les propriétés des objets d’une classe

Nom de classe
Nom d’attribut: type = valeur initiale

Personne Film Personne

nom : string titre : string Id_pers : ID
prénom : string réalisateur : string nom : string
dateNaiss : date dateProduction : date prénom : string
dateSortie : date dateNaiss : date

 Chaque nom d'attribut est unique dans une classe.

 L' identification est fournie par le système, elle n’est pas à considérer dans le
modèle objet.
 Objet et Classe : les opérations
Une opération définit une fonction applicable aux objets de la classe

Nom de classe

Nom d’opération( liste_arguments) : type_retour

Personne Rectangle
nom : string Côté1
prénom : string Côté2
dateNaiss : date
Adresse : string Ajouter( )
CalculerAge ( ) Déplacer( )
changerAdresse ( ) Périmètre( )

Une méthode est la mise en oeuvre d'une opération pour une

Classe (plusieurs méthodes pour le même service)
Objet et classes : Visibilité des attributs et
des opérations
 3 niveaux de visibilité pour les attributs et les opérations:
 public (+) qui rend l’élément visible à tous les clients de la classe
 protégé (#) qui rend l’élément visible aux sous-classes de la classe
 privé (-) qui rend l’élément visible à la classe seul

Classe
+ Attribut public Personne
# Attribut protégé
- Attribut privé - nom : chaîne
- date_naissance: date
+ Opération publique( ) + calculer_age ()
# Opération protégée( ) + rechercher()
- Opération privée( )
 Les Relations entre classes
Lien et Association

 Association
 Une relation sémantique entre classes
 Représente l'ensemble des liens entre les objets des classes qui
participent à l'association
 Degré d'une association
 Le nombre de classes qui participent à l'association
 Une association peut être réflexive
 Lien
 Une connexion physique entre objets
 Une instance d'une association
 Similarité : classe-objet et association-lien
 Les relations entre classes
Lien et Association

 Une association est une relation structurelle qui précise que les
objets d’une classe sont reliés aux objets d’une autre classe

Travaille pour
Personne société association

Travaille pour
Ali MarocTelecom
Travaille pour liens
Khalid Marjane
 Lien et Association : multiplicité
 La multiplicité est une information qui définit combien d’objets
de la classe considérée peuvent être liés à un objet de l’autre
classe
1
Personne Société
1..*

Chaque personne travaille pour une société,

chaque société emploie de une à plusieurs personnes.

Multiplicité = cardinalité
 Lien et Association : multiplicité

1
1 (un et un seul)

* 0..*
plusieurs (zéro ou plus)

0..1
facultatif (au plus un)

1..*
obligatoire (au moins 1)
2..4
deux, trois ou quatre

 Les valeurs de multiplicité expriment des contraintes liées au

domaine de l’application, valables durant l’existence des objets.
 Lien et Association : rôle

 "Rôle" des participants dans une association

 Un "rôle" peut être spécifié pour une extrémité de l'association.
 Il exprime le rôle d'une classe dans l'association.
 il facilite la lecture et la compréhension du modèle objet.

0..* travaille pour

Personne Entreprise
employé employeur
rôle d'un objet dans
une association

Khalid/employé:Personne
INWI/employeur:Entreprise
Rachid/employé:Personne
 Les relations entre classes : Les
agrégations
 Représente une association non symétrique dans laquelle
une classe joue un rôle prédominant par rapport à l’autre
classe.
 Les critères suivants impliquent une agrégation:
 une classe fait partie d’une autre classe;
 les objets d’une classe sont subordonnés aux objets
d’une autre classe;
Tout Partie
A Une agrégation B

La relation d’agrégation représente la relation ‘Possède’

 Agrégat : caractéristiques

 Quand utiliser l’agrégat

Une "partie" ne peut pas exister indépendamment du "tout"

Document 0..* Paragraphe 0..* Phrase

 Les relations entre classes : Les
agrégations
 L’agrégation peut être multiple, comme l’association

Entreprise 1 Service
*

Cette forme d ’association a pour but de distinguer le tout de la partie.

Elle est uniquement conceptuelle
 Les relations entre classes : La
composition
 La composition est un cas particulier de l’agréation
 Agrégation réalisée par valeur sur des attributs: composition.
 Ils sont physiquement contenus dans l’agrégat.

0..1 Composite
Composite Composant
* Composant

Fenêtre Fenêtre
1 1 1
scrollbar[2]:Ascenseur
titre:EnTete
scrollbar 2 1 titre 1 corps corps:Panneau
Ascenseur EnTete Panneau
 Les relations entre classes : La
composition
 Forme d’agrégat avec appartenance forte et vies
coïncidentes des parties au tout:
 La destruction du composite implique la destruction de tous ses
composants,
 La création, la modification et la destruction des composants sont de la
responsabilité du composite

 La multiplicité du côté du tout ne peut dépasser « 1 »

 Un composant est non partagée
Les relations entre classes : La
composition
Un autre exemple

Voiture
Voiture Moteur
Moteur 

Cylindre Carburateur
...
 Les relations entre classes :
généralisation/Spécialisation

La généralisation est une relation entre classes qui exprime le

lien sémantique “est-un”

Spécialisation
Généralisation
Super-classe

Sous-classe 1 Sous-classe 2
 Les relations entre classes :
généralisation/Spécialisation
Exemple 1
Livre Super classe
Titre
Nombre de pages

Livre pour les enfants Livre pour l’enseignement

Fourchette des âges Discipline
Thème Niveau

Sous classe
 Les relations entre classes :
généralisation/Spécialisation
Figure Classe abstraite (nom
Exemple 2 #couleur en italique)
* #position
Ecran +afficher()
+déplacer()
+sélectionner()
+tourner()

symbole de généralisation

1D 2D
0D #orientation
#orientation #motif remplissage
+remplir()

Arc
Ligne Polygone Cercle
Point -rayon
-angle début -nbre côtés -diamètre
-angle fin -sommets
+afficher()
+afficher() +afficher() +tourner()
 Généralisation : héritage multiple

• Possibilité d'hériter de plusieurs classes

Véhicule

Véhicule marin Véhicule terrestre

Bateau Véhicule
Voiture
amphibie

Problème : Conflit de nom

 CONTRAINTES
DEFINITION

➢ Expressions qui précisent le rôle ou la portée d'un élément de modélisation.

➢ Permettent de restreindre le nombre d'instances visées (expressions de
navigation) sur une association

➢ Peuvent s'exprimer en langage naturel (texte encadré d'accolades) ou en OC

(Object Constraint Langage)
 Exemple : le solde d’un compte est toujours positif
 CONTRAINTES
ORDERED
Exprime que les instances d’une association sont liés dans un
ordre donné

Exemple 1 : Compositeur, Œuvres (l’ordre de création des œuvres est

important)
 CONTRAINTES
FROZEN

Frozen : Exprime que les relations entre instances ne

peuventt être modifié

Exemple 1 : Véhicule, Roue (un véhicule à un nombre fixe de roues (2 au

minimum))
 CONTRAINTES
ADDONLY
AddOnly : Exprime que le nombre d’instances en relation ne peut
qu’augmenter

Exemple :
Pays, Personne (est née dans un pays, a visité un certain nombre de pays (ce
nombre ne peut que croitre) dans un ordre donnée, aimerait encore visiter une
liste de pays ordonnés par préférence
 CONTRAINTES
QUALIFICATION

•Permet de sélectionner un sous-ensemble d'objets, parmi l'ensemble des

objets qui participent à une association.
•La restriction est définie par une clé (qualificatif), qui permet de
sélectionner les objets ciblés.
Possède
Banque Client
* 0..n

Tableau
Possède Exp 2 : Un client ne peut nrCompte
Cellule
1 1..n
Ligne
avoir qu’un seul compte
colonne dans une banque donné
Exp 1 :
Dans un tableau une
seule cellule
correspond à un
couple (ligne,
colonne) donné.
Diagramme de
séquences
 Comment ?

 Les diagrammes de cas d’utilisation modélisent à QUOI sert le

système, en organisant les interactions possibles avec les acteurs.
 Les diagrammes de classes permettent de spécifier la structure et
les liens entre les objets dont le système est composé : ils spécifie QUI
sera à l’oeuvre dans le système pour réaliser les fonctionnalités
décrites par les diagrammes de cas d’utilisation.
 Les diagrammes de séquences permettent de décrire COMMENT les
éléments du système interagissent entre eux et avec les acteurs :
 Les objets au coeur d’un système interagissent en s’échangent
des messages.
 Les acteurs interagissent avec le système au moyen d’IHM
(Interfaces Homme-Machine).
Interaction

 Pour être complètement spécifiée, une interaction doit être

décrite dans plusieurs diagrammes UML :
 Cas d’utilisation

 Séquences

 Classes pour spécifier les opérations nécessaires

Ligne de vie

 Une ligne de vie représente un participant à une interaction

(objet ou acteur). La syntaxe de son libellé est :
nomLigneDeVie {[selecteur]}: NomClasseOuActeur
 Une ligne de vie est une instance, donc il y a nécessairement les
deux points (:) dans son libellé.
 Dans le cas d’une collection de participants, un sélecteur permet
de choisir un objet parmi n (par exemple objets[2]).
Messages

 Les principales informations contenues dans un diagramme de

séquence sont les messages échangés entre les lignes de vie :
 Ils sont représentés par des flèches
 Ils sont présentés du haut vers le bas le long des lignes de vie, dans un
ordre chronologique
 Un message définit une communication particulière entre des
lignes de vie (objets ou acteurs).
Messages

 Plusieurs types de messages existent, dont les plus

courants :
 l’envoi d’un signal ;
 l’invocation d’une opération (appel de méthode) ;
 la création ou la destruction d’un objet.
 La réception des messages provoque une période
d’activité (rectangle vertical sur la ligne de vie)
marquant le traitement du message (spécification
d’exécution dans le cas d’un appel de méthode).
Messages synchrones et
asynchrones

 Un message synchrone bloque l’expéditeur jusqu’à

la réponse du destinataire. Le flot de contrôle passe
de l’émetteur au récepteur.
 Si un objet A envoie un message synchrone à un objet
B, A reste bloqué tant que B n’a pas terminé.
 On peut associer aux messages d’appel de méthode
un message de retour (en pointillés) marquant la
reprise du contrôle par l’objet émetteur du message
synchrone.
Messages synchrones et
asynchrones

 Un message asynchrone n’est pas bloquant pour

l’expéditeur. Le message envoyé peut être pris en
compte par le récepteur à tout moment ou ignoré.
Messages synchrones et
diagramme de classe

 Les messages synchrones correspondent le plus souvent à une

opération :
 Les méthodes correspondant aux messages synchrones doivent
être définies dans un diagramme de classes.
 Les méthodes sont définies dans la classe du récepteur, et pas de
l’émetteur du message.
Echange de messages et
code Java class B {
C c=new C();
message1 (p:Type) {
c.message2 ();
c.message3 (p);
}
}
class C {
message2 () { ... }
message3 (p:Type) {
...
}
}
Messages asynchrones et
diagramme de classe

 Les messages asynchrones correspondent à des

signaux dans le diagramme de classes.
 Les signaux sont des objets dont la classe est
stéréotypée << signal >> et dont les attributs
(porteurs d’information) correspondent aux
paramètres du message.
Création et destruction
d’objets (et de lignes de vie)

 Création : message asynchrone stéréotypé << create >> pointant

vers le rectangle en tête de la ligne de vie
 Destruction : message asynchrone stéréotype << destroy >>
précédant une croix sur la ligne de vie
Réutilisation de séquences

 Un fragment ref permet d’indiquer la réutilisation d’un diagramme

de séquences défini par ailleurs.
 En supposant qu’il existe un diagramme intitulé Authentification et
un autre Paiement, on peut établir le diagramme suivant :
Fragment alt : opérateur
conditionnel

 Les différentes alternatives sont spécifiées dans des zones

délimitées par des pointillés.
 Les conditions sont spécifiées entre crochets dans chaque zones.
 On peut utiliser une clause [else]
Fragment loop : opérateur
d’itération

 Le fragment loop permet de répéter ce qui se trouve en son sein.

 On peut spécifier entre crochets à quelle condition continuer.