Chapitre I : le langage UML et le processus unifi

I. Introduction
Les mthodes danalyse orientes objet sont initialement issues des milieux
industriels. La proccupation dominante de leurs auteurs est le gnie logiciel, cest--
dire les principes et les techniques permettant daugmenter la rigueur et la qualit quand
on construit une application informatique. Initialement, UML(Unified Modeling
Language) est le rsultat de la fusion de trois mthodes orientes objet.
La mthode OOD, object oriented design, de grady booch a t conu la
demande du ministre de la dfense des tats-Unis. Lobjectif tait de prparer de faon
rigoureuse la structuration des programmes crits en langage ADA ou C++.
La mthode OMT object modeling technique de James Rumbaugh en 1996 a t
mise au point gnral lectrique. Ses auteurs ont t largement influencs par les
applications dinformations industrielles (automates ,contrle de processus ..). En plus
des principes des langages objet, ils ont t inspirs par les techniques de modlisation
conceptuelle des mthodes danalyse des annes 1980.
La mthode OOSE, object oriented software engineering d'IVAR Jacobson en
1993 est dorigine universitaire (informatique temps rel ) et industrielle. Comme OMT,
la mthode a emprunt aux mthodes danalyse antrieures la technique de modlisation
conceptuelle, enrichie des aspects comportementaux. Son originalit consiste faire
reposer lanalyse sur lexpression par lutilisateur de la faon dont il pense utiliser le
futur systme.
vnement considrable et presque miraculeux, les trois "gourous" qui rgnaient
chacun sur l'une des trois mthodes se mirent d'accord pour dfinir une mthode
commune qui fdrerait leurs apports respectifs (on les surnomme depuis "the
Amigos"). C'est de cet effort de convergence qu'est n UML, "Unified Modeling
Language", l'adjectif "unified" tant l pour bien marquer qu'UML "unifie" et donc
remplace les mthodes antrieures.
Dans ce chapitre nous allons dtailler le langage UML ainsi quun processus de
dveloppement.

7
 Chapitre I : le langage UML et le processus unifi

II. Le langage UML

II.1. Dfinition dUML

Cest un langage de modlisation graphique base de pictogrammes, conu pour
reprsenter, spcifier les artefacts de systmes logiciels, de plus il est destin
comprendre et dcrire des besoins spcifis et documents des systmes, esquiss des
architectures logicielles, concevoir des solutions et communiquer des points de vue,
comme il peut tre appliqu toutes sortes de systmes ne se limitant pas au domaine
informatique.
UML rsulte de lunification de techniques ayant fait leurs preuves pour lanalyse et
la conception de grands logiciels et de systmes complexes. [1][2]

UML est une norme

Il est ncessaire qu'une mthode objet soit dfinie de manire rigoureuse et unique
afin de lever les ambiguts. De nombreuses mthodes objet ont t dfinies, mais
aucune n'a su s'imposer en raison du manque de standardisation. C'est pourquoi
l'ensemble des acteurs du monde informatique a fond en 1989 l'OMG (Object
Management Group), une organisation but non lucratif, dont le but est de mettre au
point des standards garantissant la compatibilit entre des applications programmes
l'aide de langages objet et fonctionnant sur des rseaux htrognes (de diffrents
types).
A partir de 1997, UML est devenue une norme de l'OMG, ce qui lui a permis de
s'imposer en tant que mthode de dveloppement objet et tre reconnue et utilise par de
nombreuses entreprises.

UML est un langage de modlisation objet

UML comble une lacune importante des technologies objet, il permet dexprimer,
dlaborer et de modliser au sens de la thorie des langages, de ce fait il contient les
lments constitutifs de ce derniers : concepts, une syntaxe et une smantique.

UML dcrit un mta modle

La puissance et lintrt dUML est quil normalise la smantique des concepts quil
vhicule, il repose sur un mta modle pour permettre nimporte qui de dchiffrer son
intention de manire non quivoque, il est donc primordiale de saccorder sur la

