La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "Conception des Systèmes d'Information Tassadit Amghar Frédéric Saubion."— Transcription de la présentation:

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

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

3 Objectif du cours zConsidérations générales sur les SI zUne méthodologie de base : MERISE zInformatique industrielle : SADT... zVers la conception objet zUML 3

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

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

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

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. Système Pilotage Système opérationnel Objectifs EntréesSorties Fixe Variables Essentielles 7

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

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 9

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

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 11

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

13 Eléments liés au projet Coût du projetMatériel Logiciel Choix de la méthode => amélioration de la productivité exploitation Maintenance Portabilité UtilisateurNe 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 13

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 14

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 15

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 16

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 17

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 18

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 ) 19

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 20

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 21

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

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. 23

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 24

25 Récapitulation Etude préalable Etude détaillée ss projet 1 Etude détaillée Réalisation Mise en oeuvre 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 ETAPESPRODUCTIONS DES ETAPESDECISIONS (UTILISATEUR) Modification Poursuite / Abandon Accord utilisateur Réception (acceptation déf.) oui non oui 25

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

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 27

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 28

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) 29

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 30

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 31

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 : UniversitéEtudiant Banque Demande d'inscription Carte d'étudiant Chèque Avis de crédit Relevé de compte Avis de débit 32

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 33

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é 34

35 Représentation schématique SALARIEAFFECTE ASERVICE MATRICULE NOMDATE-AFFECTATION N°-SERVICE INTITULE nom entité-typenom relation-type noms propriétés-types identifiant souligné SALARIEAFFECTE ASERVICE A01 DURAND01/02/ B VENTES Exemple d'occurrence 35

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) : Personne est marié à 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 36

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 : enseignant enseigne cursus matière 1,n 0,n 1,n 37

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 38

39 Exemple RG1 Tout enseignant enseigne en principe au moins une matière, mais certains dentre eux peuvent être dispensés denseignement 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 CURSUS ENSEIGNANTENSEIGNE 0,n 1,n 3,n 39

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° INSEEdfNom 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éeab si adfb et aucune partie de a ne détermine b. ex : N°INSEE + NOMdf ADRESSE n'est pas élémentaire Dépendance fonctionelle élémentaire directe si ab et il n'existe pas de c tq adfc et cdfb 40

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 AB 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 41

42 Propriétés de DF Réflexivité adfa Projection adfb+c ==>adfb et adfc Augmentation adfb ==> c : a+cdfb Additivité adfb et adfc ==> adfb+c Transitivité adfb et bdfc ==> adfc Pseudo-transitivité adfb et b+cdfd ==> a+cdfd 42

43 Propriétés de DF - Exemples Réflexivité REF df REF Projection REFdfDESIGN + PU ==>REFdfDESIGN Augmentation REF df PU REFdfPU ==>REF+DESIGNdfb Additivité REFdfDESIGN et REFdfPU ==> REF df DESIGN + PU Transitivité REFdfCODETVA et CODETVAdfTXTVA ==> REF df TXTVA Pseudo-transitivité REFdfCODETVA CODETVA+PUdfTXTVA ==> REF+PU df TXTVA 43

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) 44

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

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 46

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. 47

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 dentités que la relation à décomposer. 48

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 REFDESIGNQTEPUMONTANT TOTAL

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. 50

51 Dictionnaire des données 51

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 quune seule propriété non concaténée Sil 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é) 52

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

54 Etablissement du MCD COMMANDE NOBON DATE REPRESENTANT COREP NOMREP PRODUIT REF DESIGN PU CLIENT COCLI NOMCLI RUCLI VILCLI x QTE 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 54

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

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. 56

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

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. 58

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 59

60 Représentation E1EnE2 E'qE'2E'1 Proposition Logique Actions R1R2Rm E'3 Evènements contributifs Synchronisation (Règles d'activation) Opération Règles d'émission Evènements internes produits 60

61 Consommation des évènements Chaque occurence dun é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. Dossier ouvert Rapport AVANTAPRES Examen Favorable Dé- favorable Dé- favorable Examen Dossie r ouvert Rapport ET Promotion accordée Promotion accordée Promotion refusée Promotion refusée 61

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 62

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

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

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

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

67 Construction du MCT (... fin) 67

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 68

69 Le MOT : Un exemple 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 lun 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 daprè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) 69

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

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

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

