Conception des Systèmes d'Information

Présentation au sujet: "Conception des Systèmes d'Information"— Transcription de la présentation:

1 Conception des Systèmes d'Information
Tassadit Amghar Frédéric Saubion

2 Pourquoi choisir cette option ?
2 Pourquoi choisir cette option ? Analyse et conception de systèmes d’information A court terme Objectif professionnel Méthodologie Plus long terme Génie Logiciel DESS

3 Objectif du cours Considérations générales sur les SI
3 Objectif du cours Considérations générales sur les SI Une méthodologie de base : MERISE Informatique industrielle : SADT ... Vers la conception objet UML

4 Notion de Système Sortie Matériels Ensemble d'éléments
4 Notion de Système Matériels Ensemble d'éléments Autres (hommes, règles, ...) Processus Entrée Sortie

5 Exemple de système Essence Voiture Déplacement
5 Exemple de système Essence Voiture Déplacement Contrôlée par un autre système de pilotage : conducteur

6 Objectif du cours Organisations : Entreprises ...
6 Objectif du cours Organisations : Entreprises ... Réalisation d'objectifs Règlements fournisseurs Règlements clients Entreprise Produits achetés Produits vendus

7 SI d'une organisation Eléments : employés, machines, règles
7 SI d'une organisation Eléments : employés, machines, règles But : Stocker et traiter des informations relatives au système opérationnel pour les mettre à disposition du système de pilotage. Objectifs Variables Essentielles Fixe Système Pilotage Entrées Système opérationnel Sorties

8 Exemple Service commercial Système d'information Service expéditions
8 Exemple Service commercial Nouveaux Produits Stat. ventes Système d'information Bons de commandes Pièces règlement Bons livraison Factures Service expéditions Cmdes Livraisons Règlements Clients

9 Statiques : Mémoire de l'organisation
9 Aspects du SI Statiques : Mémoire de l'organisation Enregistrement des faits : base d'information Enregistrement des structures de données, règles, ... Modèle des données Dynamiques M à J des données Changement de règles, structures et contraintes de l'U. ext. Processeur d'informations

10 Actions programmées / Choix
10 Actions programmées / Choix Système déterminé (sans décision) Sorties = f (Entrées) Systèmes avec décisions ou

11 11 SI Automatisable Formalisables : connaissance des entrées implique connaissance des sorties par des règles de transformation : Systèmes déterminés Les choix ne sont pas automatisables : intervention humaine SAI Mémorisation Traitement Automatique : contrôles, MàJ, Recherches, Calculs Saisie Accès

12 Analyse d'un projet Spécification du nouveau projet
12 Analyse d'un projet Spécification du projet Spécification du nouveau projet Processus d'analyse Description des opérations actuelles

13 Eléments liés au projet
13 Eléments liés au projet Coût du projet Matériel Logiciel Choix de la méthode => amélioration de la productivité exploitation Maintenance Portabilité Utilisateur Ne sais pas ce qu'il veut Analyste ne sait pas exprimer ses besoins Change d'avis Nécessité du développement de méthodes d'analyse

14 Objectif d'une telle méthode ?
14 Objectif d'une telle méthode ? Exprimer clairement le cahier des charges dans un langage qui permette une bonne spécification des besoins en étant compréhensible par l'utilisateur Décrire clairement le nouveau système et ses implications pour un bonne réalisation Cours : Méthode MERISE

15 Contexte d'apparition de MERISE
15 Contexte d'apparition de MERISE Avant 1970 : Automatisation des processus administratifs Suppression de postes de travail Ajout de postes de saisie (facturation, consultation stocks) Années 1970 : Intégration de la gestion Pbs : Automatisation au coup par coup (données pouvant être saisies plusieurs fois) Organisation de la circulation générale des données Vers 1975 : L'informatique aide à la gestion Pbs : Lourdeur des systèmes / Limitations techniques de puissance Codification / Manque de cohérence globale

16 Apparition des terminaux et saisie en temps réel
16 Apparition des terminaux et saisie en temps réel Conversion de l'ancien au neuf Actuellement : Réseaux (locaux + internationaux) Interfaces graphiques (convivialité) Langages de consultation Evolution au niveau de la gestion Gestion plus rigoureuse et plu précise Mémoire de l'entreprise plus fiable, cohérente et organisée

17 Caractéristiques d'une méthode
17 Caractéristiques d'une méthode Doit prendre en compte : Facteurs techniques Facteurs socio-économiques Facteurs liés à la nature de l'entreprise Doit mettre en œuvre : Plan technique : nouvelles possibilités Plan socio-économique décentralisation des postes de travail enrichissement des tâches Ergonomie Sécurité - Travail fait - Données enregistrées

18 - Amélioration pour le pilotage - Souplesse - Nouveaux besoins
18 - Amélioration pour le pilotage - Souplesse - Nouveaux besoins - Eléments de solutions Gestion par cmdes, clients - Plusieurs solutions validées par l'utilisateur - Approche globale - Associer aspects organisationnels et informatiques - Répartir les tâches - Plan humain Méthode = moyen d'étude et de dialogue entre utilisateurs et informaticiens

19 Mise en place d'un nouveau système
19 Mise en place d'un nouveau système Risques Adapté Fiable Rentable Enjeux Financier (un nouveau système peut "couler" l'entreprise Perte de clientèle Normalisation des concepts Définition du vocabulaire Guide normalisé pour l'analyse et la spécification ( cahier des charges ) Génie logiciel Portabilité ( ex : pas de ruses )

