Reconnaissance et évaluation de l’erreur dans la conception

Il est important de savoir évaluer chaque erreur commise lors de la conception d’un logiciel à partir d’un SAM, après l’avoir détecté, afin de mieux la comprendre et par la suite la corriger bien qu’une erreur n’entraîne pas systématiquement une panne ou un blocage.

La détection de l’erreur peut s’effectuer de deux manières différentes :

• par la constatation ou la découverte, c’est-à-dire que l’utilisateur rencontre inopinément un bogue,

• par la détection automatique des erreurs grâce à un mécanisme interne ou externe au logiciel.

Sachant que la majeure partie des erreurs de conception est humaine, le travail à mener pour les déterminer et les évaluer, est laborieux. Afin de faciliter les tâches et surtout garantir les résultats de l’expertise, nous allons adopter deux axes de vue :

• Une vue verticale se basant sur la description des grandes catégories de fonctionnalités du logiciel final et donnant par conséquent l’architecture globale du système.

• Une vue horizontale qui exprime les relations entre les tâches et entre ceux qui les mettent en œuvre.

Nous remarquerons dans ce chapitre que l’analyse d’une erreur se fait uniquement par décomposition plus ou moins hiérarchique des fonctions et par raffinements successifs.

————————————— Concept d’erreur et de robustesse dans l’utilisation des SAM

3.2.5.1.Vue verticale

Pour comprendre une erreur, il faut en connaître la source. Aussi, l’utilisateur doit-il définir le maximum de fonctions et d’opérations qu’il souhaite réaliser, dans le cahier des charges, lors de la phase spécification fonctionnelle.

La vue verticale consiste à détecter le moment et l’endroit où a lieu l’erreur et à remonter progressivement jusqu'à la source. Cette remontée peut se faire de différentes façons :

la manière abstraite consiste à analyser uniquement les différentes actions / fonctions effectuées auparavant. Cela peut renvoyer l’utilisateur à la partie spécification fonctionnelle du cahier des charges.

la manière concrète se base uniquement sur les détails techniques, de la syntaxe de la ligne d’instruction vers le bloc de fonction, ensuite vers le langage utilisé, le système d’exploitation, jusqu’au matériel. Cela renvoie alors l’utilisateur à la partie spécification technique du cahier des charges.

la manière logique s’intéresse uniquement à la structure de l’ensemble du programme. L’algorithmique et la méthode de travail, normalement décrites dans la spécification organisationnelle du cahier des charges interviennent dans ce cas.

Fonctionnalité 1 Fonctionnalité 2

ERREUR ?

Instruction X

Fonction / opération Y

Codage / Programme

Spécifications décrites dans le cahier des charges

Figure 3-4 : Vue verticale suite à la détection d’une erreur

La vue verticale donne généralement une excellente évaluation de chaque erreur détectée. En effet, comme nous l’avons développé dans le chapitre sur les facteurs d’erreurs, la majorité des erreurs proviennent de l’individu. Il s’agit alors de suivre et de vérifier en détail chaque acte effectué pour la réalisation d’une fonction donnée. Cette vue qui offre la ramification

Chapitre 3 ————————————————————————————————— complète de la propagation d’une erreur dans un système, permet ainsi une vérification détaillée de l’ossature du programme et de l’enchaînement des idées.

3.2.5.2.Vue horizontale

La vue horizontale est moins pertinente que le fait d’aller en profondeur pour comprendre une erreur. En effet, il s’agit d’étudier les relations entre les différentes tâches se situant au même niveau. Par exemple, pour constituer une séquence d’images animées, la fonction servant à distribuer les différentes images et la fonction pour les inclure dans un scénario se situent au même niveau. Ainsi, lorsqu’il y a une erreur dans le scénario, l’utilisateur peut rechercher la cause dans la distribution ou dans la constitution des séquences d’images.

La vue horizontale peut être comparée à la programmation parallèle. Comme le montre le schéma ci-dessous, pour comprendre une erreur, on peut mettre en cause simultanément plusieurs fonctions.

Fonctionnalité 2

ERREUR ?

Fonctionnalité 3 Fonctionnalité 1

Figure 3-5 : Vue horizontale suite à la détection d’une erreur

Mais la navigation entre les différentes tâches peut se réduire à une simple ballade avec une faible mémorisation et une structuration superficielle des connaissances [Labat, 91]. En effet, l’utilisateur n’a aucun recul vis-à-vis de l’ensemble et risque même de tourner en rond car les autres fonctions ou opérations parallèles, auxquelles il a recours, peuvent être également erronées. L’évaluation d’une erreur peut alors être superficielle.

En revanche, la vue horizontale offre l’avantage de pouvoir vérifier et valider les liens entre les différentes fonctionnalités impliquées. Elle permet ainsi une consolidation globale du logiciel face à une erreur.

————————————— Concept d’erreur et de robustesse dans l’utilisation des SAM

3.2.5.3.Principe d’héritage dans l’erreur

Les deux axes de vue décrits précédemment montrent la propagation de l’erreur, et ce à partir de la source de l’erreur jusqu’aux lignes de code correspondant. On obtient alors une sorte d’arborescence non binaire car un élément peut être associé par la relation « entraîne l’erreur sur », à plusieurs éléments qui lui sont dépendants. Cette arborescence permet de connaître la gravité de l’erreur et démontre une certaine hiérarchie dans l’erreur.

Nous pouvons faire un rapprochement avec la notion d’héritage de la programmation objet, car on retrouve les mêmes définitions et principes.

Fonction X Fonctionnalité 1 Fonctionnalité 2 ERREUR Instruction A Fonction Z Fonction Y Erreur Instruction B Erreur

Figure 3-6 : Arborescence de propagation de l’erreur

L’ISO24 a retenu le formalisme « entité-association » pour décrire, pendant la conception d’un système, l’aspect conceptuel des données, en distinguant les entités (éléments), des associations entre les entités.

∗ Une entité désigne un type ou une classe ou un ensemble d’objets ayant des caractéristiques communes. Les sous-entités héritent de ces caractéristiques.

∗ L’association représente une rencontre, une correspondance entre des entités.

Les études menées par Peter Chen (1976) décrivent par exemple, ce formalisme appliqué au langage naturel : les noms comme des entités, les verbes équivalents aux associations et les adjectifs comme des attributs des entités.

Cette illustration nous montre que l’on peut aller jusqu'à un niveau de détail pointilleux pour appliquer le principe d’héritage. En particulier, par rapport à notre étude, l’analyse de chaque opération effectuée est intéressante car elle peut révéler des erreurs dans l’opération elle-

Chapitre 3 ————————————————————————————————— même ou dans d’autres opérations qui lui sont associées par la vue verticale ou par la vue horizontale.