Rapport de fin de phase I - Haute école du paysage, d'ingénierie et ...

Cadre du projet
ISNet35 Rapport phase I
Ce projet à été déposé dans le centre de compétence Informatique de gestion et
systèmes (ISNet) dans le cadre du programme de la réserve stratégique de la HES-SO en
septembre 2001. Il est sous la responsabilité du Laboratoire de Technologie Objet de la
Haute Ecole de Gestion de Genève.
1.1. Rappel des objectifs du projet
Les objectifs du projet sont initialement définis ainsi :
A partir des classes Java obtenues à l'issue d'un processus d'Analyse et de Conception
• Concevoir un processus générique automatique d'implantation de la persistance
d'objets Java dans une base de données relationnelle-objet, offrant en particulier les
possibilités
de gérer cette persistance de façon transparente pour le programme d'application
Java,
de permettre l'accès aux données représentées par les objets Java par des
applications quelconques en préservant l'intégrité des données.
• Elaborer une démarche méthodologique permettant de comparer le résultat de ce
processus aux technologies existantes.
• Réaliser et valider un prototype implantant effectivement ce processus générique.
• Rédiger une publication qui sera soumise à une revue spécialisée.
1.2. Document
Le présent document est le rapport de synthèse du travail du groupe de compétence
ISNet-Ne de la Haute école Neuchâteloise en fin de phase I du projet, son contenu devra
s’intégrer dans le cadre global du projet.
L’activité de l’équipe neuchâteloise s’est principalement orientée sur la problématique de
la persistance des objets et du langage de définition des contraintes.
1.3. Objectifs de la phase I
La phase I, intitulée Conception du processus automatique et élaboration de la démarche
méthodologique est définie par les objectifs suivant :
• Etudier les entités et concepts susceptibles d'être mémorisés dans la base de données
relationnelle-objet (classes, héritage, attributs, relations entre classes, …) ;
• Définir une représentation adéquate de ces entités et concepts dans la base de
données relationnelle-objet ; deux représentations seront envisagées :
relationnelle-objet pure,
vue relationnelle-objet
• Concevoir une définition des contraintes d'intégrité auxquelles ces représentations
devront être soumises de telle sorte qu'elles n'invalident ni la représentation objet, ni
la représentation relationnelle-objet des informations gérées ;
• Elaborer une démarche méthodologique permettant de comparer les diverses
technologies réalisant la persistance (relationnelle pure, relationnelle-objet, vue
relationnelle-objet) ;
• Produire un document de synthèse comprenant :
22.06.2005 1/78

une description de la démarche méthodologique d'évaluation,
un cahier des charges du prototype qui sera réalisé dans la seconde phase du
projet.
Problématique
1.4. Gestion de la persistance
En informatique de gestion, les informations qui concernent le métier d’une entreprise sont
toujours persistantes. Il est en effet inimaginable que le comptable d’une entreprise ressaisisse
dans son logiciel de comptabilité tous les matins les écritures de l’exercice courrant avant de
pouvoir imprimer le bilan de la période.
De façon générale, un programme d’informatique de gestion fonctionne selon le principe
suivant :
Phase A
1. L’utilisateur saisit des informations dans un formulaire afin de créer un nouvel
enregistrement
2. Le logiciel mémorise l’enregistrement dans sa base de données
Phase B
1. L’utilisateur remplit un formulaire de filtre
2. Le logiciel recherche dans sa base de données l’ensemble des enregistrements
correspondant et les présente de façon résumée à l’utilisateur sous la forme d’une
liste
3. L’utilisateur sélectionne l’enregistrement qui l’intéresse
4. Le logiciel recherche dans sa base de données les données exhaustives de
l’enregistrement en question et le présente à l’utilisateur
5. L’utilisateur peut alors consulter, modifier ou supprimer l’enregistrement
6. En cas de modification ou de suppression, le logiciel met à jour sa base de données
La phase B peut se dérouler plusieurs jours après que la phase A se soit terminée.
Bien que les fichiers permettent de mémoriser de l’information avec un ordinateur depuis de
longues années, ils ne suffisent pas en informatique de gestion. En effet, les données sont
susceptibles d’être accédées simultanément par plusieurs utilisateurs et le mécanisme de
verrouillage des fichiers offert par les systèmes d’exploitation n’est pas assez fin puisqu’un
fichier ne peut être manipulé que par un utilisateur à la fois. C’est pourquoi il existe des
logiciels spécialisés pour assurer la persistance d’informations, les systèmes de gestion de
base de données (SGBD).
Un SGBD utilise bien des fichiers pour le stockage des informations, mais celles-ci sont
présentées aux applications clientes sous une forme complètement différente et indépendante.
Les données gérées par un SGBD sont accessibles au moyen d’un langage de haut niveau non
procédural, le langage SQL. Ce dernier permet d’insérer, de modifier, de supprimer et de
22.06.2005 2/78

sélectionner des informations mémorisées par un SGBD dans un environnement logiciel
client-serveur.
1.5. Applications clientes
Depuis l’arrivée à maturité de l’approche objet dans le courrant des années 90, la majorité des
applications qui accèdent aux SGBD sont désormais réalisées avec un langage de
programmation orienté objet.
Initialement, le modèle objet à la base de ces langages, devait être la solution à la fameuse
crise du logiciel des années 1970 et par conséquent permettre aux programmeurs d’écrire des
logiciels de qualité. Cependant au fil du temps, il a été utilisé par les divers acteurs du monde
informatique à d’autres fins et notamment par les constructeurs de SGBD pour assurer la
persistance d’informations.
Les langages de programmation objet sont actuellement très prisés car ils permettent d’écrire
du code satisfaisant très bien aux critères du génie logiciel, notamment la réutilisabilité et
l’évolutivité. De plus, la création d’interfaces graphiques (GUI) est grandement simplifiée
avec ces langages. En effet, l’encapsulation des données et des traitements et l’héritage
permettent le développement de librairies graphiques dont les objets (fenêtres, boutons,
ascenseurs, …) sont facilement appréhendables et utilisables par les développeurs.
1.6. Anomalie d’impédance
Il faut bien comprendre qu’un langage de programmation objet et qu’un SGBD n’ont pas les
mêmes finalités et que leurs modèles de données ne sont par conséquent pas identiques. Le
premier doit permettre la production de code réutilisable et évolutif alors que le second doit
garantir la cohérence d’informations persistantes.
Malheureusement les langages de programmation orientés objet ne prennent pas en compte,
de façon native, la persistance des objets métier dans les SGBD. En effet, comme les
principes de modélisation ne sont pas identiques entre le modèle objet et le modèle du SGBD,
la mise en correspondance des deux n’est pas vraiment simple à réaliser et pose problème. Le
terme d’ « anomalie d’impédance » est fréquent utilisé dans la littérature pour exprimer cette
inadéquation.
Pour travailler avec un SGBD depuis un langage objet, il faut donc se résoudre à recourir à
des librairies spécialisées qui permettent d’embarquer des instructions SQL (JDBC, SQLJ, …)
dans les objets ou à utiliser des logiciels de mise en correspondance (Castor, JDO, …).
1.7. Mapping objet – relationnel
Dans le cadre de ce projet, nous avons dû choisir une solution pour la mise en correspondance
du modèle objet et du modèle relationnel. Comme l’objectif du projet est de concevoir un
générateur permettant d’assurer la persistance et l’intégrité des objets métier, nous avons
22.06.2005 3/78

etenu une solution de mapping qui n’offre aucune possibilité de personnalisation de la mise
en correspondance.
Notre solution consiste donc à dire que pour chaque classe Java il existe un type Oracle
correspondant dans la base de données. Une table objet est construite à partir du type Oracle
pour assurer la persistance et l’intégrité des instances.
La classe Java possède exactement les mêmes attributs que le type Oracle. La seule chose qui
change entre les deux c’est le langage de spécification.
public class Client {
}
private int numero;
private String nom;
private Adresse adresse;
private ListeTelephones telephones;
22.06.2005 4/78
CREATE TYPE client AS OBJECT (
)
numero NUMBER,
nom VARCHAR2(255),
adresse ADRESSE
telephones LISTTELEPHONES
Notre solution nous amène donc à produire des règles de traduction pour les types de bases
(dans l’exemple int -> NUMBER, String -> VARCHAR2(255)) par contre les attributs
composé (adresse) et les collections (telephones) sont mise en correspondance de façon
directe puisque les deux langages supportent ces types d’attribut.
Ce type de mapping nous permettra d’utiliser un outil comme JPublisher d’Oracle qui offre
déjà l’automatisation de la transformation de types Oracle en classes Java. Nous pourrons
ainsi nous concentrer sur la génération des règles d’intégrité qui est la partie la plus
intéressante de ce projet et celle qui amène le plus de valeur ajoutée en terme de Ra&D.
1.8. Sources de définition
A l’origine du projet, il était question de générer du code SQL-DDL à partir des méta-données
des classes Java issues des phases d’analyse et de conception d’un projet informatique.
Malheureusement, la sémantique de Java n’est pas assez riche pour exprimer toute la
sémantique d’un modèle notamment en ce qui concerne les associations entre classes et les
invariants de classes (contraintes).
En effet, il n’est pas possible en Java de spécifier si une relation entre deux classes est une
association, une agrégation ou une composition. Cette distinction est importante notamment
entre l’association et la composition pour permettre à un générateur de code SQL-DDL de
créer correctement le schéma de données.
A partir des deux classes ci-dessous, nous pouvons déterminer qu’une instance de A ne peut
être associée au maximum qu’à une seule instance de B alors qu’une instance de B peut être
associées au maximum à plusieurs instances de A. Par contre, il ne nous est pas possible de
savoir si la relation entre elles est une association ou une composition. Les multiplicités
minimales (0 ou 1) ne sont également pas identifiables à partir du code Java.

public class A {
}
private Integer numero;
private B unB;
public A(Integer numero) {
this.numero = numero;
}
public Integer getNumero() {
return numero;
}
public void setB(B unB) {
this.unB = unB;
}
public B getB() {
return unB;
}
22.06.2005 5/78
public class B {
}
private Integer numero;
private java.util.Map desA;
public B(Integer numero) {
this.numero = numero;
desA = new java.util.HashMap();
}
public Integer getNumero() {
return numero;
}
public void addA(A unA) {
desA.put(unA.getNumero(),
unA);
}
public A getUnA(Integer numero) {
return (A)desA.get(numero);
}
Nous avons donc dû nous tourner vers un langage de spécification plus riche. Nous nous
sommes donc tout naturellement tournés vers le langage UML. Il est possible grâce à la
spécification XMI de l’OMG de créer un fichier XML contenant la description d’un modèle
UML.
La source de définition de notre générateur sera donc un fichier XMI et non plus un ensemble
de classes Java.
Nous avons reproduit ci-dessous une partie du fichier XMI décrivant le même modèle que le
modèle Java étudié précédemment. Nous avons volontairement laissé de côté les méthodes
qui n’ont pas d’influence pour le projet.
//Type de données de l’attribut
//Type de données de l’attribut

//Classe associée
//Classe associée
//Type de données
Grâce à la richesse sémantique d’UML et à XMI, nous avons maintenant à disposition toutes
les informations qui nous manquaient dans le langage Java.
Il manque encore quelque chose à notre source de définition pour être satisfaisante. En effet
UML ne prend pas en charge l’expression de contraintes qui ne découlent pas de la
sémantique de son méta-modèle.
Nous allons prendre un exemple pour mieux comprendre ce problème. Nous aimerions
exprimer que l’attribut « note » de la classe « Evaluation » peut contenir que des valeurs
entières comprises entre 1 et 10. Le type de données ne nous pose pas de problème avec UML
puisqu’il suffit de dire que l’attribut est de type entier. Par contre la plage de valeurs [1,10] ne
peut pas être représentée.
Notre solution consiste à utiliser un langage formel d’expression de contraintes, le langage
OCL de l’OMG pour exprimer notre règle métier.
context Evaluation inv :
note >= 1 and note

Dans un premier temps, nous avons utilisé l’outil de modélisation Rational Rose de Rational
Software (www.rational.com) pour générer des fichiers XMI. Ce type d’exportation n’étant
pas offert en standard il faut recourir à un add-in pour cela. Nous avons cependant dû
renoncer à utiliser Rational Rose car celui-ci ne permet pas d’associer une contrainte OCL à
une classe. Notre choix s’est finalement porté sur Poseidon for UML de la société Gentleware
(www.gentleware.com).
Poseidon for UML sauvegarde ses modèles de façon native dans des fichiers XMI. Un projet
réalisé avec cet outil comporte plusieurs fichiers (notamment notre fameux fichier XMI) . Ces
derniers sont sauvegardés dans un fichier d’archive dont l’extension est zargo. Il suffit de
désarchiver un de ces fichiers de projet avec un utilitaire comme Winzip pour accéder au
fichier XMI.
22.06.2005 7/78
!

Notre générateur devra faire la différence entre les classes persistantes et les classes
éphémères. Dans ce cas nous utiliserons une des possibilités d’extension d’UML, les Tagged
Values. Ce mécanisme permet d’ajouter des propriétés à un élément du méta-model UML
sans devoir modifier ce dernier. La norme UML précise bien qu’une classe persistante doit
être spécifiée au moyen d’une Tagged Value.
Voici un aperçu simplifié du contenu du fichier XMI produit par Poseidon for UML :
22.06.2005 8/78
!

1.9. Cible Relationnelle objet
Le modèle relationnel a fait ses preuves et il a démontré, surtout depuis les années 80,
qu'il avait des points forts indiscutables. Il a aussi un certain nombre de points faibles,
auxquels le modèle objet répond assez bien, d'où l'intérêt d'une intégration en douceur
des deux modèles.
1.9.1. Forces et faiblesses du modèle relationnel
Le modèle relationnel est complètement adapté aux applications de gestion grâce à son
système de modélisation formé de tables dont les colonnes prennent des valeurs
alphanumériques. Les concepts du modèle relationnel (tables, enregistrements, relations,
champs, etc…) sont simples et aisément compréhensibles. De plus, la longue expérience
dont bénéficient maintenant les SGBD relationnels a permis de les optimiser et donc de
les rendre très performants.
Un autre point fort du modèle relationnel est l'existence de SQL, un langage standardisé
de création et de manipulation des bases de données. Le langage SQL est bien adapté
aux architectures client-serveur, il intègre la gestion des transactions, indispensable lors
d'accès concurrents aux données ainsi que pour leur sécurité.
Par contre, le modèle relationnel, dont la conception est bien antérieure à l'avènement du
multimédia et d'Internet, présente certaines faiblesses qui le pénalise aujourd'hui. On
peut citer en particulier.
• Pas de support des objets complexes
Cette contrainte, imposée par le respect de la première forme normale de Boyce-Codd1,
est inadaptée à la gestion des objets complexes, de plus en plus nombreux dans les
applications actuelles. L'introduction des types de données binaires comme les CLOB
(Character Large Object) ou les BLOB (Binary Large Object) ne résoud pas le problème,
car la nature du stockage de ces types dans les SGBD relationnels ne permet pas des
opérations comme la comparaison de deux LOB. Ils ne sont pas structurés, ce qui impose
une lecture séquentielle de l'objet.
• Non intégration des traitements:
Le modèle relationnel sépare complètement les données des traitements, ce qui rend
impossible l'encapsulation des données. L'encapsulation permet de cacher certaines
informations à l'utilisateur et de les rendre accessibles uniquement par des opérations ou
fonctions manipulant ces informations, permettant un contrôle de la consistance des
données par le programme.
• Absence de pointeurs visibles:
Les pointeurs permettent un parcours très rapide de grandes quantités de données, avec
des gains importants par rapport aux jointures par valeurs utilisées avec le modèle
1 La première forme normale veut que chaque attribut (ou colonne) d'une table contienne une valeur unique pour
chaque enregistrement.
22.06.2005 9/78

