Raffinement de modèles JML Julien Groslambert LIFC Besançon Réunion GECCOO - 25 Octobre 2005 FRE 2661

PLAN Contexte et enjeux Raffinement préservant les sûretés Conclusion et travaux futurs

Contexte et enjeux Politique de sécurité Cahier des charges Code Java de l’application Propriétés de sécurité Expression sur un cahier des charges souvent informel Détails et décisions d’implémentations cachés Difficile d’exprimer des erreurs de bas niveau. Vérification à l’aide d’annotations JML Détection des erreurs type NullPointerException… Propriétés de haut niveau pas facilement exprimable Annotations JML

Contexte et enjeux Politique de sécurité Cahier des charges Code Java de l’application Propriétés de sécurité Annotations JML Vérification directe difficile

Contexte et enjeux Politique de Sécurité Cahier des charges Code Java de l’application Propriétés de sécurité Modèle abstrait JML Vérification simplifiée Expression simplifiée Vérification complexe Vérification des propriétés de haut niveau sur un modèle de haut niveau (abstrait) Problème du lien avec l’application

Contexte et enjeux Politique de Sécurité Cahier des charges Code Java de l’application Propriétés de sécurité Annotations JML du code Modèle abstrait JML Modèle raffiné 1 Modèle raffiné n Préservation Proposition : Introduire un raffinement de modèle JML qui préserve les propriétés du modèle abstrait

PLAN Contexte et enjeux Raffinement préservant les sécurités Conclusion et travaux futurs

Raffinement Idée du raffinement Ajouter des détails à un modèle abstrait pour le rendre plus concret Préserver les propriétés vérifiées sur le modèle abstrait. Notion différente du sous-typage Pour un type de propriété donné, trouver la bonne relation de raffinement pour préserver ce type de propriété

Exemple : Spécification de Demoney Modélisation d’une interface de Demoney d’après le cahier des charges 1 er modèle abstrait : Modélisation de la personnalisation

Exemple: Spécification de Demoney public interface model1{ boolean personnalized; personnalized == assignable ensures personnalized == void storeData(); personnalized == assignable void initializeTransaction(); personnalized == assignable void completeTransaction(); assignable void pinChangeUnblock(); … }

Vérification de propriété Expression d’une propriété de sûreté After storeData() normal always storeData() not enabled; (AMAST’02) Génération d’annotations avec JAG Vérification de la consistance du modèle complétée (ZB’05)

Raffinement de données Notations C r raffine C a C a  C r C a vérifie une propriété   Ca |=  Raffinement des données Prédicat JML I c. Lien entre variables abstraites et raffinées. Changement d’espace d’état. Ajout de nouvelles variables durant le raffinement.

