Allier Relations et Objets pour Modliser Participants C
Allier Relations et Objets pour Modéliser Participants C. Bruley, P. Genoud, J. Gensel, M. Maume, M. Page, D. Ziébelin Présentation Sherpa du 05/01/99 1
Plan l Motivations l Présentation des concepts de base d'AROM l Etat actuel d'AROM l Perspectives 2
Motivations l Modélisation et simulation de systèmes dynamiques: 1) Nécessité d'introduire des relations dans les SRCO 2) Temporalité 3) Langage de modélisation algébrique l Cet exposé se focalise sur le 1 er point 3
Pourquoi des relations ? l La plupart des méthodes de modélisation de données reconnaissent l'existence de 2 types d'information: l entités: décrivent les objets du domaine modélisé l relations: décrivent les liens entre ces objets entité-association, OMT, UML, … 4
Mise en œuvre des modèles de données • Peu de logiciels mettent en œuvre entités et relations • Exception: ILOG Power Classes 5
Relations dans les SRCO l 2 représentations fréquentes: l sous forme d’attribut-lien l sous forme de classes 6
Relations sous forme d’attribut-lien classe EMPLOYES numéro: entier nom: chaîne prénom: chaîne service: SERVICES classe SERVICES nom: chaîne adresse: chaîne employés: liste-de EMPLOYES • Certains SRCO (YAFOOL, SMECI) maintiennent la cohérence des relations bien adapté aux relations binaires sans attribut 7
Pbs des relations par attribut-lien • On veut mémoriser les différents services dans lesquels a travaillé chaque employé avec la date d'entrée classe EMPLOYES numéro: entier nom: chaîne prénom: chaîne services: ? ? ? classe SERVICES nom: chaîne adresse: chaîne employés: ? ? ? • Extensibilité ? ? ? • Maintien de la cohérence de la relation ? ? ? 8
Relations sous forme de classes • Idée: 1 relation = 1 classe EMPLOYES classe TRAVAILLE classe SERVICES numéro: entier employé: EMPLOYES nom: chaîne service: SERVICES adresse: chaîne prénom: chaîne date_entrée: date employés: listeservices: liste-de de TRAVAILLE • Généralisable aux relations d'arité > 2 9
Pbs des relations sous forme de classes l Impossible de séparer la sémantique des objets et celle des relations l exemples: • la spécialisation des relations devrait avoir une sémantique différente de celle des classes – on ne peut pas spécialiser une relation en ajoutant un rôle • le type d'un attribut pour un objet n'est pas de même nature que celui pour un attribut de relation l Impossible de séparer les opérations applicables aux objets et celles applicables aux relations l exemple: sens de la composition pour les relations ? ? ? 10
Notre proposition Séparer les objets et les relations représentation explicite des relations 11
Les concepts d’AROM l On distingue 2 niveaux distincts ® Le noyau : AROM min 12
Les concepts d’AROM ® AROM 13
Les concepts d’AROM min Une base de connaissances AROM comporte l des classes et leurs instances l des relations et leurs tuples Les classes sont organisées en hiérarchies de spécialisation… de même que les relations mais ces spécialisations n’obéissent pas aux mêmes règles L’héritage est simple en AROM 14
Classe dans AROM Une classe décrit un ensemble d'objets qui ont des propriétés, des contraintes et un comportement communs Une classe est décrite par son nom, sa super-classe et une liste de propriétés (variables) Une variable est décrite à l’aide de facettes – de typage (type, domain) – de documentation (documentation, unit) – d’inférence (default, method) 15
Typage des variables Le type d’une variable : - prédéfini (entier, réel, …) avec la possibilité d’utiliser les constructeurs set-of et list-of - défini à l’aide du système de types (en cours) Pas de variable dont la valeur est un objet pas de lien vers d’autre(s) instance(s) Si un tel lien doit être représenté, il le sera à travers une relation 16
Une hiérarchie de classes AROM class: EMPLOYES super-class: variable: NOSS type: string documentation: "n° de SS de l’employé" variable: nom type: string documentation: "nom de l’employé" variable: PRENOM type: string documentation: "prénom de l’employé" variable: NB_HEURES type: integer domain: [0. . 1000] default: 169 variable: SALAIRE type: float 17
Une hiérarchie de classes AROM class: CADRES super-class: EMPLOYES variables: variable: PRIME type: boolean class: NON_CADRES super-class: EMPLOYES 18
Instance dans AROM Une instance est attachée à une classe et une seule (en attendant les points de vue…) et possède un idf unique Les liens ne sont pas mémorisés au niveau des instances Exemple : instance: E 1 is-a: EMPLOYES NOSS = "1620251454005" NOM = "DUPONT" PRENOM = "Pierre" NB_HEURES = 180 SALAIRE = 9798. 0 19
Relation dans AROM Une relation représente une liaison entre des instances de deux classes ou plus non nécessairement distinctes Elle définit un sous-ensemble du produit cartésien des classes reliées Une relation est décrite par des rôles et éventuellement par des variables • Un rôle représente un accès nommé à une des instances impliquées dans la relation • Une variable de relation est une propriété de la relation 20
Relation dans AROM Une instance de relation n-aire comporte : - les valeurs des n rôles correspondant aux n instances des n classes liées par la relation : un tuple - les valeurs des variables de la relation A chaque rôle est associé une cardinalité La card max du rôle ri dans une relation R sur les classes C 1, C 2, . . . , Cn, est le nombre max de fois qu'une instance donnée de Ci peut apparaître comme valeur du rôle ri dans les tuples de R 21
Spécialisation de relations Les relations peuvent être structurées en hiérarchies de spécialisation On parlera (s’ ) de super-relation et de sous-relations Spécialisation d’une relation: - ajout d’une variable - affinement d’ une variable - affinement de rôle (restriction de cardinalité, soustypage) … MAIS pas d’ajout de rôles !!! 22
Exemple de hiérarchie de relations 23
Exemple de relation: TRAVAILLE documentation: "décrit dans quel service travaille chaque employé" roles: role: EMPLOYE type: EMPLOYES card: [0. . 10] // un employe travaille dans de 0 à 10 services role: SERVICE type: SERVICES card: [0. . 1000] // un service emploie de 0 à 1000 employés variable: DATE_ENTREE type: string 24
Exemple de tuple: TRAVAILLE employé = JUJU // JUJU est le nom d'une instance d'EMPLOYES service = INFO // INFO est le nom d'une instance de SERVICES 25
Etat actuel d'AROM l Implémentation partielle d'AROM min version 0. 1 l l pas implémentés mais prévus: l l API Java de création et gestion de BC AROM langage de représentation de connaissances interface graphique élémentaire points de vue, composition, attachement procédural, types extensibles, algos d'inférence: classification, valeur par défaut, . . . Utilisation en cours: l transfert d'une partie de la BC de MYOSIS 26
Perspectives à court terme Dans la pile des travaux 1 er semestre 1999 l l l stabilisation du noyau système de types à la METEO mécanismes d’inférence : valeur par défaut, classification, attachement procédural. . . éditeur de graphe à la OMT interface BD pour stockage de relations et tuples 27
Perspectives à court terme Utilisations d’AROM min l l modèle de tâches (MYOSIS, ESTEEM) modèle de composants (Génie II) Nécessité d’introduire l l points de vue (Génie II) relation de composition 28
Perspectives à moyen terme l Arom l l Langage algébrique : requêtes + contraintes + systèmes d’équations classes et relations temporelles (simulation de systèmes dynamiques) 29
Le site Web d’AROM http: //kurikala. inrialpes. fr/private/index. html 30
Et pour finir BONNE et HEUREUSE ANNEE 1999 !!! 31
- Slides: 31