Verifica parte IV. Rif. Ghezzi et al

Dimensione: px

Iniziare la visualizzazioe della pagina:

Download "Verifica parte IV. Rif. Ghezzi et al"

Domenico Pippi
5 anni fa
Visualizzazioni

1 Verifica parte IV Rif. Ghezzi et al

2 Debugging Individuazione e correzione degli errori Conseguente a un fallimento Attività non banale: Quale errore ha causato il fallimento? Come correggere l errore? La correzione dell errore ha effetti collaterali (cioè genera altri errori)? (test di regressione)

3 Individuazione dell errore Ridurre la distanza fra errore e fallimento. Strategia: rendere visibile lo stato del programma: esecuzione controllata (debugger) asserzioni istruzioni di output

4 Debugger Aiuta nell individuazione degli errori senza modifiche al codice sorgente Funzionalità di base: esecuzione step by step breakpoint valutatore di espressioni watch (break se il valore di una variabile cambia)

5 Affidabilità l Definita come la probabilità che un software funzioni correttamente in un determinato intervallo di tempo l Negli ultimi anni sono stati concepiti modelli che consentono di stimare e di prevedere l affidabilità di un sistema software. l Mutuati da altri ambiti (hardware o ingegneria industriale) Verifica 4 5

6 Peculiarità del software l Il software non è soggetto a corruzione o usura fisica l Il software non presenta errori transienti e non necessita di rodaggio l Gli esemplari di un software sono uguali fra loro l Mancanza di continuità Verifica 4 6

7 Quantità legate all affidabilità l (t), numero medio di fallimenti dopo un tempo t. l Misura media su diverse installazioni del sistema l Estensione derivabile della funzione l FI(t), intensità di fallimento l Fallimenti per unità di tempo l Derivata di rispetto a t l MTTF, mean time to failure l Tempo medio fra due fallimenti l Reciproco di FI Verifica 4 7

8 Tempo l Calendar time: tempo totale trascorso dall installazione l comprende il tempo in cui il sistema è fermo l Tempo di esecuzione: tempo di funzionamento del software l comprende il tempo in cui la piattaforma è allocata per altri processi l Tempo di clock: tempo effettivo di esecuzione del software sulla piattaforma. Verifica 4 8

9 Modelli di affidabilità l Ipotizzano una relazione fra l intensità di errore e il numero medio di fallimenti. l Con l ipotesi fatta, si utilizzano strumenti matematici per stimare l andamento del numero medio di fallimenti nel tempo. l Il punto critico è la scelta della relazione, basata su considerazioni sulla natura del processo e del prodotto software. Verifica 4 9

10 Modello base l Ipotizza che l intensità di fallimento decresca di una costante per ogni fallimento FI ( ) = k(1 - / ) l dove è il numero totale di fallimenti (ignoto) e k è una costante l Data questa ipotesi, si può determinare (t) Verifica 4 10

11 Calcolo di (t) FI ( t) = '( t) l Equazione differenziale d = k( 1- / ) dt d = kdt (1 - / ) - d = ( - ) kdt Verifica 4 11

12 Calcolo di (t) l Integrando entrambi i membri - l Supponendo l si ottiene log dy ò = k 0 ( y - ) - - log- = - ò t t 0 du - [log y - ] = k( t - 0) 0 t = 0 t = k t Verifica 4 12

13 Calcolo di (t) l Essendo log 0 ( - )- log = t - log - = - k t k l Esponenziale di entrambi i membri: k - - = e t = (1 e - - k t ) Verifica 4 13

14 Calcolo di k l FI è la derivata di rispetto a t: k k - FI = - (- ) e l Sostituendo 0 a t: t k =FI 0 Verifica 4 14

15 Modello logaritmico l Suppone che il decremento di FI per ogni fallimento decresca esponenzialmente: FI = ke -q l dove q è un parametro detto decadimento dell intensità di fallimento Verifica 4 15

16 Calcolo di (t) l Equazione differenziale: d dt = ke -q l Separazione delle variabili: d e -q = kdt l Integrazione di entrambi i membri: dy ò = 0 -qy e k ò t 0 du Verifica 4 16

17 Calcolo di (t) l Risultato dell integrazione: 1 q l Cioè l Calcolo di k FI [ ] qy = [ ku] t e 0 0 e q -1 = qkt = 1 1 q 1 + qkt qk 1 = log(1 + qkt) q k = FI (0) Verifica 4 17

18 Confronto fra modelli: FI FI FI 0 Basic model q Logarithmic model Verifica 4 18

19 Confronto fra modelli: Logarithmic model Basic model t Verifica 4 19

20 Calcolo dei parametri l e q non sono noti a priori l Possono essere stimati tramite osservazione di (t) l Il risultato permette di stimare l andamento dell affidabilità nel tempo l Modelli diversi per classi diverse di applicazioni. Verifica 4 20

21 Verifica di qualità soggettive l Qualità del software come l complessità l comprensibilità l riusabilità sono largamente soggettive l Cè comunque richiesta di metriche per la misurazione di queste qualità l Le proposte hanno generalmente applicabilità limitata ad alcune classi di applicazioni. Verifica 4 21

22 Metriche l Metriche source-code l Teoria di Halstead l Teoria di Mc Cabe l Linee di Codice (LOC, SLOC) l Metriche predittive l Function Point Verifica 4 22

23 Software science (Halstead) l Cerca di dare misure e stime quantitative di qualità soggettive, quali l difficoltà l livello di astrazione l sforzo l Le misure sono date in termini di quantità oggettive Verifica 4 23

24 Quantità l h 1 : numero di operatori unici e distinti l h 2 : numero di operandi unici e distinti l N 1 : numero totale di occorrenze di operatori l N 2 : numero totale di occorrenze di operandi l h 2* : numero di operandi concettuali di ingresso/uscita distinti Verifica 4 24

25 Esempio Verifica 4 25

26 Lunghezza del programma l Vocabolario del programma h = h 1 + h 2 l Lunghezza del programma N = N 1 + N 2 l Stima di N: N* = h 1 log 2 h 1 + h 2 log 2 h 2 l Calcoli su algoritmi pubblicati indicano un valore dell errore medio (N* - N) / N inferiore al 10% (nell esempio, N=30, N*=38). l Utile per stime se dall inizio si possono stimare h 1 ed h 2, ad esempio in base a statistiche su applicazioni simili Verifica 4 26

27 Stima di N l Volume di programma: numero di bit necessario a codificare ogni elemento di programma V = N * log 2 h l Volume potenziale: quello del programma più sintetico in cui si può codificare l algoritmo (disponibile come operazione predefinita): N = h = 2 + h 2 * V * = (2 + h 2* ) log 2 (2 + h 2* ) Verifica 4 27

28 Livello di programma e sforzo l L = V * / V l Tenta di misurare il livello di astrazione di un programma l E = V / L = V 2 / V * l Misura la difficoltà dell implementazione, manutenzione, comprensione del programma. l Risultati sperimentali soddisfacenti: mostrano la dipendenza della complessità dal linguaggio. Verifica 4 28

29 Teoria di McCabe l Stima la complessità di un programma (per quanto riguarda produzione, comprensione, modifica). l Basata sulla teoria dei grafi l Complessità concettuale di un programma (per codifica, correzione, manutenzione) legata alla complessità del suo flusso di controllo Verifica 4 29

30 Numero ciclomatico l Rappresentazione vettoriale dei cammini in un grafo a n archi. l Ogni cammino è un vettore di n componenti, ognuno uguale al numero di volte che l arco corrispondente è percorso. l Numero ciclomatico: numero di cammini linearmente indipendenti. Verifica 4 30

31 Esempio a b c d e f g h a b c d e f g h P Q R S l P, Q ed R si possono prendere come base l S = -P + Q + R l Numero ciclomatico C = 3 Verifica 4 31

32 Risultati teorici l C = e n + 2p, dove l e è il numero di archi l n è il numero di nodi l p è il numero di componenti connesse del grafo (normalmente una per ogni procedura) l C = d + 1, dove d è il numero di punti di decisione (a 2 uscite) del programma l Un punto di decisione a k uscite è contato come k-1 punti di decisione a 2 uscite (traduzione da costrutto case a costrutto if) Verifica 4 32

33 Numero ciclomatico e complessità l Il numero ciclomatico dà un idea immediata della complessità del flusso di controllo di un programma. l Non tiene però conto di altri aspetti, come la complessità delle strutture di dati. l Sperimentalmente risulta correlato al numero di errori riscontrati. l Un modulo di un sistema ben progettato dovrebbe avere C fra 3 e 7, e non superare 10 (conferme empiriche). Verifica 4 33

Documenti analoghi

18/05/2014. Università di Ferrara Corso di Ingegneria del Software AA 2013/2014

18/05/2014. Università di Ferrara Corso di Ingegneria del Software AA 2013/2014 Università di Ferrara Corso di Ingegneria del Software AA 2013/2014 La misura come strumento scientifico Misure, metriche e indicatori Metriche del software Metriche per software orientato agli oggetti