Cours de Genie Logiciel

Notes de cours
Gnie Logiciel
Anne acadmique 2008/2009
Gnie Logiciel Sommaire
Anne acadmique 2008-2009
Sommaire
Sommaire......................................................................................................................................................2 Notes Importantes........................................................................................................................................4 Chapitre I . Introduction au Gnie Logiciel ..............................................................................................5 I.1. Dfinition .............................................................................................................................................5 I.2. Les objectifs du GL ..............................................................................................................................5 I.3. Les difficults du GL............................................................................................................................7 I.4. Les logiciels et mtiers du GL .............................................................................................................7 I.5. La qualit du logiciel ?........................................................................................................................8 Chapitre II . Les modles classiques de cycle de vie ...............................................................................10 II.1. Introduction......................................................................................................................................10 II.2. Modle en cascade ...........................................................................................................................10 II.3. Modle en V .....................................................................................................................................11 II.4. Modle incrmental..........................................................................................................................11 II.5. Modle en spirale .............................................................................................................................11 Chapitre III . Introduction au processus de dveloppement .................................................................13 III.1. Dfinition ........................................................................................................................................13 III.2. Historique du processus unifi .......................................................................................................13 III.3. Instances du Processus Unifi ........................................................................................................14 Chapitre IV . Le Processus Unifi ............................................................................................................15 IV.1. Introduction.....................................................................................................................................15 IV.2. La vie du Processus Unifi .............................................................................................................15 IV.2.1. Axe horizontal .........................................................................................................................16 IV.2.2. Axe vertical .............................................................................................................................17 IV.3. Processus pilot par les cas dutilisation .......................................................................................18 IV.3.1. Intrt des cas dutilisation ......................................................................................................18 IV.3.2. Ralisation des cas dutilisation ..............................................................................................19 IV.4. Processus centr sur larchitecture ................................................................................................21 IV.4.1. Intrt de larchitecture............................................................................................................21 IV.4.2. Architecture et cas dutilisation ...............................................................................................22 IV.4.3. Construction de larchitecture .................................................................................................22 IV.5. Processus itratif et incrmental ....................................................................................................24 IV.5.1. Cest quoi itratif et incrmental ? ..........................................................................................24 IV.5.2. Intrt du dveloppement itratif et incrmental .....................................................................26 IV.5.3. La rduction des risques ..........................................................................................................27 Chapitre V . Les principaux enchanements dactivits.........................................................................29 2 /55
Gnie Logiciel Sommaire
V.1. Comprhension du contexte du systme ...........................................................................................29 V.2. Expression des besoins .....................................................................................................................29 V.2.1. Prsentation...............................................................................................................................29 V.2.2. Les artefacts ..............................................................................................................................30 V.2.3. Les travailleurs..........................................................................................................................31 V.2.4. Enchanement dactivits ..........................................................................................................31 V.3. Analyse .............................................................................................................................................35 V.3.1. Prsentation...............................................................................................................................35 V.3.2. Artefacts ....................................................................................................................................35 V.3.3. Travailleurs ...............................................................................................................................37 V.3.4. Enchanement dactivits ..........................................................................................................37 V.4. Conception .......................................................................................................................................40 V.4.1. Prsentation...............................................................................................................................40 V.4.2. Artefacts ....................................................................................................................................40 V.4.3. Travailleurs ...............................................................................................................................41 V.4.4. Enchanement dactivits ..........................................................................................................42 V.5. Implmentation .................................................................................................................................45 V.5.1. Prsentation...............................................................................................................................45 V.5.2. Artefacts ....................................................................................................................................46 V.5.3. Travailleurs ...............................................................................................................................46 V.5.4. Enchanement dactivits ..........................................................................................................47 V.6. Tests..................................................................................................................................................50 V.6.1. Prsentation...............................................................................................................................50 V.6.2. Artefacts ....................................................................................................................................50 V.6.3. Travailleurs ...............................................................................................................................51 V.6.4. Enchanement dactivits ..........................................................................................................51 V.7. Conclusion........................................................................................................................................54
3 /55
Gnie Logiciel Notes Importantes
Notes Importantes
Pre-requis - Analyse et conception (MERISE), OO (UML) - Programmation oriente objet (Java, C++, C#, ) Objectifs du cours Ce cours a pour principal objectif de parcourir les diffrentes approches, techniques et mthodes utilises dans la ralisation des logiciels critiques ( fort impact sur lconomie, la vie humaine, ) et de grande taille (mobilisant des ressources considrables). Il doit permettre lapprenant de : - Comprendre ce que cest le Gnie Logiciel ainsi que ses objectifs, - Connatre les diffrentes approches de dveloppement logiciel, - Percevoir de faon gnrique le processus unifi et ses caractristiques, - Matriser les diffrents enchanements dactivits du processus unifi, - Mettre en uvre le processus unifi dans le cadre dun projet. Programme Chapitre I . Introduction au Gnie Logiciel Chapitre II . Les modles classiques de cycle de vie Chapitre III . Introduction au processus de dveloppement Chapitre IV . Le Processus Unifi Chapitre V . Les principaux enchanements dactivits Chapitre VI . Dveloppement itratif et incrmental Bibliographie 1. Patrice CLEMENTE : Cours de Gnie Logiciel, 2me anne STI, ENSI BOURGES, 2003. 2. Anne-Marie Hugues : Gnie Logiciel, 2002. http://www.polytech.unice.fr/~hugues/GL/ 3. Pierre-Alain MULLER, Nathalie GAERTNER. Modlisation objet avec UML. Eyrolles. Edition 2000, 5me tirage 2004. 4. Ivar JACOBSON, Grady BOOCH, James RUMBAUGH. Le Processus unifi de dveloppement logiciel. Eyrolles, 2000. 5. Alfred Strohmeler, Didier Buchs. Gnie Logiciel: principes, mthodes et techniques. Presses Polytechniques et Universitaires Romandes, 1996. Mise en uvre : - Un projet ?? - Application au projet Tuteur
Zphyrin Soh
4 /55
Gnie Logiciel Introduction au Gnie Logiciel
Chapitre I . Introduction au Gnie Logiciel
I.1. Dfinition
Quest ce que le GL ? Quand est-il n ? Pourquoi ? Gnie logiciel ( Software Engineering en anglais) : Domaine des sciences de lingnieur dont la finalit est la conception, la ralisation et la maintenance de systmes logiciels complexes, srs et de bonne qualit. Un Logiciel est un ensemble bien document ( tous les niveaux) de programmes construit pour satisfaire les besoins de ses utilisateurs. Le Gnie Logiciel dfinit alors lensemble des mthodes et des techniques pouvant faciliter la conception et la ralisation des logiciels complexes et de bonne qualit. Le Gnie Logiciel est n en Europe dans les annes 70. Il a t dfini par un groupe de scientifiques pour rpondre un problme qui devenait de plus en plus vident : le logiciel nest pas fiable et il est difficile de raliser dans des dlais prvus des logiciels satisfaisant leurs besoins initiaux. Petit historique 1968 : naissance GL la confrence de l'OTAN Garmisch-Partenkirchen (Allemagne) 1973 : premire confrence sur le GL 1975 : premire revue sur le GL (IEEE Transaction of Software Engineering) 1980 : dbut des AGL Le Gnie Logiciel est rapprocher du Gnie civil, Gnie mcanique ou Gnie chimique. La ralisation d'un pont ne peut tre mene sans mthodologie, de mme la ralisation d'un logiciel ncessite un minimum de prcautions qui garantissent un certains nombre de proprits. Le terme gnie logiciel a t choisi pour exprimer le fait que le dveloppement dun logiciel doit se fonder sur des bases thoriques et sur un ensemble de mthodes et outils valids par la pratique, comme cest le cas en gnie civil, gnie industriel, etc. Le gnie logiciel considre ainsi le logiciel comme un objet complexe. La production du logiciel implique de ce fait des environnements de dveloppement, avec toute la varit d'outils et d'approches dont on peut disposer, les mthodes et les techniques de gestion de processus, mais aussi les aspects humains au sein de l'quipe de dveloppement et les relations que celle-ci entretient avec les commanditaires et les utilisateurs du produit.
I.2. Les objectifs du GL

Les objectifs ? Comment les satisfaire ? Le logiciel est aujourd'hui prsent partout, sa taille et sa complexit augmentent de faon exponentielle, les exigences en besoins et en qualit sont de plus en plus svres. L'objectif du gnie logiciel est de dvelopper dans les dlais les logiciels de qualit. Le Gnie Logiciel se proccupe des procds de fabrication de logiciels de faon sassurer que le produit qui est fabriqu : - rponde aux besoins des utilisateurs : Fonctionnalits - reste dans les limites financires prvues au dpart : Cot - corresponde au contrat de service initial : Qualit (la notion de qualit de logiciel est multi-forme) - reste dans les limites de temps prvues au dpart : Dlai => Rgle du CQFD1 : Cot Qualit Fonctionnalits Dlai. L'utilisation dune mthodologique pour produire un logiciel s'est montre incontournable par la crise de l'industrie du logiciel (crise du logiciel). Cette crise est apparue dans les annes 70 lorsque lon a pris conscience (caractristiques de la crise du logiciel) de labsence de la matrise des projets au niveau des
1
Cf Patrice CLEMENTE
Zphyrin Soh
5 /55
cots (le cot du logiciel dpassait dj celui du matriel) et des dlais, la mauvaise qualit des produits (les produits ne rpondent pas aux besoins dfinis et des erreurs persistent dans le produit final). Ces problmes suscitent des risques humains et conomiques comme lillustrent les exemples clbres suivants : - TAURUS, un projet d'informatisation de la bourse londonienne : dfinitivement abandonn aprs 4 annes de travail et 100 millions de (livres sterling) de pertes, - Lavion C17 (1993) de McDonnell Douglas livr avec un dpassement de 500 millions de $ ... (19 calculateurs htrognes et 6 langages de programmation diffrents), - Au Cameroun, les employs de ltat ont eu un retard sur le payement de leur salaire cause dune panne du logiciel traitant les salaires au CENADI. - En 1999, les tudiants de la facult des arts, lettres en sciences humaines de luniversit de Yaound I entrent en grve cause dune erreur de calcul des moyennes sur les modules. - Les origines de lchec dAriane 5 (1996) sont lies une exception logicielle qui a provoque lautodestruction dun autre module empchant ainsi la transmission des donnes dattitude correctes (=> trajectoire erratique). - En 2007, Express Union avec le passage de la numrotation tlphonique 8 chiffres : Etait-ce vrai ? - Et de nombreuses dautres erreurs que l'on ignore Remarque : Une erreur, petite soit-elle peut tre dangereuse par exemple pour la chirurgie distance, commande temps rel de lavion, D'aprs le cabinet de conseil en technologies de l'information Standish Group International, les pannes causes par des problmes de logiciel ont cot en 2000 aux entreprises du monde entier environ 175 milliards de dollars, soit deux fois plus quen 1998 (Le Monde 23/10/01). Une autre tude mene par le mme groupe sur la conduite des projets informatiques montre le rsultat suivant :
Les rponses la crise La solution imagine pour rpondre cette crise a t lindustrialisation de la production du logiciel. Cette industrialisation vise la matrise du processus de dveloppement et dfinit pour cela des procds de fabrication de manire satisfaire les besoins des utilisateurs, la qualit du logiciel, les cots et les dlais de production. Le GL a ainsi pour principal objectif la recherche permanente des moyens pour russir matriser le dveloppement, le fonctionnement, la maintenance du logiciel. Ces moyens sont constitus de : Les modles : Un modle est une reprsentation simplifie dune ralit. Les modles sont conus avec un ensemble de concepts, dots de rgles dutilisation et de reprsentation (souvent graphiques). Ils guident le raisonnement dans lidentification des aspects pertinents du domaine quon tudie. Les langages : Ils permettent de dcrire les aspects pertinents du systme. Ils peuvent tre textuels ou graphiques, naturels ou formels. La dmarche : Elle dcoupe le processus de conception en tapes successives enchaner. Les outils : Ils constituent le support automatique ou semi-automatique pour les mthodes. Ils permettent ainsi dautomatiser partiellement ou totalement certaines phases du processus de conception. On trouve ainsi des outils daide la conception, des outils de simulation, des outils daide la vrification, etc. 6 Zphyrin Soh /55
Remarque : Les modles et les langages sont en gnral indissociables. Les modles associs aux langages et une dmarche constituent une mthode. Les techniques permettent un dveloppement cohrent en prcisant comment utiliser les mthodes et les outils. La figure ci-dessous illustre la production du logiciel sous contrle du gnie logiciel.
Nouveaux besoins Besoins changs Ou Cahier de charges
Production Logiciel
Nouveau systme ou systme modifi
Systme existant Gnie Logiciel = Mthodes, techniques, outils
Composants
I.3. Les difficults du GL

Malgr les efforts mens dans le domaine du GL, il reste encore aujourdhui moins avanc par rapport aux autres sciences de lingnieur (gnie civil, ). Le GL souffre des maux majeurs : Le logiciel est un objet immatriel (abstrait) : comment apprcier sa complexit ? Le logiciel est trs flexible, mallable au sens de facile modifier : facile de modifier une ligne de code, mais infiniment difficile de garantir que le programme continuera fonctionner correctement (que pense le nophyte ?) ; Ses caractristiques attendues sont difficiles figer au dpart et souvent remises en cause en cours du dveloppement : difficult de spcifier les besoins ; Lvolution rapide des technologies et besoins de plus en plus complexes : complexit lie lenvironnement informatique ; Le logiciel ne suse pas, il devient obsolte (par rapport aux concurrents, par rapport au contexte technique, par rapport aux autres logiciels, ...) ; Le GL est un domaine trs vaste faisant intervenir plusieurs acteurs, aspects techniques => problme de communication, organisation, => Management de projet Le niveau de formalisation du savoir-faire informatique est trs faible (=>les projets logiciels diffrent et lexprience compte beaucoup) : La jeunesse du GL La rutilisation tarde tre effective : le dveloppement par assemblage de composants est encore jeune dans le domaine logiciel (EJB, composants CORBA, .NET, ...). Cependant, grce au GL des progrs ont t raliss (compilateur C : Unix, logiciels 2D/3D, systmes embarqus, ), mais la complexit des systmes ne cesse de saccrotre. Du fait de cette complexit lie llaboration des logiciels, il est difficile quun logiciel soit exempt de dfauts.
I.4. Les logiciels et mtiers du GL

Le GL est en forte relation avec presque tous les autres domaines de linformatique : langages de programmation, bases de donnes, informatique thorique (automates, rseaux de Petri, types abstraits, ...), etc. Le GL utilise linformatique comme un outil pour rsoudre des problmes de traitement de linformation. Dans sa partie technique, le GL prsente un spectre trs large depuis des approches trs formelles (spcifications formelles, approches transformationnelles, preuves de programmes) jusqu' des dmarches absolument empiriques (dmarches qui sappuient seulement sur lexprience). Cette varit reflte la diversit des types de systmes produire : gros systmes de gestion : le plus souvent des systmes transactionnels construits autour dune base de donne centrale ; 7 Zphyrin Soh /55
systmes temps-rel, qui doivent rpondre des vnements dans des limites de temps prdfinies et strictes ; systmes distribus sur un rseau de machines (distribution des donnes et/ou des traitements) ; systmes embarqus et systmes critiques, interfacs avec un systme contrler (aronautique, centrales nuclaires, ...). Pour produire ces diffrents systmes, le GL en tant que vaste domaine faisant intervenir plusieurs acteur sappuie sur : - Informatique - Droit (PI, Travail, ) - Gestion : RH, Finances, Organisation - Sciences Sociales et Humaines : communication, formation, accompagnement, La spcialisation en GL peut se faire suivant ses diffrentes branches (mtiers du GL) : Ingnierie des besoins (requirement Engeneering) Architecte (software achitect) Programmeur (software programming) Testeur (software testing) Gestionnaire de projet logiciel (software management : people management and team organisation, quality management, cost estimation, software planing and control) Formateur (software engineering education)
I.5. La qualit du logiciel ?

La qualit est un processus qui dpasse la notion de logiciel. On peut lappliquer tout processus industriel. La difficult dapplication au niveau des logiciels rside sur le caractre abstrait et invisible du logiciel. Illustration : La qualit des beignets ? dun btiment ? Idem GL : Il fait exactement ce que javais demand, NON cest difficile dutiliser, AH cest trop lent, a consomme trop de ressource processeur, a plante tout le temps, MERDE a ne me rapporte rien, Il na pas produit le diagramme de cas dutilisation. Rappel : Le GL vise produire des logiciels de qualit. Quest ce quun logiciel de bonne qualit ? CELA DEPEND (de quoi ?) Celui qui parle de qualit (acteur qui apprcie le logiciel : utilisateur, dveloppeur, testeur, manager, ). On distingue : 1. La qualit externe qui exprime le point de vue des utilisateurs : elle peut concerner les fonctionnalits (besoins satisfaits, ), les performances (temps de rponse, ) et lergonomie (facilit dutilisation, ). 2. La qualit interne qui exprime le point de vue du technicien : Elle concerne principalement loptimisation, ladaptabilit, la rutilisabilit, lefficacit, la portabilit, Outre ces deux qualits lies au logiciel, il existe la qualit lie au cot (Business value, ROI : retour sur investissement - Si je ne gagne rien, le logiciel nest pas de bonne qualit, ) et la qualit lie au processus de dveloppement (Est-ce un dveloppement professionnel ? Est-ce que toutes les tapes de dveloppement sont menes avec succs ? Lenvironnement de travail, ). Process Quality Internal Quality external Quality
La qualit lie au cot dpend de loriginalit (fonctionnalits/services rendus) du logiciel. Remarque : Ces qualits sont parfois contradictoires et il est difficile de les satisfaire toutes. Il faut les pondrer selon les circonstances (logiciel critique/logiciel grand public, ). Il faut aussi distinguer les
Zphyrin Soh
8 /55
systmes sur mesure et les produits logiciels de grande diffusion. Privilgier une qualit en fonction de la nature du logiciel. Ce que nest pas la qualit dun logiciel : Un logiciel de qualit nest pas un logiciel sans erreur, ni un logiciel contenant des lments pour faire plaisir au client/utilisateur, ni celui contenant ce qui est la mode.
Zphyrin Soh
9 /55
Gnie Logiciel Les modles classiques de cycles de vie
Chapitre II . Les modles classiques de cycle de vie
II.1. Introduction
La notion de cycle de vie permet de caractriser les tapes successives que peut prendre un logiciel depuis sa demande jusqu sa mort. Cela couvre de la cration du logiciel sa disparition en passant par son utilisation. Le but du dcoupage du processus est de matriser les risques, matriser au mieux les dlais et les cots, obtenir une qualit conforme aux exigences. Remarque : Il ne faut pas confondre cycle de vie et cycle de dveloppement. Le cycle de dveloppement sinsre dans le cycle de vie et est abusivement appel cycle de vie. Historiquement, le modle utilis dans les premiers jours du dveloppement logiciel consistait coder et rparer ( code and fix ). Ce modle comprend deux tapes : crire un peu le code, puis amliorer et corriger les erreurs. On commence donc coder, puis on rflchit sur les besoins afin dadapter le code. Les principaux modles classiques de cycle de vie sont : le modle en cascade (waterfall), le modle en V, le modle incrmental, le modle en spirale. Tous ces modles ne sont pas les mmes, mais lide est toujours la mme : le logiciel est dvelopp en phases.
II.2. Modle en cascade

Cest le tout premier modle classique du cycle de vie. Dautres noms sont parfois donns ses phases et un dcoupage plus fin est souvent utile.
Etude prliminaire Analyse des besoins Conception dtaille Conception technique Codage Test Exploitation et maintenance
1. Etude prliminaire ou tude de faisabilit : Elle concerne la dfinition globale du problme. Il faut tudier la stratgie de lentreprise et dcide de la ncessit de fabriquer ou acheter un nouveau produit. 2. Analyse des besoins (quoi faire ?) : identifier les besoins de lutilisateur (=> produire le cahier de charges) 3. Conception dtaille (comment faire) : organiser les besoins de lutilisateur dans diffrents modules du systme, faire la description dtaille des fonctions de chaque module en vue de limplmentation. 4. conception technique (Avec quoi ?) : tudier le contexte dimplmentation (matriels, outils logiciels, ) 5. Codage : coder chaque module et le tester indpendamment des autres (test unitaires) 6. Test : Intgrer les diffrents modules et les tester dans lensemble par rapport aux besoins de
Zphyrin Soh
10 /55
lutilisateur. 7. Exploitation et maintenance : Maintenir (corrective, volutive, adaptative) le logiciel en cours dutilisation jusqu son retrait. Cest pendant cette phase que leffort de documentation est bnfique.
II.3. Modle en V
Driv du modle en cascade, le modle en V montre non seulement lenchanement des phases, mais aussi les relations logiques entre phases plus loignes : ce sont des liens de validation.
Analyse Installation et rception Intgration et tests dint Tests unitaires
Conception gnrale Conception dtaille
Implmentation
Quoi faire ? Analyse Comment faire ? Conception gnrale Comment faire par morceau ? conception dtaille Comme les phases des modles prcdents sont successives, une difficult majeure est rencontre lorsque les besoins exprims par le client ne sont pas complet au dbut du cycle. Il est alors possible de construire une maquette (prototype) qui simule le comportement du logiciel tel quil sera peru par lutilisateur.
II.4. Modle incrmental

Ici, le produit est dlivr en plusieurs fois, de manire incrmentale, cest dire en le compltant au fur et mesure et en profitant de lexprimentation oprationnelle des incrments prcdents. Chaque incrment peut donner lieu un cycle de vie classique plus ou moins complet. Les premiers incrments peuvent tre des maquettes ou des prototypes (rutilisables pour passer au prochain incrment en les compltant et/ou en optimisant leur implantation). Le risque de cette approche est celui de la remise en cause du noyau ou des incrments prcdents.
Dans le modle incrmental, chaque dveloppement est moins complexe, les intgrations sont progressives, il y a la possibilit de livraison et de mise en service aprs chaque incrment, meilleure valuation du temps et de leffort de programmation. Par contre, les risques peuvent tre la mise en cause du noyau et des incrments prcdents, lventuelle difficult dintgrer les nouveaux incrments.
II.5. Modle en spirale

Ce modle met l'accent sur l'activit d'analyse des risques. Chaque cycle de la spirale se droule en quatre phases :
Zphyrin Soh
11 /55
1. Dtermination des objectifs du cycle, des alternatives pour les atteindre et des contraintes, 2. Identification et rsolution des risques : valuation des alternatives et, ventuellement maquettage, 3. Dveloppement et vrification/validation de la solution retenue, un modle classique (cascade ou en V) peut tre utilis ici, 4. Planification, revue des rsultats et vrification du cycle suivant.
Dans le dveloppement logiciel, tout dpend des circonstances et il n y a pas de modle idal de cycle de vie. Souvent, un mme projet peut mler diffrentes approches, comme le prototypage pour les sous-systmes haut risque et la cascade pour les sous systmes bien connus et faible risque. Le modle de cycle de vie nest pas une solution universelle. Malgr toutes les prcautions prises, le processus de dveloppement peut tre boulevers par des facteurs dinstabilit. Il en existe deux principales classes : les facteurs dinstabilit externes (volution de lenvironnement, de la lgislation, de la technologie, du march et de la concurrence) et les facteurs dinstabilit internes (volution de lquipe du projet, nouvelles intgrations, ).
Zphyrin Soh
12 /55
Gnie Logiciel Introduction au processus de dveloppement
Chapitre III . Introduction au processus de dveloppement
III.1. Dfinition
UML est un langage qui a connu un succs spectaculaire dans la modlisation des systmes. Ce succs ne doit pas faire oublier quil ne sagit que dun langage de modlisation dont la vocation nest pas de couvrir tous les aspects du gnie logiciel. Les auteurs de UML sont conscients de limportance dun processus de dveloppement, mais ils reconnaissent que cela passe dabord par la disponibilit dun langage de modlisation objet performant et stable. Etant un langage de modlisation, UML ne dfinit pas un processus de dveloppement particulier. Il sert dappui pour diffrentes approches mthodologiques bases sur les objets. UML doit donc tre utilis dans le cadre dun processus de dveloppement pour quon en tire le meilleur profit. Vu la complexit croissante des systmes informatiques, les besoins de plus en plus exigeants des utilisateurs, tant au niveau des fonctionnalits que des dlais de livraison, lindustrie logicielle a besoin dun processus capable de guider les dveloppeurs. Le processus a pour but de spcifier les diffrentes phases dun projet, de llaboration du cahier de charge au dploiement de lapplication. Un processus dfinit qui fait quoi, quel moment et de quelle faon pour atteindre un certain objectif. Illustration : processus de livraison, processus dinscription, processus dachat, Dans le domaine de lingnierie logiciel, le but consiste laborer un produit logiciel ou en amliorer un existant. Un processus doit alors fournir les directives garantissant le dveloppement efficace de logiciels de qualit et prsenter un ensemble de bonnes pratiques autorises par ltat de lart. Un tel processus est indispensable et doit servir de fil conducteur tous les intervenants (client, utilisateurs, dveloppeurs et responsables). Un processus de dveloppement logiciel est un ensemble dactivits coordonnes et rgules pour transformer les besoins dun utilisateur en produit logiciel. Le processus unifi est le principal processus de dveloppement logiciel propos par les auteurs dUML.
III.2. Historique du processus unifi

Le processus unifi (UP : Unified Process) est un processus gnrique pouvant tre adapte une large classe de systmes logiciels, diffrents domaines d'application, diffrents types d'entreprises, diffrents niveaux de comptences et diffrentes tailles de projets. Il est base de composants et utilise le langage UML pour la construction du systme logiciel : UML et UP ont t dvelopp en concert. La mise au point de UP a subi diverses influences rsumes dans la figure ci-dessous :
Rational Unified Process 5.0
Rational Objectory Process 4.1 1996-1997
Autres
Approche de Rational
Objectory Process 1.0-3.8 1987-1995
UML
Approche dEricsson
Zphyrin Soh
13 /55
Gnie Logiciel Introduction au processus de dveloppement
En 1967, Ericson modlisa le systme comme un ensemble de blocs interconnects (appels soussystmes en UML et implments sous forme de composants ). La description de larchitecture consistait dcrire tous les blocs et leurs interconnections (transimission des messages). En 1987, Jacobson quitta Ericson pour fonder Objectory AB qui dveloppa Objectory Process. Plusieurs versions se sont succdes. En 1995, Rational Software Corporation ayant acquis Objectory AB, menait en son sein une approche de dveloppement base sur les notions oriente objet, abstraction, rutilisabilit et prototypage. Le fruit de lexprience de Rational et les pratiques mises en uvre se sont associes Objectery Process pour former Rational Objectory Process (larchitecture tait constitue des vues architecturales des diffrents modles). UML tait alors en cours de dveloppement et servait de langage de modlisation. Dans le mme temps, Rational se lanait dans une politique de fusion-acquisition de socits ditrices de logiciels (Raquisite, SQA, Pure-Atria, Performance Awareness et Vigortech). Chacune delle contribua, dans son champ dexpertise au dveloppement de Rational Objectory Process et ds les milieux 1998 (Juin), les diverses contributions se sont unifies et Rational lana la nouvelle version du produit, Rational Unified Process 5.0. Aujourdhui, UP est un processus gnrique de dveloppement et plusieurs varits de processus y dcoulent.
III.3. Instances du Processus Unifi

RUP : Rational Unified Process, instanciation par Rational des prceptes UP EUP : Enterprise Unified Process, instanciation intgrant les phases de post-implantation. XUP : Extreme Unified Process, instanciation hybride intgrant UP avec Extreme Programming. AUP : Agile Unified Process, partie des prceptes UP permettant lagilit du dveloppement. 2TUP : Two Tracks Unified Process, instanciation de UP propos par Valtech prenant en compte les alas et contraintes lies aux changements perptuels et rapides des SI des entreprises. EssUP : Essential Unified Process, instanciation de UP propos par Ivar Jacobson Consulting propose une mouture du processus unifi qui intgre certains concepts de la mthodes Agile.
Zphyrin Soh
14 /55
Gnie Logiciel Le Processus Unifi
Chapitre IV . Le Processus Unifi
IV.1. Introduction
Le Processus Unifi est pilot par les cas dutilisation, centr sur larchitecture et droul de manire itrative et incrmentale. La figure ci-dessous rsume les caractristiques de UP.
Cas dutilisation Architecture Itratif et Incrmental
centr sur pilot par Processus Unifi
au drou lement
Pilot par les cas dutilisation : toutes les activits, de lanalyse des besoins jusquaux tests sont guids par les cas dutilisation Centr sur larchitecture : tous les intervenants au projet de dveloppement, du chef projet au programmeur doivent saccorder sur la vision commune du systme produire : larchitecture. Elle offre une perspective claire de tout le systme, indispensable pour en matriser le dveloppement. Au droulement itratif et incrmental : lensemble du travail est divis en petites parties, qui sont autant de mini-projets. Chacun dentre eux reprsente une itration qui donne lieu un incrment. Les itrations dsignent des tapes de lenchainement des activits tandis que les incrments correspondent des stades de dveloppement du produit. Les auteurs de UP prcisent ce qui suit : Les concepts de dveloppement pilot par les cas dutilisation , centr sur larchitecture et itratif et incrmental sont dgale importance. Larchitecture fournit la structure qui servira de cadre au travail effectu au cours des itrations, tandis que les cas dutilisation dfinissent les objectifs et orientent le travail de chaque itration. Labandon de lune ou lautre de ces trois notions cls attnuerait considrablement la valeur du Processus Unifi. Comme un tabouret auquel il manquerait un pied, il seffondrerait. La figure ci-dessous matrialise les relations de dpendance entre ces concepts en vue de dvelopper un produit satisfaisant.
Processus Unifi cas dutilisation 1 2 Architecture 3 5 Produit 4 6 Itration et Incrment
1. orientent le dveloppement 2. guide la ralisation 3. sert de cadre 4. se dploie 5. ralise 6. dfinissent les objectifs
IV.2. La vie du Processus Unifi

Le Processus Unifi gre le dveloppement suivant deux axes : laxe horizontal reprsente le temps et montre le droulement du cycle de vie du processus et laxe vertical reprsente les principaux enchanements d'activits. La figure suivante reprsente le cycle de vie de UP selon les deux axes.
Zphyrin Soh
15 /55
Anne acadmiq ue 2008-2009
IV.2.1. Axe horizontal

Le Processus Unifi rpte un certain nombre de fois une srie de cycles constituant la vie dun systme. Chaque cycle se droule sur une certaine dure et sarticule en 4 phases : cration, laboration, construction et transition. Chacune delles pouvant se subdiviser son tour en itrations. Les diffrentes phases de cycle sont les suivantes : Description Traduit une ide en vision de produit fini et prsente une tude de rentabilit pour ce produit - Que va faire le systme pour les utilisateurs ? => un modle simplifi des cas dutilisation regroupant les principaux cas dutilisation. Phase de cration - A quoi peut ressembler larchitecture dun tel systme ? => architecture ou dinception provisoire, une bauche relevant les principaux sous-systmes - Quels sont lorganisation et les cots du dveloppement de ce produit ? => planifier en dtail la phase dlaboration et fournir une estimation du projet dans son ensemble. Dans cette phase doit tre identification et hirarchiser les risques majeurs Permet de prciser la plupart des cas dutilisation et de concevoir larchitecture du systme. Larchitecture doit tre exprime sous forme de vue de chacun des modles. A lissue de cette phase, le chef de projet doit tre en mesure de prvoir les activits et destimer les ressources ncessaires lachvement du projet. Phase Cette phase aboutit lmergence de la stabilit des cas dutilisation, dune dlaboration architecture de rfrence, dun plan de dveloppement et la matrise des risques pour permettre le respect du contrat. Les cas dutilisation, larchitecture et les plans sont-ils assez stables et les risques suffisamment matriss pour permettre la ralisation du dveloppement dans le respect du contrat ? Moment o lon construit le produit. Au cours de cette phase, larchitecture de rfrence se mtamorphose en produit complet, elle est maintenant Phase de stable. Le produit contient tous les cas dutilisation que les chefs de projet, construction en accord avec les utilisateurs ont dcid de mettre au point pour cette version. Celle-ci doit encore avoir des anomalies qui peuvent tre en partie
Zphyrin Soh
Phases
16 /55
Phase de transition
rsolue lors de la phase de transition. Le produit satisfait-il suffisamment aux besoins des utilisateurs pour que certains clients ladoptent avant sa sortie officielle ? Le produit est en version bta. Un groupe dutilisateurs expriments essayent le produit et rendent compte des anomalies et dfauts dtects. Les dveloppeurs corrigent les problmes signals et incorporent certaines amliorations suggres la version suivante. Cette phase suppose des activits comme la formation des utilisateurs clients, la mise en uvre dun service dassistance et la correction des anomalies constates.
IV.2.2. Axe vertical

Chaque cycle se conclut par la livraison dune nouvelle version du systme. Ce produit se compose dun corps de code source rparti sur plusieurs composants pouvant tre compils et excuts et saccompagne de manuels et de produits associs. Les diffrents modles produire pendant les activits sont les suivants : Modle/activit Modle des cas dutilisation Modle danalyse Description Expose les cas dutilisation et leurs relations avec les utilisateurs Dtaille les cas dutilisation et procde une premire rpartition du comportement du systme entre divers objets appropris Dfinit la structure statique du systme sous forme de sous-systme, classes et interfaces ; Dfinit les cas dutilisation raliss sous forme de collaborations entre les sous-systmes, les classes et les interfaces Intgre les composants (code source) et la correspondance entre les classes et les composants Dfinit les nuds physiques des ordinateurs et laffectation de ces composants sur ces nuds. Dcrit les cas de test vrifiant les cas dutilisation Description de larchitecture
Modle de conception
Modle dimplmentation Modle de dploiement Modle de test Reprsentation de larchitecture
Tous ces modles sont lis. Ensemble, ils reprsentent le systme comme un tout. Les lments de chacun des modles prsentent des dpendances de traabilit. Il est par exemple possible de remonter un cas dutilisation (dans le modle des cas dutilisation) partir de sa ralisation (dans le modle de conception) ou dun cas de test (dans le modle de test). La traabilit facilite la comprhension et les modifications ultrieures. Pour mener efficacement un cycle, les dveloppeurs ont besoin de construire toutes les reprsentations du produit logiciel.
Zphyrin Soh
17 /55
La figure du cycle de vie de UP indique les enchanements dactivits, tandis que les courbes reprsentent approximativement le degr daccomplissement des activits dans chaque phase. Une itration couvre gnralement les cinq enchanements dactivits.
IV.3. Processus pilot par les cas dutilisation

IV.3.1. Intrt des cas dutilisation
Le but principal d'un systme informatique est de satisfaire les besoins du client. La dtermination et la comprhension de ces besoins sont souvent difficiles. Les cas dutilisation (use cases) est une technique de dtermination intgre dans UML. Ils privilgient le point de vue de lutilisateur. Ils recentrent ainsi lexpression des besoins sur les utilisateurs, en partant du principe quun systme est avant tout construit pour ses utilisateurs. Les cas dutilisation ont pour objectif de comprendre et structurer les besoins des utilisateurs. Ils guident pour cela la conception, limplmentation et les tests. Cest partir du modle des cas dutilisation que les dveloppeurs crent une srie de modles de conception et dimplmentation ralisant les cas dutilisation. Chacun des modles successifs est ensuite rvis pour en contrler la conformit par rapport au modle des cas dutilisation. Enfin les testeurs testent limplmentation pour sassurer que les composants du modle dimplmentation mettent correctement en uvre les cas dutilisation. Dire que UP est pilot par les cas dutilisation signifie quil procde par une srie denchanements dactivits drivs des cas dutilisation puisque la plupart des activits (analyse, conception, implmentation et test) sont effectues partir des cas dutilisation. Les cas dutilisation guident ainsi le processus de dveloppement. La figure ci-dessous prsente le lien que les cas dutilisation nouent entre les diffrentes tapes du processus.
Analyse Conception Implmentation Test
Les cas dutilisation forment le lien

dcrit et
clarifie les cas dutilisation organise la ralisation des use cases ralise les cas dutilisation vrifie la satisfaction des cas dutilisation
Zphyrin Soh
18 /55
1.
2. 3.
4.
En rsum, UP est pilot par les cas dutilisation parce que ces derniers : permettent didentifier les vritables besoins : Un cas dutilisation est une squence dactions queffectue le systme afin de produire un rsultat satisfaisant pour un acteur particulier. Lidentification des cas dutilisation est fondamentale pour le processus unifi. Ils reprsentent les fonctionnalits que fournit le systme pour rendre service ses utilisateurs. Il faut se placer du point de vue de chaque type dutilisateur (au sens acteur) et identifier les cas dutilisation qui lui permettront de faire son travail. Il est donc indispensable de savoir quels sont les utilisateurs du systme produire. Il ne faut pas se mettre identifier les fonctions du systme sans se poser la question de savoir quels sont ceux qui les utiliseront. Cela conduit gnralement lidentification des cas inutiles ou superflus. dirigent le processus : ils aident les chefs de projets planifier, affecter et surveiller les tches effectues par les dveloppeurs. constituent un mcanisme essentiel de traabilit entre modles : il est possible de suivre lvolution dun cas dutilisation de la phase danalyse sa ralisation et travers les cas de test qui en assurent la vrification. Cette traabilit permet de prserver la cohrence du systme et de lactualiser dans son ensemble en fonction de lvolution des besoins. servent de guide pour les besoins non fonctionnels : A tout besoin fonctionnel, dlimit sous forme de cas dutilisation, peut tre associ une grande partie de besoins non fonctionnels (performance, disponibilit, scurit, ).
IV.3.2. Ralisation des cas dutilisation

Des cas dutilisation au modle danalyse Le modle danalyse a pour rle de clarifier en fournissant une spcification dtaille des cas dutilisation. Il permet une meilleure comprhension de ceux-ci. Il consiste en : 1. une tude/description dtaille des cas dutilisation lun aprs lautre ; 2. une identification des classificateurs (ainsi que leurs rles et relations) intervenant dans la ralisation de chaque cas dutilisation tudi/dcrit ; 3. la reprsentation de la collaboration entre les classes identifies, chacun jouant effectivement son ou ses rles. Le modle danalyse tient lieu de premire bauche du modle de conception, tout en tant un modle part entire. La figure ci-dessous illustre la traabilit entre un cas dutilisation et sa ralisation dans le modle danalyse. La ralisation dun cas dutilisation est reprsente par une ellipse en pointilles.
Modle de cas dutilisation Modle danalyse
traabilit
use cases
Classes participant la ralisation du cas dutilisation
Du modle danalyse au modle de conception Le modle de conception est conu en vue de limplmentation. Il est ainsi plus proche du modle dimplmentation. Toutefois, il est dabord cre partir du modle danalyse avant dtre adapt lenvironnement dimplmentation choisi. A linstar du modle danalyse, le modle de conception dfinit les relations entre les classificateurs et les collaborations ralisant les cas dutilisation. Les lments dfinis dans le modle de conception sont les quivalents des lments plus conceptuels
Zphyrin Soh
19 /55
spcifis dans le modle danalyse. Les lments du modle de conception sont plus physique (adapts lenvironnement dimplmentation) alors que ceux du modle danalyse sont plus conceptuel . La ralisation des cas dutilisation dans les diffrents modles obissent plusieurs objectifs. Les diffrentes classes participants la ralisation dun cas dutilisation dans le modle danalyse donnent lieu des classes de conception plus sophistiques, adaptes lenvironnement dimplmentation. Toutefois, la traabilit permet de remonter des classes de conception du modle de conception vers les classes danalyse du modle danalyse. On doit ainsi savoir quelles classes danalyse participent la ralisation de quel cas dutilisation, et quelles classes de conception correspondent quelle classe danalyse pour la ralisation de quel cas dutilisation.
Modle de cas dutilisation Modle danalyse
traabilit
Modle de conception
traabilit
use cases
Classes danalyse
traabilit
Classes de conception
Remarques : Gnralement, une classe du modle danalyse peut sclater en plusieurs classes du modle de conception. Du modle de conception au modle dimplmentation Dans le modle dimplmentation sont dvelopps tous les lments (composants, code sources, scripts shell, bibliothques, lments de BD, ) ncessaires la production du systme excutable. Ce sont gnralement les sous-systmes du modle de conception qui sont implments en composants avec des interfaces bien dfinies. Ces composants favorisent le dploiement dans les nuds du modle de dploiement. Limplmentation ne se borne pas au dveloppement du code ncessaire la cration du systme excutable. Les dveloppeurs chargs dimplmenter les composants doivent galement les tester unit par unit avant de les soumettre aux tests dintgration et aux tests systme.
Modle de conception Modle dimplmentation
traabilit
Sous-systmes du modle de conception
traabilit
Composants du modle dimplmentation
Tests des cas dutilisation Les tests permettent de vrifier que le systme implmente correctement sa spcification. Le modle de test est compos des cas de test et de procdures de test que lon excute ensuite pour se rassurer que le systme fonctionne comme initialement prvu. Les anomalies dtectes suite au test sont ensuite analyses afin de localiser le problme. Enfin les problmes sont hirarchiss et corrigs par ordre dimportance. Lidentification des cas dutilisation ds le dbut du processus permet de planifier trs tt les activits de test et de suggrer des cas de test utiles. Ces cas de test peuvent ensuite tre amliorer au cours de la conception , lorsquon en sait un peu plus sur la faon dont le systme excutera les cas dutilisation.
Zphyrin Soh
20 /55
Les cas dutilisation peuvent tre tests soit du point de vue dun acteur traitant le systme comme une bote noire, soit dun point de vue propre la conception ; le cas de test est alors labor pour vrifier que les instances des classes participant la ralisation du cas dutilisation font bien ce quelles doivent faire. Traabilit des cas de test : Un cas de test est reprsent par le symbole du cas dutilisation revtu dune croix.
Modle des use cases
use cases
Modle des tests

traabilit
IV.4. Processus centr sur larchitecture

IV.4.1. Intrt de larchitecture
Le rle de larchitecture logicielle est comparable celui que joue larchitecture dans la construction dun btiment. Un btiment ne peut tre construit sans plan (mme conu dans la tte pour des petits projets de construction). Du point de vue du client, un btiment forme en gnral une seule unit. Pourtant il peut tre intressant pour larchitecte de crer des dessins du btiment de diffrents points de vue. En principe, peu dtaills, ces dessins sont comprhensibles par le client. Mais, la phase de construction dun btiment implique plusieurs professionnels : maons, charpentiers, ouvriers, plombiers, lectriciens, Chacun deux a besoin de dessins techniques du btiment plus dtaills et spcialiss qui, tous doivent tre cohrents les uns avec les autres (le circuit lectrique et celui dadduction deau ne doivent pas se trouver au mme emplacement physique). Larchitecte est un expert charg dintgrer tous les aspects du btiment, mais il nest spcialiste daucun des domaines. Ce sont les concepteurs qui lui apportent tous les dtails. Une fois que les dessins architecturaux (les diffrentes vues dtailles) sont prts, les professionnels les utiliseront pour produire une image fidle du btiment. De mme quun btiment, un logiciel est vu comme une entit unique par les clients. Mme si larchitecte logiciel et les dveloppeurs prfrent le prsenter selon diffrents points de vue pour mieux en matriser la ralisation. Un logiciel vaste et complexe ncessite une architecture qui pourra conduire tous les intervenants du projet une vision commune. Cette architecture permet de : Comprendre le systme : larchitecture permet aux intervenants de comprendre avec suffisamment de dtails ce qui doit tre fait et de favoriser ainsi leur participation. En effet, les systmes dvelopper ont un comportement complexe, ils fonctionnent dans des environnements complexes (volutions technologiques) et sont de plus en plus exigeants (systmes distribus, embarqus, ). Cela devient plus complexe lorsquon sait que ces facteurs changent constamment. Organiser le dveloppement : larchitecture permet de faciliter la coordination des efforts de dveloppement et de limiter les dpendances entre groupes de dveloppeurs (sous-systmes). En effet, la dfinition explicite des interfaces dune architecture permet chaque sous-systme dvoluer de faon indpendante. Favoriser la rutilisation : larchitecture dfinit des composants appropris pour raliser le modle des cas dutilisation. Ces composants peuvent tre dvelopps, et si les dveloppeurs en trouvent dautres obissant la configuration du systme exige, il devront trouver moyen de les relier pour satisfaire les cas dutilisation. Cela rduit considrablement les dlais et les cots de construction. Faire voluer le systme : larchitecture permet au systme dtre facilement modifiable. En effet, les systmes voluent mme au cours de leur dveloppement. On doit pouvoir modifier ou ajouter de nouvelles fonctions sans se soucier des rpercutions inattendues que pourraient avoir
Zphyrin Soh
21 /55
ces changements ou sans constater deffet spectaculaire sur la conception et limplmentation existantes.
IV.4.2. Architecture et cas dutilisation

Le processus de dveloppement ne se rsume pas en un enchanement dactivits guids par les seuls cas dutilisation. Les cas dutilisation une fois raliss doivent trouver leur place dans larchitecture. Les diffrentes vues du systme construire sont ressorties dans cette architecture, qui doit prvoir la ralisation de tous les cas dutilisation. Larchitecture est influence par les cas dutilisation car le souci est dobtenir une architecture adapte limplmentation des cas dutilisation. Pour le faire, on part des cas dutilisation les plus significatifs et indispensables, ceux qui constituent le cur mme des fonctions du systme. Les cas dutilisation significatifs sont ceux qui permettent de rduire les risques les plus importants, ceux qui comptent le plus pour les utilisateurs et ceux qui aident couvrir les principales fonctionnalits. Toutefois, larchitecture ne subit pas la seule influence des cas dutilisation, elle doit prendre en compte les contraintes de ralisation (la plate-forme sur laquelle sera excut le systme, le SGBD, le SE, les protocoles de communication rseau - distribution, middleware, ). Lexprience acquise sur les travaux antrieurs se rvle galement utile pour la mise au point de larchitecture. Les cas dutilisation subissent aussi linfluence de larchitecture dj en place. Il est donc indispensable de construire dabord une architecture provisoire partir dune bonne comprhension du domaine, sans toutefois considrer les dtails des cas dutilisation. Puis on choisit quelques cas dutilisation et lon adapte larchitecture pour quelle prenne en charge les cas dutilisation considrs. On prend ensuite dautres cas dutilisation, en fonction desquels on amliore encore larchitecture, et ainsi de suite. A chaque itration, on slectionne et on implmente un ensemble de cas dutilisation afin de valider et si ncessaire damliorer larchitecture. Les cas dutilisation contribuent, par consquent lamlioration progressive de larchitecture au fur et mesure quon sachemine vers le systme complet. Les cas dutilisation et larchitecture doivent volus en parallle et cette dernire doit avoir la capacit de raction aux futurs changements et la rutilisation.
IV.4.3. Construction de larchitecture

Architecture et patterns darchitecture Larchitecture est mise au point par itrations successives, essentiellement pendant la phase dlaboration. La phase dlaboration dbauche sur une architecture de rfrence. Lon doit dfinir et dcider des diffrents standards respecter, des logiciels systmes et middleware utiliser, des systmes existants rutiliser et des besoins en matire de distribution. Aprs tout cela, il est produit les premires versions des diffrents modles (cas dutilisation, analyse, conception, ). Cet ensemble de modles (que comportera le systme la fin de la phase de construction) constitue larchitecture de rfrence (la version interne du systme telle quelle existe la fin de la phase dlaboration). Elle donne un squelette du systme et est obtenu partir des cas dutilisation significatifs. A travers elle, les diffrents acteurs ont un aperu du systme et peuvent dj y ragir. Chaque modle faisant partie de larchitecture de rfrence reprsente la version du modle mise au point la fin de la phase dlaboration. Chacun doit merger vers la version complte destine au client. Les diffrents modles ne sont pas dvelopps indpendamment les uns des autres. Par exemple une modification dans le modle de dploiement visant satisfaire les exigences de performance est susceptible de conduire des remaniements dans le modle des cas dutilisation, si ces changements ncessitent de modifier certains cas dutilisation : dpendances de traabilit entre diffrents modles. Toutefois, larchitecture de rfrence ne se limite pas aux lments de modles. Elle comprend galement une description de larchitecture. En ralit, cette description slabore au fur et mesure (et parfois mme en amont) des activits qui donnent naissance aux versions des modles faisant partie de larchitecture de rfrence. Le rle de la description de larchitecture consiste guider lquipe de 22 Zphyrin Soh /55
dveloppement tout au long de la dure de vie du systme et non seulement pour les itrations du cycle en cours. Cette description doit tre stable et est un standard suivre par les dveloppeurs prsents et ceux venir. La mise au point dune architecture pour un systme particulier revient crer quelque chose de nouveau. Dautre part il existe de nombreuses solutions gnriques darchitecture : les patterns darchitecture. Il en existe aussi pour la conception : les patterns de conception. Un pattern est dfinit comme une solution un problme rcurrent de conception . Les patterns darchitecture les plus utiliss sont : Le pattern Broker : mcanisme gnrique de gestion de la distribution des objets. Les objets distribus communiquent par lintermdiaire dun broker de faon transparente (lobjet appelant na pas besoin de savoir si lobjet appel est distant ou non). Les pattern client-serveur (3-tiers), Peer-to-peer : facilitent la conception du systme au dessus du matriel. Ils dfinissent une structure pour le modle de dploiement et suggrent le mode daffectation des composants sur les nuds. Le pattern Couches (Layers) : dfinit lorganisation du systme en couches, selon laquelle les composants dune couche ne peuvent faire rfrence quaux composants de la couche situe immdiatement au-dessous. Remarque : On peut utiliser plusieurs patterns darchitecture au sein dun mme systme et il peut arriver quun pattern prdomine sur les autres. Description de larchitecture Larchitecture de rfrence survit sous la forme dune description de larchitecture. Cette description peut revtir diverses formes et contient des extraits (ou vues) des modles de larchitecture de rfrence, qui seront actualiss au gr de lvolution du systme et de lenrichissement des modles dans les phases plus tardives (aprs la phase dlaboration). La description de larchitecture sera actualise tout au long du processus de dveloppement, afin de reflter les changements et ajouts pertinents sur le plan architectural. Pendant que les diffrents modles de larchitecture de rfrence sont modifies en raction aux divers changements, la description de larchitecture nest pas ncessaire dtre toffe, elle doit simplement tre actualise pour rester pertinente. La description de larchitecture doit galement : intgrer les besoins significatifs sur le plan architectural qui ne sont pas dcrit dans les cas dutilisation. Par exemple la rpartition, les terminaux/quipements en jeu, contenir une brve description de la plate-forme, des systmes existants et protocoles utiliser, Exemple de Java RMI pour la distribution des objets, .NET, EJB ou Fractal pour le modle de composants, dcrire les outils mettant en uvre les mcanismes gnriques. Par exemple les mcanismes de stockage et rcupration travers les SGBD, les mcanismes de journalisation, de reprise aprs panne, de substitution de nuds, de rpartition de charges (entre serveurs ou processus), dcrire tous les patterns darchitecture auxquels on aura eu recours. La description de larchitecture doit susciter les ractions des participants au dveloppement. Ces ractions doivent faire lobjet de discussions, tre analyses et finalement tranches. La description de larchitecture doit tre suffisamment dtaille (prsenter de faon comprhensible tout ce qui est susceptible dintresser lun ou lautre des participants pour effectuer son travail), sans toutefois prtendre lexhaustivit. Cest une feuille de route et non une spcification complte du systme. Il ne faut pas garer les participants dans les dtails inutiles sur le plan architectural. Gnralement, moins de 10% des cas dutilisation et classes sont pertinents pour larchitecture. Les auteurs de UP estiment que la taille dune description architecturale pour des systmes une seule application est variable (pas une rgle absolue) et doit comprendre de 50 100 pages. Larchitecte cre larchitecture en compagnie de quelques dveloppeurs. Les dveloppeurs savent ce quils ont mettre en uvre et cest larchitecte de choisir les patterns darchitecture, les systmes
Zphyrin Soh
23 /55
existants et organiser les dpendances entre sous-systmes et faon viter un fort couplage entre eux (les changements intervenants dans un sous-systme ne doivent pas se rpercuter sur plusieurs autres soussystmes). Le vritable objectif tant de rpondre aux besoins de lapplication en utilisant les meilleurs moyens disponibles dans ltat actuel de la technologie, larchitecte doit avoir connaissance (en plus de lexprience acquise des projets antrieurs) : - du domaine dans lequel il travaille : il doit tre suffisamment inform pour collaborer avec tous les intervenants et non pas seulement avec les dveloppeurs ; - du dveloppement logiciel : il doit connatre jusqu lcriture du code car il doit communiquer larchitecture aux dveloppeurs et comprendre leurs ractions. Larchitecte occupe donc un poste dlicat dans lquipe de dveloppement. Il cre larchitecture, assure sa maintenance et veille son application (vrification et validation). Il peut tre ncessaire davoir recours un plusieurs architectes pour dvelopper une architecture dans le cadre dun projet. Il est important de consacrer du temps pour produire une architecture stable car cela guide les autres phases de dveloppement et la dure totale de dveloppement dcroit nettement lorsquune architecture stable est dveloppe.
IV.5. Processus itratif et incrmental

IV.5.1. Cest quoi itratif et incrmental ?
Un projet logiciel stend sur plusieurs mois, voire sur une anne ou plus. Pour tre efficace, le processus logiciel doit uvr pour une stratgie de dveloppement par petite tapes facile grer : - On planifie un peu ; - On spcifie, on conoit et on implmente un peu ; - On intgre, on teste et on excute le peu implment. Lensemble de ces points constituent une itration destine raliser une partie du projet (mini-projet). Le processus de dveloppement parcourt alors chaque phase par une srie ditrations, chacune donnant lieu un incrment. Lensemble des itrations dune phase concourent atteindre les objectifs de cette phase. Pour cela, il est indispensable de contrler les itrations. Une itration sachve par un jalon qui se dfinit par un ensemble dartefacts. Artefact : information cre, modifie et utilise par les travailleurs (une personne ou une quipe) dans la ralisation de leur activit. Il peut tre un modle, un lment de modle, un document, Bref un travailleur ralise des activits et produit un ensemble dartefacts. Jalons : Ce sont des points de synchronisation o sont atteints des objectifs prcis, o sont contrls (vrifis et valids) le dveloppement et o sont prise des dcisions importantes. Jalon majeur : jalon de fin de phase. Prise de dcision de poursuivre ou non la phase suivante du processus de dveloppement. Jalon mineur : jalon intermdiaire entre deux jalons majeurs. a peut tre la fin ditration. En gros, les jalons permettent : - Aux chefs projets de prendre un certain nombre de dcisions cruciales avant de passer la phase suivante du dveloppement ; - Aux dveloppeurs et autres responsables de surveiller eux-mmes la progression du travail ; - Evaluer les besoins en terme de dlai et de personnel, de contrler lavancement par rapport aux projections. Quest ce quune itration ? Une itration est un droulement plus ou moins complet des principaux enchanements dactivits, aboutissant une version livre en interne. Lenchainement principal dactivits est constitu de besoins, analyse, conception, implmentation et test. Cet enchanement dfinit un canevas pour la description denchainements dactivits ditration. Les itrations parcourent les cinq activits principales en dbutant
Zphyrin Soh
24 /55
par la planification et sachvent par une valuation : chaque type ditration rutilise sa faon les descriptions des enchanements principaux dactivits. En effet, les dfis auxquels sont confronts les dveloppeurs diffrent dans chaque phase. Les premires itrations sattachent la comprhension du problme et de la technologie. - Dans la phase de cration, les principaux objectifs des itrations consistent dlimiter la porte et le rle du produit, rduire les risques majeurs (les plus srieux) et produire une premire tude de rentabilit dmontrant la viabilit commerciale du projet. Le jalon majeur est ltablissement des objectifs du cycle de vie du projet. - Les principaux objectifs de la phase dlaboration consistent crer larchitecture de rfrence, saisir lessentiel des besoins et rduire les risques de moindre gravit. A lissu de cette phase, on est en mesure destimer les cots, de prvoir le calendrier de dveloppement et de planifier en dtail la phase de construction. On peut donc faire une offre. - La phase de construction a pour principaux objectifs le dveloppement du systme complet et de sassurer que le produit peut commencer tre utilis par les clients. Le jalon est que le produit atteigne une capacit oprationnelle initiale. - Les principaux objectifs de la phase de transition consistent sassurer que lon dispose dun produit prt tre livr lensemble des utilisateurs, qui sont forms ce moment lutilisation du logiciel. Dans les premires phases, un incrment ne constitue pas ncessairement un additif. Dans les phases suivantes, les incrments ne sont gnralement que des additifs successifs qui finissent par constituer la version du produit destine au client (version externe). Chaque itration fait lobjet dune valuation son terme. Lun des objectifs de cette valuation consiste dterminer si de nouveaux besoins sont apparus ou si des besoins existants ont subi des modifications susceptibles daffecter les itrations ultrieures. Avant de terminer une itration, il faut se rassurer quaucune partie du systme qui fonctionnait dans les itrations prcdentes na t endommage. Do limportance capitale des tests de non-rgression dans le dveloppement itratif et incrmental car chaque itration produit un rsultat qui sajoute lincrment prcdent et entrane un certain nombre de changements. Test de non-rgression : Fait de tester de nouveau une partie ou la totalit dune construction dj teste lors des constructions prcdentes. Elles servent essentiellement vrifier quune ancienne fonction d anciennes constructions fonctionne toujours lorsquest ajoute une nouvelle fonction dans une nouvelle construction . Si toutes les itrations parcourent tous les enchanements dactivits des besoins, de lanalyse, de la conception, de limplmentation et des tests, chacune insiste sur diffrents points selon la phase aborde (voir les courbes indicatives du cycle de vie). Au cours des phases de cration et dlaboration, les efforts se portent essentiellement sur lexpression des besoins, ainsi que sur lanalyse et la conception prliminaire, tandis que lon insiste surtout, dans les phases de construction et de transition, sur la conception dtaille, limplmentation et les tests. Planifier et squencer les itrations Les itrations doivent tre slectionnes et menes bien de faon planifie. Une itration prend en compte un certain nombre de cas dutilisation. A chaque itration les dveloppeurs identifient et spcifient les cas dutilisation pertinents, crent une conception en se laissant guid par larchitecture choisie, implmentent cette conception sous forme de composants et vrifient que ceux-ci sont conformes aux cas dutilisations. Ds quune itration rpond aux objectifs qui lui sont fixs, le dveloppement peut passer litration suivante. Dans lapproche en cascade, tout le projet est planifi lavance et cette planification repose sur une grande part dincertitude. En itratif, le projet nest pas tout planifi en dtail au cours de la phase de cration. Pendant les deux premires phases, il existe un plan de travail qui nentre pas dans les dtails : la phase de construction et de transition ne peuvent pas tre planifie sans la mise en place dune base solide la fin de la phase dlaboration. En principe (sauf au dbut du projet), la planification prend en compte
Zphyrin Soh
25 /55
les rsultats des itrations prcdentes. A la fin de la phase dlaboration, on dispose dune base permettant de planifier le reste du projet et davancer un plan dtaill pour chaque itration de la phase de construction. Le plan de la premire itration sera trs clair. Celui des itrations suivantes comportera moins de dtails, sera sujet dventuelles modifications et reposera sur les rsultats des itrations prcdentes. De mme, on devra disposer dun plan de la phase de transition qui sera susceptible de changer selon les rsultats des itrations de la phase de construction. Cette planification permet de mener un dveloppement itratif contrl. Elle tente dordonner les itrations de faon tracer une voie directe entre itrations. Lobjectif tant de trouver une squence ditrations qui permette daller de lavant, sans jamais avoir revenir aux rsultats dune itration antrieure pour reprendre le modle en fonction des connaissances issues dune itration plus tardive. Les itrations successives exploitent les artefacts de dveloppement dans ltat o les a laiss litration prcdente et les enrichissent progressivement. Une itration nest donc pas une entit totalement indpendante : cest une tape dun projet. Les qualifier de mini-projets cest parce quelles ne satisfont pas entirement les besoins initiaux des utilisateurs. En outre, chacun de ces miniprojets sapparente au modle en cascade, car il met en uvre les activits de ce type de modle. Les itrations peuvent se chevaucher dans le sens o une itration dbute alors que la prcdente est sur le point de sachever. Cependant, il ne faut pas que ces chevauchements aillent trs loin, car une itration constitue toujours le fondement de litration suivante. Lordre dans lequel sont prvues les itrations dpend largement des facteurs techniques. Lobjectif tant dorganiser de sorte que les dcisions les plus importantes (celles permettant de grer les risques techniques cest--dire concernant les nouvelles technologies, les cas dutilisation, larchitecture) soient prises trs tt. Les itrations contribuent planifier, organiser, surveiller et contrler le droulement du projet. Elles prsentent chacune leurs propres besoins en termes de ressources humaines, financement, calendrier, Cest travers elles que les dveloppeurs recherchent lquilibre entre les cas dutilisation et larchitecture.
IV.5.2. Intrt du dveloppement itratif et incrmental

Le dveloppement itratif et incrmental permet datteindre les jalons majeurs et mineurs qui permettent de matriser le dveloppement. Il aide : - rduire les risques : Plus le risque est identifi tardivement, plus il est de nature menacer tout le projet. Les risques graves sont identifis dans les deux premires phases (cration et laboration) et grs le plus tt possible au moyen des itrations. Tous les risques peu srieux sont traits par ordre dimportance ds le dbut de la phase de construction. - obtenir une architecture robuste : Lobtention dune architecture robuste est le rsultat des itrations menes dans les premires phases du processus. On stabilise ainsi larchitecture un niveau de rfrence trs tt dans le cycle de vie, lorsque les cots sont encore faibles et que les dlais de livraison restent un horizon lointain. - grer les exigences de changement : il est plus productif de faire voluer un produit travers une srie de constructions. Une construction est une version oprationnelle dune partie dun systme faisant la dmonstration dun sous-ensemble des fonctions du systme. Les itrations permettent dobtenir une srie de constructions pour approcher progressivement le rsultat prvu. Le fait de disposer dun systme en tat de fonctionnement partiel ds les premires phases permet aux utilisateurs et aux intervenants de suggrer des amliorations et de signaler les besoins ayant pu tre ngligs : les ajouts, modifications des exigences et leur intgration sont aisment ralisable sans impact (budget et calendrier), car ne reprsentent quun changement incrmental. Un incrment est une partie modeste du systme constituant lcart entre deux constructions successives. Dans le modle en cascade, les utilisateurs ne voient aucun systme en tat de fonctionnement avant lintgration et les tests : un moindre changement entrane les rallonges budgtaires et temporelles. - parvenir une intgration continue : Etant donne la livraison frquente des constructions, les itrations produisent des rsultats indiquant trs prcisment ltat davancement du projet. Cela
Zphyrin Soh
26 /55
(limplmentation qui dbute trs tt) permet de mettre jour trs tt les problmes. Par contre, labsence de lintgration continue, il est probablement possible que la tche la plus ardue reste venir. En cascade par exemple, les dveloppeurs ne dbutent pas limplmentation avant davoir finalis lexpression des besoins, lanalyse et la conception : les problmes demeurent, un niveau trs bas jusqu lintgration et les tests qui les rvlent en bloc. Cette intgration ayant lieu proche de la date de livraison et relevant une panoplie de problmes, lampleur de ces derniers et linvitable prcipitation qui rgne ce stade signifient que la plupart des corrections ne seront pas srieusement prpares. Ce qui provoque ncessairement une livraison au-del de la date prvue. En plus, le produit risque dtre difficile maintenir. - accder trs tt la connaissance (assistance lapprentissage et lacquisition dexprience) : Aprs une ou deux itrations, tous les membres de lquipe se font une ide assez claire de la nature des diffrents enchanements dactivits. Ils en apprennent tt et toute la suite leur sera mieux abordable car ce sont les mmes activits qui seront menes diffrentes phases. Lintgration de nouveaux collaborateurs est assez aise. Ils parcourront toutes les activits comme sils intgraient le projet son dbut. Sils commettent une erreur, celle-ci ne met pas en pril la progression long terme du projet, puisquelle apparat ds la tentative de construction suivante. Le problme dorganisation se gre progressivement car lquipe de dveloppement stoffe au fur et mesure que le projet avance : lquipe dorigine est optimis et ce noyau de lquipe peut guider les nouveaux venus au rythme de leur arrive. En dveloppant par phase et par itration, les dveloppeurs ont de meilleurs chances de satisfaire les besoins rels des clients, de rduire les risques, dobserver le niveau de progression, de rduire les difficults tardives (qui raccourci le dlai). Cette approche est aussi bnfique aux utilisateurs qui peuvent prendre la mesure de vritables progrs en prenant acte des itrations acheves.
IV.5.3. La rduction des risques

Un risque est un facteur, un phnomne ou un lment constituant un danger (une exposition) pouvant conduire une perte ou un dommage. Il met en danger, voire compromet totalement la russite dun projet : retard de calendrier, dpassement de budget, annulation du projet. Lapproche itrative est guide par la rduction des risques. Les cas dutilisation sont identifis, hirarchiss et mens en fonction des risques et de leur ordre dimportance. Lobjectif tant didentifier et de traiter les risques le plus tt possible. Toutefois, il est ncessaire de mener lexploration des risques dans les itrations tout au long du cycle de dveloppement jusquau codage et aux tests. En effet, certains risques relvent des performances, de la fiabilit, de la disponibilit et de la portabilit. Beaucoup de ces risques napparaissent pas tant que le logiciel mettant en uvre les fonctions sous-jacentes na pas t implment et test. Il est important de noter que les risques techniques peuvent tre attnus par les cas dutilisation (si le cas dutilisation est ralis avec tous ces besoins fonctionnels et non fonctionnels). Ils sont regroups en catgorie et peuvent tre lis : Aux nouvelles technologies : par exemple le problme de dpendance aux techniques qui ne sont pas encore au point (ou mres) : reconnaissance du langage naturel, technologies du web, nouveau protocole rseau, A larchitecture : ce sont les plus importants. La difficult de prise en compte des changements (adaptation, volution), dintgration des composants rutilisables, peuvent surgir si on na pas obtenu au terme de la phase dlaboration une architecture robuste. A la construction du systme attendu : cette catgorie de risque souligne limportance de lidentification des besoins qui revient trouver les bons cas dutilisation. Sinon le systme ne sera pas capable de satisfaire ses missions et dassister les utilisateurs qui lemploient. Il est fondamental de dterminer trs tt quelles sont les fonctions les plus importantes et de sassurer quelles sont rapidement implmentes. Lordre dans lequel sont traits les cas dutilisation, au moment de leur slection est fonction du degr et du type de risque quils prsentent. Par exemple lexcution mme dun cas dutilisation peut entraner des risques. Aux performances : il peut tre ncessaire de prvoir quun cas dutilisation aura un temps de 27 Zphyrin Soh /55
rponse bien dfinit, Il est ncessaire que les intervenants du projet examinent le systme raliser, dressent les listes des problmes susceptibles de se produire et programment des runions didentification des risques. Non pas pour rsoudre les problmes mais pour les identifier et tablir lordre dans lequel ils seront tudis plus en dtails et rsolus. Risques techniques : ceux lis des artefacts dingnierie et des aspects tels que les technologies dimplmentation, larchitecture ou les performances. Risques non techniques : ceux lis des artefacts de gestion et des aspects tels que les ressources disponibles (humaines), leurs comptences ou les dates de livraison de leurs travaux. Les risques non techniques sont ceux identifier et carter par les responsables : Implmenter certaines parties du systme dans un langage quon dcouvre seulement ; Le calendrier propos par le client semble trop serr et ne pourra tre tenu que si chaque tape se droule sans moindre problme ; Le respect du calendrier propos est conditionn par la livraison aux dates prvues, de soussystmes (composants) dvelopps par des sous-traitants ; Il est possible que le client ne puisse pas toujours donner son approbation dans les dlais fixs. Une fois les risques identifis et hirarchiss, lquipe doit dcider du traitement appliquer chacun dentre eux. En gnral, quatre attitudes peuvent tre adoptes : - Evitement : certains risques peuvent tre vits en rvisant la planification du projet ou en modifiant les exigences ; - Confinement : la porte de certains risques peut tre rduite de faon naffecter quune petite partie du projet ou du systme ; - Surveillance : certains risques sont rebelles toute tentative de rduction. Il ne reste qu les surveiller et regarder sils se matrialisent. Dans ce cas, lquipe doit appliquer ses plans de secours (plan dcrivant la conduite adopter au cas o certains risques se matrialiseraient). Si cest un risque tueur de projet , cette tape, linvestissement temporel et financier reste encore timide et lquipe doit se rjouir davoir dtect un tel risque avant dimpliquer tous les dveloppeurs dans le projet. Certaines solutions exigent gnralement une rvision du planning, tandis que dautres peuvent ncessiter la construction dun lment permettant de mettre jour ce risque. Dans tous les cas, on ne peut traiter tous les risques la fois. Do la hirarchisation des itrations qui guide la rduction des risques.
Zphyrin Soh
28 /55
Gnie Logiciel Les principaux enchanements dactivits
Chapitre V . Les principaux enchanements dactivits
Une fois compris les concepts qui sous-tendent le Processus Unifi, nous allons dcrire chacun des enchanements dactivits.
V.1. Comprhension du contexte du systme

Il est indispensable de comprendre le contexte du systme laide dun modle du domaine. Ce modle saisit les classes les plus pertinentes dans le domaine du systme. Ces classes sont lensemble de ce qui existe ou des vnements qui se produisent dans lenvironnement au sein duquel fonctionne le systme. On les retrouve en gnral en interviewant les experts du domaine. Le modle du domaine est dcrit par les diagrammes de classes. Il illustre pour les clients, les utilisateurs et les dveloppeurs les classes du domaine et la faon dont elles sont lies par des relations dassociation. La modlisation du domaine est effectue par les analystes comptents en matire de modlisation qui on associe les experts du domaine. Lobjectif tant de comprendre et de dcrire les classes essentielles dans le contexte du domaine contribuant une meilleure comprhension du contexte du systme et du problme quest cens rsoudre le systme par rapport son contexte. Remarques : Pour ne pas encombrer le modle du domaine, certaines classes moins pertinentes peuvent tre dcrites dans un glossaire. En gros, le glossaire et le modle du domaine offre aux intervenants un vocabulaire commun, indispensable au partage de connaissances. Cela vite les confusions et les ambiguts. Certains lments du domaine peuvent avoir une reprsentation directe dans le systme. Il ne faut pas se proccuper dans le modle du domaine spcifier les dtails de cette reprsentation. Il ne faut pas se mettre aller en dtails dans la gestion des comptes des clients (un client a plusieurs comptes ou un compte appartient plusieurs clients, ). Le glossaire et le modle du domaine sont trs utiles au moment de llaboration du modle des cas dutilisation et du modle danalyse. Une fois le domaine du systme compris travers le modle du domaine, les paragraphes qui suivent parcourent les enchanements dactivits principaux des besoins aux tests.
V.2. Expression des besoins

V.2.1. Prsentation
Le principal objectif de lexpression des besoins est llaboration dun modle du systme construire. Lemploi des cas dutilisation constitue un excellent moyen de procder la cration de ce modle car les besoins fonctionnels sont naturellement structurs comme des cas dutilisation. Par ailleurs, les besoins non fonctionnels lis un cas dutilisation sont traits dans le cadre de ce dernier. Les autres besoins non fonctionnels (communs une partie ou la totalit des cas dutilisation) sont traits dans un document part et dsign sous le noms dexigences supplmentaires. Exemples dexigence supplmentaires : Exigence de plate-forme matrielle : PC Pentium, Contraintes de plate-forme logicielle : SE clients (Win NT), SE serveurs (Linux, Solaris) Contraintes de formats de fichiers : prise en charge des noms de fichiers longs, Autres exigences : scurit (la transaction doit tre sre et seules les personnes autorises doivent accder aux informations), disponibilit (le service de facturation ne doit pas tre indisponible plus dune heure par mois), Les besoins se capturent principalement au cours des phases de cration et dlaboration (voir 29 Zphyrin Soh /55
cycle de vie UP). La description de lenchanement dactivits des besoins sarticule autour : - Des artefacts cres dans lenchanement dactivits des besoins ; - Des travailleurs prenant part cet enchanement dactivits ; - Dune vision plus dtaille de chaque activit de lenchanement dexpression des besoins. Le figure ci-dessous donne les diffrents travailleurs ainsi que les artefacts dont ils sont responsables. Remarque : Les symboles spciaux sont utiliss pour la plupart des artefacts : ceux reprsentant des documents sont dsigns par un symbole de document, tandis que les modles et lments de modles utilisent les symboles UML qui les identifient.
Analyste systme responsable de Spcificateur de cas dutilisation responsable de Concepteur dinterface utilisateur responsable de Architecte
responsable de
Modle de cas dutilisation
Acteur
Glossaire
Cas dutilisation
Prototype dinterface utilisateur
Description de larchitecture
V.2.2. Les artefacts

a) Modle des cas dutilisation : Cest le principal artefact de lexpression des besoins. Il permet de parvenir un accord entre le client et les dveloppeurs sur les besoins cest--dire les conditions que le systme doit respecter et les possibilits quil doit offrir. Il sert de contrat et fournit les entres pour lanalyse, la conception et les tests. Un modle de cas dutilisation contient les acteurs, les cas dutilisation et les relations quils entretiennent les uns avec les autres. Si ce modle est important en taille, il faut y introduire les paquetages afin de mieux le grer. b) Acteur : Le modle de cas dutilisation dcrit lutilit du systme pour chaque type dutilisateur. Les acteurs sont les rles des utilisateurs ou systmes externes avec lequel dialogue le systme. Une fois tous les acteurs du systme identifis, on a identifi lenvironnement externe du systme. Remarque : Attention didentifier de faux acteurs (par exemple ceux qui ninteragissent pas directement avec le systme, mais par un intermdiaire). A chaque fois quun acteur dialogue avec le systme, cest linstance correspondante de lacteur qui joue le rle de cet acteur. Linstance dun acteur est un utilisateur (ou un systme) spcifique dialoguant avec le systme. c) Cas dutilisation : Chaque usage que les acteurs font du systme est reprsent par un cas dutilisation. Un cas dutilisation spcifie une squence dactions que le systme peut effectuer en dialoguant avec les acteurs. d) Description de larchitecture : La description architecturale contient une vue architecturale du modle des cas dutilisation. Cette vue doit inclure les cas dutilisation significatifs pour larchitecture, cest--dire ceux stratgiques ou impliquant certaines exigences fondamentales qui doivent tre prises en charge au dbut du cycle de vie du logiciel. e) Glossaire : Il permet de dfinir les termes quutilisent les analystes (et les autres dveloppeurs) pour dcrire le systme. Ceci permet aux intervenants de parvenir un consensus sur la dfinition des divers concepts et notions, en limitant les risques de malentendu. f) Prototype dinterface utilisateur : Les prototypes dinterface utilisateur contribuent au cours de lexpression des besoins, faciliter la comprhension et la spcification des interactions entre acteurs et le systme.
Zphyrin Soh
30 /55
V.2.3. Les travailleurs