8
 Chapitre I : le langage UML et le processus unifi

smantique des lments de modlisation, bien avant de sintresser la manire de les

prsenter.

II.2. Points fort dUML

Il permet ainsi :

un gain de prcision.

un gage de stabilit.

l'utilisation d'outils.

Il cadre l'analyse et facilite la comprhension de reprsentations abstraites
complexes. Son caractre polyvalent et sa souplesse en font un langage
universel. [3]

II.3. Points faibles dUML

La mise en pratique d'UML ncessite un apprentissage et passe par
une priode d'adaptation.

L'intgration d'UML dans un processus n'est pas triviale, et amliorer un

processus est une tche complexe et longue. [3]

II.4. Les diagrammes

II.4.1. Dfinition dun diagramme

Un diagramme UML est une reprsentation graphique, qui s'intresse un

aspect prcis du Modle.
Chaque type de diagramme UML possde une structure et vhicule une
smantique prcise.

II.4.2. Les Diffrents types de diagrammes

Diagrammes structurels ou diagrammes statiques

Diagramme de classe : class diagram

Les diagrammes de classes expriment de manire gnrale la structure statique

dun systme, en termes de classes et de relations entre ses classes. Outre les classes, ils
reprsentent un ensemble dinterfaces et de paquetages, ainsi que leurs relations.
Les diagrammes de classes contiennent gnralement les lments suivant :
 Les classes : Une classe est la description dun ensemble dobjet qui partage les
mmes attributs, les mmes oprations, les mmes relations et la mme smantique.
Une classe est symbolise par un rectangle.

9
 Chapitre I : le langage UML et le processus unifi

 Attribut : Un attribut est une proprit nomme dune classe qui dcrit un
ensemble de valeurs que les instances de cette proprit peuvent prendre. Une classe
peut ne pas avoir, comme elle peut avoir un ou plusieurs attributs.
 Opration : Une opration est une abstraction de ce que peut raliser un objet et
qui est ralisable par tous les objets de la classe. Une classe peut ne pas avoir comme
elle peut avoir plusieurs oprations.
 Les relations dassociation dagrgation et de composition
Une association : reprsente une relation smantique durable entre deux classes.
Une agrgation est un particulier dassociation non symtrique exprimant une relation
de contenance.
Une composition est une agrgation plus forte.

Diagramme dobjets : object diagram

Les diagrammes dobjets servent, dune part inventorier les objets (i.e les
instances de classe) composant une application un instant donn ainsi que les
relations, dautre part donner une image statique des relations entre ces objets. Ils
peuvent galement tre mis en uvre pour tester la pertinence dun diagramme de
classe.

Diagramme de composant : component diagram

Les diagrammes de composants servent reprsenter la configuration logicielle

ainsi que les relations dun systme, on permettant galement de reprsenter les
programmes, les sous programmes et les interrelations.

Diagramme de dploiement : deployment diagram

Les diagrammes de dploiement reprsentent un ensemble de nuds ainsi que leurs

relations. On les utilise pour illustrer la vue de dploiement statique dune architecture.
Les diagrammes de dploiement sont apparents aux diagrammes de composant car un
nud englobe gnralement un ou plusieurs composants.

Diagramme de cas dutilisation : use case diagram

Les diagrammes de cas dutilisation reprsentent un ensemble de cas dutilisation,

dacteurs et leurs relations. Ils reprsentent la vue statique des cas dutilisation dun
systme et sont particulirement importants dans lorganisation et la modlisation des
comportements dun systme.

10
 Chapitre I : le langage UML et le processus unifi

 Les cas dutilisation : Les cas d'utilisation dcrivent, sous la forme d'actions et
