Combinaison de preuve de théorèmes et d’évaluation de modèles

Le manque de guides efficaces pour la pratique des méthodes formelles et la systématisation de l’analyse assistée par des outils, constituent des défis importants, dans le cadre des systèmes logiciels. Cela constitue une motivation principale pour une partie de nos travaux. Nous rendons compte ici d’expérimentations faites en analysant une même spécification de différentes façons. La méthode B et l’Atelier B sont utilisés pour les spécifications formelles, pour l’analyse de sûreté et pour les raffinements. L’outil ProB est utilisé pour compléter cette étude avec l’évaluation de modèle (model checking). Cela a permis de découvrir, lors des expérimentations, des erreurs et ainsi d’améliorer les spécifications initiales. Les résultats de ces travaux sont publiés dans [Att04, Att05b, Att06b].

3.1. Motivations. La mécanisation de l’analyse des systèmes et du processus de développement contri-buent à garantir la qualité des logiciels développés. Nous nous intéressons ici à la combinaison effective des outils d’analyse formelle et de développement à travers leur emploi sur des projets. Ces derniers présentent différentes facettes. Les facettes analysées relèvent souvent de la vivacité et de la sûreté. La preuve de théo-rème est utilisée pour la cohérence, le raffinement et les propriétés de sûreté. L’évaluation de modèle est utilisée pour les propriétés de vivacité. Plus généralement l’évaluation de modèle est souvent utilisée pour les systèmes où les aspects contrôle prédominent alors que la preuve de théorèmes est utilisée pour les sys-tèmes très généraux ou des syssys-tèmes où les données prédominent. La combinaison des deux approches est nécessaire lorsque la séparation des aspects n’est pas simple, c’est souvent le cas pour des systèmes de taille importante.

Très souvent ces techniques requièrent un formalisme ou un modèle d’entrée spécifique. Concernant les plates-formes opérationnelles, il n’y a pas d’interaction directe entre les outils dédiés aux différentes techniques. Les utilisateurs (ou développeurs) doivent manipuler différentes entrées selon les outils cibles.

C’est là une limitation pour leur complémentarité dans les développements réels. L’analyse multifacette consiste à appliquer plusieurs méthodes et outils appropriés au même modèle formel pour en étudier les différentes facettes. Cela peut être fait au cours d’un processus de développement allant de la spécification formelle abstraite au code exécutable en passant par l’analyse formelle de propriétés. Nous montrons sur un

cas comment effectuer une telle analyse. Nous utilisons pour ce faire Atelier B et ProB. Ici les spécifications B servent de modèle de référence pour les analyses effectuées.

Généralement, les techniques basées sur la preuve de théorème demandent des interactions avec l’utili-sateur et beaucoup de temps surtout pour les projets de grande taille. L’analyse multifacette peut intervenir bénéfiquement sur ce type de projets ; elle peut contribuer à accélérer l’analyse formelle et couvrir d’autres aspects non couverts par la preuve de théorèmes. Le choix des outils pour l’analyse multifacette est impor-tant afin de réduire les coûts de développement.

Ici l’outil ProB [LB03, LT05] est bien adapté pour compléter l’Atelier B ; en effet ProB utilise le même formalisme d’entrée que l’Atelier B.

Nous mettons en exergue trois principaux aspects dans ce travail : i) l’étude de cas révèle des caracté-ristiques intéressante des spécifications en B : par exemple la prise en compte de l’apparition dynamique de processus qui peuvent alors interagir avec des processus existants ii) la complémentarité des outils employés pour renforcer l’analyse ; iii) un guide méthodologique pour l’analyse multifacette.

Pour l’analyse multifacette, un modèle de référence constitué d’une partie statique et d’une partie dy-namique est utilisée. Selon le système à étudier, la partie statique décrit les entrées, les sorties, les variables d’état et les informations de typage. Il s’agit essentiellement d’un modèle à état abstrait à partir duquel des modèles spécifiques isomorphes sont dérivés pour correspondre à des formalismes spécifiques.

