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ù

• Des utilisateurs parcourent les rayons - si c'est du web, les sections
• Ils remplissent des paniers avec un ou plusieurs produits, parfois plusieurs fois le même produit
• Lors du paiement une trace est conservée - sur le web, c'est le dernier moment de s'enregistrer comme client

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

L'administrateur

• Des marchandises, mais aussi
• Des rayons - ou des sections
  

L'achat

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

• Navigation dans les sections ou par nom de produit
• Ajout d'un ou plusieurs produits au panier
• Sélection de la fonction Terminer ma commande

Le CRUD

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

• Pour chaque objet de la modélisation
• A avoir une manière de le
  
• • Create : le créer, avec un état inital ou pas
  • Read : lire la liste de ces objets, avec filtre dans le cas de la recherche
  • Update : modifier un élément, en totalité ou partie
  • Delete : supprimer un ou plusieurs éléments, et modifier les parents en conséquence

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

• Créée un produit si le parametre "productId" n'est pas rempli
• Modifie les propriétés passées en paramêtre - que ce soit une création ou une modification

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*

Administration basique

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

• Création, lecture, modification, suppression sur Produit
• Création, lecture, modification, suppression sur Section
• Modification du lien Produit-Section
  

• Lecture/recherche de produits
• Lecture/recherche des sections
  

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 :

• L'enregistrement
• L'authentification
• La modification de profil
• Le paiement
  ... conservons-les pour la fin de la modélisation

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

Diagramme de classes

• Reportant les fonctions ci-dessus dans Systeme
• Séparant en composants logiques - mais arbitraires
• Reportant les structures de données obligatoires
  

• La classe System est déduite des UseCase
• Les classes ProductManager, SectionManager et BasketManager sont "mon arrangement arbitraire"
• Les classes Product,Section,Basket et ProductQuantityLine sont des structures

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

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

• Site de vente avec enregistrement obligatoire dès qu'on "gère son panier"
  
• Site de vente ou même la navigation nécessite un compte - fonctionnement de type Pinterest
• Site de vente ou le panier est sauvé localement puis transféré sur le serveur dès la 1ère inscription

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

• Il existe en cookie ou localStorage du Navigateur de l'utilisateur - stockage temporaire, mais qui résiste au reboot
• Si un identifiant de client duement authentifié existe - alors il est copié également sur le serveur
• Lors du paiement, on doit garder le panier temporaire jusqu'à sa sauvegarde et son rattachement à un compte client - nouveau ou existant

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é

• Soit le nom est pris
• Soit l'enregistrement est censé réussir
  

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

• Toutes nos fonctions dans les interfaces
• Notre nouvel objet client

Diagramme de classes

Le diagramme de classe final est