Spécification et qualité du logiciel

1. Spécification et qualité du logiciel Resp. E. Bourreau Interv. M. Leclère leclere@lirmm.fr T. Libourel C. Nebut

2. Programme • Spécification • Jusqu’au vacances de Toussaint • 5 Cours lundi 9h45 • 3 TD lundi 11h30 : 2/10, 9/10, 23/10 • 2 TP de 3h : S42 et S43 (ou S45) • Mesure du logiciel • Test • Contrôle qualité

3. Grandes étapes du développement de logiciels • Étude « système » • Cahier des charges avec description des besoins et contraintes clients • Analyse fonctionnelle • Identification des grands scénarios et des composants (modules) utiles • Spécification • Définition du rôle de chaque module • Conception • Choix de structures de données, d’algorithmes… • Codage • Implémentation • Intégration • Assemblage des différents composants • Test • Vérification du respect des spécifications • Maintenance • Permettre l’évolution du logiciel

4. Spécifier pour modéliser • L’étape de spécification force à comprendre ce que doit faire chaque composant • La spécification permet d’argumenter sur la cohérence du composant • La spécification permet d’énoncer des propriétés sur le système avant même son développement

5. Spécifier pour valider • La validation consiste à se demander si le texte formel « dit bien » ce que l'on veut qu'il dise, s'il « traduit » bien la demande informelle faite par celui qui commande le logiciel • La validation ne peut pas être automatisée • La spécification permet de poser les bonnes questions afin de s’assurer de l’adéquation des composants au cahier des charges

6. Spécifier pour programmer • Une spécification est un contrat que le programmeur doit respecter quand il décide du comment • critères de langages, bibliothèques… • critères de complexité • critères de généricité • La spécification est une référence pour la suite du développement

7. Spécifier pour vérifier • Une spécification permet à chaque étape du développement de vérifier que la réalisation du système respecte les attentes initiales • En conception : Cet algorithme calcule-t-il bien ce que j’ai spécifié ? • En intégration : Ce programme réalise-t-il bien le composant initialement spécifié (notamment en termes de fonctionnalités)

8. Exemple :ce programme est il correct ? début c:=0; répéter si a mod 2 ≠ 0 alors c := c + b ; a := a div 2; b := b x 2; jusqu’à a =1; c := c + b; fin

9. Spécifier • Définir le quoi pas le comment ! • Nom • Des données en entrée • Des résultats en sortie • Une post-condition • La définition des résultats en fonction des données d’entrée • Une pré-condition • Les conditions nominales = conditions sous lesquelles l’opération doit garantir qu’elle que le résultat est bien celui attendu

10. Spécification + Programme  Vérification Quoi : nom : multiplication russe données : a,b deux entiers résultat : c le produit de a par b Comment : début c:=0; répéter si a mod 2 ≠ 0 alors c := c + b ; a := a div 2; b := b x 2; jusqu’à a =1; c : = c + b ; fin Ok ?

11. Quel langage pour spécifier • Informel, Semi-formel… • L’approche formelle consiste à utiliser un langage formel syntaxiquement et sémantiquement bien défini • par opposition à une spécification en langage naturel qui peut donner lieu à différentes interprétations • Par opposition à une spécification semi-formelle (ex. UML) qui dispose d’une syntaxe précise mais pas d’une sémantique bien définie

12. L’approche formelle • L’intérêt de cette approche est qu’elle oblige le « spécifieur » à énoncer sans ambiguïté ce que doit faire son programme • Ainsi les problèmes sont soulevés dès le début et non durant l’étape de conception où l’on pourra se consacrer aux difficiles problèmes de l’optimisation • Elle permet par ailleurs de prouver formellement des propriétés sur le système dès sa spécification (il n’est plus utile d’attendre son implémentation pour réaliser des tests exhaustifs)

13. Spécification formelle c  multiplication russe (a,b) = PRE a  NATURAL  b  NATURAL  a ≠ 0 THEN c := a x b END début c:=0; répéter si a mod 2 ≠ 0 alors c := c + b ; a := a div 2; b := b x 2; jusqu’à a =1; c : = c + b ; fin Preuve formelle

14. L’approche formelle • Les méthodes formelles ne sont pas limitées à la spécification • Conception : par reformulation formelle on passe de la spécification à du pseudo-code • Codage : puis on génére automatiquement du code exécutable • Test Preuve :On prouve à chaque étape le respect des spécifications initiales

15. Développer des logiciels à partir de spécifications formelles : la méthode B • Prolonge le module spécifications formelles du M1 : la spécification en B • En M2 : comment passer du quoi (la spécification) au comment (le code associé) par raffinements successifs : conception et codage • L'objectif de ce cours est d'avoir une ouverture sur le développement de logiciels par spécifications formelles

16. La méthode B : le raffinage • Raffiner consiste à reformuler les données et opérations d'une machine abstraite à l'aide de données et opérations plus proches de l'implémentation tout en conservant les propriétés de la machine abstraite. • Suppression des pré-conditions • Suppression de l’indéterminisme • Introduction de la séquence et des boucles • Chaque raffinement donne lieu à une preuve de la validité de la reformulation de la machine abstraite. • La dernière phase de raffinement permet d'atteindre un niveau de pseudo-code que l'outil associé, l'atelier B, peut alors traduire automatiquement dans différents langages (C, Ada, C++). • Le test du logiciel devient inutile, puisque le programme produit est formellement prouvé correct à la spécification initiale.

