UML - Cas Complet - Démarche D'analyse Et de Conception Avec Le Langage UML Par JC CORRE

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.
JC CORRE
Grenoble Le Pont de Claix
25/10/2011
Index
Dmarche danalyse et de conception avec le langage UML ______________________ 1 Index _____________________________________________________________________ 2 Prambule _________________________________________________________________ 3 Objectif global dune dmarche danalyse et de conception objet _____________________ 4 Les tapes de la dmarche ____________________________________________________ 5 Exemple trait _____________________________________________________________ 11 Dfinition des besoins ______________________________________________________ 12
premire tape : les exigences et les acteurs ________________________________________ 12 deuxime tape : les intentions dacteurs __________________________________________ 16 troisime tape : le diagramme de use case _________________________________________ 17 quatrime tape : use case description de haut niveau ________________________________ 20
L'analyse _________________________________________________________________ 21
cinquime tape : use case description de bas niveau_________________________________ 21 septime tape : diagramme de classe danalyse_____________________________________ 29 huitime tape : Le glossaire _____________________________________________________ 33 neuvime tape : les contrats d'opration __________________________________________ 34
La conception _____________________________________________________________ 40
dixime tape : le diagramme dtat ______________________________________________ 40 onzime tape : le diagramme de collaboration _____________________________________ 42
1) 2) 3) 4) 1) 2) Syntaxe du diagramme de collaboration _____________________________________________ Visibilit des objets _____________________________________________________________ GRASP patterns _______________________________________________________________ Diagramme de collaboration du magasin ____________________________________________ 42 49 51 57
douzime tape : le diagramme de classe de conception ______________________________ 61

Premire tape _________________________________________________________________ 61 Deuxime tape ________________________________________________________________ 62
Le processus unifi _________________________________________________________ 69

Notion de lot ( ou de cycle ) ______________________________________________________ 69 Notion de phases ______________________________________________________________ 69 Notion ditration______________________________________________________________ 71
conclusion ________________________________________________________________ 73 bibliographie ______________________________________________________________ 74
JC CORRE
25/10/2011
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.
JC CORRE
25/10/2011
Objectif global dune dmarche danalyse et de conception objet

Le but de cette dmarche est danalyser et de concevoir une application objet. Lobjectif est davoir une application qui puisse vivre ( volution de lapplication dans le temps ), et qui enrichisse la base de savoir-faire de lentreprise ( dveloppement de nouveaux applicatifs en sappuyant sur des objets mtiers dj dvelopps ) . La rutilisabilit est un des soucis principaux pour pouvoir rduire le cot des logiciels et augmenter la puissance de dveloppement des programmeurs. Nous nous appuierons sur le workflow, cest dire les rgles des processus mtier pour dbusquer les uses cases, et les acteurs. Dans lanalyse et la conception objet nous cherchons construire une architecture en couche de la forme suivante : couche I.H.M. couche application ( workflow ) couche objets mtiers couche accs aux donnes couche base de donnes prsentation application mtier accs aux donnes base de donnes
Nous verrons que chaque couche dfinira un ou des contrleurs pour la rendre indpendante des autres. Une tude a montr que dans certaines entreprises les rgles mtier changeaient de 10% par mois ! ! ! Il est facile de comprendre alors la raison de ce dcouplage des objets mtiers. Les objets ont tendance tre stables dans le temps, par contre les IHM et base de donnes peuvent galement tre changes sans que lon touche au mtier ni aux rgles de lentreprise. Cette architecture ne sappliquera bien sr pas toutes les applications, cest prendre comme un exemple complet.
JC CORRE
25/10/2011
Les tapes de la dmarche

Ce chapitre est un rsum du processus de dveloppement dune application. Il est difficile de comprendre ce rsum, sans avoir lu en dtail et expriment chacun des chapitres auquel il fait rfrence. Par contre je vous conseille de revenir souvent ce rsum ( textuel et graphique ) pour bien vous situer dans la dmarche, avant ltude de tout nouveau chapitre. Lister lensemble des exigences du client issues du cahier des charges, ou issu dune dmarche pralable de collecte dinformation ( documents lectroniques, notes de runions, notes dinterviews, ). Chaque exigence sera numrote et ainsi pourra tre trace. Deux solutions possibles : Nous allons regrouper les exigences par intentions dacteur compltes puis nous allons faire un diagramme de contexte ( nous nous appuierons sur un diagramme de collaboration pour cela ) Si toutes les rgles de processus mtier sont dfinies, nous raliserons un diagramme dactivit en colonnes ( "swim lane" ) o les colonnes sont les acteurs. Cela permet de dgager les responsabilits de chaque acteur, et ainsi de connatre les intentions des acteurs. Dfinir les uses cases et construire le diagramme de uses cases. Faire la description de haut niveau de chaque use case : chercher des scnarios de base. Faire la description dtaille de chaque use case : donner les squences nominales puis les squences alternatives ( Erreurs et exceptions, en limitant au maximum les exceptions). Cette description peut tre complte par un diagramme dactivit qui montre le squencement des diffrents scnarios. Cette description dtaille comprend les scnarios, les pr conditions, partir de quoi se droule le use case, comment se termine le use case, et enfin les post conditions ( rgles mtier assures quand le use case est termin). Faire un diagramme de squence par scnario ( ici cest un diagramme de squence bote noire, o la bote noire correspond au systme informatique dvelopper ). Faire un diagramme de classe par use case. Le diagramme de classe final sera la superposition de ces diagrammes de classe. Les classes obtenues sont des classes du monde rel. Nous ne mettons pas les oprations car nous ne connaissons pas lintrieur du systme informatique. Un contrat est ralis pour chaque opration du systme. Ce contrat contient un nom, des responsabilits, les exigences auxquelles rpond notre itration de cycle de vie, les pr conditions, et les post conditions ( dcrites sous la forme " has been " ) et enfin les exceptions. Ce contrat peut tre ralis sous forme textuelle, ou plus souvent sous forme dun diagramme de squence bote blanche o les objets changent des messages pour rendre le service demand. A partir des diagrammes de classe et des contrats nous raliserons les diagrammes de collaboration qui montrent comment les objets collaborent pour rendre le service demand. Nous appliquerons les patterns de conception pour cela ( GRASP patterns ) En parallle nous raliserons les diagrammes dtat des objets les plus complexes, ainsi nous dtecterons des mthodes internes ces objets.
JC CORRE
25/10/2011
Nous raliserons enfin le diagramme de classe de conception, en tenant compte nouveau des GRASP patterns. Ceci peut remettre en cause le diagramme de classe prcdemment tabli.
JC CORRE
25/10/2011
Processus simplifi
D E F I N I R B E S O I N S nom : effectuer un achat acteur principal : client acteur secondaire : caissier vnement dclencheur : rle du use case : terminaison du use case :
Diagramme de uses cases
Use case haut niveau
A N A L Y S E
nom : effectuer un achat acteur principal : client acteur secondaire : caissier vnement dclencheur : rle du use case : terminaison du use case : rfrences croises : pr conditions : scnarios et alternatives :
:caissier
:magasin
Use case bas niveau
Diagramme de squence
nom : responsabilit : exigences : notes : pr conditions : post conditions :
Diagramme de classe danalyse
Contrat dopration
C O N C E P T I O N
1 : m()
:o1 1.1 : msg() :o2
Diagramme collaboration
Diagramme de classe de conception
JC CORRE
25/10/2011
Processus de dfinition des besoins
ref R1
fonction payer achat
Exigences
Diagramme des acteurs
payer retourner
0..* est dans 0..1 magasin
magasin Diagramme contexte dynamique
Diagramme contexte statique
ref
fonction
intention
acteur
Intentions dacteurs
Diagramme de uses cases
nom : effectuer un achat acteur principal : client acteur secondaire : caissier vnement dclencheur : rle du use case : terminaison du use case :
Use case haut niveau
JC CORRE
25/10/2011
Processus danalyse
nom : effectuer un achat acteur principal : client acteur secondaire : caissier vnement dclencheur : rle du use case : terminaison du use case : rfrences croises : pr conditions : scnarios et alternatives :
Use case bas niveau
Diagramme dactivit
:caissier
:magasin
reprer les classes
Diagramme de squence
mettre les associations
mettre mthodes et attributs
nom : responsabilit : exigences : notes : pr conditions : post conditions :
Contrat dopration
JC CORRE Grenoble Le Pont de Claix 25/10/2011 9
Processus de conception
attente
actif
Diagramme dtat
1 : m()
:o1 1.1 : msg() :o2
Diagramme collaboration
Diagramme de classe de conception
JC CORRE
25/10/2011
10
Exemple trait
Nous allons traiter l'ensemble de la dmarche d'analyse objet sur un mme exemple. Cet exemple a t pris dans la littrature ( voir la bibliographie ). Nous ne traiterons pas l'ensemble de l'exemple, mais l'ensemble de la dmarche. Ralisation d'une caisse informatise. Un commerant de produits touristiques ( souvenirs, livres rgionaux, ...) dsire informatiser sa caisse. Chaque type de produit possde un code unique ( tiquette code barres ), et un mme prix pour tous les produits de ce type. L'objectif est de faciliter la maintenance des prix des articles. Chaque type de produit est rfrenc dans un catalogue, avec son prix associ. Quand le prix d'un produit doit tre modifi, le manager modifie son prix dans le catalogue, puis sur l'tagre o il est rang. Le caissier s'identifie pour dmarrer la caisse ( avec mot de passe ). La caisse fera les fonctions habituelles d'une caisse : calcul du sous total, calcul du total, possibilit de rentrer plusieurs articles ayant un mme code, retour d'une marchandise avec le ticket de caisse. Le paiement se fera en monnaie seulement. La caisse permet d'diter des rapports : Le reu qui sera donn uniquement pour une vente effective. Il contient le nom du magasin, un message de bienvenue, la date et l'heure. Puis pour chaque vente il donne le code du produit, la description du produit, le prix unitaire, la quantit et le sous total. Enfin nous y trouvons le total TTC. Le rapport quotidien de l'ensemble des ventes ( date, heure, total ). Le rapport quotidien dtaill: liste de l'ensemble dtaill des ventes de la journe. La caisse s'excute sur un PC. Une douchette permettra de lire les codes barres. Les informations peuvent tre rentres au clavier, ou la souris.
JC CORRE
25/10/2011
11
Dfinition des besoins

