la modélisation des systèmes d’information en utilisant merise et uml

69
1 1. Objectif du cours Initier les étudiants à la modélisation des Systèmes d’Informat en utilisant Merise et UML. Structuration de la démarche informatique, Méthodes d’analyse et de conception, Méthodes de modélisation, Assimiler les caractéristiques et les concepts de l’approche objet, Apprentissage des concepts de l’approche objet et de la méthode UML Quelques méthodes : MERISE, MERISE/2 SADT (Structured - Analysis - Désign - Technique ) SART (Structured - Analysis - Real - Time) OMT (Object Modeling Technique) UML ( bien que UML n'est pas une méthode mais un langage de modélisation unifiée ) 2. Contenu du cours 1.1 - Introduction

Upload: frees

Post on 10-Jun-2015

5.086 views

Category:

Documents


3 download

DESCRIPTION

* Structuration de la démarche informatique, * Méthodes d’analyse et de conception, * Méthodes de modélisation, * Assimiler les caractéristiques et les concepts de l’approche objet,* Apprentissage des concepts de l’approche objet et de la méthode UML

TRANSCRIPT

Page 1: la modélisation des Systèmes d’Information en utilisant Merise et UML

1

1. Objectif du cours

Initier les étudiants à la modélisation des Systèmes d’Information en utilisant Merise et UML.

Structuration de la démarche informatique, Méthodes d’analyse et de conception, Méthodes de modélisation, Assimiler les caractéristiques et les concepts de l’approche objet, Apprentissage des concepts de l’approche objet et de la méthode UML

Quelques méthodes :

 MERISE, MERISE/2 SADT (Structured - Analysis - Désign - Technique ) SART (Structured - Analysis - Real - Time) OMT (Object Modeling Technique) UML ( bien que UML n'est pas une méthode mais un langage de modélisation unifiée )

2. Contenu du cours

1.1 - Introduction

Page 2: la modélisation des Systèmes d’Information en utilisant Merise et UML

2

1. Introduction1. Objectif du cours2. Le contenu du cours3. A quoi sert une méthode4. Des méthodes fonctionnelles aux méthodes objet

2. Merise1. Vue d’ensemble de la démarche2. Le M.C.D (Modèle conceptuel de données)3. Le M.C.T (Modèle conceptuel de traitements)4. Le M.O.T (Modèle organisationnel de traitements)5. Le M.L.D (Modèle logique de données)

3. UML1. Qu’est-ce que UML ?2. Modes d’utilisation d’UML3. Historique d’UML4. Notation et Méta modèles

4. Les concepts de l’approche par l’objet1. L’objet2. L’encapsulation3. Spécialisation et généralisation4. L’héritage5. Classes abstraites et concrètes6. Le polymorphisme7. La composition

1.2 - Introduction

Page 3: la modélisation des Systèmes d’Information en utilisant Merise et UML

3

5. Diagrammes UML1. Le diagramme de cas d’utilisation

2. Le diagramme de classe

3. Le diagramme d’objet

4. Le diagramme de composants

5. Le diagramme de déploiement

6. Le diagramme d’états

7. Le diagramme d’activités

8. Le diagramme de collaboration

9. Le diagramme de séquence

1.2 - Introduction

Page 4: la modélisation des Systèmes d’Information en utilisant Merise et UML

4

3. A quoi sert une méthodeUne méthode définit une démarche reproductible qui produit des résultats fiables.

Une méthode d’élaboration de logiciels décrit comment modéliser et construire des systèmes logiciels de manière fiable et reproductible.

De manière générale, une méthode définit : Des éléments de modélisation, Une représentation graphique, Du savoir-faire et des règles

Avec, en autre, les objectifs suivants : Se donner toutes les chances de mener à bien un projet informatique, Établir un plan projet réaliste en définissant, estimant et planifiant les moyens à mettre en œuvre, Maîtriser le projet en mesurant son avancement et les écarts éventuels avec les engagements pris, S'assurer que la qualité définie est respectée.

Et une évidence :Le système d'information des entreprises actuelles est devenu l'un des principaux piliers sur lesquels repose l'ensemble de l'activité.

Impossible donc de traiter ce domaine de manière approximative.

1.3 - Introduction

Page 5: la modélisation des Systèmes d’Information en utilisant Merise et UML

5

4. Des méthodes fonctionnelles aux méthodes objetUne évolution des méthodes qui s’est toujours faite de la programmation vers l’analyse :

Les premières méthodes d'analyse (années 70)Découpe fonctionnelle (fonctionnelle et hiérarchique) d'un système.

L'approche systémique (années 80)Modélisation des données + modélisation des traitements (Merise, Axial, ..).

L'émergence des méthodes objet (1990-1995)

Prise de conscience de l'importance d'une méthode spécifiquement objet :comment structurer un système sans centrer l'analyse uniquement sur les données ou uniquement sur les traitements (mais sur les deux) ?

Plus de 50 méthodes objet sont apparues durant cette période (Booch, Classe-Relation, Fusion, HOOD, OMT, OOA, OOD, OOM, OOSE...) !

Aucune méthode ne s'est réellement imposée.

1.4 - Introduction

AnalyseConceptionProgrammation

Page 6: la modélisation des Systèmes d’Information en utilisant Merise et UML

6

4. Des méthodes fonctionnelles aux méthodes objet (suite) :

Les premiers consensus (1995) OMT (Object Modeling Technique - James Rumbaugh) - Méthode d'analyse et de conception orientée objet. Vues statiques, dynamiques et fonctionnelles d'un système.

OOD (Object Oriented Design - Grady Booch). Vues logiques et physiques du système.

OOSE (Object Oriented Software Engineering - Ivar Jacobson). Couvre tout le cycle de développement. Une des plus anciennes méthodes objet focalisée sur le modèle statistique. 

L'unification et la normalisation des méthodes (1995-1997) UML (Unified Modeling Language) est né de la fusion de ces 3 méthodes qui ont le plus influencé la modélisation objet au milieu des années 90

Fin 1997, UML devient une norme OMG (Object Management Group). L'OMG est un organisme à but non lucratif, créé en 1989 à l'initiative de grandes sociétés (HP, Sun, Unisys, American Airlines, Philips...). Son rôle est de promouvoir des standards qui garantissent l'interopérabilité entre applications orientées objet, développées sur des réseaux hétérogènes.

1.4 - Introduction

Page 7: la modélisation des Systèmes d’Information en utilisant Merise et UML

7

Vue d’ensemble de la démarche Merise(Méthode d’Étude et Réalisation Informatique pour les Systèmes de l’Entreprise)

2.1 – Vue d’ensemble - Merise

Page 8: la modélisation des Systèmes d’Information en utilisant Merise et UML

8

1. Vue d’ensemble de la démarcheQu’est ce que Merise ?Création : 1978-1979

Plus qu’une méthode d’analyse informatique, une démarche de construction des Systèmes d’information.

A quoi sert Merise ? En ce qui concerne les données : A identifier le nombre et la nature des tables, les articulations et la ventilation des informations entre ces tables, afin que l'ensemble soit le plus efficace et évolutif possible,

Pour les traitements : A identifier les fonctionnalités selon une approche "top / down" ("du général au particulier"), leur découpages et leurs enchaînements.

Merise est un travail d'anticipation : Elle sert à préparer les développements informatiques et à chiffrer (en coût, en temps et en énergie) ces chantiers, quelle que soit leur échelle.

L'approche Merise n'est en rien réservée aux méga-projets !

2.1 – Vue d’ensemble - Merise

Page 9: la modélisation des Systèmes d’Information en utilisant Merise et UML

9

2.1 – Vue d’ensemble - Merise

La démarche :Merise définit la réalité dont elle prend en compte comme la résultante d'une progression, menée de front, selon trois axes, qualifiés de "cycles".

Page 10: la modélisation des Systèmes d’Information en utilisant Merise et UML

10

2.1 – Vue d’ensemble - Merise

Les niveaux d’abstractionIl y a 3 niveaux d’abstraction :

1. Le niveau conceptuel2. Le niveau organisationnel3. Le niveau physique 1. Le niveau conceptuel :Il consiste à répondre à la question QUOI ?Quoi faire, avec quelles données ?A ce niveau, on ne se préoccupe pas de l’organisation du travail ni du matériel utilisé.

Les deux modèles sont le Modèle conceptuel des données (MCD) et le Modèle conceptuel des traitements (MCT).

2. Le niveau organisationnel :Il consiste à répondre à la question QUI ?, OU ?, QUAND ?C’est à ce niveau que sont intégrés les critères d’organisation de travail.On tient compte (ou on propose) des choix d’organisation de travail comme la répartition des traitements entre l’homme et la machine, le mode de fonctionnement (temps réel, temps différé).

Le modèle de représentation est le modèle organisationnel des traitements.

Page 11: la modélisation des Systèmes d’Information en utilisant Merise et UML

11

2.1 – Vue d’ensemble - Merise

Objectifs de cette décomposition :

procéder de manière progressive, distinguer le quoi (plutôt stable) du comment organisationnel et technique (plutôt instable), ne prendre en compte qu'une classe de problèmes à chaque niveau.

Niveau Données Traitements Choix pris en compte

Conceptuel

Modèle Conceptuel des Données(MCD)Signification des informations sans contrainte technique ou économique

Modèle Conceptuel des Traitements(MCD)Activite du domaine sans préciser les ressources ou leur organisation

Choix de gestionQuoi ?

Organisationnel

Modèle Organisationnel des Données(MOD)Signification des informations avec contrainte organisationnelles et économique

Modèle Organisationnel des Traitements(MOT)Fonctionnement du domaine avec les ressources utilisées

Choix d'organisationQui ?, Ou ?, Quand ?

Physique

Modèle Physique des Données(MPD)Description de la ou des bases de données dans la syntaxe du logiciel SGF ou SGBD

Modèle Physique des Traitements(MPT)Architecture technique des programmes

Choix techniqueComment ?

Page 12: la modélisation des Systèmes d’Information en utilisant Merise et UML

12

2.1 – Vue d’ensemble - Merise

1er axe : Maîtrise de la chronologie des opérations (Cycle de vie)Succession de phases contrôlables par l’organisation (planning, échéances, moyens humains, etc.)

Il comporte 4 étapes :

Schéma directeur : il s’agit de la traduction de la stratégie de l’entreprise.La réalisation d’un schéma directeur répond à un objectif principal : adapter l’organisation et les moyens de traitement de l’information aux axes stratégiques de l’entreprise.Il a pour objet de :

clarifier les centres d'intérêt, les pôles de décision, donner une première idée de la chronologie des évènements

Étude préalable : Ce document doit permettre une première mesure de l'impact financier et administratif des grandes orientations définies dans le schéma directeur.

Il comporte : L'étude de l'existant La définition du "Quoi ?" futur ("MCD" et "MCT") Le scénario (coût, impact sur l'organisation etc.) Le graphe de circulation de l'information pour les procédures les plus

représentatives. Une première approximation quant aux choix de matériels et de logiciels,

ainsi qu'une estimation du volume de l'information qui sera traitée.

Page 13: la modélisation des Systèmes d’Information en utilisant Merise et UML

13

2.1 – Vue d’ensemble - Merise

1er axe : Maîtrise de la chronologie des opérations (Cycle de vie) – suite

L'étude détaillée : La définition du "Qui ?", du "Où ?" et du "Quand ? ». C'est-à-dire la "vision utilisateurs"(soit les MOT et MLD).

Son but : décrire de façon exhaustive l’application qui devra être développée, c’est-à-dire les interfaces graphiques, les traitements et les états imprimés. Elle se présente sous la forme d'un descriptif précis portant sur les données en amont et en aval de chaque opération, et sur le mode de traitement de chacune de ces opérations. Elle débouche sur un dossier de spécifications détaillées.

L'étude technique : Les données sont réajustées et stabilisées, l'essentiel des traitements (les algorithmes fondamentaux) est décrit.

C’est seulement à ce stade qu’est censée commencer la réalisation.La réalisation concerne la production du code informatique correspondant aux spécifications définies dans l’étude détaillée. Elle débouche sur un dossier de réalisation.

Page 14: la modélisation des Systèmes d’Information en utilisant Merise et UML

14

2.1 – Vue d’ensemble - Merise

2ème axe : Fixation de jalon de validation (Cycle de décision)Le terme de jalon est utilisé pour désigner les événements sensibles de la réalisation du projet nécessitant un contrôle. Chaque jalon permet de vérifier que les conditions nécessaires à la poursuite du projet sont réunies.

Importance de la Méthode mise sur un échéancier de rencontres entre :o Les responsables des différents pôles de l’entreprise,o Les utilisateurs

On désigne par le terme d'échéancier (éventuellement jalonnement) l'enchaînement des dates des jalons.

Objectifs des jalons : o Faire prendre conscience de la charge de travailo Des difficultés relationnelles que supposent une collaboration, une compréhension et une implication dans un processus de décision

Page 15: la modélisation des Systèmes d’Information en utilisant Merise et UML

15

2.1 – Vue d’ensemble - Merise

3ème axe : Dissociation des données et des traitements et l’étude de leurs interactions (Cycle d’abstraction)

Page 16: la modélisation des Systèmes d’Information en utilisant Merise et UML

16

2.1 – Vue d’ensemble - Merise

3ème axe : Dissociation des données et des traitements et l’étude de leurs interactions (Cycle d’abstraction) - suiteIl s’agit d’un déroulement de données / traitements, selon 3 niveaux correspondant à trois groupes de questions :

Le "niveau conceptuel" (le "Quoi ?"), aboutissant aux M.C.D. ("Modèle conceptuel des données") et M.C.T. ("Modèle conceptuel des traitements"). A ce stade, données et traitements sont étudiés de manière parallèle, dissociée.

Le "niveau logique" (pour les données) et le "niveau organisationnel" (pour les traitements) (le "Qui?", le "Quand ?", le "Où ?") correspondants aux M.O.T ("modèle organisationnel des traitements") et M.L.D. ("Modèle logique des données").

Le "niveau physique" (pour les données) aboutissant à la création des tables, et le "niveau opérationnel" (pour les traitements) enclenchant analyse détaillée de chaque traitement, et développements.

Page 17: la modélisation des Systèmes d’Information en utilisant Merise et UML

17

2.2 – M.C.D - Merise

Le M.C.D (Modèle conceptuel de données)

Page 18: la modélisation des Systèmes d’Information en utilisant Merise et UML

18

2.2 – M.C.D - Merise

2. Le M.C.D (Modèle conceptuel de données)Représentation statique, sous forme schématique, de la situation respective des données d'un domaine de gestion. Ce schéma est conçu pour être très stable dans le temps.

Son objectif : définir (identifier) toutes les données utilisées, les regrouper en ensembles appelés entités, et de lier ces entités par des relations, dans un modèle définit et compréhensible par toute personne connaissant la "syntaxe" du MCD. Le MCD regroupe les informations à traiter, le "quoi" du système.

Les étapes du MCD :1. Catalogue des données2. Épuration (polysèmes et synonymes)3. Détermination des entités4. Détermination et affectation des propriétés5. Recensement des associations (avec, éventuellement, les propriétés non encore affectées6. Détermination des cardinalités

Page 19: la modélisation des Systèmes d’Information en utilisant Merise et UML

19

2.2 – M.C.D - Merise

Entité :Représentation d'un objet réel, ayant une existence et une raison d'être dans le système d'information.

Page 20: la modélisation des Systèmes d’Information en utilisant Merise et UML

20

2.2 – M.C.D - Merise

Entité : Une entité est pourvue d’une existence propre et est conforme aux choix de gestion de l’entreprise. Une entité peut être un acteur : client, usine, produit => pourvue d’une existence intrinsèque. Une entité peut être un flux : commande, livraison => existe par l’intermédiaire d’acteurs.

Les propriétés :Une propriété est une donnée élémentaire qui qualifie l’entité à laquelle elle se rapporte : Chaque propriété prend des valeurs qui sont appelées occurrences de la propriété, Chaque propriété a un domaine de définition (ensemble de valeurs possibles), Chaque propriété se rattache toujours à une entité.

Identification d’une Entité :C’est une propriété (ou ensemble de propriétés) particulière qui permet d’identifier de façon unique une occurrence de l’entité. Pour être identifiant, la ou le groupe de propriétés ne doit pas prendre plusieurs fois la même valeur sur l’ensemble des occurrences de l’entité. L’identifiant figure en premier dans la liste des propriétés Il est souligné

Page 21: la modélisation des Systèmes d’Information en utilisant Merise et UML

21

2.2 – M.C.D - Merise

Association (ou Relation)Objet permettant d'associer deux ou plusieurs entités. Ce lien est nommé et est, par convention, très souvent un verbe à l'infinitif.

ex : entre deux entités, Personne et Ordinateur, une relation nommée Posséder peut être mise, et on lit "une personne possède un ordinateur" et, dans l'autre sens, 'un ordinateur est possédé par une personne".

Page 22: la modélisation des Systèmes d’Information en utilisant Merise et UML

22

2.2 – M.C.D - Merise

Association (ou Relation) - suiteex : entre deux entités, Ouvrage et Auteur, une relation nommée Écrire peut être mise, et on lit "un Auteur a écrit un Ouvrage" et, dans l'autre sens, 'un Ouvrage est écrit par un Auteur".

Page 23: la modélisation des Systèmes d’Information en utilisant Merise et UML

23

2.2 – M.C.D - Merise

Cardinalité d’une AssociationC'est le nombre d'occurrences, minimal et maximal, d'une association par rapport à chaque occurrence d'une entité donnée. D'une entité donnée vers une association donnée.

Page 24: la modélisation des Systèmes d’Information en utilisant Merise et UML

24

2.2 – M.C.D - Merise

Ex1 :

Ex2 :

Ex 3 :

Un employé a une et une seule société. Une société a 1 ou n employés.

Une commande est composée de 1 ou n produits distincts en certaine quantité. Un produit est présent dans 0 ou n commandes en certaine quantité.

Un étudiant parle une ou plusieurs langues avec un niveau. Chaque langue est donc parlée par 0 ou n étudiants avec un niveau. Pour chaque niveau, il y a 0 ou plusieurs étudiants qui parlent une langue.

1,1 1,nEmployé a Société

1,n 0,nCommande compose

quantité Entier

Produit

1,n

0,n

0,n

Etudiant parle

Langue

Niveau

Page 25: la modélisation des Systèmes d’Information en utilisant Merise et UML

25

2.2 – M.C.D - Merise

0,n

0,n

0,n

0,n

1,n

0,n

0,n

0,n

1,1

0,n

OUVRAGE AUTEUR

EDITEURLIBRAIRIE

TYPE

écrit

édite

quantité Entier

stocke

quantité Entier

vend

quantité Entier

appartient

Une centrale d’achat : les cardinalités

Page 26: la modélisation des Systèmes d’Information en utilisant Merise et UML

26

2.2 – M.C.D - Merise

Cas des associations de dimension "1" (dites "réflexives") :

Cas des associations de dimension "3"

Page 27: la modélisation des Systèmes d’Information en utilisant Merise et UML

27

2.2 – M.C.D - Merise

Modéliser les données, comment ? La méthode de structuration des données proposée repose sur le modèle Entité/Relation, qui est censée dégager des ensembles de données et des relations de sens qu’entretiennent ces ensembles, Le modèle conceptuel de données est une relation simplifiée de la réalité, Son objet est de mettre en lumière les caractéristiques essentielles du système d’information observé, Une fois le modèle établi et validé par rapport à la réalité observée, il existe des règles permettant de le transformer en fichiers ou en bases de données.

La modélisation obéit à 2 approches différentes : L’une, plutôt intuitive, relève de la conception et repose sur la vision que se fait le concepteur de son système d’information, L’autre répond à des règles formelles permettant de valider le modèle obtenu : est-il bien formé ? Permet-il d’obtenir les résultats souhaités ?

Mais comment résoudre le problème ?

La manière la plus aisée de commencer la conception consiste à travailler sur 3 plans : lister les résultats souhaités, relever les données élémentaires nécessaires aux traitements, noter les contraintes sur les données.

Page 28: la modélisation des Systèmes d’Information en utilisant Merise et UML

28

2.2 – M.C.D - Merise

Voici un cas concret :Une entreprise X vend des véhicules toutes marques qu’elle stocke dans de grands entrepôts. Dans un même entrepôt, nous pouvons trouver plusieurs marques de véhicules, cependant, pour des raisons de logistiques, le gérant de la société X a exigé de ses employés qu’une marque ne puisse se trouver que dans un seul entrepôt. Chaque attaché commercial gère son propre portefeuille de clients. L’entreprise X souhaite établir des statistiques commerciales sur ses ventes de véhicules : nombre de véhicules achetés par un client, chiffre d’affaire réalisé par une marque, mais aussi sur les marques entreposées dans un entrepôt.

Objet :

Vente de véhicules toute marque

Application :

Statistiques commerciales

Résultats attendus :

Nombre de véhicules achetés par un client ?

Chiffre d’affaire réalisé par une marque ?

Quelles sont les marques entreposées dans un entrepôt ?

Page 29: la modélisation des Systèmes d’Information en utilisant Merise et UML

29

2.2 – M.C.D - Merise

Données :

Nom de marque

Nom de dépôt

Nom du type

Puissance fiscale

Nom du responsable commercial pour une marque

Prix unitaire d’un type de véhicule

Adresse de dépôt

Nom, adresse du client

Quantité d’une vente

Date d’une vente

Nom de l’attaché commercial

Adresse de l’attaché commercial

Contraintes sur les données :

Un dépôt peut-être multi-marques,

Une marque ne se trouve que dans un seul entrepôt,

Un attaché gère plusieurs clients,

Un client est géré par un seul attaché

Page 30: la modélisation des Systèmes d’Information en utilisant Merise et UML

30

2.2 – M.C.D - Merise

1. Repérer les entités :

Les entités sont les objets de gestion essentiels du système d’information.

L’entité est une ensemble dont chaque élément est un élément particulier.

Dans notre exemple, que gère t-on ?

En première lecture, 3 entités ressortent :

1. Les types de véhicule,

2. Les clients,

3. Les dépôts.

2. Attribuer à chaque entité son identifiant et ses propriétés :

Chacune de ces entités possède des caractéristiques, qui sont appelées propriétés :

Une propriété ne doit figurer qu’à un seul endroit du modèle,

Elle doit être significative

Parmi ces propriétés, il peut y en avoir une ou plusieurs qui permettent de définir sans ambiguïté un élément parmi l’ensemble des éléments : l’identifiant.

L’identifiant sert à désigner sans ambiguïté une occurrence de l’entité.

Comment allons-nous construire l’entité TYPE DE VEHICULE ?

Identifiant : Nom du type

Propriétés : Prix

Puissance fiscale

Nom de marque

Page 31: la modélisation des Systèmes d’Information en utilisant Merise et UML

31

2.2 – M.C.D - Merise

2. Attribuer à chaque entité son identifiant et ses propriétés :

Il faut alors vérifier qu’à toute valeur prise par l’identifiant ne correspond qu’une valeur de chaque propriété. Nous appelons cette règle : la règle d’énumération.

Ici, pour une valeur prise par un nom de type (identifiant), nous n’avons qu’une valeur de puissance fiscale.

Identifiant : Nom de dépôt

Propriétés : Adresse de dépôt

Constituons l’entité DEPOT :

Pour l’entité CLIENT, il est légitime de modéliser :

Identifiant : Code client

Propriétés : Nom du client

Adresse du client

Nom attaché commercial

Adresse attaché

Page 32: la modélisation des Systèmes d’Information en utilisant Merise et UML

32

2.2 – M.C.D - Merise

2. Attribuer à chaque entité son identifiant et ses propriétés :

Il faut ensuite vérifier toutes les propriétés d’une entité dépendent directement de l’identifiant. Nous appelons cette règle : la règle de dépendance directe.

Pour l’entité CLIENT, il convient donc de se poser la question suivante :

L’adresse de l’attaché commercial est-elle une propriété du client ou de l’attaché commercial ?

Il convient donc de modéliser ainsi :

Entité : CLIENT ATTACHE

Identifiant : Code Client Nom de l’attaché commercial

Propriétés : Nom du client Adresse de l’attaché commercial

Adresse du client

Page 33: la modélisation des Systèmes d’Information en utilisant Merise et UML

33

2.2 – M.C.D - Merise

2. Attribuer à chaque entité son identifiant et ses propriétés :

Pour l’entité TYPE DE VEHICULE, nous avons défini une propriété Nom de marque. Cependant, le responsable commercial est dépendant de la marque. MARQUE est donc une entité cachée.

Il convient donc de modéliser ainsi :

Entité : MARQUE TYPE DE VEHICULE

Identifiant : Nom de marque Nom du type

Propriétés : Responsable commercial Prix

Puissance fiscale

3. Définition des relations entre les Entités et cardinalité :

Relation entre MARQUE et DEPOT :

Page 34: la modélisation des Systèmes d’Information en utilisant Merise et UML

34

2.2 – M.C.D - Merise

3. Définition des relations entre les Entités et cardinalité :

Relation entre MARQUE et DEPOT :

(1,1) : Une marque est entreposée dans un seul entrepôt.

(1,N) : Dans un entrepôt sont entreposées une ou plusieurs marques.

Page 35: la modélisation des Systèmes d’Information en utilisant Merise et UML

35

2.2 – M.C.D - Merise

3. Dépendances fonctionnelles entre Entités (DF) :

La relation qui lie un TYPE DE VEHICULE à une MARQUE est «appartenir». Il s’agit d’une relation hiérarchique : à un type de véhicule donné ne correspond qu’une seule marque, et à une marque correspond plusieurs type de véhicule. Ici, TYPE DE VEHICULE détermine totalement MARQUE.

Nous appelons cette relation fonctionnelle (DF), et elle se note de la manière suivante :

TYPE DE VEHICULE -> MARQUE

Qu’en est-il de ATTACHE COMMERCIAL et de CLIENT ?

CLIENT -> ATTACHE COMMERCIAL(A un client ne correspond qu’un attaché commercial)

Page 36: la modélisation des Systèmes d’Information en utilisant Merise et UML

36

2.2 – M.C.D - Merise

4. Relations entre 3 Entités :

Regardons à présent le problème des quantités élémentaires de ventes.

Cette données est une propriété de la relation « vendre », liant CLIENT et TYPE DE VEHICULE : la quantité ne prend de sens que si l’on connaît conjointement le client et le type.

Cependant, pour qu’il n’y ait qu’une seule occurrence de quantité, il est nécessaire d’introduire un «  chronomètre » dans notre système d’information :

Page 37: la modélisation des Systèmes d’Information en utilisant Merise et UML

37

2.2 – M.C.D - Merise

4. Relations entre 3 Entités :

Les cardinalités se lisent alors :

Pour un type de véhicule, il peut y avoir de 0 à N relations « vendre », autrement dit il peut y avoir plusieurs ventes pour un même type de véhicule,

Pour un client, il peut y avoir 0 à N relations « vendre », en d’autres termes, il peut y avoir plusieurs ventes pour un même client.

A une date, il peut y avoir 0 à N relations « vendre ». Ce qui se traduit par : certains jours, il y a plusieurs ventes.

A une occurrence de la relation « vendre » correspond un triplet (MARQUE, CLIENT, DATE) et un seul.

Page 38: la modélisation des Systèmes d’Information en utilisant Merise et UML

38

2.2 – M.C.D - Merise

5. Vérifier la règle de pleine dépendance :

Les propriétés d’un relation doivent dépendre de la totalité des entités qu’elle relie.

Pour chaque propriété d’une relation, toutes les entités liées par la relation doivent servir à son identification.

Exemple :

Supposons que nous ayons à gérer des taux de remise dépendant à la fois du TYPE DE VEHICULE et du CLIENT, il serait erroné de faire figurer ce taux de remise dans la relation « vendre », puisque ce taux ne dépend pas de DATE. Il conviendrait dans ce cas de créer une nouvelle relation « a pour remise ».

De plus, on serait conduit à une grande redondance d’information, puisque l’on stockerait plusieurs fois un même taux de remise.

6. Synthèse et compléments :

1. Vérifier si le modèle est bien construit :

a. Contrôler l ’ensemble du modèle en vérifiant que chaque propriété se trouve en un seul endroit du modèle.

b. Contrôler chaque Entité en vérifiant :

Que chaque Entité possède un identifiant,

Que chaque propriété est significative,

La règle d’énumération,

La règle de dépendance directe

Page 39: la modélisation des Systèmes d’Information en utilisant Merise et UML

39

2.2 – M.C.D - Merise

6. Synthèse et compléments :

c. Contrôler chaque relation en vérifiant :

Q’une occurrence de relation ne lie qu’une et une seule occurrence de chacune des Entités qu’elle relie,

La règle d’énumération

Que chaque propriétés portée par une relation dépend de la totalité des entités qu’elle relie (règle de dépendance).

2. Vérifier si le modèle est capable de produire les résultats attendus.

Page 40: la modélisation des Systèmes d’Information en utilisant Merise et UML

40

2.3 – M.C.T - Merise

Le M.C.T (Modèle conceptuel de traitements)

Page 41: la modélisation des Systèmes d’Information en utilisant Merise et UML

41

2.3 – M.C.T - Merise

3. Le M.C.T (Modèle conceptuel de traitements)Représentation, sous forme schématique, de phénomènes de réactions du type et ceci indépendamment de toute préoccupation d'organisation interne :

Évènement déclenchant -> Transformation du système d'information -> Résultat

Implication du monde extérieur au niveau de chaque opération : Soit au niveau des évènements déclenchant Soit au niveau des résultats

Les étapes du MCT :1. Identification des acteurs (Rappel : il s'agit des acteurs extérieurs à l'entreprise).

2. Identification et classement chronologique des flux.

3. Construction du M.C.T.

4. Description détaillée des règles de gestion.

Page 42: la modélisation des Systèmes d’Information en utilisant Merise et UML

42

2.3 – M.C.T - Merise

Processus :Définition :

Ensemble structuré d’événements, opérations et résultats consécutifs qui concourent à un même but.

Il représente généralement un sous ensemble d ’activités de l ’organisation dont les événements initiaux et les résultats finaux délimitent un état stable du domaine.

Il est en général caractéristique du secteur d ’activité de l ’organisation et constitue de ce fait un invariant pour le concepteur.

Exemple : Processus prêt

Ensemble des opérations consécutives à la demande de prêt : Élaboration devis, Instruction d ’un dossier de prêt, Mise en place du prêt.

Page 43: la modélisation des Systèmes d’Information en utilisant Merise et UML

43

2.3 – M.C.T - Merise

Demande de prêt

Demande de prêt DEVIS

ET

DEVIS

PROPOSITIONElaboration de la

proposition

Demande Client

DEVISElaboration du devis

Demande Client

PROPOSITIONElaboration du devis

Elaboration de la proposition

Exemple : Processus prêt

Page 44: la modélisation des Systèmes d’Information en utilisant Merise et UML

44

2.3 – M.C.T - Merise

Exemple : Processus prêt

Page 45: la modélisation des Systèmes d’Information en utilisant Merise et UML

45

2.3 – M.C.T - Merise

Les relations entre "acteurs" peut être traduit soit par un "graphe des flux" soit par une "matrice des flux".

Exemple : Processus prêt

CLIENT BANQUE BDF DGI

CLIENTDemande du

client

BANQUE Accord ou RefusDemande de

renseignements

Déclaration ouverture de

compte

BDF Réponse BDF

DGI

MATRICE DES FLUX

Page 46: la modélisation des Systèmes d’Information en utilisant Merise et UML

46

2.3 – M.C.T - Merise

• Evènement Collection de faits, suceptibles de déclencher une Opération dans les conditions précisées par la Synchronisation.

• Synchronisation Condition booléenne traduisant les règles d'activation d'une opération.

• Opération Ensemble d'actions dont l'enchaînement ininterruptible n'est conditionné par l'attente d'aucun évènement autre que le déclencheur initial.

• Règles d'émissionCondition traduisant les règles de gestion, à laquelle est soumise l'émission des résultats d'une opération.

• Résultats Collection de faits, produits par l‘Opération, dans les conditions prévues par la (ou les) "règles d'émission".

Exemple : Processus prêt

Page 47: la modélisation des Systèmes d’Information en utilisant Merise et UML

47

2.3 – M.C.T - Merise

Exemple : Processus prêt

Page 48: la modélisation des Systèmes d’Information en utilisant Merise et UML

48

2.4 – M.O.T - Merise

Le M.O.T (Modèle Organisationnel de Traitements)

Page 49: la modélisation des Systèmes d’Information en utilisant Merise et UML

49

2.4 – M.O.T - Merise

Le MOT a pour objectif de représenter les traitements en prenant en compte les choix et les contraintes liées à l’organisation.

La modélisation s’effectue en faisant abstraction du COMMENT faire technologique.

Qui est qui ? Qui fait quoi ? Analyse des postes de travail. Partage des traitements entre l’homme et la machine. Type d’individu qui réalisera les traitements.

Quand ? Influence du temps et comment structurer les traitements en

conséquence.

Où ? Comment les traitements sont-ils organisés dans l’espace ?

Page 50: la modélisation des Systèmes d’Information en utilisant Merise et UML

50

2.4 – M.O.T - Merise

Le MOT se concentre sur le COMMENT : Définition des différentes ressources à mettre en œuvre (moyens

techniques ou humains, espace, temps, données) Décomposition des opérations spécifiées au niveau conceptuel en

des éléments plus fins et homogènes, les tâches Organisation de l’ensemble des ressources permettant d’assurer

l’exécution des tâches envisagées

Il s’agit ici de : spécifier le contenu de chaque opération conceptuelle, construire une ou plusieurs solutions organisationnelles

La difficulté réside dans la diversité des solutions d’organisation envisageables

Page 51: la modélisation des Systèmes d’Information en utilisant Merise et UML

51

2.4 – M.O.T - Merise

Formalisme du MOT :

Le MOT reprend les concepts du MCT, parfois réadaptés, auxquels sont ajoutés de nouveaux concepts tels que :

le poste de travail : entité physique comprenant des ressources sur un lieu donné et un responsable.

la tâche/opération : affectation des traitements d’une opération conceptuelle à une unité organisationnelle de type site ou service.

la procédure organisationnelle : enchaînement de traitements (tâches et/ou phases) affectés à un ou plusieurs sites ou services au sein d’un même processus.

Le MOT cerne l'activité de chaque poste de travail (informatique ou non), et de chaque service, en tenant compte du "planning", du type de ressources (manuel, automatisé), du type de support (document écrit, magnétique etc.)

MOT = MCT + lieu + moment + nature

Lieu : qui exécute ? Acteurs. Moment : Quand exécute t-on l’opération ? Agencement temporel. Nature : Manuelle, Automatique, Interactive

Page 52: la modélisation des Systèmes d’Information en utilisant Merise et UML

52

2.4 – M.O.T - Merise

Construction du MOT :

Faire le choix des postes, en spécifiant les ressources humaines et informatiques

Décomposer chaque opération conceptuelle en opérations organisées, les ordonner, les affecter aux postes, préciser les différentes caractéristiques (degré d’automatisation, délai de réponse, mode de travail)

S’assurer de la faisabilité des opérations organisées par rapport aux ressources composant le poste

Préciser les différentes phases Évaluer l’ergonomie générale de chaque poste de travail par rapport à

l’ensemble des phases à assurer Envisager des solutions alternatives: variantes de procédures

Page 53: la modélisation des Systèmes d’Information en utilisant Merise et UML

53

2.4 – M.O.T - Merise

Partenaire Poste 1 Poste 2 Poste 3 Partenaire

Un MOT analyse les réactions des postes de travail à un message externe

Message externe enclanchant

Procédure décomposée en opérations et par poste de travail

Page 54: la modélisation des Systèmes d’Information en utilisant Merise et UML

54

2.4 – M.O.T – Merise

Temps Poste 1 Poste 2 Poste 3 Partenaire

Il est possible de représenter le temps sous forme d’une colonne comme un acteur

T0

TO + 10 jours

Page 55: la modélisation des Systèmes d’Information en utilisant Merise et UML

55

2.4 – M.O.T – Merise

Page 56: la modélisation des Systèmes d’Information en utilisant Merise et UML

56

2.4 – M.O.T - Merise

Voici un cas concret :Construisons les modèles de traitement de l’organisme de formation X qui suit les règles suivantes :Règle 1 : en fonction des pré-requis du stage, l’inscription est acceptée ou refusée,

Règle 2 : les clients doivent transmettre les annulations d’inscription par écrit 10 jours avant le démarrage de la formation,

Règle 3 : la société X se réserve le droit d’annuler ou reporter une session 10 jours avant son démarrage,

Règle 4 : si le nombre de stagiaires est supérieur à 5, la session est maintenue et les convocations sont envoyées.

Que pouvons-nous en déduire ?

Une demande d’inscription provoque soit un inscription, soit un refus.

Une annulation n’est prise en compte que si elle est transmise 10 jours avant le début de la session.

Si 10 jours avant le début de la session, le nombre de candidats est supérieur à 5, les convocations sont envoyés aux participants. Dans le cas contraire, la session sera annulée et reportée à une autre date.

Page 57: la modélisation des Systèmes d’Information en utilisant Merise et UML

57

2.4 – M.O.T - Merise

A partir de ces éléments, nous pouvons construire un diagramme des messages :

Page 58: la modélisation des Systèmes d’Information en utilisant Merise et UML

58

2.4 – M.O.T - Merise

Enchaînons à présent les messages, en indiquant les conditions d’enchaînement :

Page 59: la modélisation des Systèmes d’Information en utilisant Merise et UML

59

2.4 – M.O.T - Merise

Le modèle conceptuel des traitements par processus :

Page 60: la modélisation des Systèmes d’Information en utilisant Merise et UML

60

2.5 – M.L.D - Merise

Le M.L.D (Modèle Logique de Données)

Page 61: la modélisation des Systèmes d’Information en utilisant Merise et UML

61

2.5 – M.L.D - Merise

Le MLD :

C'est grâce à toutes les opérations précédentes que l'ensemble des tables de la base de donnée vont pouvoir être structurées de manière simple et très rapide :

le M.C.D, ayant été corrigé à la fin de l'étape du M.O.T, ce sont les cardinalités maximales qui vont jouer le rôle essentiel.

les entités deviennent des tables (sauf des cas particuliers comme les "dates")

Si l'une des cardinalités maximales est à "1" et l'autre à "n", l'association disparaît et l'identifiant de l'entité marquée "n" vient s'ajouter à la liste des propriétés de l'entité marquée "1" (Cas 1).

Si toutes les cardinalités maximales sont à "n", l'association se transforme en une table qui permettra la correspondance entre les enregistrements des tables reliées (tout en pouvant comporter ses propres propriétés) (Cas 2).

Ces règles s'appliquent aussi bien pour les associations "réflexives" (Cas 3).

Pour les associations de dimension "3" ou plus, elles sont toujours transformées en table (Cas 4).

Page 62: la modélisation des Systèmes d’Information en utilisant Merise et UML

62

2.5 – M.L.D - Merise

1er cas :

2ème cas :

Page 63: la modélisation des Systèmes d’Information en utilisant Merise et UML

63

2.5 – M.L.D - Merise

1er cas :

Page 64: la modélisation des Systèmes d’Information en utilisant Merise et UML

64

2.5 – M.L.D - Merise

1er cas :

Page 65: la modélisation des Systèmes d’Information en utilisant Merise et UML

65

2.5 – M.L.D - Merise

2eme cas :

Page 66: la modélisation des Systèmes d’Information en utilisant Merise et UML

66

2.5 – M.L.D - Merise

Page 67: la modélisation des Systèmes d’Information en utilisant Merise et UML

67

2.5 – M.L.D - Merise

Page 68: la modélisation des Systèmes d’Information en utilisant Merise et UML

68

2.5 – M.L.D - Merise

3eme cas :

Page 69: la modélisation des Systèmes d’Information en utilisant Merise et UML

69

2.5 – M.L.D - Merise

4eme cas :