Metriche per il collaudo del software orientato agli oggetti

Metriche per il collaudo del software orientato agli oggetti

Nell’ambito dell’ingegneria del software, Binder nel 1994 suggerisce una vasta gamma di metriche di progettazione direttamente legate alla “collaudabilità” di un sistema o software orientato agli oggetti (OO). Tali metriche sono suddivise in categorie, che riflettono importanti caratteristiche progettuali.

Metriche per il collaudo del software orientato agli oggetti

Incapsulamento

  • LCOM (Mancanza di coesione nei metodi). Una valore elevato di LCOM significa un numero elevato di stati da provare per accettare che i metodi non producano effetti collaterali.
  • PAP (Percentuale attributi pubblici e protetti). Gli attributi pubblici sono ereditati da altre classi e sono quindi visibili a queste ultime. Gli attributi protetti sono specializzazioni e appartengono alla sottoclasse (sono “privati”). Questa metrica indica quale percentuale di attributi è pubblica. Un valore elevato indica rischi più elevati di effetti collaterali interclasse; si devono compiere le prove opportune per scoprirli.
  • PAD (Accesso pubblico a membri-dato). È il numero di classi (o di metodi) che possono accedere agli attributi di una classe, violando il principio di incapsulamento. Un valore elevato indica un rischio maggiore di effetti collaterali interclasse; si devono compiere le prove opportune per scoprirli.

Ereditarietà

  • NOR (Numero di classi radice). Questa metrica consiste nel numero di gerarchie distinte di classi descritte nel modello progettuale. Per ogni classe radice e corrispondente gerarchia si devono sviluppare serie di prove. Di conseguenza, al crescere di NOR, cresce l’impegno di collaudo.
  • FIN (Fan-in). In un contesto orientato agli oggetti, il Fan-in è un indice di ereditarietà multipla. Un valore superiore a 1 significa che una classe eredità attributi e operazioni da più di una classe radice. Questa situazione va evitata quando è possibile.
  • NOC e DIT (Numero di figli e profondità dell’albero di ereditarietà). I metodi di una classe devono essere collaudati nuovamente per ognuna delle sue sottoclassi.

 

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *