Rational Unified Process

Rational Unified Process
For
Christiane DAVOINE-GUHUR
Socit GICAB - Vannes

Christiane.Davoine@CA-GICAB.fr
Table des Matires

1
INTRODUCTION .................................................................................................. 1
LES COMPOSANTS ET LES GRANDS PRINCIPES DU PROCESSUS ............. 1

2.1
Les composants du produit RUP ..................................................................................................... 1
2.2
Le pilotage par les cas dutilisation................................................................................................. 3
2.2.1
Dfinition .................................................................................................................................. 3
2.2.2
Les flots des vnements dun cas dutilisation .......................................................................... 4
2.2.3
Les cas dutilisation dans le processus de dveloppement........................................................... 4
2.2.4
Exemple de cas dutilisation Retirer de largent . .................................................................. 5
2.3
Le processus centr sur larchitecture............................................................................................ 6
2.3.1
Importance des modles et de larchitecture ............................................................................... 6
2.3.2
Dfinition de larchitecture ....................................................................................................... 6
2.3.3
Reprsentation de larchitecture par le modle 4+1 vues.......................................................... 7
2.3.4
Architecture et conception architecturale. .................................................................................. 7
2.3.5
Exemple sur le cas dutilisation Retirer de largent . ............................................................. 8
2.4
Le
2.4.1
2.4.2
2.4.3
processus Itratif et Incrmental ............................................................................................ 10

Quest-ce quune itration ? ..................................................................................................... 10
La dimension statique du processus ......................................................................................... 11
La dimension dynamique du processus .................................................................................... 12
LES ENCHANEMENTS DACTIVITS DU PROCESSUS ................................ 13

3.1
La modlisation mtier.................................................................................................................. 14
3.1.1
Pourquoi modliser le mtier?.................................................................................................. 14
3.1.2
Comment modliser le mtier ?................................................................................................ 14
3.1.3
Les enchanements dactivits.................................................................................................. 15
3.1.4
Les outils de modlisation mtier............................................................................................. 16
3.2
La gestion des exigences ................................................................................................................ 16
3.2.1
Dfinitions............................................................................................................................... 16
3.2.2
Comment exprimer les exigences ? .......................................................................................... 16
3.2.3
Conception de linterface utilisateur......................................................................................... 17
3.2.4
Enchanements dactivits ....................................................................................................... 18
3.2.5
Les outils pour la gestion des exigences. .................................................................................. 19
3.2.6
Exemple des exigences pour le cas dutilisation Retirer de largent . ................................... 19
3.3
Lanalyse et la conception ............................................................................................................. 19
3.3.1
Objectif.................................................................................................................................... 19
3.3.2
Travailleurs et artefacts............................................................................................................ 20
3.3.3
Enchanements dactivits ....................................................................................................... 21
3.3.4
Exemple danalyse du cas dutilisation Retirer de largent ................................................. 21
3.3.5
Les outils pour lanalyse et la conception. ................................................................................ 22
3.4
Limplmentation .......................................................................................................................... 22
3.4.1
Objectifs .................................................................................................................................. 23
3.4.2
Les activits dimplmentation ................................................................................................ 23
3.4.3
Les types de prototypes ............................................................................................................ 24
3.4.4
Les outils pour limplmentation ............................................................................................. 24
3.5
Les tests ......................................................................................................................................... 24
3.5.1
Les objectifs............................................................................................................................. 25
3.5.2
Le rle des tests dans le cycle de vie du logiciel ....................................................................... 25
3.5.3
Les travailleurs et artefacts ...................................................................................................... 25
3.5.4
Exemple de tests pour le cas dutilisation retirer de largent ............................................... 26
3.5.5
Les types de tests ..................................................................................................................... 27
3.5.6
Les outils de tests..................................................................................................................... 27
_____________________________________________________________________________________________________
Christiane DAVOINE GUHUR
02/05/02
3.6
La gestion de configuration........................................................................................................... 27
3.6.1
Les objectifs............................................................................................................................. 27
3.6.2
Les dfinitions........................................................................................................................ 28
3.6.3
Les travailleurs et les artefacts ................................................................................................. 28
3.6.4
3.6.5
Les outils support de la gestion de configuration ...................................................................... 29
3.7
Le dploiement .............................................................................................................................. 29
3.7.1
Les objectifs............................................................................................................................. 29
3.7.2
Les travailleurs et les artefacts ................................................................................................. 30
3.7.3
Exemple de configuration pour le cas dutilisation Retirer de largent ................................ 30
3.7.4
4 LES ENCHANEMENTS DITRATION, RLE DES TRAVAILLEURS DANS LE

DVELOPPEMENT DUN PROJET AVEC RUP...................................................... 31
4.1
Exemple : Dfinir la vision du produit.......................................................................................... 32
4.2
Exemple : Construire un prototype architectural ........................................................................ 33
4.3
Exemple : Implmenter le systme ............................................................................................... 35
4.4
Cartographie des enchanements dactivits dun dveloppement de projet avec RUP............. 37
CONCLUSION .................................................................................................... 39
BIBLIOGRAPHIE.................................................................................................. 1
_____________________________________________________________________________________________________
02/05/02
Table des illustrations

Figure 1 : RUP, Les composants. ..................................................................................................................... 2
Figure 2 : Les cas d'utilisation, la description fonctionnelle des objets[Lopez, et al 1998]............................... 3
Figure 3 : Cas d'utilisation retirer de l'argent[Jacobson, et al 1999] ............................................................... 4
Figure 4 : Les cas dutilisation travers les diffrents modles[Kruchten 2000].............................................. 4
Figure 5 : Cas dutilisation retirer de largent ................................................................................................. 5
Figure 6 : Modle d'analyse "retirer de l'argent" ............................................................................................. 6
Figure 7 : Le modle darchitecture 4+1 vues[INT2]. ................................................................................... 7
Figure 8 : Structure statique de la vue architecturale du modle de conception pour le systme DAB.............. 9
Figure 9 : diagramme de collaboration du systme DAB[Jacobson, et al 1999]............................................... 9
Figure 10 : Le modle de dploiement du systme DAB[Jacobson, et al 1999].. .............................................. 9
Figure 11 : La vue architecturale du modle de dploiement[Jacobson, et al 1999].. .................................... 10
Figure 12 : Une approche itrative au dveloppement[INT1] ........................................................................ 10
Figure 13 : Travailleurs, activits et artefacts [Kruchten 2000]..................................................................... 11
Figure 14 : Exemple denchanement dactivits [Kruchten 2000]. ................................................................ 12
Figure 15 : Les quatre phases et jalons du processus itratif[Kruchten 2000]................................................ 12
Figure 16 : Dun cycle de vie squentiel un cycle de vie itratif [Kruchten 2000] ....................................... 13
Figure 17 : Les neufs principaux enchanements dactivits du processus [Kruchten 2000]. .......................... 14
Figure 18 : Travailleurs et artefacts dans les activits de modlisation mtier.[Kruchten 2000] .................... 15
Figure 19 : Des modles mtier aux modles systmes[Kruchten 2000] ......................................................... 15
Figure 20 : Un enchanement d'activits de modlisation mtier.[Kruchten 2000] ......................................... 16
Figure 21 : Diffrents artefacts de l'ensemble des exigences et leurs relations avec d'autres artefacts[Kruchten
2000]. ............................................................................................................................................................ 17
Figure 22 : Travailleurs et artefacts dans l'enchanement des activits de gestion[Kruchten 2000]................ 18
Figure 23 : Enchanement des activits de gestion des exigences [Kruchten 2000]. ....................................... 18
Figure 24 : comparaison des modles des cas d'utilisation et d'analyse[Jacobson, et al 1999]....................... 20
Figure 25 : Un enchanement des activits d'analyse et de conception[Kruchten 2000] ................................. 21
Figure 26 : identification de paquetages d'analyse gnraux partir des classes du domaine[Jacobson, et al
1999]. ............................................................................................................................................................ 22
Figure 27 : paquetages de services comptes et de risques encapsulant chacun des classes
fonctionnellement lies[Jacobson, et al 1999]................................................................................................ 22
Figure 28 : Enchanement d'activits d'implmentation.................................................................................. 23
Figure 29 : point de convergence de l'implmentation [Jacobson, et al 1999]................................................ 23
Figure 30 : Travailleurs et artefacts impliqus dans les tests [Jacobson, et al 1999]...................................... 25
Figure 31 : Modle de tests [Jacobson, et al 1999] ........................................................................................ 26
Figure 32 : Cas, procdures et scripts de test pour un terminal bancaire [Kruchten 2000]. ........................... 26
Figure 33 : Le cube CCM [Kruchten 2000].................................................................................................... 28
Figure 34 : Travailleurs et artefacts dans l'activit de dploiement [Jacobson, et al 1999]............................ 30
Figure 35 : Modle de dploiement du Cas DAB[Jacobson, et al 1999]......................................................... 30
Figure 36 : Enchanement d'activits de l'itration gnrique [Jacobson, et al 1999]. ................................... 32
Figure 37 : Rpartition du temps de planification par phase [Jacobson, et al 1999]. ..................................... 33
Figure 38 : les "patato des" traces la main regroupent les principales activits de la phase cration. ...... 35
Figure 39 : La "patato de" trace la main regroupe les principalement activits de la phase
cration[Jacobson, et al 1999]....................................................................................................................... 37
Figure 40 : Cartographie d'un projet dvelopp avec RUP[Jacobson, et al 1999]. ........................................ 38
Figure 41 : L'approche typique pour mettre en place un processus et les outils [Jacobson, et al 1999].......... 38
_____________________________________________________________________________________________________
02/05/02
Prambule
Le Rational Unified Process est un processus de gnie logiciel dvelopp et
commercialis par la socit Rational Software. Il permet daffecter et de grer de manire
rigoureuse et discipline les tches et les responsabilits au sein dune organisation de
dveloppement... [Kruchten 2000]
Le processus unifi a prcisment pour but de spcifier les diffrentes phases dun
projet, de llaboration du cahier des charges au dploiement de lapplication. Il est le
complment idal du standard UML qui est un langage de modlisation graphique, dont la
vocation nest pas de couvrir tous les aspects du gnie logiciel. [Jacobson, et al 1999]
On remarque dans ces deux citations que RUP1 est une dmarche de dveloppement
gnie logiciel et dans la deuxime de ces citations lutilisation de sigle UML2. De fait, la
dcouverte de RUP suppose des pr-requis de modlisation objet et dUML. On considre
dans cette bibliographie que ces deux points sont acquis, il ny aura pas de prsentation
dUML, ni de lapproche objet.
RUP est un outil de modlisation UML, ses possibilits sont trs tendues et sont dcrites
dans 3200 pages de la documentation de rfrence de Rational.
Lobjectif de cette bibliographie nest donc pas dtre exhaustif.
Les chapitres suivants fourniront au lecteur les points importants. Ils porteront sur une
prsentation de RUP qui sera dcoupe en trois parties,
1. Le processus , ses composants et ses grands principes
2. Les principaux enchanements dactivit qui composent chaque itration
du processus,
3. Les enchanements ditration, le rle des travailleurs dans le
dveloppement dun projet avec RUP.
Les rfrences cites permettront une tude approfondie de ce vaste sujet.
Afin de rendre la lecture de cette bibliographie plus agrable, le mme exemple servira de
fil rouge, tout au long de ces pages, il sagit dun client bancaire qui effectue un retrait
dargent sur un automate bancaire.
Les rfrences aux ouvrages, sites, documents consults sont indiqus par une rfrence
entre crochet par exemple [Jacobson, et al 1999].
1
2
RUP : Rational Unified Process

