Étude de cas Conception UML : le Point de Vente Caissier (PVC)

(1)

1

Étude de cas Conception UML : le Point de Vente Caissier (PVC)

D’après l’étude de cas présentée par Hamid EL GHAZI et Adil REFAK à l’AIMAF 2007

Adaptation de V. Deslandres

Univ. Lyon1 – Module UML/DP licence pro DevOps, IUT Doua

(2)

2

Plan

• UML : démarche du Processus Unifié

• Description : Point de Vente type Caissier

• Analyse et conception du PVC - Etape par Etape

• Etape 1: Expression du besoin client

• Etape 2: Analyse du besoin client

• Etape 3: Conception

• Etape 4: Implémentation

(3)

3

Processus de développement logiciel objet

(4)

4

Le Processus de développement objet:

Unified Process (UP)

!

Le processus unifié (PU) prend en charge le cycle de vie du logiciel et son développement, pour les logiciels orientés objets

!

PU est une méthodologie de modélisation associée à l’utilisa- tion du langage UML

!

C’est un processus itératif et incrémental

(5)

5

! UML : démarche du PU

!

Description: Point de Vente type Caissier

(6)

Présentation générale

!

Il s’agit de modéliser la partie encaissement d’un magasin.

!

Caisse non automatique : un client arrive à la caisse avec les articles qu'il souhaite acheter.

!

Le caissier enregistre les achats et récupère le paiement.

!

A la fin, le client part avec les articles.

6

(7)

7

Etude de cas - PVC

Étape 1: Expression du besoin

par le client

(8)

8

Diagramme des Cas d’Utilisation

2 Packages

V. Deslandres, Univ. Lyon1

1 / 1 Saisie d'une vente

Gestion des sessions Modèle orienté objet

Modèle : caisseMagasin Package :

Diagramme : diagPackages Auteur : VDe Date: 07/11/2012 Version:

Terminal de banque

Centre autorisation Chèques Caissier

Responsable Magasin Client

(9)

9

Diagramme des Cas d’Utilisation

2 Packages

1 / 1 Saisie d'une vente

Gestion des sessions Modèle orienté objet

Modèle : caisseMagasin Package :

Diagramme : diagPackages Auteur : VDe Date: 07/11/2012 Version:

Terminal de banque

Centre autorisation Chèques Caissier

Responsable Magasin Client

(10)

10

Cas « Enregistrer les articles »

!

Acteurs:

!

caissier (déclencheur)

!

Description:

! Un client arrive à une caisse avec les articles qu'il souhaite acheter.

A chaque passage d’article, la description et le prix sont affichés.

! Le caissier enregistre les achats

.

Enregistrer les articles

(11)

Diagramme d’activité

Cas « Enregistrer les articles »

Enregistrer les articles

(12)

12

Cas « Fermer la caisse »

!

Acteurs:

!

caissier (déclencheur)

!

Description:

! Une fois sa journée terminée, le caissier signifie la fin de session. La caisse affiche alors le solde courant, que le caissier peut -s’il le désire- vérifier avec le contenu réel du tiroir, auquel cas il valide le solde puis quitte la session.

! S’il y a le solde affiche une valeur supérieure au contenu réel, le caissier doit renflouer le tiroir caisse, c’est sa responsabilité.

Fermer la caisse

(13)

13

Scénario avec un

diagramme d’activités du Cas « Fermer la session Caisse »

Caisse

(14)

14

Scénario avec un diagramme d’activités du cas d’utilisation :

« Démarrer une session caisse » Ici on voit que seul le responsable du magasin peut modifier la valeur du solde sur la Caisse, en démarrage de session.

On souhaite savoir quel caissier à fait appel au responsable (par ex. pour faire des analyses de

fréquence : si très fréquent, se poser des questions).

Aussi on peut savoir après quelle session caissier le réajustement du solde a été nécessaire (avec les dates des sessions).

(15)

15

Cas d’utilisation détaillés :

