Qualité en Développement Laurent Henocque Enseignant Chercheur ESIL/INFO France

Présentation au sujet: "Qualité en Développement Laurent Henocque Enseignant Chercheur ESIL/INFO France"— Transcription de la présentation:

1 Qualité en Développement Laurent Henocque http://laurent.henocque.free.fr/ Enseignant Chercheur ESIL/INFO France http://laurent.henocque.perso.esil.univmed.fr/ mis à jour en Octobre 2006

2 Licence Creative Commons Cette création est mise à disposition selon le Contrat Paternité-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, 559 Nathan Abbott Way, Stanford, California 94305, USA.

3 Objectifs Ce cours a pour projet de donner les bases de techniques de travail reconnues comme nécessaires pendant tout le cycle de vie du logiciel, et d'apprendre les méthodes qui permettent d'affronter systématiquement et de résoudre les problèmes.

4 Plan Concepts fondamentaux de qualité logicielle, –notamment les notions de contrats, d'invariants et une discussion sur la notion de test. Comment lactivité de programmation peut être organisée, dans un objectif de qualité. Considérations techniques sur la qualité. Aspects humains (psychologiques notamment)

5 Qualité en programmation Notions fondamentales

6 Le contrat Principe fondamental dans toutes les activités industrielles ou plus généralement économiques, le contrat est aussi un fondement de toutes les étapes de l'élaboration d'un logiciel, de sa spécification jusqu'à son abandon. Bien sûr, en fonction du point auquel on se situe, la nature et les effets des différents contrats seront variables.

7 Le contrat Le contrat garantit une communication sans défaut, par un examen exhaustif de tous les cas nécessaires. Un bon contrat lève toute ambiguïté entre ses parties. Le contrat est un support fondamental de la simplicité des solutions mises en oeuvre pour le respecter. –En effet, il permet de travailler en monde clos, et de ne pas anticiper des évolutions improbables.

8 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 ces fonctionnalités ne sont pas accessibles (pas implantées). Ces contrats lient dans tous les cas des "clients" et des "fournisseurs".

9 Trois niveaux fondamentaux de contrat en informatique Le plus haut niveau permet la communication entre acheteur du logiciel et prestataire, 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, le dernier niveau lie les programmes entre eux.

10 La spécification : contrat entre client et fournisseur Le client admet que ses besoins y sont exprimés de façon correcte et complète, et donc accepte d'avance toute solution conforme. Le prestataire sait de son côté que les solutions qu'il envisage sont réalisables (dans les délais, ceux ci pouvant apparaître comme un besoin dans la spécification).

11 Vision du développement agile Une partie importante des projets informatiques est aujourd'hui réalisée en développement agile, en itérant de façon très rapide des prototypes, destinés à recaler le cahier des charges

12 La conception : contrat liant les membres de l'équipe La conception décrit de manière détaillée l'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.

13 Contrat entre programmes Chaque élément logiciel s'engage sur les points suivants : quoi : quelle est la fonctionnalité implantée par ce programme. comment : quelles sont les règles de nommage (noms de fonction, types des arguments, types en général) pour obtenir cette fonctionnalité. quand : quelles sont les données de base pour lesquelles son fonctionnement est garanti (contraintes de domaine).

14 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; }

15 Une option

16 Une autre option

17 Cas des Exceptions Les langages de programmation modernes (C++, Java) permettent de gérer les exceptions Il s'agit d'un mécanisme de contrôle particulier, mais la prise en charge de ces exceptions rentre dans le contrat au sens propre

18 Les Interfaces de Programmation Il est d'usage que sur l'ensemble d'un projet, ou sur même sur une gamme de produits, soient définis des guides de style pour la définition des types et des signatures de fonctions et méthodes (y compris leur nommage). toutes les fonctions du module graphique commencent par "Gr", tous les symboles globaux aient des noms commençant par une lettre capitale, tous les objets statiques soient en majuscules, aucun nom de variable ne fasse moins de six caractères etc…

19 Principe de l'utilisateur parfait Tout programme s'engage à se comporter comme un utilisateur parfait de ses ressources (les fonctions qu'il appelle), –c'est à dire à ne jamais appeler une fonction dans des conditions qui la mettent hors de son domaine de définition. Tout programme qui fournit un service au système s'engage à fonctionner correctement lorsque ses éléments de calculs sont valides.

20 Traduction technique Aucune fonction ne doit s'attendre à gérer un cas ou un autre élément de programme fournirait des données incorrectes. Aucune fonction ne doit tester les arguments de son calcul pour leur correction.

21 Utilisation d'invariants Un invariant est une propriété logique qui est toujours vraie pendant l'exécution d'une partie d'un programme, soit qu'elle constitue un prérequis (c'est alors un invariant de domaine de définition), soit qu'elle soit implicite du fait de la nature du programme (la définition et la vérification des invariants implicites est un outil de base dans la preuve formelle de programmes).

22 Assert

23 Definition de 1/x

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

25 Test de 1/x

26 Différents types d'invariants

