Verifica parte IV. Debugging. Individuazione dell errore. Debugger

Transcript

1 Debugging Verifica pare IV Rif. Ghezzi e al Individuazione e correzione degli errori Conseguene a un fallimeno Aivià non banale: Quale errore ha causao il fallimeno? Come correggere l errore? La correzione dell errore ha effei collaerali (cioè genera alri errori)? (es di regressione) Individuazione dell errore Debugger Ridurre la disanza fra errore e fallimeno. Sraegia: rendere visibile lo sao del programma: esecuzione conrollaa (debugger) asserzioni isruzioni di oupu Aiua nell individuazione degli errori senza modifiche al codice sorgene Funzionalià di base: esecuzione sep by sep breapoin valuaore di espressioni wach (brea se il valore di una variabile cambia)

2 Affidabilià Peculiarià del sofware Definia come la probabilià che un sofware funzioni correamene in un deerminao inervallo di empo Negli ulimi anni sono sai concepii modelli che consenono di simare e di prevedere l affidabilià di un sisema sofware. Muuai da alri ambii (hardware o ingegneria indusriale) Il sofware non è soggeo a corruzione o usura fisica Il sofware non presena errori ransieni e non necessia di rodaggio Gli esemplari di un sofware sono uguali fra loro Mancanza di coninuià Verifica 4 5 Verifica 4 6 Quanià legae all affidabilià Tempo AF(), numero medio di fallimeni dopo un empo. Misura media su diverse insallazioni del sisema Esensione derivabile della funzione FI(), inensià di fallimeno Fallimeni per unià di empo Derivaa di AF rispeo a MTTF, mean ime o failure Tempo medio fra due fallimeni Reciproco di FI Calendar ime: empo oale rascorso dall insallazione comprende il empo in cui il sisema è fermo Tempo di esecuzione: empo di funzionameno del sofware comprende il empo in cui la piaaforma è allocaa per alri processi Tempo di cloc: empo effeivo di esecuzione del sofware sulla piaaforma. Verifica 4 7 Verifica 4 8

3 Modelli di affidabilià Ipoizzano una relazione fra l inensià di errore e il numero medio di fallimeni. Con l ipoesi faa, si uilizzano srumeni maemaici per simare l andameno del numero medio di fallimeni nel empo. Il puno criico è la scela della relazione, basaa su considerazioni sulla naura del processo e del prodoo sofware. Modello base Ipoizza che l inensià di fallimeno decresca di una cosane per ogni fallimeno FIAF=1 AF / dove è il numero oale di fallimeni (ignoo) e è una cosane Daa quesa ipoesi, si può deerminare AF() Verifica 4 9 Verifica 4 10 Calcolo di AF() FI=AF' Equazione differenziale daf d =1 AF/ daf 1 AF / =d daf AF =d Calcolo di AF() Inegrando enrambi i membri Supponendo si oiene dy y = du [ logy ] AF 0 AF = 0 logaf log = AF 0 = 0 0 = 0 Verifica 4 11 Verifica 4 12

4 Calcolo di AF() Essendo 0 AF log AF log = log AF = Esponenziale di enrambi i membri: AF =e AF= 1 e Calcolo di FI è la derivaa di AF rispeo a : FI= Sosiuendo 0 a : =FI 0 e Verifica 4 13 Verifica 4 14 Modello logarimico Suppone che il decremeno di FI per ogni fallimeno decresca esponenzialmene: FI=e θaf dove θ è un paramero deo decadimeno dell inensià di fallimeno Calcolo di AF() Equazione differenziale: Separazione delle variabili: Inegrazione di enrambi i membri: daf d =e θaf daf =d θaf e dy e θy = du Verifica 4 15 Verifica 4 16

5 Calcolo di AF() Confrono fra modelli: FI Risulao dell inegrazione: 1 θ [eθy ] 0 AF = [u]0 FI FI 0 Cioè e θaf 1 =θ Calcolo di FI= 1 1 θ 1 +θ θ AF= 1 θ log1+θ =FI0 θ Basic model Logarihmic model AF AF Verifica 4 17 Verifica 4 18 Confrono fra modelli: AF Calcolo dei parameri AF Logarihmic model Basic model e θ non sono noi a priori Possono essere simai ramie osservazione di AF() Il risulao permee di simare l andameno dell affidabilià nel empo Modelli diversi per classi diverse di applicazioni. Verifica 4 19 Verifica 4 20

6 Verifica di qualià soggeive Sofware science (Halsead) Qualià del sofware come complessià comprensibilià riusabilià sono largamene soggeive C è comunque richiesa di meriche per la misurazione di quese qualià Le propose hanno generalmene applicabilià limiaa ad alcune classi di applicazioni. Cerca di dare misure e sime quaniaive di qualià soggeive, quali difficolà livello di asrazione sforzo Le misure sono dae in ermini di quanià oggeive Verifica 4 21 Verifica 4 22 Quanià Esempio η 1 : numero di operaori unici e disini η 2 : numero di operandi unici e disini N 1 : numero oale di occorrenze di operaori N 2 : numero oale di occorrenze di operandi η 2* : numero di operandi conceuali di ingresso/uscia disini Verifica 4 23 Verifica 4 24

