Vous êtes sur la page 1sur 37

Ecole des Mines dAlbi-Carmaux

2005-2006

Modlisation Objet : Le formalisme UML


Ecole des Mines dAlbi-Carmaux

Option GSI

TABLE DES MATIERES

1.

PRAMBULE_________________________________________________________________________3

1.1 LA MODLISATION...................................................................................3
1.2 LES CONCEPTS OBJET .........................................................................4
1.2.1
1.2.2
1.2.3

Lobjet.....................................................................................................................4
La Classe................................................................................................................5
LHritage...............................................................................................................5

2.

PRSENTATION DUML_______________________________________________________________6

3.

MODLE FONCTIONNEL______________________________________________________________9

3.1 CONCEPTS DE BASE...................................................................................9


3.1.1
3.1.2

Acteur.....................................................................................................................9
Cas dutilisation.....................................................................................................9

3.2 DIAGRAMME DE CAS DUTILISATION (USE-CASE DIAGRAM)...............10


4.

MODLE STRUCTUREL______________________________________________________________11

4.1 DIAGRAMME DE CLASSES (CLASS DIAGRAM).......................................11


4.1.1
4.1.2
4.1.2.1
4.1.2.2
4.1.2.3
4.1.2.4

4.1.3
4.1.4

Classe....................................................................................................................11
Relations entre classes..........................................................................................12
Gnralisation / Spcialisation___________________________________________________________12
Association__________________________________________________________________________13
Agrgation___________________________________________________________________________14
Dpendance__________________________________________________________________________15

Notion de Paquetage (Package)...........................................................................15


Exemple de diagramme de classes.......................................................................16

4.2 DIAGRAMME DOBJETS (OBJECT DIAGRAM)........................................17


4.2.1
4.2.2
5.

Objet.....................................................................................................................17
Exemple de diagramme dobjets...........................................................................17

MODLE COMPORTEMENTAL_______________________________________________________19

5.1 DIAGRAMME DE SQUENCE (SEQUENCE DIAGRAM)............................19


5.1.1
5.1.2
5.1.2.1
5.1.2.2

Structure dun diagramme de squence...............................................................19


Actions et messages..............................................................................................19
Appel de mthode (Call / Return)_________________________________________________________19
Cration et Destruction dObjets (Create / Destroy)___________________________________________21

5.3 DIAGRAMME DE COLLABORATION (COLLABORATION DIAGRAM)......22


5.3.1
5.3.2
5.3.3

Structure dun diagramme de collaboration........................................................22


Notion de collaboration........................................................................................22
Comparaison entre diagramme de squence et diagramme de collaboration.....23
-1-

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

5.4 DIAGRAMME DACTIVIT (ACTIVITY DIAGRAM)..................................24


5.4.1
5.4.2

Composants dun diagramme dactivit...............................................................24


Structure dun diagramme dactivit....................................................................24

5.5 DIAGRAMME DTATS-TRANSITIONS (STATE-TRANSITION DIAGRAM) 25


5.5.1
5.5.2
5.5.3
5.5.4
5.5.4.1
5.5.4.2
5.5.4.3

6.

LEtat....................................................................................................................26
La Transition........................................................................................................26
LEvnement.........................................................................................................27
Principe de description des diagrammes dtats-transitions...............................28
Dcomposition_______________________________________________________________________28
Historique___________________________________________________________________________29
Paralllisme__________________________________________________________________________29

MODLE ARCHITECTURAL__________________________________________________________31

6.1 DIAGRAMME DE COMPOSANTS (COMPONENTS DIAGRAM)..................31


6.1.1
6.1.2

Le Composant.......................................................................................................31
Structuration du diagramme de composants........................................................32

6.2 DIAGRAMME DE DPLOIEMENT (DEPLOYMENT DIAGRAM).................32


6.2.1
6.2.2
7.

Le Nud................................................................................................................33
Structuration du diagramme de dploiement.......................................................33

UTILISATION DUML_________________________________________________________________34

7.1 PRINCIPES DE MODLISATION................................................................34


7.1.1
7.1.2
7.1.3
7.1.4

Premier principe de modlisation........................................................................34


Deuxime principe de modlisation.....................................................................34
Troisime principe de modlisation......................................................................34
Quatrime principe de modlisation....................................................................34

7.2 RATIONAL UNIFIED PROCESS (RUP).....................................................35


7.2.1
7.2.2
8.

Caractristiques du processus RUP.....................................................................35


La structure itrative du RUP...............................................................................35

BIBLIOGRAPHIE_____________________________________________________________________37

-2-

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

1. Prambule
Avant daxer ce document sur la prsentation globale du formalisme UML, il est intressant de sintresser dune
part la notion de Modlisation, et dautre part aux concepts inhrents la vision Oriente Objet. Le langage
UML se trouve en effet la croise de ces deux chemins.

1.1

La Modlisation

La modlisation est une notion indissociable du fonctionnement de lhomme. Notre apprhension du monde est
entirement base sur cette ide : nos objectifs naturels de comprhension et danticipation nous amnent
naturellement construire une reprsentation mentale et abstraite de lensemble des lments qui composent
notre environnement. Ce processus dassimilation et de reprsentation peut se rsumer ainsi :
Modliser, cest reprsenter une entit connue ou inconnue selon des concepts et un vocabulaire connus
Dessiner un plan, prvoir les ractions des gens, faire un portrait, manuvrer un vhicule, faire un croquis pour
expliquer une ide sont des activits ayant directement trait avec la modlisation.
En termes de vision industrielle, la modlisation constitue un outil essentiel dans les domaines de lanalyse
(dfinition du produit) de la conception (description du produit raliser) et du dveloppement (ralisation du
produit). De manire plus gnrale, la modlisation intervient tout au long de la gestion de projet, comme outil
de description et de communication entre les acteurs. Le document rsultant de lactivit de modlisation
constitue le modle. Un modle permet de dcrire et de figer la rponse que lon pense apporter aux exigences :
Un modle est une reprsentation abstraite et non-ambigu du sujet dans un langage donn
Une maquette, un plan, une photo, des mensurations, un mulateur, un organigramme sont des modles.
Ses fonctions premires doutil de description et de communication doivent faire tendre un modle tre
comprhensif, rigoureux, volutif, complet, convivial, raffinable Nanmoins, un modle nexiste que parce
quil rsulte dun point de vue. En effet, un modle est toujours une vision simplifie et formalise dun sujet.
Cette simplification et cette formalisation rsultent du rle quon attend du modle : une photo dune maison ou
ses plans de masses sont deux modles dun mme sujet destins des usages diffrents et rsultant par
consquent daxes dobservation diffrents (un axe purement visuel et un axe plus structurel).
Le point de vue de modlisation est dict par lusage qui va tre fait du modle
Considrer un sujet selon une vue de profil, selon son aspect physique, selon ses ractions thermiques, selon son
organisation, selon son comportement, cest se placer selon diffrents points de vue de modlisation.
La modlisation est finalement une activit de projection :
dun sujet rel (existant ou non),
sur le plan dun langage de modlisation,
selon un angle de considration rsultant de lutilisation attendue du modle,
pour obtenir une vision abstraite, partielle et formalise du sujet (le modle).
Modlisation

Modle
Sujet

Plan de projection
dpendant du formalisme
de modlisation

Axe de projection dans


le prolongement du
point de vue

Figure n1 : Principe de Modlisation

-3-

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

1.2

2005-2006

Les concepts objet

Comme tout domaine de rflexion et de travail, le domaine orient-objet relve de concepts, doutils, de
rgles et dlments spcifiques. La lgitimit de toute ambition dvoluer ou dtudier dans ce type despace
passe par ladoption et la comprhension de lensemble de ces notions propres au domaine orient-objet .

1.2.1

Lobjet

Les activits orientes-objet reposent, comme leur nom lindique, sur le concept dobjet. Dans ce contexte,
lobjet constitue la brique lmentaire partir de laquelle ces activits se construisent. Dans une activit
oriente-objet , tout est objet. La bonne manipulation de ces briques lmentaires repose en partie sur la
connaissance de leur nature, de leurs caractristiques, de leurs aptitudes et de leur structure.
Un objet est donc une entit identifie qui possde un comportement propre (des fonctions spcifiques)
dpendant de son tat interne et avec laquelle on peut interagir (change de messages)
Cette dfinition informelle pose plusieurs questions :
1.
2.
3.
4.

entit identifie : Comment identifie-t-on et dlimite-t-on les objets ?


comportement propre : Quest-ce qui constitue pratiquement le comportement de lobjet ?
tat interne : Quest-ce qui caractrise ltat dun objet ?
interaction : Par quel procd interagit-on avec un objet ?

Une partie des rponses ses interrogations se trouvent dans la reprsentation structurelle des objets :
NOM
Attribut 1 Opration 1 Attribut 2
Opration 2
Attribut 5
Attribut 4
Opration 3 Opration 4
Opration 5 Attribut N
Attribut 3
Opration N

Attribut = Proprit
Opration = Fonctionnalit

Figure n2 : Structure dun objet


1.

Si la question de la dsignation des objets est videmment rsolue par la prsence dune dnomination
de lobjet (le Nom de lobjet, qui traduit la continuit de son existence), le problme de la dlimitation
des objets demeure en suspens. Il sagit dune libert laisse la personne en charge de lactivit
oriente-objet et en tant que telle, cette latitude permet dune part dexprimer une approche plus
personnelle du sujet et dautre part, elle accrot lincertitude dans la faon daborder ce sujet. On peut
nanmoins indiquer que les critres qui guident gnralement la dlimitation des objets relvent du
point de vue de description adopt (au sens o le point de vue a t abord dans la partie Modlisation).
Ainsi, pour dcrire un ordinateur on pourra dire quil se compose dune unit centrale, dun cran, dun
clavier, dune connectique (chacun de ces lments tant lui-mme dcomposable) ou encore dun
systme dexploitation, dune interface homme-machine, dun logiciel de traitement de texte, de jeux,
dun navigateur (chacun de ces lments tant galement dcomposable).

2.