a) Analyste systme : Il est le responsable de lensemble des besoins modliss en tant que cas dutilisation. Il est charg de dlimiter le systme, didentifier les acteurs et les cas dutilisation et de sassurer que le modle de cas dutilisation est la fois complet et cohrent. Il peut donc avoir recours au glossaire pour le respect de la cohrence. Bien qutant responsable de lensemble des cas dutilisation, il nest pas responsable de chaque cas dutilisation particulier, car cela est confi aux spcificateurs de cas dutilisation. b) Spcificateur de cas dutilisation : Il est responsable de la formulation dun ou de plusieurs cas dutilisation. Il doit travailler en troite collaboration avec les utilisateurs rels des cas dutilisation dont il a la charge. c) Concepteur dinterface utilisateur : Il est charg de dessiner laspect visuel de linterface utilisateur dun ou de plusieurs acteurs. Cette tche peut ncessiter la cration de prototype dinterface utilisateur pour certains cas dutilisation. d) Architecte : Il a la responsabilit de dcrire la vue architecturale du modle des cas dutilisation.
V.2.4. Enchanement dactivits

Lenchanement dactivits des besoins peut se rsumer par le diagramme dactivits cidessous.
Identifier les acteurs et les cas dutilisation Structurer le modle des cas dutilisation
Analyste systme
Architecte
Assigner un ordre de priorit aux cas dutilisation
Spcificateur de cas dutilisation
Dtailler un cas dutilisation
Concepteur dinterface utilisateur
Prototyper linterface utilisateur
Ce diagramme matrialise la rpartition des activits entre les divers intervenants. Chaque activit est reprsent par un engrenage et plac dans la zone du travailleur charg de leffectuer. Lexcution de ces activits conduit la cration, puis la modification de divers artefacts. Lenchanement dactivits est ordonn de sorte que chacune delle produise un rsultat qui servira de point de dpart lactivit suivante. Remarque : Lenchanement ci-dessus ne prsente quun flux logique. Dans la ralit, il nest pas indispensable de mener ces activits de faon squentielle pour aboutir au mme rsultat. On pourrait par exemple commencer par identifier certains cas dutilisation (activit identifier les acteurs et les cas dutilisation ), puis concevoir linterface utilisateur (activit prototyper linterface utilisateur ) avant de sapercevoir quil convient dajouter un autre cas dutilisation (retour sur lactivit identifier les acteurs et les cas dutilisation ), et ainsi de suite. Une activit peut ainsi tre reprise plusieurs fois, chacun de ces passages naboutissant qu la ralisation partielle de lactivit. Toutefois, les activits doivent suivre un enchanement logique et lexcution dune activit doit utiliser les rsultats issus de lactivit prcdente comme point de dpart. 31 Zphyrin Soh /55
Les activits effectus sont les suivantes : 1. Identifier les acteurs et les cas dutilisation : Cette activit permet de dlimiter le systme par rapport son environnement, de faire apparatre les lments (acteurs) interagissant avec le systme, les fonctionnalits (cas dutilisation) attendues du systme, de saisir et de dfinir dans un glossaire les termes essentiels la cration de descriptions dtailles des fonctionnalits du systme.
Analyste systme
Modle du domaine Exigences supplmentaires
Acteur Modle des cas dutilisation [esquisse]
Identifier les acteurs et les cas dutilisation
Liste des fonctionnalits
Glossaire
- Identifier les acteurs : Lorsquil existe un modle de domaine, lidentification des acteurs est presque directe. Dans le cas contraire, lanalyste systme doit identifier, avec laide du client les utilisateurs du systme et tenter de les rpartir en diffrentes catgories reprsentant les acteurs. Deux critres sont applicables pour identifier les acteurs pertinents : (1) il doit tre possible didentifier au moins un utilisateur susceptible dincarner lacteur propos ; (2) viter le chevauchement entre les rles (si plusieurs acteurs ont peu prs le mme rle, il est prfrable de regrouper ces rles en un ensemble unique pris en charge par un seul acteur, soit de trouver un autre acteur plus gnral auquel sont attribus les rles communs ces diffrents acteurs). - Identifier les cas dutilisation : Elle peut se faire par le biais des rencontres entre client et ses utilisateurs et lentretien entre lanalyste systme et ces derniers. Lanalyste systme examine les acteurs un par un et propose les cas dutilisation de chacun. Lacteur a le plus souvent besoin des cas dutilisation pour effectuer les tches consistant crer, modifier, supprimer, tudier les objets mtier. Il en a galement besoin pour informer le systme de certains vnements externes ou dtre informer par le systme de la survenue dun vnement donn. Dautres acteurs peuvent assurer la surveillance, ladministration ou la maintenance du systme. Il convient de bien dlimiter la porte des cas dutilisation en gardant lesprit quun cas dutilisation doit tre facile modifier, tester et grer en tant qu unit individuelle . Un cas dutilisation doit rendre service lacteur, livrer un rsultat observable et satisfaisant aux attentes de ce dernier et lui permettre datteindre un objectif. Le nom dun cas dutilisation commence gnralement par un verbe et doit reflter la nature de linteraction entre lacteur et le systme. - Dcrire brivement chaque cas dutilisation : Il faut accompagner chaque cas dutilisation des explications (les notes et ce que le systme a besoin de faire lors des interactions avec ses acteurs). - Dcrire le modle de cas dutilisation comme un tout : llaboration des diagrammes et les descriptions permet dexpliquer le modle de cas dutilisation comme un tout et dexaminer les relations que les cas dutilisation entretiennent entre eux dune part, et avec les acteurs dautres part. La mise au point dun glossaire offre un moyen pratique de rester cohrent lors de la description parallle de plusieurs cas dutilisation. Remarque : A la fin de cette activit, les personnes extrieures lquipe de dveloppement (utilisateurs, clients, ) sont invits dterminer si tous les besoins fonctionnels ont t exprims sous forme de cas dutilisation ; - la squence dactions de chaque cas dutilisation est correcte, complte et comprhensible ; - des cas dutilisation sans vritable intrt ont t identifis (=> les rexaminer). 2. Dfinir un ordre de priorit pour les cas dutilisation : Il faut identifier quelles sont les cas dutilisation quil faut dvelopper (analyser, concevoir, implmenter, tester) ds les premires itrations et ceux qui peuvent attendre les itrations plus tardives. Les rsultats sont exprims sous 32 Zphyrin Soh /55
la forme dune vue architecturale du modle des cas dutilisation. Elle sert dentre la planification des dveloppements mener au cours de chaque itration.
Modle des cas dutilisation [esquisse] Exigences supplmentaires
Architecte
Dfinir lordre de priorit des cas dutilisation
Description de larchitecture [vue du modle des cas dutilisation]
Glossaire
3. Dtailler un cas dutilisation : il faut dcrire tape par tape et dtailler la squence dactions de chaque cas dutilisation, en prcisant les modalits de dbut et de fin de chacun. On le fait en collaboration avec les utilisateurs des cas dutilisation.
Spcificateur de cas dutilisation
Dtailler un cas dutilisation
Cas dutilisation [dtaill]
Glossaire
- Structurer la description dun cas dutilisation : dcrire le cas dutilisation selon un modle et aboutir une description prcise, mais parfaitement lisible. Faire ressortir les alternatives si possible. - Formaliser les description des cas dutilisation : dcrire le cas dutilisation avec une technique de modlisation pouvant facilit sa comprhension. On peut dcrire un aperu de la dynamique de ralisation du cas dutilisation (sorte de diagramme dtats-transition, activit ou interaction) pour faire ressortir les interactions entre des diffrents lments participant la ralisation du cas dutilisation. Une description textuelle est trs avantageuse et peut se complter au fur et mesure. 4. Prototyper linterface utilisateur : lobjectif est de concevoir les prototypes dinterface utilisateur permettant lutilisateur dexcuter les cas dutilisation.
Concepteur de linterface utilisateur
Prototyper linterface utilisateur
Prototype de linterface utilisateur
Glossaire Cas dutilisation [dcrit]
- Crer une conception de linterface utilisateur logique : identifier pour chaque acteur et chacun de ses cas dutilisation les diffrents lments (attributs, ceux venant du glossaire,
Zphyrin Soh
33 /55
) dinterface utilisateur quil utilise et manipule (ce quil doit fournir au systme et ce que le systme peut lui renvoyer). Il faut galement savoir les liens entre ces lments, comment ils seront utiliss, manipuls et prsents (leur apparence). - Crer une conception et un prototype de linterface utilisateur physique : ajouter aux lments ci-dessus identifis les lments supplmentaires (conteneurs, fentres, ) pour constituer des interfaces compltes. Il faut dessiner manuellement, puis dvelopper des prototypes (respect des normes en matire dIHM). Leffort consacr au prototypage doit tre proportionnelle la valeur de retour attendue (on ne dveloppe des prototypes dIHM que sil y a beaucoup gagner en terme dutilisabilit : un prototype pour les acteurs les plus importants et esquisser sur papier les autres). Le prototype permet dviter des erreurs pouvant tre dtectes tard, de rvler les omissions dans les descriptions de cas dutilisation et dy remdier avant que le cas dutilisation nentre en phase de conception. 5. Structurer le modle de cas dutilisation : lobjectif est de structurer lensemble des cas dutilisation afin de les rendre plus comprhensibles et plus simples utiliser (dgager les descriptions gnrales et partages des fonctionnalits qui pourront tre utilises par des descriptions plus spcifiques).
Modle des cas dutilisation [esquisse] Exigences supplmentaires Analyste systme
Structurer le modle des cas dutilisation
Modle des cas dutilisation [structur]
Glossaire Cas dutilisation [dcrit]
- Identifier les descriptions partages de fonctionnalits : rechercher dans la description de chaque cas dutilisation les actions compltes ou partielles communes ou partages par plusieurs cas dutilisation. Pour viter les redondances, celles-ci doivent tre extraites et dcrites sous la forme dun cas dutilisation part susceptible dtre rutilis par les cas dutilisation originaux. Cela peut conduire des relations de gnralisation entre les cas identifis (communs) et les cas originaux. - Identifier les descriptions supplmentaires et facultatives des fonctionnalits : faire de mme que ci-dessus avec les squences dactions supplmentaires et facultatives. Ces actions tendent (souvent sous certaines conditions) les cas dutilisation originaux. - Identifier dautres relations entre cas dutilisation : les inclusions (extensions inverses sans conditions) peuvent tre aussi identifies. La structuration du modle des cas dutilisation implique des relations entre le cas. Toutefois, il faut viter de faire de la dcomposition fonctionnelle et trouver le juste milieu (un cas dutilisation ne doit tre ni trop englobant, ni trop fin). Le modle des cas dutilisation comporte essentiellement une description gnrale de lensemble des cas dutilisation, un ensemble de diagrammes (cas dutilisation, semblant dtats-transition, activit ou interaction), une description dtaille de chaque cas dutilisation. On y ajoute aussi en ensemble desquisse et de prototype dinterface utilisateur et une spcification des exigences supplmentaires gnriques non spcifique un cas dutilisation.
Zphyrin Soh
34 /55
V.3. Analyse
V.3.1. Prsentation
Lobjectif de lexpression des besoins est dutiliser un langage comprhensible par le client pour dcrire les besoins du systme afin quil (le client) puisse apprcier/confirmer la comprhension de son problme. En outre, les cas dutilisation constituant un vritable outil dexpression des besoins, il sagit essentiellement dutiliser le langage naturel dans la description des cas dutilisation. Dans ce cas, il faut tre trs vigilent dans lutilisation des notations telles que le diagramme dtats-transition, dactivit, dinteraction, Par consquent, lutilisation du langage naturel entrane une perte de puissance dexpression et il est fort probable que subsistent un grand nombre de problmes qui auraient d tre prciss par des notations beaucoup plus techniques. Lobjectif de lanalyse est donc de rsoudre ces problmes rests en suspens en procdant une analyse plus approfondie des besoins et des exigences en utilisant un langage beaucoup plus technique. En bref, ci-dessous une petite comparaison entre le modle de cas dutilisation et le modle danalyse. Modle des cas dutilisation Formul dans le langage du client Vue externe du systme Structur par les cas dutilisation Sert principalement de contrat entre le client et les dveloppeurs sur ce que le systme doit faire et ne doit pas faire Exprime les caractristiques du systme Modle danalyse Formul dans le langage du dveloppeur Vue interne du systme Structur par les classes, les paquetages strotyps Sert principalement aux dveloppeurs pour comprendre la conception et limplmentation Exprime la ralisation des caractristiques
Le modle danalyse constitue le point de convergence des premires itrations de la phase dlaboration (confre schma cycle de vie). Les travailleurs et artefacts impliqus dans lanalyse sont reprsents dans la figure ci-dessous.
Architecte
Ingnieur de cas dutilisation responsable de
Ingnieur de composants responsable de
responsable de
Modle danalyse
Description de larchitecture
Ralisation-analyse des cas dutilisation
Classe danalyse
Paquetage danalyse
V.3.2. Artefacts
a) Modle danalyse : il aide prciser les besoins et exigences (plus grande puissance dexpression et un formalisme plus pouss), permet denvisager les aspects internes du systme sous forme dobjets. b) Classe danalyse : elle reprsente une abstraction dune ou de plusieurs classes et/ou soussystmes dans la conception du systme. Elle se concentre sur les besoins fonctionnels et renvoie la prise en compte des besoins non fonctionnels la conception et limplmentation. Les classes danalyse sont de granularit plus large que leurs quivalents en conception et implmentation. Les attributs dune classe danalyse demeurent un niveau assez lev et sont souvent reconnaissable partir du domaine du problme, tandis que ceux des classes de
Zphyrin Soh
35 /55
conception et implmentation prsentent des types issus de langages de programmation. Les attributs de classes danalyse peuvent se transformer en classes au cours de la conception et limplmentation. Les relations entre classes danalyse comptent assez peu. Par exemple, une gnralisation entre classes danalyse, pourtant impossible de sen servir en conception car le langage cible ne la supporte pas. Les classes danalyse sont dfinies par trois strotypes de classe. Classes frontires : Elle est utilise pour modliser linteraction (rception/prsentation des informations et des requtes changes) entre le systme et ses acteurs. Les classes frontires modlisent les parties du systme qui dpendent de ses acteurs en recueillant et clarifiant les exigences pesant sur les frontires du systme. Ainsi, la modification dune interface utilisateur ou dune interface de communication se contente gnralement la mise jour de une ou plusieurs classes frontires. Elles reprsentent souvent des abstractions de fentres, formulaire, Chaque classe frontire doit tre lie au moins un acteur, et vice versa. Classes entits : Elle sert modliser les informations persistantes ainsi que le comportement associ. Gnralement, les classes entit sont directement drives des classes entit du domaine correspondante du modle de domaine. Toutefois, les classes entits fournissent une reprsentation des informations utiles aux dveloppeurs lors de la conception et de limplmentation du systme, tandis que les classes du domaine expriment les informations du contexte du systme qui ne sont absolument pas gres par le systme. Les classes entits font souvent apparatre une structure de donnes logique et contribuent une meilleure comprhension des informations dont dpend le systme. Classes de contrle : Les classes de contrle reprsentent la coordination, le squencement, les transactions et le contrle dautres objets. Elles servent souvent modliser le contrle associ un cas dutilisation spcifique. Elles permettent aussi de reprsenter les calculs complexes, tels que la logique mtier, ne pouvant tre lie aucune information spcifique une classe entit. Elles modlisent ainsi la dynamique du systme en coordonnant les actions et les squences principales, et dlguent le travail dautres objets (les objets frontires et entits). c) Ralisation-analyse de cas dutilisation : elle dcrit la faon dont un cas dutilisation est ralis et excut en terme de classes danalyse et dinteraction entre les objets de ces classes. Elle prsente une description des diagrammes de classes qui dcrivent les classes danalyse, de diagrammes dinteraction (collaboration par dfaut ou si possible de squence) entre objets danalyse pour la ralisation du cas dutilisation. La squence dun cas dutilisation commence lorsquun acteur invoque ce cas dutilisation en envoyant un message quelconque au systme. Cest lobjet frontire qui recevra ce message, il envoie son tour le message un autre objet, de sorte que les objets concerns dialoguent pour raliser le cas dutilisation. Une ralisation de cas dutilisation doit raliser de faon adquate le comportement du cas dutilisation correspondant dans le modle de cas dutilisation, et uniquement ce comportement. d) Paquetage danalyse : il offre un moyen dorganiser les artefacts du modle danalyse en parties grables. Il peut se composer de classes danalyse et dautres paquetages danalyse (hirarchisation). Les paquetages danalyse doivent tre cohrents (contenir des lments fortement lis). e) Description de larchitecture (vue du modle danalyse) : elle contient les classes danalyse cls, les paquetages danalyse et les ralisations des cas dutilisation qui ralisent certaines fonctionnalits importantes et stratgiques (celles impliquant un grand nombre de classes danalyse et ayant une large couverture et peuvent traverser plusieurs paquetages danalyse). Cette vue est conserver autant que possible au moment de la conception et de limplmentation de larchitecture.
Zphyrin Soh
36 /55
V.3.3. Travailleurs
a) Architecte : il sassure de lexactitude et de la cohrence du modle danalyse, de lexistence des parties significatives du modle danalyse dans larchitecture (vue architecturale du modle danalyse). Toutefois, il nest pas responsable du dveloppement des divers artefacts du modle danalyse. b) Ingnieur de cas dutilisation : il est responsable de lintgrit dune ou de plusieurs ralisations de cas dutilisation et doit sassurer que celles-ci satisfont aux exigences qui leur sont imposes. Il sassure que toutes les descriptions textuelles et les diagrammes dcrivant cette ralisation sont lisibles et remplissent leur mission. Toutefois, il nest pas responsable des classes danalyse. c) Ingnieur de composants : il dfinit les responsabilits, attributs, relations et exigences supplmentaires des classes danalyse et assure leur maintenance. Il le fait en veillant que chaque classe satisfasse aux exigences dans les ralisations des diffrents cas dutilisation auxquels elle participe. Il sassure galement que le contenu des paquetages danalyse et leurs dpendances sont justes et corrects.

