Concevoir des

applications Web
avec UML

Jim Conallen

ditions Eyrolles
ISBN : 2-212-09172-9
2000

9
Analyse
Cest au travers des activits danalyse et de conception qui peuvent tre menes sparment
ou conjointement que lon peut dfinir partir des besoins du systme un modle capable
dtre concrtis sous forme logicielle.
Lanalyse comprend les activits qui permettent prcisment daboutir au modle danalyse
du systme en partant des cas dutilisation et des besoins fonctionnels. Ce modle danalyse
est 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-del
de limplmentation physique du systme. Les classes reprsentent spcifiquement des objets
du domaine mtier (lespace du problme), tels que panier, commande, article ou produit. Le
niveau dabstraction est tel que ces mmes classes pourraient tout aussi bien sappliquer des
architectures autres que celles dapplications web. Durant lanalyse, les processus et les objets
importants 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, tels
quils sont exprims par les cas dutilisation et les autres documents, sont raliss quelque part
dans le systme. Idalement, des fins de traabilit, chaque besoin individuel et chaque cas
dutilisation est reli aux classes et aux paquetages qui les ralisent.
La conception, quant elle, est en grande partie un processus daffinement du modle
danalyse. En intgrant les besoins non fonctionnels du systme et les contraintes darchitecture, 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 ordinateurs 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 modles
sont produits : le modle danalyse et le modle de conception. Puisque le modle danalyse

Le dveloppement dapplications web

DEUXIME PARTIE

est une source pour la conception, on peut soit le conserver en tant que modle distinct, tout
en 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 des
architectures cible multiples. De mme, si le systme est trs complexe, le niveau dabstraction supplmentaire que reprsente le modle danalyse distinct peut aider sa comprhension tout au long du processus.
Le choix de conserver ou non un modle danalyse distinct doit galement prendre en compte
le cot de sa maintenance. De plus, les activits de conception, qui doivent ncessairement
sadapter 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 danalyse
implique de le faire voluer avec le modle de conception, ce qui conduit finalement le
ngliger dans le dtail, pour se concentrer sur les classes et les relations les plus importantes
du domaine. Une fois que le modle danalyse cesse dtre synchronis avec le modle de
conception, son utilit devient limite.

Itration
Les activits danalyse et de conception peuvent en principe dbuter quand le modle des cas
dutilisation et lensemble des besoins sont assez avancs. En effet, dans le processus de dveloppement incrmental, nul besoin que la totalit du modle des cas dutilisation ni
lensemble des artefacts des besoins soient achevs pour que des activits qui ont trait aux
phases suivantes du processus puissent dmarrer. Il ne faut nanmoins pas en dduire que lon
peut coder alors que lon collecte encore des besoins en analysant le problme. Cela veut
simplement dire que, lorsquune bonne comprhension des besoins est atteinte et que certains
paquetages du modle des cas dutilisation sont achevs, il est envisageable den entreprendre
lanalyse 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 lanalyse
et la conception.
Le dveloppement itratif permet, et cest important, de traiter tout ce qui reprsente un risque
pour 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 souvent
lies aux besoins non fonctionnels, tels que la performance, la scurit ou les interfaces des
systmes externes, bien que, dans le cas dorganisations saventurant dans des domaines
nouveaux, le risque puisse se situer dans les processus mtier eux-mmes. Souvent larchitecte 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 un
risque potentiel lintgration du systme de facturation avec le systme de paiement scuris
externe. Ce jugement peut provenir de ce quil na jamais travaill avec ce systme de paiement scuris particulier, ou encore quil a dj rencontr des difficults dans sa mise en
uvre. Dans un processus de dveloppement itratif, cest prcisment sur les parties du
processus 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 commencer
avant que les cas dutilisation dautres parties ne soient termins.
Dans le cadre de processus itratifs et incrmentaux, il est important quun solide processus
de contrle du changement soit en place. En effet, des dcouvertes dcisives, provenant de ces

Analyse
CHAPITRE 9

