Anna Rita Fasolino » 25.Metriche Software – Parte seconda

Metriche di design a livello dei componenti

Metriche che valutano caratteristiche interne dei moduli software, quali coesione, accoppiamento e complessità.

Esempi:
Le metriche di coesione di Bieman [Measuring Functional Cohesion, 1994, IEEE Transactions on Software Engineering, Volume 20, Issue 8 (August 1994)] si basano sull’analisi delle funzioni e dei dati elaborati da un modulo, cercando di stabilire se il modulo svolge funzioni che operano sugli stessi dati (buona coesione), oppure su dati disgiunti (scarsa coesione).

Metriche di design a livello dei componenti (segue)

La Metrica di accoppiamento proposta da Dhama [H. Dhama, Quantitative Models of Cohesion and Coupling in Software] tiene conto del flusso di dati e di controllo fra i moduli, dell’accoppiamento a variabili globali, e dell’accoppiamento ambientale (mediante fan-in e fan-out) fra moduli.

Le metriche di complessità misurano in vario modo la complessità del Control Flow Graph.

Metrica di McCabe

Metrica strutturale relativa al Control Flow Graph di un programma G.

È detta anche Numero Ciclomatico V(G).

Rappresenta la complessità logica del programma e quindi lo sforzo per realizzarlo (o per comprenderlo)

Per programmi strutturati V(G) è uguale al n.ro di predicati aumentato di uno:
V(G) = P + 1
P: n.ro di predicati (semplici ed a due vie) in G
Predicati: decisioni – semplici, ovvero non composte con connettivi logici – in strutture di controllo (if-then-else, repeat-until, whiledo, …);

Metrica di McCabe (segue)

Rappresentando un programma con il Control Flow Graph, il numero ciclomatico V(G) può essere calcolato nel seguente modo:
V(G) = E – N + 2P

• N è il n.ro di nodi,
• E è il n.ro di archi,
• P è il n.ro di componenti connesse
  • (per una sola unità di programma P è pari ad 1).

Un altro modo per calcolare V(G) è:
V(G) = numero di aree chiuse del CfG + 1.

Complessità ciclomatica di un programma

Cammini linearmente indipendenti

La complessità ciclomatica V(G) rappresenta il numero di cammini linearmente indipendenti del Control Flow Graph.

La definizione di “cammini linearmente indipendenti” risiede nella definizione di lineare indipendenza a livello algebrico, estesa ai cammini su grafi orientati.

Ad esempio, una complessità ciclomatica di 5 significa che 5 è il numero massimo di cammini possibili tra loro indipendenti e ogni altro cammino possibile sul grafo si può costruire a partire da uno di quei 5 (vale a dire è una combinazione lineare di uno di essi).

Trovare i 5 cammini indipendenti significa trovare una base per l’insieme di tutti i possibili cammini di un dato grafo G.

Cammini linearmente indipendenti (segue)

In un CFG un cammino si dice indipendente se introduce almeno un nuovo insieme di istruzioni o una nuova decisione, rispetto ad un altro cammino indipendente;
In un CfG un cammino è indipendente se attraversa almeno un arco non ancora percorso dagli altri già considerati.

L’insieme di tutti i cammini linearmente indipendenti di un programma forma i cammini di base.
Tutti gli altri possibili cammini nel CfG sono generati da una combinazione lineare di quelli di base.
Dato un programma, l’insieme dei cammini di base non è unico.

Metriche per il Codice Sorgente

• Linee di Codice
• Metriche di Halstead

Lines of Code (LOC)

È una metrica dimensionale.

Misura la lunghezza di un programma con il numero di linee di codice.

Esistono diverse possibili definizioni

