Dossier "SAM l'Informaticien" du 05/02 au 18/02 2001 par Stéphane Lambert
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 :
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) :
La méthode est toujours la même : Identifier les entités présentes, Lister les propriétés des entités, Identifier de manière unique chaque occurrence, Etablir les relations entre les différentes entités, et Identifier les cardinalités.
- 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.
On en déduit donc le MCD suivant :
Comme d'habitude, il est alors temps de retourner voir le client et de discuter le Modèle avec lui, afin de vérifier qu'il ne manque rien et que l'analyse correspond bien à SA réalité de travail. Après validation, il est temps de passer à l'étape suivante.
- Générer le Modèle Logique de Données Relationnelles (MLDR) :
Relation (X,1)-(X,n) entre FACTURE et CLIENT :
CLIENT (id_Client, Nom, Prenom, Adresse, CodePostal, Localite, Login, Passwd)
FACTURE(id_Facture, #id_Client, Date)
Relation (X,n)-(X,n) entre FACTURE et ARTICLE :
CONTIENT(#id_Facture, #id_Article, Quantite)
ARTICLE(id_Article, Libelle, PrixUnitaire)
- Transposer en Modèle Physique de Donnée (MPD) :
Voilà , il ne reste plus qu'à créer la base, à la remplir, et à développer dessus.
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 |
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
vediovis.fr