VALIDATION VERIFICATION TESTS

©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 2 : Tests boites noires et tests boites blanches / Vers. 5.0 Page 1

VALIDATION VERIFICATION TESTS

TESTS BOITES NOIRES et TESTS BOITES BLANCHES

STRUCTURE ET ORGANISATION DES PROGRAMMES EN VUE

DES TESTS

C E N T R E D E

M A I T R I S E D E S

S Y S T E M E S E T

D U L O G I C I E L


TESTS BOITES NOIRES et TESTS BOITES BLANCHES


Typologie des systèmes informatiques (1/2)

• Deux grandes classes de programmes et/ou de systèmes qui interagissent de plus en plus :

– Programmes TRANSFORMATIONNELS séquentiels et/ou concurrents– Transforment progressivement, et par étapes, les données entrées en résultats– La description des données est primordiale

» Exp. : • une transaction dans un système d’information• un calcul dans une simulation numérique, etc.

– Programmes RÉACTIFS synchrones et/ou asynchrones– Maintiennent une relation constante avec l’environnement– La description du comportement est primordiale (ce qui implique un modèle de

l’environnement)

» Exp. : • un ensemble de transactions dans un système d’information qui interagissent avec un ensemble

d’usagers du SI• le pilote automatique d’un avion, etc.


Typologie des systèmes informatiques (2/2)

• Dans les deux cas, l’architecture logicielle est une caractéristique fondamentale

– Architecture des DONNÉES– MCD, schémas et vues des données, types des données, codage des données,

variables essentielles/inessentielles, dépendances fonctionnelles, Domaines et plages de valeurs des données

– Architecture des TRAITEMENTS– Enchaînements des fonctions qui réalisent la transformation entre un état initial

(supposé cohérent) et un état final qui soit l’exact reflet de la réalité que le programme et/ou le système modélise

– Principe ACID de la programmation transactionnelle

– Architecture des CONTRÔLES– Événements programmés et/ou inopinés, interruptions, attentes, retards,

synchronisation, protocoles, états, transitions, automates– État nominal de l’environnement et contrôle de l’environnement


Éléments visibles du composant (1/2)

MAINTENABILITE / INSTRUMENTATION• paramètres et/ou ordres de visualisation des états internes de l'élément

Pvisu

Elément ou Composant

à TesterDE DS

DOMAINE ENTRÉE / LECTURE• initialisation avec une combinaison valide des données d'entrée

DOMAINE SORTIE / ECRITURE• État final résultant de l'exécution de l'élément à partir des données d'entrée

Traces

TRACES• États intermédiaires résultant de l'instrumentation

Données Code

Contrôle

Canal d'observation

Canal d'intrusion

État initial État final


Éléments visibles du composant (2/2)

Pvisu

DE DS

Traces

Données Code

Contrôle

Canal d'observation

Canal d'intrusion

Agents d'intrusion

Agents d'observationLes programmes agents sont une forme de redondance qu'il faut doser de façon à perturber le moins possible le comportement de l'élément tout en assurant les conditions d'une bonne observation. Ces agents peuvent être générés sur options, activés ou désactivés (actions de «debug», code OLTD, pré et post-conditions, etc.)

Table des paramètres et ordres d'intrusion construite à l'avance, devant conduire à l'observation d'un comportement et de résultats intermédiaires déterminés à l'avance.

Table des états intermédiaires observables (i.e. « histoire » de la transformation)


États observables d’un programme :

États programmes / états données

Elément ou Composant

à TesterDE DS

Données Code

Contrôle


L’état programme à l’instant t résulte de :

• Données directement sous le contrôle du programme P toujours accessibles état données

• Données induites par le système d’exploitation, le SGBD, les Télécom, etc. ) très difficilement accessibles

État programmeÉtat des données sous contrôle de P

Parasites / Bruit de fond résultants des actions hors contrôle de P


TESTS BOITES NOIRES

• ON NE PREND EN COMPTE QUE DE ET DS

» VALIDATION• ANALYSE DE LA STRUCTURATION DE DE ET DS

• ANALYSE DES CORRESPONDANCES ENTRE DE ET DS (i.e. on valide complètement la sémantique de la transformation)

• ASPECTS COMBINATOIRES

