Validation de systèmes interactifs centrée sur l usager

Validation de systèmes interactifs centrée sur l usager C. Ailleres Mardi 6 Janvier 2004 Problématique Avènement de l informatique : besoin de qualité et de fiabilité des systèmes Génie Logiciel Importance de l IHM dans les systèmes actuels besoin de rendre les systèmes utilisables (ISO 9241-11) Modélisation de tâche besoin des méthodes formelles?

Approche proposée Cycle de vie logiciel en V Besoins Système Spécification Recette Conception Test Codage Approche proposée Cycle de vie logiciel en V adapté aux systèmes interactifs Utilisateurs Besoins Système Modèles Spécification de tâches Recette Conception Test Codage

Approche proposée Utilisateurs Exigences fonctionnelles Modèles de tâche Modèles de tâche en Lustre Contraintes techniques Conception Propriétés satisfaites vérification Propriétés temporelles Codage Code en Lustre Modèle de tâches > Introduction représente : - les services que doit offrir le système à ses usagers - les connaissances requises par l usager pour utiliser le système facilite : - la compréhension du système - la communication entre les utilisateurs, les experts (cogniticiens, informaticiens) formalismes existants :

Modèle de tâches > ConcurTaskTrees > Présentation de la notation ConcurTaskTrees (Paterno) - sémantique riche - facilité d utilisation et de compréhension (CTTE) - nombreux outils associés (THERESA, REMUSINE) - déjà mis en œuvre dans des projets européens (MEFISTO, GUITARE, CAMELEON) en partenariat avec BAAN, Philips, EDF, Louvain-la-Neuve Modèle de tâches > ConcurTaskTrees > Définition de la tâche Une tâche définit comment l utilisateur atteint un but dans un domaine applicatif particulier. Le but étant l obtention d un état désiré du système - un identifiant - une catégorie (qui va exécuter la tâche?) - un type d action (selon la catégorie) - une fréquence d utilisation (faible, moyenne, haute) - une plate-forme cible (Desktop, PDA, GSM, etc ) - options (itérative, optionnelle, coopérative) - pré condition - liste d objets nécessaires à sa réalisation - liste des actions d entrée ou de sortie des objets - durées d exécution d une tâche (min, max, moyenne)

