Nous désignons par système d’évolution l’ensemble des mécanismes permettant de définir et d’exploiter l’évolution des concepts d’un modèle de données. Le système d’évolution de
SHOOD est défini par un ensemble de concepts (opération, règle, stratégie) et de mécanismes
sous-jacents (classification, règles actives, héritage) permettant la définition et l’exploitation de ces concepts.
Ce système d'évolution est bien adapté aux systèmes dits “extensibles”, où les concepts et leurs évolutions respectives ne sont pas figés [Cointe87]. Ces règles et stratégies d’évolution permettent, en effet, d'étendre le modèle par de nouveaux concepts et d’adapter les opérations de manipulation existantes à cette extension.
Les systèmes où tout est statique et prédéfini n'ont besoin d'exprimer ni des stratégies multiples, ni des règles de manière déclarative. Il n’y a qu’une stratégie d'évolution imposée à
D
D
toutes les classes. Cette approche n'offre pas la possibilité au programmeur d'exprimer plusieurs stratégies et d'activer à tout moment la stratégie la plus adéquate pour l'application. Par exemple, dans SHOOD, la suppression d’une classe entraîne le rattachement de ses instances aux super-classes. C’est une sémantique par défaut. Il faudrait pouvoir exprimer, pour certains types de classes ou pour certaines applications, que la suppression d’une classe entraîne la suppression de ses instances.
Une sémantique d'évolution d’un concept est souvent exprimée dans le langage hôte (langage d'implémentation du système), noyée dans le code du système (non accessible à tout programmeur), au mieux dans le code des méthodes, et le programmeur se voit confronté au problème d’extension. En effet, dans un système extensible, l'ajout de nouveaux concepts entraîne souvent, d'une part, la mise en œuvre des opérations de mise à jour permettant de faire évoluer les concepts, et d'autre part, la modification des opérations de mise à jour existantes pour tenir compte de l'évolution des concepts ajoutés. Il serait intéressant de rajouter ces fonctionnalités plus aisément. Par exemple, lors de l'ajout du concept d'événement, il faut rajouter les opérations manipulant ce concept (suppression, modification) ; il faut aussi modifier la sémantique d'évolution d'une méthode (si le nom d'une méthode change, celui de l'événement associé à son exécution change aussi) (cf. Chapitre 7).
Tenant compte des problèmes cités ci-dessus, le système d'évolution doit être caractérisé par les propriétés décrites ci dessous.
Propriétés
Convivialité : Possibilité d'exprimer les règles d'évolution de classes et d'instances de manière déclarative. Le système d'évolution doit permettre, à travers la syntaxe des règles d'évolution, d’exprimer des règles d'évolution de schémas, des contraintes d'intégrité, des calculs inférentiels et tout autre comportement entraînant l'évolution des informations manipulées par le système.
Extensibilité : On doit pouvoir rajouter de nouvelles fonctionnalités (règles ou opérations d'évolution) assez facilement sans altérer les fonctionnalités existantes. Le système ne doit pas être fermé, l'ensemble des opérations doit pouvoir être étendu à tout moment. De même, il doit être possible de redéfinir la sémantique des opérations existantes.
Multi-Stratégie : Possibilité de définir plusieurs stratégies d'évolution d'un concept ; aucune stratégie n’est imposée. En effet, il sera possible d'exprimer plusieurs stratégies, mais une seule sera activée à un instant donné.
Par exemple : lors de la suppression d’une classe, plusieurs possibilités se présentent : soit supprimer les instances, soit les rattacher aux super-classes de la classe supprimée, soit refuser tout simplement la suppression de la classe. Ces trois possibilités représentent trois stratégies d’évolution d’une classe ; chacune d’elles pourra être utilisée à des moments distincts.
Complétude : L'ensemble des fonctionnalités doit permettre de faire évoluer tous les concepts du modèle de données, quelle que soit la portée de la modification. L'ensemble des opérations accessibles ne doit pas être restreint, par exemple, uniquement aux opérations de mise à jour. Les opérations peuvent être des méthodes de l'application (par exemple, pour l'expression des contraintes). De plus, avec la propriété d’extensibilité, ces fonctionnalités peuvent toujours être complétées ; le système n'est pas figé.
Cohérence : Cette évolution ne doit pas introduire d'incohérence dans la base de connaissances. En effet, à l’exécution d’une opération de manipulation, le système doit vérifier le respect des invariants du modèle et éventuellement réaliser les propagations nécessaires pour maintenir la cohérence des connaissances.
Dans ce système, nous ne prenons en compte que les cohérences structurelles, les cohérences comportementales constituant à elles seules un sujet de recherche. Par exemple, lors de la suppression d’un attribut, le code des méthodes utilisant cet attribut (exemple : une projection) n’est jamais remis en cause alors qu’il devrait l’être.
Uniformité : Toute évolution doit s'écrire de manière uniforme pour les différents concepts du modèle (classe, métaclasse, instance). En effet, dans ce système, les règles d'évolution (cf. Chapitre 8) des classes et des instances ne sont pas séparées car c'est la sémantique des opérations qui fait la différence.
Architecture
Pour exprimer et mettre en œuvre l'évolution dans le système SHOOD, celui-ci dispose de plusieurs moyens complémentaires qui peuvent être des moyens de base, tels que les opérations de manipulation des classes, ou des moyens plus complexes, tels qu'un mécanisme de règles actives [Bounaas94a] [Bergues94], un mécanisme de classification d’instances [Bounaas94b], ou tout simplement les règles et les stratégies d'évolution définies dans le chapitre 8. Afin de mieux comprendre les liens entre ces différents mécanismes, nous proposons l'architecture suivante pour le système d'évolution :
Support d'évolution (1) Autres mécanismes (3) Classification (2) Règles et Stratégies d'évolution (5) Règles ECA (4)
Figure 4-1 : Architecture du système d'évolution
• Le support d'évolution (1) est constitué de l'ensemble des opérations manipulant les concepts de base du modèle SHOOD (cf. 4.2). Ces opérations sont munies d'une sémantique minimale par défaut. Par exemple, l’opération de suppression d’une classe a pour rôle de supprimer les attributs propres, de retirer ses instances (rattachées aux super-classes) et de supprimer physiquement cette classe. D’autres contrôles sont réalisés par des règles d’évolution (voir (5)).
• Au dessus de ce support d'évolution, des mécanismes ont été construits (3) tels que le mécanisme de classification d'instances (2) [Liotard93] et celui de génération de structures significatives [Favier90]. Ces mécanismes sont “câblés” et ne peuvent être modifiés ou étendus facilement.
• Au dessus du support d'évolution, nous avons construit également un mécanisme de règles
ECA (4) (cf. Chapitre 7) qui permettra la mise en œuvre du mécanisme de règles et de stratégies d’évolution, et qui offre, de plus, la possibilité d'exprimer des sémantiques d’évolution de concepts. En effet, les règles actives constituent elles-mêmes un outil permettant l'expression et la mise en œuvre des contraintes d'intégrité [Bouaziz95] et des règles d'évolution de schéma [Ahmed-Nacer94] [Bounaas95c]. De plus, nous verrons dans le chapitre 7 une utilisation des règles ECA pour exprimer l’évolution de schémas ou d'instances. Bien que ces règles permettent d'utiliser toute la puissance du modèle actif (lien d'inhibition, désactivation des règles etc.), les règles d'évolution permettent une expression plus abstraite et offrent la possibilité d'utiliser les stratégies d'évolution.
• Le support d'évolution peut être étendu par un ensemble de stratégies (5) où une stratégie est composée d’un ensemble de règles d'évolution (cf. Chapitre 8) [Bounaas95d]. Par exemple, pour la suppression d’une classe, on définit une règle d'évolution qui interdit la suppression si cette classe est utilisée par un domaine d’attribut. Cette règle pourra être redéfinie ou désactivée.
Il sera possible d’élaborer une bibliothèque de stratégies contenant les sémantiques usuelles des opérations de manipulation ; elle permettra à l’utilisateur de choisir la stratégie la mieux adaptée à son application. L’utilisateur pourra redéfinir la stratégie choisie, en ajoutant ou en redéfinissant les règles d’évolution. Il sera libre de choisir la manière dont ses connaissances devront évoluer. Cette redéfinition de stratégies permet une meilleure réutilisation des règles d’évolution. De plus, toute stratégie définie par l’utilisateur peut être elle-même redéfinie.
Dans la suite, nous allons décrire le support d’évolution qui représente la stratégie par défaut du système d’évolution.