La partie dynamique est constituée de plusieurs opérations vues comme une relation de transition sur l’espace d’états décrit par les variables de la partie statique.

3.2. Présentation de l’étude de cas. Il s’agit d’un cas posant un problème générique : le problème des lecteurs-rédacteurs. Dans le cadre des applications distribuées (par exemple les services Internet), il est utilisé pour traiter les accès aux ressources.

Le problème des lecteurs-rédacteurs est un problème classique d’exclusion mutuelle et de synchronisa-tion dont la solusynchronisa-tion est utilisée dans plusieurs domaines d’applicasynchronisa-tion tels que les systèmes d’exploitasynchronisa-tions et l’accès à des bases de données par des processus. Deux types de processus sont considérés : les proces-sus lecteurs et les procesproces-sus rédacteurs. L’écriture par les procesproces-sus rédacteurs est exclusive mais plusieurs lecteurs peuvent lire simultanément.

Par exemple le système de gestion de fichiers d’un système d’exploitation implante une logique de verrouillage des fichiers afin de le prévenir des incohérences sur les fichiers partagés par les processus concurrents.

Une politique d’exclusion et un mécanisme de synchronisation son nécessaires parce qu’une incohé-rence peut arriver si certains processus (les lecteurs) lisent une ressource lorsque d’autres processus (les rédacteurs) écrivent la ressource.

Analyse. Il y a plusieurs stratégies possibles comme logique de gestion de cette ressource. Une stratégie simple autoriserait l’accès à la ressource à tout moment soit à un nombre quelconque de lecteurs soit à un seul rédacteur. Cette stratégie garantit l’intégrité de la ressource mais elle n’est pas très satisfaisante ; elle donne la préférence aux lecteurs par rapport aux rédacteurs. Considérer par exemple qu’il y ait plusieurs demandes de lecture, s’il y a un lecteur en cours, alors les lecteurs prennent la priorité par rapport aux rédacteurs. Ces derniers peuvent subir la famine qui est une propriété non désirée ici.

Une des solutions souvent utilisées pour palier cette situation est de limiter le nombre de lecteurs consé-cutifs qui peuvent accéder à a ressource. Ainsi les rédacteurs peuvent retrouver la priorité lorsque le nombre de lecteurs consécutifs prévu est atteint. Cette solution est plutôt juste et n’affame pas les rédacteurs.

Afin de développer des logiciels qui intègrent de telles stratégies d’accès, il est important de les étudier soigneusement avant leur implantation et leur développement. Une étude formelle du système en vue peut

Combinaison de preuve de théorèmes et d’évaluation de modèles 101

aider à découvrir les défauts et les corriger ; elle peut aussi aider à développer correctement le système envisagé. C’est ce que nous illustrons dans la suite.

Derrière l’apparence simpliste de ce cas se cachent des aspects intéressants en matière de spécification formelle. Tous les formalismes de spécification ne peuvent pas être utilisés pour traiter ce cas simple mais réaliste. Dans un système d’exploitation par exemple, les processus sont créés à tout moment, ils s’exé-cutent et se terminent. Le nombre de processus n’est pas connu à l’avance, leurs comportements ne sont pas complètement connus, mais ils peuvent interagir avec des processus existants.

La plupart des formalismes de spécification (par exemple les algèbres de processus) ne traitent pas la composition d’un nombre indéfini de processus ; ils exigent la donnée non seulement des comportements des processus mais de leur nombre avant la composition. De plus il n’y a pas de façon simple de gérer la création dynamique de processus ; un système serait par exemple étudié avec un nombre fixé de lecteurs et de rédacteurs. En conséquence certains aspects liés à la création dynamique des processus ne sont pas bien couverts. L’utilisation de Event B est ainsi justifiée par le fait que nous pouvons y prendre en compte les aspects évoqués ci-dessus.

