www.developpez.c.

la

Dmarche danalyse et de conception avec le langage UML

Je tiens remercier mon chat et mon poisson rouge ( jusqu' ce que mon chat ne le mange ) pour l'aide et le soutien moral qu'ils m'ont apports.

www.developpez.c.la

Index

Dmarche danalyse et de conception avec le langage UML ______________________ 1 Index _____________________________________________________________________ 2 Prambule_________________________________________________________________ 3 Objectif global dune dmarche danalyse et de conception objet _____________________ 4 Les tapes de la dmarche ____________________________________________________ 5 Exemple trait_____________________________________________________________ 11 Dfinition des besoins ______________________________________________________ 12
premire tape : les exigences et les acteurs ________________________________________ 12 deuxime tape : les intentions dacteurs___________________________________________ 16 troisime tape : le diagramme de use case _________________________________________ 17 quatrime tape : use case description de haut niveau________________________________ 20

L'analyse_________________________________________________________________ 21
cinquime tape : use case description de bas niveau_________________________________ 21 septime tape : diagramme de classe danalyse_____________________________________ 29 huitime tape : Le glossaire_____________________________________________________ 33 neuvime tape : les contrats d'opration __________________________________________ 34

La conception __________________________________________Erreur ! Signet non dfini.

dixime tape : le diagramme dtat ___________________________ Erreur ! Signet non dfini. onzime tape : le diagramme de collaboration __________________ Erreur ! Signet non dfini.
1) 2) 3) 4) 1) 2) Syntaxe du diagramme de collaboration _________________________ Erreur ! Signet non dfini. Visibilit des objets _________________________________________ Erreur ! Signet non dfini. GRASP patterns ___________________________________________ Erreur ! Signet non dfini. Diagramme de collaboration du magasin ________________________ Erreur ! Signet non dfini. Premire tape_____________________________________________ Erreur ! Signet non dfini. Deuxime tape ____________________________________________ Erreur ! Signet non dfini.

douzime tape : le diagramme de classe de conception ___________ Erreur ! Signet non dfini.

Le processus unifi______________________________________Erreur ! Signet non dfini.

Notion de lot ( ou de cycle ) ___________________________________ Erreur ! Signet non dfini. Notion de phases ___________________________________________ Erreur ! Signet non dfini. Notion ditration___________________________________________ Erreur ! Signet non dfini.

conclusion_____________________________________________Erreur ! Signet non dfini. bibliographie___________________________________________Erreur ! Signet non dfini.

www.developpez.c.la

Prambule
Cette dmarche de conception est la dmarche propose par Craig LARMAN. Je lai connue travers le cours Analyse et conception avec UML et les Patterns " de la socit Valtech. Jai ici repris cette dmarche, je lai lgrement simplifie, et jai apport les informations ncessaires pour que des stagiaires de lAFPA puissent simprgner de cette dmarche. Dans un premier temps jai repris lexercice du cours Valtech. Souhaitons quil y ait un deuxime temps Les formateurs qui dsirent former leurs stagiaires cette dmarche devraient suivre le cours pr cit, afin de prendre du recul par rapport la dmarche. Je recommande tous la lecture des ouvrages de Craig LARMAN sur UML.

www.developpez.c.la

Objectif global dune dmarche danalyse et de conception objet

Le but de cette dmarche est danalyser et de concevoir une application objet. Lobjectif est davoir une application qui puisse vivre ( volution de lapplication dans le temps ), et qui enrichisse la base de savoir-faire de lentreprise ( dveloppement de nouveaux applicatifs en sappuyant sur des objets mtiers dj dvelopps ) . La rutilisabilit est un des soucis principaux pour pouvoir rduire le cot des logiciels et augmenter la puissance de dveloppement des programmeurs. Nous nous appuierons sur le workflow, cest dire les rgles des processus mtier pour dbusquer les uses cases, et les acteurs. Dans lanalyse et la conception objet nous cherchons construire une architecture en couche de la forme suivante : couche I.H.M. couche application ( workflow ) couche objets mtiers couche accs aux donnes couche base de donnes prsentation application mtier accs aux donnes base de donnes

Nous verrons que chaque couche dfinira un ou des contrleurs pour la rendre indpendante des autres. Une tude a montr que dans certaines entreprises les rgles mtier changeaient de 10% par mois ! ! ! Il est facile de comprendre alors la raison de ce dcouplage des objets mtiers. Les objets ont tendance tre stables dans le temps, par contre les IHM et base de donnes peuvent galement tre changes sans que lon touche au mtier ni aux rgles de lentreprise. Cette architecture ne sappliquera bien sr pas toutes les applications, cest prendre comme un exemple complet.

www.developpez.c.la

Les tapes de la dmarche

