Le metriche Laurence e Kidd di un progetto software

Le metriche Laurence e Kidd di un progetto software

Oltre le metriche CK e MOOD viste in un altro articolo, esistono anche le metriche di Laurence e Kidd (1994), basate su quattro grandi categorie: dimensione della classe (CS) in termini di numero di metodi e/o attributi, e il suo valore non deve essere né troppo alto né troppo basso. Inoltre sempre secondo Laurence e Kidd affermarono che il NOA, ossia il numero di operazioni aggiunte da una sottoclasse, deve avere comunque un valore contenuto affinchè si abbia qualità software.

Metriche Laurence e Kidd

Nel dettaglio, Laurence e Kidd proposero dunque le seguenti metriche:

  • CS (Class Size) misura la dimensione complessiva di una classe. Si calcola a partire dalle seguenti misure:
    • PIM (Public Instance Methods) conta il numero di metodi d’istanza pubblici di una classe.
    • NIM (Number of Instance Methods) conta il numero totale di metodi d’istanza della classe, pubblici, protetti (con il termine “protetti” si fa riferimento al grado di visibilità protected  (di un metodo/attributo) in C++/Java) e privati che siano. Pochi o troppi metodi possono indicare una non ottimale allocazione delle responsabilità.
    • NIV (Number of Instance Variables) conta il numero di attributi (protetti e privati) incapsulati nella classe.
    • NCM (Number of Class Methods) conta il numero di metodi di classe. Un metodo di classe (identificato tipicamente dalla dicitura static) è un metodo che appartiene alla classe e con essa viene installato, non necessita quindi di alcuna istanza della classe per essere utilizzato, tuttavia può essere utilizzato da qualsiasi istanza qualora sia ad essa visibile. Troppi metodi di classe indicano un uso inappropriato delle classi che sono usate invece degli oggetti.
    • NCV (Number of Class Variables) conta il numero di attributi di classe (static) di una classe

Secondo gli autori della metrica un valore elevato di CS è indizio che la classe ha troppe responsabilità, il che riduce le possibilità di riuso e ne complica le fasi di implementazione e collaudo. In generale, nel calcolare le dimensioni di una classe, a operazioni e attributi protetti o pubblici bisognerebbe dare un peso maggiore.

Secondo Pressman le operazioni e gli attributi privati sono segno di specializzazione e sono più localizzati. Si può calcolare il numero il numero medio di operazioni e di attributi per classe. Un valore basso di tali medie è segno di un maggiore potenziale riutilizzo.

  • NMO (Number of Methods Overridden) misura il numero di metodi ridefiniti da una sottoclasse. Un valore elevato di NMO è in genere segno di una progettazione imperfetta, infatti, una sottoclasse, essendo una specializzazione delle sue superclassi, dovrebbe principalmente estendere le loro operazioni, creando, quindi, nuovi metodi. In [Pressman] si afferma che se NMO è elevato, è probabile che il progettista non abbia rispettato l’astrazione implicita nella superclasse. La conseguenza è una gerarchia fragile e un prodotto più difficile da collaudare e da modificare.
  • NMI (Number of Methods Inherited) conta il numero di metodi ereditati da una sottoclasse.
  • NMA (Number of Methods Added) è il numero di metodi aggiunti da una sottoclasse. La specializzazione di una sottoclasse si traduce in nuove operazioni e nuovi attributi. Al crescere di NOA, la classe si allontana dall’astrazione rappresentata dalla sua superclasse. In generale, la crescita di profondità della gerarchia si deve accompagnare a una diminuzione di NOA nei livelli inferiori [Pressman].
  • SI (Specialization Index) indica approssimativamente il grado di specializzazione di una classe. La specializzazione si ottiene aggiungendo operazioni, oppure ridefinendo le operazioni della superclasse.
  • NSS (Number of Scenario Scripts) è il numero di scenari, o casi d’uso, ed è proporzionale al numero di classi necessarie per soddisfare i requisiti, al numero di stati per classe e al numero di metodi e attributi. NSS è un indice relativamente preciso della dimensione del programma.
  • NKC (Number of Key Classes) misura il numero di classi che sono legate direttamente al problema e che hanno bassa probabilità di essere implementare tramite riutilizzo. Di conseguenza, un valore elevato di NKC indica la necessità di un pesante lavoro di sviluppo. Secondo Laurence e Kidd le classi chiave coprono tra il 20 e il 40 delle classi totali in un sistema orientato agli oggetti tipico. Il resto è formato da classi di supporto (GUI, database, comunicazione e così via).
  • NSUB (Number of Subsystem) misura il numero di sottosistemi ed offre informazioni sull’allocazione delle risorse, sulla pianificazione temporale (con particolare rilievo sullo sviluppo parallelo) e sull’impegno di integrazione.
  • OS_avg (Operation Size) indica il numero medio di righe di codice per metodo; è, dunque, indicativo delle dimensioni di un metodo “medio”. Un’alternativa è data dal numero di messaggi inviati dal metodo. Un valore elevato di questo parametro è indizio di una distribuzione inadeguata delle responsabilità dell’interno della classe.
  • OC (Operation Complesity) è la complessità di un metodo; si può ricorrere alle metriche proposte per il software tradizionale. Poiché le operazioni devono avere in genere una responsabilità circoscritta, il progettista deve mantenere OC su livelli bassi.
  • NP_avg (Numero medio di parametri per metodo) misura il numero medio di parametri per metodo. Quanto maggiore è il numero di parametri dei metodi, tanto è più complessa la collaborazione fra oggetti. In generale, si deve tendere a valori bassi di questo parametro; gli autori suggeriscono una soglia massima di 0.7.

 

Precedente Le metriche CK e MOOD di un progetto software Successivo Linguaggio UML e diagramma di deployment

Lascia un commento

*