Dans le cadre de ce chapitre, nous nous intéressons au cas particulier de la modélisation des documents multimédias. L'approche orientée objet, en permettant l'encapsulation en une seule entité des données et des traitements, offre une solution à la gestion de tels documents. Au vu de la définition de ces derniers (cf. Partie I - Chapitre 1), ils peuvent être considérés comme des objets composites manipulé globalement par une application. Or, chaque traitement demandé sur un document induit une série d'opérations sur ses composants. La gestion des relations entre les entités composant un document multimédia font appel à des mécanismes sophistiqués comme par exemple la synchronisation d'une séquence sonore et l'affichage d'un texte. Ainsi, la prise en compte des relations entre les objets composants d'un objet composite a pour but d'améliorer sa sémantique. L'intégration dans la définition de l'objet composite de sa spécification d'action favorise son autonomie et la manipulation des objets composants de manière cohérente. Notre contribution vise donc à modéliser le comportement des objets composites par rapport à leur activité interne. En fait, il s'agit de modéliser l'activité externe des objets composants de l'objet composite.

L'approche orientée objet, tel qu'elle est utilisée dans les systèmes de gestion de bases de données objets, comme O2 [Deux, 90], Ontos [Bim, 91] n'a pas totalement permis de maîtriser le comportement des objets. C'est pour cela que dans une première section, nous allons nous intéresser au concept de base de donnée active à travers une étude des différentes recherches concernant ce domaine. Nous montrons dans cette section comment nous avons tiré parti de ces recherches pour les intégrer à notre modèle.

Notre préoccupation consiste à spécifier le comportement des objets composites par rapport à leur activité interne. Pour cela, dans une deuxième section, nous allons définir les différentes relations intervenant à la fois entre un objet composite et ses objets composants, et les relations dynamiques entre les objets composants que nous appelons relations inter-composants ; nous devrons ensuite modéliser ces différentes relations en les considérant comme des contraintes.

Nous allons gérer ces contraintes liées à l'activité interne des documents multimédias à l'aide du concept d'objet actif. Dans la troisième section, nous allons modéliser ces contraintes à l'aide d'un modèle de classes de contraintes qui va nous permettre de fournir une représentation formelle des documents multimédias [Merlet, 93b] [Nadalin, 93a] [Nadalin, 93b].

Notre problématique dans ce chapitre est de définir un modèle permettant de modéliser les documents multimédias. Nous considérons les documents multimédias comme des objets composites ayant des comportements spécifiques avec une certaine indépendance par rapport aux objets qui les entourent. Le terme indépendance signifie, dans ce contexte, qu'un document multimédia gère son activité interne, par rapport aux objets le composant, de manière autonome et en réaction à son environnement externe. Cette problématique, telle que nous la posons, peut tirer parti des recherches portant sur l'aspect dynamique des systèmes d'information. En effet, notre objectif n'est pas de définir un modèle d'objet actif. Ce courant actuel de recherche concerne la prise en compte du concept d'activité dans les systèmes d'information, et plus particulièrement dans les bases de données orientées objet. En effet, ce concept d'activité prend tout son intérêt avec le modèle orienté objet puisqu'un objet encapsule son comportement.

L'objectif de cette section est de nous permettre d'effectuer un tour d'horizon du domaine de recherche relatif à l'activité d'objet.

Le concept d'objet actif est l'élément central des recherches sur les bases de données orientées objet actives qui visent à définir des modèles d'objet actif.

Selon [Rolland, 91] un objet peut être vu selon trois axes :

Les aspects dynamiques et comportementaux représentent les évolutions de l'objet au cours du temps. Les événements qui conduisent l'objet dans un nouvel état sont soumis à des règles définies dans l'objet. Ces changements d'états peuvent se faire sur une décision interne à l'objet : un objet actif se définit ainsi par son degré d'autonomie.

Un objet actif, selon [Bouaziz, 92], est défini par le triplet <Sensibilité, Connaissance, Activité>. La Sensibilité représente l'acuité de l'objet à réagir aux événements de son environnement. La Connaissance correspond aux attributs et méthodes de l'objet. L'Activité qui définit son comportement est scindée en deux parties :

Nous pouvons rapprocher la notion d'activité interne aux notions de perspectives statique et dynamique du modèle proposé par [Rolland, 91] et l'activité externe à la notion de perspective comportementale.

D'une manière plus générale, G. Booch [Booch, 92] définit les objets actifs comme des entités possédant une certaine autonomie. Ce qui signifie qu'ils peuvent exhiber certains comportements sans être dirigés par un autre objet. Un objet actif englobe alors sa propre unité de contrôle; ce que ne possède pas un objet passif. L'unité de contrôle est la séquence d'actions qui s'exécutent en réponse à un événement imprévu quand le système est dans un état particulier.

Nous pouvons rapprocher cette définition d'objets actifs de celle qui est faite dans la méthode de conception orientée objet Hierarchical Object Oriented Design (HOOD) [Heitz, 91][Lai, 91]. Un objet est dit actif s'il possède une opération contrainte. Une opération peut être contrainte dans son exécution selon l'état interne de l'objet et/ou par des contraintes d'exécution liées aux communications inter-objet. Les objets actifs sont généralement utilisés lorsqu'il s'agit d'exprimer des contraintes de concurrence. A l'opposé, un objet passif ne possède pas de comportement autonome et n'a aucune sémantique dépendante du contrôle : les opérations offertes ne donnent lieu à aucun conflit d'accès. Ainsi le flot de contrôle est passé directement à l'opération qui est exécutée.

[Ellis, 89] enrichit la notion d'objets actifs par le fait que non seulement les méthodes de l'objet sont déclenchées automatiquement mais que de plus elles se déroulent en parallèle du processus en cours. Mais ce principe n'est pas adopté par l'ensemble des recherches sur l'activité d'objet.

Nous pouvons résumer ces différentes approches du concept d'objet actif par la définition suivante :

Définition : Objet Actif

Un objet actif est un objet capable d'activer son comportement de manière autonome, c'est-à-dire sans avoir reçu de messages, en fonction soit d'une décision interne, soit d'un événement externe.

Après avoir défini le concept d'objet actif, nous allons nous intéresser aux différents modèles d'objet actif. Cette étude va nous permettre de mieux appréhender la modélisation de l'activité interne de documents multimédias.