Ce chapitre est un rsum du processus de dveloppement dune application. Il est difficile de comprendre ce rsum, sans avoir lu en dtail et expriment chacun des chapitres auquel il fait rfrence. Par contre je vous conseille de revenir souvent ce rsum ( textuel et graphique ) pour bien vous situer dans la dmarche, avant ltude de tout nouveau chapitre. Lister lensemble des exigences du client issues du cahier des charges, ou issu dune dmarche pralable de collecte dinformation ( documents lectroniques, notes de runions, notes dinterviews, ). Chaque exigence sera numrote et ainsi pourra tre trace. Deux solutions possibles : Nous allons regrouper les exigences par intentions dacteur compltes puis nous allons faire un diagramme de contexte ( nous nous appuierons sur un diagramme de collaboration pour cela ) Si toutes les rgles de processus mtier sont dfinies, nous raliserons un diagramme dactivit en colonnes ( "swim lane" ) o les colonnes sont les acteurs. Cela permet de dgager les responsabilits de chaque acteur, et ainsi de connatre les intentions des acteurs. Dfinir les uses cases et construire le diagramme de uses cases. Faire la description de haut niveau de chaque use case : chercher des scnarios de base. Faire la description dtaille de chaque use case : donner les squences nominales puis les squences alternatives ( Erreurs et exceptions, en limitant au maximum les exceptions). Cette description peut tre complte par un diagramme dactivit qui montre le squencement des diffrents scnarios. Cette description dtaille comprend les scnarios, les pr conditions, partir de quoi se droule le use case, comment se termine le use case, et enfin les post conditions ( rgles mtier assures quand le use case est termin). Faire un diagramme de squence par scnario ( ici cest un diagramme de squence bote noire, o la bote noire correspond au systme informatique dvelopper ). Faire un diagramme de classe par use case. Le diagramme de classe final sera la superposition de ces diagrammes de classe. Les classes obtenues sont des classes du monde rel. Nous ne mettons pas les oprations car nous ne connaissons pas lintrieur du systme informatique. Un contrat est ralis pour chaque opration du systme. Ce contrat contient un nom, des responsabilits, les exigences auxquelles rpond notre itration de cycle de vie, les pr conditions, et les post conditions ( dcrites sous la forme " has been " ) et enfin les exceptions. Ce contrat peut tre ralis sous forme textuelle, ou plus souvent sous forme dun diagramme de squence bote blanche o les objets changent des messages pour rendre le service demand. A partir des diagrammes de classe et des contrats nous raliserons les diagrammes de collaboration qui montrent comment les objets collaborent pour rendre le service demand. Nous appliquerons les patterns de conception pour cela ( GRASP patterns ) En parallle nous raliserons les diagrammes dtat des objets les plus complexes, ainsi nous dtecterons des mthodes internes ces objets.

www.developpez.c.la Nous raliserons enfin le diagramme de classe de conception, en tenant compte nouveau des GRASP patterns. Ceci peut remettre en cause le diagramme de classe prcdemment tabli.

www.developpez.c.la

Processus simplifi
D E F I N I R B E S O I N S nom : effectuer un achat acteur principal : client acteur secondaire : caissier vnement dclencheur : rle du use case : terminaison du use case :

Diagramme de uses cases

Use case haut niveau

A N A L Y S E

nom : effectuer un achat acteur principal : client acteur secondaire : caissier vnement dclencheur : rle du use case : terminaison du use case : rfrences croises : pr conditions : scnarios et alternatives :

:caissier

:magasin

Use case bas niveau

Diagramme de squence

nom : responsabilit : exigences : notes : pr conditions : post conditions :

Diagramme de classe danalyse

Contrat dopration

C O N C E P T I O N

1 : m()

:o1 1.1 : msg() :o2

Diagramme collaboration

Diagramme de classe de conception

www.developpez.c.la

Processus dtaill

Processus de dfinition des besoins

ref R1

fonction payer achat

Exigences

Diagramme des acteurs

payer retourner

0..* est dans 0..1 magasin

magasin Diagramme contexte dynamique

Diagramme contexte statique

ref

fonction

intention

acteur

Intentions dacteurs

Diagramme de uses cases

nom : effectuer un achat acteur principal : client acteur secondaire : caissier vnement dclencheur : rle du use case : terminaison du use case :

Use case haut niveau

www.developpez.c.la

Processus danalyse
nom : effectuer un achat acteur principal : client acteur secondaire : caissier vnement dclencheur : rle du use case : terminaison du use case : rfrences croises : pr conditions : scnarios et alternatives :

Use case bas niveau

Diagramme dactivit

:caissier

:magasin

reprer les classes

Diagramme de squence

Diagramme de classe danalyse

mettre les associations

mettre mthodes et attributs

Diagramme de classe danalyse

Diagramme de classe danalyse

nom : responsabilit : exigences : notes : pr conditions : post conditions :

Contrat dopration

www.developpez.c.la

Processus de conception

attente

actif

Diagramme dtat

1 : m()

:o1 1.1 : msg() :o2

Diagramme collaboration

Diagramme de classe de conception

www.developpez.c.la

Exemple trait
Nous allons traiter l'ensemble de la dmarche d'analyse objet sur un mme exemple. Cet exemple a t pris dans la littrature ( voir la bibliographie ). Nous ne traiterons pas l'ensemble de l'exemple, mais l'ensemble de la dmarche. Ralisation d'une caisse informatise. Un commerant de produits touristiques ( souvenirs, livres rgionaux, ...) dsire informatiser sa caisse. Chaque type de produit possde un code unique ( tiquette code barres ), et un mme prix pour tous les produits de ce type. L'objectif est de faciliter la maintenance des prix des articles. Chaque type de produit est rfrenc dans un catalogue, avec son prix associ. Quand le prix d'un produit doit tre modifi, le manager modifie son prix dans le catalogue, puis sur l'tagre o il est rang. Le caissier s'identifie pour dmarrer la caisse ( avec mot de passe ). La caisse fera les fonctions habituelles d'une caisse : calcul du sous total, calcul du total, possibilit de rentrer plusieurs articles ayant un mme code, retour d'une marchandise avec le ticket de caisse. Le paiement se fera en monnaie seulement. La caisse permet d'diter des rapports : Le reu qui sera donn uniquement pour une vente effective. Il contient le nom du magasin, un message de bienvenue, la date et l'heure. Puis pour chaque vente il donne le code du produit, la description du produit, le prix unitaire, la quantit et le sous total. Enfin nous y trouvons le total TTC. Le rapport quotidien de l'ensemble des ventes ( date, heure, total ). Le rapport quotidien dtaill: liste de l'ensemble dtaill des ventes de la journe. La caisse s'excute sur un PC. Une douchette permettra de lire les codes barres. Les informations peuvent tre rentres au clavier, ou la souris.

www.developpez.c.la

Dfinition des besoins

