La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software Il test.

Presentazioni simili


Presentazione sul tema: "Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software Il test."— Transcript della presentazione:

1 Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software Il test

2 Ingegneria del software Sommario Introduzione al test Teoria del test Tecniche e metodologie di test Qualità del software Metriche per la stima di qualità Test e qualità dellapplicazione sviluppata Conclusioni

3 Ingegneria del software Cosè il test? Insieme di misure di controllo utili a verificare la qualità di un software.

4 Ingegneria del software Scopo Rilevare gli errori

5 Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software Teoria del test

6 Ingegneria del software 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 lesistenza 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.

7 Ingegneria del software Teoria del test Criterio di selezione del test Definizione 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 lesecuzione di P su T assicura che ogni statement in P sia eseguito almeno una volta.

8 Ingegneria del software Proprietà Proprietà del criterio di test: –Affidabilità –Validità Definizione Un criterio di test è affidabile se tutti gli insiemi (di casi di test) che soddisfano il criterio individuano gli stessi errori Definizione Un criterio di test è valido se per ogni errore nel programma cè un qualche insieme che soddisfa il criterio che rileva lerrore.

9 Ingegneria del software Tesi 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

10 Ingegneria del software Assiomi 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 è linsieme 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 lintero programma non è detto che sia soddisfatto per ogni suo componente. Assioma di anticomposizione (duale dellassioma 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

11 Ingegneria del software 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.

12 Ingegneria del software Riferimenti 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: ,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.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 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 Assiomi di Weyunker –E.J. Weyunker,"Axiomatizing software test data adequacy, IEEE transaction on software engineering, 12(12): , Dec. 1986

13 Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software Livelli di test

14 Ingegneria del software Livelli 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

15 Ingegneria del software Test di unità Controllare separatamente le diverse parti di un modulo di un programma, per rilevare gli errori e migliorarle durante la codifica

16 Ingegneria del software Test dintegrazione I moduli sono integrati in sottosistemi più grandi i quali a loro volta sono integrati in sistemi più complessi. Il test dintegrazione si effettua durante lintegrazione e consiste in un controllo delle interfacce dei moduli integrati

17 Ingegneria del software Test di sistema Consiste nel verificare che le specifiche di progetto di un programma siano state soddisfatte e i miglioramenti apportati

18 Ingegneria del software Test di accettazione Imposto dal cliente per verificare che il programma soddisfi le richieste del cliente stesso

19 Ingegneria del software Test di regressione Verifica che non si siano introdotti errori in versioni successive

20 Ingegneria del software Processo 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 lelenco 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 dellesecuzione del codice ottenuto applicando i casi di test Error report: –Descrive gli errori che si sono presentati –Le azioni intraprese per rimuoverli

21 Ingegneria del software 2. Principali tecniche e metodologie di test Ogni fase del ciclo di vita si conclude con unattività 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 dellultima 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

22 Ingegneria del software Tecniche 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 sullosservazione del suo comportamento in esecuzione (tipicamente il test) Analisi formale: –Processo che usa rigorose tecniche matematiche per lanalisi di algoritmi Adoperato soprattutto per la verifica del codice e dei requisiti specie se non sono specificati con linguaggi formali

23 Ingegneria del software Tecniche di analisi statica Analisi statica in compilazione Code reading Control flow analysis Data flow analysis Code inspections or reviews Esecuzione simbolica

24 Ingegneria del software Tecniche di analisi dinamica Black Box Testing o Testing Funzionale: –Testa il programma per esaminare come dovrebbe essere È fondato sullanalisi 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 delloracolo, 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

25 Ingegneria del software Tecniche di testing funzionale … cosa testare –Funzionalità esterne (visibili allutente e definite dai requisiti e dalle specifiche) –Funzionalità interne ( non visibili allutente e definite dal progetto di high e low level) …. partendo da –Definizione Funzionalità: Insieme dei dati dingresso, dati duscita, precondizioni e postcondizioni

26 Ingegneria del software Effettuare un test È necessario conoscere il comportamento atteso per poterlo confrontare con quello osservato e per poter definire loracolo –Loracolo 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

27 Ingegneria del software Test 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

28 Ingegneria del software Documentazione dei test I test eseguiti vanno documentati producendo una check list: funzionalitàTCInputOutputPrecondPostcondPrioritàesito

29 Ingegneria del software Definizione della check list Si parte dallanalisi 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 lanalisi dei documenti di progetto di high e low level e con lestrazione 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

30 Ingegneria del software Tecniche 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)

