Corso di Laurea Triennale in Ingegneria Corso di Laurea Triennale in Ingegneria InformaticaInformatica

Ingegneria del softwareIngegneria del software

Metodi formali nell’ingegneria del softwareMetodi formali nell’ingegneria del software

Guasti softwareSistemi criticiMetodi formali

Verifica formaleModel checking

Ingegneria del Ingegneria del softwaresoftware I guasti softwareI 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 Ingegneria del softwaresoftware Errori 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 Ingegneria del softwaresoftware Classificazione dei fallimentiClassificazione 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 Ingegneria del softwaresoftware Fallimenti benigniFallimenti 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 Ingegneria del softwaresoftware Fallimenti catastroficiFallimenti 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 Ingegneria del softwaresoftware Classificazione dei sistemi criticiClassificazione 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 Ingegneria del softwaresoftware Dependability 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 Ingegneria del softwaresoftware Attributi della dependabilityAttributi 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 Ingegneria del softwaresoftware Altri aspetti della dependabilityAltri 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 Ingegneria del softwaresoftware

Attributi di dependability dei Attributi di dependability dei sistemi embeddedsistemi 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 Ingegneria del softwaresoftware Metodi per ottenere dependabilityMetodi 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 Ingegneria del softwaresoftware Guasti softwareGuasti software

• Un guasto software (bug) è un guasto interno, umano, di progetto, in genere non intenzionale.

Ingegneria del Ingegneria del softwaresoftware Dependability del softwareDependability 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 Ingegneria del softwaresoftware Il caso Ariane 5Il caso Ariane 5

• 4 giugno 1996, il primo lancio del vettore spaziale Ariane 5 risultò un 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

• In termini della catena: guasto-errore-fallimento– 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 Ingegneria del softwaresoftware Cause dell’incidenteCause 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 Ingegneria del softwaresoftware Tipologia dei guasti nell’Ariane 5Tipologia dei guasti nell’Ariane 5

• Si tratta di guasti interni, umani, di progetto, non intenzionali

Ingegneria del Ingegneria del softwaresoftware Altri esempi di guasti softwareAltri 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 Ingegneria del softwaresoftware Altri guasti softwareAltri 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 Ingegneria del softwaresoftware Altri guasti softwareAltri 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 Ingegneria del softwaresoftware Altri guasti softwareAltri 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 Therac-25 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 Ingegneria del softwaresoftware Metodi formaliMetodi 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 Ingegneria del softwaresoftware Definizione 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 Ingegneria del softwaresoftware

Verifica formale del codice Verifica formale del codice sorgentesorgente

• 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 Ingegneria del softwaresoftware Logica di HoareLogica 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 Ingegneria del softwaresoftware Regole della logica di HoareRegole 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; Precondizione i==0while (i<n) 0<j<=k => a[j-1]==0&&i==k{a[i]=0; invariante al k-esimo cicloi++;}

Postcondizione 0<j<=n => a[j-1]==0 &&i ==n

Ingegneria del Ingegneria del softwaresoftware Invariante 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 Ingegneria del softwaresoftware Model checkingModel 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 Ingegneria del softwaresoftware Model checkingModel 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 Ingegneria del softwaresoftware VantaggiVantaggi

• 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 Ingegneria del softwaresoftware Model checkerModel 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 Ingegneria del softwaresoftware Struttura di KripkeStruttura 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 Ingegneria del softwaresoftware Computation Tree Logic (CTL)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 Ingegneria del softwaresoftware Quantifiers and OperatorsQuantifiers 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...

• AG f• AF f• A(f1 U f2)• AX f

• EG f• EF f• E( f1 U f2)• EX f

Allowed combinations:– Quantifier +

Operator

Ingegneria del Ingegneria del softwaresoftware Sintassi 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 Ingegneria del softwaresoftware Definizioni 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 Ingegneria del softwaresoftware Semantica 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 Ingegneria del softwaresoftware L’algoritmoL’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 Ingegneria del softwaresoftware Verifica 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 Ingegneria del softwaresoftware Model checking CTLModel 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 Ingegneria del softwaresoftware Esempio mutua esclusioneEsempio 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 Ingegneria del softwaresoftware Esempio: mutua esclusioneEsempio: 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 Ingegneria del softwaresoftware Esempio: mutua esclusioneEsempio: mutua esclusione

N1 N2

T1 N2 N1 T2

C1 N2 T1 T2 N1 C2T1 T2

C1 T2 T1 C2

Ingegneria del Ingegneria del softwaresoftware Formula da verificareFormula 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 Ingegneria del softwaresoftware Etichettamento Etichettamento

1. Il processo di etichettamento inizia con l’etichettatura delle formule di lunghezza 1

~Ti e

AF Ci2. 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 Ingegneria del softwaresoftware

Esempio: mutua esclusione - Esempio: mutua esclusione - etichettamentoetichettamento

N1 N2 ~ T1 ~ T1 ν AF

C1

T1 N2 AF C1 ~ T1 ν AF

C1

N1 T2 ~ T1 ~ T1 ν AF C1

C1 N2 ~ T1 AF C1 ~ T1 ν AF

C1

C1 N2 ~ T1 AF C1 ~ T1 ν AF

C1

N1 C2 ~ T1 ~ T1 ν AF C1

T1 T2 AF C1 ~ T1 ν AF C1

C1 T2 ~ T1 AF C1 ~ T1 ν AF

C1T1 C2 AF C1 ~ T1 ν AF C1

Ingegneria del Ingegneria del softwaresoftware Osservazioni 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 Ingegneria del softwaresoftware Riferimenti 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.