uml web app

download uml web app

of 13

Transcript of uml web app

  • 7/21/2019 uml web app

    1/13

    Concevoir desapplications Web

    avec UML

    Jim Conallen

    ditions Eyrolles

    ISBN : 2-212-09172-9

    2000

  • 7/21/2019 uml web app

    2/13

    9

    Analyse

    Cest au travers des activits danalyse et de conception qui peuvent tre menes sparmentou conjointement que lon peut dfinir partir des besoins du systme un modle capabledtre concrtis sous forme logicielle.

    Lanalyse comprend les activits qui permettent prcisment daboutir au modle danalysedu systme en partant des cas dutilisation et des besoins fonctionnels. Ce modle danalyseest constitu par les classes et les collaborations de classes qui traduisent les comportements

    dynamiques, dtaills dans les cas dutilisation et les besoins.Le modle reprsente la structure du systme propos un niveau dabstraction qui va au-delde limplmentation physique du systme. Les classes reprsentent spcifiquement des objetsdu domaine mtier (lespace du problme), tels que panier, commande, article ou produit. Leniveau dabstraction est tel que ces mmes classes pourraient tout aussi bien sappliquer desarchitectures autres que celles dapplications web. Durant lanalyse, les processus et les objetsimportants dans lespace du problme sont identifis, nomms et catgoriss.

    Lanalyse se concentre sur les besoins fonctionnels, en ignorant ce stade les contraintes

    darchitecture du systme. Lessentiel est de sassurer que tous les besoins fonctionnels, telsquils sont exprims par les cas dutilisation et les autres documents, sont raliss quelque partdans le systme. Idalement, des fins de traabilit, chaque besoin individuel et chaque casdutilisation est reli aux classes et aux paquetages qui les ralisent.

    La conception, quant elle, est en grande partie un processus daffinement du modledanalyse. En intgrant les besoins non fonctionnels du systme et les contraintes darchitec-ture, elle affine le modle danalyse jusqu obtention dune structure qui puisse tre code.Le concepteur doit prendre en considration que rien ne se fait instantanment, que les ordi-

    nateurs ont une capacit mmoire limite et que de temps autre les choses tournent mal.Ainsi le concepteur est-il souvent le membre pragmatique de lquipe.

    Lorsque lanalyse et la conception sont menes comme deux activits spares, deux modlessont produits : le modle danalyse et le modle de conception. Puisque le modle danalyse

  • 7/21/2019 uml web app

    3/13

    Le dveloppement dapplications webDEUXIMEPARTIE

    2

    est une source pour la conception, on peut soit le conserver en tant que modle distinct, touten le faisant progresser sparment, soit le faire voluer en modle de conception.

    Un modle danalyse distinct est utile dans le cas dun systme qui doit tre conu pour desarchitectures cible multiples. De mme, si le systme est trs complexe, le niveau dabstrac-tion supplmentaire que reprsente le modle danalyse distinct peut aider sa comprhen-sion tout au long du processus.

    Le choix de conserver ou non un modle danalyse distinct doit galement prendre en comptele cot de sa maintenance. De plus, les activits de conception, qui doivent ncessairementsadapter aux ralits du monde logiciel, font presque toujours driver le modle du systme

    par rapport la vision idalise quen a lanalyse. Ainsi, conserver le modle danalyseimplique de le faire voluer avec le modle de conception, ce qui conduit finalement lengliger dans le dtail, pour se concentrer sur les classes et les relations les plus importantesdu domaine. Une fois que le modle danalyse cesse dtre synchronis avec le modle deconception, son utilit devient limite.

    Itration

    Les activits danalyse et de conception peuvent en principe dbuter quand le modle des casdutilisation et lensemble des besoins sont assez avancs. En effet, dans le processus de dve-loppement incrmental, nul besoin que la totalit du modle des cas dutilisation nilensemble des artefacts des besoins soient achevs pour que des activits qui ont trait auxphases suivantes du processus puissent dmarrer. Il ne faut nanmoins pas en dduire que lonpeut coder alors que lon collecte encore des besoins en analysant le problme. Cela veutsimplement dire que, lorsquune bonne comprhension des besoins est atteinte et que certainspaquetages du modle des cas dutilisation sont achevs, il est envisageable den entreprendrelanalyse et la conception. Il est important de comprendre que mieux les cas dutilisation et les

    besoins sont labors et cerns, moins probable sera le risque de devoir retravailler lanalyseet la conception.

    Le dveloppement itratif permet, et cest important, de traiter tout ce qui reprsente un risquepour le projet au plus tt. Le risque, cest cette zone inconnue, le plus souvent identifie grce lexprience des membres les plus aguerris de lquipe. Les zones dombre sont souventlies aux besoins non fonctionnels, tels que la performance, la scurit ou les interfaces dessystmes externes, bien que, dans le cas dorganisations saventurant dans des domainesnouveaux, le risque puisse se situer dans les processus mtier eux-mmes. Souvent larchi-

    tecte est celui qui dlimite ces zones risque, bien que tous les membres de lquipe soient mme de le faire.

    Un architecte dun systme de commerce lectronique peut, par exemple, identifier comme unrisque potentiel lintgration du systme de facturation avec le systme de paiement scurisexterne. Ce jugement peut provenir de ce quil na jamais travaill avec ce systme de paie-ment scuris particulier, ou encore quil a dj rencontr des difficults dans sa mise enuvre. Dans un processus de dveloppement itratif, cest prcisment sur les parties duprocessus qui peuvent poser problme que doivent se fonder en priorit la collecte des besoins

    et ltablissement des cas dutilisation ; leur analyse et leur conception peuvent commenceravant que les cas dutilisation dautres parties ne soient termins.

    Dans le cadre de processus itratifs et incrmentaux, il est important quun solide processusde contrle du changement soit en place. En effet, des dcouvertes dcisives, provenant de ces

  • 7/21/2019 uml web app

    4/13

    AnalyseCHAPITRE9

    3

    zones risque identifies dans lespace du problme, affectent frquemment certaines hypo-thses qui avaient t faites dans les phases prcdentes. Quand cela se produit pendantlanalyse, les cas dutilisation ou les besoins doivent tre remis en cause. Supposons que laspcification des besoins stipule quaux nouveaux clients soit associ obligatoirement et auto-matiquement un identificateur compos de leur nom et de leur numro de tlphone. Ailleursdans la spcification des besoins, il pourrait tre indiqu que le numro de tlphone dunnouveau client est facultatif. Concdons que, dans la pratique, cette situation aurait fort proba-blement t corrige pendant la collecte des besoins, nanmoins si cela navait pas t le cas,cest assurment lanalyse qui la rvlerait, conduisant une remise en question des besoins. Le numro de tlphone doit-il faire partie de lidentificateur, ou un tout autre numro

    unique serait-il adquat ? ou Est-il inconcevable dexiger de chaque client un numro detlphone ? sont, par exemple, des questions auxquelles lquipe des besoins devrarpondre. Est-il besoin de le prciser ? Aucun membre de lquipe ne doit hsiter souleverdes questions qui pourraient simplifier le systme.

    Paquetages

    Une des premires tches dvolues lquipe danalyse est de dfinir la hirarchie des paque-

    tages du modle danalyse. Diviser pour mieux rgner est un principe qui sapplique aussitrs efficacement la rsolution de problmes complexes, au point que UML le dcline dansle monde de la modlisation par sa notion de paquetage. Un paquetage nest donc rien dautrequune partie du modle, assez rduite pour que lon puisse comprendre son sens et ses objec-tifs dans le modle. Les paquetages contiennent les lments du modle, cest--dire, entreautres, les classes, diagrammes, composants et interfaces. Chaque lment du modle est laproprit dun seul paquetage. Les lments du modle peuvent cependant apparatre dans lesdiagrammes dautres paquetages ou participer des relations avec des lments dautres

    paquetages. Cest la notion de classe publique ou prive dans un paquetage qui rend celapossible. Une classe publique dun paquetage est visible, et peut tre utilise, par des lmentsextrieurs au paquetage. Ces classes constituent, dune certaine manire, linterface publiquedu paquetage, et elles doivent tre choisies avec soin.

    Les paquetages peuvent leur tour tre subdiviss en dautres paquetages, ouvrant ainsi lemodle une structuration en hirarchie de paquetages. On sassurera que toute personne peutcomprendre et embrasser lensemble du paquetage dans sa globalit, soit tout la fois sonobjectif, sa signification, ses lments majeurs, ses relations et notamment celles quil entre-

    tient avec des lments dautres paquetages.Un paquetage est reprsent graphiquement par un dossier avec onglet dot dun nom uniquedans tout le modle. Chaque paquetage circonscrit un espace de nommage, impliquant quedeux lments peuvent avoir le mme nom pourvu quils appartiennent deux paquetagesdiffrents.

    Les relations pouvant exister entre deux paquetages sont soit des relations de dpendance, soitdes relations de gnralisation. Une relation de dpendance signifie quun paquetage dpendde la structure dlments qui appartiennent un autre paquetage, ou a connaissance de cette

    structure. On reprsente cette dpendance par une ligne en pointill et une flche qui pointevers le paquetage dont lautre dpend.

    La relation de gnralisation pour les paquetages sapparente la gnralisation des classes :les sous-paquetages sont des spcialisations dun paquetage. Par exemple, un paquetage

  • 7/21/2019 uml web app

    5/13

    Le dveloppement dapplications webDEUXIMEPARTIE

    4

    dinterface utilisateur peut tout fait possder deux sous-paquetages : une interface utilisateurcompatible avec ActiveX et une autre compatible avec Java. Chacun des deux sous-paque-tages contient des lments susceptibles de fournir une interface utilisateur, mais chacun avecson architecture propre.

    Un paquetage peut appartenir un analyste ou un concepteur. Le concepteur est libredajouter des classes ou de modifier les classes prives du paquetage, sans gner le reste delquipe. En revanche, les changements oprs sur les classes publiques doivent tre valids.Un modle convenablement maintenu doit permettre de rpondre rapidement la question : Qui utilise linterface publique de cette classe? Puisque les paquetages appartiennent des membres de lquipe, ils peuvent servir contrler la succession des versions, la possibi-lit de les modifier tant exclusivement rserve lanalyste ou au concepteur lors de chaquesession de modifications.

    Dfinition du modle de haut niveau

    Pendant la dfinition des cas dutilisation, le modle des cas dutilisation a t divis enpaquetages. Cette mme hirarchie peut servir, durant lanalyse, structurer la vue dusystme. Mon exprience en la matire, cependant, me laisse penser que la hirarchie de vue

    dynamique du systme (les cas dutilisation) ne peut servir que de point de dpart la dfini-tion de la vue structurelle du systme (les classes). La raison est que certains objets peuventtre amens participer un grand nombre de cas dutilisation et de paquetages, et ne peuventdonc pas tre associs un seul paquetage de cas dutilisation.

    Au niveau le plus lev des deux modles, les paquetages sont souvent identiques ; auxniveaux infrieurs de la hirarchie, la division des paquetages peut tre fonctionnellementplus explicite. Ainsi, le modle des cas dutilisation de plus haut niveau dun systme de-commerce (voir figure 9-1) peut comprendre les paquetages suivants : Devanture, Facturation,

    Inventaire et Administration du Site.

    Ce mme diagramme servira dfinir le modle danalyse de haut niveau. un niveau inf-

    rieur du modle des cas dutilisation, par exemple pour le paquetage Devanture, on peutsparer les principales fonctions du systme, disponibles pour le client en ligne. On peut alorsinclure dans le paquetage Devanture (voir figure 9-2) les sous-paquetages qui permettront depasser et de suivre les commandes, et de consulter le catalogue.

    Figure 9-1

    Vue de haut niveau

    dune application

    de e-commerce.

  • 7/21/2019 uml web app

    6/13

    AnalyseCHAPITRE9

    5

    Dun autre ct, et dune toute autre faon, le paquetage Devanture du modle danalyse (voirfigure 9-3) peut prsenter les sous-paquetages suivants : Catalogue, Panier, Profil Client etPersonnalisations du Produit (couleur, dcorations, taille). Dans le modle danalyse, lespaquetages tendent reprsenter des choses plutt que des actions. Par consquent, la divisiondu modle danalyse doit plutt consister, pour en faciliter la gestion, associer les chosessemblables (les objets) plutt que les comportements.

    Pour entreprendre le modle danalyse, mieux vaut donc partir des paquetages du diagrammede haut niveau des cas dutilisation ; ensuite, il convient dexaminer les cas dutilisation et lesbesoins fonctionnels en adoptant le point de vue qui permettra de diviser le modle selon lanature des choses reprsentes (les classes dobjets).

    Au moment de la cration de leur hirarchie initiale, il ne faut pas perdre de vue que la raison

    dtre des paquetages est de nous aider grer la taille et la complexit du modle lui-mme,et non de ce que nous modlisons. Un paquetage ne traduit pas une abstraction du domaine, etne transpose pas davantage la structure du systme. Trop souvent, les paquetages sont utilissen fonction dune abstraction du domaine mtier : fonctionnelle, utilisateur et consort.

    Figure 9-2

    Paquetage du casdutilisation Devanture.

    Figure 9-3

    Vue structurelle

    du paquetage

    Devanture.

  • 7/21/2019 uml web app

    7/13

    Le dveloppement dapplications webDEUXIMEPARTIE

    6

    Afin que les paquetages rpondent au mieux leur mission de simplification de la gestion dumodle, il est recommand de veiller ce quils soient tout la fois :

    Intelligibles

    : un individu doit pouvoir saisir la smantique, la justification, les lmentsmajeurs et les responsabilits du paquetage.

    Cohrents

    : dun point de vue logique, les classes sont lies. un certain niveau dabstrac-tion, toutes les classes du paquetage ne forment plus quun groupe.

    Faiblement coupls

    : gnralement, chaque classe a plus de relations avec des classes dumme paquetage quavec des classes qui se trouvent en dehors de celui-ci.

    Hirarchiquement peu profonds

    : les hirarchies trop profondes sont difficiles

    comprendre, dautant plus que chaque niveau draine avec lui ses propres significations. Ilest conseill de se contenter de deux ou trois niveaux par hirarchie.

    tablir une bonne hirarchie de paquetage est un point de dpart important. tant donn quele plus haut niveau de la hirarchie, et probablement le deuxime aussi, doivent tre connus detous les membres de lquipe danalyse et de conception, cette activit gagne tre un effortde groupe conduit par un membre chevronn de lquipe. Tout au long du processusdanalyse, les membres de lquipe creront dautres paquetages et certains seront rarrangspar la suite.

    Analyse

    Quelles soient menes pour des applications web ou pour des systmes objets distribus, lesactivits de lanalyse sont peu ou prou les mmes dans chaque cas. Comme lanalyse seconcentre sur les besoins fonctionnels du systme, en implmenter une partie avec des tech-nologies web nest pas pertinent. moins que les besoins fonctionnels ne stipulent une tech-nologie spcifique, toute rfrence des lments architecturaux devrait tre vite.

    Lanalyse dbute par lexamen du modle des cas dutilisation, des cas dutilisation et de leursscnarios, ainsi que des besoins fonctionnels du systme qui ne sont pris en compte dans lescas dutilisation. Lquipe danalyse dtermine les objets et les classes qui, de par leur colla-boration, peuvent accomplir le comportement requis du systme. Nous partons du principeque le lecteur connat les notions, traites dans de nombreux ouvrages, dobjets, de classes etles principes de base de la programmation oriente objet.

    Si une analyse de robustesse1

    a t mene, cest donc quun premier ensemble de classes etdoprations ou de processus principaux a dj t dfini. Citons quelques-unes des autresmthodes existantes pour dterminer les classes et les collaborations.

    Les exercices avec des fiches CRC (pour Class-Responsibility-Collaboration

    , Classe-Respon-sabilit-Collaboration) sont une mthode simple, qui mobilise peu de moyens, pour identifierles classes et leurs responsabilits2

    . Sur une fiche CRC sont nots le nom de la classe, sesresponsabilits, ses collaborations ou ses relations avec dautres classes. Un exercice avec desfiches CRC quivaut une sance commune de brainstorming

    ; les membres de lquipe

    1. Doug Rosenberg et Kendall Scott, Use Case Driven Object Modeling with UML

    , Addison Wesley Longman, 1999.2. Kent Beck et Ward Cunnigham, A Laboratory for Teaching Object-Oriented Thinking

    , OOPSLA 1989 ConferenceProceedings, octobre 1989, La Nouvelle-Orlans et le numro spcial de SIGPLAN Notices

    , 24(10) octobre 1989. Dispo-nible http://c2.com/doc/oopsla89/paper.html

    . Lire galement Rebecca Wirfs-Brock, Brian Wilkerson et Lauren Wiener,Designing Object-Oriented Software

    , Prentice Hall, 1990.

  • 7/21/2019 uml web app

    8/13

    AnalyseCHAPITRE9

    7

    proposent des ides de classes et dfinissent leurs responsabilits plutt que leurs attributs etleurs oprations. Les classes sont alors associes pour crer des collaborations qui rpondentaux objectifs mentionns dans les cas dutilisation et les besoins. Tous les membres ne syretrouvent pas forcment mais, pour certains, il sagit dune excellente mthode pour entamerla recherche des classes, sans sembarrasser de leurs dtails.

    La technique du jeu de rles est une autre mthode de groupe possible. Les membres delquipe jouent les rles dune partie du systme, tels que les utilisateurs, le systme lui-mme, dautres systmes ou mme des entits du systme. Le groupe droule les scnariosdes cas dutilisation et discute de la manire dont il convient de les raliser, et tous lesmembres prennent note des responsabilits de leur rle. La technique du jeu de rles estsouvent conjugue celle des fiches CRC.

    Lanalyse des substantifs est une autre technique laquelle on peut recourir pour identifier lesclasses et les objets. On y passe en revue les textes des besoins la recherche des substantifsimportants qui mettent sur la voie de classes possibles. Les verbes associs peuvent quant eux rvler des oprations ou des processus. Considrons, par exemple, lextrait du cas dutili-sation suivant :

    Le client informe le systme quil est prt passer sa commande. Le systme examine le

    contenu du panier et dresse la liste des articles prts tre achets. Le client confirme lacommande et dit au systme de lenregistrer.

    On y trouve beaucoup de substantifs qui paraissent importants et qui feraient de bonnesclasses dans le systme : client , panier , commande, etc. Les verbes passer et enregistrer (la commande) sont galement des actions significatives du cas dutilisation quiseront vraisemblablement identifies comme des oprations sur certains objets.

    Finalement, il dcoule de lanalyse une association prliminaire des comportements requis

    avec les lments structuraux du systme les classes et les collaborations. UML, quant lui,nous fournit une notation o ces lments structuraux peuvent tre reprsents graphique-ment. La figure 9-4 illustre ainsi les trois principales classes, base de notre application e-commerce. Au stade du modle danalyse, seules les proprits et oprations publiquesmajeures apparaissent. Il faudra attendre la conception, quand le modle aura t affin, pourque dautres proprits et oprations soient ajoutes.

    Figure 9-4

    Un diagrammede classes dans

    le modle danalyse.

  • 7/21/2019 uml web app

    9/13

    Le dveloppement dapplications webDEUXIMEPARTIE

    8

    Diagrammes de squence

    La vue structurelle du systme nest quun des artefacts de lanalyse. La description des colla-borations entre classes fait tout autant partie de lanalyse que la dfinition des classes. Lemcanisme de UML pour exprimer la dynamique de la collaboration de classes est lediagramme dinteraction, type gnrique des diagrammes de collaboration, de squence etdactivits. Ces diagrammes expriment le comportement dynamique du systme laide deslments structuraux des classes et des relations du modle.

    Les diagrammes de squence et de collaboration, en particulier, sont un maillon critique de latraabilit entre les scnarios de cas dutilisation et les structures des classes. Ces diagrammes

    traduisent le flot du scnario dun cas dutilisation en termes de classes qui finiront par lesimplmenter.

    Pendant la collecte des besoins et la dfinition des cas dutilisation, des scnarios simples ontt dfinis et exprims avec des diagrammes dinteraction. Ces diagrammes, cependant, nemontraient que les interactions de deux objets, lacteur et le systme. La figure 9-5 reprend unscnario dj abord dans un chapitre prcdent.

    Le diagramme contient une reformulation du texte du cas dutilisation qui dcrit le scnario.Cest l une activit majeure de lanalyse que de complter ces diagrammes de squence,crs pendant la modlisation des cas dutilisation, avec les lments structuraux du modledanalyse. Cette fusion dlments dynamiques et structuraux du modle est un maillon cl desa traabilit. Cest grce aux diagrammes de squence et de collaboration que lon peutremonter des mthodes et des classes jusquaux scnarios, et donc aux cas dutilisation,auxquels ils appartiennent, qui leur tour sont directement lis des besoins du systme.Ainsi, un modle convenablement gr permettra de rpondre des questions telles que :

    Modifier cette opration violera-t-il des besoins ? ou Quelles classes seront-elles affec-tes si ce processus mtier, exprim par ce cas dutilisation, est modifi?, ou encore : Quels cas dutilisation doit-on tester de nouveau et quels scnarios de tests revalider, aprsquun problme dans le calcul de la date dune classe a t dcouvert ? Des rponses prcises

    Figure 9-5

    Diagramme

    de squence simple

    extrait dun scnario

    de cas dutilisation.

  • 7/21/2019 uml web app

    10/13

    AnalyseCHAPITRE9

    9

    et rapides ce genre de questions sont quelquefois dcisives, justifiant tous les investisse-ments pour garantir la traabilit.

    Pendant lanalyse, lextrait de scnario de Prise de commande de la figure 9-5 pourrait volueret ressembler au diagramme de la figure 9-6. Bien que dans une application relle une prise decommande en ligne soit sans doute plus complexe, cette figure traduit lide de base duscnario avec les classes dfinies durant lanalyse.

    Remarquons que lobjet Systme de la figure 9-5 est remplac figure 9-6 par un ensembledobjets danalyse. Ces objets, qui ont t introduits lors de lanalyse du cas dutilisation,collaborent pour fournir la mme fonctionnalit que celle fournie par lobjet Systme. Lesobjets de type interface, contrle et entit dessinent la fonctionnalit du systme en classes eten collaborations de classes qui seront finalement transformes en objets de conception.

    Jusqu prsent, la description que nous avons faite des activits danalyse aurait pu gale-ment sappliquer presque tout systme orient objet, quelle quen soit larchitecture. ce

    stade de lanalyse, o larchitecture est probablement connue, un regard diffrenci peut treport sur les objets de contrle et dinterface. En effet, pendant la conception, les objetsdinterface (boundary) seront souvent associs des pages HTML, et les objets de contrle des activits ct serveur de pages web dynamiques. Cela signifie pour lanalyste que la

    Figure 9-6

    Diagramme de squence enrichi durant lanalyse.

  • 7/21/2019 uml web app

    11/13

    Le dveloppement dapplications webDEUXIMEPARTIE

    10

    fonctionnalit affecte aux objets dinterface peut et doit tre limite ; autrement dit, quechaque objet dinterface doit se limiter une tche unique.

    En effet, quand le systme est distribu, ces objets dinterface sont livrs sous forme de pagesHTML; il nest donc pas souhaitable den surcharger un pour accomplir plusieurs tches carcela ne fait que compliquer la gnration de sa page, et compromettre son interprtation parcertains navigateurs peu volus. En revanche, dans un systme client-serveur classique, uneinterface unique peut offrir un prodigieux volume de fonctionnalit et mobiliser des contrlesdinterfaces sophistiqus, tels que des onglets et panneaux multiples pour organiser une grandequantit dinformations. En revanche, avec des pages web spcialement celles conues pourdes navigateurs de base compatibles avec la version 3.2 de HTML , ce niveau de sophistication

    peut devenir problmatique. Si larchitecture choisie repose sur des pages de script, telles que lesJSP, les ASP ou les pages Cold Fusion, une grande partie de la fonctionnalit des objets decontrle sera excute dans des pages web. Les pages de script joueront le plus souvent le rledobjets de contrle dactivits dobjets ct serveur. Dans une application web type avec despages de script, mieux vaut que ces objets de contrle, comme les objets dinterface (boundary),soient conus autour dune fonctionnalit unique. La surcharge dune page de script ct serveurpeut en effet entraner quelque complexit et des problmes de performance. Voil pourquoilanalyste doit concevoir les objets de contrle pour quils soient aussi modestes et lgers que

    possible, en ayant lesprit la rgle dor de la conception objet : un objet ne doit faire quunechose, mais la faire bien . Suivant ce principe, les objets de contrle doivent plutt tre concen-trs sur lorchestration dune unique tche dans le flot du cas dutilisation.

    Diagrammes de collaboration

    Les diagrammes de collaboration ne diffrent pas fondamentalement des diagrammes desquence ; pour preuve, loutil CASE Rational Rose, qui convertit automatiquement lesdiagrammes de squence en diagrammes de collaboration, et rciproquement. Sils traduisent lemme contenu smantique, ils se distinguent par la manire de lexprimer. Dans les diagrammesde squence, la dimension temps organise la reprsentation : tout est rigidement plac le long delaxe du temps, alors que dans les diagrammes de collaboration, en labsence de principe orga-nisateur, les objets sont positionns librement, tout en conservant la squence des messages quisont regroups grce leur numro dordre par association entre objets. La figure 9-7 montrele diagramme de collaboration issu de la conversion du diagramme de squence de la figure 9-6.

    Figure 9-7

    Diagramme

    de collaboration.

  • 7/21/2019 uml web app

    12/13

    AnalyseCHAPITRE9

    11

    Diagrammes dactivits

    Voici un troisime type de diagramme auquel le modle danalyse peut recourir. Lesdiagrammes dactivits peuvent servir exprimer un flot dactivits qui leur tour gnrentdes actions. Les diagrammes dactivits, qui nutilisent pas directement les objets et lesclasses du modle danalyse, tendent exprimer le comportement dynamique un plus hautniveau que ne le font les diagrammes de squence et de collaboration.

    Par ailleurs, les diagrammes dactivits servent aussi modliser les activits dune oprationspcifique, dune manire semblable celle des organigrammes (voir lexemple prsent enfigure 9-8). Un diagramme dactivits bien conu se prte potentiellement la gnration de

    code et la rtro-ingnierie, car il prsente un niveau de dtails suffi

    sant pour coder lopra-tion. ma connaissance, il nexiste pas encore doutils CASE qui proposent une gnrationde code de si bas niveau, mais on peut sattendre ce que la gnration suivante le fasse.

    Pour tous les systmes, mis part bien sr les plus triviaux, lanalyse est le fruit dun effort degroupe. Dune manire gnrale, les membres de lquipe travaillent indpendamment et enparallle sur un paquetage, ou un ensemble de paquetages, tout en se runissant, frquemmentau dbut, pour discuter et ngocier les interfaces publiques de leurs paquetages. Par la suite,

    quand le modle saffine et que les interfaces se stabilisent, le rythme de ces runions peut tremoins lev, en veillant toutefois, par des vrifications rgulires, la cohrence du travail delquipe.

    On estime que le paquetage est termin quand tous ses cas dutilisation et leurs scnarios,principaux et secondaires, ont t pris en compte et vrifis, et sont donc prts pour laconception.

    Figure 9-8

    Diagramme dactivits de

    lopration CalculTVA.

  • 7/21/2019 uml web app

    13/13

    Le dveloppement dapplications webDEUXIMEPARTIE

    12

    En rsum

    Les activits danalyse et de conception servent dfinir un modle des besoins du systmequi puisse tre concrtis sous forme logicielle.

    Le modle danalyse est compos de classes et de collaborations de classes qui accomplis-sent les comportements dynamiques dtaills dans les cas dutilisation et les besoins.

    Les classes danalyse reprsentent des objets du domaine mtier.

    Lanalyse se concentre sur les besoins fonctionnels du systme, en ignorant, ce stade, lescontraintes darchitecture.

    La dfinition des paquetages du modle danalyse de haut niveau peut souvent sinspirer decelle du modle des cas dutilisation. des niveaux infrieurs, cependant, les hirarchiesde paquetages diffrent bien souvent.

    Lanalyse commence par lexamen, men par lquipe danalyse, du modle des cas dutili-sation, des cas dutilisation et de leurs scnarios, ainsi que des besoins fonctionnels dusystme qui ne sont pas pris en compte par les cas dutilisation.

    Lquipe danalyse dtermine les objets et les classes dobjets qui, de par leur collabora-tion, accomplissent le comportement requis du systme.

    Lexpression des interactions dynamiques entre collaborations de classes est une tcheimportante de lanalyse. Ces interactions suivent le flot dvnements dcrit dans les casdutilisation.

    Les classes dinterface et de contrle devraient tre conues autour dobjectifs uniques,tant donn quelles sont terme implmentes sous forme de pages HTML et de pages descript.