UML : Unified Modeling Language
______________________________________________________________________________________________________
02/05/02
INTRODUCTION
RUP est le Rational Unified Process, cest un processus commercial, un produit
dvelopp et maintenu par la socit Rational Software. Il contient des directives et des
conseils sur les techniques modernes pour le dveloppement logiciel. Ce produit est
une source de connaissances, toujours jour, accessible partir du poste de travail du
dveloppeur. Il est parfaitement intgr lensemble des outils de dveloppement
proposs par la socit.
Rational Unified Process est aussi un cadre de processus (Process framework), pour
une organisation qui ladopte. Cette dernire peut ladapter et ltendre en fonction de
ses besoins [Kruchten 2000].
Pour dvelopper des systmes logiciels modernes, lexprience a mis en vidence six
meilleures pratiques respecter. En les combinant, on sattaque aux causes profondes
des problmes de dveloppement logiciel [INT3].
Les meilleures pratiques pour le dveloppement de logiciel moderne respectent les
points suivants :
- Dvelopper le logiciel de manire itrative,
- Grer les exigences,
- Utiliser des architectures base de composants,
- Modliser graphiquement le logiciel,
- Vrifier la qualit du logiciel,
- Contrler les changements apports au logiciel.
RUP prsente ces meilleures pratiques sous une forme adapte un grand nombre de
projets et dorganisations, comme nous allons le dcouvrir dans la suite de ce
document en abordant : les composants et les principes du processus, les principaux
enchanements dactivits et le rle des travailleurs dans le dveloppement dun projet
avec le processus unifi.
LES COMPOSANTS ET LES GRANDS PRINCIPES DU PROCESSUS
2.1 LES COMPOSANTS DU PRODUIT RUP

RUP ne ressemble en rien la documentation des productions classiques de mthodes
de dveloppements qui fournissaient des tagres de classeurs.
Ce produit prsente les atouts suivants :
- Il publie les mises jour de manire rgulire,
- Il utilise la technologie du Web, le mettant porte de souris des dveloppeurs,
- Une organisation peut aisment ladapter pour ses besoins,
- Il est intgr un grand nombre doutils de dveloppement logiciel de Rational,
de sorte que les dveloppeurs peuvent accder aux recommandations du
processus partir de loutil quils utilisent.
Le produit en ligne permet daccder via intranet :
- A la version la plus rcente,
- Aux informations cls du processus, moteur de recherche, index, table des
matires dynamiques,
- Aux rfrences externes (comme UML) ou dactiver directement loutil ou une
tche.
______________________________________________________________________________________________________
Page - 1 02/05/02
Le produit RUP comprend :

- Un CD-Rom qui contient la description de tous les lments du RUP (tches,
activits, recommandations, procdures et exemples), sous forme dun site Web
que lusager installe sur sa machine, o sur un serveur de lentreprise,
- Le manuel dintroduction
RUP en ligne propose :
- Des guides dutilisation doutils qui tablissent des ponts entre les processus et
les outils de dveloppement du logiciel et donnent des conseils supplmentaires
sur leur usage. Il y a par exemple des guides pour Rational Rose qui aide la
modlisation graphique ou ClearCase qui facilite la gestion de configuration.
- Des canevas (templates) pour tous les artefacts importants du processus quel
que soit loutil utilis pour les crer et les grer.
On trouve ainsi :
- Rational Rose pour laide la modlisation,
- Rational SoDA pour automatiser la documentation du logiciel,
- RequisitePro pour grer le cahier des charges,
- Adobe FrameMaker et Microsoft Word pour crer la plupart des documents
classiques,
- ClearCase qui facilite la gestion de configuration,
- Microsoft Project pour planifier le processus,
- Microsoft FrontPage pour tendre RUP lui-mme [Rational, 2000].
Figure 1 : RUP, Les composants.
Avant toute chose, le Processus Unifi est un processus de dveloppement logiciel, cest-dire quil regroupe les activits mener pour transformer les besoins dun utilisateur en
systme logiciel. Mais cest plus quun simple processus, cest un framework de processus
gnriques pouvant tre adapt une large classe de systmes logiciels, diffrents
domaines dapplication, diffrents types dentreprises, diffrents niveaux de comptence
et diffrentes tailles dentreprises.
Le Processus Unifi utilise le langage UML pour la cration des plans dlaboration et de
construction du systme logiciel. En fait UML fait partie intgrante du Processus Unifi : lun
et lautre ont t dvelopps en parallle. Nanmoins, les traits distinctifs du Processus
unifi tiennent en trois expressions cls :
- pilot par les cas dutilisation,
- centr sur larchitecture,
- itratif et incrmental.
Voil ce qui fait toute loriginalit du Processus unifi [Jacobson, et al 1999].
______________________________________________________________________________________________________
Page - 2 02/05/02
2.2 LE PILOTAGE PAR LES CAS DUTILISATION

Les cas dutilisation constituent le concept principal de la mthode OOSE de Ivar
Jacobson, un des pres dUML. Dans le processus de standardisation des mthodes objet
ayant abouti au formalisme UML, le concept des use cases , cas dutilisation en franais,
a t repris dans le but deffectuer une bonne dlimitation du systme et damliorer la
comprhension de son fonctionnement.
Figure 2 : Les cas d'utilisation, la description fonctionnelle des objets [Lopez, et al 1998].
Les cas dutilisation reprsentent le moyen de dcrire le caractre fonctionnel des

objets. Il se positionne sur trois axes :
- La description des objets, leurs proprits et leurs attributs. Elle reprsente
la vue statique de lobjet,
- Lidentification des tats et des vnements. Elle reprsente la vue
dynamique de lobjet,
- La traduction du savoir-faire et du mtier. Elle met en vidence les
exigences, les rgles fonctionnelles lies au mtier [Lopez, et al 1998].
2.2.1 Dfinition
Les cas dutilisation sont un moyen dexprimer les exigences fonctionnelles du
systme. RUP dfinit les concepts de cas dutilisation et dacteur de la faon
suivante :
- Un cas dutilisation est une squence dactions que ralise un systme et qui
fournit un rsultat observable ayant une valeur pour un acteur particulier.
- Un acteur est quelquun ou quelque chose se situant lextrieur du systme
et qui interagit avec lui.
Il y a dans ces dfinitions plusieurs notions importantes :
- Action : il sagit dune procdure de traitement quand un acteur envoie un
signal au systme ou quun systme est activ lchance dune
temporisation.
- Une squence dactions : la squence dont parle la dfinition est un flot
spcifique dvnements.
- Un rsultat observable ayant une valeur : une squence dactions fournit un
rsultat utile un acteur du systme. On garantit ainsi que le cas dutilisation
est pertinent et exprim un niveau de granularit que comprend lutilisateur
[Kruchten 2000].
______________________________________________________________________________________________________
Page - 3 02/05/02
Figure 3 : Cas d'utilisation retirer de l'argent [Jacobson, et al 1999].
La description dun cas dutilisation rend compte de ce qui se passe dans le systme
quand le cas dutilisation se ralise. La fonctionnalit complte est dfinie par un
ensemble de cas dutilisation, chacun deux reprsentant un flot spcifique
dvnements.
2.2.2 Les flots des vnements dun cas dutilisation

Du point de vue des activits de gestion des exigences, llment le plus important de la
description dun cas dutilisation est le flot dvnements. Un flot dcrit une squence
dactions en langage naturel, dans une prose simple et prcise [Jacobson, et al 1999].
2.2.3 Les cas dutilisation dans le processus de dveloppement

RUP est une approche pilote par les cas dutilisation, cela signifie quils servent de
base au processus complet de dveloppement.
Figure 4 : Les cas dutilisation travers les diffrents modles [Kruchten 2000].
Le modle de cas dutilisation est le rsultat de lenchanement des activits de gestion

des exigences. Durant les activits danalyse et de conception, on se sert du modle de
cas dutilisation pour crer le modle de conception. On dcrit comment les cas
dutilisation se ralisent en termes dinteractions entre les objets du modle de
conception. On exploite les ralisations des cas dutilisation pour comprendre la
dynamique du systme et optimiser les performances. Pendant les tests, on recourt aux
cas dutilisation pour identifier et organiser des cas et procdures de test.
Comme les cas dutilisation dcrivent la faon dont un acteur interagit avec le systme,
ils constituent une base idale pour la rdaction des manuels utilisateurs. Ils servent
galement au chef de projet qui peut dfinir les contenus et les objectifs des itrations.
______________________________________________________________________________________________________
Page - 4 02/05/02
Pour faire voluer les cas dutilisation, on commence par dvelopper un squelette de
cas dutilisation avant dapprofondir sa description. Au cours des premires itrations de
la phase dlaboration, seuls les cas dutilisation sont dcrits en dtail.
2.2.4 Exemple de cas dutilisation Retirer de largent .

Parmi les cas dutilisation frquemment rencontrer sur les DAB3, on retiendra le cas
retirer de largent qui est le cas dutilisation le plus important pour le client de la
banque.
Client de la banque
Retirer de largent
Figure 5 : Cas dutilisation retirer de largent
La squence de cas dutilisation quon peut tablir pour un retrait dargent sur un
automate de type DAB pourrait se dcomposer de la faon suivante :
- Le client de la banque sidentifie,
- Le client de la banque choisit le compte sur lequel il veut effectuer son retrait
et spcifie le montant du retrait.
- Le systme dduit le montant de son compte et dlivre largent.
Ce cas dutilisation met en vidence des exigences de disponibilit, de prcision, de
scurit.
Un exemple de cas dutilisation Retirer de largent peut scrire comme suit en
tablissant le squelette du flot des vnements :
Le cas dutilisation se dclenche quand le client insre sa carte bancaire, le

systme lit la carte et valide linformation crite sur la piste magntique.
Le systme demande le code secret, le client le saisit, le systme le valide.
Le systme demande quelle opration le client dsire effectuer. Le client choisit

de retirer de largent.
Le systme demande le montant du retrait. Le client saisit un montant.

Le systme demande sur quel type de compte bancaire le retrait doit seffectuer
(compte courant ou compte pargne)
Le systme entre en communication avec le rseau de la banque pour vrifier le

numro de compte, le code et la disponibilit du montant demand.
Le systme demande au client sil dsire un reu. Cette tape nest effectue
que sil reste du papier pour limpression.
Le systme invite le client retirer sa carte. Le client sexcute.
Le systme fournit la somme dargent demande.
DAB : Distributeur Automatique de Billets
______________________________________________________________________________________________________
Page - 5 02/05/02
Le systme imprime le reu.
Fin du cas dutilisation.
On a dcrit un flot dvnements prcis, il en existe dautres, on peut envisager

diffrents droulements.
Figure 6 : Modle d'analyse "retirer de l'argent"
Ce modle danalyse indique de quelle faon le cas dutilisation est ralis par une
collaboration, lun et lautre relis par une dpendance de traabilit et fait
apparatre quatre classes qui prennent part la ralisation du cas dutilisation. Les
classes distributeur et interface guichet sont des classes frontires, la classe retrait est
une classe de contrle et la classe compte est une classe entit.
2.3 LE PROCESSUS CENTRE SUR LARCHITECTURE

Cette partie dfinit le concept darchitecture logicielle et explique son rle central dans RUP.
En effet le processus unifi propose des principes et des conseils sur ce qui constitue
lessence mme dune architecture et UML dispose de puissantes constructions qui
permettent de formuler larchitecture. Larchitecte reoit ainsi dans cette tche, le soutien
dUML et du Processus unifi[Jacobson, et al 1999].
2.3.1 Importance des modles et de larchitecture

Une part importante de RUP est consacre la modlisation. En effet les modles
aident simplifier la ralit et apprhender les solutions dun nouveau systme. Les
modles sont des reprsentations cohrentes, plus ou moins compltes du systme
construire qui regroups, constituent la description de larchitecture du systme.
Comme on le dit souvent Larchitecture est ce qui reste de la description dun
systme quand on simplifie au maximum et que lon peut encore comprendre ce que
fait ce systme et comment il fonctionne ! [Kruchten 2000].
2.3.2 Dfinition de larchitecture

Larchitecture est un concept complexe qui se reprsente par des vues
architecturales multiples et coordonnes. Elle est lensemble des dcisions prises
sur lorganisation du systme logiciel, les choix des lments structuraux, la
dfinition des interfaces et leurs comportements. Larchitecture logicielle sintresse
non seulement la structure et au comportement du systme, mais aussi son
contexte, ses contraintes conomiques et technologiques.
______________________________________________________________________________________________________
Page - 6 02/05/02
2.3.3 Reprsentation de larchitecture par le modle 4+1 vues