20 Idées générales de la méthode
20 Idées générales de la méthode Etre capable de dialoguer avec l'utilisateur Etre capable de formuler les hypothèses sur le fonctionnement du système et les valider Avoir des modèles des réalités pour pouvoir construire l'application La méthode apporte : - Des outils de représentation de la réalité (faciles à présenter à l'utilisateur avec vocabulaire clair et précis) - Une démarche pour construire des modèles de l'existant et du futur - Une démarche pour valider ces modèles et les choix qui peuvent être faits

21 Idées générales (suite)
21 Idées générales (suite) Vues externes : vues d'un utilisateur - superposition des vues externes Exhaustivité : peut conduire à la confusion Il est nécessaire de représenter la réalité en faisant abstraction des détails non significatifs en mettant en évidence les différentes règles : construire un modèle Modèle global pour coordonner les différentes vues Processus déductif empirique Pas de théorie donc tout processus déductif est empirique Des vues externes on déduit le modèle global Validation : se fait à travers les vues externes

22 Modèle Réalité Projection Vue globale Modèle global Modèle d'une vue
22 Projection Vue globale Modèle global Modèle d'une vue externe Projection sur la réalité Modèle Induction à partir de la réalité Réalité Nouvelles vues externes Validation Vues externes

23 Les grandes étapes d'un projet
23 Les grandes étapes d'un projet Une étape est définie par : - des données d'entrée - des prestations - des résultats de sortie - un point de décision contractuel sanctionnant la fin de l'étape entre utilisateur, gestionnaire et analyste : validation par l'utilisateur Le mode de validation est défini avant la réalisation de l'étape et avant son étude. Il ne faut pas induire ses propres idées et rester extérieur au problème.

24 Décisions majeures durant le projet
24 Décisions majeures durant le projet 1. Décision de mise en chantier du projet : étude préalable qui doit précéder cette décision et porter sur les points suivants Solutions fonctionnelles et techniques Coût Impact sur l'entreprise Décision de fin d'étude préalable : abandon / modification / poursuite 2. Décision des utilisateurs et des gestionnaires sur les spécifications externes détaillées (i.e. vues externes du futur) 3. Acceptation du système sur jeux d'essais (donnés par les utilisateurs) 4. Système introduit dans l'environnement réel : acceptation définitive

25 Récapitulation ETAPES DECISIONS (UTILISATEUR) PRODUCTIONS DES ETAPES
25 Récapitulation Etude préalable Modification Dossier de choix des modalités de réalisation Spécifications fonctionnelles détaillées Système OK sur jeux d'essais Système en environnement réel Etude détaillée Poursuite / Abandon ss projet 1 Etude détaillée non oui Accord utilisateur Réalisation oui Mise en oeuvre Réception (acceptation déf.) ETAPES DECISIONS (UTILISATEUR) PRODUCTIONS DES ETAPES

26 Schémas directeurs pour le découpage en sous projets
26 Schémas directeurs pour le découpage en sous projets Schéma directeur Consolidation D1 D2 D4 D3 Entreprise DC <- EP1 DC <- EP2 DC <- EP3 DC <- EP4 Domaine Découpe Etude préalable EP3 EP4 Priorités Scénario Planning Dossier de choix

27 Définition et objectifs de chaque étape
27 Définition et objectifs de chaque étape Etude préalable (précédée d'un diagnostic) Diagnostic : définition des moyens nécessaires à l'étude préalable et fixation du cadre du projet Etude préalable : étude et conception globale générale en laissant la possibilité de détailler les points très sensibles - Petite équipe - Plusieurs solutions Plan d'un dossier d'étude préalable : Structures de l'organisme dans le champ de l'étude Procédures et circuits de l'information Degré et type d'automatisation Répartition géographique des utilisateurs et des services Moyens informatiques et autres nécessaires Préciser les étapes suivantes : coûts, moyens, délais, étapes transitoires Fixer le découpage en sous projets Réalisation éventuelle d'une maquette

28 28 Etude détaillée Conduite sur la base de la solution choisie à la fin de l'étude préalable Objectifs : - Compléter et élaborer le détail de la solution choisie - Décrire le fonctionnement du nouveau système - Préciser les moyens humains et financiers les moyens et modalités de lancement protocole de réception constituer les dossiers contraintes de réalisation

29 Réalisation et mise en oeuvre
29 Réalisation et mise en oeuvre Réalisation : Obtenir des programmes qui fonctionnent sur des jeux d'essais fournis par l'utilisateur Etude technique : - Organisation physique des données - Procédures de sécurité - Stratégie de production des programmes Production des programmes : Validation par les utilisateurs, l'exploitation et la maintenance Mise en oeuvre : - Passage du système expérimental au système réel - Préparation de l'environnement (installation des postes de travail, formation des utilisateurs ...) - Préparation du lancement (remise en état des procédures dégradées, rassembler les données dispersées, répercuter les nouvelles codifications, initialisation des nouveaux fichiers) Information et formation des utilisateurs (générale et spécifique)

30 Lancement et validation définitive
30 Lancement et validation définitive Aller-retours entre l'équipe d'étude et les utilisateurs Se limiter à : - opérations de contrôle d'exécution du plan de lancement - assistance aux utilisateurs Ne pas faire : - modification du plan de lancement - modification du système Fin : - mise à jour des consignes - modalités de maintenance du système

31 Etude de l'existant : objectifs
31 Etude de l'existant : objectifs le champs d'étude est-il bien délimité ? quels sont les véritables objectifs ? les véritables besoins ? la perception des responsables est elle correct ou déformée ? A partir de la connaissance de l'existant : les aspects négatifs et positifs immédiats les aspects négatifs et positifs à moyen terme en faire la synthèse afin de : concevoir une ou plusieurs solutions proposer un dossier pour décision

32 Analyse des flux : schéma des flux
32 Analyse des flux : schéma des flux Qui agit : les acteurs - externes (ex : les clients) - internes mais hors du champ de l'étude - internes dans le champ de l'étude Exemple de schéma des flux : Banque Relevé de compte Avis de débit Chèque Avis de crédit Demande d'inscription Etudiant Université Carte d'étudiant Chèque

33 Avantages et inconvénients de ces schémas
33 Avantages et inconvénients de ces schémas Avantages clairs et synthétiques (pas plus de 7 acteurs par schéma) lisibles par n'importe qui peuvent être réalisés avec ou devant l'utilisateur peuvent servir de support d'interview permettent de récupérer les documents utilisés Inconvénients uniquement connaissance des acteurs pas de notion temporelle pas d'éléments quantitatifs

34 Le modèle conceptuel des données
34 Le modèle conceptuel des données Concepts et définitions de base Entité : Une entité est la représentation d'un objet matériel ou immatériel de l'univers extérieur Relation: Une relation est la prise en charge par le SI d'une association existante entre entités Propriété : Une propriété est une rubrique attribut d'une entité ou d'une relation Type : Ensemble d'élément ayant les mêmes caractéristiques Notions d'entité-type, de relation-type : on parlera de la collection des entités-types participant à une relation-type Propriété-type : de type code, libellé ou montant. Elémentaire, concaténée, mémorisée ou calculée. Classe : numérique, alphabétique ou alphanumérique. Longueur : nombre de caractères Propriété-Identifiant : sa valeur identifie de manière unique une entité

35 Représentation schématique
35 Représentation schématique nom entité-type nom relation-type SALARIE AFFECTE A SERVICE MATRICULE NOM DATE-AFFECTATION N°-SERVICE INTITULE noms propriétés-types identifiant souligné Exemple d'occurrence SALARIE AFFECTE A SERVICE 1025B VENTES A DURAND 01/02/1998

36 Relation-type : Caractéristiques-1
36 Relation-type : Caractéristiques-1 Collection : liste des entités-types sur laquelle la relation-type est définie Dimension (arité) : nombre d'occurrences d'entités-types concernées par une occurrence de la relation-type. Elle est supérieure ou égale au nombre d'entités de la collection. Ex (relation réflexive) : est marié à Personne Fonctionnalité : Soit X et Y deux entités-types, on distingue les relations : 1-1 A toute occurrence de X ne correspond qu'une seule occurrence de Y et réciproquement 1-n pays président est dirigé par livre auteur écrit par m-n client produit commande

37 Relation-type : Caractéristiques-2
37 Relation-type : Caractéristiques-2 Totalité-partialité Soit X et Y deux entités de la relation R, R est dite : Totale si aucune occurrence de X et de Y ne peuvent exister sans participer à une occurrence de R Partielle sinon Cardinalités : permettent d'exprimer la fonctionnalité et la totalité/partialité d'une relation. Cardinalité minimum (resp. maximum) : nombre minimum (resp. maximum) de fois ou chaque occurrence d'une entité-type participe à la relation-type. Cardinalité minimum 0 : relation partielle, 1 ou n : relation totale Exemple : matière 0,n 1,n enseigne enseignant cursus 1,n

38 38 Règles de gestion Contraintes d'intégrité du modèle (lois de l'univers réel modélisé dans le SI) Contraintes statiques Portent sur : - une propriété (liste de valeurs possibles ...) - plusieurs pptés d'une même relation ou entité cde(no,date-cde,date-livr) avec date-cde < dte-livr - des pptés d'occurrences distinctes d'une relation ou entité - des propriété d'entités/relations différentes - les cardinalité - les dépendances fonctionnelles Contraintes dynamiques : règles d'évolution ex: un salaire ne doit pas baisser

39 39 Exemple RG1 Tout enseignant enseigne en principe au moins une matière, mais certains d’entre eux peuvent être dispensés d’enseignement en raison de leur travaux de recherche RG2 Toute matière est enseignée dans au moins un cursus RG3 Toute classe a au moins trois enseignements MATIERE 1,n 0,n ENSEIGNANT ENSEIGNE 3,n CURSUS

40 Dépendances fonctionnelles
40 Dépendances fonctionnelles Dépendances fonctionnelles entre propriétés a df b si la connaissance de la valeur de a détermine une et une seule valeur de b Ex : N° INSEE df Nom d'individu ! la réciproque est fausse une df peut porter sur la concaténation de plusieurs pptés Dépendance fonctionnelle élémentaire notée a b si a df b et aucune partie de a ne détermine b. ex : N°INSEE + NOM df ADRESSE n'est pas élémentaire Dépendance fonctionelle élémentaire directe si a b et il n'existe pas de c tq a df c et c df b

41 DF (suite) Notion de clé
41 DF (suite) Notion de clé Une clé est une propriété (ou une concaténation de propriétés) d'une entité telle que toutes les autres propriétés de l'entité dépendent d'elle fonctionnellement et telle que ce ne soit plus vrai pour aucune de ses parties. Dépendance fonctionnelle entre entités notée A B si toute occurrence de A est déterminée par une et une seule occurrence de B NB les cardinalités 1-1 correspondent toujours à une DF

42 Propriétés de DF Réflexivité a df a Projection
42 Propriétés de DF Réflexivité a df a Projection a df b+c ==> a df b et a df c Augmentation a df b ==> " c : a+c df b Additivité a df b et a df c ==> a df b+c Transitivité a df b et b df c ==> a df c Pseudo-transitivité a df b et b+c df d ==> a+c df d

43 Propriétés de DF - Exemples
43 Propriétés de DF - Exemples Réflexivité REF df REF Projection REF df DESIGN + PU ==>REF df DESIGN Augmentation REF df PU REF df PU ==>REF+DESIGN df b Additivité REF df DESIGN et REF df PU ==> REF df DESIGN + PU Transitivité REF df CODETVA et CODETVA df TXTVA ==> REF df TXTVA Pseudo-transitivité REF df CODETVA CODETVA+PU df TXTVA ==> REF+PU df TXTVA

44 Normalisation des entités
44 Normalisation des entités Première forme normale (1FN) : toutes les propriétés sont élémentaires et il existe au moins une clé Si une clé est unique, elle sera prise comme identifiant, si il y a plusieurs clés, on en choisira une comme identifiant. Deuxième forme normale (2FN) : toute propriété doit dépendre de la clé par une DF élémentaire Troisième forme normale (3FN) : toute propriété doit dépendre de la clé par une DF élémentaire directe Forme normale de Boyce-Codd (BCFN) : si une entité possède un identifiant concaténé, un des éléments de cet identifiant ne doit pas dépendre d'une autre propriété. Exemples : CLIENT Nom, adresse Pas FN1 car pas de clé et adresse pas élémentaire (concaténée)

45 Exemples (suite) Ligne-Commande N°cde,Réf,Dés,Qté
45 Exemples (suite) Ligne-Commande N°cde,Réf,Dés,Qté Pas FN2 car Df avec clé n'est pas élémentaire Commande N°cde Concerne Qté Produit Réf, Dés 1,n 0,n Client Codecli,nomcli,codecaté,nomcaté Client Appartient à Catégorie 1,n 0,n Codecaté,nomcaté Codecli,nomcli

46 Exemples (suite) COURS Matière, N°classe, Code-prof N'est pas BCFN
46 Exemples (suite) COURS Matière, N°classe, Code-prof N'est pas BCFN PROF Code-prof , matière CLASSE N°classe Fait cours 1,n 1,n

47 Respect des contraintes d'intégrité, vérification et normalisation
47 Respect des contraintes d'intégrité, vérification et normalisation Le MCD doit respecter les règles de gestion Vérification Dans toute occurrence d'entité ou de relation-type, il ne doit y avoir qu'une seule valeur de chaque propriété (pour les entités règle 1FN). Dans une relation, les propriétés doivent dépendre fonctionnellement des identifiants des entités concernées par la relation. La concaténation de ces identifiants constitue l'identifiant de la relation. Normalisation des relations Chaque propriété doit dépendre fonctionnellement de l'ensemble des identifiants des entités qui participent à la relation, mais d'aucun sous-ensemble de cet ensemble.

48 Décomposition d'une relation
48 Décomposition d'une relation Principe : remplacer une relation de dimension n par plusieurs relations de dimensions plus petites en utilisant les dépendances fonctionnelles que l'on peut détecter sur la relation La décomposition n'est possible qu'à deux conditions : La cardinalité minimum des entités à gauche dans la dépendance fonctionnelle doit être 1 dans la relation à décomposer (relation totale pour ces entités) Si la dépendance fonctionnelle provient d'une autre relation que la relation à décomposer, il faut qu'elle concerne les mêmes occurrences d’entités que la relation à décomposer.

49 Exemple de construction de MCD
49 Exemple de construction de MCD On considère un SI contenant essentiellement les propriétés figurant sur des bons de commandes de la forme : N° BON DATE NOM CLIENT ADRESSE NOM REPRESENTANT REF DESIGN QTE PU MONTANT TOTAL

50 Recueil des informations
50 Recueil des informations On récolte les informations par une suite d'interviews avec les différents postes de travail On obtient ainsi les règles de gestion suivantes : R1 : Un client peut passer une ou plusieurs commandes ou aucune commandes R2 : Une commande peut concerner un ou plusieurs produits R3 : Une commande est passée à un représentant qui n'est pas toujours le même pour un client donné On établit également la liste des propriétés à partir des documents et des fichiers Ici, on imagine qu'il y a des codes pour identifier les entités évidentes comme par exemple les clients, les représentants .... S'il s'agit d'un système manuel, ces codes n'existent pas forcément, dans ce cas, on peut par exemple les marquer avec une étoile.

51 Dictionnaire des données
51 Dictionnaire des données

52 Une technique : Graphe des DFs
52 Une technique : Graphe des DFs Liste des propriétés du DD sauf concaténées ou calculées. (ex tout sauf ADRESSE, MONTANT et TOTAL) examen des documents et identifiants évidents : liste des DF dont le domaine de départ ne contient qu’une seule propriété non concaténée S’il reste des propriétés isolée, on cherche des DF qui conduisent à ces propriétés à partir de propriétés concaténées. Si on en trouve pas la ppté reste isolée. NOBON x REF DATE CODEREP COCLI QTE DESIGN PU NOMREP NOMCLI RUCLI VILCLI Elimination des cycles Fermeture des df (propriétés transitivité et pseudo-transitivité)

53 Graphe des DFs (suite) Elimination des transitivités NOBON x REF
53 Graphe des DFs (suite) Elimination des transitivités NOBON x REF DATE COREP COCLI QTE DESIGN PU NOMREP NOMCLI RUCLI VILCLI Structure d’accèes théorique (SAT) DATE CODEREP COCLI QTE DESIGN PU

54 Etablissement du MCD PRODUIT COMMANDE x NOBON DATE REF DESIGN PU QTE
54 Etablissement du MCD PRODUIT COMMANDE x NOBON DATE REF DESIGN PU QTE CLIENT REPRESENTANT COCLI NOMCLI RUCLI VILCLI COREP NOMREP Les Arcs terminaux obtenus à partir des propriétés élémentaires définissent les entités. Les origines seront les identifiants Les arcs sont les relations. Les prop non isolées restantes sont affectées à des relations. Les règles de gestion doivent permettre de trouver les cardinalités Les règles de vérification, normalisation et décomposition doivent être respectées

55 Etablissement du MCD (suite)
55 Etablissement du MCD (suite) COMMANDE SE COMPOSE DE PRODUIT 1,n 0,n NOBON DATE REF DESIGN PU QTE 1,1 1,1 CLIENT 0,n PASSE COMMANDE REPRESENTANT COCLI NOMCLI RUCLI VILCLI COREP NOMREP OBTIENT 0,n

56 Le Modèle Conceptuel des Traitements
56 Le Modèle Conceptuel des Traitements Le MCT exprime ce qu'il faut faire, mais n'indique pas qui doit faire ni quand il faut faire ni où il faut faire (concepts organisationnels) ni comment il faut le faire (concept opérationnel). Exemple : Dans une administration, les demandes de promotion sont traitées selon les règles de gestion suivantes : Toute demande de promotion doit subir un examen préalable permettant de déterminer si elle est recevable ou non. L'examen du dossier d'une demande recevable ne peut se faire qu'après rapport du supérieur hiérarchique. Après examen du dossier par l'autorité compétente, la promotion sera accordée ou refusée.

57 Exemple de MCT Demande de promotion
57 Exemple de MCT Demande de promotion Evènement externe générateur du Processus Pas d’attente Examen préalable Opération non recevable ok Règles d’émission des évènements internes Evènement interne résultat rejet Evènement interne intermédiaire Attente du rapport (attente conceptuelle) dossier ouvert Rapport du sup. hiér. Evènement externe ET Synchronisation marquant l’attentes (Règles d’activation de l’opération) Examen du dossier Avis fa- vorable Avis défa- vorable Opération Règles d’émission Promotion acceptée Promotion refusée Evènements résultats

58 Les Concepts Evénement
58 Les Concepts Evénement Compte rendu au SI quelque chose s'est produit dans l'univers extérieur ou dans le SI lui-même Un événement est externe s'il provient de l'univers extérieur, interne dans le cas contraire Un événement externe doit provoquer une réaction du SI sous la forme d'une opération. Un événement interne peut soit provoquer une nouvelle réaction du SI soit constituer un résultat pour l'Univers extérieur. Un événement peut être porteur de propriétés (constituant des mouvements) qui n'ont pas nécessairement d'identifiant. On introduit la notion de type d'événement caractérisé par : - mêmes types de propriétés associées - mêmes types d'actions à entreprendre Opération Ensemble d'actions ininterruptibles accomplies par le SI en réaction à un événement ou à une conjonction d'événements. Une opération produit en sortie de nouveaux évènements.

59 Les Concepts (suite) Type d'opération
59 Les Concepts (suite) Type d'opération - type d'actions à entreprendre (chaque action est une combinaison d'actions élémentaire AJOUT, MODIFICATION, ANNULATION, DEDUCTION et RECHERCHE reliées par TANT...QUE et SI..ALORS...SINON) - types d'événements contributifs caractérisés par des types de propriétés - types d'événements produits dont l'émission est soumise à des règles d'émission Synchronisation Rendez-vous des événements contributifs qui doivent être arrivés avant de déclencher l'opération selon une proposition logique (connecteurs OU et ET) traduisant des règles d'activation. Type de synchronisation - liste de type d'événements contributifs - règles d'activations portant sur ces types d'événements Processus : enchaînement d'opérations incluses dans un même domaine

60 Représentation Evènements contributifs Synchronisation
60 Représentation Evènements contributifs Synchronisation (Règles d'activation) Opération Règles d'émission Evènements internes produits E1 E2 En Proposition Logique Actions R1 R2 Rm E'1 E'2 E'3 E'q

61 Consommation des évènements
61 Consommation des évènements Chaque occurence d’un évènement contributif qui active la synchronisation est consommée. Une occurence de chaque évènement correspondant à la règle d’émission utilisée sera produite. AVANT APRES Dossier ouvert Dossier ouvert Rapport Rapport ET ET Examen Examen Favorable Dé- favorable Favorable Dé- favorable Promotion accordée Promotion refusée Promotion accordée Promotion refusée

62 Construction du MCT Exemple : Traitement des commandes clients
62 Construction du MCT Exemple : Traitement des commandes clients Règles de gestion 1-toute commande de client non solvable est refusée 2-les commandes non disponibles sont mises en attente et devront déclencher un réapprovisionnement par le fournisseur 3-les commandes en attente seront déclarées disponibles lorsque le réapprovisionnement sera suffisant 4- les commandes disponibles donnent lieu à livraison au client 5-les livraisons refusée par le client donnent lieu à retour de marchandises 6-les livraisons acceptées donnent lieu à des factures qui sont conservées jusqu’à complet règlement 7-toute facture non réglée à l’échéance donne lieu à relance Aucune notion de lieu, de personne, de moyens ou de temps

63 Construction du MCT (suite ...)
63 Construction du MCT (suite ...) Schéma de circulation Commande Commande acceptée SERVICE Cial MAGASIN CLIENT Refus Marchandise + Bon livraison Retour marchandise Acceptation livraison Facture Relance Manquants Réappro Règlement COMPTA Facture soldée Service achats, Fournisseur etc. ARCHIVES

64 Construction du MCT (suite ...)
64 Construction du MCT (suite ...) Graphe des flux Commande cde refusée cde acceptée cde en attente Liste des manquants Réappro bon livraison Retour Marchandise Fact. en attente règlt. Relance Règlt. Fact soldée

65 Construction du MCT (suite ...)
65 Construction du MCT (suite ...) Commande Graphe des flux corrigé cde refusée cde en attente Manquants Réappro livraison Fact. en attente règlt. Retour Marchandise Relance Règlt. Fact soldée

66 Construction du MCT (suite ...)
66 Construction du MCT (suite ...) Cde client Début de représentation graphique T1 Solvable Non Solvable Disponible Indisponible Cde Refusée Cde attente Livraison Manquants PROCES. APPRO. Réappro. ET T2 Disponible Indisponible

67 Construction du MCT (... fin)
67 Construction du MCT (... fin)

68 Le Modèle Organisationnel des Traitements (MOT)
68 Le Modèle Organisationnel des Traitements (MOT) Niveau Organisationnel : QUI, OU, QUAND Le MOT intègre les notions de temps et durée (déroulement) de ressources, de lieu et de résponsabilité (poste de travail), et de nature de traitements (manuels ou automatiques) Un exemple Niveau conceptuel Rôle du système : Gestion des stocks (en liaison avec le système de gestion commande client) - Tenue de stock - Approvisionnements

69 Le MOT : Un exemple Règles de gestion
69 Règles de gestion 1-Un produit peut être en stock dans plusieurs magasins 2-Un pdt en magasin peut être mouvementé +sieurs fois par dimin°ou augment° de la qté en stock 3-Un pdt est vendu par un seul fournisseur pour tous les magasins 4-Le système concerne une entreprise de distribution qui achète des pdts aux fournisseurs pour les revendre à ses clients 5-Une commande de réapprovisionnement concerne un fournisseur 6-On passe une commande de réapprovisionnement dans l’un des deux cas suivants : -Un pdt commandé par un client à un magasin est en rupture de stock dans ce magasin -Dans un magasin on a pour un produit : Stock + total cdé aux fournisseurs < Stock mini On commande alors Q=Stock maxi -(stock + total commandé) 7-Les livraisons des fournisseurs sont contrôlées par comparaison avec les commandes. Toute livraison non conforme est refusée et retournera chea le fournisseur. 8-On tient à jour un stock théorique d’après les mvts du stocks 9-A période fixe on fait un inventaire pour déterminer les écarts entre le stock physique réel et le stock théorique déterminé par le SI 10- les mvts de stocks sont: a) hors période inventaire : Livraison fournisseur : Stock = stock + Qté livrée Bon de livraison client : Stock = Stock - qté livrée retour marchdise client : Stock = Stock + qté retournée b) pdt ou hors période inventaire : Stock = Stock +/- ecart entre stock réel et théorique (Ajustement)

70 Exemple (suite) : Le MCD
70 COMMANDE 1,n COMPOSITION n° Cde, date Qté 0,n PRODUIT 1,1 Réf, design, PUvente 0,n PASSE A STOCKAGE Stock 0,n 0,n MAGASIN 0,n n° mag, adresse 1,1 FOURNISSEUR 1,n VENDU PAR CodeF, nomF, RueF, VilleF

71 Exemple (suite) : Le MCT Processus APPRO
71 Processus TENUE STOCK Processus GESTION CDES CLIENTS Produit sous stock mini Produit manquant OU Détermination de commande à fournisseur Toujours Livraison fournisseur Cde fournisseur ET Contrôle livraison OK Pas OK Livraison fournisseur acceptée Livraison fournisseur refusée Processus TENUE STOCK

72 Exemple (suite) : Le MCT Processus TENUE STOCK
Ecart occasionnel constaté Processus APPRO Bon livraison client émis Processus GESTION CDES CLIENTS a c Livraison fournisseur Retour mar- chandise Date hors période d’inventaire Ecarts constatés b d e f (a OU b OU c OU d) ET e OU f Traitements des mouvements de stock Toujours < stock mini Dernier mvt avant inventaire Produit sous stock mini Stock à jour Processus APPRO Période d’ inentaire Etat du stcok fin de période connue ET Inventaire Toujours

73 Exemple (suite) : Le MOT Règles d’organisation
73 RO1-Le service achats et les magasins sont équipés de micro-ordinateurs compatibles pouvant s’échanger des disquettes. Le srevice commercial dispose d’un matériel analogue RO2-Pour la détermination des commandes à passer aux fournisseurs, le micro du service achats édite des propositions de commandes qui sont analysées par le responsable en vue d’une validation ou de modifications. Ces opérations doivent être faites le matin. RO3-Les comandes validées sont éditées a)dans l’ordre des fournisseurs concernés pour leur être expédiées b)dans l’ordre des magasins concernés pour leur être transmis RO4-A chaque livraison fournisseur, le magasinier contrôle la marchandise livrée en la comparant à la mar- chandise commandée figurant sur la commande au fournisseur RO5-La MAJ du stock s’effectue a)le matin à 9h pour les sorties de stocks. Celles ci (doubles des bons de livraison à clients) proviennet du pro- cessus GESTION CDES CLIENTS et sont transmises au magasin concerné sur une disquette b)En temps réel (transactions en mode conversationnel) à tout autre moment de la journée de travail pour les autres mouvements. Les anomalies sont immédiatement recyclées. RO6-Le courrier est expédié à 12h RO7-L’inventaire est annuel. Le vendredi soir précédent, il y a édition de l’atat du stock sur ordinateur. Durant tout le WE et au vu de ce listing, le magasin mobilise toute son énergie à inventorier les casiers et à noter les écarts constatés sur l’état du stock édité. La saisie des écarts pourra se faire dans les jours suivants. R08-Dans un magasin tout produit doit pourvoir être rangé dans un seul casier et tout casier ne doit contenir qu’un seul produit.

