Anna Rita Fasolino » 24.Metriche Software – Parte prima

Misurare il software: una premessa

L’Ingegneria del Software non studia le leggi quantitative della fisica, ma processi e prodotti legati ad attività umane.

Non è possibile effettuare misure assolute, ma è necessario ricorrere a misure indirette.

Negli ultimi trent’anni molti studiosi hanno tentato di sviluppare una singola metrica che offrisse una misura globale della complessità del software.
Fenton paragona questi tentativi alla ricerca del “sacro Graal” …

Misurare il software

La misurazione del software ha lo scopo di assegnare un valore ad un attributo caratterizzante un processo o prodotto software

• consente una comparazione obiettiva tra prodotti/processi;
• rende misurabili processi, risorse, prodotti rilevanti della Ingegneria del Sw.

Sebbene molte aziende produttrici di software utilizzino procedure di misurazione, l’uso sistematico della misurazione del software non è ancora una pratica comune

• Ancora pochi standard in questa area.

Metrica

Metrica: misura quantitativa del grado di possesso di uno specifico attributo da parte di un sistema, un componente, o un processo [IEEE Std 610.12-1990: IEEE Standard Glossary of Software Engineering Terminology]
Es: numero di linee di codice di un modulo, numero di casi d’uso di un’applicazione, …

Molto spesso, metrica è usato come sinonimo di misura o misurazione;
La definizione di metrica include procedure e modalità di misurazione.

Misurazione e Misura

La Misurazione è il processo mediante il quale si assegnano numeri o simboli ad attributi di entità del mondo reale in modo tale da descriverle secondo regole chiaramente definite [Fenton].

• L’entità rappresenta l’oggetto che si vuole sottoporre a misurazione.
• L’attributo dell’entità, invece, è l’aspetto di tale oggetto che interessa descrivere o rappresentare.
• L’insieme dei simboli o valori che si possono assegnare all’attributo costituisce la “forma” di rappresentazione dell’attributo, o “scala dei valori“

Una misura è una funzione che mappa un insieme di oggetti in un altro insieme di oggetti (tipicamente numeri o insiemi di numeri, ma anche simboli).

• La Misurazione è l’attività generale, una Misura è l’effettiva assegnazione di valori.

Un esempio di Misura di attributi

Rappresentazione della Misura come Funzione di mapping fra due insiemi.

Misura e Metrica

Spesso i termini metrica e misura (e anche misurazione) sono usati come sinonimi.

Dai testi classici della misura.
Una misura è una empirica oggettiva assegnazione di un numero (o simbolo) ad una entità al fine di caratterizzarne uno specifico attributo.

Un tentativo di distinzione:
Una metrica caratterizza con valori (numericamente o con simboli) attributi semplici;
Una misura è una funzione di metriche che può essere usata per valutare o predire attributi più complessi.

Attributi

• Attributi esterni:
  • attributi di un’entità che sono visibili e di interesse per l’utente del prodotto software; descrivono l’aspetto esterno di un’entità e il loro rapporto con l’ambiente in cui vengono usate, indipendentemente dalla implementazione;
    • ad esempio: facilità d’uso; portabilità, efficienza, affidabilità.
• Attributi interni:
  • attributi di un’entità che sono visibili e di interesse del produttore, i cui valori dipendono dalla implementazione;
    • ad esempio: modularità, strutturazione, tracciabilità, testabilità, dimensione, complessità.

Misure e metriche

Misura diretta: la misura di un attributo che non dipende da quella di altri attributi.
Misura indiretta: la misura di un attributo che dipende da quella di almeno un altro attributo.

Metriche: tutto ciò per cui possiamo fare misure dirette
Misure dirette • Metriche

Misure: tutto ciò per cui dobbiamo fare misure indirette
Misure indirette • f(metriche)

- ad attributi semplici sono associate le metriche;
- ad attributi complessi sono associate le misure.

Attributi Esterni ed Interni

Un esempio di Relazioni fra Attributi Esterni ed Interni del software.

Entità

Entità di interesse per la misurazione nella IS sono:

• Prodotti:
  • tutto ciò che viene prodotto nel CVS (documentazione, software, test data, …);
• Processi (attività)
  • produzione specifiche, progettazione, codifica, testing, manutenzione, quality assurance, riuso, reengineering, …;
• Risorse:
  • hardware, software, documentazione (della risorsa), risorse umane, banche dati, conoscenza, ….

Esempi di Entità e attributi

Esempi di Entità di interesse per la Misurazione del Software e relativi Attributi.

Scale di valori

Una Scala di valori è l’insieme:
• dei numeri / simboli da assegnare ad un attributo di un’entità
• delle relazioni tra tali numeri / simboli

Esistono 5 tipologie di scala:

1. Nominale

La relazione tra i valori consente una semplice classificazione degli oggetti della misurazione, ma non ci indica nulla sulla relazione fra di essi.

Esempio:
la classificazione degli errori di programmazione in lessicali, sintattici e semantici ci consente di suddividerli ma non di sapere se un errore sia più o meno grave di un altro;

