I.

Introduction :

La conception d'un systme d'information n'est pas vidente car il faut rflchir l'ensemble de l'organisation que l'on doit mettre en place. La phase de conception ncessite des mthodes permettant de mettre en place un modle sur lequel on va s'appuyer. La modlisation consiste crer une reprsentation virtuelle d'une ralit de telle faon faire ressortir les points auxquels on s'intresse. Ce type de mthode est appel analyse. Il existe plusieurs mthodes d'analyse, la mthode la plus utilise en France tant la mthode MERISE. MERISE est une mthode de conception, de dveloppement et de ralisation de projets informatiques. Le but de cette mthode est d'arriver concevoir un systme d'information. La mthode MERISE est base sur la sparation des donnes et des traitements effectuer en plusieurs modles conceptuels et physiques. La mthode MERISE date de 1978-1979, et fait suite une consultation nationale lance en 1977 par le ministre de l'Industrie dans le but de choisir des socits de conseil en informatique afin de dfinir une mthode de conception de systmes d'information. Les deux principales socits ayant mis au point cette mthode sont le CTI (Centre Technique d'Informatique) charg de grer le projet, et le CETE (Centre d'Etudes Techniques de l'Equipement) implant Aix-en-Provence.

II.

Cycle d'abstraction de conception des systmes d'information

La conception du systme d'information se fait par tapes, afin d'aboutir un systme d'information fonctionnel refltant une ralit physique. Il s'agit donc de valider une une chacune des tapes en prenant en compte les rsultats de la phase prcdente. D'autre part, les donnes tant spares des traitements, il faut vrifier la concordance entre donnes et traitements afin de vrifier que toutes les donnes ncessaires aux traitements sont prsentes et qu'il n'y a pas de donnes superflues. Cette succession d'tapes est appele cycle d 'abstraction pour la conception des systmes d'information :

Figure II .1 cycle d'abstraction pour la conception des systmes d'information

L'expression des besoins est une tape consistant dfinir ce que l'on attend du systme d'information automatis, il faut pour cela :

faire l'inventaire des lments ncessaires au systme d'information dlimiter le systme en s'informant auprs des futurs utilisateurs

Cela va permettre de crer le MCC (Modle conceptuel de la communication) qui dfinit les flux d'informations prendre en compte. L'tape suivante consiste mettre au point le MCD (Modle conceptuel des donnes) et le MCT (Modle conceptuel des traitements) dcrivant les rgles et les contraintes prendre en compte. Le modle organisationnel consiste dfinir le MOT (Modle organisationnel des traitements) dcrivant les contraintes dues l'environnement (organisationnel, spatial et temporel). Le modle logique reprsente un choix logiciel pour le systme d'information. Le modle physique reflte un choix matriel pour le systme d'information.

III.

Modle Conceptuel de la Communication(MCC)

III.1 Dfinition de l'organisation

La premire tape de ce modle est d'arriver isoler le systme en le dlimitant. Il s'agit donc de dfinir le systme et les lments externes avec lesquels il change des flux d'information. Ces lments extrieurs sont appels acteurs externes (ou partenaires).

Figure III .1 Organisation et acteur externes

La seconde tape consiste dcouper l'organisation en entits appeles acteurs internes (ou domaines). Lorsque les domaines d'une organisation sont trop importants, ils peuvent tre dcomposs eux-mmes en sous-domaines.

Figure III .2 Organisation et acteur internes

La dernire tape est l'analyse des flux d'information, c'est--dire la dfinition des processus.

III.2 Diagramme de contexte

Le diagramme de contexte a pour but de reprsenter les flux d'informations entre l'organisation et les acteurs externes selon une reprsentation standard dans laquelle chaque objet porte un nom :

l'organisation est reprsente par un rectangle les acteurs externes sont reprsents par des ellipses en pointills les flux d'information sont reprsents par des flches dont l'orientation dsigne le sens du flux d'information

Figure III .3 Diagramme de contexte

III.3 Diagramme conceptuel de flux

Ce diagramme (appel aussi modle conceptuel de la communication) permet de complter le diagramme de contexte en dcomposant l'organisation en une srie d'acteurs internes. Dans ce diagramme la reprsentation standard est la suivante :

Les acteurs internes sont reprsents par des ellipses les messages internes sont reprsents par des flches

Figure III .4 Organisation et acteur externes

IV.

Modle Conceptuel des Donne (MCD)

Le modle conceptuel des donnes (MCD) a pour but d'crire de faon formelle les donnes qui seront utilises par le systme d'information. Il s'agit donc d'une reprsentation des donnes, facilement comprhensible, permettant de dcrire le systme d'information l'aide d'entits.

IV.1 Entits et classe d'entit

Une entit est la reprsentation d'un lment matriel ou immatriel ayant un rle dans le systme que l'on dsire dcrire. On appelle classe d'entit un ensemble compos d'entits de mme type, c'est-dire dont la dfinition est la mme. Le classement des entits au sein d'une classe s'appelle classification (ou abstraction). Une entit est une instanciation de la classe. Chaque entit est compose de proprits, donnes lmentaires permettant de la dcrire. Prenons par exemple une Ford Fiesta, une Renault Laguna et une Peugeot 306. Il s'agit de 3 entits 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 possder les proprits couleur, anne et modle. Les classes d'entits sont reprsentes par un rectangle. Ce rectangle est spar en deux champs :

le champ du haut contient le libell. Ce libell est gnralement une abrviation pour une raison de simplification de l'criture. Il s'agit par contre de vrifier qu' chaque classe d'entit correspond un et un seul libell, et rciproquement le champ du bas contient la liste des proprits de la classe d'entit

Figure IIV .1 Entit et proprits

IV.2 Relations et classes de relation

Une relation (appele aussi parfois association) reprsente les liens smantiques qui peuvent exister entre plusieurs entits. Une classe de relation contient donc toutes les relations de mme type (qui relient donc des entits appartenant des mmes classes d'entit). Une classe de relation peut lier plus de deux classes d'entit. Voici les dnominations des classes de relation selon le nombre d'intervenants :

une classe de relation rcursive (ou rflexive) relie la mme 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 reprsentes par des hexagones (parfois des ellipses) dont l'intitul dcrit le type de relation qui relie les classes d'entit (gnralement un verbe). On dfinit pour chaque classe de relation un identificateur de la forme Ri permettant de dsigner de faon unique la classe de relation laquelle il est associ.

Figure VV .2 Relation entre entit

On peut ventuellement ajouter des proprits aux classes de relation.

IV.3 La cardinalit
Les cardinalits permettent de caractriser le lien qui existe entre une entit et la relation laquelle elle est relie. La cardinalit d'une relation est compose 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 (gnralement 0 ou 1) dcrit le nombre minimum de fois qu'une entit peut participer une relation la borne maximale (gnralement 1 ou n) dcrit le nombre maximum de fois qu'une entit peut participer une relation

Figure VIV .3 Cardinalit

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 forcment la relation.

IV.4 Les identifiants

Un identifiant est un ensemble de proprits (une ou plusieurs) permettant de dsigner une et une seule entit. La dfinition originale est la suivante : L'identifiant est une proprit particulire d'un objet telle qu'il n'existe pas deux occurrences de cet objet pour lesquelles cette proprit pourrait prendre une mme valeur. Les attributs d'une classe d'entit permettant de dsigner de faon unique chaque instance de cette entit sont appels identifiants absolus. Le modle conceptuel des donnes propose de faire prcder d'un # les identifiants (parfois de les souligner).

Figure VIIV .4 Les identifiants

Ainsi, chaque classe d'entit doit possder au moins un attribut identifiant, et l'ensemble de ses attributs identifiants doivent tre renseigns la cration de l'entit.

V.

Le Modle Conceptuel des Traitement (MCT)

Le modle conceptuel des traitements permet de traiter la dynamique du systme d'information, c'est--dire les oprations qui sont ralises en fonction d'vnements. Ce modle permet donc de reprsenter de faon schmatique l'activit d'un systme d'information sans faire rfrence des choix organisationnels ou des moyens d'excution, c'est--dire qu'il permet de dfinir simplement ce qui doit tre fait, mais il ne dit pas quand, comment ni o...

V.1 Le concept d'vnement

Un vnement reprsente un changement dans l'univers extrieur au systme d'information, ou dans le systme d'information lui-mme.

un vnement externe est un changement de l'univers extrieur un vnement interne est un changement interne au systme d'information

On reprsente un vnement par une ellipse en trait plein pour les vnements internes l'organisation, en trait pointill pour les vnements externes.

Figure V .1 Evnement

V.2 Dfinition d'un processus

Un processus est un sous-ensemble de l'activit de l'entreprise, cela signifie que l'activit de l'entreprise est constitue d'un ensemble de processus. Un processus est lui-mme compos de traitements regroups en ensembles appels oprations.

V.3 Opration
Une opration est un ensemble d'actions excutes par le systme suite un vnement, ou une conjonction d'vnements. Cet ensemble d'actions est ininterruptible, c'est--dire que les vnements ne sont pas pris en compte (ils ne sont pas forcements ignors pour autant) tant que l'opration n'a pas t accomplie.

V.4 La synchronisation
La synchronisation d'une opration dfinit une condition boolenne sur les vnements contributifs devant dclencher une opration. Il s'agit donc de conditions au niveau des vnements rgies par une condition logique ralise grce aux oprateurs :

OU ET NON

Construction du MCT
Le modle conceptuel des traitements permet de reprsenter schmatiquement la gestion des vnements :

Figure V .2 Le modle conceptuel des traitements

VI.

Le Modle Organisationnel du Traitement (MOT)

Le modle organisationnel des traitements s'attache dcrire les proprits des traitements non traites par le modle conceptuel des donnes, c'est--dire :

le temps les ressources le lieu

Le modle organisationnel des traitements consiste donc reprsenter le modle conceptuel des traitements dans un tableau dont les colonnes sont la dure, le lieu, les responsables et ressources ncessaires une action.

VI.1 Le tableau des procdures fonctionnelles

La premire tape du modle organisationnel des traitements consiste dcouper les oprations en procdures fonctionnelles, une succession de traitements dclenche par un vnement. Il s'agit donc d'associer dans un tableau :

les procdures fonctionnelles l'heure de dbut et de fin le lieu du poste de travail le responsable du poste de travail les ressources du poste de travail
temps poste de travail dure lieu responsable

Procdure

dbut

ressources

VII.

Le Modle Logique des Donnes (MLD)

Le modle logique des donnes consiste dcrire la structure de donnes utilise sans faire rfrence un langage de programmation. Il s'agit donc de prciser le type de donnes utilises lors des traitements. Ainsi, le modle logique est dpendant du type de base de donnes utilis.

VII.1 Le modle relationnel

Traduction d'une classe d'entit Chaque classe d'entit du modle conceptuel devient une table dans le modle logique. Les identifiants de la classe d'entit sont appel cls de la table, tandis que les attributs standards deviennent des attributs de la table, c'est--dire des colonnes.

Figure VII.1 Traduction d'une classe d'entit

Traduction d'une classe de relation Le passage du modle conceptuel au modle logique au niveau des classes de relation se fait selon les cardinalits des classes d'entit participant la relation :

si une des classes d'entits possde 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 prcd du nom de la classe si les deux classes d'entits possdent une cardinalit forte : la table aura comme attributs, les attributs des deux classes de relation prcds des noms des classes respectives, puis le (ou les) attribut(s) de relation

Figure VII.2 Traduction d'une classe d'entit

VIII.

Le modle physique

Cette tape consiste implmenter le modle dans le SGBD, c'est--dire le traduire dans un langage de dfinition de donnes. Le langage gnralement utilis pour ce type d'opration est le SQL, et plus spcialement le langage de dfinition de donnes du SQL.

IX.

Conception de la base de donnes scolarit:

Introduction :
La conception de la base de donnes scolarit a t faite en utilisant la dmarche suivant : Etape 1 : Modlisation conceptuelle (laboration du MCD) Etape 2 : Modlisation relationnel (laboration du MRD) Etape 3 : construction du schma logique (MLD) Etape 4: conception physique de la BDD(MPD)

Outil utilis :
Logiciel DIA (MCD MRD) MYSQL. (MPD)

Conception de la base de donnes :

Nous avons recens les diffrentes informations qui circulent dans un systme de gestion de scolarit. Nous lavons regroup dans les entits suivantes :

Etudiant Enseignant Anneeuni Dpartement Module

 Note Module
Les diffrentes entits, et leurs attributs sont rsums dans le tableau suivant : Entit attribut Dfinition
Anne universitaire dtude Code du dpartement Nom du dpartement Code du chef de dpartement (codens ) Code de lenseignant Nom de lenseignant Prnom de lenseignant CODE ETIDIANT sous forme xxx/dateentre/cycle Nom de ltudiant Prnom de ltudiant Date de naissance de ltudiant Date de ladmission de ltudiant luniversit Cycle de formation Lieunais Lieu de naissance de ltudiant Code du module Nom du module Cofficient du module Mthode par laquelle on calcul la moyenne de ce module Note durant la 1ere EMD Note2 Note durant la 2ere EMD Note3 Note durant la 3ere EMD Notetp Note du TP Notetd Note du TD Synthese Note de la synthse Rattrapage Note de lexamen de rattrapage

annuni ANNEEUNI DEPARTEMENT coddep nomdep codchefdep ENSEIGNANT codens nomens prenomens Codetud nometud prenometud datenais dateentree CYCLE lieunais codmod nommod coefficient methodecalc note1 note2 note3 notetd notetp synthese rattrapage

ETUDIANT

MODULE

Notemodule

REMARQUE : pour le MRD et MCD je dois limprimer directement du dia

MCD :
Le modle conceptuel de donnes qui traduits les entits ainsi que les diffrentes Relations entres elles :

MRD

MLD :
Dans cette partie on transform le MRD en un modle logique des donnes, on a obtenu les tables suivantes : Anneeuni Dep Enseignant Etudiant Module Notemode annuni Coddep nomdep codchefdep codmod Codens nomens prenomens coddep Codetud nometud prenometud, datenais dateentree CYCLE lieunais Codmod nommod coefficient methodecalc Annuni codmod codetud note1 note2 note3 notetd notetp synthese rattrapage

MPD:
Dans cette tape on a transform le MLD en un modle physique, pour cela on a utilis MYSQL qui est un trs bon SGBD, Quelque exemple des requtes sur la base de donnes scolarit Exemple 1 : Relation entre enseignant et dpartement

Exemple 2 : relation entre module et dpartement

Exemple 3 : relation entre tudiant et note module

X. Conclusion :
Lapparition des mthodes orientes objet et la complexit des systmes dinformation ont pouss vers lextension de Merise pour rallonger sa dure de vie . Merise se positionne comme une mthode de conception de SI organisationnel, plus tourne vers la comprhension et la formalisation des besoins du mtier que vers la ralisation de logiciel. En sens, Merise se rclame plus de l'ingnierie du SI mtier que du gnie logiciel. Jamais Merise ne s'est voulu une mthode de dveloppement de logiciel ni de programmation. UML, de par son origine (la programmation objet) s'affirme comme un ensemble de formalismes pour la conception de logiciel base de langage objet. De mon point de vue, sur la seule partie des formalismes, Merise est encore tout fait valable pour: - la modlisation des donnes en vue de la construction d'une base de donnes relationnelle, - la formalisation des besoins utilisateur dans le cadre de cahier des charge utilisateur, en vue de la conception d'un logiciel adapt. UML est idal pour : - concevoir et dployer une architecture logiciel dveloppe dans un langage objet (Java, C++, VB.net) A mon avis, Merise et UML sont techniquement complmentaires. Si l'on considre que le SI est modlisable comme deux sous-systmes inclus l'un dans l'autre: le SIO (systme d'information organisationnel) reprsentant le mtier, englobant le SII (systme d'information informatis) reprsentant l'application informatique associe. Merise est adapte au SIO, UML au SII. Maintenant, selon le positionnement de chacun (consultant, analyste mtier, concepteur de logiciel, dveloppeur), on s'appuiera plus ou moins sur chaque partie de mthode. Quand Merise Objet, c'tait une tentative d'apporter une rponse merisienne la partie SII, rvolutionne par la programmation objet et l'mergence des formalismes prcurseurs C'tait mon avis inutile; il aurait mieux valu mettre en valeur la complmentarit plutt que de vouloir couvrir l'ensemble du terrain. En conclusion, je suis pour Merise + UML,