Comme le montre la figure ci-dessous, RUP propose une approche cinq vues
appele par Philippe Kruchten Modle darchitecture 4+1 vues .
Figure 7 : Le modle darchitecture 4+1 vues [INT2].
La vue logique de larchitecture sintresse aux aspects fonctionnels du systme

et ce quil doit produire pour les utilisateurs finaux. Elle dcrit les classes
majeures du systme et leur organisation en paquetages et sous-systmes.
La vue dimplmentation dcrit lorganisation des modules statiques du logiciel

dans lenvironnement de dveloppement, en terme de paquetages et de
couches. Elle prend en compte la gestion de configuration, la politique de
gestion de versions. On trouve par exemple le code source dun plan de vol et la
bibliothque de code pour une base de donnes despaces ariens.
La vue des processus dfinit les tches, les flots de contrle ou les processus
et leurs interactions.
La vue de dploiement rconcilie lingnierie du logiciel avec lingnierie

systme. Elle soccupe des problmes de dploiement, dinstallation, de
performances.
La vue des cas dutilisation contient les quelques scnarios et cas dutilisation
les plus importants. On les utilise pour guider ltude et la conception de
larchitecture pendant les phases de cration (dinception) et dlaboration et on
les exploite ensuite pour valider les diffrentes vues architecturales[Kruchten
2000]..
2.3.4 Architecture et conception architecturale.

Comment lobtient-on ?
Larchitecture est dveloppe de faon itrative au cours de la phase dlaboration
au travers de lexpression des besoins, de lanalyse, de la conception, de
limplmentation et des tests.
Comment la dcrit-on ?
La description de larchitecture est une vue des modles du systme : modles des
cas dutilisation, danalyse, de conception, dimplmentation et de dploiement. Elle
______________________________________________________________________________________________________
Page - 7 02/05/02
dcrit les parties du systme quil est important de comprendre pour les
dveloppeurs et les autres intervenants [Jacobson, et al 1999]..
La conception architecturale
Une fois quon a choisi une reprsentation de larchitecture adapte au problme
rsoudre, il faut se proccuper du processus de conception architecturale. RUP
dfinit deux artefacts importants lis larchitecture :
- la description de larchitecture logicielle pour le projet,
- le prototype architectural qui sert valider larchitecture et constitue une
rfrence pour le reste du projet.
Lintrt de larchitecture porte principalement sur trois points :
- Elle permet le contrle intellectuel sur lensemble du projet,
- Elle situe les composants principaux et les interfaces majeures les uns par
rapport aux autres,
- Elle permet de raisonner sur la rutilisation interne (identification des parties
communes) ou externes (lincorporation de composants logiciels prts lemploi).
Larchitecture fournit une base pour la gestion de projet [Kruchten 2000].
On distinguera trois catgories de composants :
- Les composants dexcution quon livre, installe et excute directement (les
DLL, ou les bibliothques lies dynamiquement) .
- Les composants de dveloppement, il sagit l de sous-systmes
dimplmentation rutilisables, de bibliothques de logiciels avec une forte
cohrence interne.
- Les composants mtier, il sagit densembles cohrents de composants
dexcution qui assurent une fonctionnalit identifie dans un mtier donn
(gestion des comptes, retirer de largent)
Il y a dautres concepts architecturaux tels que le style architectural, les mcanismes
architecturaux et les pattern [Jacobson, et al 1999].
- Le style architectural impose un certain degr duniformit dans larchitecture
au niveau des formes. On le dfinit par le choix dun framework architectural,
une infrastructure logicielle, une technique ou un outil de description architectural
(le client-serveur et les styles pilots par les vnements).
- Le mcanisme architectural est une classe, un groupe de classes ou un
pattern. Il fournit une solution commune un problme commun. Il donne un
comportement spcifique aux classes.
- Le pattern architectural reprsente un savoir-faire de conception prouv. Il
identifie des abstractions, au-del des classes, des instances et des composants
propres un systme.
2.3.5 Exemple sur le cas dutilisation Retirer de largent .

La vue architecturale du modle de conception.
On a vu dans le modle danalyse lexistence de trois sous-systmes : linterface du
DAB, la gestion des transactions et la gestion des comptes. Ces sous-systmes
tant ncessaires la ralisation du cas dutilisation retirer de largent , ils sont
donc signifiants sur le plan de larchitecture.
______________________________________________________________________________________________________
Page - 8 02/05/02
Figure 8 : Structure statique de la vue architecturale du modle de conception pour le systme DAB.
La structure statique ne suffit pas, il faut montrer la faon dont les sous-systmes
ralisent les cas dutilisation signifiants pour larchitecture laide dun diagramme de
collaboration. Les objets des classes appartenant aux sous-systmes dialoguent les
uns avec les autres pour excuter une instance de cas dutilisation. Ces objets
changent des messages comme lindique le diagramme.
Figure 9 : diagramme de collaboration du systme DAB [Jacobson, et al 1999]..
On explique ici le flot de la ralisation du cas dutilisation. Le texte est presque

identique au flot dvnement du modle danalyse, mais il est vu sous langle des
sous-systmes et non des classes.
La vue architecturale du modle de dploiement.
Le modle de dploiement dfinit larchitecture physique du systme en termes de
nuds connects. Ces nuds sont des units matrielles sur lesquelles sexcutent
les composants logiciels. Les nuds et connexions peuvent alors tre modliss
dans le modle de dploiement ds lenchanement dactivits des besoins. Dans
notre exemple, le client de la banque accde au systme par lintermdiaire dun
nud client du DAB qui accde au serveur dapplications du DAB pour effectuer les
transactions. Le serveur dapplications du DAB utilise son tour, le serveur de
donnes du DAB pour effectuer des transactions spcifiques sur des comptes.
Figure 10 : Le modle de dploiement du systme DAB [Jacobson, et al 1999]..
Une fois les nuds dfinis, il est possible de dployer les fonctionnalits. On dploie
chaque sous-systme dans son entier sur un seul nud. Le sous-systme interface
du DAB est ainsi dploy sur le nud client du DAB, le sous-systme gestion des
______________________________________________________________________________________________________
Page - 9 02/05/02
transactions sur le nud serveur dapplications du DAB, le sous-systme gestion des

comptes sur le nud serveur de donnes du DAB.
Figure 11 : La vue architecturale du modle de dploiement [Jacobson, et al 1999]..
La vue architecturale dimplmentation.

Le modle dimplmentation prsente une correspondance directe avec les modles
de conception et de dploiement. Chaque sous-systme de service du modle de
conception se traduit par un composant pour chaque type de nud sur lequel il doit
tre install.
2 .4 L E
PROCESSUS ITERATIF ET INCREMENTAL
La dmarche squentielle ou en cascade est acceptable pour des petits projets qui
comportent peu de risques et utilisent une technologie prouve. En revanche, elle
ne convient pas au projet complexe qui comporte un degr lev dinnovation ou de
risque. Partant de ce constat, on peut dcouper le cycle de vie dun grand projet en
une succession de petits projets. On adopte alors lapproche itrative. On
slectionne un sous-ensemble rduit dexigences et limit au niveau des risques, on
effectue une partie de la conception et de la ralisation, on valide nouveau et ainsi
de suite jusqu ce que le systme soit complet.
Pour tre efficace on tablit une squence de jalons mineurs et majeurs clairement
articuls fournissant aux responsables et lquipe de dveloppement les critres
ncessaires au passage dune phase lautre du cycle de vie du produit.
Figure 12 : Une approche itrative au dveloppement [INT1]
2.4.1 Quest-ce quune itration ?

Une itration est un mini-projet, cest--dire un droulement plus ou moins complet
des principaux enchanements dactivits, aboutissant une version livre en
interne. Les itrations respectent les cinq enchanements principaux besoins,
analyse, conception, implmentation, tests . Chaque itration dbute par une
activit de planification et se termine par une activit dvaluation.
______________________________________________________________________________________________________
Page - 10 02/05/02
2.4.2 La dimension statique du processus

Dans le processus itratif et incrmental, la dimension statique du processus
correspond la partie descriptive de celui-ci, la description du qui fait quoi, comment
et quand. Cest sur ces quatre lments primaires de modlisation que RUP a
choisi de prsenter ses concepts cls :
-
Le qui le travailleur. Celui-ci fait rfrence au rle que doit tenir un individu
dans le cadre de son travail et de ses responsabilits. Lindividu dsign comme
travailleur possde un ensemble de comptences.
Exemple : un concepteur est un individu qui dfinit les responsabilits, les
oprations, les attributs et les relations de dpendances dune ou plusieurs
classes et dtermine comment elles
sinsrent dans lenvironnement
dimplmentation [Kruchten 2000].
Le comment les activits et les tapes dactivit. Une activit est une unit
de travail quun individu agissant en tant que travailleur peut tre amen
effectuer. Elle doit apparatre comme un lment de planification et de
progression. En terme de modlisation objet, un travailleur est un objet actif et
les activits effectues par ce travailleur sont les oprations faites sur cet objet.
Exemples dactivits: planifier une itration, trouver des cas dutilisation et des
acteurs, excuter un test de performance.
Une activit se subdivise en tapes suivant trois catgories :
tapes de rflexion (trouver les acteurs, les cas dutilisation et leurs
interactions avec les acteurs),
- tapes dactions (constituer les paquetages, reprsenter le modle de cas
dutilisation par des diagrammes de cas dutilisation),
- tapes dinspection (valuer les rsultats) .
Le quoi les artefacts. Un artefact est un lment dinformation fabriqu,

modifi ou utilis par un processus. Il est le matriau dont se servent les
travailleurs pour raliser une activit. En conception oriente objet, les activits
sont les oprations dun objet actif et les artefacts sont les paramtres de ces
activits. Ils se prsentent sous diffrentes formes, un modle, un lment de
modle, un document, du code source, un excutable. Exemple dartefacts : le
modle de conception, le modle darchitecture.
Figure 13 : Travailleurs, activits et artefacts [Kruchten 2000].
______________________________________________________________________________________________________
Page - 11 02/05/02
Le quand les enchanements dactivits. Une suite dactivits qui produit un

rsultat observable se nomme un enchanement dactivits. Un enchanement
dactivits est reprsent dans RUP par un diagramme dactivits.
Les activits, les tapes et les principes sont des guides gnraux mis la
disposition de lutilisateur. Les guides dutilisation doutil sont les seuls documents
qui font une rfrence directe des outils. Ils expliquent comment effectuer certaines
tapes laide des outils. Des principes et conseils, des canevas, des guides
dutilisation doutils compltent la description du processus en donnant davantage
dinformations lutilisateur.
Figure 14 : Exemple denchanement dactivits [Kruchten 2000].
2.4.3 La dimension dynamique du processus

Un processus itratif subdivise le cycle de dveloppement en une succession
ditrations. Chaque itration ressemble une mini-cascade et comporte les activits
de gestions des exigences, de conception, dimplmentation et dvaluation.
Lapproche itrative permet la prise en compte des changements dans le cahier des
charges et au niveau de la stratgie dimplmentation. Elle sattaque aux risques et
les rduit ds que possible. Elle permet lorganisation de progresser, dacqurir un
savoir et de samliorer. Elle se concentre sur des objectifs rels et tangibles
[Kruchten 2000].
Dans une approche itrative, il est important de mesurer lavancement du projet, de
vrifier quon sachemine rellement vers lobjectif final, pour cela le processus
itratif est organis en quatre phases dont chacune delles est ponctue par un jalon
majeur.
Figure 15 : Les quatre phases et jalons du processus itratif [Kruchten 2000].
______________________________________________________________________________________________________
Page - 12 02/05/02
La phase inception dcrit le produit final, et permet de raliser une tude de

rentabilit et de dfinir les ambitions du projet. Cette phase se conclut par le
jalon Objectif de cycle de vie. Dans cette phase on met laccent sur lvaluation
de lenveloppe globale du dveloppement.
La phase dlaboration qui permet de planifier les activits et les ressources

ncessaires la ralisation du projet, de spcifier les fonctionnalits et de
concevoir larchitecture. Elle dtermine le jalon de larchitecture du cycle de vie.
Ici on porte les efforts sur le cahier des charges et sur llaboration dune
maquette excutable.
La phase construction qui construit le systme, en fait voluer la vision et