de ractions, le comportement, ou tout simplement ce que fait le systme du point de
vue de l'utilisateur, encore appel acteur. On recense, de la sorte, l'ensemble des
fonctionnalits d'un systme en examinant les besoins fonctionnels de chaque acteur.
 Les acteurs : Un acteur reprsente un ensemble cohrent de rles jous par les
utilisateurs des cas dutilisation en interaction avec ces cas dutilisation. En rgle
gnrale, un acteur reprsente un rle quun homme, une machine ou mme un autre
systme joue avec le systme. Il existe 4 grandes catgories d'acteurs :
- les acteurs principaux. Cette catgorie regroupe les personnes qui utilisent les
fonctions principales du systme.
- les acteurs secondaires. Cette catgorie regroupe les personnes qui effectuent des
tches administratives ou de maintenance.
- le matriel externe. Cette catgorie regroupe les dispositifs matriels autres que
les ordinateurs comme les priphriques.
- les autres systmes. Cette catgorie regroupe les systmes avec lesquels le
systme interagit.
 Les relations entre les cas dutilisations: UML dfinit trois types de relations
standardises entre cas dutilisation, dtailles ci aprs :
- La relation dinclusion : formalise par le mot cl include , le cas dutilisation de
base en incorpore explicitement un autre de faon obligatoire.
- La relation dextension : formalise par le mot cl extend , le cas dutilisation de
base en incorpore explicitement un autre, de faon optionnelle.
- La relation de gnralisation ou spcialisation : Les cas dutilisation descendant
hrite de la description de leur parent commun. Chacun entre eux peut nanmoins
comprendre des interactions spcifiques supplmentaires. [2]

Diagrammes comportementaux ou diagrammes dynamiques

Diagramme dactivit : activity diagram

Le diagramme d'activit est attach une catgorie de classe et dcrit le

droulement des activits de cette catgorie. Le droulement s'appelle "flot de contrle".
Il indique la part prise par chaque objet dans l'excution d'un travail. Il sera enrichi par
les conditions de Squencement.

Diagramme dtats-transitions : State machine diagram
Ils ont pour rle de reprsenter les traitements (oprations) qui vont grer le
domaine tudi. Ils dfinissent l'enchanement des tats de classe et font donc apparatre

11
 Chapitre I : le langage UML et le processus unifi

l'ordonnancement des travaux. Le diagramme d'tats-transition est associ une classe

pour laquelle on gre diffrents tats : il permet de reprsenter tous les tats possibles
ainsi que les vnements qui provoquent les changements d'tat.

Diagramme de squence : Squence diagram
Un diagramme de squence met en vidence le classement des messages par ordre
chronologique. On forme un diagramme de squence en plaant dabord les objets qui
participent linteraction en haut du diagramme. Le long de laxe des abscisses. En
gnrale. On place lobjet qui dbute linteraction gauche, puis on continue en
progressant vers la droite, les objets les plus subordonns tant tout fait droite. On
place ensuite les messages envoys et reus par ces objets le long de laxe des
ordonnes, par ordre chronologique, du haut vers le bas. Cela donne au lecteur une
indication visuelle claire du flot de contrle dans le temps.
En gnrale, les diagrammes de squence contiennent :
 lobjet : est une manifestation concrte dune abstraction laquelle on peut
appliquer un ensemble doprations et qui possde un tat capable de mmoriser les
effets de ces oprations. On reprsente un objet en soulignant son nom.
 Le lien: est une liaison smantique entre objets, en gnrale, il sagit dune
instance dune association. Chaque fois quune classe est relie une autre par une
association, il peut y avoir un lien entre les instances des deux classes, et chaque fois
quun lien existe entre deux objets, le premier objet peut envoyer un message au
deuxime.
 Le message : est la spcification dune communication entre objets, qui
transporte des informations et qui saffiche dans le but de dclencher une activit. La
rception dune instance de message peut tre considre comme une instance dun
vnement.

Diagramme de collaboration : collaboration diagram

Les diagrammes de collaboration (tout comme les diagrammes de squence) sont