• qualsiasi linea di codice, inclusi i commenti;
• tutte le linee di codice, esclusi i commenti (in questo caso si distinguono in Non Comment LOC (NCLOC) e Effective LOC (ELOC);
• solo le istruzioni eseguibili (EXLOC), con anche le Data Declaration LOC (DDLOC), cioè le istruzioni dichiarative dei dati.

La definizione più accettata è la seguente:
Una linea di codice è ogni linea di testo di un programma che non sia bianca o un commento, indipendentemente dal numero di istruzioni in essa inclusa. In particolare, tali linee di codice possono contenere intestazioni di unità di programma, dichiarazioni ed istruzioni esecutive.

Osservazioni sulle LOC

I commenti sono una parte importante del processo di sviluppo di un programma, per cui ignorarle, e quindi non invogliare il programmatore ad inserirle può essere deleterio; ovviamente I commenti vanno prodotti in modo consistente (e non inseriti all’ultimo solo per motivi di tariffazione).

• Le Comment LOC (CLOC) possono essere valutate in base alla loro importanza
  • differenza fra commenti inseriti utilizzando metodi formali (per cui, utilizzando appositi tool, si possa effettuare un testing automatico del programma) e commenti inseriti all’ultimo momento prima della consegna.

Alcune misure derivate dalle LOC sono:

Densità di commento = CLOC/LOC
Effort = 5.2*KLOC^0.91
con Effort misurato in mesi/uomo.

Vantaggi e svantaggi delle LOC

Vantaggi:

• Molto semplici da calcolare automaticamente;
• Molto intuitive.

Svantaggi

• Dipendenti dal linguaggio di programmazione
  • Studi empirici sono stati svolti per valutare la dipendenza del numero di LOC dal linguaggio, a parità di algoritmo;
• Dipendenti dallo stile di programmazione
  • Bisogna definire uno standard di formattazione del testo sorgente cui conformarsi, oppure uno strumento di formattazione automatica
  • Facilmente “falsificabili”!
• Diventano una misura inconsistente in presenza di generatori automatici di codice.

Altri usi delle LOC

Le LOC sono utilizzate per misurare indirettamente altri attributi.

Esempi:

• la probabilità di presenza di errori nel programma (cresce con la lunghezza);
• il tempo per produrlo;
• la produttività (o il compenso) di un programmatore;
• stima dei costi di un progetto SW.

Nelle LOC bisognerebbe contare anche tutte le linee di codice non direttamente legate ai prodotti consegnati, ad esempio:

• Codice per il testing;
• Codice per I prototipi.

Metriche di Halstead (1977)

Halstead [Halstead, Elements of Software Science, Elsevier Science Inc, 1977] ha proposto un insieme di metriche per la lunghezza ed il volume di un programma. Basate su:

• n1 = numero di operatori distinti che compaiono in un programma
  • Ad esempio costrutti di controllo, condizionali, assegnazioni, etc;
• n2 = numero di operandi distinti che compaiono in un programma
  • Ad esempio variabili e costanti di un programma;
• N1 = numero totale delle occorrenze di operatori;
• N2 = numero totale delle occorrenze di operandi;

Si definiscono:
Vocabolario: n=n1+n2
Lunghezza: N=N1+N2 (è una lunghezza concettuale)
Volume: V=N*log₂n

Metriche di Halstead

Volume V=N*log₂n
log₂n è il numero di bit necessari per rappresentare il vocabolario;
V è il numero di bit necessari per rappresentare il programma nella sua forma minima, cioè indipendentemente dalla lunghezza dei nomi dei token;

• Il concetto di Volume è legato quindi al contenuto di informazione del programma e dovrebbe dipendere unicamente dall’algoritmo scelto, non dall’espressività del linguaggio di programmazione.
• Il Volume è usato come una metrica dimensionale del software.
• Alcuni esperimenti hanno mostrato la correlazione fra il volume e le LOC, così come tra V e la difettosità dei moduli…

Stima della lunghezza di un programma

Halstead propose la seguente formula per stimare la lunghezza di un programma in base solo a n1 e n2:

N^=n1 log₂n1 + n2 log₂n2

Le statistiche effettuate su algoritmi pubblicati sembrano indicare un valore medio dell’errore relativo della stima pari a:

(N-N^)/ N < 10%

Volume Potenziale

Molte altre metriche sono state derivate da Halstead:

Volume potenziale:
in un caso ideale
N1= n1 = 2 (solo due operatori: nome funzione e parentesi);
N2 = n2 (tutti operandi distinti).

V* = (2+n₂) log₂(2+n2)

É il volume del programma più sintetico nel quale può essere codificato un algoritmo.
Viene usato per introdurre il concetto di Livello di Implementazione.

Livello di Implementazione, Difficoltà e Sforzo

Livello di implementazione
L=V* / V
maggiore è il volume V minore è L; un algoritmo implementato con un linguaggio di programmazione con basso livello espressivo richiede un maggiore volume.
È possibile approssimare L con L^ = (2*n₂)/(n1*N₂)

Difficoltà
D=1/L
difficoltà di implementare un algoritmo in un certo linguaggio di programmazione.

Sforzo
E = V*D = V/L = V²/V*
può essere pensato come lo sforzo richiesto per comprendere una implementazione piuttosto che quello per produrla.

Considerazioni

Nella storia della misurazione del software il lavoro di Halstead ha avuto dei meriti importanti:

• primo tentativo, anche se non perfetto, di derivare una misura software a partire dalla teoria;
• prima misura software usata in un contesto industriale;
• primo lavoro che ha evidenziato le potenzialità della misurazione del software nello sviluppo del software;
• le conclusioni che essa propone sono suscettibili di verifica sperimentale.

Difetti

• Misure “generali” e non orientate ad un particolare compito;
• Metrica basata sul codice e ideata quando (1970) i fondamenti dell’ingegneria del software non erano ancora pienamente apprezzati (in particolare l’importanza della progettazione del sistema);
• Regole di conteggio non precisamente definite
  • Problemi a causa di linguaggi ambigui.

Metriche per il Testing

Molte metriche proposte in letteratura si riferiscono al processo di testing (es. sforzo, durata, # difetti rilevati…), non alle caratteristiche dei test in sé.

Per progettare ed eseguire l’attività di testing, possono essere utili le metriche del livello analisi, design e codice.

Metriche per il testing (segue)

Per prevedere l’impegno delle varie attività di testing si possono usare:

• metriche per la misura della funzionalità, per pianificare il testing black-box.
• metriche per il design architetturale, per stimare la complessità del testing di integrazione e la quantità di driver e stub da sviluppare.
• la complessità ciclomatica può essere utile per avere una misura della complessità del testing di unità (white-box).

É inoltre possibile relazionare sforzo e durata del testing, errori scoperti e numero di test case prodotti ai FP (per fare stime per analogia).

Metriche di Binder

Binder [Binder, Object Oriented Software Testing, Communications of the ACM, Volume 37,  Issue 9  (September 1994)] propone una varietà di metriche per valutare la testabilità di sistemi object oriented.

• Mancanza di coesione nei metodi (già vista);
• Percentuale di attributi pubblici o protetti
  • Creano elevate potenzialità di coupling;
• Accesso pubblico ai dati (PAD)
  • Elevati valori di PAD portano a side effect fra le classi;
• Numero di classi radice
  • Più classi radice, più gerarchie da testare;
• Fan-In (conta il numero di classi da cui una classe eredita);
• Numero di figli e Profondità dell’albero di ereditarietà.

Metriche per la manutenzione

Le metriche per la manutenzione si occupano di prevedere la complessità del processo di manutenzione;
Dipendono, quindi, dal processo di manutenzione che si va a istanziare.

Ad esempio (Indice di Maturità del Software):
SMI = [M_T – (F_a+F_C+F_d) ] / M_T

• M_T: numero di moduli nella versione corrente;
• F_C: numero di moduli modificati;
• F_a: numero di moduli aggiunti;
• F_d: numero di moduli eliminati.

Al tendere di SMI a 1 il prodotto tende a stabilizzarsi.
Il tempo medio per produrre una nuova versione del prodotto è correlato a SMI.

Approcci per proporre delle metriche

Per proporre delle metriche valide, bisogna trovare le relazioni tra entità e metriche.

Tali relazioni devono essere ottenute tramite studi empirici…
si cerca di trovare una legge secondo la quale la misura di un’entità possa essere valutata come funzione delle metriche di attributi direttamente misurabili.

Oppure tramite la costruzione di modelli metrici arbitrari, nei quali le relazioni tra attributi interni ed esterni sono ipotizzati da esperti e successivamente validati.

In [Kan, Metrics and Models in Software Quality Engineering, Second Edition, Addison-Wesley Longman Publishing Co., Inc. Boston] si possono trovare molte indicazioni su come effettuare una campagna di misure e su come validare empiricamente l’efficacia di metriche proposte nella descrizione di dati fattori di qualità.

Molto utile anche il libro di Fenton e Pfleeger [Fenton and Pfleeger, Software Metrics: A Rigorous and Practical approach, Second edition, PWS Publishing Co. Boston, MA, USA, 1998].

Goal-Question-Metric (GQM) Paradigm

• Introdotto da Basili e Rombach a partire dal 1988
  Basili, V. R., Caldiera, G. and Rombach, H. D., “The Goal Question Metric Approach”, Encyclopedia of Software Engineering, Wiley&Sons Inc., 1994.
• L’applicazione di un processo GQM permette di effettuare un programma di raccolta dati:
  • Per effettuare l’assessment (valutazione) dell’efficacia dei processi aziendali;
  • Per valutare la qualità di prodotti esistenti;
  • …

GQM

Basato sull’idea che per poter misurare con successo occorre:

• Stabilire i Goals (gli Obiettivi) che si intendono perseguire con il programma di raccolta dati;
• A partire dagli Obiettivi, derivare (attraverso le Questions) i dati (le Metriche) che permettono di valutare il raggiungimento degli obiettivi;
• Definire uno schema di riferimento per interpretare i dati rispetto agli obiettivi fissati.

Il risultato sarà un modello di misurazione a tre livelli (Concettuale, Operazionale, Quantitativo) corrispondenti a Goal/ Questions/ Metrics, ottenuto in tre macro-fasi.

Misurazione Goal-Based

Goal-Question-Metric Paradigm

Goals – Obiettivi

• Quali sono gli obiettivi (attributi esterni) che si vogliono perseguire?
  • Un goal si definisce individuando l’oggetto dello studio, le motivazioni per la misurazione, un modello di qualità di riferimento, un punto di vista per l’osservazione, l’ambiente a cui l’oggetto appartiene.
  • Possibili oggetti: Prodotti/ Processi/ Risorse.
• Esempio di Goal:
  • Analizzare le attività di progettazione e verifica del processo di sviluppo, al fine di valutare l’efficacia del processo di rilevazione dei difetti presenti nel software, dal punto di vista del management e del team di sviluppo. Si vuole verificare se il field test ha un rapporto costo/benefici soddisfacente.

Questions

Questions – Domande
Quali domande ci permettono di valutare se e fino a che punto gli obiettivi vengono raggiunti?

Esempio di domande:
Q1) Quale è il costo del field test?
Q2) Quali sono I vantaggi?