• LIMITE DES TESTS BOITES NOIRES» LA DÉTERMINATION DES DOMAINES EST PROBLÉMATIQUE» RENDEMENT DE L'EFFORT DE TESTS POTENTIELLEMENT TRÈS

MAUVAIS


TESTS BOITES BLANCHES (1/2)

• ON PREND EN COMPTE DE DS ET LA STRUCTURE INTERNE DE L’ÉLÉMENT

» VÉRIFICATION» NIVEAU DE GRANULARITÉ DE L'OBSERVATION

• INSTRUCTIONS ÉLÉMENTAIRES• SÉQUENCES LINÉAIRES D'INSTRUCTIONS• BLOCS DE CODE REGROUPANT PLUSIEURS SÉQUENCES APPARENTÉES ( i.e. RÉGIONS FORTEMENT

CONNEXES )• FONCTIONS ET/OU PROCÉDURES DU LANGAGE

» ENVIRONNEMENT D'EXECUTION• ASPECTS TEMPORELS, GESTION DES RESSOURCES, etc.

• LIMITE DES TESTS BOITES BLANCHES» QUANTITÉ ET PERTINENCE DE L'INFORMATION PRODUITE» STABILITÉ DES TESTS :

– MEME STABILITÉ QUE LE CODE

» COINCIDENCE ET RECOUVREMENT NON GARANTIS ENTRE VÉRIFICATION ET VALIDATION


TESTS BOITES BLANCHES (2/2)

• Fondés sur l’aspect structural (i.e. syntaxique) du composant à tester au moyen du graphe de contrôle

– On s’intéresse à l’agencement des instructions, et non à leur signification» Exp. : DO WHILE ((a>5) & (a<5)) DO; bloc d’instructions; END DO;

• Graphes de contrôle et nombre cyclomatique ignorent l’aspect sémantique

– La sémantique prend en compte la nature de la transformation Ds = Prog(De), c.a.d. aux domaines de valeurs et au sens des opérateurs

» Exp. : la condition ((a>5) & (a<5)) est toujours FAUSSE, donc le bloc d’instructions n’est jamais exécuté

• Par définition, les tests de chemins ne peuvent pas détecter les chemins manquants

– Il n’assurent pas la complétude de l’implémentation par rapport à la spécification du composant


STRUCTURE ET ORGANISATION DES PROGRAMMES EN VUE DE LEUR CONSTRUCTION


Terminologie

• STRUCTURE d’un programme– Résulte des différentes catégories d’instructions utilisées pour construire le

programme et pour réaliser la transformation souhaitée– Résulte directement des règles de syntaxe et de sémantique du langage de

programmation utilisé

• ORGANISATION d’un programme– Regroupement des instructions constitutives de la transformation en :

» procédures, sous programmes, classes, tâches, etc.– Les instructions correspondantes (qui ne modifient pas l’état mémoire) sont,

en fait, des directives d’assemblage» unités d’alimentation (mémoire virtuelle mémoire centrale) utilisées par

l’éditeur de liens dynamique et/ou le chargeur (i.e. loader) du système d’exploitation (découpage en fichiers / segments / pages selon les SE)


STRUCTURE GÉNÉRALE DES LANGAGES DE PROGRAMMATION IMPÉRATIFS (1/2)

• Dans ce type de langage de programmation 3 catégories d’instructions :

– Celles qui MODIFIENT L’ÉTAT MÉMOIRE du programme» Exp. :

a=b; MOVE a TO b CALL tri-rapide (f1,f2); etc.

– Celles qui MODIFIENT LE FLOT D’EXÉCUTION des instructions (instructions dites de contrôle)

» Exp. :IF c THEN a=b ELSE a=c GOTO l

– Celles qui permettent D’ORGANISER LE PROGRAMME en mémoire» Exp. :

En COBOL : organisation en DIVISION, SECTION et paragraphes

En Ada : blocs d’instructions declare … begin … end;

organisation en classes package p is … end p;

pakage body p1 is procedure p2 … end p2; … end p1;

tâches task body t is… end t;

En C et C++ : etc.


STRUCTURE GÉNÉRALE DES LANGAGES DE PROGRAMMATION IMPÉRATIFS (2/2)

• Marquage des instructions– Toutes les instructions sont repérables par :