Modèle de tâches > ConcurTaskTrees > Les catégories de tâches - tâche «abstraite» actions complexes impliquant plusieurs catégories de tâches - tâche «utilisateur» planification, résolution de problèmes, comparaison, etc - tâche «application» production d alertes, affichage, comparaison, etc - tâche «interaction» commande, édition, réponse aux alertes, choix, etc - tâche «coopération» négociation, notification Modèle de tâches > ConcurTaskTrees > Les opérateurs temporels Opérateurs temporels inspirés de LOTOS + priorité - [] = ou [] [> > >> ou []>> Choix Indépendance d ordre Concurrence Désactivation Suspension Activation [T] T* T n T

Modèle de tâches > ConcurTaskTrees > Un modèle de tâche Modèle de tâches > ConcurTaskTrees > Un modèle de tâche coopératif

Modèle de tâches > ConcurTaskTrees > Outils associés - vérification syntaxique - simulateur - statistique et comparaison de modèles - test d atteignabilité - conversion en LOTOS - génération automatique d IHM (THERESA) - comparaison de modèles avec des sessions utilisateurs (RemUSINE) Modèle de tâches > ConcurTaskTrees > Simulateur - Facilite la compréhension des relations temporelles - Présentation du futur système aux utilisateurs

Modèle de tâches > ConcurTaskTrees > RemUSINE CTTE Modèle de tâche Préparation RemUSINE Table des tâches Méthode d évaluation RemUSINE Journal Utilisateur Journal 1 Utilisateur n Résultats Outil de journalisation Utilisateur 1 Utilisateur n Application Modélisation de CTT > Model Checking Objectif : Analyse de l adéquation entre deux modèles formels. Systèmes formalisés : - Propriétés - Spécifications - Programmes Langages formels : - Algèbres de processus (Lotos) - Modèles à états (StateCharts, Réseaux de pétri) - Langages synchrones (Lustre)

Modélisation de CTT > Lustre Model Checking modélisation de CTT Lustre (IMAG) : - Formalisme strict et gestion du parallélisme - Outils de preuve et de test (Lesar, SMV, Ga, Lutess) - Continuité avec le travail déjà réalisé Syntaxe de Lustre : - Les nœuds - Les équations - Les assertions Modélisation de CTT > Modélisation de CTT en Lustre - Une tâche atomique un nœud : pexe(état de la tâche) = (evt début, evt fin, dysfonctionnement) - Une relation temporelle un nœud propre à la relation : prel(exe(t1),exe(t2)) = (evt début, evt fin, dysfonctionnement) - Une tâche abstraite une équation composée de relations temporelles : T1T2T3 = prel2(pexe(t1), prel1(pexe(t2),pexe(t3)) - Le système formalisé une équation constituée de tâches composées et/ou de tâches atomiques.

Modélisation de CTT > Activation La tâche se trouvant à droite de l opérateur ne peut pas être activée tant que la tâche de gauche n a pas été complètement réalisée. node pact(st1,st2:[bool,bool,bool]) returns (st:[bool,bool,bool]); assert not(st1[2] or st2[2]); st[0] = false -> if raise(st1[0]) and not st2[0] then true else pre(st[0]); st[1] = false -> if raise(st2[1]) and st1[1] then true else pre(st[1]); st[2] = false -> if raise(st2[0]) and not st1[1] then true else pre(st[2]); Modélisation de CTT > Concurrence Les deux tâches peuvent être exécutées en même temps ou l une après l autre, avec un ordre d activation indifférent. node pcrr(st1,st2:[bool,bool,bool]) returns (st:[bool,bool,bool]); assert not(st1[2] or st2[2]); st[0] = false -> if raise(st1[0]) or raise(st2[0]) then true else pre(st[0]); st[1] = false -> if (raise(st1[1]) and st2[1]) or (raise(st2[1]) and st1[1]) then true else pre(st[1]); st[2] = false;

Modélisation de CTT > Choix Lorsqu une des deux tâches a été choisie, l autre tâche ne peut plus être activée. node pchx(st1,st2:[bool,bool,bool]) returns (st:[bool,bool,bool]); assert not(st1[2] or st2[2]); st[0] = false -> if raise(st1[0]) or raise(st2[0]) then true else pre(st[0]); st[1] = false -> if raise(st1[1]) or raise(st2[1]) then true else pre(st[1]); st[2] = false -> if st1[0] and st2[0] then true else pre(st[2]); Modélisation de CTT > Indépendance d ordre L ordre d activation des tâches est indifférent, mais il ne peut pas y avoir concurrence entre les tâches. node pindn(const n:int;ti:bool^3^n) returns (st:[bool,bool,bool]); assert not(t_or(n,ti[0..n-1,2])); st[0] = T_OR(n,Ti[0..n-1,0]); st[1] = T_AND(n,Ti[0..n-1,1]); st[2] = false -> if st[0] and not st[1] and not aone(n,totask(ti[0..n-1])) then true else pre(st[2]);

Modélisation de CTT > Désactivation Si au moins une action de la tâche se trouvant à droite de l opérateur a été réalisée, la tâche de gauche, si elle a été lancée, est désactivée. node pdac(st1,st2:[bool,bool,bool]) returns (st:[bool,bool,bool]); assert not(st1[2] or st2[2]); st[0] = false -> if raise(st1[0]) or raise(st2[0]) then true else pre(st[0]); st[1] = false -> if (raise(st1[1]) and not st2[0]) or raise(st2[1]) then true else pre(st[1]); st[2] = false -> if (raise(st1[0]) and st2[0]) or (raise(st2[0]) and st1[1]) or (raise(st2[1]) and st1[0] and not st1[1]) then true else pre(st[2]); Modélisation de CTT > Suspension La tâche de gauche, si elle a été lancée, est suspendue le temps de réaliser la tâche se trouvant à sa droite. Puis, elle est réactivée à partir de l état dans lequel elle se trouvait. node psps(st1,st2:[bool,bool,bool]) returns (st:[bool,bool,bool]); assert not(st1[2] or st2[2]); st[0] = false -> if raise(st1[0]) then true else pre(st[0]); st[1] = false -> if raise(st1[1]) then true else pre(st[1]); st[2] = false -> if (raise(st2[0]) and not st1[0]) or (raise(st2[1]) and st1[1]) or (raise(st1[0]) and st2[0]) or (raise(st1[1]) and st2[0] and not st2[1]) then true else pre(st[2]);

Modélisation de CTT > Les priorités entre opérateurs node p(t1,t2,t3:bool) returns (R:[bool,bool,bool]); R = pchx(pexe(t1),pcrr(pexe(t2),pexe(t3))); node p(t1,t2,t3:bool) returns (R:[bool,bool,bool]); R = pcrr(pchx(pexe(t1),pexe(t2)),pexe(t3)); [], =,, [>, > et >> + priorité - Automatisation des priorités dans le programme de transformation des modèles CTT en Lustre Modélisation de CTT > La hiérarchie entre les tâches node h1(t1,t21,t22:bool) returns R:[bool,bool,bool]); R = pact(pexe(t1),pact(pexe(t21),pexe(t22))); node h2(t1,t21,t22:bool) returns (R:[bool,bool,bool]) var T2:[bool,bool,bool] R = pact(pexe(t1),t2); T2 = pact(pexe(t21),pexe(t22)); node R(T1,T21,T22:bool) returns (st:[bool,bool,bool]); st = pact(pexe(t1),t2(t21,t22)); node T2(T21,T22:bool) returns (st:[bool,bool,bool]); st = pact(pexe(t21),pexe(t22));

Modélisation de CTT > Exemple de modèle CTT formalisé en Lustre node appf(t0,t1,t21,t22,t3,t41,t42:bool) returns (Root:[bool,bool,bool]); var abs0,abs1,t2,t4:[bool,bool,bool]; Root=pAct(pExe(T0),abs0); abs0=pindn(2,[abs1] [T4]); abs1=pact(pact(pexe(t1),t2),pexe(t3)); T2=pChx(pExe(T21),pExe(T22)); T4=pChx(pExe(T41),pExe(T42)); Vérification des spécifications > Principes de la vérification sous Lesar Trois notions : - Le programme sous test. - Les propriétés à vérifier. - L observateur. observateur node exclusion(t1,t2:bool) returns (Ok:bool); Ok = (T1 or T2) and not(t1 and T2); node verification(t1,t2:bool) returns (Ok:bool); entrées identiques Ok = ((T1 xor T2) = (exclusion(t1,t2))); propriété programme sous test opérateur logique qui permet de définir le type de propriété Vrai, la propriété est vérifiée Faux, la propriété est violée. Contre exemple

observateur Vérification des spécifications > Atteignabilité Quelque chose peut se produire node vatt0(t0,t1,t21,t22,t3,t41,t42:bool) returns (Ok:bool); var smod:[bool,bool];sprop:[bool,bool,bool];mod,prop:bool; entrées identiques smod= appf(t0,t1,t21,t22,t3,t41,t42); Mod = smod[0] and smod[1]; programme sous test avec exclusion, via des assertions, des cas de dysfonctionnement sprop = pact(pact(pexe(t41),pexe(t22)),pexe(t3)); Prop = sprop[0] and sprop[1] and not sprop[2]; propriété Ok = nand(mod,prop); Grâce aux assertions, Mod, lorsqu il a été réalisé, est toujours Vrai opérateur logique Mod Prop (Mod Prop) Vrai Vrai Faux Vrai Faux Vrai Faux Vrai Vrai Faux Faux Vrai Atteignabilité Contre exemple Prop ne pourra jamais être réalisé Vérification des spécifications > Atteignabilité (T41 >> T22 >> T3) Faux (T1 >> T41) Faux (T21 T22) Vrai Sûreté, s il s agit d un comportement qui ne doit jamais se produire

Vérification des spécifications > Sûreté Quelque chose de mauvais ne se produira jamais Ou quelque chose de bon arrivera toujours Cf. diapositive précédente opérateur logique Mod Prop Mod => Prop Vrai Vrai Vrai Vrai Faux Faux Faux Vrai Vrai Faux Faux Vrai Le comportement attendu se produira toujours Le comportement attendu ne se produira pas obligatoirement T1 >> T3 Vrai T41 >> T3 Faux Vérification des spécifications > Cas particulier Aura-t-on toujours T11 >> T22? Faux TRANSITION 1 --> not T11 and not T12 and not T21 and not T22 TRANSITION 2 --> T11 and not T12 and T21 and not T22 TRANSITION 3 --> T11 and not T12 and not T21 and T22 TRANSITION 4 --> not T11 and T12 and not T21 and T22 TRANSITION 5 --> not T11 and not T12 and not T21 and not T22 Est-il possible d avoir T11 >> T22? Faux TRANSITION 1 --> not T11 and not T12 and not T21 and not T22 TRANSITION 2 --> T11 and not T12 and T21 and not T22 TRANSITION 3 --> not T11 and T12 and not T21 and T22 TRANSITION 4 --> not T11 and not T12 and not T21 and not T22

Vérification des spécifications > Recherche de tous les contre exemples Est-il impossible d avoir T3? Faux On pose alors en assertion dans l observateur : T1 >> T21 >> T3 Est-il encore impossible d avoir T3? Faux On pose alors en assertion dans l observateur : T1 >> T22 >> T3 Est-il encore impossible d avoir T3? Vrai Il est possible d utiliser cette méthode pour ne pas prendre en compte certains chemins trop rapides, par exemple lorsqu on utilise l opérateur de désactivation. Vérification de l implémentation > Travail en cours Déjà réalisé : - Ecriture d un programme Java simple - Création du modèle CTT de ce programme - Formalisation du modèle CTT en Lustre - Formalisation du programme Java en Lustre en utilisant le travail déjà réalisé par Bruno d Ausbourg et Guy Durrieu En cours : - Vérification de propriétés temporelles sur les deux modèles - Vérification d un modèle de l application Java par le modèle du modèle de tâche CTT.

Conclusion et perspectives Atouts de la modélisation : - Proposition d une sémantique fidèle à CTT - Facilité d écriture - Possibilité de vérifier des propriétés d atteignabilité et de sûreté avec des temps de réponse corrects Problème ouvert de la sémantique de l itération Perspectives : - Etendre la modélisation aux tâches optionnelles - Créer d autres opérateurs pour affiner les comportements - Utiliser les modèles dans la génération automatique de jeux de tests Fin Merci de votre attention Avez-vous des questions? Me contacter : - Pour obtenir la bibliographie - Pour obtenir des renseignements complémentaires christophe.ailleres@logicacmg.com