2.1.3. Présentation du diagramme de classes
~ 86 ~
Le diagramme de classes permet en outre d'implémenter
la base de données. Certes, pour implémenter une base de
données, il faut faire recours à un Système de Gestion de
Base de Données.
A ce jour, la difficulté que rencontre la
modélisation objet est celle de conformer le diagramme de classes aux
normes du relationnel lors de l'implémentation de la base de
données.
En vue d'assurer la cohérence dans notre base de
données, il faudrait raffiner le diagramme de classes en faisant recours
formes normales de la normalisation favorisant ledit raffinement.
Ces formes normales ont pour objectifs de (d') :
? Définir des règles pour décomposer les
relations tout en préservant les DF et sans perdre d'informations, afin
de représenter des objets et associations canoniques du monde
réel (les molécules d'informations) ;
? Éviter les anomalies de mises à jour ;
? Éviter les réponses erronées.
Présentation des formes normales
1ère Forme Normale
Définition
Une relation est en 1ère forme normale si tout attribut
contient une valeur atomique (unique)
Exemple
|
PERSONNE
|
NOM
|
PROFESSION
|
|
DISONAMA KONKFIE
|
Ingénieur, Enseignant Enseignant
|
Une telle relation doit être décomposée en
répétant les noms pour chaque profession.
~ 87 ~
2ème Forme Normale
Définition
Une relation est en deuxième forme normale si et seulement
si :
1) Elle est en première forme normale et
2) Tout attribut non clé ne dépend pas d'une
partie de clé.
Exemple
Client {NumClient, Nom, Type}
Le « Type » n'est pas en deuxième forme
normale.
3ème Forme Normale
Définition
Une relation est en troisième forme normale si et
seulement si :
1) Elle est en deuxième forme normale et
2) Tout attribut n'appartenant pas à une clé ne
dépend pas d'un autre attribut non clé.
Exemple
Voiture (n° veh, marque, type, puissance, couleur) La
structure ci-dessus se décompose en :
1) Véhicule (n° veh, type, couleur)
2) Modèle (type, marque, puissance)
Figure III.1.6 : Diagramme de classes raffiné
~ 88 ~
2.1.4. Présentation du diagramme de classes
raffiné
~ 89 ~
2.2.Diagramme de Package
2.2.1. Définition
Package : mécanisme général de
regroupement d'éléments en UML, qui est principalement
utilisé en analyse et conception objet pour regrouper des classes et des
associations. Les packages sont des espaces de noms : deux
éléments ne peuvent pas porter le même nom au sein du
même package. Par contre, deux éléments appartenant
à des packages différents peuvent porter le même nom.
La structuration d'un modèle en packages est une
activité délicate. Elle doit s'appuyer sur deux principes
fondamentaux : cohérence et indépendance.
Le premier principe consiste à regrouper les classes
qui sont proches d'un point de vue sémantique. Un critère
intéressant consiste à évaluer les durées de vie
des instances de concept et à rechercher
l'homogénéité. Le deuxième principe s'efforce de
minimiser les relations entre packages, c'est-à-dire plus
concrètement les relations entre classes de packages
différents.
Un regroupement sera fait par processus. Deux processus
principaux font objet de notre étude que reprend même le diagramme
de classes à savoir celui de la location véhicule d'une part et
de la location appartement d'autre part. Il est important de rappeler que le
regroupement en package sera effectué sur base du diagramme de classes
et non selon le diagramme de classes raffiné.
En plus des processus précités, un autre
processus s'ajoute, celui de la gestion des biens (véhicule et
appartements).
~ 90 ~
Package : Location véhicule
Figure III.1.7 : Package Location véhicule du
diagramme de classes
Location véhicule
~ 91 ~
Package : Location Appartement
Figure III.1.8 : Package Location
Appartement du
diagramme de classes
Location Appartement
~ 92 ~
Package : Gestion location
Gestion Location
Figure III.1.9 : Package Gestion location du
diagramme
de classe
~ 93 ~
| 
