Rational Unified Process

Rational Unified ProcessFor

Christiane DAVOINE-GUHUR

Socit GICAB - [email protected]

_____________________________________________________________________________________________________Christiane DAVOINE GUHUR 02/05/02

Table des Matires

1 INTRODUCTION..................................................................................................1

2 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.................................................................................................32.2.1 Dfinition..................................................................................................................................32.2.2 Les flots des vnements dun cas dutilisation..........................................................................42.2.3 Les cas dutilisation dans le processus de dveloppement...........................................................42.2.4 Exemple de cas dutilisation Retirer de largent ...................................................................5

2.3 Le processus centr sur larchitecture............................................................................................62.3.1 Importance des modles et de larchitecture...............................................................................62.3.2 Dfinition de larchitecture.......................................................................................................62.3.3 Reprsentation de larchitecture par le modle 4+1 vues..........................................................72.3.4 Architecture et conception architecturale...................................................................................72.3.5 Exemple sur le cas dutilisation Retirer de largent ..............................................................8

2.4 Le processus Itratif et Incrmental............................................................................................102.4.1 Quest-ce quune itration ?.....................................................................................................102.4.2 La dimension statique du processus.........................................................................................112.4.3 La dimension dynamique du processus....................................................................................12

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

3.1 La modlisation mtier..................................................................................................................143.1.1 Pourquoi modliser le mtier?..................................................................................................143.1.2 Comment modliser le mtier ?................................................................................................143.1.3 Les enchanements dactivits..................................................................................................153.1.4 Les outils de modlisation mtier.............................................................................................16

3.2 La gestion des exigences................................................................................................................163.2.1 Dfinitions...............................................................................................................................163.2.2 Comment exprimer les exigences ?..........................................................................................163.2.3 Conception de linterface utilisateur.........................................................................................173.2.4 Enchanements dactivits.......................................................................................................183.2.5 Les outils pour la gestion des exigences...................................................................................193.2.6 Exemple des exigences pour le cas dutilisation Retirer de largent ....................................19

3.3 Lanalyse et la conception.............................................................................................................193.3.1 Objectif....................................................................................................................................193.3.2 Travailleurs et artefacts............................................................................................................203.3.3 Enchanements dactivits.......................................................................................................213.3.4 Exemple danalyse du cas dutilisation Retirer de largent .................................................213.3.5 Les outils pour lanalyse et la conception.................................................................................22

3.4 Limplmentation..........................................................................................................................223.4.1 Objectifs..................................................................................................................................233.4.2 Les activits dimplmentation................................................................................................233.4.3 Les types de prototypes............................................................................................................243.4.4 Les outils pour limplmentation.............................................................................................24

3.5 Les tests.........................................................................................................................................243.5.1 Les objectifs.............................................................................................................................253.5.2 Le rle des tests dans le cycle de vie du logiciel.......................................................................253.5.3 Les travailleurs et artefacts......................................................................................................253.5.4 Exemple de tests pour le cas dutilisation retirer de largent ...............................................263.5.5 Les types de tests.....................................................................................................................273.5.6 Les outils de tests.....................................................................................................................27


3.6 La gestion de configuration...........................................................................................................273.6.1 Les objectifs.............................................................................................................................273.6.2 Les dfinitions........................................................................................................................283.6.3 Les travailleurs et les artefacts................................................................................................. 283.6.4 Les enchanements dactivits..................................................................................................293.6.5 Les outils support de la gestion de configuration......................................................................29

3.7 Le dploiement..............................................................................................................................293.7.1 Les objectifs.............................................................................................................................293.7.2 Les travailleurs et les artefacts................................................................................................. 303.7.3 Exemple de configuration pour le cas dutilisation Retirer de largent ................................303.7.4 Les enchanements dactivits..................................................................................................31

4 LES ENCHANEMENTS DITRATION, RLE DES TRAVAILLEURS DANS LEDVELOPPEMENT 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

5 CONCLUSION ....................................................................................................39

6 BIBLIOGRAPHIE ..................................................................................................1


Table des illustrations

Figure 1 : RUP, Les composants......................................................................................................................2Figure 2 : Les cas d'utilisation, la description fonctionnelle des objets[Lopez, et al 1998]...............................3Figure 3 : Cas d'utilisation retirer de l'argent[Jacobson, et al 1999]...............................................................4Figure 4 : Les cas dutilisation travers les diffrents modles[Kruchten 2000]..............................................4Figure 5 : Cas dutilisation retirer de largent.................................................................................................5Figure 6 : Modle d'analyse "retirer de l'argent".............................................................................................6Figure 7 : Le modle darchitecture 4+1 vues[INT2]....................................................................................7Figure 8 : Structure statique de la vue architecturale du modle de conception pour le systme DAB..............9Figure 9 : diagramme de collaboration du systme DAB[Jacobson, et al 1999]...............................................9Figure 10 : Le modle de dploiement du systme DAB[Jacobson, et al 1999]................................................9Figure 11 : La vue architecturale du modle de dploiement[Jacobson, et al 1999]......................................10Figure 12 : Une approche itrative au dveloppement[INT1]........................................................................10Figure 13 : Travailleurs, activits et artefacts [Kruchten 2000].....................................................................11Figure 14 : Exemple denchanement dactivits [Kruchten 2000].................................................................12Figure 15 : Les quatre phases et jalons du processus itratif[Kruchten 2000]................................................12Figure 16 : Dun cycle de vie squentiel un cycle de vie itratif [Kruchten 2000].......................................13Figure 17 : Les neufs principaux enchanements dactivits du processus [Kruchten 2000]...........................14Figure 18 : Travailleurs et artefacts dans les activits de modlisation mtier.[Kruchten 2000]....................15Figure 19 : Des modles mtier aux modles systmes[Kruchten 2000].........................................................15Figure 20 : Un enchanement d'activits de modlisation mtier.[Kruchten 2000].........................................16Figure 21 : Diffrents artefacts de l'ensemble des exigences et leurs relations avec d'autres artefacts[Kruchten2000].............................................................................................................................................................17Figure 22 : Travailleurs et artefacts dans l'enchanement des activits de gestion[Kruchten 2000]................18Figure 23 : Enchanement des activits de gestion des exigences [Kruchten 2000]........................................18Figure 24 : comparaison des modles des cas d'utilisation et d'analyse[Jacobson, et al 1999].......................20Figure 25 : Un enchanement des activits d'analyse et de conception[Kruchten 2000]................................. 21Figure 26 : identification de paquetages d'analyse gnraux partir des classes du domaine[Jacobson, et al1999].............................................................................................................................................................22Figure 27 : paquetages de services comptes et de risques encapsulant chacun des classesfonctionnellement lies[Jacobson, et al 1999]................................................................................................22Figure 28 : Enchanement d'activits d'implmentation..................................................................................23Figure 29 : point de convergence de l'implmentation [Jacobson, et al 1999]................................................23Figure 30 : Travailleurs et artefacts impliqus dans les tests [Jacobson, et al 1999]......................................25Figure 31 : Modle de tests [Jacobson, et al 1999]........................................................................................26Figure 32 : Cas, procdures et scripts de test pour un terminal bancaire [Kruchten 2000]............................26Figure 33 : Le cube CCM [Kruchten 2000]....................................................................................................28Figure 34 : Travailleurs et artefacts dans l'activit de dploiement [Jacobson, et al 1999]............................30Figure 35 : Modle de dploiement du Cas DAB[Jacobson, et al 1999].........................................................30Figure 36 : Enchanement d'activits de l'itration gnrique [Jacobson, et al 1999]....................................32Figure 37 : Rpartition du temps de planification par phase [Jacobson, et al 1999]......................................33Figure 38 : les "patato des" traces la main regroupent les principales activits de la phase cration.......35Figure 39 : La "patato de" trace la main regroupe les principalement activits de la phasecration[Jacobson, et al 1999].......................................................................................................................37Figure 40 : Cartographie d'un projet dvelopp avec RUP[Jacobson, et al 1999].........................................38Figure 41 : L'approche typique pour mettre en place un processus et les outils [Jacobson, et al 1999]..........38