73 Exemple (suite) : Le MOT Règles dorganisation RO1-Le service achats et les magasins sont équipés de micro-ordinateurs compatibles pouvant séchanger des disquettes. Le srevice commercial dispose dun 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 dune validation ou de modifications. Ces opérations doivent être faites le matin. RO3-Les comandes validées sont éditées a)dans lordre des fournisseurs concernés pour leur être expédiées b)dans lordre 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 seffectue 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-Linventaire est annuel. Le vendredi soir précédent, il y a édition de latat 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 quun seul produit. 73

74 Procédures Fonctionnelles (PF) 74

75 PF (suite) 75

76 MOT : Les concepts Poste de travail Type de lieu: ensemble des lieus ou les actions dune opération pourront seffectuer Responsable: personne ayant la résponsabilité de certaines actions dune opération Ressources: moyens permettant de résliser certaines actions dune opération (partageable ou non, consomable ou réutilisable) Procédure Fonctionnelle (PF) ensemble ininterruptibe dactions dune opération conceptuelle affécté à un PT Nature: degré dautomatisation (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 dune PF émis : ce qui se passe à lissu de la PF soit dans lunivers extérieur (évt résultat) soit pour être consommé par une PF suivante (évt interne) 76

77 Déscription détaillée dune PF 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 lhomme et la machine Déscription des traitements autromatiques utilisés selon la mature de la PF (manuelle/automatisée) 77

78 Exemple 78

79 Exemple (suite) : description des écrans. Procédure PF9 N°MAGASIN ? 01REAUMUR CRITERES DACCES 1PAR REF 2 PAR DESIGNATION CHOIX ? 1 RM Retour Marchandise client BL Bon Livraison fournisseur AJ Ajustement TYPE DE MOUVEMENT ?... DESIGNATION ? CHEMISE... REFDESIGNPU VENTE X01CHEMISE150 X23CHEMISE120 REF ?X01 TYPE DE MOUVEMENT... REF... DESIGNATION... PU VENTE... QUANTITE ?... N° CDE FOURNISSEUR ?... 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 si accès par réf affichage entrer qte livrée ou stock réel Seulement si BL 79

80 Diagramme de répartition des tâches entre homme et machine HOMMEMACHINEREMARQUES 1 Entrer n° mag2 Afficher libellé Lib magasin. 3 Entrer choix critères Afficher critères daccès Par réf. désign ou FIN 4Afficher types mvts BL bon livr, RM retour march. Ajustement ou FIN 5Entrer choix type mvt 6 Entrer désignation Accès par désign 3 Accès par réf 8 fin session FIN 5 7 Affichage prod ayant cette design 8 Entrer réf du produit FIN 5 Accès réf 9 Affichage type de mvt et produit 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 dinfo 10 Entrer réf du produit 11 Entrer n° Cde à four. BL Autre mvt 86 Accès réf.Accès désign. 80

81 Exemple (suite) 81

82 Autre exemple : la procédure PF12 82

83 Dernier exemple : la procédure PF1 DESCRIPTION DUN ETAT DE SORTIE.PROCEDURE :PF1 TITRE:PROPOSITION DE COMMANDEETAT N° : E01 PROPOSITION N°......DATE DEDITION:../../.. MAGASIN N°.. FOURNISSEUR : CODE:.....NOM: ADRESSE: REFDESIGNATIONQUANTITE A COMMANDER

84 Modèles Externes Chaque traitement possède son modèle externe ou vue externe Cette vue reflète la vision que lutilisateur a des données à travers la procédure Il sagit dun MCD construit spécifiquement pour chaque traitement La phase de validation permettra dajuster vues externes et MCD initial. Notion de blocs logiques dentrée/sortie E1 E2 E1E2R1 E1E2R1 Bloc logique 84

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 85

86 Modèle Externe PF9 Consultation dun pdt Lexamen de la grille décran (T79) relative à laffichage dun 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 dun accès par désignation. La non répétitivité oiblige à modifier le modèle: DESIGN Désign ARTICLE Réf PU CONCERNE 1,n 1,1 on évite ainsi que toutes les désignations du bloc logique soient identiques Accès plus rapide sur le critère désignation 86

87 MEPF9 (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 dun pdt à metttre jour idéntifié par 1)N° magasin 2) 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 dun produit du magasin ANNULATION DUNE COMMANDE ANNULATION N° Cde Réf 87

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

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

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

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

