Fin du cours Spec2 Equivalence de processus et bisimulation Les deux sens du mot Modèle et model-checking Types de propriétés Sûreté et vivacité Vérification avec LTSA Henri Habrias, IUT de Nantes 20 mars 2006

Bisimulation et équivalence Equivalence observationnelle : On peut distinguer deux agents S0 et S1 si un agent extérieur interagissant avec S0 et S1 peut détecter qu’ils n’ont pas le même comportement. Ainsi, avec LTSA, quand vous faites un « run », vous constatez que vous n’avez pas les mêmes actions déclenchables.

Deux agents non équivalents P0 = (a -> b -> P1 | a -> S2), P1 = STOP, P2 = (c -> d -> S0). Q0 = (a -> Q1), Q1 = (b -> Q2 | c -> Q3), Q2 = STOP, Q3 = (d -> Q0). a b P0 a b Q0 c a c d d

Même langage accepté …mais… Ces deux agents P et Q acceptent le même langage : (acd)* ab Mais , Q0 n’est pas déterministe.

Observation P0 = (a -> b -> P1 | a -> S2), P1 = STOP, P2 = (c -> d -> S0). Q0 = (a -> Q1), Q1 = (b -> Q2 | c -> Q3), Q2 = STOP, Q3 = (d -> Q0). RUN a x b d x a x b c x c …. RUN ax cx dx ax cx dx ax bx STOP

Equivalence forte/faible Equivalence faible lorsqu’on ne considère pas l’action tau Equivalence forte lorsqu’on considère l’action tau comme n’ importe quelle autre action.

Bisimulation Quand deux agents sont équivalents pour tous leurs états. P est en bisimulation avec Q ssi : pour tout a appartenant au vocabulaire si P ---a---> P’ alors il existe Q’ tel que Q---a-->Q’ et P’ équivalent à Q’ si Q ---a---> Q’ alors il existe P’ tel que P---a-->P’ et P’ équivalent à Q’ R. Milner

Bisimulation faible P0 = (a -> b -> c -> P0 | b -> a -> c -> P0). P1 = (c -> S1). ||SYS = (P0 || P1)\{c}. P0 P1 P0 a b a || b c a c tau b a b Q0 a b a b Q0 = (a -> b -> S1 | b -> a -> Q0).

Le concept de modèle Premier sens : Celui d’interprétation, i.e. attribution d’un sens à des énoncés formels de sorte qu’ils soient vérifiés. Exemple : la géométrie vue comme un modèle d’un langage formel, plutôt que la formalisation de propriétés idéalisées à partir de l’ observation de l’espace sensible. (Hourya Sincaceur)

Modèle : premier sens Interprétations Enoncé formel Abstrait Spécification Interprétations Modèle 1 Modèle 2 Modèle 3 Concret

Modèle : deuxième sens Modéliser c’est associer un énoncé formel à une « réalité empirique », un phénomène physique. Un modèle est un prototype, une simulation de la réalité. Définition de Marvin Minsky « Un objet O est un modèle d’une réalité R si O permet de répondre aux questions que l’on se pose sur R. »

Modèle : deuxième sens Enoncé formel Modélisation Phénomène

Deux faces, 1 seule activité «  Les deux sens du concept de modèle ne sont que les deux faces complémentaires d’une même activité : interpréter. Interpréter est inéluctable, qu’il s’agisse d’interpréter un formalisme, ou, inversement d’interpréter mathématiquement un ensemble de données. D’une part, parce qu’un langage qui n’aurait pas de modèle n’a aucun intérêt, D’autre part et réciproquement, parce que l’expression n’est pas le miroir de l’expérience. » Hourya Sinaceur

« Model-checking » Vérification de modèle en français ! On modélise le système physique (le système) et les propriétés que le système doit vérifier. L’algo de model-checking prend : en entrée, l’énoncé et le propriétés formelles à vérifier Donne en réponse oui ou non selon que les propriétés sont vérifiées ou non par le système modélisé.

« Model-checking » Énoncé formel modélisation Est-ce que les Phénomène propriétés sont vérifiées ? Propriété formelle modélisation

Vérification de propriétés Propriétés d’invariance : l’invariant d’une machine B Propriétés « dynamiques »

Types de propriétés 1- Atteignabilité : Une certaine situation peut être atteinte 2-Sûreté (safety) : Sous certaines conditions, quelque chose ne se produira jamais 3-Vivacité (Fatalité, liveness, Eventually): Sous certaines conditions, quelque chose finira par avoir lieu 4-Equité (Fairness) : Sous certaines conditions, quelque chose aura lieu (ou n’aura pas lieu) un nombre infini de fois.