« Enregistrer les articles » et

« Effectuer règlement »

(16)

16

Scénario nominal « Enregistrer les articles »

Actions des acteurs Réponse du système

1. Un client arrive à la caisse avec les articles qu'il souhaite acheter.

2. Le caissier enregistre chaque article. S'il y a plus d'un exemplaire par article, le caissier indique également la quantité.

4. Après avoir enregistré tous les articles, le caissier indique au PVC que la vente est terminée.

6. Le caissier annonce le montant total au client.

7. Le client choisit le type de paiement:

a. En cas de paiement cash, voir la section « Paiement cash ».

b. En cas de paiement par carte de crédit, voir la section « Paiement par carte de crédit »

c. En cas de paiement par chèque, voir la section « Paiement par chèque ».

10. Le caissier donne le ticket de caisse au client.

11. Le client quitte la caisse avec les articles qu'il a achetés.

3. Affiche la description et le prix de l'article en question.

Détermine le prix de l'article et ajoute l'article à la transaction en cours.

5. Calcule et affiche le montant total de la vente.

8. Enregistre la vente effectuée.

9. Imprime un ticket de caisse.

(17)

17

Scenarios d’exception

« Enregistrer les articles »

! Point 3: identifiant d'article invalide

! Affichage d'un message d'erreur. Attente d’un nouveau code

! Annuler l’article

! Mettre la vente en attente (par ex. si le client va chercher un autre article)

! Point 7: le client ne peut pas payer

! Annuler la transaction en cours (=exception).

(18)

18

Scénario nominal du cas :

« Effectuer le règlement par carte de crédit »

Ce cas commence quand un client choisit de payer par carte de crédit après avoir été informé du montant total de la vente.

1. Le client transmet sa carte de crédit au caissier.

3. Le terminal de banque reçoit la demande, approuve le paiement et envoie la réponse.

2. Générer une demande de paiement par carte de crédit et la transmettre au terminal de banque.

4. Reçoit une réponse favorable de la part du terminal de banque.

5. Enregistre les informations concernant le paiement par carte de crédit et la réponse favorable. Il enregistre le montant à recevoir et le compte à créditer (on en garde la trace en cas de problème avec le règlement).

6. Affiche un message de confirmation de la transaction.

(19)

19

Ce cas commence quand le client choisit de payer par chèque après avoir été informé du montant total de la vente.

1. Le client rédige un chèque et fournit la preuve de son identité.

2. Le caissier enregistre les

informations sur l'identité du client et insère le chèque dans le boitier de vérification.

3. Génère une demande de paiement et l'envoie au centre d'autorisation des chéquiers.

4. Reçoit une réponse favorable de la part du centre d'autorisation.

5. Enregistre les informations concernant le paiement par chèque et la réponse favorable. Il enregistre le montant à recevoir et le numéro du chèque.

6. Affiche un message de confirmation de la transaction

Scénario nominal du cas :

« Effectuer règlement par chèque »

(20)

20

Ce cas commence quand un client choisit de payer en espèces, après avoir été informé du montant total de la vente.

1. Le client donne une certaine somme en espèces, qui est éventuellement plus élevée que le montant de la vente.

2. Le caissier enregistre la somme donnée par le client.

4. Le caissier encaisse l'argent reçu et délivre la monnaie à rendre.

3. Affiche la somme qui doit être rendue au client.

Scénarios alternatifs:

Point 1: le client n'a pas assez d'argent liquide. Il doit être possible d'annuler la vente ou de choisir un autre mode de paiement.

Point 2: Le tiroir de la caisse ne contient pas assez d'espèces pour qu'il soit possible de rendre la monnaie. Le caissier demande des espèces supplémentaires à son supérieur ou propose un autre mode de paiement.

Scénarios du cas :

« Effectuer règlement par espèces »

(21)

21

Cas d’utilisation : « initialiser »

!

Acteurs: Responsable magasin

!

Description:

!