Lenchanement dactivits danalyse peut se rsumer par le diagramme dactivits ci-dessous.
Architecte Analyse architecturale
Ingnieur de cas dutilisation
Analyser un cas dutilisation
Ingnieur de composants
Analyser une classe
Analyser un paquetage
1. Analyse architecturale : lobjectif est de dlimiter les contours du modle danalyse et de larchitecture en identifiant les paquetages danalyse, les classes danalyse manifestes et les exigences particulires communes.
Modle des cas dutilisation Exigences supplmentaires Modle du domaine Description de larchitecture [vue du modle des cas dutilisation] Analyse architecturale
Architecte
Paquetage danalyse [esquisse] Classe danalyse [esquisse]
Description de larchitecture [vue du modle danalyse]
- Identification des paquetages danalyse : les fonctionnalits tant exprimes sous forme de cas dutilisation, il faut attribuer un certains nombre de cas dutilisation un paquetage, puis raliser la fonctionnalit correspondante au sein de ce paquetage. Le regroupement peut se faire selon le processus mtier pris en charge, lacteur ou les relations entre cas 37 Zphyrin Soh /55
dutilisation. Selon ces critres, les cas dutilisation peuvent chevaucher entre paquetages danalyse (plusieurs paquetages danalyse se partagent le mme lment). Llment partag peut donc tre extrait de ces paquetages et mis dans un paquetage commun dont tous les autres dpendront. Il faut obtenir des paquetages forte cohsion interne (les lments au sein dun paquetage doivent tre lis), mais faible couplage (minimiser le nombre de relations entre lments de paquetages diffrents). En vue de clarifier les dpendances, un dcoupage en couche du modle danalyse est utile, en plaant les paquetages spcifiques lapplication dans une couche de haut niveau et les paquetages plus gnraux dans une couche infrieure. - Identification des classes entits manifestes : il faut faire une identification prliminaire des classes entits les plus importantes (celles prenant part la ralisation des cas dutilisation et significatives pour larchitecture). Elles peuvent tre issues des classes du domaine. - Identification des exigences particulires communes : Il faut identifier les exigences qui surgissent au cours de lanalyse afin de pouvoir les grer dans les activits de conception et dimplmentation. Celles-ci sont en gnral des restrictions et contraintes de persistance, distribution et concurrence, scurit, tolrance aux pannes, gestion des transactions, 2. Analyser un cas dutilisation : lobjectif est didentifier les classes danalyse dont les objets sont ncessaires lexcution du cas dutilisation, de repartir le comportement du cas dutilisation entre les objets danalyse en interaction et de formuler les exigences particulires sur la ralisation du cas dutilisation. Cest en fait le raffinement des cas dutilisation.
Modle des cas dutilisation Exigences supplmentaires Modle du domaine Description de larchitecture [vue du modle danalyse] Analyser un cas dutilisation Ingnieur de cas dutilisation Ralisation-analyse de cas dutilisation Classe danalyse [esquisse]
- Identification les classes danalyse : identifier les classes entits, frontires et de contrle ncessaires la ralisation du cas dutilisation, ainsi que leurs responsabilits, les attributs et relations. Pour les classes entits, il convient dtudier en dtail la description du cas dutilisation et identifier les informations ncessaires sa ralisation, tout en distinguant celles formuler en tant quattributs de celles quil vaut mieux relier des classes frontires ou de contrle. Les classes frontires centrales pour chaque acteur sont celles qui reprsentent la fentre principale de linterface utilisateur avec laquelle dialoguera lacteur. Il faut les minimiser au maximum (rduire le nombre de fentre principales avec lesquelles lutilisateur aura besoin de communiquer) car elles seront des agrgats des classes frontires primitives. Il faut identifier une classe de contrle responsable de la coordination et du contrle de la ralisation du cas dutilisation. Elle peut ne pas exister (si lacteur assure une part importante du contrle, le contrle est encapsul dans une classe frontire) ou il peut en avoir plusieurs (si le contrle est complexe, il peut tre reparti dans plusieurs classes de contrle). Les classes danalyse identifies doivent tre runies dans un diagramme de classes pour montrer les relations existantes dans la ralisation du cas dutilisation. - Description des interactions entre objets danalyse : il faut utiliser les diagrammes de collaboration pour dcrire les interactions entre les instances des acteurs, les objets
Zphyrin Soh
38 /55
danalyse et leurs liens. Ces diagrammes peuvent tre complts par des description textuelles si plusieurs diagrammes ralisent le cas dutilisation. - Expression des exigences particulires : il faut se rfrer aux exigences particulires communes identifies dans lactivit prcdente pour formuler celles pesant sur la ralisation du cas dutilisation. 3. Analyser une classe : lobjectif est de dfinir les responsabilits de la classe, didentifier les attributs et relations de la classe danalyse et de formuler les exigences particulires pesant sur la ralisation de la classe danalyse.
Ingnieur de composants Ralisation-analyse de cas dutilisation Analyser une classe Classe danalyse [bauche] Classe danalyse [complte]
- Identification des responsabilits : elle se fait partir de tous les rles que la classe danalyse joue dans les diffrentes ralisations de cas dutilisation. Ces rles sont recenss en tudiant les diagrammes de classes et dinteraction (collaboration) des diverses ralisations. - Identification des attributs : Gnralement, les attributs de classes entits sont triviales. Ceux des classes frontires sont des informations manipules par les acteurs (comme les champs de texte, ), alors que ceux des classes de contrle reprsentent des valeurs accumules ou drives au cours de la ralisation du cas dutilisation. - Identification des associations et des agrgations : il faut tudier, affiner et rduire autant que possible les associations entre classes danalyse. On dfinit alors les agrgations, multiplicits, les noms des rles, les associations rcursives, les rles ordonns, qualifis et associations n-aires. - Identification des gnralisations : Dans lobjectif de faciliter la comprhension du modle danalyse, il faut reprsenter les comportements communs et partags entre classes danalyse par les gnralisations. - Expression des exigences particulires : il faut se rfrer aux exigences particulires communes identifies dans lactivit prcdente pour formuler compltement celles concernant le classe danalyse. 4. Analyser un paquetage : lobjectif est de sassurer que le paquetage danalyse remplit sa mission (raliser certains cas dutilisation) et de dcrire les dpendances entre les diffrents paquetages. Il faut pour cela veiller que le paquetage contient les classes qui conviennent, que les dpendances entre le paquetage et les autres sont celles dont les classes lui sont associes.
Description de larchitecture [vue du modle danalyse] Paquetage danalyse [esquisse]
Analyser un paquetage
Paquetage danalyse [complet]
Le modle danalyse affine et structure les besoins et les exigences. Il comprend les paquetages danalyse, les classes danalyse (leurs responsabilits, attributs, relations et exigences particulires), les
Zphyrin Soh
39 /55
ralisations-analyse de cas dutilisation et la vue architecturale du modle danalyse. Il est possible que le modle danalyse ne soit pas conserv tel quel et ncessite quelques modifications lors de la conception et limplmentation. En effet, la conception exige de prendre en compte la plateforme dimplmentation (langage de programmation, SE, frameworks, systmes existants, ).
V.4. Conception
V.4.1. Prsentation
Le modle danalyse apporte une comprhension dtaille des besoins et des exigences, qui servira de base la conception. La conception a pour objectifs de constituer une base pour les activits dimplmentation en approfondissant la comprhension des questions concernant les exigences non fonctionnelles (lies au langage de programmation, rutilisation des composants, systme dexploitation, technologie de distribution, concurrence, transaction, ), de dcomposer le travail dimplmentation en portion devant faciliter le dveloppement parallle, Modle danalyse Evite les problmes dimplmentation Modle de conception Plan dlaboration et de construction de limplmentation Gnrique la conception Non gnrique, mais spcifique une implmentation Trois strotypes de classe danalyse ( entit , Autant de strotype de classe que le permet le de contrle et frontire ) langage dimplmentation Moins formel Plus formel Moins coteux dvelopper Plus coteux dvelopper Sattache dynamiquement peu la squence Sattache dynamiquement plus la squence Risque de ne pas tre conserv tout au long du Doit tre conserv tout au long du cycle de vie cycle de vie du logiciel La conception attire toutes les attentions durant les itrations de la fin de la phase dlaboration et celles du dbut de la phase de construction (confre cycle de vie). Elle permet la mise en place dune architecture saine et stable et cre un plan dlaboration et de construction du modle dimplmentation. Les travailleurs et artefacts impliqus dans la conception.
Architecte responsable de
Ingnieur de cas dutilisation responsable de
Modle de Modle de Description de conception dploiement larchitecture
Ralisation-conception Classe de Sous-systme de cas dutilisation conception de conception
Interface
V.4.2. Artefacts
a) Modle de conception : il reprsente la version abstraite de limplmentation systme. Il est compos des sous-systmes de conception, des classes de conception, ralisations-conception de cas dutilisation, b) Classe de conception : elle est une abstraction dune classe quivalente limplmentation. Sa spcification utilise le mme langage que le langage
Zphyrin Soh
du des de de
40 /55
c)
d)
e)
f)
g) h)
programmation. Il y est spcifi la visibilit des attributs et des oprations de la classe de conception, les relations liant celles-ci, tous ces lments ayant une correspondance directe dans limplmentation. Pour cela, leurs spcifications dpend des possibilits offertes par le langage de programmation cible. Il est cependant conseill de confier au mme dveloppeur la conception et limplmentation dune classe. Ralisation-conception de cas dutilisation : elle dcrit la ralisation et lexcution dun cas dutilisation spcifique par les classes de conception. Elle offre la traabilit directe avec une ralisation-analyse de cas dutilisation (avec les classes danalyse). Elle comporte les diagrammes de classes montrant les classes de conception, les soussystmes participants la ralisation du cas dutilisation et leurs relations. Elle comporte aussi les diagrammes dinteraction (surtout de squence) dcrivant la ralisation de la squence dactions prcise du cas dutilisation en terme dinteraction entre les objets de conception. Ces diagrammes peuvent tre accompagns des descriptions textuelles les clairant et les compltant avec des exigences dimplmentation. Sous-systme de conception : ils offrent un moyen dagencer les artefacts du modle de conception en portions plus grables. Un sous-systme peut tre compos de classes de conception, de ralisation-conception de cas dutilisation, dinterfaces et dautres soussystmes (rcursivit). Les lments qui composent un sous-systme doivent tre fortement lis et les sous-systmes doivent tre faiblement coupls (minimiser les dpendances). Interface : elle permet de spcifier les oprations fournies par les classes et les soussystmes de conception. Les interfaces offrent un moyen de sparer la spcification des fonctions de leur implmentation. Une classe de conception fournissant une interface doit procurer les mthodes qui ralisent les oprations. De mme un sous-systme fournissant une interface doit contenir les classes de conception et les autres soussystmes qui fournissent cette interface. Description de larchitecture (vue du modle de conception) : elle contient la vue architecturale du modle de conception, cest--dire les lments les plus significatifs (sur le plan architectural) du modle de conception. Elle comprend galement les processus fournissant les mcanismes de concurrence et de synchronisation du systme, y compris les exigences de performance, Modle de dploiement : il dcrit la distribution physique du systme en montrant la rpartition des fonctions sur les diffrents nuds de calcul du rseau. Description de larchitecture (vue du modle de dploiement) : elle contient la vue architecturale du modle de dploiement, prenant en compte les nuds formant la topologie matrielle sur laquelle sexcute le systme, vue centre sur la distribution, la livraison et linstallation des parties constituant le systme.
V.4.3. Travailleurs
a) Architecte : il sassure que les modles de conception et de dploiement sont corrects, cohrents et lisibles. Quils ralisent les fonctions dcrites dans le modle de cas dutilisation, les exigences supplmentaires et le modle danalyse. Il sassure de lexistence des parties significatives (sur le plan architectural) de ces modles dans larchitecture. Il nest pas responsable du dveloppement des artefacts du modle de conception. b) Ingnieur de cas dutilisation : il rend conforme et lisible les diffrentes descriptions textuelles et les diagrammes dcrivant la ralisation-conception de cas dutilisation. Il sassure que ces ralisations satisfont correctement le comportement de la ralisationanalyse de cas dutilisation, ainsi que le comportement du cas dutilisation correspondant dans le modle de cas dutilisation. c) Ingnieur de composants : il dfinit et actualise les mthodes, attributs, relations et
Zphyrin Soh
41 /55
exigences dimplmentation dune ou de plusieurs classes de conception, et sassure que chacune satisfait ses exigences formules dans les ralisations du cas dutilisation auxquelles elle prend part. il peut galement veiller la cohrence des sous-systmes en sassurant que leur contenu est juste et que leurs dpendances vis--vis dautres soussystmes sont correctes (fortement lies et faiblement couples).