31 Ingegneria del software 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 nellesecuzione dei casi di test.

32 Ingegneria del software Metodo di copertura delle istruzioni 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.

33 Ingegneria del software Metodo di copertura delle istruzioni 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 lerrore e che genera il fallimento non viene eseguita

34 Ingegneria del software Metodo di copertura delle diramazioni 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.

35 Ingegneria del software Metodo di copertura delle condizioni 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.

36 Ingegneria del software Metodo 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 lattraversamento almeno una volta di almeno un cammino per ogni classe

37 Ingegneria del software Metodo di copertura dei cammini minimi 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

38 Ingegneria del software Mutation testing Mutanti: testing strutturale Obiettivo: garantire che, durante la fase di test, ogni mutante (variazione del programma) produca unuscita diversa dalluscita del programma originale.

39 Ingegneria del software Test 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à

40 Ingegneria del software Ereditarietà –Flattering inheritance –Test incrementale Genericità –Data-flow analysis Polimorfismo –Data-flow analysis

41 Ingegneria del software 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

42 Ingegneria del software 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?

43 Ingegneria del software 1 a Soluzione 1 a Soluzione Appiattire lintera gerarchia e considerare ogni classe come una componente totalmente indipendente: Flattering inheritance Svantaggio: –Si perde lincrementalità e la riusabilità

44 Ingegneria del software 2 a 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

45 Ingegneria del software Test 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

46 Ingegneria del software Test del polimorfismo Molte implementazioni per una singola operazione –La selezione delleffettivo 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 unoperazione –Come trattare parametri polimorfici

47 Ingegneria del software Soluzioni al problema del test del polimorfismo e costrutti generici Nel caso del polimorfismo, invece, mentre nella programmazione procedurale le chiamate di procedura sono legate staticamente, nella programmazione OO, unentità può riferire oggetti di classi diverse di una gerarchia, quindi si hanno molte implementazioni per una singola operazione. La selezione delleffettivo codice da chiamare è proposta a run-time. I problemi che sincontrano nellambito del test sono dovuti alla scelta di come coprire tutte le chiamate alle operazioni polimorfiche, come esercitare tutte le implementazioni di unoperazione 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 dindividuare le effettive chiamate delle unità interessate (data-flow analysis).

48 Ingegneria del software Tecniche 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 lesecuzione di tali test richiede solo modifiche sintattiche

49 Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software Metriche di prodotto per il software Fattori di qualità ISO 9126 metriche

50 Ingegneria del software I fattori di qualità ISO 9126 Funzionalità OpportunitàPrecisioneInteroperabilitàConformitàSicurezza Affidabilità Maturità Resistenza ai guasti Ricuperabilità

51 Ingegneria del software I fattori di qualità ISO 9126 Facilità duso Comprensibilità Facilità dapprendimento Facilità duso Facilità di manutenzione Facilità danalisi Facilità di modifica Facilità di collaudo Stabilità

52 Ingegneria del software I fattori di qualità ISO 9126 Efficienza Comportamento nel tempo Comportamento con le risorse Portabilità AdattabilitàInstallabilitàConformitàSostituibilità

53 Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software Misurazione del software orientato allobiettivo

54 Ingegneria del software 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]

55 Ingegneria del software Paradigma 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 lobiettivo –Identificare metriche ben formulate per aiutare a rispondere a queste domande

56 Ingegneria del software Metriche calcolate per il prodotto sviluppato Modello di qualità GQM (Goal Question Metric) Modello di qualità GQM (Goal Question Metric) Stabilire un obiettivo di misurazione esplicito (Goal) Stabilire un obiettivo di misurazione esplicito (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 valid software engineering data, IEEE Trans. Software Engineering, vol 10, 1984, pp ] [Basili e Weiss, A methodology for collecting valid software engineering data, IEEE Trans. Software Engineering, vol 10, 1984, pp ]

57 Ingegneria del software Descrizione del modello Assume la seguente forma: –Analizzare (nome dellattività o dellattributo che deve essere misurato) con lo scopo di (obiettivo generale dellanalisi) con riferimento a (aspetto dellattività o dellattributo considerato) dal punto di vista di (persone che hanno un interesse nella misurazione) nel contesto di (ambiente in cui viene svolta la misurazione)