Un manager allume une caisse, qui s'initialise.

!

L’initialisation consiste à ouvrir une connexion avec le

catalogue des produits et le stock.

(22)

22

Etude de cas - PVC

Étape 2: Analyse détaillée du besoin

(23)

23

Diagramme de Séquences du cas « Initialiser »

Caisse

(24)

24

Diagramme de Séquences

Cas «

Acheter des articles

^»

(25)

25

Diagramme de Séquences

Cas «

Effectuer règlement en espèces »

(26)

Opérations de la classe Caisse

! Vérification de la cohérence avec les diagrammes de séquences

! Manque établirConnexion() avec le catalogue Produits, idem pour Stock

" On décide que ça se fera dans Initialiser()

! SaisirMontantDélivré() et

CalculerRenduMonnaie() appelleront modifierSolde()

26

" On réalise que chaque action sur

le tiroir caisse doit modifier le solde

(27)

Classe d’analyse Caisse

27

Initialiser() contient l’appel à :

connecterCatalogue() et connecterStock()

Fermer la caisse

Que manque-t-il encore ?

String nom : correct ?

(28)

Premier Diagramme de Classes

1 / 1

identifie 0..*

0..*

donne lieu

1..1 0..1

<enregistre

1..1 0..*

Attention :

CalculerRenduMonaie() fait appel à modifierSolde() car le rendu monaie change le

solde du tiroir caisse

comprend>

0..* 1..*

enregistre

1..1

0..*

Modèle orienté objet Modèle : caisseMagasin Package : Saisie d'une vente Diagramme : 5DCL_Vente Auteur : VDe Date: 07/11/2012 Version:

Caisse

(Gestion des sessions)

+ +

numéro état

: int : int +

+ + + + + + +

initialiser ()

modifierSolde (float nouveauSolde) saisirMontantDélivré ()

calculerRenduMonnaie () éditerSolde ()

validerSolde ()

ouvrirSession (String nom, Date date, Date heure) fermerSession (Date date, Date heure)

: void : void : void : float : void : boolean : void : void

Vente

+ + + +

numéroVente date heure montant nb articles

: int : Date : float : int +

+ + + + +

encaisser ()

choisirTypeRèglement () ajouterMontantLigne () créerLdV ()

terminerVente () annulerVente ()

: void : String : void : LigneVente : void

Article

+ + + +

idArticle désignation PU

qté en stock : int : String : float : int

LigneVente

+ + +

quantité prix montant

: int : float : float + calculerMontant ()

On garde une trace du prix de l'article au moment de la vente

(promotion...). Le PU du catalogue, lui, peut fluctuer.

Paiement -

- - -

date heure montant type

: Date : Date : double : int

Package Vente

ouvrirSession(Personnel p, Date d, Date h) fermerSession(Personnel p, Date d, Date h)

(29)

DCL Package Gestion Caisse

1 / 1 utilise>

0..*

Modèle orienté objet Modèle : caisseMagasin

Package : Gestion des sessions Diagramme : 6DCL_GestionSessions Auteur : VDe Date: 07/11/2012 Version:

Personnel

+ + + +

nom prénom login passwd

: String : String : String : String + définirDroits () : void

Responsable

+ dateEmbauche : int + initialiserCaisse ()

Caissier

+ statut : String

initialiser() : connecter la caisse au Catalogue d'articles

et au stock

Caisse

+ +

numéro état

: int : int +

+ + + + + + +

initialiser ()

modifierSolde (float nouveauSolde) saisirMontantDélivré ()

calculerRenduMonnaie () éditerSolde ()

validerSolde ()

ouvrirSession (String nom, Date date, Date heure) fermerSession (Date date, Date heure)

...

: void : void : void : float : void : boolean : void : void

On garde une trace de qui utilise la caisse

ouvrirSession(Personnel p, Date d, Date h) fermerSession(Personnel p, Date d, Date h)

(30)

30

Etude de cas - PVC

Partie 2: Conception

