Lezione 7,8

Corso di Laurea Magistrale
in
Ingegneria Informatica
per la Gestione d’azienda
Gestione della Qualità-II parte
La produzione del software: metodologie e
standards
a.a. 20102010-2011
Docente: Gigliola Vaglini
1
Lezione 7,8
Software
Verification&Validation
2
1
Verification&Validation
 Verification:
– Are we building the software
right?
 Validation:
– Are we building the right
software?
3
Alcune domande
1.
2.
3.
4.
Quando cominciare V&V
Quando finire
Quali tecniche usare
In che modo giudicare quando il prodotto
è pronto per il mercato
4
2
1e2
 V&V comincia appena si decide di
cominciare a realizzare un prodotto
software
 V&V dura oltre la consegna e finchè il
software è in uso
5
3
 Non c’è una risposta fissata
 I progettisti devono scegliere il giusto
amalgama di tecniche che garantisca
– Il livello di qualità aspettato
– Il costo aspettato
6
3
4
 Deve essere specificato il livello di
“dependability” (rispondenza alle
necessità) che il software deve
raggiungere
 Il progettista deve essere in grado di
determinare quando questo livello è
raggiunto
7
Differenti misure di dependability
 Availability (disponibilità): misura il QoS in
termini di rapporto tra il tempo di
funzionamento e il tempo in cui il sistema è giù
 Reliability (affidabilità): si misura in termini
della frazione delle operazioni terminate con
successo rispetto a tutte quelle tentate
 Il QoS si può misurare anche in termini del
tempo che passa tra due fallimenti successivi
8
4
Verification theory: definitions
 Failure: observable event that the user
see as anomalous
 Fault: the cause of a failure
 Error: it has two meanings
– A difference between the computed and the
expected result
– An action (generally of a person) that causes
a fault
9
Verification theory
 P : D  R.
 P(d) is a correct result if it satisfies
the program specification, i.e.
ok(P,d)=true
 P is correct (written ok(P)) if
ok(P,d)=true for each dD
10
5
What kind of techniques
 Testing: dynamic technique
– The behavior of the product is experimented
– We are looking for counterexamples
 Analysis: static thecnique
– Properties are proved
11
Dynamic verification
12
6
Testing
 Testing is the observation of a sample of
program executions. Sample selection can be
guided by different objectives. In testing for
defect identification, a successful test is one
which causes the system to fail. This is quite
different from testing to demonstrate that the
software meets its specifications.
 Software testing is intimately related to
software construction, if not part of it, and
also to software requirements specification.
13
La verifica nell’ingegneria
tradizionale
 Quando si progettano ponti un test
assicura infinite situazioni corrette
 Se un ponte può sopportare un carico di
10000 tonnellate, può sopportare
qualunque carico di peso inferiore
14
7
La verifica in SE
 I programmi non hanno un comportamento
continuo
 Verificare una funzione in un punto non
dice niente su tutti gli altri punti
– A=…/(x+20)
– Ogni valore di x è corretto eccetto x=-20
15
Tesi di Dijkstra
 Program testing can be used to show the
presence of bugs, but never to show their
absence (Dijkstra’s thesis 1972)
 Non vi è garanzia che, se alla n-esima prova, un
modulo od un sistema ha risposto correttamente
(ovvero non sono stati più riscontrati difetti),
altrettanto possa fare alla (n+1)-esima
 Impossibile produrre tutte le possibili
configurazioni di valori di input (test case) in
corrispondenza di tutti i possibili stati interni di
un sistema software
16
8
Impatto di nuove tecnologie
 Tecniche di sviluppo più avanzate possono
ridurre la frequenza di alcuni tipi di
errori, ma non eliminano del tutto gli
errori
 Nuovi approcci introducono nuovi tipi di
errori: ad esempio il deadlock per i
programmi concorrenti.
17
18
9
Come trattare i risultati
dell’analisi
 Ottimistica inaccuratezza
– Si possono accettare programmi che non rispettano
alcune proprietà: testing
 Pessimistica inaccuratezza
– Si possono non accettare programmi che possiedono
le proprietà volute: tecniche di analisi automatica,
theorem proving
 Proprietà semplificate
– Si riduce il grado di libertà per semplificare le
proprietà da verificare: model checking
19
Proprietà dei risultati dell’analisi
 Safety: non c’è inaccuratezza ottimistica,
