ans la famille "Je cherche à comprendre le Système d'Information que je modélise", je propose les documents fournis par votre client. Car s'il sera aisé de discuter avec lui de l'exactitude du MCD, comprendre son environnement de travail peut parfois être plus ou moins évident : ses explications seront rarement complètements explicites du premier coup, et il est courant que le client lui-même n'ai qu'une vague idée de ce qu'il veut faire. C'est là que, armée de toute notre diplomatie et de notre pédagogie, commence la partie la plus palpitante de notre travail : "Comprendre ce que veux le client, et comment ça marche". Car vous n'avez pas envie de recommencer 10 fois votre travail et de modifier votre code tout le temps, n'est ce pas ? Il va donc falloir poser des questions, aller voir comment il se débrouille actuellement, amasser un maximum de documents, et en retirer le maximum d'informations. Car être certain de comprendre les besoins de l'utilisateur qu'il exprime avec ses mots à lui, c'est là tout le but de la modélisation.

MODELISER UN DOCUMENT : UNE PRATIQUE COURANTE

Commençons par terminer l'exemple de la dernière fois, dont re-voici l'énoncé :

Système d'Information :

L'entreprise "WebCash" de vente par correspondance désire ajouter à son site un système de facturation visible en ligne pour ses clients. Chaque client, après authentification, pourra accéder à toutes les factures le concernant, qu'elles soient anciennes ou en cours de traitement indifféremment. Pour être sur de bien se faire comprendre, "WebCash" fournis une facture type en disant : "C'est ça qu'on veut sur l'écran !"

Voici une copie de cette facture :

WebCash S.A.R.L 24, Avenue des Rêves roses 75008 PARIS	FACTURE N° 12345
Paris, le 15/10/2000
Nom : BIDOCH Prénom : Robert Adresse : 12, rue du centre Code Postal : 70000 Ville : Gray
N° Article Libellé Prix Unitaire Quantité Prix 234 Stylo Plume 12.5 F 1 12.50 F 568 Couteau Suisse 75.00 F 2 150 F 132 Serviette 30.00 F 1 30.00 F TOTAL TTC :  192.50 F Dont TVA 19.6% :  37.73 F A PAYER :  192.50 F
Avec nos plus cordiaux remerciements

APPLICATION DE LA METHODE MERISE

Elle consiste à construire le Modèle Conceptuel de Donnée (MCD), Générer le Modèle Logique de Données Relationnelles (MLDR), et le transposer en Modèle Physique de Donnée (MPD).

• Construire le Modèle Conceptuel de Donnée (MCD) :

• Identifier les entités présentes :
  On relève trois entités : CLIENT, FACTURE, ARTICLE.
  • CLIENT est l'ensemble des clients de la société WebCash. Une occurrence de cette entité est présentée par Robert BIDOCH, qui est le client à qui cette facture est destinée.
  • FACTURE est l'ensemble des factures émises par WebCash, dont une occurrence est présente en "FACTURE N° 12345".
  • ARTICLE est l'ensemble des articles vendus par WebCash, dont trois occurrences sont présentes, dénommés Stylo Plume, Couteau Suisse et Serviette.
  • Une facture étant composée de plusieurs lignes, il aurait été possible de relever l'entité LIGNE_FACTURE : elle n'est utile que si l'on désire archiver pour chaque ligne son Numéro. La base déduite aurait été sensiblement la même, démontrant ainsi que plusieurs solutions sont parfois possibles.
  • La TVA est ici considérée comme constante et unique. Dans le cas contraire, elle aurait représenté l'entité TVA.
  • La société WebCash ne représente pas une occurrence d'une entité, car c'est la seule société éméttrice de facture de notre analyse.


• Lister les propriétés des entités :
  • Un CLIENT est caractérisé par son Nom, son Prénom, son Adresse, son CodePostal et sa Localité. Afin de pouvoir s'authentifier, il est aussi caractérisé par un Login et un Passwd.
  • Une FACTURE est caractérisée par son Numéro, et sa Date d'émission.
  • Un ARTICLE est caractérisé par son Numéro, son libellé, et son PrixUnitaire. Le prix total, de par son PrixUnitaire et sa quantité, peux être recalculé : ce n'est donc pas une caractéristique de l'ARTICLE.
  • Chaque propriété doit avoir une seule valeur possible pour chaque occurrence, ce qui est ici le cas. Elle doit de plus être élémentaire et non-décomposable, ce qui est aussi le cas. D'une manière générale, toute information résultant d'un calcul n'est pas une caractéristique d'une entité.


