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 tout

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 surgieront du développement, ni les attributs superflus dans les Manager.