Raffinement de classes Classe Ca { initially Init a invariant I a ; constraint H a ; … Classe Cr { initially Init r invariant I r ; constraint H r ; … Renforcement de l’initialisation Init r && I c ==>Init a Renforcement de l’invariant I r && I c ==> I a Renforcement des contraintes H r && I c && \old(I c ) ==> H a

Raffinement de méthodes requires P a diverges D a assignable A a ensures Q a signals (E a e) R M a (); requires P r diverges D r assignable A r ensures Q r signals (E r e) R M r ();

Renforcement des préconditions Obligation de preuve P r && I c ==> P a requires P a diverges D a assignable A a ensures Q a signals (E a e) R M a (); requires P r diverges D r assignable A r ensures Q r signals (E r e) R M r ();

Renforcement des conditions de divergence Obligation de preuve D r && I c ==> D a requires P a diverges D a assignable A a ensures Q a signals (E a e) R M a (); requires P r diverges D r assignable A r ensures Q r signals (E r e) R M r ();

Pas d’ajout d’effet de bord Obligation de preuve (A new nouvelles variables)  X. (X  A r && I c ==> (X  A a || X  A new )) requires P a diverges D a assignable A a ensures Q a signals (E a e) R M a (); requires P r diverges D r assignable A r ensures Q r signals (E r e) R M r ();

Renforcement des post- conditions Obligation de preuve Q r && I c && P a && !D a && P r && ! D r ==> Q a requires P a diverges D a assignable A a ensures Q a signals (E a e) R M a (); requires P r diverges D r assignable A r ensures Q r signals (E r e) R M r ();

Inclusion des types d’exceptions Obligation de preuve \typeof(E r )  \typeof(E a ) requires P a diverges D a assignable A a ensures Q a signals (E a e) R M a (); requires P r diverges D r assignable A r ensures Q r signals (E r e) R M r ();

Renforcement des post- conditions exceptionnelles Obligation de preuve R r && I c && P a && !D a && P r && ! D r ==> R a requires P a diverges D a assignable A a ensures Q a signals (E a e) R M a (); requires P r diverges D r assignable A r ensures Q r signals (E r e) R M r ();

Théorème Soit  une propriété de sûreté (  Ca |=  ) && (C a  Ic C r ) ==> (  Cr |=  ) Idée de la preuve : on montre que les exécutions de  Cr sont simulées par les exécutions de  Ca

Idée de la preuve Appel de Mr

Idée de la preuve Appel de Mr Pr

Idée de la preuve Appel de Mr Pr Pa

Idée de la preuve Mr called Pr Pa Ma called Mr normal Qr

Idée de la preuve Mr called Pr Pa Ma called Mr normal Qr Qa

Idée de la preuve Mr called Pr Pa Ma called Mr normal Qr Qa Mr normal

Idée de la preuve Mr called Pr Pa Ma called Mr normal Qr Qa Mr normal Mr exceptional Rr

Idée de la preuve Mr called Pr Pa Ma called Mr normal Qr Qa Mr normal Mr exceptional Rr Ma exceptional Ra

Exemple sur Demoney Modèle abstrait: Modélisation de la personnalisation 1 er raffinement : Modélisation des niveaux d’accès Introduction d’une variable AccessLevel représentant le niveau d’accès Mise à jour des spécifications de méthode

Exemple sur Demoney public interface model2{ boolean personnalized; int accessLevel; invariant 1 <= && accessLevel <= personnalized == & accessLevel == assignable ensures personnalized == void store_data(); personnalized == && accessLevel && accessLevel <= assignable void initialize_transaction(); personnalized == && accessLevel >=2 accessLevel <= assignable void complete_transaction(); requires accessLevel == assignable void pin_change_unblock(); … }

Spécification de Demoney Specification de Demoney en suivant la specification publique. Modèle Abstrait : Personnalisation Raffinement 1 : Niveaux d’accès Raffinement 2 : Code Pin Raffinement 3 : Balance et transactions … But : vérifier à chaque niveau les propriétés et s’approcher de l’implantation

Propriétés supplémentaires Ajout de nouvelles méthodes lors du raffinement. Les nouvelles méthodes ne peuvent modifier les variables abstraites Préservation de l’atomicité Les nouvelles méthodes ne peuvent pas être déclenchées sous certaines conditions Préservation des vivacités Le système ne doit pas comporter de nouveaux blocages Les nouvelles méthodes doivent faire décroître un variant.

PLAN Contexte et enjeux Raffinement préservant les sécurités Conclusion et travaux futurs

Conclusion Premières réflexions sur une notion de raffinement Différentes applications Développement étape par étape d’une spécification Exemple de Demoney en cours. Développement étape par étape d’un algorithme Exemple du Dutch National Flag. Vérification de l’intégration d’une classe dans un environnement

Travaux futurs Ecriture d’un outil de génération d’obligations de preuve de raffinement. OP au format Why (modèle de Krakatoa) et Jack Environnement de développement par raffinement Développement par raffinement d’algorithmes avec pointeurs. Schorr-Wait, inversion de liste chaînée… Intégration des travaux de Sylvain Boulmé Lien raffinement / sous-typage Comparaison fine des deux notions Collaboration