Modèles externes et validation - Université technique de Sofia

Chapitre 9 Modèles externes et validation
Modèles externes
OBJECTIF Pour chaque phase ont été recensées les données mises en jeu. C'était alors
le premier pas de l'équipe chargée des traitements vers celle des données.
Il est maintenant nécessaire de prolonger ce rapprochement entre les deux
équipes et, pour atteindre cet objectif, de demander aux concepteurs des
traitements de décrire les données dans la langue de ceux qui les ont
conçues. L'équipe des traitements s'exprimera donc avec le même vocabulaire
(le dictionnaire des données), et la même grammaire (le formalisme
individuel) que celle des données. Munie de cette langue, et uniquement pour chacune des phases qu'elle a
choisi d'automatiser, elle construira des petits modèles correspondant au
seul ensemble de données manipulées dans la phase étudiée, sans aucune
vision globale. A ces mini-modèles conceptuels, représentant la vue des
données à travers des traitements automatisés, on ajoutera le qualificatif
d'externes pour bien préciser qu'ils trouvent leur origine à l'extérieur du
groupe d'étude des données. On pariera donc de «modèle externe» ou de «vue
externe». Sur deux exemples nous montrerons de façon intuitive la construction de
modèles externes, pour préciser ensuite leurs règles de conception.
APPROCHE INTUITIVE Supposons que les choix d'automatisation déduits des objectifs aient
conduit des équipes de traitements à organiser : 1) Dans un restaurant, une édition automatique de l'inventaire (traitement
par lots en fin de mois, par exemple).
2) Dans un collège, une saisie conversationnelle des notes des élèves
(après chaque contrôle de connaissances, par exemple).
Ces deux exemples, choisis volontairement dans des domaines différents,
illustrent les deux grandes fonctions rencontrées : consultation pour le
premier et mise à jour pour le second. Cas no 1. Edition de l'état du stock en machine à une date donnée avec,
pour chaque produit, une quantité et un prix. Les données recensées en essayant d'utiliser les mêmes libellés que ceux du
dictionnaire sont : - nom produit,
- conditionnement,
- prix,
- quantité,
- n° de ligne,
- date.
Pour représenter dans le formalisme individuel l'ensemble de ces données,
la solution la plus simple consiste à créer un seul objet que l'on
baptisera «Inventaire» ainsi conçu : |INVENTAIRE |
|Date |
|N° ligne |
|Nom produit |
|Conditionnement |
|Prix |
|Quantité |
Dans ce formalisme, la première propriété a une fonction d'identifiant et,
ici, la date tient parfaitement ce rôle puisqu'à une date donnée correspond
un et un seul inventaire, donc une seule occurrence de l'objet. En revanche, il est clair qu'à une occurrence de l'identifiant
correspondent plusieurs occurrences des autres propriétés. Par exemple,
plusieurs lignes ou plusieurs produits existent pour une date donnée. La
création d'un objet «Inventaire» serait donc en contradiction avec la règle
de non-répétitivité des propriétés (cf. vérification du MCD). On devra alors créer un objet correspondant à chaque ligne de l'inventaire,
de façon à porter les autres propriétés. Soit «Ligne d'inventaire» un tel
objet : |LIGNE D'INVENTAIRE |
|N" ligne |
|Date |
|Nom produit |
|Conditionnement |
|Prix |
|Quantité |
Cette fois la répétitivité des propriétés a disparu et le numéro de ligne
constitue bien un identifiant. Mais la deuxième règle de normalisation
n'est pas vérifiée, car la date n'est pas en dépendance pleine de
l'identifiant. En effet, pour chaque ligne on répétera la même date qui,
par conséquent, ne dépend pas de ce numéro de ligne. On «sortira» donc cette propriété de l'objet «Ligne d'inventaire» pour
créer un objet «Inventaire », réduit à cette seule propriété et relié au
précédent. Le modèle externe sera alors le suivant : On ajoutera les cardinalités (1,n) d'un côté (un inventaire comporte au
moins une ligne) et (1,1) de l'autre (une ligne d'inventaire appartient à
un et un seul inventaire). Cette fois, les règles du formalisme individuel
sont bien respectées et la totalité des données est représentée. Cas no 2. Saisie des notes attribuées aux élèves après un contrôle des
connaissances. Les données sont alors : - nom élève,
- note,
- matière,
- classe.
Comme précédemment la non-répétitivité des propriétés impose un objet
«Elève» portant le nom et la note. Attribuer à cet objet la classe et la matière serait contraire à la seconde
règle de normalisation, puisque ces données sont identiques quel que soit
l'identifiant. On doit donc «sortir» ces deux propriétés de «Elève». La
stricte vision du traitement de saisie ne fait ressortir ni l'utilisation
de la classe seule, ni celle de la matière seule. En fait, la notion
utilisée est celle du contrôle de connaissances (Mathématiques en 6e A3),
c'est-à-dire du couple (classe-matière). Du point de vue de la seule équipe
des traitements c'est donc, simplement, un objet «Contrôle» qu'il convient
de créer et de rattacher à l'objet «Elève». La vue externe de la saisie des notes attribuées à un contrôle est donc : Ces deux exemples ont présenté intuitivement la manière de formaliser les
données propres à un traitement. Par quelques règles simples d'édification
des modèles externes nous détaillerons cette démarche.
RÈGLES DE CONSTRUCTION DES MODÈLES EXTERNES Rappelons qu'à partir de maintenant ne sont plus concernées que les phases
automatisées. Elles constituent notre objectif essentiel. Pour les phases
manuelles le travail s'est achevé avec la description des tâches qu'elles
englobent, des règles d'organisation qui les gouvernent et, enfin, du mode
opératoire décrivant leur mise en ?uvre. C'est donc la phase automatisée qui, unité de base de l'organisation, sera
notre point de départ. Il s'avère que les phases, construites sur un seul
critère d'ininterruptibilité, peuvent être des regroupements hétérogènes en
ce qui concerne la fonction des traitements qui s'y déroulent ou les
données qu'elles manipulent. Par exemple, une phase de «Préparation
commande» comprendra : - une consultation des stocks,
- une consultation des commandes en cours,
- une saisie d'un brouillon de commande (c'est-à-dire non encore communiqué
au fournisseur).
La partie de procédure comprenant cette phase est, par exemple, la suivante
: On a, dans cette seule phase, deux traitements de consultation et un
traitement de mise à jour. De plus sont manipulées des données liées au
fournisseur (commande) et d'autres plus liées à l'acheteur (stock). Afin de simplifier l'élaboration des modèles externes, on choisira alors de
construire trois modèles élémentaires plutôt qu'un seul modèle, global pour
la phase. D'où la première règle : 1) On construira un modèle externe pour une fonction particulière des
traitements Plutôt qu'une définition nous donnerons trois indications permettant
d'atteindre le niveau véritablement opérationnel pour ce travail.
a) Un modèle externe sera lié à un ensemble de traitements destinés à
exécuter une et une seule des deux fonctions :
- soit une mise à jour,
- soit une consultation.
Nous retrouverons cette dichotomie, de plus en plus invoquée au fur et à
mesure de l'approche du niveau physique où elle se traduira par deux ordres
bien différents : l'un d'écriture dans la base de données ou dans les
fichiers et l'autre de lecture.
b) Un modèle externe ne concernera qu'une seule famille de données.
Par exemple, dans une phase d'édition de paie, on distinguera les données
liées à l'entreprise (charges patronales, ...) de celles liées aux agents
(rubriques de paie,...).
c) Enfin, un modèle externe ne manipulera qu'un petit nombre de données à
la fois.
En effet, il ne faut pas oublier que ces modèles, supports de l'étape
ultérieure de validation, seront d'autant plus faciles à valider qu'ils
seront simples, même si leur nombre en est augmenté. A l'aide de ces indications il est donc possible de discerner dans chaque
phase les différentes fonctions donnant naissance aux modèles externes. Remarques 1) Si la phase est homogène et peu importante, la fonction sera unique et
un seul modèle externe sera formalisé.
2) La finesse du découpage ainsi retenu permettra souvent de retrouver,
dans des phases différentes, le même modèle externe (par exemple :
consultation des stocks).
3) Pour les phases conversationnelles, le niveau de la tâche homme-machine
sera souvent trop fin et le bon niveau correspondra alors à un
regroupement.
Par exemple, une saisie de facture conversationnelle pourra enchaîner
plusieurs tâches homme-machine : - saisie en tête de facture,
- saisie lignes de facture,
- saisie pied de facture.
On n'établira alors qu'une seule vue externe correspondant à la «saisie
facture ». De même, en consultation, et sauf si les traitements sont vraiment très
différents, on ne fera pas une vue externe pour chacun des critères de
consultation offerts mais une seule, pour l'ensemble de ceux-ci. La seconde règle concernera le vocabulaire utilisé.
2) On listera pour chaque modèle externe les données manipulées en se
référant au dictionnaire des données Le recensement des données, fait dans le modèle organisationnel des
traitements, sera donc confronté au dictionnaire de façon à éviter de créer
des synonymes ou des polysèmes. Un travail plus approfondi sera mené à la
validation et ici on essaie seulement d'introduire un peu de cohérence. Si,
par exemple, les traitements manipulent une donnée «Employé» et que celle-
ci, absente du dictionnaire, apparaît identique à celle d'«Agent» qui,
elle, y figure, on gardera comme seule donnée «Agent». Ces corrections étant faites, toutes les données manipulées par la fonction
dont on établit la vue externe doivent figurer sur le modèle. Dans le
nouveau système de référence que constitue cette seule fonction, elles son