UML 2003

Prsentation base sur un exemple simple : mise en oeuvre d'un logiciel interactif permettant la tenue du des comptes d'un petit commerant (mtaphore du livre de compte du commerant qui doit rester cohrent avec l'argent qui se trouve rellement en caisse).

1.
1.1

Modlisation mtier (business modeling)

Strotypes pour la modlisation mtier :

L'Acteur Mtier est EXTERNE l'entreprise Le Travailleur Mtier appartient l'entreprise L'entit Mtier est manipule par le Travailleur Mtier

1.2
1.2.1

Modlisation d'un processus mtier (Jacobson)

Diagrammes de cas d'utilisation mtier (calqus sur ceux d'UML)

1.2.2

Diagrammes d'activit pour modliser un processus mtier

Modliser un processus : ensemble d'activits ordonnes et affectes des acteurs identifis. Couloirs d'activit : les activits associes un acteur dans une bande verticale.

A partir de la modlisation des processus mtier, on peut passer la modlisation fonctionnelle qui dcrira les tches informatises par slection de certaines activits mtier.

2.

Modlisation fonctionnelle

Mthodologie : 1. Identifier les acteurs, a. humains ou systmes connexes b. principaux ou secondaires 2. Etablir le diagramme de contexte statique 3. Identifier les cas d'utilisation (UC) 4. Description essentielle des UC a. textuellement b. graphiquement 5. Description relle des UC a. textuellement b. graphiquement

2.1

Acteurs

Entit externe : humain, dispositif ou autre systme. Un acteur peut consulter et/ou modifier l'tat du systme grce des messages porteurs de donnes envoys et/ou reus. 2.1.1

Identifier les acteurs

Acteurs humains : identifier tous les profils possibles (administrateur, oprateur de maintenance, etc.). o commerant, client Systmes connexes agissant par le biais de protocoles (bidirectionnels). o caisse enregistreuse actor Caisse enregistreuse

2.1.2

Comment les reprsenter ?

2.1.2.1

Description textuelle Client acteur secondaire ayant le commerant comme interlocuteur Caisse enregistreuse systme connexe contenant l'argent et imprimant les tickets destination des clients

Commerant personne habilite se servir de la caisse enregistreuse, disposant de la clef de la caisse et ayant un ID et un mot de passe reconnus par le systme 2.1.2.2

Diagramme de contexte statique

2.2

Cas dutilisation (Use Cases UC)

Ensemble de squences dactions ralises par le systme (comportement attendu considr comme un tout) et qui produit un rsultat voulu par un acteur. On cherche identifier un comportement (ce quil doit faire) et non la faon dont ce comportement sera mis en uvre (comment il le fait). 2.2.1

Comment identifier les UC ?

Dcrire toutes les exigences fonctionnelles du systme Un UC correspond une fonction mtier du systme selon le point de vue dun acteur. Comment les analyser ?

2.2.2

Recenser de faon textuelle toutes les interactions entre Acteurs et Systme. Prciser les variantes possibles : les diffrents cas nominaux, les alternatives, les cas derreur. 2.2.3 Comment les reprsenter ?

Description essentielle dtaille ou relle dtaille. Description textuelle : Parties obligatoires Sommaire didentification : titre, rsum, date de cration/modification, version, responsable, acteurs, etc. Description des scnarios : nominal, alternatifs, erreur, pr et post conditions Parties optionnelles IHM : contraintes dIHM (rgles dergonomie, charte graphique), copies dcran, maquette, etc. Contraintes non-fonctionnelles : frquence, disponibilit, fiabilit, performances, confidentialit, concurrence, etc.

Description graphique : Schma incluant des UC (ovales) relis aux acteurs par des associations (lignes) 2.2.3.1 Description essentielle dun UC