In termini più analitici questo tipo di scala coincide con l’introduzione nell’insieme di partenza di classi di equivalenza.

Scale di valori (segue)

2. Ordinale
Si introduce una relazione d’ordine fra gli oggetti, per cui si è in grado di determinare le posizioni relative degli oggetti (cioè dire se uno venga prima di un altro);

Non si è però in grado di quantificare la distanza fra gli oggetti;

Esempio:
in una scala di valutazione (sufficiente, buono, ottimo) possiamo dire che buono è peggiore di ottimo ma non di sufficiente.

Scale di valori (segue)

3. Intervalli:
Si è in grado di misurare la distanza fra gli oggetti del dominio, e non solo posizionarli tra di loro come con le scale ordinali

Esempio:
la classificazione del rendimento scolastico con “6″, “8″ e “10″ in sostituzione di “sufficiente”, “buono” e “ottimo”, rispettivamente, consente non solo di dire che “6″ precede “8″, ma anche di quanto.

4. Ratio
Introduce l’elemento zero che rappresenta l’assenza totale dell’attributo che si sta misurando nell’entità sottoposta a misurazione. L’introduzione dello zero, inoltre, conferisce al valore di un attributo il senso di positività, negatività o nullità.
Esempio:
la misura di una temperatura, quantificata con un numero maggiore, minore, o uguale a zero.

Scale di valori (segue)

5. Assoluta
Esiste una strategia di conteggio per la quale possiamo assegnare ad ogni oggetto un numero univocamente determinato.
La scala assoluta è usata per quegli attributi di un oggetto che richiedono un semplice conteggio di elementi.

Esempio:
si consideri l’entità “studente” e si voglia quantificare il suo attributo “numero di esami superati”. La misura in questo caso consiste nel semplice conteggio degli esami superati da uno studente; il totale conteggiato rappresenta lo studente in esame, visto attraverso l’attributo “numero di esami superati”.

Caratteristiche di metriche software efficaci

• Semplici e Calcolabili;
• Convincenti a livello empirico ed intuitivo;
• Coerenti e obiettive;
• Coerenti nell’uso di unità e dimensioni;
• Indipendenti dal linguaggio di programmazione;
• Devono essere un meccanismo efficace per un feedback sulla qualità
  • “L’esperienza insegna che la metrica di un prodotto viene utilizzata solo se è intuitiva e facile da calcolare. Se occorre svolgere decine di calcoli complessi, è improbabile che tale metrica venga largamente adottata” [Pressman];
  • Non tutte le metriche soddisfano tutte le caratteristiche di qualità indicate.

Una Classificazione di Metriche software relative al prodotto

• Metriche per il Modello di Analisi:
  • Funzionalità fornita
  • Dimensioni del sistema (in termini di informazioni presenti sul modello di analisi)
  • Qualità delle specifiche
• Metriche per il Modello di Design:
  • Metriche dell’architettura
  • Metriche a livello dei componenti
  • Metriche della progettazione dell’interfaccia
  • Metriche specializzate relative al design object-oriented
• Metriche relative al codice sorgente:
  • Metriche di Halstead
  • Metriche di complessità
  • Metriche di lunghezza
• Metriche di testing:
  • Metriche sulle istruzioni e ramificazioni
  • Metriche relative ai difetti
  • Test dell’efficacia
  • Metriche sul processo

Metriche per il Modello di Analisi

Che tipo di metriche si possono usare in fase di analisi?

• Metriche che consentono al management di monitorare e controllare Costi, Scheduling, Qualità;
• Ad esempio: Metriche aventi lo scopo di “prevedere” quale sarà la “taglia” del processo software all’inizio del suo ciclo di vita, in modo da poter dimensionare le risorse umane e temporali da dedicare ad esso.

Metriche basate sulle funzionalità

• Function Points (FP)

Metriche per la qualità delle specifiche.

Utilizzi dei FP

Per stimare la dimensione finale del codice:
Studi hanno rilevato una correlazione tra FP e numero di LOC, variabile a seconda del linguaggio di programmazione.
Es.
COBOL: 1 FP -> 100 LOC
PL1: 1FP -> 80 LOC
OO lang: 1 FP ->60 LOC

Per stimare lo sforzo (in ore/uomo) di sviluppo:
Es. se 1 mese/uomo ->12 FP, allora …

Per valutare la completezza del testing
studi hanno misurato la correlazione fra FP e numero di difetti scoperti durante il testing.

Metriche per la qualità delle specifiche

Sono stati proposti alcuni attributi di qualità dello SRS (non ambiguità, completezza, correttezza, comprensibilità, verificabilità, coerenza interna ed esterna, realizzabilità, concisione, tracciabilità, modificabilità, precisione e riusabilità).

Un metodo per valutare tali attributi:

• n_R requisiti, di cui n_f funzionali e n_nf non funzionali: n_R=n_f+n_nf
• Una metrica proposta per ognuno degli attributi di qualità
  • Ad esempio, per l’assenza di ambiguità:
    • Q₁ = n_ui/n_R
    • Rapporto tra il numero di requisiti che non risultano ambigui (secondo i revisori dell’SRS) e il numero di requisiti funzionali.