larchitecture jusqu lobtention dun produit prt livrer. Son aboutissement est
le jalon de capacit oprationnelle initial. Lattention se porte sur la conception
dtaille et limplmentation.
La phase transition dont lobjectif est de transmettre le produit aux utilisateurs,

dassurer le soutien et la maintenance jusqu ce que lutilisateur soit satisfait. La
phase de transition se conclut par le jalon livraison de produit. On sassure ici
que le systme a un niveau de qualit suffisant pour rpondre au cahier des
charges.
Par rapport une approche traditionnelle, la dmarche itrative attnue les risques,
sadapte mieux aux changements et permet aux quipes dacqurir des
connaissances pendant le droulement du projet. Elle offre galement un grand
niveau de rutilisation et une meilleure qualit globale.
Figure 16 : Dun cycle de vie squentiel un cycle de vie itratif [Kruchten 2000].
LES ENCHAINEMENTS DACTIVITES DU PROCESSUS
Maintenant que nous avons abord les notions lmentaires qui sous-tendent les pratiques
essentielles du Processus unifi, nous allons dcrire en dtail chacun des enchanements
dactivits.
Dans RUP, il existe neuf principaux enchanements dactivits :
- De modlisation mtier
- De gestion des exigences
- Danalyse et de conception
- Dimplmentation
- De test
- De dploiement
______________________________________________________________________________________________________
Page - 13 02/05/02
De gestion de projet
De gestion de configuration et des changements
Lis lenvironnement.
Figure 17 : Les neufs principaux enchanements dactivits du processus [Kruchten 2000].
On peut ajouter des lments additionnels du processus pour faciliter la comprhension et

lutilisation qui sont les principes et conseils, les canevas, les guides dutilisation doutils et
les concepts.
Chaque enchanement dactivit fait appel au mme formalisme dans sa reprsentation
graphique. Chacun deux est reprsent par :
- un diagramme travailleurs et artefacts qui prcise pour un travailleur la
responsabilit qui lui incombe dans la production des artefacts.
- Un diagramme denchanement dactivits qui prcise la chronologie des
activits et le lien de dpendance entre les activits et dautres travailleurs.
On reprendra chacun de ces enchanements en dtail dans les paragraphes suivants. Cest
le diagramme denchanement des activits qui permet de passer de la conception vers le
modle systme.
3.1 LA MODELISATION METIER

3.1.1 Pourquoi modliser le mtier?
La modlisation mtier est une technique qui permet de comprendre les processus
mtier dune entreprise. On modlise un mtier pour comprendre sa structure et sa
dynamique, pour sassurer que tous les intervenants ont une vision commune
lorganisation et pour dduire les cahiers des charges des futurs systmes
informatiques de cette organisation. On modlise un mtier lorsque le nombre
dutilisateurs et la quantit dinformations sont importants.
3.1.2 Comment modliser le mtier ?

La modlisation du mtier est prise en charge par deux types de modles UML : le
modle des cas dutilisation et le modle objet :
- Le modle des cas dutilisation est dcrit par les diagrammes des cas
dutilisation.
- Le modle objet mtier est un modle interne du mtier. Il dcrit la faon dont
chaque cas dutilisation du mtier est ralis par un groupe de travailleurs
utilisant un ensemble dentits mtier et dunits de travail. Chaque
ralisation de cas dutilisation mtier peut tre montre sous forme de
diagrammes dinteractions et de diagrammes dactivits [Jacobson, et al 1999].
______________________________________________________________________________________________________
Page - 14 02/05/02
Figure 18 : Travailleurs et artefacts dans les activits de modlisation mtier [Kruchten 2000].
De plus, il existe deux autres artefacts :

- Les spcifications mtier complmentaires : les dfinitions, les rgles, les
procdures et les normes.
- Un glossaire qui dfinit les termes importants utiliss dans le mtier.
Un avantage de cette approche de la modlisation du mtier est quelle montre bien
les dpendances entre les modles mtier et les modles du systme informatique
utiliss dans ce mtier. Les travailleurs mtier deviennent les acteurs du systme
informatique. Les actions et comportements des travailleurs mtiers dterminent les
cas dutilisation du systme, pour les parties quon souhaite automatiser. A partir des
entits mtier on peut dduire les classes dentits du modle [Kruchten 2000].
Figure 19 : Des modles mtier aux modles systmes [Kruchten 2000].
3.1.3 Les enchanements dactivits

La figure ci-dessous montre un enchanement typique de modlisation mtier. Dans
un premier temps, il sagit didentifier les processus mtier cls et les acteurs mtier
concerns, de les dcrire sous forme dun modle de cas dutilisation.
Ensuite, il convient de dtailler les descriptions des cas dutilisation mtier mis en
vidence, didentifier les rles, de dfinir les responsabilits, les oprations, les
attributs et les relations entre les travailleurs et les entits mtier. Ces activits
relvent de la comptence du concepteur mtier.
Une fois ces modles labors, lauditeur du modle se charge de vrifier quils
reprsentent correctement lorganisation.
______________________________________________________________________________________________________
Page - 15 02/05/02
Figure 20 : Un enchanement d'activits de modlisation mtier [Kruchten 2000].
3.1.4 Les outils de modlisation mtier

Rational Rose fournit tout ce dont on a besoin pour produire les modles mtiers
graphiques.
Pour saisir les informations textuelles, on peut utiliser loutil Rational Requesite Pro,
comme dans le cadre dun dveloppement logiciel. Avec cet outil, il est possible de
grer les dpendances entre les lments issus de diffrents modles.
Pour crer et maintenir automatiquement la documentation des modles, on
dispose de loutil Rational SoDA.
3.2 LA GESTION DES EXIGENCES

3.2.1 Dfinitions
Une exigence est une condition laquelle doit satisfaire un systme ou une capacit
dont il doit faire preuve [Kruchten 2000].
Dans un systme on rencontre les exigences fonctionnelles qui expriment le
comportement dun systme en spcifiant les conditions dentre et les conditions de
sortie qui doivent en rsulter. Les exigences non fonctionnelles sont un ensemble
dexigences auquel un logiciel doit rpondre en plus des exigences fonctionnelles.
On distingue quatre catgories calques sur la typologie des attributs de qualit :
- Les exigences dutilisation bases sur des critres ergonomiques, de
cohrence au niveau de linterface utilisateur et de la documentation.
- Les exigences de fiabilit qui sont bases sur la prcision du rsultat.
- Les exigences de performance qui sappuient sur les indicateurs de temps de
rponse, de charge et de mmoire requise.
- Les exigences de maintenance qui valuent la complexit du logiciel dans le
processus de dveloppement.
3.2.2 Comment exprimer les exigences ?

Le cahier des charges qui regroupe les demandes des intervenants doit tre compris
par lquipe de dveloppement. Pour communiquer avec exactitude aux
dveloppeurs ce quils doivent raliser, il faut tablir un cahier des charges qui
contient les exigences dtailles fonctionnelles et non fonctionnelles du systme. La
modlisation par les cas dutilisation est un moyen efficace de les exprimer. Les
diffrents types dusagers du systme sont reprsents par des acteurs et les
______________________________________________________________________________________________________
Page - 16 02/05/02
fonctionnalits sont converties en suites dinteraction entre ces acteurs et le systme

[Kruchten 2000].
Pour exprimer les exigences, on collecte les demandes des intervenants, des
utilisateurs finaux, des clients, des gens du marketing et on les saisit dans le
document de demandes des intervenants (Cf la figure ci-dessous) . On utilise cet
ensemble de demandes pour dcrire le document de vision qui contient les
fonctionnalits numres, une tude de rentabilit, le cot de la ralisation et le
bnfice escompt. On traduit ces fonctionnalits dans un cahier des charges
dtaill suffisant pour concevoir et construire le systme et identifier les cas de tests.
Ce cahier des charges est constitu de deux artefacts : le modle des cas
dutilisation et les spcifications complmentaires.
A partir du cahier des charges dtaill on constitue ensuite le modle de conception,
la documentation pour lutilisateur final et le modle de test pour vrifier que les
exigences sont satisfaites.
Figure 21 : Diffrents artefacts de l'ensemble des exigences et leurs relations avec d'autres artefacts
[Kruchten 2000].
3.2.3 Conception de linterface utilisateur

La conception de linterface utilisateur comprend deux tapes, la mise en forme
graphique et la conception en terme de classes de conception.
Dans une premire tape, partir du modle des cas dutilisation et des
spcifications supplmentaires, on bauche lenchanement des activits de gestion
des exigences qui dbouche sur llaboration dun prototype de linterface utilisateur
laide dun outil de prototypage.
Dans la deuxime tape, on construit un prototype de linterface utilisateur partir
des dfinitions dtailles tablies pendant la ralisation des parties des cas
dutilisation qui ncessitent une interface avec les utilisateurs.
______________________________________________________________________________________________________
Page - 17 02/05/02
Figure 22 : Travailleurs et artefacts dans l'enchanement des activits de gestion [Kruchten 2000].
Les principaux travailleurs impliqus sont :

-
Lanalyste systme qui sattache dlimiter le primtre du systme et les

fonctions quil doit remplir.
Le spcificateur de cas dutilisation qui dtaille les exigences fonctionnelles
du systme.
Larchitecte qui identifie les cas dutilisation et les exigences architecturales.
Le concepteur dinterface utilisateur qui dirige et coordonne la conception et
le prototypage.
Lauditeur du cahier des charges qui passe en revue les artefacts gnrs.
3.2.4 Enchanements dactivits
Figure 23 : Enchanement des activits de gestion des exigences [Kruchten 2000].
Dans un premier temps les analystes systme travaillent avec les intervenants, ils
doivent identifier ce quil faut produire et identifier les exigences non fonctionnelles.
Ils peuvent alors dvelopper la vision du projet qui comprend la liste des
fonctionnalits dcrites par les intervenants.
A partir du document de vision labor par les analystes systme, les spcificateurs
de cas dutilisation dtaillent les cas dutilisation et les spcifications
supplmentaires.
______________________________________________________________________________________________________
Page - 18 02/05/02
Les concepteurs dinterfaces utilisateur progressent en parallle des spcificateurs

de cas dutilisation pour concevoir linterface utilisateur.
Dans les premires itrations, larchitecte travaille avec les analystes systme et les
spcificateurs des cas dutilisation pour extraire un ensemble de scnarios qui va
servir la dfinition de larchitecture.
3.2.5 Les outils pour la gestion des exigences.

Loutil de support qui va permettre de saisir les exigences, de les organiser la fois
dans des documents textuels, dans des bases de donnes, de les grer et de traiter
les demandes de modifications est Rational Requisite Pro de la socit Rational.
Pour la modlisation graphique des artefacts (modle des cas dutilisation, classes
frontires) on peut utiliser Rational Rose.
Rational SoDA aide automatiser la cration dun cahier des charges. Il permet de
dfinir un canevas intelligent pour extraire et assembler des informations de
diffrentes sources, SoDA va regrouper toute linformation ayant trait un artefact
pour produire un document unique.
3.2.6 Exemple des exigences pour le cas dutilisation Retirer de

largent .
Pour analyser les exigences dans le cas Retirer de largent , on peut souhaiter
que le temps de rponse un client de la banque soit infrieur 5 secondes, entre la
slection du montant retirer et la dlivrance des billets.
On peut aussi imaginer que pour un client de la banque, lorsque lautomate est en
mode autonome4, on dlivre au client une somme incluse dans le plafond
hebdomadaire inscrit sur sa carte, alors quen mode connect ce plafond peut tre
dpass en fonction du solde de son compte ou des conditions spciales dont il
peut bnficier.
3.3 LANALYSE ET LA CONCEPTION

