4 Représentation des diagrammes
d'activité
Dans cette étape nous allons présenter le
diagramme d'activité de chaque cas d'utilisation :
· Diagramme d'activité de prendre
RDV :
Figure 2. 9:Diagramme d'activité «
prendre RDV».
· Diagramme d'activité degérer
RDV :
Figure 2. 10: Diagramme d'activité «
gérer RDV».
· Diagramme d'activité de
s'inscrire :
Figure 2. 11: Diagramme d'activité «
s'inscrire».
· Diagramme d'activité d'annuler
journée :
Figure 2. 12:Diagramme d'activité «
annuler journée».
Ø Diagramme d'activité de valider compte
médecin :
Figure 2. 13Diagramme d'activité «
valider compte médecin».
· Diagramme d'activité de Valider nouvelle
spécialité pour médecin :
Figure 2. 14:Diagramme d'activité «
valider nouvelle spécialité pour
médecin».
N .B : Tous les DAC associées aux
autres cas sont présentés dans l'annexe.
5 Élaboration de diagramme de séquence
Après qu'on a vu le diagramme d'activité nous
allons voir maintenant le diagramme de séquence pour chaque cas
d'utilisation.
· Diagramme de séquencedeprendre
RDV :
Figure 2. 15: Diagramme de séquence «
Prendre RDV».
· Diagramme de séquencedegérer
RDV :
Figure 2. 16:Diagramme de séquence «
gérer RDV».
· Diagramme de
séquencedes'inscrire :
Figure 2. 17:Diagramme de séquence «
s'inscrire».
· Diagramme de séquenced'annuler
journée :
Figure 2. 18:Diagramme de séquence «
annuler journée».
· Diagramme de séquencedevalider comptes
médecin :
Figure 2. 19: valider comptes
médecin
· valider nouvelle spécialité pour
médecins :
Figure 2. 20Diagramme de séquence «
valider nouvelle spécialité pour
médecin».
N .B : Tous les DSE associées aux
autres cas sont présentés dans l'annexe.
6 Diagramme de classes
6.1 Identification
et description de classes
6.2
Élaboration de diagramme de classes
La figure suivante représente le diagramme de
classes :
Figure 2. 21: diagramme de classes
6.3 Règles
de passage de l'orienté objets au relationnel [10]
Le passage depuis le modèle objets DCL vers le
modèle relationnel est fait dans l'objectifd'implémenter la BD
sur un SGBD relationnel. Ces derniers étant jusqu'à ce jours les
plus utilisés pour implémenter les BD vu que les SGBDOO n'ont pas
encore occupé complètement le marchédu logiciel.
Pour
passer d'une représentation OO en DCL vers le modèle relationnel,
on procède comme suit :
Toute classe donnera une table avec identifiant
à clé et attributs
Dans une association 1 --- * :
· Chaque classe devient une table, les attributs de la
classe deviennent des attributs de la table et l'identifiant de classe devient
la clé de la table.
· L'association est remplacé par une
référence qui place l'identifiant de la classe à
l'extrémitédu 1 dans la table de la classe à
l'extrémité du plusieurs * (ce sera une clé
étrangère).
Dans une association * --- * :
· Chaque classe devient une table, les attributs de la
classe deviennent des attributs de la table et l'identifiant de classe devient
la clé de la table.
· L'association (qui peut être une classe
association) est remplacée par une table qui a comme clé la
concaténation des identifiants des classes participantes. Dans le cas de
classeassociation, les attributs sont rajoutés dans la nouvelle
table.
Dans une association 1--1 :
Il y a différentes façons de
d'implémenter selon les perspectives d'utilisation du concepteur :
Ø Règle1 :
Fusionner les deux classes dans une seule table, en gardant
bien-sûr la table la plus importante sémantiquement.
Ø Règle 2 :
Garder les deux classes et les implémenter en deux
tables. Sélectionner par la suite une table pour
référencer l'autre par une clé étrangère. Ce
qui revient à garder le sens de l'association qui est le plus important
dans la conception (navigabilité).
Ø L'héritage
L'implémentation de l'héritage demande un peu
plus de considération pour choisir l'une des 03 règles de
passage.
Ø Règle1:
Conceptuellement parlant la classe mère est plus
importante que les classesfilles qui ne portent pas beaucoup de
spécificité informationnelle. Dans ce cas il faut garder la
classe mère et l'implémenter par une table. Les classes filles,
elles sont dégénérées et remplacées dans la
table (classe mère) par un attribut.
Ø Règle 2 :
Conceptuellement parlant, Les classes filles sont plus
importantes que la classe générique et sont porteuses
d'information. La classe mère est dégénérée
au profit des classes filles. Tous les attributs et opérations de la
classe mère sont reportés au niveau des classes filles.
Ø Règle 3 :
Les classes mère et filles sont tout aussi importante
et doivent être gardé, l'héritage est alorsremplacé
par une association 1 --1..* qui sera ensuite implémentée. Il
faut assurer une identificationpour chaque classe
Le passage du modèle conceptuel de classe de l'O.O
représenté par le DCL d'UML vers le modèle logique
relationnel représenté à par une structure de tables,
n'est pas du tout un passage direct. C'est une remonétisation qui
nécessite de faire des choix dictés par la sémantique et
la perspective d'utilisation des informations. Ce choix est celui du concepteur
de l'application
Remarque
Il est conseillé de signaler sur un DCL une classe qui
ne doit pas être implémentée par le
stéréotype <<Abstract>>
| 
