A.E.E.L
Le but de cette methode est de mettre en évidence
des points critiques relevés durant les phases de développement d'un logiciel,
et de proposer aux personnes chargées des tests de validation, une synthèse
de la criticité des modules du logiciel analysé, afin d'affiner leur demarche.
Le principe de l'AEEL est d'envisager les hypothèses
d'erreurs dans des logiciels, puis d'examiner les conséquences de ces erreurs
:
L'AEEL se déroule
généralement en trois étapes :
Etape 1 : Définition des travaux
d'analyse :
Cette phase comprend:
Etape 2 : Classement preparatoire des modules:
Ceci consiste a effectuer un classement
des modules a analyser par ordre
de priorite en fonction des themes
d'etudes pour cela:
Ce classement permet de verifier
la couverture des tests de validation.
Etape 3: Réalisation des AEELs
Pour chaque traitement que relise
chaque module analyse dans l'etude:
On pourra faire un bilan de tout celà dans un tableau AEEL, très similaire aux tableaux AMDEC.
•Analyse structurelle
•AEEL
•RCC
•Diagnostics Qualité
•Analyse statique
Approche « volumétrique » visant à maîtriser la complexité des logiciels :
•Volume
• V(g)
• Graphe d’appels
• Méthode systématique
:
Pour chaque module, faire des hypothèses d’erreur
Étudier l’impact de chacune des hypothèses sur les sorties
du module
Analyser la propagation sur les modules environnant le module analysé.
• Sorties : recommandations de
conception et de codage des modules (exemple vérification ou filtrage
des entrées, recommandatios sur le séquencement,…) afin de garantir
des propriétés énoncées en phase de spécification.
• Constitue une analyse critique des interfaces, vis à vis de
la propagation d’erreur
• Permet de fixer des règles de structuration de la conception,
et de classer les modules par niveau de « criticité »
• Permet de donner des règles de programmation locales à
un module.
• Exemple : supposons que la vitesse mesurée d’un mobile soit
élaborée à partir d’une moyenne de points de mesure.
La moyenne est ensuite utilisée (uti) par un module de calcul de la
vitesse et de la commande d’accélération à appliquer.
On suppose qu’il existe un module de contrôle de vitesse INDEPENDANT
qui sanctionne la survitesse. A quelles conditions peut on utiliser le module
de moyenne pour le contrôle de vitesse ?
•Hypothèses d’erreur : La moyenne est réalisée sur un nombre insuffisant ou erroné de points de mesure
Conséquence : erreur relative sur le résultat
Impact : si l’erreur est trop grande on peut :
•Avoir une vitesse estimée trop faible => le module vitesse va demander une accélération à tort, qui sera sanctionnée par le contrôle de vitesse.
• SI CE MODULE A FAIT UN CALCUL D’ESTIMATION INDEPENDANT, L’impact se traduit alors en perte de disponibilité au niveau système ; SINON l’erreur ne sera pas détectée et il y a risque de collision.
• Avoir une vitesse estimée trop forte => le module vitesse va demander une décélération à tort , ce qui donne une perte de performance au niveau système.
• Exemple de recommandations suite à l’étude des effets
de l’erreur :
Le module ne peut être partagé par la commande et le contrôle
ou bien il doit être classé en critique.
Pour contrer les effets de la défaillance étudiée (production d’une moyenne incorrecte), on peut prévoir de mettre un test d’acceptance (une barrière logicielle) sur l’erreur relative entre la vitesse réelle et la vitesse estimée.
• Le test peut être fondé sur des variations acceptables (fourchette) entre la vitesse (n) et la vitesse (n+K) où n est un n° de cycle et K le nombre de cycles sur lequel on fonde l’estimation.
• Si le résultat est hors fourchette, on sort une valeur par défaut (nil par exemple) qui provoque une alarme et la mise en arrêt du système.
• Peut servir de support à la RCC
Exemple de Règles à vérifier :
• La moyenne est établie sur K mesures (n, n+K)
• Le test d’acceptance est réalisé sur la base de ces K mesures et il n’existe pas de séquence ne passant pas par le test d’acceptance
• Le résultat du test d’acceptance est réinitialisé à chaque cycle (n, n+K)
• A chaque cycle de calcul entre n et n+K, les entrées servant à l’estimation sont initialisées à une valeur « restrictive ».
• Le module n’a qu’un point de sortie, qui donne la valeur issue du test d’acceptance.
•Vérifier que le code est correct vis à vis des tâches
amont :
DCD
AEEL éventuellement
Règles de codage
• se donner des critères de relecture critique de code (exemples)
• respect de règles de nommage,
• respect de définitions de types et modes d’utilisation associés,
• respect de contraintes sur les valeurs des variables,
• respect de règles d’écriture des traitements,
• respect de contraintes structurelles du code
• respect de règles syntaxiques
• Cohérence vis à vis des spécifications et des
AEEL
Détection d’écarts fonctionnels
Prise en compte recommandations AEEL
• Cohérence DCP/code
Conception générale versus graphe d’appel
Vérification des composants appelés et des conditions d’appel
• Cohérence DCD/code
Vérification détaillée (en fait ligne à ligne)
– Séquencement des traitements,
– Vérification de l’initialisation des variables …
– Vérification des contextes d’appels , vérification des paramètres
d’appel
– Vérification des valeurs des variables produites
– Entrées
•Critères de relecture
• Documents amonts
• Code et (si disponible) analyse statique structurelle
– Sorties
• Tableaux de résultats (critère de relecture, composant)
• Démarche qui recouvre les éléments
précédents et qui consiste à « tracer » manuellement
les objectifs assignés au
logiciel sur les différents produits des phases de conception et de
codage.
Objectif : détecter les erreurs résiduelles qui provoqueront des défaillances à l’exécution
Exemples :
•Variables non initialisées
•Dépassement de bornes de tableaux
•Dépassement de bornes sur des valeurs, divisions par 0, overflows,
•Partage « illegal » de variables
•Corruption mémoire,
•Arithmétique de pointeurs erronée
•Constitue, en phase de test un moyen de compléter, voire de
remplacer la RCC pour ces classes d’erreur.
•Cf cours analyse statique dess
•Cf présentation technique et outils sous jacents « session
industriels ».
//Retourne le numero du premier thread a pouvoir etre cree
// -1 si on ne peut plus en creer
int SecuServApp::GetFreeThread (void) {
int result;
// recherche le numero du premier thread libre
for (result = 0;
(result < proxyConfig.GetThreadMax ()) && (threads[result] != NULL);
result++);
// si aucun thread n'est libre alors retourne -1
if (result >= proxyConfig.GetThreadMax ()) {
result = -1;
}
return result;
}
// Cree un thread
BOOL SecuServApp::CreateThread (int threadNumber) {
BOOL result = FALSE;
// creation de l'instance du thread
threads[threadNumber] = new
SecuServThread (userRecord, threadNumber);
if (threads[threadNumber] != NULL) {
// demarrage du thread
result = threads[threadNumber]-> CreateThread ();
// attend que le thread ait fini de s'initialiser
childStartedLock.Lock (INIT_THREAD_WAIT_TIMEOUT);
childStartedLock.Unlock ();
}
return result;
}