3.3.1 Objectif
Lobjectif de lenchanement des activits danalyse et de conception est de traduire
lensemble des exigences en une spcification qui dcrit comment raliser le
systme. Cette traduction suppose de bien comprendre le cahier des charges du
systme et de choisir la meilleure stratgie dimplmentation. Il faut mettre en place
une architecture robuste qui permet de concevoir un systme facile construire et
faire valuer.
Le langage employ dans lanalyse repose sur un modle objet conceptuel, appel
modle danalyse. En fait, dans le modle danalyse, une ressource interne peut tre
reprsente sous forme dobjet, tel le compte dun client auquel accde les cas
dutilisation dpt et retrait [Jacobson, et al 1999].
Pendant cet enchanement, on exploite les cas dutilisation pour identifier un
ensemble dobjets partir desquels on construit des classes, les sous-systmes et
Mode autonome : Mode dconnect des bases de productions,
______________________________________________________________________________________________________
Page - 19 02/05/02
les paquetages. Le but de lanalyse est de traduire les exigences du systme en

ensemble de classes et de sous-systmes.
Lobjet de la conception est dadapter le rsultat de lanalyse aux contraintes
imposes par les exigences non fonctionnelles. La conception doit dfinir le systme
de faon ce quil puisse tre implment sans ambigu t. Ces deux grandes
activits analyse et conception sont regroupes dans cette prsentation, car la
deuxime reprend les artefacts de lactivit danalyse en dtaillant plus finement les
cas dutilisation afin datteindre un niveau suffisant pour assurer son implmentation.
Le rle de la conception dans le cycle de vie du logiciel est sa contribution la mise
en place dune architecture saine et stable. Entre autre, il permet de crer un plan
dlaboration et de construction pour le modle dimplmentation. Le modle de
conception est proche de limplmentation, il est naturel de le conserver et de
lactualiser tout au long du cycle de vie du logiciel.
Figure 24 : comparaison des modles des cas d'utilisation et d'analyse [Jacobson, et al 1999].
3.3.2 Travailleurs et artefacts

La responsabilit de lanalyste est partage entre :
- larchitecte qui gre les problmes densemble,
- le concepteur qui prend en charge les dtails,
- le concepteur de base de donnes qui soccupe des dtails dans le
traitement de la persistance,
- lauditeur du modle architectural et du modle de conception qui passe
en revue les artefacts cls fabriqus pendant lenchanement dactivits.
Au cours de lanalyse et de la conception, on labore un modle de conception de
plusieurs vues architecturales, qui sont des abstractions. La vue logique prsente la
dcomposition du systme en un ensemble dlments logiques (classes, soussystmes, paquetages, et collaborations) . La vue des processus tablit une
correspondance entre ces lments et les processus ou les Threads dans le
systme.
______________________________________________________________________________________________________
Page - 20 02/05/02
3.3.3 Enchanements dactivits

La figure ci-dessous illustre un enchanement typique danalyse et de conception qui
est centr dune part sur larchitecture et dautre part sur la conception dtaille de
classes et de sous-systmes.
Examinons les activits ayant trait larchitecture.
-
Larchitecte identifie les patterns architecturaux. Les mcanismes cls

dfinissent les couches, les principes dorganisation des sous-systmes et la
stratgie de rutilisation.
Lanalyste des cas dutilisation produit des classes. Il identifie les classes
significatives, les regroupe dans des paquetages et des sous-systmes de
conception que lon organise en couches.
Le concepteur utilise larchitecture et les rsultats de lanalyse des cas

dutilisation pour identifier les caractristiques des classes, leurs relations et
affiner leurs spcifications. On poursuit la conception des cas dutilisation en
spcifiant chaque ralisation en terme doprations sur les classes et soussystmes, dans les diagrammes de squence ou diagrammes de
collaboration.
Figure 25 : Un enchanement des activits d'analyse et de conception [Kruchten 2000]
3.3.4 Exemple danalyse du cas dutilisation Retirer de largent

On reprend lexemple des clients de la banque dans lidentification des paquetages
danalyse gnraux partir du modle du domaine. Chacune des classes reprsente
des entits importantes et complexes. Les paquetages gestion des comptes et
gestion des clients de la banque contiendront probablement de nombreuses classes
danalyse, notamment des classes de contrle et des classes frontires lies
respectivement la gestion des comptes et des clients de la banque [Jacobson, et al
1999].
______________________________________________________________________________________________________
Page - 21 02/05/02
Figure 26 : identification de paquetages d'analyse gnraux partir des classes du domaine [Jacobson, et
al 1999].
Le paquetage gestion des comptes comprend un paquetage de service gnral

appel comptes, qui permet daccder aux comptes pour des activits telles que le
transfert dargent et lextraction dhistorique des transactions. Ce paquetage contient
galement un paquetage de service appel risques, consacr lestimation des
risques associs un compte particulier.
Figure 27 : paquetages de services comptes et de risques encapsulant chacun des classes

fonctionnellement lies [Jacobson, et al 1999].
3.3.5 Les outils pour lanalyse et la conception.

UML est le langage qui convient le mieux pour reprsenter les modles de cet
enchanement. Les principes et conseils de modlisation associs aux diffrents
artefacts du RUP sont tous exprims selon le formalisme dUML.
Rational Rose est le meilleur outil pour saisir, grer et prsenter les modles. Rose
permet de faire du round-trip engineering avec certains langages de programmation.
On peut garder synchroniss le modle de conception et le code et faire voluer le
systme partir de lun ou de lautre.
Avec ObjectTime Developper et Rose for Real-Time, il est possible de construire
un modle de conception excutable.
Avec SoDA on cre automatiquement des documents et des rapports en extrayant
et mettant en forme des informations provenant de plusieurs sources, telles que
Rose et Requisite Pro.
3.4 LIMPLEMENTATION
Limplmentation part des rsultats de la conception pour implmenter le systme sous
forme de composants, cest--dire de code source, de scripts, de binaires, et dexcutables.
______________________________________________________________________________________________________
Page - 22 02/05/02
3.4.1 Objectifs
Le principal objectif de limplmentation est donc dtoffer larchitecture et le systme
dans son ensemble. Pour tre plus prcis, on voit que lenchanement des activits
dimplmentation a de multiples objectifs :
- Dfinir lorganisation du code en termes de sous-systmes dimplmentation
en couches,
- Transformer les classes et les objets en composants (fichiers source,
binaires, excutables),
- Procder aux tests unitaires des programmes,
- Intgrer en un systme excutable les units produites par les
implmenteurs.
Figure 28 : Enchanement d'activits d'implmentation
Le rle de limplmentation dans le cycle de vie du logiciel est important dans deux
phases principalement. Dans la phase de llaboration, il est pour la cration de
larchitecture excutable de rfrence. Dans la phase de construction, son rle est
majeur dans le dveloppement des composants excutables du logiciel. Les
activits dimplmentation trouvent un rle dans la phase de la transition pour la
correction des anomalies.
Figure 29 : point de convergence de l'implmentation [Jacobson, et al 1999].
3.4.2 Les activits dimplmentation

Cet enchanement comprend le test unitaire des composants individuels, chaque
implmenteur est responsable du test des units de code quil produit.
Pour expliquer les activits dimplmentation dfinies dans RUP, on prsente les
trois concepts cls suivants, les constructions, lintgration, les prototypes.
______________________________________________________________________________________________________
Page - 23 02/05/02
Le concept de construction est une version excutable dun systme ou dune partie
dun systme qui ralise un sous-ensemble des fonctionnalits du produit final. Tous
les lments dune construction sont soumis au contrle de configuration.
Le concept dintgration est une activit de dveloppement logiciel au cours de
laquelle on combine des composants logiciels distincts en un tout. Il existe deux
niveaux dintgration, on procde lassemblage des lments constituant le sous
systme avant de le livrer aux intgrateurs du systme ou on les assemble pour
former le systme complet. RUP recommande une approche incrmentale de
lintgration. La dmarche consiste crire des parties de code, les tester et les
combiner graduellement dans un ensemble excutable, en ajoutant une partie la
fois.
Le concept de prototype permet de faire face aux risques et de lever lincertitude
sur : la viabilit commerciale du produit, son utilisation, son financement et la
comprhension des exigences.
3.4.3 Les types de prototypes

Les prototypes peuvent tre dfinis selon leur finalit.
- Les prototypes exploratoires quon jette une fois quils ont rempli leur
mission.
- Les prototypes volutifs qui voluent dune itration lautre pour devenir le
systme final.
- Les prototypes comportementaux qui examinent
un comportement
spcifique du systme vu de lextrieur par lutilisateur. Ici on ne se soucie
pas de la qualit ni des normes du projet.
Les prototypes structurels qui explorent les aspects architecturaux et
technologiques du systme, vu de lintrieur. Ce sont des prototypes en
gnral volutifs qui utilisent et testent linfrastructure du systme final, son
ossature.
3.4.4 Les outils pour limplmentation

Cest dans le domaine de limplmentation que lon trouve tous les outils de
dveloppement logiciel classiques tels que les diteurs, les compilateurs, les
diteurs de liens et les dbogueurs. Aujourdhui, ces outils de gestion se trouvent
dans des environnements de dveloppement intgrs o ils partagent une mme
base de donnes (exemple : lenvironnement de dveloppement Rational APEX
pour ADA et C++) .
Rational Rose permet de faire du round-trip engineering, en liant troitement les
activits de conception et dimplmentation. Des outils danalyse syntaxique comme
Purify et Quantify facilitent la dtection danomalies dans le code. Le gestionnaire
de configuration ClearCase offre des espaces de travail individuels, des espaces
dintgration des sous-systmes et du systme. ClearQuest est loutil idal pour le
suivi des demandes de changement et des anomalies, jusquau code source.
3.5 LES TESTS

Lenchanement dactivits de tests sattache la vrification des rsultats de
limplmentation en testant chaque construction, aussi bien les constructions internes et
intermdiaires que les versions finales du systme, livrables lextrieur. Cet enchanement
dactivit concourt la qualit du produit et de tous les lments qui ont servi le fabriquer.
______________________________________________________________________________________________________
Page - 24 02/05/02
3.5.1 Les objectifs

Lenchanement des tests a pour but principal dvaluer la qualit dun produit. Pour
cela il faut vrifier la bonne intgration des composants, les fonctionnalits et les
performances du produit. Les divers objectifs que poursuit la phase de tests sont de
planifier les tests ncessaires pour chaque itration, concevoir et implmenter les
tests en crant les cas de tests et en spcifiant ce qui doit tre test. Ils sont
galement deffectuer les divers tests et prendre systmatiquement les rsultats de
chacun deux.
3.5.2 Le rle des tests dans le cycle de vie du logiciel

Le rle des tests dans le cycle de vie du logiciel se situe dans les quatre phases du
dveloppement. Dans la phase de conception, on planifie les tests pour dlimiter la
porte du systme, mais ils interviennent avant tout au moment o chaque
construction doit subir des tests dintgration et des tests systme. Cela signifie que
les tests mobilisent lattention pendant la phase dlaboration lors du test de
larchitecture de rfrence excutable et pendant la phase de construction, lors de
limplmentation de la masse du systme. Pendant la phase de transition, lattention
se porte principalement sur la correction des anomalies dtectes au cours des
premires utilisations et sur les tests de non-rgression.
3.5.3 Les travailleurs et artefacts

Les principaux travailleurs impliqus dans cette phase de test sont :
- Le concepteur de test qui est responsable de la planification des tests, de
leur conception, de limplmentation des procdures et de lvaluation de la
couverture, des rsultats et de lefficacit des tests,
- Le testeur systme qui est responsable de la prparation, de lexcution, de
lvaluation des rsultats,
- Le testeur de performance qui est responsable de lexcution des tests de
performance.
Figure 30 : Travailleurs et artefacts impliqus dans les tests [Jacobson, et al 1999].
Ce plan denchanement produit quatre artefacts principaux :

-
Le plan de test dcrit les stratgies de tests, ainsi que leur calendrier et les
ressources mises leur disposition.
Le modle de test dcrit les conditions dans lesquelles les composants
excutables du modle dimplmentation subissent des tests dintgration et
des tests systme. Ce modle se compose dun ensemble de cas de test, de
procdures et de composants de test.
- Un cas de test correspond lensemble des donnes de test, les
conditions dexcution et les rsultats attendus,
______________________________________________________________________________________________________
Page - 25 02/05/02
Une procdure de tests spcifie les conditions dexcution dun ou de