elationnel. Il est aussi possible de les utiliser pour partager des références sur des
objets volumineux et ainsi économiser de l'espace de stockage. La majorité des critiques
liées aux pointeurs sont justifiées, mais il serait dommage de se priver de leurs
avantages au niveau des SGBD, uniquement à cause de ces critiques, d'autant plus que
les problèmes qui leurs sont liés sont connus, et donc évitables.
1.9.2. Apports du modèle objet
• L'identité d'objet:
L’identité d’objet appelé OID (Object Identifier) permet de référencer de manière unique
dans une base de données n'importe quel objet de cette base. Il permet aussi l'utilisation
de pointeurs sur l'objet. Ces pointeurs permettent de créer des structures complexes
d'objets (graphes, chaînes) et aussi de parcourir des suites d'associations très
rapidement car elles ne demandent plus l'utilisation de jointures longues et coûteuses.
• L'encapsulation des données:
L’encapsulation a pour but de présenter une structure de données stable à l'utilisateur,
même si la structure interne de la base change complètement. Les données, au lieu
d'être directement accessible par l'utilisateur, sont cachées et des méthodes permettant
la lecture et la modification sont mises en place.
Cette couche d'abstraction entre les données et l'utilisateur facilite grandement la tâche
du programmeur, qui peut gérer comme il le désire son application en interne avec pour
seule contrainte la fourniture d'une interface stable à l'utilisateur.
• L'héritage:
L’héritage permet la réutilisation des types de données, car il permet la définition
d'objets génériques (tables, types de données abstraits) pouvant être spécialisés suivant
les utilisations. Il facilite le travail du développeur qui ne doit plus se soucier des détails
d'implémentation pour chaque objet.
1.9.3. Le modèle objet-relationnel
Le modèle objet-relationnel se fonde sur l'extension du modèle relationnel par les
concepts essentiels de l'objet. Le cœur du système reste donc relationnel, mais tous les
concepts clés de l'objet y sont ajoutés dans une forme particulièrement prévue pour
faciliter l'intégration des deux modèles. On peut citer en particulier, le support des objets
complexes qui est sans aucun doute, l'apport le plus important de ce modèle. Il a été
introduit pour permettre le support des types de données ne respectant pas la première
forme normale de Boyce-Codd, aussi appelé NF 2 (Not First Normal Form). Ainsi tous les
types de données multimédias peuvent aussi être considérés comme des types de
données complexes, par exemple des données cartographiques ou géométriques
nécessitent des colonnes de tables capables de stocker des listes de points.
Faisant suite à la proposition du modèle persistant objet appelé manifeste, le modèle
relationnel objet est principalement basé sur deux références incontournables.
Le second manifeste ou contre-manifeste, dont le principal auteur, Stonebraker place les
SGBD objets comme ne possédant pas de langage d'interrogation.
Dans le troisième manifeste, Date et Darwen proposent une base théorique à
l'intégration des concepts objets dans un contexte relationnel. Ils affirment que
l'utilisation de pointeurs dans les bases de données objet-relationnelles brise la notion
22.06.2005 10/78

d'intégrité référentielle. L'avis général sur cette affirmation est moins tranché, même s'il
est clair pour tout le monde que les pointeurs ne sont pas l'outil idéal pour la gestion de
l'intégrité référentielle.
Cette proposition devrait débouché sur une normalisation sous la forme de la nouvelle
norme SQL 3 (Structured Query Language, ou langage structuré de requêtes), qui
contiendra de nombreuses portions consacrées à la technologie objet-relationnelle.
1.9.3.1. Les nouveaux concepts du modèle RO
• Types de données utilisateurs
Type de données définissable par l'utilisateur composé
d'une structure de données et d'opérations encapsulant
cette structure
Le système de types du SGBD devient extensible et n'est plus limité aux types
alphanumériques de base, l'utilisateur est en mesure de définir ses propres types,
adaptés à la gestion de ses informations, soit image, point, vecteur, etc. Ils sont appelés
types abstraits (ADT, Abstract Data Type), ce nom vient du fait que l'implémentation du
type est spécifique à l'environnement et que seule son interface est visible.
• Patrons de collections (Collection template)
Type de données générique permettant de supporter des
attributs multivalués et de les organiser selon un type de
collection.
Les patrons de listes permettent de définir des nouveaux types sur la base de collections
d'autres types. Ils peuvent utiliser les différents types de collections du modèle objetrelationnel,
comme table, liste, ensemble et tableau dynamique.
• Référence d'objet
Type de données particulier permettant de mémoriser
l'adresse invariante d'un objet ou d'un tuple
Les références sont les identificateurs d'objet (OID) du modèle objet-relationnel. Elles
représentent des valeurs uniques et invariantes permettant de chaîner les objets entre
eux sans passer par des jointures par valeurs.
• Héritage de type
Forme d'héritage impliquant la possibilité de définir un
sous-type d'un type existant, celui-ci héritant alors de la
structure et des opérations du type de base
Il est à noter que l'objet-relationnel permet aussi l'héritage de table car une table est vue
comme un type sans opération.
1.10. Choix d’une plateforme cible
La technologie objet-relationnelle est née en 1992, elle est donc assez nouvelle sur le
marché des SGBD, dominé depuis environ 1970 par les bases de données de type
22.06.2005 11/78

elationnel. Actuellement, tous les grands éditeurs de SGBD sont conscients des limites
du modèle relationnel, ils ont donc vu dans le modèle objet-relationnel une manière
d'enrichir ce modèle. Informix a été le premier éditeur de SGBD à relever le défi de
l'objet-relationnel en rachetant la firme Illustra, qui développait alors une version
commerciale du système Postgres, un SGBD relationnel étendu. Les autres grands
éditeurs de SGBD, comme IBM et Oracle, ont suivi cette évolution, et la tendance
générale chez ces éditeurs se décompose actuellement en trois pans:
• Evolution interne du moteur du SGBD.
• Connexion entre le moteur relationnel et des moteurs spécialisés dans la
manipulation de certains types de données complexes.
• Promotion des solutions Middleware qui permettent l'interconnexion des applications
à des SGBD hétérogènes.
L’étude concernant le choix de plate-forme cible s’est arrêtée sur un a priori de deux
constructeurs.
1.10.1. PostgreSQL
PostreSQL est le système de gestion de base de données académique par excellence. On
trouve sur le Net plusieurs documents de qualité sur ce système, mais nous n’avons pas
trouvé de références rigoureuses traitant de l’aspect relationnel objet. Nous avons étudié
les diverses fonctionnalités et développé un petit prototype. Ce SGBD supporte depuis
plusieurs années des concepts comme l’héritage mais les méthodes et plus graves les
types abstrait de données ne sont pas supportés. A la fin de cette brève étude nous
avons abandonné ce produit.
1.10.2. Oracle
Oracle propose depuis sa version 8 des fonctionnalités relationnelles objet qui ont été
améliorée avec sa version 9 qui supporte notamment l’héritage. Nous avons déjà des
compétences sur ce produit, et concernant la partie relationnelle objet, le projet ISNet 15
« base de données relationnelles objet » déposé dans le cadre de la réserve stratégique
de la HES-So constitue une sérieuse base de référence en plus de la large documentation
fournies par des tiers.
Les groupes de compétences ISNet de Neuchâtel et de Genève disposent tous les deux
de plate-formes fonctionnelles avec ce constructeur.
Description des composants
1.11. OCL
1.11.1. Introduction
OCL (Object Constraint Language) est un langage formel pour l’expression de contraintes,
standardisé par l’OMG.
Une expression OCL est sans effet de bord ; elle ne modifie pas l’état du système.
L’exécution d’une expression OCL ne fait que retourner une valeur.
22.06.2005 12/78

OCL est utilisé pour exprimer les invariants du méta-modèle UML ainsi que les règles
syntaxiques d’UML qui ne peuvent pas être exprimées dans le méta-modèle.
OCL est un langage formel qui se veut facile à appréhender. Il a été conçu par la division
« assurances » d’IBM comme langage de modélisation métier.
OCL est un langage typé et par conséquent chaque expression possède un type. Une
expression OCL bien formée doit respecter les règles de conformité des types du langage.
Chaque classificateur définit dans un modèle UML est un type OCL valide.
Les états des objets d’un modèle ne peuvent pas changer pendant l’exécution d’une
expression OCL.
OCL peut être utilisé dans les cas suivants :
• Spécification des invariants des classes et des types d’un modèle de classes
• Spécification des invariants de type pour les stéréotypes
• Description des pré- et post-conditions d’une opération
• Spécification des contraintes d’une opération
• Description des gardes
• Expression des navigations au travers d’un modèle de classes
1.11.2. Mot-clé « context »
Chaque expression OCL est liée à un contexte définissant le type auquel elle se
rapporte. Chaque instance d’un type doit ensuite respecter les contraintes définies
pour ce type.
Stéréotype de contrainte
• inv = 0
Il est possible de spécifier un nom d’instance.
context p : Pile inv :
p.nb_elem >= 0
1.11.3. Mot-clé « package »
Il est possible de préciser le contexte d’une expression OCL en indiquant un nom de
paquetage auquel elle est rattachée. Un paquetage peut contenir plusieurs
expressions OCL.
22.06.2005 13/78

package unPaquetage::unSousPaquetage
context Pile inv :
self.nb_elem >= 0
endpackage
L’opérateur :: est l’opérateur de résolution de portée du langage OCL.
1.11.4. Mot-clé « self »
Le mot-clé self sert à identifier l’instance à laquelle la contrainte se rapporte. Il n’est
pas obligatoire.
context Pile inv :
self.nb_elem >= 0
1.11.5. Commentaires
Les commentaires correspondent à du texte placé à la suite de deux tirets ; ils
s’étendent jusqu’à la fin de la ligne.
context Pile inv :
self.nb_elem >= 0 -- nb_elem est positif ou nul
Nommage des contraintes
Il est possible de nommer explicitement une contrainte afin de pouvoir la réutiliser par
la suite.
context Pile inv maContraite :
nb_elem >= 0
Types de base
Les types de base OCL sont les entiers, les booléens, les chaînes de caractères et
les réels.
Type Valeurs
Boolean true, false
Integer 1, -5, 2, 34, 26524, …
Real 1.5, 3.14, 100.987, -234.0, …
String ‘Hello world’
22.06.2005 14/78

Le type OclAny est le supertype pour tous les types.
OCL définit un certain nombre d’opérations pour les types de bases.
Type Opérations
Boolean =, and, or, xor, not, implies, if-then-elseendif
Integer *, +, -, /, =, abs(), div(), mod(), max(), min()
Real *, +, -, /, =, , , =, abs(), floor(),
round(), max(), min()
String =, size(), toUpper(), toLower(), concat(),
substring()
Types énumérés
Un type énuméré est une classe avec le stéréotype « enumeration » dans un modèle
UML. Une énumération est considérée comme un type de données
contexte Personne inv :
sexe = Sexe :: féminin
Définition d’attributs et d’opérations
Sexe
masculin
féminin
Il est possible de définir des attributs et des opérations afin de réutiliser plusieurs fois
une expression OCL.
context Person inv :
let income : Integer = job.salary -> sum()
let hasTitle(aTitle: String) : Boolean =
job->exists(title = aTitle)
in
if isUnemployed then
income < 100
else
income >= 100 and hasTitle(‘manager’)
endif
Un attribut ou une opération n’est visible qu’à l’intérieur de la contrainte qui la définit.
22.06.2005 15/78

Il est cependant possible de définir un attribut ou une opération visible par toutes les
contraintes d’un contexte. Pour cela, il faut définir une contrainte stéréotypée
« definition ». Une telle contrainte ne peut contenir que des définitions d’attributs et
d’opérations.
context Person def :
let income : Integer = job.salary -> sum()
let hasTitle(aTitle: String) : Boolean =
job->exists(title = aTitle)
context Person inv :
if isUnemployed then
income < 100
else
income >= 100 and hasTitle(‘manager’)
endif
Le nom d’un attribut ou d’une opération défini par let ne doit pas entrer en conflit
avec le nom d’un attribut, d’une extrémité d’association ou d’une opération du
classificateur du contexte de la contrainte.
Conformité des types de base
Type Opérations
Integer Real
Transtypage
La fonction oclAsType(Type) permet de faire un down cast (transtypage vers un
sous-type).
unClient.oclAsType(PersonneMorale)
Règles de précédence
1) @pre
2) . ->
3) not -(unaire)
4) * /
5) + -(binaire)
6) if-then-else-endif
7) < > =
8) =
9) and or xor
10) implies
22.06.2005 16/78

Redéfinition des opérateurs
Les opérateurs +, -, *, /, , , =, and, or, xor peuvent être redéfinis pour
n’importe quel type de l’utilisateur.
a + b a.+(b) T +(T)
Liste des mots-clés
Propriétés
if not xor context post
then let implies def in
else or endpackage inv
endif and package pre
Une propriété peut être un attribut, une extrémité d’association ou une opération
sans effet de bord (isQuery = true) d’un classificateur.
L’accès à la valeur d’une propriété se fait au moyen de l’opérateur « . ».
context Person inv :
self.age > 0
context Order inv :
self.total() >= 0
context xxx inv :
self.yyy(z) = p
Remarques : L’emploi des parenthèses est obligatoire même si une opération n’a
pas de paramètre.
L’emploi du mot self est facultatif.
Opérations et post-condition
Lorsqu’une contrainte est définie comme une post-condition d’une opération, il est
possible de faire référence au résultat de l’opération au moyen du mot « result ».
context Person::income(d:Date) post :
result = age * 1000
Pour obtenir la valeur avant modification d’une propriété dans une post-condition, il
faut post-fixer le nom de la propriété avec @pre.
22.06.2005 17/78