Pour bien comprendre le fonctionnement du logiciel, et son interaction avec son environnement, nous avons intrt travailler non pas sur le logiciel demand, mais sur le fonctionnement intgral du processus d'entreprise ( workflow ). Ainsi nous aurons une meilleure approche du logiciel. Ainsi nous considrerons l'ensemble des acteurs qui interagissent sur le processus d'entreprise, mme s'ils n'agissent pas sur le logiciel lui-mme. Cela permettra de dterminer les intentions d'acteurs qui nous donneront les uses cases. La dfinition des besoins dmarre avec le dbut du projet. Elle a pour but d'obtenir un premier jet des besoins fonctionnels et oprationnels du client. Dans cette phase nous collectons des informations pour dfinir le besoin du client. A l'issue de cette tape, nous aurons mis textuellement ou l'aide de schmas trs simples, notre comprhension du problme traiter sur le papier. Le client doit tre capable de valider l'tude ainsi faite. Elle lui est donc accessible. premire tape : les exigences et les acteurs Les exigences que nous allons dcouvrir sont les exigences fonctionnelles. A partir du problme pos, c'est dire de tout ce qui est crit, plus tout ce qui ne l'est pas, nous allons lister l'ensemble des fonctions qui pourront tre ralises par le logiciel. Ces exigences seront numrotes pour pouvoir les tracer dans les intentions d'acteur puis dans les uses cases. Fonction Modifier le prix d'un produit Calculer le total d'une vente Rentrer une quantit par article Calculer le sous total d'un produit Retourner une marchandise Payer l'achat Editer un ticket de vente Editer un rapport succinct Editer un rapport dtaill Se connecter la caisse Se connecter en grant Dfinir les droits des usagers Entrer un produit au catalogue Supprimer un produit du catalogue Enregistrer un produit la caisse Initialiser la caisse
Rfrence R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15 R16
Dans la rfrence R veut dire Requirement ( c'est 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.
JC CORRE
25/10/2011
12
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 Case View)
Client (from Use Case View)
Manager (from Use Case View
Salari (from Use Case View)
Administrateur (from Use Case View)
les acteurs de l'application
JC CORRE
25/10/2011
13
Ce diagramme est un diagramme de classe qui permet de lister les diffrents acteurs. Il se peut que notre liste ne soit pas complte, une itration suivante du processus nous permettra de complter ce schma.
Nous avons dfini 5 acteurs. N'oublions pas qu'un acteur reprsente un rle, et non pas une personne. Le Manager peut tre aussi l'Administrateur ( notion de rle ). Un Salari est soit un Caissier, soit le Manager. Il se peut que dans la premire itration l'analyste ne remarque pas ceci. C'est souvent dans une itration ultrieure que nous verrons les gnralisations d'acteurs. Nous connaissons les acteurs, et les exigences de l'application. Nous pouvons donc faire un diagramme de contexte dynamique. Ce diagramme de contexte qui dfinit les interactions entre les acteurs et le systme ( pas encore systme informatique car nous en sommes au processus mtier donc dcouvrir les uses cases ) sera ralis en UML par un diagramme de collaboration. Il reprsente le fonctionnement de l'entreprise. Ici nous ne prciserons pas forcment l'ordre et le squencement des oprations.
grer un retour d'article diter un ticket enregistrer un produit enregistrer une quantit grer un paiement
: Client
: Caissier
retourner un article payer un achat magasin grer le catalogue initialiser les caisses editer des rapports
se connecter dfinir les droits des usagers : Manager : Salari
: Administrateur
Diagramm e de contexte du magasin
JC CORRE
25/10/2011
14
Nous pouvons aussi en complment tracer un diagramme de classe des acteurs du systme pour prciser les cardinalits des diffrents acteurs du systme. Nous utiliserons alors un diagramme de classes de UML. Ce diagramme s'appelle un diagramme de contexte statique.
0..* Client from Use Case View) est dans est la caisse 1 Caissier
(from Use Case View)
0..1 0..1 magasin 0..* travaille dans 0..* 1..* 0..* gre
administre 1
1 Salari (from Use Case View)
Manager (from Use Case View
administrateur (from Use Case View)
Diagramme de contexte statique (capture initiale des besoins)
JC CORRE
25/10/2011
15
deuxime tape : les intentions dacteurs
Nous allons maintenant regrouper les exigences en intentions d'acteurs. Une intention d'acteur est un enchanement de fonctions qui rend un service complet un acteur ( et pas une fraction de service ). Rfrence R1 R13 R14 R16 R5 R10 R11 R8 R9 R12 R7 R6 R2 R3 R15 R4 Fonction Modifier le prix d'un produit Entrer un produit au catalogue Supprimer un produit du catalogue Initialiser la caisse Retourner une marchandise Se connecter la caisse Se connecter en grant Editer un rapport succinct Editer un rapport dtaill Dfinir les droits des usagers Editer un ticket de vente Payer l'achat Calculer le total d'une vente Rentrer une quantit par article Enregistrer un produit la caisse Calculer le sous total d'un produit Intention d'acteur Grer le catalogue Grer le catalogue Grer le catalogue Initialiser la caisse Retourner un article Se connecter Se connecter Editer un rapport Editer un rapport Dfinir les profils Effectuer un achat Effectuer un achat Effectuer un achat Effectuer un achat Effectuer un achat Effectuer un achat Acteurs Manager
Manager Client, Caissier Salari Manager Administrateur Client, Caissier
Ici dans le tableau la notion d'acteur repose sur l'intention d'acteur, pas sur la fonction. Ainsi toutes les lignes d'une mme intention d'acteur ne sont-elles pas renseignes pour les acteurs. Ici nous distinguerons l'acteur principal des acteurs secondaires en soulignant l'acteur qui est l'origine de l'intention. Nous allons bien sr vrifier que les exigences dfinies prcdemment sont toutes incluses dans les intentions d'acteur. La traabilit est un facteur essentiel des phases de dfinition des besoins et de celle d'analyse. Nous avons les intentions d'acteurs, nous pouvons donc faire un diagramme de Use Case. Toute cette dmarche peut tre faite d'une autre manire: Nous dterminons les acteurs et les exigences A partir des exigences nous faisons un diagramme d'activit ( UML ) en colonnes ( swim lane ). Chaque colonne correspond un acteur. Cela nous permet de dfinir les responsabilits des acteurs, donc de dfinir les uses cases correspondant.
JC CORRE
25/10/2011
16
troisime tape : le diagramme de use case Un use case est une intention d'acteur. Quand un acteur dmarre un use case, il a une intention prcise. Quelle est cette intention? Effectuer un achat est une intention qui recouvre un certain nombre d'exigences. C'est une unit d'intention complte d'un acteur: c'est donc un use case. Payer ses achats n'est pas une intention complte d'acteur. Nous n'allons pas dans un magasin pour payer, mais bien pour faire des achats. C'est donc une partie ( et pas la plus agrable ) de effectuer un achat. Ce n'est donc pas un use case. L'acteur dclencheur de l'achat est le client. C'est lui qui est venu effectuer un achat. Le diagramme de uses cases est la reprsentation graphique du tableau d'intention d'acteurs prcdent. Diagramme de use case
Effectuer un achat
Client Retourner un article
Se connecter
Caissier
les flches unidirectionnelles Les flches unidirectionnelles indiquent un lien principal, indiquent un lien principal, cest c'est dire l'acteur principal du dire lacteur use case. principal du use case
Grer le catalogue
Salari
Manager
Initialiser la caisse
Editer un rapport
administrateur Dfinir les profils
JC CORRE
25/10/2011
17
Quand nous dfinissons les uses cases, il faut faire extrmement attention la notion de point de vue. Pour le magasin le client est un acteur essentiel. Par rapport au systme informatique ce n'est pas un acteur. L'acteur qui est en interface avec le systme informatique est souvent le caissier, mais jamais le client. Nous voulons dfinir le systme informatique du magasin, pour cela il faut partir de l'ensemble des acteurs qui gravitent autour du magasin, sinon nous risquons d'oublier un certain nombre de fonctionnalits. Le fait de retourner un article est un souci du client, pas du caissier. Si nous ne prenons le point de vue que du systme informatique nous risquons de ne pas penser ce problme. Dans la phase d'analyse nous dlimiterons le systme informatique dans le processus global du magasin. Le schma de uses cases peut faire apparatre: Des fonctionnalits bien prcises qui se retrouvent parmi plusieurs uses cases. Nous parlerons alors de use case included ou subalterne. Un tel use case ne peut tre li qu' un use case, pas un acteur. ( nous mettrons alors le strotype include sur le lien use case vers use case subalterne ).
avoir solde
retrait <<include>> <<include>>
exem ple de use case subalterne pour un guichet autom atique de banque
authentification
Un use case peut ncessiter le service d'un autre use case. Le use case dont nous avons besoin du service tend le use case demandeur. Nous utiliserons le strotype extend. Ici les uses cases peuvent tre sollicits par des acteurs.
<<extend>>
gestion comm ande
gestion client
exem ple de use case tendu pour un systme de gestion de com mande. Quand nous rentrons une com mande, il faut pouvoir crer le client s'il n'existe pas.
JC CORRE
25/10/2011
18
Nous pouvons avoir des cas de spcialisation de cas d'utilisation. Plusieurs uses cases peuvent avoir une trame commune et donc hriter d'un use case parent et abstrait.
retrait euros les uses cases retrait euros et retrait dollars hritent de retrait. Retrait est le use case gnrique des retraits d'argent. Ce use case est abstrait, un acteur ne fait pas un retrait.
retrait dollars
Retrait
Ces spcialisation, include et extend ne se mettent bien souvent pas dans le premier cycle de dveloppement, car c'est l'tude de l'application qui mettra en vidence ces caractristiques. Nous verrons plus tard ces notions de cycle dans le droulement dune dmarche comme celle-ci.
JC CORRE
25/10/2011
19
quatrime tape : use case description de haut niveau Il nous faut maintenant dfinir les uses cases. Cette description est une description de haut niveau qui se fait avant l'analyse. Nous sommes toujours dans la dfinition du besoin. Une description de haut niveau d'un use case est une description textuelle qui comprend les chapitre suivants: Nom du Use Case: Acteur principal: Acteurs secondaires: Evnement dclencheur du Use Case: Rle du Use Case: Terminaison du Use Case: Cette description est assez succincte 3 ou 4 lignes maximum pour le rle du use case. C'est une description narrative d'un processus mtier. Cette description ne repose pas sur la technologie objet. Les cas d'utilisation ( autre nom pour un use case ) vus dans l'analyse sont dits essentiels. Ici nous ferons donc la description de cas d'utilisation de haut niveau essentiels. Essentiel signifie que l'on ne fait pas rfrence la technologie, que le use case dcrit le cur du mtier, ils sont appels use case pour 100 ans. De haut niveau veut dire que l'on en fait une description brve, sans entrer dans le dtail du squencement du use case. Nous verrons par la suite des uses cases dtaills ( en phase d'analyse ), et des uses cases rels ( en phase de conception ). Description d'un use case essentiel de haut niveau: Nom du Use Case: Acteur principal: Acteurs secondaires: Evnement dclencheur du Use Case: Rle du Use Case: Terminaison du Use Case: Effectuer un achat Client Caissier Un client arrive la caisse avec ses achats Le caissier passe tous les articles, fait la note, et encaisse le paiement. Le client a pay et a ramass tous ses articles.
JC CORRE
25/10/2011
20
L'analyse
Aprs une premire bauche des besoins des clients, il va falloir approfondir ses besoins, examiner les diffrents scnarios des uses cases ( ventuellement avec un diagramme d'activit pour exprimer ces diffrents scnarios ), tenir compte des traitements exceptionnels et cas d'erreur. Il va tre ncessaire de regarder le squencement des oprations d'un point de vue fonctionnel, pour voir comment les diffrents acteurs interagissent avec le logiciel, laide des diagrammes de squence bote noire ( la bote noire c'est le systme informatique dvelopper ). Il est alors ncessaire de distinguer les diffrents objets qui collaborent dans notre systme informatique ( avec un diagramme de classe ). Enfin nous allons dtailler le rle des oprations en dfinissant des contrats d'opration ( soit sous forme textuelle, soit sous forme de diagramme de squence ). Nous aurons alors tous les lments pour passer la conception. Nous n'avons ici comme souci que de dtailler les besoins du client pour s'en imprgner, afin de pouvoir le formaliser et le prciser. cinquime tape : use case description de bas niveau La description dtaille d'un use case permet de bien dcrire les enchanements des services rendus par le logiciel pour un usage prcis. N'oublions pas que nous restons au niveau essentiel, c'est dire que nous ne donnerons pas de solution au problme, nous ne faisons que prciser sa description. Nous sommes toujours dans l'espace du problme, pas dans celui de la solution. Une description dtaille de use case comprend: Nom du Use Case: Acteur principal: Acteurs secondaires: Evnement dclencheur du Use Case: Rle du Use Case: Terminaison du Use Case: Les rfrences croises des exigences: Les pr conditions ncessaires au fonctionnement du use case: Description complte du use case, avec les diffrents scnarios: Cette description intgre les cas d'erreur ( traits par le use case ) et les exceptions ( forant la sortie du use case ). Contraintes d'IHM ( optionnel ): Attention de ne pas dcrire l'interface ici, mais bien de prciser des lments prendre en compte lors de la ralisation des interfaces. Contraintes non fonctionnelles ( optionnel ): Ici nous prendrons en compte les dimensionnements, les performances attendues, Ceci permettra de mieux valuer les contraintes techniques. La description complte du use case donne la priorit aux choses que les acteurs peroivent. Nous dcrirons les actions des acteurs en commenant par l'acteur principal qui initie le use case, puis nous donnerons les rponses du systme ( vu comme une bote noire ). Le premier travail se fait sur un cas nominal ( c'est dire idal ). Les cas d'erreur ( avec correction et reprise ) et les exceptions ( avec abandon du use case ) sont traits ensuite. Le formalisme est textuel et prend la forme suivante:
JC CORRE
25/10/2011
21
Actions des acteurs 1. L'acteur principal fait 3. L'acteur principal calcule 4. L'acteur secondaire traite
Rponses du systme 2. Le systme lui envoie 5. Le systme envoie le compte rendu
Traitement des cas d'erreur et d'exception: A l'tape 2 si le code de alors le systme renvoie un message et l'acteur principal refait A l'tape 4 si alors le systme affiche et le use case s'arrte En premier lieu nous voyons les changes entre le systme et les acteurs, ainsi que la chronologie et l'enchanement des actions, dans le cas nominal. Dans un deuxime temps nous listons les cas d'erreur ( avec traitement de rcupration ) et les traitements d'exception avec arrt du use case. Nous restons bien fonctionnel car nous ne dcrivons pas comment est ralis le systme, mais comment sont raliss les services qu'il rend. Notion de scnario: un use case est un regroupement d'actions plus lmentaires qui permet de traiter une intention d'acteur assez gnrale. Un scnario est une ralisation du use case, donc une "intention lmentaire". Par exemple pour une gestion de compte client dans une banque, nous avons un use case grer les comptes. Nous avons plusieurs scnarios: crer un compte, consulter un compte, modifier un compte, Pour chacun des scnarios il va falloir faire une description dtaille de use case ( avec traitement d'erreur et d'exception pour chacun ). Un diagramme d'activit va permettre de montrer l'ensemble d'un use case, en regroupant l'ensemble des scnarios de ce use case. Exemple de description d'un use case ( effectuer un achat ): Nom du Use Case: Acteur principal: Acteurs secondaires: Evnement dclencheur du Use Case: Rle du Use Case: Effectuer un achat Client Caissier Un client arrive la caisse avec ses achats Le caissier passe tous les articles, fait la note, et encaisse le paiement. Le client a pay et a ramass tous ses articles. R2, R3, R4, R6, R7, R15
Terminaison du Use Case: Les rfrences croises des exigences:
Les pr conditions ncessaires au fonctionnement du use case: La caisse est allume et initialise. Un caissier est connect la caisse. Description complte du use case, avec les diffrents scnarios: Ici il n'y a qu'un scnario possible. Nous verrons dans l'exemple suivant un use case avec plusieurs scnarios pour mettre en vidence le diagramme d'activit.
JC CORRE
25/10/2011
22
Actions des acteurs Rponses du systme 1) Le client arrive la caisse avec les articles qu'il dsire acheter. 2) Le caissier enregistre chaque article. 3) Le systme dtermine le prix de l'article, les informations sur l'article et ajoute ces informations la transaction en cours. Il affiche ces informations sur l'cran du client et du caissier. 4) Le caissier indique la fin de vente quand il 5) Le systme calcule et affiche le montant n'y a plus d'article. total de l'achat. 6) Le caissier annonce au client le montant total. 7) Le client donne au caissier une somme d'argent suprieure ou gale la somme demande. 8) Le caissier enregistre la somme donne par 9) Le systme calcule la somme rendre au le client. client. 10) Le caissier encaisse la somme remise par 11) Le systme enregistre la vente effectue le client et rend la monnaie au client. 12) Le systme dite le ticket de caisse 13) Le caissier donne le ticket de caisse au client 14) le client s'en va avec les articles qu'il a achets. Variantes du scnario nominal ( celui qui se droule quand tout se passe bien ). Paragraphe 2: il peut y avoir plusieurs articles d'un mme produit. Le caissier enregistre le produit ainsi que le nombre d'articles. Paragraphe 3: s'il y a plusieurs articles d'un mme produit le systme calcule le sous total. Paragraphe 2: Le code produit peut tre invalide. Le systme affiche un message d'erreur. Paragraphe 7: Le client n'a pas la somme d'argent suffisante. La vente est annule. Remarque: Ceci est une exception qui termine anormalement le use case. Paragraphe 8: Le caissier n'a pas la monnaie pour rendre au client. Il va faire la monnaie la caisse principale. Remarque: ici nous avons fait apparatre un nouvel acteur: le caissier principal ( ce sera probablement la mme personne que le manager mais un acteur diffrent ). Paragraphe 12: le systme ne peut pas diter le ticket de caisse. Un message est affich au caissier, et celui-ci change le rouleau de papier. Paragraphe 14: remarquons que si le client repart sans ses articles, il est probable que le caissier les lui mettra de cot. Cet vnement ne change rien notre systme futur. Ce genre d'incident ne sera pas pris en considration.
JC CORRE
25/10/2011
23
En terme de reprsentation nous pouvons prfrer mettre une colonne par acteur pour bien voir les responsabilits des acteurs vis vis du systme. Ici cela donnerait: Actions du client Actions du caissier 1) Le client arrive la caisse 2) Le caissier enregistre avec les articles qu'il dsire chaque article. acheter. Rponses du systme 3) Le systme dtermine le prix de l'article, les informations sur l'article et ajoute ces informations la transaction en cours. Il affiche ces informations sur l'cran du client et du caissier. 4) Le caissier indique la fin de 5) Le systme calcule et vente quand il n'y a plus affiche le montant total de d'article. l'achat. 6) Le caissier annonce au client le montant total. 7) Le client donne au caissier 8) Le caissier enregistre la 9) Le systme calcule la une somme d'argent somme donne par le client. somme rendre au client. suprieure ou gale la somme demande. 10) Le caissier encaisse la 11) Le systme enregistre la somme remise par le client et vente effectue rend la monnaie au client. 12) Le systme dite le ticket de caisse 13) Le caissier donne le ticket de caisse au client 14) le client s'en va avec les articles qu'il a achets. Cette reprsentation met en vidence que le client n'a pas accs au systme informatique. Contraintes d'IHM ( optionnel ): La dsignation de l'article et son prix ( ventuellement le sous total si plusieurs occurrences du mme article ) sont affichs chaque article au caissier et au client. Le total est affich galement aux deux. Contraintes non fonctionnelles ( optionnel ): Le magasin reoit en moyenne 200 clients par jour. Chaque client achte en moyenne 10 articles.
JC CORRE
25/10/2011
24
Voici un exemple de diagramme d'activit reprsentant la runion de scnarios modlisant un use case. Nous allons grer le catalogue en utilisant un diagramme d'activit pour reprsenter l'ensemble des scnarios ( un scnario est un droulement d'un use case de bout en bout, en commenant par le dbut et se terminant par la fin. ) Un scnario supporte aussi des variantes et des exceptions. Chaque scnario peut tre dcrit comme le use case ci-dessus. Mais il est bon de regrouper l'ensemble de ces scnarios dans un diagramme d'activit pour avoir une vue complte du use case.
supprim er un article
dtruire la rfrence
saisir le code
vrifier le code
saisir et valider le prix
modifier le prix d'un article
saisir les infos du produit
vrifier le code
enregistrer le produit
ajouter un article
ralisation d'un diagram me d'activit ( ici ce n'est pas la norm e UML car la version de rose utilise ne supporte pas les diagram mes d'activit ). Ce schm a a t construit partir d'un diagramm e d'tat.
Note :
commentaire
Ceci reprsente un commentaire dans tout schma UML.
JC CORRE
25/10/2011
25
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.
JC CORRE
25/10/2011
26
sixime tape : diagramme de squence bote noire Les uses cases ont t valids par le client. Nous allons donc changer notre point de vue ( workflow c'est dire processus mtier ) pour adopter un point de vue systme informatique. Nous abandonnons donc les vnements mtier pour nous intresser aux vnements informatiques. Nous allons dvelopper un diagramme de squence par scnario de use case dtaill. Ces diagrammes de squence sont dits bote noire car nous ne savons toujours pas comment sera fait le systme informatique. Ici nous prcisons les changes entre les acteurs utilisateurs du systme informatique et le systme proprement dit. Les interactions des acteurs directement sur le systme sont appeles des vnements. Les actions engendres par le systme suite ces vnements sont appeles des oprations. A un vnement correspondra une opration. Dans la terminologie message et vnement sont quivalents entre eux, ainsi que mthode et opration. Les diagrammes de squence seront agrments de notes et commentaires qui permettront d'illustrer le diagramme: explication de contrles, itrations, logique, choix, Rappelons qu'un diagramme de squence bote noire est de la forme:
: Salari
Systme inform atique : magasin
login ( nom , m otpasse ) Le login est accept si le Lele login est accept si salari login est accept si le salari est connu, et que le est connuest connu, et de salari p)asse mot son mot deet si son est son passe correct. de passe est correct est correct mot
message bienvenue
logout()
retour de la demande de login OK
vnement
Les valeurs de retour se formalisent de diffrentes manires suivant la version d'UML choisie. Ici j'ai pris un exemple de notation la plus simple possible. Attention ne pas confondre avec un vnement ( sens acteur vers systme informatique ). En fin de phase nous connaissons les changes entre les utilisateurs et le systme informatique. Nous pourrions construire une maquette des crans pour les acteurs. Formellement nous le ferons en phase de conception. Notre maquette d'cran serait une maquette "fonctionnelle" ( cest dire que le dessin de lcran nest pas fig ).
JC CORRE
25/10/2011
27
Diagramme de squence bote noire du use case dtaill "effectuer des achats":
: Caissier pour chaque article
systme inform atique : magasin
enregistrer un article ( code ) description et prix article
si code rfrenc dnom brer ( quantit ) si quantit > 1 sous total = prix * quantit
fin de vente ( ) plus d'article prix total
payer ( somme ) monnaie ticket
ici la rponse est asynchrone
JC CORRE
25/10/2011
28
septime tape : diagramme de classe danalyse
Le diagramme de classes est un des documents les plus importants, voire le plus important de l'analyse d'un logiciel par une mthode objet. C'est le premier document qui est dans le monde des objets ( les acteurs n'tant pas forcment reprsents dans le systme informatique ). C'est donc l'entre dans le monde des objets. Ce diagramme est un diagramme de classe d'analyse. Il ne reprsente pas les classes Java ou C++ que nous dvelopperons par la suite. Ici nous nous intressons aux classes du domaine mtier, c'est dire des objets dont on parle dans le cahier des charges et dans les uses cases principalement. Nous ne nous intressons pas aux objets informatiques dans ce diagramme ( sauf bien entendu si le mtier est l'informatique !! ). Cela viendra en son temps, dans le diagramme de classe de conception. Quand nous passerons la conception des classes disparatront, d'autres apparatront, dont les classes informatiques ( collections, ). C'est normal. En phase d'analyse, nous voulons simplement faire un diagramme de classe d'objets manipuls dans le domaine mtier considr. Dans ce diagramme de classe les oprations ne sont pas reprsentes ( ce sera lors de la conception ). Ce diagramme montrera les concepts du domaine mtier, les liens ( associations ) entre ces concepts ( avec leur cardinalit ou multiplicit ), et les attributs de ces concepts ( souvent sous forme de donnes simples ). Le but de ce diagramme est de clarifier le domaine mtier du client, et de se familiariser avec ce domaine. Dans une analyse structure nous dcomposons l'analyse suivant les tches ou les fonctions. Dans une application dominante gestion, nous dcomposerons notre application suivant les donnes, et les traitements. Ici nous analyserons la complexit du domaine en regardant les objets mtier et leurs interactions entre eux. Comment identifier les bons objets mtier pour construire notre diagramme de classe d'analyse? Il va falloir recenser dans les documents de dfinition des besoins et dans les documents d'analyse l'ensemble des objets mtier. Les noms ou groupes nominaux vont tre de bons candidats pour tre lus au titre de classe, objet ou attribut. Cependant, il faut tre prudent car il y aura aussi un certain nombre de faux amis et de doublons. Voici une dmarche de slection des classes candidates: Par use case, nous raliserons un diagramme de classe, le diagramme final tant la superposition de tous ces diagrammes. Pour un use case nous recenserons les groupes nominaux rencontrs. Nous identifierons alors: Les classes ( noms communs ). Les objets ( noms propres ou nom rfrencs ). Les attributs ( donnes simples qui qualifient une classe ou un objet ). Les lments qui sont trangers notre problme ou qui n'y ont pas de rle rel.
JC CORRE
25/10/2011
29
Les " classes fonctionnelles " qui ne sont porteuses d'aucune information, mais seulement de traitement, qui ne sont souvent pas des classes de notre diagramme. Par exemple gestionnaire du planning, dcodeur de message,
Il est parfois difficile de savoir si une information est un attribut d'une classe ou une classe ( avec une association avec la classe ). Dans le doute il vaut mieux faire une classe, quitte revenir en arrire dans une itration ultrieure. Par exemple pour la classe personne l'ge est un attribut ( donne simple ) l'adresse tant priori une donne complexe sera plutt une autre classe associe la personne. Les entits suivantes peuvent prtendre devenir des classes : - les objets physiques (produit), - les transactions (rservation, commande,.), - les lignes de transaction (ligne de commande), - les conteneurs (catalogues, lots,), - les organisations (services, dpartements,.), - les acteurs ou les rles (client, fournisseur.), - les regroupements en abstraction (modle, genre, type, catgorie.), - les vnements (vol,)
Pour le use case " effectuer un achat " voici la liste des classes slectionnes:
caissier
caisse
Paiement
vente
catalogue
ticket article
ligne de vente
JC CORRE
25/10/2011
30
Nous ne grerons pas les exemplaires des articles. Nous applerons article un ensemble dexemplaires identifis par le mme code barre, et comportant des informations identiques (prix ). Nous allons maintenant rajouter les associations entre les classes, en donnant un intitul et des cardinalits ces associations. Notre but n'est pas de mettre jour toutes les associations entre les diffrentes classes, mais de noter les associations pertinentes pour comprendre le problme. Il faut privilgier les associations qui durent dans le temps, et dont la connaissance est ncessaire la comprhension du problme. Il faut viter les associations redondantes ou drivables d'autres associations. L'tablissement de ces associations nous amne poser des questions au client. C'est un des buts recherchs. Voici une possibilit de diagramme de classe avec ses associations.
caissier 0..1 utilise 0..1 caisse se fait partir 1 Paiement 1 paye par 1 vente gnre 1 effectue 0..1 1 1 1
catalogue
1 contient comprend
ticket 1
1..* ligne de vente 0..* est dcrite par 1 0..* article
Sur ce diagramme de classe d'analyse il faut maintenant mettre les attributs des classes qui ont t reprs dans le cahier des charges, le diagramme de use case, ou dans le diagramme de squence bote noire du use case.
JC CORRE
25/10/2011
31
A priori, les attributs prsents dans notre diagramme de classe d'analyse sont des attributs simples. On pourra faire exception des donnes pures qui sont des regroupements de donnes simples ( ici code, adresse, prix ) . Les attributs qui ont un comportement sont des classes associes notre classe. Ceci ne prsage en rien du diagramme de classe de conception. Nous verrons ultrieurement ce que deviennent les associations dans ce schma Dans les attributs, il ne doit pas y avoir de clef sur un autre objet. Cela se reprsente par une association. Voici notre diagramme de classe enrichi des attributs d'analyse.
caissier 0..1 utilise 0..1 caisse 1 Paiement somme : rel 1 paye par 1 effectue 0..1 1 vente date : Date heure : Heure gnre ticket 1 contient 1 comprend 1..* ligne de vente quantit : entier 0..* est dcrite par 1 1 se fait partir 1
catalogue
le prix ou la somme devraient se donner par rapport une monnaie...
0..* description article description : text prix : rel code : codebarre
JC CORRE
25/10/2011
32
huitime tape : Le glossaire Le glossaire rpertorie tous les termes et leur dfinition. Il n'y a pas de graphisme particulier pour ce document. Il peut tre fait sous la forme suivante: terme Effectuer un achat Quantit catgorie Use case Attribut description C'est le processus que suit un client pour effectuer ses achats dans le magasin. C'est un attribut de la classe ligne de vente qui donne le nombre d'occurrences d'un mme article lors d'un achat. C'est la classe qui reprsente une vente en cours ou quand elle est finie.
Vente
Classe
JC CORRE
25/10/2011
33
neuvime tape : les contrats d'opration
Nous allons maintenant tudier ce qui est fait dans le systme, pour chaque flche qui attaque le systme dans les diagrammes de squence. Notre but est de comprendre la logique de fonctionnement du systme. Les flches reprsentes dans les diagrammes de squence bote noire dclenchent des oprations sur le systme. Nous allons donc dfinir prcisment le rle de ces oprations en nous appuyant sur le diagramme de classe ( appel aussi modle de domaine ). C'est ce qui s'appelle des contrats d'opration. Le systme informatique a t vu comme une bote noire ( en particulier travers les diagrammes de squence ). Il serait, d'un point de vue fonctionnel, intressant de dcrire ce que fait le systme, en se basant sur le diagramme de classe, sans pour autant dcrire comment il le fait. Les contrats d'opration vont nous permettre de dcrire les changements d'tats du systme ( c'est dire les changements sur les objets et leurs associations ) quand les oprations ( issues des diagrammes de squence ) sont invoques par les acteurs. Un contrat d'opration est un document textuel qui dcrit les changements provoqus par une opration sur le systme. Le contrat d'opration est crit sous forme textuelle et comporte des pr conditions et des post conditions. Les pr conditions dcrivent l'tat du systme ncessaire pour que l'opration puisse s'effectuer. Les post conditions dcrivent l'tat du systme lorsque l'opration s'est acheve. Contrat d'opration type: Nom: Responsabilits: Exigences: Notes: Pr conditions: Post conditions: Nom de l'opration avec ses paramtres. Description du rle de l'opration. Liste des exigences dont le use case tient compte dans cette itration. Remarques diverses. Etat ncessaire du systme pour que l'opration se fasse. Etat du systme lorsque l'opration s'est droule entirement.
Les Pr conditions dcrivent l'tat du systme, c'est--dire l'tat des objets du systme comme dcrit dans le diagramme des classes d'analyse. Nous jouons l'opration sur le systme, en aveugle, et jusqu' sa fin. Notons les changements de l'tat du systme ( des objets et de leurs associations ) et nous obtenons les post conditions. Ces post conditions sont dcrites sous la forme "has been", c'est-dire l'objet X a t modifi, son attribut Y a t mis vrai. Les post conditions portent sur 6 clauses: Les objets crs. Les objets dtruits. Les associations cres. Les associations dtruites. Les attributs modifis. Les vnements d'affichage ( fonctionnels bien sr !!! ).
JC CORRE
25/10/2011
34
Prenons un exemple simple pour traiter ces contrats d'opration. Modifier le prix d'un article au catalogue. Nom: Responsabilits: Exigences: Notes: Pr conditions: Post conditions: modifier (cecode, nouveauprix). modifier le prix d'un article de code donn, prsent dans le catalogue. R1, R13, R14 pour le use case grer le catalogue. Si le code ne correspond pas a un article du catalogue, un message d'erreur sera envoy au manager et l'opration s'arrte. Il y a un article correspondant au code donn. l'attribut prix de l'objet description article, dont le code est cecode, a t chang par nouveauprix.
Nous allons faire les contrats d'opration des oprations du use case effectuer un achat. Pour cela il faut partir du diagramme de squence bote noire du use case effectuer un achat et du diagramme de classe d'analyse, et pour chaque flche dirige vers le systme, rdiger un contrat dopration. Par exemple : Enregistrer un article. Nom: Responsabilits: Exigences: Notes: enregistrer un article (cecode). enregistrer un article lors d'une vente, et l'ajoute la vente en cours. R15 pour le use case effectuer un achat. Si l'article est le premier de la vente, il dbute la vente. Si le code cecode n'est pas rfrenc dans le catalogue, un message d'erreur est envoy au caissier. Il y a un article correspondant au code donn. Il y a un caissier la caisse. Si c'est le premier article de la vente, il faut qu'un objet vente ait t cr et associ la caisse. Une ligne de vente ( ldv ) a t cre. Elle a t associe un article correspondant au code cecode. La ligne de vente ldv a t associe la vente. Le prix et la description de l'article ont t affichs. L'attribut quantit a t mis 1.
Pr conditions: Post conditions:
Dnombrer les articles identiques. Nom: Responsabilits: Exigences: Notes: Pr conditions: Post conditions: dnombrer (quantit). donne le nombre d'articles identiques l'article enregistr, et calcule le sous total. R3, R4 pour le use case effectuer un achat. Il y a une ligne de vente ( ldv ) correspondant au dernier article enregistr. L'attribut quantit de ldv est affect. Le sous total ( ldv.quantit*prix ) est affich.
JC CORRE
25/10/2011
35
Finir la vente. Nom: Responsabilits: Exigences: Notes: Pr conditions: Post conditions: finir vente ( ). finit une vente et calcule le prix total de la vente. R2 pour le use case effectuer un achat. Il existe une vente et au moins une ligne de vente. La vente est marque termin. Notons ici que nous avons besoin d'enregistrer le fait que la vente soit finie. Cela nous amne dfinir un attribut boolen vente termine. Le prix total de la vente est affich. Ici aussi nous allons enregistrer le prix total de la vente dans l'objet vente. Cela nous amne dfinir un attribut rel Total.
Payer la vente. Nom: Responsabilits: Exigences: Notes: Pr conditions: Post conditions: payer la vente (somme). calcule la monnaie rendre et imprime le ticket de vente. R7 pour le use case effectuer un achat. Si la somme n'est pas suffisante un message est envoy au caissier. Il y a une vente v en cours marque termin. Un objet de type Paiement p a t cr. P a t associ la vente v. V. total a t affect p.somme. La monnaie rendre ( somme p.somme ) a t affiche. Un ticket t a t cr. La vente v a t associe au ticket t. Le ticket de vente a t imprim.
Nous allons voir une autre manire de reprsenter ces contrats d'opration l'aide de diagramme de squence bote blanche. Cette manire de reprsenter les contrats d'opration est beaucoup plus utilise que la manire textuelle. Elle n'est pas forcment mieux d'ailleurs Voici le diagramme de squence bote blanche ( on regarde ici l'intrieur du systme ) de l'opration modifierprix. Cela correspond au contrat de l'opration.
JC CORRE
25/10/2011
36
: Manager
: catalogue
article
modifier(cecode, nouveauprix) modifier( prix )
Diagramme de squence bote blanche de l'opration modifier le prix d'un article au catalogue dans le use case grer le catalogue.
Maintenant nous allons faire les diagrammes de squence bote blanche des oprations du use case effectuer un achat. Diagramme de squence bote blanche de enregistrer un article.
: caisse : Caissier enregistrer un article ( cecode ) create ( date, time ) art = selectionner( cecode ) create(art,1) v : vente ldv : ligne de vente art : article : catalogue
maj ligne vente(ldv)
si nouvelle vente afficher(description,prix)
la quantit vaut 1
JC CORRE
25/10/2011
37
On notera que sur cette reprsentation nous ne voyons pas bien les associations qui ont t cres. Par contre nous voyons mieux les objets qui cooprent pour arriver au rsultat. Ces deux reprsentations du contrat sont assez complmentaires, et mriteraient d'tre prsentes toutes les deux. Diagramme de squence bote blanche de l'opration dnombrer les articles identiques.
: Caissier
: caisse
v : vente
ldv : ligne de vente
: article
dnombrer(q)
ldv = slectionner dernier ldv()
modifquantit(q) p = getprix() afficher(ldv.quantit*p)
Diagramme de squence bote blanche de l'opration finir vente.
: Caissier
: caisse
: vente
finir vente() set termin(true) T = calculer Total()
setTotal(T)
afficher Total Total
cela ncessite de parcourir toutes les lignes de vente
JC CORRE
25/10/2011
38
Diagramme de squence bote blanche de l'opration payer la vente.
: Caissier
: caisse
: vente
p : Paiement
t : ticket
payer (s) payer(s) create(v.Total)
s-v.Total afficher(s-v.Total)
create() im prim er()
Ces schmas sont moins prcis que le contrat d'opration sous forme textuelle. Nous n'y retrouvons pas les associations. Les schmas de diagramme de squence bote blanche utiliss pour dcrire un contrat d'opration ( bien que souvent utiliss ) vont introduire des choix de conception ( qui dclenche les oprations? ). Si ces choix ne sont pas faits le diagramme induit une erreur d'interprtation. Nous prfrerons donc faire ces choix de conception dans le diagramme de collaboration, et garder le contrat d'opration sous forme textuelle.
JC CORRE
25/10/2011
39
La conception
dixime tape : le diagramme dtat Le diagramme d'tat est la frontire de l'analyse ( par la comprhension des cycles de vie de certains objets ) et de la conception ( par les mthodes qu'il permet de dfinir dans les classes tudies ). "Le diagramme se ralise pour les classes d'objets ayant un comportement significativement complexe. Toutes les classes d'un systme n'ont pas besoin d'avoir un diagramme d'tat." ( James RUMBAUGH ) Si, dans l'analyse de notre systme, des classes paraissent complexes, par exemple si elles sont souvent sollicites dans les diagrammes de squence bote blanche, il est bon de faire un diagramme d'tat de ces classes: cela permet d'avoir une vue orthogonale de la classe par rapport ses liens avec les autres classes. Ainsi, nous regardons le comportement des objets d'une classe, et leur volution interne au fil des vnements. Cela nous donne le cycle de vie des objets d'une classe. Ainsi, ayant peru le fonctionnement des objets d'une classe, il est plus facile de vrifier que les objets des autres classes respectent bien ce comportement. Cela amliore notre perception du problme. Cela implique que les diagrammes d'tat doivent tre confronts aux diagrammes d'interaction afin de vrifier la cohrence de ces diagrammes. Les diagrammes d'tat permettront galement de complter les diagrammes de classes de conception en particulier en mettant en vidence des mthodes publiques ( correspondant aux actions du diagramme d'tat ) et des mthodes prives ( correspondant aux activits du diagramme d'tat ). Quelques rappels: Un tat reprsente un objet dans une situation o: Il a une raction dtermine par rapport un vnement. Il excute une activit. Il satisfait une condition. Un tat a une dure finie. Un objet peut avoir une activit dans un tat. Par exemple quand la caisse est en attente d'un client, elle peut faire dfiler un message de bienvenue sur l'cran client. Un objet peut avoir des actions qui seront dclenches sur des vnements. Par exemple sur l'vnement fin de vente, la caisse va afficher le total payer. Une action est une opration atomique qui ne peut tre interrompue. Elle est considre comme instantane. Elle est gnralement associe une transition. Une activit est une opration qui dure et qui peut tre interrompue.
JC CORRE
25/10/2011
40
Elle est associe un tat. Elle peut tre continue et interrompue par un vnement. Elle peut tre finie et dclencher une transition.
nouvel article arrive article / cration vente dmarrer caisse attente do afficher en boucle bonjour abandon / dtruire vente entry: afficher prix + description entre quantit/afficher quantit et sous total
traitem ent un article
ticket rem is / historiser vente arrter caisse im pression en cours entry : lancer im pression
abandon / dtruire vente fin vente / afficher total
attente paiement somm e saisie / afficher monnaie
Etat de la caisse concernant le use case effectuer un achat
JC CORRE
25/10/2011
41
onzime tape : le diagramme de collaboration Le diagramme de collaboration va nous montrer comment les objets interagissent entre eux pour rendre le service demand par le contrat d'opration. Nous allons d'abord observer la syntaxe, et la forme que prend ce diagramme d'opration. Les objets doivent demander des services d'autres objets. Il leur faut donc connatre ces objets pour pouvoir leur adresser des messages. Nous allons donc regarder la visibilit des objets ( c'est dire comment un objet peut connatre d'autres objets ). Enfin quand une ligne du contrat d'opration est ralise il faut se poser la question de savoir quel objet agit pour raliser cette ligne ( qui cre tel objet, qui reoit l'vnement initial). En un mot il est ncessaire de dfinir les responsabilits des objets. L'exprience et le savoir faire des professionnels nous ont permis de dfinir des rgles, des modles de pense, qui nous permettrons de nous guider pour dfinir les responsabilits des objets. Ce sont les GRASP patterns que nous verrons enfin, avant de traiter notre caisse. 1) Syntaxe du diagramme de collaboration Nous allons prendre un exemple de diagramme de collaboration pour introduire toutes les notions vhicules dans ce diagramme. Rappelons nous que ce diagramme, dans le contexte de la conception, nous montre comment les objets cooprent entre eux pour raliser les oprations dfinies par les contrats d'opration.
Modifierprix(code,prix)
:caisse
1 :Modifierprix(code,prix)
:catalogue
1.1 :art := chercher(code) : article 1.2 : setprix(prix)
art : article : article
a) les objets Ici nous reprsentons la coopration des objets pour rendre le service demand. Il sagit donc bien dobjets. Ces objets apparaissent sous trois formes : Les objets anonymes ( :caisse, :catalogue). A comprendre la caisse courante, ou le catalogue courant Les objets nomms ( art :article ). A comprendre que cest bien le type darticle qui correspond au code cherch. Les multiobjets ( :article ). A comprendre comme la collection des types darticle associe au catalogue.
JC CORRE
25/10/2011
42
Objet anonyme Modifierprix(code,prix) :caisse 1 :Modifierprix(code,prix) :catalogue
1.1 :art := chercher(code) : article Objet nomm 1.2 : setprix(prix) Multi objet
b) la syntaxe des messages
Message initial issu du diagramme de squence
Caisse envoie un message catalogue Dabord le catalogue :catalogue cherche larticle
Modifierprix(code,prix)
:caisse
1 :modifierprix(code,prix) Puis il modifie le prix de larticle trouv
1.1 :art := chercher(code) : article 1.2 : setprix(prix)
Le message initial est non numrot par convention. Ce message est un des vnements issu du diagramme de squence bote noire, dont nous avons fait un contrat dopration.
JC CORRE
25/10/2011
43
Les oprations effectues en rponse ce message seront numrotes de 1 n ( notons quen gnral n nest pas trs lev, si la conception est bien faite ). Les oprations effectues en raction un message numro x seront numrotes de x.1 x.n. Et ainsi de suite pour les oprations effectues en raction un message numro x.y ( x.y.1 x.y.n). Un message a la forme suivante :
Valeur de retour message Type de retour du message Paramtre(s) du message
1.1 :art := chercher(code) : article
numro
affectation
Un lien entre deux objets est directionnel. La flche indique le receveur du message. Ce lien implique que lobjet qui envoie le message connaisse celui qui le reoit. Un objet ne peut en effet envoyer un message qu un objet quil connat ( rappelez-vous que lon envoie un message un objet en lui parlant : moncatalogue , modifie le prix de larticle de code moncode monprix.). Chaque flche implique une visibilit oriente entre les objets.
:catalogue connat art et le multiobjet Modifierprix(code,prix) 1 :Modifierprix(code,prix)
:caisse
:catalogue
:caisse connat lobjet :catalogue 1.2 : setprix(prix)
1.1 :art := chercher(code) :article
art : article :article
JC CORRE
25/10/2011
44
c) les types de messages Nous avons vu la forme gnrale des messages. Il peut y avoir quelques formes particulires de messages, que nous allons lister maintenant. Les messages conditionnels simples
Message habituel, ici simplifi
1 :msg()
:A
numro
1.1[x>y] :message() condition
:B
Le message nest envoy :B que si la condition x>y est remplie lors du droulement du code de msg() dans la classe A.
Les messages conditionnels exclusifs ( ou si sinon)
1 :msg()
1.1a[x>y] :messageb()
:A
Numro avec une letrre condition
:B
1.1b[ not x>y] :messagec() :C Mme numro avec une autre lettre
Condition contraire
Si la condition x>y est vrifie, un message est envoy lobjet :B, sinon un message est envoy lobjet :C Les messages dinstanciation
Ce sont les messages de cration dobjet. Ce sont des messages create, avec ou sans paramtres, qui creront de nouvelles instances dobjets.
JC CORRE
25/10/2011
45
1 :Ajouter(desc,prix,code,qt)
:catalogue
1.1 :Create(desc,prix,code,qt)
Nouvelarticle :Type article
Ici le message create cre un nouvel article en linitialisant. Les vrifications dusage seraient bien sr effectuer ( le code de larticle nexiste til pas dj au catalogue ?). Les messages itratifs
* aprs le numro indique une itration 1 :msg() Ici itration de 1 10
:A
1.1*[i :=1..10] :message()
:B
Le message sera envoy dix fois lobjet :B. De manire gnrale ltoile place aprs le numro dsigne une itration. Nous trouverons soit une numration de litration, comme ici, une condition de continuation galement ( 1.1*[not condition] :message() ). Nous trouverons ultrieurement une itration sur tous les lments. Les messages itratifs groups
Ce sont des messages itratifs, o plusieurs messages sont envoys dans litration.
1 :msg()
1.1*[i :=1..10] :messageb()
:A
Itration sur i de 1 10
:B
1.2*[ i :=1..10] :messagec() :C Itration sur le mme i toujours de 1 10
Ici nous envoyons successivement un message :B, puis un message :C, le tout 10 fois. Il ny a quune seule boucle.
JC CORRE
25/10/2011
46
Les messages itratifs distincts
Ce sont des messages itratifs, o plusieurs itrations se suivent. Ici les boucles sont distinctes.
1 :msg()
1.1*[i :=1..10] :messageb()
:A
Itration sur i de 1 10
:B
1.2*[ j :=1..10] :messagec() :C Itration sur j diffrent de i
Ici nous envoyons successivement dix messages :B, puis dix messages :C. Il y a deux boucles distinctes. Les messages vers this
Ici un objet senvoie un message lui-mme.

