Post on 17-May-2020
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!