1 / 36

Raffinement de modèles JML

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. Propriétés de sécurité.

ursula-heath
Download Presentation

Raffinement de modèles JML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. Contexte et enjeux Politique de sécurité Cahier des charges Propriétés de sécurité Vérification à l’aide d’annotations JML Détection des erreurs type NullPointerException… Propriétés de haut niveau pas facilement exprimable 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. AnnotationsJML Code Java de l’application

  4. Contexte et enjeux Politique de sécurité Cahier des charges Propriétés de sécurité Vérificationdirecte difficile AnnotationsJML Code Java de l’application

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

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

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

  8. 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é

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

  10. public interface model1{ boolean personnalized; /*@ behavior @ requires @ personnalized == false; @ assignable personnalized; @ ensures personnalized == true; @*/ void storeData(); /*@ behavior @ requires @ personnalized == true; @ assignable \nothing; @*/ void initializeTransaction(); /*@ behavior @ requires @ personnalized == true; @ assignable \nothing; @*/ void completeTransaction(); /*@ assignable \nothing; @*/ void pinChangeUnblock(); … } Exemple: Spécification de Demoney

  11. 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)

  12. Raffinement de données • Notations • Cr raffineCa Ca Cr • Ca vérifie une propriété  Ca |=  • Raffinement des données • Prédicat JML Ic. • Lien entre variables abstraites et raffinées. • Changement d’espace d’état. • Ajout de nouvelles variables durant le raffinement.

  13. Classe Ca { //@ initially Inita //@ invariant Ia; //@ constraint Ha; … Classe Cr { //@ initially Initr //@ invariant Ir; //@ constraint Hr; … Raffinement de classes Renforcement de l’initialisation Initr&& Ic ==>Inita Renforcement de l’invariant Ir && Ic ==> Ia Renforcement des contraintes Hr && Ic && \old(Ic) ==> Ha

  14. /*@ behavior @ requires Pa; @ diverges Da; @ assignable Aa; @ ensures Qa; @ signals (Ea e) Ra @*/ Ma(); /*@ behavior @ requires Pr; @ diverges Dr; @ assignable Ar; @ ensures Qr; @ signals (Er e) Rr @*/ Mr(); Raffinement de méthodes

  15. Renforcement des préconditions /*@ behavior @ requires Pa; @ diverges Da; @ assignable Aa; @ ensures Qa; @ signals (Ea e) Ra @*/ Ma(); /*@ behavior @ requires Pr; @ diverges Dr; @ assignable Ar; @ ensures Qr; @ signals (Er e) Rr @*/ Mr(); Obligation de preuve Pr && Ic ==> Pa

  16. Renforcement des conditions de divergence /*@ behavior @ requires Pa; @ diverges Da; @ assignable Aa; @ ensures Qa; @ signals (Ea e) Ra @*/ Ma(); /*@ behavior @ requires Pr; @ diverges Dr; @ assignable Ar; @ ensures Qr; @ signals (Er e) Rr @*/ Mr(); Obligation de preuve Dr && Ic ==> Da

  17. Pas d’ajout d’effet de bord /*@ behavior @ requires Pa; @ diverges Da; @ assignable Aa; @ ensures Qa; @ signals (Ea e) Ra @*/ Ma(); /*@ behavior @ requires Pr; @ diverges Dr; @ assignable Ar; @ ensures Qr; @ signals (Er e) Rr @*/ Mr(); Obligation de preuve (Anew nouvelles variables)  X. (X  Ar && Ic ==> (X  Aa ||X  Anew))

  18. Renforcement des post-conditions /*@ behavior @ requires Pa; @ diverges Da; @ assignable Aa; @ ensures Qa; @ signals (Ea e) Ra @*/ Ma(); /*@ behavior @ requires Pr; @ diverges Dr; @ assignable Ar; @ ensures Qr; @ signals (Er e) Rr @*/ Mr(); Obligation de preuve Qr && Ic && Pa && !Da && Pr && ! Dr ==> Qa

  19. Inclusion des types d’exceptions /*@ behavior @ requires Pa; @ diverges Da; @ assignable Aa; @ ensures Qa; @ signals (Ea e) Ra @*/ Ma(); /*@ behavior @ requires Pr; @ diverges Dr; @ assignable Ar; @ ensures Qr; @ signals (Er e) Rr @*/ Mr(); Obligation de preuve \typeof(Er) \typeof(Ea)

  20. Renforcement des post-conditions exceptionnelles /*@ behavior @ requires Pa; @ diverges Da; @ assignable Aa; @ ensures Qa; @ signals (Ea e) Ra @*/ Ma(); /*@ behavior @ requires Pr; @ diverges Dr; @ assignable Ar; @ ensures Qr; @ signals (Er e) Rr @*/ Mr(); Obligation de preuve Rr && Ic && Pa && !Da && Pr && ! Dr ==> Ra

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

  22. Idée de la preuve Appel de Mr

  23. Idée de la preuve Pr Appel de Mr

  24. Idée de la preuve Pa Pr Appel de Mr

  25. Idée de la preuve Pa Macalled Pr Mr normal Mrcalled Qr

  26. Idée de la preuve Pa Macalled Qa Pr Mr normal Mrcalled Qr

  27. Idée de la preuve Pa Mr normal Macalled Qa Pr Mr normal Mrcalled Qr

  28. Idée de la preuve Pa Mr normal Macalled Qa Pr Mr normal Mrcalled Qr Mr exceptional Rr

  29. Idée de la preuve Pa Mr normal Macalled Qa Ra Ma exceptional Pr Mr normal Mrcalled Qr Mr exceptional Rr

  30. Exemple sur Demoney • Modèle abstrait: Modélisation de la personnalisation • 1er 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

  31. public interface model2{ boolean personnalized; int accessLevel; /*@ invariant 1 <= accessLevel @ && accessLevel <= 4; @*/ /*@ requires @ personnalized == false @ & accessLevel == 4; @ assignable personnalized; @ ensures personnalized == true; @*/ void store_data(); /*@ requires @ personnalized == true @ && accessLevel >=2 @ && accessLevel <= 3; @ assignable \nothing; @*/ void initialize_transaction(); /*@ behavior @ requires @ personnalized == true; @ && accessLevel >=2 && @ accessLevel <= 3; @ assignable \nothing; @*/ void complete_transaction(); /*@ requires accessLevel == 4 @ assignable \nothing; @*/ void pin_change_unblock(); … } Exemple sur Demoney

  32. 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

  33. 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.

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

  35. 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

  36. 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

More Related