Lenchanement dactivits de conception peut se rsumer par le diagramme dactivits cidessous.
Architecte Conception architecturale
Concevoir un cas dutilisation
Concevoir une classe
Concevoir un sous-systme
1. Conception architecturale : lobjectif est de tracer les grandes lignes des modles de conception et de dploiement et de leur vue architecturale, en identifiant les nuds et leur configuration rseau, les sous-systmes et leurs interfaces, les classes de conception significatives sur le plan architectural, les mcanismes de conception gnriques prenant en charge les exigences particulires communes.
Sous-systme [esquisse] Architecte Interface [esquisse] Conception architecturale Classe de conception [esquisse] Modle de dploiement [esquisse]
Modle des cas dutilisation Exigences supplmentaires Modle danalyse Description de larchitecture [vue du modle danalyse]
Description de larchitecture [vue des modles de conception et de dploiement]
Identification des nuds et des configurations rseau : il est frquent que les configurations rseau physiques suivent un modle trois niveaux (IU, logique mtier/applicative, donnes). Lobjectif est de rpertorier les nuds impliqus, leurs capacits en puissance de traitement (mmoire, CPU, ), les types de connexions (caractristiques, disponibilit, qualit, ) entre les nuds et les protocoles de communications utiliss, les autres besoins (copie de secours de donnes, migration de processus, ). Cette connaissance des limites et possibilits des nuds permettra larchitecte dintgrer les technologies ou les services appropris. Identification des sous-systmes et de leurs interfaces : lobjectif est de rpertorier lensemble des sous-systmes (ceux dvelopper et ceux rutiliser). Pour cela, il faut (1) identifier les sous-systmes dapplications (ceux de la couche spcifique 42 /55
Zphyrin Soh
lapplication et de la couche gnrale aux applications), (2) identifier les sous-systmes de middleware et de logiciel systme sur lesquels on doit sappuyer (Attention dtre totalement dpendant de ces sous-systmes), (3) dfinir les dpendances entre les soussystmes (inter-couches et intra-couches) et (4) identifier les interfaces des soussystmes. - Identification des classes de conception significatives sur le plan architectural : lobjectif est didentifier les classes de conception les plus significatives (celles qui participent la ralisation des cas dutilisation significatifs) partir des classes danalyse (traabilit). Il faut aussi dcider quelles classes seront actives cest--dire celles qui seront (associes) des threads ou des processus et qui seront affectes des nuds du modle de dploiement. - Identification des mcanismes gnriques de conception : il sagit dtudier les exigences particulires identifies sur les ralisations-analyse de cas dutilisation et les classes danalyse et de dcider de la manire dont elles seront prises en charge en fonction des technologies dimplmentation disponibles. Cela peut aboutir des classes de conception et sous-systmes additionnels (par exemple pour la dtection et rcupration des erreurs). 2. Concevoir un cas dutilisation : cette activit a pour objectif didentifier les classes de conception et/ou sous-systmes ncessaires la ralisation du cas dutilisation, distribuer le comportement du cas dutilisation entre les objets de conception en interaction et/ou les sous-systmes participants, de dfinir les exigences pesant sur les oprations des classes de conception et/ou des sous-systmes et leurs interfaces et de formuler les exigences dimplmentation pour le cas dutilisation en question.
Modle des cas dutilisation Exigences supplmentaires Modle danalyse Modle de conception Modle de dploiement Concevoir un cas dutilisation
Ralisation-conception de cas dutilisation Classe de conception [esquisse] Sous-systme [esquisse] Interface [esquisse]
Identification des classes de conception participantes : il faut tudier les classes danalyse prenant part la ralisation-analyse de cas dutilisation pour en identifier les classes de conception correspondantes, tudier les exigences particulires et identifier aussi les classes de conception ralisant ces exigences. Lensemble des classes de conception doit tre runi dans un diagramme de classes qui exposera les relations entre ces classes. Description des interactions entre objets de conception : il faut dcrire les interactions entre objets de lesquisse de classes identifi. On utilise le diagramme de squence pour faire ressortir les instances des acteurs participants, les objets de conception et leurs changes de message. Chaque classe de conception doit avoir au moins un objet de conception participant au diagramme de squence. Identification des sous-systmes participants et de leurs interfaces : lutilisation de lapproche descendante encourage la dcomposition du systme en sous-systme avant le dvoilement du contenu de chaque sous-systme. Dans ce cas, les sous-systmes (les classes de conception et leur regroupement en sous-systmes) doivent tre identifis 43 /55
Zphyrin Soh
partir de ltude des classes danalyse et des exigences particulires de la ralisationanalyse de cas dutilisation. - Description des interactions entre sous-systmes : les interactions sont dcrites partir des diagrammes de squences matrialisant cette fois-ci des changes de messages entre sous-systmes (les lignes de vie reprsentent les sous-systmes et non les objets de conception). - Formulation des exigences dimplmentation : il faut formuler toutes les exigences non fonctionnelles identifies, mais qui devront tre gres dans limplmentation. 3. Concevoir une classe : lobjectif est de crer une classe de conception remplissant son rle dans les ralisations de cas dutilisation.
Ralisation-conception de cas dutilisation Classe de conception [esquisse] Interface [esquisse] Classe danalyse [complte]
Concevoir une classe
Classe de conception [complte]
Ebauche de la classe de conception : il faut esquisser quelques classes de conception partir des classes danalyse et des interfaces dj identifies. Pour les classes frontires, les classes de conception dpendront de la technologie dinterface spcifique utilise. Les classes de conception correspondantes aux classes entit imposent de recourir une technologie de BD spcifique. Pour les classes de contrle, il faut tenir compte des aspects non fonctionnels (distribution, transaction, ). Dans tous les cas, les classes de conception doivent se voir attribuer des dpendances de traabilit par rapport aux classes danalyse correspondantes. Identification des oprations : il faut, en fonction des responsabilits de chaque classe, des exigences particulires la classe, de ou des interfaces fournies par la classe, des ralisations-conception de cas dutilisation auxquels participent la classe identifier les oprations qui doivent tre fournies par la classe et les dcrire dans la syntaxe du langage de programmation cible (visibilit, paramtres, ). Identification des attributs : les attributs sont souvent impliqus et ncessaires aux oprations de la classe. Ils doivent tre dcrits dans la syntaxe du langage cible. Ils sont en gnral les attributs des classes danalyse auxquelles la classe de conception remonte (il peut avoir naissance dautres). Identification des associations et des agrgations : il faut tudier les changes de messages (interactions : diagramme de squence) entre les objets des classes de conception pour dterminer les associations entre classes de conception. Identification des gnralisations : Comme la smantique du langage de programmation cible doit tre utilise, si ce dernier ne supporte pas la gnralisation, on peut utiliser les associations et/ou agrgations pour assurer la dlgation. Description des mthodes : on peut utiliser les mthodes pour spcifier la faon dont les oprations seront ralises. Il faut alors dfinir les algorithmes (ou guides) en langage naturel, pseudo-code ou autre. Description des tats : Dans le cas o le comportement ( la rception dun message) de certains objets dpend de leur tat, il est intressant dutiliser un diagramme dtatstransitions pour dcrire les diffrentes transitions de ces objets. 44 /55
Zphyrin Soh
Gestion des exigences particulires : il faut grer les exigences qui nont pas t prises en compte dans les tapes prcdentes, surtout en remontant classe danalyse laquelle drive la classe de conception. 4. Concevoir un sous-systme : lobjectif est de sassurer que le sous-systme est aussi indpendant que possible des autres sous-systmes, quil fournit les interfaces voulues, quil remplit sa mission (offre une ralisation satisfaisante des oprations dfinies par les interfaces quil fournit).
Description de larchitecture [vue du modle de conception] Sous-systme [esquisse] Interface [esquisse]
Ingnieur de composants Sous-systme [complet] Concevoir un sous-systme Interface [complet]
Actualisation des dpendances entre sous-systmes : il faut veiller ce que le soussystme dpende modrment des interfaces fournies dautres sous-systmes que de dpendre des sous-systmes eux-mmes (dpendances avec les lments internes). Dans la mesure du possible, on peut envisager de dplacer des classes qui seraient trop dpendantes dautres sous-systmes de ces sous-systmes. - Actualisation des interfaces fournies par le sous-systme : il faut sassurer et actualiser si possible les interfaces du sous-systme si celles-ci ne prennent pas en charge tous les rles du sous-systme. Les raffinements sont apports par lingnieur se composants ce qu fait larchitecte. - Actualisation du contenu dun sous-systme : le contenu du sous-systme peut tre amlior par lingnieur de composants au fur et mesure quvolue le modle de conception. En dfinitive, le modle de conception comprend les sous-systmes de conception et leurs dpendances, interfaces et contenu, les classes de conception (avec attributs, oprations, relations, exigences dimplmentation), les ralisations-conception de cas dutilisation, la vue architecturale du modle. La conception se traduit galement par le modle de dploiement, qui dcrit toutes les configurations rseau (les nuds, leurs caractristiques, les connexions, ) sur lesquelles le systme doit tre distribu.
V.5. Implmentation
V.5.1. Prsentation
Les objectifs de limplmentation sont dimplmenter (sous forme de composants code source, scripts, binaires, ) les classes et sous-systmes identifis au cours de la conception, de tester les composants unit par unit et les intgrer en les compilant et en les reliant les uns aux autres, de distribuer le systme en faisant correspondre les composants excutables des nuds du modle de dploiement, de planifier les intgrations ncessaires chaque itration. Etant au cur des itrations de construction, limplmentation intervient aussi lors de llaboration pour la cration de larchitecture excutable de rfrence et au cours de la transition pour la prise en compte des anomalies apparues tardivement (cf. cycle de vie). Les travailleurs et artefacts impliqus dans limplmentation sont les suivants :
Zphyrin Soh
45 /55
Architecte responsable de
Intgrateur systme responsable de
Modle Description de Modle de dimplmentation larchitecture dploiement
Plan de construction des intgrations
Composant
Interface Sous-systme dimplmentation
V.5.2. Artefacts
a) Modle dimplmentation : il dcrit la faon dont les lments du modle de conception sont implments. Il prsente aussi lagencement des composants en fonction des mcanismes de structuration et de modularisation disponibles dans lenvironnement dimplmentation et le(s) langage(s) dimplmentation. b) Composant : cest un empaquetage dlments de modle. Il peut tre strotyp excutable (un programme pouvant tre excut sur un nud), fichier (contenant le code source ou des donnes), bibliothque , table , document . Un composant peut implmenter plusieurs lments de modle et entretient des relations de traabilit avec les lments de modle quil implmente (en fournissant les mmes interfaces). Il peut aussi exister des dpendances de compilation entre composants. c) Sous-systme dimplmentation : il offre un moyen de rpartir les artefacts du modle dimplmentation en entits plus grables. Il peut tre constitu de composants, dinterfaces, et dautres sous-systmes. Le mcanisme de regroupement en sous-systme dpend de lenvironnement dimplmentation (paquetage en java, projet en .Net, ). Il doit avoir une traabilit un--un avec le sous-systme de conception correspondant. d) Interface : Un composant qui fournit une interface doit implmenter toutes les oprations dfinies par cette interface. De mme pour les sous-systmes, mais a peut tre un composant du sous-systme ou un autre sous-systme du sous-systme qui fournit linterface. e) Description de larchitecture (vue du modle dimplmentation) : elle contient une vue architecturale du modle dimplmentation cest--dire les artefacts les plus significatifs sur le plan architectural (composants cls remontant des classes de conception significatives). f) Plan de construction des intgrations : il dcrit la squence de constructions requise dans une itration. Pour chaque construction, il dcrit les fonctions (cas dutilisation) devant tre implmentes par la construction, les parties du modle dimplmentation affectes par la construction.
V.5.3. Travailleurs
a) Architecte : il sassure de lexactitude, de la cohrence et de la lisibilit globale du modle dimplmentation. Il veille ce que le modle dimplmentation implmente les fonctions dcrites par le modle de conception, ainsi que toute exigence supplmentaire. Il sassure de lexistence des parties significatives (sur le plan architectural) du modle dimplmentation dans larchitecture. Il nest pas responsable du dveloppement des divers artefacts du modle dimplmentation. b) Ingnieur de composants : il dfinit et actualise le code source dun ou de plusieurs composants, en sassurant que chaque composant implmente les fonctions telles quelles ont t spcifies dans la conception. Il veille lintgrit dun ou de plusieurs sous46 Zphyrin Soh /55
systmes dimplmentation (traabilit un--un avec les sous-systmes de conception). Il sassure que le contenu des sous-systmes dimplmentation est juste et que leur dpendance vis--vis dautres sous-systmes est exacte et quils implmentent correctement les interfaces fournies. c) Intgrateur systme : il planifie la squence de constructions ncessaires chaque itration et lintgration de chaque construction une fois ses diverses parties implmentes.

