Liste des tableaux
2.4 Modélisation Formelle
2.4.1 Spécifications Algébriques
2.4.2.1 Méthode VDM
La méthode VDM (“Vienna Development Method”) est une méthode de spécification formelle orientée modèle qui a ses origines dans les recherches réalisées au laboratoire IBM de Vienne sur les méthodes de spécification formelle dans les années 60.
VDM est composée d’un ensemble de techniques pour la spécification formelle des systèmes informatiques à travers un langage de spécification appelé VDM-SL (“VDM-Specification Language”). Elle introduit des règles pour le raffinement des données et des opérations ainsi qu’une théorie de preuve. Les raffinements établissent un lien entre la spé-cification des besoins et l’implantation. À travers la théorie de la preuve, les propriétés d’un système peuvent être vérifiées ainsi que la correction des décisions prises lors de la concep-tion [Ver95].
Une spécification écrite avec le langage VDM-SL est un modèle mathématique construit avec des types de données simples comme les ensembles, les listes et les applications et avec des opérations qui peuvent changer l’état du modèle. Le langage VDM-SL est en cours de standardisation par l’ISO.
Dans VDM, les types de données définis sont les entiers, les booléens, les entiers re-latifs, les réels et les chaînes de caractères, ainsi que les opérateurs qui leurs sont asso-ciés. Les autres types utilisés dans le langage doivent être composés à travers l’utilisation des constructeursensemble,séquence,compose,produitetcorrespondance: composeconstruit des types semblables aux structures du langage C,produitconstruit un typecomposeoù les champs ne sont pas nommés etcorrespondanceconstruit des types décrits par deux valeurs. Tous ces constructeurs ont des opérandes pour manipuler leurs éléments ainsi que des générateurs pour la création des éléments.
Avec VDM-SL, on peut aussi définir des invariants des types afin de res-treindre leur ensemble de valeurs possibles. Cette restriction est réalisée soit à travers des fonctions booléennes, soit à travers des appels à d’autres fonctions, soit avec une combinai-son des deux. Desétats sont aussi définis avec VDM-SL. Unétatest une collection de variables externes qui définissent la situation d’un système : un système démarre avec un état initial et change d’état par l’application d’opérations.
Les opérations dans VDM peuvent être définies de deux manières différentes, soit de manière implicite, soit de manière directe ou explicite. Avec le mode implicite, on définit ce que l’opération fait (le quoi) sans définir la façon selon laquelle elle est exécutée. Le mode direct définit le mode de calcul utilisé en donnant un algorithme. Les opérations définies implicitement sont appeléesfonctionsi elles ne changent pas l’état du système.
Les spécifications VDM utilisent une approche basée sur desmodules pour la structu-ration de la spécification. Les types de données, les invariants et les états sont organisés à l’intérieur d’un modulecomposé de trois parties : une interface pour contrôler l’importa-tion et l’exportal’importa-tion de définil’importa-tions, un état et sa valeur initiale, ainsi que la définil’importa-tion des opérations. Des commentaires peuvent être introduits dans un module ; ils sont précédés par le caractère “–”.
2.4 Modélisation Formelle 39
Cette section est une petite introduction à la méthode VDM ; pour une étude plus com-plète on peut voir [Jon90] d’où a été emprunté l’exemple présenté dans la figure 2.12 pour donner une idée du type de spécification produite avec VDM, et cela sans rentrer dans les détails des symboles utilisés. La figure 2.12 donne la spécification d’un sac en utilisant un module ; les mots en gras sont des mots clés du langage et ceux en italique sont des com-mentaires. module BAG parameters types X – Description de l’Interface exports types Bag operations COUNT:X,!o N; ADD:X,!o
– Description des types et états
definitions types Bag=X,!m N1; state State of b:Bag init(mk,State(b0 ))Mb0 =fg end;
– Desc. des fonctions et opérations
functions mpc:XBag!N mpc(e;m)M if e2dom m them m(e)else0 operations COUNT(e: X)c:N ext rd b:Bag post c=mpc(e;b) ADD(e:X) ext wr b:Bag post b= ( b yfe7!mpc(e; ( b )+1g end BAG
Figure 2.12 - Exemple de Spécification VDM [Jon90]
En regardant l’exemple de la figure 2.12, on peut dire que la notation utilisée par la méthode VDM est similaire à celle utilisée par la méthode Z (cf. section 2.4.2.2) avec une syntaxe additionnelle pour la description formelle de modules. La possibilité de définition d’une opération d’une manière directe est un avantage pour la description formelle d’algo-rithmes de logiciels.
La méthode VDM est supportée par une série d’outils. On peut citer par exemple “IFAD VDM-SL Toolbox” [IFA96] qui est composé d’un ensemble d’outils pour la vérification syntaxique et sémantique, l’analyse de tests, l’exécution et le débugage des spécifications VDM. Cet outil est développé par l’Institut d’Informatique Appliquée du Danemark. Un autre outil, du domaine public, est le parseur VDM [Rhi94] développé par l’Université
Tech-nologique de Braunsweis en Allemagne. Il existe aussi des styles LATEX pour l’écriture de spécifications VDM. Pour une liste des outils ainsi que pour des références sur VDM on peut consulter l’article de P. G. Larson [Lar96].
2.4.2.2 Méthode Z
Z est un langage pour la spécification formelle de systèmes. Bien qu’il ne soit pas une méthode, on peut utiliser la notation Z pour produire des spécifications avec une approche orientée modèle. La notation Z a été introduite par J. R. Abrial à Grenoble, puis à EDF [Abr78] au cours des années 70, et développée par le “Programming Research Group” de l’Université d’Oxford pendant les années 1980-1985.
Le but principal recherché avec l’utilisation de Z est la spécification de systèmes. Cette spécification doit définir ce que le système doit faire sans dire comment le faire. Cependant des études5ont été réalisées pour raffiner des spécifications Z afin de produire, à partir d’un modèle, un autre modèle plus proche de l’implantation car Z n’introduit pas de notation pour décrire des algorithmes [Dil94]. Le but du travail présenté dans cette thèse étant la spécification de systèmes d’information, on ne s’intéresse pas à cet aspect algorithmique.
Une spécification Z traite un système comme des machines abstraites pour lesquelles l’état interne (un ensemble de variables) peut être modifié ou accédé seulement par les
opé-rations associées à la machine [Led94]. La notation Z utilisée dans la spécification est basée
sur la théorie des ensembles ainsi que sur la logique du premier ordre. Des notations sont proposées pour les différents termes d’une spécification : prédicats, ensembles, relations, fonctions, séquences, etc. Dans Z, il existe aussi une notation appelée Schéma qui permet la réutilisation du texte mathématique et la description à la fois des aspects statiques et dynamiques d’un système. Selon M. Spivey [Spi89], les aspects statiques comprennent les états que le système peut prendre et les relations d’invariance qui sont maintenues lorsque le système passe d’un état à un autre. Les aspects dynamiques décrivent les opérations poten-tielles, les relations liant les entrées et les sorties d’une machine abstraite et les modifications d’états se produisant.
Le langage Z est supporté par des outils pour la vérification de la syntaxe et des types des spécifications. Parmi ces outils on peut citer le “ZTC - Z Type Checker” développé
5Pour passer de la spécification à l’implantation, M. Spivey [Spi89] utilise une relation d’abstraction entre un état abstrait et un état concret du système ainsi que des raffinements (voir plus bas). S. King [Kin90] propose l’utilisation du calcul de raffinements introduit par C. C. Morgan ; dans le chapitre 7 du livre de J. B. Wordsworth [Wor92] l’utilisation des concepts présents dans le travail de Dijkstra est proposée et dans le chapitre 15 du livre de A. Diller [Dil94] l’utilisation des formules de la logique de Floyd-Hoare est introduite.
2.4 Modélisation Formelle 41
par X. Pia [Jia95] de l’Université DePaul et qui appartient au domaine public ainsi que le vérificateur de types “Fuzz” développé par M. Spivey. De plus, des polices pour l’écriture de spécifications Z sont disponibles pour Unix et Windows ainsi que des styles LATEX. Pour une liste des outils ainsi que pour des références sur Z, on peut consulter l’article de J. Bowen [Bow96b].
Nous présentons la notation Z à travers un exemple de modélisation d’un agenda d’an-niversaires tel qu’il est introduit par M. Spivey [Spi89]. La notation nécessaire à la com-préhension de cet exemple est donnée à l’annexe F. Pour une description plus complète de Z, on peut consulter [Nic96] qui présente le langage Z tel qu’il a été proposé pour la standardisation à l’ISO.
Un Agenda des Anniversaires
Afin de manipuler les noms des personnes et les dates on doit définir des types de base pour le système :
[NAME;DATE]
Le premier schéma introduit décrit l’espace d’état du système.
BirthdayBook known: PNAME
birthday:NAME !7 DATE know=dom birthday
Dans ce schéma, la partie déclarative (première partie d’un schéma) introduit l’en-semble des noms enregistrés (known) et une fonction partielle qui à partir d’un nom rend la date d’anniversaire correspondante (birthday). La deuxième partie d’un schéma, la partie des prédicats représente une relation vraie pour tout état du système et qui doit être maintenue à vraie quelle que soit l’opération appliquée. Cette relation est un
invariant du système.
Après avoir défini l’espace d’état du système, il faut définir l’état initial pour celui-ci, ce qui est fait avec le schéma donné ci-dessous.
InitBirthdayBook BirthdayBook known=?
Ce schéma introduit un important concept du langage Z qui est l’inclusion de schémas. Ici, le schéma BirthdayBook est inclus dans le schéma InitBirthdayBook ce qui signifie que les variables et les prédicats définis dans BirthdayBook sont valables aussi dans
InitBirthdayBook : comme known est vide, l’invariant know = dom birthday oblige que birthday soit également vide.
L’espace d’état et l’état initial étant définis, on peut passer à la définition des opéra-tions. La première opération définie est l’ajout d’un nouvel anniversaire. Le schéma correspondant est donné ci-après.
AddBirthday BirthdayBook name?:NAME date?:DATE name?62known birthday0
=birthday[fname? 7!date?g
Avec ce schéma de nouvelles notations sont introduites. Ainsi un signe d’interrogation (“ ?”) suit une variable lorsqu’il s’agit d’une variable d’entrée : name?et date? vont recevoir le nom et la date dans l’opération. La notationBirthdayBook veut dire que
le schéma décrit une opération qui change l’état du système ; elle veut dire aussi que les variables du schéma BirthdayBook sont introduites dans le schéma AddBirthday avec la possibilité d’avoir des observations de l’état avant et après le changement. Cela introduit implicitement une autre notation : les variables qui représentent l’état
d’après ont comme décoration un prime comme par exemple birthday0
. La première ligne de la partie des prédicats introduit la pré-condition6pour le succès de l’opération à travers l’interdiction d’inclusion d’un nom connu du système. La deuxième ligne indique que lorsque la pré-condition est satisfaite, la nouvelle paire name? 7! date?
est ajoutée au système.
6M. Lemoine [Spi94] dans la traduction française du livre de Spivey, fait ressortir le fait que le terme pré-condition est une simple interprétation due au connecteur logique “et” qui lie les deux formules.
2.4 Modélisation Formelle 43
Le schéma ci-dessous introduit une opération pour trouver la date d’anniversaire d’une personne connue du système.
FindBirthday
BirthdayBook name? :NAME date!:DATE name? 2known
date!=birthday(name?)
BirthdayBook introduit les quatre variables (name et date avant et après) et indique
qu’il s’agit d’une opération qui ne change pas l’état du système (implicitement on a
known0
= known et birthday0
= birthday). La variable date suffixée avec le signe
d’exclamation (“ !”) indique qu’il s’agit d’une variable de sortie pour l’opération. La partie inférieure du schéma montre que FindBirthday prend un nom en entrée (name?) qui doit exister dans le système (la pré-condition) et fournit la date d’anniversaire correspondante comme sortie (date!).
Le schéma qui suit introduit l’opération la plus importante d’un système d’agenda des anniversaires : c’est l’opération qui fournit les personnes qui ont leur anniversaire à une date donnée.
Remind
BirthdayBook today? :DATE cards!: PNAME
cards!=fn:knownjbirthday(n)=today?g
Ce schéma présente une opération qui ne change pas l’état du système (la convention
). Dans ce schéma, il n’y a pas de pré-condition définie. Il donne comme sortie une variable (cards!) égale à l’ensemble de toutes les personnes qui ont leur anniversaire à la date today?; pour cela le schéma utilise la définition d’ensemble en intention et la fonction birthday introduite avecBirthdayBook.
Le processus grâce auquel on passe des spécifications à l’implantation est appelé
raf-finement. Selon J. M. Spivey [Spi89], l’idée principale porte sur la description des
données concrètes que le programme utilisera comme étant une représentation des données abstraites de la spécification, pour ensuite dériver les descriptions des opéra-tions en terme de structures de données concrètes.
On présente ici le raffinement pour une partie de l’exemple développé (avec des struc-tures de données abstraites) jusqu’à maintenant. L’agenda d’anniversaires est implanté à l’aide de deux tableaux déclarés par :
names : array[1::]of NAME ;
dates : array[1::]of DATE ;
Ces tableaux sont modélisés mathématiquement par les fonctions :
names:N1!NAME dates:N1!DATE
Un élément du tableau défini par names[i]correspond à la valeur names(i)de la fonc-tion, ce qui est déclaré de la façon suivante :
names0
=namesfi7!vg
7
Un schéma pour décrire l’espace d’états avec des schémas concrets de données est développé ci-dessous. Ce schéma introduit les fonctions décrites ci-dessus ainsi que la variable hwm (“high water mark”) pour contrôler le nombre d’éléments des tableaux. Le prédicat du schéma interdit la duplication d’éléments dans le tableau names.
BirthdayBook1 names:N1 !NAME dates:N1 !DATE hwm:N1 8i;j:1::hwm i6=j)names(i)6=names(j)
La prochaine étape vers l’implantation est l’établissement d’un pont entre les deux vues des états d’un système : la vue qui présente l’espace d’états abstraits BirthdayBook et celle qui présente l’espace d’états concrets BirthdayBook1. Ce pont est appelé
rela-tion d’abstracrela-tion par Spivey. Le schéma présenté ci-dessous introduit cette relarela-tion.
7L’opérateur est l’opérateur écrasement de Z. Exemple d’utilisation : soient f;g : N $ N,
f == f0 7! 1;1 7! 2get g == f0 7! 3;2 7! 4g; alors f g = f1 7! 2;0 7! 3;2 7! 4g; la rela-tion g “écrase” partiellement f : le couple07!3de g “écrase” le couple07!1de f .
2.4 Modélisation Formelle 45 Abs BirthdayBook BirthdayBook1 known=fi:1::hwmnames(i)g 8i:1::hwm
birthday(names(i))=dates(i)
À travers le premier prédicat, une relation entre des personnes et des noms est établie. Le deuxième prédicat montre qu’une personne “i” qui s’appelle name(i) a sa date d’anniversaire définie par date(i).
Si on peut avoir différents états concrets pour le même état abstrait (cas de plusieurs implantations différentes) le contraire n’est pas vrai : un état concret ne représente qu’un état abstrait et un seul.
Après la définition de l’état concret, les opérations peuvent être définies par rapport à cet état. Ainsi l’opération AddBirthday1est présentée ci-dessous.
AddBirthday1 BirthdayBook1 name? :NAME date? :DATE 8i:1::hwmname? 6=names(i) hwm0 =hmw+1 names0 =namesfhmw0 7!name?g dates0 =datesfhmw0 7!date?g
Ce schéma présente une implantation valide [Spi89] de AddBirthday pour deux rai-sons :
– lorsque l’opération AddBirthday est correcte dans un espace d’états abstraits quelconque, l’implantation AddBirthday1 est correcte dans l’état concret cor-respondant ;
– l’état final qui résulte de AddBirthday1représente un état abstrait que AddBirthday pourrait produire.
Le schéma AddBirthday1peut se traduire directement vers un langage de program-mation :
procedure AddBirthday(name:NAME ; date:DATE); begin hwm:=hwm+1; names[hwm]:=name ; dates[hwm]:=date ; end ;
L’implantation d’autres opérations peut exiger la définition de nouveaux schémas pour de nouveaux états concrets ainsi que de nouvelles relations d’abstraction. Cependant la procédure de raffinement reste la même.
L’exemple ci-dessus donne une idée des spécifications produites avec Z. Quelques re-marques peuvent être faites [Spi89] :
– les schémas permettent de décrire aussi bien l’état d’un système que les opérations qui peuvent être appliquées sur cet état ;
– les données du système sont manipulées à l’aide de types mathématiques classiques comme les ensembles et les fonctions ;
– les invariants d’états sont une information importante entre les états ;
– les opérations sont représentées comme des relations “entrée-sortie” ce qui n’impose pas une solution impérative d’implantation.
2.4.3 Spécifications Hybrides
Les spécifications hybrides ont des caractéristiques des spécifications algébriques et des spécifications orientées modèles. Des exemples de spécifications hybrides sont LOTOS [GLO91] et la méthode B. On présente B dans la section suivante.
2.4.3.1 Méthode B
B est une méthode de développement formelle développée à l’origine par J. R. Abrial avec la collaboration d’autres chercheurs du “Programming Research Group” de l’Univer-sité d’Oxford dans les années 80. Abrial travaillait alors pour British Petroleum dans un projet appelé “B-Technology”.
2.4 Modélisation Formelle 47
La Méthode-B [Abr96] est composée d’une collection de techniques mathématiques uti-lisées pour la spécification, la conception et l’implantation, comme des machines abstraites, de logiciels critiques de sécurité. Elle comprend une notation AMN (Abstract Machine No-tation) et la méthode, la notation AMN étant à la fois le langage de spécification et de conception.
Le processus de développement d’un logiciel avec la méthode B, de la spécification à l’implantation doit respecter les étapes suivantes [Lan96] :
1. analyse des besoins : un modèle d’analyse composé de modèles informels ou structu-rés doit être construit pour le système ;
2. développement de la spécification : une spécification formelle est produite. Pour y arriver, on doit (a) décomposer le modèle d’analyse en machines abstraites, (b) “ani-mer” les machines abstraites pour vérifier la spécification par rapport aux besoins et à des scénarios de test et (c) générer et prouver les contraintes internes de cohérence ;
3. conception : un projet formel du système est généré, grâce à : (a) l’identification des composants décomposables de l’implantation (réutilisation ou bibliothèques), (b) le raffinement des composants choisis et (c) la génération et la preuve des contraintes de raffinement ;
4. codification, intégration et tests : le résultat de cette étape est le logiciel exécutable. Pour achever le processus, il faut d’abord (a) appliquer un générateur de code aux spécifications de plus bas niveau et (b) tester le résultat par rapport à des cas tests fondés sur les besoins initiaux.
Une analyse plus profonde du processus de développement présenté ci-dessus permet de dire que le concept le plus important du développement avec la méthode B est le
dévelop-pement par couches (cf. 3.a) où l’implantation d’un système est faite en utilisant d’autres
spécifications. Quelques sous-étapes (ex : 2.b) doivent être conduites sous la direction d’un outil. Cela nécessite l’existence d’outils qui supportent la méthode : le “B-Toolkit” produit par la société B-Core qui permet l’animation des spécifications, la génération des contraintes de cohérence, le support de preuves et la génération du code ; l’autre outil “Atelier B” pro-duit par la société Stercia Méditerranée en collaboration avec J. R. Abrial, est semblable à “B-Toolkit”, mais sans l’animation [Lan96].
Les spécifications B sont construites sur la notation AMN qui a ses origines dans la théo-rie des ensembles utilisée dans Z mais elles utilisent des spécifications complètes (données
et opérations qui portent sur ces données) basées sur des éléments mathématiques élémen-taires (logique des prédicats, ensembles, séquences, fonctions, etc.) alors que Z utilise des schémas. Les opérations sont présentées comme des transformations de prédicats à travers l’utilisation de la technique des substitutions généralisées, ce qui permet à B de spécifier des transformations d’états. Ces données et opérations sont encapsulées dans des modules qui peuvent être vus et utilisés par d’autres modules. Le concept de module B est très proche des classes Eiffel [Lan96].
Un exemple de spécification B (emprunté de K. Lano [Lan96]) utilisant la notation AMN pour spécifier un tableau est présenté dans la figure 2.13.
MACHINE PlArray(maxlen, ITEM) VARIABLES
pointer, array INVARIANT
pointer20::maxlen^ array21::maxlen!7 ITEM INITIALISATION
pointer:=0karray:=?
OPERATIONS insert(item,place)=b
PRE item2ITEM^place2
1::maxlen THEN array(place):=itemk pointer:=place END .. . Autres Opérations END
Figure 2.13 - Exemple de Spécification B [Lan96]
Les résultats obtenus par des entreprises (GEC Alsthom, Matra International) dans l’uti-lisation de la méthode pour des systèmes réels, ainsi que le support de la méthode par des ou-tils robustes, permettent de conforter l’affirmation de J. P. Bowen et M. G. Hinchey [BH95] : “la méthode B est peut être la méthode du futur”. Cependant, dans cette thèse, le but re-cherché de l’utilisation d’une méthode formelle est celui de la spécification de systèmes