UC Annulation Sommaire didentification : Titre : Annulation Type : Essentiel Rsum : Annulation dune vente par un client qui sera rembours Acteurs : Commerant (principal) Caisse (secondaire) Date de cration : 24/11/03 Date de mise jour : 25/11/03 Version : 1.0 Responsable V. Gaildrat Description des scnarios : o Pr-conditions o Scnario nominal Commerant Systme 1) Saisie des donnes pour le remboursement 2) vrification que le remboursement correspond bien un achat 3) vrification du fond de caisse suffisant 6) Le commerant prlve la somme dans la 4) cration dune nouvelle ligne comptable caisse et la donne au client 5) acquittement pour le commerant o Enchanements alternatifs A1 : Saisie errone - enchanement au point 1 2) le remboursement ne correspond pas un achat effectu pralablement 3) chec du remboursement reprise au point 1 o Enchanements derreur E1 : Fonds insuffisants - enchanement au point 2 3) solde insuffisant 4) chec remboursement stopp anormalement o Post-conditions : la caisse contient moins dargent correspondant au montant du remboursement 2.2.3.2 Paragraphes optionnels dun UC

Besoins dIHM Ecran pour affichage du formulaire de saisie Clavier de saisie Caisse enregistreuse Contraintes non-fonctionnelles Temps de rponse Mono ou multi-utilisateurs 2.2.3.3 Un UC : Description graphique des UC

Diagramme dactivit Versus qui montre les alternatives et erreurs

Diagramme de squence systme pour le cas nominal

Diagramme systme enrichi permet de visualiser les principales actions du systme 2.2.4

Organisation des UC

Relations dinclusion (factorisation dun sous UC), dextension (incorporation dun comportement, obligatoire dans un autre cas mais optionnel ou rarement utilis dans le cas prsent), de gnralisation Acteurs principaux gauche, secondaires droite

Regroupement en packages

2.2.5

Description relle dun UC

VENTE : Proposer une fentre graphique simple pour lIHM du commerant : (voir TP) 1) Description textuelle : Commerant 1)le client arrive et annonce les produits souhaits 2)saisie des donnes grce lIHM, validation 6)annonce du montant 7)le client paye 8)argent encaiss 10)ticket et consommation au client Systme 3) cre la ligne comptable 4) affiche le montant 5) crdite le solde 9)dite le ticket Caisse

3.

Passage de l'analyse la conception

A partir des processus mtier on a dtermin les UC avec les alternatives et les erreurs. Les diagrammes de squence dtaills vont tre maintenant dvelopps afin de dterminer les classes du systme et leurs relations pour tablir le diagramme de classes.

Analyse

Conception
3.1 Strotypes (Jacobson)

: EntityName

: ControlName

: BoudaryName

3.2

Diagrammes dinteraction de conception

Un diagramme de squence ou de collaboration par opration systme nominale, d'anomalie (reprise correcte) ou d'erreur (pas de reprise possible). McGood : - Package Gestion consommations o vente nominale anomalie lors de la saisie pas de stock vente annule o remboursement nominale anomalie lors de la saisie pas de vente correspondante annulation du remboursement - Package Gestion caisse o prlvement nominal anomalie d'identification anomalie de saisie : montant > solde erreur d'identification erreur de saisie : montant > solde annulation du prlvement o versement nominal anomalie d'identification anomalie de saisie : montant ngatif erreur d'identication erreur de saisie : montant ngatif

3.2.1

Prlvement

N'importe qui ne peut pas effectuer un prlvement dans la caisse. Pour vrifier le droit d'accs il faut introduire la gestion d'un mot de passe dans le formulaire de saisie. La transaction qui sera stocke sera un Dbit qui devra mmoriser la date, l'identification de la personne autorise ayant effectu le prlvement, le montant. 3.2.1.1

Identifier les classes partir de la spcification textuelle

Compte qui permet de garder la trace de toutes les transactions effectues et non juste le solde de ces transactions, Dbit qui en est forme de transaction. Diagramme de squence

3.2.1.2

On n'a pas fait figurer ici les classes d'interface, juste pour allger

La vrification de la validit de la personne (nom + mot de passe) est dlgue au contrle "Identification".

Choix de conception : Le nom de la personne qui a effectu le prlvement est stock dans le Debit. Ce scnario concerne un prlvement nominal : pas d'erreur de saisie (personne autorise et mot de passe correct, ainsi qu'un montant infrieur au solde). Pour traiter les cas d'erreur et les anomalies, il faut faire un diagramme par cas d'erreur et en aucun cas surcharger le diagramme du cas nominal. 3.2.2 Vente

