To

THEORIE ET CONCEPTS DES OBJETS DISTRIBUES - Title
Page
Suivant Titre
Maison
THEORIE ET CONCEPTS DES OBJETS

DISTRIBUES
● THEORIE ET CONCEPTS DES OBJETS DISTRIBUES.
● Sommaire
Vous etes libre de copier, modifier et redistribuer tout ou partie de ce document, à la seule condition de
garder intact ce copyright:
Copyright 1996, Christophe Pierret (pach2@club-internet.fr) et Patrice Lacouture
Page
Suivant Titre
Maison
http://www.multimania.com/pierret/thobjd_t.htm [25-10-2001 20:55:34]

THEORIE ET CONCEPTS DES OBJETS DISTRIBUES.
Page
SuivantHaut
Maison

DISTRIBUES.
Ce document est divisé en deux parties. Une première partie décrit les concepts fondamentaux du monde
de l'objet, tels que les objets, les classes, l'héritage ... Une deuxième partie décrit les concepts théoriques
liés à la problématique des objets distribués sur un réseau.
● Introduction aux concepts de l'orienté objet.

● Concepts spécifiques à la répartition des objets.
● Synthèse des concepts principaux.
Page
SuivantHaut
Maison
http://www.multimania.com/pierret/thobjd01.htm [25-10-2001 20:55:59]

THEORIE ET CONCEPTS DES OBJETS DISTRIBUES - Introduction aux concepts de l'orienté objet.
SuivantHaut
Introduction aux concepts de l'orienté objet.

L'approche conceptuelle orientée objets repose sur quatre principes de base :
● l'abstraction des données,
● le partage des comportements,
● la prise en compte de l'évolution,
● la validité.
L'abstraction des données consiste à permettre une approche à haut niveau d'abstraction offrant à
l'utilisateur une vision externe des données proche de sa définition conceptuelle. Cette approche est
possible grâce à la modularisation, qui consiste à structurer un problème en sous problèmes
récursivement, et à la décision de cacher les détails d'implémentation à l'utilisateur, lui laissant pour seule
tâche de comprendre le concept du produit et son mode d'emploi, sans se préoccuper de sa structure.
Le principe de partage des comportements consiste à définir les entités par leur comportement, c'est à
dire leur interface externe, et à faire partager ces comportements par les entités de nature identique ou
semblable. Ce partage peut se faire par classification, c'est à dire en regroupant des entités semblables,
donc possédant le même comportement, en classes. De plus, une taxonomie des classes peut être mise en
oeuvre, permettant l'utilisation de mécanismes de spécialisation et d'inclusion. La prise en compte de
l'évolution est facilitée par les deux aspects précédents. L'évolution peut avoir deux formes : l'évolution
des besoins, nécessitant des modifications et des ajouts, et le développement d'un produit par la méthode
incrémentale. L'approche objet permet de traiter ces deux aspects de manière similaire, et applique à
l'ensemble du cycle de développement le modèle incrémental. L'approche objet est par essence
évolutionnaire. Enfin, le souci de validité consiste à fournir au développeur des moyens de vérifier a
priori la validité de la structure du système qu'il conçoit. Cette préoccupation n'a pas toujours été
respectée par les systèmes orientés objets, mais elle est tout particulièrement importante dans des
domaines où l'impossibilité pour un objet de répondre à un message potentiel est inacceptable et doit être
détectée au plus tôt, en tous cas avant l'exécution en exploitation (applications temps réel ). Tous ces
principes sont respectés grâce aux concepts introduits dans cette section.
● Objets, Classes et héritage.

● Polymorphisme, types et types de donnée abstraits.
● Partage du comportement, encapsulation: classes et prototypes.
SuivantHaut

THEORIE ET CONCEPTS DES OBJETS DISTRIBUES - Objets, Classes et héritage.
SuivantHaut
Objets, Classes et héritage.

● Les Objets
❍ La notion d'objet
❍ L'encapsulation
❍ L'interaction entre les objets
● La notion de classe
❍ Les classes
❍ L'instanciation
❍ L'héritage
❍ Recherche des méthodes
Les objets, les classes d'objets et les principes d'héritage sont les piliers de l'approche objet. Voici une
introduction à ces concepts.
Les Objets
La notion d'objet
Dans la méthodologie de conception objet, toute entité perceptible du monde réel peut être modélisée par
un objet. Les objets sont issus du découpage conceptuel du problème à traiter. De l'analyse de celui-ci
ressortent un certain nombre d'entités fonctionnelles correspondant pour l'essentiel à des entités du
monde réel. Certaines entités abstraites peuvent toutefois être modélisées grâce à un, plusieurs objets ou
une partie d'un objet (il est préférable dans la mesure du possible que les objets représentent tous des
entités concrètes).
Par exemple, dans la modélisation d'un système de messagerie, des objets directement perceptibles sont
les utilisateurs, les lettres, les boîtes aux lettres.
L'encapsulation
Un objet est essentiellement défini de manière fonctionnelle, c'est à dire que sa définition comprend
l'ensemble des fonctions ou services qu'il offre, appelées méthodes. Cette description fonctionnelle est la
partie visible par l'utilisateur de l'objet. Bien entendu, un objet possède également des caractéristiques
intrinsèques définissant son état à un instant donné et la manière de réaliser les méthodes, mais ces
éléments ne doivent en aucun cas être accessibles par l'utilisateur de l'objet. Cette définition de la notion
d'objet respecte totalement le principe dit d'encapsulation :
http://www.multimania.com/pierret/thobjd03.htm (1 of 7) [25-10-2001 20:56:57]