si accettano solo programmi corretti
 Soundness: si accettano programmi solo
quando hanno una certa proprietà
 Completeness: si accetta ogni programma
che ha una certa proprietà
20
10
The oracle
 An oracle is any (human or mechanical)
agent which decides whether a program
behaves correctly in a given test, and
accordingly produces a verdict of “pass”
or “fail.”
 There exist many different kinds of
oracles, and oracle automation can be
very difficult and expensive.
21
Come derivare un buon oracolo
 Nella fase della specifica dei requisiti
– Rendere le proprietà verificabili
 Gli oracoli di sistema vanno progettati durante il
progetto del sistema. Ad es. in un progetto
UML
– Una message sequence chart indica un caso di test e
un’uscita attesa
– Una statechart è una macchina a stati finiti che
descrive tutti i comportamenti ammissibili
22
11
Esempio
 Trovare un oracolo per un programma che
deve trovare il cammino più corto tra le
città A e B; le distanze tra le varie città
sono rappresentate da un grafo con archi
etichettati con la distanza
 Input: (A,B,d): d rappresenta la minima
distanza tra A e B
 Output: (A,X1,d0)(X1,X2,d1)…..(Xn,B,dn)
23
Possibile soluzione
 Si divide la proprietà in due parti
– Verifica che la sequenza di (X,Y,d) sia
connessa: i.e. ogni (X,Y,d) esiste in input e non
ci sono buchi nel cammino
– Verifica che la sequenza sia minima: si
controlla che il cammino costruito non sia più
lungo della distanza minima (l’oracolo la
genera)
24
12
Testing levels
25
Unit testing
 One module is tested in isolation
 We are looking for logical errors
 It is performed directly by the
module programmer
26
13
Integration testing
 For testing A before
B,C and D are built,
their behavior must
be simulated through
components with the
same interface, called
stubs.
 For testing B,C and D
without A, the calling
environment must be
simulated through
components called
27
drivers.
Big bang o integrazione
incrementale
 Si parla di test di integrazione big bang quando tutti i
moduli (già testati separatamente) sono integrati in un
sol colpo
 Si parla di test di integrazione incrementale quando i
moduli sono integrati via via che vengono prodotti e
testati singolarmente.
– Eventuali anomalie nelle interfacce possono essere rilevate ed
eliminate durante lo sviluppo, e non si propagano sul prodotto
finale
– E’ più facile localizzare (e quindi rimuovere) eventuali anomalie
– Il test incrementale esercita più a lungo ciascun modulo
28
14
System testing
 È applicato sul sistema software completo
ed integrato
 L'obiettivo e' valutare l'adesione del ai
requisiti specificati
 Lo esegue il team addetto al testing
(esterno al gruppo di sviluppo)
29
System testing
 Testing with respect to
– Functional requirements
– Non functional requirements
 System requirements are also
Performance, Reliability, Maintainability,
Usability...
30
15
Test di sistema per…
 Configurazione: tutti i comandi per
scambiare/cambiare le relazioni fisiche
logiche dei componenti HW
 Recovery: capacità di reazione del sistema
a cadute
 Stress: affidabilità in condizione di carico
limite
 Sicurezza: invulnerabilità del sistema
rispetto ad accessi non autorizzati
31
Alpha and beta testing
 Before the software is released, it is
sometimes given to a small,
representative set of potential users for
trial use, either in-house (alpha testing)
or external (beta testing).
32
16
Acceptance testing
 Acceptance testing checks the system
behavior against the customer’s
requirements; the customers undertake,
or specify, typical tasks to check that
their requirements have been met. This
testing activity may or may not involve
the developers of the system.
33
Regression testing
 Regression testing is the “selective
retesting of a system or component to
verify that modifications have not caused
unintended effects...”
 In practice, the idea is to show that
software which previously passed the
tests still does.
 This kind of testing is easy to automatize:
the new program is executed with the old
test data and the results are compared
34
against the old ones stored in a data base.
17
Testing theory
35
Testing theory
 Given a test T (T is a subset of D), T
is successful for P if ok(P,T),
otherwise it is called inadequate.
 T is called ideal if ok(P,T)  ok(P)
 One goal of the testing theory is the
definition of methods to choice tests
that approximate the ideal tests.
36
18
Test selection criteria
 A test selection criterium C for a
program P is a set of predicates on D.
 Test T is chosen through criterium C if it
