Tutoriel pour la conception d'un système d'information WEB avec UML

Ce tutoriel illustre une méthode de conception d'application WEB avec UML. Pour réagir au contenu de cet article, un espace de dialogue vous est proposé sur le forum 11 commentaires Donner une note à l'article (5)

Article lu   fois.

L'auteur

Site personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. Introduction

Suite à une demande sur mon blog, il m'est apparu intéressant de montrer, à travers un exemple concret, comment modéliser une application WEB grâce à UML.

Comme on le verra, UML permet à la fois de recueillir le besoin métier mais également de modéliser les objets logiciels (classes du langage cible, PHP, …JAVA…).

Cette analyse a été menée dans le cadre d'un projet professionnel et a abouti au développement d'une application écrite en PHP.

II. Objectif du système d'information cible

Le SI doit permettre d'automatiser les deux domaines fonctionnels stratégiques d'une entreprise de vente de pièces mécaniques, à savoir : la CRM et la SCM.

Ces deux processus métier seront instrumentalisés à travers un site de commerce en ligne au profit des trois agences de Marseille, Lyon et Paris.

II-A. Les processus du SI

Les cas d'utilisation du système sont les suivants :

Image non disponible

L'étude qui suit se décomposera en deux phases :

  • une phase d'analyse indépendante de la technologie qui sera utilisée permettant :

    • de découvrir les objets métiers qui sont liés aux deux macroprocessus (gérer la relation client et gérer les approvisionnements),
    • de les associer et gérer leurs interactions pour mettre en œuvre les processus de CRM et de SCM ;
  • une phase de conception détaillée aboutissant à l'implémentation des spécifications (modélisées durant la phase précédente) en PHP.

II-B. Description des processus fonctionnels

II-B-1. Domaine CRM

Image non disponible

Le processus cible doit permettre au client de choisir un produit présent dans le catalogue et de le mettre dans son panier. Le client peut à tout moment enlever ou ajouter des produits du panier ou modifier la quantité souhaitée. Les produits du panier peuvent être commandés (ajoutés à une commande) et inversement toute ligne d'une commande peut être remise dans le panier tant que la commande n'est pas validée définitivement par le client.

Le système de comptabilité n'autorise les commandes que pour les clients solvables. Le système n'autorise d'ajouter un produit à la commande que si les stocks sont suffisants.

Le client peut choisir à quelle adresse chaque produit sera livré. Par défaut, tous les produits d'une même commande sont livrés à l'adresse principale du client. Mensuellement, le service comptabilité facture les commandes du mois.

II-B-2. Domaine SCM

Image non disponible

Dès qu'un produit possède une quantité en stock insuffisante dans une agence, celle-ci émet un appel d'offre sur une place de marché. La PDM gère alors un processus d'enchères inversées pour sélectionner le fournisseur le moins disant.

III. Analyse des objets métier du système

III-A. Domaine CRM

Il y a 3 agences, mais un seul système d'information fédérateur pour la SCM et la CRM. Un client est rattaché à une seule agence.

Il faut s'assurer que le client commande en ligne à son agence de rattachement. Cette problématique sera traitée en 2 temps :

  • dans l'analyse du domaine SCM où l'on découvrira comment la classe client est associée à la classe agence ;
  • dans l'étude d'architecture, on évacuera définitivement cette problématique en proposant une solution technique basée sur un annuaire LDAP et une gestion des droits profils ;

On réduira le périmètre de la CRM à la recherche d'un produit, la gestion du panier et la commande par le client.

Le client utilisera bien souvent le panier comme usine de devis.

À ce stade de la découverte des classes, on peut déjà obtenir le modèle de classes métier ci-dessous :

Image non disponible

L'objet « ligne panier commande » est un objet qui, selon son état, appartient soit au panier soit à la commande comme l'illustre le diagramme d'état ci-dessous :

Image non disponible

III-B. Domaine Back office

III-B-1. Gestion des commandes et des stocks

Image non disponible

Chaque agence doit proposer tous les produits du catalogue.

Pour que chaque chef d'agence soit autonome (concept « d'empowerment »), les stocks font l'objet d'une gestion et d'une comptabilité locale. Si exceptionnellement, deux agences souhaitent faire un mouvement de stocks pour des raisons qui leur sont propres, on considérera que l'une vend un produit à un client et que l'autre achète à un fournisseur. Le service comptabilité facturera la transaction pour le compte de chaque agence qui intervient dans le mouvement de stock.

III-B-2. Gestion de la place de marché inversée

Comme la gestion des stocks est locale, les demandes d'approvisionnement sur la place de marché inversée seront donc des initiatives toutes aussi locales.

Pour un cas aussi simple, il nous est apparu que l'utilisation d'un pattern « façade » tel qu'il apparaissait sur le diagramme de séquences de la SCM devait se transformer en pattern « factory ». Comme on le voit dans le diagramme de classes ci-dessous, c'est l'objet Agence qui fabriquera un objet AppelOffre.

Image non disponible

On aurait tout aussi bien pu utiliser le pattern « abonné consommateur » pour dialoguer avec la place de marché.

IV. Architecture logique du système

Un client doit avant toute opération (gestion du panier - commande …) s'authentifier sur le système.

Le panier doit pouvoir être consulté à tout moment. Il s'agit donc d'un objet persistant en base de données qui survit au-delà de la session du client et mémorise ses actions.