Pour bien comprendre le fonctionnement du logiciel, et son interaction avec son environnement, nous avons intrt travailler non pas sur le logiciel demand, mais sur le fonctionnement intgral du processus d'entreprise ( workflow ). Ainsi nous aurons une meilleure approche du logiciel. Ainsi nous considrerons l'ensemble des acteurs qui interagissent sur le processus d'entreprise, mme s'ils n'agissent pas sur le logiciel lui-mme. Cela permettra de dterminer les intentions d'acteurs qui nous donneront les uses cases. La dfinition des besoins dmarre avec le dbut du projet. Elle a pour but d'obtenir un premier jet des besoins fonctionnels et oprationnels du client. Dans cette phase nous collectons des informations pour dfinir le besoin du client. A l'issue de cette tape, nous aurons mis textuellement ou l'aide de schmas trs simples, notre comprhension du problme traiter sur le papier. Le client doit tre capable de valider l'tude ainsi faite. Elle lui est donc accessible. premire tape : les exigences et les acteurs Les exigences que nous allons dcouvrir sont les exigences fonctionnelles. A partir du problme pos, c'est dire de tout ce qui est crit, plus tout ce qui ne l'est pas, nous allons lister l'ensemble des fonctions qui pourront tre ralises par le logiciel. Ces exigences seront numrotes pour pouvoir les tracer dans les intentions d'acteur puis dans les uses cases. Fonction Modifier le prix d'un produit Calculer le total d'une vente Rentrer une quantit par article Calculer le sous total d'un produit Retourner une marchandise Payer l'achat Editer un ticket de vente Editer un rapport succinct Editer un rapport dtaill Se connecter la caisse Se connecter en grant Dfinir les droits des usagers Entrer un produit au catalogue Supprimer un produit du catalogue Enregistrer un produit la caisse Initialiser la caisse

Rfrence R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15 R16

Dans la rfrence R veut dire Requirement (cest dire exigence en Anglais). La modification du prix sur une tagre n'est pas traite par le systme. Donc ce n'est pas une exigence fonctionnelle pour notre logiciel.

www.developpez.c.la Se connecter en grant permet de modifier les prix des articles. Ce n'est pas permis pour un caissier. Dfinir les droits des usagers n'est pas indiqu dans le texte, mais est ncessaire au bon fonctionnement du logiciel. Le PC ainsi que la douchette sont des exigences d'architecture, elles ne seront pas prises en compte ici. L'initialisation de la caisse est une fonctionnalit masque. Entrer et supprimer un produit du catalogue sont des fonctions tellement videntes que le client n'en parle pas. Elles doivent cependant tre intgres au logiciel. Les informations rentres au clavier ou la souris sont des exigences d'interface qui seront prises en compte ultrieurement. Notons que les exigences ne sont pas classes ici. Regardons maintenant les acteurs qui gravitent autour de notre application. Les acteurs seront vus dans le sens processus transversal de l'entreprise ( workflow ). Prfrer un acteur humain plutt que le dispositif lectronique devant lequel il est. L'acteur humain a bien une intention quand il fait quelque chose. Un dispositif lectronique beaucoup moins en gnral.

Cais sier (from Us e Cas e View)

Client (from Us e Cas e View)

Manager (from Us e Cas e View)

Salari (from Us e Cas e View)

Adminis trateur (from Us e Cas e View)

les acteurs de l'application

www.developpez.c.la Ce diagramme est un diagramme de classe qui permet de lister les diffrents acteurs. Il se peut que notre liste ne soit pas complte, une itration suivante du processus nous permettra de complter ce schma.

Nous avons dfini 5 acteurs. N'oublions pas qu'un acteur reprsente un rle, et non pas une personne. Le Manager peut tre aussi l'Administrateur (notion de rle). Un Salari est soit un Caissier, soit le Manager. Il se peut que dans la premire itration l'analyste ne remarque pas ceci. C'est souvent dans une itration ultrieure que nous verrons les gnralisations d'acteurs. Nous connaissons les acteurs, et les exigences de l'application. Nous pouvons donc faire un diagramme de contexte dynamique. Ce diagramme de contexte qui dfinit les interactions entre les acteurs et le systme (pas encore systme informatique car nous en sommes au processus mtier donc dcouvrir les uses cases) sera ralis en UML par un diagramme de collaboration. Il reprsente le fonctionnement de l'entreprise. Ici nous ne prciserons pas forcment l'ordre et le squencement des oprations.

grer un retour d'article diter un ticket enregis trer un produit enregis trer une quantit grer un paiem ent

: Client

: Cais s ier

retourner un article payer un achat m agas in grer le catalogue initialis er les cais s es editer des rapports

s e connecter dfinir les droits des us agers : Manager : Salari

: Adm inis trateur

Diagram m e de contexte du m agas in

www.developpez.c.la Nous pouvons aussi en complment tracer un diagramme de classe des acteurs du systme pour prciser les cardinalits des diffrents acteurs du systme. Nous utiliserons alors un diagramme de classes de UML. Ce diagramme s'appelle un diagramme de contexte statique.

0..* Client (from Use Case View) est dans est la caisse 1 Caissier

(from Use Case View)

0..1 0..1 m agas in 0..* travaille dans 0..* 1..* 0..* gre

adm inistre 1

1 Salari (from Use Case View)

Manager (from Use Case View)

administrateur (from Use Case View)

Diagram me de contexte statique (capture initiale des besoins )

www.developpez.c.la

deuxime tape : les intentions dacteurs