Nous présentons dans la suite l’analyse multifacette sur l’étude.

3.3. Analyse formelle des lecteurs/rédacteurs. Nous utilisons une spécification B comme modèle de référence. Elle possède une partie statique et une partie dynamique. Nous n’avons pas besoin de dériver des modèles d’entrée spécifique puisque les outils choisis utilisent les spécifications B comme entrée. Nous effectuons les analyses directement sur les mêmes spécifications B. Les rétroactions venant des outils per-mettent d’améliorer le modèle de référence.

Les principales étapes de l’expérience sont : la spécification abstraite en Event-B, le raffinement et l’analyse des propriétés.

3.3.1. La spécification B : le modèle de référence. L’approche Event B permet de spécifier le compor-tement asynchrone de processus. De plus on peut y spécifier l’interaction entre un nombre indéterminé de tels processus asynchrones en utilisant les substitutions nondéterministes gardées.

Nous considérons deux types de processus en nous conformant au cahier de charges : les processus lecteurs et les processus rédacteurs.

Première étape : spécification abstraite Nous avons spécifié deux systèmes abstraits : le premier est nommé Readers, le second est nommé Writers. Ils utilisent les mêmes ensembles READER et WRITER et leurs spécifications sont quasiment symétriques. Les ensembles READER et WRITER sont les abstrac-tions des processus lecteurs et rédacteurs.

Le schéma du système abstrait des Readers est donné dans la figure 4, celui du système abstrait Writers est similaire.

La variable readers décrit les lecteurs courants (abstraction de processus lecteurs). L’invariant du sys-tème abstrait Readers est donné dans la figure 5.

Propriété d’exclusion. Le prédicat not((card(activeWriter) = 1) ∧ (card(activeReaders) ≥ 1)) qui apparaît dans l’invariant (figure 5) décrit la propriété d’exclusion requise entre les lecteurs et rédacteurs. Il stipule qu’on ne peut avoir simultanément des lecteurs et un écrivain actifs. C’est une propriété de correction incluse dans l’invariant.

Le système abstrait Readers possède les événementswant2read,reading,endReadingetnewReader.

L’événementwant2readsurvient lorsqu’un lecteur donné rr demande à lire ; il est alors noté dans la

SYSTEM Readers

SETS READER WRITER

VARIABLES

readers, waitingReaders, activeReaders, activeWriter INVARIANT · · · INITIALISATION · · · EVENTS want2read = · · ·b ; reading = · · ·b ; endReading = · · ·b ; newReader = · · ·b END

FIG. 4. Spécification B des lecteurs

INVARIANT

readers⊆ READER ∧ waitingReaders ⊆ READER ∧ activeReaders ⊆ READER

∧ card(activeReaders) ≥ 0 ∧ readers ∩ waitingReaders = {} ∧ activeReaders ∩ waitingReaders = {} ∧ activeReaders ∩ readers = {}

∧ activeWriter ⊆ WRITER ∧ card(activeWriter) ≤ 1 ∧ ¬ ((card(activeWriter) = 1) ∧

(card(activeReaders) ≥ 1))

FIG. 5. Spécification B des lecteurs : l’invariant

want2read=b ANYrrWHERE rr∈ readers ∧ rr /∈ waitingReaders ∧ rr /∈ activeReaders THEN waitingReaders:= waitingReaders ∪ {rr} k readers := readers − {rr} END

La spécification de l’événementreadingest la suivante : reading=b ANYrrWHERE rr∈ waitingReaders ∧ activeWriter = {} THEN activeReaders:= activeReaders ∪ {rr} k waitingReaders := waitingReaders − {rr} END

La garde de l’événementreadingstipule que : n’importe quel lecteur rr en attente de lecture, et tel qu’il n’y a aucun rédacteur en attente, peut commencer à lire. Notons qu’on n’a pas spécifié uniquement le

Combinaison de preuve de théorèmes et d’évaluation de modèles 103