L'interface opérationnelle de l'objet encapsulé se limite au strict nécessaire à son utilisation par
l'utilisateur, grâce aux méthodes visibles de l'extérieur de l'objet. Tout le reste, constituant la structure
interne de l'objet, n'est pas accessible de l'extérieur, et encore moins modifiable.
Un exemple d'objet encapsulé, emprunté à Gordon Blair, John Gallagher, David Hutchinson et Doug
Shepherd, est le distributeur de boissons chaudes [Blair,91]. C'est un objet encapsulé dans ce sens où les
mécanismes qui lui permettent de fonctionner (pompes, réservoirs, monnayeur) sont enfermés dans le
boîtier, inaccessible de l'utilisateur. Il propose à l'utilisateur deux méthodes : I. préparer une tasse de thé
II. préparer une tasse de café. L'état de l'objet consiste en la quantité d'eau, de café, de thé, de lait, de
sucre contenus dans la machine. Toutes ces variables sont les descripteurs d'état de l'objet. L'utilisateur
n'a pas accès à ces données, car elles sont également encapsulées. L'interface de l'objet est constitué de
deux boutons sur la face avant. Chacun de ces boutons permet à l'utilisateur de déclencher une des
méthodes. L'intérêt d'une telle approche dans la résolution d'un problème réside dans le fait qu'une fois
que l'objet a été implémenté (dans ce cas précis, fabriqué), il est inutile de connaître sa structure interne.
Seule la connaissance de son interface est nécessaire à son utilisation. La réutilisation de l'objet devient
donc plus simple, puisque elle ne prend pas en compte la structure interne de l'objet, et permet de
s'affranchir de cette complexité. La définition de systèmes complexes s'effectuera en utilisant et
réutilisant des objets, qui eux mêmes en utilisent ou en contiennent d'autres ; mais à un niveau donné, il
suffit et il n'est possible de voir que l'interface des objets de niveau inférieur.
L'interaction entre les objets
Dans le cas d'un problème complexe, il est nécessaire de disposer d'un mécanisme permettant à plusieurs
objets de coopérer. Pour respecter la philosophie objet, cette coopération doit respecter strictement les
contraintes d'encapsulation des objets, c'est à dire qu'un objet ne peut communiquer avec un autre objet
qu'en invoquant ses méthodes publiques.
Dans le contexte objet, l'invocation de la méthode d'un objet est communément appelée envoi d'un
message à un objet. Ce message contient la référence de l'objet destinataire, la méthode demandée et les
paramètres nécessaires à son exécution. Tout objet doit donc posséder d'un identifiant de chaque objet
auquel il désire envoyer un message. Dans le cas de la machine à café, l'objet utilisateur pourra envoyer à
l'objet machine à café le message invoquant la méthode "préparer un café" avec pour paramètre la
quantité de sucre, grâce à une interface améliorée comprenant des boutons supplémentaires pour le
nombre de grammes de sucre. La notion de message est purement conceptuelle. Dans la plupart des cas
de systèmes orientés objets, le message n'a pas d'existence physique, mais est réalisé par exemple grâce à
une forme d'appel de procédure contrôlé. De plus, rien n'empêche à un objet de s'envoyer à lui-même un

message pour invoquer une de ses propres méthodes. Ceci permet de généraliser le mécanisme
d'exécution des méthodes, qu'il s'agisse de méthodes locales (appartenant au même objet) ou distantes
(appartenant à un objet quelconque), et évite l'existence de structures de contrôle différentes pour ces
deux usages. Pour ce faire, chaque objet connaît sa propre identification, qu'il a tout loisir d'utiliser
comme destinataire pour l'envoi d'un message.
La notion de classe
Les classes
L'intérêt des classes est de permettre une classification des objets, leur appariement en groupes d'objets
fonctionnellement identiques. Une classe permet donc la création d'objets qui possèdent tous le même
comportement, donc la même interface (les mêmes méthodes) et la même structure interne. La définition
d'une classe d'objets consiste donc en la définition complète des descripteurs d'état et des méthodes
communes aux objets de la classe. Ce travail de définition ne sera donc pas à refaire pour chaque objet de
la classe.
La classe des distributeurs de café pourrait être définie de la manière suivante :
Nom de la classe : Distributeur de café

