= Nom_classe Attributs Avion_affaire No_immat = = Nom_classe Attributs Avion_ligne No_immat = = No_imat = F-GBPX No_imat = F-GBPX avion1 avion2 : Lien d’instanciation : Lien de spécialisation : Lien de disjonction Figure 5-8 : La disjonction
La relation de disjonction interdit une instance d'appartenir à deux classes disjointes. Autrement dit : si I est rattachée à une classe C ou à une de ses sous-classes, alors elle ne peut être rattachée aux classes disjointes de C ou à leurs sous-classes. En revanche, un objet du monde réel peut être modélisé par deux objets informatiques instanciant des classes disjointes. Nous définissons la règle 3 :
Règle 3 : Soit I une instance appartenant à une classe C. I ne peut pas appartenir à une
classe disjointe C', mais une instance I', générée à partir de I, peut appartenir à C' (et pas à C ).
5.5 CONTEXTE DE VIE
La classification a produit plusieurs instances rattachées à des classes et modélisant les connaissances connues ou inférables d'un objet du monde réel. L'utilisateur choisit une ou plusieurs instances qu'il juge les plus représentatives. Pour chaque instance, les classes de rattachement proposées par la classification sont les classes possibles les plus spécialisées (Figure 5-9). Elles constituent le "contexte de vie" maximal de l'instance. Ces classes n'étant pas forcément les plus significatives, l'utilisateur peut choisir un contexte de vie plus restreint pour chaque instance choisie. Un contexte de vie d'une instance est constitué d'un sous ensemble des classes possibles, au sens de la multi-instanciation (invariant I.I.5). Toutes les combinaisons ne sont cependant pas possibles. En effet, pour respecter l'invariant I.I.5 l'instance doit, en particulier, pouvoir justifier ses valeurs. Elle doit donc appartenir directement, dans le cas des attributs à valeur dépendante, ou indirectement dans celui des attributs à valeur unique, aux classes où ses valeurs ont été inférées.
Si une classe C est possible pour I, alors une super-classe C' de C est un contexte de vie possible pour I, si I peut justifier ses valeurs dans C'. Dans le cas où C' est impossible pour I alors il existe une autre instance I', génératrice de I, qui est rattachée à C'. Dans la Figure 5-9, la classe Aéronef_ailé est impossible pour avion3 mais possible pour avion1, car l’autonomie
est un attribut sans valeur dans la classe Aéronef_ailé. De même, si deux classes (C1 et C2) constituent un contexte de vie possible pour I, alors C1 est un contexte de vie possible pour I, si cette instance justifie ses valeurs dans C1. La classe Avion_tourisme est un contexte de vie possible pour avion2 (Figure 5-9).
Aéronef_ailé Avion Avion_ligne
Avion_affaire Avion_tourisme nb_passagers =4 masse_max = 2300 autonomie = 4 nb_passagers =4 masse_max = 2300 autonomie = 4 autonomie = () avion1 avion3 avion2 : Lien d’instanciation : Lien de spécialisation
Figure 5-9 : Contexte de vie
Ecran 5-1 : Choix d’un contexte de vie
l'ensemble des instances parmi toutes celles générées (les autres instances sont détruites) et un contexte de vie pour chaque instance [Liotard93] (Ecran 5-1).
5.6 CONCLUSION
Dans ce chapitre, nous décrivons un mécanisme de classification d'instances prenant en charge l'insertion et l'évolution simultanée des différentes représentations d'objets incomplets, incohérents et multi-inférables. L'objet à classifier est complété en utilisant les inférences existantes dans le graphe de recherche. Du fait de la multiplicité des inférences, la classification propose plusieurs solutions matérialisées par des instances différentes.
Les connaissances initiales détenues sur l’objet peuvent être assimilées à l’énoncé d’un problème à résoudre. La classification peut alors être perçue comme un mécanisme de résolution de problème délivrant plusieurs solutions (les différentes instances provisoires). Ce mécanisme de résolution utilise des connaissances inhérentes au domaine d’application (la hiérarchie de classes) et des connaissances inhérentes à leur utilisation dans le contexte applicatif (attribut obligatoire/facultatif, à valeur unique/ dépendante, etc.). Pour l’instant, dans le modèle SHOOD, les connaissances du domaine d’application et celles inhérentes à leur utilisation sont confondues. Nous envisageons de les séparer afin de permettre une meilleure réutilisation des connaissances.
Une extension possible du mécanisme présenté dans ce chapitre est la classification des objets composites [Marino93]. Cette extension nécessitera un effort de programmation pour la modification du code actuel. En effet, ce mécanisme est aujourd’hui “câblé”, et n’offre pas la possibilité d’être étendu facilement. Cet inconvénient constitue une des motivations pour étudier l’apport de solutions aux problèmes d’extensibilité des mécanismes d’évolution existants. Pour cela, dans le chapitre 7, nous présentons un mécanisme de règles actives qui tente de résoudre les problèmes d’extensibilité, en offrant une expression déclarative de l’évolution. Nous présentons tout d’abord dans le chapitre qui suit (Chapitre 6) quelques modèles à base de règles qui nous ont servi à définir ce mécanisme de règles actives.
6. LES MODELES A BASE DE REGLES
n système actif est un système capable de détecter des situations et de réagir avec ou sans l’intervention de l'utilisateur en exécutant des actions ou des programmes. Les réactions d'un système sont généralement réalisées par des déclencheurs ou règles actives [Dayal88]. La notion de règle active est basée sur le formalisme Evénement, Condition, Action. La sémantique générale d’une règle active est la suivante “Lorsqu’un Evénement se produit, si la Condition est satisfaite, alors l’action est exécutée”.
L'objectif de ce chapitre n'est pas de présenter une liste de Systèmes à Objets Actifs (SOA), mais plutôt de justifier les choix des différents concepts du modèle actif de SHOOD. Nous verrons que le système actif (cf. chapitre 7) permet la mise en œuvre du mécanisme de règle et de stratégies d’évolution (cf. chapitre 8). Par la suite, nous ne citons que les systèmes de référence comme HIPAC, et les systèmes comme URDOS [Tchnoukine93], et NEOPUS
[Pachet92] dont nous nous sommes inspirés pour la conception de notre modèle actif. D'autres systèmes [Collet94] [Bouaziz95] [Roncancio94] [Riet89] [Simon92] modélisant des règles actives ne seront pas décrits en raison de la similitude de leur modèle avec celui d’HIPAC.