Qualité en Développement

Laurent HenocqueEnseignant Chercheur ESIL/INFO France

http://laurent.henocque.perso.esil.univmed.fr/mis à jour en Octobre 2008

Licence Creative Commons

Cette création est mise à disposition selon le ContratPaternité-Partage des Conditions Initiales àl'Identique 2.0 France disponible en ligne

http://creativecommons.org/licenses/by-sa/2.0/fr/

ou par courrier postal à Creative Commons, 559Nathan Abbott Way, Stanford, California 94305,USA.

Objectifs

• Ce cours a pour projet de donner les basesde techniques de travail reconnues commenécessaires pendant tout le cycle de vie dulogiciel, et

• d'apprendre les méthodes qui permettentd'affronter systématiquement et de résoudreles problèmes.

Plan

• Concepts fondamentaux de qualité logicielle,– notamment les notions de contrats, d'invariants et une

discussion sur la notion de test.• Comment l’activité de programmation peut être

organisée, dans un objectif de qualité.• Considérations techniques sur la qualité.• Aspects humains (psychologiques notamment)

Qualité en programmation

Notions fondamentales

Le contrat

• Principe fondamental dans toutes les activitésindustrielles ou plus généralement économiques,le contrat est aussi un fondement de toutes lesétapes de l'élaboration d'un logiciel, de saspécification jusqu'à son abandon.

• Bien sûr, en fonction du point auquel on se situe,la nature et les effets des différents contrats serontvariables.

Le contrat

• Le contrat garantit une communication sansdéfaut, par un examen exhaustif de tous les casnécessaires. Un bon contrat lève toute ambiguïtéentre ses parties.

• Le contrat est un support fondamental de lasimplicité des solutions mises en oeuvre pour lerespecter.– En effet, il permet de travailler en monde clos, et de ne

pas anticiper des évolutions improbables.

Documents contractuels

• Réponses aux questions suivantes :• • "quoi" :

– quelles sont les fonctionnalités à implanter,• • "comment ":

– comment accède t'on à ces fonctionnalités,• • "quand"

– quelles sont les limites hors desquelles cesfonctionnalités ne sont pas accessibles (pas implantées).

• Ces contrats lient dans tous les cas des "clients" etdes "fournisseurs".

Trois niveaux fondamentaux decontrat en informatique

• Le plus haut niveau permet lacommunication entre acheteur du logiciel etprestataire, c'est le cahier des charges(spécification).

• Le niveau suivant lie les membres d'uneéquipe d'informaticiens, c'est la conception.

• Enfin, avec la granularité nécessaire, ledernier niveau lie les programmes entre eux.

La spécification : contrat entre clientet fournisseur

• Le client admet que ses besoins y sontexprimés de façon correcte et complète, etdonc accepte d'avance toute solutionconforme.

• Le prestataire sait de son côté que lessolutions qu'il envisage sont réalisables(dans les délais, ceux ci pouvant apparaîtrecomme un besoin dans la spécification).

Vision du développement agile

• Une partie importante des projetsinformatiques est aujourd'hui réalisée endéveloppement agile, en itérant de façontrès rapide des prototypes, destinés à recalerle cahier des charges

La conception : contrat liant lesmembres de l'équipe

• La conception décrit de manière détailléel'ensemble des solutions techniques devantêtre mises en oeuvre pour implanter ce qui aété spécifié.

• Il est formellement impossible de faire plus,ou moins, que ce que la conception a décrit.

Contrat entre programmes

• Chaque élément logiciel s'engage sur les pointssuivants :

• quoi : quelle est la fonctionnalité implantéepar ce programme.

• comment : quelles sont les règles de nommage(noms de fonction, types des arguments, types engénéral) pour obtenir cette fonctionnalité.

• quand : quelles sont les données de base pourlesquelles son fonctionnement est garanti(contraintes de domaine).

Que faire de ce qui sort du contrat?

• Supposons qu'on implémente la division réelle• y = f(x,z) = x/z• La valeur z=0 est hors du domaine de définition de

la fonction.• float divise(float x, float z)

{return x/z;

}

