Pages - Menu

Pages

Cours sur la Méthode D'analyse Merise : MCD - MLD - MCT - Dictionnaire de données - Normalisation - Association - Entité - Modèle

METHODE MERISE

Historique :

 
de 1976 à 1978 centre technique informatique du ministère de l'industrie :
réflexion, choix des SSI, réalisation
1983 MERISE, Principes et outils TARDIEU, ROCHFELD, COLLETTI.

Principes généraux :

1. Démarche par étapes
2. Découpage en niveaux Conceptuel
  • Logique ou organisationnel
  • Physique ou opérationnel
3. Formalisme
  • Schéma entité / relation
  • Schéma opération / événement
4. Outils complémentaires
  • Diagramme de flux de données
  • Diagramme d'activité diagramme de contexte
  • Diagramme de décomposition
  • Diagramme de communication

LES ETAPES
 
1. Le schéma directeur
  • Planification
  • Priorités
2. Conception globale
  • Structure globale du projet
  • Choix d'architecture générale : décomposition
  • Interfaces entre modules
3. Conception détaillée
  • Intégration des éléments fonctionnels
  • Spécification technique
  • Plan de qualification
4. La réalisation
  • Programmation
  • Tests techniques
  • Documentation technique
5. La validation
  • Tests logiques
  • Procédures de mise en place
6. La mise en œuvre
  • Documentation utilisateur
  • Implantation physique
  • Transfert de données
  • Formation
7. La maintenance
  • Evolution
  • Correction d'anomalies

LES NIVEAUX
  
L'organisation par niveaux

Niveau conceptuel
  • Modèle conceptuel de données (MCD)
  • Modèle conceptuel des traitements (MCT)
Niveau logique ou organisationnel
  • Modèle logique des données (MLD)
  • Modèle logique des traitements (MLD)
Niveau physique ou opérationnel
  • Modèle physique des données (MPD)
  • Modèle physique des traitements (MPT)
Recherche des invariants
  • Modèle de données
  • Modèle de traitement
Indépendance entre les données et les traitements
 
MODELE CONCEPTUEL DES DONNEES
 
Concepts fondamentaux
  • Entité
  • La propriété
  • L'identifiant de l'entité
  • L'association ou relation
  • L'identifiant de l'association
  • Collection et dimension
Les règles de vérification

Les règles de normalisation

Les contraintes fonctionnelles
  • Les cardinalités
  • Les contraintes d'intégrité fonctionnelle (CIF)
Le processus de construction du modèle

L'ENTITE

Une entité est un objet du réel, concret ou abstrait dont on s'accorde à reconnaître une existence propre : doit présenter un intérêt pour la compréhension de la réalité.

Exemples :

           Le stand numéro A-8 situé au 3ième étage du bâtiment Océan
           L'exposant "Renault"

Une entité est une classe d'individus ayant en commun un ensemble de propriétés.

Représentation graphique :

Une entité sera désignée par un nom, son choix est important

LES PROPRIETES

Une propriété est une caractéristique que l'on perçoit sur une entité ou sur une association entre entités dans le réel.
Une entité est perceptible à travers ses propriétés.

Exemples :
  
           Le salon a lieu d'une date début à une date fin, dans un centre d'exposition.
           Un exposant a une raison sociale, une adresse, un correspondant, etc. ....

Une propriété peut être simple
           Les mètres carrés d'un stand
           Le prix d'un produit
           Le mois

Ou composée
           La date (jour, mois, année) l'adresse : nom, rue, numéro, code postal, ville.

L'IDENTIFIANT

Un identifiant est une propriété particulière telle qu'il n'existe pas deux occurrences de cette propriété pour lesquelles cette propriété puisse prendre la même valeur.
 
1. On est souvent amené à créer artificiellement les identifiants :
           Numéro de sécurité sociale
           Numéro d'immatriculation de voiture
           Numéro de stand
           Numéro d'exposant

2. La définition d'un identifiant résulte le plus souvent d'un choix de gestion.

3. Il peut y avoir plusieurs propriétés candidates au titre d'identifiant, dans la pratique on en choisira une seule.
Une entité est complètement définie par :

           Un nom
           Un identifiant
           Une liste de propriétés
 
Chaque fois que l'on veut définir une entité, on devra déterminer son identifiant.
 
EXEMPLE
 