satisfies C.
– C = {<x1, x2,..., xn> | n ≥ 3 
 i, j, k, ( xi<0  xj=0  xk>0)}
– <-5, 0, 22> and <-10, 2, 8, 33, 0, -19> satisfy C
– <1, 3, 99> does not satisfiy C
37
Raffinamento dei test
 Un criterio C1 è più fine di un altro C2
se, per ogni programma P, per ogni test
T1 che soddisfa C1 ne esiste un
sottoinsieme T2 che soddisfa C2.
38
19
Test selection criteria properties
 C is consistent for P, if, for each pair
of tests T1 and T2 chosen by C,
ok(P,T1)  ok(P,T2)
• C is complete for P if it exists at least
a test T such that ok(P,T1) whenever
ok(P)
 A consistent and complete selection
criterium chooses ideal tests.
39
Teorema di Goodenough e Gerhart
 Il fallimento di un test T per un programma P
selezionato da un criterio C consistente e
completo permette di dedurre la correttezza
del programma P, cioè:
– consistente(C,P) completo(C,P)  selezionato(C,T) 
¬ successo(T,P)  ok(P)
 La consistenza del criterio C garantisce lo
stesso risultato (in termini di rilevamento dei
malfunzionamenti) per tutti i test selezionati.
 La completezza di C garantisce che, se P non è
corretto, non lo è neppure per uno dei test
selezionati da C
40
20
Particular test selection
criteria
 A selection criterium C that includes all
elements of D is complete but not
consistent. Proof?
 A selection criterium C that is satisfied
by no element of D is consistent but not
complete.
 A selection criterium C satisfied by a
test T=D is consistent and complete
(exhaustive test)
41
Proof
 If a failure exists, it will occurr for a
input datum d; C chooses at least a test T
containing d and thus T will cause the
failure.
 On the other hand, not each test T
satisfying C contains d.
42
21
Howden’s theorem
 No algorithm exists for any P able to
define a finite ideal test (no consistent
and complete selection criterium
exists).
43
Howden’s theorem
 Non si dice che il criterio consistente e
completo non esiste (basta prendere il
criterio che seleziona tutti e soli i dati
che causano un malfunzionamento), dice
solo che non è effettivo (non può essere
tradotto in un algoritmo in grado di
produrre il risultato in un tempo finito)
 Il teorema di HOWDEN corrisponde alla
tesi di Dijkstra
44
22
Indecidable problems
 Indecidable problems are greatly
influencing testing
 A problem is indecidable if it is possible
to prove that no algorithm exists
solving it
45
Problemi di decisione
46
23
Linguaggi computazionalmente
completi
 Un linguaggio di programmazione si dice
computazionalmente completo se vi si
possono definire tutte le funzioni
ricorsive oppure tutte le funzioni
calcolabili da una Macchina di Turing
47
Tesi di Church-Turing (1936)
 Ogni algoritmo che può essere eseguito da
un umano o da un computer può essere
eseguito da una macchina di Turing
 Per dimostrare che una funzione è
calcolabile (la funzione caratteristica di
un insieme, ad esempio), basta scrivere un
algoritmo che la calcoli: la tesi di ChurchTuring ci assicura che può essere eseguito
da una macchina di Turing
48
24
 Un problema è indecidibile se è possibile
dimostrare che non esiste una macchina
di Turing che risolve il problema
 Es. stabilire se l'esecuzione di un
programma termina a fronte di un input
arbitrario e' un problema indecidibile
49
Problema della terminazione
50
25
51
Indecidable problems
 It is not possible to decide whether two
programs compute the same function or not
 Consequence
– Given a program C known correct (the
specification of P?) , we cannot prove
that P is correct through the proof of
the equivalence of P and C
52
26
Equivalenza programmi e cammini
 Non esiste un algoritmo in grado di
stabilire se due generici cammini del
grafo del flusso di controllo di un
programma calcolino la stessa funzione o
meno
 Altrimenti si potrebbe dimostrare che
due programmi, ridotti a cammini,
calcolano la stessa funzione
53
Weyuker’s theorem
 For each program P the following are
undecidable problems
“at least an input datum exists that
causes the execution of instruction i or
of branch b”.
“at least an input datum exists that
causes the execution of all instructions of
P or of all branch of P”
54
27
Weyuker’s theorem
 Esiste un dato di ingresso che causa l’esecuzione di