1 :Create() Produit frais
1.1 :defDatePremption(today)
La dfinition de la date de premption du produit est faite par lui-mme. Il sait combien de temps il peut se conserver dans des conditions de tempratures normales. Donc il senvoie le message lui-mme. Les messages vers un multiobjet
1 :art :=quelart(code) : article
:catalogue
1.1 :art :=trouver(code) :article
: article
JC CORRE
25/10/2011
47
Le message trouver n'est pas envoy l'objet :Type art mais au multi objet, qui se traduira en programmation par une collection ( tableau, vecteur, hashtable, etc ). Les multiobjets acceptent de manire gnrale un certain nombre de messages:

Trouver : Ajouter : Supprimer : Taille : Suivant : Contient : d'une cl.
rcupre un lment d'un multiobjet partir d'une cl. ajoute un lment au multiobjet. supprime un lment du multiobjet. donne le nombre d'lments du multiobjet. permet de passer l'lment suivant du multiobjet. permet de savoir si un lment est prsent dans le multiobjet partir
Itration sur les lments d'un multiobjet
1: lister()
:catalogue
Pour chaque article du catalogue, nous voulons la description de l'intitul de l'article.
1.1*: s := getDescr() : String *
Cette toile montre que l'on s'adresse aux lments de la collection
: article
Cette toile montre une itration sur tous les lments
Il nous reste ici imprimer la description obtenue. Pour cela il faut envoyer un message une classe. Envoi d'un message une classe ( appel d'une mthode statique )
1: lister() 1.2*: imprimer(s)
:catalogue
Systeme
1.1*: s := getDescr() : String * Ici nous avons une classe. La mthode imprimer est donc une mthode statique (lie une classe). : article
JC CORRE
25/10/2011
48
2)
Visibilit des objets
Pour pouvoir s'changer des messages, les objets doivent se connatre.
:caisse
:vente
Ce lien veut dire que la caisse connat la vente.
La classe caisse doit connatre la classe vente pour pouvoir lui parler:" vente , oh ma vente! Ajoute-toi un article de ce code.". La visibilit entre les objets n'est pas automatique. Il y a quatre manires diffrentes pour un objet d'en connatre un autre. La visibilit de type attribut. La visibilit de type paramtre La visibilit de type locale La visibilit de type globale
Nous allons regarder chacun de ces diffrents types de visibilit. La visibilit de type attribut.
1: desc := getdesc(code):String
:caisse
:catalogue
La caisse doit connatre de manire permanente le catalogue. Elle a donc un attribut qui rfrence le catalogue. Le lien montre cet attribut, car c'est la seule manire ici de connatre la classe catalogue.
La visibilit de type paramtre
Supposons que le diagramme de squence bote noire mette en vidence un message de type vrifier avec en paramtre une description d'article. Supposons galement que ce soit la caisse qui traite ce message. Nous obtenons le diagramme de collaboration suivant:
Que celui-l art :article 1: p := getPrix(): entier JC CORRE Grenoble Le Pont de Claix 25/10/2011 49
Val := Vrifier(art:article): entier Celui-ci c'est le mme :caisse
Ici la caisse ne connat l'article art que temporairement. Le passage de paramtre lui fait connatre l'article art qui la caisse va envoyer un message. La visibilit de type locale
Setprix(code,prix)
:caisse
1:art:= getart(code): article
:catalogue
Rcuprons une rfrence sur un objet
2: setprix(prix)
art:article
Pour pouvoir lui envoyer un message
Ici caisse va chercher une rfrence sur un article, pour pouvoir envoyer un message cet article. Ici aussi, la connaissance de l'objet est temporaire, mais elle se fait par une variable locale. La visibilit de type globale
C'est l'utilisation par un objet d'une rfrence globale un objet connu de tous. Cela peut aussi tre le cas de variables globales dans le cas de certains langages. Nous comprenons bien que ce type de visibilit sera utilis dans de rares cas, o un objet est omniprsent pour tous les autres objets, et sera considr comme le contexte de vie de ces objets. Le problme est que certaines, rares, classes ayant une instance unique doivent tre connues de nombreux objets. Il est alors conseill d'utiliser le GOF Pattern "Singleton". Supposons qu'une classe ncessite d'en connatre une autre ayant une instance unique (Par exemple, le magasin, si lon avait une classe magasin), et que les autres techniques de visibilit soient notoirement malcommodes voici ce que vous pouvez faire: La classe magasin aura une donne membre statique instance. A la cration ( constructeur ) du magasin la donne membre sera initialise this ( l'instance nouvellement cre du magasin ). La classe magasin aura une fonction statique getInstance qui retournera l'instance du magasin. Ainsi n'importe quelle classe pourra connatre l'objet magasin existant ( car la mthode tant statique, elle est envoye la classe elle mme ). Ainsi l'autre classe pourra envoyer sa requte l'objet magasin. Voici un diagramme de collaboration qui illustre cet exemple.
JC CORRE
25/10/2011
50
:X
1: m =getInstance()
Magasin
2: xxx() m:Magasin Ceci est l'instance unique Ceci est une classe
3)
GRASP patterns
Quand un vnement est envoy au systme informatique, rien n'indique quelle classe prend en charge l'vnement et le traite en droulant les oprations associes.
Systeme informatique
vnement
A qui est envoy ce message ?
De mme pour chaque opration permettant de mettre en uvre le contrat d'opration, il faudra dterminer qui cre tel objet, qui envoie tel message tel autre objet. Contrat d'opration: une ligne de vente a t cre.
Systme informatique
:caisse Qui cre la ligne de vente ? Create ?
:vente
Create ?
:magasin Create ?
L:lignevente
JC CORRE
25/10/2011
51
La rponse ces questions va influencer normment la conception de notre application. C'est ici que l'on va dfinir concrtement la responsabilit des objets, leur rle. C'est aussi ici que l'on va mettre en place la structure du logiciel par couches ( entre autre en implmentant les passerelles tanches entre les couches ). Les qualits du logiciel qui lui permettront de vivre, d'tre corrig, d'voluer, de grandir dpendront compltement des choix que l'on va effectuer ici. Les spcialistes de la conception objet, aprs avoir vcu quelques annes de dveloppement anarchique, puis aprs avoir test l'apport de quelques rgles de construction, ont fini par dfinir un certain nombre de rgles pour aider le concepteur dans cette phase capitale et difficile. Ces rgles sont issues de l'exprience d'une communaut de dveloppeurs. Ce sont des conseils, ou des rgles qui permettent de dfinir les responsabilits des objets. Ce sont les modles d'assignation des responsabilits ou GRASP Patterns ( General Responsability Assignement Software Patterns ). To grasp ( en anglais ) veut dire: saisir, comprendre, intgrer. Il est fondamental d'intgrer ces modles avant de faire de la conception objet, pour obtenir des diagrammes de classe de conception, et des diagrammes de collaboration de qualit. Il y a neuf grands principes pour attribuer les responsabilits aux objets, et modliser les interactions entre les objets. Cela permet de rpondre aux questions: Quelles mthodes dans quelles classes? Comment interagissent les objets pour remplir leur contrat? De mauvaises rponses conduisent raliser des programmes fragiles, faible rutilisation et maintenance leve. Quand, dans le diagramme de collaboration, un objet envoie un message un autre objet, cela signifie que l'objet recevant le message a la responsabilit de faire ce qui est demand.
da := getdescart(code) :catalogue
Le catalogue la responsabilit de rechercher une description d'article
Un message implique une responsabilit. Les patterns sont l pour nous aider lors de la conception. C'est un couple problme solution issu de la pratique des experts. Nous allons voir les neuf GRASP patterns. Il y a d'autres patterns qui existent ( par exemple GOF ( Gang Of Four ) patterns ) ceux-l sont plus ddis des solutions des problmes particuliers ( par exemple le modle de traitement des vnements ( GOF patterns ) qui a inspir le modle java de traitement des vnements ). Les GRASP patterns sont des modles gnraux de conception, et doivent tre considrs par le concepteur objet comme la base de son travail de conception. Nous allons tudier chacun de ces patterns.
JC CORRE
25/10/2011
52
3.1) Faible couplage Le couplage entre les classes se mesure : c'est la quantit de classes qu'une classe doit connatre, auxquelles elle est connecte, ou dont elle dpend. Plus il y a de couplage, moins les classes s'adaptent aux volutions. Il faut donc garder en permanence l'esprit que des liens entre les classes ne seront rajouts que si nous ne pouvons les viter. Un couplage faible mne des systmes volutifs et maintenables. Il existe forcment un couplage pour permettre aux objets de communiquer. 3.2) Forte cohsion Des classes de faible cohsion font des choses diverses ( classes poubelles o sont ranges les diffrentes mthodes que l'on ne sait pas classer ), ou tout simplement font trop de choses. Ces classes faible cohsion sont difficiles comprendre, rutiliser, maintenir. Elles sont galement fragiles car soumises aux moindres variations, elles sont donc instables. Le programmeur doit toujours avoir ce principe de forte cohsion en tte. Il ralisera alors des classes qui ont un rle clairement tabli, avec un contour simple et clair. 3.3) Expert Ici nous allons tablir qui rend un service. Le principe est que la responsabilit revient l'expert, celui qui sait car il dtient l'information. Quelle classe fournira le service getdescription ( code ) qui retourne la description d'un article dont nous avons le code?
:vente
Desc := getdescription( code ) : descriptionarticle
:catalogue
C'est l'expert
C'est le catalogue qui possde les descriptions d'article, c'est lui l'expert. C'est donc lui qui nous fournira le service getdescription. Ce principe conduit placer les services avec les attributs. Nous pouvons aussi garder en tte le principe: "celui qui sait, fait". 3.4) Crateur Quand une instance de classe doit tre cre, il faut se poser la question: " Quelle classe doit crer cet objet?". Une classe A cre peut crer une instance de la classe B si: A contient B. A est un agrgat de B.
A enregistre B. A utilise souvent B. Alors A est la classe cratrice de B. Il arrive souvent que deux classes soient de bons candidats pour crer une instance. Alors il faut valuer le meilleur candidat. Cela va dans le sens du faible couplage. Ici c'est le catalogue qui cre les descriptions d'articles. 3.5) Contrleur En dbut de ce document, il tait voqu l'indpendance entre les diffrentes couches logicielles. Regardons ici l'interface entre la couche prsentation et la couche mtier.
Interface utilisateur
Systme informatique
Objets de l'interface utilisateur ( Frame )
objets du sytme informatique
Ici nous voyons de fortes dpendances entre les objets du Systme informatique et les objets de l'interface. Si l'interface doit tre modifie, il y a de fortes chances qu'il faille galement modifier les objets du systme informatique. Notons sur cet exemple un autre problme: les classes du systme informatique, ici, connaissent les classes de l'interface utilisateur. Or, ces classes sont lies un usage particulier ( une application ) alors que les classes mtier sont transverses toutes les applications. Elles ne peuvent donc pas connatre les interfaces utilisateur. Ce sont les interfaces utilisateurs qui vont chercher les informations des objets mtier, et non les objets mtier qui affichent les informations. Les objets de l'interface utilisateur vont solliciter un objet d'interface, plutt que de solliciter les objets mtier eux-mmes. Cet objet s'appelle un contrleur. Il peut y avoir quatre sortes de contrleurs: - Quelque chose qui reprsente entirement le systme ( caisse ). - Quelque chose qui reprsente l'organisation ou le mtier dans son ensemble ( magasin ).
JC CORRE
25/10/2011
54
Quelque chose du monde rel qui est actif dans le processus: rle d'une personne impliqu dans le processus (caissier). Handler artificiel pour traiter tous les vnements d'un use case. ( AchatHandler )
Regardons notre schma des changes entre les couches UI et mtier. Interface utilisateur Systme informatique
Objets de l'interface utilisateur ( Frame )
objets du systme informatique
Le problme est maintenant de savoir comment nous allons choisir notre meilleur contrleur ( il peut y en avoir plusieurs ). L'vnement entrerunarticle arrive donc sur une des quatre classes: Caisse, Magasin, Caissier ou AchatHandler. L'exprience montre que la troisime proposition, appele contrleur de rle, est utiliser avec parcimonie, car elle conduit souvent construire un objet trop complexe qui ne dlgue pas. Les deux premires solutions, que l'on appelle contrleurs de faade sont bien utilises quand il y a peu d'vnements systme. La quatrime proposition ( contrleur de use case ) est utiliser quand il y a beaucoup d'vnements grer dans le systme. Il y aura alors autant de contrleurs que de use cases. Cela permet de mieux matriser chaque use case, tout en ne compliquant pas notre modle objet. Nous avons peu d'vnements grer. Nous prendrons donc la solution 1 ou 2. Le choix entre ces deux propositions va se faire en appliquant les patterns prcdemment tablis.
3.6) Polymorphisme
JC CORRE
25/10/2011
55
Quand vous travaillez avec des objets dont les comportements varient lorsque les objets voluent, ces comportements doivent tre dfinis dans les classes des objets, et les classes doivent tre hirarchises pour marquer cette volution. Les comportements seront dfinis par des fonctions polymorphes, c'est dire ayant mme forme ( mme signature ou interface ), mais avec des comportements mutants. Ainsi lorsque l'on sollicite un objet de cette hirarchie, il n'est pas besoin de savoir quelle est la nature exacte de l'objet, il suffit de lui envoyer le message adquat ( le message polymorphe ), et lui ragira avec son savoir faire propre. Cela permet de faire voluer plus facilement les logiciels. Un objet mutant ( avec un comportement polymorphe ) est immdiatement pris en compte par les logiciels utilisant l'objet initial. Un programme ne teste donc pas un objet pour connatre sa nature et savoir comment l'utiliser: il lui envoie un message et l'objet sait se comporter. Cela va dans le sens de l'radication de l'instruction switch ( de JAVA ou de C++). 3.7) Pure fabrication L'utilisation des diffrents grasp patterns nous conduit quelque fois des impasses. Par exemple la sauvegarde d'un objet en base de donnes devrait tre fait par l'objet lui-mme ( expert ) mais alors l'objet est li ( coupl ) son environnement, et doit faire appel un certain nombre d'outils de base de donnes, il devient donc peu cohrent. La solution prconise, dans un tel cas, est de crer de toute pice un objet qui traite la sauvegarde en base de donnes. Notre objet reste alors cohrent, rutilisable, et un nouvel objet, dit de pure fabrication, s'occupe de la sauvegarde en base de donnes. Cette solution n'est employer que dans des cas bien particuliers, car elle conduit raliser des objets bibliothque de fonctions. 3.8) Indirection L'indirection est le fait de dcoupler deux objets, ou un objet et un service. La pure fabrication est un exemple d'indirection, mais aussi l'interfaage avec un composant physique. Un objet ne s'adresse pas directement un modem, mais un objet qui dialogue avec le modem. 3.9) Ne parle pas aux inconnus Pour viter le couplage, chaque objet n'a le droit de parler qu' ses proches. Ainsi, nous limitons les interactions entre les diffrents objets. Quels sont les objets auxquels un objet le droit de parler? Lui-mme. Un objet paramtre de la mthode appele. Un objet attribut de l'objet lui-mme. Un objet lment d'une collection attribut de l'objet lui-mme. Un objet cr par la mthode. Les autres objets sont considrs comme des inconnus auxquels, nous le savons depuis la plus tendre enfance, il ne faut pas parler. Prenons un exemple:
JC CORRE
25/10/2011
56
L'objet caisse connat la vente en cours ( c'est un attribut de la caisse ). Cette vente connat le paiement ( c'est un attribut de la vente ). Nous voulons raliser une mthode de la caisse qui nous donne la valeur de la vente en cours. Voici une premire solution:
1:P:=paiement():Paiement
Total = totalvente():float
:Caisse
:Vente
Caisse et paiement sont coupls
2:Total := totalvente():float
p:Paiement
Cette solution implique que l'objet caisse dialogue avec l'objet paiement. Hors a priori il ne connat pas cet objet paiement. Pour limiter le couplage entre les objets, il est prfrable d'utiliser la solution suivante:
Total = totalvente():float
:Caisse
1:Total:=totalvente():float
:Vente
Vente et paiement se connaissait dj. Pas de couplage supplmentaire
1.1:Total := totalvente():float
:Paiement
Ici, la caisse ne sait pas comment la vente rcupre le total. Des modifications de la structure des objets vente et paiement ainsi que de leurs relations ne changent rien pour la caisse. 4) Diagramme de collaboration du magasin
Nous allons maintenant construire le diagramme de collaboration pour chacun des contrats d'opration que nous avions dtaills, en tenant compte des modles de conception. Nous allons faire autant de diagrammes de collaboration que nous avons fait de contrats d'oprations. Pour chaque contrat d'opration nous allons prendre l'vnement du systme comme message d'attaque de notre diagramme de collaboration, puis nous allons crer les interactions entre les objets qui, partir de l, permettent de remplir le service demand. Nous serons vigilant bien respecter les modles de conception. Il n'est pas un
JC CORRE
25/10/2011
57
message qui se construise au hasard. Chaque message envoy d'un objet un autre se justifie par un pattern de conception ( au moins ) . 4.1) Diagramme de collaboration de Enregistrer un article
Enregistrer article(code) :Caisse 2: [1er article] crer(date) 3: ajouter(art)
:Vente
3.1:ldv := crer(art) 1 art := chercherarticle(code) 3.2: ajouter(ldv)
:Catalogue
ldv:lignedevente :lignedevente
1.1 art := chercher(code)
3.1.1: p:=getprix() 3.1.2: desc := getdesc()
art: article : Article
4.2) Diagramme de collaboration de dnombrer les articles identiques