Lenchanement dactivits dimplmentation est le suivant :
Architecte Implmenter larchitecture
Intgrateur systme
Intgrer le systme
Implmenter une classe
Implmenter un sous-systme
Effectuer les tests unitaires
1. Implmenter larchitecture : lobjectif est de dlimiter le modle dimplmentation son architecture en identifiant les composants significatifs sur le plan architectural, puis en assurant la correspondance des composants avec les nuds dans les configurations rseau appropries.
Modle de conception Modle de dploiement
Architecte Composant [esquisse] Implmenter larchitecture
Description de larchitecture [vues des modles de conception et de dploiement]
Description de larchitecture [vues des modles dimplmentation et de dploiement]
Identification des composants significatifs sur le plan architectural : il faut identifier les composants cls sur le plan architectural. Le regroupement de limplmentation des classes dans les fichiers sources permet didentifier aisment certains composants fichiers. Il faut identifier juste les composants significatifs (une simple esquisse de composants significatifs). - Identification des composants excutables et correspondance avec les nuds : les classes actives dtermines pendant la conception doivent se voir affecter chacune un composant excutable devant tre dploy sur un nud. On peut dtecter dautres composants fichiers et/ou binaires ncessaires la cration de composants excutables. 2. Intgrer le systme : lobjectif est la cration dun plan de construction de lintgration et lintgration de chaque construction avant quelle ne soit soumise au test dintgration. 47 /55
Zphyrin Soh
Exigences supplmentaires Modle des cas dutilisation Modle de conception Modle dimplmentation [constructions prcdentes]
Intgrateur systme
Plan de construction de lintgration
Intgrer le systme Modle dimplmentation [constructions ultrieures]
Planification dune construction ultrieure : il faut planifier le contenu dune construction, partant dune construction existante ou de rien. Une construction doit ajouter des fonctions par rapport la construction prcdente travers limplmentation des cas dutilisation. Elle ne doit pas comprendre trop de composants nouveaux ou affins. Les premires constructions doivent partir des couches infrieures (les couches middlewares et logiciel systmes), tandis que les suivantes remontent en direction de la couche gnrale aux applications, puis celle spcifique lapplication. Il faut bien identifier les vritables besoins devant tre implments par une construction et laisser les autres besoins aux constructions ultrieures. - Intgration dune construction : il faut recueillir les versions appropries des sous-systmes dimplmentation et des composants, les compiler et les lier en une construction. Cette dernire doit tre ensuite soumise aux tests. 3. Implmenter un sous-systme : lobjectif est de sassurer que le sous-systme remplit son rle cest--dire les besoins implmenter le sont correctement par les composants de ce sous-systme. Le contenu du sous-systme peut connatre des amliorations par rapport ce qui a t dfinit par larchitecte, en fonction de lvolution du modle dimplmentation. Les dpendances de traabilit doivent existes entre les sous-systmes de conception et ceux dimplmentation. Chaque interface fournie par le sous-systme de conception correspondant et ncessaire la construction en cours doit tre fournit par le sous-systme dimplmentation.
Plan de construction des intgrations
Ingnieur de composants Sous-systme dimplmentation [implment pour une ultrieures] Interface [implmente pour une construction]
Description de larchitecture [vue du modle dimplmentation] Sous-systme de conception [conu] Interface [conue]
Implmenter un soussystme
4. Implmenter une classe : lobjectif est dimplmenter une classe de conception dans un composant fichier.
Zphyrin Soh
48 /55
Ingnieur de composants Classe de conception [conue] Interface [fournie par la classe de conception] Implmenter une classe Composant [implment]
Esquisse des composants fichier : il faut esquisser le composant fichier qui contiendra le code source. On peut implmenter plusieurs classes de conception dans le mme composant fichier. Toutefois, les conventions du langage utilis aura un impact sur llaboration des composants fichiers. - Gnration de code partir dune classe de conception : il faut gnrer le code source partir de la classe de conception et des relations quelles entretiennent. En effet, une grande partie des lments (attributs, oprations, ) de la classe de conception sont exprims dans la syntaxe du langage de programmation. Toutefois, seule la signature des oprations est gnrs et elles doivent tre implmentes. Cela dpend toujours du langage de programmation cible. - Implmentation des oprations : chaque opration dfinie par la classe de conception doit tre implmente, moins quelle ne soit abstraite et implmente par les descendants de la classe. Cela suppose de choisir un algorithme appropri mme sil peut tre dj spcifi en langage naturel ou pseudo-code pendant le conception. La mthode est limplmentation dune opration de la classe. - Faire en sorte que les composants fournissent les interfaces appropries : le composant rsultant de limplmentation de la classe doit fournir les mmes interfaces que la ou les classes de conception quil implmente. 5. Effectuer les tests unitaires : lobjectif est de tester les composants implments comme units individuelles.
Ingnieur de composants Composant Effectuer les tests unitaires Composant [test par unit]
Interface
Ralisation des tests des spcifications : il faut vrifier le comportement (observable de lextrieur) du composant sans sintresser la faon dont il est implment (test bote noir). Pour cela, on examine les sorties que le composant produit partir des entres de donnes et en fonction de ltat de dpart spcifique. Gnralement, la gamme des combinaisons entres, sorties et tats de dpart est souvent considrable (difficile de les tester un par un). On repartit alors ces entres, sorties et tats de dpart en classes dquivalence. Une classe dquivalence est un ensemble de valeurs dentre, de sortie et dtat de dpart pour lesquelles un composant est cens se comporter de manire identique. Il faut alors tester le composant pour chaque combinaison de classes dquivalence. Raliser les tests de structure : il faut vrifier le fonctionnement interne du composant (test bote blanche). Tout le code source doit tre test (chaque instruction doit tre excute au moins une fois). Il faut surtout veiller tester les chemins les plus intressants travers le code : ceux qui sont le plus couramment emprunts, les plus stratgiques et ceux qui sont 49 /55
Zphyrin Soh
associs un niveau de risque lev. Le modle dimplmentation doit donc contenir les sous-systmes dimplmentation et leurs dpendances, interface et contenus, les composants (tests un un) et leurs dpendances, la vue architecturale du modle dimplmentation (les lments significatifs de ce modle sur le plan architectural).
V.6. Tests
V.6.1. Prsentation
Lobjectif des tests est de vrifier les rsultats de limplmentation en testant chaque construction (internes, intermdiaires et versions finales livrables lextrieur). Il faut alors planifier les tests ncessaires pour chaque itration, concevoir et implmenter les tests en crant les cas de test spcifiant ce qui doit tre test, si possible dvelopper les composants de test excutables destins automatiser les tests. Les constructions faisant apparatre des anomalies doivent tre retestes, ventuellement renvoyes dautres enchanements dactivits (conception, implmentation) afin que les anomalies puissent tre corriges. Les tests mobilisent lattention pendant la phase dlaboration lors de larchitecture de rfrence et pendant la construction lors de limplmentation du systme. Pendant le phase de transition, lattention se porte principalement sur la correction des anomalies dtectes au cours des premires utilisations et des tests de non-rgression. Les travailleurs et artefacts impliqus dans les tests sont :
Ingnieur de tests responsable de Ingnieur de composants responsable de Testeur dintgration Testeur de systme
responsable de
Modle des tests
Cas de test
Procdure de test
Evaluation des tests
Plan des tests
Composant de test
Anomalie
V.6.2. Artefacts
a) Modle de test : il dcrit les conditions et les modalits de test dintgration et systme des composants excutables du modle dimplmentation. b) Cas de test : il spcifie une manire de tester le systme, en prcisant ce qui doit tre test, avec quelles entres, le(s) rsultat(s) escompt(s) et sous quelles conditions. Certains cas de test peuvent tre trs proches et ne diffrer que par une seule valeur dentre ou de rsultat (pour vrifier diffrentes possibilits scnario de cas dutilisation par exemple). Les cas de test peuvent concerner les cas dutilisation (bote noire : vrifier que le cas dutilisation ralise effectivement ses fonctions), linstallation du systme (vrifier que le systme peut tre install sur la plate-forme du client et quil fonctionne bien une fois install), la configuration (vrifier que le systme fonctionne correctement dans diverses configurations rseau, ), robustesse (provoquer lchec du systme en le faisant fonctionner dans des conditions anormales afin de mettre jour ses points faibles), c) Procdure de test : elle spcifie les instructions pour lexcution dun cas de test. Il est utile de rutiliser une mme procdure de test pour plusieurs cas de test et de rutiliser plusieurs procdures pour un seul cas de test. d) Composant de test : il automatise tout ou parties dune ou de plusieurs procdures de test. Il est utilis pour tester les composants du modle dimplmentation en fournissant les entres
Zphyrin Soh
50 /55
de test, en contrlant et en surveillant lexcution du composant test et, ventuellement en rendant compte des rsultats du test. Si plusieurs composants de test exercent des interactions complexes entre eux ou avec des composants du modle dimplmentation (ceux tests), ils peuvent ncessiter un modle de conception de test pour les modliser afin den fournir une vue de haut niveau. e) Plan de test : il dcrit les stratgies de test, leur calendrier et les ressources utiliser. Il dfinit le type et les objectifs des tests effectuer pour chaque itration. f) Anomalie : elle dsigne un symptme dchec ou un problme dcouvert. Elle dsigne tout ce que les dveloppeurs doivent considrer comme problme (symptme) suivre et rsoudre. g) valuation des tests : elle prsente lvaluation des rsultats de lensemble des tests. Elle prcise la couverture des cas de test, la couverture du code et ltat des anomalies.
V.6.3. Travailleurs
a) Ingnieur de test : il doit veiller ce que le modle de test remplisse son rle. Il est charg de planifier les tests en leur fixant des objectifs et en dfinissant le calendrier de leur droulement, Toutefois, il nexcute pas les tests, mais soccupe de leur prparation et de leur valuation. b) Ingnieur de composants : il est responsable des composants de test qui automatisent certaines procdures de test. c) Testeur dintgration : il effectue les tests dintgration ncessaires pour chaque construction produite au cours de limplmentation. Ces tests permettent de sassurer que les composants intgrs une construction fonctionnent correctement ensemble. d) Testeur systme : il est charg de vrifier les interactions entre le systme et les acteurs. Pour cela, il doit effectuer les tests exigs pour le rsultat de chaque itration. Dautres types de test (voir les cas de test) peuvent sappliquer lensemble du systme.

