<figure><img src="image_1.png" /></figure>

HAL
open science

# Polycopié du cours Méthodologies de Conception des Systèmes d'Information (MCSI) selon Merise/2

Leila Zemmouchi-Ghomari

► To cite this version:

Leila Zemmouchi-Ghomari. Polycopié du cours Méthodologies de Conception des Systèmes d'Information (MCSI) selon Merise/2. Licence. Méthodologie de Conception des Systèmes d'information selon Merise/2, Algérie. 2009, pp.56. hal-04561629

HAL Id: hal-04561629

https://hal.science/hal-04561629

Submitted on 27 Apr 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Polycopié du cours Méthodologies de Conception des Systèmes d'Information (MCSI) selon Merise/2

Leila Zemmouchi-Ghomari

► To cite this version:

Leila Zemmouchi-Ghomari. Polycopié du cours Méthodologies de Conception des Systèmes d'Information (MCSI) selon Merise/2. Licence. Méthodologie de Conception des Systèmes d'information selon Merise/2, Algérie. 2009, pp.56. hal-04561629

HAL Id: hal-04561629

https://hal.science/hal-04561629v1

Submitted on 27 Apr 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
2009-2014

Polycopié du cours
Méthodologies de
Conception des
Systèmes
d'Information
(MCSI) selon
Merise/2

Dr. LEILA ZEMMOUCHI-GHOMARI
INFORMATIQUE DE GESTION, FSESGSC, UMBB
2009-2014

Polycopié du cours
Méthodologies de
Conception des
Systèmes
d'Information
(MCSI) selon
Merise/2

Dr. LEILA ZEMMOUCHI-GHOMARI
INFORMATIQUE DE GESTION, FSESGSC, UMBB
# PLAN DU COURS

## Méthodologies de Conception des Systèmes d'Information (MCSI)

* CHAPITRE I : NOTIONS DE BASE D'UN SYSTEME D'INFORMATION

* CHAPITRE II : DEVELOPPEMENT D'UN SYSTEME D'INFORMATION

* CHAPITRE III : METHODE MERISE/2

* CHAPITRE IV : SECURITE ET QUALITE D'UNE APPLICATION INFORMATIQUE
# PLAN DU COURS

## Méthodologies de Conception des Systèmes d'Information (MCSI)

* CHAPITRE I : NOTIONS DE BASE D'UN SYSTEME D'INFORMATION

* CHAPITRE II : DEVELOPPEMENT D'UN SYSTEME D'INFORMATION

* CHAPITRE III : METHODE MERISE/2

* CHAPITRE IV : SECURITE ET QUALITE D'UNE APPLICATION INFORMATIQUE
Chapitre I :
Notions de base d'un Système d'Information

I.1. Définition du SI:

1. Qu'est-ce qu'une **information** ?

2. Qu'est-ce qu'un **système** ?

3. Qu'est-ce qu'un **système d'information** ?

I.1.1. Définition de l'information :

1er niveau : la *Donnée*

– Chaîne de caractère associé à des objets, des personnes ou des événements

- Représentée par un attribut et une valeur

– La donnée peut être brute ou calculée

– C'est la matière première de l'information

Exemples de données: <u>Nom</u> : Mohamed, <u>Date de naissance</u> : 11/10/1990,

<u>Taux de croissance de l'entreprise</u> : 5%, <u>Référence machine</u> : 1275DX, etc.

2ème niveau : *l'Information*

– La <u>signification</u> (explication/description) des <u>données interprétées</u> par une personne ou par un système

- Autrement dit, c'est la perception intellectuelle qualitative ou quantitative d'une réalité dans un référentiel sémantique (signification)

Exemple 1: <u>Un taux de croissance de 5% associé</u> à un seuil de qualité de 2% est une <u>information</u> que le pilote d'entreprise ou décideur <u>interprétera</u> comme suit : ce taux de croissance est excellent en comparaison au seuil de qualité qui peut être considéré comme une norme.

Exemple 2 : L a donnée <u>Age de l'employé</u> est <u>interprétée</u> par la <u>DRH</u> devient une information qui sert à décider si une personne ouvre droit à la retraite ou pas.

3ème niveau : la *Connaissance*

- Information apprise, découverte, comprise et partagée par une communauté (groupe de personnes ayant suivi le même type de formation, même spécialité, avec un langage commun)

Exemple : <u>les maladies du corps humain</u> peuvent être considérées comme <u>des connaissances apprises</u>, découvertes, comprises et partagées par <u>la communauté des Médecins</u>.
Chapitre I :
Notions de base d'un Système d'Information

I.1. Définition du SI:

1. Qu'est-ce qu'une **information** ?

2. Qu'est-ce qu'un **système** ?

3. Qu'est-ce qu'un **système d'information** ?

I.1.1. Définition de l'information :

1er niveau : la **Donnée**

– Chaîne de caractère associé à des objets, des personnes ou des événements

- Représentée par un attribut et une valeur

– La donnée peut être brute ou calculée

— C'est la matière première de l'information

Exemples de données: Nom : Mohamed, Date de naissance : 11/10/1990,

<u>Taux de croissance de l'entreprise</u> : 5%, <u>Référence machine</u> : 1275DX, etc.

2ème niveau : l'**Information**

— La <u>signification</u> (explication/description) des <u>données interprétées</u> par une personne ou par un système

- Autrement dit, c'est la perception intellectuelle qualitative ou quantitative d'une réalité dans un référentiel sémantique (signification)

Exemple 1: <u>Un taux de croissance de 5% associé</u> à un seuil de qualité de 2% est une <u>information</u> que le pilote d'entreprise ou décideur <u>interprétera</u> comme suit : ce taux de croissance est excellent en comparaison au seuil de qualité qui peut être considéré comme une norme.

Exemple 2 : L a donnée <u>Age de l'employé</u> est <u>interprétée</u> par la <u>DRH</u> devient une information qui sert à décider si une personne ouvre droit à la retraite ou pas.

3ème niveau : la **Connaissance**

- Information apprise, découverte, comprise et partagée par une communauté (groupe de personnes ayant suivi le même type de formation, même spécialité, avec un langage commun)

Exemple : <u>les maladies du corps humain</u> peuvent être considérées comme <u>des connaissances apprises</u>, découvertes, comprises et partagées par <u>la communauté des Médecins</u>.
### I.1.2. Définition du système :

Un système peut être défini comme **un tout organisé de composants en interaction** :

1. le monde des objets (composants)

2. le monde des relations (interactions)

3. le monde de la totalité

<figure><img src="image_3.png" /><figcaption>Figure 1. Composition d'un système</figcaption></figure>

<figure><img src="image_4.png" /></figure>

Les composants sont les parties d'un système

<figure><img src="image_5.png" /></figure>

Les attributs sont les propriétés des composants qui caractérisent le système

<figure><img src="image_6.png" /></figure>

Les relations sont les liens existants entre les composants

> *Un système est ainsi défini comme un ensemble de composants inter-reliés travaillant ensemble en vue de réaliser un objectif commun*

**Exemples de systèmes** : système de transport aérien (avions, pilotes, mécaniciens, passagers...et les relations entre eux), système bancaire (banques, clients, argent... et les relations entre eux), système agricole (terres agricoles, fermiers, tracteurs, engrais, semence... et les relations entre eux), etc....

### I.1.3. Définition du SI :

Un système d'information est « un ensemble organisé de ressources : matériel, logiciel, personnel, données, procédures permettant d'acquérir, de traiter, stocker, communiquer des informations dans des organisations »

A partir de cette définition, nous pouvons déduire :

**a. Les formes possibles de l'information** : Texte, images, sons, vidéo, graphiques, programmes, etc.
### I.1.2. Définition du système :

Un système peut être défini comme **un tout organisé de composants en interaction** :

1. le monde des objets (composants)

2. le monde des relations (interactions)

3. le monde de la totalité

<figure><img src="image_2.png" /><figcaption>Figure 1. Composition d'un système</figcaption></figure>

* Les composants sont les parties d'un système

* Les attributs sont les propriétés des composants qui caractérisent le système

* Les relations sont les liens existants entre les composants

> *Un système est ainsi défini comme un ensemble de composants inter-reliés travaillant ensemble en vue de réaliser un objectif commun*

**Exemples de systèmes** : système de transport aérien (avions, pilotes, mécaniciens, passagers...et les relations entre eux), système bancaire (banques, clients, argent... et les relations entre eux), système agricole (terres agricoles, fermiers, tracteurs, engrais, semence... et les relations entre eux), etc....

### I.1.3. Définition du SI :

Un système d'information est « un ensemble organisé de ressources : matériel, logiciel, personnel, données, procédures permettant d'acquérir, de traiter, stocker, communiquer des informations dans des organisations »

A partir de cette définition, nous pouvons déduire :

**a. Les formes possibles de l'information** : Texte, images, sons, vidéo, graphiques, programmes, etc.
## b. les usages du système d'information :

- **Collecter** les informations de façon manuelle ou automatique. Des exemples de collecte automatique peuvent être des systèmes de lecture optique, de cartes à puces, d'échanges informatisés entre entreprises...

- **Traiter** ces informations dans des applications de gestion de production, d'approvisionnement, de comptabilité, d'aide à le décision...

- **Stocker** ces informations dans des bases de données

- **Communiquer** ces informations en interne ou en externe, par exemple avec des clients, des fournisseurs, des banques...

## c. Les ressources du système d'information :

- Composantes informatiques : matériel informatique (hardware), logiciels (applications ou software)

- Composantes humaines : personnel informatique, utilisateurs managers ou autres utilisateurs opérationnels du système.

**Mise au point** : La confusion est fréquente entre système d'information et système informatisé. En fait, une partie du système d'information peut être informatisée, nous parlerons alors de système informatisé (également appelé SAI : Système Automatisé d'Information). Ce système informatisé prend appui sur un système informatique composé de matériel et de logiciel de base.

<figure><img src="image_7.png" /></figure>

Il comporte à ce titre **un aspect statique** : les données mais également **un aspect dynamique** : le traitement ou la mise à jour de ces données.
## b. les usages du système d'information :

- **Collecter** les informations de façon manuelle ou automatique. Des exemples de collecte automatique peuvent être des systèmes de lecture optique, de cartes à puces, d'échanges informatisés entre entreprises...

- **Traiter** ces informations dans des applications de gestion de production, d'approvisionnement, de comptabilité, d'aide à le décision...

- **Stocker** ces informations dans des bases de données

- **Communiquer** ces informations en interne ou en externe, par exemple avec des clients, des fournisseurs, des banques...

## c. Les ressources du système d'information :

- Composantes informatiques : matériel informatique (hardware), logiciels (applications ou software)

- Composantes humaines : personnel informatique, utilisateurs managers ou autres utilisateurs opérationnels du système.

**Mise au point** : La confusion est fréquente entre système d'information et système informatisé. En fait, une partie du système d'information peut être informatisée, nous parlerons alors de système informatisé (également appelé SAI : Système Automatisé d'Information). Ce système informatisé prend appui sur un système informatique composé de matériel et de logiciel de base.

<figure><img src="image_3.png" /></figure>

Il comporte à ce titre **un aspect statique** : les données mais également **un aspect dynamique** : le traitement ou la mise à jour de ces données.
## I.2. La place du système d'information dans l'entreprise :

Dans l'approche systémique, l'entreprise peut être divisée en trois systèmes, selon la figure suivante :

<figure><img src="image_8.png" /></figure>

**Système de pilotage** : travaille sur un nombre **réduit** d'informations issues du système opérationnel **agrégées** dans le temps et dans l'espace de manière à obtenir une vision de **synthèse** de l'activité de l'entreprise (ex : le nombre de pièces fabriquées dans le mois) pour **décider et orienter**.

**Système de gestion ou système d'information** : permet de **gérer, suivre et contrôler** le niveau opérationnel de l'entreprise et **informe** le niveau de pilotage, autrement dit, ce système prend en charge l'aspect **communication et échange** entre les différents paliers de l'entreprise tant au niveau interne qu'au niveau externe.

**Système opérationnel** : c'est le niveau de production, ce système travaille sur **des données élémentaires** (ex : le numéro de la pièce fabriquée) en respectant les objectifs émis par le niveau de gestion.

## I.3. Les applications du Système d'information :

Les frontières entre les différents niveaux de l'entreprise ne sont pas clairement définies, le système d'information est également présent dans le système d'aide à la décision et dans le système opérationnel, ceci apparaît de façon plus explicite dans les applications des systèmes d'information comme le montre le tableau suivant :
## I.2. La place du système d'information dans l'entreprise :

Dans l'approche systémique, l'entreprise peut être divisée en trois systèmes, selon la figure suivante :

<figure><img src="image_4.png" /></figure>

**Système de pilotage** : travaille sur un nombre **réduit** d'informations issues du système opérationnel **agrégées** dans le temps et dans l'espace de manière à obtenir une vision de **synthèse** de l'activité de l'entreprise (ex : le nombre de pièces fabriquées dans le mois) pour **décider et orienter**.

**Système de gestion ou système d'information** : permet de **gérer, suivre et contrôler** le niveau opérationnel de l'entreprise et **informe** le niveau de pilotage, autrement dit, ce système prend en charge l'aspect **communication et échange** entre les différents paliers de l'entreprise tant au niveau interne qu'au niveau externe.

**Système opérationnel** : c'est le niveau de production, ce système travaille sur **des données élémentaires** (ex : le numéro de la pièce fabriquée) en respectant les objectifs émis par le niveau de gestion.

## I.3. Les applications du Système d'information :

Les frontières entre les différents niveaux de l'entreprise ne sont pas clairement définies, le système d'information est également présent dans le système d'aide à la décision et dans le système opérationnel, ceci apparaît de façon plus explicite dans les applications des systèmes d'information comme le montre le tableau suivant :
<table><thead><tr><td>Type du SI</td><td>Rôle</td><td>Exemples</td></tr></thead><tbody><tr><td>SI Opérationnels</td><td>Collecter, traiter, mémoriser les données<br>Automatiser les processus</td><td><ul><li>Achats</li><li>Comptabilité</li><li>Paie et GRH<sup>1</sup></li><li>Distribution...</li></ul></td></tr><tr><td>SI d'aide à la décision</td><td>Fournir des indicateurs pertinents sur l'activité<br>Connaître les clients<br>Offrir des outils d'analyse et de simulation</td><td><ul><li>Budget</li><li>Tableau de bord</li><li>Analyse du profil client</li><li>Statistiques ...</li></ul></td></tr><tr><td>SI de communication</td><td>Echanges internes<br>Echanges avec l'environnement</td><td><ul><li>Messagerie</li><li>Réseau d'échange interne (workflow intranet)</li><li>Réseau d'échange avec les clients et les fournisseurs, plate-forme de commerce électronique</li><li>Site web</li></ul></td></tr></tbody></table>

<footnote n="1">¹ Gestion des Ressources Humaines</footnote>
<table><thead><tr><td>Type du SI</td><td>Rôle</td><td>Exemples</td></tr></thead><tbody><tr><td>SI Opérationnels</td><td>Collecter, traiter, mémoriser les données<br>Automatiser les processus</td><td><ul><li>Achats</li><li>Comptabilité</li><li>Paie et GRH<fnref n="1" /></li><li>Distribution...</li></ul></td></tr><tr><td>SI d'aide à la décision</td><td>Fournir des indicateurs pertinents sur l'activité<br>Connaître les clients<br>Offrir des outils d'analyse et de simulation</td><td><ul><li>Budget</li><li>Tableau de bord</li><li>Analyse du profil client</li><li>Statistiques ...</li></ul></td></tr><tr><td>SI de communication</td><td>Echanges internes<br>Echanges avec l'environnement</td><td><ul><li>Messagerie</li><li>Réseau d'échange interne ( workflow intranet)</li><li>Réseau d'échange avec les clients et les fournisseurs, plate-forme de commerce électronique</li><li>Site web</li></ul></td></tr></tbody></table>

<footnote n="1">¹ Gestion des Ressources Humaines</footnote>
# Chapitre II :
Développement d'un SI

1. **Point de départ** : Une réflexion, une idée, un objectif, un désir de nouveauté ou de changement, concernant le cadre de fonctionnement présent, de la part des responsables.

2. **Conception d'un SI** : création d'un nouveau SI (changement total) ou l'évolution fonctionnelle et/ou technique d'une des composantes de ce système (changement partiel).

3. **Finalité** : Introduction et utilisation intensive d'un outil logiciel (ou un ensemble d'outils) conçu ou adapté pour réaliser de la façon la plus complète le fonctionnement fixé.

## II.1. Phases de développement d'un SI :

<figure><img src="image_9.png" /></figure>

1. **Analyse** : Diagnostiquer le système actuel et définir le futur système d'information

2. **Conception** : concevoir un système informatique pouvant satisfaire les exigences formulées à l'issue de l'étape d'analyse

3. **Implémentation** : transformer les éléments décrits lors de la conception en éléments du langage cible (programme ou application)

4. **Mise en œuvre** : mettre en place le nouvel outil informatique, accompagné de la nouvelle organisation du travail pour rendre opérationnel le nouveau système d'information

### Mise au point :

Pour faciliter l'analyse du système actuel et la conception du futur système, le système d'information a besoin d'être représenté par un **formalisme**<fnref n="2" /> simple et facile à manipuler, capable de représenter la réalité de ce système, aussi fidèlement que possible

Ainsi, le formalisme adopté doit permettre de :

- Recenser toutes les informations circulant au sein du domaine étudié,

- ainsi que les liens et les échanges existant entre ces informations,

- Reproduire clairement et fidèlement tous les traitements effectués par le système d'information.

> L'opération de représentation du système d'information par des formalismes est appelée **Modélisation**

### Définition de la modélisation:

<footnote n="2">² Formalisme = langage de représentation</footnote>
Chapitre II :
Développement d'un SI

1. **Point de départ** : Une réflexion, une idée, un objectif, un désir de nouveauté ou de changement, concernant le cadre de fonctionnement présent, de la part des responsables.

2. **Conception d'un SI** : création d'un nouveau SI (changement total) ou l'évolution fonctionnelle et/ou technique d'une des composantes de ce système (changement partiel).

3. **Finalité** : Introduction et utilisation intensive d'un outil logiciel (ou un ensemble d'outils) conçu ou adapté pour réaliser de la façon la plus complète le fonctionnement fixé.

II.1. Phases de développement d'un SI :

<figure><img src="image_5.png" /></figure>

1. **Analyse** : Diagnostiquer le système actuel et définir le futur système d'information

2. **Conception** : concevoir un système informatique pouvant satisfaire les exigences formulées à l'issue de l'étape d'analyse

3. **Implémentation** : transformer les éléments décrits lors de la conception en éléments du langage cible (programme ou application)

4. Mise en œuvre : mettre en place le nouvel outil informatique, accompagné de la nouvelle organisation du travail pour rendre opérationnel le nouveau système d'information

Mise au point :

Pour faciliter l'analyse du système actuel et la conception du futur système, le système d'information a besoin d'être représenté par un **formalisme**<fnref n="2" /> simple et facile à manipuler, capable de représenter la réalité de ce système, aussi fidèlement que possible

Ainsi, le formalisme adopté doit permettre de :

- Recenser toutes les informations circulant au sein du domaine étudié,

- ainsi que les liens et les échanges existant entre ces informations,

- Reproduire clairement et fidèlement tous les traitements effectués par le système d'information.

L'opération de représentation du système d'information par des formalismes
est appelée **Modélisation**

Définition de la modélisation:

<footnote n="2">² Formalisme = langage de représentation</footnote>
La modélisation consiste à représenter le système d'information étudié tel qu'il est perçu dans le monde réel, par les modèles. Ces modèles doivent être conformes à la réalité représentée, une fois établis, ils doivent être soumis aux utilisateurs pour validation (confirmation).

## II.2. Méthodes pour l'analyse et la conception d'un SI

Le besoin d'une approche méthodologique est dicté par la nécessité de respecter les délais de réalisation et les contraintes matérielles et humaines

- la méthode choisie dépendra de la nature de l'application (du futur SI) et de l'expérience des intervenants

A partir des années '70 plusieurs méthodes ont vu le jour :