74 Procédures Fonctionnelles (PF)
74

75 PF (suite) 75

76 MOT : Les concepts Poste de travail
76 Poste de travail Type de lieu: ensemble des lieus ou les actions d’une opération pourront s’effectuer Responsable: personne ayant la résponsabilité de certaines actions d’une opération Ressources: moyens permettant de résliser certaines actions d’une opération (partageable ou non, consomable ou réutilisable) Procédure Fonctionnelle (PF) ensemble ininterruptibe d’actions d’une opération conceptuelle affécté à un PT Nature: degré d’automatisation (manuelle, automatisée batch, automatisée conversationnelle) Déroulement: Début, Durée max Flux entrant:informations qui doivent être traitées Flux sortant: émis avec un évènement Evènement: contributif : participe au déclenchement d’une PF émis : ce qui se passe à l’issu de la PF soit dans l’univers extérieur (évt résultat) soit pour être consommé par une PF suivante (évt interne)

77 Déscription détaillée d’une PF
77 OUTILS Fiche de description de procédure Déscription des mouvements portés par les évènements Diagramme de répartition des tâches entre l’homme et la machine Déscription des traitements autromatiques utilisés selon la mature de la PF (manuelle/automatisée)

78 Exemple 78

79 Exemple (suite) : description des écrans. Procédure PF9
79 Exemple (suite) : description des écrans. Procédure PF9 N°MAGASIN ? 01 REAUMUR CRITERES D’ACCES 1PAR REF 2 PAR DESIGNATION CHOIX ? 1 RM Retour Marchandise client BL Bon Livraison fournisseur AJ Ajustement TYPE DE MOUVEMENT ? ... Taper n° du magasin et afficher libellé magasin taper 1 ou 2 taper RM BL ou AJ si accès par désignation.. affichage taper ref correspondante DESIGNATION ? CHEMISE ... REF DESIGN PU VENTE X01 CHEMISE 150 X23 CHEMISE 120 REF ? X01 REF ? X01 si accès par réf affichage entrer qte livrée ou stock réel Seulement si BL TYPE DE MOUVEMENT ... REF ... DESIGNATION ... PU VENTE ... QUANTITE ? ... N° CDE FOURNISSEUR ?...

