Prsent par: - Mr Vonjy Heritiana RATSITOBAINA

- Mr Ulrich FARALAHY WONG

- Mlle Cynthia ANDRIAMANJARISOA

Liste des acronymes
OMG : Object Management Group
OMT : Object Modeling Technique
OOSE : Object Oriented Software Engineering
UML : Unified Modeling Language

INTRODUCTION
Parmi les langages de modlisation existants, Unified Modeling Language (en
franais Langage de Modlisation Objet Unifi) est le plus soutenu par le march. Cependant,
plusieurs versions dUML sont dj{ normalises par lObject Management Group.
Ce langage de modlisation connat une amlioration de la version 1.x la version
2.x. Pour ne pas ngliger les nouveauts apports par UML 2, nous avons dcid de rdiger cet
ouvrage intitul Organisation de lUnified Modeling Language version 2.0 et version
antrieur .
Notre ouvrage sera divis en trois grandes parties. Dabord, la premire partie
nous allons faire une prsentation gnrale. Ensuite, la deuxime partie de louvrage sera
consacre la prsentation des diffrents types de diagrammes dUML 2. Enfin, dans la troisime
partie, nous vous prsenterons un exemple doutil de modlisation avec tude de cas.

Premie re partie : Pre sentation
ge ne rale
Chapitre 1 : Historique dUML
Durant les annes 90, Deux mthodes ont t les plus diffuses en France entre
autre lOMT de James Rumbaugh et BOOCH de Grady Booch. Par ailleurs, OOSE de Ivar Jacobson
sest aussi impose dans le monde objet pour la partie formalisation des besoins.
Pour aller plus loin dans le rapprochement, James Rumbaugh et Grady Booch se
sont retrouvs au sein de la socit Rational Software et ont t ensuite rejoints par Ivar
Jacobson en se donnant comme objectif de fusionner leur mthode et crer UML (Unified
Modeling Language).
Il est important de noter que contrairement ce qui avait t envisag au dpart,
le processus de dveloppement a t sorti du champ couvert par le projet de norme. UML est
donc une norme du langage de modlisation objet qui a t publie, dans sa premire version, en
novembre 1997 par lOMG, instance de normalisation internationale du domaine de lobjet.
En quelques annes, UML sest impose comme standard utiliser en tant que
langage de modlisation objet. Et Aujourdhui, en cette fin de la premire dcennie des annes
2000, nous avons dj{ une dizaine dannes de recul sur lenseignement et la pratique dUML en
entreprise.
Ainsi, les grandes tapes de lexpansion dUML peuvent se rsumer comme suit :
1993-1994 : Les deux mthodes Booch93 et OMT-2 sont leaders sur le march et sont
de plus en plus proches.
Octobre 1994 : James Rumbaugh rejoint Grady Booch chez Rational Software. Ses deux
mthodes ont t unifies.
Octobre 1995 : Mthode Unifie 0.8
Fin 1995 : le fondateur dObjectory, Ivar Jacobson, rejoint { son tour Rational Software
Juin 1996 : sortie de la version 0.9 dUML
Janvier 1997 : Soumission { lOMG de la version UML 1.0
Septembre 1997 : sortie de la version 1.1 dUML
23 novembre 1997 : la version 1.1 dUML est adopte par lOMG
1998-1999 : sortie des versions 1.2 et 1.3 dUML
2000-2001 : sortie des dernires versions suivantes 1.x
2002-2003 : prparation de la version 2 dUML
10 octobre 2004 : sortie de la version 2.1 dUML
2007 : sortie de la version 2.1.1 et de la version 2.1.2 dUML
2008 : sortie de la version 2.2 dUML
2010 : sortie de la version 2.3 dUML
Aot 2011 : sortie de la version 2.4.1 dUML
UML nest donc pas un nouveau langage mais cest une fusion de plusieurs
langages. Afin de bien comprendre la fonctionnalit dUML, il est prfrable de dfinir quelques
mots qui sont utiliss le long de ltude. Nous consacrerons notre deuxime chapitre de cette
premire partie ces quelques dfinitions.

Chapitre 2 : Quelques dfinitions
UML a t pens pour permettre de modliser les activits de l'entreprise, pas pour les
rgir.

Son indpendance (par rapport aux langages d'implmentation, domaine d'application,
processus...) en font un langage universel.

Deuxie me partie :
Les diagrammes dUML 2


Dans cette partie, nous allons prsenter les diffrents types de diagrammes
dUML 2. UML dans sa version 2 propose treize diagrammes qui peuvent tre utiliss dans
la description dun systme. Ces diagrammes sont regroups dans deux grands ensembles : les
diagrammes de comportement et les diagrammes structurels.
Pour ne pas mlanger les problmes, les diagrammes sont ensuite dcoups
suivant les quatre points de vue de modlisation : fonctionnel, statique, dynamique et
implmentation, en insistant pour chacun sur le ou les diagrammes UML principaux.
Chapitre 3 : Les diagrammes de comportement
Les diagrammes comportementaux sont focaliss sur la description de la partie
dynamique et fonctionnelle du systme modliser. Sept diagrammes sont proposs par UML 2
pour assurer cette description.
A. Fonctionnel
Pour ce point de vue fonctionnel, un seul diagramme sera prsent.
1. Le diagramme de cas dutilisation :
Les cas dutilisation constituent un moyen de recueillir et de dcrire les besoins
des acteurs du systme. Ils permettent de dcrire linteraction entre les acteurs et le systme. Sa
reprsentation met en jeu trois concepts : lacteur, le cas dutilisation et linteraction entre
lacteur et le cas dutilisation.
Un acteur :
Cest un utilisateur type qui a toujours le mme comportement vis--vis dun cas
dutilisation. Ainsi les utilisateurs dun systme appartiennent { une ou plusieurs classes
dacteurs selon les rles quils tiennent par rapport au systme.
Il peut aussi tre un systme externe avec lequel le cas dutilisation va interagir.
Un acteur peut se reprsenter symboliquement par un bonhomme et tre
identifi par son nom. Il peut aussi tre formalis par une classe strotype acteur

Figure 1: Reprsentation d'un acteur

Un cas dutilisation :
Un cas dutilisation correspond { un certain nombre dactions que le systme
devra excuter en rponse { un besoin dun acteur.
Linteraction entre lacteur et le cas dutilisation :
Une interaction permet de dcrire les changes entre un acteur et un cas
dutilisation.
Linteraction entre un acteur et un cas dutilisation se reprsente comme une
association. Elle peut comporter des multiplicits comme toute association entre classes.

Figure 2 : Prsentation de cas d'utilisation

Afin doptimiser la formalisation des besoins en ayant recours notamment { la
rutilisation de cas dutilisation, trois relations peuvent tre dcrites entre cas dutilisation :
une relation dinclusion ( include ),
une relation dextension ( extend ),
une relation de gnralisation.

Une relation dinclusion dun cas dutilisation A par rapport { un cas dutilisation
B signifie quune instance de A contient le comportement dcrit dans B.
Une relation dextension dun cas dutilisation A par un cas dutilisation B signifie
quune instance de A peut tre tendue par le comportement dcrit dans B. Deux
caractristiques sont noter :
le caractre optionnel de lextension dans le droulement du cas dutilisation standard
(A) ;
la mention explicite du point dextension dans le cas dutilisation standard.
Une relation de gnralisation de cas dutilisation peut tre dfinie
conformment au principe de la spcialisation-gnralisation dj prsente pour les classes.
B. Du point de vue dynamique
1. Le diagramme de squence
??????????????????
2. Le diagramme dtat-transition
?????????????????????
3. Le diagramme dactivit
Le diagramme dactivit prsente un certain nombre de points communs avec le
diagramme dtat-transition puisquil concerne le comportement interne des oprations ou des
cas dutilisation. Cependant le comportement vis ici sapplique aux flots de contrle et aux flots
de donnes propres { un ensemble dactivits et non plus relativement { une seule classe. Les
concepts communs ou trs proches entre le diagramme dactivit et le diagramme dtat-
transition sont :
transition,
nud initial (tat initial),
nud final (tat final),
nud de fin flot (tat de sortie),
nud de dcision (choix).
Le formalisme reste identique pour ces nuds de contrle.
Les concepts spcifiques au diagramme dactivit sont :
nud de bifurcation,
nud de jonction,
nud de fusion,
pin dentre et de sortie,
flot dobjet,
partition.
Une action :
Une action correspond { un traitement qui modifie ltat du systme. Cette action peut
tre apprhende soit { un niveau lmentaire proche dune instruction en termes de
programmation soit un niveau plus global correspondant une ou plusieurs oprations.
Formalisme et exemple :
Une action est reprsente par un rectangle dont les coins sont arrondis comme pour
les tats du diagramme dtat-transition. La figure ci-dessus illustre notre dfinition.

Figure 3 : Formalisme et exemple d'une action
Transition et flot de contrle :
Ds quune action est acheve, une transition automatique est dclenche vers laction
suivante. Il ny a donc pas dvnement associ { la transition. Lenchanement des actions
constitue le flot de contrle.
Formalisme et exemple
Le formalisme de reprsentation dune transition est donn { la figure suivante :

Figure 4 : Formalisme de base du diagramme dactivit : actions et transition
Une activit :
Une activit reprsente le comportement dune partie du systme en termes dactions
et de transitions. Une activit est compose de trois types de nuds :
nud dexcution (action, transition),
nud de contrle (nud initial, nud final, flux de sortie, nud de
bifurcation, nud de jonction, nud de fusion-test, nud de test-dcision, pin
dentre et de sortie),
nud dobjet.
Une activit peut recevoir des paramtres en entre et en produire en sortie.

Formalisme et exemple
Nous donnons une premire reprsentation simple la figure suivante :

Figure 5 : Exemple de reprsentation dune activit
Nud de bifurcation (fourche)
Un nud de bifurcation (fourche) permet { partir dun flot unique entrant de crer
plusieurs flots concurrents en sortie de la barre de synchronisation.
Formalisme et exemple :
Le formalisme de reprsentation de nud de bifurcation ainsi quun premier exemple
sont donns la Figure 6. Un second exemple avec nud de bifurcation est donn { la Figure 7.

Figure 6 : Exemple 1 dactivits avec nud de bifurcation

Figure 7 : Exemple 2 de diagramme dactivit
Nud de jonction (synchronisation)
Un nud de jonction (synchronisation) permet, { partir de plusieurs flots concurrents
en entre de la synchronisation, de produire un flot unique sortant. Le nud de jonction est le
symtrique du nud de bifurcation.
Formalisme et exemple :
Le formalisme de reprsentation dun nud de jonction est illustr la figure suivante :

Figure 8 : Exemple dactivits avec nud de jonction

Nud de test-dcision
Un nud de test-dcision permet de faire un choix entre plusieurs flots sortants en
fonction des conditions de garde de chaque flot. Un nud de test-dcision na quun seul flot en
entre. On peut aussi utiliser seulement deux flots de sortie : le premier correspondant la
condition vrifie et lautre traitant le cas sinon.
Formalisme et exemple :
Le formalisme de reprsentation dun nud de test-dcision ainsi quun premier
exemple sont donns la Figure 9. Un second exemple avec nud de test-dcision est donn la
Figure 10.

Figure 9 : Formalisme et exemple 1 dactivits avec nud de test-dcision

Figure 10 : Exemple 2 de diagramme dactivits avec un nud de test-dcision
Nud de fusion-test
Un nud de fusion-test permet davoir plusieurs flots entrants possibles et un seul flot
sortant. Le flot sortant est donc excut ds quun des flots entrants est activ.
Formalisme et exemple :
Le formalisme de reprsentation dun nud de fusion-test ainsi quun exemple sont
donns la figure ci-dessous.

Figure 11 : Formalisme et exemple de diagramme dactivits avec un nud de fusion-test
Pin dentre et de sortie
Un pin dentre ou de sortie reprsente un paramtre que lon peut spcifier en entre
ou en sortie dune action. Un nom de donne et un type de donne peuvent tre associs au pin.
Un paramtre peut tre de type objet.
Formalisme et exemple :
Chaque paramtre se reprsente dans un petit rectangle. Le nom du paramtre ainsi
que son type sont aussi { indiquer. Le formalisme de reprsentation de pin dentre ou de sortie
ainsi quun exemple sont donns { la figure suivante.

Figure 12 : Formalisme et exemple dactivit avec pin dentre et de sortie
Flot de donnes et nud dobjet
Un nud dobjet permet de reprsenter le flot de donnes vhicul entre les actions.
Les objets peuvent se reprsenter de deux manires diffrentes : soit en utilisant le pin dobjet
soit en reprsentant explicitement un objet.
Formalisme et exemple :
Le formalisme de reprsentation de flot de donnes et nud dobjet est donn
directement au travers dun exemple (Figure 13).

Figure 13 : Exemple de flot de donnes et de nud dobjets
Partition
UML permet aussi dorganiser la prsentation du diagramme dactivit en couloir
dactivits. Chaque couloir correspond { un domaine de responsabilit dun certain nombre
dactions.
Les flots dobjets sont aussi reprsents dans le diagramme. Lordre relatif des couloirs
de responsabilit nest pas significatif.
Reprsentation du diagramme dactivit :
Un exemple gnral de diagramme dactivit est donn { la figure suivante :

Figure 14 : Exemple de diagramme dactivit avec couloir dactivit
Reprsentation dactions de communication
Dans un diagramme dactivit, comme dansun diagramme de temps, des interactions de
communication lies { certains types dvnement peuvent se reprsenter.
Les types dvnement concerns sont :
signal,
coulement du temps.
Formalisme et exemple :
Le formalisme de reprsentation ainsi quun exemple dactions de communication sont
donns la figure suivante :

Figure 15 : Formalisme et exemple de diagramme dactivit


4. Le diagramme dinteraction
Le diagramme global dinteraction permet de reprsenter une vue gnrale des
interactions dcrites dans le diagramme de squence et des flots de contrle dcrits dans le
diagramme dactivit.
Autrement dit, le diagramme global dinteraction est un diagramme dactivit dans
lequel on reprsente des fragments dinteraction ou des utilisations dinteractions. Ainsi, il est
possible de reprsenter :
des choix de fragments dinteractions (fusion) ;
des droulements parallles de fragments dinteractions (dbranchement et jonction)
;
des boucles de fragments dinteraction.
Les lignes de vie concernes par le diagramme global dinteraction peuvent tre cites
dans len-tte du diagramme mais ne sont pas reprsenter graphiquement.
Le diagramme global dinteraction utilise les concepts du diagramme dactivit auquel
on ajoute deux complments :
Les fragments dinteraction du diagramme de squence Il sagit comme le montre la
figure ci-dessous de la notion de fragment dinteraction vue dans le diagramme de squence
mais qui ne doit pas tre dtaill ce niveau.

Figure 16 : Exemple de fragment dinteraction
Les utilisations de fragments dinteraction Il est aussi possible de faire appel des
fragments dinteraction { laide de loprateur ref comme la montre la figure ci-dessous.

Figure 17 : Exemple de fragment dinteraction avec loprateur ref
1. Le diagramme de communication
2. Le diagramme de temps
Le diagramme de temps combine les diagrammes de squence et d'tat pour proposer
un point de vue sur l'volution de l'tat d'un objet au fil du temps, et sur les messages qui
modifient cet tat.
Il permet de reprsenter les tats et les interactions dobjets dans un contexte o le
temps a une forte influence sur le comportement du systme grer.
Le diagramme de temps utilise trois concepts de base :
Ligne de vie Elle reprsente lobjet que lon veut dcrire. Elle se dessine de manire
horizontale. Plusieurs lignes de vie peuvent figurer dans un diagramme de temps.
tat ou ligne de temps conditionne Les diffrents tats que peut prendre lobjet
dtude sont lists en colonne permettant ainsi de suivre le comportement de lobjet ligne par
ligne (une ligne pour un tat).
tats linaires Il sagit du mme concept que le prcdent, mais la reprsentation de
la succession des tats est faite de manire linaire { laide dun graphisme particulier

Chapitre 4 : Les diagrammes structurels
A. Du point de vue statique
1. Le diagramme de classe
Le diagramme de classe constitue lun des pivots essentiels de la modlisation
avec UML. En effet, ce diagramme permet de donner la reprsentation statique du systme
dvelopper.
2. Le diagramme dobjet


3. Le diagramme de structure composite
Le diagramme de structure composite permet de dcrire des collaborations dinstances
(de classes, de composants) constituant des fonctions particulires du systme dvelopper.
Collaboration
Une collaboration reprsente un assemblage de rles dlments qui interagissent en
vue de raliser une fonction donne. Il existe deux manires de reprsenter une collaboration :
reprsentation par une collaboration de rles
reprsentation par une structure composite : le diagramme de structure composite
Reprsentation et exemples
Reprsentation par une collaboration de rles :
Dans ce cas, une collaboration est formalise par une ellipse en pointill dans laquelle
on fait figurer les rles des lments qui interagissent en vue de raliser la fonction souhaite
(Figure 18). Dans cet exemple, la fonction Persistance objets mtier rsulte dune collaboration
entre deux rles dlments :
mapping : classeMtier
stockage : tableBDD

Figure 18 : Exemple de reprsentation dune structure composite laide dune collaboration de
rles
Reprsentation par un diagramme de structure composite :
Cette nouvelle reprsentation (Figure 19) permet de montrer plus explicitement les
lments de la collaboration :
la collaboration reprsente par une ellipse en pointill
les lments participant { la collaboration (classe, composant) reprsents
lextrieur de la collaboration
les rles considrs dans chaque participation reprsents sur les liens entre les
lments participants et la collaboration

Figure 19 : Exemple de reprsentation de collaboration dinstances par un diagramme de structure
composite
Dans cet exemple, la fonction Persistance objets mtier rsulte dune collaboration
entre la classe ClasseMtier considre suivant le rle mapping et la classe TableBDD
considre suivant le rle stockage.
Cette reprsentation permet aussi de prciser les seuls attributs des classes
participantes qui sont considrs suivant les rles pris en compte.
B. Du point de vue implmentation
1. Le diagramme de composant
Le diagramme de composant permet de reprsenter les composants logiciels dun
systme ainsi que les liens existant entre ces composants.
Les composants logiciels peuvent tre de deux origines : soit des composants mtiers
propres une entreprise soit des composants disponibles sur le march comme par exemple les
composants EJB, CORBA, .NET, WSDL.
Composant
Chaque composant est assimil un lment excutable du systme. Il est caractris
par :
un nom ;
une spcification externe sous forme soit dune ou plusieurs interfaces requises (une
interface requise est une interface ncessaire au bon fonctionnement du composant) soit
dune ou plusieurs interfaces fournies (une interface fournie est une interface propose
par le composant aux autres composants).
un port de connexion.
Le port dun composant reprsente le point de connexion entre le composant et une
interface. Lidentification dun port permet dassurer une certaine indpendance entre le
composant et son environnement extrieur.
Formalisme gnral :
Un composant est reprsent sur la figure ci-dessous par un classeur avec le mot-cl
composant ou bien par un classeur comportant une icne reprsentant un module.

Figure 20 : Formalisme gnral dun composant
Les deux types de reprsentation et exemples
Deux types de reprsentation sont disponibles pour modliser les composants : une
reprsentation bote noire et une reprsentation bote blanche . Pour chaque
reprsentation, plusieurs modlisations des composants sont proposes.
Reprsentation bote noire
Cest une vue externe du composant qui prsente ses interfaces fournies et requises sans entrer
dans le dtail de limplmentation du composant. Une bote noire peut se reprsenter de
diffrentes manires.
Connecteur dassemblage :
Une interface fournie se reprsente { laide dun trait et dun petit cercle et une interface requise
{ laide dun trait et dun demi-cercle. Ce sont les connecteurs dassemblage.
Un exemple de modlisation avec les connecteurs dassemblage est donn { la figure suivante, le
composant Commande possde deux interfaces fournies et deux interfaces requises.

Figure 21 : Reprsentation dun connecteur dassemblage
Connecteur dinterfaces :
Une autre reprsentation peut tre aussi utilise en ayant recours aux dpendances
dinterfaces utilise et ralise :
pour une interface fournie, cest une relation de ralisation partant du composant et
allant vers linterface
pour une interface requise, cest une dpendance avec le mot-cl utilise partant du
composant et allant vers linterface.
Un exemple de modlisation avec connecteurs dinterfaces est donn { la figure
suivante. Le composant Commande possde une interface fournie GestionCommande et une
interface requise Produit .

Figure 22 : Reprsentation dun composant avec connecteur dinterfaces

Compartiment :
Une dernire manire de modliser un composant avec une reprsentation bote noire
est de dcrire sous forme textuelle les interfaces fournies et requises { lintrieur dun second
compartiment. Un exemple de modlisation avec les compartiments est donn la figure
suivante :

Figure 23 : Reprsentation dun composant avec compartiments
Reprsentation bote blanche
Cest une vue interne du composant qui dcrit son implmentation { laide de
classificateurs (classes, autres composants) qui le composent. Plusieurs modlisations sont
possibles pour la reprsentation bote blanche.
Compartiment :
Une manire de modliser un composant avec une reprsentation bote blanche est de dcrire
sous forme textuelle les interfaces fournies et requises { lintrieur dun compartiment, les
classificateurs (classes, autres composants) dans un autre compartiment, les artefacts (lment
logiciel : jar, war, ear, dll) qui reprsentent physiquement le composant dans un dernier
compartiment.
Un exemple de modlisation avec les compartiments est donn la figure suivante :

Figure 24 : Reprsentation bote blanche avec compartiments
Dpendance :
Une autre reprsentation interne du composant peut tre aussi utilise en ayant
recours aux dpendances. Ainsi, les classificateurs qui composent le composant sont relis
celui-ci par une relation de dpendance. Les relations entre les classificateurs (association,
composition, agrgation) sont aussi modlises. Nanmoins, si elles sont trop complexes, elles
peuvent tre reprsentes sur un diagramme de classe reli au composant par une note.
Un exemple de modlisation bote blanche avec les dpendances est donn la suivante :

Figure 25 : Reprsentation bote blanche avec dpendances
Ports et connecteurs :
Le port est reprsent par un petit carr sur le composant. Les connecteurs permettent de relier
les ports aux classificateurs. Ils sont reprsents par une association navigable et indiquent que
toute information arrive au port est transmise au classificateur.
Un exemple de reprsentation avec port et connecteur du composant Commande est donn la
figure suivante :

Figure 26 : Reprsentation bote blanche avec connecteurs
Dans lexemple de la figure prcdente, le composant Commande est constitu de
deux classes (classificateur) relies par une agrgation : DetailCommande et LigneCommande.
Linterface fournie GestionCommande est accessible de lextrieur via un port et
permet daccder via les connecteurs aux oprations des deux classes DetailCommande et
LigneCommande (ajouterLigneCommande, calculTotal-Commande, calculPrixLigne).
Linterface requise Personne est ncessaire pour laffichage du dtail de la commande
et est accessible via un port du composant Commande.
Linterface requise Produit est ncessaire pour le calcul du prix de la ligne de
commande et est accessible via un port du composant Commande.
2. Le diagramme de dploiement
Le diagramme de dploiement permet de reprsenter larchitecture physique supportant
lexploitation du systme. Cette architecture comprend des nuds correspondant aux supports
physiques (serveurs, routeurs) ainsi que la rpartition des artefacts logiciels (bibliothques,
excutables) sur ces nuds. Cest un vritable rseau constitu de nuds et de connexions
entre ces nuds qui modlise cette architecture.
2.1 Nud
Un nud correspond { une ressource matrielle de traitement sur laquelle des artefacts seront
mis en uvre pour lexploitation du systme. Les nuds peuvent tre interconnects pour
former un rseau dlments physiques.
Formalisme et exemple :
Un nud ou une instance de nud se reprsente par un cube ou paralllpipde donne par la
figure suivante :

Figure 27 : Reprsentation de nuds
Complments sur la description dun nud
Il est possible de reprsenter des nuds spcialiss. UML propose en standard les deux
types de nuds suivants :
Unit de traitement Ce nud est une unit physique disposant de capacit de
traitement sur laquelle des artefacts peuvent tre dploys. Une unit de traitement est
un nud spcialis caractris par le mot-cl device.
Environnement dexcution Ce nud reprsente un environnement dexcution
particulier sur lequel certains artefacts peuvent tre excuts. Un environnement
dexcution est un nud spcialis caractris par le motcl executionEnvironment .
2.2 Artefact
Un artefact est la spcification dun lment physique qui est utilis ou produit par le processus
de dveloppement du logiciel ou par le dploiement du systme. Cest donc un lment concret
comme par exemple : un fichier, un excutable ou une table dune base de donnes.
Un artefact peut tre reli { dautres artefacts par notamment des liens de dpendance.
Formalisme et exemple :
Un artefact se reprsente par un rectangle (Figure 28) caractris par le mot-cl
artifact et/ou une icne particulire dans le coin droit du rectangle.

Figure 28 : Reprsentation dun artifact
Deux complments de description sont proposs par UML pour la reprsentation des artefacts.
2.3 Spcification de dploiement
Une spcification de dploiement peut tre associe chaque artefact. Elle permet de
prciser les conditions de dploiement de lartefact sur le nud sur lequel il va tre implant.
Formalisme et exemple :
Une spcification de dploiement se reprsente par un rectangle avec le mot-cl
deployment spec . Un exemple dun artefact avec une spcification de dploiement est donn {
la figure suivante :

Figure 29 : Exemple dun artefact avec spcification de dploiement
2.4 Liens entre un artefact et les autres lments du diagramme
Il existe deux manires de reprsenter le lien entre un artefact et son nud
dappartenance :
Reprsentation inclusive Dans cette reprsentation, un artefact est reprsent { lintrieur du
nud auquel il se situe physiquement. Un exemple est donn { la figure suivante :

Figure 2.46 Exemple de reprsentation inclusive dartefact
Reprsentation avec un lien de dpendance typ deploy Dans ce cas lartefact est
reprsent { lextrieur du nud auquel il appartient avec un lien de dpendance entre lartefact
et le nud typ avec le mot-cl deploy . Un exemple est donn la figure suivante :

Figure 30 : Exemple de reprsentation dartefact avec lien de dpendance
Un artefact peut reprsenter un ou plusieurs lments dun modle. Le qualificatif manifest
permet dindiquer ce type de dpendance.
2.5 Reprsentation et exemples
Le diagramme de dploiement reprsente les nuds de larchitecture physique ainsi
que laffectation des artefacts sur les nuds conformment aux rgles de dploiement dfinies.
Un premier exemple est donn la figure suivante :

Figure 31 : Exemple de reprsentation dun diagramme de dploiement
Un second exemple relatif { une implmentation dune architecture J2EE avec quatre nuds est
donn la Figure 32.
Dans lexemple de la Figure 32, plusieurs composants sont dploys.
Un serveur web o se trouvent les lments statiques du site dans une archive : images, feuilles
de style, pages html (static.zip).
Un serveur dapplication front sur le lequel est dploye larchive front.ear compose de
lapplication web front.war et dautres composants ncessaires au fonctionnement de cette
archive web comme clientejb.jar (classes permettant lappel aux EJB) et commun.jar
(classes communes aux deux serveurs dapplication).
Un serveur dapplication mtier sur lequel sont dploys les composants :
ejb.jar . Ils sont packags dans larchive metier.ear . Deux autres archives sont ncessaires
au fonctionnement des EJB : dao.jar (classes qui permettent laccs { la base de donnes) et
commun.jar (classes communes aux deux serveurs dapplication).
Un serveur BDD (base de donnes) sur lequel sont stockes des procdures stockes PL/SQL :
scripts.sql .

Figure 32 : Exemple de diagramme de dploiement comportant quatre nuds
3. Le diagramme de paquetage
Nous proposons au lecteur une prsentation dtaille dUML 2 en privilgiant
notamment dans les exemples et les tudes de cas le contexte dutilisation des systmes
dinformation.