Dnombrer ( quantit) :Caisse 1: dnombrer(quantit) :Vente
1.2:misejour(quantit) 1.1: ldv :=dernierldv()
1.2.2: total ligne := p*quantit
Ldv:lignedev ente
Liste:lignede vente
1.2.1: p:=getprix()
art: article
JC CORRE
25/10/2011
58
4.3) Diagramme de collaboration de Finir la vente
Finirvente()
:Caisse
1: Finirvente()
:Vente
1.1: termin := vrai 1.3: Total := somme
1.2*: somme := somme+getsstotal() *
Liste:lignede vente
4.4) Diagramme de collaboration de Payer la vente
Payervente(s)
:Caisse
1:Payersomme(s)
v:Vente
:Afficheur
1.2:afficher(s-total)
1.3: crer(v) 1.4: imprimer()
1.1: crer(total)
:Paiement Le ticket doit connatre la vente pour imprimer :ticket
Les classes ticket et vente sont troitement couples. Nous pouvons nous poser la question de savoir si cette classe ticket a un intrt. Il serait bon de faire l'impression par la vente ( l'expert ), mais en s'appuyant sur une indirection (imprimante) comme pour l'affichage. Enfin une analyse de tous les uses cases mettrait en vidence le besoin d'archiver les ventes, pour pouvoir faire les statistiques. Nous allons donc proposer une solution plus avance de ce diagramme de collaboration. On a ici rajout les notions dhistorisation des ventes (qui dcoule dautres use-case), ce qui nous permet de faire apparatre la classe magasin (singleton). Cette classe sera fusionne avec la classe catalogue.
JC CORRE
25/10/2011
59
En ce qui concerne laffichage, on a choisi dutiliser un afficheur reli directement la caisse. Il aurait pu tre judicieux de lier lafficheur la ligne de vente (pour laffichage des descriptions, prix, quantit et sous-total associs la ligne de vente) et la vente (pour laffichage du total et de la monnaie rendre).. Dans ce cas, on aurait pu aussi utiliser le pattern singleton pour modliser cet afficheur (un objet unique, accessible depuis partout).
:Afficheur :imprimante
1.2.1:afficher(s-total)
1.8.1: imprimer(line) 1.7*:line := desc+prix+quantit+sstotal
Payervente(s)
:Caisse
1:Payersomme(s)
v:Vente
2:historiser(v)
1.2:afficher(s-total) 1.8*: imprimer(line)
1.1: crer(total) :Magasin :Paiement
2.1: ajouter(v)
1.3*: desc := getdesc() * 1.4*:prix := getprix() * 1.5*:quantit := getquantit() * 1.6*: sstotal :=getsstotal() *
Ventes:vent e Liste:lignede vente 1.3.1:desc:=getdesc() 1.4.1:prix:=getprix()
Art: article
Tous les dtails sur l'impression du ticket n'y sont pas ( entte, total, somme rendue ), mais ce schma donne une bonne vue des relations entre les objets.
douzime tape : le diagramme de classe de conception Nous allons enfin construire le diagramme de classes de conception. C'est le diagramme qui nous montre les classes qui seront dveloppes. C'est donc l'aboutissement de ce travail d'analyse. Pour l'ensemble des uses cases qui composent notre cycle de dveloppement, nous allons raliser le diagramme de classes de conception. Nous allons partir des diagrammes de collaboration, qui nous donnent les classes dvelopper, leurs relations ainsi que les attributs par rfrence. Nous complterons ce diagramme par les attributs venant du diagramme de classe d'analyse. Nous allons partir uniquement du use case effectuer un achat, donc des quatre diagrammes de collaboration du chapitre prcdent. Etape par tape, nous allons construire le diagramme de classe de conception. 1) Premire tape
Nous allons rfrencer toutes les classes rencontres dans les diagrammes de collaboration. Nous allons les dessiner dans un diagramme de classes. Nous allons y ajouter les attributs venant du diagramme de classe d'analyse, et les mthodes venant du diagramme de collaboration. Nous ne rfrenons que les classes participant nos diagrammes de collaboration. Les collections ne sont pas rfrences en tant que telles, cela n'apporte pas de plus value. Les messages vers les collections n'ont pas lieu d'tre, les collections supportant ces messages par dfaut. Les messages de cration par dfaut ne sont pas rfrencs, s'il n'existe pas de constructeur par initialisation ( car alors ils existent forcment ). Les slecteurs et les modifieurs n'ont pas de raison de figurer dans ce schma pour ne pas le surcharger. En effet dans la majorit des cas, ces messages existent et sont dvelopps la construction de la classe.
Caisse Vente Date : date Termin : boolen Total : float payersomme(s:float) Vente(date:Date) ajouter(art: article) dnombrerquantit(q:entier) finirvente()
Payervente(s:float) enregistrerarticle(code : Codebarre) dnombrer(quantit : entier) finirvente() afficher(total:float) imprimer(line:text)
Magasin Nom : text Adresse : Adresse historiser(v:vente) chercherarticle(code:Codebarre): article
Lignevente Quantit : entier Sstotal : float getdesc():Text getprix():Float Lignevente(art :article) Paiement Total : float Paiement(total:float)
Descriptionarticle Description : text Prix : rel Code : codebarre Afficheur Imprimante
afficher(stt:float)
imprimer(line:text)
JC CORRE
25/10/2011
61
2)
Deuxime tape
Il faut maintenant ajouter les associations ncessaires pour montrer la visibilit par attribut des objets. Cette visibilit par attribut va permettre de construire les attributs qui rfrencent les objets que l'on doit connatre. Cette association porte une flche de navigation qui nous permet de connatre l'objet qui doit connatre l'autre. Prenons trois exemples : 1) issu du diagramme de collaboration de payervente:
1:payersomme(s) :Caisse V:Vente
Ici la caisse doit connatre en permanence la vente en cours: nous aurons une association de type attribut.
Caisse 1 traite 1..0 venteencours Vente
Cela indique que la classe Caisse a un attribut qui rfrence l'objet vente en cours. Le nom de rle venteencours donnera, pour une gnration automatique de code, le nom de l'attribut qui rfrence la vente en cours. 2) issu du diagramme de collaboration de enregistrerarticle :
:Caisse
Ajouter(art) :Ventes
Ici la caisse a une visibilit de type variable locale sur l article ( cela serait le mme traitement si il avait une visibilit de type paramtre comme pour la Vente ). Nous ajouterons des dpendances de type relation entre les deux classes.
Caisse
article
Flche avec des pointills
JC CORRE
25/10/2011
62
Cette association montre que le code des mthodes de Caisse doit manipuler la classe article. Il sera donc ncessaire, la gnration de code, d'inclure un accs la classe article dans la classe Caisse ( import java, ou include c++ ). 3) issu du diagramme de collaboration de payervente :
1:art:=chercherarticle(code) :Caisse :Catalogue
Ici le magasin est une instance unique pour l'application. Un certain nombre de classes doivent connatre le magasin. Nous pouvons rsoudre le problme comme au 1. Mais, si nous ne voulons pas multiplier les rfrences au magasin, nous pouvons appliquer le pattern Singleton ( Singleton pour instance unique ). Cela revient effectivement travailler avec une instance globale, mais fait proprement, dans des cas rares, et rpertoris. Nous retrouverons la notation de relation entre les classes, ici pour un accs une variable globale.
Caisse
Magasin $boutic:Magasin $getInstance()
Comment est trait le pattern Singleton? La classe Magasin possde une instance de classe ( statique ) d'un objet d'elle-mme, et une fonction de classe ( statique). Le code de la fonction est le suivant: (exemple en java) public static Magasin getInstance() { if (boutic == null) { boutic = new Magasin(); } return boutic; } Ainsi nous aurons une instance unique du Magasin. Cette instance peut tre appele partout en utilisant le formalisme suivant: (exemple en java) Magasin monbazar = Magasin.getInstance(); Voici maintenant le diagramme de classe de conception de notre exercice:
JC CORRE
25/10/2011
63
Afficheur
Imprimante
affichet(stt:float)
imprimer(line:text)
1 possde 0..1
possde
Vente Date : date Termin : boolen Total : float payersomme(s:float) Vente(date:Date,c:Caisse) ajouter(art:article) dnombrerquantit(q:entier) finirvente()
1
Caisse
1 1 1
Payervente(s:float) enregistrerarticle(code : Codebarre) dnombrer(quantit : entier) finirvente() afficher(total:float) imprimer(line:text)
ralise Se fait sur Venteencours 1
Historique * effectue 0..1

