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 modelli generici o modello, classi base, implementazioni dell'interfaccia, campi definiti su 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 questa discussione sull'argomento, non si entrerà in profondità con la coesione diversa da dare 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 della classe 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:

Vedere come si alza 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:

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

Come si può notare, l'accoppiamento di classe per la classe PersonStuff va fino a 2 e, se si esegue il drill-in della classe, si può notare che il DoSomething() metodo 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 codice

L'analisi del codice include una categoria di regole di gestibilità. Per altre informazioni, vedere Regole di gestibilità. 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à è una regola per l'accoppiamento di classi:

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

Citazioni

CK94

Chidamber, S. R. & Kemerer, C. F. (1994). Suite di metriche per la progettazione orientata agli oggetti (I edizione Enterprise E Transactions on Software Engineering, Vol. 20, No. 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: studio empirico sui sistemi industriali (documentazione del workshop sugli approcci quantitativi nell'ingegneria software orientata agli oggetti). 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 (I edizione Enterprise E transazioni in ingegneria software, vol. 29, n. 4).

S2010

Shatnawi, R. (2010). Analisi quantitativa dei livelli di rischio accettabili delle metriche orientate agli oggetti nei sistemi open source (I edizione Enterprise E Transactions on Software Engineering, Vol. 36, N. 2).

YC79

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