plusieurs cas de test.
Un composant de test automatise tout ou partie dune ou de plusieurs
procdures de test. Il peut tre reprsent par un script, soient des
instructions qui automatisent lexcution des procdures de tests.
Figure 31 : Modle de tests [Jacobson, et al 1999]
Le modle de charge de travail pour les tests de performance identifie les

variables de la charge et dfinit les valeurs utiliser, en fonction des
caractristiques des acteurs, des cas dutilisation.
- Les anomalies identifies la suite des tests.
3.5.4 Exemple de tests pour le cas dutilisation retirer de largent

Dans lexemple sur le retrait dargent au DAB (cf. la figure ci-dessous), on va
prendre deux cas de test , retirer un montant prdfini et retirer un montant dfini
par le client.
Figure 32 : Cas, procdures et scripts de test pour un terminal bancaire [Kruchten 2000].
Dans les deux cas, on droule les procdures spcifiques suivantes :

-
le dmarrage de la session,
______________________________________________________________________________________________________
Page - 26 02/05/02
la procdure effectuer le retrait,

le choix de loption montant prdfini ou slection du montant ,
la procdure clturer la session.
Ces procdures peuvent tre droules sur un automate de tests ou sur un poste de
travail qui simule le mcanisme par lintermdiaire de scripts de test individuels pour
assurer le mme droulement que sur un DAB.
Si tout est correct, on enchane sur les scripts de test pour effectuer lopration
retirer le montant , on vrifie que tous les rsultats sont corrects.
3.5.5 Les types de tests

Les types de test sont nombreux :
- Le test de benchmark compare les performances du sujet test une
rfrence standard,
- Le test de configuration vrifie que le sujet test fonctionne correctement,
- Le test dinstallation vrifie que le sujet test peut tre install avec succs sur
les diffrentes configurations matrielles et logicielles prvues,
- Le test dintgrit mesure la robustesse,
- Le test de charge vrifie que les performances comportementales du sujet test
restent acceptables lorsquon modifie les configurations, en maintenant stables
les conditions oprationnelles.
3.5.6 Les outils de tests

Les tests constituent un effort itratif tal tout au long du cycle de dveloppement.
Pour quils aient une efficacit maximale, il faut les automatiser en utilisant les outils
adquats. Voyons comment les outils de dveloppement logiciel de Rational
permettent lautomatisation des tests.
TestStudio est une suite doutils qui prend en charge limplmentation et lvaluation
des tests. Ils permettent aux testeurs de crer et dexcuter des scripts de tests base
dinterface utilisateur graphique senss valuer les fonctionnalits et les
performances de lapplication. TestStudio comprend les outils suivants :
- Robot soccupe de limplmentation et de lexcution des tests. Avec cet outil
les testeurs crent et excutent des scripts de tests base dinterface
utilisateur,
- LogViewer rcupre les rsultats des tests et gnre un rapport qui permet
dvaluer leur excution,
- TestManager est utilis pour la planification, la conception et lvaluation des
tests. Il founit des comptes rendus de ltat davancement des tests et du taux
de couverture du cahier des charges,
- TestFactory vrifie la fiabilit de lapplication. Il gnre et excute
automatiquement des scripts de test. Il gnre un compte rendu de couverture
du code.
PerformanceStudio implmente et excute des scripts de test dun utilisateur virtuel
dans le cadre de test de performance et de certains tests fonctionnels limits.
3.6 LA GESTION DE CONFIGURATION

3.6.1 Les objectifs
______________________________________________________________________________________________________
Page - 27 02/05/02
Lobjectif de la gestion de configuration et des changements est de garder une trace

de tous les lments qui participent au dveloppement. Le but est de suivre leur
volution puisquils sont susceptibles de faire lobjet de demandes de modification.
Tout au long du cycle de vie dun produit, lquipe de dveloppement cre, modifie
maintes fois de nombreux artefacts. Ceci reprsente un investissement trs lourd, les
artefacts constituent de ce fait un capital quil faut rendre accessible la rutilisation.
3.6.2
Les dfinitions
La gestion de configuration et des changements recouvre trois fonctions
interdpendantes : la gestion de configuration, la gestion des demandes de
changements, le suivi de ltat davancement et les mesures. On utilise le cube CCM5
(Configuration and Change Management) pour reprsenter cette triple orientation.
Figure 33 : Le cube CCM [Kruchten 2000].
La gestion de configuration consiste identifier les artefacts et leur attribuer un

numro de version. Elle gre les dpendances entre les artefacts, les constructions
et la hirarchie de dpendance des composants. Elle fournit aux dveloppeurs des
espaces indpendants afin dviter les conflits dans la phase dintgration
La gestion des demandes de changements se focalise sur la structure du

processus. Il sagit dorganiser et de traiter les modifications du systme sollicites
par les intervenants internes et externes, danalyser les consquences de ces
interventions sur le produit et de suivre les demandes de changements jusqu leur
accomplissement. Les raisons des demandes de changements peuvent porter sur la
correction dune anomalie, lamlioration de la qualit du produit ou de ces
performances, lajout dune exigence ou dune volution du produit dune itration
lautre.
Le suivi de ltat davancement et les mesures porte sur le contrle du projet. Il

sagit de fournir des informations aux responsables de projet, en utilisant des outils
de gestion de configuration. A partir de cette base de donnes, on peut fournir des
mesures sur ltat davancement du projet, des mesures de distribution des
changements et des mesures de tendance.
3.6.3 Les travailleurs et les artefacts

3.6.3.1 Les travailleurs
Les principaux travailleurs qui interviennent dans cette gestion de configuration sont :
- Le chef de projet qui est responsable du plan de gestion de la configuration,
CCM : Configuration and Change Management
______________________________________________________________________________________________________
Page - 28 02/05/02
Le responsable de la configuration qui est charg dtablir la structure du

produit dans le systme de gestion de configuration, de la dfinition et de
lallocation des espaces de travail privs.
Les implmenteurs qui sont chargs des volutions du produit dans un espace
de travail qui leur est attribu,
Les intgrateurs qui acceptent les lments modifis dans un espace de
travail dintgration, ceux-ci assemblent galement le produit.
Larchitecte qui fournit des informations pour la cration de la structure du
produit en tablissant la vue dimplmentation.
3.6.3.2 Les artefacts

Les artefacts cls de la gestion de configuration sont les suivants :
- Le plan de gestion de la configuration dcrit les versions, les variantes, les
espaces de travail et les procdures utiliser.
- Les demandes de changements sont mises par un initiateur et pour une
cause lorigine de la demande. On enregistre ces informations ainsi que les
rsultats de lanalyse dimpact, le cot, les dlais des oprations.
- Le modle dimplmentation utilis par le responsable de la configuration pour
mettre en place lenvironnement.
- Les mesures sur ltat davancement, que lon inclut dans les rapports
dvaluation de ltat davancement.

Les enchanements dactivits de gestion de configuration peuvent tre vus de la
faon suivante :
- Le chef de projet tablit les procdures de gestion de configuration utiliser
dans le projet, dfinit les exigences pour les rapports sur ltat davancement
et les rfrences de base.
- Le responsable de configuration dfinit la structure du produit, cre et alloue
les espaces de travail ncessaires aux dveloppeurs et aux intgrateurs.
- Les travailleurs modifient les artefacts dans leurs espaces de travail privs,
- Les intgrateurs acceptent les lments modifis dans les espaces
dintgration et assemblent les produits partiels tester.
- Une nouvelle version de rfrence est tablie la fin dune itration.
3.6.5 Les outils support de la gestion de configuration

La gestion de tous les changements est complexe. Cest une tche fastidieuse et
ingrate qui demande beaucoup deffort et de rigueur. On a tout intrt lautomatiser
en utilisant des outils disponibles cet effet.
Dans la panoplie des outils de dveloppement de Rational figurent :
- ClearCase qui soccupe de la gestion de configuration,
- ClearQuest qui se charge de grer les demandes de changements et fournit
des mesures sur ltat davancement du produit.
3.7 LE DEPLOIEMENT
3.7.1 Les objectifs
Le but de lenchanement des activits de dploiement est de livrer le produit aux
utilisateurs finaux. Le dploiement dpend essentiellement du domaine et du contexte
commercial dans lequel sinscrit le logiciel.
______________________________________________________________________________________________________
Page - 29 02/05/02
3.7.2 Les travailleurs et les artefacts

Lenchanement des activits de dploiement soccupe de tous les artefacts qui sont
livrs aux utilisateurs finaux, aux clients et aux organisations de soutien (marketing,
distribution et vente) .
Figure 34 : Travailleurs et artefacts dans l'activit de dploiement [Jacobson, et al 1999].
3.7.2.1 Les travailleurs

Dans cette phase de dploiement, les travailleurs suivants sont susceptibles
dintervenir :
- Le responsable de dploiement qui planifie et organise le dploiement,
- Limplmenteur qui produit la partie logicielle de la livraison,
- Le rdacteur technique qui rdige le manuel utilisateur, les notes
dinstallation
- Le dveloppeur et lutilisateur qui rdigent les supports de formation.
3.7.2.2 Les artefacts

Parmi les artefacts figurent ventuellement :
- Le plan de dploiement,
- Le manuel utilisateur,
- Les supports de formation.
3.7.3 Exemple de configuration pour le cas dutilisation Retirer de

largent
Lexemple ci-dessous montre le dcoupage du dploiement quil faudra effectuer sur
larchitecture matrielle identifie.
Figure 35 : Modle de dploiement du Cas DAB [Jacobson, et al 1999].
______________________________________________________________________________________________________
Page - 30 02/05/02

Il convient de respecter la ralisation des activits numres ci-dessous en fonction
du contexte de lapplication.
Examinons quelques activits typiques qui ont lieu pendant le dploiement :
- Produire le logiciel : on associe des scripts dinstallation aux excutables , on
tablit une documentation utilisateur et on fournit les paramtres de
configuration ainsi que les programmes pour convertir des donnes existantes
dans le nouveau format.
Conditionner le logiciel : les divers artefacts sont conditionns sur des

supports varis, disquettes, CD-Rom, bandes magntiques, fichiers sur un
serveur, cassettes vido. On doit les tiqueter correctement.
Distribuer le logiciel : plusieurs solutions sont envisages, depuis

lempaquetage dans des botes jusqu lutilisation dun rseau de distributeurs
en passant par lInternet.
Installer le logiciel : des outils dinstallation et des procdures fournis avec

lapplication facilitent la tche. Linstallation est gnralement plus complexe
quand le systme est distribu, linstallation se fait alors de faon coordonne
et elle est ralise par de multiples procdures.
Fournir laide aux utilisateurs : lassistance aux utilisateurs peut prendre

plusieurs formes, cours de formation, instruction assiste par ordinateur, aide
en ligne, assistance tlphonique ou par Internet, la mise en place de
procdures de suivi et de rsolution des problmes.
Obtenir lacceptation formelle : dans certains contrats de dveloppement, le

dploiement comprend une tape dacceptation formelle par le client pour le
logiciel livr.
Planifier et effectuer des tests bta : on livre, aux personnes qui ont dj
effectu les tests pendant le dveloppement, un sous-ensemble du produit et
on met en place des procdures pour enregistrer, regrouper et analyser leurs
ractions.
LES ENCHAINEMENTS DITERATION, ROLE DES TRAVAILLEURS DANS LE

DEVELOPPEMENT DUN PROJET AVEC RUP
La prsentation des diffrents enchanements dactivits comme on les a prsents,

peuvent donner limpression que RUP est un processus en cascade, il nen est rien. Il sagit
de modles idaliss denchanements conus pour donner un aperu des activits
ralises au cours du dveloppement.
______________________________________________________________________________________________________
Page - 31 02/05/02
Figure 36 : Enchanement d'activits de l'itration gnrique [Jacobson, et al 1999].
Dans un projet, les enchanements des activits effectues chaque itration dpendent
beaucoup de la nature du logiciel dvelopp et de la phase du cycle de vie o on se trouve.
Ce sont des enchanements concrets susceptibles dtre effectus au cours dune itration.
Ils sont de la responsabilit dune personne qui doit assurer la cohrence avec les autres
travailleurs dans llaboration des artefacts pendant toute litration.
On va voir les enchanements dactivits de manire non exhaustive dans les trois
exemples suivants :
- Le premier qui se droule dans la phase de cration a pour objectif de dfinir la
vision du produit,
- Le deuxime est ralis au dbut de la phase dlaboration, le but est de
construire un prototype architectural,
- Le troisime est effectu en fin de construction et vise limplmentation du
systme.
4.1 EXEMPLE : DEFINIR LA VISION DU PRODUIT

