corso di laurea triennale in ingegneria informatica ingegneria del software il test

Corso di Laurea Triennale in Ingegneria Corso di Laurea Triennale in Ingegneria InformaticaInformatica

Ingegneria del softwareIngegneria del software

Il testIl test

Ingegneria del Ingegneria del softwaresoftware

SommarioSommario

• Introduzione al test• Teoria del test• Tecniche e metodologie di test• Qualità del software• Metriche per la stima di qualità• Test e qualità dell’applicazione sviluppata• Conclusioni


Cos’è il test?Cos’è il test?

• Insieme di misure di controllo utili a verificare la qualità di un software.


Scopo Scopo

• Rilevare gli errori



Teoria del testTeoria del test


Definizioni Definizioni

• Dato un programma P, D ed R siano i domini di ingresso e uscita, P definisce una relazione tra D ed R.

• Un caso di test è un elemento di D. • Un insieme di test T è un insieme finito di casi test, quindi

un sottoinsieme finito di D.• P è corretto per T se risulta corretto per tutti gli elementi di

T. Si dice che T ha avuto successo per P.• Un insieme di test si dice ideale se, tutte le volte che P è

scorretto, esiste un d T tale che P risulta scorretto per d.– Un test ideale mostra sempre l’esistenza di un errore in un

programma, se tale errore esiste. – Per un programma corretto qualunque insieme di test risulta

ideala.– Se T è un insieme ideale e T ha successo per P allora P è corretto.


Teoria del testTeoria del test

Criterio di selezione del testDefinizione

Dato un programma P e le relative specifiche S, un criterio di selezione del test specifica le condizioni che devono essere soddisfatte da un insieme T di casi di test.

Es. il criterio specifica che tutti gli statements nel programma devono essere eseguiti almeno una volta durante il test allora un insieme di casi di test T soddisfa il criterio per un programma P se l’esecuzione di P su T assicura che ogni statement in P sia eseguito almeno una volta.


Proprietà Proprietà

• Proprietà del criterio di test:– Affidabilità– Validità

DefinizioneUn criterio di test è affidabile se tutti gli insiemi (di casi di

test) che soddisfano il criterio individuano gli stessi errori

DefinizioneUn criterio di test è valido se per ogni errore nel

programma c’è un qualche insieme che soddisfa il criterio che rileva l’errore.


Tesi di DijkstraTesi di Dijkstra

• Indecidibilità della correttezza dei programmi– Tesi di Dijkstra: il test di un programma può rilevare la

presenza di malfunzionamenti, ma non dimostra la loro assenza.

– Il test non può dare garanzia completa di correttezza dovendo essere limitato il numero dei casi di test per ragioni legate al costo

• Teorema di Goodenough e Gerhart:– Un criterio di test è affidabile se tutti gli insiemi (di casi di

test) che soddisfano il criterio individuano gli stessi errori

• Corollario– Teorema di Howden: dato un programma P, non esiste un

algoritmo che generi un test ideale finito, cioè selezionato da un criterio affidabile e valido


Assiomi di WeyunkerAssiomi di Weyunker

• Assioma di applicabilità– Per ogni programma (con relative specifiche) esiste un insieme di test T che

soddisfa il criterio• Per tutti i programmi è possibile avere un insieme di casi di test che soddisfa il criterio

• Assioma di antiestensionalità– Esistono due programmi P e Q, che soddisfino entrambi le stesse specifiche, tali

che un set di test T soddisfa il criterio per P ma non per Q.• La struttura del programma ha un ruolo importante nel decidere i casi di test

• Assioma di antidecomposizione– Esiste un programma P ed un suo componente Q tale che un set di test T

soddisfa il criterio per P e T’ è l’insieme dei valori che le variabili possono assumere fornendo Q per qualche caso di test In T e T’ non soddisfa il criterio per Q.

• Se il criterio è soddisfatto per l’intero programma non è detto che sia soddisfatto per ogni suo componente.

• Assioma di anticomposizione • (duale dell’assioma di anticomposizione)

– Esistono due programmi P e Q tali che T soddisfi il criterio per P e gli output di P per T (rappresentati da P(T)) soddisfano il criterio per Q, ma T non soddisfa il criterio per P;Q.

• Se il criterio soddisfa separatamente le parti P e Q


Osservazioni Osservazioni

• Molti dei criteri sono essi stessi indecidibili:– Non è decidibile se dato un dato insieme di test soddisfi i

criteri o se esista un insieme di test che li soddisfi.– Ciò significa che non è possibile automatizzare la

soluzione del problema.


Riferimenti bibliograficiRiferimenti bibliografici

• Teorema di Goodenough e Gerhart: – J. Goodenough and S.L. Gerhart, “Towards a theory of test data

selection”, IEEE Transactions on software engineering, SE-1:156-173,1975.

• Tesi di E.W. Dijkstra (1969): “Program testing can be used to show the presence of bugs, but never to show their absence!”. – J.N. Buxton and B. Randell, eds, Software Engineering

Techniques, April 1970, p. 16. Report on a conference sponsored by the NATO Science Committee, Rome, Italy, 27–31 October 1969.

• Teorema di Howden:– W.E.Howden,” Symbolic Testing and the DISSECT Symbolic

Evaluation System”, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-3, NO. 4, JULY 1977.

• Assiomi di Weyunker– E.J. Weyunker ,"Axiomatizing software test data adequacy”, IEEE

transaction on software engineering, 12(12):1128-1138, Dec. 1986



Livelli di testLivelli di test


Livelli di testLivelli di test

• test di unitàtest di unità• test di integrazionetest di integrazione• test di sistematest di sistema• test di accettazionetest di accettazione• test di regressionetest di regressione


Test di unitàTest di unità

• Controllare separatamente le diverse parti di un modulo di un programma, per rilevare gli errori e migliorarle durante la codifica


Test d’integrazioneTest d’integrazione

• I moduli sono integrati in sottosistemi più grandi i quali a loro volta sono integrati in sistemi più complessi.

• Il test d’integrazione si effettua durante l’integrazione e consiste in un controllo delle interfacce dei moduli integrati


Test di sistemaTest di sistema