context Mongolfiere.lacherLest(quantite : Poids) post :
self.poids = self.poids@pre - quantite
context Company ::hireEmployee(p : Person)
pre: not employee->include(p)
post: employee->include(p) and
stockprice() = stockprice@pre() + 10
Opérateur d’implication
A implies B Si A est faux la condition est vraie
Si A est vrai et B est vrai, la condition est vraie
Si A est vrai et B est faux, la condition est fausse
context Personne inv :
estUnConducteur = vrai implies age > 18
Opérations prédéfinies
OCL définit cinq opérations qui peuvent être appliquées à tous les objets.
oclInState
Syntaxe : oclInState(s : oclState) : booléen
L’expression est vraie si l’objet est dans l’état « s » sinon elle est fausse. Les valeurs de « s »
sont les noms des états définis dans l’automate d’états associé au classificateur de l’objet. Le
symbole « :: » permet de présenter des états imbriqués (etat_parent ::etat_enfant).
oclIsNew
Syntaxe : oclIsNew : booléen
Cette expression est utilisée dans une post-condition ; elle est vraie si l’objet est créé
lors de l’exécution de l’opération.
oclAsType
Syntaxe : oclAsType(t : oclType) : instance d’oclType
22.06.2005 18/78

Cette fonction permet de faire des conversions de type. Le type vers lequel se fait la
conversion doit être un sous-type du type de l’objet à convertir (down-cast). Comme
dans tous langage, le down-cast est dangereux et doit être utilisé de façon réfléchie.
unChien.oclAsType(ChienChasse)
oclIsTypeOf
Syntaxe : oclIsTypeOf(t : oclType) : booléen
L’expression est vraie si le type directe de l’objet et le type direct de « t » sont les
mêmes ; sinon elle est fausse.
oclIsKindOf
Syntaxe : oclIsKindOf(t : oclType) : booléen
L’expression est vraie si « t » est le type direct ou un des super-types de l’objet.
Accès à une propriété redéfinie dans un sous-type
Si B est un sous-type de A et que tous les deux disposent d’une propriété p1, il faut
utiliser l’opération oclAsType pour accéder à la propriété du type parent.
context B inv :
self.oclAsType(A).p1 >= 10 -- p1 de A
self.p1 >= 100 -- p1 de B
Extrémités d’association et navigation
Il est possible de naviguer à travers une association en utilisant l’opérateur . suivi du
nom du rôle opposé.
object.rolename
Cette expression retourne l’ensemble des objets correspondant à l’autre extrémité de
l’association. Dans le cas où la multiplicité maximale est de 1, l’expression retourne
uniquement l’objet associé.
context Company
inv : self.manager.isUnemployed = false -- 1 manager
inv : self.employee->notEmpty() -- n employés
Lorsque la navigation d’une association ne retourne qu’un seul objet, celui-ci peut
être manipulé comme un ensemble.
22.06.2005 19/78

context Company inv :
self.manager->size() = 1 -- 1 manager
Cette caractéristique peut être intéressante si une extrémité d’association à 0..1
comme multiplicité.
context Person inv :
self.wife->notEmpty()
implies self.wife.sex = Sex::female
Par défaut, la navigation retourne une collection de type Set. Si l’extrémité
d’association est enrichie par la contrainte {ordered], la collection retournée est de
type Sequence.
OCL définit trois types de collection : Set, Sequence, Bag. Ces collections disposent
toutes d’opérations prédéfinies.
Une propriété de collection peut-être accédée au moyen de l’opérateur -> suivi du
nom de la propriété.
context Person inv :
self.employer->size() < 3
context Person inv :
self.employer->isEmpty()
Lorsque le nom d’un rôle n’est pas explicitement spécifié, il faut utiliser le nom du
type à l’extrémité de l’association mais en le commençant par une minuscule. Si
cette procédure engendre une ambiguïté dans les noms des propriétés, le nom du
rôle est obligatoirement requis (c’est le cas notamment des associations réflexives).
self.person -- Navigation vers la classe Person
Pour exprimer une navigation vers une classe associative, il faut utiliser l’opérateur .
suivi du nom de l’association en le commençant par une minuscule.
self.job -- Navigation vers la classe associative Job
Si l’association est réflexive, if faut encore donner le nom du rôle pour pouvoir
naviguer vers la classe associative.
-- Navigation vers la classe associative EmployeeRanking
-- en utilisant le rôle bosses
self.employeeRanking[bosses]->sum() = 0
La navigation depuis une classe associative vers une des classes de l’association est
considéré comme une navigation normale. Cependant, en raison de la définition de
la classe associative dans UML, la navigation depuis une classe associative ne
22.06.2005 20/78

etourne toujours qu’un seul objet par extrémité d’association. Celui-ci peut
également être manipulé comme un ensemble.
Collections
OCL disposent comme nous venons de le voir trois sortes de collection (set, bag,
sequence) spécialisant la collection abstraite « collection ».
Collection
Set Bag Sequence
Un set représente un ensemble qui ne contient que des valeurs uniques (ensemble
au sens mathématique du terme). Le contenu d’un set n’est pas ordonné.
Un bag est un ensemble pouvant contenir plus d’une fois un élément. Le contenu
d’un bag n’est pas ordonné.
Une séquence est un ensemble pouvant contenir plus d’une fois un élément. Le
contenu d’une séquence est ordonné.
Il est possible d’initialiser le contenu d’une collection avec des valeurs littérales.
Set {} -- Ensemble vide
Set {7, 9, 54, 90}
Set {‘Pomme’, ‘Orange’, ‘Banane’}
Lors de l’initialisation d’une séquence, il est possible de définir des intervalles.
Sequence {10, 20..24, 90} -- 10, 20, 21, 22, 23, 24, 90
Conformité des types « collection »
Type Opérations
Set(T) Collection(T)
Sequence(T) Collection(T)
Bag(T) Collection(T)
Si « Vélo » et « Voiture » sont des sous-types de « Véhicule » :
• Set(Vélo) est conforme à Set(Véhicule)
• Set(Vélo) est conforme à Collection(Vélo)
• Set(Vélo) est conforme à Collection(Véhicule)
22.06.2005 21/78

• Set(Vélo) n’est pas conforme à Bag(Vélo)
• Set(Vélo) n’est pas conforme à Sequence(Vélo)
Les deux dernière règles s’expliquent par le fait que Set et Sequence sont au même
niveau dans la hiérarchie des collections d’OCL.
Opérations génériques sur les collections
Les opérations sur les collections ne peuvent pas modifier le contenu d’une
collection.
L’opérateur -> permet d’accéder à une opération sur une collection.
collection -> operation()
« select » et « reject »
select(exprBool) : Collection
Cette fonction retourne une nouvelle collection restreinte aux éléments satisfaisant la
condition. La nouvelle collection est une sous-collection de la collection de départ.
Il existe trois syntaxes différentes pour exprimer la condition :
select(exprBool)
context Personne :: nbFilles() : entier
post: result = self.enfants
-> select(sexe = Sexe :: feminin) -> size
select(iterateur | exprBool)
context Personne :: nbFilles() : entier
post: result = self.enfants
-> select(fille | fille.sexe = Sexe :: feminin)
-> size
select(iterateur : type | exprBool)
context Personne :: nbFilles() : entier
post: result = self.enfants
-> select(fille : Personne |
fille.sexe = Sexe :: feminin) -> size
L’utilisation d’une syntaxe sans itérateur explicite implique malgré tout un itérateur
implicite anonyme.
22.06.2005 22/78

