14 déc 2000 Samovar : un modèle pour les objets persistants avec rôles Stéphane Coulondre LIRMM...

14 déc 2000

Samovar : un modèle pour les objets persistants avec rôles

Stéphane Coulondre

LIRMM / Université Montpellier II

14 déc 2000 Samovar : un modèle pour les objets persistants avec rôles

2/46

Contexte

Les modèles de bases de données (BD) à objets :

Object-Oriented Manifesto ODMG : standardisation

Contexte : Evolution dans les BD à objets

Système à objets Système de gestion de BD

SGBD à objets


3/46

Travaux sur l’évolution : évolution de schéma, migration d’instances, etc. versionnement, vues, etc.

Aspect abordé ici : évolution de (structure + comportement = rôle) d’un objet

Contexte


4/46

I. Problèmes et objectifsII. Eléments de solutionIII. Détails de la propositionIV. ApplicationsV. ValidationVI. Travaux relatifsVII. Conclusion et perspectives

Plan


5/46

La notion de rôle est naturelle : dans la langue, dans les Systèmes d’Informations modélisation d’une entité évolutive

I. Problèmes et objectifs


6/46

modélisation d’entités sous divers aspects (génie civil, gestion, électronique, informatique géographique, etc.)

Un pont ?

et informations communes

Pour la mairie Pour le géomètre Pour l’architecte Pour l’entrepreneur



7/46

Il faut donc : prendre en compte l’évolution des entités en termes de

gain et de perte de rôles prendre en compte la pluralité des rôles (aspects,

facettes, points de vue, etc.)

Pourquoi cette étude : adaptation des SI au monde réel ODMG : choix entre robustesse/souplesse souplesse nécessaire pour des impératifs techniques,

scientifiques, financiers



8/46

Principes inviolables et nécessaires du modèle ODMG :

caractéristiques de robustesse et d’expressivité :objets complexes, identité d’objet, encapsulation, types et classes,héritage, redéfinition de méthodes et liaison dynamique, typage statique et fort, complétude d’un langage, etc.

caractéristiques relevant du stockage et du traitement :persistance orthogonale, langage de requêtes, etc.



9/46


Forte incompatibilité entre : pluralité de {type, comportement} et mono-

instanciation évolution dynamique et typage statique et fort

Solutions ad-hoc, mais incompatibilité entre : handles et identité d’objet

problèmes de référencement, complexité utilisateur héritage multiple et évolution dynamique

un seul contexte d’observation


10/46

But de la thèse :un modèle de SGBD à objets, extension d’ODMG, gérant les rôles de la façon la plus inhérente, sûre et intuitive possible

respectant l’intégrité de l’objet lui permettant de jouer plusieurs rôles permettant l’évolution dynamique


Valeurs&

Méthodes

Valeurs&

MéthodesValeurs

&Méthodes

Valeurs&

Méthodes

Valeurs&

Méthodes

Valeurs&

Méthodes

Valeurs&

Méthodes

Valeurs&

Méthodes


11/46

Contributions :

modèle formel de données (aspect déclaratif) langages de définition, de requêtes, de programmation

et mécanismes associés prototype de SGBD



12/46

Autres propositions


Représentation des connaissances

Langages de programmation

SI et bases de données Rôle

s


13/46

I. Problèmes et objectifsII. Elements de solutionIII. Détails de la propositionIV. ApplicationsV. ValidationVI. Travaux relatifsVII. Conclusion et perspectives

Plan


14/46

II. Eléments de solution

Réflexion de base : la classe et la mono-instanciation sont nécessaires

robustesse, optimisation, cohérence conceptuelle

aspects trop restrictifs pour l’évolution : un seul rôle

un objet un rôle une classe

Proposition :

un objet plusieurs rôles une classe


15/46

Classes nom pas de type ni de méthode ensemble de rôles

Rôle descripteur un type un comportement organisés en hiérarchie

II. Eléments de solutionHiérarchies


16/46



17/46