• Consiste nel verificare che le specifiche di progetto di un programma siano state soddisfatte e i miglioramenti apportati


Test di accettazioneTest di accettazione

• Imposto dal cliente per verificare che il programma soddisfi le richieste del cliente stesso


Test di regressioneTest di regressione

• Verifica che non si siano introdotti errori in versioni successive


Processo di testProcesso di test

• Test plan: – descrive

• tutte le attività di test che devono essere eseguite• le risorse da allocare • le linee guida• Le condizioni di test per ogni singolo modulo• Le modalità con cui i vari moduli dovranno essere integrati

• Documento sui casi di test:– Contiene

• l’elenco di tutti i differenti casi di test• I risultati ottenuti • Le uscite che ci si aspettava

• Test report:– Una serie di casi di test– Il risultato dell’esecuzione del codice ottenuto applicando i casi di test

• Error report:– Descrive gli errori che si sono presentati– Le azioni intraprese per rimuoverli


2. Principali tecniche e metodologie di 2. Principali tecniche e metodologie di testtest

• Ogni fase del ciclo di vita si conclude con un’attività di verifica

• Molte di queste attività nelle prime fasi di sviluppo si basano su valutazioni umane e non permettono di rilevare tutti gli errori:– Il test si occupa dell’ultima fase del ciclo di vita del software e

ha la responsabilità di rilevare qualsiasi tipo di errore– Esistono errori di diverso tipo, che possono avvenire durante

qualunque fase, per cui esistono diversi livelli di test: ognuno aspira a testare aspetti differenti del sistema


Tecniche di testTecniche di test

• Analisi statica:– Processo di valutazione di un sistema o di un suo componente basato

sulla sua forma, struttura contenuto, documentazione senza che esso sia eseguito:

– Ispezioni, revisioni, recensioni, analisi data flow• Analisi dinamica:

– Processo di valutazione di un sistema software o di un suo componente basato sull’osservazione del suo comportamento in esecuzione (tipicamente il test)

• Analisi formale:– Processo che usa rigorose tecniche matematiche per l’analisi di

algoritmi• Adoperato soprattutto per la verifica del codice e dei requisiti specie se non

sono specificati con linguaggi formali


Tecniche di analisi staticaTecniche di analisi statica

• Analisi statica in compilazione• Code reading• Control flow analysis• Data flow analysis• Code inspections or reviews• Esecuzione simbolica


Tecniche di analisi dinamicaTecniche di analisi dinamica

• Black Box Testing o Testing Funzionale:– Testa il programma per esaminare come dovrebbe essere

• È fondato sull’analisi degli output generati dal sistema o dai suoi componenti in risposta ad input definiti sulla base della sola conoscenza dei requisiti specificati del sistema o di suoi componenti

• Analizza – requisiti funzionali, specifiche, decomposizioni funzionali, requisiti di performance

• White Box Testing o Testing Strutturale:– Testa il programma per esaminare com’è

• È fondato sulla definizione dei casi di test, degli input associati e dell’oracolo, sulla base della conoscenza della struttura del software ed in particolare del codice

• Analizza – Tipi di dati, Dati, strutture di controllo, Control flow, Data flow, Callgraph, Dominanze, dipendenze


Tecniche di testing funzionaleTecniche di testing funzionale

• … cosa testare

– Funzionalità esterne (visibili all’utente e definite dai requisiti e dalle specifiche)

– Funzionalità interne ( non visibili all’utente e definite dal progetto di high e low level)

• …. partendo da

– Definizione Funzionalità:• Insieme dei dati d’ingresso, dati d’uscita, precondizioni e postcondizioni


Effettuare un testEffettuare un test

• È necessario conoscere il comportamento atteso per poterlo confrontare con quello osservato e per poter definire l’oracolo– L’oracolo conosce il comportamento atteso per ogni caso di test e può

essere:• Umano, se si basa sulle specifiche o sul giudizio• Automatico se è generato dalle specifiche formali• Lo stesso software scritto da altri• Una versione precedente ( test di regressione)

• Ogni funzionalità deve essere eseguita almeno una volta e per ogni funzionalità bisogna effettuare un numero di esecuzioni dedotte dai dati di ingresso e di uscita, da precondizioni e postcondizioni


Test caseTest case

• Vanno effettuati una volta definito il dominio dei dati di I/O selezionando:– Valori in posizione centrale– Valori ai bordi– Valori speciali

• Selezionando precondizioni e postcondizioni– Positivi– Negativi – Neutrali


Documentazione dei testDocumentazione dei test

• I test eseguiti vanno documentati producendo una check list:

funzionalità TC Input Output Precond Postcond Priorità esito


Definizione della check listDefinizione della check list

• Si parte dall’analisi dei documenti che definiscono i requisiti e la specifica

• Si estraggono le funzionalità esterne ed altre features, dati di I/O, pre e post condizioni, definizione priorità, nomi dei test

• Si procede con l’analisi dei documenti di progetto di high e low level e con l’estrazione delle funzionalità interne, dati di I/O, pre e post condizioni, definizione priorità e nomi dei test

• Si definiscono i test case e le procedure di test• Si genera la tabella di copertura (o dei test case) e la tabella delle

procedure


Tecniche di testing strutturaleTecniche di testing strutturale

• Si basa sulla scelta dei dati di test in base alla struttura del codice testato

• Per effettuare una completa analisi strutturale si applicano i seguenti criteri– criterio di inadeguatezza

• Se parti significative della struttura del programma non sono coperte il test è inadeguato

– criteri di glass box (criteri di copertura strutturale del flusso di controllo)

• Copertura delle istruzioni (statement coverage)• Copertura delle diramazioni (edge coverage)• Copertura delle condizioni (condition coverage)• Copertura dei cammini (path coverage)


Copertura Copertura

• Un insieme di casi di test (input data) tale che gli oggetti di una definita classe (strutture di controllo, istruzioni, predicati) siano attivati almeno una volta nell’esecuzione dei casi di test.


Metodo di copertura delle Metodo di copertura delle istruzioniistruzioni

• Si seleziona un insieme T di dati di test per cui ogni istruzione viene eseguita almeno una volta da qualche dato di T.

• In questo caso, fissato il criterio, si cerca di trovare il T di cardinalità minima, che soddisfa il criterio.


