Outils pour le model checking d’applications Java distribuées.

1. Outils pour le model checking d’applications Java distribuées. • Objectifs : • Tester l’usage de deux outils de vérification pour analyser des propriétés des applications distribuées. • Proposer une méthode de traitement des systèmes finis paramétrés. • Plan : • I. Etat de l’art. • Outils pour la vérification (Fc2Tools, Evaluator 3.0). • Langages pour les applications distribuées (ProActive). • II. Comparaison de deux approches de vérification. • III. Systèmes finis paramétrés. • IV. Conclusion et perspectives. MAAROUK Toufik, LIFO, Orléans Encadreur : Eric Madelaine Projet OASIS INRIA Sophia Antipolis

2. I. Etat de l ’art. • Vérification des applications distribuées pour assurer les propriétés de bon fonctionnement. • Deux approches de vérification formelle : •  Preuve de théorèmes (Système infini, semi-automatique). •  Outils de model checking (système fini, automatique). • Modèles de représentation des applications distribuées : •  Action-based : Ou systèmes de transitions étiquetées (Fc2Tools, CADP). •  State-based : Ou machines à états finis (SPIN, SMV). • Nous avons choisi le modèle Action-based • (LTS + bisimulations => Compositionnel)

3. I. Etat de l ’art. Plate-forme d ’analyse • Développement dans le projet OASIS d’une plate-forme d’analyse et de vérification pour applications Java distribuées Programme (code source) Système fini Model checker Equivalence checker Propriétés à prouver (Logique temporelle, automate, etc) Oui/ Non + Diagnostic • Problème : Explosion d’espace d ’états

4. .java .class .jimple + Call-graphs Fc2 Networks I. Etat de l ’art. Plate-forme d ’analyse, Architecture Soot Slicing, Abstraction Specs = Automata Behavioural semantics Specs = *-calculus Fc2Tools Flat Fc2 Evaluator Diagnostics

5. .java .class .jimple + Call-graphs Fc2 Networks I. Etat de l ’art. Plate-forme d ’analyse, Architecture Soot Slicing, Abstraction Behavioural semantics Parametric Fc2 Specs = Automata Finite Instantiation Specs = *-calculus Fc2Tools Flat Fc2 Evaluator

6. I.Etat de l’art : outils pour la vérification (Fc2Tools). Fc2Tools: Les fonctionnalités principales • Description graphique du système ( Automates, Réseaux) ou génération à partir d ’analyse statique du code. • Description en format fc2. • Description hiérarchique fc2 ( fc2link ). • Construction des représentations ( Explicite, Implicite) . • Analyse et preuve  Réduction et comparaison par bisimulation.  Recherche de l ’interblocage.  Abstraction et preuve de propriétés ( automate). • Interprétation des diagnostics sur le modèle.

7. Caesar Caesar.Open Generator Explicite STE BCG Implicite STE On the fly Autres formats BCG_Open BCG_IO Vérification(Evaluator : mu-calcul) Test(TGV) Explicite STE Autre formats etc Bisimulation (Aldebaran) Minimisation (BCG_MIN) Vérification(XTL) Visualisation etc I. Etat de l’art:outils pour la vérification (Evaluator 3.0). Boite à outils pour la vérification CADP:La vérification formelle des programmes LOTOS. LOTOS

8. Communication entre objets Objet actif Frontière d’un objet actif. Objet passif I. ProActive :Langages pour les applications distribuées ProActive :ProActive est une librairie Java utilisée pour écrire des applications réparties (objets actifs, communication asynchrone, distribution, migration).

9. I. ProActive :Sémantiques • Opérationnelle(Ludovic Henrio, Denis Caromel) : • ASP (calcul d’objets a la Abadi-Cardelli, avec gestion explicite des références dans le tas, des appels asynchrones vers les objets distants, de la gestion des futurs avec attente par nécessité, etc.) • Comportementale (Rabea Boulifa, Dao Anh Viet) : • bâtie au-dessus de ASP, spécifie sous forme de LTS les actions observables d’une application distribuée ProActive: soumission de requêtes vers des objets actifs, activation de requêtes, retour de résultats. • Compositionelle : un LTS par objet actif, lui-même structuré (LTSs modélisant la queue des requêtes, LTS modélisant le comportement de l’objet) • synchronisés par les mécanismes sous-tendant la bibliothèque ProActive : RdV (au-dessus de la couche de transport) pour la transmission des messages.

