uml web app

download uml web app

of 13

  • date post

    04-Feb-2018
  • Category

    Documents

  • view

    218
  • download

    0

Embed Size (px)

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-