7 Lunghezza del programma Vocabolario del programma η = η 1 + η 2 Lunghezza del programma N = N 1 + N 2 Sima di N: N* = η 1 log 2 η 1 + η 2 log 2 η 2 Calcoli su algorimi pubblicai indicano un valore dell errore medio (N* - N) / N inferiore al 10% (nell esempio, N=30, N*=38). Uile per sime se dall inizio si possono simare η 1 ed η 2, ad esempio in base a saisiche su applicazioni simili Sima di N Volume di programma: numero di bi necessario a codificare ogni elemeno di programma V = N * log 2 η Volume poenziale: quello del programma più sineico in cui si può codificare l algorimo (disponibile come operazione predefinia): N = η = 2 + η 2 * V * = (2 + η 2* ) log 2 (2 + η 2* ) Verifica 4 25 Verifica 4 26 Livello di programma e sforzo L = V * / V Tena di misurare il livello di asrazione di un programma E = V / L = V 2 / V * Misura la difficolà dell implemenazione, manuenzione, comprensione del programma. Risulai sperimenali soddisfaceni: mosrano la dipendenza della complessià dal linguaggio. Teoria di McCabe Sima la complessià di un programma (per quano riguarda produzione, comprensione, modifica). Basaa sulla eoria dei grafi Complessià conceuale di un programma (per codifica, correzione, manuenzione) legaa alla complessià del suo flusso di conrollo Verifica 4 27 Verifica 4 28

8 Numero ciclomaico Esempio Rappresenazione veoriale dei cammini in un grafo a n archi. Ogni cammino è un veore di n componeni, ognuno uguale al numero di vole che l arco corrispondene è percorso. a b c d e f g h a b c d e f g h P Q R S Numero ciclomaico: numero di cammini linearmene indipendeni. Verifica 4 29 Verifica 4 30 Risulai eorici C = e n + 2p, dove e è il numero di archi n è il numero di nodi p è il numero di componeni connesse del grafo (normalmene una per ogni procedura) C = d + 1, dove d è il numero di puni di decisione (a 2 uscie) del programma Un puno di decisione a uscie è conao come -1 puni di decisione a 2 uscie (raduzione da cosruo case a cosruo if) Numero ciclomaico e complessià Il numero ciclomaico dà un idea immediaa della complessià del flusso di conrollo di un programma. Non iene però cono di alri aspei, come la complessià delle sruure di dai. Sperimenalmene risula correlao al numero di errori risconrai. Un modulo di un sisema ben progeao dovrebbe avere C fra 3 e 7, e non superare 10 (conferme empiriche). Verifica 4 31 Verifica 4 32

9 Approccio Goal Quesion Meric Approccio Goal Quesion Meric Cerca di inegrare e superare le meriche propose da Halsead, McCabe e alri. Presupposi: Qualsiasi merica deve essere usaa per analizzare la qualià, non per valuare le persone In caso conrario, i progeisi cercheranno non di produrre buon sofware, ma di massimizzare le meriche (es. linee di codice) La valuazione di qualià deve riguardare non solo il prodoo, ma anche il processo. Le misure di qualià vanno definie non solo per il prodoo finale, ma anche per ui i prodoi inermedi. Le grandezze da misurare vanno scele in base agli obieivi da raggiungere. Le misure e le linee guida sui valori oimali vanno convalidai in base alle esperienze concree. Verifica 4 33 Verifica 4 34 Fase 1: definizione dell obieivo (goal) Schema generale: analizzare <ambio dello sudio> con l obieivo di <obieivo> le <caraerisiche> dal puno di visa di <saeholder> nel coneso di <il coneso operaivo> Ambio dello sudio: processo, prodoo, fase del processo Fase 1: definizione dell obieivo (goal) Obieivo: caraerizzare, valuare, prevedere, migliorare Caraerisiche: coso, correezza, affidabilià, usabilià Saeholder: uene, progeisa, manager, impresa Coneso operaivo: organizzazione, impresa, gruppo Verifica 4 35 Verifica 4 36

10 Fase 1: esempi Analizzare il sisema informaivo allo scopo di simare il coso dal puno di visa del manager nel coneso di una sofware house Analizzare la fase di es allo scopo di migliorare l affidabilià dal puno di visa dell uene finale nell ambio di un impiano manifauriero Analizzare la specifica dei requisii allo scopo di valuare la comprensibilià dal puno di visa del programmaore nel coneso di una sofware house Fase 2: definizione delle domande (quesion) Individuare domande la cui risposa ha l obieivo di definire il goal Esempi: Esisono malfunzionameni criici nell uso del sisema? oppure Qual è il MTTF? (affidabilià) Qual è lo sforzo necessario per la fase di es? (coso) Verifica 4 37 Verifica 4 38 Fase 3: definizione delle meriche (meric) Merica appropriaa per ogni domanda: Esempi: Criicià di un malfunzionameno: valore da 1 a 10 aribuio dall uene ( pesao in base alla compeenza?) Coperura del codice sorgene in fase di es: percenuale (righe di codice, isruzioni, decisioni) GQM nella praica Meodologia ampia, in evoluzione Valuazioni informali (qualià soggeive) ma sforzo per arrivare a misure oggeive Le decisioni (soprauo domande e misure) vanno convalidae a poseriori Le meriche sono arbirarie, ma devono rispeare alcune condizioni per essere significaive Verifica 4 39 Verifica 4 40

11 Condizioni su meriche: esempi Linee guida La merica di complessià C(P) di un frammeno di codice deve essere ale che, se P;Q è la composizione di due frammeni P e Q sia C(P;Q) C(P) Se D(P) è la misura della dimensione di un programma, D(P) 0 D(P) = 0 se e solo se P è il programma nullo Se P e Q sono disgiuni (cioè non condividono alcun elemeno) D(P;Q) = D(P) + D(Q) La definizione di meriche dovrebbe enere cono delle caraerisiche che influenzano il goal desiderao. Esempio: riusabilià modularià ala coesione, basso accoppiameno rapporo fra meodi pubblici e privai Per ogni merica, dovrebbero essere definie soglie il cui superameno richiede un esame del prodoo o del processo. Verifica 4 41 Verifica 4 42