zones risque identifies dans lespace du problme, affectent frquemment certaines hypothses qui avaient t faites dans les phases prcdentes. Quand cela se produit pendant
lanalyse, les cas dutilisation ou les besoins doivent tre remis en cause. Supposons que la
spcification des besoins stipule quaux nouveaux clients soit associ obligatoirement et automatiquement un identificateur compos de leur nom et de leur numro de tlphone. Ailleurs
dans la spcification des besoins, il pourrait tre indiqu que le numro de tlphone dun
nouveau client est facultatif. Concdons que, dans la pratique, cette situation aurait fort probablement 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 de
tlphone ? sont, par exemple, des questions auxquelles lquipe des besoins devra
rpondre. Est-il besoin de le prciser ? Aucun membre de lquipe ne doit hsiter soulever
des questions qui pourraient simplifier le systme.

Paquetages
Une des premires tches dvolues lquipe danalyse est de dfinir la hirarchie des paquetages du modle danalyse. Diviser pour mieux rgner est un principe qui sapplique aussi
trs efficacement la rsolution de problmes complexes, au point que UML le dcline dans
le monde de la modlisation par sa notion de paquetage. Un paquetage nest donc rien dautre
quune partie du modle, assez rduite pour que lon puisse comprendre son sens et ses objectifs dans le modle. Les paquetages contiennent les lments du modle, cest--dire, entre
autres, les classes, diagrammes, composants et interfaces. Chaque lment du modle est la
proprit dun seul paquetage. Les lments du modle peuvent cependant apparatre dans les
diagrammes dautres paquetages ou participer des relations avec des lments dautres
paquetages. Cest la notion de classe publique ou prive dans un paquetage qui rend cela
possible. Une classe publique dun paquetage est visible, et peut tre utilise, par des lments
extrieurs au paquetage. Ces classes constituent, dune certaine manire, linterface publique
du paquetage, et elles doivent tre choisies avec soin.
Les paquetages peuvent leur tour tre subdiviss en dautres paquetages, ouvrant ainsi le
modle une structuration en hirarchie de paquetages. On sassurera que toute personne peut
comprendre et embrasser lensemble du paquetage dans sa globalit, soit tout la fois son
objectif, sa signification, ses lments majeurs, ses relations et notamment celles quil entretient avec des lments dautres paquetages.
Un paquetage est reprsent graphiquement par un dossier avec onglet dot dun nom unique
dans tout le modle. Chaque paquetage circonscrit un espace de nommage, impliquant que
deux lments peuvent avoir le mme nom pourvu quils appartiennent deux paquetages
diffrents.
Les relations pouvant exister entre deux paquetages sont soit des relations de dpendance, soit
des relations de gnralisation. Une relation de dpendance signifie quun paquetage dpend
de 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 pointe
vers 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

Le dveloppement dapplications web

DEUXIME PARTIE

dinterface utilisateur peut tout fait possder deux sous-paquetages : une interface utilisateur
compatible avec ActiveX et une autre compatible avec Java. Chacun des deux sous-paquetages contient des lments susceptibles de fournir une interface utilisateur, mais chacun avec
son architecture propre.
Un paquetage peut appartenir un analyste ou un concepteur. Le concepteur est libre
dajouter des classes ou de modifier les classes prives du paquetage, sans gner le reste de
lquipe. 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 possibilit de les modifier tant exclusivement rserve lanalyste ou au concepteur lors de chaque
session de modifications.

Dfinition du modle de haut niveau

Pendant la dfinition des cas dutilisation, le modle des cas dutilisation a t divis en
paquetages. Cette mme hirarchie peut servir, durant lanalyse, structurer la vue du
systme. 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 dfinition de la vue structurelle du systme (les classes). La raison est que certains objets peuvent
tre amens participer un grand nombre de cas dutilisation et de paquetages, et ne peuvent
donc pas tre associs un seul paquetage de cas dutilisation.
Au niveau le plus lev des deux modles, les paquetages sont souvent identiques ; aux
niveaux infrieurs de la hirarchie, la division des paquetages peut tre fonctionnellement
plus explicite. Ainsi, le modle des cas dutilisation de plus haut niveau dun systme decommerce (voir figure 9-1) peut comprendre les paquetages suivants : Devanture, Facturation,
Inventaire et Administration du Site.
Figure 9-1

