demarche d analyse par le langage uml

7/31/2019 Demarche d Analyse Par Le Langage UML

1/35

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.


2/35

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___________________________________________ 16troisime 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) Syntaxe du diagramme de collaboration _________________________ Erreur ! Signet non dfini.2) Visibilit des objets _________________________________________ Erreur ! Signet non dfini.3) GRASP patterns ___________________________________________ Erreur ! Signet non dfini.4) Diagramme de collaboration du magasin ________________________ Erreur ! Signet non dfini.

douzime tape : le diagramme de classe de conception ___________ Erreur ! Signet non dfini.1) Premire tape_____________________________________________ Erreur ! Signet non dfini.2) Deuxime tape____________________________________________ 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.

Notionditration___________________________________________ Erreur ! Signet non dfini.

conclusion_____________________________________________Erreur ! Signet non dfini.

bibliographie___________________________________________Erreur ! Signet non dfini.


3/35

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.


4/35

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 ensappuyant 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. prsentation

couche application ( workflow ) application

couche objets mtiers mtiercouche accs aux donnes accs aux donnes

couche base de 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.


5/35

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 etgraphique ) 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 dunedmarche 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 nousallons 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 puisles 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 sedroule 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 botenoire, o la bote noire correspond au systme informatique dvelopper ).

Faire un diagramme de classe par use case. Le diagramme de classe final sera lasuperposition 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, desresponsabilits, 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 decollaboration 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.


6/35

www.developpez.c.la

Nous raliserons enfin le diagramme de classe de conception, en tenant compte nouveaudes GRASP patterns. Ceci peut remettre en cause le diagramme de classe prcdemment

tabli.


7/35

www.developpez.c.la

nom : effectuer un achat

acteur principal : clientacteur secondaire : caissier

vnement dclencheur :

rle du use case :

terminaison du use case :


acteur principal : client

acteur secondaire : caissier


rle du use case :


rfrences croises :

pr conditions :

scnarios et alternatives :

nom :

responsabilit :

exigences :

notes :

pr conditions :

post conditions :

Diagramme de uses cases

A

N

A

L

YS

E

C

O

N

C

E

PT

I

O

N

D

E

F

I

N

IR

B

E

SO

I

N

S

Use case haut niveau

Use case bas niveau Diagramme de squence

Diagramme de classe danalyse Contrat dopration

Diagramme collaboration Diagramme de classe de conception

:caissier :magasin

:o1

:o2

1 : m()

1.1 : msg()

Processus simplifi


8/35

www.developpez.c.la



acteur secondaire : caissier


rle du use case :


Diagramme de uses cases

Use case haut niveau

Diagramme contexte statique

Processus de dfinition des besoins

Exigences Diagramme des acteurs

Diagramme contextedynamique

Intentions dacteurs

ref

R1

fonction

payer achat

magasin

payer

retourner

magasin

est dans

0..*

0..1

ref fonction intention acteur

Processus dtaill


9/35

www.developpez.c.la



acteur secondaire : caissiervnement dclencheur :

rle du use case :


rfrences croises :

pr conditions :

scnarios et alternatives :

nom :

responsabilit : exigences :

notes :

pr conditions :

post conditions :

Use case bas niveau

Diagramme de squence

Diagramme de classe danalyse

Contrat dopration

:caissier :magasin

Processus danalyse



Diagramme dactivit

reprer les

classes

mettre les

associations

mettre mthodes

et attributs


10/35

www.developpez.c.la

Diagramme dtat

Diagramme collaboration

Diagramme de classe de conception

:o1

:o2

1 : m()

1.1 : msg()

Processus de conception

attente

actif


11/35

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 dumagasin, 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.


12/35

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 unemeilleure 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'acteursqui nous donnerontles 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.

RfrenceFonction

R1 Modifier le prix d'un produit

R2 Calculer le total d'une vente

R3 Rentrer une quantit par article

R4 Calculer le sous total d'un produit

R5 Retourner une marchandise

R6 Payer l'achat

R7 Editer un ticket de vente

R8 Editer un rapport succinct

R9 Editer un rapport dtaill

R10 Se connecter la caisse

R11 Se connecter en grantR12 Dfinir les droits des usagers

R13 Entrer un produit au catalogue

R14 Supprimer un produit du catalogue

R15 Enregistrer un produit la caisse

R16 Initialiser la caisse

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.


13/35

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.

Caissier

from Use Cas e View)

Client

(from Use Cas e View)

Manager

(from Us e Case Vie

Administrateur

(from Us e Case View)

Salari

(from Us e Case View)

les acteurs de l'application


14/35

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 unepersonne.

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 decollaboration. Il reprsente le fonctionnement de l'entreprise. Ici nous ne prciserons pas

forcment l'ordre et le squencement des oprations.

Diagramme de contexte du magas in

magasin

: Client : Caissier

: Manager

: Administrateur

: Salari

se connecter

dfinir les droits des usagers

grer le catalogueinitialiser les caissesediter des rapports

grer un retour d'articlediter un ticketenregistrer un produitenregistrer une quantitgrer un paiement

retourner un articlepayer un achat


15/35


16/35

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 unefraction de service ).

Rfrence Fonction Intention d'acteur Acteurs

R1 Modifier le prix d'un produit Grer le catalogue Manager

R13 Entrer un produit au catalogue Grer le catalogue

R14 Supprimer un produit du catalogue Grer le catalogue

R16 Initialiser la caisse Initialiser la caisse Manager

R5 Retourner une marchandise Retourner un article Client, Caissier

R10 Se connecter la caisse Se connecter Salari

R11 Se connecter en grant Se connecter

R8 Editer un rapport succinct Editer un rapport ManagerR9 Editer un rapport dtaill Editer un rapport

R12 Dfinir les droits des usagers Dfinir les profils Administrateur

R7 Editer un ticket de vente Effectuer un achat Client, Caissier

R6 Payer l'achat Effectuer un achat

R2 Calculer le total d'une vente Effectuer un achat

R3 Rentrer une quantit par article Effectuer un achat

R15 Enregistrer un produit la caisse Effectuer un achat

R4 Calculer le sous total d'un produit Effectuer un achat

Ici dans le tableau la notion d'acteur repose sur l'intention d'acteur, pas sur la fonction. Ainsitoutes 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 ( swimlane ). Chaque colonne correspond un acteur. Cela nous permet de dfinir les

responsabilits des acteurs, donc de dfinir les uses cases correspondant.


17/35

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 certainnombre 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

Salari

Se connecter

Client

Retourner un article

Caissier

Grer le catalogue

Initialiser la caiss eManager

Editer un rapport

administrateur

Dfinir les profils

les flches unidirectionnellesindiquent un lien principal,c'est dire l'acteur principal duuse case.

Les flches unidirectionnellesindiquent un lien principal, cest

dire lacteur principal du use case


18/35


19/35

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.

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.

les us es cases retrait euros et retraitdollars hritent de retrait. Retrait est leuse case gnrique des retraitsd'argent. Ce use case es t abstrait, unacteur ne fait pas un retrait.

retrait euros retrait dollars

Retrait


20/35

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'estune 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: Effectuer un achatActeur principal: Client

Acteurs secondaires: Caissier

Evnement dclencheur du Use Case: Un client arrive la caisse avec ses achats

Rle du Use Case: Le caissier passe tous les articles, fait la note, et

encaisse le paiement.

Terminaison du Use Case: Le client a pay et a ramass tous ses articles.


21/35

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 exceptionnelset 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 intgreles 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 deprciser des lments prendre en compte lors de la ralisation des interfaces.

Contraintes non fonctionnelles ( optionnel ): Ici nous prendrons en compte lesdimensionnements, 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:


22/35

www.developpez.c.la

Actions des acteurs Rponses du systme1. L'acteur principal fait 2. Le systme lui envoie

3. L'acteur principal calcule

4. L'acteur secondaire traite 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: Effectuer un achat

Acteur principal: Client

Acteurs secondaires: Caissier

Evnement dclencheur du Use Case: Un client arrive la caisse avec ses achats

Rle du Use Case: Le caissier passe tous les articles, fait la note, et

encaisse le paiement.

Terminaison du Use Case: Le client a pay et a ramass tous ses articles.

Les rfrences croises des exigences: R2, R3, R4, R6, R7, R15

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.


23/35

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 cesinformations 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

n'y a plus d'article.

5) Le systme calcule et affiche le montant

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

le client.

9) Le systme calcule la somme rendre au

client.

10) Le caissier encaisse la somme remise par

le client et rend la monnaie au client.

11) Le systme enregistre la vente effectue

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 lacaisse 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.


24/35

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 Rponses du systme

1) Le client arrive la caisse

avec les articles qu'il dsireacheter.

2) Le caissier enregistre

chaque article.

3) Le systme dtermine le

prix de l'article, lesinformations 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 n'y a plus

d'article.

5) Le systme calcule et

affiche le montant total de

l'achat.

6) Le caissier annonce au

client le montant total.

7) Le client donne au caissierune somme d'argent

suprieure ou gale la

somme demande.

8) Le caissier enregistre lasomme donne par le client.

9) Le systme calcule lasomme rendre au client.

10) Le caissier encaisse la

somme remise par le client et

rend la monnaie au client.

11) Le systme enregistre la

vente effectue

12) Le systme dite le ticket

de caisse

13) Le caissier donne le ticket

de caisse au client14) 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.


25/35

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.

Note : Ceci reprsente un commentaire dans tout schma UML.

sais ir les infos du produit vrifier le code

saisir le code vrifier le code

dtruire la rfrence

sais ir et valider le prix

enregistrer le produit

modifier le prixd'un article

supprimer unarticle

ajouter unarticle

ralisation d'un diagramme d'activit ( ici ce n'est pas la norme UML car la versionde rose utilise ne s upporte pas les diagram mes d'activit ). Ce schma a tconstruit partir d'un diagramme d'tat.

commentaire


26/35

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.


27/35

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:

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 unemaquette "fonctionnelle" ( cest dire que le dessin de lcran nest pas fig ).

retour de la demandede login OK

: SalariSystme informatique

: magasin

login ( nom, motpasse )

logout()

Le login es t accept si lesalari es t connu, et queson mot de p)asse estcorrect.

vnement

mes sage bienvenue

le login est accept si le

salari est connu, et son

mot de passe est correct

Le login est accept si le salari

est connu et si son mot de passe

est correct


28/35

www.developpez.c.la

Diagramme de squence bote noire du use case dtaill "effectuer des achats":

ici la rponseest asynchrone

: Caissiersystme informatique

: magasin

enregis trer un article ( code )

pour chaquearticle

description et prix article

dnombrer ( quantit )

si quantit > 1

si coderfrenc

sous total = prix * quantit

fin de vente ( )

prix totalplus d'article

payer ( somme )

monnaie

ticket


29/35

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 mondedes 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 lesdonnes, 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.


30/35

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

vente

caisse

Paiement

catalogue

article

ligne de vente

ticket


31/35

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.

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 desquence bote noire du use case.

caissier

0..1

0..1

caisse

0..1

0..1

utilise

0..1

1..*

Paiement 1

1

ticket1

1

0..*

ligne de vente

1

0..*1

1

1

vente

1

0..1

effectue

1..*

1

comprend

1

1

paye par

1

1gnre

catalogue

11

1

se fait partir

1

1

article

1

0..*

est dcrite par

0..*

contient


32/35

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 quedeviennent 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

0..1

caisse

0..1

0..1

utilise

0..1

1..*

Paiement

somme : rel 1

1

ticket1

1

0..*

ligne de vente

quantit : entier

1

0..*1

1

1

vente

date : Dateheure : Heure

1

0..1effectue

1..*

1

comprend

1

1

paye par

1

1gnre

catalogue

11

1

se fait partir

1

1

description articledescription : textprix : relcode : codebarre

1

0..*

est dcrite pa0..*

contient

le prix ou lasomme devraientse donner parrapport unemonnaie...


33/35

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 catgorie description

Effectuer un achat Use case C'est le processus que suit un client pour effectuer

ses achats dans le magasin.

Quantit Attribut C'est un attribut de la classe ligne de vente qui

donne le nombre d'occurrences d'un mme article

lors d'un achat.

Vente Classe C'est la classe qui reprsente une vente en cours ou

quand elle est finie.


34/35

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 lesoprations ( 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: Nom de l'opration avec ses paramtres.

Responsabilits: Description du rle de l'opration.

Exigences: Liste des exigences dont le use case tient compte dans cetteitration.

Notes: Remarques diverses.

Pr conditions: Etat ncessaire du systme pour que l'opration se fasse.

Post conditions: 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 !!! ).


35/35

www.developpez.c.la

Prenons un exemple simple pour traiter ces contrats d'opration.

Modifier le prix d'un article au catalogue.

Nom: modifier (cecode, nouveauprix).

Responsabilits: modifier le prix d'un article de code donn, prsent dans lecatalogue.

Exigences: R1, R13, R14 pour le use case grer le catalogue.

Notes: Si le code ne correspond pas a un article du catalogue, unmessage d'erreur sera envoy au manager et l'opration s'arrte.

Pr conditions: Il y a un article correspondant au code donn.

Post conditions: l'attribut prix de l'objet description article, dont le code estcecode, a t chang par nouveauprix.

demarche d analyse par le langage uml

Documents