Conclusion :
A travers ce chapitre, j'ai présenté
l'architecture de la solution et dressé les différents outils et
technologies avec lesquelles j'ai travaillé.
Le chapitre suivant est consacrée à la
modélisation et la conception de la solution
développée.
CHAPITRE IV : MODELISATION
ET CONCEPTION
|
Mémoire de fin d'études |
|
48
|
Mémoire de fin d'études |
49
Introduction :
Ce chapitre est le socle du travail réalisé vu
qu'il englobe la modélisation et la
conception de la solution. Cette partie du rapport va
présenter tous les diagrammes établis pour me permettre de
développer une solution répondant aux besoins soulevés.
I. Modélisation :
La modélisation conceptuelle de la base de
données et de la solution demande le choix de la méthode et du
langage de conception les plus adaptés. Pour cette raison, j'ai fait le
choix d'exploiter la méthode de conception Merise et le langage de
modélisation UML. J'ai utilisé la première pour la
modélisation de la base de données (MCD et MPD), alors que le
deuxième m'a servi pour la description de la solution (Diagramme de cas
d'utilisation).
Les méthodes Merise et UML sont deux méthodes
bien différentes, mais qui sont
complémentaires. Merise est une méthode de
conception, alors que l'UML est un langage de modélisation, ce qui fait
la différence entre les deux.
L'UML représente un langage graphique qui permet la
modélisation de la base de données et par suite
l'amélioration de la qualité de l'implémentation du
système d'information. Il est constitué d'un nombre
intéressant de diagrammes, à savoir : le diagramme des classes,
diagramme de cas d'utilisation, diagramme de séquence, diagramme de
déploiement,... etc.
De sa part, Merise est une méthode de conception
éprouvée, qui présente un ensemble
de modèles simples à concevoir, comprendre et
modéliser. Il donne une vue globale de la solution sans entrer dans les
détails.
Le choix d'une méthode et d'un langage pour la
conception et aussi la modélisation du système d'information, est
dû au fait que l'un ou l'autre présente des avantages et des
inconvénients. Merise est une méthode plus
généraliste, et difficile à implémenter puisqu'elle
donne une représentation loin des langages de programmation, son
utilité reste liée à la base de données. En
revanche, les diagrammes d'UML s'adaptent aux langages de programmation,
puisqu'il représente un langage de programmation orientée
objet.
Afin de rassembler la clarté et la précision, il
m'a paru nécessaire d'utiliser Merise et
UML avec leurs différents modèles et diagrammes,
pour la conception de la base de données et la modélisation de
solution.
1. Diagramme des cas d'utilisation :
Les cas d'utilisations permettent de modéliser et
structurer les besoins des utilisateurs
et les objectifs correspondants d'un système. Ils
précisent le but à atteindre et permettent d'identifier les
fonctionnalités principales du système.
D'après ce qui était convenu dans le cahier des
charges, l'application devrait répondre aux besoins de quatre
utilisateurs différents à savoir :
? Cas de l'Utilisateur .
·
Dans ce deuxième diagramme, l'utilisateur aura, en
plus, d'afficher l'état actuel des immeubles foncier, la
possibilité d'insérer un nouvel immeuble foncier et d'actualiser
la procédure foncière d'un certain immeuble et aussi d'exporter
les données souhaitées.
|
Figure 7 : Diagramme de cas d'utilisation : Utilisateur
|
|
|
|
|
Mémoire de fin d'études |
|
50
|
Mémoire de fin d'études |
51
II. Conception :
1. Règles de gestion des données
:
SERVICE REGULARISTAION FONCIERE :
- RG1 : La parcelle peut ne pas appartenir
à un dossier de délimitation
- RG2 : Les dossiers de délimitation
peuvent contenir un seule client.
- RG3 : Chaque parcelle dépend d'une
seule et unique client.
- RG4 : Lae client peuvent appartient à
une seule ou plusieurs parcelle.
- RRG6 : Pour chaque parcelle on effectue un
repérage de bornage et un dossier.
- RG7 : Dossier peut englober plusieurs
parcelles.
- RG8 : Le dossier de délimitation est
déterminé par son code délimitation.
Service commerciale :
- RG9 : un quartier peut appartenir à une
seule ville.
- RG10 : un quartier peut appartenir à
une ou plusieurs bâtiments. - RG11 : un bâtiment
peut avoir une ou plusieurs étages.
2. Modèle Conceptuel de Données
:
A travers le temps il a été reconnu que pour
tout problème existait une solution sauf qu'il y a plusieurs
manières d'y arriver et la différence réside dans
l'efficience de chacune. Alors il faudrait étudier la quelle d'entre
elles est la conception la plus optimale et répondant aux exigences avec
le moins de complexité.
J'étais libre de concevoir mon système comme je
le voulais car aucune autre exigence n'était soulevé à
part ce que les règles de gestion exigées et en tenant compte que
ma base de données doit être liée avec la base de
données standard de l'application déjà existante.
Mémoire de fin d'études |
52
Au cours de la conception j'étais affronté
à choisir entre une modélisation dont la philosophie est
axée surtout autour de la couche. C'est-à-dire qu'elle est
transportable et adaptable à d'autres thématiques
indépendamment du métier. Tout en étant moins complexe, il
suffira juste d'ajouter les tables du Parcelle voulu.
Dans une modélisation par couche, nous avons tendance
à créer pour chaque couche thématique une table propre
à elle. Ce qui nous donne au final une base de données complexe
et redondante. Contrairement à la modélisation
synthétique, où j'ai opté de placer toutes les couches
dans une seule table sachant que la différence entre ces enregistrements
se fait par un statut indiquant à quelle thématique appartient ce
dernier (Fig.8).
Figure 8: Modèle Conceptuel de Données (MCD)
Service cession amiable.
En plus de ces tables spatiales, PostGIS fournit deux tables
supplémentaires pour récupérer et s'informer sur les types
de géométries disponibles dans la base de données.
y' La première table, spatial_ref_sys, définit tous
les systèmes de projection connus de la base de données et sera
décrite plus en détails plus tard.
y' La seconde table, geometry_columns, fournit une liste de
toutes les «entités» (définit comme un objet avec un
attribut géométrique) et les détails de base relative
à ces entités.
Figure 9: Table Relationship
|
Mémoire de fin d'études |
|
53
|
Mémoire de fin d'études |
54
Figure 10 : Modèle Conceptuel de Données (MCD)
service commerciale.
3. Modèle Physique de Données
:
Après matérialisation des dépendances
entre les entités dans le MCD ci-dessus. J'ai pu dégager ce
Modèle Physique de Données qui constitue une
représentation fidèle de la base de données à
implémenter au niveau du SGBD. Il représente une traduction du
MCD, de telle façon à traduire les entités et les
relations en table, en respectant les contraintes définies par la
modélisation utilisée MERISE.
Figure 11 : Modèle Physique de Données (MPD)
| 
