UML

(Introduction)
Unified Modeling Language

Mr Omar ASKANDER
 Genèse d’ UML

• UML est le fruit de l’unification de 3 méthodes de modélisation

orientées objet
– OMT (Object Modeling Technique) : James Rumbaugh
– Booch : Grady Booch
– OOSE (Object Oriented Software Engineering) : Ivar Jacobson

• UML est le fruit d’un consensus général

– élaboré avec le concours de la communauté des utilisateurs

• UML est une notation (relativement) simple et non propriétaire

– standardisé par l’OMG (Object Management Group)
 Genèse d’UML

- 2002 UML 2.0

- 1999 UML 1.3

- 1997(Q4) UML 1.1

- 1997 (Q1) UML 1.0

- 1996 UML 0.9

- 1995 Méthode unifiée 0.8

- 1993 Booch’93 OMT-2

Autres méthodes Booch’91 OMT-1 OOSE Partenaires OMG

 UML est une notation

• UML est un langage de modélisation objet

– 9 diagrammes standardisés (facettes complémentaires d’un
système)
– Support des phases d’Analyse et de Conception orientée objet

• UML est un langage de communication

– utilisation d’un même formalisme par tous les intervenants
– permet de lever les ambiguïtés du langage naturel

• UML est un langage simple de haut niveau

– facile à appréhender car visuel
– indépendant de tout langage de programmation
• UML est un langage ouvert
– possibilité d’ajouter des notes (texte)
– utilisation de stéréotypes permettant d’étendre la notation, améliorant
ainsi la sémantique des éléments modélisés
 UML n’est pas une méthode

• UML n’est pas une méthode, ce n’est qu’une notation

– attente de la part des utilisateurs d’une normalisation du formalisme
– définir un processus de développement logiciel universel est illusoire

• UML est indépendant de toute démarche

– ce qui en fait un langage universel
– mais favorise la mise en œuvre d’un processus itératif et
incrémental, fondé sur les cas d’utilisation et centré sur l’architecture
 Plan Du Cours

• Partie I : Modélisation fonctionnelle

• Partie II : Modélisation Statique

• Partie III : Modélisation Dynamique

• Partie IV : La Conception
 Partie I :

Modélisation fonctionnelle:
» Acteur
» Cas d’utilisation
» Scénario
 Modélisation fonctionnelle

Principes & Définitions

1/ Acteur :
1.1 Définition :
un acteur représente un rôle joué par une
entité externe.
Il peut être Humain, ou non Humain (Dispositif
matériel ou autre système)
Un Acteur peut consulter et/ou modifier
directement l’état du système, en émettant
et/ou recevant des messages susceptibles
d’être porteurs de données.
 Modélisation fonctionnelle
1.2 Identification :
Acteur Humain : toutes personnes qui intervienne dans le cas étudié
Acteur Non Humain : Touts dispositifs ou système susceptibles de
participer au système étudié

1.3 Représentation :
On utilise l’icône appelée en UML stick man avec le nom de l’acteur sous
le dessin. Pour les Acteurs non Humain on utilisera une forme
rectangulaire avec le mot clé en haut « ACTOR »

Client
 Modélisation fonctionnelle
2/ Cas d’Utilisation: (Use Case)
2.1 Définition :
• Chaque cas d’utilisation Représente un
ensemble d’actions qui sont réalisées par le
système et qui produisent un résultat
observable intéressant pour un acteur
donnée.
• C’est un comportement attendu du système.
Il permet de décrire ce que le futur système
devra faire, sans spécifier comment il le fera.
 Modélisation fonctionnelle
2.2 Identification :
Chaque cas d’utilisation correspondant à une fonction métier du système
L’ensemble des cas d’utilisation doit décrire les exigences fonctionnelles du
système.

2.3 Représentation :
Le Diagramme de Cas d’utilisation est un schéma qui montre les cas
d’utilisation (ovales) reliés par des associations(ligne) à leurs acteurs
(stick man ou représentations graphiques) On utilise l’icône appelée

Acteur Humain
 Modélisation fonctionnelle
3/ Scénario:
3.1 Définition :
Un scénario représente une succession particulière
d’enchaînements,s’exécutant du début à la fin du cas
d’utilisation, un enchaînement étant l’unité de description
de séquences d’actions.

un Cas d’utilisation contient :

• Un scénario nominal
• Des scénarios alternatifs (qui se terminent de façon normale)
• Des scénarios d’erreur (qui se terminent en échec).
 Scénario
3.3 Représentation :

Erreur
Fin
Début Normale

Enchaînements
 étude de Cas : GAB
GAB : Guichet automatique de Banque offres les
services suivants :
1/ Distribution d’argent a tout porteur de carte
banc aire via un lecteur et un distributeur de
billets.

2/ Consultation de solde de compte et autres

services.
A retenir :
3/ Toutes les transactions sont sécurisées.
4/ il est parfois nécessaire de recharger le
distributeur …
 étude de Cas : GAB

EXRCICE 1 : ACTEURS
Dans cet exercice on est appelle à identifier les
entités externes qui réagissent directement avec
le GAB.

T.A.F :
1.1 Identifier les acteurs du GAB.
1.2 Identifier les acteurs principaux et les acteurs
secondaires
1.3 élaborer le digramme correspondant
 étude de Cas : GAB

EXRCICE 2 : CAS D’ UTILISATIONS

En reprenant les acteurs dégagés de

l’exercice 1 lister les différentes façons
qu’ils ont pour utiliser le GAB.

T.A.F :
décrivez la partie obligatoire du cas utilisation
RETIRER DE LARGENT (pour acteur non
client de la banque)
 étude de Cas : GAB

EXRCICE 3 : SCENARIO

Extraire de l’exercice précédant :

• les enchaînements alternatifs
• les enchaînements d’erreur.