L'intégration du concept d'objet actif dans les modèles orientés objet permet d'améliorer la prise en compte de la dynamique des systèmes d'information. Elle favorise notamment la mise en oeuvre de mécanismes régissant les changements d'état des objets (règles d'évolution et contraintes d'intégrité). Cette intégration peut également améliorer les évolutions des objets et cela surtout pour les instances. En effet, l'évolution d'une instance, c'est-à-dire la non conformité de sa structure et/ou de son comportement par rapport à sa classe mère, n'est pas pris en compte par les modèles orientés objet.

Les objectifs principaux des modèles d'objet actif sont les suivants :

Pour parvenir à ces objectifs, qui reviennent à activer le comportement des objets de manière autonome, les modèles d'objet actif intègrent un ensemble de règles. Ce sont ces règles qui vont permettre d'activer les méthodes d'un objet sans envoi explicite de messages d'autres objets.

Lorsque nous parlons de modèles d'objet actif, le modèle de référence est le modèle basé sur les règles Evénement-Condition-Action (ECA) introduit par [Dayal, 88] avec le système HiPAC. Compte tenu de la diversité des modèles orientés objets, les modèles qui tiennent compte de l'activité des objets sont très variés, mais ils restent néanmoins basés sur ce modèle de règles ECA. Un modèle d'objet actif se compose d'un modèle de règle et d'un modèle d'exécution ou d'inférence. Ce dernier définit les principes d'activation et de sélection des règles en précisant les problèmes de conflits de priorité dans l'activation des règles. Mais ce modèle est trop lié à des problèmes techniques, comme le modèle transactionnel sous-jacent de la base de données orientée objet, pour ne pas concerner la modélisation de documents multimédia. De ce fait, pour chacun des modèles d'objet actif, nous allons limiter notre étude au modèle de règles. Celui-ci définit principalement la sémantique et le couplage des trois composantes Evénement, Condition et Action ainsi que le niveau d'intégration des règles dans le modèle orienté objet.

Nous commençons par présenter le modèle d'objet actif HiPAC qui est le modèle de référence, puis différents modèles actifs ayant chacun leurs particularités. Cette étude va nous permettre d'établir une synthèse en vue de la définition de notre propre modèle de documents multimédias.

L'objectif du projet HiPAC (High Performance ACtive database) [Dayal, 88] est de concevoir un système de gestion de bases de données actif. C'est HiPAC qui a introduit le concept de règles ECA comme un formalisme des capacités d'une base de données active.

HiPAC utilise un modèle de données orienté objet où les règles sont des objets de la classe définie dans le modèle.

Les composantes d'une règle ECA sont définies comme suit :

Les trois composantes (E,C et A) sont fortement découplées puisqu'il existe trois modes de couplages différents (immédiat, reporté et séparé) pour les deux couples (E, C) et (C, A).

[Beeri, 91] propose un modèle logique pour une base de données orientée objet active où les règles sont de type Evénement-Action. L'idée principale est d'utiliser les concepts d'encapsulation et d'héritage. En particulier, les règles sont des méthodes spéciales encapsulées dans l'objet approprié. Ainsi, une règle étend la définition de méthode en rajoutant un ensemble d'actions à déclencher (pas nécessairement immédiatement). Les composantes d'une règle EA sont donc définies comme suit :

De plus, chaque objet possède une partie active où est stockée dans des attributs l'information des actions déclenchées qui sont en attente d'exécution.

Le prototype EXACT développé par [Diaz, 91] [Diaz, 92] repose sur le système de gestion de base de données orientées objet ADAM (Aberdeen DAta Model) développé en Prolog. Le modèle EXACT intègre le mécanisme de règles ECA dans une base de données orientée objet à l'aide d'une approche uniforme. Celle-ci permet de ne pas distinguer les règles des autres types d'objets. De plus, les classes de règles sont fortement hiérarchisées. En effet, le modèle propose une hiérarchie de classes avec au sommet de la hiérarchie deux métaclasses qui factorisent trois classes de règles. Ces classes de règles sont :

Les composantes d'une règle ECA sont définies comme suit :

Comme pour toute autre entité, la signification d'une règle est traduite par les attributs attachés à la règle et leur interprétation par les méthodes associées. Les méthodes seules ne peuvent pas spécifier totalement le contexte d'invocation mais elles ne prennent véritablement leur sens qu'à partir d'une classe. La définition de règles est alors étendue avec un attribut classe-active. Puisque les règles sont de véritables objets, cet attribut peut être implémenté comme une relation à double sens entre les règles et les classes. Cette approche permet de réduire considérablement la recherche des règles applicables puisqu'à chaque classe est attaché l'ensemble des règles à vérifier.

Le modèle AO2, bâti autour du concept d'objet actif, proposé par [Bouaziz, 92] a pour objectif de prendre en compte toute la dynamique des systèmes d'information. Ce modèle a permis la réalisation d'un prototype de système de gestion de bases de données orientées objet actif construit au-dessus du système O2 [Deux, 90]. L'aspect actif, en se basant sur le concept de règle ECA permet d'exprimer l'occurence d'un événement et le comportement de l'objet correspondant à cet événement. Une classe AO2 est définie comme n'importe quelle autre classe avec des attributs et des méthodes. Au niveau implantation, une classe AO2 est composée de deux classes : une classe passive et une classe active. La classe passive définit les aspects <Attributs, Méthodes>. La classe active a pour attributs les événements et les couples <Conditions, Actions> et pour méthode la méthode "capte_événement" qui renvoie tous les couples <Conditions, Actions> déclenchés par un événement, et les méthodes "activités" qui sont associées à ces couples.

Les composantes de l'objet actif sont définies comme suit :

Le modèle URDOS (Using Rules for a Dynamic Object System) proposé par [Tchounikine, 93a][Tchounikine, 93b] est un modèle qui permet l'intégration de l'activité dans une base de données orientées objet générique. Le modèle URDOS est conçu indépendamment du système de gestion de bases de données hôte tout en étant construit avec les fonctionnalités offertes par celui-ci : le modèle n'utilise pas d'autres concepts que ceux offert par le système hôte. Les règles décrivant l'activité des objets sont décrites dans des classes. A ces classes sont rattachées des méthodes permettant de créer et d'exécuter les règles. Ce schéma de classes URDOS importé dans le schéma d'une base de données orientées objet permet l'intégration de la composante activité. Ce schéma comporte une classe règles et une hiérarchie de classes événements.