Descripteurs d'état :
Quantité de lait
Quantité de café
Quantité de sucre
Quantité d'eau
Quantité de thé
Méthodes :
Préparer un café
Préparer un thé
La description des méthodes est également nécessaire. Dans le cas de la machine à café, il s'agira de la
description des mécanismes internes permettant d'exécuter la méthode.
L'instanciation
La classe ne constitue qu'un modèle, autrement dit un plan de fabrication. La création d'un objet d'une
classe donnée se nomme l'instanciation. Une fois un objet instancié, il est initialisé et existe alors parmi
tous les autres objets, pouvant dès l'ors communiquer avec eux. Chaque objet sait à quelle classe il
appartient, et chaque classe connaît la liste de ses instances.
Il est faut bien comprendre que bien que tous les objets d'une classe aient le même comportement, ils ne
sont pas identiques. Ils sont identiques dans leur interface et leur implémentation, mais chaque objet
possède une existence et un état qui lui sont propres et qui peuvent varier au cours du temps,
indépendamment des autres objets de la même ou des autres classes.

Il est intéressant de noter que l'on peut concevoir que la classe est elle même un objet tout à fait similaire
aux autres, avec pour méthode évidente celle qui crée une instance. Cette méthode est souvent appelée
new. Cette homogénéité permet de créer de nouveaux objets à tout moment, d'envoyer des messages à la
classe pour la paramétrer ou obtenir des informations sur ses objets, voire de faire évoluer les classes.
Elle est poussée à l'extrême dans le langage Smalltalk-80.
L'héritage
Le concept des classes est puissant, mais utilisé seul, il oblige à définir l'ensemble du comportement des
instances de chaque classe. Il est le plus souvent facile de définir une classe à partir d'une classe existante
que l'on modifie sans la remettre totalement en cause. La nouvelle classe conserve le comportement de la
classe existante, mais propose des comportements modifiés ou ajoutés. Une classe qui hérite d'une classe
existante hérite de toutes ses méthodes et de tous ses attributs. A ces propriétés héritées peuvent s'ajouter
de nouvelles méthodes et de nouveaux attributs. On dit que la nouvelle classe est sous-classe de
l'ancienne, et que l'ancienne est la superclasse de la nouvelle.
Pour reprendre l'exemple du distributeur, on peut définir une sous-classe de la classe "Distributeur de
café", que l'on appellera "Distributeur version 2" qui, en plus des fonctions du distributeur de café,
propose de nouvelles méthodes (préparer un chocolat), une interface étendue permettant l'accès à ces
méthodes, une implémentation étendue permettant d'assurer les fonctions nouvelles (nouveaux
mécanismes). Tout ce qui concerne la classe des distributeurs de café est également présent dans celle
des distributeurs version 2. On peut dire que tout distributeur version 2 est aussi et reste malgré tout un
distributeur de café, puisqu'il en a toutes les caractéristiques.

En créant une sous-classe d'une classe existante, on définit en fait une spécialisation de celle-ci, dans le
sens où la sous-classe représente un sous-ensemble de la superclasse, répondant à des besoins plus précis,
plus spécialisés, tout en bénéficiant des caractéristiques de soutes les superclasses. On peut définir ainsi
une hiérarchie de classes, qui représente tous les niveaux de spécialisation depuis la classe la plus
générale à la classe la plus spécialisée. Voici un exemple de hiérarchie de classes tiré de la bibliothèque
standard de Smalltalk-80 :
Dans cet exemple, le comportement d'un objet de la classe Integer est conforme à la classe Integer, bien
sûr, mais également à toutes les surclasses successives, c'est à dire Number, Magnitude et Object. Toutes
les classes de cette hiérarchie sont donc conformes à la définition de l'objet (classe Objet), en apportant
chacune leur spécialisation.

Il convient de noter que l'on n'a pas cherché à représenter la hiérarchie des nombres telle que l'aurait
imaginée le mathématicien, c'est à dire ainsi :
En effet, l'intérêt de la hiérarchisation des classes est d'automatiser le partage des comportements
communs à plusieurs classes d'objets. Par exemple, dans la hiérarchie des nombres en Smalltalk,
supposons l'existence d'une méthode `=' définie pour chaque classe, qui calcule si deux objets d'une
même classe sont égaux. Si nous voulons implémenter la méthode `!=', il n'est pas nécessaire de l'écrire
pour chaque classe : tous les objets disposent de la même méthode `!=', qui renvoie la négation logique
de la méthode `='. La méthode `!=' sera donc définie pour la classe Object uniquement, et toutes les
sous-classes de Object en hériteront automatiquement. De la même manière on pourra définir des
méthodes génériques pour Collection, applicables à toutes ses sous-classes, sans avoir à les réécrire. C'est
pourquoi il n'est pas nécessaire que la hiérarchie des classes corresponde à la vision ensembliste, mais
elle doit plutôt regrouper les comportements, dans le but de minimiser l'écriture des méthodes. Dans le
cas des nombres, Entier est une spécialisation de Rationnel au niveau ensembliste, mais pas au niveau
comportemental.
Recherche des méthodes
La première conséquence de la hiérarchisation des classes et de leur héritage est le mécanisme de lien
entre un message adressé à un objet et la méthode effectivement invoquée. Dans un système sans
héritage, la méthode invoquée serait très simplement recherchée parmi les méthodes de l'objet receveur
du message. Mais dans un système à héritage, un objet hérite des méthodes de toutes ses superclasses.
Lorsqu'il reçoit un message, la recherche de la méthode capable d'y répondre s'effectue d'abord dans la
classe même de l'objet. Si cette recherche est infructueuse, elle se poursuit dans la superclasse de l'objet,
et ainsi de suite. Si aucune méthode ne peut répondre au message dans toutes les superclasses jusqu'à la
classe racine (généralement Object), alors il est impossible de répondre au message.

