To

THEORIE ET CONCEPTS DES OBJETS DISTRIBUES - Title

Suivant

Titre

Page 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 ([email protected]) et Patrice Lacouture Suivant

Titre

Page Maison

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

THEORIE ET CONCEPTS DES OBJETS DISTRIBUES.

SuivantHaut

Page Maison

THEORIE ET CONCEPTS DES OBJETS 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. SuivantHaut

Page 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

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

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]

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

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

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

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

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.

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

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

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.

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

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

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.

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

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

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.

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

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

SuivantHaut

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

THEORIE ET CONCEPTS DES OBJETS DISTRIBUES - Sommaire

THEORIE ET CONCEPTS DES OBJETS 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]

THEORIE ET CONCEPTS DES OBJETS DISTRIBUES - Sommaire

■

■

■

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.

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

THEORIE ET CONCEPTS DES OBJETS DISTRIBUES - Sommaire

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

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 :

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

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

- 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 Langages classiques : pas de Recherche statique polymorphisme, mais validation stricte dès la compilation Permet une forme de polymorphisme Recherche dynamique mais aussi une validation à la compilation

Vérification dynamique Sans intérêt : la recherche statique nécessitant une vérification statique, pourquoi encore vérifier à l'exécution ? Permet le polymorphisme total, mais ne permet qu'une validation à 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 http://www.multimania.com/pierret/thobjd04.htm (2 of 3) [25-10-2001 20:57:11]

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

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 `Ajouter 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 `Objet'. 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

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

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 `Objets, 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

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

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

é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' :

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

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

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 http://www.multimania.com/pierret/thobjd05.htm (3 of 4) [25-10-2001 20:57:33]

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

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

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

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

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

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

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