Lenchanement dactivits de test est le suivant :
Planifier les tests
Ingnieur de tests
Concevoir les tests
Evaluer les tests Effectuer les tests dintgration
Testeur dintgration
Testeur de systme
Effectuer les tests systme
Implmenter les tests
1. Planifier les tests : lobjectif est de planifier les tests en dcrivant la stratgie de test, en estimant les exigences imposes par les tests (ressources humaines et systmes ncessaires, ), en fixant le calendrier des tests. Les diffrents modles conus et les exigences supplmentaires aident les ingnieurs de tests dfinir la stratgie pour chaque itration (type de test, quand et comment les excuter, comment dterminer sils ont t concluants, 51 Zphyrin Soh /55
). Toutefois, les cas et procdures de test prioritaires sont ceux destins tester les cas dutilisation les plus importants et les exigences associes aux risques les plus srieux.
Exigences supplmentaires Modle des cas dutilisation Modle danalyse Modle de conception Modle dimplmentation Planifier les tests Plan des tests Ingnieur de tests
Description de larchitecture [vues architecturales des modles]
2. Concevoir les tests : lobjectif est didentifier et de dcrire les cas de test pour chaque itration, didentifier et de structurer les procdures de test indiquant les conditions de ralisation des cas de test.
Exigences supplmentaires Modle des cas dutilisation Modle danalyse Modle de conception Modle dimplmentation Plan des tests [stratgies et calendrier] Description de larchitecture [vues architecturales des modles] Concevoir les tests Procdure de test Ingnieur de tests Cas de test
Conception des cas de test dintgration : les cas de test dintgration servent vrifier linteraction des composants les uns avec les autres aprs leur intgration au sein dune construction. Pour cela, il faut crer un ensemble de cas de test permettant datteindre lobjectif du plan des tests. On considre les diagrammes dinteraction et on recherche les combinaisons dentres, de sorties et dtat de dpart du systme formant les ralisations de cas dutilisation mettant contribution les classes (=> les composants) figurant dans les diagrammes. Conception des cas de test systme : les tests systme visent vrifier que le systme fonctionne correctement dans son ensemble. Les cas de test systme doivent privilgier les combinaisons de cas dutilisation susceptibles dtre excuts en parallle, de sinfluencer les uns les autres, impliquant de nombreux processus, utilisant frquemment les ressources systmes (mmoire, processeur, ). Il faut concevoir les cas de test systme sous diffrentes conditions (diffrentes configurations matrielles, diverses tailles de BD, ), 52 /55
Zphyrin Soh
inspir des exigences particulires. - Conception des cas de test de non-rgression : les cas de test de non-rgression peuvent tre certains de ceux issus des constructions prcdentes. Les cas de test doivent tre assez souples pour ragir correctement aux changements affectant le systme tester. - Identification et structuration des procdures de test : il faut identifier et structurer les instructions pour lexcution des cas de test. 3. Implmenter les tests : lobjectif est dautomatiser les procdures de test en crant des composants de test. Ces composants peuvent provenir dun outil dautomatisation des tests (on spcifie les actions de la procdure de test et loutil gnre un composant de test) ou dvelopp explicitement (les actions de la procdure de test serviront de spcification du composant dvelopper). Le composant de test obtenu doit fournir sous une forme agrable (mode de visualisation) les rsultats de test afin de faciliter leur interprtation. Il nest pas possible dautomatiser entirement toutes les procdures de test.
Ingnieur de composants Cas de test Composant de test
Procdure de test Modle dimplmentation [construction tester]
Implmenter un test
4. Effectuer les tests dintgration : lobjectif est de soumettre au test chaque construction cre au cours dune itration. Il faut en particulier excuter manuellement les procdures de test pour chaque cas de test ou excuter les composants de test qui automatisent ces procdures. Ensuite, comparer les rsultats des tests aux rsultats escompts et examiner les rsultats des tests qui sloignent de ceux prvus. Il faut galement rendre compte des anomalies dtectes lingnieur de composants concern et lingnieur de test (pour valuation des rsultats de test).
Testeur dintgration
Cas de test
Procdure de test Composant de test Modle dimplmentation [construction tester] Effectuer les tests dintgration Anomalie
5. Effectuer les tests systme : on le fait de faon analogue aux tests dintgration. Toutefois, ils dbutent lorsque les tests dintgration indiquent que le systme satisfait aux objectifs de lintgration fixs par le plan des tests (par exemple, 95% des cas de test dintgration sexcutent avec un rsultat prvisible).
Zphyrin Soh
53 /55
Cas de test
Testeur systme
Procdure de test Composant de test Modle dimplmentation [construction tester] Effectuer les tests systme Anomalie
6. Evaluer les tests : lobjectif est dvaluer les tests mens au sein dune itration. Les rsultats des tests sont valus par rapport aux objectifs fixs dans le plan de test. Les ingnieurs de tests prparent galement les mtriques leur permettant de dterminer le niveau de qualit du logiciel et les tests restant effectuer. Il faut surtout mesurer la compltude des test (degr de couverture des cas de test et celui des composants/code tests), la fiabilit (analyser les tendances qui se dgage des anomalies dtectes, le ratio des tests excuts avec succs). A partir de ces tudes, plusieurs actions peuvent tre entreprises (1) excuter les tests supplmentaires (2) assouplir les critres dvaluation des tests (si la barre tait trs haute pour juger la qualit) et (3) isoler les parties ayant un niveau de qualit acceptable et les prsenter comme rsultat de litration en cours. Les autres parties doivent tre rvises et testes nouveau. Lvaluation des tests peut tre dcrite (compltude, fiabilit, actions suggres) dans un document : description de lvaluation des tests.
Ingnieur de tests Plan de test
Modle des tests Anomalie
Evaluer les tests
Evaluation des tests [pour litration]
Le modle de test dcrit la manire dont est test le systme. Il contient les cas de test, les procdures de test et les composants de test. Le modle de test se traduit galement par le plan de test, les valuation des tests effectus et les anomalies susceptibles de guider les autres enchanements dactivits principaux (conception, implmentation).
V.7. Conclusion
En dcrivant les enchanements dactivits principaux lun aprs lautre, on a limpression que le processus global de dveloppement logiciel ne traverse cette squence denchanement dactivits quune seule fois entre le dbut et la fin du projet (comme le cycle de vie en cascade). Mme si lon traverse les cinq enchanements dactivits de faon squentielle, ce parcours se produit chaque itration et non pas une seule fois pour tout le projet : on parcoure autant de fois que ditrations rparties sur les 4 phases du processus. Toutefois, il faut reconnatre quil est probable que lon naille pas jusquaux derniers enchanements dactivits (implmentation, test) dans les premires itrations (phase de cration). En bref, le parcours des enchanements dactivits est soumis aux particularits de chaque itration. 54 Zphyrin Soh /55
Aussi, les enchanements dactivits principaux, bien que dcrits sparment dialoguent les uns avec les autres en produisant les artefacts et en utilisant ceux produits par les autres. Lassociation des divers enchanements dactivits est faite selon le stade du cycle de vie o lon se trouve.
Zphyrin Soh
55 /55