Metrics

Metrics – Metriche

Quali metriche consentono di dare risposta alle domande?

Q1)-> M11: Giornate per singolo test
-> M12: Costo per figura professionale
-> M13: Numero di Persone coinvolte
-Q2) -> M21: Numero di errori gravi rilevati
-> M22: Numero di errori lievi rilevati

Un esempio di Questions

Goal: Analizzare l'usabilità di un Tool CASE dal punto di vista degli sviluppatori secondo il modello di qualità ISO 9126, per valutarne l'adeguatezza funzionale.

Goal-Question-Metric Paradigm

Si costruisce una matrice Goal-Question GQ tale che:
GQ_ij=1 se la j-esima Question contribuisce a valutare il soddisfacimento dell’i-esimo Goal.

Si costruisce una matrice Question-Metrics QM tale che:
QM_ij=1 se la j-esima Metric contribuisce a rispondere alla i-esima Question.

Si misurano i valori delle metriche M_j.
Si calcolano, indirettamente i valori associati alle questions e da questi i valori associati ai goals.

Osservazioni

I valori per le matrici QM e GQ sono spesso ottenuti da questionari compilati dagli esperti dei processi aziendali e dai responsabili della qualità che utilizzano un insieme discreto di valori possibili (poi normalizzati tra 0 e 1).

La difficoltà nell’esecuzione di un GQM sta nella ricerca di matrici che portino a risultati soddisfacenti.

I valori possono essere aggiustati a seguito di osservazioni fatte a posteriori che vadano a correggere delle dipendenze tra question e goal che non siano soddisfacenti;
Dei feedback possono essere ottenuti dall’applicazione dello stesso modello GQM a diversi progetti nell’ambito della stessa azienda e dal confronto dei risultati ottenuti.