Nous allons maintenant regrouper les exigences en intentions d'acteurs. Une intention d'acteur est un enchanement de fonctions qui rend un service complet un acteur ( et pas une fraction de service ). Rfrence R1 R13 R14 R16 R5 R10 R11 R8 R9 R12 R7 R6 R2 R3 R15 R4 Fonction Modifier le prix d'un produit Entrer un produit au catalogue Supprimer un produit du catalogue Initialiser la caisse Retourner une marchandise Se connecter la caisse Se connecter en grant Editer un rapport succinct Editer un rapport dtaill Dfinir les droits des usagers Editer un ticket de vente Payer l'achat Calculer le total d'une vente Rentrer une quantit par article Enregistrer un produit la caisse Calculer le sous total d'un produit Intention d'acteur Grer le catalogue Grer le catalogue Grer le catalogue Initialiser la caisse Retourner un article Se connecter Se connecter Editer un rapport Editer un rapport Dfinir les profils Effectuer un achat Effectuer un achat Effectuer un achat Effectuer un achat Effectuer un achat Effectuer un achat Acteurs Manager

Manager Client, Caissier Salari Manager Administrateur Client, Caissier

Ici dans le tableau la notion d'acteur repose sur l'intention d'acteur, pas sur la fonction. Ainsi toutes les lignes d'une mme intention d'acteur ne sont-elles pas renseignes pour les acteurs. Ici nous distinguerons l'acteur principal des acteurs secondaires en soulignant l'acteur qui est l'origine de l'intention. Nous allons bien sr vrifier que les exigences dfinies prcdemment sont toutes incluses dans les intentions d'acteur. La traabilit est un facteur essentiel des phases de dfinition des besoins et de celle d'analyse. Nous avons les intentions d'acteurs, nous pouvons donc faire un diagramme de Use Case. Toute cette dmarche peut tre faite d'une autre manire: Nous dterminons les acteurs et les exigences A partir des exigences nous faisons un diagramme d'activit ( UML ) en colonnes ( swim lane ). Chaque colonne correspond un acteur. Cela nous permet de dfinir les responsabilits des acteurs, donc de dfinir les uses cases correspondant.

www.developpez.c.la

troisime tape : le diagramme de use case Un use case est une intention d'acteur. Quand un acteur dmarre un use case, il a une intention prcise. Quelle est cette intention? Effectuer un achat est une intention qui recouvre un certain nombre d'exigences. C'est une unit d'intention complte d'un acteur: c'est donc un use case. Payer ses achats n'est pas une intention complte d'acteur. Nous n'allons pas dans un magasin pour payer, mais bien pour faire des achats. C'est donc une partie ( et pas la plus agrable ) de effectuer un achat. Ce n'est donc pas un use case. L'acteur dclencheur de l'achat est le client. C'est lui qui est venu effectuer un achat. Le diagramme de uses cases est la reprsentation graphique du tableau d'intention d'acteurs prcdent. Diagramme de use case

Effectuer un achat

Client Retourner un article

Se connecter

Caissier

les flches unidirectionnelles indiquent un lien principal, indiquent un lien principal, cest dire dire l'acteur principal case c'est lacteur principal du usedu use case.

Les flches unidirectionnelles

Grer le catalogue

Salari

Manager

Initialiser la caisse

Editer un rapport

administrateur Dfinir les profils

www.developpez.c.la Quand nous dfinissons les uses cases, il faut faire extrmement attention la notion de point de vue. Pour le magasin le client est un acteur essentiel. Par rapport au systme informatique ce n'est pas un acteur. L'acteur qui est en interface avec le systme informatique est souvent le caissier, mais jamais le client. Nous voulons dfinir le systme informatique du magasin, pour cela il faut partir de l'ensemble des acteurs qui gravitent autour du magasin, sinon nous risquons d'oublier un certain nombre de fonctionnalits. Le fait de retourner un article est un souci du client, pas du caissier. Si nous ne prenons le point de vue que du systme informatique nous risquons de ne pas penser ce problme. Dans la phase d'analyse nous dlimiterons le systme informatique dans le processus global du magasin. Le schma de uses cases peut faire apparatre: Des fonctionnalits bien prcises qui se retrouvent parmi plusieurs uses cases. Nous parlerons alors de use case included ou subalterne. Un tel use case ne peut tre li qu' un use case, pas un acteur. ( nous mettrons alors le strotype include sur le lien use case vers use case subalterne ).

avoir solde

retrait <<include>> <<include>>

exem ple de use case subalterne pour un guichet autom atique de banque

authentification

Un use case peut ncessiter le service d'un autre use case. Le use case dont nous avons besoin du service tend le use case demandeur. Nous utiliserons le strotype extend. Ici les uses cases peuvent tre sollicits par des acteurs.

<<extend>>

gestion comm ande

gestion client

exem ple de use case tendu pour un systme de gestion de com mande. Quand nous rentrons une com mande, il faut pouvoir crer le client s'il n'existe pas.

www.developpez.c.la Nous pouvons avoir des cas de spcialisation de cas d'utilisation. Plusieurs uses cases peuvent avoir une trame commune et donc hriter d'un use case parent et abstrait.

retrait euros les uses cases retrait euros et retrait dollars hritent de retrait. Retrait est le use case gnrique des retraits d'argent. Ce use case est abstrait, un acteur ne fait pas un retrait.

retrait dollars

Retrait

Ces spcialisation, include et extend ne se mettent bien souvent pas dans le premier cycle de dveloppement, car c'est l'tude de l'application qui mettra en vidence ces caractristiques. Nous verrons plus tard ces notions de cycle dans le droulement dune dmarche comme celle-ci.

www.developpez.c.la