Paiement
enregistre
1
Magasin Nom : text Adresse : Adresse $boutic:Magasin historiser(v:vente) chercherarticle(code:Codebarre): article $getInstance():Magasin
Total : float Paiement(total:float)
contient
1..*
Lignevente
1
Quantit : entier Sstotal : float
rfrence rfrence * catalogue

article Description : text Prix : rel Code : codebarre
getdesc():Text getprix():Float Lignevente(art :article)
JC CORRE
25/10/2011
64
Notes sur le diagramme de conception:
Quand la vente en cours est cre, il faut lui associer la caisse sur laquelle s'effectue la vente. Nous avons fait le choix que la vente ne connaisse que la caisse, plutt que de connatre chacun de ses lments ( afficheur, imprimante, ) La caisse joue un double rle: celui d'interface pour le use case effectuer un achat, et l'indirection vers les composants physiques de la caisse. Si la caisse devient trop complexe, il vaut mieux couper la classe en deux, d'un cot l'interface du use case, et de l'autre ct l'interface vers les composants de la caisse elle-mme. Nous ne l'avons pas fait dans le cadre de cet exercice. Quand entre deux classes, il existe dj une association ( ), il n'est pas utile d'y rajouter une relation ( ). Cela n'apporte rien, sinon du bruit. Ici, nous n'avons pas rajout les indicateurs de visibilit ( public +, priv -,), tant bien entendu que les mthodes sont publiques, et les attributs sont privs. Les fonctions d'accs aux attributs sont sous-entendues. Les noms de rle mis sur certaines associations donnent le nom de l'attribut dans la classe concerne. Les associations sont unidirectionnelles et donne le sens de la visibilit. Le diagramme nous montre que la classe Caisse a un attribut qui s'appelle venteencours qui rfrence la vente en cours. De mme la classe Magasin a un attribut qui s'appelle catalogue et qui est une collection darticles ( c'est la cardinalit qui nous montre que dans ce cas c'est une collection ). Les trois relations prsentes sont des trois types possibles ( global, paramtre et local )
JC CORRE
25/10/2011
65
treizime tape : le codage A partir des diagrammes de collaboration et du diagramme de classe de conception, on en dduit simplement des lments de codage associs. En voici quelques exemples : class Caisse { private Catalogue cat ; private Vente v ; public void enregistrerarticle(int code) { Article art=Cat.chercherarticle(code) ; if (v==null) { v=new Vente() ; } v.ajouter(art) ; } public void finvente() { v.finvente() ; } . }
class Catalogue { private Hashtable articles=new Hashtable() ; ; public Article chercherarticle(int code) { return articles.get (code) ; } . } class Vente { private boolean ventetermine = false ; private Vector lignes = new Vector() ; public void ajouter(Article art) { lignes.addElement(new Ldv(art)) ; } public void finvente() { ventetermine= true ; }
JC CORRE
25/10/2011
66
public float total() { float total=0 ; Enumeration e=lignes.elements() ; while (e.hasmoreElements()) { total+=((Ldv)e.nextElement()).soustotal(); } return total; } . }
class Ldv { private int qte ; private Article art ; . public Ldv(Article a) { this.art=a ; } public void soustotal() { return qte*art.getprix() ; } public denombrer(int newqte) { setqte(newqte) ; } . }
class Article { private int code=0 ; private float prix=0 ; private String desc= ; public Article(int code, float prix, String desc) { this.code=code ; this.prix=prix; this.desc=desc; } public int getcode() { return code;
} public int getprix() { return prix; } public int getdesc() { return desc; }
. }
JC CORRE
25/10/2011
68
Le processus unifi
Le processus unifi est la dmarche danalyse et de conception qui sappuie sur le langage UML pour sa modlisation. Ce que nous avons vu jusqu prsent, cest une dmarche linaire pour partir dun besoin utilisateur jusqu sa ralisation. Ceci nest pas reprsentatif de la ralit des dveloppements. Un dveloppement dun projet informatique va tre incrmental et itratif. Cela permet dviter leffet tunnel des projets classiques ( le client perd de vue son logiciel entre le cahier des charges et la livraison ). Ici le projet est dvelopp en concertation avec le client, le dialogue doit tre permanent, les livraisons se font rgulirement, permettant dintervenir au plus tt si il y a un cart entre le besoin du client et le logiciel ralis. Nous allons donc mettre en 3 dimensions le processus que nous avons tudi.
Notion de lot ( ou de cycle )

