© Éditions Eyrolles
85
chapitre n° 1
Le niveau conceptuel : face à face Merise/UML
UML définit trois niveaux de visibilité pour les attributs et les méthodes (ces niveaux correspondent
à ce que propose le langage C++) :
• public (symbole +) : niveau le moins strict, qui rend l’élément visible à toutes les autres classes ;
• protégé (symbole #) : niveau intermédiaire, qui rend l’élément visible aux sous-classes de la
classe fournisseur (aux « classes amies », friend classes en C++) ;
• privé (symbole -) : niveau le plus strict, qui rend l’élément visible à la classe fournisseur
seule (aux classes amies en C++).
L’exemple 1-91 précise la visibilité des attributs et méthode des deux services.
Au niveau de la base de données
L’encapsulation et la visibilité devront être programmées manuellement et explicitement au
niveau de la base. C’est là où se trouve le plus grand fossé entre classes d’objets et enregistrements
de la base. Alors que l’encapsulation et la visibilité sont assurées intrinsèquement par les
langages objet (C++ et Java par exemple), ces concepts ne sont pas natifs aux bases de données.
Pour l’heure, les outils de conception ne répercutent pas automatiquement ces notions dans les
scripts SQL. Et tant que les bases de données cibles seront relationnelles, il est probable que la
situation restera en l’état et qu’il faudra se retrousser les manches…
L’encapsulation doit être programmée au niveau de la base par l’ajout de méthodes ou des
procédures cataloguées. Il faudra donc prévoir suffisamment de méthodes d’insertion, de
modification et de suppression d’objets de la base, ainsi que les services à assurer. Puis il
faudra interdire l’accès à la base en révoquant les INSERT, UPDATE et DELETE tout en
donnant les droits d’exécution sur les méthodes aux utilisateurs concernés (sous Oracle
GRANT EXECUTE ON nom_type TO utilisateur). Oracle permet en outre d’affiner les prérogatives
d’une méthode [SOU 04].
Attributs dérivés
Un attribut dérivé, au sens UML, est une propriété valuée intéressante pour l’analyste mais
redondante, car sa valeur peut être déduite d’autres données présentes dans le modèle. Au sens
Figure 1-91 Niveaux de visibilité
avec UML
Departement
#codedept
+nomdept
-
budget
#augmente_budget(p)
-creation(c,n,b)
85
chapitre n° 1
Le niveau conceptuel : face à face Merise/UML
UML définit trois niveaux de visibilité pour les attributs et les méthodes (ces niveaux correspondent
à ce que propose le langage C++) :
• public (symbole +) : niveau le moins strict, qui rend l’élément visible à toutes les autres classes ;
• protégé (symbole #) : niveau intermédiaire, qui rend l’élément visible aux sous-classes de la
classe fournisseur (aux « classes amies », friend classes en C++) ;
• privé (symbole -) : niveau le plus strict, qui rend l’élément visible à la classe fournisseur
seule (aux classes amies en C++).
L’exemple 1-91 précise la visibilité des attributs et méthode des deux services.
Au niveau de la base de données
L’encapsulation et la visibilité devront être programmées manuellement et explicitement au
niveau de la base. C’est là où se trouve le plus grand fossé entre classes d’objets et enregistrements
de la base. Alors que l’encapsulation et la visibilité sont assurées intrinsèquement par les
langages objet (C++ et Java par exemple), ces concepts ne sont pas natifs aux bases de données.
Pour l’heure, les outils de conception ne répercutent pas automatiquement ces notions dans les
scripts SQL. Et tant que les bases de données cibles seront relationnelles, il est probable que la
situation restera en l’état et qu’il faudra se retrousser les manches…
L’encapsulation doit être programmée au niveau de la base par l’ajout de méthodes ou des
procédures cataloguées. Il faudra donc prévoir suffisamment de méthodes d’insertion, de
modification et de suppression d’objets de la base, ainsi que les services à assurer. Puis il
faudra interdire l’accès à la base en révoquant les INSERT, UPDATE et DELETE tout en
donnant les droits d’exécution sur les méthodes aux utilisateurs concernés (sous Oracle
GRANT EXECUTE ON nom_type TO utilisateur). Oracle permet en outre d’affiner les prérogatives
d’une méthode [SOU 04].
Attributs dérivés
Un attribut dérivé, au sens UML, est une propriété valuée intéressante pour l’analyste mais
redondante, car sa valeur peut être déduite d’autres données présentes dans le modèle. Au sens
Figure 1-91 Niveaux de visibilité
avec UML
Departement
#codedept
+nomdept
-
budget
#augmente_budget(p)
-creation(c,n,b)