quatrime tape : use case description de haut niveau Il nous faut maintenant dfinir les uses cases. Cette description est une description de haut niveau qui se fait avant l'analyse. Nous sommes toujours dans la dfinition du besoin. Une description de haut niveau d'un use case est une description textuelle qui comprend les chapitre suivants: Nom du Use Case: Acteur principal: Acteurs secondaires: Evnement dclencheur du Use Case: Rle du Use Case: Terminaison du Use Case: Cette description est assez succincte 3 ou 4 lignes maximum pour le rle du use case. C'est une description narrative d'un processus mtier. Cette description ne repose pas sur la technologie objet. Les cas d'utilisation ( autre nom pour un use case ) vus dans l'analyse sont dits essentiels. Ici nous ferons donc la description de cas d'utilisation de haut niveau essentiels. Essentiel signifie que l'on ne fait pas rfrence la technologie, que le use case dcrit le cur du mtier, ils sont appels use case pour 100 ans. De haut niveau veut dire que l'on en fait une description brve, sans entrer dans le dtail du squencement du use case. Nous verrons par la suite des uses cases dtaills ( en phase d'analyse ), et des uses cases rels ( en phase de conception ). Description d'un use case essentiel de haut niveau: Nom du Use Case: Acteur principal: Acteurs secondaires: Evnement dclencheur du Use Case: Rle du Use Case: Terminaison du Use Case: Effectuer un achat Client Caissier Un client arrive la caisse avec ses achats Le caissier passe tous les articles, fait la note, et encaisse le paiement. Le client a pay et a ramass tous ses articles.

www.developpez.c.la

L'analyse
Aprs une premire bauche des besoins des clients, il va falloir approfondir ses besoins, examiner les diffrents scnarios des uses cases ( ventuellement avec un diagramme d'activit pour exprimer ces diffrents scnarios ), tenir compte des traitements exceptionnels et cas d'erreur. Il va tre ncessaire de regarder le squencement des oprations d'un point de vue fonctionnel, pour voir comment les diffrents acteurs interagissent avec le logiciel, laide des diagrammes de squence bote noire ( la bote noire c'est le systme informatique dvelopper ). Il est alors ncessaire de distinguer les diffrents objets qui collaborent dans notre systme informatique ( avec un diagramme de classe ). Enfin nous allons dtailler le rle des oprations en dfinissant des contrats d'opration ( soit sous forme textuelle, soit sous forme de diagramme de squence ). Nous aurons alors tous les lments pour passer la conception. Nous n'avons ici comme souci que de dtailler les besoins du client pour s'en imprgner, afin de pouvoir le formaliser et le prciser. cinquime tape : use case description de bas niveau La description dtaille d'un use case permet de bien dcrire les enchanements des services rendus par le logiciel pour un usage prcis. N'oublions pas que nous restons au niveau essentiel, c'est dire que nous ne donnerons pas de solution au problme, nous ne faisons que prciser sa description. Nous sommes toujours dans l'espace du problme, pas dans celui de la solution. Une description dtaille de use case comprend: Nom du Use Case: Acteur principal: Acteurs secondaires: Evnement dclencheur du Use Case: Rle du Use Case: Terminaison du Use Case: Les rfrences croises des exigences: Les pr conditions ncessaires au fonctionnement du use case: Description complte du use case, avec les diffrents scnarios: Cette description intgre les cas d'erreur ( traits par le use case ) et les exceptions ( forant la sortie du use case ). Contraintes d'IHM ( optionnel ): Attention de ne pas dcrire l'interface ici, mais bien de prciser des lments prendre en compte lors de la ralisation des interfaces. Contraintes non fonctionnelles ( optionnel ): Ici nous prendrons en compte les dimensionnements, les performances attendues, Ceci permettra de mieux valuer les contraintes techniques. La description complte du use case donne la priorit aux choses que les acteurs peroivent. Nous dcrirons les actions des acteurs en commenant par l'acteur principal qui initie le use case, puis nous donnerons les rponses du systme ( vu comme une bote noire ). Le premier travail se fait sur un cas nominal ( c'est dire idal ). Les cas d'erreur ( avec correction et reprise ) et les exceptions ( avec abandon du use case ) sont traits ensuite. Le formalisme est textuel et prend la forme suivante:

www.developpez.c.la

Actions des acteurs 1. L'acteur principal fait 3. L'acteur principal calcule 4. L'acteur secondaire traite

Rponses du systme 2. Le systme lui envoie 5. Le systme envoie le compte rendu

Traitement des cas d'erreur et d'exception: A l'tape 2 si le code de alors le systme renvoie un message et l'acteur principal refait A l'tape 4 si alors le systme affiche et le use case s'arrte En premier lieu nous voyons les changes entre le systme et les acteurs, ainsi que la chronologie et l'enchanement des actions, dans le cas nominal. Dans un deuxime temps nous listons les cas d'erreur ( avec traitement de rcupration ) et les traitements d'exception avec arrt du use case. Nous restons bien fonctionnel car nous ne dcrivons pas comment est ralis le systme, mais comment sont raliss les services qu'il rend. Notion de scnario: un use case est un regroupement d'actions plus lmentaires qui permet de traiter une intention d'acteur assez gnrale. Un scnario est une ralisation du use case, donc une "intention lmentaire". Par exemple pour une gestion de compte client dans une banque, nous avons un use case grer les comptes. Nous avons plusieurs scnarios: crer un compte, consulter un compte, modifier un compte, Pour chacun des scnarios il va falloir faire une description dtaille de use case ( avec traitement d'erreur et d'exception pour chacun ). Un diagramme d'activit va permettre de montrer l'ensemble d'un use case, en regroupant l'ensemble des scnarios de ce use case. Exemple de description d'un use case ( effectuer un achat ): Nom du Use Case: Acteur principal: Acteurs secondaires: Evnement dclencheur du Use Case: Rle du Use Case: Effectuer un achat Client Caissier Un client arrive la caisse avec ses achats Le caissier passe tous les articles, fait la note, et encaisse le paiement. Le client a pay et a ramass tous ses articles. R2, R3, R4, R6, R7, R15

Terminaison du Use Case: Les rfrences croises des exigences:

Les pr conditions ncessaires au fonctionnement du use case: La caisse est allume et initialise. Un caissier est connect la caisse. Description complte du use case, avec les diffrents scnarios: Ici il n'y a qu'un scnario possible. Nous verrons dans l'exemple suivant un use case avec plusieurs scnarios pour mettre en vidence le diagramme d'activit.

www.developpez.c.la

Actions des acteurs Rponses du systme 1) Le client arrive la caisse avec les articles qu'il dsire acheter. 2) Le caissier enregistre chaque article. 3) Le systme dtermine le prix de l'article, les informations sur l'article et ajoute ces informations la transaction en cours. Il affiche ces informations sur l'cran du client et du caissier. 4) Le caissier indique la fin de vente quand il 5) Le systme calcule et affiche le montant n'y a plus d'article. total de l'achat. 6) Le caissier annonce au client le montant total. 7) Le client donne au caissier une somme d'argent suprieure ou gale la somme demande. 8) Le caissier enregistre la somme donne par 9) Le systme calcule la somme rendre au le client. client. 10) Le caissier encaisse la somme remise par 11) Le systme enregistre la vente effectue le client et rend la monnaie au client. 12) Le systme dite le ticket de caisse 13) Le caissier donne le ticket de caisse au client 14) le client s'en va avec les articles qu'il a achets. Variantes du scnario nominal ( celui qui se droule quand tout se passe bien ). Paragraphe 2: il peut y avoir plusieurs articles d'un mme produit. Le caissier enregistre le produit ainsi que le nombre d'articles. Paragraphe 3: s'il y a plusieurs articles d'un mme produit le systme calcule le sous total. Paragraphe 2: Le code produit peut tre invalide. Le systme affiche un message d'erreur. Paragraphe 7: Le client n'a pas la somme d'argent suffisante. La vente est annule. Remarque: Ceci est une exception qui termine anormalement le use case. Paragraphe 8: Le caissier n'a pas la monnaie pour rendre au client. Il va faire la monnaie la caisse principale. Remarque: ici nous avons fait apparatre un nouvel acteur: le caissier principal ( ce sera probablement la mme personne que le manager mais un acteur diffrent ). Paragraphe 12: le systme ne peut pas diter le ticket de caisse. Un message est affich au caissier, et celui-ci change le rouleau de papier. Paragraphe 14: remarquons que si le client repart sans ses articles, il est probable que le caissier les lui mettra de cot. Cet vnement ne change rien notre systme futur. Ce genre d'incident ne sera pas pris en considration.

www.developpez.c.la En terme de reprsentation nous pouvons prfrer mettre une colonne par acteur pour bien voir les responsabilits des acteurs vis vis du systme. Ici cela donnerait: Actions du client Actions du caissier 1) Le client arrive la caisse 2) Le caissier enregistre avec les articles qu'il dsire chaque article. acheter. Rponses du systme 3) Le systme dtermine le prix de l'article, les informations sur l'article et ajoute ces informations la transaction en cours. Il affiche ces informations sur l'cran du client et du caissier. 4) Le caissier indique la fin de 5) Le systme calcule et vente quand il n'y a plus affiche le montant total de d'article. l'achat. 6) Le caissier annonce au client le montant total. 7) Le client donne au caissier 8) Le caissier enregistre la 9) Le systme calcule la une somme d'argent somme donne par le client. somme rendre au client. suprieure ou gale la somme demande. 10) Le caissier encaisse la 11) Le systme enregistre la somme remise par le client et vente effectue rend la monnaie au client. 12) Le systme dite le ticket de caisse 13) Le caissier donne le ticket de caisse au client 14) le client s'en va avec les articles qu'il a achets. Cette reprsentation met en vidence que le client n'a pas accs au systme informatique. Contraintes d'IHM ( optionnel ): La dsignation de l'article et son prix ( ventuellement le sous total si plusieurs occurrences du mme article ) sont affichs chaque article au caissier et au client. Le total est affich galement aux deux. Contraintes non fonctionnelles ( optionnel ): Le magasin reoit en moyenne 200 clients par jour. Chaque client achte en moyenne 10 articles.

www.developpez.c.la Voici un exemple de diagramme d'activit reprsentant la runion de scnarios modlisant un use case. Nous allons grer le catalogue en utilisant un diagramme d'activit pour reprsenter l'ensemble des scnarios ( un scnario est un droulement d'un use case de bout en bout, en commenant par le dbut et se terminant par la fin. ) Un scnario supporte aussi des variantes et des exceptions. Chaque scnario peut tre dcrit comme le use case ci-dessus. Mais il est bon de regrouper l'ensemble de ces scnarios dans un diagramme d'activit pour avoir une vue complte du use case.

supprim er un article

dtruire la rfrence

saisir le code

vrifier le code

saisir et valider le prix

modifier le prix d'un article

saisir les infos du produit

vrifier le code

enregistrer le produit

ajouter un article

ralisation d'un diagram me d'activit ( ici ce n'est pas la norm e UML car la version de rose utilise ne supporte pas les diagram mes d'activit ). Ce schm a a t construit partir d'un diagramm e d'tat.

Note :
commentaire

Ceci reprsente un commentaire dans tout schma UML.

www.developpez.c.la Les notes nous montrent les trois scnarios possibles pour ce use case. Pour chacun de ces scnarios il est ncessaire de faire le tableau prcdent pour mieux dtailler le use case dans le scnario particulier. En particulier il faut penser aux cas d'erreur et aux exceptions. Remarquons qu'un certain nombre de symboles du diagramme d'activit ne sont pas disponibles comme l'alternative, et les conditions de cette alternative.