Un lot, ou un cycle de dveloppement, permet de livrer au client une version de logiciel. Il est important de faire des livraisons rgulires du logiciel, pour que le client garde le contrle du logiciel que nous lui dveloppons. Typiquement un cycle peut durer trois semaines deux mois. Les exceptions viendront des gros logiciels, o une nouvelle version sort tous les ans. Comment sy prendre pour dcouper un logiciel en lot ? Nous allons lister lensemble des uses cases, en les valuant suivant deux critres : leur importance pour le client, et le risque technique de ralisation, en notant par exemple de un cinq chacun des critres. Nous comprenons bien quil vaut mieux raliser dabord un module de facturation quun module daide en ligne pour un commerant. Il est aussi important de raliser dabord les exigences fort risque technique, afin de vrifier la faisabilit technique, et la validit de la solution. Nous classerons les uses cases par leur pondration ( risque + importance ). Puis nous donnerons une logique ce classement. Cela peut nous amener ne vrifier quune faisabilit pour un use case particulier, ou traiter une partie des exigences dun use case dans un premier lot, et les autres dans un lot suivant. Ce dcoupage sera valid par le client, et nous donnera les diffrentes livraisons qui seront faites au client.
Notion de phases
Un lot est compos de plusieurs phases. Il y a 4 phases dans le dveloppement dun lot : - Inception ou cration - Elaboration - Construction - Transition
JC CORRE
25/10/2011
69
Nous allons voir en quoi consiste chaque phase, puis nous verrons que chaque phase est constitue dune ou plusieurs itrations.
Inception : Cette phase sert prouver la faisabilit.