des cas particuliers de diagrammes dinteractions qui reprsentent une vue dynamique
du systme. Les diagrammes de collaboration prsentent un ensemble de rles jous
par des objets dans un contexte particulier, ainsi que les liens entre ces objets. [4][5]

12
 Chapitre I : le langage UML et le processus unifi

III. Le choix de la mthode

Il existe plusieurs mthodes de dveloppement logiciel construites sur UML
comme la mthode : UP, RUP, TTUP, UP agile, XP, 2TUP ..
Parmi ses mthodes notre choix est bas sur la mthode UP (Unified Process).

III.1. Le processus unifi

III.1.1. Dfinition du processus unifi

Le processus unifi est un processus de dveloppement logiciel itratif, centr sur

l'architecture, Pilot par des cas d'utilisation et orient vers la diminution des risques
.C'est un patron de processus pouvant tre adapte une large classe de systmes
logiciels, diffrents domaines d'application, diffrents types d'entreprises,
diffrents niveaux de comptences et diffrentes tailles de l'entreprise. [2]

III.1.2. Les caractristiques du processus unifi

 UP est itratif et incrmental

Le projet est dcoup en itrations ou tapes de courte dure qui permettent de

mieux suivre lavancement globale. A la fin de chaque itration une partie excutable
du systme finale est produite, de faon incrmentale (par ajout).
La figure I.1 illustre litration dUP.

Figure I.1 : Droulement Du Processus Unifi

13
 Chapitre I : le langage UML et le processus unifi

 UP est centr sur l'architecture

Tout systme complexe doit tre dcompos en partie modulaire afin den faciliter
la maintenance et lvolution. Cette architecture (fonctionnelle, logique, matrielle, etc.)
doit tre modliser en UML, et pas seulement documente en texte.

 UP est guid par les cas d'utilisation d'UML

Le but principal dun systme dinformatique est de satisfaire les besoin de client.
Le processus de dveloppement sera donc accs sur lutilisateur. Le cas dutilisation
permettent dillustrer ces besoins. Ils dtectent puis dcrivent les besoin fonctionnel et
leur ensemble constitue le modle de cas dutilisation qui dicte les fonctionnalits
compltes du systme. [2]

 UP est pilot par les risques

Les risques majeurs du projet doivent tre identifis au plus tt mais surtout levs le
plus rapidement. Les mesures prendre dans ce cadre dterminent lordre des itrations

III.1.3. Cycle de vie du processus unifi

L'objectif d'un processus unifi est de matriser la complexit des projets
informatiques en diminuant les risques. UP est un ensemble de principes gnriques
adapt en fonctions des spcificits des projets.
 Larchitecture bidirectionnelle: UP gre le processus de dveloppement par
deux axes. (figure I.2).
 L'axe vertical : reprsente les principaux enchanements d'activits, qui
regroupent les activits selon leur nature. Cette dimension rend compte l'aspect statique
du processus qui s'exprime en termes de composants, de processus, d'activits,
d'enchanements, d'artefacts et de travailleurs.
 L'axe horizontal : reprsente le temps et montre le droulement du cycle de vie
du processus; cette dimension rend compte de l'aspect dynamique du processus qui
s'exprime en terme de cycles, de phases, d'itrations et de jalons.

14
 Chapitre I : le langage UML et le processus unifi

Figure I.2 : Larchitecture bidirectionnelle

Pour mener efficacement un tel cycle, les dveloppeurs ont besoins de toutes les
reprsentations du produit logiciel.
- un modle de cas d'utilisation.
- un modle d'analyse : dtailler les cas d'utilisation.
- un modle de conception : finissant la structure statique du systme sous
forme de sous systmes, de classes et interfaces.
- un modle d'implmentation : intgrant les composants
- un modle de dploiement : dfinissant les nuds physiques des ordinateurs
- un modle de test : dcrivant les cas de test vrifiant les cas d'utilisation
- une reprsentation de l'architecture.