80 Diagramme de répartition des tâches entre homme et machine
80 Diagramme de répartition des tâches entre homme et machine HOMME MACHINE REMARQUES 1 Entrer n° mag 2 Afficher libellé Lib magasin. 3 Entrer choix critères Afficher critères d’accès Par réf. désign ou FIN FIN fin session 4Afficher types mvts BL bon livr, RM retour march. Ajustement ou FIN 5Entrer choix type mvt Accès par réf Accès par désign FIN 3 8 6 Entrer désignation 7 Affichage prod ayant cette design FIN 5 8 Entrer réf du produit Accès réf 9 Affichage type de mvt et produit FIN Type mvt réf, désign et pu Qté entrée si BL ou RM stock réel si AJ Pour supprimer ligne de Cde livrée de la base d’info 5 10 Entrer réf du produit Autre mvt BL 11 Entrer n° Cde à four. Accès réf. Accès désign. 8 6

81 81 Exemple (suite)

82 82 Autre exemple : la procédure PF12

83 Dernier exemple : la procédure PF1
83 Dernier exemple : la procédure PF1 DESCRIPTION D’UN ETAT DE SORTIE.PROCEDURE :PF1 TITRE:PROPOSITION DE COMMANDE ETAT N° : E01 PROPOSITION N° DATE D’EDITION: ../../.. MAGASIN N°.. FOURNISSEUR : CODE: NOM: ADRESSE: REF DESIGNATION QUANTITE A COMMANDER