Propriétés vérifiées avec LTSA safety (sûreté) : Rien de mal n’arrive pendant l’exécution liveness (vivacité) : Quelque chose de bon arrive forcément (eventually) Dit autrement : Safety : Le système n’atteint pas un mauvais état. Vivacité : Le système atteint forcément un bon état.

Propriété de sûreté en B classique vs en prog concurrente (programmes séquentiels) On veut que l’état final d’un programme (l’implantation d’une opération) soit correct (respecte l’invariant) Propriété de sûreté (en prog. Concurrente) : Exclusion mutuelle, absence de verrou fatal (deadlock)

Propriété de vivacité en B classique vs en prog concurrente Propriété de vivacité (en prog. Séquentielle) Le programme se termine (la fonction est définie) Propriété de vivacité (en prog. Concurrente) concernent souvent des systèmes qui ne s’arrêtent pas.

Politique d’ordonnancement On va voir des propriétés de vivacité relatives à l’accès à des ressources. Les propriétés de vivacité sont affectées par la politique d’ ordonnancement qui détermine quelle action dans un ensemble d’actions sont choisies pour exécution.

Safety (avec LTSA) ACTIONNEUR = (commande -> ACTION), ACTION = (reponse -> ACTIONNEUR | commande -> ERROR). property ACTIONNEUR_SUR = (commande -> reponse -> ACTIONNEUR_SUR ).

Vérif d’une propr. de safety PERSONNE = (entrer -> frapper -> PERSONNE). Il est poli de frapper avant d’entrer : Property POLI = (frapper -> entrer -> POLI). Composition: DEFAULT = POLI || PERSONNE State Space: 2 * 2 = 2 ** 2 Composing... property POLI violation. -- States: 1 Transitions: 1 Memory used: 2361K Composed in 130ms

Safety : définition Une propriété de sûreté (safety) P définit un processus déterministe qui asserte que toute trace incluant les actions de l’alphabet de P, est acceptée par P.

Autre ex. de prop de safety Quand un processus entre en section critique (p[i].entrer), ce même processus doit sortir de la section critique (p[i]. Sortie) avant qu’un autre processus puisse entrer. Property MUTEX = (p[i:1..3]. entrer -> p[i] . sortie -> MUTEX]

Vivacité en LTSA Propriété de progression (progress) : quelque soit l’état du système, une action spécifiée finira par être exécutée. Opposée à la famine (starvation)

Hypothèse d’équité Fair choice : Si un choix parmi un ensemble de transitions est exécuté infiniment souvent, alors chaque transaction de cet ensemble sera exécuté infiniment souvent. PIECE = (toss -> heads -> PIECE | toss -> tails -> PIECE) Si la politique d’ordonnancement n’est pas équitable, on peut toujours choisir la transition toss -> heads.

Progress property Progress P = {a1, a2, …,an} définit une propriété de progression P qui asserte que dans une exécution infinie d’un système, au moins une des actions a1, a2, …,an sera exécutée infiniment souvent. A toute étape d’exécution, une des actions de l’ensemble de définition de la propriété de progression, sera forcément exécutée. progress HEADS = {heads} progress TAILS = {tails}

Propriété de progrès TWOCOIN = (pick -> COIN | pick -> TRCK), TRICK = (toss -> heads -> TRICK), COIN = (toss -> heads -> COIN | toss -> tails -> COIN). progress TAILS = {tails} est violée Progress HEADSorTAILS = {heads, tails} n’est pas violée

Ensemble terminal d’états L’analyse de la propriété de progression consiste à rechercher d’ abord un ensemble terminal d’états. Un ensemble terminal d’états est un ensemble dans lequel chaque état est atteignable de tout autre état de l’ensemble via une ou plusieurs transitions et s’il n’y a pas de transition de cet ensemble vers tout état qui est hors de cet ensemble. i.e. une composante fortement connexe qui n’a pas de chemin vers des nœuds situés hors de la composante.

Algo de vérif de la prop. de progression Vérifier une propriété de progression progress P ={a1, …,an} est simplement vérifier que dans chaque ensemble terminal, il y a au moins une des actions de l’ensemble de progression {a1, …,an}. Inversement, une propriété de progression est violée si l’analyse trouve un ensemble terminal dans lequel il n’y a aucune des actions de {a1, …, an}.