Vue de haut niveau

dune application
de e-commerce.

Ce mme diagramme servira dfinir le modle danalyse de haut niveau. un niveau infrieur du modle des cas dutilisation, par exemple pour le paquetage Devanture, on peut
sparer les principales fonctions du systme, disponibles pour le client en ligne. On peut alors
inclure dans le paquetage Devanture (voir figure 9-2) les sous-paquetages qui permettront de
passer et de suivre les commandes, et de consulter le catalogue.

Analyse
CHAPITRE 9
Figure 9-2

Paquetage du cas
dutilisation Devanture.

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

Vue structurelle
du paquetage
Devanture.

Pour entreprendre le modle danalyse, mieux vaut donc partir des paquetages du diagramme
de haut niveau des cas dutilisation ; ensuite, il convient dexaminer les cas dutilisation et les
besoins fonctionnels en adoptant le point de vue qui permettra de diviser le modle selon la
nature 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, et
ne transpose pas davantage la structure du systme. Trop souvent, les paquetages sont utiliss
en fonction dune abstraction du domaine mtier : fonctionnelle, utilisateur et consort.

Le dveloppement dapplications web

DEUXIME PARTIE

Afin que les paquetages rpondent au mieux leur mission de simplification de la gestion du
modle, il est recommand de veiller ce quils soient tout la fois :
Intelligibles : un individu doit pouvoir saisir la smantique, la justification, les lments
majeurs et les responsabilits du paquetage.
Cohrents : dun point de vue logique, les classes sont lies. un certain niveau dabstraction, toutes les classes du paquetage ne forment plus quun groupe.
Faiblement coupls : gnralement, chaque classe a plus de relations avec des classes du
mme 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. Il
est 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 que
le plus haut niveau de la hirarchie, et probablement le deuxime aussi, doivent tre connus de
tous les membres de lquipe danalyse et de conception, cette activit gagne tre un effort
de groupe conduit par un membre chevronn de lquipe. Tout au long du processus
danalyse, les membres de lquipe creront dautres paquetages et certains seront rarrangs
par la suite.

Analyse
Quelles soient menes pour des applications web ou pour des systmes objets distribus, les
activits de lanalyse sont peu ou prou les mmes dans chaque cas. Comme lanalyse se
concentre sur les besoins fonctionnels du systme, en implmenter une partie avec des technologies web nest pas pertinent. moins que les besoins fonctionnels ne stipulent une technologie spcifique, toute rfrence des lments architecturaux devrait tre vite.
Lanalyse dbute par lexamen du modle des cas dutilisation, des cas dutilisation et de leurs
scnarios, ainsi que des besoins fonctionnels du systme qui ne sont pris en compte dans les
cas dutilisation. Lquipe danalyse dtermine les objets et les classes qui, de par leur collaboration, peuvent accomplir le comportement requis du systme. Nous partons du principe
que le lecteur connat les notions, traites dans de nombreux ouvrages, dobjets, de classes et
les principes de base de la programmation oriente objet.
Si une analyse de robustesse1 a t mene, cest donc quun premier ensemble de classes et
doprations ou de processus principaux a dj t dfini. Citons quelques-unes des autres
mthodes existantes pour dterminer les classes et les collaborations.
Les exercices avec des fiches CRC (pour Class-Responsibility-Collaboration, Classe-Responsabilit-Collaboration) sont une mthode simple, qui mobilise peu de moyens, pour identifier
les classes et leurs responsabilits2. Sur une fiche CRC sont nots le nom de la classe, ses
responsabilits, ses collaborations ou ses relations avec dautres classes. Un exercice avec des
fiches 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 Conference
Proceedings, octobre 1989, La Nouvelle-Orlans et le numro spcial de SIGPLAN Notices, 24(10) octobre 1989. Disponible http://c2.com/doc/oopsla89/paper.html. Lire galement Rebecca Wirfs-Brock, Brian Wilkerson et Lauren Wiener,
Designing Object-Oriented Software, Prentice Hall, 1990.

Analyse
CHAPITRE 9