Metodo di copertura delle Metodo di copertura delle istruzioniistruzioni

• Si seleziona un insieme T di dati di test tali che ogni istruzione viene eseguita almeno una volta da qualche dato di T.

• Non è possibile individuare un errore se la parte del programma che contiene l’errore e che genera il fallimento non viene eseguita


Metodo di copertura delle Metodo di copertura delle diramazionidiramazioni

• Si seleziona un insieme T di dati di test tale che ogni diramazione del flusso di controllo viene selezionata almeno una volta da qualche elemento di T.


Metodo di copertura delle Metodo di copertura delle condizionicondizioni

• Si seleziona un insieme T per cui si percorre ogni diramazione e tutti i possibili valori dei costituenti della condizione che controlla la diramazione sono esercitati almeno una volta.


Metodo di copertura dei camminiMetodo di copertura dei cammini

• Si seleziona un insieme T che attraversa tutti i cammini del programma.

• Problema: presenza di un numero infinito di cammini e/o non percorribili

• Soluzione: numero finito di cammini eseguibili• Trovare un insieme di test case che assicuri

l’attraversamento almeno una volta di almeno un cammino per ogni classe


Metodo di copertura dei cammini Metodo di copertura dei cammini minimiminimi

• Metodi fondati sui grafi di controlloMetodi fondati sui grafi di controllo– Metodo dei cammini esemplari– Metodo dei cammini linearmente indipendenti (McCabe)

• Metodi data flow:Metodi data flow:• Garantire il test delle variabili e dei loro usiGarantire il test delle variabili e dei loro usi


Mutation testingMutation testing

• Mutanti: testing strutturale

• Obiettivo: garantire che, durante la fase di test, ogni mutante (variazione del programma) produca un’uscita diversa dall’uscita del programma originale.


Test di software OOTest di software OO

• Concetti di OO:– Modularizzazione– Information hiding– Tipi di dati astratti– Progettazione per il cambiamento– Ereditarietà– Polimorfismo– Binding dinamico

• Test di software OO:– Information hiding– Shadow invocations– Polimorfismo e dynamic binding– Ereditarietà– Genericità


• Ereditarietà– Flattering inheritanceFlattering inheritance– Test incrementaleTest incrementale

• Genericità– Data-flow analysis

• Polimorfismo– Data-flow analysis


Problemi Problemi

• Ereditarietà: i metodi sono riutilizzati in classi diverse • Information hiding: gli oggetti, avendo uno stato violano le ipotesi

di un comportamento funzionale• Shadow invocations: i metodi possono essere invocati

implicitamente (problemi relativi al conteggio delle percentuali di copertura)

• Polimorfismo e dynamic binding: i metodi invocati non possono essere identificati staticamente

• Genericità: le classi generiche devono essere istanziate per essere testate


Test ed ereditarietàTest ed ereditarietà

• Alcune operazioni possono non essere modificate nelle sottoclassi, altre possono essere ridefinite o cancellate:

• Problema:– Come fare il test?– Quali operazioni possono essere ri-testate?


11a a SoluzioneSoluzione

• Appiattire l’intera gerarchia e considerare ogni classe come una componente totalmente indipendente: Flattering inheritance

• Svantaggio:– Si perde l’incrementalità e la riusabilità


22aa Soluzione Soluzione

• Test incrementale – Evitare di ripetere il test di elementi che sono ereditati senza cambiamenti,

mentre si dovrebbero testare i nuovi elementi e quelli che sono stati ridefiniti • Tecnica usata per testare classi appartenenti ad una gerarchia con

ereditarietà– Quando una classe eredita da una classe base già testate, il test della

sottoclasse richiede il test solo di alcuni elementi– Una sottoclasse R può essere definita come una classe base P più una modifier M

• A seconda del tipo di elemento il test può avvenire riusando un caso di test esistente in modo totale o parziale


Test dei costrutti genericiTest dei costrutti generici

• Costrutti generici e polimorfismo sono strumenti essenziali per ottenere generalità e riusabilità dei programmi, ma sono sorgente di complessità nel test e nella verifica– Genericità:

• A differenza della programmazione procedurale i moduli generici sono molto presenti e rappresentano la base per la costruzione di librerie e componenti riusabili

• Problemi nel test: – assunzioni sul parametro– metodo da usare nel test di un componente generico già riutilizzato


Test del polimorfismoTest del polimorfismo

• Molte implementazioni per una singola operazione– La selezione dell’effettivo codice da chiamare è proposta a run-

time• Problemi nel test:

– Scelta di come coprire tutte le chiamate alle operazioni polimorfiche

– Come esercitare tutte le implementazioni di un’operazione – Come trattare parametri polimorfici


Soluzioni al problema del test del Soluzioni al problema del test del polimorfismo e costrutti genericipolimorfismo e costrutti generici

• Nel caso del polimorfismo, invece, mentre nella programmazione procedurale le chiamate di procedura sono legate staticamente, nella programmazione OO, un’entità può riferire oggetti di classi diverse di una gerarchia, quindi si hanno molte implementazioni per una singola operazione. La selezione dell’effettivo codice da chiamare è proposta a run-time.

• I problemi che s’incontrano nell’ambito del test sono dovuti alla scelta di come coprire tutte le chiamate alle operazioni polimorfiche, come esercitare tutte le implementazioni di un’operazione o come trattare parametri polimorfici.

• Il testing strutturale, in questo caso, non può essere trattato statisticamente.• Si può dimostrare che tutte le possibili combinazioni di chiamate polimorfiche e

parametri polimorfici rischiano di far esplodere in modo combinatorio il numero dei casi di test. • Si può ottenere una riduzione di questo effetto attraverso tecniche di analisi statica che

permettano d’individuare le effettive chiamate delle unità interessate (data-flow analysis).


Tecniche tradizionali per OOTecniche tradizionali per OO

• Test di sistema e di accettazione, che si basano su requisiti funzionali

• gli approcci tradizionali al testing strutturale, che possono essere usati per testare metodi singoli

• il test di regressione, il quale richiede solo di scrivere nuovi test per le caratteristiche nuove o modificate

• l’esecuzione di tali test richiede solo modifiche sintattiche