» leur nom (en anglais label)l1 : a=b; l1 : DO …. END l1; GOTO l1;

» leur N° d’ordre dans le programme» leur adresse machine (symbolique ou physique)

• Cf. : les références croisées et les cartes d ’allocation mémoire produite par les compilateurs et les éditeurs de liens

– Obligatoire pour des raisons d’édition et de mise au point

• La plupart des langages ont des fonctions d’édition incorporées qui permettent de composer le programme à compiler à partir de motifs pré-enregistrés

– Clauses COPY en COBOL– Unités generic en Ada– Macros en C / C++


REPRÉSENTATIONS ET PROPRIÉTÉS ÉLÉMENTAIRES DE LA BOÎTE BLANCHE


Graphe de contrôle d’un programme

• Tout programme peut se représenter sous forme de graphe où :

– Les nœuds sont les instructions– Les arcs sont les branchements

• Exemple :

Un if-then-else


Les types de nœuds du graphe

• Il y a trois types de nœuds :– Les nœuds « fonction » (toute instruction est une fonction) matérialisés par :

– Les nœuds « prédicatifs » (représentant une condition) matérialisés par :

– Les nœuds « de regroupement » (qui sont vides) matérialisés par :

f

c


Programmation structurée (1/3)

• Si l’on examine tous les graphes de 1 à 4 nœuds (il y en a 15), seuls 7 sont pertinents car les autres n’ont pas de nœuds fonction (il n’y a donc pas d’instruction !)

• Ces 7 graphes sont à l’origine de la programmation structurée


Programmation structurée (2/3)

• En effet, on a :– L’instruction : a = b; par exemple

– La séquence : a = b; c = d;

» Remarque : correspond à la composition de fonctions

– Les alternatives :

» If-then

» If-then-else

– Les itératives :

» While-do

» Do…while (ou repeat…until)

» Do-while-do (test de « milieu » de boucle)


La programmation structurée (3/3)

• On remarque que :– Il n’y a pas le « case » (switch)

» C’est un confort syntaxique pour exprimer des cascades de if-then-else imbriqués

– Il n’y a pas de boucle « for »» La boucle «for » n’est pas une vraie boucle


Programme structuré

• Un programme structuré est donc :– Un programme qui ne possède qu’un point d’entrée et un point de sortie– Constitué à partir des 7 formes de bases (appelées structures premières)– Tel que pour chaque nœud il existe un chemin reliant l’entrée à la sortie


Définition du nombre cyclomatique(1/4)

• À partir du graphe de programme on peut calculer le nombre cyclomatique (Mc Cabe-1976) V(g) tel que :

– V(g) = e – n + 2 (e : edge [arc] ; n : node [nœud])

• Le nombre cyclomatique représente :– Le nombre de chemins linéairement indépendants dans un graphe fortement

connexe

– Le nombre de décisions + 1 prises dans un programme (i.e. le nombre de nœuds prédicatifs + 1)



• Un graphe est fortement connexe si : ni et nj, deux nœuds du graphe, un chemin reliant ni et nj

» On remarque qu’un programme bien structuré n’a pas un graphe fortement connexe car il n’y a pas de chemin reliant la sortie à l’entrée ! (on ajoute donc cet arc fictif)

• Le nombre de chemins linéairement indépendants correspond au nombre de régions du plan délimitées par le graphe quand les arcs ne se recoupent pas.



• Exemple

V(G) = 3 (donc 2 décisions)



• Quelle valeur maximum ?– On considère généralement que le nombre cyclomatique doit être inférieur à 10

dans chaque sous-programme

• Remarque importante– Le nombre cyclomatique ne mesure que la complexité structurelle statique


APPLICATION : SÉLECTION ET DESCRIPTION DE CHEMINS

1 3

810

5 24 6

9 7

DEBUT FIN

m

i h g f

edcba

l k j

CHEMINS DÉCISIONS LIENS4 6 7 9 a b c d e f g h i j k l m

abcde OUI OUI - - - - -abhkgde NON OUI NON - - - - - - -abhlibcde NON,OUI OUI OUI - - - - - - - -abcdfjgde OUI NON,OUI OUI - - - - - - - -abcdfmibcde OUI NON,OUI NON - - - - - - - -