L'exposant "Renault" qui a reçu le numéro 021 présent comme fabricant de moteurs

 
L'ASSOCIATION (OU LA RELATION)
 
Une association (ou relation) est perçue dans le réel entre des individus

Une association définit une relation entre une ou plusieurs entités
           Exemple : L'exposant Renault expose sur le stand A-8

Représentation graphique :
 
 
Une association n'a pas d'existence propre, elle dépend des entités qu'elle regroupe
 
Une association peut être porteuse de propriétés
 
Pour désigner une occurrence de l'association, il faut désigner les occurrences des entités
qui la composent
 
Une occurrence de l'association correspond à une et une seule occurrence de chacune des
entités qui la composent

Une association peut être binaire

           Exemple : "expose sur" entre exposant et stand

Une association peut être ternaire

 
           Exemple : l'association exposant, stand, salon

Une association peut être n - aire

Le choix d'une association est lié à l'intérêt du concepteur
Stand peut être vu :
           soit comme une association entre exposant et salon.

           soit comme une entité liée à l'exposant et au salon par des relations

Une association peut être réflexive

 
Plusieurs relations peuvent exister entre deux entités

 
Si une association a deux pattes (pas de symétrie) : préciser la signification de chaque patte
 
 
IDENTIFIANT DE L'ASSOCIATION
 
L'identifiant de l'association est obtenu par concaténation des identifiants des entités qui la composent

           Exemple : pour l'association Exposant-Stand
                      l'identifiant de l'association "expose sur" est :
                                 numéro exposant/ numéro de stand
 
           Exemple : pour l'association Exposant-Stand-Salon
                      l'identifiant de l'association "expose sur" est :
                                 numéro d'exposant / numéro de stand / code salon

           Exemple : pour l'association réflexive "filiale de"
                      l'identifiant de l'association est :
                                 numéro d'exposant / numéro d'exposant
 
OCCURRENCES DE L'ASSOCIATION
 
A chaque occurrence d'une relation ou association correspond une et une seule occurrence des entités qui la composent :

 

LES RÈGLES DE VÉRIFICATION

Règle 1
           Une propriété ne peut qualifier qu'une seule entité ou qu'une seule association
       Exemple : le numéro de Stand ne peut pas être à la fois une propriété de l'entitéExposant et de l'association Stand.

Règle 2
           Toute entité doit être dotée d'un identifiant donc au minimum d'une propriété

Règle 3
           Pour une occurrence d'une entité chaque propriété prend une valeur et une seule.

           Si un exposant peut avoir plusieurs marques, "marque" ne peut être une propriété d'exposant. On doit créer l'entité "marque"

Règle 4
           Pour les associations comme pour les entités une propriété ne doit prendre qu'une valeur pour une occurrence de l'association.

           Exemple : un exposant peut exposer à plusieurs salons sur le même stand. la propriété salon ne peut être une propriété de l'association "expose sur"

Règle 5
           Pour chaque occurrence de l'entité ou de l'association, il faut au minimum et au maximum une valeur à terme pour chaque propriété

           Exemple : la notion de filiale n'a pas de sens pour tous les exposants, donc filiale ne peut être une propriété d'exposant

Règle 6
           Une propriété dépendant de plus d'une entité (2 ou plus) ne peut qualifier qu'une association entre les entités correspondantes

           Exemple : la propriété numéro de stand qui peut qualifier l'entité Exposant et l'entité Salon est une propriété de l'association entre Exposant et Salon.

Règle 7
           Pour chaque occurrence d'une association toutes les entités qui participent à la relation doivent être définies

 
           Exemple : la marque ne participe pas à toutes les relations Stand, certains exposants ont une marque d'autres non

LES RÈGLES DE NORMALISATION

Règle 1
           Chaque propriété d'une entité doit dépendre de l'identifiant et de tout l'identifiant de cette entité

Règle 2
           Si une propriété dépend de l'identifiant de l'entité qu'elle qualifie mais aussi d'une autre propriété de cette entité cela signifie qu'il y a une entité imbriquée

Règle 3
           Toutes les entités d'une association doivent être nécessaires pour définir chaque propriété de l'association

Règle 4
           Une propriété d'association doit avoir un sens pour toutes les pattes de la relation.

LES CARDINALITES