SuivantHaut

THEORIE ET CONCEPTS DES OBJETS DISTRIBUES - Sommaire

DISTRIBUES - Sommaire
● THéORIE ET CONCEPTS DES OBJETS DISTRIBUéS.
❍ Introduction aux concepts de l'orienté objet.
■ Objets, Classes et héritage.
■ Les Objets
■ La notion d'objet
■ L'encapsulation
■ L'interaction entre les objets
■ La notion de classe
■ Les classes
■ L'instanciation
■ L'héritage
■ Recherche des méthodes
■ Polymorphisme, types et types de donnée abstraits.
■ Polymorphisme
■ Typage
■ Polymorphisme et typage
■ Les types abstraits
■ Partage du comportement, encapsulation: classes et prototypes.
■ Modèle à base de classes.
■ Modèle à base d'acteurs.
■ Systèmes mixtes
❍ Concepts spécifiques à la répartition des objets.
■ Intégration dans le système d'exploitation et les outils de développement.
■ Gestion de la distribution.
■ Héritage et répartition.
■ Migration et réplication des objets.
http://www.multimania.com/pierret/thobjd_c.htm (1 of 3) [25-10-2001 20:57:05]

■ Nom virtuel.
■ Accès aux objets.
■ Protection des objets.
■ Appels à distance.
■ Appel de procédures à distance.
■ Communication par messages synchrones.
■ Communication par messages asynchrones.
■ Passage de paramètres à distance.
■ Le futur des systèmes dexploitation.
■ Gestion de la concurrence d'exécution et d'accès.
■ Parallélisme à lintérieur dun objet.
■ Parallélisme entre objets.
■ Verrous mortels (interbloquage).
■ Gestion des versions.
■ Au niveau de l'application.
■ Version d'instance.
■ Version de classe.
■ Au niveau du système.
■ Sécurité.
■ Divers problèmes liés à la distribution.
■ Problèmes datomes crochus.
■ Problèmes dévolution dynamique.
■ Problèmes de comportement sociaux.
■ Problèmes de déboguage.
■ Problèmes de défense.
■ Problèmes de contraintes temporelles.
■ Persistance des objets.
■ Bases de données relationnelles.
■ Systèmes de gestion de fichiers.
■ Bases de données orientées objets.
■ Comparaison des trois possibilités.
❍ Synthèse des concepts principaux.


THEORIE ET CONCEPTS DES OBJETS DISTRIBUES - Polymorphisme, types et types de donnée abstraits.
SuivantHaut
Polymorphisme, types et types de donnée abstraits.