L'ERP de comptabilité est alimenté par le SI pour les données de facturation et statue sur la solvabilité du client.

Le schéma ci-dessous montre les liens de dépendance entre les différents modules applicatifs du SI tel qu'il se déduit à ce stade de l'analyse. On voit d'ores et déjà que le service d'authentification (qui concentrera la majorité des exigences de sécurité) est déjà hautement consommé. Il apparaît qu'un des axes d'amélioration SOA du SI serait de le faire également consommer par l'ERP de comptabilité.

Image non disponible

V. Cinématique de navigation du tiers de présentation

V-A. CRM

V-A-1. Authentification

Image non disponible

Ce diagramme qui illustre l'authentification d'un client sera dans le concept tout aussi valable pour authentifier l'acheteur ou le gestionnaire des stocks ainsi que le fournisseur qui soumissionnera pour répondre à un appel d'offre. C'est donc durant cette phase d'authentification que l'utilisateur sera identifié et dirigé vers le processus qui correspond à son profil.

V-A-2. Gestion du panier

Image non disponible

Un client authentifié doit pouvoir visualiser le contenu de son panier et y ajouter les produits de son choix. Le client doit aussi pouvoir vider son panier.

V-A-3. Rechercher un produit

Image non disponible

Comme on s'y attend pour ce genre de site, l'utilisateur peut rechercher dans un catalogue (par référence ou dénomination) les articles dont il a besoin.

Bien entendu, l'objet de sa recherche doit pouvoir être ajouté au panier.

V-A-4. Commander

Image non disponible

Quand il le souhaite, le client doit pouvoir transformer son panier en commande.

Le système proposera alors au client de choisir son adresse de livraison après avoir vérifié sa solvabilité.

V-B. SCM

Image non disponible

La place de marché sélectionne le fournisseur le moins cher pour un produit donné, mais la commande au fournisseur est validée par le service achat qui vérifie que le prix est cohérent.

VI. Diagrammes de classes de conception

L'application implémentera le pattern Modèle - Vue - Contrôleur. Les classes des modèles de conception seront donc stéréotypées « Modèle », « Vue » ou « Contrôleur ».

VI-A. Rechercher un produit

Image non disponible

On remarque sur ce diagramme de classes que les produits vendus sont classés en familles pour faciliter la recherche, la gestion des stocks et opérer des statistiques.

VI-B. Gérer le panier

Image non disponible

Le panier sera un objet mis en persistance. En effet, le client peut commencer à constituer son panier, se déconnecter et revenir pour le compléter et passer commande.

VI-C. Gérer la commande

Image non disponible

Le panier est constitué de lignes et la commande également. Ces lignes sont communes, et transitent d'un état à l'autre lors du passage de la commande.

VI-D. Gérer la place de marché

Image non disponible

La spécification de la mécanique de cette place de marché et sa compréhension par le développeur furent obtenues en jouant un scénario basé sur la technologie XML comme détaillée ICIEchanger sur une place de marché avec XML.

VII. Développement de l'application

Pour répondre aux attentes stratégiques de la direction, le SI sera développé sur une technologie LAMP :

Système d'exploitation : LINUX

Serveur web : Apache

Serveur d'appli : PHP 5

SGBD/R : MySQL

VII-A. Modèles de classes PHP

Les modèles qui seront présentés dans ce chapitre seront donc dérivés des modèles dits PIM (Plateform Independant Model) présentés précédemment, mais seront spécifiques à la technologie PHP 5. Ces modèles appelés PSM (Plateform Specific Model) seront stéréotypés « page PHP » « classe PHP » « PHP Lib » etc…

Cette modélisation présente la particularité de présenter dans un même diagramme de classes les objets métier ainsi que l'ergonomie de présentation orientée web. Ces deux aspects sont unifiés au travers des opportunités qu'offrent un langage objet tel que PHP et l'aspect déclaratif du langage HTML. À cet égard, il est important de noter qu'il en serait de même avec n'importe quel autre langage ou Framework web tel que JEE ou .NET.

VII-A-1. Modèle de classe front office

Image non disponible

On remarque que toutes les pages PHP héritent d'un modèle de page qui possède un header (bandeau) ainsi qu'un menu latéral. On y remarque également qu'un contrôleur unique orchestre la navigation des pages pour respecter le modèle de conception MVC2.

VII-A-2. Modèle de classe gestion de la PDM

Image non disponible

En outre, une classe (hautement mutualisée) appelée Connexion sera utilisée pour les opérations de persistance en lien avec la base de données :

  • chargement d'un objet métier depuis la base de données ;
  • sauvegarde d'un objet métier dans la base de données.

VII-B. Schéma de la base de données

Un certain nombre de dénormalisations ont été retenues pour passer du modèle de classes d'analyse au modèle physique implémenté dans l'application.

Image non disponible

VIII. Conclusions

On voit, à travers cet exemple, qu'il est possible de mener une analyse du besoin et une conception de bout en bout grâce à UML.

UML nous permet de spécifier les éléments de conception dans un langage qui est compréhensible par le client et par le développeur, ce qui sonne comme un gage de réussite pour le projet.

Nous tenons à remercier Milkoseck pour la relecture technique et Franouch pour la relecture orthographique de cet article.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2015 autran. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.