MODEL CHECKING COS'È E COME SI APPLICA
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
MODEL CHECKING
COS’È E COME SI APPLICA
Il model checking ha dimostrato di essere una tecnologia di successo per Alessandro Fantechi
Stefania Gnesi
verificare la correttezza dei requisiti nella progettazione di un consistente
numero di sistemi real-time, embedded e safety-critical. Lo scopo di que-
sto breve articolo è di spiegare come funziona.
3.2
1. INTRODUZIONE ❑ I requisiti sono scritti chiaramente e non
L o sviluppo di metodologie formali per la
progettazione, l’analisi e la verifica dei
moderni sistemi software, spesso realizzati
contengono ambiguità? Sono comprensibili?
❑ I requisiti sono opportunamente strutturati
per facilitare la progettazione e lo sviluppo?
mediante l’assemblaggio di componenti pre- ❑ I requisiti possono essere utilizzati per de-
esistenti, assume un’importanza cruciale nel finire facilmente i casi di test di accettazione
fornire un valido sostegno alla loro validazio- per verificare la conformità del prodotto ri-
ne fin dalle prime fasi del loro sviluppo. Al fi- spetto ai requisiti stessi?
ne di evitare l’introduzione di difetti di pro- ❑ I requisiti sono scritti in modo sufficiente-
gettazione o l’insorgere di problemi di inte- mente astratto e ad alto livello in modo da
grazione, o d’interoperabilità nell’intercon- dare sufficiente libertà al progettista e agli
nessione dinamica dei componenti software sviluppatori di implementare in modo effi-
è importante affiancare alla specifica del si- ciente?
stema in progettazione opportune metodo- Trovare le risposte a queste domande è un la-
logie di verifica. voro difficile e non c’è un modo semplice per
È prassi comune scrivere i requisiti di un siste- farlo. Nonostante qualche aiuto possa venire
ma in lingua naturale corredando le descrizio- dall’uso di strumenti di modellazione come
ni testuali con diagrammi, screenshot e nota- per esempio UML, il problema di garantire la
zioni UML, come per esempio i casi d’uso e qualità dei requisiti rimane. E talvolta si intro-
diagrammi di sequenza, di classe e di stato. ducono ulteriori problemi:
L’attività di verifica dei requisiti consiste fon- ❑ Quale notazione usare per quali requisiti?
damentalmente nel cercare le risposte a una ❑ Come garantire che le descrizioni in diver-
serie di domande quali per esempio: se notazioni siano coerenti tra loro?
❑ I requisiti soddisfano le esigenze degli uten- Prima ancora di iniziare a scrivere il codice che
ti? Tutto ciò che è stato descritto corrisponde realizzerà un sistema software, il progettista
a ciò che essi vogliono e tutto ciò che gli uten- dovrà esser sicuro che i requisiti che descrivo-
ti hanno chiesto è incluso? no le funzionalità del sistema stesso non con-
29
M O N D O D I G I T A L E • n . 2 - 3 - g i u g n o - s e t t e m b r e 2 0 1 1
0
tengano errori. È infatti importante trovare il eseguite. Inoltre, nella maggior parte dei si-
maggior numero di possibili difetti prima che stemi real-time embedded o safety-critical è
la fase di codifica venga effettuata perché altri- necessario avere a disposizione dei linguag-
menti l’eliminazione degli errori quando il pro- gi formali idonei a descrivere aspetti orienta-
dotto è già stato consegnato potrebbe diven- ti al loro controllo, piuttosto che al tratta-
tare molto costosa. mento dei dati.
Un modo per migliorare la qualità dei requisiti Per quest’ultima classe di sistemi, vari “dialet-
1 e del progetto è quello di utilizzare strumenti
automatici per verificarne la qualità relativa-
ti” di automi a stati finiti, come macchine a sta-
ti finiti (FSM), sistemi di transizione etichettati
mente ad un insieme di caratteristiche consi- (LTS), o diagrammi a stati UML, sono ampia-
derate importanti al fine di garantire il buon mente accettati come una notazione formale
funzionamento del sistema. chiara, semplice e sufficientemente astratta
per esprimere i requisiti.
Quali strumenti sono più idonei per questo Negli ultimi venti anni, la ricerca in informati-
0 compito?
Un modo potrebbe essere quello di costruire
ca ha fatto enormi progressi nello sviluppo di
strumenti automatici a supporto della verifi-
strumenti automatici per verificare i requisiti ca dei requisiti di sistemi complessi. Uno de-
scritti in linguaggio naturale. Qualcosa in que- gli approcci di maggior successo è quello co-
sta direzione è stato fatto, ma sicuramente nosciuto come model checking, che permet-
non è possibile, data la natura intrinseca del te di automatizzare il processo di verifica di
linguaggio naturale, realizzare delle analisi sistemi descritti mediante l’uso di linguaggi
esaustive dei requisiti così espressi. formali.
L’introduzione di linguaggi e notazioni for- In questo articolo, si darà un'introduzione al
mali diventa un passo necessario al fine di model checking e si mostrerà come funziona.
poter descrivere i requisiti di un sistema in
modo chiaro e non ambiguo e quindi con una
2. MODEL CHECKING
semantica ben definita. Partendo da qui sarà
possibile sviluppare strumenti automatici La tecnica del model checking, introdotta da
per analizzare in modo esaustivo i requisiti Clarke, Emerson e contemporaneamente da
stessi. Quielle e Sifakis agli inizi degli anni ‘80, è ba-
La progettazione di sistemi software comples- sata su idee estremamente semplici ed è pro-
si sarà quindi molto facilitata dall'applicazione babilmente uno dei più significativi avanza-
di metodologie che facciano riferimento in mo- menti della ricerca in Informatica di base di
do diretto o indiretto a descrizioni formali delle questi ultimi decenni.
applicazioni stesse. Ciò è particolarmente im- Nella verifica tramite model checking il siste-
portante per quei sistemi dedicati al controllo ma sotto analisi viene descritto con un lin-
di applicazioni critiche, di cui quelle nei settori guaggio formale e successivamente model-
automotive, ferroviario, avionico e spaziale, lato mediante qualche dialetto di automi a
sono gli esempi più immediati, per i quali le stati finiti (nel seguito faremo riferimento al-
descrizioni formali possono fornire una guida la notazione di base degli automi a stati fini-
utile per garantire le proprietà necessarie di ti, che assumeremo come nota). Le proprietà
correttezza, sicurezza, interoperabilità, affida- da verificare su tale modello sono rappre-
bilità ed efficienza. sentate tramite un linguaggio preciso e non
La domanda che ora ci dobbiamo porre è ambiguo, tipicamente in logica temporale, e
quale sia il linguaggio formale più idoneo per la loro soddisfacibilità sull’automa a stati fi-
definire i nostri sistemi. Non esiste una rispo- niti che modella il sistema viene verificata in
sta unica, poiché i fabbisogni per i sistemi in modo efficiente ed automatico. Se le pro-
1 diversi domini applicativi variano notevol-
mente. Per esempio, i requisiti di un sistema
prietà non sono soddisfatte, una traccia di
esecuzione (controesempio) è mostrata al fi-
bancario o quelli di un sistema aerospaziale ne di evidenziare perché si ha il fallimento
0 si differenziano molto sia per struttura, com-
plessità, natura dei dati, sia per le operazioni
nella verifica.
In sintesi la verifica tramite model checking
30
M O N D O D I G I T A L E • n . 2 - 3 - g i u g n o - s e t t e m b r e 2 0 1 1
0
consiste, dato un automa M modello di un quenza di stati e transizioni tra stati che rap-
sistema e una formula di logica temporale presenta un’esecuzione del modello su cui la
φ, che rappresenta una proprietà che si de- formula è verificata. Gli stati colorati rappre-
sidera che M abbia, nel verificare se M sod- sentano stati in cui le sottoformule della for-
disfa φ. mula considerata sono verificate; la prima se-
quenza indica che, se non vi sono connettivi
Come possiamo specificare queste pro- temporali, la formula si intende verificata sul-
prietà delle esecuzioni? lo stato iniziale.
Sono state sviluppate diverse logiche tempo- 1
rali a questo scopo. Una logica temporale è
3. UN SEMPLICE ESEMPIO
un’estensione della logica proposizionale la
cui struttura di interpretazione è una succes- Per mostrare il funzionamento dell'algoritmo
sione di istanti di tempo distinti. di model checking, consideriamo un classico
Tra le logiche temporali esistenti consideria-
mo qui la logica LTL (Linear time Temporal Lo-
gic), una logica temporale che fa riferimento
X φ (next) Vera nello stato corrente se la formula φ
è vera nello stato successivo.
0
ad una struttura temporale lineare di stati e
G φ (always) Vera nello stato corrente se φ è vera in
transizioni, che rappresenta una possibile tutti gli stati successivi.
esecuzione di un sistema modellato median-
te un automa. La sintassi della logica LTL è F φ (eventually) Vera nello stato corrente se φ è vera in
definita a partire dagli operatori della logica almeno uno degli stati successivi.
booleana proposizionale (che comprende i φ1 U φ2 (until) Vera nello stato corrente se φ2 è vera in
connettivi logici come AND, OR, NOT, implica uno stato futuro e φ1 è vera in tutti gli stati
ecc.), dove sono stati aggiunti connettivi precedenti.
φ1 P φ2 (precedes) Vera nello stato corrente se φ2 non è
temporali. Alcuni connettivi temporali tipici
di LTL sono rappresentati nella tabella 1, in- vera in uno stato precedente a quello in
sieme al loro significato informale. cui φ1 è vera.
La figura 1 rappresenta graficamente il signifi-
cato degli operatori temporali descritti nella TABELLA 1
tabella 1, dando per ogni formula una se- Alcuni degli operatori temporali di LTL
FIGURA 1
1
Interpretazione
degli operatori
temporali di LTL 0
31
M O N D O D I G I T A L E • n . 2 - 3 - g i u g n o - s e t t e m b r e 2 0 1 1
0
1
FIGURA 2
Composizione di
due processi che
0 accedono ad una
risorsa condivisa
tivamente, ed analogamente per le transi-
zioni n ed e).
Supponiamo che ci interessi provare la pro-
prietà di mutua esclusione, ovvero che non
vi è interferenza sull'accesso alla risorsa
condivisa. Possiamo esprimere questa pro-
prietà dicendo che se il processo A accede
per primo alla risorsa, il processo B non de-
ve accedere prima che A abbia rilasciato la
risorsa. Ovvero, non devono esistere se-
FIGURA 3 quenze di transizioni in cui cA precede cB e
Automa della formula da verificare cB precede eA.
In logica temporale LTL questo si esprime
esempio di sistema concorrente, in cui due come:
processi accedono ad una risorsa condivisa.
Per semplificare l’esposizione, consideriamo φ = ~(cA P cB & cB P eA)
un semplice modello del funzionamento di
ognuno dei due processi, di cui si osservano Per specificare completamente la mutua
solamente le principali transizioni di stato: esclusione dovremmo poi esprimere anche
❑ una transizione, n, che modella la compu- la formula simmetrica, con A e B scambiati,
tazione che viene svolta senza accedere alla ma ci limitiamo a questa parte della pro-
risorsa; prietà.
❑ una transizione, c, che modella l'ingresso Per verificare questa proprietà si procede
nella “regione critica”, in cui si accede alla ri- definendo un automa A(~φ) che generi tutte
sorsa condivisa, le sequenze di transizione non ammesse
❑ una transizione, e, che modella il rilascio dalla suddetta formula (Figura 3). L’interse-
della risorsa condivisa (si vedano i due auto- zione dell’automa AB con l’automa A(~φ) ci
mi a sinistra nella Figura 2). fornisce un automa che genera le sequenze
Se eseguiamo in parallelo i due processi A e che sono riconosciute da entrambi gli auto-
B, assumendo le transizioni come atomiche, mi. Se la proprietà fosse verificata, questa
1 l’automa a stati finiti che rappresenta il
comportamento complessivo del sistema
intersezione ci dovrebbe quindi dare il lin-
guaggio vuoto. Questo non è vero in questo
dei due processi è l’automa AB, a destra caso, in quanto la sequenza nA nB cA cB eA
0 nella figura 2 (cA e cB rappresentano la tran-
sizione c eseguita dal processo A e B rispet-
appartiene all'intersezione. Questa sequen-
za (Figura 4) viene detta “controesempio”, in
32
M O N D O D I G I T A L E • n . 2 - 3 - g i u g n o - s e t t e m b r e 2 0 1 1
0
1
0
FIGURA 4
Cammino
di controesempio
sull’automa AB
FIGURA 5
Comportamento
del sistema che usa
un semaforo
quanto dimostra la non veridicità della for- processi A e B con il semaforo, otteniamo
mula per il sistema AB (in questo caso non è l'automa ABs, rappresentato a destra nella fi-
l’unico controesempio ricavabile). Il controe- gura 5. Ripetendo il procedimento di model
sempio può servire a diagnosticare il motivo checking si vede che questa volta l'interse-
per cui il sistema non soddisfa la proprietà zione tra A(~φ) e ABs è nulla, e quindi la for-
richiesta: in questo caso ci si è chiaramente mula è soddisfatta.
dimenticati di impedire l’accesso del proces- Si noti che i passaggi che sono stati effettua-
so B alla risorsa quando il processo A l’ha ti in questo esempio sono tutti formalizzabili
già acquisita.
A questa dimenticanza si può ovviare con il
come operazioni su automi e sono imple-
mentabili con opportuni algoritmi. Questo si-
1
classico meccanismo del semaforo, che pre- gnifica che il procedimento esemplificato
senta il comportamento descritto dall’auto-
ma a sinistra nella figura 5. Sincronizzando i
può essere codificato in un algoritmo che di-
mostra formalmente che la proprietà vale o, 0
33
M O N D O D I G I T A L E • n . 2 - 3 - g i u g n o - s e t t e m b r e 2 0 1 10
in caso contrario, fornisce un controesempio. l’hardware, tanto da valere ai pionieri Clarke,
Questo algoritmo, modificato per lavorare su Emerson e Sifakis il prestigioso ACM Turing
automi di Büchi, ovvero automi che ricono- Award del 2007.
scono sequenze infinite, è sostanzialmente La ricerca sul model checking si è da allora svi-
quello utilizzato nel Model Checker SPIN. luppata enormemente e varie tecniche sono
L’algoritmo di model checking di Clarke ed state studiate per migliorarne ancora le pre-
Emerson agisce invece visitando gli stati del- stazioni e tentare di ridurre il fenomeno dell’e-
1 l’automa ed etichettandoli progressivamen-
te con le sottoformule della formula da verifi-
splosione degli stati. Una possibilità è quella
di generare e memorizzare solo lo spazio degli
care, formule espresse nella logica tempora- stati necessario per verificare la proprietà in
le CTL. questione.
Entrambi questi algoritmi presentano una In particolare, nel local model checking (an-
complessità computazionale lineare con la di- che noto come on-the-fly model checking) si
mensione dello spazio degli stati del modello. generano, sulla base della struttura della for-
0 mula, solo gli stati che effettivamente servo-
no a verificare la formula (in alcuni casi però
4. LIMITI DEL MODEL CHECKING
potrebbe essere necessario generare l’intero
L’esempio della mutua esclusione mostra co- spazio degli stati).
me l’algoritmo di model ckecking si applichi ad Nel Bounded Model Checking (BMC) invece
un modello a stati ottenuto tramite la compo- lo spazio degli stati viene generato fino ad
sizione dei modelli di più processi. Come l’e- una profondità fissata: il risultato del BMC
sempio mostra, in genere il numero degli stati sarà quindi ternario: la formula è verificata,
del sistema complessivo cresce, quando il si- la formula non è verificata, la profondità non
stema è composto di più processi, in modo è sufficiente per verificare. Nel terzo caso, si
esponenziale con il numero dei processi coin- può decidere di aumentare la profondità. Il
volti, perché lo spazio degli stati può essere il BMC sta vivendo un momento di popolarità
prodotto degli spazi degli stati di ogni proces- da quando si è dimostrato che il problema
so. Questo fenomeno, chiamato “esplosione del model checking LTL su uno spazio degli
dello spazio degli stati”, limita fortemente la stati di profondità limitata si può esprimere
capacità degli algoritmi di model ckecking cita- efficientemente come un problema di soddi-
ti a lavorare su esempi di sistemi “reali”, fer- sfacibilità (SAT), problema che, pur essendo
mandosi intorno al milione di stati, principal- in generale NP-completo, viene affrontato
mente a causa della dimensione dello spazio con successo da algoritmi molto efficienti re-
di memoria necessario per rappresentare lo centemente sviluppati.
spazio degli stati.
Le limitazioni degli algoritmi di model
5. MODEL CHECKING
checking dovute all’esplosione dello spazio IN PRATICA
degli stati sono state affrontate con la tecni-
ca introdotta da McMillan che permette la La disponibilità di strumenti di model checking
rappresentazione simbolica degli stati per efficienti e capaci di lavorare su spazi degli sta-
mezzo degli Ordered Binary Decision Dia- ti di grandi dimensioni ne ha favorito, a partire
grams (OBDD). In questa tecnica lo spazio dalla metà degli anni novanta, la diffusione an-
degli stati non viene rappresentato esplicita- che in ambito industriale.
mente memorizzando tutti gli stati e le transi- I due model checker di origine accademica
zioni, ma implicitamente (o simbolicamente) più famosi sono SMV, sviluppato presso la
mediante un insieme di funzioni binarie, a lo- Carnegie Mellon University, come model
ro volta memorizzate in modo compatto tra- checker basato su rappresentazione BDD
1 mite OBDD, arrivando a poter trattare sistemi
da 1023 a 10120 stati.
per la logica CTL e di cui ne esiste una ver-
sione reingegnerizzata, NuSMV, sviluppata
Questa tecnica ha quindi posto le basi per dalla Fondazione Bruno Kessler di Trento, e
0 una vasta diffusione del model checking, so-
prattutto nell’ambito della verifica del-
SPIN, sviluppato come model checker per la
logica temporale lineare (LTL), presso i Bell
34
M O N D O D I G I T A L E • n . 2 - 3 - g i u g n o - s e t t e m b r e 2 0 1 10
Labs sotto la direzione di Gerard Holzmann. 6. MODEL BASED
Dopo il famoso caso in cui Intel dovette nel DEVELOPMENT
1994 ritirare dal mercato i nuovi chip Pen- Nell’applicazione del model checking alla pro-
tium, affetti da un guasto di progetto del- duzione del software di sistemi critici, si pos-
l’algoritmo di divisione in virgola mobile, ri- sono individuare due tendenze principali: la
levato anche tramite model checking, nel prima, che possiamo considerare più matura
settore della produzione di chip questa tec- e diffusa, si situa all'interno dei metodi di svi-
nica si è ormai affermata come metodologia luppo basati sulla modellazione formale dei
insostituibile di prova della corretta proget- requisiti (model based). 1
tazione utilizzando vari model checker pro- In questo approccio lo sviluppo del software
prietari, costruiti spesso in casa dalle ditte avviene a partire da modelli del sistema, at-
produttrici. traverso passi di raffinamento e traduzione,
Diversa e più variegata è la situazione dell’u- anche supportati da appositi strumenti (si-
tilizzo del model checking per la verifica della mulatori, generatori di codice ecc.). La defini-
correttezza del software. In effetti, la produ-
zione dell’hardware digitale ha sempre fatto
zione di modelli accurati del funzionamento
del sistema, prima dello sviluppo del codice,
0
riferimento a macchine a stati finiti per rap- ha effetti positivi sulla possibilità di rilevare
presentare convenientemente il comporta- errori di progettazione, quando la loro corre-
mento richiesto da un dispositivo. L’applica- zione ha un costo molto minore. La rilevazio-
zione del model checking, una volta superate ne di errori può avvenire tramite simulazione
le limitazioni di dimensione, ha quindi trova- del modello, o tramite, appunto, la sua verifi-
to facile presa tra gli addetti. Nel caso della ca formale. Il modello può poi direttamente
produzione del software, nonostante l’ese- servire per generare automaticamente il co-
cuzione di un programma possa essere sem- dice tramite appositi strumenti: questa pos-
pre in teoria modellata come una macchina a sibilità è interessante per la realizzazione di
stati, la corrispondenza tra codice e modello prototipi - consentendo di concentrare gli
non è immediata. Inoltre, in molti casi il sforzi di progettazione e verifica nella specifi-
software ha, almeno da un punto di vista teo- ca dei modelli - ma viene sempre più diffusa-
rico, un numero di stati infinito o, al meglio, mente usata anche per la produzione finale
enormemente grande. Se in generale il pro- del codice.
blema del model checking è indecidibile su Diversi strumenti commerciali di ausilio alla
programmi a stati infiniti, basta un semplice progettazione model based, come Simu-
programma in cui due variabili intere a 32 bit, link/Stateflow di Matlab, o SCADE, conten-
possono assumere valori indipendenti tra lo- gono moduli che implementano varie versio-
ro e non limitabili a priori, a produrre uno ni di algoritmi di model checking. In altri stru-
spazio di 264 stati. menti di supporto a questo paradigma di svi-
Il model checking ha quindi stentato a farsi luppo (come IAR Visualstate), il motore di
strada nella produzione del software, dove model checking è nascosto allo sviluppatore,
il testing viene ancora visto come la princi- permettendogli di provare proprietà pre-ca-
pale attività di verifica della correttezza del blate sui modelli sviluppati.
codice, pur non possedendo le doti di esau- Secondo questa tendenza, l’applicazione del
stività che costituiscono il principale van- model checking avviene per verificare i mo-
taggio del model checking. Se quindi, per il delli, lasciando al generatore di codice il com-
software di utilizzo comune questa tecnica pito di derivarne un codice corretto.
non si è affermata, è stata invece presa in Una delle esperienze più interessanti in que-
seria considerazione, anche se con un certo sto ambito è quella della Rockwell Collins,
ritardo rispetto all’hardware, nel settore operante nel settore avionico, dove sono sta-
della produzione del software di sistemi cri-
tici, dove è necessario garantire la massima
ti usati come ambienti di progetto model ba-
sed sia Simulink/Stateflow che SCADE, e so-
1
affidabilità raggiungibile mantenendo i co- no stati sviluppati traduttori per poter appli-
sti delle attività di verifica al di sotto di una
soglia accettabile.
care ai modelli prodotti diversi model
checkers, tra cui SMV e NuSMV. Uno dei risul- 0
35
M O N D O D I G I T A L E • n . 2 - 3 - g i u g n o - s e t t e m b r e 2 0 1 10
tati più interessanti di questa esperienza è la sentazione esplicita spazio degli stati, co-
conferma che il model checking è più efficace munque generata on-the-fly, e l’adozione di
del testing nel trovare errori: in un esperi- un motore di astrazione che si basa su CE-
mento di verifica fatto con due team indipen- GAR (Counterexample Guided Abstraction
denti sullo stesso sottosistema, quello che Refinement), un procedimento iterativo che
usava model checking ha trovato 12 errori, permette di raffinare l’astrazione del model-
mentre il team di testing, nonostante abbia lo fino a trovare quella che permette di veri-
1 utilizzato più della metà del tempo speso nel-
l’attività di model checking dall’altro team,
ficare (o falsificare) effettivamente la formu-
la, eliminando i falsi positivi o falsi negativi
non ha potuto rilevare alcun errore. che possono risultare dalla verifica fatta sul
sistema astratto.
Il più noto tra i software model checker è Java-
7. SOFTWARE MODEL
CHECKING PathFinder, realizzato in un progetto sviluppa-
to dalla Nasa per verificare i programmi Java.
0 La seconda tendenza, che possiamo conside-
rare ancora in via di sviluppo, è quella dell’ap-
JavaPathFinder comprende il traduttore Ban-
dera da Java Bytecode ad un certo numero di
plicazione diretta delle tecniche di verifica al noti model checkers.
codice prodotto, e va sotto il nome di “Softwa- Infatti, lo strumento fornisce una Java Virtual
re Model Checking”. Machine che non esegue normalmente il by-
In questo caso, l’approccio è opposto a quello tecode, ma controlla direttamente su questo
visto in precedenza: si parte dal codice, in qua- le proprietà da verificare. JavaPathFinder è
lunque modo sviluppato, e se ne ricava lo spa- stato usato per verificare software installati
zio degli stati. Essenziale è in questo approc- su sonde spaziali, in particolare si riporta l'in-
cio l’adozione di potenti tecniche di astrazio- dividuazione e la correzione durante il volo di
ne, che siano in grado di ridurre sostanzial- un errore nel software a bordo della sonda
mente la dimensione dello spazio degli stati, Deep Space DS-1.
senza incidere sulla soddisfacibilità o meno Ci riferiamo alla tabella 2 per un elenco di alcu-
delle proprietà da provare. ni software model checkers di libera distribu-
Il lavoro pionieristico all'applicazione diretta zione. In particolare tra questi vogliamo citare
del model checking al codice è stato fatto al- SLAM, sviluppato da Microsoft e utilizzato per
la NASA dalla fine degli anni ‘90 adottando verificare che i driver di Windows rispettino le
due diverse strategie: la prima, traducendo il convenzioni API.
codice nel linguaggio di input di un model In entrambe le tendenze (Model Based Verifi-
checker esistente, per esempio traducendo cation e Software Model Checking) una diffi-
in PROMELA, linguaggio di input per SPIN. In coltà intrinseca, che talvolta frena l’adozione
secondo luogo, attraverso lo sviluppo di mo- del model checking nella produzione del
del checker ad hoc che prendano direttamen- software, è quella relativa all’espressione
te i programmi come input. In entrambi i casi, delle proprietà desiderate in logica tempora-
vi è la necessità di estrarre dal codice un mo- le. A questa difficoltà alcuni strumenti di mo-
dello a stati finiti, anche quando esso abbia del checking ovviano fornendo all’utente lin-
teoricamente un numero infinito di stati, e guaggi più amichevoli ma meno espressivi
comunque con l’obiettivo di diminuire lo spa- che propongono proprietà di default “built-
zio degli stati ad una dimensione gestibile. in” nel sistema oppure suggeriscono tramite
L’astrazione è quindi la chiave per il model dei template come le proprietà possono es-
checking del software ed ha lo scopo di elimi- sere scritte.
nare i dettagli irrilevanti al fine della verifica
delle proprietà.
1 In questi ultimi anni sono stati sviluppati un
certo numero di software model checker
7. CONCLUSIONI
In questo articolo ci siamo limitati a descrive-
che prendono come input il codice. Alcune re sommariamente la tecnica del model
0 caratteristiche comuni di questi sono l'uso
nella maggior parte dei casi di una rappre-
ckecking e le sue applicazioni alla verifica del
software, che si stanno via via consolidando
36
M O N D O D I G I T A L E • n . 2 - 3 - g i u g n o - s e t t e m b r e 2 0 1 10
Strumenti di model checking Linguaggio di descrizione Linguaggio di specifica
dei modelli delle proprietà
SMV- NuSMV Reti di macchine a stati CTL
http://www.cs.cmu.edu/~modelcheck/smv.html che comunicano
attraverso variabili
http://www.kenmcmil.com/smv.html condivisa
http://nusmv.fbk.eu/
SPIN PROMELA PLTL
1
http://spinroot.com/spin/whatispin.html
Model checker per sistemi temporizzati
KRONOS Automi temporizzati Timed CTL
http://www-verimag.imag.fr/~tripakis/openkronos.html
UPAALL Automi temporizzati Timed CTL
0
http://www.uppaal.com/
Model checker probabilistici
PRISM Catene di Markov a tempo PCTL, CSL, LTL, PCTL*,
discreto e continuo,
http://www.prismmodelchecker.org/ processi di decisione
markoviani
MRMC Modelli di Markov con PCTL, CSL, PRCTL, CSRL
ricompensa, a tempo
http://www.mrmc-tool.org/trac/ discreto e a tempo
continuo
Software model checkers
BLAST Programmi C Annotazioni C
http://mtc.epfl.ch/software-tools/blast/index-epfl.php
CPAChecker
http://cpachecker.sosy-lab.org/
SLAM
http://research.microsoft.com/en-us/projects/slam/
CBMC Programmi ANSI-C e C++ Asserzioni C
http://www.cprover.org/cbmc/
JAVAPATHFINDER Java™ bytecode Annotazioni JPF, API
http://javapathfinder.sourceforge.net/ di verifica
TABELLA 2
Alcuni dei model checker di pubblico dominio
specialmente in determinati settori della pro- prietà di interesse quantificano con esattezza gli
duzione del software. intervalli di tempo in cui azioni e reazioni del si-
L’attività di ricerca su questa tecnica è ancora stema debbano avvenire, e quella del model
molto attiva e promette un suo più vasto utilizzo
in vari ambiti dello sviluppo di sistemi informati-
checking probabilistico, dove si vuole valutare
quale sia la probabilità che un modello goda di
1
ci. Tra le direzioni di ricerca più seguite negli ulti- una certa proprietà, aprendo la strada all’utiliz-
mi anni possiamo citare quella sui sistemi tem-
porizzati, quali i sistemi real-time, in cui le pro-
zo del model checking nella valutazione quanti-
tativa delle caratteristiche di un sistema. 0
37
M O N D O D I G I T A L E • n . 2 - 3 - g i u g n o - s e t t e m b r e 2 0 1 10
Bibliografia ming Languages and Systems, Vol. 8, n. 2,
1986, p. 244-263.
[1] Clarke Edmund M., Emerson E. Allen: Design
and synthesis of synchronization skeletons [4] Clarke Edmund M., Grumberg Orna, Peled Do-
using branching time temporal logic. Proc. of ron: A Model Checking. Cambridge, MA: MIT
Workshop in Logics of Programs. 1981. Press, 1999.
[2] Quielle Jean-Pierre, Sifakis Joseph: Specifica- [5] Baier Christel, Katoen Joost-Pieter: Principles
tion and verification of concurrent systems in of model checking. MIT Press, Vol. I-XVII,
CESAR. In: Proc. of Symposium on Program- 2008, p. 1-975.
1 ming 1982, p. 337-351.
[3] Clarke Edmund M., Emerson E. Allen, Sistla A.
[6] Holzmann Gerard J.: The SPIN Model Checker.
Addison-Wesley Professional, 2003.
Prasad: Automatic verification of finite-state [7] Miller Steven P., Whalen Michael W., Cofer Darren
concurrent systems using temporal logic spe- D.: Software model checking takes off. Commu-
cifications. ACM Transactions on Program- nication of ACM, Vol. 53, n. 2, 2010, p. 58-64.
0
STEFANIA GNESI è dirigente di ricerca presso il CNR-ISTI ed è responsabile del gruppo di Metodi Formali e Tool
dell’ISTI. È stata coordinatrice del gruppo di lavoro dell’ERCIM su Fomal Methods for Industrial Critical Sy-
stems. È attualmente vicepresidente dell'associazione Formal Methods Europe. Ha coordinato vari progetti
nazionali su metodi e strumenti formali per l’analisi e verifica di sistemi software e ha partecipato a diversi
progetti Europei. Svolge attività didattica nel Corso di Laurea Magistrale in Informatica dell’Università di Fi-
renze tenendo lezioni su “Metodi e Strumenti per l’Analisi e la Verifica”.
E-mail: stefania.gnesi@isti.cnr.it
ALESSANDRO FANTECHI è Professore Ordinario presso la Facoltà di Ingegneria dell’Università di Firenze, dove in-
1 segna Informatica Industriale per il Corso di Laurea in Ingegneria Informatica, e Elementi di Software Depen-
dability per il Corso di Laurea Magistrale. I principali interessi di ricerca vertono su applicazioni di metodi for-
mali di specifica e verifica, temi sui quali ha intessuto numerose collaborazioni con aziende produttrici di si-
stemi safety-critical. Dal Novembre 2008, è coordinatore dello Working Group “Formal Methods for Industrial
0 Critical Systems” del consorzio Europeo ERCIM.
E-mail: fantechi@dsi.unifi.it
38
M O N D O D I G I T A L E • n . 2 - 3 - g i u g n o - s e t t e m b r e 2 0 1 1Puoi anche leggere