Hiérarchie de rôles au sein d’une classe aucune contrainte sur le type des rôles aucune contrainte sur les signatures de méthodes

indépendance des rôles

Hiérarchie de classessémantique du lien de spécialisation entre classes

« revisitée » héritage et extension des hiérarchies de rôles contraintes de sous-typage entre rôles de même identificateur spécialisation covariante des signatures de méthodes



18/46

Avantages de la double hiérarchisation :

rôles potentiels facilement identifiables rôles spécialisables dans les sous-classes

rôles adaptés à la nature des objets

pas de confusion entre modèles abstraits classes et rôles



19/46

Mais : niveau de complexité utilisateur supplémentaire

Solution originale : rôle identifié par une assertion logique : le critère de

définition modélisation entièrement déclarative :

factorisation et partage de propriétés implicite/explicitecontraintes de simultanéité implicites/explicites

implication logique ordre partiel hiérarchie de rôles induite

potentiel applicatif intéressant...



20/46

Un objet est instance d’une classe identifiant unique possède un critère courant

ce critère détermine le sous-ensemble des rôles que l’objet joue

peut gagner ou perdre dynamiquement des rôles

II. Eléments de solutionInstances


21/46

II. Eléments de solutionInstances


22/46

Une vue sur un objet but de confidentialité ou de visibilité volontaire permet d’agir comme un filtre sur les rôles joués par un

objet définie par l’utilisateur (non le concepteur), de manière

déclarative peut être persistante

II. Eléments de solutionVues


23/46



24/46

Différences avec l ’ODMG double hiérarchisation et spécialisation revisitée déclarativité objets évolutifs

Différences avec la notion classique de vues en objets pas de données calculées se rapporte à un seul objet vue objet (à des collections) est une valeur dans la base vue objet (niveau schéma) modifiable dynamiquement vue objet (recalculée mais

non modifiée)



25/46


Plan


26/46

III. Détails de la proposition

Modèle de données formel incorporant les notions précédentes langages de définition de données extension d’O2 ODL

exemples de critère de définition :

Descripteur Critère correspondantCitoyen statut(citoyen)Salarié statut(citoyen)

et statut(salarié)EtudiantSalarié statut(citoyen)

et statut(étudiant)et statut(salarié)

Commun vrai


27/46

Mécanismes communs aux langages accès aux attributs et envoi de messages

en spécifiant un ou des rôles par l’intermédiaire d’un critère d’accès <> critère courant

détermine de manière déclarative les rôles concernés

envoi de messages avec liaison statique ou dynamique

III. Détails de la proposition Mécanismes communs aux langages


28/46

III. Détails de la propositionEnvoi de messages


29/46

Langage de requêtes VOQL

extension d’ODMG OQL syntaxe et sémantique formelle sécurisation des requêtes

exemple de requête dans le calcul :

