1 implementazione significa “tradurre” la progettazione in codice scritto in un particolare...
Post on 02-May-2015
216 Views
Preview:
TRANSCRIPT
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 innestatema comando switch / array di procedure
no valori numerici distribuiti nel codicema 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 dinamicaTestare il prodotto facendo prove e osservandone il comportamento
Verifica StaticaAnalizzare la rappresentazione statica del sistema per individuare i problemi
Verifica statica/dinamica
8
V&V statica e dinamica
Formalspecification
High-leveldesign
Requirementsspecification
Detaileddesign
Program
PrototypeDynamicvalidation
Staticverification
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 lapresenza 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
Sub-systemtesting
Moduletesting
Unittesting
Systemtesting
Acceptancetesting
Componenttesting
Integration testing Usertesting
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
Requirementsspecification
Systemspecification
Systemdesign
Detaileddesign
Module andunit codeand tess
Sub-systemintegrationtest plan
Systemintegrationtest plan
Acceptancetest plan
ServiceAcceptance
testSystem
integration testSub-system
integration test
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
T3
T2
T1
T4
T5
A
B
C
D
T2
T1
T3
T4
A
B
C
T1
T2
T3
A
B
Test sequence1
Test sequence2
Test sequence3
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
Level 2Level 2Level 2Level 2
Level 1 Level 1Testing
sequence
Level 2stubs
Level 3stubs
. . .
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
Level NLevel NLevel NLevel NLevel N
Level N–1 Level N–1Level N–1
Testingsequence
Testdrivers
Testdrivers
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
P2
P1
P5
P4
I1 (P2)
O2 (P4)
O1(P5)
I2 (P1)
I1 (P1)
I3 (P1)
P3I1 (P3) O1 (P4)
31
Thread testing
P2P3 P4 O1(P4)
I1(P3)
P2P1 P5 O1(P5)
I2(P1)
I1(P1)
I3(P1)
32
Multiple-thread testing
P2P1 P5
P4
I1 (P2)
O2 (P4)
O1 (P5)I2 (P1)
I1 (P1)
I3 (P1)
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
Test data
Programversion A
Programversion B
Resultscomparator
Difference report
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
localizzaanomalie
progettariparazione
effettuariparazione 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?
top related