IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Rédaction des documents d'analyse avec U.M.L

Cet article décrit la démarche d'écriture des documents de spécifications en s'appuyant sur la notation UML. Il part de la réponse au cahier des charges jusqu'à la rédaction du dossier de conception. Il ne prétend pas être une analyse ou un document méthodologique, simplement un exemple essayant de donner la réponse à une question que nous rencontrons souvent lors des formations « Quand dois-je utiliser tel ou tel schéma ? ». Nous avons préféré mettre en avant les commentaires de la démarche plutôt que la rédaction d'un document de spécification en tant que tel et nous avons privilégié une lecture transversale du document vous permettant de comprendre rapidement comment on s'appuie sur les schémas pour la rédaction. Le cas exposé est décrit dans le cahier des charges. Il est, comme tout cahier des charges, insuffisant, ce qui introduit la notion de risque inhérent à tout projet. La démarche de construction va donc s'enrichir dans les phases ultérieures de réunions dont nous donnons le résumé par la rédaction de (fictifs) comptes-rendus. Il ne s'agit pas d'un cours UML, ni d'un plan qualité, mais seulement d'une approche vous permettant, nous l'espérons, de visualiser l'apport d'UML dans une rédaction. Bonne lecture…

Article lu   fois.

L'auteur

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. L'auteur

Pierre Meleard est chef de projet.

Depuis 1998, Pierre Meleard a dirigé des projets au forfait qui l'ont amené à s'intéresser au design et à l'eXtreme Programming. Il a mené de nombreuses missions comme consultant (Gestion de projet, intégration des nouvelles technologies de développement…) ou comme formateur (Software design, Design pattern, tests unitaires, Swing, J2EE…). En 2005, Pierre Meleard a intégré le cabinet Infhotep comme directeur technique.

II. Cahier des charges

II-A. Préambule

