La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Tests Programmation par contrats. Commentaires Lorsque le code est très commenté – Souvent cest parce que le code est mauvais – Sil y a besoin de commenter.

Présentations similaires


Présentation au sujet: "Tests Programmation par contrats. Commentaires Lorsque le code est très commenté – Souvent cest parce que le code est mauvais – Sil y a besoin de commenter."— Transcription de la présentation:

1 Tests Programmation par contrats

2 Commentaires Lorsque le code est très commenté – Souvent cest parce que le code est mauvais – Sil y a besoin de commenter un bloc de code pour expliquer ce quil fait – Extract Method – Rename Method – Introduce Assertion Sil faut en plus énoncer certaines règles au sujet de létat requis du système Attention, il ne sagit pas de proscrire les commentaires

3

4 Programmation par contrats Relation entre une classe et ses clients – Un accord formel (contrat) définissant les droits et devoirs de chaque partie Objectif – Assurer la conformité entre les spécifications et limplémentation – Inclure des éléments de la spécification dans limplémentation comme telle Assertion – Une propriété sur les valeurs des éléments dun programme Ex.: argument doit être positif – Expression booléenne

5 Préconditions et postconditions Spécification sémantique des méthodes Précondition – Les propriétés qui doivent être vérifiées avant lappel dune méthode Postcondition – Les propriétés qui doivent être vérifiées lorsque la méthode se termine

6 Exemple : la classe Stack public class Stack { private int[] stack ; private int num; private int capacity; public Stack(int capacity) { super(); this.capacity = capacity; stack = new int[capacity]; num = 0; }

7 Précondition & postcondition public int top() { // precondition : la pile ne doit pas être vide assert !isEmpty() : "Stack is empty"; return stack[num]; }

8 Précondition & postcondition public int pop() { // precondition : la pile ne doit pas être vide assert !isEmpty() : "Stack is empty"; int oldNum = num; int top = stack[--num]; // postcondition : //la pile ne doit pas être pleine; //le nombre d'éléments a été décrémenté de 1 assert num == oldNum - 1 && !isFull() : "problem with counter"; return top; }

9 Précondition & postcondition public void push(int element) { // precondition : la pile ne doit pas être pleine assert num < capacity : "stack is full"; int oldNum = num; stack[num] = element; // postcondition : //la pile ne doit pas être vide; //le sommet de la pile correspond à l'élément ajouté //le nombre d'éléments a été incrémenté de 1 assert num == oldNum + 1 && stack[num-1] == element && !isEmpty() : "problem with counter"; }

10 Quest-ce quun contrat ? Les préconditions lient le client – Définissent les conditions pour lesquelles une invocation de la méthode est légitime – Si les préconditions ne sont pas remplies, le comportement de la méthode et de la classe est indéterminé Valeur rendue invalide, Boucle infinie, fin anormale… Les postconditions lient la classe – Les conditions qui sont garanties lorsque la méthode rend son résultat ou se termine si aucun résultat nest rendu

11 Et si un contrat nest pas respecté… Si les préconditions ne sont pas remplies, – le comportement de la méthode et de la classe est indéterminé Valeur rendue invalide, Boucle infinie, fin anormale… Avantage – Simplification de la programmation – Une des sources importantes de complexité dans les programmes est le besoin constant de vérifier si les données transmises satisfont les contraintes requises pour un traitement adéquat Vérifications redondantes – Diminuent lefficacité – Pollution conceptuelle du logiciel Diminution de la simplicité du système Augmentation du risque derreurs Entrave des qualités comme lextensibilité, la compréhensibilité et la maintenabilité Le code des méthodes pop et top nont pas besoin de vérifier si la pile est vide (underflow) Le code de la méthode push na pas besoin de vérifier si la pile est pleine (overflow) Approche recommandée – Utiliser systématiquement les préconditions et programmer en supposant que les préconditions sont respectées – Les préconditions et postconditions déterminent clairement qui a la responsabilité de vérifier si certaines conditions sappliquent - approche plus rigoureuse

12 Jusquà quel point faut-il faire confiance aux clients ? Il faut faire confiance aux clients que lon connaît – Si on a un contrôle sur les clients On peut définir des préconditions strictes pour simplifier le code – Dans le cas contraire, Rendre les préconditions moins strictes Et gérer explicitement les erreurs (exceptions)

13 Encapsuler la pile par héritage public class ProtectedStack extends Stack { public ProtectedStack(int capacity) { super(capacity); } public int top() throws StackException { if (!isEmpty()) throw new StackException("Stack is empty"); return super.top(); } public int pop() throws StackException { if (!isEmpty()) throw new StackException("Stack is empty"); return super.pop(); } public void push(int element) throws StackException { if ( getNum() < getCapacity()) throw new StackException("stack is full"); super.push(element); }

14 Encapsuler la pile par indirection public class FilteredStack { private Stack stack; public FilteredStack(int capacity) { stack = new Stack(capacity); } public int top() throws StackException { if (!stack.isEmpty()) throw new StackException("Stack is empty"); return stack.top(); } public int pop() throws StackException { if (!stack.isEmpty()) throw new StackException("Stack is empty"); return stack.pop(); } public void push(int element) throws StackException { if (stack.getNum() < stack.getCapacity()) throw new StackException("stack is full"); stack.push(element); }

15 Invariants de classe Propriétés globales pour toutes les instances dune classe qui doivent être préservées par toutes les méthodes – Sur les variables dinstance dune classe 0 < = num <= capacity – Relations sémantiques entre les fonctions dune classe – Relations sémantiques entre des fonctions et des attributs isEmpty rend vrai num = 0 Un invariant de classe doit être vérifié – Après la création dune instance – Avant et après linvocation de toute méthode de la classe Les méthodes internes ne sont pas contraintes à maintenir la validité de linvariant de classe

16 /** * Class invariant */ private boolean inv() { return (num >= 0 && num < capacity); } public Stack(int capacity) { // linvariant de classe ne doit pas être vérifié ici this.capacity = capacity; stack = new int[capacity]; num = 0; assert inv() : "Class invariant failure"; } public int top() throws StackException { // precondition : la pile ne doit pas être vide assert inv() : "Class invariant failure"; assert !isEmpty() : "Stack is empty"; int top = stack[num]; assert inv() : "Class invariant failure"; return top; }

17 Invariant de boucle Une propriété entre les variables qui est vraie – lorsque le contrôle entre dans la boucle – à chaque exécution du corps de laboucle – à la sortie de la boucle

18 Quotient entier public static int quotient(int n, int d) { int q = 0, r = n; assert n == q * d + r : "loop invariant before entering loop"; while (r >= d) { assert n == q * d + r : "loop invariant before performing body"; r = r - d; q = q + 1; assert n == q * d + r : "loop invariant after performing body"; } assert r < d && n == q * d + r : "loop invariant after the loop"; return q; }

19 Assertion en Java assertion facility in J2SE 1.4 and later versions assert booleanExpression; assert booleanExpression : errorMessage; public int pop() { // precondition assert !isEmpty() : "Stack is empty"; return stack[--num]; } java -ea:com.javacourses.tests... -da:com.javacourses.ui.phone MyClass – ea : enable assertions – da : disable assertions

20


Télécharger ppt "Tests Programmation par contrats. Commentaires Lorsque le code est très commenté – Souvent cest parce que le code est mauvais – Sil y a besoin de commenter."

Présentations similaires


Annonces Google