• Identifier de manière unique chaque occurrence :
  chaque occurrence de chaque entité doit pouvoir être identifiée de manière unique : cette propriété s'appele l'identifiant.
  • Un CLIENT sera identifié par un Numéro unique, cette caractéristique de l'entité étant appelé id_Client.
  • Une FACTURE sera identifiée par son Numéro qui est unique. Cette caractéristique sera appelée id_Facture.
  • Un ARTICLE sera identifié par son Numéro qui est lui aussi unique. Cette caractéristique sera appelée id_Article.


• Etablir les relations entre les différentes entités :
  Un CLIENT obtient une FACTURE qui contient des ARTICLES en certaine quantité.
  
  
• Identifier les cardinalités :
  • Un même CLIENT obtient 1 ou plusieurs FACTURE.
  • Une même FACTURE est obtenue par un seul CLIENT.
  • Une même FACTURE contient 1 ou plusieurs ARTICLE.
  • Un ARTICLE est contenu dans 0 ou n FACTURE.

• Générer le Modèle Logique de Données Relationnelles (MLDR) :

• Transposer en Modèle Physique de Donnée (MPD) :

UNE BASE DE DONNEE COHERENTE

Un tel modèle est dit cohérent, c'est à dire que pour chaque donnée fournie, il permet de retrouver toutes les informations s'y rattachant.

Pour chaque client donné, il sera possible d'avoir toutes ses factures, et donc tous les articles qu'il a achetés et en quelle quantité. Pour chaque facture, il sera possible de retrouver le client correspondant, ainsi que la liste des articles et leurs quantités respectives. Enfin, pour chaque article, il sera aisé de retrouver les quantités vendues, à quelle date et à quels clients.

La base ne contient aucune redondance, c'est à dire qu'aucune information présente ne peut être déduite d'autres informations présentes. Ceci évite grandement le risque de corruption, ou présence de donnée aberrante.

Les prix intermédiaires, la somme totale et autres résultats sont des traitements, c'est à dire qu'ils sont calculés par rapport aux informations contenues dans la base. Ainsi, toute erreur sera forcemment une erreur de calcul, et non pas une erreur de stockage. Il est plus facile de vérifier un programme d'extraction de donnée que de vérifier la cohérence du contenu d'une base.

LES AVANTAGES D'UN TEL RESULTAT

Le développement se réduit maintenant à une interface d'administration (BackOffice) ou WebCash pourra ajouter/modifier/supprimer ses ARTICLES, rentrer ses FACTURES, et consulter son fichier CLIENT. Ensuite, sur le site lui-même (FrontOffice), il ne reste plus qu'à faire le formulaire d'accréditation du CLIENT (Login/Passwd) qui permettra de retrouver son identifiant, puis à lui lister les FACTURE correspondant à cet identifiant, et enfin lui afficher le détail de celle qu'il aura sélectionné.

Si ce développement paraît au final aussi simple, c'est qu'il s'appuie sur une base bien pensée. Si celle-ci correspond effectivement à l'environnement de travail de WebCash, il n'y aura aucune raison de la changer.

Vous obtiendrez ainsi la meilleure des références et des publicités : concevoir un outil simple à utiliser qui marche durant longtemps sans avoir à être modifié. Et ça, pour un client, c'est vraiment le top du top.

A bientôt...

<< Lire la 3ème partie

Lire la 5ème partie >>

Stéphane Lambert
http://www.vediovis.fr/

Spécialisé dans le développement Web, Stéphane LAMBERT
a fondé VEDIOVIS PRODUCTIONS en Mai 2000.
Son expérience couvre essentiellement les sites à fortes audiences,
institutionnels ou audiovisuels.

Tous droits réservés - Reproduction même partielle interdite sans autorisation préalable