Une option

Une autre option

Cas des Exceptions

• Les langages de programmation modernes(C++, Java) permettent de gérer lesexceptions

• Il s'agit d'un mécanisme de contrôleparticulier, mais la prise en charge de cesexceptions rentre dans le contrat au senspropre

Les Interfaces de Programmation

• Il est d'usage que sur l'ensemble d'un projet, ou sur mêmesur une gamme de produits, soient définis des guides destyle pour la définition des types et des signatures defonctions et méthodes (y compris leur nommage).

• Exemples:• les fonctions du module graphique débutent par "Gr",• les symboles globaux commencent par une lettre capitale,• tous les objets statiques sont en majuscules,• aucun nom de variable n’a moins de six caractères etc…

Principe de l’Utilisateur Parfait

Principe de l'utilisateur parfait

• Tout programme s'engage à se comporter commeun utilisateur parfait de ses ressources (lesfonctions qu'il appelle),– c'est à dire à ne jamais appeler une fonction dans des

conditions qui la mettent hors de son domaine dedéfinition.

• Tout programme qui fournit un service au systèmes'engage à fonctionner correctement lorsque seséléments de calculs sont valides.

Traduction technique

• Aucune fonction ne doit s'attendre à gérerun cas ou un autre élément de programmefournirait des données incorrectes.

• Aucune fonction ne doit tester lesarguments de son calcul pour leurcorrection.

Utilisation d'invariants

• Un invariant est une propriété logique qui esttoujours vraie pendant l'exécution d'une partie d'unprogramme,

• soit un prérequis– (condition sur les données en entrée nécessaire pour le

déroulement d’un programme),• soit implicite du fait de la nature du programme

– (la définition et la vérification des invariants implicitesest un outil de base dans la preuve formelle deprogrammes).

La macro/instruction « assert »

• En C/C++/Java, l’outil de base pour lavérification d’invariants dans lesprogrammes est la macro « assert »

Exemple: definition de 1/x

Compiler en C/C++

• Compiler avec les assertions:• CC -o test test.cc

• Compiler sans les assertions:• CC -o test -DNDEBUG test.cc

Test de 1/x

Différents types d'invariants

Invariants de compatibilité système

• Ces invariants permettent de valider lerespect par l'architecture matérielle etlogicielle de conditions nécessaires auprogramme

Invariants de compatibilité debibliothèques

• On vérifie que les types définis par deuxbibliothèques distinctes sont compatibles

Invariants d’étape dans lesalgorithmes

• décrit une condition connue comme devantêtre vraie en un point d’un algorithme

• Par exemple un pointeur non nul à la sortied'une boucle

Exemple// tab est un tableau d’entiers positifsint Max=-1;int MaxI=-1;for (int i=0; i<N;i++){

assert(tab[i]>=0);if (tab[i]>Max){Max=tab[i];MaxI=i;}

}assert(Max>-1);assert(MaxI>=0);assert(MaxI<N);tab[MaxI]--; // toujours valide

Variants de boucle

• Un tel invariant s’appelle un « variant »parce qu’il décrit le fait que deux itérationssuccessives d’une boucle modifient lavaleur d’une variable de contrôle d’unemanière telle que l’on sait que leprogramme va s’arrêter.

Exemple de variant de boucle

Invariants de classe

• Ces invariants décrivent des conditionsvraies de toutes les instances d’une classe àtout moment de leur existence compris entre

• la fin de leur construction et• le début de leur destruction

Exemple

Finalement, un test c'est quoi?

Exemple

• Par exemple, imaginons une fonction définie parintervalles sur le domaine des nombres réelsstrictement positifs:

• x≤0fonction non définie test de domaine• x>0 et x<3 f(x)=1/x test de partie• x≥3 f(x)=1/3 test de partie

0 3

1/3

Principe

• Principe des tests de domaine: une fonctionqui implante un algorithme ne teste jamaisl'appartenance de ses arguments au domainede définition.

Test de domaines V1

• Ou l’on ne veut surtout pas que leprogramme s’arrête - combien de temps?

Test de domaines V2

