Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software Metodi formali nellingegneria del software Guasti software Sistemi critici.

Presentazione sul tema: "Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software Metodi formali nellingegneria del software Guasti software Sistemi critici."— Transcript della presentazione:

1 Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software Metodi formali nellingegneria del software Guasti software Sistemi critici Metodi formali Verifica formale Model checking

2 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 dalluomo –Confini del sistema: Guasti interni: parti del sistema che producono errori Guasti esterni: causati dallinterferenza dellambiente fisico nel sistema o dallinterazione con luomo –Fase di creazione: Guasti di progetto Guasti operativi –Persistenza temporale: Guasti permanenti Guasti temporanei

3 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 è leffetto 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.

4 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 sullambiente –Consideriamo di seguito la classificazione relativa soltanto alle conseguenze del fallimento sullambiente, 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

5 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

6 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.

7 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)

8 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.

9 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 laspettativa principale sul servizio è data dalla sua prontezza di risposta Reliability: affidabilità – se laspettativa riguarda la fornitura continua del servizio per un tempo sufficientemente lungo, Safety: sicurezza – se laspettativa principale è la garanzia di evitare situazioni catastrofiche e danni allambiente o alle persone Security: sicurezza - se laspettativa è la prevenzione di accessi non autorizzati e/o manipolazioni di informazioni private

10 Ingegneria del software Altri aspetti della dependability Pervasività: il principale aspetto da studiare a proposito di dependability è la pervasività e linevitabilità 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 è lattività di rimozione dei guasti durante il funzionamento o comunque nella vita operativa di un sistema

11 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

12 Ingegneria del software Metodi per ottenere dependability Protezione dai guasti (fault prevention): tecniche mirate a prevenire e minimizzare le occorrenze di guasti: –Comprende luso 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 ladozione 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

13 Ingegneria del software Guasti software Un guasto software (bug) è un guasto interno, umano, di progetto, in genere non intenzionale.

14 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 lintroduzione di guasti nel software Software fault removal: rimozione dei guasti software - debugging

15 Ingegneria del software Il caso Ariane 5 4 giugno 1996, il primo lancio del vettore spaziale Ariane 5 risultò un fallimento: –Dopo 36 secondi dallinizio 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 –Leccezione 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 dellaccelerazione laterale) aveva un valore superiore a quello rappresentabile con un signed integer 16 bit –Le piattaforme inerziali erano state ereditate dallAriane 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 sullAriane 4 ma inutile nellAriane 5, non eliminata per non modificare il codice già collaudato

16 Ingegneria del software Cause dellincidente 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 dellesecuzione 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

17 Ingegneria del software Tipologia dei guasti nellAriane 5 Si tratta di guasti interni, umani, di progetto, non intenzionali

18 Ingegneria del software Altri esempi di guasti software Il baco del processore Pentium 5 – Lerrore era dovuto a un difetto di progettazione dellalgoritmo 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. –Lerrore 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

19 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.

20 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.

21 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 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.

22 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

23 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 allimplementazione in modo formalmente verificabile

24 Ingegneria del software Verifica formale del codice sorgente Hoare alla fine degli anni 60 propose luso 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 lesecuzione di un pezzo di codice cambia lo stato della computazione.

25 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

26 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; Precondizione i==0 while (i a[j-1]==0&&i==k {a[i]=0;invariante al k-esimo ciclo i++; } Postcondizione0 a[j-1]==0 &&i ==n

27 Ingegneria del software Invariante Per comandi semplici (es. assegnamento ) la postcondizione si ottiene dalla precondizione modificando lasserzione sul valore della variabile toccata dallassegnamento Se il comando è un ciclo, al fine di calcolare la postcondizione occorre definire linvariante del ciclo, ovvero unasserzione che vale in un punto del corpo del ciclo and ogni iterazione.

28 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, nellesprimere una proprietà dinteresse 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

29 Ingegneria del software Model checking Definito da Edmund Clarke ( cmu), Allan Emerson ( univ. Of texas), Joseph Sifakis ( cmu), che ricevono nel 2007 lACM 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]

30 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

31 Ingegneria del software Model checker È lalgoritmo 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à.

32 Ingegneria del software Struttura di Kripke È una macchina a stati finiti, una quintupla M=(S, S 0,R,AP,L) dove: –S insieme finito di stati –S 0 è linsieme degli stati iniziali –RSxS è 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 2 AP è una funzione che assegna ad ogni stato unetichetta che contiene le proposizioni atomiche vere in quello stato.

33 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

34 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... AG f AF f A(f1 U f2) AX f EG f EF f E( f1 U f2) EX f Allowed combinations: –Quantifier + Operator

35 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 φ

36 Ingegneria del software Definizioni Un cammino π è una sequenza finita di stati tale che per ogni i0, (s i,s i+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

37 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 A ψ π a partire da s, π ψ s E ψ π a partire da s, tale che π ψ π X φ π=s 0,s 1,s 2,…,s n,.. s 1 φ π φ 1 U φ 2 π=s 0,s 1,s 2,…,s n,.. i: s i φ 2 k<i, S k φ 1 π Fφ π =s 0,s 1,s 2,…,s n,.. i: si φ π Gφ π=s 0,s 1,s 2,…,s n,.. i: s i φ

38 Ingegneria del software Lalgoritmo 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 nelletichettare 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.

39 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.

40 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

41 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

42 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 limplementazione non deve consentire che tutti e due i processi si trovino nella sezione critica

43 Ingegneria del software Esempio: mutua esclusione N1 N2 T1 N2N1 T2 C1 N2T1 T2 N1 C2 T1 T2 C1 T2 T1 C2

44 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)

45 Ingegneria del software Etichettamento 1.Il processo di etichettamento inizia con letichettatura delle formule di lunghezza 1 ~Ti e AF Ci 2.Quindi procede con letichettatura dei nodi per cui valgono le formule di lunghezza 2. Cioè la formula: ~Ti AF Ci 3.Si procede con letichettatura 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.

46 Ingegneria del software Esempio: mutua esclusione - etichettamento 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 N1 C2 ~ T1 ~ T1 ν AF C1 T1 T2 AF C1 ~ T1 ν AF C1 C1 T2 ~ T1 AF C1 ~ T1 ν AF C1 T1 C2 AF C1 ~ T1 ν AF C1

47 Ingegneria del software Osservazioni La descrizione dello spazio degli eventi ci permette di astrarre dalle funzionalità dei processi La complessità dellalgoritmo nel caso peggiore è lineare in termini della grandezza della formula e in termini dello spazio degli stati In caso di fallimento lalgoritmo permette di tracciare gli stati che lhanno causato Il numero degli sati del sistema cresce al più esponenzialmente con il numero dei processi indipendenti

48 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.