27 Invariants de compatibilité système Ces invariants permettent de valider le respect par l'architecture matérielle et logicielle de conditions nécessaires au programme

28 Invariants de compatibilité de bibliothèques On vérifie que les types définis par deux bibliothèques distinctes sont compatibles

29 Invariants détape dans les algorithmes décrit une condition connue comme devant être vraie en un point dun algorithme Par exemple un pointeur non nul à la sortie d'une boucle

30 Exemple int Max=-1; int MaxI=-1; for (int i=0; i<N;i++){ if (tab[i]>Max){Max=tab[i];MaxI=i;} } assert(Max!=-1); assert(MaxI>=0); assert(MaxI<N); tab[MaxI]--;

31 Variants de boucle Un tel invariant sappelle un « variant » parce quil décrit le fait que deux itérations successives dune boucle modifient la valeur dune variable de contrôle dune manière telle que lon sait que le programme va sarrêter.

32 Exemple de variant de boucle

33 Invariants de classe Ces invariants décrivent des conditions vraies de toutes les instances dune classe à tout moment de leur existence compris entre la fin de leur construction et le début de leur destruction

34 Exemple

35 Finalement, un test c'est quoi?

36 Exemple Par exemple, imaginons une fonction définie par intervalles sur le domaine des nombres réels strictement positifs: x0fonction non définie test de domaine x>0 et x<3f(x)=1/xtest de partie x3f(x)=1/3test de partie 03 1/3

37 Principe Principe des tests de domaine: une fonction qui implante un algorithme ne teste jamais l'appartenance de ses arguments au domaine de définition.

38 Test de domaines V1

39 Test de domaines V2

40 Test de domaines V3

41 Test de domaines V4 On ne teste pas les domaines. On les asserte

42 Impact sur la performance Dans de très nombreuses situations, les algorithmes garantissent que les conditions d'appel des fonctions sont satisfaites.

43 Commentaire final Les invariants de domaine fournissent une documentation vivante intégrée au programme - 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

44 Principes de Capitalisation Capitaliser=Réutiliser

45 Spécifier Les besoins auxquels répond un module (une gestion de liste par exemple) doivent être clairement définis. Pour garantir leur réutilisation ils doivent être universels, donc indépendants de toute spécificité applicative. Si de telles spécificités existent cependant, elles sont décrites à part en s'appuyant sur le noyau fondamental.

46 Concevoir Pour garantir la réusabilité, la conception doit prévoir une interface de portabilité (indépendance des architectures matérielle et système), et doit obéir aux différents principes généraux, dont celui de l'utilisateur parfait.

47 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 rigoureuse gestion de versions. Les programmes eux mêmes sont protégés des malversations par des contrôles d'invariants dans leur version de développement. On ne doit jamais conduire un utilisateur (programmeur) à utiliser un débugger pour naviguer dans des sources inconnus à la recherche de l'origine d'une erreur.

48 Documenter De bons documents de spécification et de conception constituent la documentation de base. Il faut les compléter par un "manuel de l'utilisateur" qui décrit notamment des cas d'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 ses invariants

49 Livrer Un module doit être disponible aux développeurs sous deux versions. La première, de développement, effectue tous les tests de domaines nécessaires par des contrôles d'invariants, et garantit de ne jamais "planter" sans dire pourquoi. La seconde est une version de déploiement débarrassée des contrôles d'invariants

50 Principes de documentation interne Les invariants constituent le fondement de la documentation interne. La structure logique d'un programme (tests et boucles) parle d'elle même au lecteur lui même programmeur. –Une documentation intégrée redondante est inutile. Quand une expression évaluée dans un test n'est pas suffisamment explicite pour le comprendre, un commentaire est nécessaire. Lorsqu'un programme possède un effet de bord non évident, cela doit être documenté. Un invariant qui ne peut raisonnablement pas être testé doit être mentionné en commentaire.

51 Organisation de l'activité

52 Compiler et exécuter dès le début de son activité Les outils de génération de code sont la première aide du programmeur. compiler aussi tôt que possible, avec tous les fichiers include des bibliothèques que l'on va utiliser. linker avec les bibliothèques que l'on doit utiliser par la suite. exécuter le programme de façon à pouvoir le tester.

53 Sauver le temps 1Ne pas programmer de fonctions inutiles. 2Communiquer l'information. –Messageries, aide et manuel de référence en ligne, cvs. 3Réduire le temps d'accès à l'information. –utilisation d'outils 4Documenter ses programmes. 5Protéger ses programmes. –assert permet de presque totalement supprimer les recours au débugger. 6 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 il convient de prendre les décisions qui s'imposent pour que la compilation et les tests se fassent en un temps acceptable.

54 Savoir automatiser Bien utiliser les outils disponibles pour gagner du temps et des efforts rébarbatifs est fondamental dans l'activité de développement. La mise en oeuvre d'un automatisme annexe doit prendre un temps négligeable au regard du problème posé (disons que cela se compte en minutes en général).

55 Exemple: un shell pour l'appel récursif d'une commande dans les sous répertoires

56 Organiser l'accès à l'Information