Metriche di prodotto per il softwareMetriche di prodotto per il software

Fattori di qualità ISO 9126metriche


I fattori di qualità ISO 9126I fattori di qualità ISO 9126

• FunzionalitàOpportunitàOpportunitàPrecisionePrecisioneInteroperabilitàInteroperabilitàConformitàConformitàSicurezzaSicurezza

• Affidabilità

MaturitàMaturitàResistenza ai Resistenza ai guastiguastiRicuperabilitàRicuperabilità



• Facilità d’uso

ComprensibilitàFacilità d’apprendimentoFacilità d’uso

• Facilità di manutenzione

Facilità d’analisiFacilità di modificaFacilità di collaudoStabilità



• Efficienza Comportamento nel tempoComportamento nel tempoComportamento con le risorseComportamento con le risorse

• PortabilitàAdattabilitàAdattabilitàInstallabilitàInstallabilitàConformitàConformitàSostituibilitàSostituibilità



Misurazione del software orientato Misurazione del software orientato all’obiettivoall’obiettivo


Cos’è una metrica?Cos’è una metrica?

Definizione Misura quantitativa del grado con cui un sistema, un componente o un processo possiede un determinato attributo.

[IEEE Standard Glossary Engineering terminology, 1993]


Paradigma GQMParadigma GQM

• Tecnica che identifica metriche significative per ogni parte del processo di sviluppo software.

• Evidenzia la necessità di:– Stabilire un obiettivo di misurazione esplicito, specifico delle

attività del processo o delle caratteristiche del prodotto che deve essere valutato

– Definire un insieme di domande cui occorre rispondere per ottenere l’obiettivo

– Identificare metriche ben formulate per aiutare a rispondere a queste domande


Metriche calcolate per il prodotto Metriche calcolate per il prodotto sviluppatosviluppato

• Modello di qualità GQM (Goal Question Metric)Modello di qualità GQM (Goal Question Metric)

Stabilire un obiettivo di misurazione esplicito Stabilire un obiettivo di misurazione esplicito (Goal)(Goal)

Definire un insieme di domande (Question) Definire un insieme di domande (Question) Identificare metriche ben formulate (Metric)Identificare metriche ben formulate (Metric)

[Basili e Weiss, “ A methodology for collecting [Basili e Weiss, “ A methodology for collecting valid software engineering data”, IEEE Trans. valid software engineering data”, IEEE Trans. Software Engineering, vol 10, 1984, pp. 728-738]Software Engineering, vol 10, 1984, pp. 728-738]


Descrizione del modelloDescrizione del modello

• Assume la seguente forma:– Analizzare (nome dell’attività o dell’attributo che deve

essere misurato) con lo scopo di (obiettivo generale dell’analisi) con riferimento a (aspetto dell’attività o dell’attributo considerato) dal punto di vista di (persone che hanno un interesse nella misurazione) nel contesto di (ambiente in cui viene svolta la misurazione)


Modello di Progettazione di un GQMModello di Progettazione di un GQM

Usa i fogli metrici, come strumento operativo per migliorare la leggibilità e tracciare esplicitamente il monitoraggio e il

miglioramento continuo GQM/QIP

Oggetto dello studio Scopo Prospettiva Punti di Vista Contesto

Quality Focus Variation Factors

descrive la relazione tra i fattori divariazione e le metriche del qualityfocus

contiene i quesiti e le metriche perla conformità del processo o dellacaratterizzazione del prodotto

Baselines Hypothesis Impact on Baseline Hypothesis

contiene i quesiti e le metrichedei modelli di conferma e divalidità

descrive la relazione tra i fattori divariazione e le metriche del qualityfocus


Modello di Progettazione di un GQMModello di Progettazione di un GQM

• Usa le tavole di decisione per interpretare i risultati delle misurazioni effettuate e selezionare le attività di miglioramento più adatte.

Condizioni (metrichenecessarie per l’interpretazione)

Stati condizionali: combinazione di valori che possono assumere lecondizioni (baseline)

Attività di miglioramento Regola di decisione


Metriche di prodottoMetriche di prodotto

• Metriche per il modello analitico:– Funzionalità fornita– Dimensioni del sistema– Qualità delle specifiche

• Metriche per il modello progettuale– Dell’architettura– A livello di componenti– Della progettazione dell’interfaccia– Specializzate relative al progetto orientato agli oggetti

• Metriche relative al codice sorgente– Di Halstead– Di complessità– Di collaudo– Sulle istruzioni e ramificazioni– Relative ai difetti– Test dell’efficacia– Sul processo


Metriche per il modello concettualeMetriche per il modello concettualebasate sulle funzionalitàbasate sulle funzionalità

• Metrica dei punti funzione usata per :– Stimare il costo o l’impegno necessario per progettare,

programmare e collaudare il software– Prevedere il numero di errori che verranno rilevati

durante il collaudo– Prevedere il numero di componenti e/o il numero di

righe di codice che comporranno il sistema implementato


Punti funzionePunti funzione

• Derivati utilizzando una relazione empirica che si basa su misure calcolabili dirette nel dominio delle informazioni del software e valutando la complessità del software

• Numero di input esterni (EI). Ogni input esterno viene ottenuto da un utente o trasmesso da un’altra applicazione e fornisce dati distinti, orientati all’applicazione, oppure informazioni di controllo. Gli input vengono spesso usati per aggiornare i file logici interni (ILF - Internal Logical File).

• Numero di output esterni (EO). Ogni output esterno viene creato nell’applicazione e fornisce informazioni all’utente. In questo contesto l’output esterno fa riferimento ai report, agli schemi, ai messaggi d’errore e così via.


Calcolo dei punti funzioneCalcolo dei punti funzione

• Numero di richieste esterne (EQ). Una richiesta esterna viene definita come un input ondine, che produce la generazione di una risposta immediata del software, sottoforma di un output online.

• Numero di file logici interni (IFL). Ogni file logico interno è un raggruppamento logico di dati che risiedono all’interno dell’applicazione e vengono gestiti tramite gli input esterni.

• Numero di file dell’interfaccia esterna (EIF). Ogni file dell’interfaccia esterna è un raggruppamento logico di dati che risiede esternamente rispetto all’applicazione, ma che fornisce dati utilizzati dall’applicazione.