● Polymorphisme
● Typage
● Polymorphisme et typage
● Les types abstraits
Polymorphisme
Lorsqu'un message parvient à un objet, il peut invoquer une méthode appartenant aussi bien à la classe de
l'objet ou à une de ses superclasses, sans que l'on puisse a priori dire laquelle. On peut donc parler de
polymorphisme. Le polymorphisme signifie ici que le même message, en fonction de l'objet auquel il est
envoyé, peut être traité de plusieurs façons différentes. Le polymorphisme peut se manifester sous deux
formes :
- par création de sous-classe : une méthode peut être définie dans une classe et redéfinie dans une de ses
sous-classes. Le même message aura des comportements différents selon qu'il est envoyé à un objet de
l'une ou l'autre des classes. - par surcharge : deux classes indépendantes peuvent posséder une méthode
de même nom et répondre ainsi, chacun à leur manière, à un message. Dans ces deux cas, il est évident
que pour que le polymorphisme présente un intérêt, il faut que quelle que soit la méthode invoquée pour
répondre à un message donné, la sémantique de ce message reste la même. Par exemple, on définira une
méthode `écrire' pour une classe d'objets, dont le rôle est d'écrire une description de l'objet sur l'écran.
Cette méthode est également valable pour toutes les sous-classes, mais il est possible de la redéfinir pour
certaines sous-classes qui nécessitent l'affichage de données supplémentaires par exemple
(polymorphisme par création de sous-classe). De même, une autre classe d'objets totalement
indépendante peut, elle aussi, disposer de la méthode `écrire', et répondra au même message à sa façon
(polymorphisme par surcharge). Le message `écrire' pour toutes les classes d'objets qui y répondent devra
toutefois, d'un point de vue externe, avoir la même sémantique, à savoir déclencher l'écriture d'une
description de l'objet sur l'écran, même si aucun système ne pourra contraindre le concepteur à respecter
cette règle.
Typage
La notion de type est assez similaire à celle de classe, sans toutefois la recouvrir totalement. Elle a pour
origine la volonté d'abstraction des données. Tout système informatique peut être considéré comme un
ensemble de valeurs pouvant être manipulées. Il est pratique de regrouper les valeurs similaires en types
de manière à raisonner en fonction de leurs propriétés communes. Par exemple, le type 'entier' représente
généralement un groupe de données qui présente des propriétés comparables au concept mathématique
d'entier relatif. Ainsi le typage, permettant l'abstraction des données, est un fondement de l'informatique.
Le typage remplit plusieurs fonctions :

- Il permet l'abstraction des propriétés intrinsèques des données : les valeurs sont des entités complexes
possédant une structure et une sémantique associée à cette structure, qui définit les opérations que l'on
peut effectuer sur la valeur. Le fait de définir un type permet de définir ces propriétés une fois pour toutes
et de supposer que toutes les données du type ainsi défini posséderont ces mêmes propriétés et cette
même structure. - Il permet la composition des types : il est possible de créer des types de niveau
d'abstraction supérieur à partir de types existants. Dans la plupart des systèmes ou langages existants, il
existe des types de base (entier, réel, caractère), et des types agrégés (tableaux, enregistrements, listes)
permettant de regrouper des données d'autres types. Ce processus est à la base de la représentation de
toutes les données du monde réel dans les systèmes informatiques. - Il permet la protection : le typage
permet également la protection des données contre les actions illégales. Un langage possédant une
fonction de vérification des types détectera les opérations illicites sur les données manipulées. Une
opération ne peut être effectuée sur une donnée que si elle est autorisée sur son type. Cette vérification
est souvent faisable a priori, sans nécessiter l'exécution du programme. Il consiste essentiellement à
contrôler les affectations de valeurs et le passage de paramètres aux procédures et fonctions. Néanmoins,
le contrôle des types ne vérifie que la validité des actions, elle ne concerne absolument pas la manière
dont les actions sont effectuées. Dans l'approche objet toutefois, ces deux préoccupations sont
intimement liées.
Polymorphisme et typage
Dans les langages classiques, toute valeur ne possède qu'un type unique. Le typage polymorphe permet à
une valeur d'appartenir à plusieurs types simultanément en fonction du contexte où il est utilisé. Par
exemple, un entier pourra être utilisé en tant que réel, voire en tant que chaîne de caractères selon les
opérations (addition, concaténation). On retrouve donc une notion de polymorphisme similaire à celle
qu'on avait introduite plus haut, c'est à dire qu'une même fonction peut avoir plusieurs comportements
(définitions) selon le type des paramètres qu'elle reçoit en entrée ou en sortie.
Une autre conséquence est qu'une variable polymorphe peut prendre des valeurs de types différents, et les
opérations qui peuvent être effectuées sur ces variables devront être polymorphes (exemple : l'affectation
d'un entier ou d'un réel à une variable réelle).. Selon les systèmes, la vérification de la validité des types
(possibilité d'effectuer chaque opération demandée sur les objets spécifiés) peuvent être statiques (à la
compilation) ou dynamiques (à l'exécution). De même, la recherche du code à exécuter pour chaque
exécution peut être statique ou dynamique.
Vérification statique Vérification dynamique
Langages classiques : pas de Sans intérêt : la recherche statique
Recherche statique polymorphisme, mais validation stricte nécessitant une vérification statique,
dès la compilation pourquoi encore vérifier à l'exécution ?
Permet une forme de polymorphisme Permet le polymorphisme total, mais
Recherche dynamique mais aussi une validation à la ne permet qu'une validation à
compilation l'exécution.
Dans les systèmes orientés objets, la notion de type, si elle n'existe pas toujours, et très similaire à celle
de classe. Dans certains cas on peut faire correspondre (mais pas exactement) les propriétés des classes à
celles des types, sans toutefois permettre généralement une validation statique. Dans d'autres cas une
combinaison des notions de type et de classe existe et permet une validation statique (C++). Le
polymorphisme est donc la capacité des systèmes à objets de représenter par le même terme des réalités

variées (entités, comportements).
Les types abstraits
Considérons la notion de file d'attente. Elle peut être représentée par un type acceptant les fonctions
Àjouter un élément', `Retirer un élément', `Taille de la file'. Si l'on désire utiliser des files d'attente de
réels, d'entiers et d'autres types de données, il conviendra de réécrire les fonctions quasiment identiques
pour chacun des types pouvant être stockés dans la liste. Cette réécriture peut être évitée grâce au
polymorphisme. Dans les bibliothèques de classes de C++ et de Smalltalk-80, par exemple, existent des
classes `file d'attente', qui sont des files de valeurs de la classe Òbjet'. Le polymorphisme permis par ces
langages grâce à la hiérarchie des classes permet de considérer comme un objet des valeurs de types
variés, donc d'effectuer les traitements propres aux listes grâce à un jeu unique de méthodes.
Une autre possibilité est de définir le type `file d'attente' qui peut être paramétrée par le type des objets
contenus. On peut ainsi à partir d'une seule et même définition générer simplement un nombre indéfini de
sous-types de la file d'attente : la `file d'attente de réels', la `file d'attente d'entiers', la `file d'attente de
clients', etc. De tels types génériques sont appelés types abstraits, en ce sens qu'ils ne servent
véritablement à stocker des valeurs, mais simplement à définir un comportement commun à une famille
de types. La même démarche appliquée aux classes définit des classes abstraites, qui ne dont on ne
créera jamais aucune instance, mais simplement des sous-classes en représentant une application
particulière. Les types abstraits et les classes abstraites sont des modèles non fonctionnels, utilisables
pour construire des types ou des classes utilisables d'une même famille.
SuivantHaut

THEORIE ET CONCEPTS DES OBJETS DISTRIBUES - Partage du comportement, encapsulation: classes et prototypes.
SuivantHaut
Partage du comportement, encapsulation: classes et prototypes.

● Modèle à base de classes.
● Modèle à base d'acteurs.
● Systèmes mixtes
Nous avons présenté dans le paragraphe Òbjets, classes et héritage' l'encapsulation et le partage du
comportement grâce l'approche hiérarchique des classes. Si l'encapsulation est généralement définie de
façon assez homogène au niveau de l'objet, le problème du regroupement et du partage du comportement
est résolu de manières différentes. Les deux grandes familles sont celle des systèmes à base de classes et
d'héritage et celle des systèmes à base de prototypes. Leurs différences se situent dans la façon dont un
objet est capable d'emprunter un comportement d'un objet particulier, et dans celle dont un objet peut être
défini à partir d'un modèle. Lynn Andrea Stein, Henry Lieberman et David Ungar nomment
respectivement ces deux caractéristiques `l'empathie' et l'usage des `patrons'.
Modèle à base de classes.
L'empathie dans ce modèle réside complètement dans le mécanisme héritage. Celui-ci détermine les
méthodes empruntées à d'autres objets de manière statique et par groupe, ce qui signifie que pour un
message adressé à un objet quelconque d'une même classe, la méthode sera toujours empruntée à une
autre classe bien précise.
Dans tous les cas, les méthodes sont définies pour une classe, non pour un objet. Ce modèle définit donc
des groupes distincts d'objets uniformes, séparant ce qui peut être délégué de ce qui ne l'est pas : ce qui
peut être délégué est stocké dans les classes, ce qui ne l'est pas est stocké dans les objets eux-mêmes. Les
`patrons' sont les classes. Dans ce modèle, chaque objet d'une classe respecte strictement les
spécifications définies pour sa classe. Il ne peut y avoir d'exception à une classe. Tout objet constituant
une exception à une classe doit faire l'objet d'une nouvelle classe. L'avantage évident est que
l'appartenance des objets à une classe est une relation très rigoureuse, d'où des répercussions importantes
au niveau de la validation a priori et des performances (l'absence d'exception simplifie la recherche des
méthodes, par exemple). C'est également un inconvénient à cause de la lourdeur du système dans le cas
où l'on désire représenter une multitude d'objets ne se conformant pas exactement à une classe unique ou
dont le comportement est susceptible de changer (`Vous modélisez bien les figurants, mais pas les
vedettes'). Enfin, nombreux sont les objets du monde réel pour lesquels le modèle hiérarchique de classes
n'est tout simplement pas adapté.
Modèle à base d'acteurs.
Le modèle à base d'acteurs est une alternative au modèle à base de classes qui se destine à une
modélisation plus souple du monde réel.
Un acteur est un objet actif et communiquant. Chaque acteur possède pour caractéristiques propres son