Lorsqu’il y a une ambiguïté pour la sélection d’une propriété dans une expression, il
faut obligatoirement utiliser une syntaxe avec itérateur.
La contrainte ci-dessous n’est pas valide car l’accès à la propriété « lastName » est
ambiguë.
context Person
inv: employer->forAll(employee->exists(lastName = name)
En effet, « lastName » peut dans cette expression s’appliquer soit à l’instance de
personne qui a déclenché le contrôle de la contrainte ou aux instances de la
collection retournée par la navigation d’ « employer » vers « employee ». Il faut donc
spécifier explicitement à quelle instance s’applique la propriété.
ou bien
ou encore
context Person
inv: employer->forAll(employee->exists(p |
p.lastName = name)
context Person
inv: employer->forAll(employee->exists(p : Person |
p.lastName = name)
context Person
inv: employer->forAll(employee->exists(
self.lastName = name)
reject(exprBool) : Collection
Cette fonction retourne une nouvelle collection restreinte aux éléments ne
satisfaisant pas une condition. La nouvelle collection est une sous-collection de la
collection de départ. Les trois formes de syntaxe sont possibles.
« collect »
collect(expr) : Bag
Cette fonction retourne un bag construit à partir de la collection de départ mais
contenant des éléments du type de l’expression. La nouvelle collection n’a pas
forcément le même type que la collection de départ. Le nombre d’éléments du bag
est le même que celui de la collection de départ. Les trois formes de syntaxe sont
possibles.
self.employee->collect(birthDate)
self.employee->collect(p | p.birthDate)
self.employee->collect(p : Person | p.birthDate)
22.06.2005 23/78

L’expression ci-dessus retourne un bag contenant les dates de naissance de tous les
employés de la société. La collection de départ est un set(Employee) et la collection
d’arrivée est un bag(Date).
Il existe un raccourci pour utiliser la fonction « collect ». L’application d’une propriété
à une collection est interprétée comme un appel implicite à « collect ».
« forAll »
self.employee.birthDate
forAll(exprBool) : Boolean
Cette fonction retourne vrai si la condition est vraie pour tous les éléments de la
collection. Les trois formes de syntaxe sont possibles.
« forAll » permet également d’avoir plus d’un itérateur sur une même collection. Il
s’agit en fait d’appliquer la fonction au produit cartésien de la collection avec ellemême.
context Company inv
self.employee->forAll(e1, e2 |
e1 e2 implies e1.forename e2.forename
context Company inv
self.employee->forAll(e1, e2 : Person|
e1 e2 implies e1.forename e2.forename
Ces deux contraintes sont identiques. Elles permettent de s’assurer que tous les
employés ont des prénoms différents.
forename
A
B
C
Produit cartésien
e1.forename e2.forename e1 e2 implies e1.forename e2.forename
A A VRAI
A B VRAI
A C VRAI
B A VRAI
B B VRAI
B C VRAI
C A VRAI
C B VRAI
C C VRAI
On pourrait également écrire cette contrainte de la façon suivante :
22.06.2005 24/78

« exists »
context Company inv
self.employee->forAll(e1 |
self.employee->forAll(e2 |
e1 e2 implies e1.forename e2.forename))
exists(exprBool) : Boolean
Cette fonction retourne vrai si une condition est vraie pour au moins un élément de la
collection, sinon elle retourne faux. Les trois formes de syntaxe sont possibles.
« iterate »
context Classe::ajouter(unEleve : Personne)
pre : classeNonSurchargee : nb_eleves exists(unEleve)
context Classe::effectif()
post: result = nb_eleves
iterate(iterateur : T ; accumulateur : T = expr1 |expr2) : ???
Cette fonction permet d’itérer sur une collection.
Les opérations « reject », « select », « forAll », « exists » et « collect » peuvent se
faire au moyen de la fonction iterate.
« expr1 » représente la valeur initiale de la variable « accumulateur ».
context Personne :: revenusDesParents() : Integer
post: result = self.parent
->iterate(p : Personne;
val : Integer = 0 |
val = p.revenus->sum())
La méthode « revenusDesParents » doit retourner un entier correspondant à la
somme des revenus de chaque parent.
collection->collect(x: T | x.property)
correspond aussi à
collection->iterate(x: T; acc : T2 = Bag{} | x.property)
« isEmpty » et « notEmpty »
isEmpty() : Boolean
Cette fonction retourne vrai si la collection est vide, faux sinon.
22.06.2005 25/78

notEmpty() : Boolean
Cette fonction retourne vrai si la collection n’est pas vide, faux sinon.
« size »
size() : Integer
Cette fonction retourne la cardinalité d’une collection (le nombre d’éléments contenus
par la collection).
« count »
count(unObjet) : Integer
Cette fonction retourne le nombre de fois qu’unObjet figure dans la collection (pour
un set ce sera toujours 1).
« sum »
sum() : T
Cette fonction retourne la valeur de l’addition de tous les éléments (de type T) de la
collection. Les élément de la collection doivent évidemment supporter l’opération +
(c’est le cas des types Integer et Real). Le type de retour de la fonction dépend du
contenu de la collection.
« includes » , « includesAll », « exclude » et « excludeAll »
includes(unObjet) : Boolean
Retourne vrai si unObjet fait partie de la collection, sinon faux
excludes(unObjet) : Boolean
Retourne vrai si unObjet ne fait pas partie de la collection, sinon faux.
includesAll(uneCollection)
Retourne vrai si les elements de uneCollection sont tous contenus dans la collection,
sinon faux.
excludesAll(uneCollection)
Retourne vrai si aucun des elements de uneCollection n’est contenu dans la
collection, sinon faux.
isUnique(expr) : Boolean
22.06.2005 26/78

Retourne vrai si l’expression retourne une valeur unique pour chaque élément de la
collection, sinon faux.
sortedBy(expr) : Sequence
Cette fonction retourne une séquence ordonnée d’après l’expression passée en
paramètre. Le plus petit élément pour l’expression devient le premier élément de la
séquence. Le type des éléments de la collection source doit implémenter l’opération
Sequence asSequence()
Set –>Bag asBag()
Bag –> Sequence asSequence())
Bag –> Set asSet()
self.employee->collect(birthDate)->asSet()
Opérations propres à chaque type de collection
Set
=(unSet : Set) : Boolean
Cette fonction retourne vrai si les deux sets possèdent les mêmes éléments, faux
sinon.
-(unSet : Set) : Set
Cette fonction retourne un nouveau set contenant les éléments du set qui ne se
trouvent pas dans unSet.
union(unSet : Set) : Set
union(unBag : Bag) : Bag
22.06.2005 27/78

intersection(unSet : Set) : Set
intersection(unBag : Bag) : Bag
including(unObjet : T) : Set
Cette fonction retourne un ensemble contenant les éléments de l’ensemble plus
unObjet.
excluding(unObjet : T): Set
Cette fonction retourne un ensemble contenant les éléments de l’ensemble à
l’exception de unObjet.
symmetricDifference(unSet : Set) : Set
Cette fonction retourne les éléments qui sont soit dans le set, soit dans unSet mais
pas dans les deux à la fois.
Bag
=(unBag : Bag) : Boolean
Cette fonction retourne vrai si les deux bags possèdent les mêmes éléments, le
même nombre de fois.
union(unBag : Bag) : Bag
union(unSet : Set) : Bag
intersection (unBag : Bag) : Bag
intersection (unSet : Set) : Bag
including(unObjet : T) : Bag
excluding(unObjet : T): Bag
Cette fonction retourne un bag contenant les éléments du bag d’origine à l’exception
de toutes les occurrences d’unObjet.
Sequence
=(uneSequence : Sequence) : Boolean
Cette fonction retourne vrai si les deux séquences possèdent les mêmes éléments
dans le même ordre.
union(uneSequence : Sequence) : Sequence
append(unObjet : T) : Sequence
Cette fonction retourne une nouvelle séquence contenant les éléments de la
séquence d’origine suivi de unObjet.
22.06.2005 28/78

prepend(unObjet : T) : Sequence
Cette fonction retourne une nouvelle séquence commençant par unObjet suivi par
les éléments de la séquence d’origine.
including(unObjet : T) : Sequence
excluding(unObjet : T): Sequence
subSequence(debut : Integer, fin Integer) : Sequence
Cette fonction retourne une nouvelle séquence contenant les éléments contenus
entre les deux bornes.
at(indice : Integer) : T
Cette fonction retourne l’instance se trouvant à l’indice indiqué dans la séquence.
first() : T
last() : T
Ces fonctions retourne la première et la dernière instance de la séquence.
Remarques
Il ne sert à rien de spécifier avec OCL ce qui est déjà exprimé par le modèle UML
Contenu Conteneur
0..*
1
context Contenu inv:
self.conteneur -> size = 1
Bibliographie
Modélisation objet avec UML, deuxième édition, Pierre-Alain Müller et Nathalie
Gaertner, Eyrolles, Paris, 2000, ISBN 2-212-09122-2
OMG – Unified Modeling Language Specification, version 1.5, OMG, Mars 2003,
http://www.omg.org/technology/documents/formal/uml.htm
XMI
1.12. Introduction
22.06.2005 29/78

XMI (XML Metadata Interchange) est un langage de spécification destiné à faciliter
l’échange des méta-données entre les outils de modélisation basés sur UML et les référentiels
de méta-données basés eux sur le MOF (Meta Object Facilty) dans des environnements
hétérogènes.
Il existe actuellement deux versions de XMI. La version 1.3 (01 mai 2003) définit comment
utiliser des XML Schémas au lieu de la traditionnelle DTD mais les fonctionalités sont
identiques à la version 1.2. La version 2.0 (02 mai 2003) apporte, elle, de nouveau éléments
au langage XMI.
Dans le cadre de ce projet, nous nous sommes intéressés à la version 1.2 uniquement car notre
outil de modélisation Poseidon for UML supportait uniquement cette dernière.
Comme nous allons le voir, XMI est capable d’embarquer plus de sémantique qu’un modèle
Java et supporte également les contraintes définies avec OCL.
UML permet de décrire des modèles de façon orientée objet alors que MOF définit un
framework pour la modélisation des méta-données et fournit des outils pour accéder à ces
méta-données à partir d’un langage de programmation. XMI permet d’échanger des métadonnées
sous la forme de flux ou de fichiers en recourant à XML.
1.13. Classes et types de données
A partir du modèle UML ci-dessus, voilà à quoi ressemble un fichier XMI. Nous allons
commencer par étudier comment sont définis les types int et String. Les balises importantes
sont mise en évidence grâce au surlignage.
Voici le contenu intégral du fichier XMI généré par Poseidon for UML:
Netbeans XMI Writer
1.0
22.06.2005 30/78

22.06.2005 31/78

Les types de données se trouve (avec Poseidon For UML) dans un paquetage java.lang. Les
types élémentaires sont décrits au moyen de la balise alors que les types
composés le sont avec . Il est intéressant de remarquer pour ces deux éléments
22.06.2005 32/78

l’attribut xmi.id dont la valeur permettra de faire référence au type en question à partir d’une
autre balise du fichier.

dataValue = '-99-26--92-79-247d4a:f5d0b19cde:-7ffd'>
Nous retrouvons bien notre classe « client » définie par une balise . Cette
dernière contient les attributs grâce à . Pour le type des attributs, nous
trouvons un lien dans vers les types que nous avons présentés cidessus
au moyen de l’attribut xmi.idref. de ou de .

Il est possible de définir une valeur par défaut pour un attribut.
1.14. Associations
En se basant sur le modèle UML ci-dessus, nous allons maintenant étudier comment une
association 1-1 est décrite en XMI.
Voici un aperçu du fichier XMI généré par Poseidon for UML:
22.06.2005 37/78

Les balises principales pour décrire une association sont reproduites ci-dessous.
22.06.2005 38/78

Attribut Description
visibility spécifie la visibilité de l’extrémité d’association (public, protected,
private, package)
isSpecification spécifie si l’extrémité d’association fait partie de la spécification
(true) ou de la réalisation (false) de la classe
iNavigable spécifie si l’extrémité d’association peut être traversée depuis
l’instance associée (true) ou non (false)
odering spécifie si les éléments résultant de la traversée de cette extrémité
d’association sont ordonnés (ordered) ou non(unordered)
aggregation spécifie si la classe associée à cette extrémité d’association est un
agrégat (aggregate) ou un composé (composite) ou encore une
classe normale (none)
targetScope spécifie si l’extrémité d’association est associé à une instance ou à
une classe
changeability spécifie si l’instance associée à cette extrémité d’association peut
être changée (changeable) ou s’il est ne peut pas être changée
(frozen) ou s’il est uniquement possible d’ajouter de nouvelles
instances (addOnly)
Attribut Description
lower spécifie le nombre minimum d’instance pouvant être associé à
l’extrémité d’association
upper spécifie le nombre maximum d’instance pouvant être associé à
22.06.2005 39/78

l’extrémité d’association
La seule chose qui change pour une association 1-n par rapport à une association 1-1 c’est la
valeur de la borne maximale de la multiplicité.
Si l’attribut « upper » de la balise a la valeur –1, il s’agit d’une
association « à plusieurs ».
Une association n-n voit donc ses deux extrémités d’association prendre la valeur –1 comme
multiplicité maximale.
1.15. Relations de généralisation
Voici un aperçu du fichier XMI généré par Poseidon for UML:
22.06.2005 40/78

…
Si une classe B spécialise une classe A, alors la classe B contient une balise
qui fait référence à une autre balise
dans le fichier.
La balise permet de savoir quelle est la classe parent
() et la classe enfant ()de la
relation de généralisation.
1.16. Classes associatives
22.06.2005 41/78

collabore
Employe Mandat
0..*
0..*
Collaboration
nbHeures
Poseidon for UML ne supportant pas les classes associatives, nous avons utilisé Rational Rose
et son add-in JCRUML pour obtenir un fichier XMI contenant une classe associative.
Voici un aperçu du fichier XMI généré par Poseidon for UML:
22.06.2005 42/78

Une classe associative porte bien son nom puisqu’elle dispose à la fois des caractéristiques
d’une classe () et de celles d’une association
().
…
…
…
1.17. Contraintes OCL
XMI est capable d’embarquer des contraintes OCL. Nous allons voir comment la contrainte
ci-dessous est déclarée dans le fichier XMI.
context Article inv :
prix > 0.0
Voici un aperçu du fichier XMI généré par Poseidon for UML:
…
22.06.2005 43/78

…
L’existence d’une contrainte OCL sur une classe est déclarée au moyen de la balise
. Cette dernière référence une balise
qui contient l’expression OCL définissant la contrainte dans l’attribut « body » de la balise
.
1.18. Bibliographie
OMG – XML Metadata Interchange Specification, version 1.2, OMG, Janvier 2002,
http://www.omg.org/technology/documents/formal/xmi.htm
OMG – Unifield Modeling Language Specification, version 1.5, OMG, Mars 2003,
http://www.omg.org/technology/documents/format/xmi.htm
1.19. Oracle 9i
L’objectif est de décrire ici globalement les capacités relationnelles objets supportée par
Oracle, soit :
22.06.2005 44/78

• Les types définis par l'utilisateur, qui sont les classes de la base de données.
• Les références d'objets (semblables aux pointeurs).
• Les objets de grande taille ou Large Objects (LOB) et leurs dérivés.
• L’héritage
• Les procédures stockées en langage PL/SQL2 et/ou Java (JDBC3 et SQLJ4).
Dans le cadre particulier de ce de ce projet, les fonctionnalités des méthodes des classes
persistantes ont été volontairement mises de coté, c’est pourquoi nous n’allons que très
peu les développer ici.
1.19.1. Référence
Le modèle de référence utilisé par Oracle est le manifeste5 de Date et Darwen. Cette
approche basé sur la dualité de structure est aussi cohérent avec la double vision de
l’objet BD : « encapsulation » associée aux domaines, « structuration » associée aux
relations. Dans ce manifeste les deux nouveautés essentielles naturellement intégrées
dans le modèle relationnel de bases sont :
• Les types de données extensibles
• L’héritage
1.19.2. Description des fonctionnalités objet Oracle
1.19.2.1. Types 6
Oracle définit de nouveaux types de données pouvant être créés par les utilisateurs et
qui peuvent être utilisés pour modéliser des objets. Ces objets sont semblables aux
mécanismes de classes que l'on trouve en Java, ils peuvent contenir:
• Des attributs qui peuvent être:
Des types scalaires définis par Oracle (VARCHAR, NUMBER, DATE, …).
Des références sur d'autres objets (pointeurs).
Des objets.
Des collections d'objets.
Des objets larges non structurés (LOBs, BLOBs CLOBs, …).
• Des méthodes, dont
Des méthodes membres (MEMBER) qui s'applique à un objet
Des méthodes statiques (STATICS) qui s'applique à la classe
Ces nouveaux types peuvent être interrogés par les moyens habituels, c'est-à-dire
requêtes SQL, PL/SQL ou autres. Ils peuvent être inclus dans des tables de plusieurs
manières:
• Comme une colonne de table.
• Comme un tuple (une ligne est un objet).
2 PL/SQL est une extension procédurale à la norme SQL. C’est le langage propriétaire d’Oracle
3 JavaDataBaseConnectivity : APIs Java de connexion pour une base de données cible
4 SQLJ précompilateur Java pour SQL. Génère des appels JDBC
5 Est également nommé troisième manifeste
6 Ce qu' Oracle dénomme un type est en fait ce qu'on appelle dans la terminologie objet une classe.
22.06.2005 45/78

Quand les objets sont définis comme lignes (tuples), un identificateur unique, appelé OID
(Object Identifier), leur est automatiquement assigné. Cet identificateur est unique pour
chaque objet de la base de données et il n'est jamais réutilisé, même si l'objet est
détruit.
Les fonctions membres des types peuvent être écrites de différentes façons :
• En PL / SQL, de la même manière que l’on écrit un trigger ou une procédure stockée.
• En Java (à partir de la version 8i)
• Dans un langage externe à la base de données comme le C ou le C++.
1.19.2.2. OID et Références
L’implémentation de données objets persistantes nécessitent la notion d'identificateur
d’objet. Oracle introduit le concept de références dans la base de données. Les
références sont semblables aux références que l'on trouve dans les langages de
programmation orientés objet comme le C++ ou Java. Elles peuvent être vues comme
une extension de la notion de clé étrangère, et elles représentent le principal moyen pour
représenter l'intégrité référentielle dans les données objet comme les types définis par
l'utilisateur.
Une référence est définie par l'utilisation du mot clé REF et, en interne, elle utilise l'OID
(object Identifier) pour définir sa cible. L'obtention de la référence sur un objet se fait en
appelant la fonction REF(…), et le déréférencement se fait de la même manière par la
fonction DEREF(…).
L'utilisateur peut utiliser les références comme si il manipulait l'objet qui est référencé,
sans restrictions.
1.19.2.3. Collections d'objets
Oracle permet de gérer les données qui ne respectent pas la première forme normale de
Boyce-Codd, 7 comme :
• Les tables en tant qu’attributs de tables (Nested Tables)
• Les tableaux de taille variable (Varrays)
Les attributs des objets ainsi que les colonnes des tables peuvent être d’un de ces types,
et ainsi, les développeurs ont la possibilité de modéliser des relations un à plusieurs (1 –
n) et plusieurs à plusieurs (n – m) directement à l’intérieur des objets de leur schéma.
• Nested tables
Une nested table est une table à l'intérieur d'une autre table, elle est particulièrement
utilisée dans la modélisation des relations 1-n et des liens identifiants. Une table
imbriquée possède toutes les caractéristiques d'une table normale.
• Varrays
Un VARRAY contient zéro ou plusieurs éléments du même type, ayant une position
unique sous la forme d'une collection triée. Le VARRAY est utilisé comme une seule entité
par SQL, il a deux attributs:
7 Souvent appelé NF 2 (Not First Normal Form)
22.06.2005 46/78

Count: Nombre actuel d'éléments.
Limit: Nombre maximal d'éléments.
Les valeurs sont stockées dans une seule ligne physique si elles ne dépassent pas 4 kb.
Les positions des éléments sont indiquées par des entiers et commencent à 1. Il n'est
pas possible de définir des valeurs par défaut ou des contraintes sur un VARRAY ou ses
éléments.
• Différences entre VARRAY et NESTED TABLE
VARRAY NESTED TABLE
Collection triée Comportement multi-ensemble
Stocké dans le segment Stocké hors du segment
Ne supporte pas les index Supporte les index
Limite sur le nombre d'éléments Pas de limite sur la taille
Pas de SELECT sur les éléments SELECT possible sur les lignes d'une
NESTED TABLE
On utilisera donc vraisemblablement un VARRAY pour des petites quantités de données
de taille connue et une nested table quand les données sont moins uniformes et moins
prévisibles.
1.19.2.4. Méthodes
• Méthodes membres
Chaque type peut comporter des méthodes. Ces méthodes peuvent être implémentée
avec des fonctions (elles retournent une valeur) ou une procédure. La directive SELF
désigne l'objet sur lequel porte la méthode.
• Méthodes statique
La méthode n’est pas rattaché à un objet particulier mais à la classe complète.
Une méthode memebre ou statique peut être utilisée
• Appelée dans un programme PL/SQL.
• Evaluée8, dans une requête SQL si elle retourne une valeur (fonction).
Les fonctionnalités du SGBD pour l’implémentation des méthodes ne sont que très peu
développées ici, le cahier des charges du projet spécifiant clairement que nous
n’implémenterons pas de méthodes au niveau des objets persistants
1.19.2.5. LOBS
Les LOBs sont des objets de grande taille (en anglais Large Objects). Ils se divisent en
deux catégories, et supportent plusieurs types:
• Internes
BLOBs : Binary Large Objects (Ex: Images, sons, vidéo)
CLOBs : Character Large Objects (Ex: Textes encodage single byte)
NCLOBs : National Character Large Objects (Ex: Textes encodage multi-byte)
8 La fonction qui implémente la fonction membre doit impérativement être pure
22.06.2005 47/78

• Externes
BFILEs : Pointeur sur des fichiers stockés à même le système d'exploitation.
L'objet DIRECTORY est utilisé pour manipuler des LOBs externes (BFILE), il représente un
alias sur un répertoire du système d'exploitation.
Les deux types de LOB ont des fonctionnalités pour des utilisations différentes.
LOBs Internes LOBs externes
Stockés dans la base de données. Stockés à l'extérieur de la base de données, en
tant que fichiers. La base ne garde qu'une
référence sur le fichier.
Intégrés au modèle transactionnel (ACID). Aucune gestion des transactions.
Complètement intégrés à la base de données. Utilisables en lecture seule uniquement.
(ajout, modif., suppression)
Peu fortement augmenter la taille de la base Augmentation de taille négligeable
de données
Peuvent implémenter plusieurs formats N'implémente que le format (BFILE)
(CLOBS / BLOBS / NCLOBS)
1.19.2.6. Héritage
L'héritage9 est une technique utilisée dans le développement orienté objet afin de créer
des classes qui contiennent des attributs et des méthodes généralisées pour les objets
qui en dépendent. Les classes les plus générales sont appelées super-type et celles qui
en dépendent sous-type.
Exemple:
Un sous-type peut hériter directement d’un super-type ou indirectement au travers de la
hiérarchie des types. Un sous-type ne peut hériter que d’un seul super-type, l’héritage
multiple n’est pas supporté. Les attributs du super-type sont hérités dans tous les soustypes.
Les droits sur les attributs private ou protected n’existent pas, ils sont tous public..
La spécialisation des sous-types s’effectue selon les règles de la programmation objet,
soit création de nouveaux attributs dans les sous-types, toutes les modifications
effectuées sur les super-types sont répercutées dans leurs sous-types.
La création d’un sous-type est l’action d’hériter d’un type qui s’appellera super-type,
cette opération s’effectue par la clause « UNDER ».
• Propriétés des types
PERSONNES
PHYSIQUES MORALES
9 Oracle supporte la notion d’héritage depuis sa version 9.
22.06.2005 48/78

Un type défini comme « FINAL » (valeur par défaut) ne pourra pas être hérité par un
sous-type. Un type « NOT FINAL » peut être transformé en « FINAL » uniquement s’il n’a
pas de sous-type.
La notion d’abstraction ou non, sous Oracle est définie par les clauses « NOT
INSTANTIABLE » ou « INSTANTIABLE » ce qui va permettre aux développeurs de créer
des types abstraits. Un type « NOT INSTANTIABLE » est donc une classe abstraite, son
instantiation est impossible.
Par défaut un type est « INSTANTIABLE ».Un type « INSTANTIABLE » peut devenir
«NOT INSTANTIABLE » et vice-versa.
1.19.2.7. Principe de substitution et polymorphisme
Le principe de substitution affirme qu’il doit être possible de substituer n’importe quel
objet instance d’un sous-type à n’importe quel objet instance d’un super-type sans que la
sémantique du programme écrit dans les termes du super-type ne soit affectée.
Ceci est applicable pour tous les containers de type Oracle objets (ex : une variable, un
attribut table ou vue). Sans le respect de ce principe, le polymorphisme ne peut être mis
en œuvre.
Le polymorphisme désigne un concept de la théorie des types (types objets, REF ou
collection d’objets), selon lequel un nom d’objet peut désigner des instances de types
différents, issues d’une même arborescence. La clause «NOT SUBSTITUTABLE AT ALL
LEVELS » désactive le principe de substitution et par analogie le polymorphisme. La
clause « IS OF » permet de limiter le principe de substitution à certains types.
Les objets qui sont abrités dans un container super-type peuvent être accédés à l’aide de
la fonction « TREAT ». Cette fonction cherche à modifier le type d’une expression par un
autre type, généralement par un sous-type.
1.19.2.8. Héritage et méthodes
Les méthodes du super-type sont héritées dans tous les sous-types, la spécialisation des
sous-types s’effectue selon les règles de la programmation objet :
Surcharge des méthodes et ré-implémentation.
Méthode à signature variable.
• Méthodes abstraites
La clause « NOT INSTANTIABLE » définit une méthode abstraite, par défaut celle ci est
« INSTANTIABLE ». L’implémentation d’une méthode « NOT INSTANTIABLE » doit
s’effectuer dans un sous-type de son arborescence. Si le sous-type de 1 er niveau
n’implémente pas une méthode abstraite, elle doit tout de même être déclarée comme
étant « NOT INSTANTIABLE ».
• Surcharge, signatures variables et comportement des méthodes héritées
Les méthodes peuvent être surchargées à l’aide de la clause « OVERRIDING ». Le soustype
hérite alors de toutes les méthodes du super-type qu’elles soient « STATIC » ou
« MEMBER ». Plusieurs méthodes de même nom mais avec une signature différente
peuvent être définies.
Une hiérarchie de type peut surcharger plusieurs fois la même méthode. Les
conséquences lors de l’exécution seront les suivantes :
Le type de l’instance de l’objet désignera la méthode à utiliser.
22.06.2005 49/78

Cette désignation s’effectuera lors de l’exécution et non lors de la compilation
(résolution tardive).
Une méthode « FINAL » ne pourra pas être surchargée dans ses sous-types. Par défaut
une méthode est « NOT FINAL ».
• Restriction à la surcharge
Les méthodes de type « FINAL » ne peuvent évidemment pas être surchargées.
Une méthode « STATIC » du sous-type ne peut pas surcharger une méthode
« MEMBER » du super-type et inversement.
Une méthode avec des paramètres ayant une valeur par défaut (« DEFAULT
VALUE ») peut être surchargée uniquement si les valeurs par défaut sont
redéfinies dans son ou ses sous-types.
Une méthode « ORDER » ne peux pas être surchargée.
1.19.3. Persistance
A partir des types créés, Oracle propose deux manières d’implémenter des objets
persistant.
• Céation d’une tables à partir du type. On nomme ces tables tables objets. Chaque
insertion dans la table est donc une instanciation d’objet.
• Création d’une vue dont la structure est définie par le type et de tables relationnelles
pour placer des tuples. La vue est définie par une requête basée sur les tables
relationnelles
Dans les deux cas, ce sont les tables (objet ou relationnelles) qui suppoteront les
contraintes déclaratives. Le choix d’une implémentation est donc déterminant pour
décrire les méthodes et les contraintes procédurales.
1.19.3.1. Tables objets
Si on uttilise les tables objets, on créer à partir d'un type une table objet qui est un
"container" capable d'assurer la persistance des objets.
Dans la déclaration de la table objet, l’utilisation de la clause "SCOPE IS" limite la portée
d'un attribut de type "REF" aux OID de la table référencée. Elle permet d'améliorer
l'intégrité référentielle. La clause SCOPE contrôle correctement l'ajout d'une valeur
erronée qui référence (enfant sans père) mais n'assure pas la manipulation de l'objet
référencé. (Suppression d'un père qui a des enfants). Il est donc possible dans une base
de données relationnelle objet, qu’une référence ne pointe plus sur un objet valide du
container même si la clause SCOPE est explicite. De telles références sont nommées
dangling REFs. Elles peuvent être détectées avec le prédicat IS DANGLING.
Si la clause "WITH ROWID" qualifie attribut de type "REF", cela signifie que l’on stocke le
"ROWID" du tuple avec l'OID dans l'attribut en question. Ceci permet d'améliorer les
performances de déférencement, mais utilise davantage d'espace mémoire.
• Instanciation des collections
1.19.3.2. Vues objets
22.06.2005 50/78

La seconde possibilité pour assurer la persistance des objets est de construire une vue
dont la structure est basé sur un type. Les objets seront stockés dans des tables
relationnels classiques.
Le lien entre les tables (contenu des objets) et la structure (type) est garanti par la
requête définissant la vue. L'OID peut être obtenu à partir de l'identifiant de l'objet (clé
primaire de la table principale).
Pour gérer les éléments multivalués comme les collections, on utilise des requêtes
imbriquées dans la requête de définition de la vue et les clauses CAST et MULTISET.
CAST s'occupera de forcer l'élément retourné dans un type déclaré, alors que MULTISET
prend en charge la création d'une collection (VARRAY ou Nested Table).
1.19.3.3. Héritage et Vues Objets
Définition
Le principe de l’héritage des vues objets se base sur un ensemble de vues objets qui sont
constituées à partir de types différents issus d’une même arborescence.
Règles
• Une sous-vue qui hérite d’une super-vue doit avoir son équivalence dans une
hiérarchie de type.
• Une hiérarchie de vue peut avoir la racine au milieu d’une arborescence de type.
• La racine d’une hiérarchie de vue est appelée « vue de base » ou « root view » en
anglais.
• Deux hiérarchies de vue objet ne peuvent pas se baser sur le même type.
• Toutes les vues d’une hiérarchie doivent se trouver dans le même schéma.
• Le terme pour la définition de l’héritage de vue objet est « UNDER »
Identificateur d’objets (OID)
La vue de base doit définir l’identificateur de l’objet (OID) et ne peut hériter d’aucune
autre vue. L’OID doit être spécifié à l’aide de la commande « WITH OBJECT ID », si le
système doit générer l’OID, il sera possible de créer une sous-vue uniquement si la vue
de base est créée à partir d’une table objet ou d’une vue objet dont l’OID a été généré
par le système. Une sous-vue ne peut évidemment pas définir d’identificateur d’objet
(OID).
Afin de permettre à une vue d’être modifiable sans l’utilisation des triggers « INSTEAD
OF », il faut que la requête qui décrit la vue respecte les contraintes suivantes :
• Pas de jointures
• Pas de set operators
• pas de aggregate functions
• pas de GROUP BY, DISTINCT
• pas de pseudocolumns
• pas d’expressions
Si une vue n’est pas modifiable il faut utiliser les triggers « INSTEAD OF ». Ce type de
trigger n’est pas hérité par les sous-vues. Ils doivent donc être redéfini pour chaque
sous-vue.
Une vue objet peut être de type abstrait. Le terme « NOT INSTANTIABLE » va la
caractériser. Ceci existe afin de pouvoir baser la vue sur un type abstrait.
Lors de la sélection d’une vue objet, tous les objets retournés peuvent être du type de la
vue ou d’une de ses sous-vues. Les fonctions « VALUE », « REF » ou un ou plusieurs
22.06.2005 51/78

attribut de la vue peuvent être employés lors de la sélection d’une vue objet. Afin
d’exclure les objets appartenant aux sous-vue lors de la sélection, il faut utiliser le terme
« ONLY » dans la requête.
1.19.3.4. Modèles hiérarchiques de vues
La conception d’une hiérarchie de vue peut influencer les performances des opérations
qui seront effectuées sur cette structure de vues. C’est pourquoi il est conseillé d’utiliser
un de ces trois modèle pour la mise en place d’une hiérarchie optimale :
• Modèle Plat
• Modèle Horizontal
• Modèle Vertical
Modèle Plat
Toutes les vues et les sous-vues de ce modèle sont basées sur la même table, mais sur
des types différents dans une même arborescence. L’intérêt de ce type de modèle est
qu’il rend la vue modifiable, en supportant les indexes et les contraintes. Par contre le
nombre total de colonnes différentes dans une hiérarchie de types est de 1000,
puisqu’une table ne supporte que 1000 colonnes au maximum. Tous les attributs
appartenant à une sous-vue de l’objet seront de valeur NULL lorsque l’objet sera d’un
type hiérarchiquement supérieur.
Modèle Horizontal
Dans ce type de modèle, chaque vue et sous-vue est créée à partir de tables différentes
et de types différents d’une même arborescence. e type de modèle est très efficace pour
le type de sélection avec une restriction sur un sous-type (SELECT … FROM WHERE .. IS
OF ONLY sous_type)
Par contre, une sélection sans restriction (SELECT * FROM mavue) oblige le système à
faire des UNION pour obtenir le résultat escompté.
Modèle Vertical
Pour ce type de modèle, il y a une table pour chaque vue. Les attributs de ces tables
doivent correspondre aux types ou sous-types sur lesquels les vues seront basées, plus
l’attribut OID. Ce modèle permet la création d’indexes sur un attribut et d’imposer des
contraintes d’unicité sur les attributs. Ce type de modèle dispose des propriétés inverses
du modèle horizontal, puisque la jointure s’effectue entre la table représentant la vue de
base et sa sous-vue.
Les droits
Les droits d'accès sur les tables objets et vues objets est géré de manière classique avec
des GRANT et des privilèges SELECT,INSERT,UPDATE et DELETE.
Pour les méthodes, les mécanismes classiques du modèle objet (private, public,
protected) ne sont pas implémentés dans la version actuelle d'Oracle.
Le privilège EXECUTE sur un type, permet l'exécution de toutes ces méthodes.
22.06.2005 52/78

Ces mécanismes simple permettent donc de mettre en place un système garantissant ou
brisant l'encapsulation des objets, conformément au modèle des BDOO10
"Invoker_Rights_Clause" spécifie si les méthodes "MEMBER" d'une classe doivent être
exécutées avec les privilèges et dans le schéma de leur propriétaire ou de l'utilisateur
courant (CURRENT_USER)
AUTHID CURRENT_USER Spécifie que les fonctions et procédures
"MEMBER" sont exécutées avec les
privilèges de l'utilisateur courant.
Cette clause crée un type "invoker-rights"
AUTHID DEFINER Spécifie que les fonctions et procédures
"MEMBER" sont exécutées avec les
privilèges du propriétaire du schéma dans
lequel se trouvent les méthodes.
1.19.4. Jpublisher
22.06.2005 53/78
Ceci est la clause par défaut.
Jpublisher est un générateur de classe Java à partir des types objets définis dans la base
de données. Il génère des classes SQLJ dans le cas où il y a des méthodes et des class
java sans méthodes dans les types. Les objets générés sont
• Une classe Java représentant le type Oracle.
Cette classe contient des accesseurs set et get pour tous les attributs du type.
• Il peut en outre générer des classes représentant le type de la référence contenu
dans un attribut
Cette classe contient une méthode getValue() qui rend une instance de l’objet se
trouvant dans la référence et un setValue() afin d’effectuer sa modification.
• Pour les collections, il crée une classe qui les représente.
Cette classe contient la méthode getArray() afin de récupérer la collection,
setArray() pour la modifier. Afin de modifier et de récupérer les éléments se
trouvant dans la collection, Jpublisher génère les méthodes getElements() et
setElements
• Elle implémente dans les classes générées l’interface OraData et l’interface
OraDataFactory et la méthode OraDataFactory()
1.20. Transformation des règles
1.20.1. Modèles de classes UML, respect des
cardinalités
L’objectif de ce chapitre est d’évaluer les possibilités de génération de script DDL à partir
d’un modèle de classe UML11. Dans le cadre du projet, la source proposée est un fichier
XMI, alors que pour des raisons de compréhension, les cas traités ici ce feront
10 BDOO : Base de Données Orientée Objet, l'encapsulation est pénalisant pour le langage de requête
11 Le modèle de classe UML n'est pas traité dans ce document, il est repris comme point de départ pour obtenir
le script DDL après transformation.

directement depuis les schéma du modèle de classe. La transposition modèle de classe
en script DDL fait partie selon nous de la phase II du projet.
De part les choix que nous proposons, le résultat du scritpt DDL sera une suite de
création de types dans un premier temps, et de création de table contraintes, basé sur
ces types.
Règles de passage entre niveaux d’abstraction.
Il existe comme pour le modèle relationnel, des règles de passage entre niveaux
d’abstraction permettant de définir des classes persistantes à partir du modèle
conceptuel de données, soit le modèle de classe UML. Mais de part la richesse
sémantique du modèle relationnel objet, elles ne sont pas si rigoureuses que celle du
monde relationnel.
Règle 1
Chaque entité du diagramme de classe UML devient une classe. L’identité devient celui
de la classe.
Règle 2
Une association 1-N/1-* entre deux entités/classes peut se modéliser de trois manières
dans le modèle objet.
• La classe fille migre dans la classe mère
• Avec deux classes dont l’une contient éventuellement une collection avec ou sans
pointeurs
• Avec trois classes ne contenant aucune collection
Règle 3
Une association N-N/*-* entre deux entités/classes peut se modéliser de deux manières
dans le modèle objet.
• Avec deux classes dont l’une contient une collection de pointeurs
• Avec une troisième classe contenant éventuellement une collection de pointeurs
Règle 4
Une association N-aire peut se modéliser de deux manières dans le modèle objet.
• Avec N classes dont l’une contient une collection de pointeurs
• Avec une (N+1)ième classe contenant éventuellement une collection de pointeurs
Règle 5
Une association 1-1 entre deux entités/classes peut se modéliser dans le modèle objet.
• Avec deux classes sans collection et mettant en œuvre des pointeurs
• Avec une troisième classe contenant des pointeurs mais sans collection
On remarque donc que les règles ne sont pas bijectives, et qu’elle laisse place à une libre
interprétation du développeur. Cet état n’est pas tolérable pour un automate comme un
générateur.
Nous nous proposons donc dans la suite du document d’approfondir les différents cas a
fin de lever ces imprécisions en éliminant tout par à l’interprétation et à la suggestion.
Traduction d’un lien de composition monovalué
C1 1 0..1
C2
a
b
22.06.2005 54/78

Le lien de composition va se traduire en un attribut ast2 de type C2.
CREATE TYPE c2 AS OBJECT
( b Varchar(10)) ;
CREATE TYPE c1 AS OBJECT
( a Varchar(10),
ast2 c2 ) ;
Ici le seul problème concernant le script LDD à générer concerne l’ordonnancement de la
création des types. Une proposition à retenir serait l’utilisation systématique des types
partiels en début de script. A noter que si la cardinalité minimum aurrait été 1 au lien du
0 de l’exemple, il faudrait générer une contrainte NOT NULL mais sur la table basé sur le
type c1 et l’attribut ast2.
Traduction d’un lien d’association monovalué
Si on désire traduire un lien d’association d’un modèle de classe on doit résoudre
l’épineux problème de la dualités des paradigmes relationnelles et objets. En effet le
modèle objet spécifie un système de lien avec une navigation directionnel, donc un lien
d’association devrait permettre par défaut de naviguer dans les deux sens.
C1
a
0..1
La traduction du lien l’association dans un monde navigationnel est une mise en place de
deux liens monovalués réciproques leC1 et leC2. Cette combinaison nécessite la création
de type partiel pour permettre les références croisées 12 .
CREATE TYPE c2 ;
CREATE TYPE c1 AS OBJECT
( a Varchar(7),
LeC2 REF c2 ) ;
CREATE OR REPLACE c2 AS OBJECT
( b Varchar(7),
LeC1 REF c1 ) ;
12 Le double référencement rend également plus compliqué l'effacement d'un type. Il faut utiliser l'instruction
DROP TYPE nomtype FORCE. Le dictionnaire est alors incohérent
22.06.2005 55/78
1
C2
b

Sens de navigation imposée
Pour spécifier le sens de navigation le modèle de classe UML dispose d'une notation
précise. Il nous semble donc important de le spécifier clairement lors de la construction
du modèle puisque le sens de navigation n’est pas spécifié, il doit être assuré dans les
deux sens. La solution proposée nous semble donc être la solution correct
Dans le cas de l'implémentation avec une base de données relationnelle objet, le langage
de manipulation de type SQL dispose de l'opérateur de jointure qui ne nécessite pas un
sens de navigation. Si nous disposons d'une base de données objet, le langage de
requête n'est pas spécifié, et la navigation est alors primordiale. De plus si on désire
obtenir un « mapping » automatique entre les classe du langage de programmation et les
classes persistantes, il est impératifs qu’elles aient la même structure.
Dans la suite du document, nous relèverons parfois ce problème de navigation pour
certains points particuliers.
C1
C2
0..1
1
a
b
Avec un sens de navigation imposé, l’association se traduit par une simple mise en place
d’un lien monovalué leC1. La cardinalité minimale 0 figure à la source du lien.
CREATE TYPE c1 AS OBJECT
(a Varchar(10) ) ;
CREATE TYPE c2 AS OBJECT
(b Varchar(10) ,
LeC1 REF c1) ;
C1
C2
0..1
1
a
b
Avec le sens de navigation imposé inverse, l’association se traduit par un lien monovalué
leC2, solution symétrique à la précédente1.
CREATE OR REPLACE TYPE c2 AS OBJECT
(b Varchar(10)) ;
CREATE OR REPLACE TYPE c1 AS OBJECT
(a Varchar(10) ) ;
LeC2 REF c2) ;
Selon les règles proposée (règle 5), l’utilisation d’une classe supplémentaire A et mise en
place de deux liens monovalués leC1 et leC2 est enviseageable. Cette solution appelée
solution universelle nous semble à éviter puisqu'elle ne mets pas en application les
cardinalités, et interdit un mapping automatique.
22.06.2005 56/78

Héritage
Voici ici un exemple de traduction d’une relation d’héritage. A rappeler que la cible
retenue ne supporte pas l’héritage multiple.
C2
b
C4
d
22.06.2005 57/78
C1
CREATE TYPE c1 AS OBJECT
( a Varchar(10))
NOT FINAL NOT INSTANTIABLE;
CREATE TYPE c2 UNDER c1
( b VARCHAR2(10)) NOT FINAL;
a
C3
CREATE TYPE c3 UNDER c1
( c VARCHAR2(10)) FINAL;
CREATE TYPE c4 UNDER c2
( d NUMBER) FINAL;
Contraintes sur héritage
B
b
A
a
c
C
c
{contrainte}

On trouve la notation ci-dessous dans le langage UML pour spécifier une contrainte sur
l’héritage. Les différentes contraintes décrites sont :
- Exclusion (disjonction sans couverture)
- Totalité (non disjonction et couverture)
- Partition (disjonction et couverture)
La notion de couverture entraîne que la super-classe soit abstraite, alors la disjonction
concerne l’identifiant. Il semble donc que les contraintes d’héritage ne doivent pas être
traitées de manières explicite lors du passage dans les différents niveaux d’abstractions.
Mise en place de liens multivalués
La mise en place d’un lien multivalué nécéssite la notion de collection. Oracle supporte
deux types de collections:
• Tables imbriquées (NESTED TABLE)
Une table imbriquée (TABLE OF) est une collection non ordonnée et non limitée
d’éléments de même type. Elle est adaptée à la représentation d’un lien de cardinalité
non définie, N
• Tableaux prédimensionnés
Un tableau prédimensionné (VARRAY) est une collection ordonnée et limitée d’éléments
de même type. Elle est adaptée à la représentation d’un lien de cardinalité fixe (p ex : 3)
Traduction d’un lien de composition multivalué
Modèle de classe pour une cardinalité non définie
C1
De la composition l’attribut ast2 est de type ensemble C2
CREATE OR REPLACE TYPE c2 AS OBJECT
(b Varchar(10) ) ;
CREATE OR REPLACE TYPE tc2 AS TABLE OF c2 ;
CREATE OR REPLACE TYPE c2 AS OBJECT
(a Varchar(10) ,
ast2 tc2) ;
22.06.2005 58/78
a
1 0..*
C2
b

Modèle de classe pour une cardinalité définie
C1
a
De la composition l’attribut ast2 est de type ensemble C2 en respectant la cardinalité
nb
CREATE OR REPLACE TYPE c2 AS OBJECT
(b Varchar(10) ) ;
CREATE OR REPLACE TYPE tc2 AS VARRAY(nb)
OF c2 ;
CREATE OR REPLACE TYPE c2 AS OBJECT
(a Varchar(10) ,
ast2 tc2) ;
Relation d’association de un à plusieurs
C1
On retrouve ici ensemble les deux problèmes précités dans les exemples précédents,
soit :
• Le sens de navigation
• La définition (ou non) des cardinalités
Si l’association à une cardinalité non définie et que le sens de navigation est spécifié de
la fille à la mère, on se retrouve dans le cas d’une traduction identique au modèle
relationnelle, soit la traduction de l’association en un attribut dans la classe fille qui
référence la classe mère, soit :
CREATE TYPE c2 AS OBJECT
(b Varchar(10) ) ;
CREATE TYPE c1 AS OBJECT
(a Varchar(10) ,
ast2 REF c2 ) ;
Si le sens de navigation est inversé (de la mère à la fille), l’association va se traduire par
la mise en place d’un lien multivalué. L’implémentation du type de collection dépendra si
les cardinalités sont définies ou non.
22.06.2005 59/78
a
1 0..nb
* 1
C2
b
C2
b

Voici par exemple la mise en place d’un lien multivalué lesC1 en utilisant un tableau sans
cardinalités.
CREATE TYPE c1 AS OBJECT
(a Varchar(10) ) ;
CREATE TYPE pc1 AS OBJECT
(atpc1 Ref c1 ) ;
CREATE TYPE tpc1 AS
TABLE OF pc1 ;
CREATE TYPE c2 AS OBJECT
(b Varchar(10) ,
LesC1 REF tpc1) ;
Si le sens de navigation n’est pas spécifié, l’association sera traduite par la mise en place
d’un lien multivalué lesC1 et d ’un lien réciproque monovalué leC2. La navigation est
possible avec cette solution dans les deux sens, la remarque émise lors de la
transformation de la cardinalité 1-1 reste valable. Cette donc cette solution qui est
correct par rapport au modèle de classe proposé.
Le code LDD est une combinaison des deux exemples précédents.
La solution universelle, soit l’utilisation d’une classe supplémentaire A et mise en place
de deux liens monovalués leC1 et leC2 est à nouveau à rejeter car elle ne reflète pas les
cardinalités proposées. La navigation entre classes n'est possible qu'en partant de la
classe A, ce qui n'a pas de sens. Pour permettre la navigation bidirectionnelle entre C1 et
C2 il faudrait ajouter deux liens multivalués, une fois entre C1 et A et un second entre C2
et A. Le modèle devient alors particulièrement lourd.
Transformation d’associations N-N sans propriétés
C1
a
L’ensemble des remarques faites pour les exemples précédents restes valable, la
complexité est cumulative. La transformation de cette association est toujours liés aux
sens de navigation et à la définition des cardinalités, mais les liens sont les deux
multivalués.
Pour le diagramme ci-dessus, soit pas de sens de navigation proposée, la solution la plus
rigoureuse constitue à mettre en place deux liens multivalués réciproque lesC1 et lesC2.
CREATE TYPE c1 AS OBJECT
(a Varchar(10) ) ;
CREATE TYPE pc1 AS OBJECT
(atpc1 Ref c1 ) ;
* 1..*
22.06.2005 60/78
C2
b

CREATE TYPE tpc1 AS TABLE OF pc1 ;
CREATE TYPE c2 AS OBJECT
(b Varchar(10) ,
LesC1 REF tpc1) ;
CREATE TYPE pc2 AS OBJECT
(atpc2 Ref c2 ) ;
CREATE TYPE tpc2 AS TABLE OF pc2 ;
CREATE OR REPLACE TYPE c1 AS OBJECT
(a Varchar(10) ,
LesC2 REF tpc2 ) ;
La traduction d’une cardinalité définie est simple a mettre en place avec un VARRAY sur
le lien a la place du TABLE
La solution universelle, soit l’utilisation d’une classe supplémentaire A et mise en place de
deux liens monovalués leC1 et leC2 n’est toujours pas acceptable si l’on tien compte de
la remarque sur le sens de navigation. De par la lourdeur des liens réciproques, nous
proposons plutôt la solution précédente pour une association N-N sans propriétés.
Transformation d’associations N-N avec propriétés
C1
a
Dans ce cas, l’utilisation d’une classe supplémentaire A et mise en place de deux liens
monovalués leC1 et leC2 vers les classes C1 et C2 parrait naturelle, mais elle ne permet
la navigation entre les classes qu'à partir de la classe association. Il est nécessaire de
traduire l’association en des attributs de collections (lien multivalués) dans chaque
classe.
Le diagramme ci dessous devrait être traduit avec le script DDL suivant
CREATE TYPE c1 AS OBJECT
(a Varchar(10) ) ;
CREATE TYPE c2 AS OBJECT
1..* 1..*
22.06.2005 61/78
A
c
b

(b Varchar(10) ),
CREATE TYPE a AS OBJECT
(c Varchar(10) ,
LeC1 REF c1 ,
LeC2 REF c2 ) ;
CREATE TYPE pa AS OBJECT
(atpa Ref a ) ;
CREATE TYPE tpa AS TABLE OF pa ;
CREATE OR REPLACE TYPE c1 AS OBJECT
(a Varchar(10) ,
LesA REF tpa) ;
CREATE OR REPLACE TYPE c2 AS OBJECT
(b Varchar(10) ,
LesA REF tpa) ;
Dans le cas de cardinalités définies, le script pourrait être quelque peu plus compliqué, si
les cardinalités n’étaient pas identiques.
Le modèle de classe UML nous permet de spécifié une association N-N avec (ou sans)
propriétés, mais ou on désire privilégier fortement un sens de navigation. On utilise pour
cela le cela le lien d'agrégation (symbole du diamant blanc).
C1
a
Cela nous fournit une variante de modèle intéressante ou le lien est représentée par la
structure A dans la classe C2 contient l’attribut c et le lien monovalué leC1 vers la classe
C1 qui représente une association. La classe C2 est rattachée à cette structure par le lien
multivalué lesA.
La structure contient :
• les attributs de l’association ;
• un lien monovalué vers la classe C1.
1..* 1..*
A
c
CREATE OR REPLACE TYPE c1 AS OBJECT
(a Varchar(10) ) ;
22.06.2005 62/78
C2
b

CREATE OR REPLACE TYPE A AS OBJECT
(c Varchar(10) ,
LeC1 REF c1 ) ;
CREATE OR REPLACE TYPE tc AS TABLE OF A ;
CREATE OR REPLACE TYPE c2 AS OBJECT
(b Varchar(10) ,
LesA tc ) ;
On voit la puissance de description du modèle de classe du langage UML.
La différentiation entre la composition (diamant noir) et l'agrégation (diamant blanc) est
alors évidente pour la transformation d une association N-N avec (ou sans) propriétés,
mais ou on désire privilégier fortement un sens de navigation.
C1
a
Le lien est représentée par la structure A dans la classe C2 contient l’attribut c et
l’attribut leC1 de classe C1. C’est cette fois une agrégation.
CREATE OR REPLACE TYPE c1 AS OBJECT
(a Varchar(10) ) ;
CREATE OR REPLACE TYPE A AS OBJECT
(c Varchar(10) ,
LeC1 c1 ) ;
CREATE OR REPLACE TYPE tc AS TABLE OF A ;
CREATE OR REPLACE TYPE c2 AS OBJECT
(b Varchar(10) ,
LesA tc ) ;
Transformation d’associations réflexives
Les associations réflexives peuvent être binaires ou n-aires. Il convient alors d’utiliser
une solution de transformation en fonction du type de l’association réflexive (1-1, 1-N, N-
N ou n-aire).
L’exemple traité ici est une transformation d’une association réflexive 1-N en raisonnant
sur une seule classe.
22.06.2005 63/78
C
a
0..*
1..* 1..1
A
c
1
C2
b

Ici en exemple, utilisation d’un lien multivalué lesC et un lien inverse leC.
CREATE TYPE c ;
CREATE TYPE tc AS OBJECT (ast REF c ) ;
CREATE OR REPLACE TYPE ttc AS TABLE OF tc;
CREATE OR REPLACE TYPE c AS OBJECT
(a Varchar(10) ,
LeC REF c , -- ou tc
LesC ttc ) ;
Création d’objets persistants
• En guise de rappel, pécisone encore ici qu’avec le modèle de Date et Darween, un
objet persistant ne peut exister que dans le contexte d’une table. Une table objet est
basé sur un type, le nom des colonnes de la tables est repris des attributs du type.
Chaque objet (ou tuple) possède un identificateur unique généré par le système
(OID) qui pourra être référencé par REF. Un objet persistant à donc deux partie
distincts, une référence, soit son OID, interrogeable par la fonction Ref() et une
valeur, correspondant à l’ensembles de ses attributs, interrogeable par la fonction
Value().
Contraintes déclaratives
Les contraintes déclarative doivent être placées sur les tables et non pas sur les types. A
noter que le modèle relationnel objet recouvre les différents contraintes du modèle
relationnel, soit :
• PRIMARY KEY
• FOREIGN KEY
• UNIQUE
• NOT NULL
• CHECK
La notion de PRIMARY KEY ne doit pas être confondue avec l’OID. Le modèle relationnel
objet propose enfin une solution élégante pour différentier formellement l’identificateur
de l’identifiant.
Nous préconisons donc d’utiliser l’OID comme identificateur unique d’objet persistant et
la contrainte PRIMARY KEY pour qualifié l’identifiant.
Dans ce cadre la notion de clé étrangère n’a pas lieu d’être puisque que la notion de
relation entre classe doit être assurée par des références d’objets. Le respect de
l’intégrité référentielle sur les référence est assuré par la clause SCOPE.
22.06.2005 64/78

Les clause UNIQUE et NOT NULL sont générées pour satisfaire les cardinalités, alors que
la clause CHECK doit être récupérée par les définitions OCL.
Exemple de création d’une classe persistante simple « tc1 »
CREATE TYPE c1 AS OBJECT
(att1 Varchar(7) ,
att2 Varchar(20) ) ;
CREATE TABLE tc1 OF c1 ;
ALTER TABLE tc1 ADD CONSTRAINT pk_tc1
PRIMARY KEY (att1) ;
ALTER TABLE tc1 MODIFY att2
ADD CONSTRAINT nn_att2 NOT NULL ;
Il aurait été possible de créer la table tc1 en une commande en intégrant la création de
la contrainte de clé primaire, directement dans la création de la table. La syntaxe
proposé est plus simple à gérée par un générateur, chaque information sémantique
générant une commande. A relever également que cette méthode est généralement
retenue dans le monde relationnel pour gérer l’ordonnancement des contraintes, les clés
primaires devant impérativement être créées avant les clés étrangères.
Dans le monde relationnel objet, l’intégralité étant géré par la clause SCOPE, cette règle
est un peu différente, puisque elle impose de gréer toutes les table dans une première
phase et de modifier celles qui contiennent une (ou plusieurs) références.
A noter également la mise de la contrainte NOT NULL sur un ordre de modification
d’attribut et non pas d’ajout de contrainte. Cette syntaxe est incontournable pour ce type
de contrainte, puisque celle ci est placée sur l’attribut et non pas sur la table. Les autres
types de contraintes peuvent être placée sur la table.
Exemple de transformation associations 1-N
Le premier exemple prend un sens de navigation unique
C1
a
b
22.06.2005 65/78
C
att1
att2
1 1..*
C2
c
d

L’association un à plusieur sera traduite en un lien simple monovalué, il en resultera deux
tables liées comme le schéma ci-dessous :
Création des types
TC1
OID attributs
22.06.2005 66/78
TC2
CREATE OR REPLACE TYPE c1 AS OBJECT
(a Varchar(5) ,
b Varchar(20) );
CREATE OR REPLACE TYPE c2 AS OBJECT
(c Varchar(5) ,
d Varchar(20) ,
leC1 REF c1 ) ;
Création des tables
CREATE TABLE tc1 OF c1
(CONSTRAINT pk_c1 PRIMARY KEY (a) ) ;
CREATE TABLE tc2 OF c2
(CONSTRAINT pk_c2 PRIMARY KEY (c) ,
lec1 SCOPE IS tc1 ) ;
OID attributs @tc1
La clause SCOPE limite les valeurs de lec1 dans les valeurs existantes d’ OID de c1.
Le second exemple utilise une navigation dans les deux sens, de manière explicite.
C1
a
b
1 1..*
C2
c
d

L’association un à plusieur sera traduite cette fois comme le schéma ci-dessous :
TC1
Création des types
OID attributs Tab_refs
Tab_@ref
CREATE TYPE c2 ;
Tab_@ref
22.06.2005 67/78
TC2
CREATE TYPE pc2 AS OBJECT (apc2 REF c2) ;
CREATE TYPE tpc2 AS TABLE OF pc2 ;
CREATE OR REPLACE TYPE c1 AS OBJECT
(a Varchar(5) ,
b Varchar(20) ,
lesC2 tpc2 ) ;
CREATE OR REPLACE TYPE c2 AS OBJECT
(c Varchar(5) ,
d Varchar(20) ,
leC1 REF c1 ) ;
OID attributs @ref
Type partiel
Type pointeur sur c2
Type tableau de pointeurs sur c2
Type c1 avec lesC2 tableau de
pointeurs sur c2
Type c2 avec leC1 pointeurs sur c1

Création des tables
CREATE TABLE tc1 OF c1
(CONSTRAINT pk_c1 PRIMARY KEY (a) )
NESTED TABLE lesc2 STORE AS stab_lesc2 ;
CREATE TABLE tc2 OF c2
(CONSTRAINT pk_c2 PRIMARY KEY (c) ,
lec1 SCOPE IS tc1 ) ;
ALTER TABLE stab_lesc2
ADD (SCOPE FOR (lesc2) IS tc2) ;
1.20.2. Règles OCL
1.20.3. Evaluation du mapping
La technologie relationnel objet est censé être un amalgame de l’objet et du relationnel
afin de garder le meilleur de ces philosophies. L’avantage d’utiliser cette technique est
que tous les objets (data row ou objet) persistants sont représentés dans la base de
données donc centralisé. En outre le ou les modèles persistant sont décrits à l’aide des
méta-données de la base de données, ce qui devrait permettre d’effectuer un mapping
automatique et donc de rendre la persistance objet transparente et facile à créer.
Dans notre projet le modèle relationnel-objet sera utilisé comme modèle de persistance
avec une approche descendante de l’application. Les tests ont été faites à l’aide d’une
base de données Oralce9i et met en application la partie théorique de ce document sur
les types « objet-relationnel Oracle9i» en outre elle utilise l’utilitaire Jpublisher afin de
créer le lien (mapping) entre l’objet et le relationnel.
Pour ce mapping nous utilisons les composant suivant :
• Type Oracles
• Table objet
• Type Java ou sqlj de mapping
L’idée de ce concept étant de créer des types objets représentant le modèle objet.
A l’aide de ces types nous allons créer une structure de table objet devant stocker les
données sous forme relationnelle objet.
Les Types Oracles vont aussi nous permettre de générer à l’aide de Jpublisher les class
Java du modèle objet persistant qui vont accéder aux tables objets pour manipuler les
données. Cette structure a comme caractéristique d’être très simple et de permettre de
stocker les données sous une forme plus proche de l’objet, Elle permet en outre
l’utilisation des règles d’intégrité référentielle.
Modèle Objet
Type Oracle
22.06.2005 68/78
Type Java
Table Objet
Implémentation de la
collection dans une
table imbriquée
Limitation des
valeurs des cellules
de la table
imbriquée dans les
OID existants de
tc1Type pointeur sur
c2
Transaction
JDBC
Approche
Descendante

Après avoir mis en place la composition de la structure, nous allons devoir représenter le
modèle objet en créant les types correspondant.
• Gestion des relations N (Collections vs tables de liaisons)
Pour la problématique concernant la transformation des cardinalités de type N, notre cas
exprime parfaitement les difficultés de transformation décrite dans ce document.
Après avoir essayé différentes structures hiérarchiques, les constations suivantes sont
apparues :
• La relation N-N transformé sous la forme de collection pour garder la double
navigabilité ne permettait pas l’utilisation de contrainte d’intégrité référentielle sur la
structure de collection proposée par Oracle.
• La relation N-N transformé sous la forme de collection pour garder la double
navigabilité était très difficile à gérer.
• La relations N-N sous la forme de collection faisant partie d’un sous-type contenu
dans une table objets de type super types nous ont fait créer des programmes
PL/SQL de manipulations de données très compliquées et complexe à mettre en
place, donc contre productif.
Ces constations pour la transformation des liaisons avec une cardinalité N nous ont fait
décider de ne pas utiliser les collections dans les tables objets et de mettre en place une
table de liaison contenant les référence. Ceci nous a permis d’utiliser les contraintes
d’intégrité référentielles et d’éviter de devoir gérer des collections qui comme vous l’avez
compris sont très problématique. La table de liaison aura des attributs représentant les
références des objets. Il aurait tout à fait été possible d’utiliser l’id généré des tables
pour faire cette liaison mais pour notre exemple nous avons pensé utiliser la manière la
plus objet possible.
• Composant et manipulation de données
Le choix de la table de liaison dans la gestion des relations de type N nous a en outre
imposée la manière de manipuler les données faisant partie de ces relations.
Pour ce faire nous avons utilisé les méthodes de type pour gérer la relation et renvoyer
les données correspondant à la relation par le biais variable de type collection. Ceci
présente l’avantage de ne pas utiliser de collections dans les structures et de tout de
même présenter au monde objet des composants respectant la philosophie objet.
La gestion de l’ajout et suppression de données sur la relation se faisant avec la même
philosophie. Voici la méthode que devra implémenter un type Oracle devant faire face à
une relation
Méthode renvoyant la liste d’objets de la liaison
Méthode ajoutant un objet à la liaison
Méthode supprimant un objet de la liaison
Pour toutes les autres manipulations de données nous pouvons utiliser la manière
standard c’est à dire des commandes sql qui manipulent les données directement des
tables objets depuis Java ou créer de méthode en capsulant les commandes SQL ce qui
nous ramènerait à la question si SQL est tolérable ou non au niveau de Java.
22.06.2005 69/78

Un des objectif de ce projet est de manipuler les données uniquement sous la forme
d’objets, donc la technique consiste à encapsuler les commandes SQL dans des méthodes
de types. Ceci aura comme conséquences :
• Le code SQL se trouvera en capsule dans le type Oracle, il deviendra un service objet
de la base de données réutilisable par plusieurs éléments.
• Le développeur Java n’écrit plus de SQL.
• La naissance d’un nouveau rôle pour le projet « application DB développeur Oracle ».
• Les queries doivent être développé par l’application DB développeur Oracle sur
demande.
• L’apparition de standard de développements de types Oracle pour les méthodes
Il faut donc que :
• Le type doit avoir une méthode STATIC s’appelant store()
• La méthode store doit renvoyer l’OID ou la référence base de données
• La méthode store doit s’occuper de la persistance dans la base de données dans tous
les cas de figure (Insert, Update)
• Une méthode STATIC pour la suppression doit exister.
Cette technique d’encapsulation peu avoir toutes les formes que l’on peut imaginer. Elle
peut par exemple être utiliser pour offrire au développeur des méthodes de queries
optimisée. Il faut cependant constater que la mise en place d’une telle technique
augmente le travail développement au niveau de la base de données et lie l’application
au niveau de la persistance à la Base de données Oracle.
Si vous ne désirez pas utiliser le méthode de type et l’encapsulation de commandes dans
les méthodes de types pour une raison ou pour une autre, il vous suffit d’utiliser les
commandes SQL dans le code Java (manière standard).
Une des caractéristiques de la manipulation de données relationnelles objets de manière
standard est que les commandes SQL sont simplifiées, puisque plusieurs termes sont à
disposition des développeurs (VALUE, REF,…) pour effectuer des insertions et
modifications des objets se trouvant dans la base de données sans devoir spécifier tous
les champs. Pour plus d’information il suffit de vous référer à la 1 ère partie de ce
document traitant des nouveautés sur les types relationnels objets.
Il faut cependant faire remarquer que les triggers INSTEAD OF ne sont plus utilisé dans
cette structure puisque nous n’utilisons pas de composant vues objets.
• Persistance d’une relation d’héritage
L’héritage à l’aide des tables objet peut être gérer de 2 manières différentes :
A l’aide 1 seul table de type du super-Types
Chaque type et sous-type sont stocké dans une table différentes
Pour notre exemples nous avons décidé d’utiliser la gestion à 1 seul table par hiérarchie.
Cette décision est intervenu puisqu’elle simplifiait la gestion des structures hiérarchique
en outre, il est intéressant de pouvoir tester ces nouvelles fonctionnalité dans ce
domaine de la base de données.
Type1
Type2 Type3
Génère
22.06.2005 70/78
Table container de
type1, type2 et
type3

Cette manière de gérer l’héritage aura un impact sur la gestion des relations N-N des
sous-types se trouvant dans la table container avec d’autres tables.
Comme nous l’avons déjà dis, nous gérons les relations sous forme de références dans
des tables de liaisons. Par définition nous voulons que les références soit des références
du type impliqué dans la relation et pas de son super type.
Cependant comme le container est du type super type (comme décidé précédemment) le
type de l’attribut appartenant à la table de liaison ne peut être que du type super type,
ceci afin de pouvoir mettre en place une contrainte d’intégrité référentielle (FK) pour
gérer la relation dans la table de liaison. Il faudrait donc pouvoir mettre en place une
restriction de substitution à l’aide de la commande IS OF sur l’attribut. Ceci n’étant pas
applicable au type REF, il nous faut gérer cette situation à l’aide d’un trigger Before
Insert sur la table de liaison donc par programmation.
1.20.3.1. Constatations sur les outils de manipulations
de composants R.O.
• Problématique de manipulation des composants
Après nos tests il est apparu que l’utilisation des types et des composants relationnels
objets mis à disposition par Oracle était très instable. C’est pourquoi le stockage de
données dans une structure de tables relationnel objet ne serait pas judicieux et pas
fiable. Cette fonction offerte par la base de données a bien évolué depuis sa première
version mais beaucoup de travail reste à faire afin que tous les problèmes soit corrigé.
C’est pourquoi, nous conseillons l’utilisation des types pour la construction de vues
relationnels objets et l’utilisation d’une structure relationnelle standard pour la
sauvegarde des données. Cette stratégie va nous permettre d’obtenir les fonctionnalités
objets au travers des types et de pouvoir garantir la pérennité des données.
Les problèmes suivants sont à prendre en compte lors de la création des structures et de
leur maintenance sous peine de devoir régénérer à chaque manipulation des structures
relationnelles objets de la base de données, ce qui dans le cadre du stockage de données
sous forme de table serait un gros risque :
• Doublage de méthodes :
Le nombre de méthode double sur le type lorsque la commande Alter type add attribut
est utilisé.
Solution : créer les méthodes après que tous les attributs soit ajouté
• Perte d’attribut :
Les types ayant comme attribut unique une référence sur un autre type perde l’attribut
après la manipulation de du type référencé avec la commande ALTER type.
Solution : créer ces types ayant l’attribut après la dernière manipulation du type en
question.
• Plusieurs niveau de collections :
22.06.2005 71/78

L’utilisation d’une collection de type référence d’un type direct (Exemple REF Type1)
comme attribut d’un type ne permet pas à l’utilitaire JPublisher de générer le class
correspondante en Java.
Solution : créer un type intermédiaire ayant un attribut de type référence du type
correspondant.
• Non-héritage de méthodes :
Dans une relation d’héritage lorsque nous créons les méthodes des super-types à l’aide
de la commande ALTER type donc après la structure d’héritage et qu’un sous-type n’a
pas eu besoin d’ajout de méthode il n’hérite d'aucune méthode.
Solution : Créer le type après que les super-types soit complet.
• Dépendance cyclique des paramètres de méthode :
Lors de la conception de méthode d’encapsulation pour la gestion des relations N-N il a
été impossible d'utiliser un paramètre de fonction ou procédure de type "type oracle"
sous la forme cyclique. Puisque lorsqu’un Type que nous appellerons TY1 à une méthode
dont le paramètre est d'un type TY2 et que le type TY2 a une méthode ayant un
paramètre de type TY1, la base de données Oracle interprète cela comme une
dépendance cyclique et émet une erreur ORA. Il conseille alors d'utiliser le type REF pour
casser ce cycle. Cependant lorsque cette solution est mise en place il y une erreur interne
ORA du moteur la base de données il est donc impossible de mettre en place une
stratégie complètement objet.
Solution : Elle consiste à utiliser l'id créer pour identifier uniquement comme (C.f
paragraphe suivant Identification objet), comme il est de type numérique cela interrompt
la dépendance cyclique et nous pouvons mettre en place la stratégie désirée.
• Problématique de l’identification d’objet
Lors de la conception des différentes structures base de données avec une pensée objets
nous avons cru qu’il était possible d’implémenter complètement le paradigme objet.
Nous avons été déçus de voir que ce principe était impossible à réaliser :
« Tout objet est identifié uniquement » .
Au début des tests nous pensions que l’identification d’un objet aurait été prise en main
par la base de données Oracle. OID devant remplir ce rôle.
Après quelques essais nous avons très vite abandonné cette idée et nos avons décidé de
mettre en place une clé primaire unique générée par une séquence base de données
(gestion standard de l’unicité des clés).
Cette décision à été prise après avoir remarqué qu’il était impossible d’obtenir une
référence base de données sans utiliser la commande « select ref(x)…. ».
La situation qui nous a posé problème était la suivante :
• Demander à l’objet sa propre référence (OID ) afin d’accéder d’autres objets ou il
était référencé
Comme nous n’avions de clé primaire et qu’il était impossible d’utiliser la commande
« select » pour identifier l’objet de façon certaine, nous avons exploré d’autres solutions
qui n’ont pas donné le résultat escompter.
Les solutions essayées sont les suivantes :
• Création d’une méthode membre revoyant avec la commande SELF la référence de
l’objet. SELF étant un paramètre représentant l’objet et pas sa référence ceci est
impossible
• Recherche dans les tables system pour trouver l’OID. Trop long et impossible à
réaliser
22.06.2005 72/78

• Recherche d’une fonction fournie par Oracle pour faire ce travail. Ceci était Inexistant
• Support Oracle. Incompétent dans ce domaine
Nous espérons qu’Oracle fournira une telle fonctionnalité dans le futur. Ceci serait la
dernière étape vers l’implantation du concept objet. En attendant nous conseillons
l’utilisation des clés primaires générées pour identifier uniquement les objets. Ceci ne
signifie pas que les relations ne peuvent pas être sous la forme de référence mais que
l’objet est identifié par un attribut identifiant pour pouvoir le retrouver à tout moment
dans la base de données.
Transformation des règles OCL
La transformation des règles OCL en trigger ou en contraintes déclaratives dans un schéma
relationnel-objet Oracle 9i sera une des tâches importantes de la phase 2 du projet.
Nous présentons ci-dessous une exemple simple de ce qu’il sera possible de faire avec le
générateur en guise d’amuse-bouche.
A partir d’une contrainte OCL et d’une classe UML, nous générerons un fichier XMI avec
Poseidon for UML
context Article inv :
prix > 0.0
Le contenu de ce fichier XMI sera analysé par le générateur et produira les deux scripts SQL-
DDL suivants :
• Script de création des types
CREATE TYPE ty_article AS OBJECT
(numero Number(9) ,
prix Number(5.2) );
• Script de création des tables
CREATE TABLE article OF ty_article
CONSTRAINT pk_article PRIMARY KEY (numero) ) ;
ALTER TABLE article ADD CONSTRAINT ch_pric
CHECK (prix > 0.0);
1.21. Annexes
1.21.1. Scripts DDL du modèle exemple
1.21.1.1. Création des types
22.06.2005 73/78

-- Creation de la base exemple
DROP TYPE ty_stockitem FORCE ;
DROP TYPE ty_ligItem FORCE ;
DROP TYPE ty_Lis_ligItem FORCE ;
DROP TYPE ty_lis_telephone FORCE ;
DROP TYPE ty_addresse FORCE ;
DROP TYPE ty_genre FORCE ;
DROP TYPE ty_client FORCE ;
DROP TYPE ty_personne FORCE ;
DROP TYPE ty_entreprise FORCE ;
DROP TYPE ty_commande FORCE ;
------------------------------------
CREATE TYPE ty_StockItem AS OBJECT (
numStock Number,
Prix Number,
Taxe Number
);
/
CREATE TYPE ty_ligItem AS OBJECT (
numligitem Number,
ref_stock REF ty_StockItem,
Quantite Number,
Rabais Number
);
/
CREATE TYPE ty_Lis_ligItem AS TABLE OF ty_LigItem;
/
CREATE TYPE ty_lis_telephone AS VARRAY(3) OF Varchar2(20);
/
CREATE TYPE ty_addresse AS OBJECT (
Rue Varchar2(200),
Ville Varchar2(200),
Canton Char(2),
code Varchar2(20)
)
/
CREATE TYPE ty_genre AS OBJECT (
genre Varchar2(200)
)
/
CREATE TYPE ty_client AS OBJECT (
numclient Number,
nomclient Varchar2(200),
addresse ty_Addresse,
lis_telephone ty_lis_telephone
)
NOT INSTANTIABLE
NOT FINAL;
/
22.06.2005 74/78

CREATE TYPE ty_personne UNDER ty_client (
ref_genre REF ty_genre
)
INSTANTIABLE
FINAL;
/
CREATE TYPE ty_entreprise UNDER ty_client (
chiffreaffaire Number
)
INSTANTIABLE
FINAL;
/
CREATE TYPE ty_commande AUTHID CURRENT_USER AS OBJECT (
numcom Number,
ref_client REF ty_client,
Date_commande Date,
Date_livraison Date,
tab_LigItem ty_lis_ligitem,
addresse_livraison ty_Addresse
);
/
1.21.1.2. Création des tables
-- Creation de la base exemple
------------------------------------
CREATE TABLE to_genre OF ty_genre
OBJECT IDENTIFIER IS SYSTEM GENERATED ;
CREATE TABLE to_stockitem OF ty_StockItem
( numStock PRIMARY KEY)
OBJECT IDENTIFIER IS PRIMARY KEY ;
CREATE TABLE to_client OF ty_client
( numclient PRIMARY KEY)
OBJECT IDENTIFIER IS PRIMARY KEY ;
CREATE TABLE to_commande OF ty_commande (
PRIMARY KEY (numcom),
FOREIGN KEY (ref_client) REFERENCES to_client)
OBJECT IDENTIFIER IS PRIMARY KEY
NESTED TABLE tab_ligItem STORE AS PoLine_ntab (
(PRIMARY KEY(NESTED_TABLE_ID, numligitem))
ORGANIZATION INDEX COMPRESS)
RETURN AS LOCATOR
/
ALTER TABLE poline_ntab
ADD (SCOPE FOR (ref_stock) IS to_stockitem ) ;
22.06.2005 75/78

1.21.1.3. Exemple de peuplement pour tests
---Nécéssite la version 9.2
-- Ne fonctionne pas en 9.0 !!------
-- Table to_genre
INSERT INTO to_genre VALUES ('Féminin');
INSERT INTO to_genre VALUES ('Masculin');
-- Table to_stockitem
INSERT INTO to_stockitem VALUES(1004, 6750.00, 2) ;
INSERT INTO to_stockitem VALUES(1011, 4500.23, 2) ;
INSERT INTO to_stockitem VALUES(1534, 2234.00, 2) ;
INSERT INTO to_stockitem VALUES(1535, 3456.23, 2) ;
-- Table to_client
---- Personne
INSERT INTO to_client
SELECT ty_personne( 1,
'Jean Nance',
ty_Addresse('2 Pommiers',
'Neuchâtel',
'NE',
'2000'),
ty_lis_telephone('032/234.23.12'),
Ref(g)
)
FROM to_genre g
WHERE genre = 'Masculin' ;
---- Entreprise
INSERT INTO to_client
VALUES (ty_entreprise( 2,
'Edison',
ty_Addresse('3 Zone industrielle',
'La Chaux-de-Fonds',
'NE',
'2300'),
ty_lis_telephone('032/226.12.23','032/121.65.32'),
120
)
) ;
--------------------
INSERT INTO to_commande
SELECT 1001,
REF(cli),
SYSDATE,
To_date('11-09-2003','DD-MM-YYYY'),
ty_lis_ligitem(),
NULL
FROM to_client cli
WHERE cli.numclient = 1 ;
22.06.2005 76/78

INSERT INTO TABLE (
SELECT c.tab_ligitem
FROM to_commande c
WHERE c.numcom = 1001
)
SELECT 01,
REF(S),
12,
0
FROM to_stockitem S
WHERE S.numStock = 1534 ;
INSERT INTO TABLE (
SELECT c.tab_ligitem
FROM to_commande c
WHERE c.numcom = 1001)
VALUES (01,null,12,0);
-- OK
DELETE FROM TABLE (
SELECT c.tab_ligitem
FROM to_commande c
WHERE c.numcom = 1001)
WHERE numligitem = 1 ;
*/
----
INSERT INTO to_commande
SELECT 2001,
REF(cli),
SYSDATE,
To_date('20-05-2003','DD-MM-YYYY'),
ty_lis_ligitem(),
ty_Addresse('3 Zone industrielle',
'La Chaux-de-Fonds',
'NE',
'2300')
FROM to_client cli
WHERE cli.numclient = 2 ;
INSERT INTO TABLE (
SELECT c.tab_ligitem
FROM to_commande c
WHERE c.numcom = 1001
)
SELECT 02,
REF(S),
10,
10
FROM to_stockitem S
WHERE S.numStock = 1535 ;
INSERT INTO TABLE (
SELECT c.tab_ligitem
FROM to_commande c
WHERE c.numcom = 2001
22.06.2005 77/78

)
SELECT 10,
REF(S),
1,
0
FROM to_stockitem S
WHERE S.numStock = 1004 ;
-- Autre syntaxe, meilleur
INSERT INTO TABLE (
SELECT c.tab_ligitem
FROM to_commande c
WHERE c.numcom = 2001
)
VALUES (11,
(SELECT REF(S)
FROM to_stockitem S
WHERE S.numStock = 1011) ,
2,
1 ) ;
COMMIT ;
22.06.2005 78/78