Le problème du magasin

Une des solutions informatiques que la plupart des programmeurs ont à exprimer dans leur carrière est celle du magasin.
Le magasin est un univers qui a un contenu - les marchandises, et des interactions avec l’extérieur -les clients.

Ce problème est similaire à la gestion de stocks, la vente en ligne et hors ligne, la facturation - dans sa forme la plus simple.
Il est également cliché tellement il inclut 4 CRUD et de la sécurité. C'est un peu le B-A BA, donc pas si simple.


Le principe

Le magasin est un syst√®me o√Ļ

Mais cela n'est pas possible sans un magasin déjà rempli

L'administrateur

Pour que le magasin ait été rempli, il faut qu'un administrateur ait rentré des marchandises après l'installation.



Le magasin peut donc être livré vide à l'installation, il sera rempli par un Admin.

L'achat

Vos utilisateurs vont finir par effectuer un achat après :




Le CRUD

C'est le moment d'ajouter toutes les action manquante : on s'attend

La vérification du CRUD sur ces cas d'utilisation révèle les manquants :

La sauvegarde du panier à l'enregistrement

La création de sections, produits et le changement de section

La modification dans l'écran "Mon panier"

Le détail des cas d'utilisation dans le "Parcours du site", qui reviennent tous à modifier les "filtres" de la la liste de produits



Un usecase, une séquence


Pour chaque usecase il faut tracer un diagramme de séquence !
Commencons par réduire le nombre de Usecase nécessaire


Exemple 1 : Pour faire de la création et de la modification, on a souvent besoin d'une seule fonction

Il suffit de faire une fonction foobar() qui

Le système a besoin d'une fonction createOrUpdateProduct(productId:String, properties:KeyValue*)


Exemple 2 : La plupart des lectures sont des "recherches avec filtres" dont le cas général - filtres à blanc - provoque la recherche de tous les éléments

Il suffit d'avoir une seule fonction qui "peut le plus" :

Le système a besoin d'une fonction findProducts(nameFilter:String, sectionFilter:String):Product*


Ci-dessous les séquences pour chaque UseCase

Administration basique

Pour le CRUD des objets, les méthodes suivantes sont nécessaires à l'administrateur



Certaines de ces méthodes vont également servir à l'administration



En ayant nommé 7 méthodes nous avons couvert les UseCases suivant :






La navigation

Le système comprends deux fonctions pour lister les sections et lister les produits.
Pour l'utilisateur qui a un navigateur - ou une GUI - c'est suffisant :

Le navigateur liste les sections, par exemple http://example.com/shop/data/products/search?filter=filter
Le navigateur liste les produits, par exemple http://example.com/shop/data/section/search?filter=filter2

Il combine ces données en une page HTML - ou GTK. Le usecase "Browse" est donc rempli.

Le usecase "Clear" devrait être facile à remplir également.


La gestion du panier

Le cas standard de navigation anonyme est géré. A un moment donné de la navigation, l'utilisateur va cliquer sur "Ajouter au panier".

Le système doit donc exposer les méthodes suivantes :

Avec ces méthodes on a couvert la gestion du panier, hors paiement :


Diagramme de séquence système

Les usecase non couverts sont donc :

Pour l'instant le "diagramme de séquence système" - c'est à dire les fonctions de plus haut niveau - contient :



Diagramme de classes


Le magasin prends forme en :



Dans cette modélisation,

Les composants obtenus ne contiennent que des "fonctions". Ce sont donc des interfaces.

Ce diagramme est appelé Diagramme des interfaces système. Il comprends les fonctions publiques à réaliser
- ni les fonctions privées qui surgiront du développement, ni les attributs superflus dans les Manager.


Le panier

Dans la modélisation ci-dessus il est supposé que le client est identifiable lorsqu'il appelle readBasket()
Très exactement la séquence suivante va arriver :
 


Deux problèmes se posent ici :
  1. Comment avoir un objet client ?
    • On peut supposer qu'il y aura une authentification,
    • qui laissera un cookie,
    • qui transmettra la session utilisateur,
    • qui contiendra l'identifiant client

  2. Si l'utilisateur n'est pas inscrit, que faire
    • Soit on "cr√©e un client en base" et on lui donne un cookie
    • Soit on propose la cr√©ation de compte
    • Soit on refuse la cr√©ation de panier et on attends le paiement pour forcer
      • la sauvegarde du panier
      • au moment du paiement
      • qui entraine la cr√©ation de compte

Il existe donc de multiples stratégies

La plupart des sites de vente en 2016 ont un fonctionnement du 3eme type :
L'enregistrement client n'est obligatoire qu'au dernier moment

Le panier a donc un statut particulier


Finalisation de l'Authentification et du paiement

Les UseCase restant à ce niveau, bien que la décision soit prise de "Sauvegarder temporairement" les paniers jusqu'a ce que "l'internaute anonyme soit un client", sont :

Soit en listant les UseCase génériques uniques :


Plus de séquences

L'enregistrement se passe comme suit, une fois le bouton "Register" appuyé


L'authentification est équivalente à vérifier le bon mot de passe

A partir du moment ou un cookie de session est envoyé à l'utilisateur,
Il le renvoie a chaque requete
Il est considéré comme Client


L'édition de profil est aussi un simple CRUD


Le paiement

Supposons qu'il existe une bibliotheque externe pour réaliser le paiement, par exemple
GAFAPayService.performTransaction(fromClientAccount:String, toCommerceAccount:String) en envoyant un SMS au client.

Alors le paiement devient :


Reportons maintenant


Diagramme de classes

Le diagramme de classe final est