58 Ingegneria del software Modello 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 ScopoProspettiva Punti di Vista Contesto Quality FocusVariation Factors descrive la relazione tra i fattori di variazione e le metriche del quality focus contiene i quesiti e le metriche per la conformità del processo o della caratterizzazione del prodotto Baselines HypothesisImpact on Baseline Hypothesis contiene i quesiti e le metriche dei modelli di conferma e di validità descrive la relazione tra i fattori di variazione e le metriche del quality focus

59 Ingegneria del software Modello 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 (metriche necessarie per linterpretazione) Stati condizionali: combinazione di valori che possono assumere le condizioni (baseline) Attività di miglioramentoRegola di decisione

60 Ingegneria del software Metriche di prodotto Metriche per il modello analitico: –Funzionalità fornita –Dimensioni del sistema –Qualità delle specifiche Metriche per il modello progettuale –Dellarchitettura –A livello di componenti –Della progettazione dellinterfaccia –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 dellefficacia –Sul processo

61 Ingegneria del software Metriche per il modello concettuale basate sulle funzionalità Metrica dei punti funzione usata per : –Stimare il costo o limpegno 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

62 Ingegneria del software Punti 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 unaltra applicazione e fornisce dati distinti, orientati allapplicazione, 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 nellapplicazione e fornisce informazioni allutente. In questo contesto loutput esterno fa riferimento ai report, agli schemi, ai messaggi derrore e così via.

63 Ingegneria del software Calcolo 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 allinterno dellapplicazione e vengono gestiti tramite gli input esterni. Numero di file dellinterfaccia esterna (EIF). Ogni file dellinterfaccia esterna è un raggruppamento logico di dati che risiede esternamente rispetto allapplicazione, ma che fornisce dati utilizzati dallapplicazione.

64 Ingegneria del software Conteggio dei punti funzione Fattore di peso Parametro di misurazione Conteggi oSempliceMedio Compless o Input utente 346= Output utente 457= Interrogazioni utente 346= File 71015= Interfacce esterne 5710= Totale

65 Ingegneria del software Conteggio dei punti funzione Dove conteggio-totale è la somma di tutte le voci FP tratte dalla tabella precedente

66 Ingegneria del software Valori 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 lapplicazione? 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.Linserimento 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.Lelaborazione interna è complessa? 11.Il codice è progettato per essere riutilizzabile? 12.Nel progetto sono compresi la conversione e linstallazione? 13.Il sistema è progettato per più installazioni in più organizzazioni? 14.Lapplicazione è progettata per facilitare le modifiche e la facilità duso 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]

67 Ingegneria del software Metriche per il modello progettuale Metriche per la progettazione orientata agli oggetti Metriche CK Metriche Mood Secondo Whitmire, esistono nove caratteristiche distinte e misurabili di un progetto orientato agli oggetti. [Whitmire, Object-Oriented Design Measurement, Wiley, 1997]

68 Ingegneria del software Caratteristiche di un progetto orientato 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 unindicazione indiretta del valore fornito al cliente da unapplicazione 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 laccoppiamento allinterno del sistema.

69 Ingegneria del software Caratteristiche di un progetto orientato agli oggetti 2/2 4.Sufficienza. E il grado in cui unastrazione possiede le caratteristiche richieste o il grado in cui un componente progettuale possiede le caratteristiche della sua astrazione, dal punto di vista dellapplicazione corrente. 5.Completezza. E linsieme di caratteristiche rispetto alle quali si deve confrontare lastrazione 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 unoperazione. 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.

70 Ingegneria del software Metriche orientate alle classi: metriche 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 ]

71 Ingegneria del software 1. Metodi pesati per classe Metodi pesati per classe (WMC - Weighted Methods per Class). Una classe definisce n metodi di complessità c1, c2, …, cn WMC = Σ ci i=1,...,n La 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 WMC VG(m) = complessità ciclomatica del metodo m MIm(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 è lalbero dereditarietà; nonché, allaumentare di questo valore, è probabile che la classe divenga più specifica dellapplicazione, limitando il suo potenziale riutilizzo.

72 Ingegneria del software 2. Profondità dellalbero di ereditarietà Profondità dellalbero di ereditarietà (DIT - Depth of the Inheritance Tree). Indica la distanza massima di un nodo (una classe) dalla radice dellalbero 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.

73 Ingegneria del software 3. 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 lastrazione 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.

74 Ingegneria del software 4. Risposte per classe Risposte per classe (RFC - Response For a Class). Indica linsieme 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.

75 Ingegneria del software 5. Accoppiamento fra le classi di oggetti 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à, laccoppiamento va tenuto al minimo; esso influisce sullimpatto di modifiche in altri moduli.

76 Ingegneria del software 6. Mancanza di coesione nei metodi 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 luno allaltro tramite gli attributi, ma questo comporta una maggiore complessità del progetto della classe. Si preferisce LCOM basso e coesione alta.

77 Ingegneria del software Metriche orientate alla classe: le metriche MOOD 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 ]