______________________________________________________________________________________________________Christiane DAVOINE GUHUR 02/05/02

Prambule

Le Rational Unified Process est un processus de gnie logiciel dvelopp etcommercialis par la socit Rational Software. Il permet daffecter et de grer de manirerigoureuse et discipline les tches et les responsabilits au sein dune organisation dedveloppement... [Kruchten 2000] Le processus unifi a prcisment pour but de spcifier les diffrentes phases dunprojet, de llaboration du cahier des charges au dploiement de lapplication. Il est lecomplment idal du standard UML qui est un langage de modlisation graphique, dont lavocation 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 dveloppementgnie logiciel et dans la deuxime de ces citations lutilisation de sigle UML2. De fait, ladcouverte de RUP suppose des pr-requis de modlisation objet et dUML. On considredans cette bibliographie que ces deux points sont acquis, il ny aura pas de prsentationdUML, ni de lapproche objet.

RUP est un outil de modlisation UML, ses possibilits sont trs tendues et sont dcritesdans 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 uneprsentation de RUP qui sera dcoupe en trois parties,

1. Le processus , ses composants et ses grands principes2. 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 defil rouge, tout au long de ces pages, il sagit dun client bancaire qui effectue un retraitdargent sur un automate bancaire.

Les rfrences aux ouvrages, sites, documents consults sont indiqus par une rfrenceentre crochet par exemple [Jacobson, et al 1999].

1 RUP : Rational Unified Process2 UML : Unified Modeling Language

______________________________________________________________________________________________________Christiane DAVOINE GUHUR Page - 1 - 02/05/02

11 IINNTTRROODDUUCCTTIIOONN

RUP est le Rational Unified Process, cest un processus commercial, un produitdvelopp et maintenu par la socit Rational Software. Il contient des directives et desconseils sur les techniques modernes pour le dveloppement logiciel. Ce produit estune source de connaissances, toujours jour, accessible partir du poste de travail dudveloppeur. Il est parfaitement intgr lensemble des outils de dveloppementproposs par la socit.

Rational Unified Process est aussi un cadre de processus (Process framework), pourune organisation qui ladopte. Cette dernire peut ladapter et ltendre en fonction deses besoins [Kruchten 2000].

Pour dvelopper des systmes logiciels modernes, lexprience a mis en vidence sixmeilleures pratiques respecter. En les combinant, on sattaque aux causes profondesdes problmes de dveloppement logiciel [INT3].

Les meilleures pratiques pour le dveloppement de logiciel moderne respectent lespoints 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 deprojets et dorganisations, comme nous allons le dcouvrir dans la suite de cedocument en abordant : les composants et les principes du processus, les principauxenchanements dactivits et le rle des travailleurs dans le dveloppement dun projetavec le processus unifi.

22 LLEESS CCOOMMPPOOSSAANNTTSS EETT LLEESS GGRRAANNDDSS PPRRIINNCCIIPPEESS DDUU PPRROOCCEESSSSUUSS

22..11 LLEESS CCOOMMPPOOSSAANNTTSS DDUU PPRROODDUUIITT RRUUPP

RUP ne ressemble en rien la documentation des productions classiques de mthodesde 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 duprocessus 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.


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 Webque 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 supplmentairessur leur usage. Il y a par exemple des guides pour Rational Rose qui aide lamodlisation graphique ou ClearCase qui facilite la gestion de configuration.

- Des canevas (templates) pour tous les artefacts importants du processus quelque 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 ensystme logiciel. Mais cest plus quun simple processus, cest un framework de processusgnriques pouvant tre adapt une large classe de systmes logiciels, diffrentsdomaines dapplication, diffrents types dentreprises, diffrents niveaux de comptenceet diffrentes tailles dentreprises.Le Processus Unifi utilise le langage UML pour la cration des plans dlaboration et deconstruction du systme logiciel. En fait UML fait partie intgrante du Processus Unifi : lunet lautre ont t dvelopps en parallle. Nanmoins, les traits distinctifs du Processusunifi 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].


22..22 LLEE PPIILLOOTTAAGGEE PPAARR LLEESS CCAASS DDUUTTIILLIISSAATTIIOONN

Les cas dutilisation constituent le concept principal de la mthode OOSE de IvarJacobson, un des pres dUML. Dans le processus de standardisation des mthodes objetayant 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 lacomprhension 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 desobjets. Il se positionne sur trois axes :

- La description des objets, leurs proprits et leurs attributs. Elle reprsentela vue statique de lobjet,

- Lidentification des tats et des vnements. Elle reprsente la vuedynamique de lobjet,

- La traduction du savoir-faire et du mtier. Elle met en vidence lesexigences, les rgles fonctionnelles lies au mtier [Lopez, et al 1998].

2.2.1 Dfinition