- **SADT** ('70) (structured analysis and design techniques)

- **Merise**, puis **Merise 2** ('79, '90)

- **IEM** ('80) (information engineering method)

- **OOD** ('90) (object modeling technique)

- **UP** ('90) (Unified Process)

- **RAD** ('90) (rapid development activity)

- etc.

## II.3. La méthode Merise :

« Le merisier ne peut porter de beaux fruits que si on lui greffe une branche de cerisier : ainsi en va-t-il des méthodes informatiques bien conçues qui ne produisent de bons résultats que si la greffe sur l'organisation réussit » Hubert Tardieu concepteur de la méthode merise<fnref n="3" />.

Merise est une méthode complète de développement des systèmes d'information (la plus répandue en France), crée en 1978/1979. La deuxième version de Merise, objet de ce cours date du début des années 90, elle est caractérisée par l'ajout de la couche communication par rapport à la version précédente.

### Les trois dimensions de la méthode Merise.

Une méthode de conception de système d'information s'inscrit dans trois dimensions exprimant :

* La démarche ou *cycle de vie*,

* le raisonnement ou *cycle d'abstraction*,

* la maîtrise ou *cycle de décision*.

<footnote n="3">³ L'ouvrage de référence de la méthode Merise est : H.Tardieu, A.Rochfeld, R.Colletti : la méthode Merise tome 1 : principes et outils 1983, tome2 : démarche et pratiques. Les éditions d'organisation, 1985.</footnote>
La modélisation consiste à représenter le système d'information étudié tel qu'il est perçu dans le monde réel, par les modèles. Ces modèles doivent être conformes à la réalité représentée, une fois établis, ils doivent être soumis aux utilisateurs pour validation (confirmation).

## II.2. Méthodes pour l'analyse et la conception d'un SI

Le besoin d'une approche méthodologique est dicté par la nécessité de respecter les délais de réalisation et les contraintes matérielles et humaines

- la méthode choisie dépendra de la nature de l'application (du futur SI) et de l'expérience des intervenants

A partir des années '70 plusieurs méthodes ont vu le jour :

- **SADT** ('70) (structured analysis and design techniques)

- **Merise**, puis **Merise 2** ('79, '90)

- **IEM** ('80) (information engineering method)

- **OOD** ('90) (object modeling technique)

- **UP** ('90) (Unified Process)

- **RAD** ('90) (rapid development activity)

- etc.

## II.3. La méthode Merise :

« Le merisier ne peut porter de beaux fruits que si on lui greffe une branche de cerisier : ainsi en va-t-il des méthodes informatiques bien conçues qui ne produisent de bons résultats que si la greffe sur l'organisation réussit » Hubert Tardieu concepteur de la méthode merise<fnref n="3" />.

Merise est une méthode complète de développement des systèmes d'information (la plus répandue en France), crée en 1978/1979. La deuxième version de Merise, objet de ce cours date du début des années 90, elle est caractérisée par l'ajout de la couche communication par rapport à la version précédente.

### Les trois dimensions de la méthode Merise.

Une méthode de conception de système d'information s'inscrit dans trois dimensions exprimant :

* La démarche ou *cycle de vie*,

* le raisonnement ou *cycle d'abstraction*,

* la maîtrise ou *cycle de décision*.

<footnote n="3">³ L'ouvrage de référence de la méthode Merise est : H.Tardieu, A.Rochfeld, R.Colletti : la méthode Merise tome 1 : principes et outils 1983, tome2 : démarche et pratiques. Les éditions d'organisation, 1985.</footnote>
<figure><img src="image_10.png" /><figcaption>Figure : Repérage dans les trois dimensions de Merise</figcaption></figure>

La mise en œuvre de la méthode doit toujours se repérer par rapport à ces trois dimensions. Tout instant de la conception doit pouvoir se situer dans ce référentiel.

## 1. Cycle de Vie

Le cycle de vie est constitué des sept étapes :

1. **Schéma Directeur** : faire un diagnostic, identifier et qualifier les domaines concernés pour aboutir à un plan stratégique

2. **Etude Préalable** : étudier des scénarios d'informatisation d'un domaine étudié au niveau du schéma directeur

3. **Etude Détaillée** : fournir les spécifications détaillées par sous-projet

4. **Etude Technique** : lister tous les moyens techniques dont on dispose et dont on a besoin (matériel, logiciel de développement)

5. **Production du Logiciel** : développement informatiques et tests logiciel

6. **Mise en œuvre** : préparation de l'environnement, mise en place dans un premier temps d'un site pilote pour tester, mise en place globale, livraison du produit (recette)

7. **Maintenance** : faire évoluer le produit final (correction des erreurs, évolutions naturelles, divers paramétrages)

Lorsque l'environnement évolue fortement : obsolescence⁴ des techniques utilisées, modification profonde des règles de gestion, bouleversement en profondeur des structures, un autre cycle de vie recommence.

## 2. Cycle de Décision :

La méthode souligne l'importance d'un échéancier de rencontres entre les responsables des différents pôles de l'entreprise, bien sûr, mais aussi avec les utilisateurs, afin de faire prendre conscience de la charge de travail, et parfois des difficultés relationnelles, que supposent une collaboration, une compréhension et une implication personnelle dans un processus de décisions sur des questions pluridisciplinaires.

<footnote n="44">⁴⁴ Dépassé, pas moderne</footnote>
<figure><img src="image_6.png" /><figcaption>Figure : Repérage dans les trois dimensions de Merise</figcaption></figure>

La mise en œuvre de la méthode doit toujours se repérer par rapport à ces trois dimensions. Tout instant de la conception doit pouvoir se situer dans ce référentiel.

## 1. Cycle de Vie

Le cycle de vie est constitué des sept étapes :

1. **Schéma Directeur** : faire un diagnostic, identifier et qualifier les domaines concernés pour aboutir à un plan stratégique

2. **Etude Préalable** : étudier des scénarios d'informatisation d'un domaine étudié au niveau du schéma directeur

3. **Etude Détaillée** : fournir les spécifications détaillées par sous-projet

4. **Etude Technique** : lister tous les moyens techniques dont on dispose et dont on a besoin (matériel, logiciel de développement)

5. **Production du Logiciel** : développement informatiques et tests logiciel

6. **Mise en œuvre** : préparation de l'environnement, mise en place dans un premier temps d'un site pilote pour tester, mise en place globale, livraison du produit (recette)

7. **Maintenance** : faire évoluer le produit final (correction des erreurs, évolutions naturelles, divers paramétrages)

Lorsque l'environnement évolue fortement : obsolescence⁴ des techniques utilisées, modification profonde des règles de gestion, bouleversement en profondeur des structures, un autre cycle de vie recommence.

## 2. Cycle de Décision :

La méthode souligne l'importance d'un échéancier de rencontres entre les responsables des différents pôles de l'entreprise, bien sûr, mais aussi avec les utilisateurs, afin de faire prendre conscience de la charge de travail, et parfois des difficultés relationnelles, que supposent une collaboration, une compréhension et une implication personnelle dans un processus de décisions sur des questions pluridisciplinaires.

<footnote n="44">⁴⁴ Dépassé, pas moderne</footnote>
### 3. Cycle d'abstraction :

Ce cycle décrit la démarche de la méthode Merise selon **3 découpages répartis sur 4 niveaux**.

En effet pour étudier et développer l'informatique d'une entreprise ou de tout type d'organisme, il est nécessaire de connaître ses échanges internes et avec l'extérieur, comment elle réagit à une sollicitation externe et quelle est la structure des informations qu'elle utilise. La méthode MERISE décrit cette connaissance sous forme de **trois découpages : communication, traitement et données**.

a. **Communication** : Les échanges ou la communication sont des flux entre systèmes, notamment des flux d'informations ou messages.

b. **Traitement** : Les traitements des messages, flux d'informations, décrivent les tâches à effectuer à la réception ou pour l'émission d'un flux d'informations.

c. **Données** : La structure de mémorisation des informations est représentée sous une forme qui permet un passage aisé vers les "enregistrements informatiques".

#### Quatre niveaux : conceptuel, organisationnel, logique et physique

<figure><img src="image_11.png" /></figure>

##### Niveau I : Les objectifs de l'entreprise : le niveau conceptuel

Le plus invariant, le niveau conceptuel, définit les fonctions réalisées dans l'organisme. Il répond à la question QUE FAIT L'ORGANISME ? Il est déterminé par son activité.

##### Niveau II : Les postes de travail de l'entreprise : le niveau organisationnel

Pourquoi une organisation ? Pour réaliser les fonctions de l'entreprise décrites dans la première partie. Cela répond à la question QUI FAIT QUOI ?

Conceptuel et organisationnel représentent toute l'entreprise. Les deux niveaux suivants ne prennent en compte que la solution informatique retenue.

##### Niveau III : L'informatique universelle : le niveau logique ou externe
### 3. Cycle d'abstraction :

Ce cycle décrit la démarche de la méthode Merise selon **3 découpages répartis sur 4 niveaux**.

En effet pour étudier et développer l'informatique d'une entreprise ou de tout type d'organisme, il est nécessaire de connaître ses échanges internes et avec l'extérieur, comment elle réagit à une sollicitation externe et quelle est la structure des informations qu'elle utilise. La méthode MERISE décrit cette connaissance sous forme de **trois découpages : communication, traitement et données**.

a. **Communication** : Les échanges ou la communication sont des flux entre systèmes, notamment des flux d'informations ou messages.

b. **Traitement** : Les traitements des messages, flux d'informations, décrivent les tâches à effectuer à la réception ou pour l'émission d'un flux d'informations.

c. **Données** : La structure de mémorisation des informations est représentée sous une forme qui permet un passage aisé vers les "enregistrements informatiques".

#### Quatre niveaux : conceptuel, organisationnel, logique et physique

<figure><img src="image_7.png" /></figure>

##### Niveau I : Les objectifs de l'entreprise : le niveau conceptuel

Le plus invariant, le niveau conceptuel, définit les fonctions réalisées dans l'organisme. Il répond à la question QUE FAIT L'ORGANISME ? Il est déterminé par son activité.

##### Niveau II : Les postes de travail de l'entreprise : le niveau organisationnel

Pourquoi une organisation ? Pour réaliser les fonctions de l'entreprise décrites dans la première partie. Cela répond à la question QUI FAIT QUOI ?

Conceptuel et organisationnel représentent toute l'entreprise. Les deux niveaux suivants ne prennent en compte que la solution informatique retenue.

##### Niveau III : L'informatique universelle : le niveau logique ou externe
Puis, plus variable, est la forme que doit prendre l'outil informatique pour être adapté à l'utilisateur, à son poste de travail. C'est le niveau logique, la maquette des enchaînements d'écran et la réponse à la question A QUOI RESSEMBLERA LA SOLUTION INFORMATIQUE PROPOSEE ? Le niveau logique est indépendant de l'informatique spécifique, des langages de programmation ou de gestion des données.

## Niveau IV : L'informatique spécifique : le niveau physique ou interne

Le dernier niveau, le plus variable, est l'outil informatique lui-même, les fichiers, les programmes. AVEC QUOI ou COMMENT? Ce niveau est appelé niveau physique. Ce niveau dépend à 100% du système informatique retenu, du type de la base de données et des outils de développement.

### Remarques importantes :

* L'existence des quatre niveaux permet un suivi méthodique. Cette étude se conduit sans retour entre chaque niveau.

* Le niveau inférieur doit être étudié après le niveau supérieur. Le niveau logique est abordé après le niveau organisationnel

* Le niveau inférieur peut être modifié sans affecter le niveau supérieur. Par exemple, le niveau organisationnel peut être modifié sans affecter le niveau conceptuel.

Merise décrit ces modèles sous forme de dessins.

* MCC = Modèle Conceptuel de Communication

* MCD = Modèle Conceptuel de Données

* MCT = Modèle Conceptuel de Traitements...

<table><thead><tr><th></th><th>COMMUNICAT.</th><th>DONNEES</th><th>TRAITEMENT</th></tr></thead><tbody><tr><td>CONCEPTUEL</td><td>MCC</td><td>MCD</td><td>MCT</td></tr><tr><td>ORGANISATIONNEL</td><td>MOC</td><td>MOD</td><td>MOT</td></tr><tr><td>LOGIQUE</td><td>MLC</td><td>MLD</td><td>MLT</td></tr><tr><td>PHYSIQUE</td><td>MPC</td><td>MPD</td><td>MPT</td></tr></tbody></table>

Les "temps forts" de la méthode sont le Modèle Conceptuel de Communication (MCC), le Modèle Conceptuel de Données (MCD) et le Modèle Organisationnel de Traitement (MOT). Parmi ces trois modèles, le plus important concerne la représentation des modèles conceptuels de données.

## Les atouts majeurs (avantages) de MERISE en temps que méthode de conception sont :

* une approche globale du S.I. menée parallèlement sur les données et les traitements,

* une description du S.I. par niveaux conceptuel, niveau logique ou organisationnel et niveau physique ou opérationnel,
Puis, plus variable, est la forme que doit prendre l'outil informatique pour être adapté à l'utilisateur, à son poste de travail. C'est le niveau logique, la maquette des enchaînements d'écran et la réponse à la question A QUOI RESSEMBLERA LA SOLUTION INFORMATIQUE PROPOSEE ? Le niveau logique est indépendant de l'informatique spécifique, des langages de programmation ou de gestion des données.

## Niveau IV : L'informatique spécifique : le niveau physique ou interne

Le dernier niveau, le plus variable, est l'outil informatique lui-même, les fichiers, les programmes. AVEC QUOI ou COMMENT? Ce niveau est appelé niveau physique. Ce niveau dépend à 100% du système informatique retenu, du type de la base de données et des outils de développement.

### Remarques importantes :

* L'existence des quatre niveaux permet un suivi méthodique. Cette étude se conduit sans retour entre chaque niveau.

* Le niveau inférieur doit être étudié après le niveau supérieur. Le niveau logique est abordé après le niveau organisationnel

* Le niveau inférieur peut être modifié sans affecter le niveau supérieur. Par exemple, le niveau organisationnel peut être modifié sans affecter le niveau conceptuel.

Merise décrit ces modèles sous forme de dessins.

* MCC = Modèle Conceptuel de Communication

* MCD = Modèle Conceptuel de Données

* MCT = Modèle Conceptuel de Traitements...

<table><thead><tr><th></th><th>COMMUNICAT.</th><th>DONNEES</th><th>TRAITEMENT</th></tr></thead><tbody><tr><td>CONCEPTUEL</td><td>MCC</td><td>MCD</td><td>MCT</td></tr><tr><td>ORGANISATIONNEL</td><td>MOC</td><td>MOD</td><td>MOT</td></tr><tr><td>LOGIQUE</td><td>MLC</td><td>MLD</td><td>MLT</td></tr><tr><td>PHYSIQUE</td><td>MPC</td><td>MPD</td><td>MPT</td></tr></tbody></table>

Les "temps forts" de la méthode sont le Modèle Conceptuel de Communication (MCC), le Modèle Conceptuel de Données (MCD) et le Modèle Organisationnel de Traitement (MOT). Parmi ces trois modèles, le plus important concerne la représentation des modèles conceptuels de données.

## Les atouts majeurs (avantages) de MERISE en temps que méthode de conception sont :

* une approche globale du S.I. menée parallèlement sur les données et les traitements,

* une description du S.I. par niveaux conceptuel, niveau logique ou organisationnel et niveau physique ou opérationnel,
* une description du S.I utilisant un **formalisme de représentation précis, simple et rigoureux** pour la description des données. Ce formalisme est normalisé au plan international par l'ISO. Sous le nom de modèle « ENTITE RELATION » ;

* une description très riche du niveau conceptuel fondée sur les invariants du S.I. sur des bases solides, **indépendantes de l'organisation et des choix techniques** d'automatisation ;

* la représentation visuelle, notamment des modèles conceptuels, contribue dans une large mesure à l'établissement d'un **dialogue constructif entre tous les partenaires** qui conçoivent ensemble le nouveau S.I,

* Elle sert de référence aux enseignements sur les méthodes.

Les griefs (reproches) les plus fréquemment émis aujourd'hui concernant MERISE sont les suivants :

* définis pour une architectures de l'état de l'art des années 80, elle n'est pas adaptée aux **nouvelles architectures techniques** ;

* elle n'a pas suffisamment pris compte des **évolutions organisationnelles** ; les utilisateurs sont devenus plus exigeants en matière d'ergonomie, d'évolutivité, de fiabilité, de souplesse,

* vis à vis des choix d'organisation ; les organisations s'internationalisent, elle est davantage destinée à des **sites centraux** plus qu'à des développements en temps réel,

* elle propose une démarche **par étapes**, assez monolithique (les retours sont faibles, méthode rigide),

* elle fournit peu d'aide aux chefs de projets dans une grande partie de leurs activités de **pilotage** de projets et d'assurance qualité (ne prend pas en charge l'aspect décisionnel),

* elle « s'arrête au niveau **organisationnel des traitements** » et doit être complétée par des démarches spécifiques pour l'étude technique et la réalisation des logiciels ;

* elle s'applique plus aux systèmes développés scratch (à partir de zéro) qu'aux systèmes ayant besoin d'une maintenance ou de **seconde informatisation** ou rénoves ;

* elle a une **diffusion limitée** géographiquement (pays francophones).
* une description du S.I utilisant un **formalisme de représentation précis, simple et rigoureux** pour la description des données. Ce formalisme est normalisé au plan international par l'ISO. Sous le nom de modèle « ENTITE RELATION » ;

* une description très riche du niveau conceptuel fondée sur les invariants du S.I. sur des bases solides, **indépendantes de l'organisation et des choix techniques** d'automatisation ;

* la représentation visuelle, notamment des modèles conceptuels, contribue dans une large mesure à l'établissement d'un **dialogue constructif entre tous les partenaires** qui conçoivent ensemble le nouveau S.I,

* Elle sert de référence aux enseignements sur les méthodes.

Les griefs (reproches) les plus fréquemment émis aujourd'hui concernant MERISE sont les suivants :

* définis pour une architectures de l'état de l'art des années 80, elle n'est pas adaptée aux **nouvelles architectures techniques** ;

* elle n'a pas suffisamment pris compte des **évolutions organisationnelles** ; les utilisateurs sont devenus plus exigeants en matière d'ergonomie, d'évolutivité, de fiabilité, de souplesse,

* vis à vis des choix d'organisation ; les organisations s'internationalisent, elle est davantage destinée à des **sites centraux** plus qu'à des développements en temps réel,

* elle propose une démarche **par étapes**, assez monolithique (les retours sont faibles, méthode rigide),

* elle fournit peu d'aide aux chefs de projets dans une grande partie de leurs activités de **pilotage** de projets et d'assurance qualité (ne prend pas en charge l'aspect décisionnel),

* elle « s'arrête au niveau **organisationnel des traitements** » et doit être complétée par des démarches spécifiques pour l'étude technique et la réalisation des logiciels ;

* elle s'applique plus aux systèmes développés scratch (à partir de zéro) qu'aux systèmes ayant besoin d'une maintenance ou de **seconde informatisation** ou rénoves ;

* elle a une **diffusion limitée** géographiquement (pays francophones).
# Etapes d'une Etude Informatique :

Les étapes principales pour le niveau conceptuel sont:

* construction du modèle conceptuel de communication, domaines, partenaires et messages ;

* construction du modèle conceptuel de données ;

* validation des modèles de communication et de données ;

* construction du modèle conceptuel de traitement ;

* validation des modèles conceptuels de données et de traitement.

<figure><img src="image_12.png" /></figure>

Les étapes du niveau organisationnel et de définition des outils sont :

* construction de l'organigramme et de la liste des MOT ou procédures ;

* construction du ou des modèles organisationnels de données ;

* construction des modèles organisationnels de traitement ou procédures ;

* construction de la liste des outils validée par les modèles de données et de traitements.

<figure><img src="image_13.png" /></figure>

Les étapes du niveau logique et physique sont les suivantes :

* spécification externe : construction des enchaînements d'écrans et description des champs des écrans ou MLT, et validation par l'utilisateur final ;

* construction des modèles de données dépendant du SGBD choisi ;

* description des actions des écrans sur la base de donnés : spécification interne ;
Chapitre III :

La Méthode Merise/2

Etapes d'une Etude Informatique :

Les étapes principales pour le niveau conceptuel sont :

 construction du modèle conceptuel de communication, domaines, partenaires et messages ;

 construction du modèle conceptuel de données ;

 validation des modèles de communication et de données ;

 construction du modèle conceptuel de traitement ;

 validation des modèles conceptuels de données et de traitement.

<figure><img src="image_8.png" /></figure>

Les étapes du niveau organisationnel et de définition des outils sont :

 construction de l'organigramme et de la liste des MOT ou procédures ;

 construction du ou des modèles organisationnels de données ;

 construction des modèles organisationnels de traitement ou procédures ;

 construction de la liste des outils validée par les modèles de données et de traitements.

<figure><img src="image_9.png" /></figure>

Les étapes du niveau logique et physique sont les suivantes :

 spécification externe : construction des enchaînements d'écrans et description des champs des écrans ou MLT, et validation par l'utilisateur final ;

 construction des modèles de données dépendant du SGBD choisi ;

 description des actions des écrans sur la base de donnés : spécification interne ;
* construction du jeu de test ;

* programmation : modèles physiques des traitements ;

* tests de réception appelés *recettes* en informatique.

<figure><img src="image_14.png" /></figure>

# 1. Le Niveau Conceptuel de Merise

L'objectif est de représenter l'activité de l'entreprise et de formaliser son "système d'information" indépendamment de son organisation.

1. Le modèle de communication formalise les échanges d'informations entre systèmes fonctionnels et identifie les systèmes "à mémoire".

2. Le modèle de traitement formalise, comme son nom l'indique, les traitements effectués par un système fonctionnel, comment l'entreprise réagit à une réception d'informations, ou quand, spontanément, elle décide d'émettre des informations.

3. Le modèle de données est la référence de l'activité de l'entreprise, la manière dont elle perçoit et mémorise son activité. Il formalise toutes les informations mémorisées.

## a. Le Modèle Conceptuel de Communication :

<figure><img src="image_15.png" /><figcaption>Figure : le MCC</figcaption></figure>
* construction du jeu de test ;

* programmation : modèles physiques des traitements ;

* tests de réception appelés *recettes* en informatique.

<figure><img src="image_10.png" /></figure>

# 1. Le Niveau Conceptuel de Merise

L'objectif est de représenter l'activité de l'entreprise et de formaliser son "système d'information" indépendamment de son organisation.

1. Le modèle de communication formalise les échanges d'informations entre systèmes fonctionnels et identifie les systèmes "à mémoire".

2. Le modèle de traitement formalise, comme son nom l'indique, les traitements effectués par un système fonctionnel, comment l'entreprise réagit à une réception d'informations, ou quand, spontanément, elle décide d'émettre des informations.

3. Le modèle de données est la référence de l'activité de l'entreprise, la manière dont elle perçoit et mémorise son activité. Il formalise toutes les informations mémorisées.

## a. Le Modèle Conceptuel de Communication :

<figure><img src="image_11.png" /><figcaption>Figure : le MCC</figcaption></figure>
Les objectifs du MCC :
- Définir le champ de l'étude
- Définir un vocabulaire commun informatique/utilisateur
- Déterminer les domaines centraux (noyaux) : beaucoup d'entrées/sorties

## Les phases de construction du MCC :

1. Définir les fonctions élémentaires

2. Les regrouper en domaines

Un domaine est un système de l'entreprise qui a la caractéristique d'avoir une mémoire. Le système d'information sera construit par domaine. L'entreprise est décomposée en domaines décomposés en sous-domaines, somme de fonctions élémentaires : vendre, produire, réparer....L'objectif est de vérifier qu'une fonction n'est exercée que par un domaine et que toute fonction est exercée par un domaine. Ainsi, une meilleure définition du champ de l'étude est obtenue.

Exemple d'identification des domaines/sous domaines:

- Pourquoi analyser la production ? Pour produire à moindre coût.

- Pourquoi produire ? Pour vendre.

- Pourquoi gérer les stocks ? Pour approvisionner la production.

- Pourquoi maintenir ? Pour produire.

- Pourquoi gérer les pièces détachées ? Pour approvisionner la maintenance.

- Pourquoi suivre les pannes ? Pour planifier les réparations.

- Pourquoi gérer les réparations ? Pour réaliser la maintenance.

3. Identifier les partenaires

L'entreprise est perçue comme un ensemble de systèmes fonctionnels qui a des échanges avec les systèmes externes de l'entreprise. L'ensemble des systèmes externes et internes à l'entreprise sont appelés intervenants, **Les partenaires** sont les systèmes ou **les acteurs externes** de l'entreprise : client, fournisseur, banque...

4. Définir les flux réels et les flux d'information

Les intervenants définis, intéressons-nous aux échanges entre ceux-ci. Ces échanges sont plus importants que les intervenants. Des flux sont échangés entre des émetteurs et des récepteurs, les intervenants. Ils peuvent être réels (produit, énergie, argent) ou d'information, les messages. La description des messages entre domaines ou entre domaine et partenaire précise les demandes ou les réponses échangées nécessaires au fonctionnement du système. Les messages conceptuels sont indépendants de leur support. Ils sont écrits, oraux ou même sous-entendus. La phase suivante est la description des informations véhiculées par les messages, exemple : Message : commande, les informations contenues dans ce message sont : N° bon de commande, date de la commande, nom client, désignation produit, quantité, prix unitaire, adresse de livraison, date de livraison.
Les objectifs du MCC : - Définir le champ de l'étude

- Définir un vocabulaire commun informatique/utilisateur

- Déterminer les domaines centraux (noyaux) : beaucoup d'entrées/sorties

## Les phases de construction du MCC :

1. Définir les fonctions élémentaires

2. Les regrouper en domaines

Un domaine est un système de l'entreprise qui a la caractéristique d'avoir une mémoire. Le système d'information sera construit par domaine. L'entreprise est décomposée en domaines décomposés en sous-domaines, somme de fonctions élémentaires : vendre, produire, réparer....L'objectif est de vérifier qu'une fonction n'est exercée que par un domaine et que toute fonction est exercée par un domaine. Ainsi, une meilleure définition du champ de l'étude est obtenue.

Exemple d'identification des domaines/sous domaines:

Pourquoi analyser la production ? Pour produire à moindre coût.

Pourquoi produire ? Pour vendre.

Pourquoi gérer les stocks ? Pour approvisionner la production.

Pourquoi maintenir ? Pour produire.

Pourquoi gérer les pièces détachées ? Pour approvisionner la maintenance.

Pourquoi suivre les pannes ? Pour planifier les réparations.

Pourquoi gérer les réparations ? Pour réaliser la maintenance

3. Identifier les partenaires

L'entreprise est perçue comme un ensemble de systèmes fonctionnels qui a des échanges avec les systèmes externes de l'entreprise. L'ensemble des systèmes externes et internes à l'entreprise sont appelés intervenants, **Les partenaires** sont les systèmes ou **les acteurs externes** de l'entreprise : client, fournisseur, banque...

4. Définir les flux réels et les flux d'information

Les intervenants définis, intéressons-nous aux échanges entre ceux-ci. Ces échanges sont plus importants que les intervenants. Des flux sont échangés entre des émetteurs et des récepteurs, les intervenants. Ils peuvent être réels (produit, énergie, argent) ou d'information, les messages. La description des messages entre domaines ou entre domaine et partenaire précise les demandes ou les réponses échangées nécessaires au fonctionnement du système. Les messages conceptuels sont indépendants de leur support. Ils sont écrits, oraux ou même sous-entendus. La phase suivante est la description des informations véhiculées par les messages, exemple : Message : commande, les informations contenues dans ce message sont : N° bon de commande, date de la commande, nom client, désignation produit, quantité, prix unitaire, adresse de livraison, date de livraison.
## 5. Epurer les informations :

Les informations du MCC sont explicitées. La suppression des synonymes (mots ayant la même signification), des poly sèmes (mots ayant plusieurs significations) et la description des règles de calcul, des informations composées ou équivalentes permettent de définir un premier "dictionnaire de données" permettant une clarification et une définition des données. Le vocabulaire utilisé par l'informatique et l'utilisateur ne doit pas contenir d'ambiguïté, il doit être épuré afin d'être mémorisé.

Exemple :

### Commande client

Nom du client donneur d'ordre

Nom du client à livrer

Adresse de livraison

date de la commande

date de la livraison

no article

quantité commandée

prix unitaire

montant commandé

Nom du client : livraison

Nom du client DO : commande

Nom du client à livrer : commande

Adresse de livraison : commande, livraison

date de la commande : commande

date de la livraison : commande, livraison

no article : commande

no produit : livraison

quantité commandée : commande

quantitée livrée : livraison

prix unitaire : commande

montant commandé : commande

### Livraison client

Nom du client

Adresse de livraison

date de la livraison

no produit

quantité livrée

prix unitaire

### Polysème :

La date de la livraison a 2 significations différentes :

- date de livraison souhaitée à la commande

- date de livraison réelle à la livraison

### Synonymes :

N° article et N° produit ont la même signification

### Equivalence à expliciter (clarifier) :

« Nom du client donneur d'ordre » par rapport au « nom client à livrer »

### Informations composées :

Date de la commande : JJ, MM, AA

Adresse de livraison : adresse rue, code postal, nom de ville

### Informations calculées :

Montant commandé = prix unitaire * quantité commandée

Chiffre d'affaires : somme des factures de l'année

### Exemple de MCC :
## 5. Epurer les informations :

Les informations du MCC sont explicitées. La suppression des synonymes (mots ayant la même signification), des poly sèmes (mots ayant plusieurs significations) et la description des règles de calcul, des informations composées ou équivalentes permettent de définir un premier "dictionnaire de données" permettant une clarification et une définition des données. Le vocabulaire utilisé par l'informatique et l'utilisateur ne doit pas contenir d'ambiguïté, il doit être épuré afin d'être mémorisé.

Exemple :

### Commande client

Nom du client donneur d'ordre

Nom du client à livrer

Adresse de livraison

date de la commande

date de la livraison

no article

quantité commandée

prix unitaire

montant commandé

Nom du client : livraison

Nom du client DO : commande

Nom du client à livrer : commande

Adresse de livraison : commande, livraison

date de la commande : commande

date de la livraison : commande, livraison

no article : commande

no produit : livraison

quantité commandée : commande

quantitée livrée : livraison

prix unitaire : commande

montant commandé : commande

### Livraison client

Nom du client

Adresse de livraison

date de la livraison

no produit

quantité livrée

prix unitaire

### Polysème :

La date de la livraison a 2 significations différentes

- date de livraison souhaitée à la commande

- date de livraison réelle à la livraison

### Synonymes :

N° article et N° produit ont la même signification

### Equivalence à expliciter (clarifier) :

« Nom du client donneur d'ordre » par rapport au « nom client à livrer »

### Informations composées :

Date de la commande : JJ, MM, AA

Adresse de livraison : adresse rue, code postal, nom de ville

### Informations calculées :

Montant commandé = prix unitaire * quantité commandée

Chiffre d'affaires : somme des factures de l'année

### Exemple de MCC :
<figure><img src="image_16.png" /><figcaption>MCC simplifié de l'entreprise de livraison</figcaption></figure>

Les flux :

**Avis d'encaissement** : numéro compte bancaire, montant à encaisser, date d'encaissement.

**Bon de livraison** : numéro de bon de livraison, date de livraison, adresse de livraison, nom du client livré, nom du chauffeur.

**Chèque** : numéro chèque, numéro facture, montant du chèque, date chèque.

**Demande de facturation** : numéro de bon de livraison, nom du livreur, référence interne du colis.

**Demande de livraison** : Référence du colis à livrer, date de livraison, adresse de livraison, nom du client.

**Facture** : numéro facture, numéro colis, montant facture HT, montant facture TTC, date de paiement.

**Facture émise** : numéro de client, numéro de facture, date de paiement.

**Ordre de livraison** : numéro d'ordre de livraison, date de livraison, adresse de livraison, nom du client, nom du livreur.

## b. Le modèle conceptuel de données : MCD

Le modèle conceptuel des données est la représentation de l'ensemble des données mémorisables du domaine, sans tenir compte des aspects techniques et économiques du stockage, ni des conditions d'utilisation.

**Deux méthodes pour le définir :**

**A. La démarche déductive** s'appuie sur une liste d'informations à structurer. Cette méthode, suppose la constitution préalable de la liste des informations, en prenant pour base tous les documents disponibles, plus d'autres informations qui ne font pas nécessairement l'objet d'un traitement. L'extraction d'information peut rencontrer différents problèmes :

- **redondance** : une même information figure sur plusieurs documents (ex. le prix unitaire d'un article figure sur le bon de commande et sur la facture).

- **synonymie** : ne pas dupliquer une information sous des appellations différentes.
<figure><img src="image_12.png" /></figure>

Les flux :

**Avis d'encaissement** : numéro compte bancaire, montant à encaisser, date d'encaissement.

**Bon de livraison** : numéro de bon de livraison, date de livraison, adresse de livraison, nom du client livré, nom du chauffeur.

**Chèque** : numéro chèque, numéro facture, montant du chèque, date chèque.

**Demande de facturation** : numéro de bon de livraison, nom du livreur, référence interne du colis.

**Demande de livraison** : Référence du colis à livrer, date de livraison, adresse de livraison, nom du client.

**Facture** : numéro facture, numéro colis, montant facture HT, montant facture TTC, date de paiement.

**Facture émise** : numéro de client, numéro de facture, date de paiement.

**Ordre de livraison** : numéro d'ordre de livraison, date de livraison, adresse de livraison, nom du client, nom du livreur.

## b. Le modèle conceptuel de données : MCD

Le modèle conceptuel des données est la représentation de l'ensemble des données mémorisables du domaine, sans tenir compte des aspects techniques et économiques du stockage, ni des conditions d'utilisation.

Deux méthodes pour le définir :

**A. La démarche déductive** s'appuie sur une liste d'informations à structurer. Cette méthode, suppose la constitution préalable de la liste des informations, en prenant pour base tous les documents disponibles, plus d'autres informations qui ne font pas nécessairement l'objet d'un traitement. L'extraction d'information peut rencontrer différents problèmes :

- **redondance** : une même information figure sur plusieurs documents (ex. le prix unitaire d'un article figure sur le bon de commande et sur la facture).

- **synonymie** : ne pas dupliquer une information sous des appellations différentes.
– *polysémie* : ne pas confondre deux informations exprimées par un même mot avec des significations différentes, (ex. le numéro de client figurant sur une facture du fournisseur n'a rien à voir avec le numéro de client figurant sur une facture produite par l'entreprise).

**B. la démarche inductive** tente de mettre en évidence les concepts du discours (via des interviews par exemple), puis à les décrire par des informations.

## Le schéma entité-association

Le formalisme de représentation final est connu sous le nom de schéma « individus-relations » ou encore «entités-associations ». Ce schéma se retrouve aussi bien dans les méthodes d'analyse de tradition française, telles Merise, que dans les méthodes américaines. Il y a des variantes dans le formalisme et la terminologie, mais on retrouve ce type de modélisation partout.

Ce schéma met en œuvre trois concepts fondamentaux :

<figure><img src="image_17.png" /></figure>

### 1. la propriété-type

Parfois nommée aussi attribut, la propriété type modélise une information élémentaire présente dans le discours. Elle peut prendre des valeurs. Elle peut parfois être composée (se baser sur plusieurs informations distinctes dans l'univers du discours). Notons que la décomposition d'une propriété n'est en principe pas admise. Dans ce cas, il faut distinguer dès le départ plusieurs propriétés distinctes. Les propriétés n'ont pas d'existence indépendante des deux autres concepts (individu et relation).

### 2. l'individu-type

L'individu-type, appelé entité dans d'autres contextes théoriques, permet de modéliser un ensemble d'objets ou d'êtres de même nature, concrets ou abstraits, perçus d'intérêt dans le discours. La détermination des individus obéit aux critères suivants :

(1) pertinence : la distinction entre différents individus-types doit se conformer à la manière de percevoir l'environnement. Par exemple, le fait que certains professeurs puissent être élèves dans l'école où ils enseignent ne doit pas nous amener à confondre les deux individus-types.

(2) identification : chaque occurrence d'un individu doit être distincte, ce qui implique la définition d'un identifiant, c'est-à-dire une ou plusieurs propriétés dont les valeurs déterminent une seule occurrence d'individu. L'identifiant n'est pas toujours facile à déterminer.

Ce peut être une propriété « naturelle » (le nom dans un ensemble de petite taille), une propriété artificielle (souvent un numéro ou un code inventé exprès), une propriété composée (par exemple nom + prénom) ou encore un identifiant relatif (présence d'un numéro d'ordre).
– *polysémie* : ne pas confondre deux informations exprimées par un même mot avec des significations différentes, (ex. le numéro de client figurant sur une facture du fournisseur n'a rien à voir avec le numéro de client figurant sur une facture produite par l'entreprise).

**B. la démarche inductive** tente de mettre en évidence les concepts du discours (via des interviews par exemple), puis à les décrire par des informations.

## Le schéma entité-association

Le formalisme de représentation final est connu sous le nom de schéma « individus-relations » ou encore «entités-associations ». Ce schéma se retrouve aussi bien dans les méthodes d'analyse de tradition française, telles Merise, que dans les méthodes américaines. Il y a des variantes dans le formalisme et la terminologie, mais on retrouve ce type de modélisation partout.

Ce schéma met en œuvre trois concepts fondamentaux :

<figure><img src="image_13.png" /></figure>

### 1. la propriété-type

Parfois nommée aussi attribut, la propriété type modélise une information élémentaire présente dans le discours. Elle peut prendre des valeurs. Elle peut parfois être composée (se baser sur plusieurs informations distinctes dans l'univers du discours). Notons que la décomposition d'une propriété n'est en principe pas admise. Dans ce cas, il faut distinguer dès le départ plusieurs propriétés distinctes. Les propriétés n'ont pas d'existence indépendante des deux autres concepts (individu et relation).

### 2. l'individu-type

L'individu-type, appelé entité dans d'autres contextes théoriques, permet de modéliser un ensemble d'objets ou d'êtres de même nature, concrets ou abstraits, perçus d'intérêt dans le discours. La détermination des individus obéit aux critères suivants :

(1) pertinence : la distinction entre différents individus-types doit se conformer à la manière de percevoir l'environnement. Par exemple, le fait que certains professeurs puissent être élèves dans l'école où ils enseignent ne doit pas nous amener à confondre les deux individus-types.

(2) identification : chaque occurrence d'un individu doit être distincte, ce qui implique la définition d'un identifiant, c'est-à-dire une ou plusieurs propriétés dont les valeurs déterminent une seule occurrence d'individu. L'identifiant n'est pas toujours facile à déterminer.

Ce peut être une propriété « naturelle » (le nom dans un ensemble de petite taille), une propriété artificielle (souvent un numéro ou un code inventé exprès), une propriété composée (par exemple nom + prénom) ou encore un identifiant relatif (présence d'un numéro d'ordre).
(3) « distinguabilité » : deux occurrences d'un même individu doivent être distinguables. Le problème se pose quand on doit gérer des objets réels reproduits à plusieurs exemplaires (livres, véhicules...). Dans ce cas, il faut choisir l'identifiant avec soin. Souvent, le fabriquant anticipe ce problème en posant un numéro de série sur l'objet. Quand le numéro de série n'existe pas, on doit l'inventer (le numéro d'inventaire dans une bibliothèque).

Parfois, des objets de la réalité ne peuvent pas constituer des entités (des clous ou des vis ne peuvent être distingués individuellement).

(4) non-répétitivité : l'individu est décrit par ses propriétés, mais il ne peut pas y avoir plusieurs valeurs pour une des propriétés. Si c'est le cas, cette propriété n'appartient pas à l'individu type. L'exemple habituel est le numéro de téléphone. Une personne peut avoir plusieurs numéros de téléphone (maison, bureau, portable ou résidence secondaire). On pourra employer une autre entité et une association pour rendre compte de cette situation.

(5) homogénéité : il est recommandé que les propriétés aient un sens pour tous les occurrences des individus types. On peut déroger à cette règle, mais son non-respect signifie souvent qu'on a artificiellement regroupé sous un même individu-type des populations appartenant en fait à plusieurs.

### 3. La relation-type

Elle représente des associations entre plusieurs individus-types. Elle se caractérise par :

(1) sa dimension : on entend par là le nombre d'individus-types avec lesquels elle s'associe. En pratique, les relations binaires sont les plus fréquentes. Une relation de dimension supérieure à 6 est exceptionnelle (c'est dû à l'incapacité de l'esprit humain de concevoir plus de 6 objets simultanés).

(2) sa collection d'individus-types : une relation-type s'associe avec des individus-types, qu'on nomme sa collection. Notons qu'à une même collection peuvent correspondre plusieurs relations-types (ex. Personne et Logement peuvent s'associer dans les relations posséder et occuper).

(3) la cardinalité de chacun de ses individus-types : elle s'exprime à l'aide de deux nombres. Le premier indique le nombre minimal d'occurrences d'un individu dans une relation (c'est généralement 0 ou 1), le second prévoit le nombre maximal d'occurrences (c'est 1 ou N). D'autres valeurs que 0 ou 1 sont possibles, mais rarement rencontrées (et peu intéressantes à préciser). Il est sans intérêt, à ce niveau, de chercher à donner une valeur précise à N

<table><thead><tr><td>Participation</td><td>optionnelle</td><td>obligatoire</td></tr></thead><tbody><tr><td>unique</td><td>0,1</td><td>1,1</td></tr><tr><td>multiple</td><td>0,N</td><td>1,N</td></tr></tbody></table>

(4) son absence d'identifiant propre : une relation compose les identifiants des individus types qu'elle associe pour se composer son propre identifiant. Cet identifiant n'est donc jamais noté.

(5) ses propriétés ou son absence de propriétés : certaines propriétés s'attachent à la relation type.
(3) « distinguabilité » : deux occurrences d'un même individu doivent être distinguables. Le problème se pose quand on doit gérer des objets réels reproduits à plusieurs exemplaires (livres, véhicules...). Dans ce cas, il faut choisir l'identifiant avec soin. Souvent, le fabriquant anticipe ce problème en posant un numéro de série sur l'objet. Quand le numéro de série n'existe pas, on doit l'inventer (le numéro d'inventaire dans une bibliothèque).

Parfois, des objets de la réalité ne peuvent pas constituer des entités (des clous ou des vis ne peuvent être distingués individuellement).

(4) non-répétitivité : l'individu est décrit par ses propriétés, mais il ne peut pas y avoir plusieurs valeurs pour une des propriétés. Si c'est le cas, cette propriété n'appartient pas à l'individu type. L'exemple habituel est le numéro de téléphone. Une personne peut avoir plusieurs numéros de téléphone (maison, bureau, portable ou résidence secondaire). On pourra employer une autre entité et une association pour rendre compte de cette situation.

(5) homogénéité : il est recommandé que les propriétés aient un sens pour tous les occurrences des individus types. On peut déroger à cette règle, mais son non-respect signifie souvent qu'on a artificiellement regroupé sous un même individu-type des populations appartenant en fait à plusieurs.

### 3. La relation-type

Elle représente des associations entre plusieurs individus-types. Elle se caractérise par :

(1) sa dimension : on entend par là le nombre d'individus-types avec lesquels elle s'associe. En pratique, les relations binaires sont les plus fréquentes. Une relation de dimension supérieure à 6 est exceptionnelle (c'est dû à l'incapacité de l'esprit humain de concevoir plus de 6 objets simultanés).

(2) sa collection d'individus-types : une relation-type s'associe avec des individus-types, qu'on nomme sa collection. Notons qu'à une même collection peuvent correspondre plusieurs relations-types (ex. Personne et Logement peuvent s'associer dans les relations posséder et occuper).

(3) la cardinalité de chacun de ses individus-types : elle s'exprime à l'aide de deux nombres. Le premier indique le nombre minimal d'occurrences d'un individu dans une relation (c'est généralement 0 ou 1), le second prévoit le nombre maximal d'occurrences (c'est 1 ou N). D'autres valeurs que 0 ou 1 sont possibles, mais rarement rencontrées (et peu intéressantes à préciser). Il est sans intérêt, à ce niveau, de chercher à donner une valeur précise à N

<table><thead><tr><td>Participation</td><td>optionnelle</td><td>obligatoire</td></tr></thead><tbody><tr><td>unique</td><td>0,1</td><td>1,1</td></tr><tr><td>multiple</td><td>0,N</td><td>1,N</td></tr></tbody></table>

(4) son absence d'identifiant propre : une relation compose les identifiants des individus types qu'elle associe pour se composer son propre identifiant. Cet identifiant n'est donc jamais noté.

(5) ses propriétés ou son absence de propriétés : certaines propriétés s'attachent à la relation type.
Par exemple, la relation acheter entre un client et un produit peut avoir un montant de remise comme propriété. Notons que dans bien des cas, une relation-type n'a pas de propriétés.

## Exemple de modèle simple

Dans notre exemple, nous allons considérer un schéma réduit de la représentation d'une école. Deux entités s'imposent : les étudiants et les formations (nous laissons de côté les professeurs dans notre exemple).

Chaque étudiant aura un nom, un prénom, une date de naissance, une adresse, un code postal et une localité ; chaque formation un nom, une durée, une date de début, un jour et une heure (dans l'hypothèse d'une fréquence hebdomadaire).

La relation S'Inscrire va relier nos deux entités. Si on veut y placer une propriété, on pourra penser à la date d'inscription. Il est intéressant de noter le traitement asymétrique de la cardinalité :

<figure><img src="image_18.png" /><figcaption>FIG. 5.1 – Inscription d'un étudiant</figcaption></figure>

<table><thead><tr><th></th><th>Étudiant</th><th>Formation</th></tr></thead><tbody><tr><td>Cardinalité minimale</td><td>I : un étudiant doit avoir au moins une inscription (si une personne n'a pas d'inscription, elle ne fera pas partie de notre système).</td><td>O : une formation peut ne pas avoir d'étudiant.</td></tr><tr><td>Cardinalité maximale</td><td>N : un étudiant peut s'inscrire à plusieurs formations.</td><td>N : une formation peut se donner à plusieurs étudiants (c'est souhaitable :-) !)</td></tr></tbody></table>

Exercice :

- Représenter des acteurs jouant dans des films.

- Représenter les voitures et leurs propriétaires.

- Représenter les logements, leurs propriétaires et leurs locataires.

- Représenter le personnel d'une entreprise ayant plusieurs services. Chaque service possède un chef de service.
Par exemple, la relation acheter entre un client et un produit peut avoir un montant de remise comme propriété.
Notons que dans bien des cas, une relation-type n'a pas de propriétés.

## Exemple de modèle simple

Dans notre exemple, nous allons considérer un schéma réduit de la représentation d'une école. Deux entités s'imposent : les étudiants et les formations (nous laissons de côté les professeurs dans notre exemple).

Chaque étudiant aura un nom, un prénom, une date de naissance, une adresse, un code postal et une localité ; chaque formation un nom, une durée, une date de début, un jour et une heure (dans l'hypothèse d'une fréquence hebdomadaire).

La relation S'Inscrire va relier nos deux entités. Si on veut y placer une propriété, on pourra penser à la date d'inscription. Il est intéressant de noter le traitement asymétrique de la cardinalité :

<figure><img src="image_14.png" /><figcaption>FIG. 5.1 – Inscription d'un étudiant</figcaption></figure>

<table><thead><tr><th></th><th>Étudiant</th><th>Formation</th></tr></thead><tbody><tr><td>Cardinalité minimale</td><td>I : un étudiant doit avoir au moins une inscription (si une personne n'a pas d'inscription, elle ne fera pas partie de notre système).</td><td>O : une formation peut ne pas avoir d'étudiant.</td></tr><tr><td>Cardinalité maximale</td><td>N : un étudiant peut s'inscrire à plusieurs formations.</td><td>N : une formation peut se donner à plusieurs étudiants (c'est souhaitable :-) !)</td></tr></tbody></table>

Exercice :

- Représenter des acteurs jouant dans des films.

- Représenter les voitures et leurs propriétaires.

- Représenter les logements, leurs propriétaires et leurs locataires.

- Représenter le personnel d'une entreprise ayant plusieurs services. Chaque service possède un chef de service.
## Conseils pour la création des modèles

Le modèle entités/relations est profondément lié à la représentation du monde à travers le langage. De nombreuses théories linguistiques ont mis en avant l'existence de verbes, qui correspondent aux relations, caractérisés par leur dimension :

- les verbes de dimension 0 et 1 n'ont pas d'équivalent dans le modèle E/R et correspondent respectivement aux verbes impersonnels (qui ne peuvent avoir de vrai sujet, comme il pleut), et aux verbes intransitifs (Nadia pleure).

- les verbes de dimension 2 sont les plus fréquents et associent un sujet à son complément : (l'étudiant lit un livre, le professeur parle à ses étudiants).

- les verbes de dimension 3, déjà plus rares, ont deux compléments associés à leur sujet (un responsable offre une prime à son employé, le représentant discute des prix avec son client).

- il n'existe pas de verbes de dimension 4, mais des procédés syntaxiques permettent d'en créer : (les dirigeants ont fait envoyer des lettres de menaces à leurs opposants par des agents secrets).

Le cerveau humain normal a du mal à concevoir plus de six objets simultanés. Un verbe de dimension 5 atteindrait déjà cette limite (5 entités + la relation). En théorie, la modélisation pourrait dépasser ces limites, mais elle poserait des problèmes de compréhension rapidement insupportables

## Transformation des phrases en modèle

Chaque phrase apporte une information sur le modèle à construire. La technique consiste à faire correspondre des mots avec des entités, des associations et des propriétés. Il existe quelques règles empiriques qui peuvent aider l'analyste. Nous allons examiner les différentes catégories de mots.

### Nom commun

Très souvent le nom commun représente une entité. C'est particulièrement vrai lorsqu'il remplit une fonction de sujet ou de complément du verbe. Voici quelques exemples :

- les clients effectuent des commandes

- les étudiants s'inscrivent à des cours

Lorsque le nom possède un complément déterminatif, il s'agit le plus souvent d'une propriété :

- le montant d'une facture se calcule en faisant la somme des articles et de la TVA.

- la couleur de la voiture est mentionnée sur le bon de commande.

- le salaire de Sofiane est de 25.000 DA (Sofiane est un employé).

### Nom propre

Le cas du nom propre est plus complexe. Dans la plupart des cas, il représente des occurrences d'entité (notamment dans des exemples). Il figurera éventuellement comme valeur de propriété. Certains noms propres disparaîtront purement et simplement :

- les clients s'adressent à la SNTF pour transporter des marchandises (c'est le nom de la société)
## Conseils pour la création des modèles

Le modèle entités/relations est profondément lié à la représentation du monde à travers le langage. De nombreuses théories linguistiques ont mis en avant l'existence de verbes, qui correspondent aux relations, caractérisés par leur dimension :

- les verbes de dimension 0 et 1 n'ont pas d'équivalent dans le modèle E/R et correspondent respectivement aux verbes impersonnels (qui ne peuvent avoir de vrai sujet, comme il pleut), et aux verbes intransitifs (Nadia pleure).

- les verbes de dimension 2 sont les plus fréquents et associent un sujet à son complément : (l'étudiant lit un livre, le professeur parle à ses étudiants).

- les verbes de dimension 3, déjà plus rares, ont deux compléments associés à leur sujet (un responsable offre une prime à son employé, le représentant discute des prix avec son client).

- il n'existe pas de verbes de dimension 4, mais des procédés syntaxiques permettent d'en créer : (les dirigeants ont fait envoyer des lettres de menaces à leurs opposants par des agents secrets).

Le cerveau humain normal a du mal à concevoir plus de six objets simultanés. Un verbe de dimension 5 atteindrait déjà cette limite (5 entités + la relation). En théorie, la modélisation pourrait dépasser ces limites, mais elle poserait des problèmes de compréhension rapidement insupportables

## Transformation des phrases en modèle

Chaque phrase apporte une information sur le modèle à construire. La technique consiste à faire correspondre des mots avec des entités, des associations et des propriétés. Il existe quelques règles empiriques qui peuvent aider l'analyste. Nous allons examiner les différentes catégories de mots.

### Nom commun

Très souvent le nom commun représente une entité. C'est particulièrement vrai lorsqu'il remplit une fonction de sujet ou de complément du verbe. Voici quelques exemples :

- les clients effectuent des commandes

- les étudiants s'inscrivent à des cours

Lorsque le nom possède un complément déterminatif, il s'agit le plus souvent d'une propriété :

- le montant d'une facture se calcule en faisant la somme des articles et de la TVA.

- la couleur de la voiture est mentionnée sur le bon de commande.

- le salaire de Sofiane est de 25.000 DA (Sofiane est un employé).

### Nom propre

Le cas du nom propre est plus complexe. Dans la plupart des cas, il représente des occurrences d'entité (notamment dans des exemples). Il figurera éventuellement comme valeur de propriété. Certains noms propres disparaîtront purement et simplement :

- les clients s'adressent à la SNTF pour transporter des marchandises (c'est le nom de la société)
- *Mr. Mokhtar* expédie les factures tous les 25 du mois (il s'agit d'une règle de gestion)

## Verbe transitif

Le verbe transitif s'accompagne d'un sujet et d'un ou plusieurs compléments. Il correspond à une relation.

- les clients *achètent* des marchandises

## Adjectif

En général, l'adjectif correspond à une valeur de propriété ou à une propriété s'il possède un complément :

- les employés *mariés* peuvent souscrire une assurance pour leur conjoint (propriété état civil).

- les personnes âgées de plus de 40 ans ne peuvent plus suivre ce type de formation (propriété âge)

# Compléments au MCD

## Modélisation du temps

Dans notre étude des différents exemples, nous avons explicitement exclu la dimension temporelle. Nous la reprenons ici dans une perspective globale qui expose différents traitements du temps.

### a) le temps comme propriété

Si on veut indiquer le moment qui caractérise un événement lié à une entité ou à une propriété, on va traiter le temps comme une simple propriété. Exemples :

- date de naissance d'un individu (propriété d'entité)

- date de facturation (propriété d'entité)

- date d'inscription d'un étudiant dans une section (propriété de relation)

### b) le temps comme entité

Dans des cas plus rares, on va considérer le temps comme une entité (dont les occurrences se suivront avec une périodicité fixe : tous les mois, toutes les semaines...). On pourra par exemple établir une relation entre une entité client et une entité mois pour mémoriser le chiffre d'affaires des clients.

### c) historisation

Ce terme un peu barbare désigne la conservation des valeurs successives d'une propriété. Elle ne doit pas être confondue avec l'archivage. L'archivage consiste à effectuer une copie de données qui sont retirées de la mémoire immédiate. Par exemple, un client qui n'a plus effectué d'achat sera retiré de la liste des clients au terme d'un nombre de mois fixé et enregistré dans les archives. Ici, il s'agit, pour une donnée qui reste en mémoire immédiate, de conserver un nombre fixé de valeurs anciennes. C'est ainsi qu'on pourra historier l'adresse d'une personne. Cette historisation prend en compte deux paramètres : la datation va stipuler avec la précision avec laquelle la date sera mémorisée (par exemple par mois, dans ce cas un deuxième changement d'adresse dans un même mois entraînera l'effacement du premier changement) ; la profondeur va stipuler le nombre d'anciennes valeurs conservées (par exemple les cinq dernières adresses).
- *Mr. Mokhtar* expédie les factures tous les 25 du mois (il s'agit d'une règle de gestion)

## Verbe transitif

Le verbe transitif s'accompagne d'un sujet et d'un ou plusieurs compléments. Il correspond à une relation.

- les clients *achètent* des marchandises

## Adjectif

En général, l'adjectif correspond à une valeur de propriété ou à une propriété s'il possède un complément :

- les employés *mariés* peuvent souscrire une assurance pour leur conjoint (propriété état civil).

- les personnes âgées de plus de 40 ans ne peuvent plus suivre ce type de formation (propriété âge)

# Compléments au MCD

## Modélisation du temps

Dans notre étude des différents exemples, nous avons explicitement exclu la dimension temporelle. Nous la reprenons ici dans une perspective globale qui expose différents traitements du temps.

### a) le temps comme propriété

Si on veut indiquer le moment qui caractérise un événement lié à une entité ou à une propriété, on va traiter le temps comme une simple propriété. Exemples :

- date de naissance d'un individu (propriété d'entité)

- date de facturation (propriété d'entité)

- date d'inscription d'un étudiant dans une section (propriété de relation)

### b) le temps comme entité

Dans des cas plus rares, on va considérer le temps comme une entité (dont les occurrences se suivront avec une périodicité fixe : tous les mois, toutes les semaines...). On pourra par exemple établir une relation entre une entité client et une entité mois pour mémoriser le chiffre d'affaires des clients.

### c) historisation

Ce terme un peu barbare désigne la conservation des valeurs successives d'une propriété. Elle ne doit pas être confondue avec l'archivage. L'archivage consiste à effectuer une copie de données qui sont retirées de la mémoire immédiate. Par exemple, un client qui n'a plus effectué d'achat sera retiré de la liste des clients au terme d'un nombre de mois fixé et enregistré dans les archives. Ici, il s'agit, pour une donnée qui reste en mémoire immédiate, de conserver un nombre fixé de valeurs anciennes. C'est ainsi qu'on pourra historier l'adresse d'une personne. Cette historisation prend en compte deux paramètres : la datation va stipuler avec la précision avec laquelle la date sera mémorisée (par exemple par mois, dans ce cas un deuxième changement d'adresse dans un même mois entraînera l'effacement du premier changement) ; la profondeur va stipuler le nombre d'anciennes valeurs conservées (par exemple les cinq dernières adresses).
L'historisation se fait également au moyen d'une entité date, cette fois sans régularité. On va dupliquer la propriété, qui apparaîtra une fois à sa place normale dans l'entité et autant de fois que nécessaire dans une relation entre l'entité et la date.

### c. Modèle Conceptuel des Traitements

## Construction du MCT

<figure><img src="image_19.png" /></figure>

A partir du MCC, nous recensons les événements en entrée et les événements en sortie. Il suffit d'ajouter les opérations enclenchées par les événements en entrée et dont les résultats sont les événements en sortie.
Les règles de gestion des opérations orientent la production des résultats, par exemple si le client n'est pas solvable, sa demande de domiciliation est refusée.

S'il y a plusieurs événements en entrée, la synchronisation (triangle inversé) souvent exprimée sous forme d'une expression booléenne (avec des opérateurs logiques : et, ou, non) gère l'aboutissement de l'exécution de l'opération.

Donc, pour récapituler : événement(s) en entrée (ellipse), synchronisation (triangle inversé), opération (rectangle), règles de gestion (si aucune, écrire toujours, si booléen : écrire OK ou OK barre), évènement(s) en sortie (ellipse).
L'historisation se fait également au moyen d'une entité date, cette fois sans régularité. On va dupliquer la propriété, qui apparaîtra une fois à sa place normale dans l'entité et autant de fois que nécessaire dans une relation entre l'entité et la date.

### c. Modèle Conceptuel des Traitements

## Construction du MCT

<figure><img src="image_15.png" /></figure>

A partir du MCC, nous recensons les événements en entrée et les événements en sortie. Il suffit d'ajouter les opérations enclenchées par les événements en entrée et dont les résultats sont les événements en sortie.
Les règles de gestion des opérations orientent la production des résultats, par exemple si le client n'est pas solvable, sa demande de domiciliation est refusée.

S'il y a plusieurs événements en entrée, la synchronisation (triangle inversé) souvent exprimée sous forme d'une expression booléenne (avec des opérateurs logiques : et, ou, non) gère l'aboutissement de l'exécution de l'opération.

Donc, pour récapituler : événement(s) en entrée (ellipse), synchronisation (triangle inversé), opération (rectangle), règles de gestion (si aucune, écrire toujours, si booléen : écrire OK ou OK barre), évènement(s) en sortie (ellipse).
<figure><img src="image_20.png" /></figure>

Autre exemple :

<figure><img src="image_21.png" /></figure>
<figure><img src="image_16.png" /></figure>

Autre exemple :

<figure><img src="image_17.png" /></figure>
**Remarque importante :**

A la fin de chaque niveau de la méthode Merise/2 (conceptuel, organisationnel, logique et physique), le concepteur du système d'information procède à une validation des modèles entre eux et cela dans le but d'obtenir des modèles corrects et cohérents.

**Validation à la fin du niveau conceptuel :**

En fait, il s'agit de valider le MCD avec les deux autres modèles du même niveau (MCC, MCT) :

1. Validation du MCD avec les messages du MCC

2. Validation du MCD avec les traitements du MCT

<figure><img src="image_22.png" /></figure>

**1. Validation MCD/MCC :**

Il s'agit de mettre en accord les informations extraites des messages (MCC) et les informations (les propriétés) du MCD.

<figure><img src="image_23.png" /></figure>

Certaines informations dans les messages ne seront jamais dans le modèle de données par choix de l'utilisateur. Les autres se retrouvent dans le modèle de données (individus et relations) soit telles quelles (sans subir de changements), soit via une équivalence (synonymes), soit via une règle de calcul.

Exemple de règle de calcul : Montant avec TVA=montant hors TVA *(1+taux TVA)

Montant en devise= montant en DA * taux de change de la devise
**Remarque importante :**

A la fin de chaque niveau de la méthode Merise/2 (conceptuel, organisationnel, logique et physique), le concepteur du système d'information procède à une validation des modèles entre eux et cela dans le but d'obtenir des modèles corrects et cohérents.

**Validation à la fin du niveau conceptuel :**

En fait, il s'agit de valider le MCD avec les deux autres modèles du même niveau (MCC, MCT) :

1. Validation du MCD avec les messages du MCC

2. Validation du MCD avec les traitements du MCT

<figure><img src="image_18.png" /></figure>

**1. Validation MCD/MCC :**

Il s'agit de mettre en accord les informations extraites des messages (MCC) et les informations (les propriétés) du MCD.

<figure><img src="image_19.png" /></figure>

Certaines informations dans les messages ne seront jamais dans le modèle de données par choix de l'utilisateur. Les autres se retrouvent dans le modèle de données (individus et relations) soit telles quelles (sans subir de changements), soit via une équivalence (synonymes), soit via une règle de calcul.

Exemple de règle de calcul : Montant avec TVA=montant hors TVA *(1+taux TVA)

Montant en devise= montant en DA * taux de change de la devise
Dans le modèle conceptuel de données, aucune information ne peut être à la fois dans le modèle (portée par un individu ou une relation) et déduite des informations du modèle. Pour chaque règle de calcul, les informations en entrée et les informations en sortie ne peuvent être ensemble dans le modèle.

En résumé, pas de propriétés calculées dans le MCD, sauf dans des cas où la propriété calculée est nécessaire pour la compréhension du modèle.

## 2. Validation MCD/MCT

* Toute information du MCD doit être **créée et consultée** par une opération du MCT.

* Toute opération du MCT doit avoir dans le MCD les informations nécessaires à son fonctionnement :
  A chaque opération du modèle de traitement correspondent **une ou deux vues du modèle de données**.
  Une vue représente **le modèle en lecture ou en consultation**. Exemples : Quels sont les clients de telle entreprise ? Quelle est l'adresse du client X ?
  Une autre vue représente **le modèle en mise à jour** (création, modification, suppression), c'est-à-dire, en **création ou en écriture** : exemple création d'un nouveau client, modification de son adresse, suppression d'un employé (cas de décès, cas de retraite ou cas de licenciement).

**Remarque :** L'étude menée au niveau conceptuel (les trois modèles), doit être approuvée ou validée par l'utilisateur final avant d'entamer l'étape suivante qui consiste en la prise en compte des aspects organisationnels.

## 3. Le Niveau Organisationnel :

### a. Le Modèle Organisationnel des Traitements : MOT

Le modèle conceptuel des traitements a permis de décomposer un processus en opérations décrivant ainsi l'ensemble de l'activité de l'entreprise.

Cette description doit être maintenant complétée par la prise en considération de l'organisation choisie par l'entreprise. Trois préoccupations sont prises en considération :

- L'affectation des traitements aux **postes de travail (Qui, Où)**;

- Le **type de traitement** en termes d'**automatisation** qui peut être soit manuel soit automatisé<fnref n="5" /> (**Comment**);

- L'aspect **temporel** des opérations organisées (**Quand**).

Le modèle organisationnel des traitements (MOT) permet de représenter l'ensemble des traitements en prenant en compte l'**organisation de l'entreprise**. Cette organisation sera matérialisée par les postes de travail. Chaque poste de travail correspond à une unité de travail d'action élémentaire.

<footnote n="5">⁵ Automatisé veut dire que l'action est réalisée par l'application (le software).</footnote>
Dans le modèle conceptuel de données, aucune information ne peut être à la fois dans le modèle (portée par un individu ou une relation) et déduite des informations du modèle. Pour chaque règle de calcul, les informations en entrée et les informations en sortie ne peuvent être ensemble dans le modèle.

En résumé, pas de propriétés calculées dans le MCD, sauf dans des cas où la propriété calculée est nécessaire pour la compréhension du modèle.

## 2. Validation MCD/MCT

* Toute information du MCD doit être **créée et consultée** par une opération du MCT.

* Toute opération du MCT doit avoir dans le MCD les informations nécessaires à son fonctionnement :
  A chaque opération du modèle de traitement correspondent **une ou deux vues du modèle de données**.
  Une vue représente **le modèle en lecture ou en consultation**. Exemples : Quels sont les clients de telle entreprise ? Quelle est l'adresse du client X ?
  Une autre vue représente **le modèle en mise à jour** (création, modification, suppression), c'est-à-dire, en **création ou en écriture** : exemple création d'un nouveau client, modification de son adresse, suppression d'un employé (cas de décès, cas de retraite ou cas de licenciement).

**Remarque** : L'étude menée au niveau conceptuel (les trois modèles), doit être approuvée ou validée par l'utilisateur final avant d'entamer l'étape suivante qui consiste en la prise en compte des aspects organisationnels.

## 3. Le Niveau Organisationnel :

### a. Le Modèle Organisationnel des Traitements : MOT

Le modèle conceptuel des traitements a permis de décomposer un processus en opérations décrivant ainsi l'ensemble de l'activité de l'entreprise.

Cette description doit être maintenant complétée par la prise en considération de l'organisation choisie par l'entreprise. Trois préoccupations sont prises en considération :

- L'affectation des traitements aux **postes de travail (Qui, Où)**;

- Le **type de traitement** en termes d'**automatisation** qui peut être soit manuel soit automatisé<fnref n="5" /> (**Comment**);

- L'aspect **temporel** des opérations organisées (**Quand**).

Le modèle organisationnel des traitements (MOT) permet de représenter l'ensemble des traitements en prenant en compte l'**organisation de l'entreprise**. Cette organisation sera matérialisée par les postes de travail. Chaque poste de travail correspond à une unité de travail d'action élémentaire.

<footnote n="5">⁵ Automatisé veut dire que l'action est réalisée par l'application (le software).</footnote>
A chaque **opération** du niveau conceptuel correspondra une ou plusieurs **phases** su MOT.

Une succession de **phases** appartenant à un même processus s'appellera **procédure**.

## 1er niveau : La Procédure :

A chaque processus du MCT correspondra une ou plusieurs procédures, elle est constituée d'un ensemble de traitements est déclenchée soit par des messages déclencheurs ou par des temporisateurs (ex : fin d'année, fin de mois, fin de semaine, fin de journée...). Exemples de procédures : procédure de recrutement, procédure de traitement de commandes.

Une procédure appartient à un et à un seul processus.

## 2ème niveau : La Phase :

Sous-ensemble de la procédure, la phase est une suite non interrompue de traitements, de même périodicité, exécutés par un même poste de travail.

Exemple :

Pour la procédure de recrutement, nous pouvons détecter les phases suivantes :

- Phase 1 : Enregistrement de la demande d'embauche

- Phase 2 : Contrôle du dossier de candidature

- Phase 3 : Saisie de la convocation pour interview

- Phase 4 : Edition de la convocation

Chaque phase est exécutée par un seul poste de travail.

**Récapitulons :** le découpage de la procédure en phases est provoqué soit par un changement de temps ou un changement de poste de travail.

### 3ème niveau : La Tâche : une tâche représente un ensemble de traitements élémentaires exécutés à l'intérieur d'une phase. Une phase peut comprendre une ou plusieurs tâches.

**Remarque :** le formalisme utilisé pour représenter le MOT est le même formalisme utilisé pour représenter le MCT (événements déclencheurs, synchronisation, règles d'émission et événements résultats).

**Exemple :** passer du MCT au MOT du cas : Sélection de candidats à l'entrée d'une Grande Ecole payante.

**Notion de site :**

C'est un regroupement fonctionnel et/ou géographique de types d'acteurs dans une structure de référence.
A chaque **opération** du niveau conceptuel correspondra une ou plusieurs **phases** su MOT.

Une succession de **phases** appartenant à un même processus s'appellera **procédure**.

**1er niveau : La Procédure :**

A chaque processus du MCT correspondra une ou plusieurs procédures, elle est constituée d'un ensemble de traitements est déclenchée soit par des messages déclencheurs ou par des temporisateurs (ex : fin d'année, fin de mois, fin de semaine, fin de journée...). Exemples de procédures : procédure de recrutement, procédure de traitement de commandes.

Une procédure appartient à un et à un seul processus.

**2ème niveau : La Phase :**

Sous-ensemble de la procédure, la phase est une suite non interrompue de traitements, de même périodicité, exécutés par un même poste de travail.

Exemple :

Pour la procédure de recrutement, nous pouvons détecter les phases suivantes :

- Phase 1 : Enregistrement de la demande d'embauche

- Phase 2 : Contrôle du dossier de candidature

- Phase 3 : Saisie de la convocation pour interview

- Phase 4 : Edition de la convocation

Chaque phase est exécutée par un seul poste de travail.

**Récapitulons :** le découpage de la procédure en phases est provoqué soit par un changement de temps ou un changement de poste de travail.

**3ème niveau : La Tâche :** une tâche représente un ensemble de traitements élémentaires exécutés à l'intérieur d'une phase. Une phase peut comprendre une ou plusieurs tâches.

**Remarque :** le formalisme utilisé pour représenter le MOT est le même formalisme utilisé pour représenter le MCT (événements déclencheurs, synchronisation, règles d'émission et événements résultats).

**Exemple :** passer du MCT au MOT du cas : Sélection de candidats à l'entrée d'une Grande Ecole payante.

**Notion de site :**

C'est un regroupement fonctionnel et/ou géographique de types d'acteurs dans une structure de référence.
**Exemple** : le même site géographique peut regrouper à la fois le site du siège (la direction) et le site d'une agence (une antenne ou une succursale), donc il s'agira dans ce cas de considérer deux sites plutôt qu'un seul site car ces deux structures ne remplissent pas les mêmes fonctions.

## b. Le Modèle Organisationnel des Données : MOD

Le modèle organisationnel des données permet de définir quelles informations seront stockées dans quel site ?

Cette découpe par site, construite à partir du MCD global permet de conserver la cohérence, de maîtriser la "redondance" d'information entre site et détermine les consolidations de données éventuelles (au niveau central, ex : le siège ou la direction d'une entreprise).

Ce découpage permet de calculer les volumes de données nécessaires par site de données final. Ce calcul de volume des données est de moins en moins nécessaire suite à l'augmentation rapide des capacités de stockage.

Pour chaque base de données, un modèle organisationnel de données (MOD) est construit. Ces modèles organisationnels de données sont des vues externes du modèle principal (MCD) correspondant à chaque site.

Autrement dit, 1 site= 1 MOD (le MCD spécifique de ce site)

Pour le MOD, on doit déterminer exactement quelles sont les informations exactes à conserver (nécessaire pour le fonctionnement du site concerné). On va donc ajouter des entités ou des relations ou au contraire en supprimer, en fonction des besoins du site en termes de données manipulées.

**Exemple** : soit une entreprise de livraison constituée d'un **siège social**, d'un **entrepôt** et d'agences.

**Le siège** qui s'occupe de tous les clients et de toutes les factures aura **le modèle général** :

<figure><img src="image_24.png" /></figure>

**L'entrepôt** ne s'occupe que de la livraison à partir des ventes et possède **un modèle sans contrat ni facture**.
**Exemple** : le même site géographique peut regrouper à la fois le site du siège (la direction) et le site d'une agence (une antenne ou une succursale), donc il s'agira dans ce cas de considérer deux sites plutôt qu'un seul site car ces deux structures ne remplissent pas les mêmes fonctions.

## b. Le Modèle Organisationnel des Données : MOD

Le modèle organisationnel des données permet de définir quelles informations seront stockées dans quel site ?

Cette découpe par site, construite à partir du MCD global permet de conserver la cohérence, de maîtriser la "redondance" d'information entre site et détermine les consolidations de données éventuelles (au niveau central, ex : le siège ou la direction d'une entreprise).

Ce découpage permet de calculer les volumes de données nécessaires par site de données final. Ce calcul de volume des données est de moins en moins nécessaire suite à l'augmentation rapide des capacités de stockage.

Pour chaque base de données, un modèle organisationnel de données (MOD) est construit. Ces modèles organisationnels de données sont des vues externes du modèle principal (MCD) correspondant à chaque site.

Autrement dit, 1 site= 1 MOD (le MCD spécifique de ce site)

Pour le MOD, on doit déterminer exactement quelles sont les informations exactes à conserver (nécessaire pour le fonctionnement du site concerné). On va donc ajouter des entités ou des relations ou au contraire en supprimer, en fonction des besoins du site en termes de données manipulées.

**Exemple** : soit une entreprise de livraison constituée d'un **siège social**, d'un **entrepôt** et d'agences.

**Le siège** qui s'occupe de tous les clients et de toutes les factures aura le modèle général :

<figure><img src="image_20.png" /></figure>

**L'entrepôt** ne s'occupe que de la livraison à partir des ventes et possède un modèle sans contrat ni facture.
<figure><img src="image_25.png" /></figure>

Une agence n'effectue que les livraisons et les factures et a un modèle sans contrat.

<figure><img src="image_26.png" /></figure>

### c. Le Modèle Organisationnel de Communication : MOC

#### Exemples de traitements nécessitant des échanges de lecture/écriture entre sites :

Dans les exemples qui suivent, déterminer les opérations de lecture / écriture ainsi que les sites impliqués dans ces échanges :

* Saisie des commandes au service approvisionnement avec édition en fin de journée des bons de livraison au service stock

* Consultation des comptes client des différentes agences au niveau du siège de la banque

* Saisie des E/S<fnref n="6" /> avec mise à jour immédiate du stock pour consultation (au service stock)

* Saisie, édition d'un billet de réservation (agence Air Algérie)

* Gestion de la paie de nouvelles recrues

* Consolidation puis édition des statistiques au niveau national sur la base de statistiques régionales

#### Définition du MOC :

Il décrit les échanges d'informations entre sites ou lieux des postes de travail (s'il n'existe qu'un seule site).

<footnote n="6">⁶ E/S : entrées /sorties</footnote>
<figure><img src="image_21.png" /></figure>

Une agence n'effectue que les livraisons et les factures et a un modèle sans contrat.

<figure><img src="image_22.png" /></figure>

### c. Le Modèle Organisationnel de Communication : MOC

#### Exemples de traitements nécessitant des échanges de lecture/écriture entre sites :

Dans les exemples qui suivent, déterminer les opérations de lecture / écriture ainsi que les sites impliqués dans ces échanges :

* Saisie des commandes au service approvisionnement avec édition en fin de journée des bons de livraison au service stock

* Consultation des comptes client des différentes agences au niveau du siège de la banque

* Saisie des E/S<fnref n="6" /> avec mise à jour immédiate du stock pour consultation (au service stock)

* Saisie, édition d'un billet de réservation (agence Air Algérie)

* Gestion de la paie de nouvelles recrues

* Consolidation puis édition des statistiques au niveau national sur la base de statistiques régionales

#### Définition du MOC :

Il décrit les échanges d'informations entre sites ou lieux des postes de travail (s'il n'existe qu'un seule site).

<footnote n="6">⁶ E/S : entrées /sorties</footnote>
Le modèle organisationnel de communication ou MOC, traite les messages échangés entre sites différents : demande de présentation, demande de lancement de programme, mise à jour ou interrogation de données à distance.

La volonté de répartition par rapport aux sites géographiques et informatiques, conduit à un modèle qui décrira la répartition aussi bien des données que des traitements.

Plusieurs configurations sont possibles<sup>7</sup>, dont voici quelques possibilités par rapport au site de données :

**1er cas : centralisation totale**, un seul site de données, au niveau national.

Toutes les opérations, effectuées par les postes de travail des différents sites, locaux, régionaux et national, font référence aux mêmes informations sur un même site.

<figure><img src="image_27.png" /></figure>

**2e cas : centralisation nationale et régionale/locale.** Un site de données au niveau national et des sites de données régionaux et départementaux.

<figure><img src="image_28.png" /></figure>

**3e cas : décentralisation totale.** Il n'existe aucun échange, sauf éventuellement entre sites locaux et base de données locale, sites départementaux et base de données départementale

<footnote n="7"><sup>7</sup> Exemples : architecture distribuée (ressources décentralisées), architecture centralisée (un serveur et plusieurs clients).</footnote>
Le modèle organisationnel de communication ou MOC, traite les messages échangés entre sites différents : demande de présentation, demande de lancement de programme, mise à jour ou interrogation de données à distance.

La volonté de répartition par rapport aux sites géographiques et informatiques, conduit à un modèle qui décrira la répartition aussi bien des données que des traitements.

Plusieurs configurations sont possibles<sup>7</sup>, dont voici quelques possibilités par rapport au site de données :

**1er cas : centralisation totale**, un seul site de données, au niveau national.

Toutes les opérations, effectuées par les postes de travail des différents sites, locaux, régionaux et national, font référence aux mêmes informations sur un même site.

<figure><img src="image_23.png" /></figure>

**2e cas : centralisation nationale et régionale/locale.** Un site de données au niveau national et des sites de données régionaux et départementaux.

<figure><img src="image_24.png" /></figure>

**3e cas : décentralisation totale.** Il n'existe aucun échange, sauf éventuellement entre sites locaux et base de données locale, sites départementaux et base de données départementale

<footnote n="7"><sup>7</sup> Exemples : architecture distribuée (ressources décentralisées), architecture centralisée (un serveur et plusieurs clients).</footnote>
<figure><img src="image_29.png" /><figcaption>MOC 3</figcaption></figure>

**Remarque** : Dans cette phase, la "propriété" des données (qui a le droit de manipuler les données), l'autorisation de créer, de modifier, de lire et de supprimer des données doit être explicitée par poste de travail (privilèges et droits des différents utilisateurs, ex : administrateur du réseau, agent de saisie, directeur, secrétaire, manutentionner etc.).

**Validation des modèles au niveau organisationnel :**

La validation permet d'ajuster le MOD avec les vues externes, c'est-à-dire à mettre en accord **les données et les traitements.**

Chaque traitement possède son modèle externe ou vue externe. Il s'agit d'une [sorte de MCD](#) qui n'aurait été construit que dans l'optique d'un [seul traitement.](#)

A ce stade de la méthode, on ne s'intéresse qu'aux **traitements automatisés**. Ces traitements automatisés sont déduits du **MOT** qui représente [le futur système d'information.](#)

1 traitement automatisé<fnref n="8" /> dans le futur MOT = 1 modèle externe ou vue externe (ME).

Donc, la première étape dans la partie validation des données avec les traitements au niveau organisationnel est d'extraire [la liste des modèles externes (ME)](#) à partir du MOT.

L'étape suivante consiste à [les trier](#) selon qu'ils appartiennent à la catégorie des **ME en MAJ** (plus tard seront représentés par des masques de saisie dans l'application) ou à la catégorie des **ME en consultation** (plus tard seront représentés par des états en sortie dans l'application).

**Validation en MAJ (mis à jour) :**

Etant donné que les ME sont des MCD qui décrivent un traitement en particulier, ces derniers contiennent des propriétés qu'on appelle [propriétés externes](#) car elles appartiennent à des modèles externes.

Une propriété externe doit avoir un rôle (il est important de justifier son existence dans le modèle), soit :

* Servir à [identifier](#) le modèle externe de façon unique;

* Servir à [charger](#) une nouvelle valeur de propriété dans le modèle externe.

<footnote n="8">⁸ Traitement automatisé = Traitement faisant partie des procédures ou des fonctions d'une application informatique.</footnote>
<figure><img src="image_25.png" /></figure>

MOC 3

**Remarque** : Dans cette phase, la "propriété" des données (qui a le droit de manipuler les données), l'autorisation de créer, de modifier, de lire et de supprimer des données doit être explicitée par poste de travail (privilèges et droits des différents utilisateurs, ex : administrateur du réseau, agent de saisie, directeur, secrétaire, manutentionner etc.).

**Validation des modèles au niveau organisationnel :**

La validation permet d'ajuster le MOD avec les vues externes, c'est-à-dire à mettre en accord **les données et les traitements.**

Chaque traitement possède son modèle externe ou vue externe. Il s'agit d'une [sorte de MCD](#) qui n'aurait été construit que dans l'optique d'un [seul traitement.](#)

A ce stade de la méthode, on ne s'intéresse qu'aux **traitements automatisés**. Ces traitements automatisés sont déduits du **MOT** qui représente [le futur système d'information.](#)

1 traitement automatisé<fnref n="8" /> dans le futur MOT = 1 modèle externe ou vue externe (ME).

Donc, la première étape dans la partie validation des données avec les traitements au niveau organisationnel est d'extraire [la liste des modèles externes (ME)](#) à partir du MOT.

L'étape suivante consiste à [les trier](#) selon qu'ils appartiennent à la catégorie des **ME en MAJ** (plus tard seront représentés par des masques de saisie dans l'application) ou à la catégorie des **ME en consultation** (plus tard seront représentés par des états en sortie dans l'application).

**Validation en MAJ (mis à jour) :**

Etant donné que les ME sont des MCD qui décrivent un traitement en particulier, ces derniers contiennent des propriétés qu'on appelle [propriétés externes](#) car elles appartiennent à des modèles externes.

Une propriété externe doit avoir un rôle (il est important de justifier son existence dans le modèle), soit :

* Servir à [identifier](#) le modèle externe de façon unique;

* Servir à [charger](#) une nouvelle valeur de propriété dans le modèle externe.

<footnote n="8">⁸ Traitement automatisé = Traitement faisant partie des procédures ou des fonctions d'une application informatique.</footnote>
**Remarque** : si la propriété externe ne sert **ni à l'identification, ni au chargement**, cette propriété est **inutile** et doit être supprimée du modèle externe.

Une fois, la liste des propriétés externes nécessaires à l'identification et à la mise à jour (chargement de nouvelles valeurs) du modèle externe établie, il s'agit de comparer ces propriétés avec les propriétés contenues dans le ou les MOD(s) correspondant(s) afin de s'assurer qu'elles sont identiques ou semblables.

Si une propriété existe dans un modèle et pas dans l'autre, cela veut dire qu'il faut soit **l'ajouter** dans le modèle où elle manque (si elle est vraiment utile) ou alors la **supprimer** du modèle où elle existe car considérée finalement comme étant inutile (autrement dit juger de son utilité à figurer dans la BDD et dans le masque de saisie prévu dans l'application).

<table><thead><tr><td>Propriétés Externes</td><td>Rôle</td><td>Individu/Relation invoqués</td></tr></thead><tbody><tr><td>Prop1</td><td>Identification ou chargement</td><td>Situer la propriété dans le MOD (dans une relation ou dans un individu)</td></tr></tbody></table>

**Validation en consultation :**

Tous les traitements automatisées du MOT qui expriment la lecture à partir de la BDD (consultation sur écran ou édition sur imprimante) sont appelés **modèles externes en consultation** ou **vues externes en consultation**.

Dans ce type de validation, il suffit de s'assurer que les propriétés externes correspondent aux propriétés du ou des MOD(s) correspondants (Propriétés Organisationnelles). Si une différence est constatée, il faut procéder de la même manière décrite précédemment (ajout ou annulation de la propriété qui pose problème, autrement dit juger de son utilité à figurer dans la BDD et dans l'état en sortie prévu dans l'application).

<table><thead><tr><td>Propriétés externes</td><td>Propriétés Organisationnelles</td><td>Individu/Relation invoqués</td></tr></thead><tbody><tr><td>Prop1</td><td>Propriété équivalente dans le MOD</td><td>Situer la propriété dans le MOD (dans une relation ou dans un individu)</td></tr></tbody></table>
**Remarque** : si la propriété externe ne sert **ni à l'identification, ni au chargement**, cette propriété est **inutile** et doit être supprimée du modèle externe.

Une fois, la liste des propriétés externes nécessaires à l'identification et à la mise à jour (chargement de nouvelles valeurs) du modèle externe établie, il s'agit de comparer ces propriétés avec les propriétés contenues dans le ou les MOD(s) correspondant(s) afin de s'assurer qu'elles sont identiques ou semblables.

Si une propriété existe dans un modèle et pas dans l'autre, cela veut dire qu'il faut soit **l'ajouter** dans le modèle où elle manque (si elle est vraiment utile) ou alors la **supprimer** du modèle où elle existe car considérée finalement comme étant inutile (autrement dit juger de son utilité à figurer dans la BDD et dans le masque de saisie prévu dans l'application).

<table><thead><tr><td>Propriétés Externes</td><td>Rôle</td><td>Individu/Relation invoqués</td></tr></thead><tbody><tr><td>Prop1</td><td>Identification ou chargement</td><td>Situer la propriété dans le MOD (dans une relation ou dans un individu)</td></tr></tbody></table>

**Validation en consultation :**

Tous les traitements automatisées du MOT qui expriment la lecture à partir de la BDD (consultation sur écran ou édition sur imprimante) sont appelés **modèles externes en consultation** ou **vues externes en consultation**.

Dans ce type de validation, il suffit de s'assurer que les propriétés externes correspondent aux propriétés du ou des MOD(s) correspondants (Propriétés Organisationnelles). Si une différence est constatée, il faut procéder de la même manière décrite précédemment (ajout ou annulation de la propriété qui pose problème, autrement dit juger de son utilité à figurer dans la BDD et dans l'état en sortie prévu dans l'application).

<table><thead><tr><td>Propriétés externes</td><td>Propriétés Organisationnelles</td><td>Individu/Relation invoqués</td></tr></thead><tbody><tr><td>Prop1</td><td>Propriété équivalente dans le MOD</td><td>Situer la propriété dans le MOD (dans une relation ou dans un individu)</td></tr></tbody></table>
## 4. Le Niveau Logique :

Maintenant que le MOD (MCD par site) est établi, on peut le traduire en différents systèmes logiques et notamment les bases de données relationnelles qui proposent une vision plus concrète pour modéliser la situation.

### SGBD :

Un Système de Gestion de Bases de Données (SGBD) est un logiciel destiné au stockage et à la manipulation de bases de données

### Pourquoi un SGBD?

* Indépendance des données par rapport aux applications et sûreté d'accès aux données.

* Temps de développement d'application réduit.

* Intégrité des données et sécurité des accès.

* Administration des données uniforme.

* Concurrence des accès et reprise sur panne.

### Types de SGBD :

Il existe différents types de SGBD (Systèmes de Gestion des Bases de Données) dont :

1. les SGBD hiérarchiques dans lesquelles les données sont organisées en arbre

2. les SGBD réseaux dans lesquels les données sont organisées selon un graphe plus général

Ces deux types de SGBD sont dit navigationnels, car on peut retrouver l'information à condition d'en connaître le chemin.

3. Aujourd'hui, ils sont largement remplacés par les SGBD relationnels ou SGBDR, avec lesquelles l'information peut être obtenue par une requête formulée dans un langage quasiment naturel (le langage SQL pour Structured Query Language), parmi les SGBDR les plus répandus, nous trouvons ORACLE, SQL SERVER...

4. Plus récemment, sont apparus des SGBD orientés objet, pourtant les SGBDR restent extrêmement majoritaires.

### Schéma relationnel :

Un schéma relationnel est composé de relations, appelée tables.

Ces tables sont décrites par des attributs ou champs (noms de colonnes) et les lignes contiennent les valeurs de ces champs pour chaque enregistrement.
## 4. Le Niveau Logique :

Maintenant que le MOD (MCD par site) est établi, on peut le traduire en différents systèmes logiques et notamment les bases de données relationnelles qui proposent une vision plus concrète pour modéliser la situation.

### SGBD :

Un Système de Gestion de Bases de Données (SGBD) est un logiciel destiné au stockage et à la manipulation de bases de données

### Pourquoi un SGBD?

* Indépendance des données par rapport aux applications et sûreté d'accès aux données.

* Temps de développement d'application réduit.

* Intégrité des données et sécurité des accès.

* Administration des données uniforme.

* Concurrence des accès et reprise sur panne.

### Types de SGBD :

Il existe différents types de SGBD (Systèmes de Gestion des Bases de Données) dont :

1. les SGBD hiérarchiques dans lesquelles les données sont organisées en arbre

2. les SGBD réseaux dans lesquels les données sont organisées selon un graphe plus général

Ces deux types de SGBD sont dit navigationnels, car on peut retrouver l'information à condition d'en connaître le chemin.

3. Aujourd'hui, ils sont largement remplacés par les SGBD relationnels ou SGBDR, avec lesquelles l'information peut être obtenue par une requête formulée dans un langage quasiment naturel (le langage SQL pour Structured Query Language), parmi les SGBDR les plus répandus, nous trouvons ORACLE, SQL SERVER...

4. Plus récemment, sont apparus des SGBD orientés objet, pourtant les SGBDR restent extrêmement majoritaires.

### Schéma relationnel :

Un schéma relationnel est composé de relations, appelée tables.

Ces tables sont décrites par des attributs ou champs (noms de colonnes) et les lignes contiennent les valeurs de ces champs pour chaque enregistrement.
<table><thead><tr><td>NUMERO CLIENT</td><td>NOM CLIENT</td><td>PRENOM CLIENT</td><td>ADRESSE CLIENT</td></tr></thead><tbody><tr><td>1</td><td>BACHIRI</td><td>MOHAMED</td><td>BOUMERDES</td></tr><tr><td>2</td><td>MOKRANE</td><td>AHMED</td><td>THENIA</td></tr><tr><td>3</td><td>MESSAOUDI</td><td>MAHMOUD</td><td>ALGER</td></tr><tr><td>4</td><td>ADJAL</td><td>ABDELHAMID</td><td>BOUIRA</td></tr><tr><td>5</td><td>MESBAH</td><td>AMIN</td><td>BOUMERDES</td></tr><tr><td>...</td><td>...</td><td>...</td><td>...</td></tr></tbody></table>

Pour décrire une relation, on indique tout simplement son nom en majuscule, suivi du nom de ses attributs entre parenthèses.

L'identifiant d'une relation est composé d'un ou plusieurs attributs qui forment la **clé primaire**.

**CLIENT (NUMERO CLIENT, NOM CLIENT, PRENOM CLIENT, ADRESSE CLIENT)**

Une relation peut faire référence à une autre en utilisant une **clé étrangère**, qui correspond à la clé primaire de la relation référencée.

Il n'y a pas de notation officielle pour repérer les clés primaires et étrangères. C'est à vous d'en adopter une et de l'expliquer en légende.

Par exemple :

- on souligne la clé primaire d'un seul trait

- on fait précéder (ou suivre) les clés étrangères du symbole # ou *

**Règles de passage du MCD au MLD :**

**Règle 1 : Une entité se transforme en une relation (table)**

Toute entité du MCD devient une relation du MLD, et donc une table de la Base de données. Chaque propriété de l'entité devient un attribut de cette relation, et dont une colonne de la table correspondante. L'identifiant de l'entité devient la **Clé Primaire** de la relation (elle est donc soulignée), et donc la **Clé Primaire** de la table correspondante.

<table><tr><td>CLIENT</td></tr><tr><td>id_client</td></tr><tr><td>Nom_CLIENT</td></tr><tr><td>Tel_CLIENT</td></tr></table>

<===> CLIENT (id_client, Nom_CLIENT, Tel_client)
<table><thead><tr><td>NUMERO CLIENT</td><td>NOM CLIENT</td><td>PRENOM CLIENT</td><td>ADRESSE CLIENT</td></tr></thead><tbody><tr><td>1</td><td>BACHIRI</td><td>MOHAMED</td><td>BOUMERDES</td></tr><tr><td>2</td><td>MOKRANE</td><td>AHMED</td><td>THENIA</td></tr><tr><td>3</td><td>MESSAOUDI</td><td>MAHMOUD</td><td>ALGER</td></tr><tr><td>4</td><td>ADJAL</td><td>ABDELHAMID</td><td>BOUIRA</td></tr><tr><td>5</td><td>MESBAH</td><td>AMIN</td><td>BOUMERDES</td></tr><tr><td>...</td><td>...</td><td>...</td><td>...</td></tr></tbody></table>

Pour décrire une relation, on indique tout simplement son nom en majuscule, suivi du nom de ses attributs entre parenthèses.

L'identifiant d'une relation est composé d'un ou plusieurs attributs qui forment la clé primaire.

CLIENT (NUMERO CLIENT, NOM CLIENT, PRENOM CLIENT, ADRESSE CLIENT)

Une relation peut faire référence à une autre en utilisant une clé étrangère, qui correspond à la clé primaire de la relation référencée.

Il n'y a pas de notation officielle pour repérer les clés primaires et étrangères. C'est à vous d'en adopter une et de l'expliquer en légende.

Par exemple :

- on souligne la clé primaire d'un seul trait

- on fait précéder (ou suivre) les clés étrangères du symbole # ou *

Règles de passage du MCD au MLD :

Règle 1 : Une entité se transforme en une relation (table)

Toute entité du MCD devient une relation du MLD, et donc une table de la Base de données. Chaque propriété de l'entité devient un attribut de cette relation, et dont une colonne de la table correspondante. L'identifiant de l'entité devient la Clé Primaire de la relation (elle est donc soulignée), et donc la Clé Primaire de la table correspondante.

<table><tr><td>CLIENT</td></tr><tr><td>id_client</td></tr><tr><td>Nom_CLIENT</td></tr><tr><td>Tel_CLIENT</td></tr></table>

<===> CLIENT (id_client, Nom_CLIENT, Tel_client)
## 2 : Relation binaire aux cardinalités (X,1) - (X,n), X=0 ou X=1

La Clé Primaire de la table à la cardinalité (X,n) devient une Clé Etrangère dans la table à la cardinalité (X,1) :

Exemple :

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

MCD :

<figure><img src="image_30.png" /></figure>

Modèle Logique de Donnée (MLD) :

EMPLOYE (id_Employe, Nom_Employe, #id_Societe)

SOCIETE (id_Societe, Nom_Societe)

## 3 : Relation binaire aux cardinalités (X,n) - (X,n), X=0 ou X=1

Il y a création d'une table supplémentaire ayant comme Clé Primaire une clé composée des identifiants des 2 entités. On dit que la Clé Primaire de la nouvelle table est la **concaténation** des Clés Primaires des deux autres tables.

Si la relation est porteuse de donnée, celles-ci deviennent des attributs pour la nouvelle table.

Exemple :

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

MCD :

<figure><img src="image_31.png" /></figure>

MLD :

COMMANDE (id_Commande, Date_commande)
## 2 : Relation binaire aux cardinalités (X,1) - (X,n), X=0 ou X=1

La Clé Primaire de la table à la cardinalité (X,n) devient une Clé Etrangère dans la table à la cardinalité (X,1) :

Exemple :

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

MCD :

<figure><img src="image_26.png" /></figure>

Modèle Logique de Donnée (MLD) :

EMPLOYE (id_Employe, Nom_Employe, #id_Societe)

SOCIETE (id_Societe, Nom_Societe)

## 3 : Relation binaire aux cardinalités (X,n) - (X,n), X=0 ou X=1

Il y a création d'une table supplémentaire ayant comme Clé Primaire une clé composée des identifiants des 2 entités. On dit que la Clé Primaire de la nouvelle table est la concaténation des Clés Primaires des deux autres tables.

Si la relation est porteuse de donnée, celles-ci deviennent des attributs pour la nouvelle table.

Exemple :

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

MCD :

<figure><img src="image_27.png" /></figure>

MLD :

COMMANDE (id_Commande, Date_commande)
PRODUIT (id_Produit, libelle)

COMPOSE (id_Commande, id_Produit, quantité)

## 4 : Relation n-aire (quelles que soient les cardinalités).

Il y a création d'une table supplémentaire ayant comme **Clé Primaire** la **concaténation** des **identifiants** des entités participant à la relation.

Si la relation est porteuse de donnée, celles-ci deviennent des attributs pour la nouvelle table.

### Exemple :

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

### MCD :

<figure><img src="image_32.png" /></figure>

### MLD :

ETUDIANT (id_Etudiant, Nom_Etudiant)

NIVEAU (id_Niveau, Nom_Niveau)

LANGUE (id_Langue, Nom_Langue)

PARLE (id_Etudiant, id_Niveau, id_Langue)

### Exception à la règle 1

Les entités n'ayant que leur identifiant comme attribut ne deviennent pas des relations, mais des attributs dans les autres relations liées.

Exemple : on mémorise chaque jour, pour chaque ouvrier les pièces qu'il a fabriqué et en quelle quantité.
PRODUIT (id_Produit, libelle)

COMPOSE (id_Commande, id_Produit, quantité)

**4 : Relation n-aire (quelles que soient les cardinalités).**

Il y a création d'une table supplémentaire ayant comme **Clé Primaire** la **concaténation** des **identifiants** des entités participant à la relation.

Si la relation est porteuse de donnée, celles-ci deviennent des attributs pour la nouvelle table.

**Exemple :**

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

**MCD :**

<figure><img src="image_28.png" /></figure>

**MLD :**

ETUDIANT (id_Etudiant, Nom_Etudiant)

NIVEAU (id_Niveau, Nom_Niveau)

LANGUE (id_Langue, Nom_Langue)

PARLE (id_Etudiant, id_Niveau, id_Langue)

**Exception à la règle 1**

Les entités n'ayant que leur identifiant comme attribut ne deviennent pas des relations, mais des attributs dans les autres relations liées.

Exemple : on mémorise chaque jour, pour chaque ouvrier les pièces qu'il a fabriqué et en quelle quantité.
<figure><img src="image_33.png" /></figure>

Quand on passe au modèle relationnel, l'entité DATE FABRICATION ne devient pas une relation, mais un attribut clé dans la relation FABRIQUE issue de l'association.

<figure><img src="image_34.png" /></figure>

# 5 : Association Réflexive.

## Premier cas : cardinalité (X,1) - (X,n), avec X=0 ou X=1. (Réflexive hiérarchique)

La Clé Primaire de l'entité se dédouble et devient une Clé Etrangère dans la relation ou nouvelle table. Exactement comme si l'entité se dédoublait et était reliée par une relation binaire (X,1) - (X,n) (règle 2).

Exemple :

Prenons l'exemple d'une société organisée de manière pyramidale : chaque employé a 0 ou 1 supérieur hiérarchique direct. Simultanément, chaque employé est le supérieur hiérarchique direct de 0 ou plusieurs employés.

MCD :

<figure><img src="image_35.png" /></figure>
<figure><img src="image_29.png" /></figure>

Quand on passe au modèle relationnel, l'entité DATE FABRICATION ne devient pas une relation, mais un attribut clé dans la relation FABRIQUE issue de l'association.

<figure><img src="image_30.png" /></figure>

# 5 : Association Réflexive.

## Premier cas : cardinalité (X,1) - (X,n), avec X=0 ou X=1. (Réflexive hiérarchique)

La Clé Primaire de l'entité se dédouble et devient une Clé Etrangère dans la relation ou nouvelle table. Exactement comme si l'entité se dédoublait et était reliée par une relation binaire (X,1) - (X,n) (règle 2).

Exemple :

Prenons l'exemple d'une société organisée de manière pyramidale : chaque employé a 0 ou 1 supérieur hiérarchique direct. Simultanément, chaque employé est le supérieur hiérarchique direct de 0 ou plusieurs employés.

MCD :

<figure><img src="image_31.png" /></figure>
MLD :

EMPLOYE (id_Employe, Nom_Employe, #id_Sup_Hierarchique)

#id_Sup_Hierarchique est l'identifiant (id_Employe) du supérieur hiérarchique direct de l'employé considéré.

**Deuxième cas : cardinalité (X,n) - (X,n), avec X=0 ou X=1. (reflexive non hiérarchique ou réseau)**

De même, tout se passe exactement comme si l'entité se dédoublait et était reliée par une relation binaire (X,n) - (X,n) (règle 3). Il y a donc création d'une nouvelle table.

Exemple :

Une pièce entre dans la composition de 0 à plusieurs autres pièces. Une pièce peut être composée de plusieurs autres pièces. Une pièce entre dans la composition d'une autre un certain nombre de fois.

ex : La pièce "voiture" est composée de 4 pièces "roue". La pièce "roue" est elle-même composée d'une pièce "pneu" et d'une pièce "jante".

Une pièce entrant dans la composition d'une autre est appelée composant. Une pièce composée d'autres pièces est appelée composé. Une roue est à la fois un composant (de voiture) et un composé (de pneu et jante)

<figure><img src="image_36.png" /></figure>

Traduction en modèle relationnel

PIECE(référence, libellé)

COMPOSITION(#référence_composé, #référence_composant, nombre)

**6 : Relation binaire aux cardinalités (0,1) - (1,1).**

La Clé Primaire de la table à la cardinalité (0,1) devient une Clé Etrangère dans la table à la cardinalité (1,1)

Exemple :

Dans ce centre de vacances, Chaque animateur encadre en solo 0 ou 1 groupe, chaque groupe étant encadré par un et un seul animateur.
MLD :

EMPLOYE (id_Employe, Nom_Employe, #id_Sup_Hierarchique)

#id_Sup_Hierarchique est l'identifiant (id_Employe) du supérieur hiérarchique direct de l'employé considéré.

**Deuxième cas : cardinalité (X,n) - (X,n), avec X=0 ou X=1. (reflexive non hiérarchique ou réseau)**

De même, tout se passe exactement comme si l'entité se dédoublait et était reliée par une relation binaire (X,n) - (X,n) (règle 3). Il y a donc création d'une nouvelle table.

Exemple :

Une pièce entre dans la composition de 0 à plusieurs autres pièces. Une pièce peut être composée de plusieurs autres pièces. Une pièce entre dans la composition d'une autre un certain nombre de fois.

ex : La pièce "voiture" est composée de 4 pièces "roue". La pièce "roue" est elle-même composée d'une pièce "pneu" et d'une pièce "jante".

Une pièce entrant dans la composition d'une autre est appelée composant. Une pièce composée d'autres pièces est appelée composé. Une roue est à la fois un composant (de voiture) et un composé (de pneu et jante)

<figure><img src="image_32.png" /></figure>

Traduction en modèle relationnel

PIECE(référence, libellé)

COMPOSITION(#référence_composé, #référence_composant, nombre)

**6 : Relation binaire aux cardinalités (0,1) - (1,1).**

La Clé Primaire de la table à la cardinalité (0,1) devient une Clé Etrangère dans la table à la cardinalité (1,1)

Exemple :

Dans ce centre de vacances, Chaque animateur encadre en solo 0 ou 1 groupe, chaque groupe étant encadré par un et un seul animateur.
MCD :

<figure><img src="image_37.png" /></figure>

MLD :

ANIMATEUR (id_Animateur, Nom_Animateur)

GROUPE (id_Groupe, Nom_Groupe, #id_animateur)

**Avertissement** : les niveaux logique et physique associés à Merise ne sont pas aussi bien élaborés que les deux niveaux précédents (conceptuel et organisationnel).
MCD :

<figure><img src="image_33.png" /></figure>

MLD :

ANIMATEUR (id_Animateur, Nom_Animateur)

GROUPE (id_Groupe, Nom_Groupe, #id_animateur)

**Avertissement** : les niveaux logique et physique associés à Merise ne sont pas aussi bien élaborés que les deux niveaux précédents (conceptuel et organisationnel).
## 5. LE NIVEAU PHYSIQUE :

Le dernier niveau de la méthode, le niveau physique, représente le résultat informatique. Il dépend des logiciels de développement nécessaires à la programmation et à la manipulation des données.

### MODELE PHYSIQUE DE DONNEES.

Le modèle physique de données est un modèle de la base de données. Le passage du modèle individu/relation au modèle relationnel consiste à créer des tables provenant d'individus, des tables provenant de relations et de répéter ou migrer les identifiants ou les clés de table dans d'autres tables.

La traduction d'un MLD conduit à un MPD qui précise notamment le stockage de chaque donnée à travers son type et sa taille (en octets ou en bits).

La traduction d'un MLD relationnel en un MPD est la création d'une BDD hébergée par un SGBD relationnel particulier.

**Exemple** : MCD de « Suivi des dossiers comptables d'un centre de gestion communal »

<figure><img src="image_38.png" /></figure>

Ce qui donne le MPD suivant :

<figure><img src="image_39.png" /></figure>
## 5. LE NIVEAU PHYSIQUE :

Le dernier niveau de la méthode, le niveau physique, représente le résultat informatique. Il dépend des logiciels de développement nécessaires à la programmation et à la manipulation des données.

### MODELE PHYSIQUE DE DONNEES.

Le modèle physique de données est un modèle de la base de données. Le passage du modèle individu/relation au modèle relationnel consiste à créer des tables provenant d'individus, des tables provenant de relations et de répéter ou migrer les identifiants ou les clés de table dans d'autres tables.

La traduction d'un MLD conduit à un MPD qui précise notamment le stockage de chaque donnée à travers son type et sa taille (en octets ou en bits).

La traduction d'un MLD relationnel en un MPD est la création d'une BDD hébergée par un SGBD relationnel particulier.

**Exemple** : MCD de « Suivi des dossiers comptables d'un centre de gestion communal »

<figure><img src="image_34.png" /></figure>

Ce qui donne le MPD suivant :

<figure><img src="image_35.png" /></figure>
Pk : « primary key » ou clé primaire

Fk : « foreign key » ou clé étrangère

→ : **Pointeur** (qui indique le lien ou le chemin entre les tables de la BDD)

Une fois le MPD, réalisé l'étape suivante consiste à calculer le volume de la ou les BDD (dans le cas de plusieurs sites)

### Calcul du volume de la BDD :

L'objectif est de produire une estimation de l'espace mémoire qu'occupera la BDD dans le disque.

**Taille BDD = Σ (taille de chaque table)**

**Taille d'une table = Σ (taille en caractères de chaque champs (attribut ou propriété) de la table) × nombre d'occurrences (instances) approximatives de la table pour une période donnée.**

**Exemple :** une BDD qui contient les tables : CLIENT, COMMANDE, FACTURE, PRODUIT.

### TABLE CLIENT

<table><tr><td>ID_CLIENT</td><td>&lt;PK&gt;</td><td>char(20)</td></tr><tr><td>CATEGORIE_CLIENT</td><td></td><td>char (2)</td></tr><tr><td>NOM_CLIENT</td><td></td><td>char (30)</td></tr><tr><td>PRENOM_CLIENT</td><td></td><td>char(20)</td></tr><tr><td>ADRESSE_CLIENT</td><td></td><td>char(100)</td></tr><tr><td>WILAYA</td><td></td><td>integer</td></tr><tr><td>TEL_CLIENT</td><td></td><td>char(15)</td></tr><tr><td>DATE_NAISSANCE</td><td></td><td>date</td></tr></table>

<table><thead><tr><td>TABLE</td><td>Taille en caractères</td><td>Nombre d'occurrences</td><td>Volume</td></tr></thead><tbody><tr><td>CLIENT</td><td>200</td><td>50 000</td><td>10 000 000</td></tr><tr><td>COMMANDE</td><td>50</td><td>4000 (pour 1 an)</td><td>2 00 000</td></tr><tr><td>FACTURE</td><td>50</td><td>4000 (pour 1 an)</td><td>2 00 000</td></tr><tr><td>PRODUIT</td><td>70</td><td>10</td><td>700</td></tr></tbody></table>

Soit un total de : 10400700 octets = presque 10 MO (méga octets)

**Volume auquel il faut rajouter au moins 30% de plus pour la gestion des pointeurs d'où un volume total de presque 13 MO.**

**Il faut savoir que :**

1 K (Kilo) octets = 1024 octets

1 M (Méga) octets = 1024 K octets

1 G (Giga octets) = 1024 M octets
Pk : « primary key » ou clé primaire

Fk : « foreign key » ou clé étrangère

→ : **Pointeur** (qui indique le lien ou le chemin entre les tables de la BDD)

Une fois le MPD, réalisé l'étape suivante consiste à calculer le volume de la ou les BDD (dans le cas de plusieurs sites)

**Calcul du volume de la BDD :**

L'objectif est de produire une estimation de l'espace mémoire qu'occupera la BDD dans le disque.

**Taille BDD = Σ (taille de chaque table)**

**Taille d'une table = Σ (taille en caractères de chaque champs (attribut ou propriété) de la table) × nombre d'occurrences (instances) approximatives de la table pour une période donnée.**

**Exemple :** une BDD qui contient les tables : CLIENT, COMMANDE, FACTURE, PRODUIT.

**TABLE CLIENT**

```
ID_CLIENT      <PK>      char(20)
CATEGORIE_CLIENT char (2)
NOM_CLIENT     char (30)
PRENOM_CLIENT  char(20)
ADRESSE_CLIENT char(100)
WILAYA         integer
TEL_CLIENT     char(15)
DATE_NAISSANCE  date
```

<table><thead><tr><td>TABLE</td><td>Taille en caractères</td><td>Nombre d'occurrences</td><td>Volume</td></tr></thead><tbody><tr><td>CLIENT</td><td>200</td><td>50 000</td><td>10 000 000</td></tr><tr><td>COMMANDE</td><td>50</td><td>4000 (pour 1 an)</td><td>2 00 000</td></tr><tr><td>FACTURE</td><td>50</td><td>4000 (pour 1 an)</td><td>2 00 000</td></tr><tr><td>PRODUIT</td><td>70</td><td>10</td><td>700</td></tr></tbody></table>

Soit un total de : 10400700 octets = presque 10 MO (méga octets)

**Volume auquel il faut rajouter au moins 30% de plus pour la gestion des pointeurs** d'où un volume total de presque 13 MO.

**Il faut savoir que :**

1 K (Kilo) octets = 1024 octets

1 M (Méga) octets = 1024 K octets

1 G (Giga octets) = 1024 M octets
**MLT** : description logique des traitements consiste à trier les phases en 2 types de phases :

* Phases temps réel ou transactions, exemple : saisie d'une commande, MAJ du stock...

* Phases temps différé ou batch, exemple : édition d'états statistiques, calcul de l'inventaire...

**MPT ou MOpT** : Description opérationnelle des traitements :

Il s'agit de décrire l'architecture générale de l'application et la spécification des traitements.

Autrement dit, décrire l'arborescence des menus et l'enchainement des écrans ainsi que la préparation d'un jeu de tests.

Le MOpT est fortement dépendant des outils de développement choisis

Exemple : menu : MAJ, RECHERCHE, EDITIONS, A PROPOS

MAJ (LISTE DES TABLES)

RECHERCHE (par critère)

Editions (liste des états en sortie)

A propos (infos sur les développeurs, version du logiciel, date dernière maj...)

Jusqu'à arriver aux écrans de saisie ainsi que les états en sortie, via touche : impr écran puis ctrl+v dans document word afin de récupérer l'image de l'écran.

**Suite (Récapitulatif des différences de merise/2 avec la version précédente de merise)**

Le volet communication avec ses deux principaux modèles:

**MCC** : distingue entre flux physiques (argent, matière et énergie) et flux informationnels, décrit le champ d'étude et se focalise sur les fonctions qui appartiennent à ce dernier.

**MOC** : met en avant l'architecture du SI (centralisée, décentralisée, répartition des ressources site de traitement et site de données) ainsi que les échanges de lecture et écriture sur et à partir des BDD du SI

Quelques nouveautés au niveau organisationnel :

**MOD** : MCD par site (des vues différentes) et par conséquent BDD par site.

**MOT** : intervient à deux reprises dans le déroulement de la méthode : une fois pour décrire les procédures du SI actuel et une deuxième fois pour décrire les procédures du futur SI en mettant en avant la nouvelle organisation (nouvelle répartition des tâches et/ou nouveaux postes de travail) ainsi que l'automatisation de certaines phases (ex : MAJ de stock) et la création de nouvelles phases automatisées (ex : édition de certaines statistiques inexistantes auparavant).
**MLT** : description logique des traitements consiste à trier les phases en 2 types de phases :

* Phases temps réel ou transactions, exemple : saisie d'une commande, MAJ du stock...

* Phases temps différé ou batch, exemple : édition d'états statistiques, calcul de l'inventaire...

**MPT ou MOpT** : Description opérationnelle des traitements :

Il s'agit de décrire l'architecture générale de l'application et la spécification des traitements.

Autrement dit, décrire l'arborescence des menus et l'enchainement des écrans ainsi que la préparation d'un jeu de tests.

Le MOpT est fortement dépendant des outils de développement choisis

Exemple : menu : MAJ, RECHERCHE, EDITIONS, A PROPOS

MAJ (LISTE DES TABLES)

RECHERCHE (par critère)

Editions (liste des états en sortie)

A propos (infos sur les développeurs, version du logiciel, date dernière maj...)

Jusqu'à arriver aux écrans de saisie ainsi que les états en sortie, via touche : impr écran puis ctrl+v dans document word afin de récupérer l'image de l'écran.

**Suite (Récapitulatif des différences de merise/2 avec la version précédente de merise)**

Le volet communication avec ses deux principaux modèles:

**MCC** : distingue entre flux physiques (argent, matière et énergie) et flux informationnels, décrit le champ d'étude et se focalise sur les fonctions qui appartiennent à ce dernier.

**MOC** : met en avant l'architecture du SI (centralisée, décentralisée, répartition des ressources site de traitement et site de données) ainsi que les échanges de lecture et écriture sur et à partir des BDD du SI

Quelques nouveautés au niveau organisationnel :

**MOD** : MCD par site (des vues différentes) et par conséquent BDD par site.

**MOT** : intervient à deux reprises dans le déroulement de la méthode : une fois pour décrire les procédures du SI actuel et une deuxième fois pour décrire les procédures du futur SI en mettant en avant la nouvelle organisation (nouvelle répartition des tâches et/ou nouveaux postes de travail) ainsi que l'automatisation de certaines phases (ex : MAJ de stock) et la création de nouvelles phases automatisées (ex : édition de certaines statistiques inexistantes auparavant).
## La qualité de l'information à l'intérieur du SI :

La valeur d'une information est fonction du besoin qu'on en a. Elle est liée à sa confidentialité, son intégrité et sa disponibilité.

Le concept de sécurité des systèmes d'information recouvre un ensemble de méthodes, techniques et outils chargés de protéger les ressources d'un système d'information afin d'assurer :

* la disponibilité des services : les services (ordinateurs, réseaux, périphériques, applications...) et les informations (données, fichiers...) doivent être accessibles aux personnes autorisées quand elles en ont besoin ;

* la confidentialité des informations : les informations n'appartiennent pas à tout le monde ; seuls peuvent y accéder ceux qui en ont le droit ;

* l'intégrité des systèmes : les services et les informations (fichiers, messages...) ne peuvent être modifiés que par les personnes autorisées (administrateurs, propriétaires...).

Les principales menaces effectives auxquelles un système d'information peut être confronté sont :

1. Un **utilisateur du système** : l'énorme majorité des problèmes liés à la sécurité d'un système d'information est l'utilisateur, généralement insouciant ;

2. Une **personne malveillante** : une personne parvient à s'introduire sur le système, légitimement ou non, et à accéder ensuite à des données ou à des programmes auxquels elle n'est pas censée avoir accès en utilisant par exemple des failles connues et non corrigées dans les logiciels ;

3. Un **programme malveillant** (virus, spyware...): un logiciel destiné à nuire ou à abuser des ressources du système est installé (par mégarde ou par malveillance) sur le système, ouvrant la porte à des intrusions ou modifiant les données ; des données personnelles peuvent être collectées à l'insu de l'utilisateur et être réutilisées à des fins malveillantes ou commerciales ;

4. Un **sinistre** (vol, incendie, dégât des eaux) : une mauvaise manipulation ou une malveillance entraînant une perte de matériel et/ou de données.

## Qu'est-ce qu'un virus ?

Pour la plupart des utilisateurs, un virus est un programme qui, à leur insu, exerce une action nuisible à son environnement: modification ou destruction de fichiers, effacement du disque dur, allongement des temps de traitement, manifestations visuelles ou sonores plus ou moins inquiétantes, etc. Cette action peut être continue, sporadique, périodique, ou n'avoir lieu qu'à une date précise ou selon la conjonction d'événements extérieurs fortuits. Le virus Michelangelo, par exemple, ne se déclenche que le 6 mars, le virus Tchernobyl le 26 avril.
## La qualité de l'information à l'intérieur du SI :

La valeur d'une information est fonction du besoin qu'on en a. Elle est liée à sa confidentialité, son intégrité et sa disponibilité.

Le concept de sécurité des systèmes d'information recouvre un ensemble de méthodes, techniques et outils chargés de protéger les ressources d'un système d'information afin d'assurer :

* la disponibilité des services : les services (ordinateurs, réseaux, périphériques, applications...) et les informations (données, fichiers...) doivent être accessibles aux personnes autorisées quand elles en ont besoin ;

* la confidentialité des informations : les informations n'appartiennent pas à tout le monde ; seuls peuvent y accéder ceux qui en ont le droit ;

* l'intégrité des systèmes : les services et les informations (fichiers, messages...) ne peuvent être modifiés que par les personnes autorisées (administrateurs, propriétaires...).

Les principales menaces effectives auxquelles un système d'information peut être confronté sont :

1. Un **utilisateur du système** : l'énorme majorité des problèmes liés à la sécurité d'un système d'information est l'utilisateur, généralement insouciant ;

2. Une **personne malveillante** : une personne parvient à s'introduire sur le système, légitimement ou non, et à accéder ensuite à des données ou à des programmes auxquels elle n'est pas censée avoir accès en utilisant par exemple des failles connues et non corrigées dans les logiciels ;

3. Un **programme malveillant** (virus, spyware...): un logiciel destiné à nuire ou à abuser des ressources du système est installé (par mégarde ou par malveillance) sur le système, ouvrant la porte à des intrusions ou modifiant les données ; des données personnelles peuvent être collectées à l'insu de l'utilisateur et être réutilisées à des fins malveillantes ou commerciales ;

4. Un **sinistre** (vol, incendie, dégât des eaux) : une mauvaise manipulation ou une malveillance entraînant une perte de matériel et/ou de données.

## Qu'est-ce qu'un virus ?

Pour la plupart des utilisateurs, un virus est un programme qui, à leur insu, exerce une action nuisible à son environnement: modification ou destruction de fichiers, effacement du disque dur, allongement des temps de traitement, manifestations visuelles ou sonores plus ou moins inquiétantes, etc. Cette action peut être continue, sporadique, périodique, ou n'avoir lieu qu'à une date précise ou selon la conjonction d'événements extérieurs fortuits. Le virus Michelangelo, par exemple, ne se déclenche que le 6 mars, le virus Tchernobyl le 26 avril.
## La prévention contre les virus

Pour se protéger des virus, il est recommandé de :

* de contrôler toutes les nouvelles applications à installer ;

* de verrouiller les supports de stockage quand ils n'ont pas besoin d'être en écriture ;

* d'avoir un antivirus mis à jour régulièrement.

### Quelques réponses possibles aux menaces :

1. Formation du personnel, codification et contrôle des données, ce qui permettra d'éviter les erreurs de saisie.

2. Définir des privilèges d'accès : un administrateur aura tous les privilèges par contre un utilisateur ne pourra pas faire de suppression par exemple ou ne pourra consulter certains états statistiques et cela par le biais de l'instauration de mots de passe par profil en fonction des privilèges associés.

3. Equiper les PCs d'anti-virus et d'anti-spyware (en cas de connexion internet) efficaces, ces logiciels devront être mis à jour de façon régulière.

4. Faire des sauvegardes régulières des applications et de plusieurs exemplaires des BDDs et les stocker dans des lieux différents.

## CODIFICATION DES DONNEES :

**Un code** : est un nom abrégé ou une représentation de l'information permettant de désigner un objet ou un concept de manière claire et unique.

**La codification** : est l'opération qui consiste à remplacer une information sous sa forme naturelle par un code clair qui serait mieux adapté aux besoins de l'utilisateur de l'information

### Principales caractéristiques d'une codification

* Une codification remplace une information par un code qui doit être unique et clair.

* Le code doit répondre aux besoins de l'utilisateur et lui facilite les tâches de codification et d'interprétation des codes établis.

* La codification doit être aussi stable que possible, c'est-à-dire qu'on n'aura pas à changer le code à chaque fois qu'un nouvel objet à codifier arrive dans le système

### Les différents types de codification :

#### 1. La codification séquentielle :
## La prévention contre les virus

Pour se protéger des virus, il est recommandé de :

* de contrôler toutes les nouvelles applications à installer ;

* de verrouiller les supports de stockage quand ils n'ont pas besoin d'être en écriture ;

* d'avoir un antivirus mis à jour régulièrement.

### Quelques réponses possibles aux menaces :

1. Formation du personnel, codification et contrôle des données, ce qui permettra d'éviter les erreurs de saisie.

2. Définir des privilèges d'accès : un administrateur aura tous les privilèges par contre un utilisateur ne pourra pas faire de suppression par exemple ou ne pourra consulter certains états statistiques et cela par le biais de l'instauration de mots de passe par profil en fonction des privilèges associés.

3. Equiper les PCs d'anti-virus et d'anti-spyware (en cas de connexion internet) efficaces, ces logiciels devront être mis à jour de façon régulière.

4. Faire des sauvegardes régulières des applications et de plusieurs exemplaires des BDDs et les stocker dans des lieux différents.

## CODIFICATION DES DONNEES :

**Un code** : est un nom abrégé ou une représentation de l'information permettant de désigner un objet ou un concept de manière claire et unique.

**La codification** : est l'opération qui consiste à remplacer une information sous sa forme naturelle par un code clair qui serait mieux adapté aux besoins de l'utilisateur de l'information

### Principales caractéristiques d'une codification

* Une codification remplace une information par un code qui doit être unique et clair.

* Le code doit répondre aux besoins de l'utilisateur et lui facilite les tâches de codification et d'interprétation des codes établis.

* La codification doit être aussi stable que possible, c'est-à-dire qu'on n'aura pas à changer le code à chaque fois qu'un nouvel objet à codifier arrive dans le système

### Les différents types de codification :

#### 1. La codification séquentielle :
Attribuer à chaque information un numéro, de sorte que les numéros associés soient successifs (1, 2, 3, ...),
exemple : les wilayas de notre pays.

Avantages :

• Non ambiguë

• Simple (dernier N°+1)

• Extension possible

Inconvénients :

• Non significative

• insertion impossible (sauf réutilisation)

2. La codification par tranches :

Attribuer une tranche (sous-ensemble) de codes à chaque catégorie d'objets à codifier (les codes sont séquentiels dans une tranche)

Exemple: dans une bibliothèque, les ouvrages sont codés et classés par catégories:

- Technologie 0001 à 1000

- Littérature 1001 à 2000

- Sociologie 2001 à 3000

- Médecine 3001 à 4000

- Économie 4001 à 5000

Avantage :

• Non ambiguë

• Simple (dernier N°+1)

• Nombre de code dans une tranche difficile à fixer

• Extension possible

Inconvénients :

• Non significative

• Nombre de code dans une tranche difficile à fixer
Attribuer à chaque information un numéro, de sorte que les numéros associés soient successifs (1, 2, 3, ...),
exemple : les wilayas de notre pays.

Avantages :

• Non ambiguë

• Simple (dernier N°+1)

• Extension possible

Inconvénients :

• Non significative

• insertion impossible (sauf réutilisation)

2. La codification par tranches :

Attribuer une tranche (sous-ensemble) de codes à chaque catégorie d'objets à codifier (les codes sont séquentiels dans une tranche)

Exemple: dans une bibliothèque, les ouvrages sont codés et classés par catégories:

- Technologie 0001 à 1000

- Littérature 1001 à 2000

- Sociologie 2001 à 3000

- Médecine 3001 à 4000

- Économie 4001 à 5000

Avantage :

• Non ambiguë

• Simple (dernier N°+1)

• Nombre de code dans une tranche difficile à fixer

• Extension possible

Inconvénients :

• Non significative

• Nombre de code dans une tranche difficile à fixer
* la répartition des objets en catégories n'est pas toujours évidente

### 3. La codification articulée

Attribuer des codes découpés en zones significatives (zone: descripteur)

Exemple: matricule d'un véhicule : 0233-111-35

#### 0233 N° Séquentiel

1. Catégorie du véhicule (1 tourisme, 2 transport en commun, 3 engins,...)

11. Année de mise en circulation

35. Code Wilaya d'enregistrement

**Avantages:**

* Significative

* Très utilisée

* Non ambiguë

* insertion et extension possible

* Possibilité de regrouper les objets selon un critère donné

* Possibilité de contrôler

**Inconvénients :**

* Code trop long donc lourd à manipuler

* Possibilité de saturation d'une zone

* Instabilité

### 4. La codification par niveau ou hiérarchique

Cas particulier de la codification articulée, les zones (descripteurs) sont des niveaux.

Exemple: Code postal 16132

16 Code Wilaya (niv.1)

1 Code Daira (niv.2)

32 Code Commune (niv.3)

### 5. La codification mnémonique

Associer au nom de l'objet, un nom abrégé qui rappelle l'objet codifié.

- Code postal CP
* la répartition des objets en catégories n'est pas toujours évidente

### 3. La codification articulée

Attribuer des codes découpés en zones significatives (zone: descripteur)

Exemple: matricule d'un véhicule : 0233-111-35

#### 0233 N° Séquentiel

1. Catégorie du véhicule (1 tourisme, 2 transport en commun, 3 engins,...)

11. Année de mise en circulation

35. Code Wilaya d'enregistrement

**Avantages:**

* Significative

* Très utilisée

* Non ambiguë

* insertion et extension possible

* Possibilité de regrouper les objets selon un critère donné

* Possibilité de contrôler

**Inconvénients :**

* Code trop long donc lourd à manipuler

* Possibilité de saturation d'une zone

* Instabilité

### 4. La codification par niveau ou hiérarchique

Cas particulier de la codification articulée, les zones (descripteurs) sont des niveaux.

Exemple: Code postal 16132

16 Code Wilaya (niv.1)

1 Code Daira (niv.2)

32 Code Commune (niv.3)

### 5. La codification mnémonique

Associer au nom de l'objet, un nom abrégé qui rappelle l'objet codifié.

- Code postal CP
– Compte courant postal CCP

Avantages

•Facile à mettre en œuvre

•Significative

Inconvénients

•Porte sur le nom et non sur la valeur

•Utiliser uniquement pour coder les variables dans des programmes informatiques et les noms de données
dans les bases de données

Question : quel est le type de codification adopté pour les matricules étudiants ?

CONTROLE DES DONNEES :

Contrôler une information c'est vérifier sa justesse et sa conformité à la réalité de l'organisation. Il existe 2 types de contrôles : Les contrôles directs et Les contrôles indirects

1. Les contrôles directs :

Les contrôles qui s'effectuent sur l'information elle-même, sans tenir compte des autres informations existantes
dans le système.

Les contrôles directs peuvent être des contrôles de présence (Exemple: dans une opération de prêt d'un ouvrage, l'emprunteur doit faire partie des abonnés de la bibliothèque) ou de non présence (la saisie d'un nouvel abonné sous-entend que ce dernier n'existe pas dans le fichier des abonnés) ou encore des contrôles de type, il s'agit de vérifier que le type d'une information correspond à ce qu'il doit être (Exemple: Code postal = 16190, Erreur, car le caractère I n'est pas un chiffre. Le code postal doit être numérique).

2. Les contrôles indirects :

Vérifier la conformité d'une information par rapport à d'autres informations se trouvant dans le système (Il y a comparaison entre les informations) ou tout simplement être en accord avec le bon sens. Exemples:

Le prix unitaire d'un produit doit être supérieur strictement à 0,

Une note ne peut pas être supérieure à 20.

La date de mutation ou de promotion d'un employé doit être supérieure à la date de recrutement de l'entreprise
– Compte courant postal CCP

Avantages

•Facile à mettre en œuvre

•Significative

Inconvénients

•Porte sur le nom et non sur la valeur

•Utiliser uniquement pour coder les variables dans des programmes informatiques et les noms de données
dans les bases de données

Question : quel est le type de codification adopté pour les matricules étudiants ?

CONTROLE DES DONNEES :

Contrôler une information c'est vérifier sa justesse et sa conformité à la réalité de l'organisation. Il existe 2 types de contrôles : Les contrôles directs et Les contrôles indirects

1. Les contrôles directs :

Les contrôles qui s'effectuent sur l'information elle-même, sans tenir compte des autres informations existantes
dans le système.

Les contrôles directs peuvent être des contrôles de présence (Exemple: dans une opération de prêt d'un ouvrage, l'emprunteur doit faire partie des abonnés de la bibliothèque) ou de non présence (la saisie d'un nouvel abonné sous-entend que ce dernier n'existe pas dans le fichier des abonnés) ou encore des contrôles de type, il s'agit de vérifier que le type d'une information correspond à ce qu'il doit être (Exemple: Code postal = 16190, Erreur, car le caractère I n'est pas un chiffre. Le code postal doit être numérique).

2. Les contrôles indirects :

Vérifier la conformité d'une information par rapport à d'autres informations se trouvant dans le système (Il y a comparaison entre les informations) ou tout simplement être en accord avec le bon sens. Exemples:

Le prix unitaire d'un produit doit être supérieur strictement à 0,

Une note ne peut pas être supérieure à 20.

La date de mutation ou de promotion d'un employé doit être supérieure à la date de recrutement de l'entreprise
Si le mois=février, le jour doit être <=29

Un code postal ne peut pas prendre la valeur : 49110 car il n'y a pas de wilaya 49.
Si le mois=février, le jour doit être <=29

Un code postal ne peut pas prendre la valeur : 49110 car il n'y a pas de wilaya 49.
Facteurs de non qualité du logiciel

* Mauvaises spécifications

• Vagues, incomplètes, instables

* Mauvaises estimations

• Fausses, oublis, précisions insuffisantes

* Mauvaise répartition des tâches

• Organisation inadaptée, contraintes omises

* Mauvais suivi

• Ecarts non détectés à temps

* Mauvaise réalisation technique

• Codage, tests, documentation

* Problèmes humains

• Mauvaise distribution des travaux

• Conflits, rétention d'information

* Manque d'expérience du métier de Chef de projet

Le problème de la conformité aux besoins

Besoins exprimés

Produit réalisé

<figure><img src="image_40.png" /></figure>

a : satisfaction

b : non conformité

c : insatisfaction client

d : satisfaction hasardeuse

e : prestations imputables hors spécification.

f : spécifications et prestations imputables

g : spécifications imputables

Spécifications rédigées
Facteurs de non qualité du logiciel

* Mauvaises spécifications

• Vagues, incomplètes, instables

* Mauvaises estimations

• Fausses, oublis, précisions insuffisantes

* Mauvaise répartition des tâches

• Organisation inadaptée, contraintes omises

* Mauvais suivi

• Ecarts non détectés à temps

* Mauvaise réalisation technique

• Codage, tests, documentation

* Problèmes humains

• Mauvaise distribution des travaux

• Conflits, rétention d'information

* Manque d'expérience du métier de Chef de projet

Le problème de la conformité aux besoins

Besoins exprimés

Produit réalisé

<figure><img src="image_36.png" /></figure>

a : satisfaction

b : non conformité

c : insatisfaction client

d : satisfaction hasardeuse

e : prestations imputables hors spécification.

f : spécifications et prestations imputables

g : spécifications imputables

Spécifications rédigées
## Sept principes de la qualité

* Formalisation des procédures
  « Ecrire ce que l'on doit faire »

* Contrôle du respect des procédures
  « Vérifier que ce qui est fait est conforme à ce qui a été écrit »

* Traçabilité
  « Ecrire ce que l'on a fait »

* Mesure de la qualité
  « Apprécier la satisfaction du client »

* Calibrage par le retour d'expérience
  « Améliorer les procédures de façon continue »

* Unicité de responsabilité
  « Eviter la confusion des rôles »

* Séparation du contrôle et de la production
  « Eviter d'être juge et partie »

## Mesure de la qualité
Exemple - Facilité d'apprentissage

<table><thead><tr><td>Questions</td><td>Réponse</td></tr></thead><tbody><tr><td>Aptitude à être mémorisé</td><td></td></tr><tr><td>♦ Chaque bouton correspond t-il à une fonction unique ?</td><td></td></tr><tr><td>♦ Existe t-il des valeurs par défaut pour les entrées ?</td><td></td></tr><tr><td>♦ Les procédures d'arrêt sont-elles décrites ?</td><td></td></tr><tr><td>♦ ...</td><td></td></tr><tr><td>Gestion des erreurs</td><td></td></tr><tr><td>♦ Toute erreur en entrée est-elle signalée explicitement ?</td><td></td></tr><tr><td>♦ Quand une commande est potentiellement destructrice, est-elle confinnée ?</td><td></td></tr><tr><td>♦ Existe t-il une liste des erreurs en ligne ?</td><td></td></tr><tr><td>♦ ...</td><td></td></tr><tr><td>Total</td><td></td></tr></tbody></table>
## Sept principes de la qualité

* Formalisation des procédures
  « Ecrire ce que l'on doit faire »

* Contrôle du respect des procédures
  « Vérifier que ce qui est fait est conforme à ce qui a été écrit »

* Traçabilité
  « Ecrire ce que l'on a fait »

* Mesure de la qualité
  « Apprécier la satisfaction du client »

* Calibrage par le retour d'expérience
  « Améliorer les procédures de façon continue »

* Unicité de responsabilité
  « Eviter la confusion des rôles »

* Séparation du contrôle et de la production
  « Eviter d'être juge et partie »

## Mesure de la qualité
Exemple - Facilité d'apprentissage

<table><thead><tr><td>Questions</td><td>Réponse</td></tr></thead><tbody><tr><td><strong>Aptitude à être mémorisé</strong><ul><li>Chaque bouton correspond t-il à une fonction unique ?</li><li>Existe t-il des valeurs par défaut pour les entrées ?</li><li>Les procédures d'arrêt sont-elles décrites ?</li><li>...</li></ul></td><td></td></tr><tr><td><strong>Gestion des erreurs</strong><ul><li>Toute erreur en entrée est-elle signalée explicitement ?</li><li>Quand une commande est potentiellement destructrice, est-elle confirmée ?</li><li>Existe t-il une liste des erreurs en ligne ?</li><li>...</li></ul></td><td></td></tr><tr><td>Total</td><td></td></tr></tbody></table>
La norme internationale ISO 9241-12 publiée en 1998, (deviendra 9241-111 en 2008), précise également
sept principes pour la présentation des informations, clairement mis en valeur dans la révision précédemment
citée 9241-110 :

(1) **Clarté** : le contenu s'affiche rapidement et avec précision

(2) **Discriminabilité** : les informations peuvent être distinguées avec précision,

(3) **Concision** : seules les informations nécessaires à la tâche sont affichées

(4) **Cohérence** : les mêmes informations sont présentées de manière identique sur toute l'application

(5) **Détectabilité** : les informations sont codées de façon adéquate au bon endroit

(6) **Lisibilité** : l'information est facile à lire

(7) **Compréhensibilité** : la signification des termes est clairement compréhensible.

Quelques recommandations pour une interface graphique qui répond aux normes internationales :

• pas plus de huit options par sous menu

• ordonnez les options par priorité,

• groupez-les par type de fonctionnalité.

• Existence de : lignes séparatrices, codes émis depuis le clavier (raccourcis),

• menus hiérarchiques

• pas plus de trois couleurs dans une fenêtre de dialogue

• Soigner les retours utilisateur : messages (avertir, demande de confirmation, guider en cas d'erreurs..), bips (effets sonores)...

• Consistance des termes avec la documentation du métier

• S'inspirer des logiciels existants : windows, word...
La norme internationale ISO 9241-12 publiée en 1998, (deviendra 9241-111 en 2008), précise également
sept principes pour la présentation des informations, clairement mis en valeur dans la révision précédemment
citée 9241-110 :

(1) **Clarté** : le contenu s'affiche rapidement et avec précision

(2) **Discriminabilité** : les informations peuvent être distinguées avec précision,

(3) **Concision** : seules les informations nécessaires à la tâche sont affichées

(4) **Cohérence** : les mêmes informations sont présentées de manière identique sur toute l'application

(5) **Détectabilité** : les informations sont codées de façon adéquate au bon endroit

(6) **Lisibilité** : l'information est facile à lire

(7) **Compréhensibilité** : la signification des termes est clairement compréhensible.

Quelques recommandations pour une interface graphique qui répond aux normes internationales :

* pas plus de huit options par sous menu

* ordonnez les options par priorité,

* groupez-les par type de fonctionnalité.

* Existence de : lignes séparatrices, codes émis depuis le clavier (raccourcis),

* menus hiérarchiques

* pas plus de trois couleurs dans une fenêtre de dialogue

* Soigner les retours utilisateur : messages (avertir, demande de confirmation, guider en cas d'erreurs..), bips (effets sonores)...

* Consistance des termes avec la documentation du métier

* S'inspirer des logiciels existants : windows, word...
# Symétrie
(partage équilibrée des zones de l'écran)

<figure><img src="image_41.png" /></figure>

## Même hauteur des champs de saisie

<figure><img src="image_42.png" /></figure>

## Longueur harmonisée des champs de saisie

<figure><img src="image_43.png" /></figure>
Symétrie
(partage équilibrée des zones de l'écran)

<figure><img src="image_37.png" /></figure>

Même hauteur des champs de saisie

<figure><img src="image_38.png" /></figure>

Longueur harmonisée des champs de saisie

<figure><img src="image_39.png" /></figure>
**Largeur**
minimum des
boutons

<figure><img src="image_44.png" /></figure>

**Alignement des titres avec les champs de saisie**

<figure><img src="image_45.png" /></figure>

**Alignement des titres (pas de dépassement)**

<figure><img src="image_46.png" /></figure>
**Largeur**
minimum des
boutons

<figure><img src="image_40.png" /></figure>

**Alignement des titres avec les champs de saisie**

<figure><img src="image_41.png" /></figure>

**Alignement des titres (pas de dépassement)**

<figure><img src="image_42.png" /></figure>
<figure><img src="image_47.png" /></figure>

Bad

<figure><img src="image_48.png" /></figure>

Good
<figure><img src="image_43.png" /></figure>

Bad

<figure><img src="image_44.png" /></figure>

Good
BIBLIOGRAPHIE :

* [Diviné et Tardieu, 1989] Diviné, M., & Tardieu, H. (1989). Parlez-vous Merise?. Eyrolles.

* [Diviné, 1994] Diviné, M. (1994). *MERISE: 60 Affaires classées*. Eyrolles.

* [LE MOIGNE, 1971] LE MOIGNE J.L., « Les Systèmes d'Information », Editions d'organisation, 1971

* [Matheron et al., 1990] Matheron, J. P., Daumard, P., & Tardieu, H. (1990). Comprendre Merise: outils conceptuels et organisationnels. Eyrolles.

* [Tardieu et al., 1984] Tardieu, H., Rochfeld, A., & Colletti, R. (1984). La méthode merise-principes et outils (No. BOOK). Les éditions d'organisation.

* [Tardieu et al., 1985] Tardieu, H., Rochfeld, A., Colletti, R., Panet, G., & Vahée, G. (1985). La méthode Merise. 2: démarche et pratiques.
BIBLIOGRAPHIE :

* [Diviné et Tardieu, 1989] Diviné, M., & Tardieu, H. (1989). Parlez-vous Merise?. Eyrolles.

* [Diviné, 1994] Diviné, M. (1994). *MERISE: 60 Affaires classées*. Eyrolles.

* [LE MOIGNE, 1971] LE MOIGNE J.L., « Les Systèmes d'Information », Editions d'organisation, 1971

* [Matheron et al., 1990] Matheron, J. P., Daumard, P., & Tardieu, H. (1990). Comprendre Merise: outils conceptuels et organisationnels. Eyrolles.

* [Tardieu et al., 1984] Tardieu, H., Rochfeld, A., & Colletti, R. (1984). La méthode merise-principes et outils (No. BOOK). Les éditions d'organisation.

* [Tardieu et al., 1985] Tardieu, H., Rochfeld, A., Colletti, R., Panet, G., & Vahée, G. (1985). La méthode Merise. 2: démarche et pratiques.