Metriche analoghe sono proposte per tutti gli altri attributi di qualità dell’SRS.

Metriche di progetto architetturale

Si concentrano sulle caratteristiche dell’architettura del software, non tenendo conto della struttura interna dei singoli moduli.

Si basano sull’analisi di modelli di progetto nei quali si evidenziano i moduli del sistema (qualora esso sia scomponibile) e i dati che vengono scambiati tra essi.

Molto semplici da misurare, ma poco affidabili in quanto a legame con lo sforzo effettivo legato allo sviluppo del sistema.

Esempi di Metriche di Progetto Architetturale

Architectural design metrics (applicabili a moduli di architetture gerarchiche)

• Structural complexity = f (fan-out)
• Data complexity(mi) = f(input & output variables, fan-out)
• System complexity = f (structural & data complexity)

Henry e Kafura (HK) metric: complessità architetturale vista come funzione del fan-in e fan-out dei moduli.

Morphology metrics (Fenton): una funzione del numero dei moduli e del numero delle interfacce tra i moduli.

Metriche per il Design Object Oriented

Peculiarità Sistemi O-O

• Localizzazione: il modo con cui le informazioni e loro elaborazioni sono ‘confinate’ in un sistema
  • Nei sistemi Function oriented le informazioni sono localizzate intorno alle funzioni (moduli procedurali);
  • Nei sistemi Object Oriented sono concentrate incapsulando dati e procedure che li elaborano.
• Incapsulamento:
  • una delle conseguenze sulle metriche è che l’unità da considerare è l’oggetto piuttosto che il sotto-programma.
• Information hiding:
  • influisce sull’accoppiamento fra oggetti.
• Inheritance: varie forme di influenza sul progetto.
• Abstraction:
  • possibilità di considerare gli oggetti da vari livelli di astrazione.

Metriche orientate alle classi

Metriche di Chidamber and Kemerer [A Metrics Suite for Object-Oriented Design, 1994]:

• weighted methods per class (WMC)
• depth of the inheritance tree (DIT)
• number of children (NOC)
• coupling between object classes (CBO)
• response for a class (RFC)
• lack of cohesion in methods (LCOM)

Weighted Method per Class (WMC)

WMC è la somma pesata dei metodi di una classe

Il peso di un metodo è dato da un fattore di complessità a scelta.

• Il fattore di complessità dei metodi può essere una metrica di complessità proposta per le funzioni (ad esempio la complessità di Mc Cabe).
• Al crescere di WMC aumenta la complessità della classe e diminuisce la speranza di poterla riusare.
• Problema: come tener conto della complessità dei metodi ereditati?

Profondità dell’albero di ereditarietà di una classe – DIT

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.

Alberi di ereditarietà con elevata profondità possono aumentare la complessità del progetto (più classi e metodi sono coinvolti).

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

Ma i metodi della superclasse devono essere nuovamente testati per ciascuna sottoclasse.

Numero di figli – NOC

Numero di sottoclassi, figlie di una super-classe.

Al crescere del NOC, cresce il livello di riuso (NOC è dunque un indicatore di Riuso) …

• ma tende ad ‘evaporare’ l’astrazione della Classe madre.
• aumenta la possibilità che una Classe figlia non sia membro appropriato della madre.

Al crescere del NOC, cresce la quantità di test case necessari a testare ogni figlia.

Risposte per classe RFC

Insieme dei metodi che possono essere potenzialmente eseguiti in risposta ad un messaggio ricevuto da un oggetto della Classe.

Include l’insieme dei metodi della classe e di tutte le classi a cui essa invia messaggi.

RFC è un indicatore del ‘volume’ di interazione fra classi.

A valori elevati di RFC:
aumenta la complessità progettuale della classe;
cresce lo sforzo per il testing.

Accoppiamento tra le classi – CBO

Numero di collaborazioni di una classe, ovvero numero di altre classi cui essa è accoppiata.

L’accoppiamento può avvenire a seguito di lettura/modifica attributi, chiamata metodi, instanziazione oggetti;

Eccessivo accoppiamento è negativo per la modularità ed il riuso;

Maggiormente indipendente è una classe più facilmente è riusabile;

Per migliorare la modularità, l’accoppiamento va tenuto al minimo; esso influisce sull’impatto di modifiche in altri moduli;

Valori elevati del CBO complicano testing e modifiche.

Mancanza di coesione nei metodi – LCOM

La coesione di un metodo esprime la proprietà di un metodo di accedere in maniera esclusiva ad attributi della classe.
La Mancanza di Coesione deriva dalla presenza di più metodi che accedono ad attributi comuni.

Se ogni attributo è acceduto da un solo metodo, allora LCOM=0 (massima coesione dei metodi).
Altrimenti, LCOM >0 ed aumenta quanto più i metodi vanno ad operare sugli stessi attributi, rendendo quindi difficile il controllo di tutte le interazioni tra i metodi dovuti all’uso degli attributi comuni.

Quindi se LCOM è elevato, i metodi potrebbero essere molto accoppiati tra loro attraverso gli attributi, ed aumenta la complessità del design della classe.