• Aucun résultat trouvé

2.5 Approches pour l’analyse et la vérification logicielle

2.5.1 Approches par raffinement

Les approches par raffinement consistent, à partir d’un modèle abstrait d’un système, à obtenir un modèle concret en procédant par dérivations successives. Chaque étape de raffine-ment doit être prouvée afin de garantir que le modèle dérivé est conforme au modèle abstrait utilisé. À l’instar du model-checking, ces techniques permettent de montrer que le modèle ob-tenu à chaque itération est un raffinement de la spécification et donc que le système modélisé satisfait ses exigences. Dans cette sous-section, la présentation du raffinement est inspirée de [Abr10 ; GFL05].

2.5.1.1 Description

Les méthodes par raffinement ont émergé suite au constat que les systèmes complexes ne peuvent être conçus parfaitement et sans erreur en une seule itération. La conception de ces systèmes est une tâche difficile car elle requiert à la fois une vision globale de leur fonctionne-ment et une vision détaillée permettant d’en comprendre tous les rouages. Une technique est

donc de procéder par itérations successives afin d’enrichir progressivement le modèle du sys-tème. Pour décrire cette approche, la Figure 2.3 illustre le principe de conception d’un système à l’aide d’une méthode de raffinement.

FIGURE2.3 – Schéma de l’approche par raffinement.

À partir de la Spécification des exigences logicielles, un ingénieur conçoit un Modèle abs-trait du système. Ce modèle est décrit à un haut niveau d’abstraction à l’aide d’un Langage de modélisation. Par itérations successives, l’ingénieur va ensuite détailler les différents sous-composants du système afin d’enrichir le modèle. Cette activité est appelée raffinement ho-rizontal (ou superposition) [Abr10]. Elle permet de passer d’un Modèle abstrait à un Modèle détaillé abstrait dans lequel toutes les exigences logicielles du système ont été considérées. Le raffinement horizontal est indépendant de toutes contraintes d’implémentation ou choix tech-nologiques. Il ne se base que sur des outils mathématiques afin d’obtenir une représentation formelle du système modélisé. À chaque étape, des preuves de raffinement, aussi appelées obligations de preuve, doivent être réalisées afin de garantir que le pas de raffinement conserve la cohérence et les exigences prises en compte dans les raffinements précédents. Une obliga-tion de preuve peut être définie de la façon suivante :

Définition 2.7 (Obligation de preuve). “Une obligation de preuve est une formule mathéma-tique à démontrer afin d’assurer qu’un composant [...] est correct.” [Cle09]

Une fois que toutes les exigences logicielles ont été prises en compte et qu’une représen-tation abstraite du système a été réalisée, l’ingénieur utilise alors le raffinement vertical [Abr10] pour transformer certains éléments abstraits en éléments concrets (plus proches des concepts d’implémentation). Les différentes itérations de raffinement vertical permettent ainsi de passer d’un Modèle détaillé abstrait à un Modèle concret à partir duquel il est facile de générer du code. À chaque étape de raffinement vertical, il faut aussi vérifier des obligations de preuve afin d’assurer que les types de données concrets et les choix d’implémentation du modèle plus

2.5. Approches pour l’analyse et la vérification logicielle

concret restent cohérents avec les exigences logicielles du modèle plus abstrait. C’est pour cette raison que le raffinement vertical est aussi qualifié de raffinement de données (ou en anglais data refinement).

En résumé, les approches par raffinement permettent de faire le lien entre les différents niveaux d’abstraction d’un même modèle. Ces techniques permettent ainsi d’assurer qu’un modèle satisfait ses exigences. Elles constituent en ce sens une alternative aux travaux réalisés dans cette thèse. Plus qu’une alternative, elles offrent également une certaine complémentarité par rapport aux autres techniques d’analyse (p. ex. la simulation, le model-checking). En effet, l’application de ces outils reste possible (voire primordial) pour valider le comportement du système modélisé dans chacun des niveaux d’abstraction considérés.

2.5.1.2 Langages et outils

Pour mettre en œuvre les approches par raffinement, plusieurs langages formels ont été dé-finis dont Z [WD96 ; Spi92], Vienna Development Method (VDM) [Jon95] et B [Abr96 ; Abr+91]. Si la méthode Z ne permet pas de fournir de version exécutable des programmes Z, des outils ont été développés pour supporter les méthodes VDM et B. Pour VDM, le langage de modé-lisation VDM Specification Language (VDM-SL) [PL92] est supporté par SpecBox [FM89] ou encore VDMTools [FLS+08] qui est aujourd’hui l’outil de référence pour VDM. L’un des premiers succès notables de VDM a été de donner une définition formelle de la sémantique du langage PL/I développé par IBM dans les années 60. Pour B, plusieurs outils ont également été déve-loppés dont B Toolkit9[LH00] ou encore l’Atelier B10 commercialisé par la société ClearSy11. L’un des premiers projets utilisant l’Atelier B visait la vérification de la ligne 14 du métro parisien. Il a depuis été utilisé par de nombreux projets industriels dont les lignes de métro automatique de Pékin et São Paulo. De plus, pour valider le comportement des systèmes modélisés en B, il est également possible d’appliquer des outils d’analyse comme le model-checker ProB [LB08] sur les modèles de chaque niveau d’abstraction.

Les langages de raffinement ne se limitent pas à ces trois langages. Des variantes de ces langages utilisent le paradigme objet comme VDM++ [DK92], Z++ [Lan90] ou ObjectZ [Smi12]. Pour la méthode B, un profil nommé UML-B a également été défini pour permettre l’utilisation des principes de B avec UML (cf. section A.3.4). Si B est particulièrement adapté pour la conception logicielle, son homologue Event-B [Abr10] basé sur le paradigme évènementiel est dédié à la conception système.

Les langages utilisés pour les approches par raffinement sont riches et expressifs permet-tant ainsi la modélisation de systèmes complexes. L’outillage supporpermet-tant ces langages

contri-9. B Toolkit : https://github.com/edwardcrichton/BToolkit. 10. Atelier B : https://www.atelierb.eu/.

bue aussi à l’émergence de ces techniques et aux succès industriels qui ont été accomplis. Ces approches utilisent néanmoins des langages spécifiques ce qui les rend difficilement ap-plicables pour le développement de systèmes avec d’autres langages de modélisation.