On souhaite ajouter dans les comptes le fait qu'une vente a t effectue. Cela veut dire qu'il faudra ajouter une transaction de type Crdit. Question poser : Comment dfinir la transaction crdit : Faut-il crer une seule transaction pour toute une vente un client ou ne vaut-il mieux pas tablir une transaction pour chaque produit vendu (date, label, prix U, total).

3.2.2.1

Identifier les classes partir de la spcification textuelle

Produit avec label et prix unitaire du Produit, SDDProduit qui regroupe tous les produits et va offrir un moyen de recherche la rfrence d'un Produit en particulier, Compte qui permet de garder la trace de toutes les transactions effectues et non juste le solde de ces

transactions, Crdit qui est une forme de transaction, Diagramme de squence

3.2.2.2

Choix de conception : Le solde est recalcul aprs toute modification, ajout ou suppression d'une transaction. Ici, aprs l'ajout d'un Crdit dans le Compte, le solde est recalcul. Une transaction Crdit est ajoute pour chaque type de Produit vendu.

3.2.3

Annulation de la vente dun produit

Pour annuler la vente d'un produit il est possible de crer une ligne comptable dbitrice qui contient la date, le nom du produit, le prix unitaire, la quantit et le total. Cette possibilit n'est pas directement faisable avec la conception choisie car la ligne comptable dbitrice ne contient pas toutes ces informations. - Il faudrait ajouter une classe hritire de Dbit qui contienne toutes les informations ncessaires.

Ou bien reprendre la classe Crdit pour la rendre neutre ( ni crditrice, ni dbitrice) et faire hriter cette classe de deux classes une Crditrice et une Dbitrice. - Ou bien crer une nouvelle classe LigneComptable et placer dedans les attributs ncessaires la cration d'un Crdit ou d'un Dbit, de faon ce que seule l'opration de solde soit diffrente selon que l'on ait affaire un Crdit ou un Dbit. Ainsi on cre un Dbit qui annule seulement l'effet du Crdit. - Une autre solution est de faire une classe LigneComptable et de faire deux sous-classes : une sous-classe LigneComptablePersonne (qui correspond aux prlvements et versements) et une LigneComptableProduit (qui correspond aux ventes et annulations).
-

3.2.3.1

Diagrammes de squence correspondants

C'est le contrle Identification qui effectue la vrification du mot de passe et du solde. Puis le contrle Prlvement assure la continuit du flot de donnes en fournissant les informations ncessaires (et valides) au Compte pour qu'il puisse ajouter une transaction de Dbit. 3.2.3.2 Annulation vente produit

Choix de conception : On considre qu'on peut annuler la saisie de la vente de plusieurs produits la fois (pour conserver un modle d'interface proche de celle de la saisie). Il serait peut-tre plus judicieux d'annuler la vente d'un seul produit la fois. La gestion des erreurs en sera simplifie. Ici, tous les produits annuls ont bien t vendus et font donc partie des transactions Crdit stockes dans Comptes. Si la quantit annuler est suprieure ce qui a t vendu : soit on invalide la transaction, soit on accepte d'annuler concurrence de ce qui a t rellement vendu.

4.
4.1

Modlisation dynamique
Diagrammes dtat

Un diagramme dcrit les changements dtat dune instance dune classe : un diagramme pour une classe. Seulement pour les classes pour lesquelles ce diagramme est significatif.

Diagramme dtat pour la classe Compte

5.
5.1

Modlisation statique
Diagramme de classes

Les diagrammes de classe partiels sont tablis au fur et mesure de l'tablissement des diagrammes de squence. Ensuite on regroupe le tout pour crer un diagramme de classes complet. Question : La transaction Crdit doit-elle stocker la rfrence du Produit vendu, ou seulement des informations qui permettraient de le retrouver. Dans l'optique de l'tablissement d'un papier de comptabilit, on pencherait plutt pour cette deuxime solution : le comptable n'a rien faire de la rfrence du Produit. De plus, si le PU du Produit change, ce qui a t vendu ne doit pas changer ! La solution fournie n'est qu'une des diverses possibilits envisageables, titre d'exemple