(31)

Dans la partie Conception

!

Dessiner les IHM envisagées et vérifier la navigation

!

Spécification des contrats d’opération notamment

!

Quelles données seront persistantes ? Choix du mode de stockage

31

Présentation Métier

Données

On s’intéresse aux 3 couches :

(32)

Conception des packages techniques

dépendance

<<couche>>

PackageIHM

<<couche>>

PackageNoyau

<<couche>>

PackagePersistance

<<sous-système>>

PackageUtil

(33)

1- Couche Présentation : IHM

33

Nouvelle vente Session Responsable

Quitter

Écran Caissier en cours de session

Initialiser Quitter

Écran Responsable Magasin démarrage Caisse

Etc.

(34)

2- Couche applicative ‘Noyau’

!

Objectif : mieux structurer les classes issues de l’analyse

!

On verra que l’on peut s’aider des design patterns

!

Par exemple pour la connexion au réseau, utiliser le pattern Singleton qui assure qu’une classe a une instance unique, conservée dans une variable de classe (

static uniqueInstance

)

!

On traite les choix de conception et on affine les définitions des contrats d’opération

(35)

Choix de conception

!

Pour la gestion du stock, on a 2 choix :

!

Soit on a une classe Stock isolée avec pour chaque code article, la quantité en stock correspondante

! (choix sous-jacent aux besoins exprimés précédemment, qui correspond sans doute à l’organisation actuelle)

!

Soit on enregistre, dans le catalogue, la quantité en stock de chaque article

V. Deslandres, Univ. Lyon1 35

(36)

Étude des choix pour le stock

Un stock indépendant

# Le stock peut être transféré facilement à une autre application, par ex. du service Achat pour le réapprovisionnement des produits.

# On peut rapidement effectuer des analyses de l’évolution du stock au cours du temps

# Statistiques sur le nombre moyen de produits en stock, sur la durée moyenne où les produits

restent en stock élevé (par ex., 20% des articles restent en stock > 1000 unités pendant plus de 10 jours)

$ 2 accès seront nécessaires pour chaque ligne de vente

$ un accès à Catalogue pour connaître le prix et le libellé, et un autre à Stock pour la

quantité

V. Deslandres, Univ. Lyon1 36

(37)

Étude des choix de conception pour le stock

Stock intégré dans le Catalogue

# Un unique accès est nécessaire pour chaque ligne de vente

$ au Catalogue pour le prix, le libellé et la quantité

$ Le stock ne peut pas être transféré facilement à une autre application

$ Les analyses de l’évolution du stock au cours du temps sont plus complexes voir impossibles

37

% Choix discuté avec le client, une décision est prise

en fonction de ses besoins

(38)

38

Contrat d’opération: entrerUnArticle(CPU, qte)

! Opération: entrerUnArticle (CPU, quantite)

! Responsabilités: Enregistrer la vente d’un article et l’ajouter à la vente en cours. Afficher la description et le prix de l’article

! Pré-conditions: Il existe une description d’article avec un code CPU valide

! Post-conditions:

! S’il s’agit d’une nouvelle vente, elle a été créée (création d’instance)

! La vente a été enregistrée dans le système (relation établie)

! Une ligne de vente LdV a été créée (création d’instance)

! LdV a été associée à la vente (relation établie)

! LdV a été associée à la description d’article du produit (relation établie)

! La quantité demandée a été ajustée à la quantité fournie (attribut modifié)

! Le montant total a été augmenté du montant : prix article x quantité (attribut modifié)

! La quantité en stock de l’article a été diminuée de la qté de LdV (attribut modifié)

! Le prix et la description d’article ont été affichés (événement d’affichage)

(39)

39

Diagramme de Séquence:

Caisse::entrerUnArticle(CPU, qte)

(40)

40

Contrat d’Opération: terminerVente

!

Opération: terminerVente()

!

Responsabilités:

Enregistrer la fin de la saisie d’articles pour la vente en cours.

