Programmation par contrat
Pour les articles homonymes, voir DBC.
La programmation par contrat (en anglais, design by contract ou DBC) est un paradigme de programmation dans lequel le déroulement des traitements est régi par des règles. Ces règles, appelées des assertions, forment un contrat qui précise les responsabilités entre le client et le fournisseur d'un morceau de code logiciel. C'est une méthode de programmation semi-formelle dont le but principal est de réduire le nombre de bogues dans les programmes.
Historiquement, la programmation par contrat a été introduite par Bertrand Meyer dans son langage Eiffel datant de 1985, qui était inspiré de la notation Z créée par Jean-Raymond Abrial.
Principe
modifierLe principe est de préciser ce qui doit être vrai à un moment donné de l'exécution d'un programme. Il ne faut pas penser que ce paradigme oblige à réaliser des tests effectifs des règles pendant l'exécution : ces tests ne sont qu'une des façons de s'assurer que les règles sont respectées. Il existe quatre types d'assertions :
- Précondition : La condition qui doit être vérifiée par le client avant le lancement d'un traitement donné. Cette condition doit garantir que l'exécution du traitement est possible sans erreur ;
- Postcondition : La condition qui doit être garantie par le fournisseur après le déroulement d'un traitement donné. Cette condition doit garantir que le traitement a bien réalisé son travail ;
- Invariant : Il s'agit d'une condition qui est toujours vraie. Selon le type d'invariant, cette assertion caractérise l'état interne de tout le programme, ou seulement d'une partie comme pour un invariant de boucle ou un invariant d'objet.
- Variant : Il s'agit d'une valeur numérique entière positive associée à une boucle. La valeur doit nécessairement décroître à chaque évaluation, garantissant la terminaison.
Le langage utilisé pour écrire les conditions est important. Il doit avoir une valeur de vérité ; autrement dit c'est une logique et on utilise en général les expressions booléennes du langage hôte. Pour pouvoir exprimer plus de choses on y adjoint souvent un moyen pour que les postconditions puissent se référer à l'ancienne valeur des variables modifiées par le traitement. Enfin on peut rajouter les quantificateurs de la logique du premier ordre.
Ces assertions sont écrites directement dans le code source du programme et permettent de fournir une documentation supplémentaire sur le sens que possède le code. Cela permet donc de décrire la sémantique du programme.
Contexte
modifierPlusieurs langages de programmation mettent en œuvre ce paradigme comme Eiffel, D, Lisaac, Oxygene (en), SPARK, Vala ainsi qu'Ada à partir de la version Ada 2012. Des modules existent pour d'autres langages, comme OCL pour UML, JML pour Java, ACSL pour le C, Praspel pour PHP ou PSL pour VHDL.
Cette technique possède un lien très fort avec les méthodes formelles permettant de certifier correct un programme. Les trois règles ci-dessus sont en fait une forme de spécification classique du programme.
Mais, contrairement aux méthodes de preuves de programmes, on ne va pas chercher à montrer explicitement que la spécification est bien réalisée par le programme. Cette partie est laissée à la discrétion du client et du fournisseur.
Les outils de vérification statique de code peuvent s'appuyer sur les assertions pour émettre des diagnostics pertinents.
Néanmoins on met souvent en place des mécanismes de tests des règles pendant l'exécution pour vérifier leur validité. On peut vérifier les assertions durant les tests de manière élégante. Mais cela ne permet en aucun cas d'être sûr que les règles sont tout le temps valides. En effet il faudrait, la plupart du temps, réaliser une infinité d'exécutions différentes pour vérifier tous les cas possibles.
La programmation par contrat, lorsqu'elle est générale, permet une recherche des erreurs aussi efficace que les tests unitaires mais en utilisant des tests automatisés de toute nature. Une erreur qui survient dans une partie d'une application lorsque les assertions sont vérifiées à l'exécution, se trouve précisément localisée par la première assertion échouée.
Dans une certaine mesure les spécifications peuvent aussi être conservées pour être vérifiées et auditées dans l'application en production, si leur vérification n'affecte pas les performances. Elle deviennent alors un puissant moyen de détection d'erreur en condition réelle.
Mais il est reconnu[1] que cette méthode permet quand même d'obtenir des logiciels de meilleure qualité et d'accélérer les phases de débogage.
Exemple
modifierUne fonction calculant une racine carrée d'un nombre réel peut être vérifiée de la manière suivante en pseudo-code.
- Fonction calculant la racine carrée de la valeur x
- Précondition : x ≥ 0
- Postcondition : résultat ≥ 0 et resultat² = x
La précondition assure que le développeur utilise la fonction correctement, alors que la postcondition permet au développeur de faire confiance à la fonction. Il faut faire attention à ce que l'expression puisse être effectivement vérifiée, par exemple ici il faudrait veiller aux erreurs de calculs numériques.