• Ou l’on se dit - lançons une exception, ilsera bien à temps plus tard de le capter…

Test de domaines V3

• Où la paresse l’emporte

Test de domaines V4

• On ne teste pas les domaines. On les asserte

Impact sur la performance

• Dans de très nombreuses situations, lesalgorithmes garantissent que les conditionsd'appel des fonctions sont satisfaites.

Commentaire final

• Les invariants de domaine fournissent unedocumentation vivante intégrée auprogramme - utile pour la maintenance

• Les tests ne peuvent jamais être enlevés• Si nécessaire, on peut toujours compléter les

API avec des versions qui testent

Organisation de l'activité

Compiler et exécuter dès le début deson activité

• Les outils de génération de code sont la premièreaide du programmeur.

• compiler aussi tôt que possible, avec tous lesfichiers include des bibliothèques que l'on vautiliser.

• linker avec les bibliothèques que l'on doitutiliser par la suite.

• exécuter le programme de façon à pouvoir letester.

Sauver le temps

• Ne pas programmer de fonctions inutiles.

• Communiquer l'information.– Messageries, aide et manuel de référence en

ligne, cvs.

• Réduire le temps d'accès à l'information.– utilisation d'outils

Sauver le temps

• Documenter ses programmes.•• Protéger ses programmes.

– assert permet de presque totalement supprimer lesrecours au débugger.

• Réduire la charge des machines.– dans des projets importants la progression vers le but

s'accompagne d'une montée en charge du système.– A intervalles réguliers , prendre les décisions qui

s'imposent pour que la compilation et les tests sefassent en un temps acceptable.

Savoir automatiser

• Bien utiliser les outils disponibles pourgagner du temps et des efforts rébarbatifsest fondamental dans l'activité dedéveloppement.

• La mise en oeuvre d'un automatisme annexedoit prendre un temps négligeable au regarddu problème posé (disons que cela secompte en minutes en général).

Exemple: un shell pour l'appelrécursif d'une commande dans les

sous répertoires

Avoir une démarche produit

• documenter• tester• assurer la compatibilité ascendante de ses

programmes• assurer la portabilité• permettre la réentrance• séparer les algorithmes et les interfaces

homme machine

Principes de documentation

• Les invariants constituent le fondement de ladocumentation interne.

• La structure logique d'un programme (tests etboucles) parle d'elle même au lecteur lui mêmeprogrammeur.– Une documentation intégrée redondante est inutile.

Principes de documentation

• Quand une expression évaluée dans un test n'estpas suffisamment explicite pour le comprendre, uncommentaire est nécessaire.

• Lorsqu'un programme possède un effet de bordnon évident, cela doit être documenté.

• Un invariant qui ne peut raisonnablement pas êtretesté doit être mentionné en commentaire.

La ligne de compilation avec tests

Un exemple de makefile pour unebibliothèque d'outils

Organiser l'accès à l'Information

Structurer• Décider que chaque classe (C++) est décrite dans un jeu

de fichiers spécifiques, quelle qu'en soit la complexité.– avantages: la règle est facile à suivre– grouper par classes reflète la structure logique interne des

classes dans les fichiers, notamment l'encapsulation desfonctions.

• Grouper dans un fichier unique les programmes relevantde l'impression, ou de la trace, pour toutes les classes.

– avantages: les programmes de trace ont des traits communsfaisant que leur présence groupée dans un fichier unique permetd'en programmer rapidement de nouveaux "par l'exemple".

• Quelle que soit l'approche, on aura dans certains casbesoin d'informations orthogonales.

Accéder• La structure de fichiers ne permet pas simultanément les multiples

points de vue qui peuvent être nécessaires pour la disposer de toutesles informations utiles.

• Il est nécessaire de se donner des outils permettant de retrouver etde lister une information aussi rapidement que possible.

– ex: consulter le source d'une méthode de sérialisation– ex: retrouver la déclaration d'une fonction pour en connaître la

signature exacte• Sous Unix, les outils de base "grep", "sed" et "awk" sont précieux

pour concevoir des programmes de recherche d'information dansdes sources. Ils doivent être utilisés en l'absence de meilleur outil.