Pour dfinir la vision du produit et prparer ltude dopportunit, il faut effectuer un
certain nombre denchanements dactivits dans la phase de cration, dite
dinception.
Lenchanement dactivits qui va tre dcrit dans ce point sinscrit dans le cycle de
dveloppement initial dun produit, il serait diffrent sil sagissait dun cycle
dvolution.
-
Dans lactivit de dmarrage on va dfinir la vision et la porte du systme.

Les intervenants travaillent avec les analystes systme pour dfinir les ambitions
du projet, les contraintes et les interfaces externes. A partir de la vision, le
groupe commence prparer une tude de rentabilit et une liste de risques.
Dans lactivit de gestion des exigences on dtermine et clarifie les
fonctionnalits du systme. Les analystes systmes font une bauche du modle
de cas dutilisation du systme. Ils crent un glossaire pour simplifier la
maintenance du modle et assurer sa cohrence.
Dans lactivit de gestion de projet on prcise le plan de projet, on examine la
faisabilit du projet et on tablit le plan du projet. Aprs la ralisation de
lbauche du modle de cas dutilisation, on traduit la vision en intgrant les
aspects conomiques, les cots dinvestissement du projet, les ressources
estimes, lenvironnement de dveloppement, les critres de russite et on
commence ltude de rentabilit. A ce stade, on tablit un ordre de priorit entre
les fonctionnalits et les cas dutilisation, le chef de projet peut alors dtailler le
plan de projet. On dfinit un ensemble provisoire ditrations et on fixe les
objectifs de chacune delles. Le chef de projet construit un planning de phase qui
______________________________________________________________________________________________________
Page - 32 02/05/02
contient les dates provisoires des phases de cration, de construction,

transition et leurs jalons principaux.
de
Les rsultats de cette itration initiale sont les premires bauches de la vision, de la
porte et du plan du projet, ainsi que ltude dopportunit.
Les dlais valus dans la phase de cration ne sont donns qu titre indicatif. Les
estimations du plan de projet initial sont grossires et deviennent plus ralistes au fur
et mesure que le projet avance [Kruchten 2000].
Figure 37 : Rpartition du temps de planification par phase [Jacobson, et al 1999].
4.2 EXEMPLE : CONSTRUIRE UN PROTOTYPE ARCHITECTURAL

Nous allons voir ci-dessous les enchanements dactivits drouler dans le dbut de
la phase dlaboration pour construire le prototype architectural ainsi que les
travailleurs impliqus dans cette phase.
La phase de cration est termine et le projet a pass le jalon de lobjet du cycle de
vie. Lorganisation possde une bauche du modle de cas dutilisation ainsi quune
version initiale du plan de projet.
-
Dans lactivit de dmarrage on bauche le plan ditration, des risques et des

objectifs architecturaux. En se basant sur le plan de projet, le chef de projet dmarre
le plan ditration avec litration courante. Avec larchitecte il tablit les critres
dvaluation de larchitecture en considrant les risques architecturaux liminer.
Dans lactivit de gestion des exigences on choisit les cas dutilisation et les
scnarios qui piloteront le dveloppement architectural. Larchitecte et le chef de
projet dfinissent une vue initiale des cas dutilisation qui spcifie les scnarios
prendre en compte pendant litration. Ces cas dutilisation et ces scnarios
piloteront le dveloppement architectural.
Un certain nombre de spcificateurs de cas dutilisation dcrivent en dtail les cas
dutilisation et les scnarios qui sont les plus critiques et les plus complexes.
Lanalyste systme peut avoir restructurer le modle de cas dutilisation dans son
ensemble.
Un concepteur dinterface complte les cas dutilisation dtaills et construit
linterface quil soumet pour validation aux utilisateurs.
Dans lactivit de gestion de projet on revoit les cas dutilisation et les risques.
Larchitecte rvise la vue des cas dutilisation partir des nouvelles descriptions et
ventuellement de la nouvelle structure du modle des cas dutilisation. Le chef de
projet met nouveau jour le plan ditration et reconsidre la gestion des risques si
de nouveaux risques sont rvls.
______________________________________________________________________________________________________
Page - 33 02/05/02
Dans lactivit danalyse et conception on dtermine les classes videntes, pour

faire une rpartition initiale des sous-systmes et on examine en dtail les cas
dutilisation. Pour se faire une ide gnrale des classes videntes et tablir un
dbut dorganisation des sous-systmes, larchitecte prend en compte le cahier des
charges, le glossaire, la vue des cas dutilisation et la connaissance gnrale que
lquipe a du domaine. Larchitecte identifie les mcanismes danalyse qui forment
une solution commune un problme dcouvert pendant lanalyse. On commence
crire un document darchitecture logicielle. En parallle, une quipe de
concepteurs, ventuellement aide de larchitecte, dtermine les classes et les
objets pertinents.
Certains concepteurs dfinissent les responsabilits des classes, mettent en
vidence leurs relations et leurs attributs. Puis larchitecte identifie les classes
architecturales significatives et les inclut dans la vue logique (document
darchitecture logicielle) .
Larchitecte organise, dans des paquetages des couches basses de larchitecture,
les classes qui offrent des services et les relient aux sous-systmes qui les
invoquent. Il traduit galement les mcanismes de conception qui prennent en
compte les contraintes et les services offerts par lenvironnement dimplmentation (
systme dexploitation, middleware, base de donnes) .
Les concepteurs instancient les classes de ces mcanismes, ils traduisent
lensemble des exigences dtailles pour chaque classe. Larchitecte soccupe des
exigences.
Larchitecte dfinit les tches et les processus ncessaires ainsi que le rseau
physique. Le rsultat est le document darchitecture logicielle. Larchitecte passe
ensuite en revue larchitecture.
-
Dans lactivit dimplmentation on soccupe de lorganisation du code.

Larchitecte considre limpact de la conception architecturale sur le modle
dimplmentation et dfinit la vue dimplmentation.
Un intgrateur systme dfinit dans quel ordre on doit implmenter les soussystmes et les intgrer dans un prototype architectural. Le rsultat de cette
planification figure dans le plan de projet.
Les implmenteurs crivent le code et font les tests unitaires des classes. Les
classes sont contenues dans les composants et les sous-systmes du modle
dimplmentation. Les testeurs dintgration testent ces sous-systmes et les
implmenteurs les livrent en vue de leur intgration.
Dans lactivit de test on planifie les tests dintgration et les tests systme. Le
concepteur de test dtermine et implmente les cas de test et les procdures de
tests correspondants. Les tests dintgration permettent de vrifier la capacit du
systme excuter un scnario dans un certain dlai ou sous une charge
spcifie.
On value le prototype architectural. Une fois intgr, le systme est test par le
testeur systme. Le concepteur de test analyse les rsultats pour vrifier que les
buts sont atteints. Larchitecte value ensuite ces rsultats au regard des risques
identifis.
Dans lactivit de gestion de projet on value litration. Le chef de projet

compare les cots, les dlais et le contenu rel de litration ceux du plan
ditration. Il dtermine les ventuels lments du systme reprendre. Il met
______________________________________________________________________________________________________
Page - 34 02/05/02
jour le plan de projet, il dcrit sommairement le plan ditration dans litration

suivante [Kruchten 2000].
Le rsultat de cette itration est une premire version de larchitecture, qui consiste en
des vues architecturales assez bien dcrites : la vue des cas dutilisation, la vue
logique et la vue dimplmentation et en un prototype architectural excutable.
Figure 38 : les "patato des" traces la main regroupent les principales activits de la phase cration.
4.3 EXEMPLE : IMPLEMENTER LE SYSTEME

Lenchanement dactivits dcrit dans cette section se droule vers la fin de la phase
de construction. Le cahier des charges est stable et une grande partie des
fonctionnalits sont implmentes et intgres prtes tre testes. Le projet se
prpare passer le jalon de la capacit oprationnelle initiale.
-
Dans lactivit de gestion de projet on planifie litration. Le chef de projet met

jour le plan ditration en tenant compte des fonctionnalits ajouter et des
risques attnuer au cours de cette nouvelle itration.
Dans lactivit dimplmentation on planifie lintgration au niveau systme.

Lintgrateur systme prend en considration lordre dans lequel les soussystmes doivent tre assembls pour former une configuration qui fonctionne et
que lon puisse tester. Le plan dintgration dpend des fonctionnalits dj
implmentes et de la stratgie gnrale dintgration et de test suivre.
Dans lactivit de test on planifie et on conoit les tests au niveau systme. Le

concepteur de test dtermine et dcrit les cas et les procdures de test dans le
______________________________________________________________________________________________________
Page - 35 02/05/02
modle de test. Il sassure que les procdures permettent dvaluer la

satisfaction des exigences.
-
Dans lactivit danalyse et conception on complte les ralisations de cas

dutilisation. Les concepteurs donnent des responsabilits au cours des
itrations prcdentes et mettent en vidence leurs relations et leurs attributs.
Dans lactivit de test on planifie et conoit les tests dintgration au niveau

des sous-systmes et du systme. Les tests dintgration sintressent la faon
dont les composants sont connects et fonctionnent ensemble. Le concepteur
de test suit la stratgie gnrale de test dfinie dans le plan de test.
Dans lactivit dimplmentation on dveloppe le code, les classes du modle

dimplmentation en suivant les rgles de programmation du projet et on fait les
tests unitaires, on corrige les ventuelles anomalies.
Limplmenteur conoit des tests unitaires pour vrifier ce que fait lunit ( bote
noire) et comment elle le fait ( bote blanche) . Les tests en bote noire sassurent
que lunit dans les diffrents tats est conforme aux spcifications. Les tests en
bote blanche sassurent que la conception est correctement implmente.
Les tests unitaires portent sur les plus petits composants logiciel testables.
Limplmenteur de lunit les conoit, les implmente et les excute. Le but
principal dun test unitaire est de sassurer que les tests en bote blanche
produisent les rsultats attendus et soient aux normes de qualit du projet.
Limplmenteur intgre un sous-systme, il combine des classes compltement

ou partiellement implmentes pour constituer une construction excutable.
Les testeurs excutent les procdures de test pralablement dveloppes, ils

font un rapport sur les anomalies qui devront tre corriges.
Quand le sous-systme est suffisamment test et prt tre intgr au niveau du

systme, limplmenteur le livre.
Lintgrateur systme combine de faon incrmentale des sous-systmes pour
crer une construction complte.
Dans lactivit de test du systme on fait les tests dintgration. Les testeurs
dintgration excutent les tests dintgration pralablement dvelopps et
examinent les rsultats. Une fois que le systme complet est intgr, le testeur
systme le teste. Le concepteur de test analyse les rsultats pour sassurer que
les buts sont atteints.
Dans lactivit de gestion de projet on value litration. Le chef de projet

compare les cots, les dlais et le contenu rels de litration ceux du plan
ditration. Il dtermine les lments reprendre et les itrations au cours
desquelles il faudra le faire. Il met jour la liste des risques et le plan de projet
[Kruchten 2000].
______________________________________________________________________________________________________
Page - 36 02/05/02
Figure 39 : La "patato de" trace la main regroupe les principalement activits de la phase cration
[Jacobson, et al 1999].
4.4 CARTOGRAPHIE DES ENCHAINEMENTS DACTIVITES DUN