www.developpez.c.la sixime tape : diagramme de squence bote noire Les uses cases ont t valids par le client. Nous allons donc changer notre point de vue ( workflow c'est dire processus mtier ) pour adopter un point de vue systme informatique. Nous abandonnons donc les vnements mtier pour nous intresser aux vnements informatiques. Nous allons dvelopper un diagramme de squence par scnario de use case dtaill. Ces diagrammes de squence sont dits bote noire car nous ne savons toujours pas comment sera fait le systme informatique. Ici nous prcisons les changes entre les acteurs utilisateurs du systme informatique et le systme proprement dit. Les interactions des acteurs directement sur le systme sont appeles des vnements. Les actions engendres par le systme suite ces vnements sont appeles des oprations. A un vnement correspondra une opration. Dans la terminologie message et vnement sont quivalents entre eux, ainsi que mthode et opration. Les diagrammes de squence seront agrments de notes et commentaires qui permettront d'illustrer le diagramme: explication de contrles, itrations, logique, choix, Rappelons qu'un diagramme de squence bote noire est de la forme:

: Salari

Systme inform atique : magasin

login ( nom , m otpasse ) Le login est accept si le Lele login connu, et que salari login est accept si le salari est est accept si le est mot deet connu,est de salari p)asse et son connuest si son motson passe correct. de passe est correct est correct mot

message bienvenue

logout()

retour de la demande de login OK

vnement

Les valeurs de retour se formalisent de diffrentes manires suivant la version d'UML choisie. Ici j'ai pris un exemple de notation la plus simple possible. Attention ne pas confondre avec un vnement ( sens acteur vers systme informatique ). En fin de phase nous connaissons les changes entre les utilisateurs et le systme informatique. Nous pourrions construire une maquette des crans pour les acteurs. Formellement nous le ferons en phase de conception. Notre maquette d'cran serait une maquette "fonctionnelle" ( cest dire que le dessin de lcran nest pas fig ).

www.developpez.c.la Diagramme de squence bote noire du use case dtaill "effectuer des achats":

: Caissier pour chaque article

systme inform atique : magasin

enregistrer un article ( code ) description et prix article

si code rfrenc dnom brer ( quantit ) si quantit > 1 sous total = prix * quantit

fin de vente ( ) plus d'article prix total

payer ( somme ) monnaie ticket

ici la rponse est asynchrone

www.developpez.c.la

septime tape : diagramme de classe danalyse