un particolare cammino?
 Esiste un dato di ingresso che causi l’esecuzione di
ogni cammino di P?
 Questo teorema è importante per i metodi di test
che richiedono l’esecuzione di particolari elementi del
programma.
 Tuttavia, dato un problema indecidibile, è possibile
individuare sottoproblemi significativi decidibili, per i
quali è possibile formulare algoritmi in grado di
risolvere parzialmente il problema.
 Inoltre si possono sempre risolvere problemi
indecidibili in maniera creativa e non meccanica
55
Testing techniques
 The main classification is based on how tests
are generated from the software engineer’s
intuition and experience, the specifications, the
code structure, the (real or artificial) faults to
be discovered, the field usage, or, finally, the
nature of the application.
 Sometimes these techniques are classified as
white-box, if the tests rely on information
about how the software has been designed or
coded, or as black-box if the test cases rely
only on the input/output behavior.
56
28
White-box testing
Coverage criteria
 Statement coverage
 Edge coverage
 Condition coverage
 Path coverage
 Data flow (syntactic dependency)
coverage
57
Black-box testing: three steps
 Decompose the system specification in a
set of independent functions.
 Identify the relevant values: special
cases, normal cases, wrong cases..
 Constraints the possible combinations of
values
58
29
Black-box vs. white-box
59
Testing process
Planning the quality
60
30
Testing and quality
 Testing is the analysis and the
controlled execution of a program
with the aim of revealing defects.
 Testing is planning, designing,
costruction, maintenance of test and
testing environments
61
The testing process
 Testing concepts, strategies, techniques,
and measures need to be integrated into a
defined and controlled process which is
run by people. The test process supports
testing activities and provides guidance
to testing teams, from test planning to
test output evaluation, in such a way as to
provide justified assurance that the test
objectives will be met costeffectively.
62
31
 Thus the testing is a process
 This process must produce deliverables.
i.e. documents
– IEEE Standard for Software Test
Documentation (Std. 829-1998 – Revised
Std. 829-1983).
63
Std IEEE 829
 The standard defines 8 types of documents to
be used in 3 distinct phases
 Tests design
–
–
–
–
–
Test plan
Test design specification
Test case specification
Test procedure
Test item transmittal report
 Tests execution
– Test log
– Test incident report
 Tests end
– Test summary report
64
32
Test plan
 The Test plan is a document describing
the scope, approach, resources, and
schedule of intended testing activities.
It identifies test items, the features
to be tested, the testing tasks, who
will do each task, and any risks
requiring contingency planning.”
65
Test plan outline
 Test Plan Identifier
– A unique identifier
 Introduction
– Summary of the items and features to be
tested
– Need for an history of each item (optional)
– References to related documents such as
project authorization, project plan, QA
plan, configuration management plan,
relevant policies, relevant standards
– References to lower level test plans
66
33
Test plan outline (cont.)
 Test Items
– Test items and their version
– Characteristics of their transmittal media
– References to related documents such as
requirements specification, design
specification, users guide, operations
guide, installation guide
– References to bug reports related to test
items
– Items which are specifically not going to
67
be tested (optional)
Test plan outline (cont.)
 Features to be Tested
– All software features and combinations of features
to be tested
– References to testtest-design specifications associated
with each feature and combination of features
 Features Not to Be Tested
– All features and significant combinations of features
which will not be tested
– The reasons these features won’
won’t be tested
68
34
Test plan outline (cont.)
 Approach
– For each major group of features or combinations of
features,
features, specify the approach
– Specify major activities,
activities, techniques,
techniques, and tools which are to
be used to test the groups
– Specify a minimum degree of comprehensiveness required
– Identify which techniques will be used to judge
comprehensiveness
– Specify any additional completion criteria
– Specify techniques which are to be used to trace
requirements
– Identify significant constraints on testing,
testing, such as testtest-item
availability,
availability, testingtesting-resource availability,
availability, and deadline
69
Test plan outline (cont.)
 Item Pass/Fail
Pass/Fail Criteria
– Specify the criteria to be used to determine whether each
test item has passed or failed testing
– Suspension Criteria and Resumption Requirements
– Specify criteria to be used to suspend the testing activity
– Specify testing activities which must be redone when testing
is resumed
 Testing Tasks
– Identify tasks necessary to prepare for and perform testing
– Identify all task interdependencies
– Identify any special skills required
70
35
Test plan outline (cont.)
 Environmental Needs