Le comportement dun objet est dtermin par les aptitudes dont il dispose (i.e. ses oprations). Ces
fonctionnalits pourront tre dclenches en interne ou appeles de lextrieur (par dautres objets).

3.

Ltat interne dun objet est caractris par le vecteur de ses attributs. Lensemble des valeurs des
attributs dun objet permet de situer lobjet dans lensemble des tats auxquels il peut accder.

4.

Concernant linteraction avec lobjet, elle va porter essentiellement sur lappel doprations depuis
lextrieur ou plus rarement sur lintervention directe sur les attributs (et donc ltat) de lobjet.

-4-

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

1.2.2

2005-2006

La Classe

Du point de vue dune activit oriente-objet , les objets rsultent de linstanciation de classes (o
linstanciation est laction de crer une entit relle partir dun concept thorique). Une classe constitue donc
la fois le domaine de dfinition et la description gnrique dun ensemble dobjets. Chaque objet appartient ainsi
une unique classe.
Une classe est une description gnrique dune collection dobjets ayant une structure similaire
On peut illustrer les relations entre classes et objets laide de la figure suivante :
Pour chaque objet, lattribut Puissance
et la mthode Rouler() doivent tre
prciss

Objet 1

R11

Objet 2

GS Palace

CLASSE

VOITURE

Objet 4

Proprits
hrites

Objet 3

406

Fuego

Puissance
Rouler()

Figure n3 : Objets et classes (vue de principe et exemple)

1.2.3

LHritage

Une notion importante du monde de lobjet est le concept dhritage. Cette ide permet de factoriser les lments
communs dun ensemble de classes dans une classe plus gnrale. On dira par exemple que le vin, leau, la bire
ou la vodka-orange hritent des proprits des liquides ; et ce mme sils disposent en plus de proprits propres.
Lhritage permet de dcrire les notions de spcialisation ou de gnralisation
Il faut galement noter que lhritage peut tre multiple (i.e. une classe hrite de plusieurs autres). Dans ce
cas, le processus dhritage neffectue pas une union des proprits hrites mais une somme, ce qui peut induire
des conflits et des collisions de dnominations.
ANIMAL

Objet 1
CLASSE C1
MAMMIFERE
Objet 2

C2 hrite de C1

CLASSE C2
Objet 3

ANIMAL DU
DESERT

SeDplacer()
SupporteChaleur

SINGE
MainsPrhensiles
SeDplacer()+

FELIN

CHAT DU
DESERT

Raoul

Carnivore
SeDplacer()+

Figure n4 : hritage et hritage multiple (vue de principe et exemple)


Forte de ces considrations thoriques, la suite du document va tre consacre ltude et la description du
formalisme UML en tant que langage de modlisation oriente-objet.

-5-

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

2. Prsentation dUML
La modlisation et les formalismes existent depuis toujours (croquis, plans, maquettes). La modlisation
oriente-objet est apparue durant les annes 70 et 80 suite lmergence de la programmation oriente-objet. En
effet, il tait indispensable dassocier ces nouvelles techniques de dveloppement de nouveaux outils de
description adapts. Entre 1989 et 1994, le nombre de mthodes et de langages de modlisation orients objet est
pass de moins de 10 plus de 50. Parmi cet assortiment doutils, 3 mergeaient plus particulirement :

La mthode Booch (du nom de Grady Booch son concepteur),


La mthode OOSE (pour Object-Oriented Software Engineering cre par Ivar Jacobson),
La mthode OMT (pour Object Modeling Technique conue par James Rumbaugh).

Face lvolution convergente de ces mthodes, leurs auteurs (Booch, Rumbaugh et Jacobson) ont dcid de
sassocier au sein de lentreprise Rational pour crer le langage UML (Unified Modeling Language) ; lobjectif
de cet outil de modlisation tant dunir les apports de leurs travaux respectifs. Le formalisme UML est
stabilis depuis 1997 (avec la mouture UML 1.1, ce qui nempche pas les volutions puisque actuellement
la toute rcente version UML 2.0 fait rfrence) et est suivi par lOMG (Object Modeling Group, autorit de
normalisation lie lobjet).
UML ne constitue aucunement une mthode de conception mais bien un langage de modlisation
UML a t conu selon les objectifs suivants :

Objectif longitudinal : accompagner lensemble du cycle de conception,


Objectif vertical : tre adapt toutes les chelles de modlisation (du plus haut niveau de considration
la prise en compte des dtails les plus fins),
Objectif tranversal : tre suffisamment comprhensible et convivial pour tre facilement accessible
lhomme et tre dans le mme temps suffisamment formel et rigoureux pour tre adapt au traitement
informatique.

Comme tout langage volu, UML propose :

Un vocabulaire : un ensemble de symboles graphiques


Ce sont les lments de modlisation propre UML (classes, tats, relations) et leur
smantique (la signification de chaque symbole).
Une grammaire : un ensemble des rgles dagencement de ces symboles
Ce sont les lois de construction en UML (un tat doit tre reli un autre tat par une
transition, les hritages ne doivent pas prsenter de cycles, laccs aux proprits
dune classe par une autre classe dpend des relations qui les associent).
Une libert dexpression : un ensemble dalternatives dpendantes du point de vue
Ce sont les diffrents diagrammes proposs par UML (ou combinaisons de
diagrammes) qui peuvent tre choisis selon langle de description (et donc de lecture)
que lon veut donner au modle (vue structurelle : diagrammes de classes et dobjets,
vue comportementale : diagrammes de squences et dtats-transitions, vue
architecturale : diagrammes de composants et de dploiement).

Le formalisme UML peut tre vu comme une bote outil offrant au concepteur un panel de diagrammes parmi
lesquels il va choisir ceux qui sont adapts la finalit du modle quil veut construire. Ces diagrammes sont les
suivants :

Diagramme de cas dutilisation : ensemble des contextes de mise en uvre du sujet modlis
Ce diagramme permet de reprsenter les fonctionnalits principales du systme
modlis, considres du point de vue de lutilisateur.
Diagrammes de classes : description de la structure statique du sujet modlis
Ce diagramme permet de dcrire tout ou partie du systme modlis, dune manire
abstraite, en terme de classes, de structure et dassociations.
Diagrammes dobjets : description de la structure statique dune instance du sujet modlis

-6-

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

Ce diagramme permet de dcrire des exemples de configuration de tout ou partie du


systme modlis, en terme dobjets, de valeurs et de liens.
Diagrammes de squence : reprsentation temporelle du comportement du sujet modlis
Ce diagramme permet de dcrire des scnarios au travers du squencement des
interactions entre les acteurs et composants du modle (description chronologique).
Diagrammes de collaboration : reprsentation spatiale et temporelle du comportement du sujet
Ce diagramme permet de dcrire lagencement des chanes fonctionnelles impliques
dans les scnarios. Ce diagramme est trs proche du diagramme de squence quil
complte de notions de rpartition physique des objets.
Diagrammes dtats-transitions : description du comportement spcifique dune classe
Ce diagramme utilise les automates tats finis (statecharts) pour dcrire lactivit
propre dune classe en terme dtats, dvnements, dactions, de conditions et de
transitions permettant le changement dtat.
Diagrammes dactivit : description doprations en terme de succession dactions
Ce diagramme permet de dcrire le droulement des fonctions et des processus par le
biais de la reprsentation de lorganisation des sous-taches et des flux entre les objets.
Diagrammes de composants : projection du diagramme dobjets sur le plan physico-rel
Ce diagramme permet deffectuer lallocation des composants depuis une vue logique
(diagramme de classes ou dobjets) vers la reprsentation et lorganisation des
composants physiques qui implmenteront rellement le sujet et de leurs dpendances.
Diagrammes de dploiement : description de la mise en place de larchitecture du sujet modlis
Ce diagramme permet de reprsenter le dploiement des composants sur les dispositifs
matriels.

Cette prsentation trs thorique des lments constitutifs du formalisme UML nest destine qu fournir une
vision globale du langage et de son organisation. Cette approche haut-niveau sera reprise lissue de la
prsentation dtaille des diffrents diagrammes mais elle permet dores et dj de positionner les composants
qui vont tre prsents (symboles et conventions graphiques) dans lorganisation globale du langage UML.
Concernant la structure du formalisme UML, on peut en donner la premire vision suivante :
Vue Fonctionnelle

Diagramme de
cas dutilisation

Vue Structurelle

Vue Comportementale
Diagramme
de classes

Diagramme
dtats-transitions

Diagramme
dobjets

Diagramme
dactivit

Diagramme
de squence

Diagramme de
collaboration

Vue Logique
Vue Physique

Vue Architecturale

Diagramme de
composants

Diagramme de
dploiement

Vue Statique

Vue Dynamique

Figure n5 : Une rpartition des diagrammes UML


Ces diffrentes classifications de lespace des diagrammes UML (logique/physique, statique/dynamique, et
fonctionnel/structurel/comportemental/architectural) permettent de dterminer les jeux de diagrammes choisir
en fonction du point de vue adopt. Le point de vue de modlisation tel quil a t prsent en prambule de ce
-7-

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

document est principalement support en UML par le choix des vues du sujet qui doivent tre dcrites et donc
par le choix des diagrammes au sein de ses vues. Afin de mieux apprhender la signification et lintrt de ces
diffrentes vues on peut en donner les dfinitions partielles suivantes :

Vue logique : facette thorique du sujet. Cette vue, dconnecte de toute considration matrielle,
fournit une description base sur les rles, les responsabilits et les relations associes.
Vue physique : aspect organique et matriel du sujet. Cette vue fournit une description base sur les
composants physiques qui implmentent rellement le sujet.
Vue statique : facette relative lagencement des composants. Cette vue sapparente une description
fige du sujet fournissant une photographie de sa physionomie.
Vue dynamique : facette lie lactivit du sujet. Cette vue fournit une reprsentation vivante du sujet
et dcrit ses comportements et ses ractions.
Vue fonctionnelle : facette relative aux contextes dactivit du sujet. Cette vue particulire relve dune
description externe du sujet en tant que fournisseurs de services lenvironnement et aux utilisateurs.
Vue structurelle : aspect organisationnel logique du sujet. Cette vue dcrit la structuration des
diffrents constituants fonctionnels du systme.
Vue comportementale : facette lie au fonctionnement du sujet et de ses composants. Cette vue fournit
une description des actions, processus et modes de fonctionnement sur divers niveaux de granularit.
Vue architecturale : aspect organisationnel physique du sujet. Cette vue dcrit la structuration des
diffrents composants matriels qui constituent organiquement le sujet

