Etude de cas – TPV (Terminal Point de Vente)

Présentation au sujet: "Etude de cas – TPV (Terminal Point de Vente)"— Transcription de la présentation:

1 Etude de cas – TPV (Terminal Point de Vente)
Etape 1: Elicitation du besoin des clients

2 TPV Itération 1: Diagramme de Use Cases

3 Use case: Acheter des articles
Acteurs: client (déclencheur), caissier Description: un client arrive à une caisse avec des 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.

4 Scénarios avec des diagrammes d’activité: Acheter des articles

5 Use case détaillé: Acheter des articles

6 Scénario nominal 3. détermine le prix de l'article et ajoute l'information sur l'article à la transaction en cours. affiche la description et le prix de l'article en question. 5. calcule et affiche le montant total de la vente. 8. Enregistre la vente effectuée. 9. imprime un ticket de caisse. 1. ce use-case commence quand un client arrive à la caisse avec des 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 TPV 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 payer cash. b. en cas de paiement par carte de crédit, voir la section payer par carte de crédit. c. en cas de paiement par chèque, voir la section payer par chèque. 10. le caissier donne le ticket de caisse au client. 11. Le client s'e va avec les articles qu'il a achetés. Réponse du système Actions des acteurs

7 Scenarios alternatifs
section 3: saisie d'un identifiant d'article invalide. affichage d'un message d'erreur. section 7: le client ne peut pas payer. annuler la transaction en cours (=exception).

8 Section: payer par carte de crédit
3. génèrer une demande de paiement par carte de crédit et la transmettre à un centre d'autorisation. 5. Reçoit une réponse favorable de la part du centre d'autorisation. 6.enregistre les informations concernant le paiement par carte de crédit et la réponse favorable. dans la rubrique crédit de son système de comptabilité il enregsitre le montant à reevoir et le compte à créditer (le centre d'auorisation doit l'argent au magasin donc la rubrique crédit doit garder la trace). 7. affiche un message de confirmation de la transaction. 1. ce use case commence quand un client choist de payer par carte de crédit après avoir été informé du montant total de la vente. 2. le client transmet sa carte de crédit au caissier. 4. le centre d'autorisation reçoit la demande, approuve le paiement, et envoie une réponse. Réponse du système Actions des acteurs

9 Section: payer par chèque
4. génère une demande de paiement par chèque et l'envoie à un centre d'autorisation. 6. reçoit une réponse favorable de la part du centre d'autorisation. 7. affiche un message de confirmation de la transaction. 1. ce use case commence quand un client choisit de payer par chèque après avoir été informé du montant total de la vente. 2. le client rédige un chèque et fournit la preuve de sont identité. 3. le caissier enregistre les informations sur l'identité du client et fait une demande d'autorisation de paiement, et envoie une réponse. Réponse du système Actions des acteurs

10 Section - payer cash Scénarios alternative:
4 affiche la somme qui doit être rendue au client. 1. ce use case commence quand un client choisit de payer en espèces, après avoir été informé du montant total de la vente. 2. le client donne en paiement une somme en espèces, elle est éventuellement plus élevée que le montant total de la vente. 3. Le caissier enregistre la somme donnée par le client. 5. le caissier encaisse l'argent reçu et sort la monnaie qu'il doit rendre Réponse du système Actions des acteurs Scénarios alternative: section 2: le client n'a pas assez d'argent liquide. il est possible d'annuler la vente ou de choisir une méthode de paiement. section 3: 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 une autre méthode de paiement.

11 Use case: initialiser Acteurs: manager
Description: un manager allume un TPV, qui s'initialise lui-même.

12 Use case détaillé: Initialiser

13 Scénario nominal 2. Le système TPV s'initialise.
1. ce use case commence quand un manager allume un système TPV. Réponse du système Actions des acteurs

14 Etude de cas - TPV Etape 2: Analyse du besoin

15 Diagramme de Séquence Système: Acheter articles (cash seulement)

16 Diagramme de Séquence Système: Initialiser

17 Diagramme de Séquence Système: Login/out

18 Opérations Système-TPV

19 Diagramme d’états du TPV

20 Modèle du domaine ou diagramme de classes d’analyse

21 Etude de cas - TPV Partie 2: Conception

22 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, il faut qu’elle ait été créée (création d’instance) Et que la vente ait été enregistrée dans le système TPV (relation établie) Une ligne de vente LdV a été créée (création d’instance) LdV a été associée avec une description d’article basée sur le CPU (relation établie) LdV a été associée avec la vente (relation établie) La quantité demandée a été ajustée à la quantité fournie (attribut modifié) Le montant total a été augmenté du montant de description d’article x quantité (attribut modifié) Le prix et la description d’article ont été affichés (événement d’affichage)

23 Diagramme de Collaboration: TPV::entrerUnArticle(CPU, qte)

24 Diagramme de Séquence: TPV::entrerUnArticle(CPU, qte)

25 Contrat d’Oparation: terminerVente
Opération: terminerVente() Responsabilités: Enregistrer ce qui constitue la fin de la saisie d’articles de la vente. Pré-conditions: La vente existe et est composée de une ou plusieurs lignes de vente Post-conditions: L’attribut booléen « estTrminee » est positionné à « true » (attribut modifié)

26 Diagramme de Collaboration: TPV::terminerVente()

27 Diagramme de Séquence: TPV::terminerVente()

28 Contrat d’Oparation: 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éer (création d’instance) « pmt » a été associé à la vente (relation établie) pmt.montant a été affecté à « montant » (attribut modifié) Un ticket a été créé (création d’instance) Le ticket a été associé à la vente (relation établie)

29 Diagramme de Collaboration: TPV::paiementCash(montant)

30 Diagramme de Séquence: TPV:: paimentCash(montant)

31 Diagramme de classes de conception

32 Etude de cas - TPV Partie 2: Implémentation

33 Exemple C++: TPV.h class Vente; class TPV { public:
Vente *venteCourante; entrerUnArticle(String CPU, int quantite); terminerVente(); traiterPaimentCash(int montant); login(String nom, String password); logout(); initialiser(); };

34 Exemple C++: TPV.cc TPV::entrerUnArticle(String& CPU, int& quantite) {
//un objet catalogue est unique ds toute l’appli: desing pattern Singleton DescriptionArticle* da= Catalogue->instance()->getDescriptionArticle(CPU); // creation nouvelle vente si besoin if(venteCourante == NULL) venteCourante= new Vente(); } venteCourante->ajouterLdV(da, quantite); …

35 Fin.. Questions ?