Cardinalité d'une entité dans une association : le nombre minimum et maximum d'occurrences de l'association pouvant exister pour une occurrence d'entité.

Cardinalité 1-1 :
           Une occurrence d'entité participe une fois et une seule à une association
           Toutes les occurrences d'entités participent à une association

Cardinalité 0-1 :
           Une occurrence d'entité participe au plus une fois à une association
           Une occurrence d'entité peut ne pas participer à une association

Cardinalité 0-N :
           Une occurrence d'entité peut participer à plusieurs associations.
           Une occurrence d'entité peut ne pas participer à une association

Cardinalité 1-N :
           Une occurrence d'entité peut participer à plusieurs associations.
           Toutes les occurrences d'entités participent à une association

La dépendance fonctionnelle que l'on appelle contrainte d'intégrité fonctionnelle ou CIF est un cas particulier de relation binaire non porteuse de données et ayant des cardinalices de type ( 1-1, 0-N ) ou ( 1-1, 1-N )

Les contraintes d'intégrité fonctionnelles permettent de simplifier les associations n—aires

CONSTRUCTION DU MODELE :

Interviews
Documents
Acteurs
Flux
Inventaire des propriétés
Épuration des synonymes et des polysémies
Constitution du dictionnaire de données
Recherche des entités
Rattacher les propriétés
Placer les relations
Déterminer les cardinalités
Vérifier le modèle
Normaliser le modèle
Décomposer le modèle

ETAPES DE LA CONCEPTION

Les étapes :

           1. Recueillir les informations
                      Les documents
                      Les contraintes sur les données
           2. Constituer le dictionnaire des données
           3. Établir le modèle
                      Repérer les entités
                      Attribuer à chaque entité un identifiant, s'il n'existe pas le créer, et compléter le dictionnaire des                       données
                      Placer les propriétés dans les entités
                      Placer les relations
           4. Valider
           5. Transformer le modèle en schéma relationnel

DICTIONNAIRE DES DONNÉES
           
1. Établir la liste des données figurant sur les documents existants

Attention aux synonymes :
deux mots différents peuvent exprimer la même propriété (TVA et Taxe) vendeur d'un grossiste parle d'articles et l'employé des stocks parle de pièces


Attention aux polysèmes : même terme, sens différents

2. Éliminer, dans un premier, temps les données calculées
 
Exemple : "Quantité en stock"
calculée si historique des entrées-sorties de stock non calculée si données permettant d'effectuer ce calcul non mémorisée
 
3. Éclater les entités composées en propriétés élémentaires :
 
Prénoms en Prénom 1, Prénom 2 Prénom 3

ETABLIR LE MODELE
 
1. Repérer les entités en répondant aux questions :
Que gère-t-on?
Quels sont les objets de gestion essentiels de la réalité observée ?

2. Attribuer à chaque entité un identifiant
S'il n'existe pas, le créer et compléter le dictionnaire de données.

3. Placer les propriétés dans les entités en vérifiant :
  • qu'à une valeur prise par l'identifiant ne correspond qu'une valeur de la propriété (règle d'énumération) 
  • que la propriété ne dépend pas d'une autre propriété de entité (règle de dépendance directe) 
  • que cette propriété n'a pas déjà été attribuée à une autre entité (une propriété se trouve à un seul endroit du modèle)

4. Placer les dépendances fonctionnelles entre entités

5. Placer les autres relations en vérifiant :
  • qu'à chaque occurrence d'une relation ne correspond qu'une et une seule occurrence de chacune des entités participant à la relation
  • qu'une propriété de relation qualifie complètement l'association des entités liées par la relation (règle de pleine dépendance)
  • que dès leur création toutes les occurrences de la relation sont complètes

EXEMPLE : BIBLIOTHEQUE

La Bibliothèque Municipale de Paramé a été créée il y 109 ans et est toujours gérée selon le même principe :

Le directeur est chargé de la gestion de la bibliothèque et de l'achat des nouveaux livres.

Avant d'acheter un livre, le directeur consulte les indices des ventes parus dans différents magazines et la liste des suggestions d'achat des abonnés, ainsi que les fréquences d'emprunt de chaque ouvrage.