AVEC RUP.
DEVELOPPEMENT DE PROJET
La cartographie gnrale dun projet avec RUP permet de voir qu chaque itration, on
fera intervenir les mmes travailleurs et on produira les mmes type dartefacts propres
la partie du systme dveloppe dans litration. Lobjectif des itrations est dajouter
de nouvelles fonctionnalits au prototype et de produire un systme plus complet. Les
rsultats de litration constituent la base du dveloppement pour litration suivante et
sont mis disposition de tous les dveloppeurs.
______________________________________________________________________________________________________
Page - 37 02/05/02
Figure 40 : Cartographie d'un projet dvelopp avec RUP [Jacobson, et al 1999].
Pour faire adopter le Processus unifi dans une socit, il est recommand de construire
un prototype, afin de tester la dmarche et lorganisation indispensable pour sa ralisation.
Figure 41 : L'approche typique pour mettre en place un processus et les outils [Jacobson, et al 1999].
______________________________________________________________________________________________________
Page - 38 02/05/02
CONCLUSION
Le processus unifi est une dmarche de dveloppement adapte au projet orient
objet. Lutilisation dUML en est le garant. Ce processus prconise le droulement
dun cycle en quatre phases avec des jalons majeurs chaque phase. Ceux-ci
permettent une parfaite matrise des risques dans la gestion de projet du logiciel.
Les socits qui adoptent ce processus doivent intgrer le changement
dorganisation et des mthodes de travail. En effet celui-ci des impacts non
ngligeables sur lorganisation rigoureuse des projets, la gestion des ressources et
lidentification des comptences. Ce processus a un avantage certain, cest quil
permet aux diffrentes ressources de dveloppement dacqurir de nouvelles
comptences dans les dveloppements sur les technologies nouvelles.
Dautre part, la direction doit vendre le processus ses clients. Celui-ci modifie la
dmarche dlaboration du systme entre les utilisateurs qui expriment leurs
besoins, larchitecte qui assure sa conception et le chef de projet qui pilote la
gestion du projet.
La charge de travail des utilisateurs pour leur intervention plus rgulire la
validation du systme chaque itration du cycle de vie est accrue et doit tre bien
value. En revanche la scurit procure par lanalyse des risques sur le systme
doit rassurer les directions concernes.
Dans cette tude, il na t abord que le processus et lutilisation des produits
Rational sans en voquer le cot. Il apparat vident que lutilisation du processus
unifi et des outils de Rational ne peuvent concerner que des socits qui ont
dvelopper des logiciels complexes et peuvent supporter une structure de
dveloppement importante.
Il est toutefois envisageable pour des PME dutiliser le processus unifi et dutiliser
ses propres outils de gestion de projet, de demande dvolution et de
dveloppement de logiciel pour rpondre la problmatique des projets qui utilisent
les technologies modernes, par exemple, bases sur les dveloppements pour le
Web. Ces socits doivent prvoir alors les interfaces entre les diffrents outils
utiliss dans leurs socits et le processus unifi.
______________________________________________________________________________________________________
Page - 39 02/05/02
BIBLIOGRAPHIE
Ouvrages, publications diverses

[Jacobson,
1999]
et
al Yvar Jacobson, Grady Booch et James Rumbaugh, de 1999

Le Processus unifi de dveloppement logiciel
Edition 2000 Eyrolles
Rsum
[Kruchten 2000]
Rsum
[Lopez, et al 1998]
Rsum
[Muller, et al 2000]
Rsum
[Quatrani, 2000]
Rsum
[Rational, 2000]
Cet ouvrage montre comment le processus unifi a prcisment pour but de

spcifier les diffrentes phases dun projet, de llaboration du cahier des
charges jusquau dploiement de lapplication. Cest un bon ouvrage un peu
confus, mais les tudes de cas permettent un bon clairage du processus.
Philippe Kruchten
Introduction RUP
ditions 2000 Eyrolles
Ce livre est dcouvrir, il prsente une autre approche du processus de
dveloppement logiciel, le processus (RUP) prsent par le fondateur du
processus chez Rational. Il est comprhensible et mthodique, en
complment louvrage Le processus Unifi de Ivar Jacobson est utiliser
pour approfondir certaines phases du dveloppement. Ces deux ouvrages
peuvent tre considrs comme rfrence pour le dveloppement de logiciel
sappuyant sur le langage de modlisation graphique UML.
Nathalie Lopez, Jorge Migueis et Emmanuel Pichon

Intgrer UML dans vos projets
Ce livre apporte une rponse lintgration dUML dans un projet. Il aborde
les quatre phases de la modlisation UML, lanalyse laide de uses cases,
le modle statique, le modle dynamique et le modle de conception sont
expliqus travers une tude de cas. Une analyse critique et constructive
des principaux AGL est propose galement dans cet ouvrage.
Pierre-Alain Muller et Nathalie Gaertner

Modlisation objet avec UML
Ce livre est un trs bon ouvrage par son approche la modlisation objet
dans une dmarche globale de gestion de projet. Il est de plus illustr par
deux tudes de cas.
Terry Quatrani
Modlisation UML avec Rational Rose 2000
Ce livre est un trs bon ouvrage, facile dutilisation grce ses tudes de
cas, il donne une rponse tout utilisateur de Rational Rose pour mener un
projet et dcliner les diffrentes tapes de ce projet.
Rational the e-development company

La solution de-development de Rational
Octobre Dcembre 2000.
[Roques, et al 2000] Pascal Roques et Franck Valle

UML en action
02/05/02
Rsum
Ce livre est dcouvrir, il prsente une autre approche du processus de

dveloppement logiciel, le processus en Y (2TUP) . Il apporte une rponse
aux contraintes de changements continuels imposs aux systmes
dinformation de lentreprise. Il intgre en permanence lvolution
fonctionnelle des mtiers de lentreprise avec les contraintes de larchitecture
technique.
Internet
[INT1]
http://www.UML.fr/
Site UML francophone
Rsum
[INT2]
Ce site ma permis daccder la bibliographie UML et dobtenir une

synthse sur la dmarche de modlisation graphique.
http://www.rational.com/
Site RUP toutes langues
Rsum
[INT3]
Ce site ma permis de dcouvrir les deux processus unifis. RUP (RUP) et

2TUP (Two Track Unified Process).
http://www.spmm.com/
Site Internet du Software Program ManagerNetwork
Rsum
Ce site permet de consulter les meilleures pratiques de dveloppement

logiciel.
02/05/02
RESUME
Le Rational Processus Unifi (RUP) est un processus commercial produit et dvelopp par
la socit Rational Software. Il sintgre lensemble des outils de dveloppement proposs
par Rational. Ce produit est une source de connaissances, toujours jour, accessible en
ligne sur le Web partir du poste de travail du dveloppeur.
Cest un cadre de processus et aussi un framework de processus gnriques pouvant tre
adapt une large classe de systmes logiciels, diffrents domaines dapplication et
diffrentes tailles de projet. Il utilise le langage de modlisation graphique UML (Unified
Modelisation Language) pour la cration des plans dlaboration et de construction dun
systme logiciel.
Le processus unifi est un processus de dveloppement logiciel qui regroupe les activits
mener pour transformer les besoins dun utilisateur en systme logiciel. Les traits distinctifs
de celui-ci tiennent en trois expressions cls : il est pilot par les cas dutilisation, centr sur
larchitecture, itratif et incrmental.
Le processus unifi rpte un certain nombre de cycles constituant la vie du systme.
Lapproche itrative recommande par RUP permet de prendre en compte les
changements qui interviennent souvent dans le cahier des charges. Elle permet de
contrler les risques plus rapidement dans le projet, puisque cest gnralement au moment
de lintgration quils apparaissent.
Tout cycle se droule en quatre phases, la cration, llaboration, la construction et la
transition et un certain nombre denchanements dactivits dont les principaux sont :
lexpression des besoins, lanalyse, la conception, limplmentation, les tests, la gestion de
configuration et le dploiement. Tout cycle aboutit la livraison dune version de produit aux
clients.
Pour mener efficacement chaque cycle, les dveloppeurs utilisent toutes les
reprsentations du produit logiciel : un modle de cas dutilisation, un modle danalyse et
de conception, un modle dimplmentation, de dploiement, un modle de tests et un
modle darchitecture du systme. Tous ces modles illustrent le systme logiciel, pour les
clients, les utilisateurs, les dveloppeurs et facilitent ainsi leur comprhension pendant le
cycle de vie du systme.
Mots cls :
Processus unifi cas dutilisation architecture itratif incrmental enchanement dactivits
phase exigence risque -

Rational Unified Process

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Rational Unified Process

Încărcat de

Drepturi de autor:

Formate disponibile

Rational Unified Process

Socit GICAB - Vannes

Table des Matires

LES COMPOSANTS ET LES GRANDS PRINCIPES DU PROCESSUS ............. 1

Les composants du produit RUP ..................................................................................................... 1

processus Itratif et Incrmental ............................................................................................ 10

LES ENCHANEMENTS DACTIVITS DU PROCESSUS ................................ 13

4 LES ENCHANEMENTS DITRATION, RLE DES TRAVAILLEURS DANS LE

Exemple : Dfinir la vision du produit.......................................................................................... 32

Exemple : Construire un prototype architectural ........................................................................ 33

Exemple : Implmenter le systme ............................................................................................... 35

Cartographie des enchanements dactivits dun dveloppement de projet avec RUP............. 37

Table des illustrations

RUP : Rational Unified Process

LES COMPOSANTS ET LES GRANDS PRINCIPES DU PROCESSUS

2.1 LES COMPOSANTS DU PRODUIT RUP

Le produit RUP comprend :

Figure 1 : RUP, Les composants.

2.2 LE PILOTAGE PAR LES CAS DUTILISATION

Les cas dutilisation reprsentent le moyen de dcrire le caractre fonctionnel des

Figure 3 : Cas d'utilisation retirer de l'argent [Jacobson, et al 1999].

2.2.2 Les flots des vnements dun cas dutilisation

2.2.3 Les cas dutilisation dans le processus de dveloppement

Le modle de cas dutilisation est le rsultat de lenchanement des activits de gestion

2.2.4 Exemple de cas dutilisation Retirer de largent .

Figure 5 : Cas dutilisation retirer de largent

Le cas dutilisation se dclenche quand le client insre sa carte bancaire, le

Le systme demande le code secret, le client le saisit, le systme le valide.

Le systme demande quelle opration le client dsire effectuer. Le client choisit

Le systme demande le montant du retrait. Le client saisit un montant.

Le systme entre en communication avec le rseau de la banque pour vrifier le

Le systme invite le client retirer sa carte. Le client sexcute.

Le systme fournit la somme dargent demande.

DAB : Distributeur Automatique de Billets

Le systme imprime le reu.

Fin du cas dutilisation.

On a dcrit un flot dvnements prcis, il en existe dautres, on peut envisager

Figure 6 : Modle d'analyse "retirer de l'argent"

2.3 LE PROCESSUS CENTRE SUR LARCHITECTURE

2.3.1 Importance des modles et de larchitecture

2.3.2 Dfinition de larchitecture

2.3.3 Reprsentation de larchitecture par le modle 4+1 vues

Figure 7 : Le modle darchitecture 4+1 vues [INT2].

La vue logique de larchitecture sintresse aux aspects fonctionnels du systme

La vue dimplmentation dcrit lorganisation des modules statiques du logiciel

La vue de dploiement rconcilie lingnierie du logiciel avec lingnierie

2.3.4 Architecture et conception architecturale.

2.3.5 Exemple sur le cas dutilisation Retirer de largent .

Figure 9 : diagramme de collaboration du systme DAB [Jacobson, et al 1999]..

On explique ici le flot de la ralisation du cas dutilisation. Le texte est presque

Figure 10 : Le modle de dploiement du systme DAB [Jacobson, et al 1999]..

transactions sur le nud serveur dapplications du DAB, le sous-systme gestion des

Figure 11 : La vue architecturale du modle de dploiement [Jacobson, et al 1999]..

La vue architecturale dimplmentation.

PROCESSUS ITERATIF ET INCREMENTAL

Figure 12 : Une approche itrative au dveloppement [INT1]

2.4.1 Quest-ce quune itration ?

2.4.2 La dimension statique du processus

Le quoi les artefacts. Un artefact est un lment dinformation fabriqu,

Figure 13 : Travailleurs, activits et artefacts [Kruchten 2000].

Le quand les enchanements dactivits. Une suite dactivits qui produit un

Figure 14 : Exemple denchanement dactivits [Kruchten 2000].

2.4.3 La dimension dynamique du processus

Figure 15 : Les quatre phases et jalons du processus itratif [Kruchten 2000].