Vos commerciaux font bien leur travail. Votre société est identifiée comme acteur principal des communautés de commerçants et vos solutions sont connues comme innovantes et techniquement à la pointe du mouvement… Vous recevez donc le cahier des charges que voici : (non je sais, un cahier des charges comme celui-ci, vous en rêvez, disons qu'il est le compte-rendu de réunions préliminaires…).

II-B. Le besoin

Des commerçants souhaitent participer à l'animation du centre-ville par la création d'un groupement de commerçants dont les principaux objectifs sont :

  • attirer la clientèle en centre-ville par la création d'une carte de fidélité ;
  • animer des opérations de marketing (Semaine de promotion…) ;
  • constituer un carnet d'adresses des clients pour des opérations de mailing ciblées.

Le modèle économique adopté est le suivant :

  • tous les mois, le groupement demande aux commerçants adhérents de verser une cotisation de fonctionnement ;
  • sur chaque achat donnant lieu à un acte de fidélisation, le commerçant accorde une remise de 5 % sur le montant de l'achat. Sur cette remise est prélevée une participation aux frais destinée au prestataire informatique ;
  • Le budget initial de mise en place du groupement relève de subventions ou de sponsoring.

Le groupement n'ayant que peu de moyens financiers souhaite des propositions d'un prestataire informatique pour la mise en place de la carte de fidélité et son hébergement.
Le prestataire pourra se rémunérer par des frais fixes pris sur chacun des actes de fidélisation (montant prélevé sur la remise accordée).

II-B-1. Architecture

Tous les commerçants sont dotés d'un TPE (Terminal de Paiement Électronique) sur lequel, à côté du logiciel de paiement bancaire, peut être installé un logiciel de fidélité.

Le TPE dialogue avec un serveur hébergé chez le prestataire qui mémorise les transactions et effectue les calculs de fidélité. Le serveur doit disposer d'une application permettant d'effectuer la comptabilité de fin de mois en liaison avec les banques et de calculer les statistiques.

Un serveur WEB doit permettre au groupement de saisir les informations nécessaires au fonctionnement de la fidélité.

II-B-2. Principe

Le principe de la fidélité est le suivant :

  • chaque client est possesseur d'une carte de fidélité magnétique valide dans tous les commerçants du groupement ;
  • chaque achat donne lieu à une provision de remises (Montant d'achat * 5 % - frais). Le commerçant est débité chaque mois des provisions accordées plus la cotisation de fonctionnement au profit d'un compte détenu par le groupement ;
  • au bout du dixième achat, la somme des provisions (moins les frais) devient une remise accordée au client qui est déduite par le commerçant du montant du dixième achat. Si la remise accordée est supérieure au montant de l'achat, le commerçant débourse de sa caisse la différence. Le commerçant est crédité du montant de la remise accordée, en fin de mois, à partir du compte du groupement.

II-B-3. Acte de fidélité

Lorsqu'un nouveau client arrive, le commerçant donne au client une carte magnétique au logo du groupement permettant d'effectuer les actes de fidélité. Le commerçant demande au client de remplir un coupon papier sur lequel le client donne son adresse. Le commerçant complète le coupon avec le numéro de la carte de fidélité. Le coupon est envoyé à la secrétaire du groupement qui effectue la saisie des adresses.

L'enregistrement d'un acte d'achat donnant lieu à une remise au titre de la fidélité est le suivant :

  1. Le commerçant saisit le montant de l'achat ;
  2. Le commerçant introduit la carte de fidélité ;
  3. Le TPE appelle un serveur chez le prestataire informatique par le réseau commuté ;
  4. Le serveur reçoit la demande de fidélité avec le numéro du commerçant, le numéro de la carte et le montant. Il vérifie l'existence de la carte, du commerçant et calcule le montant de la fidélité ;
  5. 1er cas :

    1. si le client n'a pas droit à la remise, le serveur renvoie la provision de remises accordées,
    2. le TPE édite un ticket en double exemplaire (l'un pour le commerçant, l'autre pour le client) avec le nom du commerçant, la date d'achat, le montant de l'achat, la provision de remises, le cumul des provisions et le rang de l'achat,
    3. le commerçant encaisse la totalité du montant de l'achat ;
  6. 2e cas :

    1. le client a droit à une remise, le serveur renvoie les informations permettant le remboursement de la remise (somme des provisions - somme des frais) ;
    2. le TPE édite un ticket comprenant, le nom du commerçant, la date d'achat, la provision de remises sur cet achat, le montant des provisions de remises, et le restant dû par le client (Achats - remises). Il est possible que la somme des remises soit supérieure au montant de l'achat ;
    3. le commerçant encaisse le montant de l'achat moins la remise ou décaisse l'écart.

II-B-4. Site Web

Le site Web doit permettre au groupement de paramétrer l'application sur le serveur, de saisir les adresses et d'effectuer des interrogations sur la vie des cartes. Peu de commerçants disposent d'internet. La secrétaire du groupement est la principale utilisatrice du site Web.

II-B-5. La comptabilité

La comptabilité est décrite plus haut.
Elle est effectuée en fin de mois pour les transactions du premier au dernier jour du mois. Le groupement souhaite que les prélèvements et les virements soient effectués automatiquement vers la banque qui détient le compte du groupement.

III. Cas d'utilisation principal

III-A. Préambule

Vous devez donc répondre au cahier des charges en tant que prestataire et montrer que vous avez compris les besoins du groupement. Vous cherchez aussi à évaluer le budget de réalisation…

III-B. Use case Principal

Vous allez donc à définir les principales actions par lesquels les utilisateurs vont interagir avec le système d'information. Vous ne cherchez pas à entrer dans le détail, mais à être exhaustif, c'est-à-dire couvrir l'ensemble des besoins. Vous déterminez donc un premier découpage de l'application, les acteurs puis les actions des utilisateurs sur les domaines.

III-B-1. Diagramme du cas d'utilisation

Le premier souci est de définir les grands domaines de l'application. On peut en distinguer principalement trois largement identifiés en termes d'acteurs et de moyens mis en œuvre :

  • l'administration et le paramétrage : L'administration est effectuée par la secrétaire du groupement via une interface Web ;
  • la fidélité proprement dite : Les actes de fidélité sont effectués chez les commerçants sur les TPE ;
  • les traitements de fin de mois (statistiques et comptabilité). Ces traitements sont effectués par le prestataire informatique au titre de l'hébergement et de l'exploitation.

Les acteurs principaux sont :

  • les commerçants ;
  • la secrétaire du groupement ;
  • la banque semble un acteur secondaire qu'il faut mentionner. La banque sera en effet notre correspondant pour les échanges informatiques des virements et prélèvements ;
  • le prestataire est aussi un acteur, notamment lors des opérations de fin de mois. Vous pouvez supposer la nécessité d'un minimum de statistiques.

Il est noté que le client final n'est pas un acteur dans le sens où il n'interagit pas directement avec le système. Le client sera considéré simplement comme une entité du système d'information.

Image non disponible
Cas d'utilisation principal

Un schéma n'est jamais explicite en lui-même. Il doit s'accompagner d'un texte d'explication. Vous décrivez donc les acteurs puis chacune des actions qui feront l'objet d'études plus détaillées.

III-B-2. Description des acteurs

Acteur

Rôle

Secrétaire

Responsable de l'administration du groupement.

Commerçant

Réalise les actes de fidélités.

Banque

Acteur secondaire vers qui le système doit envoyer les virements et prélèvements du compte du groupement.

Prestataire

Le prestataire est responsable de l'exploitation du système. Il intervient en fin de mois notamment pour déclencher les traitements.

III-B-3. Description des cas d'utilisation

Scénarios

Description

Saisie des adresses

Entrer les adresses dans la base de données avec le numéro de carte associé. Cette base de données doit permettre aux commerçants d'effectuer des mailings.

Interroger

Interrogation des actes de fidélité pour renseigner les commerçants ou les clients.

Acte de fidélité

Passage d'un achat de fidélité. Vous pouvez supposer des fonctions complémentaires comme l'annulation, le remboursement ou des demandes de duplicatas.

Mailing

Demande de fichier d'adresse

Virement - prélèvement

Calcul de la comptabilité (et des statistiques) et envoi des fichiers de virements - prélèvements à la banque.

Vérifier comptabilité - Suivre l'activité

Réception des statistiques. Vérification des données comptables.

Exploitation (fin de mois)

Déclenchement de la clôture du mois. Édition des statistiques.

Ce cas d'utilisation vous permet d'obtenir une vision synthétique des fonctionnalités du système. Il vous a (bien entendu) demandé un peu d'imagination pour prévoir des fonctionnalités non prévues dans le cahier des charges, mais qui vous semblent indispensables…

Il vous aide à déterminer les principales zones de risques. La notion de risque est toujours subjective suivant les acteurs. Vous devez rassurer votre correspondant chez les commerçants et vous rassurer vous-même sur les points qui vous semblent délicats…

Plusieurs points semblent particulièrement importants :

  • l'acte de fidélité. Il est en effet au cœur de l'activité du système. Sa simplicité aidera l'adhésion des commerçants. Un premier dessin du ticket remis au client permettra au groupement de concrétiser l'acte de fidélité ;
  • le fait que le système comporte un TPE. Il y a là une contrainte d'architecture technique primordiale pour l'élaboration de la solution. C'est un facteur de risque important, car, n'ayant pas de compétences particulières sur le développement des TPE, vous préférez sous-traiter la solution ;
  • l'organisation du projet. Vous devez tenir compte que la réussite d'un projet n'est pas seulement résumée à l'informatique et que beaucoup d'acteurs vont intervenir pour le démarrage de celui-ci. L'ensemble doit être coordonné dans un temps très court. Pour des raisons commerciales, et ne pas faire peur à votre prospect, vous préférez aborder ce point oralement, et garder la rédaction du rôle de chacun des participants que si l'affaire est signée….

Les commentaires associés au cas d'utilisation général doivent donc rapidement cerner ces points. Vous rédigez les chapitres correspondants.

III-C. Acte de fidélité

Nous devons décrire l'acte de fidélité ou plutôt, puisqu'il est bien détaillé dans le cahier des charges, montrer que vous avez parfaitement compris ce dont il s'agit. Un diagramme de séquence est tout à fait indiqué. Vous ne cherchez pas à rendre exhaustif le diagramme, mais simplement à étudier le cœur du problème dans un fonctionnement nominal.

Image non disponible
Diagramme de séquence : Acte d'achat

Vous décrivez ensuite les séquences principales du diagramme (quelque chose qui ressemble à un couper-coller du cahier des charges fera l'affaire… ).
Vous décrivez ensuite une proposition pour les deux tickets principaux à éditer. Ceci permet de concrétiser le résultat de l'acte de fidélité :

Image non disponible

Image non disponible

III-D. Diagramme de classe

Un premier diagramme de classe est possible. Il permet de donner une approximation de la complexité du logiciel à construire.

Image non disponible
Premier diagramme de classe

La fidélité doit permettre le remboursement des remises provisionnées. Nous appelons « Série » l'ensemble des mouvements d'achats ayant donné lieu à ce remboursement.

Plusieurs questions restent en suspens :
La carte de fidélité est un acteur du modèle. Elle sert à identifier le client. Le schéma fait porter l'adresse par la carte. Ceci corresponde il à la réalité ? Ne faut-il pas introduire la notion de client pour identifier une personne qui veut changer de carte en cas de perte ? Une personne peut-elle avoir plusieurs cartes ? Quels sont les besoins statistiques ? Faut-il un journal des remboursements ?

III-E. Épilogue

Vous pouvez faire de même pour les autres scénarios. Ils vous permettront de réaliser une première estimation de votre budget. Mais celui-ci ne peut être complet ou réaliste sans aborder le problème de l'architecture.

IV. Architecture

IV-A. Préambule

Le deuxième point de risque est représenté par le TPE. Quelques coups de fil et une réunion sont nécessaires pour mettre l'architecture en place.

IV-B. Réunion avec les constructeurs de TPE

Les TPE doivent comporter un logiciel client.
Le système d'exploitation des TPE est propriétaire aux constructeurs. Ils disposent de leurs propres A.P.I.
Le protocole de transmission adopté entre le TPE vers le serveur est la norme d'échange des cartes bancaires (CBPR).

Le prestataire informatique ne souhaite pas investir dans le développement sur les TPE. D'autre part, les TPE bancaires sont installés par des tierces parties (les mainteneurs) généralement en sous-traitance de la banque du commerçant.

En accord avec le groupement :

  • les mainteneurs réaliseront l'installation du logiciel client. Le groupement prend en charge l'organisation de la relation commerçant - banque – mainteneur ;
  • le développement du logiciel sur le TPE client est sous-traité à un seul constructeur. Les commerçants installeront tous un TPE de cette marque à la place ou en plus de leur TPE bancaire.

IV-C. Diagramme de déploiement

À la suite de cette réunion, vous êtes prêt à proposer une architecture.

Image non disponible
Diagramme de déploiement : Architecture du matériel
  • Le serveur de fidélité est un serveur dédié aux applications de gestion. La base de données est placée sur ce serveur.
  • Pour plus de souplesse, un frontal de télécommunication est mis en place. Son rôle est de prendre en charge les appels multiples, les time-out, la conversion du protocole d'échange bancaire en entrée et en sortie avec le serveur applicatif.
  • Pour des raisons de sécurité, vous placez un serveur web dédié dans la DMZ.

IV-D. Épilogue

Maintenant que vous avez décrit les principaux cas d'utilisation et que vous avez dessiné une architecture, vous êtes prêt à remettre votre proposition…

V. Organisation du projet

V-A. Préambule

Votre réponse technique et commerciale a donné entière satisfaction et vous voilà C.P. du projet “Carte de fidélité”. Votre premier souci est d'organiser le projet…

V-B. Grant du projet

Il semble que pour tenir les délais, il faille mener plusieurs opérations en parallèle :

  • la relation avec le constructeur pour qu'il puisse démarrer rapidement les développements ;
  • l'organisation de la part du groupement de la mise en place de la fidélité (Logo des cartes, relation avec la banque, relation avec les mainteneurs…) ;
  • la mise en place de l'architecture interne (achat machine, installation…) ;
  • la spécification des besoins.

Dans le cas de délai court de mise en place, un diagramme de Grant peut être très utile. Pour conserver une notation U.M.L., un diagramme d'activité est tout indiqué…

Image non disponible
Grant des tâches

V-C. Description des tâches du projet

Vous prenez ensuite votre plume pour spécifier le rôle de chacun…

Libellé

Commentaire

Date

Spécification générale

Elles doivent comprendre :

  • De manière détaillée les spécifications d'échange avec l'opérateur de TPE
  • Définir de manière exhaustive (1) l'ensemble des tâches à réaliser
 

Spécification détaillée WEB

Description des écrans Web, diagramme de navigation…

 

   

Commande des cartes

 

   

Certaines tâches ne sont pas précisément décrites dans le graphe précédant. Elles nécessitent d'être détaillées.

V-D. Tâche : Commande des cartes

Image non disponible
Grant : Commande des cartes

Nous vous laissons le soin de décrire chacune des étapes…

V-E. Épilogue

Les autres tâches du road map sont à reprendre suivant le même principe.
Maintenant que vous avez listé les tâches et les contraintes, il vous reste à construire le planning en fonction de l'organisation de votre équipe.
Bonne chance…

VI. Détaillons…

VI-A. Préambule

Vous devez maintenant vous concentrer sur la spécification des besoins qui permettra d'alimenter les autres tâches.

Trois scénarios dans le cas d'utilisation principale sont décrits. Il est maintenant temps de les préciser à tour de rôle.

Le cœur du métier est l'acte de fidélité. C'est donc le premier point par lequel commencer. Pour cela une réunion d'analyse avec le groupement et le constructeur de TPE est organisée.

VI-B. Réunion : L'acte de fidélité

Vous abordez avec le groupement l'utilisation du TPE chez les commerçants. Il apparaît qu'il ne faut pas oublier :

  • les cas dégradés et leurs solutions ;
  • le fait que le TPE est le principal moyen de communication entre le commerçant et le système d'information.

VI-B-1. Cas dégradés

Cas

Solution

Erreur sur la transaction (généralement erreur sur la saisie du montant)

Annulation de la dernière transaction qu'il y ait remboursement des remises cumulées ou non. Puis le commerçant recommence la transaction. Pour éviter les fraudes, seule la dernière transaction peut être annulée. La carte doit être dans le lecteur.

Perte du ticket

Demande de duplicata. Le duplicata ne peut porter que sur la dernière transaction ou annulation. Il n'est pas nécessaire que la carte soit présente dans le lecteur

Time-out (Temps de réponse > 2 mn)

Abandon de la transaction. Le commerçant recommence.

Pas d'établissement de la ligne

Abandon de l'acte de fidélité.

VI-B-2. Fonctions annexes

Les fonctions annexes sont les suivantes :

Cas

Solution

Le client souhaite connaître l'état de sa carte (Cumul des provisions, rang dans la série)

Le commerçant introduit la carte dans le lecteur et par menu, choisit une option « Consultation ».

Le commerçant souhaite connaître le cumul des remises du mois précédent et du mois en cours pour son commerce

Le commerçant introduit sa carte commerçant et par menu choisi une option « Interrogation ».

Le constructeur du TPE présent à la réunion nous permet de mettre au point les échanges. Nous apprenons au passage :

  • qu'un commerçant possède une « carte commerçant » qui permet de l'identifier. Le numéro de commerce sera donc le numéro de cette carte ;
  • que toutes les cartes possèdent un numéro d'application qui permet de réaliser les contrôles de validité de la carte introduite. Ainsi seront rejetées toutes les cartes n'ayant pas ce numéro (vous ne voulez pas de cartes de parking !).

En devançant la réunion sur l'administration des cartes, nous découvrons que certaines cartes peuvent être annulées ou remplacées en cas perte.

VI-C. Cas d'utilisation

La réunion sur l'acte de fidélité permet l'établissement du cas d'utilisation correspondant.

Image non disponible

Comme pour chaque cas d'utilisation, nous décrivons succinctement les acteurs et les scénarios

VI-C-1. Acteur

Acteur

Rôle

Commerçant

Unique acteur du cas d'utilisation. Il est responsable du passage des actes de fidélité en présence du client.

VI-C-2. Liste des scénarios

Scénario

Description

Passage d'un achat

Scénario principal du cas d'utilisation. Il consiste à enregistrer un achat dans le commerce afin de provisionner des remises. Si plus de 10 achats ont déjà été effectués, le système doit proposer le remboursement des remises provisionnées.

Annulation

Doit permettre d'annuler le dernier acte d'achat effectué en cas d'erreur. Si le commerçant n'est pas certain si la transaction précédente est enregistrée ou non, il peut interroger la carte client.

 

VI-D. Scénario : Passage d'un achat

Puis vous devez approfondir chacun des scénarios… Vous commencez par le plus important : l'acte d'achat.

Le cas nominal du passage d'un acte d'achat au titre de la fidélité a été vu lors du cas d'utilisation principal. Il semble maintenant nécessaire de le détailler en tenant compte des contrôles et des cas dégradés. Un graphe de séquence serait trop complexe et illisible. Nous préférons un diagramme d'activité.

Image non disponible

Il reste à décrire plus précisément chaque étape.

Code

Étape

Commentaire

1

Saisie du montant

La saisie du montant est effectuée par le commerçant. C'est le premier acte du scénario. On suppose que toutes les transactions sont en Euro.

2

Contrôle du montant

En cas d'échec, Le TPE affiche :
Le montant saisi et la mention « Montant incorrect »
La transaction est abandonnée.
Si le montant est correct, le TPE passe en étape 3.

3

Affichage montant

Le TPE contrôle le montant et l'affiche sur l'écran :
le montant saisi et la mention « Introduire carte »
Si la carte n'est pas introduite dans les 2 minutes, la transaction est arrêtée.

4

Introduction carte

Le commerçant demande la carte au client et l'introduit dans le TPE

5

Contrôle carte

Le TPE lit la bande magnétique sur la carte. En cas de carte illisible ou incorrecte, le TPE affiche le message « Carte incorrecte » et abandonne la transaction.

6

Initialisation de la connexion

Le TPE appelle le serveur par le réseau commuté.
En cas d'échec, le TPE essaie au plus 3 tentatives.
Si la connexion est réussie, le TPE affiche le message « Connexion en cours ».
Si la connexion est en échec après 3 tentatives, le TPE affiche « Échec de connexion » et la transaction est abandonnée.
Le message d'échange d'initialisation est donné plus en annexe.

7

Réception transaction

Le serveur prépare le traitement de la demande. Il aiguille sur le traitement des achats.

8

Contrôle commerçant

Le serveur recherche la carte commerçant dans la base de données.
Si le commerçant est non identifié ou n'est pas autorisé le serveur va en 8.1 sinon il va en 9.

8.1

Préparation commerçant invalide

Le serveur formate les informations à envoyer au TPE. Le message envoyé au serveur est de type échec.
La transaction est abandonnée.

9

Contrôle de la carte

Le serveur lit la carte dans la base de données.
En cas d'échec, il va en 9.1
En cas de lecture réussie, il va en 9.2.

9.1

Création de la carte

Le serveur crée un enregistrement carte dans la base de données avec les informations suivantes :

  • N° de carte
  • mtCumulProvision = 0
  • nbAchat = 0
  • etatCarte = « OK »

9.2

Contrôle de la carte

Si la carte est annulée ou remplacée, le serveur va en 9.3 sinon en 10.

9.3

Préparation carte invalide

Le serveur formate les informations à envoyer au TPE. Le message envoyé au serveur est de type échec.

10

Enregistrement de l'achat

Le serveur enregistre l'achat dans la base de données. Le montant du cumul des provisions est mis à jour.
Le serveur va à l'étape 11.

11

Calcul des remises

Montant remise = Mt Achat * Taux remise - Frais.
Mise à jour du mtCumulProvision de la carte
Incrémentation du nombre d'achats de la carte.

12

Préparation provision

Mise à jour de la base de données.
Le serveur formate les informations à envoyer au TPE. Le message envoyé au serveur est de type « Transaction acceptée ».

13

Remboursement

Mise à jour de la base de données
Mt Remboursement = Somme des montants remises provisionnées.
Mise à zéro du montant des cumuls de provision de la carte et du nombre d'achats de la série.
Le serveur formate les informations à envoyer au TPE. Le message envoyé au serveur est de type « Remboursement accepté ».

14

Réception demande ticket

Le TPE reçoit le message de la part du serveur et prépare l'édition.
Les opérations 15 et 16 sont en parallèle.

15

Édition ticket

(Présentation de la maquette du ticket ici.)

16

Accusé de réception

Le TPE envoie au serveur un accusé de réception. Le serveur peut alors valider les mises à jour de la base de données

VI-E. Annexe

Quelques précisions d'ordre technique sont nécessaires. Elles ne sont pas destinées à l'utilisateur final qui validera l'analyse. Un chapitre particulier (à défaut d'un document spécifique) est consacré à ces annexes.

VI-E-1. Message d'échange avec le TPE

Message

N° de la carte commerçant (6N)
Code fonction (XXX)
N° de la carte (6N)
Date du message (SSAAMMJJ)
N° du message (NNNN)
Montant de l'achat (NNNNNN.NN)
Libellé du message : 15 lignes de 20 caractères

Code fonction

AC : Achat
EC : Échec
AN : Annulation

VI-E-2. Diagramme de classes

Le modèle de données pour réaliser les transactions d'achat doit être précisé. le résultat obtenu est légèrement plus complexe que lors de la réponse au cahier des charges… Mais il reste un modèle fonctionnel.

Image non disponible
Diagramme de classe : Acte d'achat

Ce diagramme doit être complété, notamment par la liste des statuts :

 

Liste des états de la carte (Classe EtatCarte)

OK

Carte acceptée

AN

Carte annulée

RE

Carte remplacée

Remarques

  • Pour des raisons d'optimisation en termes de performance, nous choisissons de stocker les résultats des calculs plutôt que de les recalculer à chaque transaction. Ceci nous met aussi à l'abri des modifications dans les formules de calcul des remises.
  • Les remboursements sont mémorisés dans une nouvelle table. Il stocke le résultat des calculs et le mouvement qui a porté le remboursement. Tous les mouvements sont identifiés par un attribut Id.
  • De manière similaire, tous les remboursements porteront un identificateur. Les transactions ayant donné lieu à un remboursement seront indicées par cet identificateur. Ceci permettra de retrouver toutes les transactions d'une série.
  • Nous construisons une classe CalculAchat pour le calcul des remises et la cinématique de l'ensemble. Cette classe permet de centraliser les algorithmes de calcul.

Il peut être nécessaire de vérifier qu'aucune méthode ou attribut n'est oublié par des diagrammes de collaboration (les diagrammes de séquence sont parfois plus lisibles…). Seul le cas des remboursements est donné ici :

Image non disponible
Diagramme de collaboration : Remboursement

VI-F. Autres scénarios

Les autres scénarios sont à analyser de la même manière.
Pour chacun des scénarios, il est nécessaire de construire un diagramme de classe. Deux approches sont possibles.

  1. Consolider les diagrammes de classes en ajoutant les nouvelles fonctions et attributs qui apparaissent
  2. Construire un diagramme de classe ne permettant de réaliser que le scénario en cours.

La deuxième approche nous semble préférable. Elle permet de lire les scénarios indépendamment les uns des autres et de conserver une approche « De quoi ai-je besoin pour réaliser le cas d'utilisation ? ».
Une deuxième étape est alors nécessaire pour consolider tous les diagrammes de classes. Cette consolidation permettra de changer de point de vue et passer à une vue « métier », c'est-à-dire à une consolidation des besoins par entité (Carte, mouvement, commerçant…).

VII. Description d'une interface homme-machine

VII-A. Préambule

Le cas d'utilisation suivant est l'administration. Une réunion sur ce point est vite apparue nécessaire.

VII-B. Réunion : L'administration

Le premier diagramme de classe semblait peu clair sur la relation entre une carte et une adresse. Vous discutez de ce point avec le groupement. La solution retenue doit permettre d'effectuer des mailings, donc d'identifier des individus. Vous devez envisager aussi les cas dégradés (perte de la carte, piste illisible…).

Les règles suivantes sont retenues :

  • une personne n'a qu'une adresse ;
  • une personne peut avoir plusieurs cartes. Mais les cartes ne sont alors pas cumulatives (les provisions de remises sont gérées au niveau de la carte et non au niveau de la personne). De ce principe, il est admis que la notion de personne est abandonnée. Le système ne saura gérer que des cartes ;
  • il est possible qu'une personne perde sa carte. Il doit alors être possible d'annuler la carte pour éviter son utilisation suite à un vol ;
  • une carte peut être endommagée. Il doit alors être possible de la remplacer par une nouvelle carte. Le report des provisions de remises et de l'historique des transactions est automatique.

Les commerçants sont enregistrés dans le système d'information :

  • les commerçants seront identifiés par leur numéro de carte commerçant. Ceci est une contrainte du constructeur de TPE ;
  • le commerçant donnera un compte bancaire sur lequel seront effectués les virements -prélèvements ;
  • un commerçant peut abandonner la fidélité ;
  • un commerce peut changer de propriétaire. Il est admis qu'une nouvelle carte commerçant sera émise par la banque.

Les autres fonctionnalités attendues du site web sont les suivantes :

  • recherche d'une carte par le nom et/ou la ville de la personne ;
  • historique des achats en cours pour une carte ;
  • historique des achats et des remboursements pour une carte ;
  • historique des achats et des remboursements pour un commerçant.

VII-C. Description du cas d'utilisation : Administration

Vous connaissez la démarche, allons au plus vite…

Acteur

Rôle

Secrétaire

Unique acteur du cas d'utilisation. Il est admis que les commerçants qui à terme se connecteront sur le site Web, ne disposeront pas de fonctions spécifiques.

Scénarios

Description

Administration des adresses

Permet d'enregistrer ou de modifier des adresses

 

Il est ici nécessaire de réaliser le diagramme de navigation du site Web. Un diagramme d'état semble suffisant.

Image non disponible
Diagramme d'état : Navigation du site Web

VII-D. Scénario Saisie carte

Le scénario doit permettre de saisir une adresse pour un numéro de carte. L'écran associé doit notamment permettre de visualiser l'état de la carte. Il n'y a pas d'apport particulier d'UML dans la description d'un écran. Vous restez classique…

VII-D-1. Fonctionnalité

  • Permettre la saisie ou la modification d'une carte.
  • Un menu contextuel permet d'accéder aux fonctions liées à la gestion des cartes.

VII-D-2. Écran

Image non disponible
Écran de gestion des cartes

VII-D-3. Cinématique

VII-D-3-a. Étape 1

L'utilisateur entre le numéro de la carte.

  • Le bouton « Abandonner » permet de retourner au menu.
  • Le bouton « Rechercher » permet d'aller sur l'écran de recherche. Suite à une recherche réussie, l'écran se positionne en étape 2.
  • Le bouton « Confirmer » permet de passer en étape 2.
VII-D-3-b. Étape 2

Le n° de carte devient en affichage.

  • Si le numéro de la carte existe, les informations de la carte sont affichées, les liens « Annuler carte », « Remplacer carte », « Achat en cours » et « Historique » sont activés.

L'utilisateur effectue la saisie puis clique sur « Confirmer ».

  • Le bouton « Abandonner » permet d'abandonner la saisie ne cours et revient en étape 1.
  • Le bouton « Annuler carte » permet d'aller dans l'écran d'annulation de la carte.
  • Le bouton « Remplacer carte » permet d'aller dans l'écran de remplacement de la carte.
  • Le bouton « Achat en cours » permet d'aller dans l'écran de visualisation des achats de la série.
  • Le bouton « Historique » permet d'aller en recherche des mouvements et des remboursements.
  • Le bouton « Confirmer » permet d'enregistrer la saisie et revient en début d'étape 1.

VII-D-4. Contrôles

M : Modifiable, O : Obligatoire

Libellé

M

O

Format

Remarque

N° de carte

 

X

6 numériques

 

Statut

     

Table des statuts. Voir « Annulation carte » et Remplacement carte »

Civilité

X

   

La civilité doit appartenir à la table des civilités définie par le système.

Nom

X

X

32 Alpha

 

Rue

X

 

32 Alpha

Attention la rue n'est pas obligatoire

Code postal

X

X

5 Alpha

Les caractères doivent être numériques.

Ville

X

X

26 Alpha

 

VII-D-5. Fonctionnalités supplémentaires

  • Il est impossible de modifier une carte remplacée ou annulée. Par contre, il est possible de visualiser les historiques.
  • Si la carte est annulée ou remplacée, les liens « Annuler carte » et « Remplacer carte » sont inactifs.

VII-E. Annexes

Diagramme de classe associée

Image non disponible
Diagramme de classe : Administration

La classe EtatCarte nous indique comment activer ou désactiver les différents liens.
L'adresse porte des fonctions de contrôle sur ses attributs. (Il n'est pas possible en UML de spécifier des exceptions, mais au niveau design, il serra possible de remplacer les booléens retournés par des exceptions qui sont plus précises sur la condition refusée et permettent de passer des messages d'erreurs.)

VII-F. Épilogue

Il est bien sûr possible de compléter les annexes par tous les éléments nécessaires à la bonne compréhension du cas d'utilisation.
La description des algorithmes peut prêter à discussions. Certains considèrent qu'ils doivent être validés par les utilisateurs, d'autres non… Peut-être n'y a-t-il pas de bonne formule… S'adapter en fonction du niveau de compréhension de l'interlocuteur à notre préférence…

Faire de même pour les autres cas d'utilisation et scénario de l'administration.

VIII. Traitement batch

VIII-A. Préambule

Le scénario concerne la comptabilité fin de mois. Une réunion avec la banque est nécessaire.

VIII-B. Réunion : Traitements bancaires

Le format d'échange est précisé avec la banque ( le fichier d'échange doit respecter la normalisation bancaire).
La banque indique qu'une fois reçus, les virements et prélèvements ne peuvent être injectés dans le circuit bancaire qu'avec l'accord du groupement. Cette procédure reste manuelle par envoi d'un fax au responsable du compte de la banque. Le fax doit mentionner la mention « Accord de débit/crédit pour un montant de xxxx,xxx en date du xx/xx/xx ».

Du point de vue du groupement, cette validation demande une statistique…

VIII-C. Cas d'utilisation : Fin de mois

Ce cas d'utilisation ne contient pas de difficultés particulières.

Acteur

Rôle

Fin de mois

Acteur fictif figurant la fin de mois. La fin de mois déclenche le déroulement du cas d'utilisation.

Scénarios

Description

Comptabilité

 

La réunion sur les traitements fin de mois permet d'y voir plus clair. Elle introduit notamment un workflow sur les virements-prélèvements.

Image non disponible
Diagramme d'activité : Validation de la comptabilité

Vous prenez soin de décrire chacune des tâches…

VIII-D. Cas d'utilisation : comptabilité

Pour quelques instants les notations UML sont abandonnées pour revenir aux comptes en T de nos comptables !
Le schéma comptable est le suivant :

Image non disponible
Mouvements comptables

Les scénarios à envisager sont donc :

Scénario

Description

Provision de remises

Du débit du commerçant au crédit du groupement

Frais

Du débit du groupement au crédit du prestataire

Remise

Du débit du groupement au crédit du commerçant

Cotisation

Du débit du commerçant au crédit du groupement

VIII-E. Comptabilité de fin de mois : Traitement des provisions de remises

Le traitement « provision de remises » et « frais » est effectué en un seul passage.

VIII-E-1. Objectif

Effectuer les mouvements comptables de fin de mois sur les remises accordées.

VIII-E-2. Quand

Lancement automatique, dans la nuit du 1er au 2e jour ouvré du mois.

VIII-E-3. Paramètre de lancement

  • Année/Mois à prendre en compte

VIII-E-4. Algorithme

 
Sélectionnez
Calculer la date de fin de mois
  Récupérer le compte du groupement
  Récupérer le compte du prestataire
  Parcours de tous les mouvements du mois triés par commerçant
     Pour chaque commerçant
        Lire le commerçant (pour récupérer son numéro de compte)
        Initialiser le cumul des provisions de remises
        Pour chaque mouvement
           Cumuler le montant des provisions de remises
           Cumuler le montant des frais
           Marquer le mouvement comme comptabilisé (Année/Mois de
           comptabilisation)
        Fin Pour
        Écrire un mouvement comptable du débit du commerçant au
        crédit du groupement du cumul du montant des provisions
     Fin pour
     Écrire un mouvement comptable du débit du compte du groupement
     vers le crédit du compte du prestataire pour le cumul des
     frais.
  Fin pour

VIII-E-5. Reprise en cas d'erreur

  • Remettre la marque de comptabilisation du mois à blanc (Ce que vous pouvez faire de manière systématique. Ceci permet une reprise automatique…).
  • Relancer le traitement.

VIII-E-6. Diagramme de classe

Image non disponible
Diagramme de classe : Comptabilité

VIII-F. Épilogue

Le même exercice est à faire pour les mouvements de remboursement et les cotisations.
Le transfert des fichiers mouvements vers la banque est à décrire. Cette description doit notamment décrire les moyens techniques de mise en œuvre du transfert (Protocole, adresse serveur…) par un diagramme de déploiement.

Le deuxième scénario du cas d'utilisation « Fin de mois », c'est à dire les statistiques est décrit dans le chapitre suivant.

IX. Description d'une édition

IX-A. Préambule

Dans le cadre du cas d'utilisation « Fin de mois » le groupement demande une statistique permettant de vérifier les mouvements comptables. Une réunion permet de préciser les besoins…

IX-B. Réunion : Statistiques fin de mois

La réunion permet d'aborder les statistiques.
En fait les statistiques nécessaires à la comptabilité seront suffisantes. Le site Web est là pour les autres besoins.

Nous définissons donc :

  • les statistiques détaillées commerçant : Mouvement par mouvement. Elles justifieront la comptabilité commerçant ;
  • les statistiques cumulées par commerçant : Elles sont destinées au groupement. Elles permettront de justifier la comptabilité du groupement et d'effectuer la validation des virements-prélèvements.

IX-C. Statistique : Comptabilité commerçant

Vous êtes maintenant rodés à la mise en forme d'un cas d'utilisation. Passons directement à la description de la statistique.
UML n'offre pas d'aide particulière. Restez classique…

Objet

Représenter les mouvements et remises du mois.
Déclenchement

  • Automatique en fin de mois

Paramètres en entrée

  • Année/Mois à traiter

Tri

  • Par commerçant
  • Par date de mouvement

Sélection

  • Mouvement du mois en paramètres.

Dessin

Image non disponible
Statistique commerçant

Description

Zone

Description

Montant remise

Montant de la remise accordée au client si le mouvement donne lieu à remboursement.

 

Totaux

Par commerçant

  • Montant achat
  • Montant provision
  • Montant frais
  • Montant remise

Total général

  • Montant achat
  • Montant provision
  • Montant frais
  • Montant remise

Rupture de Page

  • Par commerçant

Algorithme

L'algorithme n'est pas très loin de celui de la comptabilité…

Diagramme de classe

IX-D. Épilogue

Il vous reste à décrire de la même manière l'ensemble des statistiques pour terminer le cas d'utilisation « Fin de mois ».

X. Conception

X-A. Préambule

Vous avez au cours des différents cas d'utilisation, recensé l'ensemble des besoins. Il apparaît maintenant nécessaire d'effectuer une synthèse des modèles de classes dessinés à chaque cas d'utilisation. L'objectif est triple :

  • obtenir une vision « Entité » qui prépare l'étape de design ;
  • obtenir un schéma de base de données ;
  • valider que l'ensemble des scénarios est cohérent.

X-B. Découpage en package

Auparavant, il semble utile de définir comment nous allons découper les objets métiers en packages.

Image non disponible
Découpage des packages

Ce découpage semble relativement naturel. Il n'offre pas de cycles (2) apparents ce qui facilitera le design.

Nous avons néanmoins introduit deux classes « AnnulerCarte » et « RemplacerCarte » qui détiendront les algorithmes de ces actions. Il semblait plus naturel de les mettre dans le package Carte mais :

  • l'effort principal de programmation va porter sur les mouvements et non sur les cartes (modifier les numéros de carte dans les mouvements, modifier leur statut..) ;
  • ceci introduirait un cycle entre le package carte et le package Mouvement.

Nous avons introduit un package de type « FrameWork » qui contient des entités génériques largement réutilisables d'une application à l'autre. Les dépendances par rapport à ce package ne sont pas montrées.

X-C. Package Carte

Image non disponible
  • L'adresse appartient à un autre package. Nous préférons la considérer dans le package carte comme une interface dont l'implémentation sera une classe du package « Framework ».

X-D. Base de données

La transformation des classes en entités de la base de données est assez simple. Il suffit d'introduire des identifiants permettant la liaison entre les tables.
Contrairement aux diagrammes de classes, le modèle des données doit chercher à être exhaustif. Néanmoins, nous ne représenterons ici que la partie concernant les cartes.

Image non disponible

X-E. Épilogue

Ce modèle de conception donne une vision d'implémentation. Il structure les développements.
Mais le travail de programmation transformera encore une fois ce diagramme en introduisant contraintes de design et patterns. Finalement le diagramme de classes fera apparaître encore d'autres objets…

XI. Conclusion

Nous avons essayé de montrer l'apport d'UML dans le travail de spécification.

L'utilisation des diagrammes est au choix du rédacteur. Il ne doit pas chercher à poser tel ou tel diagramme à telle ou telle étape de son analyse en fonction d'une méthode d'analyse qui spécifierait chacune des étapes, mais simplement illustrer son propos lorsqu'il le juge opportun.
Le niveau de détail (niveau d'abstraction) pose souvent problème lorsque l'on démarre les rédactions de spécification en s'appuyant sur UML. En fait, vous dessinez un diagramme pour un lecteur. Adapter le niveau de détail en fonction de ce qu'il attend. Par analogie, vous pouvez comparer vos diagrammes à une carte. Si vous parlez de la géographie mondiale, une carte du monde est suffisante, vous n'avez pas besoin de dessiner les rues de Paris ou l'entrée du port de Marseille. Votre diagramme, non détaillé, n'est pas faux pour autant… Mais attention, ne tombez pas dans l'erreur de considérer qu'un diagramme se suffit à lui-même. Un diagramme est un support de communication. Pour être compris, il doit nécessairement être explicité par le « verbe »…
Notre exemple était relativement simple. Nous n'avons pas cherché à être exhaustifs dans la spécification, mais simplement à montrer les différents cas que vous pouvez rencontrer. Dans une analyse d'ampleur plus importante, les spécifications sont découpées en plusieurs documents qui croisent interlocuteurs et niveaux de détail. Le découpage des documents est alors à définir avec vos interlocuteurs (MOA, architectes, exploitation…).

Même si UML n'est pas une méthode, mais simplement une notation, il prend en compte l'importance des analyses orientées cas d'utilisation. L'important n'est pas dans la notation des cas d'utilisation, somme toute très pauvre, mais dans la démarche implicite :

  • un cas d'utilisation spécifie ce qu'attend un utilisateur du système. En bref, ne partez pas de la description d'une organisation ou des fonctions intrinsèques à un sujet… Vous reconstruirez ces deux dernières notions en partant de ce que veut l'utilisateur. C'est en ce sens que les méthodes orientées cas d'utilisation ne sont pas des méthodes fonctionnelles ou organisationnelles (Merise) ;
  • les cas d'utilisation structurent l'analyse. Le cas d'utilisation principal définit le domaine de votre projet. Vous reprenez alors chacun des cas pour les affiner dans d'autres cas d'utilisation, ainsi de suite. Cette démarche vous permet de garantir la complétude de l'analyse.

Dans notre exemple, l'arbre des cas d'utilisation est le suivant :

  • carte de fidélité

    • Administration

      • Gestion des cartes

        • Recherche des adresses
        • Saisie adresse
        • Annulation carte
        • Remplacement carte
        • Liste des achats en cours
        • Historique des achats et remboursements d'une carte
        • Demande de mailing
      • Gestion des commerçants

        • Saisie des commerçants
        • Historique des achats et remboursements d'un commerçant
    • Fin de mois

      • Comptabilité

        • Provision de remises
        • Frais
        • Remise
        • Cotisation
      • Statistiques

        • Statistique détaillée par commerçants
        • Statistique cumulée par commerçant
    • Acte de fidélité

      • Achat
      • Annulation
      • Demande de duplicata
      • Interrogation statistique commerçant
      • Interrogation carte client

Le plus souvent, vous ne pourrez obtenir un tel graphe au début de l'analyse. Si vous chiffrez un tel projet, vous savez bien, par expérience qu'il vous faudra écrire quelques statistiques, même si ce besoin n'est pas encore énoncé par votre client…
Votre démarche doit donc être orientée « par le risque ». Étudier d'abord ce qui vous semble le plus risqué. Dès que le risque vous semble circonscrit, passez au sujet suivant… Mais circonscrire le risque ne veut pas dire aller au niveau de détail le plus fin. Si vous faites cela, vous laissez d'autres zones d'ombres en jachère… qui elles peuvent porter d'autres risques encore insoupçonnés…

Bon UML.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Ce document est soumis à la licence GNU FDL traduit en français ici.
Permission vous est donnée de distribuer, modifier des copies de cette page tant que cette note apparaît clairement.