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
Ci-dessous un filtre "livre"
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.
Des marchandises, mais aussi
Des rayons - ou des sections
Le magasin peut donc être livré vide à l'installation, il sera rempli par un Admin.
L'administration des sections : L'administration des produits :
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*
Ci-dessous les séquences pour chaque UseCase
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
Certaines de ces méthodes vont également servir à l'administration
Lecture/recherche de produits
Lecture/recherche des sections
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 :
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
Le magasin prends forme en :
Reportant les fonctions ci-dessus dans Systeme
Séparant en composants logiques - mais arbitraires
Reportant les structures de données obligatoires
Dans cette modélisation,
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
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 :
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
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
Cette page a été illustrée par le logiciel issu du code généré par ses diagrammes..
Cf http://sling.migniot.com/Magasin/5_Classes_Finales.html Et trouver l'icone