Toujours dun point de vue vision gnrale dUML , ce formalisme de modlisation comprend en plus des 9
diagrammes voqus un langage de description de contraintes. Ce langage nomm OCL (pour Object Constraints
Language) permet dajouter une composante smantique plus riche certains diagrammes. Il faut comprendre
que le graphe obtenu lors de la modlisation dune facette dun sujet selon un diagramme donn peut parfois
manquer dune nuance prcise quon souhaiterait voir apparatre. Il est alors toujours possible dassocier une
note au diagramme qui explicite cette notion (et cest souvent ce qui est fait). Cependant, si lon revient sur
lobjectif tranversal voqu en dbut de cette partie, il semble clair que linterprtation par une machine de ces
notes en langage naturel (par exemple lors de la gnration de code partir de modle UML) est totalement
utopique (aujourdhui au moins). OCL pallie ce manquement en offrant un langage de contraintes formalis qui
pourra tre interprt par un ordinateur (comme un langage de programmation). La description du langage OCL
et de ses applications ne fait pas partie des objectifs de ce document.
La prsentation dtaille dUML qui va suivre sarticule autour de la dcoupe selon les diffrentes vues
fonctionnelle, structurelle, comportementale et architecturale. Ce sont donc les diagrammes de cas dutilisation
qui sont prsentes dans un premier temps (vue fonctionnelle) avant quon ne sintresse plus spcifiquement
aux diagrammes de classes et dobjets (en tant que vue structurelle), puis au groupe comportementale avec les
diagrammes de squence, de collaborations, dactivit et dtats-transitions avant de terminer par les diagrammes
de composants et de dploiement pour la vue architecturale.

-8-

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

3. Modle Fonctionnel
Les diagrammes de cas dutilisation composent la vue fonctionnelle du formalisme UML. Ce sont des
diagrammes cruciaux vis vis de la cohrence et de la pertinence du modle en cours de description. En outre,
leur originalit et leur relative indpendance parmi les diagrammes UML leur confrent une certaine spcificit
qui ncessite une tude distincte.

3.1

Concepts de base

Un diagramme de cas dutilisation fait appel deux concepts :

3.1.1

Lacteur : entit extrieure en interaction avec le systme


Le cas dutilisation : une manire dutiliser le systme

Acteur

Les acteurs reprsentent les lments externes aux dlimitations du systme qui sont amens interagir avec
celui-ci. Ils comprennent aussi bien les acteurs humains (utilisateurs) que les acteurs dautre type (machine, autre
systme, tout lment de lenvironnement).
Les acteurs dfinissent les partenaires extrieurs interagissant avec le sujet
Les acteurs jouent un rle important dans le travail de dlimitation des frontire du sujet modlis, ils permettent
de positionner le systme dans son environnement en reprsentant son entourage actif .
Un acteur se reprsente graphiquement sous la forme dun personnage accompagn de sa dsignation (visuel
cr avec Objecteering UML Modeler) :

Figure n6 : Aspect visuel dun acteur

3.1.2

Cas dutilisation

Les cas dutilisation rpondent la question pour quoi le systme va-t-il tre utilis ? (Quels services va-t-il
rendre, vu de lextrieur ?) et dcrivent les rles du sujet. Ces symboles reprsentent le point de vue des
utilisateurs du systme.
Les cas dutilisation dcrivent les fonctionnalits externes du sujet
Il faut galement noter que les cas dutilisation couvrent implicitement lensemble des scnarios oprationnels
associs au sujet (vu de lextrieur en tant quentit globale).
Un cas dutilisation se reprsente graphiquement sous la forme dune figure ovale (ventuellement incluse dans
un cadre structurant) complte de la fonctionnalit reprsente (visuel cr avec Objecteering UML Modeler) :

Figure n7 : Aspect visuel dun cas dutilisation

-9-

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

3.2

2005-2006

Diagramme de cas dutilisation (Use-Case Diagram)

Lobjet dun diagramme de cas dutilisation est de positionner le systme dans son contexte oprationnel et de
dcrire les nouvelles rgles de fonctionnement issues de sa mise en uvre. Ce type de diagrammes se
consacre la description des interactions du sujet avec les acteurs qui lentourent.
Les diagrammes de cas dutilisation prsentent lintgration du sujet dans son environnement
en sintressant sa description fonctionnelle
Le formalisme associ est relativement simple afin de faciliter lexpression du besoin et le dialogue avec le
matre douvrage. La construction de diagrammes de cas dutilisation est une excellente faon daborder la
description et la conception dun systme.
Les relations admises au sein dun diagramme de cas dutilisation sont les suivantes :

Les relations de type dclenchement qui relient un acteur un cas dutilisation : ces relations sont
reprsentes sous la forme dun trait simple et traduisent limplication dun acteur vis vis dun cas
dutilisation (du type lacteur dclenche le cas dutilisation),
Les relations de type inclusion ou utilisation qui relient deux cas dutilisation : ces relations sont
reprsentes sous la forme dune flche pointille accompagne du terme include et traduisent le fait
que le cas dorigine contient obligatoirement le cas destination,
Les relations de type extension ou raffinement qui relient deux cas dutilisation : ces relations sont
reprsentes sous la forme dune flche pointille accompagne du terme extend et traduisent le fait
que le cas dorigine peut optionnellement tre rajout au cas destination,
Les relations de type gnralisation ou spcialisation qui relient deux cas dutilisation : ces relations
sont reprsentes sous la forme dune flche pleine pointe triangulaire vide et traduisent le fait que le
cas dorigine peut remplacer le cas destination.

Pour illustrer ces concepts relatifs la construction dun diagramme de cas dutilisation, on peut sintresser la
description des fonctionnalits dun systme de gestion de commande en ligne pour un organisme de VPC
(visuel cr avec Objecteering UML Modeler) :

Figure n8 : Exemple de diagramme de cas dutilisation

- 10 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

4. Modle Structurel
Les diagrammes de classes et dobjets composent la vue structurelle du formalisme UML. Le diagramme de
classes dcrit de manire abstraite une vision gnrique du sujet alors que le diagramme dobjets dcrit un
exemple de configuration du systme.

4.1

Diagramme de classes (Class Diagram)

Un diagramme de classe dcrit lagencement de classes connectes par des relations de diffrents types. Ce type
de diagramme fait partie de la vue structurelle du sujet et participe sa description logique et statique.
Les diagrammes de classes dcrivent la structure logique du sujet sous une vision orient-objet
Une classe dcrit un groupe dobjets ayant la mme structure (mme ensemble dattributs) et le mme
comportement (mmes oprations). Les relations signifient la smantique de lorganisation des classes.

4.1.1

Classe

Le formalisme UML dcrit une classe en utilisant la symbolique suivante (visuel cr avec Objecteering UML
Modeler) :

Nom de la classe
Attributs de la classe
Mthodes de la classe

Figure n9 : Reprsentation graphique dune classe (vue de principe et exemple)


Le nom dune classe est unique. Il est dit simple lorsquil est de la forme NomClasse et complet lorsquil
est de la forme NomPackage::NomClasse (o NomPackage dsigne lensemble de classes dans lequel la classe
NomClasse est incluse).
Un attribut reprsente une proprit de la classe modlise (il sera donc commun tous les objets de la classe et
pour chaque objet il sera valu). La notation complte dun attribut est la suivante :
[visibilit] nomAttribut [ [multiplicit] ] [:type] [=valeur initiale] [ {proprits} ]
+-#

exemple :

[0..1], [n]

+ taille : real = 1,8

[ ] : lments optionnels

{constant, addOnly}

qui signifie que les objets de cette classe ont un attribut taille de type
rel, daccs publique et dont la valeur par dfaut est 1,8 (en
rajoutant constant, on aurait pu interdire de le modifier pour prciser
par exemple que tous les objets ont dfinitivement une taille de 1,8).

Une mthode (opration) est limplmentation dun service qui peut tre demand tous les objets de la classe
modlise. Les mthodes sont associes au comportement. La notation complte dune mthode est la suivante :
[visibilit] nomMthode [ (paramtres:types) ] [:type retourn] [ {proprits} ]
+-#

exemple :

( param1:type1, param2:type2 )

- moyenne(a,b:real):real

[ ] : lments optionnels

{query, abstract}

qui signifie que les objets de cette classe ont une mthode moyenne
qui prend en entre deux rels (a et b) et fournit un rsultat rel.
Cette mthode est prive (visible pour la classe).

- 11 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

En terme de lisibilit de la classe, on se contente gnralement de faire apparatre sur le modle les attributs et
mthodes importants pour sa comprhension (ce qui nempche leur existence mais les outils informatiques
UML permettent gnralement de cacher certains attributs ou mthodes). Les strotypes (noms entre guillemets,
par exemple : caractristiques visuelles ou proprits dynamiques ) permettent de structurer laffichage
des attributs et des mthodes (plutt que de les montrer en vrac).
Il est possible dajouter un 4 me compartiment la reprsentation graphique dune classe : la responsabilit. Ce
compartiment permet de dcrire les attentes vis vis de la classe. Cette notion de responsabilit permet de
revenir sur les critres de dcoupe dun sujet en classe. En gnral, il est pertinent de se contenter dune ou deux
responsabilits par classes. Si les classes sont trop vastes (modle peu rutilisable) ou si elles sont trop petites
(modle trop abstrait), le modle risque dtre peu reprsentatif et inexploitable.

4.1.2

Relations entre classes

Le formalisme UML associe aux classes un certain nombre de relations permettant dexpliciter leurs rapports.
4.1.2.1

Gnralisation / Spcialisation

