1
La spécification formelle
1. Introduction
En génie logiciel, les techniques formelles de développement du logiciel sont largement utilisées dans le milieu industriel (développement des logiciels industriels).
Le terme « méthodes formelles » se réfère à n’import quelle activité qui utilise une représentation mathématique du logiciel (spécification formelle du système, développement de la transformation, vérification de programme).
Depuis 1980 ; plusieurs recherches en génie logiciel proposent l’utilisation des méthodes formelle dans le but d’améliorer la qualité du logiciel justifiant le fait qu‘une analyse détaillée et rigoureuse est une partie essentielle des méthodes formelles conduisant à des programmes avec peu d’erreurs et qui conviennent aux besoins des utilisateurs.
Les spécifications formelles représentent un excellent moyen pour découvrir les erreurs et présenter la spécification du système de manière non ambigüe. Parallèlement, un certain nombre d’inconvénients liés à ces méthodes en font leurs restrictions.
2. Définition d’une spécification formelle
Une spécification formelle est exprimée dans un langage à syntaxe et sémantique précises, construit sur une base théorique solide et qui permet des validations automatisées (base mathématique).
Exemples
Les réseaux de Petri, les grammaires formelles, les automates d’états finis, la logique formelle, l’algèbre, la théorie des graphes, le -calcul.
Certaines spécifications formelles s’appliquent à des domaines d’activités spécifiques :
- Les réseaux de Petri sont largement utilisés pour spécifier et valider des protocoles de communication.
- Les grammaires formelles sont utilisées pour définir et analyser les langages, notamment en théories des langages de programmation.
- Les automates d’états finis permettent de modéliser des mécanismes critiques dont la validation formelle est estimée nécessaire (moniteurs temps réel).
- La théorie des ensembles est un support important des bases de données relationnelles et des spécifications abstraites de systèmes.
Le terme « formel » est souvent confondu avec le terme « précis » : Formel => précis, mais la réciproque n’est pas vraie.
L’objectif de ce chapitre est d’introduire les techniques de spécification formelle qui sont utilisées afin d’ajouter des détails à la spécification des besoins du système. Cela permettra de
- comprendre pourquoi les techniques de spécification formelle aident à découvrir les besoins du système.
- Comprendre l’utilisation des techniques algébriques des spécifications formelles pour définir les spécifications d’interface.
- Comprendre pourquoi les techniques formelles et les techniques basées sur les modèles sont utilisées pour la spécification comportementale
2 2.1 Intérêts des méthodes formelles
Les avantages des ces méthodes résident dans : a) Les aspects formels :
- Les propriétés peuvent être établies par raisonnement formel ce qui n’est pas le cas des autres méthodes.
- Les conséquences d’une spécification peuvent être mises en évidence. Les contradictions sont détectées avant la réalisation.
- Les outils de preuve calculent et vérifient automatiquement et uniquement ce qui a été décrit.
b) La précision
- Le domaine du problème est mieux perçu, les imprécisions sont levées, les contradictions sont mises en valeur, le problème est mieux compris.
- Le même langage est pratiqué par différentes personnes.
- Une conversion en langage naturel facilitera la discussion avec le client qui lui-même appréhende mieux le problème.
- La spécification formelle est un avant projet à la réalisation. Le programmeur sait exactement ce qu’il doit programmer.
c) L’abstraction
- L’abstraction permet de ne retenir que les caractéristiques essentielles.
- Une description abstraite est plus évolutive. Elle améliore la maintenabilité du logiciel et facilite l’accès au logiciel par de nouveaux acteurs de développement.
- Les méthodes formelles mènent à des composantes plus faciles à réutiliser et plus fiables.
Tous ces avantages conduisent à la réduction des coûts et une rentabilité accrue des investissements en amont de la réalisation. Cependant, certains problèmes se posent.
2.2 Problèmes des méthodes formelles
a) Difficulté : les praticiens n’ont pas toujours la connaissance nécessaire, les formalismes ne sont pas toujours lisibles.
b) Diversité : plusieurs standards existent (Z, VDM, etc.).
c) Difficulté de modélisation : manque de structuration, erreurs, exceptions, concurrences d’où le besoin d’outils et de méthodes pour construire les spécifications formelles.
d) Adéquation : la spécification aide à cerner les oublis et les contradictions, mais on ne peut prouver que ce qui a été spécifié pas ce qui était souhaité par le client.
e) Preuve : les outils de preuve existent mais ils sont insuffisants.
f) Domaine d’application : les spécifications formelles ne sont appliquées qu’à un nombre réduit d’applications.
g) Raffinage : la théorie de raffinage est relativement simple à comprendre : on transforme petit à petit les structures de données et de contrôle jusqu’à atteindre les langages de programmation. Le nombre d’étapes de raffinage est parfois important et la preuve du bien fondé de la transformation est souvent lourde.
3. Paradigmes de spécification
Les techniques de spécification formelle diffèrent principalement par le paradigme de spécification particulière qui leur est associé.
3.1 Spécification basée sur les histoires
Le principe repose sur le fait de spécifier un système en le caractérisant par un ensemble d’histoires admissibles (comportements) définies en fonction du temps.
3
Les propriétés d’intérêt sont spécifiées par des assertions en logique temporelle sur les objets du système. De telles assertions impliquent des opérateurs se référant aux états passés, courants et futurs.
3.2 Spécification basée les états
Il est aussi possible de caractériser un système par les états admissibles. Les propriétés d’intérêt sont spécifiées par des invariants contraignant les objets du système. Les pré et post conditions contraignant les opérations du système.
Exemple : Z, VDM ou B.
3.3 Spécification basée sur les transitions
Un système peut aussi être caractérisé par les transitions nécessaires pour passer d’un état à un autre. Les propriétés d’intérêt sont spécifiées par un ensemble de transitions de machine d’état.
La fonction de transition pour un objet du système donne, pour chaque état d’entrée et événement déclenchant, l’état de sortie correspondant.
Exemple : PROMELA.
3.4 Spécification fonctionnelle
Le principe repose sur le fait de spécifier un système comme une collection structurée de fonctions mathématiques. Deux approches peuvent être distinguées :
- La spécification algébrique où les fonctions sont groupées par type d’objet qui apparaît dans leur domaine en définissant les structures algébriques. Les propriétés d’intérêt sont définies comme des équations conditionnelles qui capturent l’effet des fonctions composantes.
Exemple : PLUSS, ASL.
- Les fonctions d’ordre supérieur : les fonctions sont regroupées en théories logiques. De telles théories contiennent des définitions de types (possiblement à l’aide de prédicats logiques), des déclarations de variables et des axiomes définissant des fonctions variées dans la théorie.
Les fonctions peuvent avoir d’autres fonctions comme argument qui, significativement, incrémentent la puissance du langage.
Exemple : PVS.
3.5 Spécification opérationnelle
Dans le cas extrême, un système peut être caractérisé comme une collection de processus qui peuvent être exécutés par certaines machines plus ou moins abstraites.
Exemple : réseaux de Pétri.
4. Spécification formelle dans le processus logiciel
Le développement de systèmes critiques implique le suivi un modèle de processus (modèle en cascade, par exemple). Les besoins du système et la conception du système sont exprimés en détail puis analysés et vérifiés avant que l’implémentation débute.
Si la spécification formelle est développée, cela vient après les besoins du système soient exprimés mais avant la conception détaillée. Cela représente une boucle de rétroaction entre la spécification détaillée des besoins et la spécification formelle.
Dans les premières étapes du processus, La spécification est orientée client. La spécification doit être comprise par le client et les hypothèses sur la conception doivent être minimes.
Cependant, la dernière étape du processus, qui est la construction des spécifications complètes, précises et consistantes, est principalement orientée développeur.
4 Il spécifie les détails d’implémentation du système.
La figure suivante illustre les étapes de spécification et leur interface avec le processus de conception :
Increasing contractor involvement
Decreasing client involvement
Specification
Design Figure 1 : spécification et conception [1]
Le développement des spécifications en détail, implique une compréhension profonde de ces dernières. La création d’une spécification formelle nécessite une analyse détaillée du système qui permet de ressortir les erreurs et les inconsistances dans la spécification informelle des besoins.
L’élaboration d’une spécification formelle permet de couvrir les coûts de développement du logiciel.
Le schéma suivant montre comment les coûts d’un processus logiciel sont affectés par l’utilisation d’une spécification formelle.
Cost Validation
Validation
Design et
Implementation Design et
Specification Implementation Specification
Figure 2 : coûts de développement du logiciel et la spécification formelle [1]
Quand un processus conventionnel est utilisé, les coûts de validation sont de 50% du coût de développement et les coûts de conception et implémentation valent deux fois les coûts de spécification.
Avec une spécification formelle, les coûts de spécification et d’implémentation sont comparables et les coûts de validation du système sont significativement réduits.
User requirement definition
System requirement specification
Architectural design
Formal specification
High-level design
5
Deux approches fondamentales à la spécification formelle sont utilisées pour définir une spécification détaillée des systèmes logiciels industriels.
- Approche algébrique où le système est décrit en termes d’opérations et de relations.
- Approche basée sur les modèles où le modèle du système est construit en utilisant une construction mathématique.
Différents langages de ces familles ont été développés pour spécifier les systèmes séquentiels et les systèmes concurrents :
Les exemples de langages de chaque classe sont montrés ci-dessous :
sequential concurrent
Algebraic Larch (Guttag et al., 1993)
OBJ (Futatsugi et al., 1985)
Lotos (Bolognesi end Brinksma, 1987)
Model-based Z (Spivey, 1992)
VDM (Jones, 1980) B (Wordsworth, 1996)
CSP (Hoare, 1985)
Petri Nets (Peterson, 1981)
Figure 3 : langages de spécification formelle [1]
5. Spécification d’interface des sous systèmes
Les grands systèmes sont généralement décomposés en sous systèmes qui ont été développés de manière indépendante. Les sous systèmes utilisent d’autres sous systèmes et une partie importante dans le processus de spécification est de définir des interfaces des sous systèmes.
Les interfaces étant définis, les sous systèmes peuvent être conçus et implémentés de manière indépendante.
Les interfaces des sous systèmes sont souvent définies comme un ensemble d’objets ou composants. Elles décrivent les données et les opérations qui peuvent être accessibles à travers les interfaces des sous systèmes.
Les spécifications précises des interfaces de sous systèmes sont importantes car les développeurs ont à écrire un code qui utilise les services des autres sous systèmes avant que ces derniers soient implémentés.
Une spécification d’interface claire et non ambigüe réduit la non compréhension entre les sous systèmes fournissant les services et les sous systèmes utilisant les services.
L’approche algébrique a été conçue pour une définition des interfaces des types abstraits de données. Dans un type abstrait de donnée, le type est défini en spécifiant les opérations de types plutôt que la représentation de type. Ceci est similaire à une classe d’objet.
Une méthode algébrique d’une spécification formelle définit le type abstrait de donnée en termes de relation entre les opérations de type.
La structure d’une spécification d’un objet est illustrée par la figure suivante : Objets d’interface
Figure 4 : les objets d’interface des sous systèmes [1]
Sous système A
Sous système B
6
Le corps de la spécification comprend quatre composantes :
- Une introduction : qui déclare le nom du type de l’entité à spécifier. Cela est similaire à un type dans un langage de programmation.
- Une partie description où les opérations sont décrites informellement ce qui facilite la compréhension d’une spécification formelle.
- Une partie signature qui définit la syntaxe de l’interface d’une classe d’objets ou d’un type abstrait de donnée.
- Une partie axiome : qui définit la sémantique des opérations en définissant un ensemble d’axiomes qui caractérisent le comportement du type abstrait de donnée.
Le processus d’élaboration d’une spécification formelle d’interface de sous système inclut les activités suivantes :
- La structuration d’une spécification qui organise la spécification d’interface en un ensemble de types abstraits de données ou de classes d’objets.
- Le nommage de la spécification qui établit le nom de chaque spécification de type abstrait.
- La sélection de l’opération qui choisit un ensemble d’opérations pour chaque spécification basée sur la fonctionnalité de l’interface identifiée.
- La spécification informelle d’opération
- La définition de la syntaxe : qui définit la syntaxe des opérations et des paramètres pour chacune d’elles.
- La définition des axiomes : qui définit la sémantique de l’opération en décrivant quelles sont les conditions vraies pour les différentes combinaisons d’opérations.
6. Spécification comportementale
La technique algébrique peut être utilisée pour décrire des interfaces où les opérations de l’objet sont indépendantes de l’état de l’objet. L’approche utilisée de leur spécification formelle, pour les projets industriels, est la spécification basée sur les modèles. Dans ce cas, le système est exprimé comme un modèle d’état du système. Les notations adoptées sont VDM, Z, B.
La spécification formelle peut être difficile notamment quand elle se présente comme étant des formules mathématiques importantes.
Les spécifications formelles se présentent comme un texte informel avec des descriptions formelles. Celle-ci est incluse dans un schéma. Les schémas sont utilisés pour introduire des variables d’états et des opérations sur l’état.
La signature d’un schéma définit les entités qui décrivent l’état du système et les prédicats du schéma disposent des conditions qui doivent être toujours vraies pour ces entités (invariants).
L’exemple suivant illustre une structure d’un schéma en Z :
Nom du schéma
Signature du schéma
Conteneur Prédicat du schéma Contenu : N
Capacité : N Contenu <= capacité
7
7. Conclusion
Les méthodes de spécification formelle de système complémentent les techniques de spécification informelle des besoins.
Les spécifications formelles sont précises et non ambiguës. Elles permettent d’éviter certains problèmes de mauvaises interprétations du langage. Cependant, les non spécialistes peuvent trouver la spécification formelle difficile à comprendre.
La valeur principale en utilisant les méthodes formelles dans le processus logiciel est de permettre d’effectuer l’analyse des besoins du système au début de l’étape. La correction des erreurs à cette étape est moins coûteuse que de modifier le système, une fois, délivré.
Les techniques algébriques de la spécification formelle conviennent particulièrement à la spécification des interfaces où l’interface est définie comme un ensemble de classes d’objets ou de types abstraits de données.
Les techniques basées sur les modèles modélisent le système en utilisant des constructions mathématiques (ensembles et fonctions).
Les opérations, dans la spécification basée sur les modèles, sont définies en définissant les pré et post conditions sur l’état du système.
Référence :
[1] Sommerville (2007). Software Engineering, Eighth Edition. Pearson Education
