Quand le problème est identifié, la spécification permet d’apporter une solution. Étant donné une application d’assistance à réaliser, quelle démarche mettre en place pour spécifier le modèle de scénario correspondant ? Comment aider l’utilisateur à bâtir un scénario ? Comment s’assurer que le scénario bâti est conforme à la spécifi- cation ? Telles sont les questions posées dans ce paragraphe.
Il est impossible de décrire l’ensemble des situations possibles rencontrées par l’utilisateur final durant la phase de conception. Il faut donc mettre en place une spécification globale et s’assurer à tout instant durant la phase de conception que les ajouts itératifs n’entrent pas en conflit avec la spécification de base. Chaque spé-
cification est construite autour d’axiomes fournissant des propriétés pour décrire le comportement du système d’assistance. Itérativement et de manière incrémentale, chaque axiome est ajouté au modèle, traduit en un système de preuve et passé à un moteur de raisonnement.
3.6.1
Le choix de ALLOY comme outil de spécifications for-
melles
Les spécifications formelles sont le plus souvent utilisées pour concevoir, valider, documenter, communiquer, réorganiser et réutiliser des solutions [61]. Plusieurs outils de spécifications et de vérifications formelles ont été développés dans la littérature. Entre autres, nous pouvons citer, les méthodes B et ses dérivées, le langage OCL, le langage VDM, le langage Z, ou le langage ALLOY. Nous utilisons ALLOY comme outil de spécification et de validation de nos scénarios. En effet, ALLOY est un langage qui capture l’essence des abstractions logicielles de manière simple et succincte. Il effectue une analyse entièrement automatique et peut exposer les fautes logicielles les plus subtiles. ALLOY a été choisi parce qu’il permet de produire un modèle abstrait du système à spécifier. Ceci facilite son évolution ou son expansion pour le futur et pour les éventuelles modifications. Ainsi, ALLOY est capable de garantir que les nouvelles modifications d’un système sont compatibles avec ses spécifications d’origine. Ce choix est soutenu par le fait que dans le domaine des scénarios les évolutions sont courantes. Enfin, ALLOY peut être utilisé avant, pendant et durant la phase de conception et même pendant celle de mise en oeuvre.
3.6.2
Du Scénario à la spécification formelle en ALLOY
Nous avons combiné à l’approche dirigée par les scénarios un langage de logique orienté objet pour formaliser la définition d’un scénario. L’approche utilisée garantit par validation que chaque instance d’un nouveau scénario est conforme à la spécifi- cation de base.Une spécification ALLOY est basée sur des signatures. Une signature est similaire à la notion de classe en programmation orientée objet. Cependant, les signatures ne contiennent pas de méthodes. Une spécification ALLOY est avant tout constituée d’un
Figure 3.9 – Exemple de spécification de base d’un scénario en ALLOY
ensemble de faits et d’assertions. La Figure 3.9 montre une vue partielle contenant les assertions et les faits pour la description du modèle décrit à la section 3.5.
Les signatures user, room, furniture, operator et condition n’ont pas de définitions spécifiques, elles sont utilisées pour exprimer les relations avec les autres signatures. La classe task est définie comme étant une signature abstraite spécialisée par les signatures compositetask et action. Le mot-clé enum permet de définir une énumération des différentes tâches. La signature goal qui spécialise la signature compositetask utilise le mot-clé one pour indiquer qu’il ne peut contenir qu’un seul objet. La signature User contient les objets utilisateurs impliqués dans le scénario. Le mot-clé lone associé à l’attribut parent indique que chaque tâche a au plus un parent. La signature GOAL n’a pas de parent comme l’indique l’attribut no parent. Dans ALLOY, les attributs sont représentés par des relations binaires. Par exemple, l’attribut parent est un sous-ensemble du produit cartésien task*compositetask.
3.6.3
La spécification de contraintes
ALLOY propose deux manières pour exprimer les contraintes. La première est l’utilisation des contraintes sur les multiplicités d’ensemble ou sur des relations entre les signatures. La seconde est l’utilisation des faits énonçant une contrainte sur l’en-
semble des relations.
Les faits introduits par le mot-clé fact, sont des contraintes qui doivent être sa- tisfaites par une instance de la spécification, c’est-à-dire un ensemble de valeurs pour les signatures et leurs attributs. Plusieurs faits ont été définis pour exprimer les contraintes à respecter pour les scénarios comme le montre la Figure 3.9.
Fait 1 - l’atteignabilité exprime le fait que toutes les tâches sont accessibles depuis la racine du scénario. Il s’agit de fixer une contrainte pour dire que le but est atteignable depuis une tâche quelconque. Nous avons utilisé la composition de deux relations et un opérateur de fermeture pour exprimer cette contrainte.
Fait 2 – la non décomposition des actions exprime le fait que les actions ne sont pas des tâches abstraites. Par conséquent, elles ne peuvent pas être décomposées en sous-tâches.
Fait 3 – la décomposition des tâches traduit le fait que toutes les décomposi- tions doivent se terminer par des actions. Il s’agit de s’assurer que chaque parent a au moins deux enfants ou aucun enfant.
Fait 4 – la généralité du but s’exprime par le fait que le but est toujours une tâche abstraite et peut ne pas se décomposer en plusieurs tâches.
Fait 5 – l’unicité du parent impose à toutes les tâches, sauf le but de n’avoir qu’un seul parent direct.
Fait 6 – les opérateurs n-aire sont définis sur des nœuds composites et s’ap- pliquent aux nœuds enfants.
Fait 7 – les opérateurs u-naires peuvent être définis sur tous les nœuds.
Validation des faits
La validation des faits est un processus qui recherche des instances de la spécifi- cation pour lesquelles l’une des instances violerait un fait. Dans ALLOY ce processus se fait en utilisant la commande run n. Cette commande rechercher l’existence d’une instance de la spécification avec au plus n objets dans chaque signature qui viole une contrainte. Le nombre n représente la portée (l’étendue) dans laquelle nous effectuons notre recherche. La qualité du résultat dépend du choix de cette portée.
Pour comprendre la notion de portée, considérons la commande run 1. Elle permet de vérifier que les instances de scénarios aléatoires n’ayant qu’une seule signature et ne violant aucune contrainte sont possibles. Dans le cas d’espèce le seul scénario possible est celui ayant 1 nœud : le but. Puisque, le but ne viole aucune des contraintes alors cette validation est correcte dans cette portée de 1. Un second exemple est celui donné par la commande run for 1 but exactly 3 task , qui permet de trouver des spécifications pour lesquelles on aurait un objet pour chacune des signatures à l’exception de la signature task qui en aurait 3. Cette validation elle aussi est correcte, car il existe bien un scénario avec 3 tâches où chaque parent à plus d’un enfant. En revanche la commande run for 1 but exactly 2 task échoue, puisqu’il est impossible de construire d’instance de scénarios ayant 2 tâches où chaque parent doit avoir plus d’un enfant.
La vérification des assertions
Une assertion est un théorème qui utilise les faits pour prouver que les nouvelles prépositions et spécifications ne sont pas contradictoires à la spécification de base. ALLOY prouve les assertions en analysant toutes les instances possibles d’une spé- cification dans une portée bien précise. Une assertion est une contrainte destinée à être valide pour tous les cas possibles dans une portée (l’étendue, espace, limite) bien définie. Pour vérifier les assertions d’une spécification, nous utilisons ALLOY pour lui demander de trouver des contre-exemples pour lesquels le théorème ne serait pas vrai. Un exemple d’assertion est le fait de dire qu’il ne devrait pas y avoir de cycle dans les relations entre parents et enfants.
Figure 3.10 – Exemple de spécification de base d’un scénario en ALLOY
vérification est faite. ALLOY vérifie que toutes les instances de la spécification dans cette plage ne violent aucun fait. Si aucun contre-exemple n’est trouvé, cela ne garantit pas le résultat, mais plutôt qu’aucun contre-exemple n’a été trouvé dans cette portée. Généralement, ALLOY traduit les assertions en formules booléennes et utilise un solveur basé sur SAT (SATISFIABILITY) pour vérifier chaque formule.