1 Implementazione Significa “tradurre” la progettazione in codice scritto in un particolare linguaggio di programmazione Due scelte fondamentali: scelta del paradigma di programmazione (imperativo, funzionale, logico, ad oggetti, visuale, ecc.) e dello specifico linguaggio di programmazione (C, ML, Prolog,java, VisualBasic,…) scelta dell’ “ambiente di sviluppo”: editor, compilatore, debugger, linker, ecc. (es. CodeWarrior)

2 Un buon codice… è ben strutturato in diversi moduli e interfacce gerarchia dei moduli all’interno del singolo modulo: astrazione procedurale all’interno della singola procedura: no sequenze di istruzioni condizionali innestate ma comando switch / array di procedure no valori numerici distribuiti nel codice ma uso di costanti no variabili globali nelle procedure ma passaggio esplicito dei parametri

3 Un buon codice… è ben leggibile Stile di programmazione conforme alle convenzioni del linguaggio (indentazione) Raggruppare la dichiarazioni nelle interfacce Usare nomi significativi per gli indentificatori (di tipo, di variabile, di costante, di procedura, ecc.) Usare gli stessi criteri con cui si valuta la leggibilità di documento scritto (es. la pagina di una rivista…)

4 Un buon codice è ben documentato Header con data di creazione e di ultima modifica, autore, affiliazione Specificare ogni procedura: pre e post-condizioni e modalità di utilizzo Commentare puntualmente i “punti critici” (algoritmi e strutture dati) Isolare chiaramente le parti obsolete (vecchie versioni) e i comandi per il debugging Usare strumenti per fare della documentazione un “deliverable” che accompagna il codice

5 Verifica e Validazione Come assicurarsi che il software corrisponda alle necessità dell’utente? Introdurremo i concetti di verifica e validazione Descriveremo le fasi del processo di testing Parleremo di pianificazione del testing Descriveremo diverse strategie di testing

6 Verifica: “Stiamo costruendo il prodotto nel modo giusto?” Il software deve soddisfare la specifica Validazione: "Stiamo costruendo il prodotto giusto?" Il software deve fare quello che l’utente realmente richiede Sono domande che devono percorrere tutto il ciclo di vita del software, per correggere errori e per valutare se il prodotto è usabile dal punto di vista operativo Verifica & validazione

7 Verifica e Validazione dinamica Testare il prodotto facendo prove e osservandone il comportamento Verifica Statica Analizzare la rappresentazione statica del sistema per individuare i problemi Verifica statica/dinamica

8 V&V statica e dinamica

9 Testing La verifica di corretto comportamento corretto su un numero finito di casi non assicura la correttezza del programma Non si può raggiungere una certezza di correttezza attraverso il testing Questo non significa che sia una tecnica di verifica inutile Anche le prove matematiche possono contenere errori

10 Terminologia ERRORE la causa di un malfunzionamento, p.es. un errore umano di editing ANOMALIA, GUASTO (fault) difetto del programma dovuto a un errore MALFUNZIONAMENTO ( failure) manifestazione visibile della presenza di un’anomalia

11 Esempio ERRORE di editing ANOMALIA --> “ * ” invece di “+” MALFUNZIONAMENTO --> si stampa un valore diverso da quello atteso ANOMALIA causata da un errore MALFUNZIONAMENTO causato da un’anomalia program RADDOPPIA read (x); y := x*x; write (y)...

12 Obiettivo per un test Obiettivo finale: scoprire le anomalie e correggere l’errore che le ha causate Obiettivo del testing: Individuare tecniche empiriche per aumentare la probabilità che una anomalia causi un malfunzionamento

13 Un test ha successo se permette di individuare uno o più errori Per i requisiti non funzionali possono solo essere utilizzate tecniche di validazione Testing Il test può servire per scoprire la presenza di possibili malfunzionamenti, ma non a garantirne l’assenza (Dijkstra)

14 Testing Testing statistico Il test è progettato in relazione alla frequenza d’uso dei vari tipi di input da parte degli utenti. Usato per la stima di affidabilità del sistema e la efficienza del sistema Defect testing I test sono progettati per scoprire i difetti del sistema Debugging Individuare dove si trova l’errore e progettarne la correzione

15 Fasi del testing

16 Testing di sistemi OO Nei sistemi OO i livelli di integrazione sono meno distinti rispetto allo schema precedente Testare le singole classi corrisponde al “unit testing” Cluster testing. Corrisponde al module testing. Testare un gruppo di oggetti che cooperano per fornire una serie di servizi

17 Il piano di testing E’ un documento che deve descrivere: 1. Il processo di testing adottato 2. Tracciabilità dei requisiti 3. Elementi testati 4. Schedule del testing: tempo e risorse allocate 5. Procedure di registrazione dei test 6. Requisiti hardware e software utilizzati 7. Vincoli che condizionano il testing