Cours de Genie Logiciel

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cours de Genie Logiciel

Uploaded by

Copyright:

Available Formats

Notes de cours

Anne acadmique 2008/2009

Gnie Logiciel Sommaire

Anne acadmique 2008-2009

Gnie Logiciel Sommaire

Anne acadmique 2008-2009

Gnie Logiciel Notes Importantes

Anne acadmique 2008-2009

Gnie Logiciel Introduction au Gnie Logiciel

Anne acadmique 2008-2009

Chapitre I . Introduction au Gnie Logiciel

I.2. Les objectifs du GL

Gnie Logiciel Introduction au Gnie Logiciel

Anne acadmique 2008-2009

Gnie Logiciel Introduction au Gnie Logiciel

Anne acadmique 2008-2009

Nouveau systme ou systme modifi

Systme existant Gnie Logiciel = Mthodes, techniques, outils

I.3. Les difficults du GL

I.4. Les logiciels et mtiers du GL

Gnie Logiciel Introduction au Gnie Logiciel

Anne acadmique 2008-2009

I.5. La qualit du logiciel ?

Gnie Logiciel Introduction au Gnie Logiciel

Anne acadmique 2008-2009

Gnie Logiciel Les modles classiques de cycles de vie

Anne acadmique 2008-2009

Chapitre II . Les modles classiques de cycle de vie