84 84 Modèles Externes Chaque traitement possède son modèle externe ou vue externe Cette vue reflète la vision que l’utilisateur a des données à travers la procédure Il s’agit d’un MCD construit spécifiquement pour chaque traitement La phase de validation permettra d’ajuster vues externes et MCD initial. Notion de blocs logiques d’entrée/sortie E2 E1 E1 E2 R1 Bloc logique E’1 E’2 R’1 Bloc logique E’1 E’2

85 Règles de construction des ME
85 Règles de construction des ME Une vue externe pour chaque consultation et chaque mise à jour de chaque PF automatisée Uttilisation des blocs logiques Utilisation du formalisme entité-association Identifiant non obligatoire pour une entité externe Utilisation des noms figurant sur le dictionnaire des données pour les propriétés externes qui correspondraient à des propriétés conceptuelles répertoriées Ignorance du modèle conceptuel des données

86 Modèle Externe PF9 Consultation d’un pdt
86 Modèle Externe PF9 Consultation d’un pdt L’examen de la grille d’écran (T79) relative à l’affichage d‘un produit nous montre que le bloc logique de sortie est composé pour tout produit affiché de la référence, de la désignation, du prix unitaire. (dans DD : Réf, Désign et PU) Entité pour un produit affiché : ARTICLE Réf PU Désign Un examen plus poussé montre que si +sieurs prdt affichés -> cas d’un accès par désignation. La non répétitivité oiblige à modifier le modèle: DESIGN Désign 1,n on évite ainsi que toutes les désignations du bloc logique soient identiques CONCERNE 1,1 Accès plus rapide sur le critère désignation ARTICLE Réf PU