92 ... MCD Validé 92

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 Désign CONCERNE PRODUIT Réf PUVente STOCKAGE MAGASIN N°mag libellé 1,n1,1 0,n Stock stock mini stock max n°casier 93

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 dune entité ou dune relation soit par lidentifiant On doit se demander si on peut sélectionner les bonnes occurences des propriétés auxquelles on accède pb si absence dun 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 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 quelles relient aussi Valider les cardinalités comme pour la consultation 95

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-Sassurer que tte ppté conceptuelle a pu être insérée (et même modifiée ou supprimée sil sagit dune 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. 96

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 limplantation du système, les créations dentités permanentes se feront en premier Exemple Ou encore Nouveau produit Création Produit Toujours Produit inséré Hausse des prix MAJ des prix Toujours Hausse répercutée sur toiuts les produits Processus à intégrer au MOT 97

98 Conclusion Les concepts utilisés MCD BRUT : MCD établi dans labsolu sans préjuger des traitements (Perception du réel) ME ou Vue Externe : Modèle des données «vu» par lutilisateur 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 NIVEAUTRAITEMENTSDONNEES CONCEPTUEL ORGANISATIONEL MCTMCD MCT MCD VALIDE MLD VALIDATION 98

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

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 100

101 CONTEXTE NAVIGATIONNEL Enregistrements esclaves membres Enregistrement maître - propriétaire Relation 1 à plusieurs Ex : Client - Commande Commandes du Client C23 Client C23 Notions importantes: Type denregistrement Occurence denregistrement Type densemble Occurrence dun type densemble 101

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

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

104 E/R Enregistrements/Ensembles MODELE CODASYL Toute entité devient un type denregistrement AB R 1,1 ou 0,1 1,n ou 0,n A AB 1,n ou 0,n 1,n ou 0,n R B AB R A B RR RARB 104

105 Exemple NOM CONCERNE SE COMPOSE DE PASSEE PAR COMMANDECLIENT NOCDE, DATECODE, ADRESSE 1,n 1,1 0,n1,1 1,n 0,n PRODUIT REF, DESIGN, PU 105

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

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

108 1- Toute entité devient un fichier (lidentifiant de lentité 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,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 Fichier PASSE COMMANDECLIENT N°cde,dateCode-cli, nom 0,n1,1 Fichier maître Fichier esclave Fichier CLIENT Code-cli, nom Fichier COMMANDE N°cde, codecli, date clé du fichier maître CLIENT COMMANDE 108

109 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 : Fichier (suite) SE COMPOSE DE COMMANDEPRODUIT N°cde,dateRéf, désign, PU 0,n1,n QTE COMMANDEPRODUIT N°cde,dateRéf, désign, PU LIGNE-COMMANDE N°Cde, Réf, qté 109

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 doocurences) Exemple : VOYAGE(NOVOYAGE, VILLE-DEPART,VILLE-ARRIVEE) CONSTITUANTSNOVOYAGEVILLE-DEPARTVILLE-ARRIVEE OOCURENCES Occurence 1IT25PARISNICE Occurence 2IT27NICEPARIS Occurence 3IT33LYONPARIS} 3-UPLE Occurence 4IT47PARISLYON CONSTITUANT card.:4, deg.:3, doms.: NOVOYAGE = (IT25, IT27, IT33, IT47) et VILLE=(PARIS, LYON, NICE) Autres Concepts : Dépendences foctionnelles, clé dune relation, formes normales 110

111 Opérateur de lalgè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 lutil. -puissants langages de manip° et dinterrogation (algèbre rel. /calcul des prédicats) -Dé«finition des données par descr° du MLD relationnel (SUITE) 111

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

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

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

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

116 La démarche MERISE (fin) Etude technique Cahier des charges de réalisation Programmation PROG1PROG2PROG1PROG2PROG3 Mise en oeuvre Maintenance Manuel dutilisation, consignes 116

117 LEtude détaillée 1-Etude générale du MOT futur : Tableau des PF, Diagramme denchainemlent 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 decran (a faire aprouver par les utilisateursconcernées), Grilles de contrôles, Fiche de répartition des tâches entre lhomme 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 117


Télécharger ppt "Conception des Systèmes d'Information Tassadit Amghar Frédéric Saubion."

Présentations similaires


Annonces Google