4 Caso di studio

Utilizzando il model checking possibile supportare lo sviluppo di un sistema software con una procedura che parte dalla denizione di un modello del sistema per individuarne meglio le caratteristiche salienti senza dover subito occuparsi degli aspetti implementativi, specicare delle propriet in modo rigoroso con logiche temporali e infine vericare tali propriet allo scopo di cercare di dimostrarne la validit o di identificare errori nelle scelte progettuali; pi precisamente la procedura con cui viene effettuata lattivit di modellazione e verifica con il model checking la seguente: 1. denizione di un modello formale del sistema in via di sviluppo; per il model checking il formalismo utilizzato in generale definito mediante strutture di Kripke, una sorta di macchine a stati finiti; 2. specifica di un insieme di propriet mediante logiche temporali (LTL o CTL), formulate su attributi del modello definito precedentemente; 3. esecuzione di verifica automatica delle propriet definite al punto 2 mediante strumenti che implementano tale verifica.

4.1 Modello del sistema

Consideriamo un semplice esempio per mostrare come vengono utilizzate le strutture di Kripke per rappresentare alcune caratteristiche dei sistemi reali: il caso considerato quello di un forno a microonde che pu avere quattro possibili configurazioni (stati), pu ricevere o eseguire comandi e per il quale sono fornite le seguenti specifiche: il forno si trova inizialmente in uno stato in cui non ha ricevuto nessun comando, non sta svolgendo alcuna attivit e la porta chiusa; il forno pu ricevere il comando start, ma non pu avviare la cottura se la porta non viene chiusa; se il forno riceve il comando start e la porta chiusa allora pu avviare la cottura;

Illustrazione 1: Modello di forno automatico

durante la cottura, il forno pu ricevere il comando di start, aprendo la porta e mettendo in pausa la cottura; al termine della cottura, il forno entra in uno stato di fine, in cui attende l'apertura della porta.

Il modello che rappresenta le specifiche suddette riportato nell'Illustrazione 1. La struttura definisce il valore della funzione L per ogni stato, ossia il valore di verit di ogni variabile (close, start, cooking), linsieme degli stati S = (S0, S1, S2, S3) e linsieme R delle transizioni.

4.2 Propriet
Le logiche temporali consentono di esprimere propriet relative allevoluzione del sistema nel tempo. da sottolineare che con il model checking possibile dimostrare che un modello soddisfa una certa propriet, ma impossibile dimostrare che la specifica di una propriet o di un insieme di propriet copra linsieme di tutte le propriet soddisfacibili dal sistema. Safety Properties sono propriet che esprimono una condizione che deve sempre verificarsi oppure una condizione di pericolo che non si deve mai vericare per la sicurezza del sistema; nel caso dellesempio una propriet di safety potrebbe essere la seguente: LTL: G(cooking ~open U cooking) che vuole significare che deve essere sempre vero che se il forno attivo prima deve essere stata chiusa la porta e che deve rimanere chiusa fintanto che il forno attivo. Banalmente, questa propriet equivalente alla propriet della logica proposizionale: cooking ~open che pu essere verificata con una semplice analisi degli stati, notando che non esiste alcuno stato in cui permesso che la porta sia aperta e la cottura attiva. utile notare che un'analisi siffatta richiede un tempo lineare nel numero degli stati, laddove, invece, verificare l'equivalente propriet LTL avrebbe richiesto un tempo esponenziale. Liveness Properties LTL: G(cooking F(finished)) ovvero che ogni cottura deve essere, prima o poi, portata a termine. abbastanza semplice notare, guardando il diagramma a stati del modello, che esso non gode di questa propriet, e la sequenza di input (start, open, close, ) porta il forno in un ciclo infinito che visita infinitamente spesso lo stato di accettazione, ma non porta mai a compimento la cottura. A differenza della propriet precedentemente analizzata, questa non pu essere ridotta ad analisi sui singoli stati, perch esprime due condizioni che devono essere verificate in istanti diversi di tempo, e supera il potere espressivo della logica proposizionale.

4.3 Model checking

Si procede, ora, a simulare l'esecuzione dell'algoritmo di model checking che fa uso di DFS annidata per la verifica della propriet G(cooking F(finished)) sul modello illustrato in sezione 4.1.
Negazione della propriet

Il primo passo per la verifica consiste nella negazione della formula. Si passa, quindi, a G(cooking F(finished))
Forma normale negata

(1)