87 ME PF9 (suite) MAJ DU STOCK
87 ME PF9 (suite) MAJ DU STOCK Bloc logique contenant les pptés nécessaires 1)identification de la ppté à mettre à jour 2)obtention de la nouvelle valeur Stock d’un pdt à metttre jour idéntifié par 1)N° magasin ) réfrence du produit Mise à jour nécessite de connaitreqté en mvt et type de mvt (RM AJ BL) DD : Réf et N°mag. on doit créer les pptes externes Type_mvt et Qté _mvt MOUVEMENT-STOCK Type_mvt n°mag réf Qté_mvt répétitivité du type de mouvements non génante car un seul mouvement du stock pour la MAJ du stock d’un produit du magasin ANNULATION D’UNE COMMANDE ANNULATION N° Cde Réf

88 ME PF1 PF8 PF12 PROPOSITION BL ETAT N°Proposition N°Mag CodeF
88 ME PF1 PF8 PF12 PROPOSITION BL ETAT N°Proposition N°Mag CodeF nomF RueF VilleF N°BL N°mag date-inventaire 1,n 1,n 1,n COMPORTE COMPORTE COMPORTERAIT 1,1 1,1 1,1 STOCK-MOUVEMENTE LIGNE LIGNE Réf Désign Qté-sortie N°casier Réf Désign stock Réf Désign Qté-à-Commander

89 La validation Principe
89 La validation Principe Chaque vue externe doit être mise en accord avec le MCD En mise à jour, on doit s’assurer qu’on donne bien au système tous les élémnets nécessaires à cette MAJ En consultation, on doit s’assurer que le système est capable de sortir les données désirées Chaque modèle externe doit être déductible du MCD

90 Exemple ME validé pour PF9 consultation d’un produit DESIGN ARTICLE
90 Exemple ME validé pour PF9 consultation d’un produit DESIGN ARTICLE 1,n CONCERNE 1,1 Désign Réf PUVente 1,n STOCKE DANS 1,n MAGASIN N°mag libellé

91 Suite MCD corrigé: DESIGN PRODUIT 1,n CONCERNE 1,1 Désign Réf PUVente
91 Suite MCD corrigé: DESIGN PRODUIT 1,n CONCERNE 1,1 Désign Réf PUVente

