Article pp.7-9 du Vol.22 n°1 (2003)

(1)

Editorial

La méthode B a maintenant plus de dix ans. Conçue à la fin des années 80 par Jean-Raymond Abrial, elle a pour ambition de fournir un cadre rigoureux à la construction de logiciels. Elle vise plus particulièrement les logiciels pour lesquels certaines propriétés importantes, voire critiques, exprimées au plus haut niveau de la spécification, doivent être garanties. Pour cela, elle s’appuie sur des notions logiques de la théorie des programmes introduites par C. A. R. Hoare (1969) et E.

W. Dijkstra (1975) et elle est instrumentée par un ensemble d’outils intégrés. C’est cette association : bases mathématiques solides et outils industriels, qui en font une méthode utilisable pour la réalisation, en vraie grandeur, de logiciels sécuritaires.

Ainsi, pour le projet de métro sans conducteur Météor (ligne 14), la RATP a choisi d’utiliser la méthode B pour spécifier et implanter le système critique du pilotage automatique et de l’arrêt d’urgence. Une convention a réuni les principaux artisans de ce projet : RATP, Siemens Transportation Systems (STS)¹ pour la réalisation, ClearSy² pour la fourniture des outils : l’AtelierB, ainsi que GEC Alstom et SNCF, également utilisateurs de la méthode B. On sait que ce projet s’est déroulé et s’est terminé avec succès. L’article de Daniel Dollé, Didier Essamé et Jérôme Falampin dans ce numéro présente les travaux de STS pour ce projet et les développements qui sont actuellement réalisés dans l’entreprise pour faciliter l’utilisation de la méthode B sur les nouveaux projets.

Un autre type d’utilisation privilégié concerne les logiciels embarqués et les supports intelligents. C’est le cas en particulier des cartes à puces et surtout des cartes ouvertes basées sur la technologie de la Java Card. Gemplus, dès 1998, étudie l’utilisation de la méthode B pour assurer l’intégrité du chargement d’applets sur une machine virtuelle Java Card embarquée. Ce travail a abouti, en particulier, à la réalisation d’un vérifieur de « byte-code » d’applications Java. En plus du développement de ce logiciel et de la preuve de sa correction, la difficulté est de pouvoir charger le code généré sur une carte à puce dont on connaît la faible capacité de mémoire. Ce pari a été relevé et il est décrit dans l’article de Lilian Burdy, Ludovic Casset et Antoine Requet.

La méthode B est utilisable dans les projets de grande taille parce qu’elle utilise deux principes de structuration essentiels : le raffinement et la modularité. Le raffinement permet de décrire les propriétés et les fonctionnalités d’un logiciel de manière abstraite et de détailler petit à petit cette description pour arriver à un programme final dans un langage de programmation usuel, tout en assurant que les

1. Alors Matra Transport International.

2. Alors Digilog.

Cet article des Editions Lavoisier est disponible en acces libre et gratuit sur tsi.revuesonline.com

(2)

8 RSTI - TSI – 22/2003. Méthode B

propriétés exprimées au premier niveau sont bien préservées. Il est également possible d’introduire des propriétés de plus en plus concrètes tout au long du processus de raffinement. La décomposition modulaire est une notion bien connue dans les langages de programmation. Elle existe en B, mais ici, il faut assurer que les propriétés qui sont vraies localement restent vraies globalement après assemblage des composants. L’article de Marie-Laure Potet met en lumière ces aspects sensibles et importants de la méthode.

Dans les réalisations évoquées ci-dessus, l’utilisation de la méthode B consiste à spécifier un logiciel, à en décrire les propriétés et les fonctionnalités, puis à réaliser les raffinements et la structuration jusqu’à obtenir des « programmes B » exécutables dont on est sûr, par la preuve, qu’ils respectent bien les conditions de sûreté exprimées initialement ou dans le développement. Les programmes de bas niveau sont alors traduits automatiquement dans le langage de programmation de son choix, intégrés éventuellement à d’autres composants non développés formellement, pour constituer finalement l’application attendue.

Avec l’expérience et surtout avec l’introduction d’une nouvelle façon d’écrire le B (appelée B-événementiel), il s’avère que la méthode peut être utilisée dans l’analyse système. On entend par là le fait d’expliciter un cahier des charges informel pour faire apparaître plus précisément l’architecture et les fonctionnalités à réaliser. Il ne s’agit pas encore de spécifier le logiciel, mais plutôt de décrire les besoins, de manière à mieux comprendre les objectifs et trouver les moyens de les atteindre. L’utilisation de B peut aussi consister à explorer un cahier des charges, à en réécrire le contenu d’une manière plus concise et plus complète et à valider les énoncés. C’est une expérience de ce genre qui est décrite par Guilhem Pouzancre et Jean-Philippe Pitzalis à propos de la formalisation de principes de fonctionnement de véhicules chez Peugeot.

Qu’en est-il donc exactement de la méthode B aujourd’hui ? Pour répondre à cette question, Jean-Raymond Abrial explique à quoi sert B, comment et pourquoi l’utiliser. Il montre aussi que les principes initiaux sont en train d’évoluer et que B peut devenir une façon de penser et de valider les besoins. Une retombée possible est alors de faire apparaître des solutions de mises en œuvre logicielle et/ou matérielle. Cette nouvelle orientation, axée sur l’analyse système, peut très bien cohabiter avec la précédente, plus classique, car elle l’englobe d’une certaine manière. Elle s’accompagne d’une évolution des outils, qui deviendraient alors plus ouverts et sujets à extension. Voilà un article de synthèse qui donne un aperçu précis et néanmoins très facile d’accès de la méthode B.

Enfin, dans ce numéro thématique, le panorama de « l’aujourd’hui de B » est complété par une chronique sur la recherche et une autre sur l’enseignement de B.

Nous souhaitons que le lecteur puisse découvrir au long de ces pages comment la méthode B est utilisée par des équipes industrielles dans des domaines d’application variés. Il se rendra compte également que la méthode B n’est pas uniquement destinée à réaliser des développements complets et prouvés (bien

(3)

Editorial 9

qu’elle soit la seule méthode formelle à pouvoir le faire), mais qu’elle peut être utilisée à divers stades d’un projet informatique et notamment lors de la définition des besoins. Il découvrira que les recherches sur ce sujet sont toujours actives et que des avancées sont possibles pour améliorer la méthode et les outils. En conclusion, nous espérons que ce numéro lui aura donné l’envie d’en connaître davantage sur ce qu’est cette méthode et sur ce qu’elle peut apporter dans le domaine du génie logiciel.

Didier Bert LSR-IMAG, Grenoble didier.bert@imag.fr Henri Habrias IRIN, Nantes habrias@irin.univ-nantes.fr Véronique Viguié Donzeau-Gouge CNAM, Paris donzeau@cnam.fr