57 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 des fonctions. Grouper dans un fichier unique les programmes relevant de l'impression, ou de la trace, pour toutes les classes. –avantages: les programmes de trace ont des traits communs faisant que leur présence groupée dans un fichier unique permet d'en programmer rapidement de nouveaux "par l'exemple". Quelle que soit l'approche, on aura dans certains cas besoin d'informations orthogonales.

58 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 toutes les informations utiles. Il est nécessaire de se donner des outils permettant de retrouver et de 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 dans des 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

59 Exemple: un shell d'extraction de source

60 Ne pas dupliquer

61 Classe, Fonction ou Macro? Il y a des cas ou un fragment de code qui ne correspond pas à une unité identifiable du langage doive être répétée Dans ce cas on doit utiliser le macro processeur

62 Ex: décl/init de variable locale

63 Ex : action locale répétée

64 Ex : comparaisons en cascade

65 Ex Comparaisons (2)

66 Ne maintenir qu'un seul source

67 Apports de la compilation conditionnelle permettre la compilation sur toutes les plate formes, 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.

68 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

69 Aspects techniques Distinguer les différents types de paramètres

70 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épendra certainement. Le pré processeur C permet de prendre en compte des symboles définis automatiquement par le compilateur, ou explicitement par la commande de compilation, pour s'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.

71 Exemple

72 Paramètres système Le système d'exploitation pose également des conditions sur l'exécution des programmes. –Par exemple, le nombre de fichiers qu'il est possible d'ouvrir simultanément est variable, comme le nombre de processus, ou de threads qu'il est possible d'exécuter à un moment donné.

73 Paramètres de configuration Paramètres transmis par l'environnement qui permettent l'exécution du programme

74 Les variables d'environnement

75 Paramètres d'exécution Les données qui peuvent varier d'une exécution à une autre et qui ne dépendent ni de la machine, ni du système, ni de la configuration sont les paramètres d'exécution.

76 Passage de ces paramètres

77 Parser Argv

78 Parser Argv (2)

79 Parser Argv (3)

80 Constantes La bonne manière de déclarer les constantes est la dernière:

81 Gestion de la mémoire

82 Mémoire statique espace associé au code du programme, et sous Unix il en est très proche physiquement. réservé par la déclaration d'une variable globale

83 Mémoire Statique

84 Réentrance

85 Réentrance en action

86 Classe "Utility"

87 Mémoire automatique espace alloué sur la pile d'exécution

88 Adresses invalides

89 Mémoire dynamique espace total disponible pour le programme (hors pile 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 la mémoire vive du code programme et des données statiques. Un programme peut ensuite demander explicitement de la mémoire à l'aide de la fonction "sbrk".

90 Panorama de la mémoire

91 Conventions générales pour l'allocation de mémoire En aucun cas une fonction ne peut renvoyer l'adresse d'un espace alloué automatiquement.

92 Allocation de mémoire (2) Lorsqu'une fonction retourne un pointeur, il faut savoir de façon non ambiguë (documentée) si le pointeur désigne une zone allouée par la fonction, ou bien une zone accessible par l'un de ses paramètres, et donc allouée antérieurement. –On ne peut donc avoir de mécanisme mixte : valeur allouée dans certains cas, non allouée dans d'autres.

93 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ède peut être cette information, qui reste sans utilité pour la fonction appelée. –économie : l'autre alternative est celle de la copie systématique des paramètres en entrée. Elle se traduit par des coûts d'exécution temps/espace plus importants, et par le risque de voir proliférer des zones non libérées. –sécurité : la fonction appelante sait exactement dans quelles conditions la copie est nécessaire, en fonction de ses propres traitements, et peut la réaliser elle même.

94 Distinguer les fonctions faisant des copies si nécessaire

95 Aspects Humains

96 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

97 Savoir déboguer les programmes corrects mais qui implantent un algorithme faux, les programmes qui implanteraient un algorithme correct, s'ils ne contenaient des erreurs. la combinaison des deux

98 Aspects psychologiques Comment 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étant mentalement 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 permettre de trouver l'erreur. Souvent, le fait d'expliquer permet au programmeur de faire effectivement l'effort calme et patient en question ci dessus, et de trouver l'erreur lui même.

99 Aspects statistiques Lorsqu'un programme "plante", les instructions erronées sont en général très proches de l'endroit où le programme s'arrête effectivement. L'utilisation des invariants a pour but de cerner le point d'erreur au plus près

100 Isoler les conditions d'apparition du bug Pour réduire les conditions d'erreur à leur plus simple expression il suffit en général de supprimer des portions du programme de façon itérative tant que l'erreur est maintenue. Il est en général inutile de chercher la cause de l'erreur tant qu'on n'a pas procédé à cette réduction à la séquence minimale.

101 savoir procéder par différences élémentaires Après avoir isolé les conditions du bug, faire varier de manière indépendante tous les paramètres du programme, et considérer que ceux qui ne changent pas le comportement du programme ne sont pas concernés.

102 La ligne de compilation avec tests Un exemple de makefile pour une bibliothèque d'outils

103

104

105

106

107

108 Fin du chapitre