Upload
souriant
View
235
Download
0
Embed Size (px)
Citation preview
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.
7/31/2019 Demarche d Analyse Par Le Langage UML
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.
7/31/2019 Demarche d Analyse Par Le Langage UML
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.
7/31/2019 Demarche d Analyse Par Le Langage 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.
7/31/2019 Demarche d Analyse Par Le Langage UML
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.
7/31/2019 Demarche d Analyse Par Le Langage UML
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/31/2019 Demarche d Analyse Par Le Langage UML
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 :
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 :
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
7/31/2019 Demarche d Analyse Par Le Langage UML
8/35
www.developpez.c.la
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
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
7/31/2019 Demarche d Analyse Par Le Langage UML
9/35
www.developpez.c.la
nom : effectuer un achat
acteur principal : client
acteur secondaire : caissiervnement dclencheur :
rle du use case :
terminaison 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 de classe danalyse
Diagramme de classe danalyse
Diagramme dactivit
reprer les
classes
mettre les
associations
mettre mthodes
et attributs
7/31/2019 Demarche d Analyse Par Le Langage UML
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
7/31/2019 Demarche d Analyse Par Le Langage UML
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.
7/31/2019 Demarche d Analyse Par Le Langage UML
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.
7/31/2019 Demarche d Analyse Par Le Langage UML
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
7/31/2019 Demarche d Analyse Par Le Langage UML
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
7/31/2019 Demarche d Analyse Par Le Langage UML
15/35
7/31/2019 Demarche d Analyse Par Le Langage UML
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.
7/31/2019 Demarche d Analyse Par Le Langage UML
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
7/31/2019 Demarche d Analyse Par Le Langage UML
18/35
7/31/2019 Demarche d Analyse Par Le Langage UML
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
7/31/2019 Demarche d Analyse Par Le Langage UML
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.
7/31/2019 Demarche d Analyse Par Le Langage UML
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:
7/31/2019 Demarche d Analyse Par Le Langage UML
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.
7/31/2019 Demarche d Analyse Par Le Langage UML
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.
7/31/2019 Demarche d Analyse Par Le Langage UML
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.
7/31/2019 Demarche d Analyse Par Le Langage UML
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
7/31/2019 Demarche d Analyse Par Le Langage UML
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.
7/31/2019 Demarche d Analyse Par Le Langage UML
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
7/31/2019 Demarche d Analyse Par Le Langage UML
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
7/31/2019 Demarche d Analyse Par Le Langage UML
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.
7/31/2019 Demarche d Analyse Par Le Langage UML
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
7/31/2019 Demarche d Analyse Par Le Langage UML
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
7/31/2019 Demarche d Analyse Par Le Langage UML
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...
7/31/2019 Demarche d Analyse Par Le Langage UML
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.
7/31/2019 Demarche d Analyse Par Le Langage UML
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 !!! ).
7/31/2019 Demarche d Analyse Par Le Langage UML
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.