10. Création dynamique des objets. • Variables définies sur des intervalles infinis. • . . . Modèle infini Techniques et méthodes d ’approximation • Domaine abstrait finis. • Analyse de flot de données. • Enumération bornée • . . . Modèle fini Comportemental Outils de vérification I. ProActive :Modèles finis • Dans ProActive : • On associe un processus à chaque objet actif crée dans l ’application. • Chaque appel de méthode représente une action. • On calcule pour chaque processus l’ensemble des services qu’il offre et qu’il utilise.

11. ?ReqTake Fork ?ReqTake ?ReqDrop ?ReqDrop Fork !RepTake !RepTake Think Think Think !ReqTakeG !ReqTakeD !ReqTakeG !ReqTakeD !ReqTakeD !ReqTakeG Philo Philo Philo ?RepTakeD ?RepTakeG ?RepTakeG ?RepTakeG ?RepTakeD ?RepTakeD !ReqDropG !ReqDropG !ReqDropD !ReqDropD !ReqDropD !ReqDropG Eat Eat Eat ?ReqTake Fork ?ReqDrop !RepTake II.Comparaison de deux model-checkersExemple d ’application distribuée Les philosophes en ProActive : (Philosophe, fourchette).

12. II.Comparaison de deux model-checkers Exemple d’application distribuée Un objet actif = Une queue de requêtes + un automate de contrôle

13. II.Comparaison de deux model-checkersPreuve : Fc2Tools. Dans les travaux de R. Boulifa et E. Madelaine • Modélisation compositionnelle d ’application ProActive. • Exemple de propriétés prouvées : • Recherche et élimination d ’interblocage. • Finitude de la queue de requêtes : Chaque fourchette reçoit 2 requêtes Take, donc la queue des requêtes est finie, l’action abstraite représente la contradiction de cette hypothèse..

14. Le model checker Evaluator 3.0 : Description graphique (ATG) des fichiers. Fc2link Description hiérarchique fc2. Fc2explicit Automate Fc2 plat Formule en mu-calcul régulier Evaluator Vrai ou Faux + Diagnostic II.Comparaison de deux model-checkersPreuve : Evaluator 3.0

15. II.Comparaison de deux model-checkers • Détection de l ’interblocage • [true*]<true>true

