UMl (Unified Modeling language)

INTRODUCfION

Il

LA MODELISATION des USE CASES

III

LA MODELISATION des ClASSES

IV

LA MODELISATION des INTERACfIONS

LA MODELISATION des ACTIVITES

VI

LA MODELISATION des Machines d'Etat

VII

La MODELISATION STATIQUE

(Complment:

Package, Objet, Composant, Dploiement, Structures Composites)

Bibliographie
Grady Booch , James Rumbaugh et Ivar Jacobson
1) UML 2.0 le Guide de l'Utilisateur
2} UML 2.0 le Manuel de Rfrence
3) UML le Processus Unifi

M.LAI, UML: La notation unifie de modlisation objet, MASSON

P. A MULLER, Modlisation Objet avec UML,

EYROLLES

Urlographie: www.developpez.com

Introduction:
UML est un langage qui s'appuie sur la technologie oriente objet et ses.concepts

Mthodologie, Mthode et Formalisme?

Le terme mthodologie ,dans son sens premier, dsigne l'tude
des mthodes scientifiques et techniques. Il est employ pour dsigner l'utilisation d'une dmarche
rationnelle et structure lors de l'laboration ..d'un ..logiciel.
Un formalisme est un ensemble de notations et de rgles dcrivant des concepts permettant de
spcifier, construire, visualiser et documenter un systme informatique.
Une mthode informatique est une dmarche conceptuelle et
organisationnelle base sur un formalisme spcifique et permettant la mise en oeuvre d'une solution
informatique.

UML n'est pas une mthode.

UML est un langage objet graphique, autrement dit un formalisme orient objet; ce n'est pas une
mthode mais une synthse de tous les concepts et formalismes mthodologiques les plus utiliss
dans la Technologie Objet.

o UML est issu de la fusion du formalisme de trois mthodes orientes objet qui taient les
plus utilises aux USA:

o OMT (Object Modeling Technique),de James Rumbaugh

o BOOCH de Grady Booch,
1

o OOSE (Object Oriented Sofware Engineering) de Ivar Jacobson qui

fut intgre UMl en

1997.

o UMl s'inspire galement de toutes les autres mthodes leaders du march.

[J le formalisme UMl peut donc tre utilis dans diffrents processus de dveloppement et en
particulier dans celui propos par les concepteurs du langage (RUP : Rational Unified Process
ou le Processus Unifi), (UP: l' Unified Process), ( 2TUP : Two Track Unified Process ), (XP :
Extreme Programming )'0'

o la migration de MERISE 0.0 UMl peut se faire assez aisment.

[J UML et la standardisation

o Initialement, UMl a t soumise en janvier 1997 l'OMG (Object Management Group) dans
le cadre de la standardisation des mthodes d'analyse et de conception orientes objet, la
version 1.0 d'UML a trs vite obtenu le ralliement de nombreux acteurs du march
(Microsoft, Oracle, Hewlett-Packard ... )et de nombreux diteurs d'AGL (ateliers de gnie
logiciel). UML 2.0 est la dernire version vote en 2003.

o la technologie oriente objet, et le formalisme UMl en particulier vhiculent des concepts

trs gnraux dont l'application n'est pas limite au domaine informatique.
UML et La Modlisation
Un Systme est un ensemble d'lments organiss et de relations entre ces
lments en vue d'atteindre un objectif. Il est dcrit par un ensemble de Modles en
gnral sous diffrents points de vues ou angles.
Un Modle: c'est une abstraction d'un Systme complte et ferme du point de
vue smantique; c' ad: reprsentant une simplification cohrente de la ralit et
cre dans le but de faciliter la comprhension du systme (UMl2.0 propose 13 en
tout)..
Un Diagramme est une reprsentation graphique d'un ensemble d'lments sous
forme d'un graphe connect de sommets (lments structurels) et d'arcs (relations).
Un diagramme n'est pas un modle; ce n'est qu'une reprsentation de quelques
lments du modle.

o Plusieurs diagrammes s'avrent souvent ncessaires pour illustrer un modle complet.

o Pour la modlisation, UML distingue 2 catgories de diagrammes:
Les Diagrammes Structurels: permettent de visualiser, construire et documenter les aspects

statiques d'un systme.

Dans cette catgorie on trouve 6 diagrammes:

- de Classes,

- d'Objets,

- de Composants,

- de Dploiement,

- de Structure Composite,
- de Package,
Les Diagrammes Comportementaux:
permettent de visualiser, construire et documenter
les aspects dynamiques d'un systme. Dans cette
catgorie on trouve 7 diagrammes:

des USE CASES.

des Interactions

Squence.

de Communication (av. collaboration)

vue d'ensemble des Interactions,

deTiming

dlActivits.

de Machine d'Etats (av. Etats-Transitions).

o En principe ni UML ni le Processus Unifi (la Mthode) n'obligent reprsenter les 13

diagrammes.
Ils laissent l'analyste et au concepteur la latitude dcisionnelle en fonction de leurs besoins.
Cependant, les 2 diagrammes qui s'avrent toujours ncessaires sont surtout:
le diagramme des USE CASES et
le diagramme de Classes.
Il) La Modlisation des USE CASES
(CAS D'UTILISATION ou CAS D'USAGE).