– Specify necessary and desired properties of the test
environment:
environment: physical characteristics of the facilities including
hardware, communications and system software, the mode of
usage (i.e., standstand-alone), and any other software or supplies
needed
– Specify the level of security required
– Identify special test tools needed
– Identify any other testing needs
– Identify the source for all needs which are not currently
available
 Test Items section
– Identify groups responsible for providing the environmental
needs identified in the Environmental Needs section
71
Test plan outline (cont.)
 Test Deliverables
– Identify the deliverable documents: test
plan, test design specifications, test case
specifications, test procedure
specifications, test item transmittal
reports, test logs, test incident reports,
test summary reports
– Identify test input and output data
– Identify test tools (optional)
72
36
Test plan outline (cont.)
 Staffing and Training Needs
– Specify staffing needs by skill level
– Identify training options for providing necessary skills
 Responsibilities
– Identify groups responsible for managing,
managing, designing,
designing, preparing,
preparing,
executing,
executing, witnessing,
witnessing, checking and resolving
– Identify groups responsible for providing the test items
identified in the Test Items section
– Identify groups responsible for providing the environmental
needs identified in the Environmental Needs section
73
Test plan outline (cont.)
 Schedule
–
–
–
–
–
Specify test milestones
Specify all item transmittal events
Estimate time required to do each testing task
Schedule all testing tasks and test milestones
For each testing resource,
resource, specify its periods of use
 Risks and Contingencies
– Identify the highhigh-risk assumptions of the test plan
– Specify contingency plans for each
 Approvals
– Specify the names and titles of all persons who must
approve the plan
– Provide space for signatures and dates
74
37
Test process documents
75
Hierarchy of planning and
specification documents
76
38
Verifica e validazione
Strumenti di base: grafi
77
Grafi utilizzati







CFG(P)
Execution tree
CDG(P)
Grafi di dominanza
Grafi di dipendenza
DFD(P)
…..
78
39
Flusso del controllo
 Il codice è rappresentato tramite un
grafo, il grafo del flusso di controllo
(Control flow Graph - CFG), i cui nodi
rappresentano statement (istruzioni e/o
predicati) del programma e gli archi il
passaggio del flusso di controllo.
79
Elementi di base di un CFG
 Un grafo è costruito secondo la seguente
notazione
 Istruzioni=nodo
 Passaggio del flusso del controllo=arco
etichettato con {true, false, uncond}
80
40
Definizione di un CFG
 Dato un programma P, CFG(P)=<N, AC,
nI,nF>, dove
–
–
–
–
<N, AC> è un grafo con archi etichettati
N= { nI,nF }Ns Np
nI e nF sono il nodo iniziale e il nodo finale
Ns e Np sono insiemi disgiunti di nodi
istruzione e nodi predicato, rispettivamente
– AC (N-{nF})x(N-{nI})x{true,false,uncond}
rappresenta la relazione di flusso di controllo
81
Costruzione di un CFG
 Un CFG può essere costruito in modo
strutturato
– Si definiscono i sottografi delle varie
strutture di controllo
– Si compongono i sottografi
82
41
Strutture di controllo in un CFG
83
84
42
Alcune definizioni
85
Semplificazioni
 Un nodo ed il suo successore immediato che
hanno entrambi un solo punto d’ingresso ed un
solo punto di uscita si possono ridurre ad un solo
nodo nel grafo
 La riduzione può essere applicata n volte
(sequenze di nodi); il nodo risultante può essere
etichettato con le etichette dei nodi in esso
ridotti
 I self-loops possono essere sostituiti da un solo
nodo (loop naturale ha una sola uscita e un solo
ingresso)
86
43
87
Accompagnano i CFG
 Il CFG rappresenta la struttura del
programma
 Si possono associare ai CFG altri grafi (in
generale alberi) che rappresentano altri
aspetti, anche dinamici, legati
all’esecuzione
88
44
Esecuzioni simboliche
 In realtà i programmi vengono eseguiti in
modo simbolico (o astratto)
 Valori simbolici per le variabili si
propagano lungo i cammini di esecuzione
 Gli statement si considerano eseguibili
solo se gli input soddisfano determinate
condizioni
 Come si caratterizzano queste condizioni?
89
Path conditions
 Una Path Condition (pc), per un determinato statement,
