Corso di Laurea Triennale in Ingegneria Informatica
Ingegneria del software
Metodi formali nell’ingegneria del software
Guasti software
Sistemi critici
Metodi formali
Verifica formale
Model checking
Ingegneria del
software
I guasti software
Classificazione dei guasti:
• Natura dei guasti:
– Accidentali: che si verificano fortuitamente
– Intenzionali: creati con scopi malevoli
• Origine dei guasti:
– Cause fenomenologiche:
• Guasti fisici: dovuti a fenomeni fisici
• Guasti causati dall’uomo
– Confini del sistema:
• Guasti interni: parti del sistema che producono errori
• Guasti esterni: causati dall’interferenza dell’ambiente fisico nel sistema o
dall’interazione con l’uomo
– Fase di creazione:
• Guasti di progetto
• Guasti operativi
– Persistenza temporale:
• Guasti permanenti
• Guasti temporanei
Ingegneria del
software
Errori
• Catena
– Guasto->errore->fallimento
• Ogni sistema è inteso in maniera ricorsiva come
strutturato in componenti, fino al livello dei componenti
atomici non ulteriormente scomponibili
– Un guasto di un componente nel sistema, se non gestito
opportunamente può determinare uno stato erroneo detto
errore.
– Errore: è uno scostamento del sistema dallo stato nominale, ed
è l’effetto di un guasto, non è il guasto.
– Fallimento: si verifica se lo stato di errore non viene gestito,
rappresenta la deviazione del comportamento del sistema
rispetto a quello atteso secondo le specifiche.
Ingegneria del
software
Classificazione dei fallimenti
• Il fallimento di un sistema avviene quando un errore si
manifesta come deviazione dal servizio offerto.
– Vi sono diversi failure modes, che possono essere caratterizzati
secondo tre punti di vista:
• il dominio
• la percezione del fallimento da parte degli utenti del sistema
• le conseguenze sull’ambiente
– Consideriamo di seguito la classificazione relativa soltanto alle
conseguenze del fallimento sull’ambiente, ossia alla gravità:
• Fallimenti benigni:
– le conseguenze sono dello stesso ordine di grandezza del beneficio dato
dal servizio erogato in assenza di fallimento
• Fallimenti catastrofici:
– le conseguenze sono incommensurabilmente più grandi dei benefici
prodotti dal servizio in assenza di fallimento
Ingegneria del
software
Fallimenti benigni
• Le conseguenze sono dello stesso ordine di grandezza
del beneficio dato dal servizio erogato in assenza di
fallimento:
– Il costo del fallimento si limita alla perdita economica dovuta alla
mancanza del servizio stesso:
• Es. se un aereo non può partire per un guasto, i viaggiatori non
possono raggiungere velocemente la destinazione.
– Sistemi fail-safe: sistemi i cui fallimenti possono essere solo
benigni
Ingegneria del
software
Fallimenti catastrofici
• Le conseguenze sono incommensurabilmente più grandi
dei benefici prodotti dal servizio in assenza di fallimento:
– Es. se il guasto all’ aereo provoca un incidente, le conseguenze
sono ovviamente diverse e meno desiderabili rispetto al in
relazione alla gravità dei possibili fallimenti si identifica la criticità
di un sistema:
– Se il fallimento di un sistema ha la potenzialità di essere
catastrofico si parla di sistema critico, altrimenti si parla di
sistema non critico.
Ingegneria del
software
Classificazione dei sistemi critici
• A seconda della categoria degli effetti dei fallimenti i
sistemi critici possono essere classificati in:
• Sistemi safety-critical:
– Sistemi il cui fallimento può causare ferimenti, perdite di vite o
seri danni ambientali( sistemi di controllo di impianti chimici,
centrali nucleari, sistemi fly-by-wire, o sistemi drive-by-wire)
• Sistemi mission-critical:
– Sistemi il cui fallimento può causare la cancellazione di attività
mirate ad un obiettivo importante (sistema di navigazione di una
sonda spaziale)
• Sistemi business-critical:
– Sistemi il cui fallimento può causare ingenti perdite di denaro
(sistema di gestione dei conti correnti di una banca)
Ingegneria del
software
Dependability
• Definizione:
– la proprietà di un sistema di essere adeguato a che un essere
umano, o una collettività, possa dipendere da esso, senza
correre rischi inaccettabili [indicare i riferimenti bibliografici]
– Un termine utilizzato spesso con la stessa accezione è affidabilità
(reliability)
– Caratterizzazione della dependability:
• La credibilità di un sistema di calcolo, ossia il grado di fiducia che
può essere ragionevolmente riposto nei servizi che il sistema offre.
Ingegneria del
software
Attributi della dependability
• I servizi offerti da un sistema di calcolo sono
rappresentati dal suo comportamento così come viene
percepito dagli utenti:
– A seconda dei servizi che il sistema deve fornire, la garanzia di
funzionamento può essere interpretata in relazione a proprietà
distinte, ma complementari:
• Availability: disponibilità - se l’aspettativa principale sul servizio è
data dalla sua prontezza di risposta
• Reliability: affidabilità – se l’aspettativa riguarda la fornitura
continua del servizio per un tempo sufficientemente lungo,
• Safety: sicurezza – se l’aspettativa principale è la garanzia di evitare
situazioni catastrofiche e danni all’ambiente o alle persone
• Security: sicurezza - se l’aspettativa è la prevenzione di accessi non
autorizzati e/o manipolazioni di informazioni private
Ingegneria del
software
Altri aspetti della dependability
• Pervasività: il principale aspetto da studiare a proposito
di dependability è la pervasività e l’inevitabilità della
presenza di guasti:
– La presenza di guasti rende necessaria la possibilità di riparare i
guasti
• Maintainability: la capacità di un sistema dependable di
essere riparato in tempi e con costi prevedibili:
– La manutenzione è l’attività di rimozione dei guasti durante il
funzionamento o comunque nella vita operativa di un sistema
Ingegneria del
software
Attributi di dependability dei sistemi
embedded
• Si tratta di sistemi chiusi in cui attributi fondamentali
sono:
–
–
–
–
Reliability
Availability
Maintainability
Safety
• Nei sistemi aperti (che comunicano cioè con altri sistemi)
attributo fondamentali è la safety intesa come protezione
dai guasti intenzionali e security intesa come protezione
dei dati relativamente alla facile diffusione su nternet
Ingegneria del
software
Metodi per ottenere dependability
• Protezione dai guasti (fault prevention): tecniche mirate a prevenire
e minimizzare le occorrenze di guasti:
– Comprende l’uso di tecniche di progettazione e ingegnerizzazione adeguate
allo scopo:
• Es. tecniche di ingegneria del software per minimizzare la presenza di bugs nel
codice
• Tolleranza ai guasti (fault tolerance): la possibilità di guasti in un
sistema può permanere nonostante l’adozione di tecniche di
progettazione:
– Si tratta di tecniche che si occupano di garantire un servizio che si
mantenga conforme alla specifiche nonostante i guasti
• Eliminazione dei guasti (fault removal): debugging, svolto o durante
la fase di sviluppo del software o successivamente al rilascio
(manutenzione correttiva)
• Predizione di guasti (fault forecasting): consiste nello stimare il
numero, la frequenza e la probabilità di incidenza presente e futura,
e nel prevedere le possibili conseguenze
Ingegneria del
software
Guasti software
• Un guasto software (bug) è un guasto interno, umano,
di progetto, in genere non intenzionale.
Ingegneria del
software
Dependability del software
• Software fault tolerance: tolleranza ai guasti del software
• Software fault forecasting: software reliability
• Software fault avoidance: tecniche di ingegneria del
software e di buona programmazione (già note); inoltre
vi sono tecniche di metodi formali di sviluppo del
software, che permettono di evitare l’introduzione di
guasti nel software
• Software fault removal: rimozione dei guasti software debugging
Ingegneria del
software
Il caso Ariane 5
•
4 giugno 1996, il primo lancio del vettore spaziale Ariane 5 risultò un fallimento:
•
In termini della catena: guasto-errore-fallimento
–
–
–
–
–
–
–
Dopo 36 secondi dall’inizio della sequenza di volo il razzo deviò dalla rotta ed il vettore
espose con una perdita stimata di oltre 500 milioni di dollari, ma nessun danno a persone o
cose
Missile esploso per la procedura di autodistruzione
Decisione errata presa dai computer di bordo dovuta ad un messaggio proveniente dalle
piattaforme inerziali
Le due piattaforme avevano subito uno shutdown a causa di una eccezione Ada Operand
Error non trattata
L’eccezione era stata sollevata durante la conversione di dati da floating point a 64 bit a
signed integer a 16 bit poiché il numero da convertire ( il valore dell’accelerazione laterale)
aveva un valore superiore a quello rappresentabile con un signed integer 16 bit
Le piattaforme inerziali erano state ereditate dall’Ariane 4 in cui il software funzionava
poiché non si raggiungevano tali accelerazioni laterali
• Il software era stato riusato ma in condizioni non analoghe a quelle per cui era stato
collaudato
La funzione in cui veniva utilizzata la conversione era necessaria sull’Ariane 4 ma inutile
nell’Ariane 5, non eliminata per non modificare il codice già collaudato
Ingegneria del
software
Cause dell’incidente
• Incapacità del software di bordo di distinguere il
messaggio di shutdown delle piattaforme inerziali
• Omissione di controllo a run-time delle eccezioni
• Riuso del software in un ambiente diverso da quello per
cui era stato progettato e testato
• Mantenimento dell’esecuzione di funzionalità diventate
inutili
• Mancanza di test adeguato nelle condizioni di utilizzo del
software
• Mancanza di un corretto flusso di informazione sulle
specifiche di funzionamento del software delle
piattaforme inerziali dal progetto Ariane 4 ad Ariane 5
Ingegneria del
software
Tipologia dei guasti nell’Ariane 5
• Si tratta di guasti interni, umani, di progetto, non
intenzionali
Ingegneria del
software
Altri esempi di guasti software
• Il baco del processore Pentium 5
–
L’errore era dovuto a un difetto di progettazione dell’algoritmo di divisione
in floating point (FDIV)
– FDIV è l'istruzione in assembly x86
– il processore sbagliava a calcolare espressioni semplici come se x fosse un
numero contenente diverse cifre dopo la virgola:
• es. dividendo 4195835.0/3145727.0 si otteneva 1,33374 invece di 1,33382 un
errore dello 0,006 per cento.
• Anche se il problema interessa poche persone diventa un danno di immagine per
Intel
• Stimando tra i 3.000 e i 5000 chips difettosi in circolazione la Intela dapprima si
impegna a sostituirli soltanto per gli utenti che avessero necessità di effettuare
calcoli con elevata precisione, successivamente cede e sostituisce i chips a
chiunque ne avesse fatto richiesta. Il danno economico ammonta a 475milioni di
dollari.
– L’errore non era presente nel processore 486
– La scoperta avvenne nell'estate del 1994 quando il professore Thomas
Nicely tentò di calcolare il risultato di una particolare espressione
matematica
Ingegneria del
software
Altri guasti software
• 2005 - Automaker Toyota announced a recall of 160,000 of its Prius
hybrid vehicles following reports of vehicle warning lights
illuminating for no reason, and cars' gasoline engines stalling
unexpectedly. But unlike the large-scale auto recalls of years past,
the root of the Prius issue wasn't a hardware problem -- it was a
programming error in the smart car's embedded code. The Prius
had a software bug.
• January 15, 1990 -- AT&T Network Outage. A bug in a new
release of the software that controls AT&T's #4ESS long distance
switches causes these mammoth computers to crash when they
receive a specific message from one of their neighboring machines - a message that the neighbors send out when they recover from a
crash.
– One day a switch in New York crashes and reboots, causing its neighboring
switches to crash, then their neighbors' neighbors, and so on. Soon, 114
switches are crashing and rebooting every six seconds, leaving an estimated
60 thousand people without long distance service for nine hours. The fix:
engineers load the previous software release.
Ingegneria del
software
Altri guasti software
• July 28, 1962 -- Mariner I space probe. A bug in the flight
software for the Mariner 1 causes the rocket to divert from its
intended path on launch. Mission control destroys the rocket over
the Atlantic Ocean. The investigation into the accident discovers
that a formula written on paper in pencil was improperly transcribed
into computer code, causing the computer to miscalculate the
rocket's trajectory.
• 1982 -- Soviet gas pipeline. Operatives working for the Central
Intelligence Agency allegedly plant a bug in a Canadian computer
system purchased to control the trans-Siberian gas pipeline. The
Soviets had obtained the system as part of a wide-ranging effort to
covertly purchase or steal sensitive U.S. technology. The CIA
reportedly found out about the program and decided to make it
backfire with equipment that would pass Soviet inspection and then
fail once in operation. The resulting event is reportedly the largest
non-nuclear explosion in the planet's history.
Ingegneria del
software
Altri guasti software
• 1985-1987 -- Therac-25 medical accelerator. A radiation
therapy device malfunctions and delivers lethal radiation doses at
several medical facilities. Based upon a previous design, the Therac25 was an "improved" therapy system that could deliver two
different kinds of radiation: either a low-power electron beam (beta
particles) or X-rays. The Therac-25's X-rays were generated by
smashing high-power electrons into a metal target positioned
between the electron gun and the patient. A second "improvement"
was the replacement of the older Therac-20's electromechanical
safety interlocks with software control, a decision made because
software was perceived to be more reliable.
– What engineers didn't know was that both the 20 and the 25 were built
upon an operating system that had been kludged together by a programmer
with no formal training. Because of a subtle bug called a “race condition“, a
quick-fingered typist could accidentally configure the Therac-25 so the
electron beam would fire in high-power mode but with the metal X-ray
target out of position. At least five patients die; others are seriously injured.
Ingegneria del
software
Metodi formali
Tecniche basate su fondamenti matematici, di aiuto al
corretto sviluppo ed alla verifica del software.
• Problema: Indecibilità della verifica di correttezza di un
programma rispetto ad una specifica
• Soluzione:
– Una metodologia model driven
Ingegneria del
software
Definizione
• Metodo di specifica e produzione del software che
comprende:
– Una collezione di notazioni matematiche indirizzate alle fasi di
specifica, di progetto e di sviluppo
– Un sistema di inferenza logica ben fondato in cui si possano
formulare dimostrazioni di correttezza e altre proprietà
– Un contesto metodologico mediante il quale il software possa
essere sviluppato dalla specifica all’implementazione in modo
formalmente verificabile
Ingegneria del
software
Verifica formale del codice sorgente
• Hoare alla fine degli anni 60 propose l’uso di asserzioni
nel codice sorgente:
– si usa la logica di Hoare
• Un sistema formale con lo scopo di fornire un insieme di regole per
studiare la correttezza di programmi col rigore della logica
matematica.
– Si basa sulla tripla di Hoare, che descrive come l’esecuzione di
un pezzo di codice cambia lo stato della computazione.
Ingegneria del
software
Logica di Hoare
Si presenta nella forma:
• [P]C[Q] dove
–
P e Q sono asserzioni, formule valide in logica dei predicati
sulle variabili del programma
– C un comando
• P precondizione
• Q postcondizione
– La logica definisce assiomi e regole di inferenza per tutti i
costrutti di un linguaggio di programmazione imperativo basate
sulla semantica del linguaggio
Ingegneria del
software
Regole della logica di Hoare
• Le regole permettono di derivare la postcondizione Q a
partire dalla precondizione P e dalla semantica del
comando C
• Esempio:
i=0;
while (i<n)
{a[i]=0;
i++;
}
==n
Precondizione i==0
0<j<=k => a[j-1]==0&&i==k
invariante al k-esimo ciclo
Postcondizione 0<j<=n => a[j-1]==0 &&i
Ingegneria del
software
Invariante
• Per comandi semplici (es. assegnamento ) la
postcondizione si ottiene dalla precondizione
modificando l’asserzione sul valore della variabile toccata
dall’assegnamento
• Se il comando è un ciclo, al fine di calcolare la
postcondizione occorre definire l’invariante del ciclo,
ovvero un’asserzione che vale in un punto del corpo del
ciclo and ogni iterazione.
Ingegneria del
software
Model checking
• Tecnica di verifica:
– Le proprietà del sistema diventano decidibili (cioè verificabili
algoritmicamente) se un sistema è modellato mediante una
macchina a stati finiti.
– Model checking
• Consiste nel descrivere un sistema (software o altro) mediante una
finite state machine, nell’esprimere una proprietà d’interesse
mediante una formula e nel verificare se il comportamento del
sistema soddisfi la proprietà stessa.
• La dimostrazione della proprietà può essere fatta automaticamente
• Il model checking coniuga le proprietà del test con quelle delle
prove matematiche di correttezza
Ingegneria del
software
Model checking
Model checking
Definito da Edmund Clarke ( cmu), Allan Emerson ( univ. Of texas),
Joseph Sifakis ( cmu), che ricevono nel 2007 l’ACM Turing Award,
[E.M. Clarke, E.A. Emerson, A.P. Sistla,” Automatic Verification of
Finite-state Concurrent Systems using Temporal Logic Specification,
“ACM Transaction on Programming Languages and Systems,
8(2),April 1986, pp.244-263]
Ingegneria del
software
Vantaggi
• definizione di un modello formale del sistema conforme alla
implementazione
• possibilità di specificare proprietà del sistema mediante formalismi
logici
• dimostrazione della validità di tali proprietà rispetto al modello
• disponibilità di un modello eseguibile ossia di un modello su cui si
possono effettuare simulazioni
– definire un modello utilizzando un formalismo
– verificare proprietà del modello rispetto a specifiche formulate tramite
logiche temporali
Ingegneria del
software
Model checker
• È l’algoritmo che verifica le proprietà, fornisce o una
prova che la proprietà in esame risulta verificata oppure
un contro-esempio, ossia un caso di test che dimostra il
fallimento del sistema nel comportamento corretto
rispetto alla proprietà.
Ingegneria del
software
Struttura di Kripke
• È una macchina a stati finiti, una quintupla M=(S,
S0,R,AP,L) dove:
– S insieme finito di stati
– S0 è l’insieme degli stati iniziali
– R⊆SxS è la relazione di transizione di stato che deve essere
totale ossia per ogni stato sєS esiste s’єS tale che sia definita
R(s, s’)
– AP è un insieme di proposizioni atomiche
– L: S→2AP è una funzione che assegna ad ogni stato un’etichetta
che contiene le proposizioni atomiche vere in quello stato.
Ingegneria del
software
Computation Tree Logic (CTL)
• Branching time logic
– Syntax:
• Propositional atoms & connectives AND, OR, NOT
• Temporal connectives (F, G, U, X)
• Quantifiers over paths (A, E)
– Semantics
• Paths on a Kripke structure
Ingegneria del
software
•
Quantifiers and Operators
Path Quantifiers
– A - for All paths...
– E - there Exists a path...
•
Temporal Operators
– G - Globally in a path...
– F - sometime in the Future...
– U - ...Until...
– X …in the neXt state...
Allowed combinations:
– Quantifier + Operator
•
•
•
•
AG f
AF f
A(f1 U f2)
AX f
•
•
•
•
EG f
EF f
E( f1 U f2)
EX f
Ingegneria del
software
Sintassi
• La logic CTL è definita mediante due categorie
sintattiche:
• Formule di stato φ:
• φ ≔∼ φ | φ ∧ φ | true |p | A ψ |E ψ
– Formule di cammino ψ:
• ψ ≔X φ | φU φ |F φ |G φ
• La negazione si applica solo alle formule di stato,
consentendo la dualità solo tra operatori preceduti
dal quantificatore:
∼AF φ= EG ∼ φ
∼EF φ= AG ∼ φ
∼EX φ= AX ∼ φ
Ingegneria del
software
Definizioni
• Un cammino π è una sequenza finita di stati tale che per ogni
i≥0, (si,si+1) ∈ R
• Se φ è una formula di stato,
• M,s ⊨ φ significa che φ è valida nello stato s nella struttura di
Kripke M
• Se ψ è una formula di cammino,
• M, π ⊨ ψ significa che ψ è valida lungo il cammino π nella
struttura di Kripke M
• Generalmente M può essere omesso se è evidente dal contesto
Ingegneria del
software
Semantica
La relazione ⊨ è definita induttivamente come segue:
• Se φ1 ,φ2 sono formule di stato e ψ 1, ψ 2 sono
formule di cammino
• s ⊨ true sempre
• s ⊨ p ⇔ p ∈ L(S)
• s ⊨ φ1 ∧ φ2 ⇔ (s ⊨ φ1) ∧ (s ⊨ φ2)
•
•
•
•
•
•
•
s⊨∼φ⇔∼s⊨ φ
s ⊨ A ψ ⇔ ∀π a partire da s, π ⊨ ψ
s ⊨ E ψ ⇔ ∃π a partire da s, tale che π ⊨ ψ
π⊨ X φ ⇔ π=s0,s1,s2,…,sn,.. ∧ s1⊨ φ
π⊨ φ1 U φ2 ⇔ π=s0,s1,s2,…,sn,.. ∧ ∃i: si⊨ φ2 ∧ ∀k<i, S k ⊨ φ1
π⊨ Fφ ⇔ π =s0,s1,s2,…,sn,.. ∃i: si⊨ φ
π⊨ Gφ ⇔ π=s0,s1,s2,…,sn,.. ∀i: si⊨ φ
Ingegneria del
software
L’algoritmo
• Data una struttura di Kripke M ed una formula φ, il model checking
consiste nel verificare se M soddisfa φ.
– La formula rappresenta una proprietà che si desidera che M abbia.
– Il model checking consiste nel verificare che M sia un modello per φ
cioè M ⊨ φ.
• Emerson e Clarke hanno proposto un algoritmo che risolve il model
checking per la Logica CTL.
– Consiste nell’etichettare tutti gli stati di M con sottoformule di φ
soddisfatte in tali stati, iniziando con le sottoformule di lunghezza 0,
(cioè con i predicati atomici), passando a sottoformule di lunghezza 1,
dove si applica un solo operatore logico a formule con predicati atomici,
quindi a sottoformule di lunghezza 2 dove si applica un operatore logico
a sottoformule di lunghezza 1 e così via.
Ingegneria del
software
Verifica
• Il risultato si evince dalla formule che etichettano lo
stato iniziale:
– La formula è verificata se e solo se essa etichetta lo stato
iniziale.
Ingegneria del
software
Model checking CTL
• Data una stuttura di Kripke che rappresenta una
macchina a stati finiti ed una formula espressa in logica
temporale che specifica lamproprietà che si desidera
verificare, il problema del model checking consiste nel
determinare tutti gli stati in S che soddisfano la formula
Ingegneria del
software
Esempio mutua esclusione
• Due processi concorrenti:
– Eseguono alcune operazioni usando una risorsa condivisa
– Entrambi i processi:
• eseguono alcune operazioni non critiche rappresentate dallo stato
Ni con i=1,2
• cercano di accedere alla risorsa (stato Ti trying con i=1,2)
• Eseguono operazioni critiche sulla risorsa condivisa (stato Ci i=1,2)
Ni
Ti
Ci
Ingegneria del
software
Esempio: mutua esclusione
• Problema:
– Implementare un meccanismo di mutua esclusione che
impedisca ai processi di accedere alla risorsa condivisa
contemporaneamente:
– Ogni stato è una combinazione degli stati dei due processi
• nessuno stato deve implementare la combinazione degli stati C1 e
C2
• l’implementazione non deve consentire che tutti e due i processi si
trovino nella sezione critica
Ingegneria del
software
Esempio: mutua esclusione
N1 N2
T1 N2
C1 N2
N1 T2
T1 T2
C1 T2
N1 C2
T1 T2
T1 C2
Ingegneria del
software
Formula da verificare
In logica temporale la formula è la seguente:
AG ~(C1 ∧ C2)
Si vuole, inoltre, verificare che non vi sia starvation ossia
che quando un processo entra nella fase di trying prima
o poi riesca ad accedere alla risorsa:
AG (Ti⇒ AF Ci)
Cioè
AG (~Ti ∨ AF Ci)
Ingegneria del
software
Etichettamento
1. Il processo di etichettamento inizia con l’etichettatura delle
formule di lunghezza 1
~Ti
e
AF Ci
2. Quindi procede con l’etichettatura dei nodi per cui valgono le
formule di lunghezza 2. Cioè la formula:
~Ti ∨ AF Ci
3. Si procede con l’etichettatura delle formule di lunghezza 3.
Cioè la formula:
AG (~Ti ∨ AF Ci)
Che andrà ad etichettare lo stato iniziale, essendo tutti gli altri
stati già etichettati con le formule di lunghezza 2.
Ingegneria del
software
Esempio: mutua esclusione etichettamento
N1 N2 ~ T1
~ T1 ν AF C1
T1 N2 AF C1 ~
T1 ν AF C1
C1 N2 ~ T1 AF
C1 ~ T1 ν AF C1
N1 T2 ~ T1 ~
T1 ν AF C1
C1 N2 ~ T1 AF
C1 ~ T1 ν AF C1
C1 T2 ~ T1 AF
C1 ~ T1 ν AF C1
N1 C2 ~ T1 ~
T1 ν AF C1
T1 T2 AF C1 ~
T1 ν AF C1
T1 C2 AF C1 ~
T1 ν AF C1
Ingegneria del
software
Osservazioni
• La descrizione dello spazio degli eventi ci permette di
astrarre dalle funzionalità dei processi
• La complessità dell’algoritmo nel caso peggiore è lineare
in termini della grandezza della formula e in termini dello
spazio degli stati
• In caso di fallimento l’algoritmo permette di tracciare gli
stati che l’hanno causato
• Il numero degli sati del sistema cresce al più
esponenzialmente con il numero dei processi
indipendenti
Ingegneria del
software
Riferimenti
• E. M. Clarke, E. A. Emerson, A.P. Sistla, “ Automatic
Verification of Finite-State Concurrent Systems using
Temporal Logic Specifications”, “ACM Transaction on
Programming Languages and Systems”, 8(2), april 1986,
pp. 244-263.
• E.M. clarke, Jr. O Grumberg, D.A. Peled, “ Model
checking”, The MIT Press, 1999.
• A. Fantechi ,“Informatica Industriale”, CittàStudi
Edizioni,2009.