NON

OUIOUI

OUI OUI

NON NON

NON


INTÉRETS DES MODES DE REPRÉSENTATION

• GRAPHE DE CONTRÔLE : LE PLUS INTUITIF « ça se voit » !

• MODES DE REPRÉSENTATION PLUS ABSTRAITS :– Expressions régulières:

• correspondance directe GC ER

– Automates

» Machines logiques à mémoire VOLONTAIREMENT rudimentaire• Automates à états finis

• Automates à pile(s)

• Machines de Turing

» Ont des propriétés mathématiques très intéressantes et permettent des preuves (sémantique parfaitement définie)

– Machines abstraites

» Adaptées aux problèmes à résoudre, donc moins générales que les automates

» Rendent explicites ce que le programmeur considère comme important• les événements à contrôler auxquels on va associer les instructions de la machine.

• les états mémoire dont on peut choisir la structure et la topologie.


NOMBRE CYCLOMATIQUE (1/3)

• MESURE DE COMPLEXITÉ DE Mc CABE» M = Arcs - Noeuds + 2P

– Arrière plan mathématique :• s'applique à des graphes non orientés

• chemins minimaux à partir desquels on peut engendrer tous les chemins possibles

– notion de base d'un espace vectoriel

– Exemples :

M = 7

M = 1

M = 2 M = 2


– Applications• évaluation du nombre de tests minimaux