11.1) Que sont les USE CASES?

Les USE CASES constituent le concept principal de la mthode OOSE d'Ivar Jacobson.
Le concept des USE CASE a t repris dans le but d'effectuer une bonne dlimitation du systme mais
galement pour amliorer la comprhension de son fonctionnement et raliser sa spcification.
Les USE CASES reprsentent un mcanisme qui permet de dtecter. d'identifier, de comprendre et
de consigner les besoins.
Ils permettent d'orienter tout le processus de dveloppement car les activits d'Analyse, de

Conception et de Test sont effectues partir des USE CASES.

Les USE CASES reprsentent le premier modle du systme concevoir.

Les USE CASES sont une reprsentation oriente

fonctionnalit du systme qui permettent de

modliser les attentes des utilisateurs.

Une bonne comprhension du systme est primordiale avant d'entreprendre l'analyse et la

conception.

USE

CONCEPTION

Il.2 Les concepts

Deux concepts fondamentaux pour reprsenter les USE CASES:
- les acteurs qui utilisent le systme;
- les USE CASES qui reprsentent l'utilisation
du systme par les acteurs.
A) Les acteurs (utilisateurs du systme):

Pour permettre une bonne dlimitation du systme, il est bon de bien sparer les lments

constitutifs du systme logiciel des lments extrieurs. les acteurs reprsentent cette frontire.

Ce sont des lments extrieur au systme et qui interagissent avec lui.

Il faut d'abord Identifier les acteurs qui peuvent tre des:

Humains: ce sont des utilisateurs du logiciel

travers son interface graphique par exemple,
Logiciels: ce sont des logiciels dj disponibles qui
communiquent avec le systme grce une
interface logicielle (une API par exemple) ;
Matriels: robots et automates qui exploitent les
donnes du systme ou qui sont pilots par le
systme (GAB).
Systmes: extrieurs (le Systme de la banque de la
socit).

Al) Typologie des acteurs

Il existe trois types d'acteurs:

Les acteurs principaux ou primaires: Ceux qui utilisent le systme pour atteindre leurs buts (ils sont

la raison de l'existence du systme).

Les acteurs secondaires, Ceux qui administrent le systme et assurent sa maintenance. Ce sont eux

qui paramtrent le systme et qui lui fournissent toutes les informations ou services ncessaires

son bon fonctionnement pour les acteurs principaux.

Ex:la personne charge de la MAJ des cours des devises.

Les acteurs externes: Ceux qui ont un intrt dans le comportement du cas d'utilisation.

Ex: les services des impts, du commerce...

Remarquef:
Un acteur correspond un rle jou vis--vis du systme. (Un salari d'une banque correspond
souvent un ou plusieurs rles: directeur, guichetier, responsable devises ... ) et plusieurs individus
jouent souvent le mme rle (guichetier).
Une mme entit peut reprsenter tour tour deux types d'acteurs.
Exemple: dans le caS de petites agences bancaires, le directeur d'agence peut tre amen
faire des oprations de maintenance (alimenter le DAB en liquide).
A2)