Effort : 5% du temps total. Objectif : apprhender le contexte du dveloppement. Connatre, dans les grandes lignes, les services rendus aux utilisateurs principaux. Mettre en vidence les risques, et vrifier quils sont matriss. Choisir une architecture. Planifier la phase suivante Estimer assez prcisment les cots, dlais, ressources ncessaires. Documents produits : Principaux cas dutilisation Descriptions de haut niveau de ces uses cases
Elaboration : Cette phase sert construire larchitecture de base, et dfinir la plupart des
exigences. Effort : 20% du temps total. Objectif : Recueillir les exigences. Mettre en uvre les exigences haut risque. Faire une description dtaille des uses cases. Crer larchitecture du logiciel. Dfinir les niveaux de qualit requis pour le systme ( fiabilit, temps de rponse, ) Planifier et budgter le dveloppement Documents produits : Uses cases dtaills Diagrammes de squences bote noire. Diagramme de classes danalyse. Diagramme de classe de conception, diagrammes de collaboration, et contrats doprations sur quelques classes qui permettent de rendre le risque matrisable.
Construction : Cette phase sert btir le systme.

Effort : 65% du temps total. Objectif : Etendre lanalyse et la conception lensemble des classes non critiques du systme. Coder ces classes. Tester les classes unitairement. Prparer les tests du systme. Documents produits : Modle du domaine.
JC CORRE
25/10/2011
70
Diagramme de classe de conception, diagrammes de collaboration, et contrats doprations sur quelques classes qui permettent de rendre le risque matrisable. Code. Tests et procdures de test du systme. Surveiller les risques dtects en phases amont.
Transition : Cette phase sert tester et dployer le produit chez le ou les utilisateurs.
Effort : 10% du temps total. Objectif : faire les bta tests. convertir les donnes antrieures. former les utilisateurs. finalisation des manuels utilisateurs. corriger les derniers bugs. Documents produits : Diagrammes de composants. Diagramme de dploiement.
Notion ditration
Chacune des phases dcrites, peut tre effectue en plusieurs itrations. Par exemple dans la phase de conception, les itrations peuvent tre trs brves ( de lordre de la demi journe, jusqu deux jours ), et consiste implmenter une classe par exemple. Dans la phase dlaboration, une itration pourra par exemple traiter dun risque particulier.
JC CORRE
25/10/2011
71
phases
Inception
Elaboration
Construction
Transition Modlisation mtier
Exigences
Analyse et Conception
Implmentation
Tests
Dploiement
Initial
#1
#2
#1
#2
#n
#1
#2
itrations
JC CORRE
25/10/2011
72
conclusion
Nous avons vu quune mthode ( de type Unified Process ) qui sappuie sur UML, permettait davoir une dmarche danalyse et de conception qui nous amne de manire continue du problme du client, vers le systme quil dsire. Cette mthode est incrmentale et itrative. Le client voit se construire son logiciel petit petit, peut donc se lapproprier, se former, et mieux adapter le logiciel par rapport son besoin. Cette mthode permet au client de participer llaboration du logiciel, et permet aux dveloppeurs de prendre en compte les remarques du client sans avoir remettre en cause tout ce qui a dj t ralis. Elle permet galement de se construire des bibliothques dobjets mtiers, qui permettront de rduire les cots des prochains logiciels raliser. Les informaticiens vont enfin pouvoir capitaliser leurs comptences au sein de bibliothques dobjets. Il ne vous reste plus qu acqurir de la pratique dans cette mthode. Le dveloppeur commence devenir rellement autonome sur lensemble de cette dmarche au bout dun an de pratique, avec un tuteur. Bon courage.
JC CORRE
25/10/2011
73
bibliographie
Applying UML And Patterns Craig LARMAN Prentice Hall Pour approfondir la pratique dUML, je conseille de suivre le cours Analyse et conception avec UML et les Patterns " de la socit Valtech.
JC CORRE
25/10/2011
74