78 Ingegneria del software Fattore di ereditarietà dei metodi Fattore di ereditarietà dei metodi (MIF- Method Inheritance Factor) Il grado in cui larchitettura della classe di un sistema orientato agli oggetti utilizza lereditarietà 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 dellarchitettura; Ci è una classe allinterno dellarchitettura = 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 unindicazione dellimpatto dellereditarietà sul software.

79 Ingegneria del software Fattore 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=1se 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.

80 Ingegneria del software Metriche orientate agli oggetti di Lorenz e Kidd 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 lintero sistema orientato agli oggetti. Le metriche basate sullereditarietà 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 ]

81 Ingegneria del software Dimensioni 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 limplementazione ed il collaudo.

82 Ingegneria del software Numero di operazioni aggiunte da una sottoclasse 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 allastrazione 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.

83 Ingegneria del software Metriche 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 distinti n2 = il numero di operandi distinti N1 = il numero totale di operatori N2 = il numero totale di operandi e sono descritte dalle seguenti metriche: Lunghezza del programma N= N1+ N2 Vocabolario del programma n= n1 + n2 Volume V= N * (LOG2 n) Difficoltà D= (n1 /2) * (N2 / n2) Sforzo E= D * V [Halstead, Element of Software Science, North-Holland, 1977.]

84 Ingegneria del software 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.]

85 Ingegneria del software Grafo 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à.

86 Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software Esempio applicativo del modello GQM

87 Ingegneria del software Valutazione di metriche secondo il modello GQM Fattori di qualità ISO 9126 considerati: facilità duso facilità di manutenzione portabilità PRODOTTO SOFTWARE SVILUPPATO Facilità d'usoFacilità di manutenzionePortabilità GOAL 1X GOAL 2 X GOAL 3 X

88 Ingegneria del software GOAL 1 - Facilità duso G1- Facilità duso QF1- Comprensibilità QF2-Facilità dapprendimento QF3- Facilità duso RFCLCOMCSNOAWMCMIFVg Q2 DIT Q1Q3Q4Q5 Quanto è profonda la gerarchia di classi? Qual è il grado di complessità della risposta ad un messaggio? Quanto è generica una classe? Quanto è complessa una classe? Qual è il grado di coesione interna di una classe?

89 Ingegneria del software Quality FactorsVariation Factors DIT e : profondità dellalbero di ereditarietà NOA e : numero di operazioni aggiunte ad una sottoclasse MIF e : fattore di ereditarietà dei metodi RFC e : risposte per classe LCOM e : mancanza di coesione nei metodi CS e : dimensione della classe WMC e : metodi pesati per classe Vg e : complessità ciclomatica Coesione interna Profondità della gerarchia di classe Complessità di classe Generalizzazione di classe Complessità di risposta Oggetto dello studioScopoProspettivaPunti di vistaContesto Prodotto software sviluppatoValutazioneFacilità d'usoSviluppatoreProdotto sviluppato Foglio metrico

90 Ingegneria del software Baseline HypothesisBaseline Impacts DIT a <30% NOA a <30% MIF a <30% RFC a <20% LCOM a >80% CS a <20% WMC a <30% Vg a <20% La profondità gerarchica di classe influenza la profondità dellalbero 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. Oggetto dello studioScopoProspettivaPunti di vistaContesto Prodotto software sviluppatoValutazioneFacilità d'usoSviluppatoreProdotto sviluppato

91 Ingegneria del software Tavola di decisione per Goal 1 c1. DITaLCOMe YYYYYYYYNNNNNN c6. CSa30% <=20% >20% >=80% <80%

92 Ingegneria del software GOAL 2 - Facilità di manutenzione G2- Facilità di manutenzione QF4- Facilità di analisi QF5- Facilità di modifica QF6- Facilità di collaudo CBORFCCFWMCMIF Q7 NOC Q6Q8 Q9 Qual è la capacità di funzionamento delle classi figlie in una gerarchia di classe? Qual è il grado di profondità di una gerarchia di classe? Qual è il grado dimpegno per il collaudo? Qual è il grado di accoppiamento tra le classi?