16. II.Comparaison de deux model-checkers Finitude de la queue de requêtes : Other = not ("ReqTakeD1" or "ReqTakeG3" or "RepTakeD1" or "RepTakeG3") ReqTake = "ReqTakeD1" or "ReqTakeG3" RepTake = "RepTakeD1" or "RepTakeG3" [true*] nu X0.( [Other] X0 and [ReqTake]nu X1.( [RepTake]X0 and [Other] X1 and [ReqTake]nu X2.( (*On interdit la troisième requête*) [ReqTake] false and [RepTake] X1 and [Other] X2) ) Résultat : Evaluator rend la valeur Vrai. Donc en mu-calcul on peut coder toutes les actions abstraites de Fc2Tools.

17. II. Comparaison de deux model-checkers • Autres propriétés : • Certains propriétés ne sont pas exprimables en automate (fc2), mais exprimables en mu-calcul (Evaluator). • Propriété 1 :AG_A(true, EF_A(true, <"eat">true)): Atteignabilité équitable. • AG_A(true, AF_A(true, <"eat">true)): Atteignabilité forte inévitable. • Propriété 2 :AG_A(true, ["RepTakeD1"]AF_A("ReqDropD1",true)) : Sûreté. • Propriété 3 : • Other = not ("ReqDropD" or "RepTakeD") : Sûreté. • nu X0.( ["ReqDropD"] false and [Other]X0 and ["RepTakeD"] nu X1.( • ["ReqDropD"]X0 and [Other] X1)). • Le mu-calcul exprime finement les propriétés d’équité.

18. II.Comparaison de deux model-checkers Discussion et comparaison Evaluator 3.0 Fc2Tools Formats d’entrée (système, propriété). • Formalisme logique : formules de logique temporelle (mu-calcul régulier, ACTL, etc ). • Format du système : système plat (fc2 ou bcg), évaluation à la volée. • Formalisme logique : action abstraite • ( automate). • Format du système : système hiérarchique • en format fc2.

19. II.Comparaison de deux model-checkers Evaluator 3.0 Fc2Tools Résultats fournis. • Vrai ou Faux + Diagnostic.. • Diagnostic :Le diagnostic est complet, • interprétable facilement sur le système. • Diagnostic : Moins d’informations dans le • diagnostic. Efficacité et limites. • On ne peut pas exprimer les propriétés • d’équité. • Puissance d’expression • Difficile pour l’utilisateur de décrire des formules logiques.

20. Fc2 paramétré Code Source Fc2 standard Transformation Fc2 instanciation Model checker III. Systèmes finis paramétrés Motivations • Traiter des systèmes relativement grands. • Coder directement des applications réalistes • ( Modèle plus proche du code source)

21. ReqTakeD(k,n) ReqTakeG(k,m) RepTakeD(k,n) ?ReqTake ?ReqDrop Fork(n) ReqDrop(k,m) !RepTake RepTakeG(k,m) ReqDrop(k,n) Think(k) !ReqTakeD !ReqTakeG Philo(n) ?RepTakeD ?RepTakeG !ReqDropD !ReqDropG Eat(k) III. Systèmes finis paramétrés Version paramétrée :Réseau global. m = (k+1) mod n

22. III. Systèmes finis paramétrés • Parti pris: • Ne pas modifier la définition de FC2 • => utilisation de déclarations locales d’opérateurs • => syntaxe “machine” pas nécessairement lisible. • Traiter un sous-ensemble très simple des types finis • => valeurs entières, intervales, énumérations explicites • => arithmétique simple (+, -, modulo, comparaisons) • Le passage d’un vrai code Java à ces types simples pouvant • être traité en amont par abstraction.

23. III. Systèmes finis paramétrés. Format Fc2 : Paramétré Standard Table des actions behavs 3 : 0 " eat " : 1 " think " : 2 " ReqTakeD2" behavs 3 : 0 " eat" &kn : 1 " think " &kn : 2 " ReqTake" &kn Structure du réseau Struct _ < 1, 2, 1, 2 Struct _ < 1$kk, 2$kk Vecteur de synchronisation behav 2 < *, *, ?2, !0 ->0 behav 2 < ?2$(1&kn), !0$(2&kn) ->0

24. III. Systèmes finis paramétrés. Fichier d’instanciation: struct ''Philo3'' < ''Philonet'', kk=3, in(kn,1,kk) Résultat de l ’instanciation behavs 6 : 0 " eat(1) " : 3 " think(1) "  : 1 " eat(2)" : 4 " think(2) " : 2 " eat(3)" : 5 " think(3) " behavs 2 : 0 " eat" &kn : 1 " think " &kn   Struct _ < 1$kk, 2$kk Struct _ < 1, 1, 1, 2, 2, 2  behav 0 < 0$(1&kn) ->0 behav 0 < 0, *, *, *, *, * ->0 behav 1 < *, *, 0, *, *, * ->0 behav 2 < *, *, *, *, 0, * ->0

25. IV.Conclusion et perspectives • Apports • Comparaison de deux approches de vérification. • Difficulté d’expression des propriétés : plus facile sous forme d ’automate, mais plus expressive en logiques. • Hypothèse d’équité : Exprimable dans Evaluator. • Différence dans la qualité des diagnostics: plus d’informations dans Fc2Tools que dans Evaluator. • Différence dans la représentation du système : hiérarchique pour Fc2Tools, plat pour Evaluator. • Les deux outils ne peuvent pas traiter directement de propriétés portant sur les données du programme à vérifier. • Architecture d’un outil pour les systèmes finis paramétrés.

26. IV.Conclusion et perspectives • Perspectives : • Terminer le développement de l’outil de transformation. • Garantir la remontée des diagnostics, tout au long de la chaîne • Définir un formalisme pour des formules paramétrées. • Généraliser le format fc2 paramétré dans plusieurs directions. (cf exemple « taxes électroniques » de Tomás Barros)