18 Modello a V del processo software

19 Strategie di testing Strategie diverse possono essere applicate nelle diverse fasi del processo di testing 1. Incremental testing 2. Top-down testing 3. Bottom-up testing 4. Thread testing 5. Stress testing 6. Back-to-back testing

20 Incremental testing

21 Esperienza Circa il 40% di malfunzionamenti si puo’ attribuire a problemi di integrazione essenzialmente sono errori nell’interpretazione che un modulo fa delle specifiche dell’altro

22 Test di modulo Un modulo fa parte di un sistema è cliente di altri moduli è usato da altri moduli MOD

23 Test di modulo Occorre simulare i moduli usati STUB Occorre simulare i moduli che lo usano DRIVER Caso di MOD sottoprogramma DRIVER inizializza eventuali globali chiama STUB uno per sottoprogramma usato

24 Top-down testing

25 Top-down testing Inizia con i livelli più alti del sistema e procede all’ingiù: le sottocomponenti sono rappresentate da “stub” (ceppi, monconi), che hanno la stessa interfaccia delle sottocomponenti ma funzionalità limitata E’ una strategia di testing adatta quando si procede in uno sviluppo top-down Individua rapidamente errori architetturali Può richiedere di aver già completa la struttura del sistema, prima di poter iniziare qualsiasi test Può risultare difficile sviluppare gli “stub”

26 Casi possibili di “stub” Il chiamato non fa nulla (eventualmente stampa la traccia) Il chiamato colloquia con il programmatore per calcolare il risultato atteso Il chiamato è una versione semplificata (un prototipo) del modulo che verrà chiamato

27 Bottom-up testing

28 Bottom-up testing I vantaggi del bottom-up sono gli svantaggi del top-down (e viceversa) Si inizia dalle componenti più a basso livello e si lavora all’insù, realizzando dei “drivers” che simulano l’ambiente nel quale le componenti sono valutabili Non individua errori di progettazione di alto livello se non molto avanti nel processo E’ appropriato per sistemi object-oriented

29 Thread testing Adatto a sistemi real-time e ad oggetti Si basa sul testare un’operazione che comporta una sequenza di passi di processo che sono legati da uno stesso thread (filo) nel sistema Inizia con thread legati a un singolo evento e poi viene reso più complesso testando threads a eventi multipli Può essere impossibile un “threading test” completo, a causa del numero elevato di combinazioni di eventi

30 Esempio: interazione di processi

31 Thread testing

32 Multiple-thread testing

33 Ha come obiettivo verificare che il sistema sopporti il carico massimo previsto in fase di progettazione. Il sistema viene testato oltre i limiti finché fallisce Testa il comportamento del sistema in caso di fallimento, e verifica le conseguenti perdite di dati o di servizi Particolarmente importante in sistemi distribuiti, che possono subire degrado quando la rete è troppo carica Stress testing

34 Back-to-back testing Testa diverse versioni del programma con lo stesso input, e confronta gli output. Se l’output è diverso, ci sono errori potenziali Riduce il costo di esaminare il risultato dei test: il confronto degli output può essere automatizzato Si può usare quando è disponibile un proototipo, quando il sistema vine sviluppato in più versioni (su diverse piattaforme), o nel caso di upgrade di sistema

35 Back-to-back testing

36 Riparazione Dopo che il test fa sorgere un malfunzionamento occorre scoprirne la causa riparare il programma eliminando la causa del malfunzionamento Debugging

37 Debugging E’ il passo successivo (costoso!) al testing I sintomi e la causa possono essere “geograficamente” lontani (un’altra ragione per avere programmi con accoppiamento lasco) I sintomi possono scomparire (temporaneamente) correggendo un altro errore I sintomi possono essere causati da un non-errore (ad esempio un arrotondamento) I sintomi possono essere causati da errori umani che non sono facilmente tracciabili Può essere difficile riprodurre condizioni di input (es real-time) I sintomi possono essere dovuti a cause distribuite in tasks che girano su diversi processori

38 Il processo di debugging localizza anomalie progetta riparazione effettua riparazione ritesta

39 Debugging: i possibili approcci Forza bruta Riempire il programma di comandi WRITE Si analizza la traccia del programma Questo approcco deve essere l’ultima spiaggia! Backtracking A partire dal sintomo di errore, risalire all’indietro nel codice fino a trovare la causa dell’errore Il numero di cammini all’indietro può essere molto elevato... Eliminazione delle cause Usare la strategia di partizione binaria dei dati, isolando i dati che sembrano generare errori, raffinando i dati di test per isolare il “bug”

40 Prima di correggere un “bug”... La causa dell’errore si può trovare riprodotta in altre parti del programma? La correzione che sto per dare, quali altri “bug” può introdurre? Cosa avrei dovuto fare prima per prevenire questo tipo di errore?