Les composantes d'une règle ECA sont définies comme suit :

Pour conclure notre approche des modèles, nous allons effectuer un bref bilan sur les points forts et les points faibles de chaque modèle. Puis, nous synthétisons leurs caractéristiques (type de règles, niveau d'intégration des règles, etc.) à l'aide d'un tableau récapitulatif (cf. Tableau II.2.1).

Le modèle HiPAC est non seulement le modèle qui a introduit les règles ECA mais c'est également le modèle le plus complet au niveau des composantes (E, C et A) et de leur différents modes de couplage. De plus, le modèle HiPAC reste conforme à l'approche orientée objet puisqu'une règle est définie en tant qu'objet. La critique principale de ce modèle, mais qui demeure en dehors de nos préoccupation, est sa relative complexité de mise en oeuvre.

Le modèle de [Beeri] est un modèle tout objet basé sur des règles EA. L'intégration des règles est faite par l'ajout d'une partie active dans l'objet et de l'extension de la notion de méthode. Mais ce modèle n'a pas encore fait l'objet d'une implantation. Celle-ci risque d'être difficile à cause de l'originalité de ce modèle qui consiste à intégrer les règles au niveau des méthodes.

Le modèle EXACT est un modèle orienté objet basé sur des règles ECA. L'intérêt de ce modèle, outre l'encapsulation des règles au sein des objets actifs, est de prendre en compte la gestion des contraintes d'intégrité et la propagation d'opérations à travers le schéma d'objet.

Le modèle AO2 est un modèle orienté objet basé sur des règles ECA. Tout comme le modèle EXACT, le modèle AO2 utilise l'objet actif comme support des contraintes d'intégrité. Les seules contraintes qu'il aborde concerne la modification des valeurs des attributs.

Le modèle URDOS est un modèle orienté objet qui permet l'intégration de l'activité dans une base de données orientées objet générique. C'est le seul modèle qui est indépendant de tout système. L'événement n'est pas un message mais est la description d'un état spécifique de la base. De ce fait, ce n'est qu'après une mise à jour de la base que la sélection et le déclenchement des règles est effectué. Dans ce cas, l'activité ne peut pas convenir pour des opérations de type édition ou consultation. Les règles sont rattachées de façon dynamique aux objets actifs. Si cette approche permet à la base active d'être évolutive, elle s'avère pénalisante en terme de temps de réponse.

Tous les modèles étudiés respectent le modèle orienté objet "classique", c'est-à-dire conformément à l'état de l'art des modèles orientés objets (cf. Partie I, Chapitre 1). Tous les modèles considèrent les règles comme des objets avec néanmoins des niveaux d'intégration différents. Ainsi, les modèles de [Beeri] et AO2 font subir des transformations aux concepts objets. Le modèle de [Beeri] modifie la notion de méthode alors que le modèle AO2 sépare la partie passive de la partie active d'une classe. Les modèles HiPAC et URDOS n'intègrent pas les règles au sein des objets actifs. Cette approche n'impose pas d'ajouter des attributs spécifiques dans les objets actifs comme le font les autres modèles. Néanmoins le modèle URDOS reste le modèle le plus générique puisque ne dépendant d'aucun système orienté objet particulier.

Nous pouvons remarquer à travers le tableau II.2.1 que tous les modèles, mise à part celui de [Beeri], ont adopté les règles ECA introduites par le modèle HiPAC. Si tous les modèles ont des définitions similaires pour les composantes C et A, les définitions concernant E diffèrent. Ainsi, les modèles HiPAC, [Beeri] et EXACT définissent E comme étant l'envoi d'un message, c'est-à-dire l'appel d'une méthode. Par contre les modèles AO2 et URDOS décrivent E par le même triplet et le définissent comme étant la description d'un état spécifique de la base.

Cette étude nous a permis de mettre l'accent sur les apports et les limites des modèles actifs par rapport au modèle orienté objet COSYf bien que notre objectif ne soit pas de définir un modèle d'objet actif.

Les apports des modèles actifs concerne le fait qu'un objet actif peut activer son comportement de manière autonome. En effet, dans le modèle orienté objet COSYf le comportement d'un objet n'est activable que par l'envoi de message. Ainsi, les modèles actifs peuvent servir efficacement de support aux contraintes d'intégrité qui doivent être vérifiées de manière autonome. Néanmoins, par rapport à notre problématique de gestion de l'activité interne des documents multimédias, la définition d'un modèle de règles ECA COSYf, équivalent à ceux des modèles actifs, va nous permettre de gérer ces contraintes inhérentes à la complexité de ces documents.

Par contre, nous n'avons obtenu aucune information nous permettant d'affirmer que les modèles actifs prennent en considération les contraintes liées à l'expression de la concurrence (synchronisation, parallélisme, etc.) et qui sont nécessaires à la gestion d'informations multimédias. C'est ainsi que la définition du modèle de règles ECA de COSYf va devoir prendre en compte ces contraintes liées au multimédia. Cette définition va se baser sur l'étude des différents modèles actifs afin d'effectuer les choix pertinents au regard des avantages et des inconvénients de chaque modèle actif.

L'objectif de la section suivante est de définir les relations liées aux objets composites afin de nous aider à modéliser les documents multimédias.

Nous rappelons que notre problématique concerne la modélisation des documents multimédias. Ceux-ci, au vu de leur définition (cf. Partie I, Chapitre 1), peuvent être considérés comme des objets composites. Une première définition est de considérer un objet composite comme l'agrégation d'un ensemble d'objets appelés objets composants. L'objectif de ce chapitre va donc être de définir les différentes relations intervenant au niveau des objets composites et des objets composants.

Avant de nous intéresser à la définition de ces différentes relations, nous allons préciser le concept d'objet composite.

Si certains auteurs considèrent un objet composite (ou complexe) comme le résultat de l'application de constructeurs (ensemble, liste, ...) à des objets atomiques (entier, chaîne, etc.) [Atkinson, 89], pour notre part, nous considérons un objet composite comme une composition d'objets disjoints tel que le définit W. Kim [Kim, 89]. Nous appelons objets disjoints des objets de types hétérogènes qui ne sont pas forcément rattachés à des classes disjointes. C'est une notion sémantique, c'est-à-dire dépendante du contexte dans lequel évoluent les objets. Par exemple, une image et une séquence sonore sont deux objets de types disjoints puisque il n'existe à priori aucune caractéristique (attribut ou méthode) spécifique qui puisse être partagée par les deux objets. Or, si deux instances particulières de la classe Image et de la classe Son forment un agrégat appelé "scénario", les deux instances vont alors être traitées globalement comme une seule entité (par exemple, exécuter la méthode Edition de scénarios).

Notre définition d'objet composite est donc la suivante :

Définition : Objet Composite

Un objet composite est la composition, avec un niveau d'intégration plus ou moins fort, d'objets, que nous appelons objets composants. Ces derniers peuvent être soit des objets disjoints, soit des objets composites. Ce regroupement d'objets composants peut être ordonné par des relations temporelles et/ou spatiales.

Dans notre modèle orienté objet, la structure d'un objet est définie par des liens de composition. Mais ces liens définissent seulement une partie de la structure des objets composites que sont les relations entre l'objet composite et ses objets composants. Il également est nécessaire de prendre en compte les relations intervenant au niveau des objets composants. Celles-ci permettent notamment l'expression de relations dans le temps et/ou l'espace.

D'après notre définition précédente, un objet composite est donc définit par :

L'objectif de cette section est de définir ces différentes relations qui aident à la définition de la structure d'un objet tout comme les relations d'héritage. En effet, nous utiliserons également ces relations, qui traduisent la classification entre objets, dans notre modèle d'objets composites.

Les relations objet composite - objets composants traduisent en fait des liens de composition. Dans notre modèle orienté objet de base les attributs sont uniquement définis sur des classes. Ainsi, tout objet est un objet composite dont les composants sont définis par leurs attributs.

Toutefois, ces liens de composition qui correspondent au niveau le plus faible d'intégration entre composite et composants ne suffisent pas à exprimer toute la richesse sémantique des relations intervenant dans un document multimédia.

En effet, reprenons l'exemple de l'objet Concept (cf. Chapitre 1), celui-ci à un nom et est composé de deux objets composants Contenu et Illustration. En considérant qu'un concept a obligatoirement un contenu et que celui-ci n'est vrai que pour ce seul concept, alors l'objet composite Concept et l'objet composant Contenu ne peuvent exister l'un sans l'autre. Par contre, même si l'illustration n'est pas indispensable à l'existence d'un concept, elle est exclusivement un objet composant de l'objet composite Concept. Cet objet composant Illustration est lui-même un objet composite composé d'un dessin, de la légende associée et d'un commentaire sonore. Ces trois objets composants sont non obligatoire à l'existence de l'objet composite Illustration. Le dessin et le commentaire peuvent être attachés à d'autres objets composites que Illustration. La légende, quant à elle, peut se décliner en français ou en anglais. Dans ce cas, suivant la langue choisie, nous avons un lien de composition alternatif entre l'objet composite Légende et un des objets composants Légende_Français ou Légende_Anglais.

Nous voyons à travers cet exemple que le simple lien de composition de notre modèle orienté objet ne peut donc suffire, mais qu'au contraire, les relations entre composite et composants nécessitent une sémantique plus riche.

Nous proposons ainsi d'enrichir la sémantique attachée au lien de composition en définissant d'autres relations entre composite et composants. Certains auteurs, dont récemment [Palenque, 92] [Nicolas, 93], ont définis des relations équivalentes. Mais celles-ci, ne sont pas aussi complètes et surtout pas aussi riches sémantiquement que celles que nous définissons. Les relations que nous définissons correspondent à plusieurs modes de composition représentant différents niveaux d'intégration entre l'objet composite et les objets composants. Pour nous aider à décrire ces modes de compositions, nous utilisons le formalisme suivant, déjà introduit dans le chapitre précédent :

Chacune des relations est illustrée à l'aide de l'exemple de l'objet Concept. Nous ajoutons au lien de composition le type de la relation entre l'objet composite et l'objet composant. Seul le lien de composition de type Association n'est pas libellé, puisque c'est celui par défaut du modèle orienté objet COSYf.

Les différentes relations entre objet composite et objets composants, que nous illustrons à l'aide de l'exemple de l'objet composite Concept, sont les suivantes :

La relation Fusion (Rfu) représente le plus fort niveau d'intégration du lien de composition entre un objet composite et ses objets composants.

L'objet composite et les objets composants n'existent qu'au travers du lien de composition qui les unit. Le début, la fin et la durée des cycles de vie de l'objet composite et des objets composants sont égaux. Ainsi, la création du lien de composition implique la création à la fois de l'objet composite et des objets composants. Une fois le lien de composition établie, le composite et les composants sont indissociables : la suppression du lien de composition entraîne la suppression de l'objet composite et des objets composants.

La relation Agrégation (Rag) représente le niveau intermédiaire d'intégration du lien de composition entre un objet composite et ses objets composants.

Les objets composants n'existent qu'à travers le lien de composition. Le début et la fin des cycles de vie des objets composants sont inclus dans ceux de l'objet composite. La création du lien de composition n'implique pas la création des objets composants. Contrairement à la fusion, si le lien de composition est supprimé les objets composants sont alors supprimés, mais l'objet composite continue d'exister. A tout moment du cycle de vie de l'objet composite il est possible de créer et de rajouter un nouvel objet composant.

La relation Exclusive (Rex) est une relation d'agrégation avec la contrainte supplémentaire que les objets composants n'appartiennent qu'à un objet composite et un seul. Dans ce cas, les objets composants ne peuvent pas être inclus dans un autre objet composite.

Le début et la fin des cycles de vie des objets composants sont exclusivement inclus dans ceux de l'objet composite.

La relation Alternative (Ral) est une relation d'agrégation avec la contrainte supplémentaire que sur l'ensemble des relations d'agrégation entre l'objet composite et ses objets composants, seul une relation est valide à un instant donné.

" e Î EO, $ ! Oi=1 à n, tel que O.e Rag Oi

Exemple (cf. Figure II.2.4) : nous avons une relation alternative entre l'objet composite Légende et les objets composants Légende_Français et Légende_Anglais.

La relation Association (Ras) représente le niveau le plus faible d'intégration du lien de composition entre un objet composite et ses objets composants.

Cette relation est le lien de composition par défaut du modèle orienté objet de COSYf. Les cycles de vie de l'objet composite et des objets composants sont indépendants mais doivent exister en même temps à un instant donné de leur cycle de vie. L'existence de l'objet composite et des objets composants ne sont pas liés à l'existence du lien de composition. Ainsi, la suppression du lien de composition n'entraîne ni la suppression de l'objet composite, ni celle des objets composants.

Si nous synthétisons l'exemple de l'objet Concept, l'ensemble des relations Composite - Composants (cf. Figure II.2.6) relatif à cet objet est le suivant :

Après avoir défini les relations entre objet composite et objets composants, il nous reste à étudier les relations intervenant au sein d'un même objet composite, c'est-à-dire entre ses objets composants.

Dans le cadre de documents multimédias, la gestion des relations inter-composants peut faire appel à des mécanismes sophistiqués comme par exemple la synchronisation d'une séquence sonore et de l'affichage d'un texte. Avec l'essor de la technologie du multimédia, de plus en plus de travaux se rapportent à l'étude de ces relations.

Ainsi, les travaux de [Nah, 92] ont mis en avant certaines relations dynamiques spatio-temporelles tant au niveau des classes qu'au niveau des instances. Le modèle proposé définit ainsi les structures conceptuelles et les structures de présentation persistante des objets. Ces dernières sont relatives à l'intégration des données multimédias. En ce qui concerne les relations temporelles, les travaux de [Little, 93] ont permis de définir une spécification formelle et un modèle pour le stockage dans une base de données de données multimédias dépendantes du temps. Ce modèle est complété par des algorithmes permettant la restitution de telles données. Par rapport à notre problématique, ces travaux nous apparaissent trop spécifiques et limités. En effet, le modèle de [Nah, 92] ne permet pas de prendre en compte l'aspect dynamique des objets, c'est-à-dire l'activité d'objet. Quant au modèle de [Little, 93], il se limite d'une part aux données multimédias et non aux documents multimédias et d'autre part aux relations temporelles.

Nous avons élaboré une typologie des relations entre les objets composants d'un objet composite en séparant les relations temporelles des relations spatiales.

Pour nous aider à décrire ces différentes relations, nous utilisons le formalisme suivant :

Lors de la définition de ces relations, l'expression "traitement d'un objet" signifie tout simplement l'appel d'une méthode de cet objet. Ces différentes relations n'ont véritablement d'intérêt que lors de la présentation (ou restitution) de l'objet composite. Mais celles-ci peuvent être nécessaires à d'autres traitements, c'est-à-dire à d'autres méthodes, comme par exemple la mise-à-jour simultanée de deux objets composants. C'est la raison pour laquelle le concepteur doit préciser si les relations inter-composants sont ou ne sont pas applicables à tous les traitements.

Les relations temporelles décrivent la position des objets composants les uns par rapport aux autres dans une échelle de temps. Nous considérons seulement deux relations qui sont la relation Séquence et la relation Synchronisation.

La relation Séquence (Rsé) implique un séquencement continu, c'est-à-dire sans intervalle de temps, entre le traitement des objets composants.

Ainsi, Rsé (O1, O2, ..., On) signifie que l'objet i-1 est traité directement avant l'objet i dans le temps, sans intervalle de temps entre les deux. C'est-à-dire que la fin du traitement de l'objet i-1 coïncide avec le début du traitement de l'objet i.

La relation Synchronisation (Rsy) signifie que les objets composants sont traités simultanément.

Plus précisément, Rsy (O1, O2, ..., On) implique que le début du traitement de chaque objet Oi, avec i allant de 1 à n, soit exécuté en parallèle.

Avec ces deux simples relations, il est possible de représenter d'autres relations plus complexes. Pour cela, il suffit d'utiliser une instance de la classe Intervalles définie dans notre modèle orienté objet (cf. Chapitre 1).

Les relations spatiales concernent seulement les relations persistantes, c'est-à-dire les relations non dépendantes de l'interface utilisateur. Ces relations ne s'appliquent évidemment pas à des objets de type audio, contrairement aux relations précédentes qui peuvent faire intervenir des d'objets de tous types.

La relation Spatiale (Rspn) décrit la position des objets composants les uns par rapport aux autres dans un espace de dimension n.

Ainsi, Rsp1 (O1, O2, ..., On) signifie que l'objet i-1 précède l'objet i sur une échelle spatiale à une dimension.

Pour chacune de ces relations, nous allons les illustrer à l'aide de l'exemple de l'objet composite Concept. Pour cela il nous faut utiliser un formalisme graphique : celui qui nous apparaît comme le plus adéquat est le diagramme de comportement des classes.

Pour formaliser les relations inter-composants nous utilisons le diagramme de comportement car ces relations sont liées aux méthodes. Même s'il s'agit des relations inter-composants, nous faisons apparaître l'objet composite, puisque c'est lui qui est l'initiateur de l'événement déclenchant la relation entre les objets composants (cf. § 3.1).

Nous devons compléter ce diagramme par :

Si nous reprenons l'exemple précédent de l'objet composite Concept nous considérons alors les relations, définies par le concepteur, entre ses objets composants :

Le diagramme de comportement de l'objet composite Concept (cf. Figure II.2.9a) devient :

Quelque soit la méthode de l'objet Illustration (ce qu'indique l'étoile à la place du nom d'une méthode dans l'ovale), toutes les méthodes (ce qu'indique l'étoile à la place du nom du message sur la flèche) des objets composants sont traitées simultanément. Si nous avions voulu qu'indiquer le comportement de l'objet Illustration par rapport à la restitution, nous aurions obtenu le diagramme de comportement suivant (cf. Figure II.2.9b) :

Dans le cadre de cette section, nous nous sommes basé sur le concept d'objet. En réalité, le concepteur utilisera les classes plutôt que les objets.

A partir de l'assimilation des documents multimédias comme des objets composites, l'objectif de cette section a été de définir :

A travers cette étude, nous remarquons que les relations liées aux objets composites peuvent être complexes. Cette complexité est liée à la richesse sémantique des entités du monde réels que ces objets composites représentent. Une fois ces relations définies, la problématique suivante concerne la prise en compte de ces relations dans notre modèle. Cette modélisation des relations implique que notre modèle garantisse l'intégrité sémantique des objets composites.

C'est pour cette raison, que nous considérons ces différentes relations intervenant dans la définition d'un objet composite comme des contraintes d'intégrité. Une contrainte d'intégrité est un ensemble de clauses destinées à vérifier la pertinence des traitements (création, modification, restitution, etc.) effectués sur un objet.

Notre approche permet non seulement de prendre en compte les contraintes relatives aux relations liées aux objets composites, mais également les autres types de contraintes d'intégrité applicables à un objet. Notre approche se veut donc uniforme quant à la modélisation de ces contraintes d'intégrité qui permettent d'assurer la cohérence des objets à travers la définition de notre modèle de contraintes.

Notre approche des documents multimédias considérés comme des objets composites, nous a permis de définir les différentes relations liées aux objets composites. Afin de prendre en charge toutes les contraintes liées à un objet, nous traduisons également ces relations par des contraintes d'intégrité.

La première étape va donc consister à définir comment vont être gérés et intégrés les contraintes d'intégrité dans notre modèle orienté objet. En effet, devons-nous intégrer les contraintes d'intégrité au sein des objets composites ou en faire des objets indépendants ? Ensuite, devons-nous définir de nouveaux concepts objets ou utiliser ceux existants pour gérer ces contraintes ? Notre solution consiste à définir notre propre modèle de règles ECA COSYf.

Une fois la problématique de la gestion des contraintes posée avec la définition de ce modèle de règles ECA COSYf, l'étape suivante nous amène à définir notre modélisation des documents multimédias. Nous devons pour cela définir un modèle de contraintes intégrant les différentes contraintes liées aux objets composites (cf. § 2) à l'aide du modèle de règles ECA COSYf.

La première étape de notre problématique nous conduit à préciser à quel niveau de notre modèle orienté objet introduire les contraintes d'intégrité.

Dans le cas particulier de documents multimédias qui sont des informations fortement structurées, l'entité racine décrit la composition d'entités disjointes. Dans le contexte d'une approche orientée objet, il semble naturel d'intégrer à l'objet composite toutes les informations concernant sa composition et en particulier les contraintes d'intégrité (intra objet composite). Ceci évite de dupliquer ces informations dans chacun des objets composants. Ainsi l'ajout ou la suppression d'un objet composant nécessite seulement de modifier les informations contenues dans l'objet composite. De plus, cette solution garantit une meilleure cohérence de l'objet composite car les objets composants ne peuvent être atteints qu'à partir de la racine de la composition.

Au contraire, les travaux de [Tchounikine, 93b] préconisent de gérer les contraintes hors des objets afin de préserver l'intégrité et la réutilisabilité des objets. Cette approche, qui s'avère pénalisante en terme de la complexité des liens à gérer entre contraintes et objets, est contradictoire par rapport au fait que les contraintes modélisent des propriétés comportementales des objets et ne se trouvent pas encapsulées dans les objets. Cette approche est également partagée par certains auteurs [Escamilla, 90] [Nguyen, 93] [Rieu, 91] qui affirment que les méthodes peuvent ne pas être encapsulées dans les objets, mais être des classes à part entière. Malgré des avantages indéniables dans certains domaines comme la Conception et la Fabrication assistés par Ordinateur, nous ne partageons pas cette démarche qui à notre sens est une déviation par rapport à l'intégrité sémantique de l'objet représentant une entité du monde réel.

Ayant ainsi précisé où introduire les contraintes d'intégrité, nous devons préciser comment les introduire. La solution la plus logique dans une approche orientée objet est d'introduire ces contraintes au sein des méthodes de l'objet composite. En effet, il y a une adéquation entre les méthodes qui spécifient le comportement des objets et les contraintes d'intégrité qui assurent la cohérence du comportement des objets composites

Cette approche, simple à mettre en oeuvre, présente les inconvénients principaux suivants :

A partir de cette première analyse de la gestion des contraintes d'intégrité, nous formulons les hypothèses suivantes :

C'est face à ces hypothèses que nous avons orienté notre choix vers le concept d'objet actif, c'est-à-dire vers un modèle de règles ECA. L'atout principal d'un modèle de règles ECA est que ces règles sont indépendantes des méthodes ce qui permet de disposer de plus de flexibilité pour activer celles-ci.

Le concept d'objet actif (cf. § 1.) permet de gérer les contraintes d'intégrité. Nous allons nous baser sur cette même démarche afin de modéliser les différentes contraintes qui spécifient le comportement des objets composites. En effet, l'invocation d'une méthode d'un objet composite est un événement qui déclenche différentes actions correspondant à l'expression des différentes contraintes d'intégrité liées à cet objet.

Un modèle de règles ECA définit principalement la sémantique des trois composantes ainsi que leur intégration dans le modèle orienté objet. En effet, une des hypothèses que nous avons formulées précédemment spécifie que le modèle de règles ECA doit être totalement intégré au modèle orienté objet et ne dépendre en aucun cas du système. Ceci permet de concevoir un modèle générique et autonome.

Une règle Evénement-Condition-Action (ECA) a la signification suivante :

Nous allons donc nous attacher à définir ces trois composantes. Pour chacune de ces trois composantes nous allons seulement préciser nos choix. Ces choix sont effectués en fonction des travaux du domaine que nous ne détaillons pas ici car nous l'avons effectué auparavant (cf. § 1. L'Activité d'Objet).

La composante événement est le fait déclencheur de la règle : c'est un fait qui se produit dans le schéma de classes et auquel la règle réagit. Les événements se trouvent donc liés aux objets et plus précisément aux différents états qu'ils peuvent prendre. Le premier état d'un objet est sa création et son dernier état sa suppression. Les autres états correspondent à des modifications ou à des consultations de l'objet. Comme les méthodes sont le seul moyen de modifier la vie et l'état d'un objet, nous considérons que tout événement est relatif à la manipulation d'un objet.

Définition : Evénement

Un événement correspond au message d'activation d'une méthode de l'objet composite auquel se rapporte la règle.

Dans notre modèle nous ne gérons pas d'une façon particulière les événements relatifs au temps. En effet, le temps ne fait que retarder ou plutôt préciser la manipulation d'un objet. Ainsi, pour exprimer un événement temporel il suffit d'employer un objet temporel de notre modèle orienté objet qui enverra au moment voulu un message d'activation d'une méthode.

A partir de ces événements, il est possible de spécifier des compositions d'événements. De façon similaire aux objets composites, une composition d'événements implique différentes relations entre les composants. En effet, une composition d'événements n'est pas une simple collection d'événements mais au contraire nous avons vu que la composante événement est équivalente à une expression logique : si l'événement est vrai alors la règle est actionnable. Cela nous impose de définir quels sont les opérateurs logiques utilisables dans l'expression logique que constitue la composition d'événements : ce sont les opérateurs de conjonction et de disjonction.

En fait, une conjonction de n événements correspond à un appel synchronisé de n méthodes des n objets composants. Ceci implique qu'il y ait une relation de synchronisation entre ces n objets. Or, cette relation est déjà traitée par une contrainte équivalente à la relation Rsy (cf. § 2.). Quant à la disjonction de n événements, elle implique une relation d'alternative entre les n objets, et est donc déjà traitée par la relation Ral. Nous voyons donc qu'au sein d'un objet composite, nous ne pouvons pas avoir de compositions d'événements.

Dans notre modèle de règles, le couplage entre l'événement et la condition est immédiat. C'est-à-dire que dès la détection d'un événement, la condition correspondante est évaluée. Notre choix se justifie par rapport aux documents multimédias. En effet, si nous devons restituer en parallèle une illustration graphique et le commentaire correspondant, la contrainte d'intégrité spécifiant cette relation de synchronisation doit être vérifiée dès la restitution du document multimédia, et non pas après.

Alors que la composante événement détermine si une règle est activable, le rôle de la composante condition est de déterminer si la règle est actionnable. En fait, la condition est une expression logique binaire dont les éléments peuvent être relatifs soient à des objets composants, soient à des objets externes à l'objet composite. Contrairement à la composante événement, la composante condition peut également être une composition de conditions, c'est-à-dire une expression logique n-aire.

Définition : Condition

Une Condition est une expression logique dont les éléments correspondent à des messages d'activation de méthodes d'objets composants de l'objet composite, auquel se rapporte la règle, ou d'objets externes.

La composante action permet de décrire l'ensemble des opérations à exécuter si la condition est vérifiée. En fait, elle correspond à l'exécution de la contrainte d'intégrité liée à l'objet composite. En d'autres termes, l'action définit non seulement les méthodes à exécuter, mais également l'ordre d'exécution de ces méthodes. En effet, si il y a une relation de séquence entre les objets composants d'un objet composite, la composante action, conformément à la contrainte de séquencement, appelle successivement les méthodes des objets composants. Ces méthodes peuvent correspondre soient à des méthodes de l'objet composite, soient à des méthodes des objets composants.

Définition : Action

Une Action correspond à un ensemble ordonné de messages d'activation de méthodes de l'objet composite et/ou d'objets composants de l'objet composite auquel se rapporte la règle .

Maintenant que nous avons défini notre propre modèle de règles ECA, l'étape suivante consiste à l'intégrer à notre modèle orienté objet afin de définir notre modèle de contraintes.

Notre objectif est de définir un modèle permettant de représenter les classes composites en tenant compte des différentes contraintes d'intégrité qui leur sont liées. Nous gérons chacune de ces contraintes à l'aide de règles ECA. Il nous faut tout d'abord intégrer les règles ECA au modèle orienté objet COSYf.

Notre proposition est de définir un modèle de règles totalement intégré dans notre modèle orienté objet. Les règles sont spécifiées dans des classes dédiées à leur gestion. Ainsi, une classe de règle permet de définir les trois composantes d'une règle ECA. Pour rester cohérent par rapport à notre modèle orienté objet où toutes les classes de base sont des métaclasses, nous définissons également les classes de règle à l'aide de métaclasses (cf. Figure II.2.10). Chaque métaclasse correspond donc à une contrainte générique. Pour rattacher des classes de règle aux classes composites, le concepteur n'utilise pas directement les métaclasses. En effet, il doit commencer par créer une classe de règle à partir des métaclasses. Cette approche permet de limiter les répercussions d'une modification d'une classe de règle sur l'ensemble des classes. De plus, toutes ces métaclasses sont génériques car elles ne précisent pas les classes auxquelles s'appliquent les classes de règles.

Par rapport à une classe de règle, les composantes d'une règle ECA se définissent par :

Nous notons que ces classes de règle contiennent seulement la spécification des actions et non leur définition. Cette approche permet de réduire considérablement le travail de modification d'une contrainte. En effet, en cas de modification, il suffit simplement de modifier la classe de règle et non toutes les méthodes des classes composites ou des classes composantes. Prenons l'exemple de la contrainte de fusion, relative à Rfu. Toute redéfinition de la sémantique attachée à cette contrainte implique uniquement une modification de la composante Action de la classe de règle. Ainsi, il suffit de redéfinir l'ordonnancement des messages d'activation de méthodes et non les méthodes elles-mêmes.

Notre modèle de règles ECA définit donc chaque règle, correspondant à une contrainte générique, par une métaclasse. De ce fait, chaque contrainte traduisant une relation liée à une classe composite est définie par une métaclasse correspondant à une règle ECA : ce sont des métaclasses de contrainte. Toutes ces métaclasses de contraintes héritent d'une classe mère qui définit la structure et le comportement commun à chacune d'elles : c'est la métaclasse Contrainte (cf. Figure II.2.11). Seule la contrainte traduisant la relation d'Association n'est pas traduite par une métaclasse de contrainte. En effet, cette relation est le lien de base du modèle orienté objet COSYf.

Nous avons ainsi défini une hiérarchie de métaclasses génériques représentant les différents cas de contraintes liées aux classes composites. Chacune de ces métaclasses représente une contrainte spécifique soit entre classes composites et classes composantes, soit entre classes composantes. Ces métaclasses sont génériques en ce sens qu'elles ne précisent pas les classes manipulées.

Afin que notre modèle de contraintes prenne en compte les autres types de contraintes d'intégrité applicables à un objet, il nous faut définir une métaclasse de contrainte générique. Or, cette métaclasse existe déjà : c'est la métaclasse Contrainte qui est au sommet de la hiérarchie des classes de contraintes. Donc, pour créer une classe de contrainte d'intégrité spécifique, le concepteur doit établir un lien d'héritage avec la métaclasse Contrainte et définir les composantes Condition et Action.

Dans cette section, nous allons présenter la manière d'utiliser notre modèle de contraintes afin de modéliser les documents multimédias. Ainsi, lorsque le concepteur a défini les relations liées à une classe composite, il lui faut créer les classes de contraintes correspondantes aux relations.

Pour créer une classe de contrainte, il suffit d'instancier une métaclasse de contrainte du modèle. Une fois les classes de contraintes créées, il est possible d'utiliser la relation d'héritage afin de créer des classes de contraintes plus spécifiques ou des classes multi contraintes grâce au principe d'héritage multiple. C'est également à partir de ce niveau de classes de contraintes, que le concepteur peut préciser les classes manipulées, c'est-à-dire les classes sur lesquelles portent les contraintes.

Le fait de pouvoir créer des classes de contrainte spécialisées permet d'instaurer différents niveaux d'abstraction d'une contrainte, c'est-à-dire de pouvoir spécialiser une contrainte d'intégrité. Cela est rendu possible grâce à la possibilité que donne la relation d'héritage de pouvoir spécialiser toute méthode qu'une classe hérite de sa super classe. Le sommet de cette hiérarchie de classes de contraintes est la classe générique la plus générale et une feuille de cette arborescence est une classe spécialisée. Une classe de contrainte spécialisée permet ainsi de préciser les contraintes d'intégrité proposées par notre modèle à travers les métaclasses de contraintes.

Les classes multi-contraintes permettent de regrouper dans une même classe de contraintes toutes les contraintes liées à une classe composite.

Pour définir une contrainte au niveau d'une classe composite, il suffit d'utiliser la relation d'héritage entre la classe composite et la classe de contrainte. De ce fait, toute classe composite hérite d'une classe de contrainte.

Ainsi, les méthodes publiques d'une classe composite sont définies à l'aide de méthodes héritées de la super classe de contrainte. Tout appel d'une méthode publique d'une classe composite déclenche lui-même l'appel d'une méthode publique d'une instance de la classe de contrainte. Les conditions et actions sont définies dans la classe de contrainte. Celles-ci permettent seulement d'ordonnancer l'appel des méthodes de la classe composite ou des classes composantes. En effet, la définition des méthodes n'est pas spécifiée dans ces classes de contraintes, mais dans les classes composites elles-mêmes.

Si une classe composante est elle-même une classe composite, le message d'activation d'une méthode de la classe composante constitue indirectement un événement pour la classe de contrainte associée à la classe composante. L'appel est indirect puisque le message d'activation d'une classe de contraintes est situé dans le corps de la méthode de l'objet composant.

A titre d'exemple, nous allons reprendre quelques relations de l'exemple précédent de la classe composite Concept. Nous ne retenons que les relations indiquées sur le diagramme des liens de composition (cf. Figure II.2.12) et sur le diagramme de comportement (cf. Figure II.2.13) de la classe Concept.

Le concepteur doit, à partir des métaclasses de contraintes, instancier les classes Fusion_Unaire, Exclusive_Unaire et Séquence_Ternaire afin de concevoir la classe Concept (cf. Figure II.2.14).

De ces différents formalismes graphiques, nous en déduisons les formalismes textuels (partiels) correspondant aux classes Fusion_Unaire (cf. Figure II.2.15), Exclusive_Unaire (cf. Figure II.2.16), Séquence_Ternaire (cf. Figure II.2.17) et Concept (cf. Figure II.2.18). Tous ces formalismes textuels ne sont pas complets car nous n'avons formalisé que les éléments pertinents.

Figure II.2.15 : Formalisme textuel partiel du schéma de la classe Fusion_Unaire

Figure II.2.16 : Formalisme textuel partiel du schéma de la classe Exclusive_Unaire

Figure II.2.17 : Formalisme textuel partiel du schéma de la classe Séquence_Ternaire

Figure II.2.18 (suite) : Formalisme textuel partiel du schéma de la classe Concept

Si nous essayons de repérer les composantes E, C et A de la contrainte Séquence nous obtenons :

Comme la classe composante Illustration est elle-même une classe composite, chaque message d'activation de la classe Illustration constitue indirectement (cf. § 3.3.3.2) un événement pour une classe de contrainte associée à la classe Illustration.

L'objectif de cette section a été de proposer une modélisation uniforme des différentes contraintes d'intégrité liées aux objets composites qui permettent d'assurer leur cohérence. Nous avons ainsi défini un modèle de classes de contraintes qui permet de spécifier des règles ECA [Merlet, 93b] [Nadalin, 93a] [Nadalin, 93b].

Notre modèle de classes de contraintes consiste à définir un ensemble de métaclasses génériques organisées hiérarchiquement. Chaque métaclasse représente un type de contrainte d'intégrité traduisant une relation :

Ce modèle de contraintes permet également de prendre en compte les autres types de contraintes d'intégrité applicables à une classe.

L'élaboration de notre modèle de classes de contraintes permet au concepteur de modéliser la structure et le comportement des différents objets composites, et notamment les documents multimédias, qu'il conçoit. En effet, notre modèle permet de prendre en compte d'une part la structure hiérarchique complexe de tout document et d'autre part les relations spécifiques liées aux informations multimédias.

Mais cette seule modélisation des documents multimédias ne saurait suffire. En effet, l'accès aux informations est un aspect important des systèmes de formation. L'interactivité offerte par le concept d'hypermédia aux utilisateurs leur donne la possibilité de naviguer dans le réseau de documents multimédias.

L'étape suivante dans l'élaboration de notre méthode de conception orientée objet de systèmes de formation multimédia, concerne donc la modélisation d'hyperdocuments multimédias éducatifs.