Un employé est en charge de la création des cartes d'abonnement, des demandes de prêt et des restitutions. Pour chaque demande de prêt, il vérifie que le demandeur est bien inscrit et à jour de sa cotisation, ainsi que l'ouvrage demandé n'est pas sorti. Si un ouvrage n'est pas disponible, il est possible pour l'emprunteur de le réserver, il ne peut réserver qu'un seul livre à la fois. Dans ce cas, l'employé note le nom du livre et celui du demandeur.

L'employé vérifie les exemplaires à leur retour. Si ceux-ci sont en mauvais état, l'emprunteur doit le rembourser sous peine de radiation.

Un bibliothécaire est en charge de guider et de conseiller les lecteurs dans leur choix. Il est aussi chargé du stockage des livres dans les rayons. Chaque exemplaire à un code d'identification (ISBN).

Remarques :
Ce texte, qui est la synthèse d'observations et d'entrevues, contient un certain nombre d'ambiguïté et peut-être incomplet.

Résultats attendues :

1.  Gestion des exemplaires non restitués
2.  Listes des ouvrages les plus lus
3.  Accès a un exemplaire à partir du titre et du nom de l'auteur
4.  Gestion des livres disponibles

PASSAGE AU LOGIQUE

Modèle logique ≡ modèle relationnel
           → passage du modèle Entité/Relation au modèle relationnel

Analogies entre modèle relationnel et notions classiques de fichier :

 
Une relation est un fichier à structure fixe où :
           tous les tuples sont de même taille
                      (enregistrement de longueur fixe)

           tous les tuples ont la même liste d'attributs
                      (le nombre de rubriques est identique pour tous les enregistrements)

           chaque attribut a une taille identique dans tous les tuples
                      (la longueur de chaque rubrique est fixe pour tous les enregistrements)

Clé d'une relation    

           Toute relation doit posséder un ou plusieurs attributs qui identifie(nt) sans ambiguïté un tuple, cet(s) attribut(s) est appelé "clé de la relation"

Dépendance fonctionnelle    

           Une propriété A est en dépendance fonctionnelle avec la propriété B si à une valeur de la propriété A ne correspond qu'une et une seule valeur de la propriété B

Première forme normale     (1FN) correspond à la règle d'énumération :

           Tous les attributs contiennent une valeur atomique

Deuxième forme normale      (2FN) correspond à la règle de pleine dépendance :

           Tout attribut n'appartenant pas à la clé ne dépend pas (fonctionnellement) d'une partie de la clé

Troisième forme normale      (3FN) correspond à la règle de dépendance directe :

           Tout attribut n'appartenant pas à la clé ne dépend pas d'un attribut non-clé

EXEMPLES

1NF :    

Attribut prénoms n'est pas en première forme normale :
           chaque prénom distingué par un attribut prénom1, prénom2, prénom3...

2NF :   

Relation Rl (Fournisseur, Article, Adresse, Prix)
           avec "Fournisseur, Article", la clé  de la relation et des attributs : Adresse, Prix
relation 1NF, mais pas 2NF → décomposition :
           R2(Fournisseur, Adresse) et R3 (Fournisseur, Article, Prix)

3NF :   

           Relation R1 (Numéro-véhicule, Marque, Type du véhicule, Puissance, Couleur)

           Dépendances fonctionnelles :
                      Numéro-véhicule → Type du véhicule, Couleur
                      Type du véhicule → Marque, Puissance
                      Type du véhicule clé pour Marque et Puissance

           → décomposition :
                      R2 (Type du véhicule, Puissance, Marque)
                      R3 (Numéro-véhicule, Couleur, Type du véhicule)

PASSAGE DU MODELE ENTITE/RELATION AU MODELE RELATIONNEL

Si règles de construction et de validation du modèle Entité/Relation sont respectées  → modèle 

Entité/Relation en troisième forme normale :
  • les propriétés sont sous forme élémentaire
  • à toute valeur prise par l'identifiant ne correspond qu'une valeur de chaque propriété
  • chaque propriété d'une relation dépend de la totalité des entités qu'elle relie toutes les propriétés dépendent directement de l'identifiant

Ordre d'application des règles de transformation du modèle Entité/Relation au  modèle relationnel :

           1. transformer toutes les dépendances fonctionnelles
           2. transformer toutes les relations (n, n)
           3. transformer en relations les entités
                      (les entités sans propriétés peuvent être supprimées)

PASSAGE DU MODELE ENTITE/RELATION AU MODELE RELATIONNEL

