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

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…).

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▲

II-B-2. Principe▲

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

II-B-4. Site Web▲

II-B-5. La comptabilité▲

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…

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.

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▲

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

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.

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é :

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

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 ?

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.

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.

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.

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

• 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.

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…

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…

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é…

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

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.

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

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…

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.

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▲

VI-B-2. Fonctions annexes▲

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

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

VI-C-1. Acteur▲

VI-C-2. Liste des scénarios▲

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é.

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

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▲

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.

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 :

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…).

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

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.

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

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

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é▲

VII-D-2. Écran▲

VII-D-3. Cinématique▲

VII-D-4. Contrôles▲

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

Diagramme de classe associée

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.)

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.

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

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…

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

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.

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

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 :

Les scénarios à envisager sont donc :

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

VIII-E-1. Objectif▲

VIII-E-2. Quand▲

VIII-E-3. Paramètre de lancement▲

VIII-E-4. Algorithme▲

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▲

VIII-E-6. Diagramme de classe▲

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.

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…

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.

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

Description

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

…

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

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.

Auparavant, il semble utile de définir comment nous allons découper les objets métiers en 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.

• 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 ».

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.

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…