Les cas dutilisation sont un moyen dexprimer les exigences fonctionnelles dusystme. RUP dfinit les concepts de cas dutilisation et dacteur de la faonsuivante :

- Un cas dutilisation est une squence dactions que ralise un systme et quifournit 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 dunetemporisation.

- Une squence dactions : la squence dont parle la dfinition est un flotspcifique dvnements.

- Un rsultat observable ayant une valeur : une squence dactions fournit unrsultat utile un acteur du systme. On garantit ainsi que le cas dutilisationest pertinent et exprim un niveau de granularit que comprend lutilisateur[Kruchten 2000].


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 systmequand le cas dutilisation se ralise. La fonctionnalit complte est dfinie par unensemble de cas dutilisation, chacun deux reprsentant un flot spcifiquedvnements.

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 ladescription dun cas dutilisation est le flot dvnements. Un flot dcrit une squencedactions 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 debase 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 gestiondes exigences. Durant les activits danalyse et de conception, on se sert du modle decas dutilisation pour crer le modle de conception. On dcrit comment les casdutilisation se ralisent en termes dinteractions entre les objets du modle deconception. On exploite les ralisations des cas dutilisation pour comprendre ladynamique du systme et optimiser les performances. Pendant les tests, on recourt auxcas 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 serventgalement au chef de projet qui peut dfinir les contenus et les objectifs des itrations.


Pour faire voluer les cas dutilisation, on commence par dvelopper un squelette decas dutilisation avant dapprofondir sa description. Au cours des premires itrations dela 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 labanque.

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 unautomate 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, descurit. Un exemple de cas dutilisation Retirer de largent peut scrire comme suit entablissant le squelette du flot des vnements :

- Le cas dutilisation se dclenche quand le client insre sa carte bancaire, lesystme 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 choisitde 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 lenumro 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.

3 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 envisagerdiffrents droulements.

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

Ce modle danalyse indique de quelle faon le cas dutilisation est ralis par unecollaboration, lun et lautre relis par une dpendance de traabilit et faitapparatre quatre classes qui prennent part la ralisation du cas dutilisation. Lesclasses distributeur et interface guichet sont des classes frontires, la classe retrait estune classe de contrle et la classe compte est une classe entit.

22..33 LLEE PPRROOCCEESSSSUUSS CCEENNTTRREE SSUURR LLAARRCCHHIITTEECCTTUURREE

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 constituelessence mme dune architecture et UML dispose de puissantes constructions quipermettent de formuler larchitecture. Larchitecte reoit ainsi dans cette tche, le soutiendUML 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 modlesaident simplifier la ralit et apprhender les solutions dun nouveau systme. Lesmodles 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 dunsystme quand on simplifie au maximum et que lon peut encore comprendre ce quefait ce systme et comment il fonctionne ! [Kruchten 2000].

2.3.2 Dfinition de larchitecture

Larchitecture est un concept complexe qui se reprsente par des vuesarchitecturales multiples et coordonnes. Elle est lensemble des dcisions prises sur lorganisation du systme logiciel, les choix des lments structuraux, ladfinition des interfaces et leurs comportements. Larchitecture logicielle sintressenon seulement la structure et au comportement du systme, mais aussi soncontexte, ses contraintes conomiques et technologiques.


2.3.3 Reprsentation de larchitecture par le modle 4+1 vues

Comme le montre la figure ci-dessous, RUP propose une approche cinq vuesappele 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 systmeet ce quil doit produire pour les utilisateurs finaux. Elle dcrit les classesmajeures 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 decouches. Elle prend en compte la gestion de configuration, la politique degestion de versions. On trouve par exemple le code source dun plan de vol et labibliothque 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 lingnieriesystme. Elle soccupe des problmes de dploiement, dinstallation, deperformances.

- La vue des cas dutilisation contient les quelques scnarios et cas dutilisationles plus importants. On les utilise pour guider ltude et la conception delarchitecture pendant les phases de cration (dinception) et dlaboration et onles exploite ensuite pour valider les diffrentes vues architecturales[Kruchten2000]..

2.3.4 Architecture et conception architecturale.

Comment lobtient-on ?

Larchitecture est dveloppe de faon itrative au cours de la phase dlaborationau travers de lexpression des besoins, de lanalyse, de la conception, delimplmentation et des tests.

Comment la dcrit-on ?

La description de larchitecture est une vue des modles du systme : modles descas dutilisation, danalyse, de conception, dimplmentation et de dploiement. Elle


dcrit les parties du systme quil est important de comprendre pour lesdveloppeurs 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. RUPdfinit 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 fortecohrence interne.

- Les composants mtier, il sagit densembles cohrents de composantsdexcution 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 mcanismesarchitecturaux 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 unpattern. Il fournit une solution commune un problme commun. Il donne uncomportement spcifique aux classes.

- Le pattern architectural reprsente un savoir-faire de conception prouv. Ilidentifie des abstractions, au-del des classes, des instances et des composantspropres 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 duDAB, la gestion des transactions et la gestion des comptes. Ces sous-systmestant ncessaires la ralisation du cas dutilisation retirer de largent , ils sontdonc signifiants sur le plan de larchitecture.


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-systmesralisent les cas dutilisation signifiants pour larchitecture laide dun diagramme decollaboration. Les objets des classes appartenant aux sous-systmes dialoguent lesuns avec les autres pour excuter une instance de cas dutilisation. Ces objetschangent 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 presqueidentique au flot dvnement du modle danalyse, mais il est vu sous langle dessous-systmes et non des classes.

La vue architecturale du modle de dploiement.

Le modle de dploiement dfinit larchitecture physique du systme en termes denuds connects. Ces nuds sont des units matrielles sur lesquelles sexcutentles composants logiciels. Les nuds et connexions peuvent alors tre modlissdans le modle de dploiement ds lenchanement dactivits des besoins. Dansnotre exemple, le client de la banque accde au systme par lintermdiaire dunnud client du DAB qui accde au serveur dapplications du DAB pour effectuer lestransactions. Le serveur dapplications du DAB utilise son tour, le serveur dedonnes 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 dploiechaque sous-systme dans son entier sur un seul nud. Le sous-systme interfacedu DAB est ainsi dploy sur le nud client du DAB, le sous-systme gestion des


transactions sur le nud serveur dapplications du DAB, le sous-systme gestion descomptes 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 modlesde conception et de dploiement. Chaque sous-systme de service du modle deconception se traduit par un composant pour chaque type de nud sur lequel il doittre install.