• critère pour investigations plus poussées (révélateur d'anomalies)

– revues, inspections

– Faiblesses• les programmes sont des graphes orientés; la notion de chemin est différente .

• la mesure n'est pas fidèle.

» Exemples:• conditions multiples

• boucles

A&B&C A BA B&C C

V

F

V

F F

M = 2 M = 3 M = 4



DO WHILE

DO UNTIL

43 2

1

5

1

4

5

2,3,4

1

23

4

1

2,3,2

4

2

M = 2


1 seul test pour les 2 chemins

2 tests pour les 2 chemins


NOMBRE CYCLOMATIQUE ET EFFORT DE TEST

Début

Bloc N°1

Bloc N°2

Bloc N°3

Bloc N°4

Bloc N°5

Fin

M=1 Début

Bloc N°1 Bloc N°2 Bloc N°3 Bloc N°4 Bloc N°5

Fin

M=5

Bien que les nombres cyclomatiques soient très différents, l’effort de test est quasiment le même !!!


COUVERTURES

• DÉTERMINENT LES DIFFÉRENTES FAÇONS DE PARCOURIR LE GRAPHE DE CONTROLE

– TOUS LES NOEUDS: C0

– TOUS LES ARCS: C1

– TOUS LES CHEMINS: C

• FACILITÉ DE MISE EN OEUVRE– C0 et C1 très faciles

– C très difficile

• RENDEMENT– C1 EXCELLENT, EN PARTICULIER ASSOCIÉE AVEC PROGRAMMATION

STRUCTURÉE


LIMITATIONS DES GRAPHES DE CONTROLE

• LA SIMPLIFICATION DU MODELE CONDUIT A NE PAS OU A MAL REPRÉSENTER LES ÉLÉMENTS SUIVANTS :

» le détail des expressions booléennes

» l'itération simple

» les assignations et la dépendance fonctionnelle des variables

» les déclarations de données, la portée des variables

» la segmentation des données et du code (packaging en mémoire virtuelle pour bénéficier des effets « cluster » grâce aux caches)

» les appels de fonctions et de procédures

» les ordres d'entrées sorties et d’une façon générale les appels système

» les macros et/ou l’héritage de code

» les exceptions et les interruptions ; la synchronisation (i.e. programmes réactifs)

TOUS CES ÉLÉMENTS JOUENT UN ROLE TRES IMPORTANT

ET SONT SOURCE DE NOMBREUSES ERREURS


DÉFAUTS SÉMANTIQUES POTENTIELLEMENT INDÉCELABLES PAR COUVERTURE SIMPLE (1/2)

Exemple :Valeurs initiales a=0 ; b=0 a=0 ; b=1 a=1 ; b=0 a=1 ; b=1 a=1 ; b=2

(a+b)(a+1) 0 1 2 4 6

Programmes faux

N°1 (a-b)(a+1) 0 -1 2 0 -2N°2 (a+1)(a+1) -1 -1 0 0 0N°3 (b+b)(a+1) 0 2 0 4 8N°4 (a+b)+(a+1) 0 2 3 4 5N°5 (a+b)(a-1) 0 -1 0 0 0

Résultats corrects maisprogramme faux

4 0 1 2 0

Il faut passer plusieurs fois dans la même branche avec des valeurs différentes pour détecter l’erreur


DÉFAUTS SÉMANTIQUES POTENTIELLEMENT INDÉCELABLES PAR COUVERTURE SIMPLE (2/2)

Erreur décelable par ajout de redondance

Calcul de l’expression

Calcul d’une expression sémantiquement

équivalente(test en ligne)

Comparaison des résultats

Vrai Faux

Auto diagnostique

Par exemple : a2 + a×b + a + b a× (a + b + 1) + b


Annexe et complément sur la programmation en vue des tests :

STRUCTURE ET ORGANISATION DES PROGRAMMES EN VUE DES TESTS


MODÈLE DE COMPOSANT

Pré

-con

diti

ons

Pos

t-co

ndit

ions

Code fonctionnel nominal

Exceptions et/ou défaillances programmées

et/ou inopinées

Autocontrôles

DE DS


Événements entrants Événements sortants

Composante transformationnelle

Composante réactive

PA

RT

IE V

ISIB

LE

PA

RT

IE C

AC

HÉ

E


Caractéristiques et classes de programmes

Séquentiel Concurrent

Asynchrone(Rendez-vous)

T TR

Synchrone(Temps vrai,respect de priorités)

T (tempscontraint)

R

T (temps + RDVcontraints)

R

• T = Transformationnel ; R = Réactif


PROGRAMMES TRANSFORMATIONNELS (1/3)

• Pour le programmeur, tout se passe comme si le programme dispose instantanément de toutes les ressources système nécessaires à son exécution

– Toute ressource nommée dans le programme est considérée comme acquise– Le programme est très proche de l’idéal déterministe

• La plupart des mécanismes système lui sont cachés par le système d’exploitation

– La sémantique de la transformation ne dépend pas de ces mécanismes (propriété d’idempotence)

– La « sphère de contrôle » du programme est strictement incluse dans celle du système d’exploitation de la machine

• Le programme est une abstraction logique intemporelle sur lequel on peut raisonner de façon sûre avec toutes les ressources de la logique mathématique



PROGRAMME PMémoire

vuepar P

Zone Tampon (interface avec le SE)

Contenu de la zone tampon :• Buffer pool pour fichiers et/ou bases de données,• Mémoire virtuelle,• Files d'attente de messages télécoms vus comme des fichiers,etc.

Le programme est généralement mono processus et ne s'exécute que sur un seul processeur à la fois. Il n'a aucune relation directe avec l'extérieur. Il est assimilable à une suite d’instructions ininterruptibles.Il faut parfaitement connaître les interfacesavec le système d'exploitation.

Appels directs aux fonctions du SE

Recueille et traite tous les événements et les interactions avec l'extérieur (sous contrôle du SE)

RESSOURCES(gérées par le SE)

SYSTEME D'EXPLOITATION



Mémoire non persistante statique

Mémoire non persistante dynamique

Mémoire persistante

Algorithmes de la transformation

Données de la transformation

SPHÈRE DE CONTRÔLE DU PROGRAMME

SP

HÈ

RE

DE

CO

NT

RÔ

LE

DU

S

YS

TÈ

ME

D’E

XP

LO

ITA

TIO

N

Via SGF et/ou SGBD


PROGRAMMES RÉACTIFS (1/4)

• Pour le programmeur, tout se passe comme si le programme doit lui-même gérer les ressources système nécessaires à son exécution

– Toute ressource utilisée par le programme doit être acquise (statiquement ou dynamiquement) conformément au protocole d’acquisition propre de la ressource

– Le programme est très éloigné de l’idéal déterministe

• La plupart des mécanismes système sont visibles par le programme lui-même

– La sémantique de la transformation peut dépendre de ces mécanismes – La « sphère de contrôle » du programme déborde celle du système d’exploitation de la

machine

• Chaque instance (i.e. exécution) du programme est susceptible d’une histoire particulière qui dépend aléatoirement des événements qui l’engendrent ; on ne peut plus raisonner de façon sûre avec les seules ressources de la logique mathématique (i.e. nouvelle logique temporelle)



• MODÈLE ASYNCHRONE : PARTAGE DE RESSOURCES + CONCURRENCE POUR LES RESSOURCES EXCLUSIVES

» MODÈLE CLIENT-SERVEUR ET PROTOCOLES DE COMMUNICATIONS

» LE MODÈLE LE PLUS RÉPANDU EST CELUI DE LA PROGRAMMATION TRANSACTIONNELLE (en COBOL dès les années 70)

• LE PROGRAMME SE PARTAGE PLUSIEURS PROCESSEURS

• IL Y A CONCURRENCE SUR LES DONNÉES (accès aux bases de données)

• LES RESSOURCES AFFECTÉES AU PROGRAMME SONT BANALISÉES

• MODÈLE SYNCHRONE : TEMPS RÉEL» LE TEMPS VRAI EST UN PARAMÈTRE FONDAMENTAL

• INTERRUPTIONS ET PRIORITÉS

• RESSOURCES DEDIÉES (y compris les processeurs)

• MODÈLES MIXTES» SYSTÈMES C3I

• COHABITATION D ’INTERACTIONS DE TYPE CONVERSATIONNEL - temps « réfléchi » où l’attente est possible - ET DE TYPE RÉFLEXE où la réponse doit être immédiate

» SYSTÈMES HYBRIDES• COHABITATION ÉQUIPEMENTS ANALOGIQUES - fonctionnant en continu - ET ORDINATEURS (le tout fonctionnant en boucles fermées)


M1,3M1,2

M1,1Tâche T3


Le programme est multitâches qui peuvent s'exécuter sur plusieurs processeurs et gérer plusieurs contextes.Il est en permanence en relation directe avec l'extérieur. L’exécution des instructions peut être interrompue à tout moment phénomène d ’entrelacement (interleaving).Il faut parfaitement connaître le fonctionnement des moniteurs qui notifient les événements aux différentes tâches.

M1,3M1,2

M1,1Tâche T2

M1,3M1,2

M1,1Tâche T1

Zone de communication entre tâches

RESSOURCES(gérées par le SE)

SYSTEME D'EXPLOITATION

Différents moniteurs

Dispatching des événements selon les moniteurs

Contenu de la zone de communications :• Files d’attentes de messages à dispatcher,• Tables de verrouillage de ressources,• Sémaphores de synchronisation, etc.

Ordonnancement des taches selon

les priorités et les contraintes temporelles

La cohérence entre le système d'exploitation et les moniteurs doit être soigneusement validée et vérifiée.



• Conséquences de l’entrelacement sur le flot des instructions» Contrôle rigoureux des règles de partage des données (en particulier pour les mises à jour et les lectures « sales »)» Contrôle rigoureux des règles de rupture de séquence (section critique, propriétés ACID des transactions)

Séquence quelconque d’instructions des autres tâches, des moniteurs, du système d ’exploitation

Flot de la tâche T1

Durée t quelconque

•••

•••

Potentialité de générer très facilement des états incohérent du programme qui provoqueront des défaillances très difficiles, voire impossibles, à reproduire !!!


TEST DE PROGRAMMES RÉACTIFS

Exemple de la gestion de ressources logicielles


Principes

• Expliciter aussi précisément que possible la sphère de contrôle du programme et/ou du système à tester

– Faire un modèle de l’environnement dans lequel opère le programme– Faire l’inventaire des événements qui doivent remonter sur le programme

• Tester d’abord les composantes transformationnelles du programme– Couverture 100%

• Mettre en place, à demeure dans le programme, un jeu de traces que l’on peut activer ou débrayer dynamiquement, y compris in situ

– Identifier exhaustivement toutes les variables partagées, les points de synchronisation, les sections critiques, les ressources partagées, etc.

– Journalisation des événements sur des mémoires circulaires stables (pour éviter la perte d’information)

– Relaxation progressive de la granularité en fonction de l’évolution de la courbe de maturité jusqu’à obtention du grain nominal


Ressource logicielle (1/4)

Ce qui permet à une fonction logicielle de s’exécuter• Exp : Mémoire, fichiers, DB, appareil, ligne télecom, 1 ou n processus, une donnée, etc.

• L’acquisition d’une ressource résulte toujours d’une demande– Explicite sous contrôle du/des programmeur(s)

• Ouverture d’un fichier, allocation d’une zone mémoire, etc.

– Implicite à partir de l’information des programmes• Par le compilateur, l’éditeur de liens, le système d’exploitation, le moniteur de contrôle, etc.



• Etat d’une ressource– Disponible

» Libre / Attribuée (à 1 ou n, i.e. partagée)– Indisponible

» Temporairement (saturation, attente, etc.)» Définitivement (types de pannes)

– Réparable / Non réparable

Mot d’état associé à la ressource» Visibilité du mot d’état : Broadcast / Polling



• La prise en compte de la demande par l’environnement peut être faite

– A la compilation et/ou édition de liens

Construction déterministe– Au démarrage de l’application lors du chargement– Dynamiquement, au dernier moment

Construction non déterministe (d’où contrôle de charge)» Cas fréquent en programmation objet

• L’exécution de la demande peut être synchrone ou asynchrone

Priorité, durée, etc.



• Types de ressources» Banalisée / homogène : une zone mémoire, une tâche, un fichier

temporaire, etc. Possibilité d’épuisement ; ressources centralisées

» Spécifique / hétérogène : un fichier particulier, une donnée (i.e. données « essentielles »), un processus système, etc.

Possibilité de conflit avec une autre demande ; ressources distribuées

» Composite (toute combinaison autorisée)

» Persistante : la demande survit à la fin logique du processus/programme : i.e. rangement dans un cache.

• Régulière : restituée automatiquement à l’environnement à la terminaison du programme (i.e. critère LRU)

• Irrégulière : restituée si notification explicite (i.e. time out)


Pipeline de ressources (1/3)

• Notion de pipeline• Pipeline permettant le chargement anticipé d’instructions et de données avant leur emploi

réel (Localité + régularités statistiques)

Mécanisme fondamental (mais très délicat) des UC modernes qui évite de synchroniser la machine sur les organes les plus lents (le bus, E/S, etc.)

• Anticipation des demandes de ressources• la ressource est disponible au moment de son utilisation effective

• Relaxation progressive en fin de demande• la fin logique d’une demande de ressource ne coïncide pas nécessairement avec la

restitution physique des ressources



Espace d'adresse d'une application particulière A

Espace système contenant toutes les ressources accessibles depuis A

Zone de communication permettant d'échanger des informations

Espace machine global contenant toutes les entités adressables, y compris le système d'exploitation et tous ses sous-systèmes.La construction de cet espace est faite par le « Boot » du système d'exploitation qui à son tour créera tous les autres espaces nécessaires aux applications.



TFin

Fin de l'exécution de l'application A, du point de vue du programmeur

•••

Séquences d'ordres explicites relâchant certaines ressources temporairement utilisées par A Durée d'exécution TE

Programme système d'analyse des résidus de la terminaison

•••

Séquences d'ordres complémentaires implicites relâchant le reliquat de ressources non encore libérées Durée d'exécution TI

Application A

Exemple de terminaison d’une application


Ingénierie de l’architecture

• L’architecture doit identifier :– Le code fonctionnel basique,– Le code fonctionnel dur– Le code non fonctionnel

• Facilités d ’emploi, Fiabilité, Performance, Maintenabilité, Portabilité

– La structure de contrôle la plus appropriée à la logique d ’enchaînement– Le jeu d’interfaces qui minimise le volume du code– La taille maximum des composants critiques pour la survie de l’application

Concept d’architecture testable et maintenable


Dilemme de l’architecte

• Pour réduire le coût à risque constant, la performance doit être réduite

• Pour réduire le risque à coût constant, la performance doit être réduite

• Pour réduire le coût à performance constante, un niveau de risque plus élevé doit être accepté

• Pour réduire le risque à performance constante, un coût plus élevé doit être accepté

Cf. Vade-mecum du chef de projet

Date post:	14-Jan-2016
Category:	Documents
Upload:	tadhg
View:	47 times
Download:	0 times

VALIDATION VERIFICATION TESTS

Documents