View
106
Download
2
Category
Preview:
Citation preview
Bases de données orientées-objetsBases de données orientées-objets1. L ’approche objet1. L ’approche objet
Rappel
Yves PigneurStéphane Rey
Ecole des HECUniversité de Lausanne
CH-1015 Lausanneyves.pigneur@hec.unil.ch
(+41 21) 692.3416
HEC Lausanne - 19992
Agenda
• Introduction à l'approche objet:– objectifs de l'approche objet;– décomposition rapide des objets;– ...
• Classes d'objets:– instances de classes;– méthodes;– messages;– surcharge et polymorphisme;– ...
• Héritage:– redéfinition;– visibilité;– ...
• Identités d'objets
HEC Lausanne - 19993
Références pour en savoir plus
• Mokrane Boutzeghoub, Georges Gardarin, Patrick Valduriez, "Les Objets", Eyrolles, 1998, 450 pages;
• R. Cattell, "Bases de données orientées objets", Thomson Publishing, 1997, 395pages;
• Georges Gardarin, "Bases de données objet & relationnel", Eyrolles, 1999, 780 pages.
HEC Lausanne - 19994
Typographie
• Cette ligne est un exemple pour illustrer du texte standard.
• Cette ligne est un exemple pour illustrer du code Java.
• Cette ligne est un exemple pour illustrer du pseudo-code ou toute autre code non Java.
• Les termes anglais apparaissent en italique (sauf dans le code).
HEC Lausanne - 19995
Introduction à l'approche objet
• L'objet est la notion centrale de l'approche objet.• L'objet associe traitements (méthodes) et données dans une même entité.• L'interface est le seul moyen d'accéder à l'objet, par l'envoi de messages.
• "Abstraction informatique d'une entité du monde réel caractérisée par une identité, un état et un comportement." [Gardarin, "Bases de Données objets & relationnel", Eyrolles, 1999]
MéthodeMéthode
MéthodeMéthode
MéthodeMéthodeInterface
MéthodeMéthode
MéthodeMéthode
DonnéesDonnées
Objet
Messages
HEC Lausanne - 19996
Objectifs de l'approche objet
• Modéliser directement les entités du monde réel, sans les déformer ou/et les décomposer;
• réutiliser le code existant, à partir de bibliothèques spécialisées:– les objets facilitent la modularisation (encapsulation);– les classes améliorent la gestion des objets (modèle);– l'héritage supporte la gestion des classes (hiérarchie);
• permettre la création rapide d'interfaces homme/machine graphique capables de réagir à tout événement extérieur (clavier, clic souris, etc.);
• faciliter le prototypage rapide des applications;
• faciliter l'exploitation du parallélisme sur des machines multiprocesseurs et/ou distribuées.
HEC Lausanne - 19997
Décomposition rapide des objets
• Objets: entité regroupant des données (variables d'instance) et des opérations (méthodes). Par abus de langage, terme générique pour désigner une instance de classe.
• Méthodes: opérations qui déterminent les messages auxquels l'objet peut répondre.
• Données (variables d'instance, attributs): état de l'objet, masquées de l'extérieur et accessibles par les méthodes.
• Abstraction de données:– principe selon lequel un objet est complètement défini par son interface, c'est-
à-dire l'ensemble de ses méthodes;
– réalisé par un mécanisme d'encapsulation.
HEC Lausanne - 19998
Classes d'objets
• Famille d'objets similaires possédant un état, décrits par des variables d'instance, et un comportement, décrit par des méthodes:– un module (ensemble de services, masquage de l'information, relations, ...);
– un type abstrait de donnée (déclaration de variables, sous-typage, ...);
– un modèle pour créer des instances de la classe;
– l'ensemble des classes forme une hiérarchie dans laquelle chaque sous-classe hérite des variables d'instance et des méthodes de ses classes mères.
• Mécanisme d'instanciation qui permet de créer des objets, appelés instances de la classe:– toutes les instances d'une classe constituent l'extension de la classe.
HEC Lausanne - 19999
Instances de classe
• Représentation physique d'une classe détenant les valeurs des variables d'instance et dont le comportement est défini par les méthodes de sa classe.
class employee {
// Instance variables
string name;
double salary;
//methods
//constructor
employee (string n, double s) { name=n; salary=s; }
string getName() { return name; }
setSalary(double x) { salary = x; }
}
Class employee
string name;double salary;
getNamesetSalary
Object employee
string name;double salary;
getNamesetSalary
HEC Lausanne - 199910
Class employee
string name;double salary;
getNamesetSalary
"John"67'000
"Jack"83'000
Instance de
Relations d'instanciation
• Relation qui associe les objets ou instances à leur classe.
• Ces objets sont créés ou instanciés en respectant la structure de leur classe.
HEC Lausanne - 199911
Méthodes
• Opération ou procédure appartenant à l'interface d'une classe. Une méthode est désignée par un sélecteur et peut avoir des paramètres (arguments/résultats).
class employee {
// Instance variables
string name;
double salary;
//methods
//constructor
employee (string n, double s) { name=n; salary=s; }
string getName() { return name; }
setSalary(double x) { salary = x; }
}
HEC Lausanne - 199912
Messages
• Requête adressée à un objet demandant l'exécution d'une de ses méthodes.
• Un message comprend l'objet destinataire, un sélecteur de méthode, et des arguments (si nécessaire):
//Declare a variableemployee oneEmployee;//Create an employeeoneEmployee = new employee ("John", 67000);
//MessageoneEmployee.setSalary(71000);
HEC Lausanne - 199913
Généricité (polymorphisme paramètrique)
• Mécanisme qui permet de définir une classe avec des paramètres qu'on ne précise qu'à l'instanciation de la classe.
• Facilite l'implantation de classes au comportement similaire qui peuvent avoir une même implantation générique.
CLASSES
PILE (T)
VARIABLES D'INSTANCE:
Implantation: TABLEAU [T]
...
METHODES:
...
empiler (x: T)
Utilisation (instanciation) de la classe PILE (T):
TYPAGE
pileInteger: PILE [INTEGER]
pileReal: PILE[REAL]
HEC Lausanne - 199914
Création et destruction d'objets
• Création d'une nouvelle instance de classe (objet):– création générique:
oneEmployee = new employee ();
– création avec initialisation des variables d'instance:
oneEmployee = new employee ("John", 67000);
• Destruction d'une instance de classe:– destruction explicite:
oneEmployee.dispose;
– destruction implicite:
garbage collector (Java par exemple, avec oneEmployee = null;)
HEC Lausanne - 199915
Extension de classes
• Toutes les instances d'une classe (qui n'ont pas encore été détruites) constituent l'extension de la classe;
• La plupart des langages orientés-objets ne gèrent pas l'extension des classes:– A moins d'utiliser explicitement une classe de type "collection":
employees = COLLECTION [employee]
...
– Contrairement à une approche de type "base de données SQL":
create table employees (name, salary)
...
HEC Lausanne - 199916
Surcharge (overloading) (1)
• Principe selon lequel des opérations de même nom s'appliquent à des arguments de types différents et possèdent des implantations différentes:– en Java, il est possible de faire de la surcharge, c'est-à-dire créer des méthodes
qui ont le même nom, tant que chaque méthode a un jeu de paramètres unique.
//Constructor
employee()
{
name="";
salary=0;
}
//Constructor
employee (string n, double s)
{ ...
}
HEC Lausanne - 199917
Surcharge (overloading) (2)
• Existe dans les langages conventionnels pour des types pré-définis:– par exemple + par l'addition d'entiers ou de réels;
• existe dans certains langages (ADA par exemple) pour les procédures:– le compilateur choisi la bonne procédure recherche (x, t) en fonction du
type de x et de t.
• L'orientation objet généralise la surcharge.
HEC Lausanne - 199918
Polymorphisme
• Principe selon lequel une même entité du programme ou variable peut référencer, en cours d'exécution, des objets (instances) de classes différentes.
...
//Create an array of different person's
person[] people = {new client("Bob"), new employee("Alice")};
person choice; //One person
...
choice = people[i]; //Select one person
...
choice.getType(); //Use client.getType if it's a client, employee.getType if it's an employee
HEC Lausanne - 199919
Liaison dynamique
• Une liaison est un mécanisme permettant d'associer un sélecteur à la méthode à appliquer lors de l'envoi d'un message. La liaison peut être statique ou dynamique.
• Une liaison est dynamique lorsque la classe d'appartenance de l'objet désigné par une variable n'est connu qu'à l'exécution. La validité des messages envoyés ne peut donc être vérifiée qu'à l'exécution.
• Un mécanisme de liaison dynamique pour:– la surchage des méthodes;
– le polymorphisme des variables.2/3
"dynamique"
#(1, 2, 3, 5, 8, 13)
rationnel
chaîne
collection
afficher
HEC Lausanne - 199920
Object Client
nameaddresslimit
revenue
Object Person
nameaddress
Héritage (1)
• Mécanisme permettant le partage ou la réutilisation de propriétés entre les objets.
Class Person
nameaddress
Classe Client
limitrevenue
HEC Lausanne - 199921
Héritage (2)
• Point de vue ensembliste:
ensemble(Client) ensemble(Person) Héritage
x • x Client x Person Instanciation
• Point de vue logique:
une implication de prédicats (d'appartenance);
x • Client(x) Person (x).
• Point de vue conceptuel:
une spécialisation;
Client est une sorte de Person.
HEC Lausanne - 199922
Person
Client Employee
Manager
Généralisation/spécialisation
• Spécialisation:Client sous-classe de Person.
• Généralisation:Person super-classe de Client.
HEC Lausanne - 199923
Héritage des variables d'instance
Object Client
nameaddresslimit
revenue
Object Person
nameaddress
Class Person
nameaddress
Classe Client
limitrevenue
HEC Lausanne - 199924
Class Person
changeNamechangeAddress
Class Client
changeLimitchangeRevenue
Héritage des méthodes
person1 = Person.create ...
client1 = Client.create ...
person1.changeAddress (...
client1.changeAddress (... HERITAGE
person1.changeLimit (... ERREUR
client1.changeLimit (...
HEC Lausanne - 199925
Redéfinition (overriding, masquage) (1)
• Principe selon lequel une sous-classe peut respécifier la méthode d'une super-classe, avec une implémentation différente.
class person {
...
string changeAddress() {
... }
}
class client extends person {
...
string changeAddress() {
... }
}
Class Person
changeNamechangeAddress
Class Client
changeLimitchangeRevenuechangeAddress
HEC Lausanne - 199926
Redéfinition (overriding, masquage) (2)
• Masquage pour les variables d'instance:– aucune redéfinition: héritage sans possibilité de redéfinir une variable;– redéfinition arbitraire: possibilité de redéfinir le type d'une variable sans aucune
contrainte (langages non typés, type Smalltalk par exemple);– redéfinition contrainte: les variables d'instance ne peuvent être que des sous-types
des variables de la super-classe (typage fort, type Eiffel par exemple);– définition cachée: les variables d'instance peuvent être cachées aux sous-classes,
pour éviter des conflits entre encapsulation et héritage.
• Masquage pour les méthodes:– redéfinition abstraire: la sous-classe peut offrir une implantation différente d'une
méthode masquée de même nom, sans restriction sur l'implantation et sur les arguments. Lors de l'envoi d'un message, la méthode la plus spécialisée est appliquée (typage faible);
– redéfinition contrainte: le type de chaque argument d'une méthode spécialisée doit être un sous-type de l'argument correspondant dans la méthode masquée (typage fort).
HEC Lausanne - 199927
Visibilité
• Il peut y avoir un conflit entre encapsulation et héritage si les variables d'instance d'une classe sont directement accessibles par ses sous-classes (comme dans Smalltalk par exemple);
• une variable d'instance devrait pouvoir être (comme en C++):– publique: n'importe quel instance peut y avoir accès directement;
– privée: aucune instance ne peut y avoir accès directement, elle doit passer par les méthodes;
– visible des sous-classes: une instance ne peut y avoir accès directement et doit passer par les méthodes. Par contre, une instance héritante peut y avoir accès directement.
HEC Lausanne - 199928
Héritage multiple
• L'ensemble des classes forment un graphe orienté sans circuit;• une classe hérite de l'union des variables et des méthodes de ses super-
classes.
• Conflits entre variables et méthodes:– provenant d'un ancêtre commun;
– provenant d'un problème d'homonymie.
Person
Client Employee
ClientEmployee
HEC Lausanne - 199929
Identifiant et identité des objets
• Matérialise l'identité d'un objet:– tout objet a un identifiant unique, permanent, et immuable;
– deux objets ayant la même valeur mais un identifiant différent sont deux objets différents;
– un objet peut changer de valeur, mais pas d'identifiant (sinon, nous changeons d'objet).
HEC Lausanne - 199930
Egalité d'identité
• Deux objets sont identiques s'ils ont la même identité.
Object Account
balance: 150client: i6bank: i4
Object Bank
name: BOAaddress: "..."director: i12
Object Account
balance: 120client: i2bank: i4
i1
i5
i4
O1 == O2 siO1 et O2 ont le
même identifiant.
HEC Lausanne - 199931
Object Account
balance: 120client: i2bank: i4
i5
Egalité superficielle
• Deux objets sont égaux si leurs états sont égaux:– ils appartiennent à la même classe.
Object Account
balance: 120client: i2bank: i4
i1
O1 = O2 siO1 et O2 ont le
même état.
HEC Lausanne - 199932
Formats d'identifiants
• Format pivot: l'identifiant ne contient aucune information de localisation.– #objet (compteur);– indépendance vis-à-vis du support, mais coûteux quant à l'adresse en mémoire
et/ou sur disque.
• Format mémoire: l'identifiant contient de l'information de localisation en mémoire d'exécution.– @mémoire;– facilite l'adressage en mémoire, et devrait se développer avec l'adressage 64-bit.
• Format disque: l'identifiant contient de l'information de localisation dans l'espace de stockage physique.– #fichier #page;– fiabilité de l'information, mais nécessite un mécanisme de transformation format
disque en format mémoire (table de hachage).
HEC Lausanne - 199933
Langages de programmation et pointeurs
• Dans les langages de programmation conventionnels (Pascal, Ada, C), la gestion des objets prend la forme suivante:– gestion de structures et des pointeurs associés;
– création et destruction d'objets à l'aide d'opérations explicites (new et dispose en Pascal).
• La durée de vie des objets est limitée à la durée d'exécution des programmes qui les créent.
HEC Lausanne - 199934
Clés-identifiantes (1)
• Dans les bases de données [relationnelles], la clé-identifiante d'une relation est un ensemble de ses attributs tel qu'il n'existe pas deux n-uplets ayant même valeur pour ces attributs.
• L'utilisation d'une clé pour identifier un objet (n-uplet) mélange identité et état.
• Cette approche entraîne un certain nombre de problèmes:– répercussion d'une modification de valeurs d'attributs d'une clé (clé étrangère
par exemple);
– non uniformité des clés dans les tables;
– jointures peu naturelles.
HEC Lausanne - 199935
Clé-identifiantes (2)
• L'utilisation d'une clé pour identifier un objet (n-uplet) mélange identité et état.
NPA LOCALITE
1000 Lausanne
1005 Lausanne
Renens
1030 Bussigny
1180 Rolle
... ...
10201020Etat
Identifiant
HEC Lausanne - 199936
Rappel
• Classes;• objets et instances;• méthodes;• messages;• variables d'instance, état;• héritage simple et multiple;• généralisation et spécialisation;• surcharge;• redéfinition;• polymorphisme;• ...
Recommended