comportement d’un processus lecteur, mais celui de n’importe quel nombre de lecteurs. Cela est fait grâce à l’usage du nondéterminisme pour spécifier les événements du système abstrait.

L’invariant du second système abstrait (Writers) est similaire à celui de Readers mais il a en plus la contrainte sur l’exclusion entre les rédacteurs : card(activeWriter) ≤ 1.

Le système abstrait des rédacteurs (Writers) a la même structure que Readers ; il a les événements want2write,writing,endWritingetnewWriter. L’événementwritingest comme suit :

writing=b ANYwwWHERE ww∈ waitingWriters ∧ activeReaders = {} THEN activeWriter:= {ww} k waitingWriters := waitingWriters − {ww} END

Ensuite nous combinons parallèlement (voir chapitre 5) les systèmes abstraits pour obtenir un système interactif global readWrite.

readWrite = Readers]|[ Writersb

Le système abstrait résultant a comme invariant la conjonction des invariants des sous-systèmes ; ses événements consistent en une union des événements venant de Readers et Writers.

Dans cette première étape de l’étude nous avons considéré une stratégie simple (un nombre quelconque de lecteurs ou un seul rédacteur) pour définir une première solution opérationnelle. Nous avons ensuite raffiné cette solution pour prendre en compte la propriété d’équité.

Deuxième étape : raffinement Nous raffinons les spécifications qui résultent de la première étape ; nous incluons la variable nbConsecutiveReaders, une constante maxConsecutiveR et une nouvelle propriété dans

l’invariant. Nous avons introduit également deux nouveaux événements :leaveReaderetleaveWriter.

Le premier simule la sortie/destruction d’un lecteur, le dernier simule la sortie/destruction de processus. La propriété incluse concerne l’équité : il n’y a pas que des lecteurs ou des rédacteurs qui sont autorisés à accéder à la ressource. Cela est géré en limitant (avec maxConsecutiveR) le nombre de lectures consécutives. Les événements et leurs gardes son réécrits et mis à jour en fonction des nouvelles variables. Nous avons utilisé une approche montante : les systèmes abstraits Readers et Writers sont raffinés respectivement en ReadersR en WritersR. Ces derniers sont composés parallèlement pour obtenir le système interactif global nommé readWriteR. Dans le raffinement, la variable nbConsecutiveR est mise à 0 lorsqu’un rédacteur obtient l’accès en écriture.

readWriteR= ReadersR]|[ WritersRb

INVARIANT writers⊆ WRITER ∧ activeWriter ⊆ WRITER ∧ card(activeWriter) ≤ 1 ∧ waitingWriters ⊆ WRITER ∧ writers ∩ waitingWriters = {} ∧ activeWriter ∩ waitingWriters = {} ∧ activeWriter ∩ writers = {} ∧ nbActiveReaders ∈ NAT ∧ nbActiveReaders = card(activeReaders) ∧ nbConsecutiveR ∈ NAT ∧ nbConsecutiveR ≤ maxConsecutiveR ∧ readers ⊆ READER ∧ waitingReaders ⊆ READER ∧ activeReaders ⊆ READER ∧ card(activeReaders) ≥ 0 ∧ readers ∩ waitingReaders = {} ∧ activeReaders ∩ waitingReaders = {} ∧ activeReaders ∩ readers = {} ∧ ¬ ((card(activeWriter) = 1) ∧ (card(activeReaders) ≥ 1))

3.3.2. Expérimentations. Toutes les spécifications ont été analysées (cohérence et raffinement) et prou-vées correctes en utilisant l’Atelier B.

Dans le contexte d’une analyse formelle sans génération de code l’étude aurait pris fin là. Mais dans le cadre de l’analyse multifacette nous poursuivons l’étude en animant le système modélisé et en l’explorant avec l’outil ProB.

Animation. Le système readWriteR est animé en utilisant la stratégie aléatoire pour les déclenchements et un paramétrage du nombre d’opérations à 40. Le résultat semble satisfaisant ; la couverture d’état montre que toutes les opérations (correspondant aux événements) sont couvertes.

Test du raffinement. L’espace d’état entier du système readWrite est exploré. Le graphe de transition résul-tant est stocké et les traces sont comparées avec celles du système raffiné readWriteR. Aucune erreur n’est détectée.

Évaluation de modèle L’analyse est poursuivie par l’exploration des états en utilisant la fonctionnalité Temporal Model Checking.

La fonctionnalitéCompute Coveragepermet d’avoir le nombre d’états couverts pendant l’exploration

et indique les états bloquants (deadlocks). Un état d’interblocage a été détecté ici sur 3223 états. Nous avons découvert la cause de cette situation en analysant cet état : un processus lecteur (READER2) est actif et

nbConsecutiveR= 10; normalement, l’événement endReadingdoit se produire mais ce n’est pas le cas. Nous revenons alors à la spécification qui suit :

Synthèse et perspectives sur cette étude 105

endReading=b

ANYrrWHERE/* an active reader finishes reading */

rr: activeReaders ∧ nbActiveReaders > 1 THEN activeReaders:= activeReaders − {rr} k readers := readers ∪ {rr} k nbActiveReaders := nbActiveReaders − 1 END

Il apparaît que la garde de l’événement est fausse. Nous devions avoir nbActiveReaders ≥ 1. En effet

le problème est que, lorsqu’on a qu’un seul processus en cours de lecture, la gardeendReadingn’est pas

vraie et le processus ne peut se terminer d’où le blocage. La spécification est alors corrigée en conséquence. Nous n’avions pas détecté le problème avec le prouveur Atelier B. En effet la preuve de cohérence, n’est pas en cause car l’invariant n’est pas violé.

Cela renforce l’obligation de preuve d’absence de blocage posée par Event B : "si aucune garde n’est vraie le système est bloquant".

En conséquence ProB a aidé à découvrir une obligation de preuve (liée à Event B) non déchargée. 4. Synthèse et perspectives sur cette étude

Nous avons proposé et utilisé une approche d’analyse multifacette pour étudier des système. L’étude est illustrée par le problème des lecteurs-rédacteurs ; il aborde la composition, le raffinement, la preuve de théorème et l’évaluation de modèle afin de couvrir les diverses étapes dans un développement. Nous avons spécifié les lecteurs, les rédacteurs puis nous les avons combiné pour avoir un système interactif global. Une des principales caractéristiques de ce système est l’architecture dynamique des processus (composition d’un nombre indéfini de processus). Les systèmes abstraits Readers et Writers sont raffinés pour améliorer le modèle B initial et pour assurer les propriétés désirées. Le raffinement concerne la prise en compte de propriétés et l’introduction de nouveaux événements.

L’adoption de l’approche multifacette pousse le spécifieur à utiliser plusieurs techniques d’analyse. Ce faisant, la complémentarité des techniques et outils permet d’affiner l’étude entreprise.

Nous avons ainsi combiné les techniques de preuve de théorème et d’exploration de modèles via les outils Atelier B et ProB. Nous avons mis en évidence leur complémentarité, pour décharger les obligations de preuve et montrer l’absence de blocage.

Pour des systèmes de grande taille, nous pensons que l’approche multifacette est une voie intéressante ; le travail est un peu plus aisé lorsque les formalismes d’entrée des divers outils employés sont proches voir les mêmes, sinon il faut avoir recours à des traductions systématiques d’un formalisme à un autre afin de maintenir la cohérence globale. Dans cette étude nous avons considéré la méthode B mais il faut noter que parmi les environnements permettant la mise en œuvre de différentes techniques sur le même formalisme d’entrée on peut citer PVS [Sha00] ; le système PVS permet de combiner preuve et évaluation de modèles pour l’analyse de propriétés.

Dans le prolongement de ce travail nous travaillons sur l’analyse multifacette de modèles construit à

CHAPITRE 8