Pourquoi des acteurs ?

Identifier les acteurs d'un systme permet de :

dlimiter le systme: Un acteur est un lment extrieur au systme qui interagit avec ce dernier.
- avoir une vue oriente utilisateur du systme: Avant de se lancer dans l'analyse et la conception
interne du systme, il est bon d'en avoir une vue externe, qui correspond

toutes les fonctionnalits

attendues par les diffrents acteurs.

Remarque:
UMl permet de strotyper les acteurs et d'utiliser d'autres icnes plus spcifiques (avec
utilisation des couleurs et images) en fonction des besoins pour offrir un meilleur repre visuel.
Mais l'utilisation de ces icnes doit tre faite avec parcimonie
Ex :

Un tudiant

Une tudiante

A3) Les relations entre ACTEURS:

Pour UMl, la relation prvue entre acteurs est une relation de:

gnralisation/Spcialisation

B) Les USE CASES: Elments de l'interface d'utilisation

Bl) Dfinitions:
Un USE CASE est une suite de squences d'actions y compris des variantes (souvent initie par un
des acteurs) et qui correspond une excution particulire du systme pour produire un rsultat ou
rpondre au(x) besoin(s) d'un acteur.
les USE CASES permettent de bien comprendre le systme.
Le but des USE CASES n'est pas de faire une description exhaustive des fonctionnalits du systme
logiciel en dveloppement. Ils permettent de dcrire ce que fait un systme (un sous systme, une
classe ou une interface) mais ne prcisent pas comment il le fait.

Ils permettent de reprsenter les besoins fonctionnels et non fonctionnels (scurit,

performances, ...) que doit raliser le systme logiciel en dveloppement.
B) Les USE CASES: Elments de l'interface d'utilisation

Bi) Dfinitions:

o Un USE CASE est une suite de squences d'actions y compris des variantes

(souvent initie

par un des acteurs) et qui correspond une excution particulire du systme pour
produire un rsultat ou rpondre aulx) besoin(s) d'un acteur.

o Les USE CASES permettent de bien comprendre le systme.

Le but des USE CASES n'est pas de faire une description exhaustive des fonctionnalits du
systme logiciel en dveloppement. Ils permettent de dcrire ce que fait un systme (un
sous systme, une classe ou une interface) mais ne prcisent pas comment il le fait.

Ils permettent de reprsenter les besoins fonctionnels et non fonctionnels (scurit,

performances,...) que doit raliser le systme logiciel en dveloppement.

o Ils sont utiliss aussi comme moyen de dialogue entre diffrents travailleurs (Spcificateurs,
Analystes, Concepteurs, Programmeurs, ...) et entre ces derniers et les acteurs (ou
utilisateurs).
Le symbole graphique d'un Use Case se fait par:

~om du Use Case

B 2) Description d'un USE CASE

o La description des USE CASES doit tre synthtique, comprhensible (comme tout modle) et
doit galement rendre compte aisment du droulement d'un cas d'utilisation.

Un USE CASE peut tre dcrit de diffrentes faons:

de faon informelle, il s'agit alors de texte libre, comme peuvent l'tre les spcifications.
de faon formelle, il peut alors s'agir d'une langage structur, de diagrammes ou d'un
pseudo-code.
Il est recommand d'effectuer au moins deux descriptions:

+ Une externe (au niveau Analyse) qui spcifie les besoins du point de vue de l'acteur
uniquement;

+ une interne (au niveau conception) qui prend en considration les concepts du
systme (classes, crans, contrles, base de donnes, ...).