!

Pré-conditions:

La vente existe et est composée d’une ou plusieurs lignes de vente

!

Post-conditions:

! L’attribut booléen « estTerminee » de la vente en cours est mis à TRUE (attribut modifié)

! Le prix total et la quantité d’articles de la vente ont été affichés (événement d’affichage)

(41)

41

Diagramme de Séquences:

Caisse::terminerVente()

1 / 1 4DSQ_terminerVente

afficher (type règlement ?)

afficher (total Vente) total

total = total + MontantLdV montant_LdV get(montant_LdV) total = calculerTotalVente() setTerminee(true)

terminerVente signaler Fin de Vente

Modèle orienté objet Modèle : caisseMagasin Package : Saisie d'une vente Diagramme : 4DSQ_terminerVente Auteur : VDe Date: 07/11/2012 Version:

:Caisse :Vente :LigneVente

Caissier

[tant qu'il y a des LdV]

loop

afficher (type règlement ?)

afficher (total Vente) total

total = total + MontantLdV montant_LdV get(montant_LdV) total = calculerTotalVente() setTerminee(true)

terminerVente signaler Fin de Vente

afficher (le nbArticles)

(42)

42

Contrat d’Opération:

paiementCash(montant)

!

Opération: paiementCash(montant)

!

Responsabilités:

Enregistrer le paiement, calculer le solde (la monnaie) à rendre et imprimer le ticket.

!

Pré-conditions:

La vente existe, elle est composée d’une ou plusieurs lignes de vente et elle est complète

!

Post-conditions:

! Un objet « pmt » de type PaimentCash a été créé (création d’instance)

! « pmt » a été associé à la vente (relation établie)

! pmt.montant a été affecté au montant de la vente (attribut modifié)

! Un ticket a été créé (création d’instance)

! Le ticket est envoyé à l’imprimante (événement d’impression)

(43)

43

Diagramme de Séquences

Caisse:: paimentCash(montant)

(44)

44

Diagramme de classes de conception

Caisse (diagramme partiel,

manque le solde, dépend du choix du

client)

(45)

3- Couche Données

!

Données persistantes

!

Ce sont les données qui doivent perdurer, i.e. avoir une durée plus longue que la durée d’exécution

!

Pour Caisse :

!

Catalogue Produit, Ventes, Lignes de Vente

!

Caissiers, Managers

45

Fichiers ou BD

(46)

Diagramme de composants

Composants : Caisse (avec une interface d’authentification), le Catalogue (stock), les Ventes, le Paiement

Caisse

Catalogue

Paiement

Vente

(47)

Diagramme de déploiement

Noyau

Postes : Caisse,

Catalogue (stock), boîtier CB

(48)

48

Etude de cas - PVC

Partie 3: Implémentation

(49)

49

Exemple C++:

class Vente;

class Caisse { public:

Vente *venteCourante;

entrerUnArticle(String CPU, int quantite);

terminerVente();

traiterPaimentCash(int montant);

login(String nom, String password);

logout();

initialiser();

};

Caisse::entrerUnArticle(String& CPU, int& quantite) { //l’objet catalogue est unique pour l’application : // design pattern Singleton

DescriptionArticle* da=

Catalogue->instance()->getDescriptionArticle(CPU);

// creation nouvelle vente si besoin : if(venteCourante == NULL) {

venteCourante= new Vente();

}

venteCourante->ajouterLdV(da, quantite);

}

…

Caisse.cc

Caisse.h

(50)

Conclusion

!

UML, utilisé conjointement avec un AGL,

! permet de documenter les choix d’analyse et de conception

!

Grâce au processus de développement maîtrisé

! le produit est conforme à ce qui était prévu au départ

!

Grâce aux design patterns , le produit est évolutif

! on peut facilement modifier l’interface ou la persistance

!

Grâce à l’implémentation objet, le produit est modulaire et certaines parties portables

! Système d’exploitation, SGBD

50