de l’influence propagée probabiliste dépend donc du paramètre returnProba.
6.3 Validation
Le package model.validation contient les différentes classes liées à la notion de validation d’une carte cognitive, présentée dans le chapitre 3. Il a été développé différemment des définitions présentées dans ce chapitre.
Pour présenter les différentes classes de package, nous expliquons tout d’abord les différences entre les définitions et l’implémentation dans la section 6.3.1. Puis, nous présentons comment est implémentée la notion de critère de qualité dans la section 6.3.2. Enfin, nous présentons dans la section 6.3.3 comment est implémentée la gestion des conflits pour chacun des critères de qualité.
6.3.1 Approche de l’implémentation
Dans le chapitre consacré à la validation, nous avons défini de différentes manières les mêmes critères, pour leur ajouter de la souplesse ou bien pour les adapter à d’autres ensembles de valeurs. Leur structure était identique : seule la manière de comparer deux valeurs changeait. Ainsi, si on considère le critère de cohérence, il a été défini originellement avec une égalité stricte (définition 3.7), puis avec la notion de valeurs compatibles (définition 3.10) et enfin avec la notion d’intervalles compatibles (définition 3.16). Dans toutes ces définitions, la manière d’accéder aux valeurs reste la même puisqu’on compare toujours une influence taxonomique à la valeur de la contrainte. Notre implémentation a été conçue de telle manière que l’accès aux valeurs n’est codé qu’une seule fois : seule la façon de comparer les valeurs change.
Pour représenter la manière de comparer deux valeurs, nous définissons une in-terface ContradictoryValuesChecker. Cette inin-terface définit une méthode char-gée de comparer deux valeurs pour indiquer si elles sont ou non contradictoires. Ainsi, lorsque cette comparaison est une égalité, les deux valeurs sont contradic-toires si elles sont différentes. Cette méthode prend en paramètres deux valeurs ainsi que leurs ensembles de valeurs respectifs. La méthode renvoie donc vrai ssi les deux valeurs passées en paramètres sont différentes. C’est donc une fonction de va-leurs d’arité 2. Ainsi, la notion de vava-leurs compatibles pour {+, −} (définition 3.9) ne peut s’appliquer qu’à des valeurs de l’ensemble {+, ⊕, 0, , −, ?}. De la même manière, la notion d’intervalles compatibles (définition 3.15) ne peut s’appliquer qu’à des valeurs qui sont des intervalles.
La différence utilisée pour comparer des valeurs numériques (définition 3.12) ou des valeurs d’ensembles finis totalement ordonnés (définition 3.17) peut elle aussi être vue comme étant une instance de ContradictoryValuesChecker. Le diagramme de classes UML de la figure 6.11 représente les liens entre les différentes classes et interfaces représentant cette comparaison de valeurs.
L’interface DifferenceOperator représente une différence entre deux valeurs appartenant chacune à un ensemble de valeurs. Comme pour l’interface
ValueSetAlgorithm ContradictoryValuesChecker areContradictory(v1,vs1,v2,vs2):boolean DifferenceContradictoryValuesChecker threshold:double DifferenceOperator difference(v1,vs1,v2,vs2):double * 1
Figure 6.11 – Diagramme de classes liées à ContradictoryValuesChecker.
ContradictoryValuesChecker, elle dispose d’une méthode définie sur deux va-leurs permettant de calculer leur différence. C’est donc aussi un algorithme qui s’applique à deux ensembles de valeurs. La notion de seuil (définition 3.11) n’ap-paraît pas ici : on se contente simplement de renvoyer un nombre qui représente la différence entre deux valeurs. Ainsi, pour l’ensemble de valeurs [−1; 1], on renvoie la différence numérique entre les deux valeurs passées en paramètre.
La classe DifferenceContradictoryValuesChecker est basée sur la notion de valeurs compatibles selon un seuil (définitions 3.12 et 3.17). Elle représente
cepen-dant plutôt la notion de valeurs incompatibles selon un seuil, puisqu’on cherche
à savoir si deux valeurs sont contradictoires. Elle implémente donc logiquement l’interface ContradictoryValuesChecker. Le calcul de la différence est délégué à une instance de l’interface DifferenceOperator. L’attribut threshold représente le seuil. Pour savoir si deux valeurs sont compatibles, on calcule leur différence grâce au DifferenceOperator. Si le résultat de cette différence est inférieur ou égal au seuil en valeur absolue, alors les valeurs sont compatibles. Le domaine de cette fonction est le même que celui de l’opérateur de différence associé.
6.3.2 Critères de qualité
Le diagramme de classes UML de la figure 6.12 représente les liens entre les diffé-rentes classes et interfaces représentant des critères de qualité.
L’interface QualityCriterion représente un critère de qualité pour une carte cognitive. Sémantiquement, les critères de qualité doivent utiliser une instance de ContradictoryValuesChecker et comparent par conséquent deux valeurs. Cette interface introduit deux méthodes, chacune s’appliquant à l’une de ces deux va-leurs. Leur intérêt est de savoir à quel ensemble ces deux valeurs appartiennent. Si on prend l’exemple du critère de propreté (définition 3.2) on compare une valeur d’influence propagée d’un concept sur un autre à une valeur d’influence. Pour l’en-semble de valeurs {+, −}, on compare donc une valeur de l’enl’en-semble {+, 0, −, ?} à une valeur de l’ensemble {+, −}. Cette interface introduit également une méthode dédiée aux conflits, qui est présentée dans la section suivante.
L’interface Verification représente un critère de vérification. Ce type de cri-tère nécessite deux méthodes : une pour vérifier si le cricri-tère est validé ou non
6.3. VALIDATION 183 Algorithm QualityCriterion canComputeConflictsWith(params,vs):boolean getValueSet1(cm,im):ValueSet getValueSet2(cm,im):ValueSet Verification verify(params,cm):boolean getVerifConflicts(params,cm):Set Test test(params,s,cm):boolean getTestConflicts(params,s,cm):Set
Figure 6.12 – Diagramme de classes des critères de qualité.
et l’autre pour construire l’ensemble des conflits associé à ce critère. Puisque ce type de critère ne nécessite pas d’information externe, il s’applique directement sur une carte cognitive, ici le paramètre cm. Le paramètre params représente dif-férents paramètres pour la vérification. C’est en réalité une instance de la classe QualityCriterionParams qui, à la manière de la classe InfluencesManager (sec-tion 6.2.3), permet de simplifier l’écriture du code. Elle réunit un ges(sec-tionnaire d’influences, une instance de ContradictoryValuesChecker et éventuellement une spécification, pour les critères de test. Les critères de propreté (définition 3.2) et de non-ambiguïté (définition 3.4) implémentent donc cette interface.
La spécification accessible par les paramètres params permet de savoir à quelle taxonomie appartiennent les concepts de la contrainte ainsi que l’ensemble de valeurs de sa valeur. Elle est donc définie sur une taxonomie de concepts et un ensemble de valeurs. Elle dispose de méthodes permettant d’ajouter ou de retirer des contraintes. À chaque ajout, on vérifie que la contrainte est compatible avec la spécification, c’est-à-dire que ses concepts sont ordonnés par la taxonomie et que sa valeur appartient à l’ensemble de valeurs.
L’interface Test est finalement très semblable à l’interface Verification. Ses méthodes nécessitent cependant un paramètre supplémentaire, s, qui représente une contrainte. Une contrainte est définie comme étant une influence. On note que la carte cognitive en paramètre n’est pas une carte taxonomique. En réa-lité, puisque la taxonomie est accessible via les paramètres via la spécification, on construit une carte taxonomique en unifiant cette taxonomie et la carte cognitive. Définir le test uniquement pour une contrainte nous permet d’éviter de le faire pour une spécification puisque la définition de la validité d’une spécification est toujours la même une fois qu’on connaît le résultat du test des contraintes, et ce quelque soit le critère de test. Le critère de cohérence avec une contrainte (définition 3.7) implémente donc l’interface Test.
6.3.3 Gestion des conflits
Avant de construire un ensemble de conflits pour un critère donné, il faut tout d’abord s’assurer qu’on peut bien calculer cet ensemble. En effet, comme expliqué dans le chapitre 3, la notion de conflit est intrinsèquement liée, entre autres, à l’ensemble de valeurs sur lequel est définie la carte cognitive. La définition d’un conflit varie donc en fonction de ses paramètres. Certains paramétrages sont même incompatibles avec la construction de conflits. Pour toutes ces raisons, la mé-thode canComputeConflictsWith(params,vs) de l’interface QualityCriterion doit être appelée avant toute construction d’un ensemble de conflits. Cette mé-thode indique en effet si on peut construire un ensemble de conflits en fonction de l’instance de ContradictoryValuesChecker, de l’ensemble de valeurs de la carte cognitive ainsi que des définitions de calcul d’influence utilisés.
Les ensembles des conflits de chacun des critères de qualité peuvent être construits via leurs méthodes dédiées. Les ensembles construits par ces méthodes peuvent correspondre à différentes définitions selon le paramétrage considéré. Les ensembles de conflits calculés doivent être des ensembles de conflits minimaux. Pour construire simplement de tels ensembles, on peut utiliser la classe MinimalConflictSet qui construit automatiquement un ensemble de conflits mi-nimaux. À chaque fois qu’un conflit est ajouté à cet ensemble, il le refuse si l’un de ses conflits est englobé par ce conflit ou bien supprime tous ses conflits englobant ce conflit. Cette classe contient également une méthode de classe qui construit l’ensemble des diagnostics à partir d’un ensemble de conflits minimaux.