• Les environnements de développement modernes (Visual, Eclipse)offrent de multiples possibilités

Exemple: un shell d'extraction desource

Ne pas dupliquer

Classe, Fonction ou Macro?

• Il y a des cas ou un fragment de code qui necorrespond pas à une unité identifiable dulangage doive être répétée

• Dans ce cas on doit utiliser le macroprocesseur

Ex: décl/init de variable locale

Ex : action locale répétée

Ex : comparaisons en cascade

Ex Comparaisons (2)

Ne maintenir qu'un seul source

Apports de la compilationconditionnelle

• permettre la compilation sur toutes les plateformes,

• ne jamais oublier de version,• réduire le nombre des fichiers source utilisés,• utilisation optimale des ressources de chaque

environnement,• éviter l'oubli des conditions dans lesquelles la

variabilité apparaît.

Aspects techniques

Distinguer les différents types deparamètres

Paramètres machine• Les paramètres machine sont ceux qui sont liés à

l'architecture physique de la machine.– On sait par exemple que telle machine utilise des mots de 32 bits.– Un autre exemple est le nombre de registres internes au

processeur. L'écriture d'un "garbage collector " en dépendracertainement.

• Le pré processeur C permet de prendre en compte dessymboles définis automatiquement par le compilateur, ouexplicitement par la commande de compilation, pours'adapter aux variations d'architectures physique.– Le symbole correspondant s'appelle ARCH sous Unix. Sa valeur

lors d'une compilation est connue et peut être prise en compte.

Exemple

Paramètres système

• Le système d'exploitation pose égalementdes conditions sur l'exécution desprogrammes.– Par exemple, le nombre de fichiers qu'il est

possible d'ouvrir simultanément est variable,comme le nombre de processus, ou de threadsqu'il est possible d'exécuter à un momentdonné.

Paramètres de configuration• Paramètres transmis par l'environnement

qui permettent l'exécution du programme

Les variables d'environnement

Paramètres d'exécution

• Les données qui peuvent varier d'uneexécution à une autre et qui ne dépendent nide la machine, ni du système, ni de laconfiguration sont les paramètresd'exécution.

Passage de ces paramètres

Parser Argv

Parser Argv (2)

Parser Argv (3)

Constantes

• La bonne manière de déclarer les constantesest la dernière:

Gestion de la mémoire

Mémoire statique

• espace associé au code du programme, etsous Unix il en est très prochephysiquement.

• réservé par la déclaration d'une variableglobale

Mémoire Statique

Réentrance

Réentrance en action

Classe "Utility"

Mémoire automatique

• espace alloué sur la pile d'exécution

Adresses invalides

Mémoire dynamique

