Chapitre 2

1. Introduction :

Aujourd’hui l’informatique n’est pas destinée uniquement à des spécialistes, elle est
devenue un outil de gestion presque dans tous les organismes qui doivent concevoir des
solutions informatique, notamment les systèmes d’information

Dans ce chapitre, on représente la conception d’un système d’information automatisée de

la gestion de salle de sport. Dans les premières sections de ce chapitre on prese,nte notre
objective de travail, modélisation des systèmes d’informations, une petite description de
la méthode Merise. Ensuite, on décrive les différons phases du cycle de vis de conception
d’un système informatisée pour la gestion d’une salle de sport.

2. Objectif de travail :

Notre objectif est de réaliser un système informatisé pour la gestion d’une salle de sport.
Tel système se propose offrir une gestion informatisée intégré des diverses opérations
d’une salle de sport offrant des services diagnostics sous forme de l’ajout d’Athlète
(Homme ou Femme, a partir de ça Taille et ça Poids l’Entraineur affecter un Programme
d’entrainement a l’Athlète, et un Entraineur qui suive le, un Régime s’il besoins …etc.) et
de L’Ajout d’Entraineur, Programme d’entrainement, Régime 

Le système devra offrir les fonctionnalités suivantes :

1. Propulsion et la gestion des fichiers des Athlètes, y compris leurs données

personnelles, leurs historique d’Abonnement et leurs Programmes d’entrainement
et leurs Entraineurs, et Régimes.
2. Le paiement des services rendus par les Athlètes selon diverses modalités (Par
Année, Mois, Semaine) et en plusieurs versements.
3. La gestion des Entraineurs y compris leurs données personnelles, leur historique
d’Abonnement et ses Athlètes.
4. La gestion des Programmes d’entrainement et les Athlète qui les participent.
5. La gestion des Régimes et les Athlète qui les participent.
6. Production statistique.
7. Alerte l’utilisateur quand l’abonnement d’un athlète est fini.
8. Alerte l’utilisateur quand l’athlète se termine son programme d’entrainement.
9. Alerte l’utilisateur quand l’athlète se termine son Régime.
 Chapitre 2

3. Modélisation des Systèmes d’information :

Un système d’information est une représentation possible du système dont une partie peut
être automatisée, on parle alors de système informatisé. Ce dernier prend appui sur un
système informatique composé de matériels et de logiciels de base.

En pratique la modélisation (représentation de la réalité sous forme des graphes) d’un

système nécessite l’utilisation d’une combinaison de types de modèles (modèles de flux
d’information, modèles de données, modèles de traitements, etc.) pour obtenir une
représentation complète du système avec différents niveaux d’abstraction (conceptuel,
organisationnel et technique pour la méthode Merise par exemple).
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é analyse. Il existe
plusieurs méthodes d'analyse que l’on peut classer en quatre catégories :
 Les méthodes d’analyse: comme CORIG,  Robert Mallet, fondateur de la CGI,
