CHAPITRE 4 : MODELISATION ET CONCEPTION DU SYSTEME
D'INFORMATION
La conception de tout SI n'est pas une évidence car
elle nécessite une réflexion active sur l'organisation à
mettre en place. La phase conceptuelle requiert des méthodes pertinentes
qui permettront de créer un modèle de référence. La
modélisation consiste à concevoir une représentation
virtuelle d'une réalité de telle façon à faire
ressortir les points auxquels on s'intéresse (Avison, 1991).
Pour la conception et la modélisation de notre SI, nous utiliserons la
Méthode MERISE.
4.1 ANALYSE DE L'EXISTANT
Après s'être imprégné du cahier des
charges, nous retenons qu'il s'agira de mettre en place un gestionnaire
électronique de la documentation pour six (6) structures de l'USTM.
Parmi ces structures, on distingue :
les administrations : le Rectorat et
le Secrétariat général ;
les établissements pédagogiques
: l'Ecole Polytechnique de Masuku, l'Institut National
Supérieur d'Agronomie et de Biotechnologies, la Faculté des
Sciences, l'Ecole Doctorale des Sciences Fondamentales Appliquées.
Ces structures sont organisées hiérarchiquement,
alors il est évident qu'elles disposent de personnes
qui la dirigent.
Les dirigeants peuvent
gérer un département
et/ou enseigner dans un
département. Le département gère les classes
qu'il contient.
Pour ranger la documentation dans ces différentes
structures, nous allons rester conforme à une ossature simple, logique
et réelle d'un système d'archivage manuel classique qui permettra
à tout le monde de s'acclimater facilement à son utilisation.
Dans cette ossature, les informations seront rangées selon une
architecture suivant la logique ci-après :
Rubrique -> Dossiers -> Documents. Le
schéma ci-dessous illustre son fonctionnement.
Rubrique
Une Rubrique a plusieurs
Dossiers dans lesquels sont inclus des Documents
Dossier
Dossier
Document
Document
Document
Document
Figure 23 : Fonctionnement de la banque
documentaire
Page 27 sur 57
Page 28 sur 57
Une personne peut ajouter ou accéder
à une rubrique. Les dossiers détiennent
un statut spécifique et les documents
possèdent un type
particulier. De plus, l'accessibilité aux rubriques et
à leurs fonctionnalités dépendra du rend
hiérarchique.
Les rubriques et leurs contenus pourront être
partagés d'une structure à une autre ou
à toutes les structures. Leur visibilité (masqué
ou visible) persistera malgré le partage et seuls les
utilisateurs de rang hiérarchique autorisé pourront changer leur
visibilité.
Il est courant que dans des applications où les
utilisateurs partagent un flux d'informations il y ait un mini forum pour
permettre aux utilisateurs de communiquer. Il nous a été utile
d'adopter ce schéma en ajoutant une fonctionnalité qui permettra
à toute personne de voir ou poster
des messages de diffusion.
4.2 DICTIONNAIRE DES DONNEES
De l'analyse précédente, il en ressort des mots
clés, mis en gras et en italique, qui constituent notre dictionnaire de
données. Ce dictionnaire est constitué de noms communs et de
verbes. Nous avons successivement :
Administrations, Etablissements, Personnes,
Dirigent, Dirigeant, Gérer, Départements, Enseigner, Classe,
Contient, Rubrique, Dossiers, Documents, Accéder, Possèdent,
Statut, Type, Partagés, Voir, Poster, Messages.
Ces informations nous permettent de ressortir les
éléments les plus pertinents pour définir un cadre
organisationnel pour nos données.
4.3 IDENTIFICATION DES ENTITES ET DE LEURS
PROPRIETES
Pour identifier les entités en présence dans
notre SI, il suffira de recenser tous les noms communs de notre dictionnaire de
données et de les mettre au pluriel. Il en résulte douze (12)
entités suivantes imbriquées de leurs propriétés
respectives :
1. Administrations :
a. id_admin : identifiant de l'administration,
b. nom_admin : nom de l'administration,
c. sub_admin : dimunitif du nom de l'administration (utile
pour le backend).
2. Etablissements :
a. id_etab : identifiant de l'établissement ;
b. nom_etab : nom de l'établissement ;
c. sub_admin : dimunitif du nom de l'établissement (
utile pour le backend).
3. Personnes :
a. id_personne : identifiant de la personne ;
b. nom_personne : nom de la personne ;
c. prenom_personne : prénom de la personne ;
d. tel_personne : numéro de téléphone
de la personne ;
e. pseudo_personne : définit par le backend et
indispensable lors de l'authentification) ;
Page 29 sur 57
f. password_personne : mot de passe de la personne
(définit par l'utilisateur ayant droit pour permettre à la
personne qu'il ajoute au système de s'authentifier).
4. Dirigeants :
a. id_dirig : identifiant du dirigeant ;
b. fonction_dirig : fonction du dirigeant ;
c. droit_dirg : droit d'accès du dirigeant ;
d. grade_dirig : grade du dirigeant.
5. Départements :
a. id_dep : identifiant du département ;
b. nom_dep : nom du département.
6. Classes :
a. id_classe : l'identifiant de la classe ;
b. nom_classe : nom de la classe.
7. Rubriques :
a. id_rubrique : identifiant de la rubrique ;
b. nom_rubrique : nom de la rubrique ;
c. visible_rubrique : visibilité de la rubrique
;
d. partage_rubrique : propriété permettant de
définir le partage ou non d'une rubrique à toutes les
structures.
8. Dossiers :
a. id_dossier : identifiant du dossier ;
b. nom_dossier : nom du dossier ;
c. description_dossier : description du dossier ;
d. date_dossier : date de création de dossier
;
e. date_statut : date de changement de statut ;
f. visible_dossier : visibilité du dossier ;
g. partage_dossier : partage du dossier.
9. Documents :
a. id_document : identifiant du document ;
b. nom_document : nom du document ;
c. description_document : description du document ;
d. taille_document : taille du document ;
e. extension_document : extension du document ;
f. chemin_document : chemin du document ;
g. partage_document : partage du document ;
h. visible_document : visibilité du document
;
i. date_document : date de création du
document.
10. Statuts :
a. id_statut : identifiant du statut du dossier ;
b. nom_statut : nom du statut du dossier.
Page 30 sur 57
11. Types :
a. id_type : identiant du type de document ;
b. nom_type : nom du type de document.
12. Messages :
a. id_message : identifiant du message de diffusion
;
b. contenu_message : contenu du message de diffusion
;
c. date_message : date de création du
message.
Nous pouvons constater que chaque attribut des entités
suit la nomenclature Camel Case
(constituée du nom de l'attribut et du nom de
l'entité). Nous utilisons cette norme pour faciliter la manipulation des
données lors des requêtes en base de données.
4.4 RECENSEMENT DES ASSOCIATIONS ENTRE
ENTITES
Les entités ayant été recensées,
pour faire de même pour les associations logiques qui les lient, il nous
suffira de mettre à l'infinitif tous les verbes de notre dictionnaire de
données. Il en résulte les associations ci-dessous avec leurs
définitions respectives :
1. diriger : association tertiaire entre
les entités « Dirigeants », « Administrations » et
« Etablissements » ;
2. gérer : association
binaire entre les entités « Dirigeants » et «
Départements » ;
3. enseigner : association binaire entre
les entités « Dirigeants » et « Classes » ;
4. contenir : association binaire entre
les entités « Départements » et « Classes »
;
5. accéder : association binaire
entre les entités « Personnes » et « Rubriques »
;
6. posséder : association binaire
entre les entités « Types » et « Documents »
;
7. partager : association tertiaire
entre les entités « Rubriques », « Administrations »
et « Etablissements » ;
8. poster : association binaire entre
les entités « Personnes » et « Messages » ;
9. voir : association binaire entre les
entités « Personnes » et « Messages ».
Etant donné qu'un département appartient
à un établissement, en plus des neuf (9) associations
recensées, nous pouvons ajouter une dixième que nous appellerons
:
10. appartenir : association binaire
entre les entités « Départements » et
«
Etablissements ».
4.4.1 RECENSEMENT DES CARDINALITES
Pour construire notre modèle conceptuel il ne nous
reste plus qu'à définir les cardinalités entre les
associations des différentes entités de notre SI. Nous avons
successivement :
1. Diriger :
a. cardinalité à gauche (1,n)
: un « Dirigeant» dirige une ou plusieurs «
Administrations », un ou plusieurs « Etablissements » ;
b. cardinalité à droite (1,1)
: une « Administration » ou une « Etablissement »
ne peut être dirigé que par un et un seul «
Dirigeant ».
2. Gérer :
a.
Page 31 sur 57
cardinalité à gauche (1,n)
: un « Département» peut être géré
par un ou plusieurs « Dirigeants» ;
b. cardinalité à droite (1,1)
: un « Dirigeant » gère un et un
seul Dirigeant .
3. Enseigner :
a. Cardinalité à gauche
(1,n) : un « Dirigeant» enseigne
une ou plusieurs « Classes» ;
b. Cardinalité à droite (1,1)
: une « Classe » ne peut être enseignée
que par un et un seul « Dirigeant ».
4. Contenir :
a. Cardinalité à gauche
(1,n) : un « Département» contient
une ou plusieurs « Classes» ;
b. Cardinalité à droite (1,1)
: une « Classe » ne peut être contenu
que dans un et un seul « Département ».
5. Accéder :
a. Cardinalité à gauche
(1,n) : une « Personne» accède
une ou plusieurs « Rubriques» ;
b. Cardinalité à droite (1,n)
: une « Rubrique » peut être accessible
pour une ou plusieurs « Personnes ».
6. Posséder :
a. cardinalité à gauche
(1,n) : un « Type » est
possédé par un ou plusieurs « Documents »
;
b. cardinalité à droite (1,1)
: un « Document » possède un et un
seul « Type ».
7. Partager :
a. cardinalité à gauche
(1,n) : un « Rubrique» est partagé
par une ou plusieurs « Administrations », un ou plusieurs
« Etablissements » ;
b. cardinalités à droite (1,n)
: une « Administration » ou une « Etablissement »
peut partager un ou plusieurs « Rubrique ».
8. Poster :
a. cardinalité à gauche
(1,n) : une « Personne» poste un ou
plusieurs « Messages» ;
b. cardinalité à droite (1,1)
: un « Message » peut être posté
par une et une seul « Personne ».
9. Voir :
a. cardinalité à gauche (1,n)
: une « Personne» voit un ou plusieurs «
Messages» ;
b. cardinalité à droite (1,n)
: un « Message » peut être vu par une
ou plusieurs « Personnes ».
10. Appartenir :
a. cardinalité à gauche
(1,1) : un « Département » appartient
à un et un seul « Etablissement » ;
b. cardinalité à droite (1,1)
: un « Etablissement » peut être appartenue
par un ou plusieurs « Départements ».
4.4.2 SCHEMA DU MODELE CONCEPTUEL DE DONNEES
(MCD)
Page 32 sur 57
Figure 24 : Modèle Conceptuel de Données du
GED
| 