Le diagramme de classes est un des documents les plus importants, voire le plus important de l'analyse d'un logiciel par une mthode objet. C'est le premier document qui est dans le monde des objets ( les acteurs n'tant pas forcment reprsents dans le systme informatique ). C'est donc l'entre dans le monde des objets. Ce diagramme est un diagramme de classe d'analyse. Il ne reprsente pas les classes Java ou C++ que nous dvelopperons par la suite. Ici nous nous intressons aux classes du domaine mtier, c'est dire des objets dont on parle dans le cahier des charges et dans les uses cases principalement. Nous ne nous intressons pas aux objets informatiques dans ce diagramme ( sauf bien entendu si le mtier est l'informatique !! ). Cela viendra en son temps, dans le diagramme de classe de conception. Quand nous passerons la conception des classes disparatront, d'autres apparatront, dont les classes informatiques ( collections, ). C'est normal. En phase d'analyse, nous voulons simplement faire un diagramme de classe d'objets manipuls dans le domaine mtier considr. Dans ce diagramme de classe les oprations ne sont pas reprsentes ( ce sera lors de la conception ). Ce diagramme montrera les concepts du domaine mtier, les liens ( associations ) entre ces concepts ( avec leur cardinalit ou multiplicit ), et les attributs de ces concepts ( souvent sous forme de donnes simples ). Le but de ce diagramme est de clarifier le domaine mtier du client, et de se familiariser avec ce domaine. Dans une analyse structure nous dcomposons l'analyse suivant les tches ou les fonctions. Dans une application dominante gestion, nous dcomposerons notre application suivant les donnes, et les traitements. Ici nous analyserons la complexit du domaine en regardant les objets mtier et leurs interactions entre eux. Comment identifier les bons objets mtier pour construire notre diagramme de classe d'analyse? Il va falloir recenser dans les documents de dfinition des besoins et dans les documents d'analyse l'ensemble des objets mtier. Les noms ou groupes nominaux vont tre de bons candidats pour tre lus au titre de classe, objet ou attribut. Cependant, il faut tre prudent car il y aura aussi un certain nombre de faux amis et de doublons. Voici une dmarche de slection des classes candidates: Par use case, nous raliserons un diagramme de classe, le diagramme final tant la superposition de tous ces diagrammes. Pour un use case nous recenserons les groupes nominaux rencontrs. Nous identifierons alors: Les classes ( noms communs ). Les objets ( noms propres ou nom rfrencs ). Les attributs ( donnes simples qui qualifient une classe ou un objet ). Les lments qui sont trangers notre problme ou qui n'y ont pas de rle rel.

www.developpez.c.la

Les " classes fonctionnelles " qui ne sont porteuses d'aucune information, mais seulement de traitement, qui ne sont souvent pas des classes de notre diagramme. Par exemple gestionnaire du planning, dcodeur de message,

Il est parfois difficile de savoir si une information est un attribut d'une classe ou une classe ( avec une association avec la classe ). Dans le doute il vaut mieux faire une classe, quitte revenir en arrire dans une itration ultrieure. Par exemple pour la classe personne l'ge est un attribut ( donne simple ) l'adresse tant priori une donne complexe sera plutt une autre classe associe la personne. Les entits suivantes peuvent prtendre devenir des classes : - les objets physiques (produit), - les transactions (rservation, commande,.), - les lignes de transaction (ligne de commande), - les conteneurs (catalogues, lots,), - les organisations (services, dpartements,.), - les acteurs ou les rles (client, fournisseur.), - les regroupements en abstraction (modle, genre, type, catgorie.), - les vnements (vol,)

Pour le use case " effectuer un achat " voici la liste des classes slectionnes:
caissier

caisse

Paiement

vente

catalogue

ticket article

ligne de vente

www.developpez.c.la Nous ne grerons pas les exemplaires des articles. Nous applerons article un ensemble dexemplaires identifis par le mme code barre, et comportant des informations identiques (prix ). Nous allons maintenant rajouter les associations entre les classes, en donnant un intitul et des cardinalits ces associations. Notre but n'est pas de mettre jour toutes les associations entre les diffrentes classes, mais de noter les associations pertinentes pour comprendre le problme. Il faut privilgier les associations qui durent dans le temps, et dont la connaissance est ncessaire la comprhension du problme. Il faut viter les associations redondantes ou drivables d'autres associations. L'tablissement de ces associations nous amne poser des questions au client. C'est un des buts recherchs. Voici une possibilit de diagramme de classe avec ses associations.

caissier 0..1 utilise 0..1 caisse se fait partir 1 Paiement 1 paye par 1 vente gnre 1 effectue 0..1 1 1 1

catalogue

1 contient comprend

ticket 1

1..* ligne de vente 0..* est dcrite par 1 0..* article

Sur ce diagramme de classe d'analyse il faut maintenant mettre les attributs des classes qui ont t reprs dans le cahier des charges, le diagramme de use case, ou dans le diagramme de squence bote noire du use case.

www.developpez.c.la

A priori, les attributs prsents dans notre diagramme de classe d'analyse sont des attributs simples. On pourra faire exception des donnes pures qui sont des regroupements de donnes simples ( ici code, adresse, prix ) . Les attributs qui ont un comportement sont des classes associes notre classe. Ceci ne prsage en rien du diagramme de classe de conception. Nous verrons ultrieurement ce que deviennent les associations dans ce schma Dans les attributs, il ne doit pas y avoir de clef sur un autre objet. Cela se reprsente par une association. Voici notre diagramme de classe enrichi des attributs d'analyse.
caissier 0..1 utilise 0..1 caisse 1 Paiement somme : rel 1 paye par 1 effectue 0..1 1 vente date : Date heure : Heure gnre ticket 1 contient 1 comprend 1..* ligne de vente quantit : entier 0..* est dcrite par 1 1 se fait partir 1

catalogue

le prix ou la somme devraient se donner par rapport une monnaie...

0..* description article description : text prix : rel code : codebarre

www.developpez.c.la

huitime tape : Le glossaire Le glossaire rpertorie tous les termes et leur dfinition. Il n'y a pas de graphisme particulier pour ce document. Il peut tre fait sous la forme suivante: terme Effectuer un achat Quantit catgorie Use case Attribut description C'est le processus que suit un client pour effectuer ses achats dans le magasin. C'est un attribut de la classe ligne de vente qui donne le nombre d'occurrences d'un mme article lors d'un achat. C'est la classe qui reprsente une vente en cours ou quand elle est finie.

Vente

Classe

www.developpez.c.la

neuvime tape : les contrats d'opration

Nous allons maintenant tudier ce qui est fait dans le systme, pour chaque flche qui attaque le systme dans les diagrammes de squence. Notre but est de comprendre la logique de fonctionnement du systme. Les flches reprsentes dans les diagrammes de squence bote noire dclenchent des oprations sur le systme. Nous allons donc dfinir prcisment le rle de ces oprations en nous appuyant sur le diagramme de classe ( appel aussi modle de domaine ). C'est ce qui s'appelle des contrats d'opration. Le systme informatique a t vu comme une bote noire ( en particulier travers les diagrammes de squence ). Il serait, d'un point de vue fonctionnel, intressant de dcrire ce que fait le systme, en se basant sur le diagramme de classe, sans pour autant dcrire comment il le fait. Les contrats d'opration vont nous permettre de dcrire les changements d'tats du systme ( c'est dire les changements sur les objets et leurs associations ) quand les oprations ( issues des diagrammes de squence ) sont invoques par les acteurs. Un contrat d'opration est un document textuel qui dcrit les changements provoqus par une opration sur le systme. Le contrat d'opration est crit sous forme textuelle et comporte des pr conditions et des post conditions. Les pr conditions dcrivent l'tat du systme ncessaire pour que l'opration puisse s'effectuer. Les post conditions dcrivent l'tat du systme lorsque l'opration s'est acheve. Contrat d'opration type: Nom: Responsabilits: Exigences: Notes: Pr conditions: Post conditions: Nom de l'opration avec ses paramtres. Description du rle de l'opration. Liste des exigences dont le use case tient compte dans cette itration. Remarques diverses. Etat ncessaire du systme pour que l'opration se fasse. Etat du systme lorsque l'opration s'est droule entirement.

Les Pr conditions dcrivent l'tat du systme, c'est--dire l'tat des objets du systme comme dcrit dans le diagramme des classes d'analyse. Nous jouons l'opration sur le systme, en aveugle, et jusqu' sa fin. Notons les changements de l'tat du systme ( des objets et de leurs associations ) et nous obtenons les post conditions. Ces post conditions sont dcrites sous la forme "has been", c'est-dire l'objet X a t modifi, son attribut Y a t mis vrai. Les post conditions portent sur 6 clauses: Les objets crs. Les objets dtruits. Les associations cres. Les associations dtruites. Les attributs modifis. Les vnements d'affichage ( fonctionnels bien sr !!! ).

www.developpez.c.la Prenons un exemple simple pour traiter ces contrats d'opration. Modifier le prix d'un article au catalogue. Nom: Responsabilits: Exigences: Notes: Pr conditions: Post conditions: modifier (cecode, nouveauprix). modifier le prix d'un article de code donn, prsent dans le catalogue. R1, R13, R14 pour le use case grer le catalogue. Si le code ne correspond pas a un article du catalogue, un message d'erreur sera envoy au manager et l'opration s'arrte. Il y a un article correspondant au code donn. l'attribut prix de l'objet description article, dont le code est cecode, a t chang par nouveauprix.