Compagnie Générale d'Informatique, société de services et d'ingénierie
informatique, inventa la méthode CORIG vers 1960. Cette méthode pour
informatiser les procédures de gestion permit le succès de son entreprise. Elle fut
déclinée sous forme de générateurs de programme COBOL et de progiciels de
gestion. Cette méthode associe fortement les concepts de l'organisation du travail
tertiaire et les spécificités de la programmation informatique. Ses caractéristiques
essentielles sont ici rappelées. Elle a contribué à la genèse de la méthode Merise,
largement diffusée en France.
( http://www.revuesim.org/sim/article/view/125)
 Les méthodes cartésienne : La Méthode SADT : Méthode d'analyse fonctionnelle La
méthode SADT (Structured Analysis Design Technic) est une méthode d'analyse
hiérarchique et descendante apparue en 1977 au sein de la société Sof'Tech Inc.
C'est une méthode d'analyse par niveaux successifs d'approche descriptive d'un
ensemble quel qu'il soit. Elle a été introduite en Europe à partir de 1982. Les auteurs
la présentent comme une méthode pour « communiquer des problèmes ». On peut
appliquer SADT à la gestion d'une entreprise tout comme à un système automatisé.
 Chapitre 2
La méthode SADT est fondée sur un formalisme graphique et textuel facile à
apprendre. Elle permet d'une part de modéliser le problème posé (informatique,
automatique ou autre), avant de chercher à en extraire une solution, et d'autre part
d'assurer une communication efficace entre les différents intervenants concernés
par le système à analyser.)
 Les méthode systémique : La méthode MERISE (Méthode d' Etude et de

Réalisation Informatique de Systèmes d'Entreprise), est une méthode de

conception, de développement et de réalisation de projets informatiques.
 Les méthodes objets UML : (Unified Modeling Language, que l'on peut traduire
par "langage de modélisation unifié) est une notation permettant de modéliser un
problème de façon standard. Ce langage est né de la fusion de plusieurs méthodes
existant auparavant, et est devenu désormais la référence en terme de modélisation
objet, à un tel point que sa connaissance est souvent nécessaire pour obtenir un
poste de développeur objet.

3.1 Description de méthode Merise :

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.
Merise étant une méthode de conception et de développement de système d’information.
Le but de cette méthode est d'arriver à concevoir un système d'information. La méthode
MERISE est basée 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 présente comme avantage indéniable de permettre une définition claire
et précise de l’ensemble du système d’information et d en défini correctement le
périmètre .Elle ce caractérise par :

 Une approche systémique en ayant une vue de l’Enterprise en terme de système

 Chapitre 2

 Une séparation des données (le Cote statique) et des traitements (le cote
dynamique) 
 Une approche par niveaux
 La méthode Merise est bien adaptée l’automatisation de tâches séquentielles de
gestion pure.
 Un grand nombre d’ensembles d’informations manipulée nécessite un travaille de
cohérence indispensable et d’optimisation des couts de stockage et de traitement
des informations
 Les informations sont structurées et classées, sans répétition, en deux type
d’ensemble (d’information), les individus et les relations
MERISE définit trois niveaux de description du système d'information :
le niveau conceptuel,
le niveau organisationnel,
le niveau physique
 Le niveau conceptuel : qui se base directement sur l’analyse, décrit l’ensemble des
données et des traitements du système d’information, sans tenir compte de
l’implémentation informatique de ses données ni des détails organisationnels des
traitements (quoi ?). se niveau se traduit par deux méthodes conceptuels que nous
appelons : Modèle conceptuel des données (MCD) et Modèle conceptuel des
traitements (MCT)
 Le niveau Logique : Il s’articule sur le modèle conceptuel, prend en considération la
technique d’organisation de données et les détails organisationnels des traitements(Le
Qui, Ou et Quand?). Ce niveau est représenté par les Modèles logique des données
(MLD) et Modèles Organisationnel des traitements (MOT)
 Le niveau physique : IL se base sur les modèles du niveau Précédent, contient
finalement tous les détails d’implémentations du système de données et des
traitements (Comment ?). Ce niveau est représenté par les Modèles physique des
données (MPD) et Modèles Opérationnels Des traitements (MOpt)

Niveau Statique (données) Dynamique (traitements)

Conceptuel MCD MCT

 Chapitre 2
Indépendant du
système:
QUOI ?
Organisationnel ou MLD MOT QUI ?
logique (OU ?) (QUI ? QUAND ?) QUAND ? OU ?

Opérationnel ou COMMENT ?
physique MPD MOpt

4. conception d’un système informatisée pour la gestion d’une

salle de sport :

Par la suite on va décrire les différentes étapes de conception d’un système automatisé
d’information en appliquant la méthode de Merise.

Discours Documents

DD

DF

GDF

MCD BRUT

MCD Normalisé

Figure :
 Chapitre 2
DD  : Dictionnaire de données 

DF  : Dépendance Fonctionnelle

GDF : Graphe des dépendances fonctionnelles

4.1 Règles de gestion :

Les règles de gestion précisent les contraintes qui doivent être respectées par le modèle.

En effet grâce aux règles de gestion nous pouvons, entre autres, déduire les relations entre
les objets et déterminer les cardinalités du MCD.et voici quelques règles :

Un Athlète est identifie par son nom, prénom, âge, poids, sexe, photo, adresse,
numéro de téléphone,
Un Entraineur est identifie par son nom, prénom, sexe, photo, adresse, numéro de
téléphone,
Un type Programme est identifie par son description.
Un Programme est identifie par son nom, durée, description.
Un Régime est identifie par son nom, durée, description.
Un Entraineur peut former de nombreux athlètes, et a une seule abonnement à la
fois.
Chaque Athlète a un et un seule programme, un régime, un entraineur ,un sport et
une fiche d’abonnement à la fois.
Un athlète abonné plusieurs fois.
Un athlète peut verser plusieurs versements.
Un athlète peut avoir plusieurs notifications.
Une fiche d’abonnement est associe à un seul athlète.
Un programme peut être participé par plusieurs Athlètes.
Un régime peut être suive par plusieurs athlètes.
Un type de programme contient plusieurs programmes, et plusieurs Régimes
Chaque Programme a un seul type de programme.
Chaque Régime a un seul type de programme.
On garde l’historique des programmes, régimes, entraineurs et les abonnements des
athlètes.
 Chapitre 2

4.2 Dictionnaire de données :

Pour construire le modèle conceptuel de donnée, Merise propose un outil nécessaire pour
aide à la construction de modèles conceptuel des données cet outil est le dictionnaire de
donnée

Dictionnaire des données est:

 L'ensemble des données (propriétés du MCD) correspondant à la description de toutes les

entités du modèle.

 Chaque donnée représentera une rubrique d'information homogène pour chaque entité du
système d'informations.

Objet Rubrique Libellé Type Taille

Athlète IDAthlète Identifiant de l’athlète Entier 4

NomAthlète Nom de l’athlète Texte 50

PrenomAthlète Prénom de l’athlète Texte 50

AgeAthlète Age de l’athlète Entier 2

AdresseAthlète Adresse de l’athlète Texte 60

NumTelAthlète Numéro de téléphone Entier 10

SexeAthlète Sexe de l'athlète Chaine 5

PhotoAthlète Photo de l’athlète Image

PoidAthlète Poids d athlète Réel 10

ActiveAthlète Athlète Active / non Booléen 1

Entraineur IDEntraineur Identifient Entier

NomEntraineur Nom de l’Entraineur Texte 50

 Chapitre 2

PrenomEntraineur Prénom de l’Entraineur Texte 50

NumTelEntraineur Numéro de Téléphone Entier 10

AdresseEntraineur Adresse d’Entraineur Texte 60

SexeEntraineur Sexe d’Entraineur Texte 5

PhotoEntraineur Photo d’Entraineur Image

SalaireEntraineur Salaire d’Entraineur Réel 10

ActiveEntraineur Entraineur active/non Booléen 1

Programme IDProgramme Identifient Entier

NomProgramme Nom de Programme Texte 50

DescriptionP Description de Programme Texte 65534

DuréeP La durée de Programme Entier 4

ActiveProgramme Programme Active/non Booléen 1

Régime IDRégime Identifient Entier

NomRégime Nom de Régime Texte 50

DescriptionRégime Description de Régime Texte 65534

DuréeRégime Durée de Régime Entier 3

ActiveRégime Régime Active/non Booléen 1

TypeProgramme IDTypeProgramme Identifient Entier

DescriptionTP Description type Texte 50

programme

Sport IDSport Identifient Entier

descriptionSport Description de Sport Texte 50

Historique- IDAbonnement Identifient Entier

Abonnement
 Chapitre 2

DateDebutAbonnement Date début d’abonnement Date 8

DateFinAbonnement Date Fin Abonnement Date 8

EtatAbonnement L’abonnement actuel/ non boolien

verssement IDverssement Identifient Entier

PrixTotal Prix Totale de Paiement Réel 10

DateP Date de Paiement Date 8

TypePay Type Paiement Texte 10

Versnt Versment Réel 10

NombreSéance Nombre de séance par Entier 1

semaine

MotDePasse IDMotdePasse Identifient Entier

NomUtulisateur d automatique Texte 50

MotDePasse Nom d'utilisateur Texte 50

Active Mot de passe Booléen 1

Mot de passe active/Non

Régnant IDrégnant Identifiant de régnant Entier

NomRégnant Nom de Régnant Texte 50

prénomRégnant Prénom de régnant Texte 50

AdresseRégnant Adresse de régnant Texte 50

NumTelRégnant Numéro de telephone de Entier 10

régnant

Nom de la salle du sport

NomGym gym Texte 50
 Chapitre 2

Abonnement- IDAbonnementEnt Identifient Entier 4

Entraineur
dateAbonnementEnt Date d’abonnement Date

dateFinAbonement Date fin de l’abonnement Date

EtatAbonnement Abonnement actuel ou non Boolien

Table 1 : Dictionnaire de données

4.3 Dépendance fonctionnelle :

Dépendance fonctionnelle : il y a dépendance fonctionnelle entre deux propriétés lorsque la

connaissance d'une valeur d'une propriété permet de déterminer une et une seule valeur
d'une autre propriété, la dépendance fonctionnelle est notée P1 P2;

Exemple : IDAthlète NomAthlète

En revanche NomAthlète ne détermine pas l’IDAthlète.

4.4 Graphe des dépendances fonctionnelles :

Il s'agit d'ordonner, pour avoir une vision synthétique, le résultat de l'analyse des DF faite
précédemment.

4.5 Modèle Conceptuel de données (MCD) :

4.6.1 MCD Brut :

 Chapitre 2

Figure : Modèle conceptuel de donnée brut (MCD Brut)

4.7 MCD Normalisé :

Tout MCD doit être normalisé, vérifié et décomposé.

4.7.1 Normalisation des entités :

La normalisation a pour objectif d'éliminer les redondances dans la base ainsi que les
anomalies de mise à jour. Dans notre MCD il y a une redondance entre les entités Athlète
et Programme, Athlète et Régime, Athlète et Entraîneur, pour enlever cette redondance on
va éliminer les trois associations avoirReg, Suivée et Avoir, et ajouter les attributs EtatPgm,
 Chapitre 2
EtatRgm et EtatEnt dans les associations HistoriqueProgramme, HistoriqueRégime et
HistoriqueEntraineur respectivement.

Les entités doivent vérifier ensemble de règles.

 Première forme normale (1ère FN)

Toutes les propriétés sont élémentaires et il existe un identifiant. Sinon on
décompose une propriété en plusieurs propriétés et/ou on crée une propriété
identifiant.
 Deuxième forme normale (2ème FN)
Toute propriété dépend de l'identifiant par une dépendance fonctionnelle (DF)
élémentaire. Donc chaque propriété dépend de tout l'identifiant et non pas d'une
partie. Sinon on décompose en plusieurs entités.
 Troisième forme normale (3FN)
Toute propriété doit dépendre de l'identifiant par une DF directe. Donc tous les
attributs non identifiants sont indépendants entre eux. Sinon on décompose en deux
entités. [PDF petit Merise]

4.7.2 Normalisation des entités

Les entités du MCD doivent vérifier les règles suivantes :

1ère forme normale : dans une entité, toutes les propriétés sont élémentaires et il existe au
mois une clé caractérisant chaque occurrence (identifiant).

2ème forme normale : toutes les propriétés d'une entité doivent dépendre de la clé par une
dépendance fonctionnelle élémentaire.

3ème forme normale : dans une entité, les propriétés doivent dépendre de la clé par une
dépendance fonctionnelle élémentaire directe.

4.7.3 Normalisation des relations :

Chaque propriété d'une relation doit dépendre fonctionnellement de l'ensemble des

identifiants des entités de la collection de cette relation, mais d'aucun sous-ensemble.

4.8 Vérification
Dans toute occurrence d'entité ou de relation, il ne doit y avoir qu'une seule valeur de
chaque propriété. Pour les entités ceci résulte de la première forme normale.
 Chapitre 2
"Les propriétés d'une relation doivent dépendre fonctionnellement des identifiants des
entités concernées par la relation. La concaténation de ces identifiants forme l'identifiant de
la relation."

4.9 Décomposition des relations

La décomposition consiste à remplacer une relation de dimension n (supérieure à 2) en
plusieurs relations de dimensions plus petites en utilisant les dépendances fonctionnelles
présentes sur la relation.
La décomposition n'est possible que si les deux conditions sont vérifiées :
1. Cardinalité minimale des entités à gauche de la dépendance fonctionnelle doit être 1
dans la relation à décomposer
2. Si la dépendance fonctionnelle provient d'une autre relation, il faut qu'elle concerne
les mêmes occurrences d'entités que la relation à décomposer. [bouamari]

Figure : Modèle conceptuel de donnée(MCD)

 Chapitre 2

5. Modèle de conceptuel des traitements (MCT) :

Arrivée d’un athlète

-Enregistrer les informations de l’athlète.

-Lui affecter un programme, un entraineur et un régime.

-Ajouter un abonnement.
Met la liste des athlètes à
Toujours jours

Programme
Régime

Nouveau
programme Pgm
Fiche d’abonnement Rgm
-vérifier le programme
-vérifier le régime.
Terminer Pas encore
Terminer Pas encore

Abonnement
Vérifier l’abonnement
Terminer(a) Pas encore Nouvelle régime
Indiquer que cet athlète n’a
pas de régime

Versement (b)

b et (a ou c)

Paiement
-Vérifier le reste de paiement.
Il y a de reste(c) Il n’y a pas

Met l’abonnement comme payer

Choisir traitement

Nouvelle abonnement

Supprimer l’athlète
 Chapitre 2

Figure : Modèle conceptuel des traitements (MCT)

Le modèle conceptuel des traitements permet de traiter la dynamique du système

d'information, c'est-à-dire les opérations qui sont réalisées en fonction d'événements.

Ce modèle permet donc de représenter de façon schématique l'activité d'un système

d'information sans faire référence à des choix organisationnels ou des moyens d'exécution,
c'est-à-dire qu'il permet de définir simplement ce qui doit être fait, mais il ne dit pas quand,
comment ni où[http://www.commentcamarche.net/contents/660-merise-modele-
conceptuel-des-traitements]

5.1 Définitions
 Evénement : traduit un fait nouveau dans le système qui peut être déclencheur ou
résultat d’une opération du SI. Ce fait est porteur d’information.
 Opération : ensemble d’actions accomplies en réaction à un événement ou à une
conjonction d’événements déclencheurs et produit en sortie de nouveaux
événements. L’enchainement des actions dans une opération conceptuelle est
interruptible et toute attente d’un événement externe provoque un découpage de
l’opération.
 Synchronisation : c’est la représentation d’une pré-condition au déclenchement
d’une opération ; c’est une association d’événements. L’opération est déclenchée
après arrivées des événements contributifs selon une proposition logique (OU et
ET).
 Règle d’émission : condition traduisant les règles de gestion, auxquelles est
soumise l’émission des résultats d’une opération. Ces règles doivent couvrir
l’ensemble des situations possibles de façon que l’opération émette toujours un
résultat.
 Processus : c’est un enchaînement d’opérations propre à un domaine d’activités.
C’est un sous-ensemble d’activités dont les points d’entrée et de sortie sont stables
et indépendants des choix organisationnels.

Le MCT représente les opérations effectuées dans le SI sans tenir compte de l’affectation
des taches ni de la durée ou de l automatisation de celle-ci ni de données affectées par
ceux-ci. Il est un outil de conception des traitements et de communication et permet de
 Chapitre 2
préparer le MOT ou on décrira alors qui fait quoi, pour arriver a l’étude des postes de
travaille des acteurs.

Le modèle suivant est Modèle Organisationnel des traitements.

6. Modèle Organisationnelle de traitement (MOT) :

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 données, c'est-à-dire :
 Quand ? : le temps et la durée (déroulement).
 Qui? : nature du traitement manuel ou automatisé (batch ou conversationnel).
 Où?  : le poste de travail concerné.
6.1 Définitions

1. Règle d’organisation : ce qui est mis en place en termes de poste de travail, de nature
de traitement et de chronologie.

2. Evénement : fait réel dont l’occurrence déclenche une ou plusieurs procédure

fonctionnelles (ex. arrivée déclaration sinistré).

3. Procédure fonctionnelle : ensemble d’actions de même nature accomplies dans un poste

de travail en réaction à un déclencheur de manière continue et complète.

4. Synchronisation : condition logique traduisant les règles de gestion et d’organisation

que doivent vérifier les événements pour déclencher les procédures. Le déroulement
(temps et durée) fait partie intégrante de la synchronisation (ex. demande inscription et
début année)

5. Règle d’émission : condition traduisant les règles de gestion et d’organisation,

auxquelles est soumise l’émission des résultats d’une procédure. [bouamari]
Natur Poste de
Déroulement Enchainement des phases travail
e
 Chapitre 2
Arrivée d’un athlète
Aléatoire
(a chaque
arrivée
d’un nouvel -Enregistrer les informations de l’athlète.
-Lui affecter un programme, un entraineur et un régime.
athlète) -Ajouter un abonnement.
Toujours

Manuel

Met la liste des athlètes à jours

Programme

Date fin du
programme-
7jours Pgm
-vérifier le programme
Terminer Pas encore

Auto
Nouveau programme Régime
Régnan
t
Rgm
-vérifier le régime.
Date fin du
Terminer Pas encore
régime-7jours
Nouvelle régime

Indiquer que cet athlète n’a pas de régime

Auto
Fiche d’abonnement

Date fin
d’abonnemen
t
Abonnement
-Vérifier l’abonnement
Terminer(a) Pas encore

Versement (b)

b et (a ou c)

Paiement Met l’abonnement comme payer

-Vérifier le reste de paiement.
Il y a de reste(c) Il n’y a pas Auto

Choisir traitement

Nouvelle abonnement
Supprimer l’athlète
 Chapitre 2

Manuel
Figure : Modèle organisationnel des traitements

7. Modèle Logique de données (MLD) :

On ne sait pas implémenter directement un modèle conceptuel des données dans une
machine et il existe différentes sortes de SGBD qui ont chacun leur propre modèle : SGF
(qui ne sont pas vraiment des SGBD), hiérarchiques (organisés selon une arborescence),
SGBD réseau (encore appelés CODASYL).
Le modèle logique des données (MLD) est composé des relations qui décrivent les tables
de données du système d’information. Il est construit du Modèle conceptuel de données
(MCD) à l’aide de règles de transformation simples. http://scenari-platform.org/mobile-
source/opale-demo/co/01_introduction_web/co/nx17UL014.html
 Chapitre 2

Figure : Modèle logique de donnée (MLD)

8. Conclusion :
D’après ce que nous avons étudiés, nous pouvons dire que la phase de conception est
la plus importante étape dans le développement du système d’information.
Au cours de ce chapitre nous avons présenté les modèles de conception de
réalisation des projets informatique qui permet de structurer les besoins des décideurs de
façon simple et compréhensible et améliorer la communication entre les différents acteurs
du processus de développement.
Dans le chapitre suivant, on va essayer de traduire les modèles de conception en une
application android.
 Chapitre 2

http://www.umc.edu.dz/vf/coursLigne/MSI/MSI_Methodes.pdf