22..44 LLEE PPRROOCCEESSSSUUSS IITTEERRAATTIIFF EETT IINNCCRREEMMEENNTTAALL

La dmarche squentielle ou en cascade est acceptable pour des petits projets quicomportent peu de risques et utilisent une technologie prouve. En revanche, ellene convient pas au projet complexe qui comporte un degr lev dinnovation ou derisque. Partant de ce constat, on peut dcouper le cycle de vie dun grand projet enune succession de petits projets. On adopte alors lapproche itrative. Onslectionne un sous-ensemble rduit dexigences et limit au niveau des risques, oneffectue une partie de la conception et de la ralisation, on valide nouveau et ainside suite jusqu ce que le systme soit complet.Pour tre efficace on tablit une squence de jalons mineurs et majeurs clairementarticuls fournissant aux responsables et lquipe de dveloppement les critresncessaires 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 completdes principaux enchanements dactivits, aboutissant une version livre eninterne. Les itrations respectent les cinq enchanements principaux besoins,analyse, conception, implmentation, tests . Chaque itration dbute par uneactivit de planification et se termine par une activit dvaluation.


2.4.2 La dimension statique du processus

Dans le processus itratif et incrmental, la dimension statique du processuscorrespond la partie descriptive de celui-ci, la description du qui fait quoi, commentet quand. Cest sur ces quatre lments primaires de modlisation que RUP achoisi de prsenter ses concepts cls :

- Le qui le travailleur. Celui-ci fait rfrence au rle que doit tenir un individudans le cadre de son travail et de ses responsabilits. Lindividu dsign commetravailleur possde un ensemble de comptences.

