Intitiation à la conception
de système d'information

Le besoin de méthodes

La conception d'un système d'information n'est pas évidente car il faut réfléchir
à l'ensemble de l'organisation que l'on doit mettre en place. La phase de
conception nécessite des méthodes permettant de mettre en place un modèle sur
lequel on va s'appuyer. La modélisation consiste à créer une
représentation virtuelle d'une réalité de telle façon à faire ressortir les points auxquels
on s'intéresse.

Ce type de méthode est appelée analyse. Il existe plusieurs méthodes d'analyse,
la méthode la plus utilisée en France étant la méthode MERISE.

Présentation de la méthode MERISE

MERISE est une méthode de conception, de développement et de réalisation de
projets informatiques. Le but de cette méthode est d'arriver
à concevoir un système d'information. La méthode MERISE
est basé sur la séparation des données et des traitements
à effectuer en plusieurs modèles conceptuels
et physiques.
La séparation des données et des traitements assure une longévité au
modèle. En effet, l'agencement des données n'a pas à être souvent remanié,
tandis que les traitements le sont plus fréquemment.

La méthode MERISE date de 1978-1979, et fait suite à une consultation nationale
lancée en 1977 par le ministère de l'Industrie dans le but de choisir des sociétés
de conseil en informatique afin de définir une méthode de conception de systèmes
d'information. Les deux principales sociétés ayant mis au point cette méthode
sont le CTI (Centre Technique d'Informatique) chargé de gérer le projet,
et le CETE (Centre d'Etudes Techniques de l'Equipement)
implanté à Aix-en-provence.

Cycle d'abstraction de conception des systèmes d'information

La conception du système d'information se fait par étapes,
afin d'aboutir à un système d'information fonctionnel reflétant
une réalité physique. Il s'agit donc
de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part,
les données étant séparées des traitements,
il faut vérifier la concordance entre données et traitement
afin de vérifier que toutes les données nécessaires
aux traitements sont présentes et qu'il n'y a pas de données superflues.

Cette succession d'étapes est appelée cycle d'abstraction pour la conception des
systèmes d'information:

L'expression des besoins est une étape consistant à définir ce que l'on attend du
système d'information automatisé, il faut pour cela:

• faire l'inventaire des éléments nécessaires au système d'information
• délimiter le système en s'informant auprès des futurs utilisateurs

Cela va permettre de créer le MCC (Modèle conceptuel de la communication) qui
définit les flux d'informations à prendre compte

L'étape suivante consiste à mettre au point le MCD
(Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements)
décrivant les règles et les contraintes à prendre en compte

Le modèle organisationnel consiste à définir le MOT
(Modèle organisationnel des traitements) décrivant les contraintes
dûs à l'environnement (organisationnel, spatial et temporel)

Le modèle logique représente un choix logiciel pour
le système d'information

Le modèle physique reflète un choix matériel pour
le système d'information

Modèle conceptuel de la commuinication

Définition de l'organisation

La première étape de ce modèle est d'arriver à isoler le système en le délimitant.
Il s'agit donc de définir le système et les éléments externes
avec lesquels il échange des flux d'information.
Ces éléments extérieurs sont appelés
acteurs externes (ou partenaires).

La seconde étape consiste à découper l'organisation en entités
appelées acteurs internes (ou domaines).
Lorsque les domaines d'une organisation sont trop importants,
ils peuvent être décomposés eux-mêmes en sous-domaines.

La dernière étape est l'analyse des flux d'information, c'est-à-dire la définition
des processus.

Diagramme de contexte

Le diagramme de contexte a pour but de représenter
les flux d'informations entre l'organisation et les acteurs externes
selon une représentation standard
dans laquelle chaque objet port un nom:

• l'organisation est représentée par un rectangle
• les acteurs externes sont représentés
  par des ellipses en pointillés
• les flux d'information sont représentés
  par des flèches dont l'orientation
  désigne le sens du flux d'information

Diagramme conceptuel de flux

Ce diagramme (appelé aussi modèle conceptuel de la communication) permet de
compléter le diagramme de contexte en décomposant
l'organisation en une série d'acteurs internes.
Dans ce diagramme la représentation standard est la suivante:

• Les acteurs internes sont représentés par des ellipses
• les messages internes sont représentés par des flèches

Modèle conceptuel des données

Le modèle conceptuel des données

Le modèle conceptuel des données (MCD) a pour but d'écrire
de façon formelle les données qui seront utilisées par le système d'information. Il s'agit donc d'une
représentation des données,facilement compréhensible,
permettant de décrire le système d'information à l'aide d'entités.

Entités et classe d'entité

Une entité est la représentation d'un élément matériel
ou immatériel ayant un rôle dans le système que l'on désire décrire.

On appelle classe d'entité un ensemble composé d'entités
de même type, c'est-à-dire dont la définition est la même.
Le classement des entités au sein d'une classe s'appelle
classification (ou abstraction).
Une entité est une instanciation de la classe.
Chaque entité est composée de propriétés, données élémentaires permettant de la décrire.

Prenons par exemple une Ford fiesta,
une Renault Laguna et une Peugeot 306.
Il s'agit de 3 entités faisant partie d'une classe d'entité
que l'on pourrait appeler voiture.
La Ford Fiesta est donc une instanciation de la classe voiture.
Chaque entité peut posséder les propriétés couleur, année et modèle.

Les classes d'entités sont représentées par un rectangle.
Ce rectangle est séparé en deux champs:

• le champ du haut contient le libellé.
  Ce libellé est généralement une abbréviation pour une raison de simplification de l'écriture. Il s'agit par contre de vérifier
  qu'à chaque classe d'entité correspond un et un seul libellé,
  et réciproquement
• le champ du bas contient la liste des propriétés
  de la classe d'entité

Relations et classes de relation

Une relation (appelée aussi parfois association) représente les liens sémantiques qui peuvent exister entre plusieurs entités.
Une classe de relation contient donc
toutes les relations de même type
(qui relient donc des entités appartenant à des mêmes classes d'entité). Une classe de relation peut lier plus de deux
classes d'entité. Voivi les dénominations des classes de relation
selon le nombre d'intervenants:

• une classe de relation récursive (ou réflexive)
  relie la même classe d'entité
• une classe de relation binaire relie deux classes d'entité
• une classe de relation ternaire relie trois classes d'entité
• une classe de relation n-aire relie n classes d'entité

Les classes de relations sont représentées par des hexagones
(parfois des ellipses) dont l'intitulé décrit le type de relation
qui relie les classes
d'entité (généralement un verbe). On définit
pour chaque classe de relation un identificateur
de la forme R_i permettant de désigner de façon unique
la classe de relation à laquelle il est associé.

On peut éventuellement ajouter des propriétés aux classes de relation.

La cardinalité

Les cardinalités permettent de caractériser le lien qui existe entre une entité et
la relation à laquelle elle est reliée. La cardianlité d'une relation est composé
d'un couple comportant une borne maximale et une borne minimale, intervalle
dans lequel la cardinalité d'une entité peut prendre sa valeur:

• la borne minimale (généralement 0 ou 1)
  décrit le nombre minimum de fois
  qu'une entité peut participer à une relation
• la borne maximale (généralement 1 ou n)
  décrit le nombre maximum de fois
  qu'une entité peut participer à une relation

Une cardinalité 1.N signifie que chaque entité appartenant
à une classe d'entité participe au moins une fois à la relation
Une cardinalité 0.N signifie que chaque entité appartenant
à une classe d'entité ne participe pas forcément à la relation.

Les identifiants

Un identifiant est un ensemble de propriétés (une ou plusieurs)
permettant de désigner une et une seule entité.
La définition originale est la suivante:

L'identifiant est une propriété particulière
d'un objet telle qu'il n'existe pas deux
occurences de cet objet pour lesquelles
cette propriété pourrait prendre une même

valeur

Les attributs d'une classe d'entité permettant de
désigner de façon unique chaque instance de cette
entité sont appelé identifiant absolu

Le modèle conceptuel des données propose de faire
précéder d'un # les identifiants (parfois de les souligner).

Ainsi, chaque classe d'entité doit posséder au moins
un attribut identifiant, et l'ensemble de ses attributs
identifiants doivent être renseignés à la création de l'entité.

Agrégation (ou identification relative)

Lorsqu'un identifiant est constitué uniquement
d'attributs intrinsèques à une entité,
c'est-à-dire ne faisant référence à aucune autre entité,
on le nomme identifiant absolu. Les entités comportants
des identifiants absolus peuvent être définis indépendamment
des autres occurences d'entités, on dit que ces entités sont indépendantes.

Certaines entitées ne peuvent toutefois être identifiées que par l'intermédiaire
d'autres entités, c'est la raison pour laquelle on parle
d'identification relative.
On parlera par exemple de la 4^ème porte au 2^ème étage
du bâtiment B au lieu de dire la porte n°3451...

Ainsi, l'agrégation (appelée aussi identification relative)
permet de spécifier qu'une entité est nécessaire
pour en identifier une autre.

• la classe d'entité permettant d'identifier est
  appelé classe d'entité agrégeante
• la classe d'entité identifiée est appelée
  classe d'entité agrégée

La représentation de ce type de relation est la suivante:

Contraintes sur rôle

La cardinalité d'une relation permet de définir les conditions
de participation d'une entité à une relation. Toutefois,
une entité peut participer à plusieurs relations,
c'est ce que l'on nomme les contraintes sur rôles.

Contraintes de totalité sur rôles

La contrainte de totalité sur rôles exprime le fait
qu'une entité participe au moins à une des classes
de relation qu'elle met en oeuvre.

Elle est représenté par un "T" reliant deux classes d'entités.

Contraintes d'exclusion sur rôles

La contrainte d'exclusion sur rôles exprime le fait qu'une
entité ne peut pas participer aux deux classes de relation simultanément.

Elle est représenté par un "X" reliant deux classes d'entités.

Lorsque cette contrainte fait intervenir plusieurs relations,
l'entité ne peut pas participer à toutes les relations simultanément,
tout au plus à n-1 relations

Contraintes de sous-ensemble sur rôles

La contrainte de sous ensemble sur rôles exprime
le fait qu'une entité participant
à une classe de relation, participe obligatoirement
à l'autre relation.

Elle est représenté par une flèche reliant deux classes d'entités et
montrant la direction de l'implication.

Cette contrainte ne fait intervenir que deux relations.

Contraintes d'égalité sur rôles

La contrainte d'égalité sur rôles exprime le fait qu'une
entité participant à une classe de relation,
participe obligatoirement à l'autre relation,
et réciproquement. Il s'agit donc d'une contrainte de sous-ensemble bidirectionnelle.

Elle est représenté par un signe "=" reliant deux classes d'entités.

Cette contrainte peut faire intervenir plusieurs relations,
auquel cas une entité participant à une relation doit participer aux n relations.

Contraintes sur relations

Alors que les contraintes sur rôles permettent de définir
les conditions de participation d'une entité à une relation,
les contraintes sur relations permettent d'exprimer
des restrictions sur les classes de relation.

Contraintes d'exclusion sur relations

La contrainte d'exclusion sur relation exprime le fait que
deux occurences de classes d'entité ne peuvent
pas participer simultanément à une même classe de relation.

Elle est représenté par un "X" reliant deux classes de relation.

Contraintes de sous-ensemble sur relations

La contrainte de sous ensemble sur relation exprime le fait que une occurence
de classe d'entité participant à une classe de relation,
participe obligatoirement à l'autre classe de relation.

Elle est représenté par une flèche reliant deux classes de relation et montrant
la direction de l'implication.

Cette contrainte ne fait intervenir que deux relations.

Contraintes d'égalité sur relations

La contrainte d'égalité sur relation exprime le fait qu'une occurence
de classe d'entité participant à une classe de relation,
participe obligatoirement à l'autre classe de relation, et réciproquement.
Il s'agit donc d'une contrainte de sous-ensemble bidirectionnelle.

Elle est représenté par un signe "=" reliant deux classes de relation.

Cette contrainte peut faire intervenir plusieurs occurences de classes d'entité,
auquel cas une occurence de classe d'entité participant à une classe
de relation doit participer aux n classes de relation.

Moèle organistaionnel des traitements

Le modèle organisationnel des traitements

Le modèle organisationnel des traitements s'attache décrire
les propriétés des traitements non traitées par le modèle
conceptuel des traitements, c'est-à-dire:

• le temps
• les ressources
• le lieu

Le modèle organisationnel des traitements consiste donc
à représenter le modèle conceptuel des traitements
dans un tableau dont les colonnes sont la durée, le lieu,
les responsables et ressources nécessaires à une action.

Le tableau des procédures fonctionnelles

La première étape du modèle organisationnel des traitements
consiste à découper les opérations en
procédures fonctionnelles, une succession
de traitements déclenchée par un événement.

Il s'agit donc d'associer dans un tableau:

• les procédures fonctionnelles
• l'heure de début et de fin
• le lieu du poste de travail
• le responsable du poste de travail
• les ressources du poste de travail

Modèle logique des données

Le modèle logique des données

Le modèle logique des données consiste à décrire la structure
de données utilisée sans faire référence à un
langage de programmation. Il s'agit donc de préciser le type
de données utilisées lors des traitements.

Ainsi, le modèle logique est dépendant
du type de base de données utilisé.

Le modèle relationnel

Traduction d'une classe d'entité

Chaque classe d'entité du modèle conceptuel devient une table
dans le modèle logique. Les identifiants de la classe d'entité
sont appelé clés de la table, tandis que les attributs standards
deviennent des attributs de la table, c'est-à-dire des colonnes.

Traduction d'une classe de relation

Le passage du modèle conceptuel au modèle logique au niveau
des classes de relation se fait selon les cardinalités
des classes d'entité participant à la relation:

• si une des classes d'entités possède une cardinalité faible:
  la table aura comme attributs, les attributs de la classe ayant
  une cardinalité faible, puis le (ou les) attribut(s) de relation
  et enfin les attributs de la seconde classe précédé
  du nom de la classe
• si les deux classes d'entités possèdent une cardinalité forte:
  la table aura comme attributs, les attributs des deux classes
  de relation précédés des noms des classes respectives,
  puis le (ou les) attribut(s) de relation

Traduction d'une classe d'agregation

Dans le cas de la présence d'une classe d'agrégation,
la classe d'entité agrégée a comme attributs supplémentaires
les attributs de la classe d'netité agrégeante

Le modèle physique

Cette étape consiste à implémenter le modèle dans le SGBD,
c'est-à-dire le traduire dans un langage de définition de données.

Le langage généralement utilisé pour ce type d'opération est
le SQL, et plus spécialement le langage de définition de
données du SQL.