• espace total disponible pour le programme (horspile d'exécution liée à la mémoire automatique).

– Cet espace est égal lors du lancement du programmeà celui strictement nécessaire au chargement dans lamémoire vive du code programme et des donnéesstatiques.

• Un programme peut ensuite demanderexplicitement de la mémoire à l'aide de lafonction "sbrk".

Panorama de la mémoire

Conventions générales pourl'allocation de mémoire

• En aucun cas une fonction ne peut renvoyerl'adresse d'un espace allouéautomatiquement.

Allocation de mémoire (2)

• Lorsqu'une fonction retourne un pointeur, ilfaut savoir de façon non ambiguë(documentée) si le pointeur désigne unezone allouée par la fonction, ou bien unezone accessible par l'un de ses paramètres,et donc allouée antérieurement.– Il faut éviter d’avoir un mécanisme mixte :

valeur allouée dans certains cas, non allouéedans d'autres.

Allocation de mémoire (3)• Lorsqu'une fonction prend un pointeur en paramètre, elle

n'effectue jamais de duplication des données.– faisabilité : la copie n'est possible que lorsque on connaît la

taille et la structure des données. La fonction appelante possèdepeut être cette information, qui reste sans utilité pour la fonctionappelée.

– économie : l'autre alternative est celle de la copie systématiquedes paramètres en entrée. Elle se traduit par des coûtsd'exécution temps/espace plus importants, et par le risque devoir proliférer des zones non libérées.

– sécurité : la fonction appelante sait exactement dans quellesconditions la copie est nécessaire, en fonction de ses proprestraitements, et peut la réaliser elle même.

Distinguer les fonctions faisant descopies si nécessaire

Aspects Humains

Eviter de généraliser et d'abstraire

• 1 le goût de résoudre un "problème" difficile,• 2 le goût d'une certaine esthétique des

programmes,• 3 la croyance que l'on se protège d'avance contre

des évolutions futures du besoin client.• 4 la croyance que le même programme puisse

servir dans un autre projet• 5 l'impression d'améliorer la qualité du logiciel

Savoir déboguer

• les programmes corrects mais quiimplantent un algorithme faux,

• les programmes qui implanteraient unalgorithme correct, s'ils ne contenaient deserreurs.

• la combinaison des deux

Aspects psychologiquesComment déboguer:• décontraction (éviter le blocage)• faire un effort calme et patient de mémoire :

– passer les symboles et les programmes en revue, en répétantmentalement leur rôle.

• demander l'aide d'une personne extérieure :– lui expliquer le rôle des éléments du programme fautif et la

logique générale du programme suffira souvent à lui permettrede trouver l'erreur. Souvent, le fait d'expliquer permet auprogrammeur de faire effectivement l'effort calme et patient enquestion ci dessus, et de trouver l'erreur lui même.

Aspects statistiques

• Lorsqu'un programme "plante", lesinstructions erronées sont en général trèsproches de l'endroit où le programmes'arrête effectivement.

• L'utilisation des invariants a pour but decerner le point d'erreur au plus près

Isoler les conditions d'apparition dubug

• Pour réduire les conditions d'erreur à leurplus simple expression il suffit en généralde supprimer des portions du programme defaçon itérative tant que l'erreur estmaintenue.

• Il est en général inutile de chercher la causede l'erreur tant qu'on n'a pas procédé à cetteréduction à la séquence minimale.

savoir procéder par différencesélémentaires

• Après avoir isolé les conditions du bug,faire varier de manière indépendante tousles paramètres du programme, et considérerque ceux qui ne changent pas lecomportement du programme ne sont pasconcernés.

Principes de Capitalisation

Capitaliser=Réutiliser

Spécifier

• Les besoins auxquels répond un module (unegestion de liste par exemple) doivent êtreclairement définis.

• Pour garantir leur réutilisation ils doivent êtreuniversels, donc indépendants de toute spécificitéapplicative.

• Si de telles spécificités existent cependant, ellessont décrites à part en s'appuyant sur le noyaufondamental.

Concevoir

• Pour garantir la réutilisation, la conceptiondoit prévoir une interface de portabilité(indépendance des architectures matérielleet système), et doit obéir aux différentsprincipes généraux, dont celui del'utilisateur parfait.

Programmer• Les outils de base font l'objet de modules indépendants,

groupés dans une ou plusieurs bibliothèques.• Ces bibliothèques sont accessibles à l'ensemble des

membres de l'équipe, et font l'objet d'une rigoureusegestion de versions.

• Les programmes eux mêmes sont protégés desmalversations par des contrôles d'invariants dans leurversion de développement.

• On ne doit jamais conduire un utilisateur (programmeur)à utiliser un débugger pour naviguer dans des sourcesinconnus à la recherche de l'origine d'une erreur.

Documenter

• De bons documents de spécification et deconception constituent la documentation debase.

• Il faut les compléter par un "manuel del'utilisateur" qui décrit notamment des casd'utilisation détaillés et des exemples.

• Un manuel de référence si possible généréautomatiquement est nécessaire

• Le code est documenté en interne par sesinvariants

Livrer

• Un module doit être disponible auxdéveloppeurs sous deux versions.

• La première, de développement, effectue tousles tests de domaines nécessaires par descontrôles d'invariants, et garantit de ne jamais"planter" sans dire pourquoi.

• La seconde est une version de déploiementdébarrassée des contrôles d'invariants

Fin du chapitre

• Merci!