93 Ingegneria del software Foglio metrico Quality FactorsVariation Factors NOC e : numero di classi figlie CBO e : accoppiamento fra le classi di oggetti CF e : fattore di accoppiamento MIF e : fattore di ereditarietà dei metodi RFC e : risposte per classe WMC e : metodi pesati per classe Funzionamento classi figlie Accoppiamento Profondità della gerarchia di classe Impegno del collaudo Oggetto dello studioScopoProspettivaPunti di vistaContesto Prodotto software sviluppatoValutazioneFacilità di manutenzioneSviluppatoreProdotto sviluppato

94 Ingegneria del software Baseline HypothesisBaseline Impacts NOC a <30% CF a <20% CBO a <20% MIF a <30% RFC a <20% WMC a <30% Il funzionamento delle classi figlie influenza il valore atteso del numero di classi figlie rispetto a quello effettivo. Laccoppiamento 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. Limpegno del collaudo influenza il numero atteso di risposte per classe ed il numero atteso di metodi per classe rispetto ai valori effettivi. Oggetto dello studioScopoProspettivaPunti di vistaContesto Prodotto software sviluppatoValutazioneFacilità di manutenzioneSviluppatoreProdotto sviluppato

95 Ingegneria del software Tavola di decisione per Goal 2 c1. NOCa30% <=20% >20%

96 Ingegneria del software G3- Portabilità QF7- Adattabilità QF8- Riutilizzo QF9- Sostituibilità CBODITCFWMC Q11 NOC Q10 Q12 GOAL 3 - Portabilità Qual è il grado di profondità di una gerarchia di classe? Qual è il grado di accoppiamento tra le classi? Qual è il grado di specificità della classe?

97 Ingegneria del software Foglio metrico Quality FactorsVariation Factors DIT e : profondità dellalbero di ereditarietà NOC e : numero di classi figlie CBO e : accoppiamento fra le classi di oggetti CF e : fattore di accoppiamento WMC e : metodi pesati per classe Specificità dellapplicazione Accoppiamento Profondità della gerarchia di classe Oggetto dello studioScopoProspettivaPunti di vistaContesto Prodotto software sviluppatoValutazionePortabilitàSviluppatoreProdotto sviluppato

98 Ingegneria del software Baseline HypothesisBaseline Impacts DIT a >=70% NOC a >=70% CBO a <20% CF a <20% WMC a <30% La specificità dellapplicazione influenza il numero atteso di metodi rispetto a quello effettivo. Laccoppiamento influenza il valore atteso di collaborazioni tra le classi rispetto al valore effettivo. La gerarchia di classi influenza il valore atteso della profondità dellalbero di ereditarietà rispetto a quello effettivo. Oggetto dello studioScopoProspettivaPunti di vistaContesto Prodotto software sviluppatoValutazionePortabilitàSviluppatoreProdotto sviluppato

99 Ingegneria del software Tavola di decisione per Goal 3 c1. DITa>DITe YYYYYYYYYYYYYYYY c2. NOCa>NOCe YYYYYYYYNNNNNNNN c3. CBOa30% <=20% >20% >=70% <70%

100 Ingegneria del software Metriche calcolateProspettive future WMC bassoMaggiori possibilità di riutilizzo delle classi DIT bassoMinore complessità progettuale Possibilità di prevedere il comportamento delle classi NOC nulloSistema non necessita di numerosi collaudi RFC bassoSemplicità di collaudo Minore complessità progettuale CBO bassoRiutilizzo possibile delle classi Semplificazione delle modifiche e del collaudo che verifica tali modifiche Conclusioni

101 Ingegneria del software Metriche calcolateProspettive future LCOM bassoMinore complessità progettuale MIF basso Ereditarietà ininfluente sul software CF bassoMinore complessità software Maggiore comprensibilità Facilità di manutenzione Possibilità di riutilizzo CS bassoClasse con poche responsabilità Possibilità di riutilizzo Semplicità dimplementazione e collaudo Vg bassoBuona manutenibilità e testabilità Conclusioni


Scaricare ppt "Corso di Laurea Triennale in Ingegneria Informatica Ingegneria del software Il test."

Presentazioni simili


Annunci Google