Pour cette description interne, on peut utiliser une maquette (une succession
d'crans) o on indiquerait les options et les informations que doit renseigner un acteur pour
un Use Case donn.

Ex : Retrait d'Argent dans une agence bancaire

6

Responsable argent
Exemple:

Un cas d'utilisation peut tre le retrait d'espces demand par un

client sur un compte prcis.

Une description teKtuelle peut tre:

+ La responsable argent alimente chaque guichetier en argent chaque matin et en fonction des

besoins

Le guichetier saisit le numro de compte du client.

L'application valide le compte auprs du systme central.

L'application demande le type d'opration au guichetier.

Le guichetier choisit un retrait d'espces du montant en Dirhams.

Le systme guichet interroge le systme central pour s'assurer que le compte est

suffisamment approvisionn.
+

Le systme central effectue le dbit du compte.

Le systme notifie au guichetier qu'il peut dlivrer le montant demand..

UML n'a pas spcifi un canevas de description pour les USE CASES mais le modle le plus rpandu
correspond au format ci dessus:

Acteur Principal: celui qui fait appel au systme;

Parties prenantes et intrts: dcrit et dlimite ce que le systme fait;

Pr conditions: ce qui doit tre vrai avant le dbut d'un scnario;

Post conditions (garanties de succs) : ce qui doit tre vrai

Scnario Principal: chemin type le plus utilis pour les parties impliques;

Extensions (ou Scnarios alternatifs) : branchements particulires ou d'exception;

Spcifications Particulires: besoins non fonctionnels, dispositifs d'E/S...

la fin d'un scnario;

o Liste de variantes et de donnes technologiques.

ex: lecteur de cartes pour diffrents codes barres;

Frquence d'occurrences:

Questions ouvertes: pour complter les spcifications dans les itrations suivantes.

Certains pratiquants ont apport ce modle quelques prcisions:

(voir exemple 1 ci dessous)

Une autre description propose ressemble au diagramme de rpartition des tches Homme /
Machine (du MOT de MERISE) et utilise deux colonnes: une pour l'acteur et ,'autre pour le systme
(voir exemple 1 ci-dessous).
83) les relations entre USE CASES au sein d'un systme:
On distingue trois types de relations entre USE CASES:
a) la relation de Gnralisation 1 Spcialisation:
C'est le principe d'hritage: ex:
b) la relation Include :

Permet la factorisation d'un ensemble de tches.

Dans un systme, il existe des tches que doit faire rgulirement un utilisateur.

Par exemple, le guichetier: aura souvent besoin de valider le numro du compte de l'utilisateur. On
peut prciser comment se fait cette validation dans un Use Case et indiquer que cette fonctionnalit
sera utilise dans diffrents USE CASES.
Cette relation permet donc de :

+ factoriser des USE CASES correspondant des fonctionnalits qui servent dans diffrents USE
CASES;

+ expliciter la constitution d'un USE CASE complexe en le dcomposant en plusieurs USE CASES
relis.

Exemple : Considrons le USE CASE Valider utilisateur dcrit comme suit:

+ le guichetier saisit le code de la banque du compte

+ il saisit te numro du compte

+ il saisit la cl de compte
+ le systme calcule la cl du compte et vrifie qu'elle est bonne;
+ le systme interroge le compte sur le systme central;

+ le systme affiche le compte ainsi que son dtenteur.

c) la relation extend :
Cette relation qui peut exister entre USE CASES indique que le USE CASE qui est point par la flche
est une sous-partie optionnelle de l'autre USE CASE et qu'il peut aussi tre utilis tout seul.

La relation extend )} : indique que tous les USE CASES fils hritent de toutes les caractristiques du
USE CASE pre (USE CASE qui est point par la flche), c'est--dire qu'ils ont les mmes liens avec les
acteurs et les autres USE CASES.
Ce type d'hritage a aussi une valeur smantique:
Il indique que tous les USE CASES fils sont des cas particuliers du USE CASE pre.

Exemple : {( Commander/Tlphone)} est le USE CASE gnrique et Demander prix produits est
un cas particulier du premier.

Remarque: Il faut distinguer entre une relation extend

