Metriche del codice - Accoppiamento di classi

L'accoppiamento di classi passa anche dal nome Accoppiamento tra oggetti (CBO) come originariamente definito da CK94. Fondamentalmente, l'accoppiamento di classi è una misura del numero di classi usate da una singola classe. Un numero elevato è negativo e un numero basso è in genere buono con questa metrica. L'accoppiamento di classi è stato dimostrato come un preditore accurato di errori software e recenti studi hanno dimostrato che un valore limite superiore di 9 è il S2010 più efficiente.

Secondo la documentazione Microsoft, l'accoppiamento di classi "misura l'accoppiamento a classi univoche tramite parametri, variabili locali, tipi restituiti, chiamate di metodo, istanze di generici o template, classi base, implementazioni di interfacce, campi definiti in tipi esterni e decorazione di attributi. Una buona progettazione software determina che i tipi e i metodi devono avere una coesione elevata e un accoppiamento basso. L'accoppiamento elevato indica una progettazione difficile da riutilizzare e gestire a causa delle numerose interdipendenze su altri tipi".

I concetti di accoppiamento e coesione sono chiaramente correlati. Per mantenere la discussione incentrata sull'argomento, non entreremo nei dettagli della coesione, a parte fornire una breve definizione da KKLS2000:

"La coesione del modulo è stata introdotta da Yourdon e Costantino come "quanto strettamente vincolati o correlati gli elementi interni di un modulo sono l'uno all'altro" YC79. Un modulo ha una forte coesione se rappresenta esattamente un'attività [...], e tutti i suoi elementi contribuiscono a questa singola attività. Descrivono la coesione come attributo di progettazione, anziché codice, e un attributo che può essere usato per prevedere la riutilizzabilità, la gestibilità e la modificabilità."

Esempio di accoppiamento di classi

Esaminiamo l'accoppiamento delle classi in azione. Creare prima di tutto una nuova applicazione console e creare una nuova classe denominata Person con alcune proprietà in esso contenute, quindi calcolare immediatamente le metriche del codice:

Si noti che l'accoppiamento della classe è 0 perché questa classe non usa altre classi. Creare ora un'altra classe denominata PersonStuff con un metodo che crea un'istanza di Person e imposta i valori della proprietà. Calcolare di nuovo le metriche del codice:

Guarda come aumenta il valore di accoppiamento della classe? Si noti anche che, indipendentemente dal numero di proprietà impostate, il valore di accoppiamento della classe viene semplicemente alzato di 1 e non da un altro valore. L'accoppiamento di classi misura ogni classe una sola volta per questa metrica indipendentemente dalla quantità usata. Inoltre, è possibile notare che DoSomething() ha un valore 1, ma il costruttore , PersonStuff()ha un valore 0 per il relativo valore? Attualmente non è presente alcun codice nel costruttore che usa un'altra classe.

Cosa accade se si inserisce il codice nel costruttore che ha usato un'altra classe? Ecco cosa si ottiene:

Ora il costruttore ha chiaramente codice che usa un'altra classe e la metrica di accoppiamento della classe mostra questo fatto. Anche in questo caso, è possibile vedere l'accoppiamento complessivo della classe per PersonStuff() è 1 ed DoSomething() è anche 1 per indicare che viene usata una sola classe esterna indipendentemente dalla quantità di codice interno in uso.

Creare quindi un'altra nuova classe. Assegnare a questa classe un nome e creare alcune proprietà al suo interno:

Utilizzare ora la classe nel metodo DoSomething() all'interno della classe PersonStuff e calcolare di nuovo le metriche del codice:

Come si può vedere, l'accoppiamento della classe PersonStuff arriva fino a 2 e, se si esegue il drill-in della classe, si può vedere che il metodo DoSomething() ha il massimo accoppiamento, ma il costruttore utilizza ancora solo 1 classe. Usando queste metriche, è possibile visualizzare il numero massimo complessivo per una determinata classe ed eseguire il drill-down dei dettagli in base ai singoli membri.

Il numero magico

Come per la complessità ciclomatica, non esiste alcun limite che si adatti a tutte le organizzazioni. Tuttavia, S2010 indica che un limite di 9 è ottimale:

"Pertanto, consideriamo i valori soglia [...] come il più efficace. Questi valori di soglia (per un singolo membro) sono CBO = 9[...]". (enfasi aggiunta)

Analisi del codice

L'analisi del codice include una categoria di regole di gestibilità. Per altre informazioni, vedere Regole di manutenibilità. Quando si usa l'analisi del codice legacy, il set di regole delle linee guida per la progettazione estesa contiene un'area di gestibilità:

All'interno dell'area di manutenibilità c'è una regola relativa all'accoppiamento delle classi:

Questa regola genera un avviso quando l'accoppiamento della classe è eccessivo. Per altre informazioni, vedere CA1506: Evitare un eccessivo accoppiamento tra classi.

Citazioni

CK94

Chidamber, S. R. & Kemerer, C. F. (1994). Una suite di metriche per la progettazione orientata agli oggetti (transazioni IEEE in Ingegneria software, vol. 20, n. 6). Recuperato il 14 maggio 2011 dal sito Web dell'Università di Pittsburgh: http://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf

KKLS2000

Kabaili, H., Keller, R., Lustman, F., e Saint-Denis, G. (2000). Coesione di classe rivisitata: uno studio empirico sui sistemi industriali (atti del workshop sugli approcci quantitativi nell'Ingegneria del Software Object-Oriented). Recuperato il 20 maggio 2011 dal sito Web Université de Montreal http://www.iro.umontreal.ca/~sahraouh/qaoose/papers/Kabaili.pdf

SK2003

Subramanyam, R. & Krishnan, M. S. (2003). Analisi empirica delle metriche CK per la complessità della progettazione orientata agli oggetti: implicazioni per i difetti software (IEEE Transactions on Software Engineering, Vol. 29, No. 4).

S2010

Shatnawi, R. (2010). Analisi quantitativa dei livelli di rischio accettabili delle metriche di Object-Oriented nei sistemi Open-Source (transazioni IEEE su software engineering, vol. 36, n. 2).

YC79

Edward Yourdon e Larry L. Costantino. Progettazione strutturata. Prentice Hall, Englewood Cliff, N.J., 1979.