Soit C une classe possible pour l'instance en cours de classification. Pour l'attribut A1, on dispose d'une valeur inférée dans C par une inférence Inf1. Lors de l'examen d'une sous-classe
de C le problème à résoudre par le mécanisme de classification est alors : "une autre inférence (Inf2) pour l'attribut A1 doit-elle ou non être exécutée? ".
Lorsqu'il s'agit d'un attribut à valeur unique et possédant pour l'instance en cours de classification une valeur dans la classe C, la valeur est conservée dans les sous-classes de C. Autrement dit, la valeur de l'attribut reste correcte tant que l'instance appartient directement ou indirectement à la classe qui a permis de l'inférer. Aucune autre inférence rencontrée sur le même attribut ne sera donc prise en compte.
Supposons à présent, qu'il s'agisse d'un attribut à valeur dépendante et possédant une valeur dans la classe C pour l'instance à classifier. Cette instance sera impossible pour les sous-classes, car elle ne justifiera pas ses valeurs (Invariant I.I.4 et I.I.5). Nous proposons, dans les sous-classes de C détenant une inférence propre pour A1, de générer une nouvelle instance. La nouvelle instance est créée par copie de l'objet en cours de classification dont elle a les mêmes valeurs d'attributs, sauf pour l'attribut où il y a un conflit d'inférence (attribut A1). La génération de cette instance est régie par la règle suivante :
Règle 1 : Soit I une instance appartenant à une classe C et valuant un attribut A à valeur
dépendante. I ne peut appartenir à une classe C' avec la même valeur pour A, mais une instance I', générée à partir de I avec une autre valeur de A, peut appartenir à C' (mais pas à C). Nom_classe Attributs Aeronef Autonomie : Inf_user = = Nom_classe Attributs ULM Autonomie : Cal_autonomie_ulm = = No_imat =F-GBPX Autonomie = 10 Nom_classe Attributs Avion Autonomie : Cal_autonomie_avion = = No_imat = F-GBPX
Autonomie = 2 No_imat = F-GBPX Autonomie = 8 avion1
avion2
avion3
: Lien d’instanciation : Lien de spécialisation
Figure 5-5 : Multiplicité des inférences
En classifiant un Aéronef (Figure 5-5), le mécanisme trouve une première classe d'appartenance : la classe Aéronef, et affecte la valeur (10) de l'autonomie saisie par l'utilisateur. Le mécanisme continue la classification de l'instance avion1 dans les sous-classes. Les inférences Inf_user et Cal_autonomie_ulm sont en conflit. Le mécanisme de génération d'instances est alors utilisé : l'instance avion2 est générée à partir de l'instance
avion3 est générée avec une valeur pour l'autonomie inférée par Cal_autonomie_avion
(autonomie = 8).
L'utilisation de la règle 1 est correcte dans ce contexte : Il ne serait pas cohérent de garder la valeur de l'autonomie calculée dans le cas d'un ULM pour un Avion. La classification de avion1 terminée, le mécanisme tente de classifier avion2 et avion3 respectivement dans Avion et ULM. Ces deux classes étant disjointes, avion2 (respectivement. avion3) ne peut être rattaché à Avion (respectivement ULM).
5.4.2 La gestion d’un attribut sans valeur
Illustrons le problème de l'attribut sans valeur par un exemple. Nous disposons pour une personne de son nom Dupond et de sa date de naissance 1965. L'utilisateur demande à classifier cette instance à partir de la classe Personne (la modélisation suivante n'est pas forcément la plus correcte).
Nom_classe Attributs = = Personne Nom Age : Inf_user Nom_classe Attributs = = Adulte Nom Date_naissance Age : Cal_Age_Naiss Nom Date_naissance= = Dupond 1965 dupond1 : Lien d’instanciation : Lien de spécialisation
Figure 5-6 : Doit-on utiliser Cal_Age_Naiss pour l'instance dupond1?
Le mécanisme commence par la classe Personne où l'inférence associée à l'attribut âge est exécutée. L'utilisateur n'ayant pas fourni cette information, l'inférence échoue : l'attribut âge est sans valeur. Puis la classification s'effectue sur la classe Adulte. Doit-on utiliser l'inférence
Cal_Age_Naiss pour l'instance dupond1? Si on ne l'utilise pas, nous perdons l'occasion de
calculer l'âge. Mais si l'inférence est utilisée, Adulte sera une classe possible pour Dupond, mais cette dernière ne peut être rattachée à la classe Personne, car elle ne justifie pas ses valeurs dans la classe Personne.
Pour pallier ce problème, nous traitons un attribut sans valeur avec le mécanisme de génération d'instance. Lorsque de nouvelles inférences sont définies pour un attribut sans valeur, une nouvelle instance est générée. Pour ce cas, nous définissons la règle 2.
Règle 2 : Soit I une instance appartenant à une classe C et n'ayant pas de valeur pour un
attribut A. I ne peut appartenir à une sous-classe C' où A est valué, mais une instance I', générée à partir de I, peut appartenir à C' (mais pas à C).
Nom_classe Attributs = = Personne Nom Age : Inf_user Nom_classe Attributs = = Adulte Nom Date_naissance Age : Cal_Age_Naiss Nom Date_naissance= = Dupond 1965 dupond2 Age = 30 Nom = Dupond dupond1 : Lien d’instanciation : Lien de spécialisation
Figure 5-7 : Utilisation de Cal_Age_Naiss pour l'instance dupond2
Après la classification, nous avons une instance dupond1 représentant les connaissances de l'utilisateur sur Dupond. Cette instance peut être rattachée à la classe Personne. L'autre instance dupond2 représente un autre objet informatique modélisant Dupond avec un âge de 27 ans. Cet objet ne peut être rattaché qu'à la classe Adulte.
5.4.3 La disjonction
Lorsqu'une instance appartient à une classe C disjointe d'une classe C', la première idée est de dire que cette instance ne pourra jamais appartenir à la classe C'. Or le modèle SHOOD prend en compte des objets incomplets et incohérents. Une instance peut donc être rattachée à une classe avec un certain nombre d'informations incomplètes et donc pourrait être rattachée à une classe disjointe avec des informations différentes. Nous ne pouvons donc pas privilégier une classe plutôt qu'une autre. Mais l'instance ne peut pas appartenir aux deux classes disjointes qui sont globalement impossibles pour l'instance (§ 5.1 et invariant I.I.5).
Pour répondre à ce besoin, nous utilisons le mécanisme de génération d'instance vu précédemment. Lors de la classification d'une instance dans une classe disjointe d'une classe d'appartenance, nous générons un objet informatique qui représente une information différente.
Du fait de l'incomplétude des connaissances, l'avion est représenté par deux objets informatiques : avion1 vu comme un Avion_affaire et avion2 comme un Avion_ligne (Avion_affaire étant disjointe d'Avion_ligne) (Figure 5-8).
Nom_classe Attributs Avion No_immat = = 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 ).