et une relation de Gnralisation ISpcialisation

Il.3) le Diagramme des USE CASES

Cette reprsentation graphique permet de voir de faon simple.

les diffrents acteurs

comment est dlimit le systme

les fonctionnalits demandes au systme

les rles des diffrents acteurs vis--vis du

systme.

Il faut donner un nom au diagramme.

Applkation BaliCaire

1\

CAISSIER

Responsable Devise

"Acte-ur"

DIRECTEUR

Syst, Ce-nb-aJ

Description du cas d'utilisation Retraits Dirhams: Modle classique

Sommaire d'identification (obligatoire)

Titre

: retrait d'argent avec un chque ou un chque guichet

Rsum: ce cas permet un client de la banque de retirer de

l'argent de son compte avec un chque, une carte ou un
chque guichet si son solde ou son dcouvert le lui permet
Acteurs: guichetier de la banque, le systme central
Date de cration: 11/09/04

Date de MAJ: 19/09/04

Version : 2,3
Responsable: Kaddour ben Jilali

Description des enchanements

(obligatoire)

o Pr conditions: Le systme est lanc, le guichetier est identifi, le solde caisse est

suffisamment approvisionn.

Scnario Principal:

1) Le client prsente un chque lui pour retirer des dirhams

2) Le guichetier demande identification du client

10

3} Le systme valide l'identification et affiche la signature

4} Le guichetier vrifie la signature appose sur le chque

5) Le systme vrifie le solde et le dcouvert du compte client

6) Le systme donne son accord

7} Le guichetier dlivre le montant demand

Le systme met jour le compte client et le solde caisse.

Scnarios alternatifs :

S.Al : Le client n'a pas de chque.

Cet enchanement dmarre au point

1)

la) Le guichetier remplit un chque guichet avec le montant demand

1) Le client signe le chque
2) le guichetier le reprend.
Ce scnario continue au point 2 du scnario principal.
S.A2 : Le solde et le dcouvert ne permettent pas le retrait
Cet enchanement dmarre en

6)

6a) le systme ne donne pas l'accord pour le retrait

1) le chque est remis au client
2) l'opration est termine.

Post conditions: Le compte client est mis jour ainsi que le solde de la caisse en
cas de succs du retrait autrement ils doivent rester inchangs.

Besoins d'IHM : lfocultatiO

+ un lecteur de chques,

+ Un terminal avec clavier (pour saisir le num chque si le lecteur n'y arrive pas) et afficher l'image de
la signature du client,

+ Un compteur de billets.

o Contraintes non fonctionnels: lfocultatiO

+ Temps de rponse: Une transaction nominale doit durer moins

de 2 minutes,

+ Concurrence : Un chque du client peut tre retir en mme temps par une autre personne
auprs d'un autre guichetier dans la mme agence,

11

+ Disponibilit

: le systme doit tre lanc 15 mn avant les horaires du travail est arrt la

demande du directeur de l'agence,

+ Confidentialit: l'cran doit tre positionn de telle sorte qu'il ne peut tre lu par un client
quelque soit sa position.
Description du cas d'utilisation Retraits Dirhams :
Modle de 2 colonnes pour les scnarios (ou enchanements)
{obligatoire}

Description des enchanements

D Scnario Principal:
Le guichetier

1Le systme

1) prend le chque client

et demande identification

2) lit le chque et

vrifie "identification et

affiche la signature

3) vrifie la signature ...

,
\

\~~----------~---------------~
tXfflLe "

Loc s~Ji
(~h>.Q t~ \~,., bA \J\o,Je.-eJ

et

<. 1

~!l)~..J ~s (~."'!i"'~ i.v. ow 'SeJ\v 10/ ~,,,,

s.lj~
'" IbL~~ ';)~ l..~
3(;(..1",::,

~ J~ kA s.lj\~iJV... ~l S(~

J..eA b 1~~ .))J,

D\ cc.(.9'v-~~,~" J t iJr-6

Le S

crf)""",,-,',,_.

12