III.1.4. Les activits

Expression des besoins

L'expression des besoins comme son nom l'indique, permet de dfinir les diffrents
besoins :
- inventorier les besoins principaux et fournir une liste de leurs fonctions ;
- recenser les besoins fonctionnels (du point de vue de l'utilisateur) qui conduisent
l'laboration des modles de cas d'utilisation ;
- apprhender les besoins non fonctionnels (techniques) et livrer une liste des
exigences.

15
 Chapitre I : le langage UML et le processus unifi

Le modle de cas d'utilisation prsente le systme du point de vue de l'utilisateur et

reprsente sous forme de cas d'utilisation et d'acteur, les besoins du client

Analyse

L'objectif de l'analyse est d'accder une comprhension des besoins et des

exigences du client. Il s'agit de livrer des spcifications pour permettre de choisir la
conception de la solution.
Un modle d'analyse livre une spcification complte des besoins issus des cas
d'utilisation et les structure sous une forme qui facilite la comprhension (scnarios), la
prparation (dfinition de l'architecture), la modification et la maintenance du futur
systme. Il s'crit dans le langage des dveloppeurs et peut tre considr comme une
premire bauche du modle de conception.

Conception

La conception permet d'acqurir une comprhension approfondie des contraintes

lies au langage de programmation, l'utilisation des composants et au systme
d'exploitation. Elle dtermine les principales interfaces et les transcrit l'aide d'une
notation commune.
Elle constitue un point de dpart l'implmentation :
- elle dcompose le travail d'implmentation en sous-systme
- elle cre une abstraction transparente de l'implmentation

Implmentation

L'implmentation est le rsultat de la conception pour implmenter le systme sous

formes de composants, c'est--dire, de code source, de scripts, de binaires, d'excutable
et d'autres lments du mme type.
Les objectifs principaux de l'implmentation sont de planifier les intgrations des
composants pour chaque itration, et de produire les classes et les sous-systmes sous
formes de codes sources.

Test

Les tests permettent de vrifier des rsultats de l'implmentation en testant la

construction. Pour mener bien ces tests, il faut les planifier pour chaque itration, les
implmenter en crant des cas de tests, effectuer ces tests et prendre en compte le
rsultat de chacun.
16
 Chapitre I : le langage UML et le processus unifi

III.1.5. Les phases

Analyse des besoins
L'analyse des besoins donne une vue du projet sous forme de produit fini. Cette
phase porte essentiellement sur les besoins principaux (du point de vue de l'utilisateur),
l'architecture gnrale du systme, les risques majeurs, les dlais et les cots.

Elaboration
L'laboration reprend les lments de la phase d'analyse des besoins et les prcise
pour arriver une spcification dtaille de la solution mettre en uvre.
L'laboration permet de prciser la plupart des cas dutilisation, de concevoir
larchitecture du systme et surtout de dterminer l'architecture de rfrence.

Construction
La construction est le moment o lon construit le produit. Larchitecture de
rfrence se mtamorphose en produit complet. Le produit contient tous les cas
dutilisation que les chefs de projet, en accord avec les utilisateurs ont dcid de mettre
au point pour cette version.

Transition
Le produit est en version bta. Un groupe dutilisateurs essaye le produit et dtecte
les anomalies et dfauts. Cette phase suppose des activits comme la formation des
utilisateurs clients, la mise en uvre dun service dassistance et la correction des
anomalies constates.
Tout simplement la phase de transition permet de faire passer le systme
informatique des mains des dveloppeurs celles des utilisateurs finaux. [4]

IV. Conclusion
Le langage UML nous apporte une aide toutes les tapes dun projet, comme il
nous offre ainsi de nombreux avantages pour lanalyse et la conception dun systme,
Le couple UML et le processus unifi propose une approche pour conduire la ralisation
de systmes orient objet.
Le chapitre suivant dfinit la conception de notre systme.

17