Conteggio dei punti funzioneConteggio dei punti funzione

Fattore di peso

Parametro di misurazioneContegg

io Semplice MedioCompless

o

Input utente 3 4 6 =

Output utente 4 5 7 =

Interrogazioni utente 3 4 6 =

File 7 10 15 =

Interfacce esterne 5 7 10 =

Totale


Conteggio dei punti funzioneConteggio dei punti funzione

• Conteggio dei punti funzione

• Dove conteggio-totale è la somma di tutte le voci FP tratte dalla tabella precedente

)F*01.065.0(*totaleconteggioFP i


Valori FiValori Fi

• I valori Fi (i=da 1 a 14) sono fattori di aggiustamento (VAF - Value Adjustment Factors) che si basano sulle risposte alle seguenti domande.

1. Il sistema ha bisogno di operazioni di backup e ripristino di affidabilità?2. E’ necessario impiegare comunicazioni specializzate per trasferire le informazioni da o

verso l’applicazione?3. Esistono funzioni di elaborazione distribuita?4. Le prestazioni rappresentano un fattore critico?5. Il sistema può funzionare in un ambiente operativo esistente, pesantemente utilizzato?6. Il sistema richiede un inserimento online dei dati?7. L’inserimento online dei dati richiede che venga realizzata una transazione di input

costituita da più schermi o operazioni?8. I file IFL vengono aggiornati online?9. Esistono input, output, file o richieste di natura complessa?10.L’elaborazione interna è complessa?11.Il codice è progettato per essere riutilizzabile?12.Nel progetto sono compresi la conversione e l’installazione?13.Il sistema è progettato per più installazioni in più organizzazioni?14.L’applicazione è progettata per facilitare le modifiche e la facilità d’uso da parte degli

utenti?15. Occorre rispondere ad ognuna di queste domande utilizzando una scala che

va da 0 (non importante o non applicabile) a 5 (assolutamente fondamentale).

[Longstreet, “Fundamental of Function Point Analysis”, Longstreet Consulting, Inc. 2002]


Metriche per il modello progettualeMetriche per il modello progettualeMetriche per la progettazione orientata agli oggettiMetriche per la progettazione orientata agli oggetti

• Metriche CK • Metriche MoodSecondo Whitmire, esistono nove caratteristiche

distinte e misurabili di un progetto orientato agli oggetti.

[Whitmire, “Object-Oriented Design Measurement”, Wiley, 1997]


Caratteristiche di un progetto Caratteristiche di un progetto orientato agli oggetti 1/2orientato agli oggetti 1/2

1. Dimensioni. Le dimensioni sono definite in termine di quattro elementi: numerosità, volume, lunghezza e funzionalità.

– La numerosità viene misurata conteggiando staticamente le entità orientate agli oggetti (es. classi o operazioni).

– Le misure del volume sono identiche a quelle di numerosità, ma vengono raccolte in modo dinamico.

– La lunghezza misura una catena di elementi progettuali interconnessi (es. profondità di un albero di ereditarietà).

– Le metriche di funzionalità forniscono un’indicazione indiretta del valore fornito al cliente da un’applicazione orientata agli oggetti.

2. Complessità. E’ vista in termini di caratteristiche strutturali, esaminando le relazioni tra le classi di un progetto orientato agli oggetti.

3. Accoppiamento. Le connessioni fisiche tra gli elementi del progetto orientato agli oggetti rappresentano l’accoppiamento all’interno del sistema.


Caratteristiche di un progetto Caratteristiche di un progetto orientato agli oggetti 2/2orientato agli oggetti 2/2

4. Sufficienza. E’ il grado in cui un’astrazione possiede le caratteristiche richieste o il grado in cui un componente progettuale possiede le caratteristiche della sua astrazione, dal punto di vista dell’applicazione corrente.

5. Completezza. E’ l’insieme di caratteristiche rispetto alle quali si deve confrontare l’astrazione o il componente del progetto.

6. Coesione. Si verifica quando un componente ad oggetti viene progettato in modo che tutte le operazioni collaborino per un unico obiettivo ben definito.

7. Primitività. Indica il grado di atomicità di un’operazione.8. Similarità. E’ il grado in cui due o più classi sono simili in termini

di struttura, funzione, comportamento o scopo.9. Volatilità. Misura la probabilità che si verifichi una modifica.


Metriche orientate alle classi: Metriche orientate alle classi: metriche CKmetriche CK

• Una delle metriche più utilizzate per il software orientato agli oggetti è quella proposta da Chidamber e Kemerer da cui il nome di metriche CK.

– Gli autori hanno proposto sei metriche di progettazione basate su classi per un sistema orientato agli oggetti.

[Chidamber, Kemerer, “A metrics Suite for Object-Oriented Design”, IEEE Trans. Software Engineering, vol. SE – 20, no 6, June 1994, pp. 476-493.]


1. Metodi pesati per classe1. Metodi pesati per classe

Metodi pesati per classe (WMC - Weighted Methods per Class).

Una classe definisce n metodi di complessità c1, c2, …, cnWMC = Σ ci i=1,...,nLa metrica di complessità prescelta può essere qualsiasi. Se la complessità di ciascun metodo assume il valore 1, WMC è pari

al numero dei metodi della classe. Se si usa la complessità di McCabe:

c = classe di cui si sta valutando WMCVG(m) = complessità ciclomatica del metodo mMIm(c) = insieme dei metodi implementati nella classe c

Il numero di metodi e la loro complessità sono indice della complessità della classe.

Infatti, si preferisce un valore di WMC basso, perché maggiore è il numero dei metodi, più complesso è l’albero d’ereditarietà; nonché, all’aumentare di questo valore, è probabile che la classe divenga più specifica dell’applicazione, limitando il suo potenziale riutilizzo.


2. Profondità dell’albero di 2. Profondità dell’albero di ereditarietàereditarietà

Profondità dell’albero di ereditarietà (DIT - Depth of the Inheritance Tree). Indica la distanza massima di un nodo (una classe) dalla radice dell’albero rappresentante la struttura ereditaria.

Maggiore è la profondità della classe, nella gerarchia, maggiore è il numero di metodi che essa può ereditare, rendendo più complesso predire il suo comportamento.

Inoltre, alberi di ereditarietà con maggiore profondità possono aumentare la complessità del progetto (più classi e metodi sono coinvolti).

Infine, maggiore è la profondità di una classe, in una gerarchia, maggiore è il riuso potenziale dei metodi ereditati.


3. Numero di figli3. Numero di figli

Numero di figli (NOC - Number Of Children). Indica il numero di sottoclassi, figlie di una superclasse.Al crescere del NOC, cresce il livello di riuso, ma tende ad ‘evaporare’ l’astrazione della classe madre. Inoltre, aumenta la possibilità che una classe figlia non sia membro appropriato della madre.Al crescere del NOC, cresce la quantità di casi di test necessari a testare ogni figlia.


4. Risposte per classe4. Risposte per classe

Risposte per classe (RFC - Response For a Class). Indica l’insieme dei metodi che possono essere eseguiti in risposta ad un messaggio ricevuto da un oggetto della classe. A valori elevati di RFC, cresce lo sforzo per il testing ed aumenta anche la complessità progettuale della classe.


5. Accoppiamento fra le classi di 5. Accoppiamento fra le classi di oggettioggetti

Accoppiamento fra le classi di oggetti (CBO - Coupling Between Object classes). Registra il numero di collaborazioni di una classe, ovvero il numero di altre classi cui essa è accoppiata.Un eccessivo accoppiamento è negativo per la modularità ed il riuso; mentre più una classe è indipendente più è facilmente riusabile.Per migliorare la modularità, l’accoppiamento va tenuto al minimo; esso influisce sull’impatto di modifiche in altri moduli.


6. Mancanza di coesione nei 6. Mancanza di coesione nei metodimetodi

Mancanza di coesione nei metodi (LCOM - Lack of Cohesion in Methods). Indica la coesione tra gli elementi di una classe ed è espressa tramite il numero di metodi che accedono agli stessi attributi di una classe.In questo caso, se il suo valore è alto, i metodi possono essere accoppiati l’uno all’altro tramite gli attributi, ma questo comporta una maggiore complessità del progetto della classe.Si preferisce LCOM basso e coesione alta.


Metriche orientate alla classe: le metriche Metriche orientate alla classe: le metriche MOODMOOD

• Harrison, Counsell e Nithi propongono un insieme di metriche per la progettazione orientata agli oggetti che rappresentano indicatori quantitativi delle caratteristiche di progettazione orientata agli oggetti.

[Harrison, Consell e Nithi, “An evaluation of the MOOD Set of Object-Oriented Software Metrics”, IEEE Trans. Software Engineering, vol. SE – 24, no. 6, June 1998, pp. 491-496.]


Fattore di ereditarietà dei metodiFattore di ereditarietà dei metodi

Fattore di ereditarietà dei metodi (MIF- Method Inheritance Factor)Il grado in cui l’architettura della classe di un sistema orientato agli oggetti utilizza l’ereditarietà sia nei metodi che negli attributi è definita nel seguente modo:

dove la sommatoria si verifica per i=1…Tc;Tc è definito come il numero totale di classi dell’architettura; Ci è una classe all’interno dell’architettura = il numero di metodi che possono essere richiamati in associazione con Ci;

= il numero di metodi dichiarati in Ci=il numero di metodi ereditati (ma non modificati) in Ci.

Il MIF definisce un’indicazione dell’impatto dell’ereditarietà sul software.

)C(M

)C(MMIF

ia

ii

)C(M ia

)C(M id

)C(M ii


Fattore di accoppiamentoFattore di accoppiamento

Fattore di accoppiamento (CF – Coupling Factor)

dove la sommatoria si verifica per i=1…Tc e j=1… Tc;la funzione

is_client=1 se e solo se esiste una relazione fra la classe client Cc e la classe server Cs e se Cc ≠ Cs

=0 altrove.Per quanto riguarda il CF, se aumenta, aumenta anche la complessità del software e questo può peggiorare la comprensibilità e la facilità di manutenzione oltre che le possibilità di riutilizzo.

c2

c

i jji

TT

)C,C(client_is

CF


Metriche orientate agli oggetti di Lorenz e Metriche orientate agli oggetti di Lorenz e KiddKidd

Lorenz e Kidd dividono le metriche basate su classi in quattro grandi categorie: dimensioni, ereditarietà, aspetti interni e aspetti esterni.Le metriche orientate alle dimensioni per una classe orientata agli oggetti considerano il numero di attributi ed operazioni per una singola classe e calcolano la media per l’intero sistema orientato agli oggetti. Le metriche basate sull’ereditarietà considerano il modo in cui le operazioni vengono riutilizzate nella gerarchia di classi.Le metriche per gli aspetti interni della classe considerano problemi quali la coesione delle caratteristiche del codice.Infine, le metriche sugli aspetti esterni della classe considerano i fattori di accoppiamento e riutilizzo.Un campione delle suddette metriche è rappresentato dalle due seguenti.

[Lorenz, Kidd, “Object-Oriented Software Metrics”, Prentice-Hall, 1994 ]


Dimensioni della classeDimensioni della classe

Dimensioni della classe (CS – Class Size). Le dimensioni generali di una classe possono essere determinate come o il numero totale di metodi (privati ed ereditati) o come il numero totale di attributi (privati ed ereditati).In questo caso, se il CS è troppo alto, indica una classe con troppe responsabilità e ciò riduce la riutilizzabilità della classe e ne complica l’implementazione ed il collaudo.


Numero di operazioni aggiunte da una Numero di operazioni aggiunte da una sottoclassesottoclasse

Numero di operazioni aggiunte da una sottoclasse (NOA – Number of Operations Added). Le sottoclassi vengono specializzate aggiungendo operazioni ed attributi. Il NOA, se aumenta, comporta una deviazione della sottoclasse rispetto all’astrazione determinata dalla superclasse. In generale, a mano a mano che si approfondisce la gerarchia di classi (DIT più alto), il NOA ai livelli più bassi della gerarchia dovrebbe calare.


Metriche per il codice sorgenteMetriche per il codice sorgente

Halstead ha definito alcune leggi quantitative per lo sviluppo di software, derivate dopo la generazione del codice.Le misure di Halstead si basano su quattro numeri ricavabili direttamente dal codice sorgente:

n1 = il numero di operatori distintin2 = il numero di operandi distintiN1 = il numero totale di operatoriN2 = il numero totale di operandi

e sono descritte dalle seguenti metriche:Lunghezza del programma N= N1+ N2Vocabolario del programma n= n1 + n2Volume V= N * (LOG2 n)Difficoltà D= (n1 /2) * (N2 / n2)Sforzo E= D * V

[Halstead, “Element of Software Science”, North-Holland, 1977.]


Metriche di complessitàMetriche di complessità

• Per misurare la complessità del flusso di controllo di un programma si dispone di numerose metriche, molte delle quali basate su una rappresentazione detta grafo di flusso.

• McCabe e Watson indicano alcuni impieghi importanti delle metriche di complessità.

• La più diffusa fra le metriche di complessità è la complessità ciclomatica.

• Essa è stata definita da Thomas McCabe nel 1976 e rappresenta il numero di percorsi linearmente indipendenti in un modulo.

• E’ calcolata sulla base del grafo di flusso di un programma/modulo software. I nodi (n) di tale grafo rappresentano le linee di codice, mentre gli archi, il flusso di controllo

[McCabe, Watson, “Software Complexity”, Crosstalk, vol.7, no. 12, December 1994, pp 5-9.]


Grafo di flusso per un generico programmaGrafo di flusso per un generico programma

La complessità ciclomatica è calcolata come V(G)=e-n+2.

Essa è legata alla frequenza degli errori nel sistema. Di solito, se ne preferisce un valore basso al fine di garantire una buona manutenibilità e testabilità.



Esempio applicativo del modello GQM Esempio applicativo del modello GQM


Valutazione di metriche secondo il Valutazione di metriche secondo il modello GQMmodello GQM

Fattori di qualità ISO 9126 considerati:• facilità d’uso• facilità di manutenzione• portabilità

PRODOTTO SOFTWARE SVILUPPATO

Facilità d'uso Facilità di manutenzione Portabilità

GOAL 1 X

GOAL 2 X

GOAL 3 X


GOAL 1 - Facilità d’usoGOAL 1 - Facilità d’uso

G1- Facilità d’usoG1- Facilità d’uso

QF1- QF1- ComprensibilitàComprensibilità

QF2-Facilità QF2-Facilità d’apprendimentod’apprendimento

QF3- Facilità d’usoQF3- Facilità d’uso

RFCRFC LCOMLCOM CSCS NOANOA WMCWMC MIFMIF VgVg

Q2Q2

DITDIT

Q1Q1 Q3Q3 Q4Q4 Q5Q5

Quanto è Quanto è profonda profonda

la la gerarchia gerarchia di classi?di classi?

Qual è il grado di Qual è il grado di complessità complessità

della risposta ad della risposta ad un messaggio?un messaggio?

Quanto è Quanto è generica generica

una una classe?classe?

Quanto è Quanto è complesscompless

a una a una classe?classe?

Qual è il grado di Qual è il grado di coesione interna coesione interna di una classe?di una classe?


Quality Factors Variation Factors• DITe: profondità dell’albero di ereditarietà

• NOAe: numero di operazioni aggiunte ad una sottoclasse

• MIFe: fattore di ereditarietà dei metodi

• RFCe: risposte per classe

• LCOMe: mancanza di coesione nei metodi

• CSe: dimensione della classe

• WMCe: metodi pesati per classe

• Vge: complessità ciclomatica

• Coesione interna• Profondità della gerarchia di

classe• Complessità di classe• Generalizzazione di classe • Complessità di risposta

Oggetto dello studio Scopo Prospettiva Punti di vista Contesto

Prodotto software sviluppato Valutazione Facilità d'uso Sviluppatore Prodotto sviluppato

Foglio metricoFoglio metrico


Baseline Hypothesis Baseline Impacts

• DITa<30%

• NOAa<30%

• MIFa<30%

• RFCa<20%

• LCOMa>80%

• CSa<20%

• WMCa<30%

• Vga<20%

• La profondità gerarchica di classe influenza la profondità dell’albero di ereditarietà, il numero di azioni introdotte nelle sottoclassi ed il fattore di ereditarietà dei metodi attesi rispetto a quelli effettivi.

• La complessità di classe influenza il valore atteso della complessità ciclomatica e della complessità dei metodi pesati per classe rispetto ai valori effettivi.

• La generalizzazione influenza il valore atteso di operazioni aggiunte alle sottoclassi e di dimensioni della classe rispetto a quello effettivo.

• La coesione influenza il valore atteso rispetto a quello effettivo.


Prodotto software sviluppato Valutazione Facilità d'uso Sviluppatore Prodotto sviluppato


Tavola di decisione per Goal 1Tavola di decisione per Goal 1

c1. DITa<DITe Y Y Y Y Y Y Y Y Y Y Y Y Y Y

c2. NOAa<NOAe Y Y Y Y Y Y Y Y Y Y Y Y Y Y

c3. MIFa<MIFe Y Y Y Y Y Y Y Y Y Y Y Y Y Y

c4. RFCa<RFCe Y Y Y Y Y Y Y Y Y Y Y Y Y Y

c5. LCOMa>LCOMe Y Y Y Y Y Y Y Y N N N N N N

c6. CSa<CSe Y Y Y Y N N N N Y Y Y Y N N

c7. WMCa<WMCe Y Y N N Y Y N N Y Y N N Y Y

c8. Vga<Vge Y N Y N Y N Y N Y N Y N Y N

a1. goal soddisfatto x

a2. aumentare coesione x x x x x x

a3. ridurre la profondità della gerarchia di classi

a4. ridurre la complessità di classe x x x x x x x x x x

a5. aumentare la generalizzazione x x x x x x

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Legenda <=30%

La % si riferisce al valore atteso >30%

<=20%

>20%

>=80%

<80%


GOAL 2 - Facilità di manutenzione

G2- Facilità di manutenzioneG2- Facilità di manutenzione

QF4- Facilità di QF4- Facilità di analisianalisi

QF5- Facilità di QF5- Facilità di modificamodifica

QF6- Facilità di QF6- Facilità di collaudocollaudo

CBOCBO RFCRFC CFCFWMCWMC MIFMIF

Q7Q7

NOCNOC

Q6Q6 Q8Q8 Q9Q9

Qual è la Qual è la capacità di capacità di

funzionamento funzionamento delle classi figlie delle classi figlie in una gerarchia in una gerarchia

di classe?di classe?

Qual è il grado di Qual è il grado di profondità di profondità di

una gerarchia di una gerarchia di classe?classe?

Qual è il Qual è il grado grado

d’impegno d’impegno per il per il

collaudo?collaudo?

Qual è il grado Qual è il grado di di

accoppiamentaccoppiamento tra le classi?o tra le classi?



Quality Factors Variation Factors

• NOCe: numero di classi figlie

• CBOe: accoppiamento fra le classi di oggetti

• CFe: fattore di accoppiamento

• MIFe: fattore di ereditarietà dei metodi

• RFCe: risposte per classe


• Funzionamento classi figlie • Accoppiamento• Profondità della gerarchia di

classe • Impegno del collaudo


Prodotto software sviluppato Valutazione Facilità di manutenzione Sviluppatore Prodotto sviluppato



• NOCa<30%

• CFa<20%

• CBOa<20%

• MIFa<30%

• RFCa<20%

• WMCa<30%

• Il funzionamento delle classi figlie influenza il valore atteso del numero di classi figlie rispetto a quello effettivo.

• L’accoppiamento influenza il numero atteso di collaborazioni con le classi rispetto ai valori effettivi.

• La profondità gerarchica di classe influenza il fattore di ereditarietà dei metodi attesi rispetto a quelli effettivi.

• L’impegno del collaudo influenza il numero atteso di risposte per classe ed il numero atteso di metodi per classe rispetto ai valori effettivi.


Prodotto software sviluppato Valutazione Facilità di manutenzione Sviluppatore Prodotto sviluppato


Tavola di decisione per Goal 2

c1. NOCa<NOCe Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y

c2. CBOa<CBOe Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y N N N N

c3. CFa<CFe Y Y Y Y Y Y Y Y N N N N N N N N Y Y Y Y

c4. MIFa<MIFe Y Y Y Y N N N N Y Y Y Y N N N N Y Y Y Y

c5. RFCa<RFCe Y Y N N Y Y N N Y Y N N Y Y N N Y Y N N

c6. WMCa<WMCe Y N Y N Y N Y N Y N Y N Y N Y N Y N Y N


a2. riduzione classi figlie

a3. riduzione accoppiamento x x x x x x x x x x x x

a4. riduzione profondità gerarchica

x x x x x x x x

a5. riduzione impegno collaudo x x x x x x x x x x x x x x x

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Legenda <=30%


<=20%

>20%


G3- PortabilitàG3- Portabilità

QF7- AdattabilitàQF7- Adattabilità QF8- RiutilizzoQF8- Riutilizzo QF9- SostituibilitàQF9- Sostituibilità

CBOCBO DITDIT CFCFWMCWMC

Q11Q11

NOCNOC

Q10Q10 Q12Q12

GOAL 3 - PortabilitàGOAL 3 - Portabilità

Qual è il grado Qual è il grado di profondità di di profondità di una gerarchia una gerarchia

di classe?di classe?

Qual è il grado Qual è il grado di di

accoppiamentaccoppiamento tra le classi?o tra le classi?

Qual è il Qual è il grado di grado di

specificità specificità della classe?della classe?



Quality Factors Variation Factors

• DITe: profondità dell’albero di ereditarietà

• NOCe: numero di classi figlie

• CBOe: accoppiamento fra le classi di oggetti

• CFe: fattore di accoppiamento


• Specificità dell’applicazione• Accoppiamento• Profondità della gerarchia di classe


Prodotto software sviluppato Valutazione Portabilità Sviluppatore Prodotto sviluppato



• DITa>=70%

• NOCa>=70%

• CBOa<20%

• CFa<20%

• WMCa<30%

• La specificità dell’applicazione influenza il numero atteso di metodi rispetto a quello effettivo.

• L’accoppiamento influenza il valore atteso di collaborazioni tra le classi rispetto al valore effettivo.

• La gerarchia di classi influenza il valore atteso della profondità dell’albero di ereditarietà rispetto a quello effettivo.


Prodotto software sviluppato Valutazione Portabilità Sviluppatore Prodotto sviluppato


Tavola di decisione per Goal 3

c1. DITa>DITe Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y

c2. NOCa>NOCe Y Y Y Y Y Y Y Y N N N N N N N N

c3. CBOa<CBOe Y Y Y Y N N N N Y Y Y Y N N N N

c4. CFa<CFe Y Y N N Y Y N N Y Y N N Y Y N N

c5. WMCa<WMCe Y N Y N Y N Y N Y N Y N Y N Y N


a2. aumento profondità gerarchica x x x x x x x x

a3. riduzione specificità di classe x x x x x x x x

a4. riduzione accoppiamento x x x x x x x x x x x x

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Legenda: <=30%


<=20%

>20%

>=70%

<70%


Metriche calcolate Prospettive future

WMC basso • Maggiori possibilità di riutilizzo delle classi

DIT basso • Minore complessità progettuale• Possibilità di prevedere il

comportamento delle classi

NOC nullo • Sistema non necessita di numerosi collaudi

RFC basso • Semplicità di collaudo• Minore complessità progettuale

CBO basso • Riutilizzo possibile delle classi• Semplificazione delle modifiche e

del collaudo che verifica tali modifiche

Conclusioni


Metriche calcolate Prospettive future

LCOM basso • Minore complessità progettuale

MIF basso • Ereditarietà ininfluente sul software

CF basso • Minore complessità software• Maggiore comprensibilità• Facilità di manutenzione• Possibilità di riutilizzo

CS basso • Classe con poche responsabilità• Possibilità di riutilizzo• Semplicità d’implementazione e

collaudo

Vg basso • Buona manutenibilità e testabilità

ConclusioniConclusioni

corso di laurea triennale in ingegneria informatica ingegneria del software il test

Documents