état et un script définissant le comportement interne de l'acteur. Dans un système à base d'acteurs, tout est
acteur. Les acteurs communiquent par des messages. Un acteur peut envoyer un message à un autre, qui
le filtrera et enverra d'autres messages vers d'autres acteurs avant de répondre. L'encapsulation est
assurée, car le seul moyen d'accéder d'une manière ou d'une autre à un acteur est de lui envoyer un
message et d'en attendre la réponse. `L'empathie' est possible grâce au processus de délégation : lorsqu'un
acteur reçoit un objet, il l'envoie à chacune de ses méthodes, qui est elle-même un acteur, jusqu'à ce que
l'une d'entre elles soit capable d'interpréter le message. De la même façon, les accès aux variables d'état,
elles aussi des acteurs, se font par délégation.
La délégation est possible vers les méthodes et les variables d'état, elle est également possible vers
d'autres objets. On peut ainsi créer des objets d'extensions, en opposition avec les objets de base, ou
prototypes :
Comme montré ci-dessus, on peut définir un objet d'extension qui reprend l'objet défini précédemment
(prototype), et qui implémente une nouvelle fonction pression. Tout message qui n'est pas reconnu par
`pression' sera délégué aux proxies de l'objet, en l'occurrence à `Jauge A' :

Il faut bien remarquer que même si les méthodes sont déléguées à l'acteur `Jauge A', ce sont bien les
données de `Jauge B' qui sont manipulées, ce qui signifie que toute méthode de `Jauge A' appelée par
délégation par `Jauge B' (ex : calcule Gradient), si elle doit envoyer en message à la Jauge, l'enverra en
priorité à `Jauge B' et pas à `Jauge A' (ici, `pression' de `Jauge B' a été utilisée en priorité par rapport à
`pression' de `Jauge A'). De cette manière, même si l'objet d'extension délègue des comportements, il
n'utilise pas moins ses propres données. De cette manière, le partage des comportements est parfaitement
assuré. Il faut bien remarquer que le prototype (ici `Jauge A') est un acteur totalement similaire et
fonctionnel, contrairement aux classes qui ne peuvent fonctionner comme les objets qu'elles définissent.
Cette méthode repose sur un certain nombre de conventions telles que le choix d'une recherche de la
méthode en profondeur d'abord (généralement employée) ou en extension d'abord. Elle remplit à la fois
les objectifs `d'empathie' et de génération selon un `patron', d'une façon dans les deux cas plus souple que
celle proposée par les classes. Cette approche possède plusieurs avantages sur celle reposant sur les
classes : Un acteur n'est pas obligé de posséder une copie de toutes les valeurs des prototypes sur lesquels
il repose : seules les valeurs qu'il utilise sont créées. Un acteur, à partir d'un prototype, peut très bien
définir de nouveaux comportements destinés à être utilisés par lui seul, mais il peut aussi devenir
lui-même un prototype. Cela offre une grande souplesse que n'offrent pas les classes. Le schéma de
recherche des méthodes est totalement dynamique et explicite. Il peut être modifié au cours de l'existence
de l'objet. En revanche, on peut formuler les critiques suivantes : Performances a priori inférieures : en
regroupant les méthodes, les classes permettent une réduction substantielle du coût en ressources d'un
système par rapport à l'approche acteurs équivalente. Faible protection : comme le prototype,
contrairement à la classe, est un objet banalisé et fonctionnel, il peut être modifié avec pour conséquence
le dysfonctionnement des objets qui lui délèguent des actions. Il est par conséquent nécessaire de
développer des mécanismes de protection supplémentaires. Enfin, il faut garder à l'esprit que tout n'est
pas propre à être modélisé par des acteurs, de même que par des objets regroupés par classes.
Systèmes mixtes
Certains systèmes, pour bénéficier des apports combinés des classes et des acteurs, sont définis comme
un compromis. Les systèmes de classes sont adaptés à la représentation des comportements de groupes
importants, en liant ces comportements aux classes, tandis que les systèmes d'acteurs représentent plus
efficacement les comportements d'entités différenciées, en associant directement les comportements aux
acteurs. Il existe un certain nombre de systèmes qui se situent à mi-chemin de ces deux extrêmes. Le

moyen le plus évident est de permettre les deux approches, en les combinant ou en les juxtaposant.
SuivantHaut

THEORIE ET CONCEPTS DES OBJETS DISTRIBUES - Concepts spécifiques à la répartition des objets.
SuivantHaut
Concepts spécifiques à la répartition des objets.

Il existe différents types de systèmes distribués: il est difficile d'évaluer la limite entre ce que fait le
système et ce que fait l'environnement de développement.
Les applications distribuées prennent des formes très diverses et la stratégie de distribution peut avoir été
adoptée pour différentes raisons:
● Parallélisation des tâches pour des raisons de performance
● A cause de l'éloignement d'entités communicantes (messageries ...) ou pour des raisons de

spécialisation des équipement ( usine automatisée)
● Pour l'intégrité des données et des applications ( risques d'incendie, de tremblement de terre ...)
grâce à la réplication des données.
Pour toutes ces raisons, un système distribué à base d'objets doit résoudre des problèmes de tout ordre:
● gestion de l'emplacement des objets;
● transparence de la distribution;
● parallélisme et synchronisation;
● communication entre objets;
● partage de comportement (héritage...) et distribution.
Dans ce chapitre, nous allons nous attacher à décrire tous ces problèmes et les solutions qui peuvent
apparaître. En effet, pour pouvoir comparer les différentes architectures d'objets distribués comme OLE,
CORBA ou OpenDoc, il faut pouvoir s'appuyer sur des bases solides (pas uniquement les discours
commerciaux).
● Intégration dans le système d'exploitation et les outils de développement.

● Gestion de la distribution.
● Gestion de la concurrence d'exécution et d'accès.
● Gestion des versions.
● Sécurité.
● Divers problèmes liés à la distribution.
● Persistance des objets.
SuivantHaut

THEORIE ET CONCEPTS DES OBJETS DISTRIBUES - Intégration dans le système d'exploitation et les outils de développement.
SuivantHaut
Intégration dans le système d'exploitation et les outils de

développement.
Il existe différents niveaux d'intégration des services d'un système orienté objet. Le plus souhaitable est
d'avoir le maximum de services de base inclus dans le système. Sinon, il va falloir réinventer la roue à
chaque fois ou réutiliser du code source ce qui n'est pas la panacée.
On verra plus avant comment l'intégration dans le système des services de base permettra de résoudre de
manière élégante et performante les problèmes actuels des approches objet et notamment: nommage,
transparence, et réutilisation.
L'enjeu de l'intégration à terme dans le système d'exploitation est de permettre une réutilisation au
niveau binaire, et non pas comme à l'heure actuelle en récupérant une classe C++.
En effet, la réutilisation de source de classes C++ est limitée dans la pratique à un projet, ou au mieux à
un service. Alors qu'on peut attendre de la réutilisation binaire, une réutilisation au niveau de l'entreprise
ou même la commercialisation d'objets pré-définis et interopérables.
SuivantHaut

To

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

To

Enviado por

Direitos autorais:

Formatos disponíveis

THEORIE ET CONCEPTS DES OBJETS DISTRIBUES - Title

THEORIE ET CONCEPTS DES OBJETS

http://www.multimania.com/pierret/thobjd_t.htm [25-10-2001 20:55:34]

THEORIE ET CONCEPTS DES OBJETS

● Introduction aux concepts de l'orienté objet.

http://www.multimania.com/pierret/thobjd01.htm [25-10-2001 20:55:59]

Introduction aux concepts de l'orienté objet.

● le partage des comportements,

● la prise en compte de l'évolution,

● Objets, Classes et héritage.

http://www.multimania.com/pierret/thobjd02.htm [25-10-2001 20:56:12]

Objets, Classes et héritage.

http://www.multimania.com/pierret/thobjd03.htm (1 of 7) [25-10-2001 20:56:57]

L'interaction entre les objets

http://www.multimania.com/pierret/thobjd03.htm (2 of 7) [25-10-2001 20:56:57]

Nom de la classe : Distributeur de café

http://www.multimania.com/pierret/thobjd03.htm (3 of 7) [25-10-2001 20:56:57]

http://www.multimania.com/pierret/thobjd03.htm (4 of 7) [25-10-2001 20:56:57]

http://www.multimania.com/pierret/thobjd03.htm (5 of 7) [25-10-2001 20:56:57]

Recherche des méthodes

http://www.multimania.com/pierret/thobjd03.htm (6 of 7) [25-10-2001 20:56:57]

http://www.multimania.com/pierret/thobjd03.htm (7 of 7) [25-10-2001 20:56:57]

THEORIE ET CONCEPTS DES OBJETS

http://www.multimania.com/pierret/thobjd_c.htm (1 of 3) [25-10-2001 20:57:05]

http://www.multimania.com/pierret/thobjd_c.htm (2 of 3) [25-10-2001 20:57:05]

http://www.multimania.com/pierret/thobjd_c.htm (3 of 3) [25-10-2001 20:57:05]

Polymorphisme, types et types de donnée abstraits.

http://www.multimania.com/pierret/thobjd04.htm (1 of 3) [25-10-2001 20:57:11]

http://www.multimania.com/pierret/thobjd04.htm (2 of 3) [25-10-2001 20:57:11]

variées (entités, comportements).

Les types abstraits

http://www.multimania.com/pierret/thobjd04.htm (3 of 3) [25-10-2001 20:57:11]

Partage du comportement, encapsulation: classes et prototypes.

Modèle à base de classes.

Modèle à base d'acteurs.

http://www.multimania.com/pierret/thobjd05.htm (1 of 4) [25-10-2001 20:57:33]

http://www.multimania.com/pierret/thobjd05.htm (2 of 4) [25-10-2001 20:57:33]

http://www.multimania.com/pierret/thobjd05.htm (3 of 4) [25-10-2001 20:57:33]

http://www.multimania.com/pierret/thobjd05.htm (4 of 4) [25-10-2001 20:57:33]

Concepts spécifiques à la répartition des objets.

● A cause de l'éloignement d'entités communicantes (messageries ...) ou pour des raisons de

● communication entre objets;

● partage de comportement (héritage...) et distribution.

● Intégration dans le système d'exploitation et les outils de développement.

http://www.multimania.com/pierret/thobjd06.htm [25-10-2001 20:57:42]

Intégration dans le système d'exploitation et les outils de

http://www.multimania.com/pierret/thobjd07.htm [25-10-2001 20:58:08]

Você também pode gostar