92 92 ... MCD Validé

93 Sous-modèle conceptuel
93 Sous-modèle conceptuel A propos de chaque PF, on sort du MCD validé un extrait qui permet de déduire ttes les vues externes de la PF Exemple : sous-modèle conceptuel pour PF12 DESIGN PRODUIT 1,n CONCERNE 1,1 Désign Réf PUVente 0,n STOCKAGE Stock stock mini stock max n°casier 0,n MAGASIN N°mag libellé

94 Règles et méthodes de validation
Validation en consultation Les propriétés externes doivent être des propriétés conceptuelles sinon voir si oubli dans le MCD et rajout propriété organisationnelle à rajouter au MCD ppté absente = donnée calculée. Ajout dans le MCD des données pour calcul ppté absente = ppté indésirable entrée en conversationnelle. Retrait du ME On doit se demander si le système peut accéder aux propriétés recherchées soit par balayage d’une entité ou d’une relation soit par l’identifiant On doit se demander si on peut sélectionner les bonnes occurences des propriétés auxquelles on accède pb si absence d’un critère de sélection dans la vue externe (à rajouter) pb de confusion entre deux relations conceptuelles identiques mais sémantiquement différentes On doit vérifier que pour deux relations sémantiquement analogues dans la vue externe et le MCD, les cardinalités externes sont contenues dans les cardinalités conceptuelles

95 (suite) Validation en mise à jour
95 (suite) Validation en mise à jour Valider les propriétés externes qui doivent servir soit à identifier le ppté conceptuelle à mettre à jour soit à l’élaboration de la nouvelle valeur de la ppté conceptuelle à insérer ou modifier Valider les entités et les relations externes les entités externes sont valides si leurs pptés le sont les relation externes sont valides si leur pptés le sont et les entités qu’elles relient aussi Valider les cardinalités comme pour la consultation

96 96 Méthode de Validation 1- Valider toutes les vues externes en consultation, en notant les éventuelles modif° à apporter au MCD Si on modifie le MCD, il faut revalider ttes les vues externes déjà examinées 2-Valider toutes les vues externes en MAJ (mêmes remarques que pour consultataion) 3-S’assurer que tte ppté conceptuelle a pu être insérée (et même modifiée ou supprimée s’il s’agit d’une proposition permanente) dans au moins une vue externe. Sinon imaginer des PF pour les créer avec des vues externes à valider... (a moins que 4-). cf maintenance des données permanentes 4-Repérer les pptés conceptuelles ne participant à aucune vue externe. Si non fondamentales, les supprimer du MCD 5- construire le MCD compte tenu des modifs 6-Construire npour chaque PF à partir de ses ME un sous-modèle extrait du MCD et permettant de déduire ttes les vues externes de la PF.

97 Maintenance des données permanentes
97 Maintenance des données permanentes Entités et Relations permanentes doivent être créées et modifiées (cf MCT et MOT) Exemple : maintenance des produits et des fournisseurs Il faut prévoir un processus de maintenance pour chaque entité/relation permanente Au moment de l’implantation du système, les créations d’entités permanentes se feront en premier Exemple Ou encore Nouveau produit Hausse des prix Création Produit MAJ des prix Toujours Toujours Produit inséré Hausse répercutée sur toiuts les produits Processus à intégrer au MOT

98 Conclusion Les concepts utilisés
98 Conclusion Les concepts utilisés MCD BRUT : MCD établi dans l’absolu sans préjuger des traitements (Perception du réel) ME ou Vue Externe : Modèle des données «vu» par l’utilisateur Validation : Confrontation du MCD et des vues externes dans le but des les faire correspondre MCD validé : MCD après validation ME validé : vue externe après validation Sous-modèle conceptuel : extrait du modèle conceptuel correspondant à une PF Principe de la démarche NIVEAU TRAITEMENTS DONNEES MCT MCD CONCEPTUEL ORGANISATIONEL MCT VALIDATION MCD VALIDE MLD

99 Le Modèle Logique des Données
99 Le Modèle Logique des Données OBJECTIF : MCD Formalisme (Choix Organisationnels fonctions de logiciels) Navigationnelle entité-type relation-type FICHIERS BD (Enregistrements/Ensembles) occurence ENREGISTREMENTS Relationnelle CHAMPS CLE Identifiant

100 100 Rappels sur les BD BESOIN : accès multi-critères - intégration des données - relation entre les données CARACTERISTIQUES Données : structurées non redondance accès direct multi-critères reliée conformément au MCD Indépendantes des programmes Sécurité SGBD : interface programmes utilisateur/BD

101 Enregistrements esclaves
101 CONTEXTE NAVIGATIONNEL Relation 1 à plusieurs Ex : Client - Commande Enregistrement maître - propriétaire Client C23 Enregistrements esclaves membres Commandes du Client C23 Notions importantes: Type d’enregistrement Occurence d’enregistrement Type d’ensemble Occurrence d’un type d’ensemble

102 Diagramme de structure
102 Diagramme de structure Exemple : nom de l’enregistrement-type (du propriétaire type) CLIENT CODE, NOM, CA nom des champs (types de propriétés) COMMANDES-DU-CLIENT Relation 1-n nom de l’ensemble-type COMMANDE nom du membre-type NOCDE, DATE propriétés Exemple d’occurrences: occurrence de CLIENT A01 DUPONT 5000 Occurrence de COMMANDES-DU- CLIENT pour le client A01 occurrence de COMMANDE /01/98 occurrence de COMMANDE /02/98

103 Structures possibles Arborescence/Hiérarchie Occurrences racine
103 Structures possibles Arborescence/Hiérarchie Occurrences 4 TIERS de la racine CLASSE racine NOCL, LIBCL de segments 400 FOURNISSEURS 410 CLIENTS COMPTE NOCPT, LIBCPT DUPONT DURAND DUBOIS DUPIN COMPTE-AUXILIAIRE feuille NOCPA, NOM des feuilles Réseau (ex CODASYL) SYSTEME TOUS-LES-CLIENTS TOUS-LES-PRODUITS TTES-CDES CLIENT COMMANDE PRODUIT NOCDE, DATE CODE, NOM COM-DU-CLI REF, DESIGN, PU DETAIL COM-DU-PROD LIGNE-COMMANDE QTE

104 E/R Enregistrements/Ensembles
104 E/R Enregistrements/Ensembles MODELE CODASYL Toute entité devient un type d’enregistrement 1,n ou 0,n R 1,1 ou 0,1 1,n ou 0,n 1,n ou 0,n A B A R B A A A B RA RB R R R B B

105 Exemple NOM NOM 1 ,n CONCERNE 1,1 COMMANDE CLIENT 1,1 PASSEE PAR 0,n
105 Exemple NOM NOM 1 ,n CONCERNE 1,1 COMMANDE CLIENT 1,1 PASSEE PAR 0,n NOCDE, DATE CODE, ADRESSE 1,n PRODUIT SE COMPOSE DE 0,n REF, DESIGN, PU