UML - Cas Complet - Démarche D'analyse Et de Conception Avec Le Langage UML Par JC CORRE

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

UML - Cas Complet - Démarche D'analyse Et de Conception Avec Le Langage UML Par JC CORRE

Transféré par

Droits d'auteur :

Formats disponibles

Dmarche danalyse et de conception avec le langage UML

Grenoble Le Pont de Claix

douzime tape : le diagramme de classe de conception ______________________________ 61

Le processus unifi _________________________________________________________ 69

conclusion ________________________________________________________________ 73 bibliographie ______________________________________________________________ 74

Grenoble Le Pont de Claix

Grenoble Le Pont de Claix

Objectif global dune dmarche danalyse et de conception objet

Grenoble Le Pont de Claix

Les tapes de la dmarche

Grenoble Le Pont de Claix

Grenoble Le Pont de Claix

Diagramme de uses cases

Use case haut niveau

Use case bas niveau

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

Diagramme de classe danalyse

:o1 1.1 : msg() :o2

Diagramme de classe de conception

Grenoble Le Pont de Claix

Processus de dfinition des besoins

fonction payer achat

Diagramme des acteurs

0..* est dans 0..1 magasin

magasin Diagramme contexte dynamique

Diagramme contexte statique

Diagramme de uses cases

Use case haut niveau

Grenoble Le Pont de Claix

Use case bas niveau

reprer les classes

Diagramme de classe danalyse

mettre les associations

mettre mthodes et attributs

Diagramme de classe danalyse

Diagramme de classe danalyse

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

:o1 1.1 : msg() :o2

Diagramme de classe de conception

Grenoble Le Pont de Claix

Grenoble Le Pont de Claix

Dfinition des besoins

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

Grenoble Le Pont de Claix

Caissier from Use Case View)

Client (from Use Case View)

Manager (from Use Case View

Salari (from Use Case View)

Administrateur (from Use Case View)

les acteurs de l'application

Grenoble Le Pont de Claix

se connecter dfinir les droits des usagers : Manager : Salari

Diagramm e de contexte du magasin

Grenoble Le Pont de Claix

(from Use Case View)

1 Salari (from Use Case View)

Manager (from Use Case View

administrateur (from Use Case View)

Diagramme de contexte statique (capture initiale des besoins)

Grenoble Le Pont de Claix

deuxime tape : les intentions dacteurs

Manager Client, Caissier Salari Manager Administrateur Client, Caissier

Grenoble Le Pont de Claix

conclusion __ 73 bibliographie 74