Outils pour le model checking d

1
Outils pour le model checking dapplications Java
distribuées.

• MAAROUK Toufik, LIFO, Orléans
• Encadreur Eric Madelaine
• Projet OASIS INRIA Sophia Antipolis

• Objectifs
• Tester lusage 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 lart.
• 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.

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 gt Compositionnel)

3
I. Etat de l art. Plate-forme d analyse

• Développement dans le projet OASIS dune
  plate-forme danalyse 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 despace d états

4
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
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 lart 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
I. Etat de lartoutils pour la vérification
(Evaluator 3.0).
Boite à outils pour la vérification CADP La
vérification formelle des programmes LOTOS.
LOTOS
8
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 dobjets 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 dune 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
  lobjet)
• 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
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 lensemble des
  services quil offre et quil utilise.

11
II.Comparaison de deux model-checkersExemple
d application distribuée
Les philosophes en ProActive (Philosophe,
fourchette).
12
II.Comparaison de deux model-checkers Exemple
dapplication 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, laction
• abstraite représente la contradiction de cette
• hypothèse..

14
II.Comparaison de deux model-checkersPreuve
Evaluator 3.0
15
II.Comparaison de deux model-checkers

• Détection de l interblocage
• truelttruegttrue

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
ReqTakenu X1.(
RepTakeX0 and Other X1 and ReqTakenu
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,
  lt"eat"gttrue)) Atteignabilité équitable.
• AG_A(true, AF_A(true, lt"eat"gttrue))
  Atteignabilité forte inévitable.
• Propriété 2 AG_A(true, "RepTakeD1"AF_A("ReqDr
  opD1",true)) Sûreté.
• Propriété 3
• Other not ("ReqDropD" or "RepTakeD") Sûreté.
• nu X0.( "ReqDropD" false and OtherX0
  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
Fc2Tools
Evaluator 3.0
Formats dentré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

Fc2Tools
Evaluator 3.0
Résultats fournis.

• Vrai ou Faux Diagnostic..

• Diagnostic Le diagnostic est complet,
• interprétable facilement sur le système.

• Diagnostic Moins dinformations dans le
• diagnostic.

Efficacité et limites.

• On ne peut pas exprimer les propriétés
• déquité.

• Puissance dexpression
• Difficile pour lutilisateur de décrire des
  formules logiques.

20
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
III. Systèmes finis paramétrés
Version paramétrée  Réseau global.
m (k1) mod n
22
III. Systèmes finis paramétrés

• Parti pris
• Ne pas modifier la définition de FC2
• gt utilisation de déclarations locales
  dopérateurs
• gt syntaxe machine pas nécessairement lisible.
• Traiter un sous-ensemble très simple des types
  finis
• gt valeurs entières, intervales, énumérations
  explicites
• gt arithmétique simple (, -, modulo,
  comparaisons)
• Le passage dun 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 _ lt 1, 2, 1, 2
Struct _ lt 1kk, 2kk
Vecteur de synchronisation
behav 2 lt , , ?2, !0 -gt0
behav 2 lt ?2(1kn), !0(2kn) -gt0
24
III. Systèmes finis paramétrés.
Fichier dinstanciation
struct ''Philo3'' lt ''Philonet'',
kk3, 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 _ lt 1kk, 2kk
Struct _ lt 1, 1, 1, 2, 2, 2
?
behav 0 lt 0(1kn) -gt0
behav 0 lt 0, , , , , -gt0
behav 1 lt , , 0, , , -gt0
behav 2 lt , , , , 0, -gt0
25
IV.Conclusion et perspectives

• Apports
• Comparaison de deux approches de vérification.
• Difficulté dexpression 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
  dinformations 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 dun outil pour les systèmes finis
  paramétrés.

26
IV.Conclusion et perspectives

• Perspectives
• Terminer le développement de loutil 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)