Per poter trasformare la propriet in un automa di Bchi, prima necessario effettuare alcune trasformazioni, in modo da ricondurre la formula ad una forma normale, in cui le negazioni si applicano solamente a singole variabili: G(cooking F(finished) F((cooking F(finished)) F(cooking F(finished)) F(cooking G(finished))
Da LTL a Bchi

Dalla formula { F(cooking G(finished)) }, precedentemente ricavata, si passa ad un automa di Bchi equivalente:

Illustrazione 2: Automa Bchi corrispondente alla propriet di liveness L'automa rappresentato nell'Illustrazione 2 utilizza una notazione compatta, in cui, per esempio, con l'etichetta cooking sulla transizione da P0 a P1, si indica che tale transizione viene eseguita in presenza di un qualunque assegnamento delle variabili di stato avente cooking=TRUE.

Prodotto sincrono degli automi A questo punto, necessario produrre il prodotto dei due automi, per poi verificarne la vuotezza del linguaggio accettato. Tuttavia, i lettori attenti non avranno mancato di notare che l'automa che rappresenta il sistema e quello che rappresenta la propriet hanno due alfabeti diversi. Infatti, il primo definito sull'alfabeto dei comandi in input, mentre il secondo definito sull'insieme delle parti delle variabili di stato del sistema.

Illustrazione 3: Automa di Bchi usato per rappresentare il modello nell'algoritmo di verifica Di fatto, in questa fase, l'automa che rappresenta il sistema non viene usato nella sua forma originale. Invece, si utilizza un automa che ha lo stesso insieme di stati e le stesse transizioni, in cui, tuttavia, queste ultime sono etichettate con l'insieme dei valori delle variabili di stato che caratterizzano lo stato finale della transizione. In questo modo, si lavora con una coppia di automi definita sullo stesso alfabeto, che l'insieme delle parti delle variabili di stato.

Illustrazione 4: Prodotto sincrono del modello S e della propriet P A questo punto, possibile procedere con il prodotto sincrono tra i due automi, il cui risultato l'automa di Bchi generalizzato raffigurato nell'Illustrazione 4.

Degeneralizzazione dell'automa

L'ultimo passo preparatorio consiste nella de-generalizzazione dell'automa prodotto, che porta ad un automa di Bchi deterministico equivalente:

Illustrazione 5: Degeneralizzazione dell'automa dell'Illustrazione 4 Questo automa, com' stato gi spiegato, ha la propriet di accettare tutte e sole le esecuzioni accettate dal modello che non soddisfano la propriet verificata. A occhio, come anticipato, possibile notare che possibile individuare il ciclo tra gli stati GCD, che visita infinitamente spesso lo stato di accettazione D. Questo conferma l'osservazione iniziale che il modello preso in considerazione non corretto rispetto alle propriet richieste. Questo verr meglio dimostrato dall'esecuzione dell'algoritmo di DFS annidata.
DFS annidata

Si pu, infine, procedere all'esecuzione della DFS annidata, per cercare un input accettato dall'automa dell'Illustrazione 5. La visita di primo livello parte dallo stato iniziale. Questo stato gi di accettazione. Pertanto, essa viene immediatamente sospesa, per passare alla visita di secondo livello. Lo stato A non ha transizioni entranti. Pertanto, la DFS di secondo livello visita l'intero insieme degli stati senza trovare alcun ciclo che permetta di tornare ad A. Continua, quindi, la visita di primo livello, fino a raggiungere lo stato D, unico altro stato di accettazione, attraverso il cammino (A, G, C, D). Si passa, quindi, alla visita di secondo livello. La visita di secondo livello termina alla prima iterazione, con il cammino (D, G), per aver raggiunto lo stato G, che gi stato visitato dal primo livello di DFS. Viene, quindi, determinato che, qualunque input porti l'automa ad attraversare gli stati (A, G, C, D, G, C, D, ), viene accettato dall'automa dell'Illustrazione 5 e, pertanto, costituisce un esempio del fatto che il modello descritto in Illustrazione 2 non soddisfa la propriet di liveness precedentemente espressa.

Costruzione del controesempio

Si deve, ora, costruire un input di esempio. Osservando l'Illustrazione 5, si nota che il ciclo (A, G, C, D, G, C, D, ) corrisponde, nell'automa S, al ciclo (S0, S2, S1, S0, S2, S1, S0, ). Leggendo le transizioni nell'Illustrazione 1, facile ricavare la sequenza di input (start, open, close, start, open, close, ), che, com' possibile notare, viene accettata da S, ma visita una sequenza di stati in cui la cottura non viene mai portata a compimento. L'algoritmo, quindi, restituir il controesempio =start , open , close . =start , open , close