106 Exemple (suite) MLD CODASYL SYSTEME TOUS-LES-PRODUITS TOUS-LES-CLIENTS
106 Exemple (suite) MLD CODASYL SYSTEME TOUS-LES-PRODUITS TOUS-LES-CLIENTS CLIENT CODE, NOM, ADRESSE TOUTES-LES-CDES PASSATION COMMANDE PRODUIT NOCDE, DATE REF, DESIGN, PU COM-DU-PROD DETAIL LIGNE-COMMANDE QTE

107 Modèle hiérarchique Toute entité devient un segment A 0,n ou 1,n 1,1
107 Modèle hiérarchique Toute entité devient un segment A 0,n ou 1,n 1,1 0,n ou 1,n 0,1 0,n ou 1,n R B A R B A R 0,n ou 1,n B A A A A B RAB RBA B RAB A B B ou A RAB R

108 108 Fichier 1- Toute entité devient un fichier (l’identifiant de l’entité sera la clé du fichier) 2- Relations 1 à n (0,1/1,1 et 0,n/1,n) Entité avec 0,n ou 1,n Fichier Maître Entité avec 0,1 ou 1, Fichier Esclave La clé du fichier maître est ajoutée aux champs du fichier escalve Les pptés éventuelles de la relation migrent dans le fichier esclave Exemple COMMANDE CLIENT 1,1 0,n N°cde,date PASSE Code-cli, nom Fichier CLIENT Fichier maître CLIENT Code-cli, nom Fichier COMMANDE Fichier esclave N°cde, codecli, date COMMANDE clé du fichier maître

109 Fichier (suite) 3- Relations n-m (0,n/1,n et 0,n/1,n)
109 Fichier (suite) 3- Relations n-m (0,n/1,n et 0,n/1,n) Relation Fichier Esclave Entités avec 0,n ou 1,n Fichiers Maîtres Clé du fichier esclave = concaténation clés fichiers maitres Exemple : COMMANDE PRODUIT 1,n SE COMPOSE DE 0,n N°cde,date Réf, désign, PU QTE COMMANDE PRODUIT N°cde,date Réf, désign, PU LIGNE-COMMANDE N°Cde, Réf, qté

110 CONTEXTE RELATIONNEL Modèle Relationnel
110 CONTEXTE RELATIONNEL Modèle Relationnel Enregistrements Relations entre pptés (non entre entités du MCD!!) Concepts : RELATION-TYPE, OCCURENCE DE RELATION-TYPE, Domaine, Constituant (Attribut), Degré (n-uplet), Cardinalité (nbr d’oocurences) Exemple : VOYAGE(NOVOYAGE, VILLE-DEPART,VILLE-ARRIVEE) CONSTITUANTS NOVOYAGE VILLE-DEPART VILLE-ARRIVEE OOCURENCES Occurence 1 IT25 PARIS NICE Occurence 2 IT27 NICE PARIS Occurence 3 IT33 LYON PARIS} 3-UPLE Occurence 4 IT47 PARIS LYON CONSTITUANT card.:4, deg.:3, doms.: NOVOYAGE = (IT25, IT27, IT33, IT47) et VILLE=(PARIS, LYON, NICE) Autres Concepts : Dépendences foctionnelles, clé d’une relation, formes normales

111 (SUITE) Opérateur de l’algèbre relationnelle Union Intersection
111 (SUITE) Opérateur de l’algèbre relationnelle Union Intersection Différence Projection Selection Composition (jointure) Division Requêtes manipulations de données ou interrogations sur des bases relationnelles SGBD Relationnels -concept de relation -TOTALE INDEPENDANCE PROGRAMMES-DONNEES passage auto. du MLD rel. au modèle physique non connu de l’util. -puissants langages de manip° et d’interrogation (algèbre rel. /calcul des prédicats) -Dé«finition des données par descr° du MLD relationnel

112 MCD Entités/Relations MLD Relationnel
112 MCD Entités/Relations MLD Relationnel Entité Relations, Propriétés Constituants (identifiant clé) 1,n ou 0,n A R 1,1 ou 0,1 B B(constituants de B, identifiant de A, pptés éventuelles de R) 1,n ou 0,n A R 1,n ou 0,n B R(clé=identifiant_A+identifiant-B, pptés éventuelles de R) NOTE : MCD bien construit MLD en 3fn

113 Exemple COMMANDE SE COMPOSE DE PRODUIT 1,1 0,n NOCDE DATE
113 Exemple COMMANDE SE COMPOSE DE PRODUIT 1,1 0,n NOCDE DATE REF DESIGN PU QTE 1,1 1,1 TAXE A CLIENT 0,n PASSE COMMANDE 1,n COCLI NOMCLI RUCLI VILCLI TVA CODETVA TAUX MLD Relationnel CLIENT (COCLI, NOM) COMMANDE (NOCDE, COCLI, DATE) LIGNE-CDE (NOCDE,REF, QTE) PRODUIT(REF, DESIGN, PU, CODE-TVA) TVA(CODE-TVA, TAUX)

114 Formalisation conceptuelle
114 La démarche Merise de constitution de SI Etude des données Etude des traitements Modélisation du Réel (réel perçu machinable) Abstraction du Réel Choix organisationnels Formalisation conceptuelle des processus Validation Traitements futurs ML MOT et MPD

115 La démarche MERISE (suite)
115 La démarche MERISE (suite) Etude Globale du SI - Schéma directeur Plan de developpement Etude préalable d’un domaine du SI Etude préalable Dossier de choix domaine 1 Dossier de choix domaine 2 Decision DG Decision DG Etude détaillée d’un domaine par projet et par app° Etude détaillée domaine 2 Cahier des charges util. app 1 Cahier des charges util. app 2 Approbation DG et utilisateurs Etude technique

116 La démarche MERISE (fin)
116 La démarche MERISE (fin) Etude technique Cahier des charges de réalisation Cahier des charges de réalisation Programmation PROG1 PROG2 PROG1 PROG2 PROG3 Mise en oeuvre Manuel d’utilisation, consignes Maintenance

117 117 L’Etude détaillée 1-Etude générale du MOT futur : Tableau des PF, Diagramme d’enchainemlent des PF, Graphe de circulation 2-Etude poussée de chaque PF : Fiche de description, Description des documents éventuels, Tables de décision éventuelles, Description éventuelle des états de sortie, Grilles d’ecran (a faire aprouver par les utilisateursconcernées), Grilles de contrôles, Fiche de répartition des tâches entre l’homme et la machine (a faire approuver par les utilisateurs concernés), Modèle externe non validé 3-Validation du MCD : Validation des modèles externes, Validation du MCD, Sous-modèles conceptuels 4-Passage au MLD