Il sagit dune relation entre une classe-mre (ou super-classe) et une classe-fille (ou sous-classe) qui dcrit la
relation dhritage entre la classe-fille et la classe-mre : la sous-classe est drive de la super-classe (elle hrite
de lensemble de ses proprits : attributs, mthodes, associations). La reprsentation graphique est la suivante
(visuel cr avec Objecteering UML Modeler) :

Figure n10 : Reprsentation de la relation de gnralisation / spcialisation (vue de principe et exemple)


Ce type de relation permet lintroduction de classes dites abstraites. Il sagit de classes dont le nom est indiqu
en italique et qui ne peuvent pas tre instancies. Arbre est une classe abstraite dans la mesure o tout arbre rel
instancie une espce donne et non la classe Arbre (il nexiste pas darbre daucune espce).
Lhritage peut tre multiple (une classe-fille hritant de plusieurs classes-mres) afin de prciser en particulier
la nature multiple dune classe. Ce type dhritage peut savrer relativement dlicat manipuler du fait des
collisions qui peuvent tre entranes parmi les attributs et les mthodes. En effet, la classe-fille nhrite pas
de lunion des caractristiques de ses classes-mres mais de la somme. Si les classes-mres disposent de
proprits communes, la classe-fille hrite des deux proprits (estampilles chacune de leur provenance afin de
les diffrencier).
Ces considrations amnent voquer la notion de polymorphisme. Une classe-fille peut redfinir ou simplement
complter une proprit hrite dune classe mre (en particulier une mthode qui peut tre prcis dans le cadre
dutilisation de la classe-fille). Les descendants de la classe-fille hriteront thoriquement de la nouvelle
proprit (celle affine par la dfinition de la classe-fille) qui remplace la proprit initiale dans la chane
dhritage. En pratique, les outils logiciels de modlisation oriente objet ont tendance conserver les deux
proprits dans la chane dhritage (ds la classe qui redfinit la proprit et qui possde ainsi les deux versions)
et laisser la phase dutilisation de ces proprits la responsabilit de prciser celle qui est utiliser (si la
prcision nest pas donne, cest la version la plus rcente de la proprit, i.e. celle redfinie, qui devient
prioritaire). Cette notion de redondance de signature de proprit est dsigne sous le terme de polymorphisme.

- 12 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

Concernant les notions dhritage multiple, la reprsentation graphique est la suivante (visuel cr avec
Objecteering UML Modeler) :

Figure n11 : Reprsentation dhritages multiples (exemple issu dune application bancaire)
4.1.2.2

Association

Il sagit de la relation la plus gnrale entre classes. Cette relation permet de donner du sens (lassociation est
complte dindications smantiques) un lien organisationnel entre classes.
Lassociation permet de dcrire une relation structurelle entre classes, enrichie dun contenu smantique
Une association peut concerner une seule classe (association unaire) ou plusieurs classes (association binaire ou
n-aire). La reprsentation graphique est la suivante (visuel cr avec Objecteering UML Modeler) :

Figure n12 : Reprsentation dassociations entre classes (vue de principe et exemple)


Une association peut contenir un descriptif (qui donne du sens lassociation et justifie son existence), des
cardinalits (1 = un et un seul, 1..* = au moins 1, n = une valeur prcise, * = une valeur quelconque) qui prcise
dans quelles quantits lassociation doit tre instancie, des rles qui permettent de prciser limplication de
chaque classe dans lassociation.
Il faut noter quil est galement possible denrichir la description dune association en compltant sa description
laide dune classe qui est ddie lassociation. Cette classe sappelle alors une Classe-association et prsente

- 13 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

les caractristiques dune classe (hritage, relations, attributs, mthodes) et celles dune association (descriptif,
cardinalits, rles) :

Ce type de relation traduit le fait que la classe-association nest lie aux deux classes composant
lassociation que du fait de lexistence dune relation entre elles (et non pas lie chacune delle
indpendamment).
Ce type dentit correspond globalement un besoin de dcrire les proprits et les caractristiques de
lassociation entre les deux classes (cest une amplification de la reprsentation de lassociation).

Une classe-association permet la fois de complter la description dune association laide de concepts
orients-objet et de faire apparatre un composant du sujet (classe) spcifique la relation
La reprsentation graphique est la suivante (visuel cr avec Objecteering UML Modeler) :

Figure n13 : Reprsentation dune classe-association


Il faut tre vigilant, ce type de notation ne correspond pas la reprsentation dune association entre trois classes
mais bien la description dune relation entre la classe-association dune part et le binme compos des deux
autres classes dautre part.
4.1.2.3

Agrgation

Cette relation dcrit les relations de constitution entre les classes. Elle peut concerner une ou plusieurs classes.
Lagrgation permet de dcrire les notions de contenance ou dappartenance entre classes
Un cas particulier dagrgation est la composition (qui implique que le composant nexiste pas sans le compos).
La reprsentation graphique est la suivante (visuel cr avec Objecteering UML Modeler) :

Figure n14 : Reprsentation dagrgations et de compositions entre classes (vue de principe et exemples)
Le sens de cette relation est dans un sens est lment de ou appartient et dans lautre sens contient
ou est constitu de . La relation de composition traduit le fait que le Bras ne peut exister sans la Personne
qui il appartient.

- 14 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux


4.1.2.4

2005-2006

Dpendance

Sur le plan smantique, toutes les relations (agrgation, association, gnralisation) sont des relations de
dpendance. Cest lutilisation quotidienne qui a amen certaines sous-catgories de dpendances tre
identifies comme suffisamment frquentes et suffisamment importantes pour donner lieu un type de relation
spcifique. Nanmoins la notion de dpendance conserve son importance en UML en gnral et dans la
construction des diagrammes de classes en particulier.
La dpendance traduit le fait que lexistence dun lment (en particulier son comportement)
ncessite la prsence dun autre
Dans le cas des diagrammes de classes, cette relation traduit gnralement la notion dutilisation dune classe par
une autre. Dun point de vue pratique, une relation de dpendance correspond souvent au positionnement dune
classe comme paramtre dune mthode dune autre classe. La reprsentation graphique est la suivante (visuel
cr avec Objecteering UML Modeler) :

Figure n15 : Reprsentation de dpendance entre classes (vue de principe et exemples)


Dans lexemple prcdent, la classe Footballeur dispose dune mthode shooter dont un paramtre est le Ballon
(la nature du ballon influencera cette fonction).
Compte tenu du caractre englobant et originel de la relation de dpendance, il existe un certain nombre
de strotypes permettant de nuancer le sens de cette relation (les strotypes lis aux notions dassociation, de
gnralisation et dagrgation ont disparu pour laisser place ces relations elles-mmes). En thorie, il existe 17
strotypes accessibles pour nuancer ou catgoriser une relation de dpendance (bind, derive, friend, instanceOf,
instanciate, powertype, refine, use, access, import, extend, include, become, call, copy, send, trace).
En pratique ces strotypes ne sont que rarement utiliss dans les diagrammes de classes (beaucoup plus
couramment dans dautres diagrammes : include et extend sont trs prsents dans les diagrammes de cas
dutilisation) moins quon ne cherche obtenir un modle destin limplmentation extrmement dtaill.

4.1.3

Notion de Paquetage (Package)