exemple VOQL :SELECT x FROM x in Tout WHERE ROLES(x, état (physique))->poids < 65000


}65000))(,x(Toutx{x EntitéEntitéEntité poidsphysiqueétat


30/46

Langage de programmation VOPL

extension d’O2 O2C syntaxe et sémantique formelle

spécificités par rapport à VOQL : modification des racines de persistances instanciation ajout et suppression de rôle auto référence (dans les méthodes)



31/46


Plan


32/46

IV. Applications

Application à la sécurité Modélisation possible de

droits par identité droits par niveau droits temporels

différence fondamentale : droits non révocables

exemple de critère de définition :

infos(medicales) et niveau(N) et N>=8 et jour(J) et J<>vendredi

exemple de critère d’accès :

infos(medicales) et niveau(9) et jour(mardi)


33/46

Simulation du versionnement de schémaexemple de critère de définition:

date(D) et D>14/12/1999 et D<14/12/2000

exemple de critère d ’accès : date(18/01/2000)

cohabitation de plusieurs versions versionnement alternatif et/ou temporel réversibilité travaux en cours avec l’Université de Bologne

IV. Applications


34/46

Diffusion de composants logiciels

même composant selon un point de vue particulier (ex. composants de gestion pour différents métiers)

exemple de critère de définition :module(paie) et métier(santé) et spécialité(ambulancier)

versions pouvant cohabiter au sein d’un composantexemple de critère de définition :

version(2) et sousversion(3) et statut(beta)

travaux en cours dans l ’équipe

IV. Applications


35/46

Application à la multi-représentation un élément admet plusieurs représentations

exemple : un pont

1/1000 échelle(E) et E>=1/1000

1/10000 échelle(E) et E>=1/10000 et E<1/1000

1/100000 échelle(E) et E>=1/100000 et E<1/10000

exemple de critère d ’accès : échelle(1/5000)

travaux en cours avec l’Université de Nottingham

IV. Applications


36/46


Plan


37/46

Prototype de SGBD Objet avec rôles : Samovar en C++, O2C et Java architecture client/serveur

Construit au dessus d’O2 mais : système de types différent notions de classe, d’héritage, et mécanismes d’accès et

d’envoi de messages différents

Documentation utilisateur Ensemble d’exemples en VODL, VOPL et VOQL

V. Validation


38/46

V. Validation

Hiérarchie de classes

Hiérarchie de rôles de la

classe

Type associé au rôle

Méthodes associées au

rôle


39/46


Plan


40/46

VI. Travaux relatifs

Approches marquantes relevant des langages (Pas d’aspects SGBD)

Clovers (1989) [Stein et Zdonik] Multiple Views (1989) [Shilling et Sweeney]

ROME (1989, 90) [Carré][Carré et Geib]

Objets morcelés (1996) [Bardou et Dony]

} Typage dynamique

Pas de liaison dynamique}

} Pas d’évolution


41/46


Approches relevant des bases de données

Iris (1987) [Fishman et al.] Aspects (1991) [Richardson et Schwarz] Fibonacci (1993, 95) [Albano et al.]

IQL(2) (1995) [Abiteboul et Dos Santos]

Extended Smalltalk (1996) [Gottlob et al]

ORM (1997) [Papazoglou et Krämer] DOOR (1997) [Wong et al.]

} Comportement global

} Classes non hiérarchiséesLiaison dynamique

empirique} Liaison dynamique possible sur les schémas “stricts”} Pas d’unicité d’OID

Pas de liaison dynamique

} Pas de liaison dynamique

} Liaison dynamique ?

} Pas d’unicité d’OID


42/46

Samovar fournit, en plus du respect de l’ODMG

une synthèse des apports l’héritage multiple (rôles et classes) : présent dans DOOR les vues : présentes dans IQL(2) mais notion classique double hiérarchisation : présente dans Extended Smalltalk

et DOOR

l’aspect original de la déclarativité applications à de nombreuses situations



43/46


Plan


44/46

VII. Conclusion

Objectif atteint

ODMG respecté : robustesse nécessaire pour la migration des bases existantes

La fonctionnalité d’évolution est inhérente Application à diverses problématiques Prototype en-ligne implantant :

le modèle de données et son langage de définition les langages de programmation et de requêtes, et les

mécanismes mis en jeu


45/46

Niveau Modèle

Contraintes rôles exclusifs et plus généralement contraintes

d’intégritéexemple : employé et chômeur

masquage/encapsulation de rôles ?

Raccourcis syntaxiques des critères, inférences ? Versionnement de l’état des objets

VII. Conclusion - Perspectives

Perspectives


46/46

Niveau réalisation

Prototype application idéal : un SGBD open-source (-DB ?) implantation dans un langage de programmation

Travaux en cours multi-représentation versionnement de schéma composants logiciels

VII. Conclusion - Perspectives

14 déc 2000 Samovar : un modèle pour les objets persistants avec rôles Stéphane Coulondre LIRMM...

Documents

Transcript of 14 déc 2000 Samovar : un modèle pour les objets persistants avec rôles Stéphane Coulondre LIRMM...