proposent des ides de classes et dfinissent leurs responsabilits plutt que leurs attributs et
leurs oprations. Les classes sont alors associes pour crer des collaborations qui rpondent
aux objectifs mentionns dans les cas dutilisation et les besoins. Tous les membres ne sy
retrouvent pas forcment mais, pour certains, il sagit dune excellente mthode pour entamer
la recherche des classes, sans sembarrasser de leurs dtails.
La technique du jeu de rles est une autre mthode de groupe possible. Les membres de
lquipe jouent les rles dune partie du systme, tels que les utilisateurs, le systme luimme, dautres systmes ou mme des entits du systme. Le groupe droule les scnarios
des cas dutilisation et discute de la manire dont il convient de les raliser, et tous les
membres prennent note des responsabilits de leur rle. La technique du jeu de rles est
souvent conjugue celle des fiches CRC.
Lanalyse des substantifs est une autre technique laquelle on peut recourir pour identifier les
classes et les objets. On y passe en revue les textes des besoins la recherche des substantifs
importants 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 dutilisation 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 la
commande et dit au systme de lenregistrer.
On y trouve beaucoup de substantifs qui paraissent importants et qui feraient de bonnes
classes dans le systme : client , panier , commande , etc. Les verbes passer et
enregistrer (la commande) sont galement des actions significatives du cas dutilisation qui
seront 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 graphiquement. La figure 9-4 illustre ainsi les trois principales classes, base de notre application ecommerce. Au stade du modle danalyse, seules les proprits et oprations publiques
majeures apparaissent. Il faudra attendre la conception, quand le modle aura t affin, pour
que dautres proprits et oprations soient ajoutes.
Figure 9-4

Un diagramme
de classes dans
le modle danalyse.

Le dveloppement dapplications web

DEUXIME PARTIE

Diagrammes de squence
La vue structurelle du systme nest quun des artefacts de lanalyse. La description des collaborations entre classes fait tout autant partie de lanalyse que la dfinition des classes. Le
mcanisme de UML pour exprimer la dynamique de la collaboration de classes est le
diagramme dinteraction, type gnrique des diagrammes de collaboration, de squence et
dactivits. Ces diagrammes expriment le comportement dynamique du systme laide des
lments structuraux des classes et des relations du modle.
Les diagrammes de squence et de collaboration, en particulier, sont un maillon critique de la
traabilit 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 les
implmenter.
Pendant la collecte des besoins et la dfinition des cas dutilisation, des scnarios simples ont
t dfinis et exprims avec des diagrammes dinteraction. Ces diagrammes, cependant, ne
montraient que les interactions de deux objets, lacteur et le systme. La figure 9-5 reprend un
scnario dj abord dans un chapitre prcdent.
Figure 9-5

Diagramme
de squence simple
extrait dun scnario
de cas dutilisation.

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 modle
danalyse. Cette fusion dlments dynamiques et structuraux du modle est un maillon cl de
sa traabilit. Cest grce aux diagrammes de squence et de collaboration que lon peut
remonter 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 affectes 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, aprs
quun problme dans le calcul de la date dune classe a t dcouvert ? Des rponses prcises

Analyse
CHAPITRE 9

et rapides ce genre de questions sont quelquefois dcisives, justifiant tous les investissements pour garantir la traabilit.
Pendant lanalyse, lextrait de scnario de Prise de commande de la figure 9-5 pourrait voluer
et ressembler au diagramme de la figure 9-6. Bien que dans une application relle une prise de
commande en ligne soit sans doute plus complexe, cette figure traduit lide de base du
scnario avec les classes dfinies durant lanalyse.

Figure 9-6

Diagramme de squence enrichi durant lanalyse.