Les paquetages permettent la structuration verticale des composants trs plat en UML par rassemblement
des lments sous une dnomination commune. Ils permettent dorganiser et de hirarchiser bien dautres
diagrammes que les diagrammes de classes mais ils sont nanmoins trs utiliss dans cette vue structurelle.
Les paquetages constituent des outils de regroupement et dorganisation des composants UML
Un paquetage (appel aussi package) regroupe des classes prsentant un lien smantique ou structurel fort et les
cache compltement au reste de lenvironnement. Les classes contenues dans le paquetage pourront alors tre
publiques (+ public), protges (# protected) ou prives (- private). Or, les paquetages peuvent tre connects par
des relations dhritage ou de dpendance. Cette relation de dpendance est gnralement strotype import
(ou plus rarement access ) et signifie que les classes du paquetage qui fait limport pourront accder librement
aux classes publiques du paquetage import. Les classes prives demeurent quant elles inaccessibles et les
classes protges ne sont visibles que pour les paquetages descendant du paquetage initial.

- 15 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

Cette notion de paquetage permet de dcomposer et dorganiser un diagramme (de classes en particulier) et de ne
pas tre oblig de le construire plat , elle permet galement de rpartir la tche de modlisation en spcifiant
les paquetages et leur contenu exportable (i.e. les classes publiques).
Les paquetages se reprsentent et sutilisent, en terme dimport en particulier, comme prsent sur la figure
suivante (visuel cr avec Objecteering UML Modeler) :

Figure n16 : Reprsentation de paquetages (packages)

4.1.4

Exemple de diagramme de classes

Si lon considre la reprsentation simplifie dun logiciel de dessin basique, on peut considrer quil sagit
dune interface offrant deux zones lcran, lune pour le choix des fonctions-outils (gomme, crayon,
coloriage) et lautre pour la feuille de dessin. Cest la partie reprsentant la feuille de dessin qui appliquera aux
mouvements de la souris une fonction-outil parmi celles proposes dans la partie choix. Un diagramme de
classes dcrivant cet outil peut tre le suivant (visuel cr avec Objecteering UML Modeler) :

Gnralisation

Agrgation

Dpendance

Association

Figure n17 : Exemple de diagramme de classes (utilitaire de dessin simplifi)

- 16 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

Comme toute expression dans un langage volu, ce modle peut tre contest (il faut alors pouvoir le justifier
dune manire rigoureuse et indiscutable) ou reformul (un autre diagramme peut tre tout aussi cohrent avec le
sujet bien que diffrent).

4.2

Diagramme dobjets (Object Diagram)

Un diagramme dobjets reprsente une vision relle du schma thorique dcrit par le diagramme de classes. On
va retrouver de nombreuses analogies et similitude entre le diagramme dobjets et le diagramme de classes.

4.2.1

Objet

Le formalisme UML dcrit un objet en utilisant la symbolique suivante (visuel cr avec Objecteering UML
Modeler) :
Objet orphelin

Objet anonyme

Figure n18 : Reprsentation dobjets


Lobjet qui porte le nom Objet1 instancie la classe Classe et lattribut attribut1 de cette classe Classe est valu
pour cet objet valeur relle 1. Lobjet Objet2 est dit orphelin car on ne sait pas quelle classe il instancie, son
attribut attribut2est valu valeur relle 2. Lobjet :Classe est dit anonyme car on sait quil instancie la
classe Classe mais on ne sait pas son nom, par contre, son attribut attribut1 est valu valeur relle 3. Lobjet
CercleOrigine instancie la classe FormeGomtrique (cf. Figure n9) et ses attributs origine et type sont valus
en accord avec les spcifications de la classe. On peut remarquer que sur cette reprsentation, il a t choisi de ne
pas faire figurer les mthodes des objets (issues de la classe).

4.2.2

Exemple de diagramme dobjets

Si lon se base sur lexemple de logiciel de dessin vu lors de la prsentation du diagramme de classes, on peut
prendre comme illustration le cas de mon logiciel de dessin, nomm Dessinlog et prsenter le diagramme suivant
(visuel cr avec Objecteering UML Modeler) :

Figure n19 : Exemple de diagramme dobjets (un utilitaire de dessin simplifi)

- 17 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

On peut noter que le contenu des objets nest pas reprsent. Le diagramme en est plus lisible et la prsence de
ces contenus ne simposait pas dans ce schma.
La reprsentation des relations est similaires celle utilise pour les diagrammes de classes la diffrence prs
que les associations sont instancies en liens (notation identique aux associations avec le descriptif soulign).
Cependant, usuellement on se contente gnralement dans un diagramme dobjet dutiliser les instances
dassociations (i.e. les liens) qui traduisent la smantique du diagramme (et apporte sa spcificit) alors que les
autres relations (agrgation, gnralisation, dpendance) reprennent des caractristiques structurelles inhrentes
au diagramme de classes originel.

- 18 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

5. Modle Comportemental
Les diagrammes de squence, de collaboration, dactivit et dtats-transitions composent la vue
comportementale du formalisme UML. Ces diagrammes permettent de dcrire la dynamique interne du sujet. En
pratique, on choisit gnralement de reprsenter le comportement du systme en utilisant un sous-ensemble de
ces quatre diagrammes car sils dcrivent des aspects complmentaires du fonctionnement, les recouvrements et
redondances sont nombreux. Il sagit donc de choisir le ou les diagrammes les plus pertinents vis vis de
lobjectif de modlisation.

5.1

Diagramme de squence (Sequence Diagram)

Ce diagramme, qui fait partie de la description logique et dynamique, permet de reprsenter le droulement de
scnarios au travers dune vision squentielle et chronologique des changes et interactions entre les lments
intervenant (acteurs ou composants du modle).
Les diagrammes de squence prsentent le droulement dune phase dactivit du systme en le
caractrisant par lenchanement temporel des changes entre les lments y
participant
Un diagramme de squence regroupe donc les objets et acteurs concerns par un mme scnario et dcrit leurs
changes au moyen dactions et de messages.

5.1.1

Structure dun diagramme de squence

Un diagramme de squence regroupe lensemble des acteurs et objets concerns par le droulement du scnario
dcrit. Chacun de ces lments dispose de sa ligne de vie qui va permettre de reprsenter ses priodes dactivits
(rectangles) et de positionner temporellement les changes (visuel cre avec Objecteering UML Modeler) :
Instance dacteur

Objet

Ligne de vie
Priode dactivit

Actions et changes

Figure n20 : Allure globale dun diagramme de squence

5.1.2

Actions et messages

Les objets et acteurs mis en uvre dans la description dun scnario agissent et communiquent par le biais
dactions et de messages disponibles dans le cadre de la construction dun diagramme de squence.
5.1.2.1 Appel de mthode (Call / Return)
Le principe de lchange Call/Return est de permettre un objet dinvoquer et de dclencher (faire appel) une
opration dun autre objet. Lobjet metteur du message doit donc tre en droit daccder aux mthodes de
lobjet rcepteur (association entre les classes) et lobjet rcepteur doit de son ct tre porteur de la mthode
appele. Le message porte le nom de la mthode appele (qui est une aptitude de lobjet cible).
Il est donc indispensable dassurer la cohrence entre le diagramme de classes et un diagramme de squence : les
mthodes ncessaires lcriture dun diagramme de squence pertinent doivent apparatre dans les classes
concernes. Cette notion de cohrence entre les diffrents diagrammes permet de garantir lhomognit du

- 19 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

modle et dautoriser des retours constructifs sur les diagrammes dj raliss (il est trs courant de revenir, par
exemple, sur un diagramme de classes lors de la ralisation dun diagramme de squence parce quon se rend
compte quune mthode manque dans une classe telle quelle a initialement t conue).
Si lon considre un scnario simple mettant en jeu un individu utilisant une tlcommande lmentaire et une
tlvision, on peut obtenir le diagramme de squence suivant (en lien avec un diagramme de classes)
correspondant la mise en marche de la tlvision depuis la tlcommande, quelques manipulations
(changement de chane, diminution du son) et sa mise en veille (visuel cre avec Objecteering UML Modeler) :

Figure n21 : Lappel de mthode dans un diagramme de squence


Ce diagramme permet de voir que les opration de la tlcommande (les mthodes EmettreSignal) sont appeles
par lacteur (ce qui est bien le cas en pratique puisque cest le fait que lutilisateur appuie sur une touche qui
amne la tlcommande dclencher une de ses oprations) et que les mthodes de la tlvision sont appeles

- 20 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

par la tlcommande (le changement de canal ou la gestion du volume sont des fonctions techniques rellement
internes la tlvision qui ne sexcutent que sur ordre de la tlcommande).
5.1.2.2 Cration et Destruction dObjets (Create / Destroy)
Le principe de ce type de message Create / Destroy dans un diagramme de squence est de permettre un objet
den crer ou den dtruire un autre au cours de lexcution dun scnario. La restriction ce type daction
concerne les droits entre les classes dont sont issus les objets (droits qui doivent tre en accord avec les actions
de cration et de destruction).
En reprenant lexemple de la tlvision, on peut introduire lobjet image et voir comment la tlvision manipule
cet objet (visuel cre avec Objecteering UML Modeler) :

- 21 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

Figure n22 : La cration et la destruction dobjets dans un diagramme de squence

5.3

Diagramme de collaboration (Collaboration Diagram)

Ce diagramme dispose dun statut un peu particulier au sein des diagrammes UML. En effet, le diagramme de
collaboration reprend les principes du diagramme de squence dans un cadre de prsentation diffrent.
Les diagrammes de collaboration regroupent les lments concerns par un mme scnario
et rappelle leurs interactions
Pour illustrer cette notion, on peut dire que si le diagramme de squence permet la description dun scnario dans
un cadre chronologique, le diagramme de collaboration reprsente le groupe dobjet concern par le droulement
de ce mme scnario. Un diagramme de collaboration regroupe donc les objets et acteurs concerns par un mme
scnario et dcrit leur cadre de coopration.

5.3.1

Structure dun diagramme de collaboration

Un diagramme de collaboration dcrit un groupe dobjets dans le cadre dun comportement particulier du
systme. Ce type de diagramme prsente donc un groupe dobjets concerns par un mme scnario en prcisant
les changes et les appels de mthodes effectus au cours du scnario. De manire similaire ce qui concerne le
diagramme de squence, la construction dun diagramme de collaboration ncessite une cohrence avec le
diagramme de classes. Cette cohrence passe par les associations existant entre les classes dont sont issues les
objets (un objet ne peut mettre un message ou appeler une mthode dun autre objet que dans le cadre dune
relation entre les classes dont ils proviennent) mais galement par les mthodes de ces classes (on ne peut
videmment appeler quune mthode existant chez un objet).
Le diagramme de collaboration dcrivant lutilisateur allumant et teignant le tlviseur est le suivant (visuel
cre avec Objecteering UML Modeler) :

Figure n23 : Le diagramme de collaboration Allumer et teindre la tlvision


On peut constater que ce diagramme instancie les objets partir des classes et dcrit au moyen dune
numrotation lensemble des actions effectues dans le cadre du scnario concern (ces actions tant effectues
en accord avec linstanciation des associations existant entre les classes, cf. commande qui permet laction de
la tlcommande sur la tlvision).
Ce diagramme correspond une vision duale du diagramme de squence en intgrant les notions hrites de la
structure logique prsente dans le diagramme de classes.

5.3.2

Notion de collaboration

En UML, la notion de collaboration est associe la ralisation dun lment dynamique. Une collaboration
possde une facette structurelle et statique et une facette comportementale et dynamique. Cette notion dsigne un
ensemble dlments du systme qui interagissent et travaillent ensemble pour assurer un comportement du
systme rsultant de la coopration de ces lments.

- 22 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

Il est important de noter que la notion de coopration est fortement associe au concept dexploitation des
composants du systme. Ainsi, parmi un ensemble de composants dun modle, une premire sous-partie peuttre concerne par une premire collaboration alors quune autre sous-partie (prsentant certains recouvrements
avec la premire) peut quant elle tre concerne par une autre collaboration. Cest ce concept dexploitation
coopratif qui justifie de la prsence des collaborations. La figure suivante illustre conceptuellement lintrt de
lexistence de cette notion de collaboration partir dun diagramme de classes :

Collaboration
rglage image
Collaboration
diffusion de limage

Collaboration
diffusion du son

Figure n24 : Exemple de collaborations dans un systme


Les collaborations, en tant que lien entre les plans structurel et comportemental, se trouvent associes une
opration ou un cas dutilisation. En pratique, on peut souhaiter attacher une collaboration toutes sortes
dlments de modlisation : une classe, un package Une collaboration se reprsente conceptuellement sous la
forme suivante :

NomDeLaCollaboration
Figure n25 : Reprsentation dune collaboration
Le concept de collaboration doit tre expliciter car il ne correspond pas simplement un sous-ensemble de
composants mais bien la mise en action de ce groupe de composants dans le cadre dune tche particulire
(scnario, cas dutilisation, opration et autre phase dynamique). Une collaboration sexplicite donc en UML
laide dun diagramme de squence ou dun diagramme de collaboration (le nom apparat alors ambigu car il ne
sagit pas de la seule faon de dcrire une collaboration).

5.3.3

Comparaison entre diagramme de squence et diagramme de collaboration

Il semble vident, dun point de vue conceptuel, de constater que ces deux types de diagrammes UML
(collaboration et squence) prsentent une proximit dexpressivit et de smantique qui leur confre un statut de
cousins voire de frres (ils sont les outils de description dune collaboration). Ces deux types de diagrammes
sont dailleurs souvent dsigns communment sous la dnomination diagrammes dinteraction .
Concernant lapparente redondance entre ces deux diagrammes, une hypothse quelque peu cynique pourrait
amener penser que puisque UML rsulte de lunification de diffrents langages de modlisation des annes 80
et 90, il est tout fait possible que ces deux diagrammes proviennent originellement de deux formalismes
diffrents et que malgr leur indniable proximit ils aient tous deux t conservs au sein du langage terminal
pour des raisons qui peuvent tre varies (nuances entre les deux qui savrent constructives, attachement des
diffrents auteurs des langages ces diagrammes, ngociations au cours de lunification).

- 23 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

Nanmoins, sil ne faut pas occulter ce genre de possibilit de pieds de nez historiques , on peut constater que
les diagrammes de squences et les diagrammes de collaboration prsentent des nuances tout fait structurantes
par rapport aux objectifs du formalisme UML et qui peuvent en elles-mmes justifier leur prsence conjointe.
Afin de faciliter la slection de lun ou de lautre en fonction des paramtres associs au modle (objectif,
positionnement dans le cycle de conception, domaine technologique concern), il est possible de proposer un
tableau synthtique rcapitulatif des caractristiques respectives et relatives de ces deux types de diagrammes :
Diagramme de squence

Diagramme de collaboration

Thme

Orientation vers le squencement

Orientation vers le regroupement

Objet

Adaptation la modlisation temps-rel

Adaptation aux contraintes de proximit

Rle des changes

Les changes y sont prsents pour leur


ordonnancement

Les changes y sont prsents pour les


couples metteur/rcepteur quils induisent

Positionnement

Pertinence par rapport lanalyse et


la conception

Pertinence par rapport la conception et


au dveloppement

Figure n26 : Comparaison des diagrammes dinteraction


Si ces deux types de diagrammes prsentent certaines caractristiques propres qui permettent de nuancer leur
recouvrement et de souligner leurs intrts respectifs, il nen demeure pas moins quils sont smantiquement
quivalents et ne peuvent tre utiliss que de manire dissocie.

5.4

Diagramme dactivit (Activity Diagram)

Un diagramme dactivit est un dcrit une squence dactions relatives une tche (activit) particulire.
Les diagrammes dactivits dcrivent une phase active du sujet au moyen dorganigrammes
regroupant une succession dtapes organises squentiellement
Cette description met en jeu les objets, leurs mthodes et les messages quils changent. On peut illustrer la
diffrence qui existe entre diagrammes de squence et diagrammes dactivit en la comparant celle qui existe
entre programmation procdurale et programmation oriente objet.

5.4.1

Composants dun diagramme dactivit

Un diagramme dactivit se compose dtats dactivit ou dtats daction et de transitions. Un tat dactivit est
un tat dcomposable de dure non-nulle comportant des actions dentres et/ou de sortie. Un tat daction est un
tat atomique (ou lmentaire) dune dure ngligeable.
Dun point de vue plus formel, les lments de vocabulaire dont le modeleur dispose pour raliser un diagramme
dactivit sont les suivants :

5.4.2

Etat initial et tat final,


Etat daction / tat dactivit
Branchement conditionnel,
Synchronisation (fourches et jonctions),
Traves (dcoupes structurantes du diagramme),
Objets (crs ou modifis par un tat).

Structure dun diagramme dactivit

- 24 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

On retrouve les lments prcdents dans le diagramme dactivit sommaire suivant qui dcrit la procdure
didentification dun utilisateur (visuel cre avec Objecteering UML Modeler) :

Etat initial

Trave

Etat daction

Etat dactivit

Branchement
conditionnel
Fourche

Jonction

Objet cr

Etat final

Figure n27 : Composition dun diagramme dactivit


Le diagramme prcdent permet de constater que les fourches et jonctions jouent effectivement un rle de
synchronisation (les tats dactions AccorderAcces et AfficherMenu sont initis simultanment de mme que
ltat final nest atteint que lorsque ses deux actions sont termines).
Lobjet Menu est cr par laction AfficherMenu et sont tat est prcis ce stade du diagramme. Un objet
modifi par un tat daction ou un tat dactivit sera systmatiquement associ celui-ci et son nouvel tat
(consquence de lintervention de laction ou de lactivit sur cet objet) sera prcis entre crochets.
Le formalisme relatif aux diagrammes dactivit est trs similaire celui parfois employ pour dcrire des
algorithme en langage procdural. Ce diagramme peut tre utilis comme outil de description de processus.

5.5

Diagramme dtats-transitions (State-Transition Diagram)

Un diagramme dtats-transitions est un outil de description du fonctionnement de chaque composant du sujet.


Tout objet issu dune mme classe rpondra au comportement dcrit laide du diagramme dtats-transitions.
Les diagrammes dtats-transitions dcrivent le comportement dune classe
sous la forme dun automate tats finis

- 25 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

Lenjeu de ce type de diagramme est de bien choisir les classes dont on va dcrire le comportement laide de ce
type de diagramme. Le formalisme des diagrammes dtats-transitions reprend celui des Statecharts.

5.5.1

LEtat

Un tat constitue une situation ou une condition (au sens de condition humaine) accessible pour les objets relatifs
la classe dcrite. Lorsquun objet est dans un tat donn, il peut excuter une activit (ventuellement
compose dactions) ou attendre un vnement.
Un tat est une situation qui se produit dans la vie dun objet et au cours de laquelle lobjet satisfait une
condition, ralise une activit ou attend un vnement
Un tat est caractris par un nom et comporte :

des actions dentres : elles sont optionnelles et sont excutes chaque entre dans ltat (quel que soit
le chemin par lequel on a accd ltat),
une activit interne : il sagit daction(s) interne(s) qui compose(nt) le comportement interne de ltat,
des actions de sortie : elles sont optionnelles et sont excutes chaque sortie de ltat (quel que soit le
chemin de sortie de ltat,
de transition(s) interne(s) : appeles aussi auto-transitions, constitues du couple vnement/action, elles
interrompent lactivit interne en cas dapparition de lvnement et dexcutent laction associe.
dvnements diffrs : il sagit dune liste dvnements suivie de /defer qui, sils se produisent, seront
ignors mais conservs en mmoire afin dtre dclars dans le prochain tat ( condition quils ne
soient pas non plus dclars comme vnement diffrs dans celui-ci).

Il existe deux tats particuliers, ltat initial et ltat final. Ces deux tats constituent des pseudo-tats car ils ne
contiennent pas de comportement et marquent simplement le dbut et la fin du comportement de la classe. La
reprsentation graphique dun tat est la suivante (visuel cre avec Objecteering UML Modeler) :
action dentre
action interne
action de sortie
transition interne
tat final
tat

tat initial

Figure n28 : ltat dans le diagramme dtats-transitions


Remarque : Objecteering UML Modeler ne permet pas (dans la version utilise pour rdiger ce document) la
reprsentation des vnements diffrs.

5.5.2

La Transition

Les transitions permettent le passage dun tat un autre (dun tat source un tat cible).
Une transition est une relation entre deux tats, contraintes par certaines conditions
et accompagne de certaines actions
La transition se compose de plusieurs lments (tous optionnels) :

un vnement dclencheur : occurrence dun stimulus qui va dclencher la transition. Ce stimulus peut
tre de type vari : signal, appel, vnement temporel, vnement de modification,

- 26 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

une condition de garde : expression boolenne place entre crochets qui sera value ponctuellement
lapparition de lvnement dclencheur et qui conditionnera la validation de lvnement. Si pour un
vnement donn la condition de garde nest pas vrifie, lvnement sera perdu,
une action : cette action, prcd dun symbole / , sera effectue au passage de la transition.

La reprsentation graphique dune transition est la suivante (visuel cre avec Objecteering UML Modeler) :
condition de garde
vnement
action

Figure n29 : ltat dans le diagramme dtats-transitions


Dans cet exemple, lvnement signal* (cest dire un signal quelconque de la tlcommande) conditionn par
la condition de garde AlimOK (cest dire que la tlvision soit encore sous tension) permet le franchissement de
la transition vers ltat diffusion avec lexcution de laction Allumer( ).
Il est important de noter que la seule diffrence entre une action sur une transition et une action dentre est que
la premire ne sera effectue que si la transition est franchie alors que la seconde sera excute lissue de tout
franchissement dune transition amenant dans ltat.
Ainsi, dans lexemple de la figure n22, laction Allumer( ) pourrait tre place, de manire rigoureusement
quivalente, en action dentre de ltat Diffusion dans la mesure o il ny a quun chemin daccs cet tat (par
la transition Veille Diffusion).

5.5.3

LEvnement

Un vnement peut tre interne ou externe (signal dun composant, commande dun utilisateur, fait du
lenvironnement) et intervient dans le droulement de la vie du systme.
Un vnement relve de loccurrence localise (dans le temps et dans lespace) dun stimulus
Les vnements se classent parmi les quatre types suivants :

signal : il sagit dun objet envoy et reu par des objets du systme. Cest donc un objet ordinaire du
modle faisant partie dune structure hirarchise de signaux. Il sera associ une opration de lobjet
metteur par le biais dune association de dpendance strotype Send et les classes sensibles ce
signal comporteront un compartiment abonnement supplmentaire dans leur structure contenant les
signaux auxquels la classe est abonne (reprsentation non-incluse dans Objecteering UML Modeler),
appel : il sagit du dclenchement dune opration,
vnement temporel : mesure dune dure laide de linstruction After (After 1s),
vnement de modification : surveillance dun instant particulier laide de linstruction When portant
gnralement sur des attributs de la classe (When heure=12h15, When altitude=5000).

Les signaux constituent une catgorie dvnements importante dans la mesure o ces derniers sapparentent
des objets au sein du modle. La hirarchie des signaux peut alors tre dcrite laide des concepts relatifs aux
classes et aux objets et sintgrer dans les diagrammes de classes.

- 27 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

Lexemple suivant dcrit larrangement des signaux relatifs au systme tlcommande/tlvision (visuel cre
avec Objecteering UML Modeler) :

Figure n30 : les signaux (hirarchie et lien avec les classes)

5.5.4
5.5.4.1

Principe de description des diagrammes dtats-transitions


Dcomposition

Il peut tre intressant de regrouper un comportement lmentaire lintrieur dun tat plus gnral. On peut
alors dcrire ce comportement lmentaire lintrieur de ltat gnral dsign sous la forme de sous-tats. Un
sous-tat est un tat embot dans la description de lactivit dun super-tat.
La figure suivante prsente lintgration de sous-tats (Veille et Diffusion) dans un super-tat (Sous-tension)
illustrant le principe de dcomposition (visuel cre avec Objecteering UML Modeler) :

- 28 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

Figure n31 : Dcomposition dtats en sous-tats


5.5.4.2

Historique

Lvolution dans un diagramme dtats-transitions peut tre interrompue et il peut alors savrer intressant de
pouvoir revenir dans un sous-tat dans lequel on se trouvait avant linterruption. Le symbole H (pour Historique)
permet de reprsenter cette mmorisation.
Chaque entre dans un super-tat passe par lhistorique et active le dernier tat par lequel on est pass dans le
super-tat. Dans le cas du premier passage ou dun passage indterministe, cest ltat par dfaut (celui vers
lequel pointe lhistorique) qui est activ.
La figure suivante prsente lintgration de lhistorique dans un super-tat (Diffusion) illustrant le principe de
traabilit (visuel cre avec Objecteering UML Modeler) :

Figure n32 : Dcomposition dtats en sous-tats

- 29 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

Dans ce diagramme, on traduit le fait que lorsque la tlvision est en veille, lorsquon sera amen la rallumer,
elle diffusera automatiquement celle des trois chanes qui tait active lors de la dernire mise en veille.
5.5.4.3

Paralllisme

Dans un diagramme dtats-transitions on peut tre amen dcrire deux sous-diagrammes qui voluent en
parallle dans un super-tat. Ces sous-tats permettent de prciser plusieurs automates tats-finis qui
fonctionnent de manire synchronise : les tats finaux doivent tous tre activs pour que le super-tat ait
termin son activit.
La figure suivante prsente lintgration du paralllisme pour la classe CombinTlvisionMagntoscope dans un
super-tat (Sous-Tension) illustrant le principe selon lequel lappareil peut la fois jouer son rle de tlviseur
classique et garantir en parallle la programmation dun enregistrement.
On ne peut alors mettre lappareil hors-tension tant que si lenregistrement est termin (prsence dun tat final),
par contre, la diffusion nentrane pas de contrainte sur cette mise hors tension (pas de prsence dtat final). Ce
principe de paralllisme se retrouve sur la figure n26 (visuel cre avec Objecteering UML Modeler) :

Figure n33 : Paralllisme au sein dun super-tat


Il est important didentifier clairement quil sagit de la description parallle de deux comportements avant
dutiliser les concepts de paralllisme : on est en effet souvent tent davoir recours ce type de principe pour
dcrire la prsence de plusieurs actions au sein dun tat (alors quil ne sagit que dune dcomposition de
lactivit interne de ltat).

- 30 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

6. Modle Architectural
Les diagrammes de composants et de dploiement composent la vue architecturale du formalisme UML. Ces
diagrammes permettent de dcrire la dynamique interne du sujet. En pratique, on choisit gnralement de
reprsenter le comportement du systme en utilisant un sous-ensemble de ces quatre diagrammes car sils
dcrivent des aspects complmentaires du fonctionnement, les recouvrements et redondances sont nombreux. Il
sagit donc de choisir le ou les diagrammes les plus pertinents vis vis de lobjectif de modlisation.

6.1

Diagramme de composants (Components Diagram)

Le diagramme de composant entre directement dans la description physique (et statique) du sujet. Il sattache
concrtiser les considrations logiques et abstraites vers le monde rel.
Les diagrammes de composants dcrivent les lments physiques concrtisant le systme et leurs relations
Cest partir de ce type de diagramme quon dtermine les choix de ralisation (on va dfinir quels constituants
techniques vont raliser physiquement le systme). Ces composants constituent la finalisation de certains
lments logiques (objets ou classes).

6.1.1

Le Composant

Un composant est une reprsentation dune partie physique du systme (ventuellement remplaable) qui
reprend et instancie un regroupement dlments logiques (il constitue lemballage tangible des objets).
Un composant est un lment, gnralement strotyp, qui participe lexcution relle du systme
Les composants peuvent tre strotyps selon diverses natures :

executable : composant pouvant tre excut,


library : composant implmentant une bibliothque objet statique ou dynamique,
table : composant reprsentant une table de base de donnes,
file: composant assimilable un document contenant un code source ou des donnes,
document : composant implmentant un document gnral.

Chacun de ces strotypes offre une reprsentation graphique spcifique. Nanmoins, Objecteering UML
Modeler ne propose pas ces symboles particuliers et se contente de certains strotypes. La figure suivante
contient ainsi une reprsentation des symboles spcifiques et certaines quivalences obtenues avec Objecteering
UML Modeler :
Executable :

Library :

Autres strotypes
dObjecteering

Table :

File :

Document :

Figure n34 : Les strotypes de composants (formalisme UML et outil Objecteering UML Modeler)
- 31 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

Outre cette typologie des composants, on distingue un second mode de classification relatif au niveau
dintervention des composants. Cette approche permet de distinguer trois types de composants qui sont
thoriquement mme de rassembler des composants issus des cinq types prsents prcdemment (executable,
library, table, file, document) :

6.1.2

composants de dploiement : les composants ncessaires et suffisants pour former un systme


excutable. Ces composants regroupent globalement les excutables (executable), les bibliothques
dynamiques (library),
composants produits du dploiement : ces composants rsultent du processus de dveloppement. Ils se
composent des fichiers code source et des fichiers de donnes (file),
composants dexcution : ces composants rsultent quant eux dune excution du systme. Ce sont les
produits du fonctionnement du sujet.

Structuration du diagramme de composants

Un premier moyen dorganisation des composants relve de la possibilit de les regrouper dans des paquetages.
De plus, les composants peuvent tre connects entre eux par le biais des relations classiques (dpendance,
gnralisation, association, agrgation) ou relis aux classes, en particulier celles quils ralisent
physiquement par le biais de relations dites de ralisation.
En pratique, les relations qui sont les plus usites lors de la ralisation dun diagramme de composants sont
celles de dpendance et en moindre proportion, celles de ralisation (lorsquon veut lier le diagramme de
composants des classes). Cette relation de dpendance relve en gnral plus dune convention dcriture qui
signifie que le composant origine de la dpendance importe les interfaces du composant destination de la
dpendance .
Un exemple de diagramme de composants reprsentant une application de gestion de commandes peut tre
reprsent laide de la figure suivante (visuel cre avec Objecteering UML Modeler) :

Figure n35 : Un exemple de diagramme de composants


Une notion importante relative au diagramme de composants est quil permet de reprsenter quels lments
logiciels ou matriels vont implmenter la vue logique du systme mais quils ne permettent de visualiser
larchitecture physique (en terme de machines et de choix technologiques) qui va tre ralise.

6.2

Diagramme de dploiement (Deployment Diagram)

Le diagramme de dploiement entre dans la vue physique (et statique) du sujet. Il vise reprsenter les choix
technologiques et matriels finaux sur lesquels seront positionns les composants.
Les diagrammes de dploiement reprsentent la configuration des nuds dexcution
et des composants qui rsident sur ces nuds

- 32 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

Cest la topologie du matriel qui est abord avec ce type de diagramme. Leur intervention est donc
extrmement tardive et vise essentiellement la phase de dveloppement (mme si on peut galement placer cette
tape en amont afin de conduire un travail de dimensionnement).
Si Le formalisme UML nest pas restreint globalement dans son utilisation au seul domaine du gnie logiciel, les
diagrammes de dploiement sont pour leur part exclusivement ddis la reprsentation physique de systmes
informatiss.

6.2.1

Le Nud

Les nuds sont les lments de base des diagrammes de dploiement. Il sagit dlments physiques qui existent
au moment de lexcution et reprsente une ressource (mmoire, capacit de calcul ou de traitement). Les nuds
reprsentent gnralement les processeurs ou les priphriques.
Si les composants reprsentent le regroupement et limplmentation physiques de constituants logiques, les
nuds dcrivent le matriel sur lequel ces composants sont dploys et excuts.
La dsignation dun nud se fait laide dun nom issu du vocabulaire de limplmentation. Un nud se
reprsente comme indiqu sur la figure suivante (visuel cre avec Objecteering UML Modeler) :

Figure n36 : Reprsentation dun nud


On peut noter que la reprsentation dun nud peut saccompagner de complments similaires ceux quon
fournirait pour dcrire les caractristiques dune classe (attributs et mthodes). On peut, par exemple, prciser
quun Processeur possde les attributs vitesseProcesseur et mmoire ainsi que les oprations allumer( ),
teindre( ), et suspendre( ). Cependant, cette fonctionnalit nest pas prvue par la version dObjecteering UML
Modeler utilise pour la ralisation de ce document.

6.2.2

Structuration du diagramme de dploiement

Les nuds peuvent tre organiss laide de paquetages (tout comme les classes et les composants). Ils peuvent
galement tre relis par les relations de gnralisation, association, agrgation et dpendance. On peut en
particulier expliciter la relation entre un nud et le composant quil dploie en positionnant une relation de
dpendance du nud vers le composant.
Cependant, en pratique, la relation la plus utilise est lassociation entre nuds. Cette relation reprsente alors
une connexion physique entre les composants (connexion ethernet, ligne srie, bus partag, liaison satellite, etc.).
Un exemple de diagramme de dploiement est donn par la figure suivante (visuel cr avec Objecteering UML
Modeler) :

Figure n37 : Un exemple de diagramme de dploiement

- 33 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

7. Utilisation dUML
UML nest pas une mthode, cest un langage de modlisation , nous lavons rpt tout au long de ce
document ; et la prsentation dUML qui a t faite sest essentiellement attache en donner une vision
permettant den apprhender concrtement les concepts.
Lobjectif de ce document est donc de permettre au lecteur dacqurir une connaissance de lensemble du
formalisme UML suffisante pour le mettre en position dorganiser lui-mme son utilisation de ce langage de
modlisation en fonction de ses objectifs de modlisation.
Nanmoins, certains principes de modlisation ou certaines approches mthodologiques existent (de manire
indpendante et gnralement postrieure la cration du langage UML) et il est videmment intressant de les
voquer lissue de cette prsentation dUML.

7.1

Principes de modlisation

Comme nous lavons dj voqu, la modlisation est une activit ancestrale indissociable du fonctionnement
mental de ltre humain. Cet acquis historique nous permet de rappeler quatre grands principes de modlisation
dicts par lexprience (cf. Le Guide de lutilisateur UML G. Booch, J. Rumbaugh, I. Jacobson). Ces
principes, globalement indpendants du formalisme de modlisation adopt, sadaptent tout fait la
modlisation oriente objet avec UML.

7.1.1

Premier principe de modlisation


Le choix des modles crer a une forte influence sur la manire
daborder un problme et sur la nature de sa solution

Les modles doivent tre choisis avec soin car, sils sont pertinents, ils feront ressortir les problmes de
dveloppement inhrents au sujet et apporteront par l-mme un claircissement et de prcieuses indications
quant la faon de les rsoudre.

7.1.2

Deuxime principe de modlisation


Tous les modles peuvent avoir diffrents niveaux de prcision

Les diffrents utilisateurs dun modle (client, analyste, dveloppeur) de mme que les diffrents stades du
cycle de vie exigent de pouvoir visualiser le systme avec une prcision variable.

7.1.3

Troisime principe de modlisation


Les meilleurs modles ne perdent pas le sens de la ralit

Une lacune courante des techniques danalyse structure rside dans le dcalage fondamental entre le modle
analytique et le modle conceptuel dun systme (i.e. les modles relatifs aux phases danalyse et de conception).
Il est en effet indispensable de connatre les conventions de simplification et lcart la ralit qui accompagnent
la construction du modle de conception.

7.1.4

Quatrime principe de modlisation


Parce quaucun modle nest suffisant lui seul, il est prfrable de dcomposer
Un systme important en un ensemble de sous-modles presque indpendants

La cohrence de lensemble des diffrents points de vue dun modle garantit lefficacit de la modlisation. La
quasi-indpendance des diffrents modles (couvrant les diffrents angles dapprhension du systme) permet
leur dveloppement spar tout en assurant leur homognit et leur cohrence globale.

- 34 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

7.2

2005-2006

Rational Unified Process (RUP)

Un processus est un ensemble dtapes plus ou moins ordonnes, destines atteindre un objectif. Concernant
les objectifs dun processus dingnierie logicielle, il sagit de livrer un produit logiciel qui rponde aux besoins
exprims.
UML est largement indpendant des processus de conception, ce formalisme peut ainsi tre utilis avec de
nombreux processus dingnierie logicielle. Le RUP (Rational Unified Process) est lune de ces approches de
cycle de vie particulirement adapte au langage UML.

7.2.1

Caractristiques du processus RUP

Le RUP est un processus itratif particulirement adapt au traitement des projets actuels. Leur complexit et
leur degr de sophistication se prtent particulirement une approche de ce type offrant la flexibilit suffisante
pour ragir lintroduction de nouvelles exigences ou de changement dobjectifs commerciaux. Ce processus est
ainsi qualifi de configurable.
Les activits du RUP sont orientes vers la cration et la maintenance de modles plutt que de documents
papier. Ce processus est centr sur larchitecture : il sagit de concentrer linitiation du cycle sur la dtermination
de lignes de base de larchitecture logicielle. Ce plan architectural est une base solide facilitant le dveloppement
en parallle, qui rduit le travail de rvision et augmente la rutilisabilit et la maintenabilit du systme.
Ce processus est pilot par les cas dutilisation et met fortement laccent sur la construction de systmes bass
sur une comprhension approfondie de la faon dont le systme sera utilis. Cest donc une conception guide
par le besoin et les scnarios.

7.2.2

La structure itrative du RUP

Le RUP sappuie sur quatre concepts distincts qui sont les cycles dvolution, les phases, les itrations et les
activits. Il est important de cerner de quelle manire ces lments du RUP sont agencs.
Le cycle de dveloppement dun systme repose sur un premier cycle dvolution appel cycle de dveloppement
initial. Ce premier cycle dvolution conduira la premire version du systme et pourra tre suivi dautres
cycles dvolution ( = cycles de dveloppement des versions ultrieures).
Chacun de ces cycles dvolution se dcompose en quatre phases. Une phase est lintervalle temporel sparant
deux jalons importants du processus :
1.
2.
3.
4.

Cration (ou Inception) :


Elaboration :
Construction :
Transition :

dfinition du cadre du projet, tude dopportunit,


tablissement du plan du projet et dune architecture solide,
dveloppement du systme en version bta,
livraison du systme aux utilisateurs finaux.

Chacune de ces phases se dcompose en itrations (en gnral entre 1 et 3) qui correspondent la conduite dun
ou plusieurs cycle(s) dactivits. En fonction de la phase dans laquelle on se trouve, litration (et donc le cycle
dactivits) sera plus ou moins consacre certaines des activits du cycle dactivits. Les activits (appele
aussi workflow selon les descriptions du RUP) prsentes dans chacun des cycle dactivits ainsi que les attendus
(en particulier en terme de dlivrables UML) de chacune delles sont les suivantes :
1.

Gestion de projet :

2.

Modlisation mtier :

3.

Analyse des besoins :

4.

Analyse et conception :

5.

Implmentation :

planification, allocation (tches et ressources), tude (faisabilit et risques)


calendrier du projet, diagramme de GANTT (par le chef de projet)
modlisation (structure et fonctionnement)
cas dutilisation de lorganisation (par le concepteur dorganisation)
exigences (fonctionnelles et non-fonctionnelles)
cas dutilisation du systme, descriptif de linterface (par lanalyste)
description de la solution thorique rpondant aux besoins
diagrammes de classes, de collaboration, dtats-transitions, de
composants (par larchitecte et/ou le concepteur)
transcription en programme (utilisation de composant existants)
code (par les dveloppeurs)

- 35 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux


6.
7.
8.
9.

2005-2006

Test :

droulement du jeu de test, limites


diagnostics (par le testeur)
Dploiement :
distribution du logiciel dans son environnement oprationnel
diagramme de dploiement
Maintenance/Evolution : gestion des volutions (pendant lavancement du projet)
plan de modification
Environnement :
support du dveloppement (slection des outils, administration systme)
documentation

Ces activits sagencent, dans le cycle dactivits relatif chacune des itrations selon le principe suivant :
3. Analyse des besoins
4. Analyse et conception
5. Implmentation

1. Gestion de projet
2. Modlisation mtier

7. Dploiement

8. Maintenance et volution

6. Test

1. Gestion de projet, 9. Environnement

Figure n38 : Un cycle dvolution dune itration


A chaque itration, les rsultats (planification, modles, prototypes, jeux de tests) de litration prcdente sont
rutiliss, valus, corrigs, amliors. La consquence naturelle ce phnomne est que chacune des activits
est plus ou moins prsente dans un cycle dactivit selon la phase dans laquelle on se trouve. La figure suivante
illustre ce principe dimplication quantitative des activits (ce qui permet donc de dduire la nature des cycles
dactivits) dans les phases :
Cration

Elaboration

Construction

Transition

1. Gestion de projet
2. Modlisation mtier
3. Analyse des besoins
4. Analyse et conception
5. Implmentation
6. Test
7. Dploiement
8. Maintenance et volution
9. Environnement
Figure n39 : Implication des activits en fonction des phases
Le RUP est donc un processus de conception bas sur un cycle de dveloppement (rsultant ventuellement de
cycles dvolution) compos de quatre phases regroupant une ou plusieurs itrations du cycle dactivit constitu
de workflows de processus (activits).

- 36 -

Frdrick Benaben

Ecole des Mines dAlbi-Carmaux

2005-2006

8. Bibliographie

Les ouvrages et documents suivants ont permis dalimenter ce cours :

Le guide de lutilisateur UML

Grady Booch, James Rumbaugh, Ivar Jacobson

Ouvrage : EYROLLES ISBN 2-212-09103-6

UML en action

Pascal Roques, Franck Valle

Ouvrage : EYROLLES ISBN 2-212-11213-0

UML 2 en action

Pascal Roques, Franck Valle

Ouvrage : EYROLLES ISBN 2-212-11462-1

UML pour lanalyse dun systme dinformation

Chantal Morley, Jean Hugues, Bernard Leblanc

Ouvrage : DUNOD ISBN 2-100-04826-0

UML et RUP : un survol

Thrse Libourel, Marianne Huchard

Cours DEA Informatique LIRMM (Universit de Montpellier II)

Unified Modeling Language

J.-P. Bourey

Cours Ecole Centrale Lille

UML 2 par la pratique

Pascal Roques

Ouvrage : EYROLLES ISBN 2-212-11480-X

UML 2.0 Guide de rfrence

Grady Booch, James Rumbaugh, Ivar Jacobson

Ouvrage : EYROLLES ISBN 2-7440-1820-1

- 37 -

Frdrick Benaben