Dépendances fonctionnelles : relations (l, l / l, n)
           Relation hiérarchique (père-fils, A représenté le fils et l'entité B le père) :

 

Relations (n / n)  : (1, n / 1, n) (1, n / 0, n) (0, n / 0, n)

 
  
Relations (0, 1 / 0, n), (0, 1 /1, n) ou (0, 1 / 0, 1)
→ se ramener soit au cas dépendance fonctionnelle, soit au cas relation (n / n) :


OBJECTIFS ET CONTRAINTES

Manipulation des données et exécution des tâches traduisent des objectifs ou des contraintes de l'entreprise

 dégager les règles :

Règles de gestion
  • associées au niveau conceptuel
  • décrivent donc le "quoi" de l'entreprise
Règles d'organisation
  • associées au niveau organisationnel
  • décrivent le "où", le "qui" et le "quand"
Règles techniques
  • associées au niveau opérationnel
  • décrivent le "comment"
LES RÈGLES DE GESTION

expriment d'une façon :
           dynamique en dictant les actions qui doivent être accomplies
           statique en détaillant la réglementation jointe à ces actions

origine soit
           externe à l'entreprise : lois, règlements ...
           interne à l'entreprise : règlements intérieurs, choix de gestion ...

La règle de gestion est
           la traduction conceptuelle des objectifs choisis et des contraintes acceptées parl'entreprise
           liée aux traitements → règle d'action
           liée aux données → règle de calcul

Règle d'action décrit les actions à accomplir :
           "Un inventaire doit être dressé périodiquement"
           "Tout produit livré sera entré en stock"
           "Un contrôle de la gestion des échelons déconcentrés sera mis en place"
           "La Centrale d'achats sera libre d'imposer des jours de commande"

Règle de calcul décrit la façon dont doivent s'accomplir les actions :
           "La valeur de stockage d'un produit est calculée par la formule du prix moyen pondéré"
           "Le salaire de base est égal à l'indice multiplié par la valeur du point"

Exemples de règles de gestion :

DATE
           Propriétés :
                      Année
                      Mois
                      Jour
           Fonctions :
                      Format numérique
                      Format texte
                      Afficher ( pays; format)
                      Comparer ( date1  : date2)
                      Soustraire ( date1 - date2)
                      Ajouter ( date1 + jour )
           Règles de gestion :
                      1- Le mois est un nombre de 1 à 12
                      2- le jour est un nombre de 1 à 31
                      3- Une année a 365 jours sauf si elle est bissextile
PAYS
           Propriétés :
                      Nom
                      Ancien nom
                      Code téléphone
                      Code voiture
                      Code INSEE
                      Date de création
           Fonctions :
                      Créer un pays
                      Afficher un pays
                      Liste des pays
                      Mise à jour
           Règles de gestion :
                      1- Un pays créé ne peut être détruit
                      2- Si un pays change de nom le code est conservé, l’ancien nom est enregistré :
                      Burkina-Fasso, ex-Haute-Volta
                      3- Si un pays est transformé en plusieurs pays, de nouveaux codes sont créés, l’ancien nom est                       mentionné :
                      Slovaquie, ex-Tchécoslovaquie ou Ukraine, ex-URSS CEI, ex-URSS

LES RÈGLES D'ORGANISATION

traduisent l'organisation mise en place dans l'entreprise afin d'atteindre les objectifs fixés résultent des objectifs
de contraintes externes :
           obligation de créer un poste de travail de comptable,

Exemples

           "L'état des stocks sera suivi par une gestion informatisée confiée au magasinier"
                      découle d'une règle de gestion imposant la tenue d'un stock logique
           "L'enregistrement des livraisons sera fait en fin de journée"
                      découle d'une habitude de travail
           "Les commandes à la Centrale d'achats ne pourront être passées que le mardi et le jeudi"
                      traduction en termes d'organisation d'une règle de gestion

LES RÈGLES TECHNIQUES

expriment les conditions techniques de mise en œuvre des tâches
traduisent les solutions techniques mises en œuvre, compatibles avec l'organisation conçue, et visant à atteindre les objectifs

Exemples

           "La capacité des mémoires auxiliaires sera d'au moins 30 milliards d'octets"
           "Les performances de l'imprimante permettront une édition totale de la paie en moins d'une heure"
           "Le système d'exploitation permettra un travail multipostes"

conséquences d'une règle d'organisation telle que :

           "Plusieurs postes de travail pourront simultanément consulter l'état des stocks"

RECENSEMENT DES RÈGLES

→ fiches descriptives :

en langage courant : lisible mais peu précise et lourde

Exemple : "Une commande doit toujours être valorisée."
           par formule de type mathématique : précise mais obligeant à définir des noms symboliques de données (adaptée aux règles de calcul)          

Exemple : (PS)t = [(PS)t-l  X Qt-l + (PA)t X Qt]/(Qt-l + Qt)

(exprime que le prix de stockage (PS)t est égal à la moyenne entre l'ancien prix destockage PS)t-l et le prix d'achat (PA )t pondérés par les quantités Qt-1 et Qt par pseudo-code : 
permet d'exprimer en les décomposant des règles complexes par autres moyens de description : tables de décision…

RECENSEMENT DES TACHES

Chaque tâche comprend un descriptif des éléments suivants :

           - libellé de la tâche
                      choisi pour l'identifier de manière unique et non ambiguë
           - conditions de déclenchement
                      expriment les événements et leur origine
           - résultats produits
                      finalité de la tâche
           - fréquence de la tâche
                      valeur moyenne ou histogrammes
           - durée de la tâche
                      valeur moyenne ou histogrammes
           - règles associées
                      règles référencées précédemment régissant cette tâche
           - commentaires
                      exemple : difficultés exprimées à l'interview dans l'exécution de la tâche


RECENSEMENT DES DONNÉES
 
Dresser les listes de données identifiées

→ fiche descriptive comprenant :

           nom de la donnée
                      nom choisi selon habitudes de l'entreprise
           définition
                      libellée en compréhension
           structure
                      alphabétique, numérique, alphanumérique, booléenne
           type
                      calculée (règle de calcul), en série (juxtaposition de plusieurs données), élémentaire
           quantification
                      estimation du nombre de valeurs différentes que la donnée est susceptible  de prendre
           exemples de valeurs
                      illustrant la définition
           commentaires
                      référence à des règles de calcul, existence d'autres données ayant des définitions voisines, contrôles de vraisemblance...
           niveau
                      conceptuelle, organisationnelle, physique
            date de création

RECENSEMENT DES DONNÉES

Exemple :

 
DOMAINES D’ACTIVITÉ
  
Idée :
regrouper des actions présentant entre elles une certaine cohésion, autant par le  but qu'elles visent à atteindre que par les règles et les données qu'elles  manipulent, de façon à réaliser un découpage du champ de l'étude

Exemple : gestion d'une petite entreprise de restauration
 
           → 4 domaines :
                      gestion des stocks de marchandises
                      suivi de l'activité de restauration
                      gestion et paie du personnel
                      comptabilité.
 
Un domaine d'activité est :
           une partie du champ de l'étude à laquelle on peut associer un ou plusieurs 

           objectifs précis :
           opérationnels : automatiser la paie, tenir une comptabilité générale, gérer  les stocks, fonctionnels :                prévision, suivi, contrôle, planification, ...
           décrit par un ensemble d'actions, de règles de gestion et de données
           
Isoler un domaine d'activité :
                      regrouper des actions cohérentes entre elles

Exemple : production, contrôle budgétaire, relations humaines...
           associer à ces actions un ensemble de règles de gestion.
           associer à ces actions un ensemble de données
                      Exemple : financières, en personnel, en matières premières...

Exemple : la comptabilité est un domaine :
           contrôle, mesure, obligation légale
           règles de gestion : les règles comptables
  
MODELISER LES TRAITEMENTS
  
Un événement est un message adressé ou reçu par le système d'information

Un message peut être
           porteur d'information
           externe ou interne

Les événements peuvent être synchronisés pour déclencher une opération
           Une opération (ou traitement)
           produit en sortie des messages
           consiste en une suite non-interruptible d'actions élémentaires

Une action élémentaire correspond soit à une
           recherche dans la base d'information
           mise à jour de la base d'information
                      insertions ou suppressions d'occurrences d'entité ou de relation
                      changement de valeur de propriétés
 
Les changements d'état de la base d'information (ou transitions) sont régis
           par des règles de traitement (ou de transition)
           par des contraintes dynamiques

Le MCD ne peut rendre compte de toutes les règles :
           le MCD décrit les aspects statiques que la base d'information doit toujours respecter
           le MCD ne peut pas rendre compte des transitions entre les états successifs  de la base

Les règles de traitement figurent dans le modèle conceptuel de traitement (MCT)
           Le MCT décrit les règles de transition et exprime des contraintes dynamiques
           Le MCT exprime le découpage entre organisationnel et conceptuel (attentes conceptuelles)

risque principal → reproduire le système de traitement existant :
           automatiser les tâches manuelles

Le MCT permet de valider le modèle de données
           vérifier si les messages entrants dans chaque traitement permettent de mettre  à jour correctement la base
           vérifier si le MCD possède les propriétés de produire ces messages

MODELISER LES TRAITEMENTS
 
           1. Identifier les règles de traitement
           2. Faire l'inventaire des événements-messages
           3. Construire le diagramme des messages
                      échangés par l'organisation avec l'extérieur
                      échangés par un domaine de l'organisation
                      échangés par un processus du domaine
           4. Ordonner les messages
           5. Identifier les opérations
           6. Détailler chaque opération
                      exprimer les règles de traitement de l'opération
                      vérifier la pertinence du découpage en opérations 
                      les attentes conceptuelles
                      vérifier que dans une même opération toutes les actions appartiennent à  un même processus
                      identifier les coopérations de processus
                      spécifier les synchronisations
                      vérifier que le MCT est bien formé
           7. Préciser le contenu des messages
           8. Valider le MCD avec le MCT
                      messages entrants, sous-modèle en mise à jour
                      messages sortants, sous-modèle en consultation

EXEMPLE

Le système d'information d'une central d'achat

Les principes de gestion clients sont :

           Lors de l'arrivée d'une commande, le service commercial vérifie l'état du compte client
           Si celui-ci est débiteur, le client est prévenu que la commande ne peut être prise en compte
           Sinon, une confirmation de commande est émise indiquant le taux de remise accordé
           Le taux de remise accordé pour un article dépend à la fois du client et de la  famille à laquelle            appartient l'article
           Un ordre de préparation est transmis au service planning qui a pour charge de planifier la livraison de            la commande
           Le délai de livraison moyen est d'un mois
           Le mois écoulé, le magasin procède à la préparation de la commande puis déclenche la livraison (peut être partielle)
           A chaque livraison un bon (de livraison) est émis indiquant les quantités livrées de chaque article
           Les factures ne sont émises qu'une fois la totalité de la commande honorée

EXEMPLE

MCD :Gestion des Commandes - Facturation


EXEMPLE
 
Le MCD représente certaine règles de gestion :

           taux de remise sont fonction du client et du type de produit acheté. De la
           une seule facture par confirmation de commande
           livraisons partielles : cardinalité (0, n) de CONFIRMATION COMMANDE vers BON                       LIVRAISON

Règles de traitement :
           
           Règle 1 :
                      Une commande est prise en compte si le compte client est solvable

           Règle 2 :
                      Dès que le stock mini est atteint, une demande de réapprovisionnement est faite

           Règle 3 :
                      Le délai de préparation d'une commande est d'un mois

           Règle 4 :
                      La facturation est faite une fois la commande entièrement livrée

MESSAGES-EVENEMENTS
 


DOMAINES


DOMAINES


DIAGRAMME DES MESSAGES
 

IDENTIFICATION DES OPERATIONS

OPERATION DETAILLEE

Domaine : Servir Client
           Processus : Gérer Client
                      Opération : Confirmation Commande


MCT : Gestion des Commandes


CODE

Opération : Confirmation Commande
           Rechercher    
                      Commande (N° client, Date réception, n*{(N° article, Qté commandée)})
           Rechercher Client (N° client)
           
           Si   solvable  alors   
                      Générer N° confirmation
                      Insérer Confirmation Commande
                      Pour tout N° article     faire
                                 Rechercher  Article (N° article)
                                 Insérer Demande de préparation Article (N° article, Qté commandée)
                                 Mise à jour  Article (Stock = Stock - Qté commandée)
                                 Si Stock - Qté commandée < stock mini   alors   
                                            Insérer Rupture (Article)
                                 Finsi   
                      Fait   
                      sinon Insérer refus
           Finsi   

4 commentaires: