Verifica parte IV Rif. Ghezzi et al. 6.8-6.9
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)
Individuazione dell errore Ridurre la distanza fra errore e fallimento. Strategia: rendere visibile lo stato del programma: esecuzione controllata (debugger) asserzioni istruzioni di output
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)
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
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
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
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
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
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
Calcolo di (t) FI ( t) = '( t) l Equazione differenziale d = k( 1- / ) dt d = kdt (1 - / ) - d = ( - ) kdt Verifica 4 11
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 0 0 0 = k t Verifica 4 12
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
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
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
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
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
Confronto fra modelli: FI FI FI 0 Basic model q Logarithmic model Verifica 4 18
Confronto fra modelli: Logarithmic model Basic model t Verifica 4 19
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
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
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
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
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
Esempio Verifica 4 25
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
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
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
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
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
Esempio a b c d e f g h a b c d e f g h P 1 1 1 1 0 0 0 0 Q 1 1 0 0 0 0 1 1 R 0 0 1 1 1 1 0 0 S 0 0 0 0 1 1 1 1 l P, Q ed R si possono prendere come base l S = -P + Q + R l Numero ciclomatico C = 3 Verifica 4 31
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
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