II.2. Modle en cascade

Gnie Logiciel Les modles classiques de cycles de vie

Anne acadmique 2008-2009

Conception gnrale Conception dtaille

II.4. Modle incrmental

II.5. Modle en spirale

Gnie Logiciel Les modles classiques de cycles de vie

Anne acadmique 2008-2009

Gnie Logiciel Introduction au processus de dveloppement

Anne acadmique 2008-2009

Chapitre III . Introduction au processus de dveloppement

III.2. Historique du processus unifi

Rational Objectory Process 4.1 1996-1997

Objectory Process 1.0-3.8 1987-1995

Gnie Logiciel Introduction au processus de dveloppement

Anne acadmique 2008-2009

III.3. Instances du Processus Unifi

Gnie Logiciel Le Processus Unifi

Anne acadmique 2008-2009

Chapitre IV . Le Processus Unifi

centr sur pilot par Processus Unifi

IV.2. La vie du Processus Unifi

Gnie Logiciel Le Processus Unifi

Anne acadmiq ue 2008-2009

IV.2.1. Axe horizontal

Gnie Logiciel Le Processus Unifi

Anne acadmique 2008-2009

IV.2.2. Axe vertical

Modle dimplmentation Modle de dploiement Modle de test Reprsentation de larchitecture

Gnie Logiciel Le Processus Unifi

Anne acadmique 2008-2009

IV.3. Processus pilot par les cas dutilisation

Les cas dutilisation forment le lien

Gnie Logiciel Le Processus Unifi

Anne acadmique 2008-2009