Remarquons que lobjet Systme de la figure 9-5 est remplac figure 9-6 par un ensemble
dobjets 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. Les
objets de type interface, contrle et entit dessinent la fonctionnalit du systme en classes et
en collaborations de classes qui seront finalement transformes en objets de conception.
Jusqu prsent, la description que nous avons faite des activits danalyse aurait pu galement sappliquer presque tout systme orient objet, quelle quen soit larchitecture. ce
stade de lanalyse, o larchitecture est probablement connue, un regard diffrenci peut tre
port sur les objets de contrle et dinterface. En effet, pendant la conception, les objets
dinterface (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

10

Le dveloppement dapplications web

DEUXIME PARTIE

fonctionnalit affecte aux objets dinterface peut et doit tre limite ; autrement dit, que
chaque objet dinterface doit se limiter une tche unique.
En effet, quand le systme est distribu, ces objets dinterface sont livrs sous forme de pages
HTML ; il nest donc pas souhaitable den surcharger un pour accomplir plusieurs tches car
cela ne fait que compliquer la gnration de sa page, et compromettre son interprtation par
certains navigateurs peu volus. En revanche, dans un systme client-serveur classique, une
interface unique peut offrir un prodigieux volume de fonctionnalit et mobiliser des contrles
dinterfaces sophistiqus, tels que des onglets et panneaux multiples pour organiser une grande
quantit dinformations. En revanche, avec des pages web spcialement celles conues pour
des 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 les
JSP, les ASP ou les pages Cold Fusion, une grande partie de la fonctionnalit des objets de
contrle sera excute dans des pages web. Les pages de script joueront le plus souvent le rle
dobjets de contrle dactivits dobjets ct serveur. Dans une application web type avec des
pages 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 serveur
peut en effet entraner quelque complexit et des problmes de performance. Voil pourquoi
lanalyste 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 quune
chose, mais la faire bien . Suivant ce principe, les objets de contrle doivent plutt tre concentrs sur lorchestration dune unique tche dans le flot du cas dutilisation.

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

Diagramme
de collaboration.

Analyse
CHAPITRE 9

Diagrammes dactivits
Voici un troisime type de diagramme auquel le modle danalyse peut recourir. Les
diagrammes dactivits peuvent servir exprimer un flot dactivits qui leur tour gnrent
des actions. Les diagrammes dactivits, qui nutilisent pas directement les objets et les
classes du modle danalyse, tendent exprimer le comportement dynamique un plus haut
niveau que ne le font les diagrammes de squence et de collaboration.
Par ailleurs, les diagrammes dactivits servent aussi modliser les activits dune opration
spcifique, dune manire semblable celle des organigrammes (voir lexemple prsent en
figure 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 suffisant pour coder lopration. ma connaissance, il nexiste pas encore doutils CASE qui proposent une gnration
de code de si bas niveau, mais on peut sattendre ce que la gnration suivante le fasse.
Figure 9-8

Diagramme dactivits de
lopration CalculTVA.

Pour tous les systmes, mis part bien sr les plus triviaux, lanalyse est le fruit dun effort de
groupe. Dune manire gnrale, les membres de lquipe travaillent indpendamment et en
parallle sur un paquetage, ou un ensemble de paquetages, tout en se runissant, frquemment
au 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 tre
moins lev, en veillant toutefois, par des vrifications rgulires, la cohrence du travail de
lquipe.
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 la
conception.

11

12

Le dveloppement dapplications web

DEUXIME PARTIE

En rsum
Les activits danalyse et de conception servent dfinir un modle des besoins du systme
qui puisse tre concrtis sous forme logicielle.
Le modle danalyse est compos de classes et de collaborations de classes qui accomplissent 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, les
contraintes darchitecture.
La dfinition des paquetages du modle danalyse de haut niveau peut souvent sinspirer de
celle du modle des cas dutilisation. des niveaux infrieurs, cependant, les hirarchies
de paquetages diffrent bien souvent.
Lanalyse commence par lexamen, men par lquipe danalyse, du modle des cas dutilisation, des cas dutilisation et de leurs scnarios, ainsi que des besoins fonctionnels du
systme qui ne sont pas pris en compte par les cas dutilisation.
Lquipe danalyse dtermine les objets et les classes dobjets qui, de par leur collaboration, accomplissent le comportement requis du systme.
Lexpression des interactions dynamiques entre collaborations de classes est une tche
importante de lanalyse. Ces interactions suivent le flot dvnements dcrit dans les cas
dutilisation.
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 de
script.