indica le condizioni che gli input devono soddisfare
affinché un’esecuzione percorra un cammino lungo cui lo
statement sia eseguito.
 Una pc è un’espressione Booleana sugli input simbolici di
un programma; all’inizio dell’esecuzione simbolica essa
assume il valore vero (pc:= true ).
 Per ogni condizione che si incontrerà lungo l’esecuzione,
pc assumerà differenti valori a seconda dei differenti
casi relativi ai diversi cammini dell’esecuzione.
90
45
Evoluzione di una pc
91
Esempio
92
46
CFG con accompagnamento di ET
93
Execution tree
 Ogni foglia dello execution tree rappresenta
un cammino percorso per classi di valori di
input (pc associata)
 Le pc associate a due differenti foglie sono
distinte
 Non esistono esecuzioni per cui sono vere
contemporaneamente più pc (per linguaggi di
programmazione sequenziali).
 Se l’output ad ogni foglia è corretto allora il
programma è corretto.
94
47
Cammini eseguibili
 'cammino eseguibile‘ è un cammino per il
quale esiste un insieme di dati di
ingresso che soddisfa la path condition
 'cammino non eseguibile' ( 'infeasible
path') è un cammino per il quale non
esiste un insieme di dati di ingresso che
soddisfa la path condition
95
Call-Direct-Graph CDG(P)
96
48
Esempio
97
Proprietà dei nodi
 Dato un grafo, CFG o CDG o.., si possono
stabilire alcune proprietà dei nodi che
risultano interessanti dal punto di vista
del comportamento del programma
 Le proprietà valgono per grafi aciclici, ma
è sempre possibile eliminare i cicli interni
di un grafo
98
49
Relazione di dominanza
99
Dominatori
100
50
Dominatori
101
Esempio
102
51
Dominanza diretta
103
Albero delle dominanze
104
52
Albero delle dominanze per un CDG
105
Postdominanza
 Dato un grafo CFG(P) = <N, AC, nI, nF>, e
due nodi n, m  N: m postdomina n se e
solo se per ogni cammino in CFG(P) del
tipo n=p0, p1,..., pk=nF, m{p1,..., pk}
 La relazione di postdominanza è transitiva
e non riflessiva
106
53
Postdominatori
107
Postdominatori
108
54
Esempio
109
Postdominanza diretta
110
55
Albero delle postdominanze
111
Dipendenze sul controllo
 Dato CFG(P) = <N, AC, nI, nF>, e due
nodi x, yN, y si dice dipendente sul
controllo da x se e solo se:
– esiste un cammino x=p0, p1,..., pk=y tale
che i,
1 ≤ i ≤ k-1, pi è postdominato da y;
– x non è postdominato da y.
112
56
In pratica
113
Dipendenze unitarie sul controllo
114
57
In pratica
115
Esempio
116
58
CD Graph
 Le dipendenze sul controllo possono
essere espresse mediante apposito
grafo.
 Ogni arco del grafo è etichettato con
vero, falso o incond indicando una
dipendenza sul controllo per valore di un
predicato uguale a vero o falso, oppure
per ogni valore, rispettivamente.
117
Regioni
 Affinchè ogni nodo predicato abbia al più due
archi uscenti (l’uno etichettato con vero e
l’altro con falso), ulteriori nodi, chiamati nodi
regione, vengono inseriti nel grafo.
 I nodi regione riassumono l’insieme delle
dipendenze sul controllo per ogni predicato.
 Gli archi uscenti da un nodo regione sono
etichettati con incond.
118
59
CD Graph
119
Esempio
120
60
Proprietà
121
DF Graph
 Al grafo del controllo viene associata una
relazione che descrive il flusso dei dati e che
rappresentata l’evoluzione del valore delle
variabili in base alle operazioni eseguite sulla
variabile stessa in ogni istruzione:
– definizione: alla variabile è assegnato un valore
– uso: il valore della variabile è usato in un’espressione
o un predicato
– annullamento: al termine di un’istruzione il valore
associato alla variabile non è più significativo
 Es. nell’espressione a:=b+c la variabile a è
definita mentre b e c sono usate
122
61
Esempio
123
Relazione DEF_USO
124
62
Variabili live
 Definizione: la variabile x è live al nodo v
se esiste un cammino nel CFG da v a n tale
che x non è ridefinito in tale cammino, e n
usa x.
 Proprietà: la relazione lvx non è riflessiva
né transitiva.
125
Esempio
126
63