Expression de l’erreur

L’erreur peut être détectée selon trois mécanismes de base [Jambon, 96] : 1. L’autocontrôle par l’auteur lui-même donc par l’utilisateur de niveau 1,

2. La détection par un tiers qui est un moyen efficace pour détecter les erreurs de diagnostiques,

3. La détection à partir d’indices de l’environnement appelés plus couramment des bogues. La troisième manière de détecter une erreur nous intéresse particulièrement dans notre recherche car l’utilisateur de niveau 1 d’un SAM peut être néophyte en conception et donc n’aura pas le réflexe d’effectuer l’autocontrôle.

Une erreur en logiciel informatique se manifeste généralement lors de son utilisation. Les niveaux de criticité d’une erreur peuvent s’exprimer dans les termes suivants [Fournier, 93]: • Catastrophique : erreur non tolérée par l’application

• Majeur : erreur qui modifie le service rendu

• Gênant : erreur qui transforme sans gravité le service rendu • Mineur : erreur qui réduit le service rendu

• Bénin : erreur qui n’a aucun effet réel sur le service

————————————— Concept d’erreur et de robustesse dans l’utilisation des SAM Cette partie de notre étude sur l’erreur décrit les différentes manifestations de tout type d’erreurs, et présente les outils et méthodes pour les éviter et les résoudre.

3.2.1.1.Les différents types de bogues

Une panne ou un blocage résultant d’une erreur est appelé bogue en informatique. Généralement un bogue est une occurrence ou un fait qui n'a pas été prévu dans le programme [Dubrovsky, 97]. Voici la liste des principaux types de bogues auxquels nous avons associé à chacun une qualification :

• Bogues radicales :

Il s’agit des types de bogues qui peuvent être détectés même par un débutant. Il s'agit des erreurs créant un "plantage" soit du programme, soit de l’ensemble du système, donc l'ordinateur. Ils arrivent inopinément et sont difficiles à corriger ou à éviter.

• Bogues syntaxiques :

Ce nom définit les bogues provenant du non-respect du langage de programmation que l'ordinateur va coder. Ces problèmes sont souvent faciles à résoudre grâce au compilateur et interpréteur souvent très évolués. Nous pensons par exemple à l’analyseur syntaxique Lint sous Unix lorsque l’on veut lister les erreurs syntaxiques avant de compiler un programme en langage C. Ils apparaissent uniquement pendant le développement du logiciel, jamais lorsque le logiciel est compilé.

• Bogues pervers :

Ces types de bogues sont souvent bien camouflés et très difficiles à détecter même par les spécialistes. Nous pouvons penser au bogue concernant les premiers microprocesseurs Pentium, qui donne un résultat faux périodiquement, après un nombre défini d’opérations. Les bogues pervers mettent souvent énormément de temps pour se manifester, sont difficilement décelables et sont plus ou moins faciles à corriger.

• Bogues surprises :

Ces types de bogues se manifestent par surprise. Le programme exécute parfois des instructions complètement inattendues. Ce sont surtout les débutants qui ne maîtrisent pas suffisamment leurs outils de développement qui font face à ces bogues.

Chapitre 3 ————————————————————————————————— Ces types de bogues sont dûs à une erreur de logique dans le programme. Le programme pourra ainsi dévier de son objectif principal. Ils ne sont souvent détectés qu’à la fin du développement.

3.2.1.2.Outils et méthodes de prévention et de détection

Les bogues sont souvent communs à tous les domaines constituant la discipline informatique. Aussi, les systèmes auteurs ont-ils pu profiter de toutes les recherches effectuées pour résoudre les bogues, bien que ce ne soit pas en temps réel. Les méthodes et outils mis en œuvre aujourd’hui pour la détection sont :

• Le debugger offre un environnement qui prévient le développeur dès qu'une erreur est détectée. Mais les erreurs reconnues par ces debuggers sont prédéfinies et ne couvrent pas encore tous les cas d’erreurs possibles. Plusieurs systèmes auteurs tels que Director ou IconAuthor ont implémenté un debugger.

• Le breakpoint correspond à un traçage de l'exécution d'un programme. Le développeur marque la ligne d'instruction où l'exécution doit s'arrêter. Cette méthode lui permet de situer l’emplacement du problème. Ce sont surtout les langages de programmation de niveau 0 et les langages générateurs de code18 qui utilisent cette méthode.

• Le Single Step est quasiment la même méthode que le breakpoint sauf que le traçage s'effectue ligne par ligne. L’utilisateur a alors la possibilité de tester le résultat de chaque instruction. Le single step est par conséquent plus précis au point de vue syntaxique mais n’aide pas le développeur au niveau logique de programmation et surtout à avoir une vision globale du programme.

• L’Output désigne une méthode visant à afficher volontairement sur la sortie standard ou dans un fichier certains résultats du programme. Cette méthode est souvent associée aux deux précédentes.

• Le Commentaire est la manière la plus simple, et la plus utilisée pour déboguer un programme. Cette méthode est peu efficace, surtout syntaxiquement. En échange, le fait de commenter le maximum de lignes d’instruction, représente une aide considérable dans le suivi de l’ossature du programme. Cela permet à l’utilisateur, qu’il soit novice ou expert, de ne pas se noyer pendant la phase de codage.

————————————— Concept d’erreur et de robustesse dans l’utilisation des SAM D’autres méthodes moins directes, destinées principalement à la prévention, existent également [Chebili, 2000] :

• La documentation : selon sa qualité, elle peut être considérée comme le premier élément de secours en cas de problème.

• Les messages d'erreurs : ils permettent à l’utilisateur de diagnostiquer une mauvaise action ou une erreur de syntaxe qu’il a commise. Le plus souvent, ces messages sont d'ordre indicatif et ne sont pas approfondis. Ils ne sont donc pas suffisants pour permettre à un utilisateur débutant ou occasionnel de résoudre la difficulté à laquelle il est confronté. En revanche, les messages d’erreur sont avantageux par le fait qu’ils apportent une aide en temps réel.

• Les définitions des fonctions : on les rencontre souvent dans les interfaces graphiques ; au passage de la souris sur l'icône représentative de la fonction, une très brève définition s'affiche pour informer l'utilisateur de la tâche qui sera effectuée en cliquant sur l'icône en question.

• Les tutoriels : ils offrent des formations structurées aux utilisateurs pour apprendre l’utilisation de l’application [Shute-94]. Ils sont généralement utilisés hors session de travail et n’apportent pas d’assistance en temps réel à l’utilisateur en cas de problème.