Exemple : un concepteur est un individu qui dfinit les responsabilits, lesoprations, les attributs et les relations de dpendances dune ou plusieursclasses et dtermine comment elles sinsrent dans lenvironnementdimplmentation [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 deprogression. En terme de modlisation objet, un travailleur est un objet actif etles activits effectues par ce travailleur sont les oprations faites sur cet objet.

Exemples dactivits: planifier une itration, trouver des cas dutilisation et desacteurs, 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 lestravailleurs pour raliser une activit. En conception oriente objet, les activitssont les oprations dun objet actif et les artefacts sont les paramtres de cesactivits. Ils se prsentent sous diffrentes formes, un modle, un lment demodle, un document, du code source, un excutable. Exemple dartefacts : lemodle de conception, le modle darchitecture.

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


- Le quand les enchanements dactivits. Une suite dactivits qui produit unrsultat observable se nomme un enchanement dactivits. Un enchanementdactivits est reprsent dans RUP par un diagramme dactivits.

Les activits, les tapes et les principes sont des guides gnraux mis ladisposition de lutilisateur. Les guides dutilisation doutil sont les seuls documentsqui font une rfrence directe des outils. Ils expliquent comment effectuer certainestapes laide des outils. Des principes et conseils, des canevas, des guidesdutilisation doutils compltent la description du processus en donnant davantagedinformations 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 successionditrations. Chaque itration ressemble une mini-cascade et comporte les activitsde gestions des exigences, de conception, dimplmentation et dvaluation.

Lapproche itrative permet la prise en compte des changements dans le cahier descharges et au niveau de la stratgie dimplmentation. Elle sattaque aux risques etles rduit ds que possible. Elle permet lorganisation de progresser, dacqurir unsavoir 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, devrifier quon sachemine rellement vers lobjectif final, pour cela le processusitratif est organis en quatre phases dont chacune delles est ponctue par un jalonmajeur.

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


- La phase inception dcrit le produit final, et permet de raliser une tude derentabilit et de dfinir les ambitions du projet. Cette phase se conclut par lejalon Objectif de cycle de vie. Dans cette phase on met laccent sur lvaluationde lenveloppe globale du dveloppement.

- La phase dlaboration qui permet de planifier les activits et les ressourcesncessaires la ralisation du projet, de spcifier les fonctionnalits et deconcevoir larchitecture. Elle dtermine le jalon de larchitecture du cycle de vie.Ici on porte les efforts sur le cahier des charges et sur llaboration dunemaquette excutable.

- La phase construction qui construit le systme, en fait voluer la vision et

larchitecture jusqu lobtention dun produit prt livrer. Son aboutissement estle jalon de capacit oprationnelle initial. Lattention se porte sur la conceptiondtaille 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. Laphase de transition se conclut par le jalon livraison de produit. On sassure icique le systme a un niveau de qualit suffisant pour rpondre au cahier descharges.

Par rapport une approche traditionnelle, la dmarche itrative attnue les risques,sadapte mieux aux changements et permet aux quipes dacqurir desconnaissances pendant le droulement du projet. Elle offre galement un grandniveau de rutilisation et une meilleure qualit globale.

Figure 16 : Dun cycle de vie squentiel un cycle de vie itratif [Kruchten 2000].

33 LLEESS EENNCCHHAAIINNEEMMEENNTTSS DDAACCTTIIVVIITTEESS DDUU PPRROOCCEESSSSUUSS

Maintenant que nous avons abord les notions lmentaires qui sous-tendent les pratiquesessentielles du Processus unifi, nous allons dcrire en dtail chacun des enchanementsdactivits.

Dans RUP, il existe neuf principaux enchanements dactivits :- De modlisation mtier- De gestion des exigences- Danalyse et de conception- Dimplmentation- De test- De dploiement


- 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 etlutilisation qui sont les principes et conseils, les canevas, les guides dutilisation doutils etles concepts.

Chaque enchanement dactivit fait appel au mme formalisme dans sa reprsentationgraphique. Chacun deux est reprsent par :

- un diagramme travailleurs et artefacts qui prcise pour un travailleur laresponsabilit qui lui incombe dans la production des artefacts.

- Un diagramme denchanement dactivits qui prcise la chronologie desactivits et le lien de dpendance entre les activits et dautres travailleurs.

On reprendra chacun de ces enchanements en dtail dans les paragraphes suivants. Cestle diagramme denchanement des activits qui permet de passer de la conception vers lemodle systme.

33..11 LLAA MMOODDEELLIISSAATTIIOONN MMEETTIIEERR

3.1.1 Pourquoi modliser le mtier?

La modlisation mtier est une technique qui permet de comprendre les processusmtier dune entreprise. On modlise un mtier pour comprendre sa structure et sadynamique, pour sassurer que tous les intervenants ont une vision commune lorganisation et pour dduire les cahiers des charges des futurs systmesinformatiques de cette organisation. On modlise un mtier lorsque le nombredutilisateurs 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 : lemodle des cas dutilisation et le modle objet :

- Le modle des cas dutilisation est dcrit par les diagrammes des casdutilisation.

- Le modle objet mtier est un modle interne du mtier. Il dcrit la faon dontchaque cas dutilisation du mtier est ralis par un groupe de travailleursutilisant un ensemble dentits mtier et dunits de travail. Chaqueralisation de cas dutilisation mtier peut tre montre sous forme dediagrammes dinteractions et de diagrammes dactivits [Jacobson, et al 1999].


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, lesprocdures 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 bienles dpendances entre les modles mtier et les modles du systme informatiqueutiliss dans ce mtier. Les travailleurs mtier deviennent les acteurs du systmeinformatique. Les actions et comportements des travailleurs mtiers dterminent lescas dutilisation du systme, pour les parties quon souhaite automatiser. A partir desentits 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. Dansun premier temps, il sagit didentifier les processus mtier cls et les acteurs mtierconcerns, de les dcrire sous forme dun modle de cas dutilisation.

Ensuite, il convient de dtailler les descriptions des cas dutilisation mtier mis envidence, didentifier les rles, de dfinir les responsabilits, les oprations, lesattributs et les relations entre les travailleurs et les entits mtier. Ces activitsrelvent de la comptence du concepteur mtier.

Une fois ces modles labors, lauditeur du modle se charge de vrifier quilsreprsentent correctement lorganisation.


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 mtiersgraphiques.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 degrer les dpendances entre les lments issus de diffrents modles.Pour crer et maintenir automatiquement la documentation des modles, ondispose de loutil Rational SoDA.

33..22 LLAA GGEESSTTIIOONN DDEESS EEXXIIGGEENNCCEESS

3.2.1 Dfinitions

Une exigence est une condition laquelle doit satisfaire un systme ou une capacitdont il doit faire preuve [Kruchten 2000].Dans un systme on rencontre les exigences fonctionnelles qui expriment lecomportement dun systme en spcifiant les conditions dentre et les conditions desortie qui doivent en rsulter. Les exigences non fonctionnelles sont un ensembledexigences 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 comprispar lquipe de dveloppement. Pour communiquer avec exactitude auxdveloppeurs ce quils doivent raliser, il faut tablir un cahier des charges quicontient les exigences dtailles fonctionnelles et non fonctionnelles du systme. Lamodlisation par les cas dutilisation est un moyen efficace de les exprimer. Lesdiffrents types dusagers du systme sont reprsents par des acteurs et les


fonctionnalits sont converties en suites dinteraction entre ces acteurs et le systme[Kruchten 2000].

Pour exprimer les exigences, on collecte les demandes des intervenants, desutilisateurs finaux, des clients, des gens du marketing et on les saisit dans ledocument de demandes des intervenants (Cf la figure ci-dessous) . On utilise cetensemble de demandes pour dcrire le document de vision qui contient lesfonctionnalits numres, une tude de rentabilit, le cot de la ralisation et lebnfice escompt. On traduit ces fonctionnalits dans un cahier des chargesdtaill 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 casdutilisation 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 lesexigences 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 formegraphique et la conception en terme de classes de conception.Dans une premire tape, partir du modle des cas dutilisation et desspcifications supplmentaires, on bauche lenchanement des activits de gestiondes 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 partirdes dfinitions dtailles tablies pendant la ralisation des parties des casdutilisation qui ncessitent une interface avec les utilisateurs.


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 lesfonctions quil doit remplir.

- Le spcificateur de cas dutilisation qui dtaille les exigences fonctionnellesdu 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, ilsdoivent identifier ce quil faut produire et identifier les exigences non fonctionnelles.Ils peuvent alors dvelopper la vision du projet qui comprend la liste desfonctionnalits dcrites par les intervenants.

A partir du document de vision labor par les analystes systme, les spcificateursde cas dutilisation dtaillent les cas dutilisation et les spcificationssupplmentaires.


Les concepteurs dinterfaces utilisateur progressent en parallle des spcificateursde cas dutilisation pour concevoir linterface utilisateur.

Dans les premires itrations, larchitecte travaille avec les analystes systme et lesspcificateurs des cas dutilisation pour extraire un ensemble de scnarios qui vaservir 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 foisdans des documents textuels, dans des bases de donnes, de les grer et de traiterles demandes de modifications est Rational Requisite Pro de la socit Rational.Pour la modlisation graphique des artefacts (modle des cas dutilisation, classesfrontires) on peut utiliser Rational Rose.

Rational SoDA aide automatiser la cration dun cahier des charges. Il permet dedfinir un canevas intelligent pour extraire et assembler des informations dediffrentes sources, SoDA va regrouper toute linformation ayant trait un artefactpour produire un document unique.

3.2.6 Exemple des exigences pour le cas dutilisation Retirer delargent .

Pour analyser les exigences dans le cas Retirer de largent , on peut souhaiterque le temps de rponse un client de la banque soit infrieur 5 secondes, entre laslection du montant retirer et la dlivrance des billets.

On peut aussi imaginer que pour un client de la banque, lorsque lautomate est enmode autonome4, on dlivre au client une somme incluse dans le plafondhebdomadaire inscrit sur sa carte, alors quen mode connect ce plafond peut tredpass en fonction du solde de son compte ou des conditions spciales dont ilpeut bnficier.

33..33 LLAANNAALLYYSSEE EETT LLAA CCOONNCCEEPPTTIIOONN

3.3.1 Objectif

Lobjectif de lenchanement des activits danalyse et de conception est de traduirelensemble des exigences en une spcification qui dcrit comment raliser lesystme. Cette traduction suppose de bien comprendre le cahier des charges dusystme et de choisir la meilleure stratgie dimplmentation. Il faut mettre en placeune architecture robuste qui permet de concevoir un systme facile construire et faire valuer.

Le langage employ dans lanalyse repose sur un modle objet conceptuel, appelmodle danalyse. En fait, dans le modle danalyse, une ressource interne peut trereprsente sous forme dobjet, tel le compte dun client auquel accde les casdutilisation dpt et retrait [Jacobson, et al 1999].

Pendant cet enchanement, on exploite les cas dutilisation pour identifier unensemble dobjets partir desquels on construit des classes, les sous-systmes et

4 Mode autonome : Mode dconnect des bases de productions,


les paquetages. Le but de lanalyse est de traduire les exigences du systme enensemble de classes et de sous-systmes.

Lobjet de la conception est dadapter le rsultat de lanalyse aux contraintesimposes par les exigences non fonctionnelles. La conception doit dfinir le systmede faon ce quil puisse tre implment sans ambigu t. Ces deux grandesactivits analyse et conception sont regroupes dans cette prsentation, car ladeuxime reprend les artefacts de lactivit danalyse en dtaillant plus finement lescas 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 miseen place dune architecture saine et stable. Entre autre, il permet de crer un plandlaboration et de construction pour le modle dimplmentation. Le modle deconception est proche de limplmentation, il est naturel de le conserver et delactualiser 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 deplusieurs vues architecturales, qui sont des abstractions. La vue logique prsente ladcomposition du systme en un ensemble dlments logiques (classes, sous-systmes, paquetages, et collaborations) . La vue des processus tablit unecorrespondance entre ces lments et les processus ou les Threads dans lesystme.


3.3.3 Enchanements dactivits

La figure ci-dessous illustre un enchanement typique danalyse et de conception quiest centr dune part sur larchitecture et dautre part sur la conception dtaille declasses et de sous-systmes.

Examinons les activits ayant trait larchitecture.

- Larchitecte identifie les patterns architecturaux. Les mcanismes clsdfinissent les couches, les principes dorganisation des sous-systmes et lastratgie de rutilisation.

- Lanalyste des cas dutilisation produit des classes. Il identifie les classessignificatives, les regroupe dans des paquetages et des sous-systmes deconception que lon organise en couches.

- Le concepteur utilise larchitecture et les rsultats de lanalyse des casdutilisation pour identifier les caractristiques des classes, leurs relations etaffiner leurs spcifications. On poursuit la conception des cas dutilisation enspcifiant chaque ralisation en terme doprations sur les classes et sous-systmes, dans les diagrammes de squence ou diagrammes decollaboration.

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 paquetagesdanalyse gnraux partir du modle du domaine. Chacune des classes reprsentedes entits importantes et complexes. Les paquetages gestion des comptes etgestion des clients de la banque contiendront probablement de nombreuses classesdanalyse, notamment des classes de contrle et des classes frontires liesrespectivement la gestion des comptes et des clients de la banque [Jacobson, et al1999].


Figure 26 : identification de paquetages d'analyse gnraux partir des classes du domaine [Jacobson, etal 1999].

Le paquetage gestion des comptes comprend un paquetage de service gnralappel comptes, qui permet daccder aux comptes pour des activits telles que letransfert dargent et lextraction dhistorique des transactions. Ce paquetage contientgalement un paquetage de service appel risques, consacr lestimation desrisques associs un compte particulier.

Figure 27 : paquetages de services comptes et de risques encapsulant chacun des classesfonctionnellement 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 cetenchanement. Les principes et conseils de modlisation associs aux diffrentsartefacts du RUP sont tous exprims selon le formalisme dUML.Rational Rose est le meilleur outil pour saisir, grer et prsenter les modles. Rosepermet 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 lesystme partir de lun ou de lautre.

Avec ObjectTime Developper et Rose for Real-Time, il est possible de construireun modle de conception excutable.Avec SoDA on cre automatiquement des documents et des rapports en extrayantet mettant en forme des informations provenant de plusieurs sources, telles queRose et Requisite Pro.

33..44 LLIIMMPPLLEEMMEENNTTAATTIIOONN

Limplmentation part des rsultats de la conception pour implmenter le systme sousforme de composants, cest--dire de code source, de scripts, de binaires, et dexcutables.


3.4.1 Objectifs

Le principal objectif de limplmentation est donc dtoffer larchitecture et le systmedans son ensemble. Pour tre plus prcis, on voit que lenchanement des activitsdimplmentation a de multiples objectifs :

- Dfinir lorganisation du code en termes de sous-systmes dimplmentationen 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 deuxphases principalement. Dans la phase de llaboration, il est pour la cration delarchitecture excutable de rfrence. Dans la phase de construction, son rle estmajeur dans le dveloppement des composants excutables du logiciel. Lesactivits dimplmentation trouvent un rle dans la phase de la transition pour lacorrection 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, chaqueimplmenteur est responsable du test des units de code quil produit.Pour expliquer les activits dimplmentation dfinies dans RUP, on prsente lestrois concepts cls suivants, les constructions, lintgration, les prototypes.


Le concept de construction est une version excutable dun systme ou dune partiedun systme qui ralise un sous-ensemble des fonctionnalits du produit final. Tousles lments dune construction sont soumis au contrle de configuration.

Le concept dintgration est une activit de dveloppement logiciel au cours delaquelle on combine des composants logiciels distincts en un tout. Il existe deuxniveaux dintgration, on procde lassemblage des lments constituant le soussystme avant de le livrer aux intgrateurs du systme ou on les assemble pourformer le systme complet. RUP recommande une approche incrmentale delintgration. La dmarche consiste crire des parties de code, les tester et lescombiner graduellement dans un ensemble excutable, en ajoutant une partie lafois.

Le concept de prototype permet de faire face aux risques et de lever lincertitudesur : la viabilit commerciale du produit, son utilisation, son financement et lacomprhension 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 souciepas de la qualit ni des normes du projet.

- Les prototypes structurels qui explorent les aspects architecturaux ettechnologiques du systme, vu de lintrieur. Ce sont des prototypes engnral volutifs qui utilisent et testent linfrastructure du systme final, sonossature.

3.4.4 Les outils pour limplmentation

Cest dans le domaine de limplmentation que lon trouve tous les outils dedveloppement logiciel classiques tels que les diteurs, les compilateurs, lesditeurs de liens et les dbogueurs. Aujourdhui, ces outils de gestion se trouventdans des environnements de dveloppement intgrs o ils partagent une mmebase de donnes (exemple : lenvironnement de dveloppement Rational APEXpour ADA et C++) .Rational Rose permet de faire du round-trip engineering, en liant troitement lesactivits de conception et dimplmentation. Des outils danalyse syntaxique commePurify et Quantify facilitent la dtection danomalies dans le code. Le gestionnairede configuration ClearCase offre des espaces de travail individuels, des espacesdintgration des sous-systmes et du systme. ClearQuest est loutil idal pour lesuivi des demandes de changement et des anomalies, jusquau code source.

33..55 LLEESS TTEESSTTSS

Lenchanement dactivits de tests sattache la vrification des rsultats delimplmentation en testant chaque construction, aussi bien les constructions internes etintermdiaires que les versions finales du systme, livrables lextrieur. Cet enchanementdactivit concourt la qualit du produit et de tous les lments qui ont servi le fabriquer.


3.5.1 Les objectifs

Lenchanement des tests a pour but principal dvaluer la qualit dun produit. Pourcela il faut vrifier la bonne intgration des composants, les fonctionnalits et lesperformances du produit. Les divers objectifs que poursuit la phase de tests sont deplanifier les tests ncessaires pour chaque itration, concevoir et implmenter lestests en crant les cas de tests et en spcifiant ce qui doit tre test. Ils sontgalement deffectuer les divers tests et prendre systmatiquement les rsultats dechacun 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 dudveloppement. Dans la phase de conception, on planifie les tests pour dlimiter laporte du systme, mais ils interviennent avant tout au moment o chaqueconstruction doit subir des tests dintgration et des tests systme. Cela signifie queles tests mobilisent lattention pendant la phase dlaboration lors du test delarchitecture de rfrence excutable et pendant la phase de construction, lors delimplmentation de la masse du systme. Pendant la phase de transition, lattentionse porte principalement sur la correction des anomalies dtectes au cours despremires 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 lacouverture, des rsultats et de lefficacit des tests,

- Le testeur systme qui est responsable de la prparation, de lexcution, delvaluation des rsultats,

- Le testeur de performance qui est responsable de lexcution des tests deperformance.

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 lesressources mises leur disposition.

- Le modle de test dcrit les conditions dans lesquelles les composantsexcutables du modle dimplmentation subissent des tests dintgration etdes tests systme. Ce modle se compose dun ensemble de cas de test, deprocdures et de composants de test.

- Un cas de test correspond lensemble des donnes de test, lesconditions dexcution et les rsultats attendus,


- Une procdure de tests spcifie les conditions dexcution dun ou deplusieurs 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 desinstructions 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 lesvariables de la charge et dfinit les valeurs utiliser, en fonction descaractristiques 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 vaprendre deux cas de test , retirer un montant prdfini et retirer un montant dfinipar 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,


- 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 detravail qui simule le mcanisme par lintermdiaire de scripts de test individuels pourassurer 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 stablesles 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 outilsadquats. Voyons comment les outils de dveloppement logiciel de Rationalpermettent lautomatisation des tests.

TestStudio est une suite doutils qui prend en charge limplmentation et lvaluationdes tests. Ils permettent aux testeurs de crer et dexcuter des scripts de tests basedinterface utilisateur graphique senss valuer les fonctionnalits et lesperformances de lapplication. TestStudio comprend les outils suivants :

- Robot soccupe de limplmentation et de lexcution des tests. Avec cet outilles testeurs crent et excutent des scripts de tests base dinterfaceutilisateur,

- LogViewer rcupre les rsultats des tests et gnre un rapport qui permetdvaluer leur excution,

- TestManager est utilis pour la planification, la conception et lvaluation destests. Il founit des comptes rendus de ltat davancement des tests et du tauxde couverture du cahier des charges,

- TestFactory vrifie la fiabilit de lapplication. Il gnre et excuteautomatiquement des scripts de test. Il gnre un compte rendu de couverturedu code.

PerformanceStudio implmente et excute des scripts de test dun utilisateur virtueldans le cadre de test de performance et de certains tests fonctionnels limits.

33..66 LLAA GGEESSTTIIOONN DDEE CCOONNFFIIGGUURRAATTIIOONN

3.6.1 Les objectifs


Lobjectif de la gestion de configuration et des changements est de garder une tracede tous les lments qui participent au dveloppement. Le but est de suivre leurvolution puisquils sont susceptibles de faire lobjet de demandes de modification.Tout au long du cycle de vie dun produit, lquipe de dveloppement cre, modifiemaintes fois de nombreux artefacts. Ceci reprsente un investissement trs lourd, lesartefacts 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 fonctionsinterdpendantes : la gestion de configuration, la gestion des demandes dechangements, 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 unnumro de version. Elle gre les dpendances entre les artefacts, les constructionset la hirarchie de dpendance des composants. Elle fournit aux dveloppeurs desespaces indpendants afin dviter les conflits dans la phase dintgration

- La gestion des demandes de changements se focalise sur la structure duprocessus. Il sagit dorganiser et de traiter les modifications du systme sollicitespar les intervenants internes et externes, danalyser les consquences de cesinterventions sur le produit et de suivre les demandes de changements jusqu leuraccomplissement. Les raisons des demandes de changements peuvent porter sur lacorrection dune anomalie, lamlioration de la qualit du produit ou de cesperformances, 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. Ilsagit de fournir des informations aux responsables de projet, en utilisant des outilsde gestion de configuration. A partir de cette base de donnes, on peut fournir desmesures sur ltat davancement du projet, des mesures de distribution deschangements et des mesures de tendance.

3.6.3 Les travailleurs et les artefacts

3.6.3.1 Les travailleursLes principaux travailleurs qui interviennent dans cette gestion de configuration sont :

- Le chef de projet qui est responsable du plan de gestion de la configuration,

5 CCM : Configuration and Change Management


- Le responsable de la configuration qui est charg dtablir la structure duproduit dans le systme de gestion de configuration, de la dfinition et delallocation des espaces de travail privs.

- Les implmenteurs qui sont chargs des volutions du produit dans un espacede travail qui leur est attribu,

- Les intgrateurs qui acceptent les lments modifis dans un espace detravail dintgration, ceux-ci assemblent galement le produit.

- Larchitecte qui fournit des informations pour la cration de la structure duproduit en tablissant la vue dimplmentation.

3.6.3.2 Les artefactsLes artefacts cls de la gestion de configuration sont les suivants :

- Le plan de gestion de la configuration dcrit les versions, les variantes, lesespaces de travail et les procdures utiliser.

- Les demandes de changements sont mises par un initiateur et pour unecause lorigine de la demande. On enregistre ces informations ainsi que lesrsultats de lanalyse dimpact, le cot, les dlais des oprations.

- Le modle dimplmentation utilis par le responsable de la configuration pourmettre en place lenvironnement.

- Les mesures sur ltat davancement, que lon inclut dans les rapportsdvaluation de ltat davancement.


Les enchanements dactivits de gestion de configuration peuvent tre vus de lafaon suivante :

- Le chef de projet tablit les procdures de gestion de configuration utiliserdans le projet, dfinit les exigences pour les rapports sur ltat davancementet les rfrences de base.

- Le responsable de configuration dfinit la structure du produit, cre et alloueles 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 etingrate qui demande beaucoup deffort et de rigueur. On a tout intrt lautomatiseren 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.

33..77 LLEE DDEEPPLLOOIIEEMMEENNTT

3.7.1 Les objectifs

Le but de lenchanement des activits de dploiement est de livrer le produit auxutilisateurs finaux. Le dploiement dpend essentiellement du domaine et du contextecommercial dans lequel sinscrit le logiciel.


3.7.2 Les travailleurs et les artefacts

Lenchanement des activits de dploiement soccupe de tous les artefacts qui sontlivrs 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 susceptiblesdintervenir :

- 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 delargent

Lexemple ci-dessous montre le dcoupage du dploiement quil faudra effectuer surlarchitecture matrielle identifie.

Figure 35 : Modle de dploiement du Cas DAB [Jacobson, et al 1999].



Il convient de respecter la ralisation des activits numres ci-dessous en fonctiondu 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 deconfiguration ainsi que les programmes pour convertir des donnes existantesdans le nouveau format.

- Conditionner le logiciel : les divers artefacts sont conditionns sur dessupports varis, disquettes, CD-Rom, bandes magntiques, fichiers sur unserveur, cassettes vido. On doit les tiqueter correctement.

- Distribuer le logiciel : plusieurs solutions sont envisages, depuislempaquetage dans des botes jusqu lutilisation dun rseau de distributeursen passant par lInternet.

- Installer le logiciel : des outils dinstallation et des procdures fournis aveclapplication facilitent la tche. Linstallation est gnralement plus complexequand le systme est distribu, linstallation se fait alors de faon coordonneet elle est ralise par de multiples procdures.

- Fournir laide aux utilisateurs : lassistance aux utilisateurs peut prendreplusieurs formes, cours de formation, instruction assiste par ordinateur, aideen ligne, assistance tlphonique ou par Internet, la mise en place deprocdures de suivi et de rsolution des problmes.

- Obtenir lacceptation formelle : dans certains contrats de dveloppement, ledploiement comprend une tape dacceptation formelle par le client pour lelogiciel livr.

- Planifier et effectuer des tests bta : on livre, aux personnes qui ont djeffectu les tests pendant le dveloppement, un sous-ensemble du produit eton met en place des procdures pour enregistrer, regrouper et analyser leursractions.

44 LLEESS EENNCCHHAAIINNEEMMEENNTTSS DDIITTEERRAATTIIOONN,, RROOLLEE DDEESS TTRRAAVVAAIILLLLEEUURRSS DDAANNSS LLEEDDEEVVEELLOOPPPPEEMMEENNTT DDUUNN PPRROOJJ EETT AAVVEECC RRUUPP

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 sagitde modles idaliss denchanements conus pour donner un aperu des activitsralises au cours du dveloppement.


Figure 36 : Enchanement d'activits de l'itration gnrique [Jacobson, et al 1999].

Dans un projet, les enchanements des activits effectues chaque itration dpendentbeaucoup 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 autrestravailleurs dans llaboration des artefacts pendant toute litration.

On va voir les enchanements dactivits de manire non exhaustive dans les troisexemples suivants :

- Le premier qui se droule dans la phase de cration a pour objectif de dfinir lavision du produit,

- Le deuxime est ralis au dbut de la phase dlaboration, le but est deconstruire un prototype architectural,

- Le troisime est effectu en fin de construction et vise limplmentation dusystme.

44..11 EEXXEEMMPPLLEE :: DDEEFFIINNIIRR LLAA VVIISSIIOONN DDUU PPRROODDUUIITT

Pour dfinir la vision du produit et prparer ltude dopportunit, il faut effectuer uncertain nombre denchanements dactivits dans la phase de cration, ditedinception.

Lenchanement dactivits qui va tre dcrit dans ce point sinscrit dans le cycle dedveloppement initial dun produit, il serait diffrent sil sagissait dun cycledvolution.

- Dans lactivit de dmarrage on va dfinir la vision et la porte du systme.Les intervenants travaillent avec les analystes systme pour dfinir les ambitionsdu projet, les contraintes et les interfaces externes. A partir de la vision, legroupe commence prparer une tude de rentabilit et une liste de risques.

- Dans lactivit de gestion des exigences on dtermine et clarifie lesfonctionnalits du systme. Les analystes systmes font une bauche du modlede cas dutilisation du systme. Ils crent un glossaire pour simplifier lamaintenance du modle et assurer sa cohrence.

- Dans lactivit de gestion de projet on prcise le plan de projet, on examine lafaisabilit du projet et on tablit le plan du projet. Aprs la ralisation delbauche du modle de cas dutilisation, on traduit la vision en intgrant lesaspects conomiques, les cots dinvestissement du projet, les ressourcesestimes, lenvironnement de dveloppement, les critres de russite et oncommence ltude de rentabilit. A ce stade, on tablit un ordre de priorit entreles fonctionnalits et les cas dutilisation, le chef de projet peut alors dtailler leplan de projet. On dfinit un ensemble provisoire ditrations et on fixe lesobjectifs de chacune delles. Le chef de projet construit un planning de phase qui


contient les dates provisoires des phases de cration, de construction, detransition et leurs jalons principaux.

Les rsultats de cette itration initiale sont les premires bauches de la vision, de laporte et du plan du projet, ainsi que ltude dopportunit.

Les dlais valus dans la phase de cration ne sont donns qu titre indicatif. Lesestimations du plan de projet initial sont grossires et deviennent plus ralistes au furet mesure que le projet avance [Kruchten 2000].

Figure 37 : Rpartition du temps de planification par phase [Jacobson, et al 1999].

44..22 EEXXEEMMPPLLEE :: CCOONNSSTTRRUUIIRREE UUNN PPRROOTTOOTTYYPPEE AARRCCHHIITTEECCTTUURRAALL

Nous allons voir ci-dessous les enchanements dactivits drouler dans le dbut dela phase dlaboration pour construire le prototype architectural ainsi que lestravailleurs impliqus dans cette phase.

La phase de cration est termine et le projet a pass le jalon de lobjet du cycle devie. Lorganisation possde une bauche du modle de cas dutilisation ainsi quuneversion initiale du plan de projet.

- Dans lactivit de dmarrage on bau

Rational Unified Process

Documents

Transcript of Rational Unified Process