17. La notion de machine abstraite • En B • On spécifie • On prouve • On développe • On code Une (ou plusieurs) machine abstraite • Cette notion est proche • Type abstrait, Module, Classe, Composant

18. La machine abstraite Op Op • Un en-tête (nom) • Des données cachées • Des opérations visibles d’accès à la machine D Op Op Op Op Op Op

19. Les clauses d’une MA MACHINE Nom de la machine abstraite (idem nom de la classe) SETS Déclaration des ensembles abstraits et énumérés VARIABLES Déclaration des variables (idem attributs d’une classe) INVARIANT Typage et propriété des variables INITIALISATION Définition de la valeur initiale des variables (idem constructeur) OPERATIONS Déclaration des opérations (idem méthodes) END

20. L’en-tête • Un nom + optionnellement des paramètres pour la généricité MACHINE MACHINE MACHINE MACHINE calculatrice reservation pile(ELEMENT) variable (TYPE) END END END END

21. Les données • La définition des données s’appuie sur un langage d’expressions • les symboles désignant les données de base de la machine (ensembles abstraits, variables, constantes…) • les expressions booléennes • les expressions arithmétiques • les ensembles, relations, fonctions, • les suites… • Ces données sont caractérisées par un invariant • Une formule de la logique des prédicats exprimée au moyen de prédicats ensemblistes (appartenance, inclusion…) et de comparateurs arithmétiques.

22. Exemple : réservation MACHINE reservation VARIABLES nbPlacesLibres, capacite INVARIANT nbPlacesLibres  NAT  capacite NAT  nbPlacesLibres ≤ capacite END

23. Exemple : variable MACHINE variable (TYPE) VARIABLES valeur INVARIANT valeur  TYPE END

24. Les opérations • Une en-tête (la signature) liste des paramètres de sortie <-- NOM (liste des paramètres d’entrée) • Une pré-condition • Typage des paramètres d’entrée • Conditions nominales de fonctionnement de l’opération (domaine de définition) • Une transformation • Définition de l’opération comme une transformation des données internes et une affectation de valeur aux paramètres de sortie

25. Exemple : reserver MACHINE reservation … OPERATIONS reserver(nbPlaces)= PRE nbPlaces  NAT1 nbPlaces ≤ nbPlacesLibres THEN Définition de l’opération END END

26. Exemple : opérations de variable MACHINE variable (TYPE) … OPERATIONS v<--obtenir =Définition de l’opération ; affecter(v) = PRE v TYPE THEN Définition de l’opération END END

27. Les transformations • La définition des opérations s’appuie sur le langage des substitution généralisées • La transformation de base est la substitution simple devient égal, notée := • Les autres transformations permettent de modéliser le résultat de tous les changements d’états réalisables par algorithmique • Les boucles en particulier sont souvent modélisée par des substitutions indéterministes

28. Exemple : reserver reserver(nbPlaces)= PRE nbPlaces  NAT1  nbPlaces ≤ nbPlacesLibres THEN nbPlacesLibres := nbPlacesLibres-nbPlaces END

29. Exemple : affecter affecter(v)= PRE v TYPE THEN valeur := v END

30. Preuve de cohérence • La dernière étape de la spécification consiste à prouver la cohérence de chaque machine abstraite • On prouve pour chaque opération que • lorsque la machine est dans un état correct • Les propriétés invariantes I sont supposées vérifiées • lorsque l’opération est appelée dans des conditions nominales • la pré-condition P d’appel est supposée vérifiée • alors sa transformation S amène la machine dans un état correct • un état qui satisfait l’invariant I

31. Deux étapes de preuve • Calcul de [S]I la plus faible pré-condition • Condition minimale garantissant que l’état de la machine après l’opération respecte l’invariant • On applique simplement la substitution S à la formule I • On prouve que les conditions initiales (invariant et pré-condition) impliquent cette plus faible pré-condition • Pour chaque opération, la formule dont il faut établir la validité est donc de la forme I  P  [S]I

32. Illustration sur reserver MACHINE I  P  [S]I reservation VARIABLES nbPlacesLibres, capacite INVARIANT nbPlacesLibres  NAT  capacite NAT  nbPlacesLibres ≤ capacite OPERATIONS reserver(nbPlaces)= PRE nbPlaces  NAT1  nbPlaces ≤ nbPlacesLibres THEN nbPlacesLibres := nbPlacesLibres-nbPlaces END END I P S

33. B en pratique • On définit les données internes de la machine et leurs propriétés invariantes ; • On définit les opérations d’accès à la machine : pré-condition et transformation ; • L’atelier vérifie la syntaxe et le typage ; • L’atelier calcule les plus faibles pré-conditions et génère les preuves à faire ; • L’atelier tente de les prouver automatiquement ; • Si certaines preuves n’ont pas été démontrées, on détermine si : • l’opération est incorrecte et on corrige • le prouveur n’est pas assez « fort » et on aide le prouveur à réaliser la démonstration