Codemetriken – Klassenkopplung

Klassenkopplung ist auch als Kopplung zwischen Objekten (KBO) bekannt, wie ursprünglich von CK94 definiert. Im Grunde ist die Klassenkopplung ein Maß dafür, wie viele Klassen eine einzelne Klasse verwendet. Eine hohe Zahl ist schlecht und eine niedrige Zahl ist in der Regel gut mit dieser Metrik. Die Klassenkopplung wurde als präziser Prädiktor für Softwarefehler erwiesen, und aktuelle Studien haben gezeigt, dass ein Obergrenzwert von 9 der effizienteste S2010 ist.

Gemäß der Microsoft-Dokumentation misst die Klassenkopplung die Kopplung an eindeutige Klassen durch Parameter, lokale Variablen, Rückgabetypen, Methodenaufrufe, generische oder Template-Instanziationen, Basisklassen, Schnittstellenimplementierungen, Felder, die für externe Typen definiert sind, und Attribut-Dekoration. Ein guter Softwareentwurf bestimmt, dass Typen und Methoden einen hohen Zusammenhalt und eine niedrige Kopplung aufweisen sollten. Hohe Kopplung weist auf ein Design hin, das aufgrund seiner vielen Abhängigkeiten von anderen Typen schwer wiederverwendet und beibehalten werden kann."

Die Konzepte der Kopplung und des Zusammenhalts sind eindeutig miteinander verbunden. Um beim Thema zu bleiben, werden wir uns nicht mit dem Zusammenhalt befassen, außer dass wir eine kurze Definition aus KKLS2000 geben.

Der Modulzusammenhalt wurde von Yourdon und Constantine als "das Ausmaß, in dem die internen Elemente eines Moduls miteinander verbunden oder verwandt sind" YC79 eingeführt. Ein Modul hat einen starken Zusammenhalt, wenn es genau eine Aufgabe [...] darstellt, und alle seine Elemente tragen zu dieser einzelnen Aufgabe bei. Sie beschreiben den Zusammenhalt als Attribut des Designs und nicht als Code und ein Attribut, das verwendet werden kann, um Wiederverwertbarkeit, Verhaltbarkeit und Änderungsfähigkeit vorherzusagen."

Beispiel für Klassenkopplung

Sehen wir uns die Klassenkopplung in Aktion an. Erstellen Sie zuerst eine neue Konsolenanwendung, und erstellen Sie eine neue Klasse namens "Person" mit einigen Eigenschaften darin, und berechnen Sie dann sofort die Codemetriken:

Beachten Sie, dass die Klassenkopplung 0 ist, da diese Klasse keine anderen Klassen verwendet. Erstellen Sie nun eine weitere Klasse namens "PersonStuff" mit einer Methode, die eine Instanz von Person erstellt und die Eigenschaftswerte festlegt. Berechnen Sie die Codemetriken erneut:

Sehen Sie, wie der Klassenkopplungswert steigt? Beachten Sie außerdem, dass der Klassenkopplungswert unabhängig davon, wie viele Eigenschaften Sie festlegen, nur um 1 und nicht um einen anderen Wert nach oben geht. Klassenkopplung misst jede Klasse nur einmal für diese Metrik, unabhängig davon, wie viel sie verwendet wird. Darüber hinaus können Sie sehen, dass DoSomething() eine 1 hat, aber der Konstruktor, PersonStuff(), eine 0 für seinen Wert hat. Derzeit gibt es keinen Code im Konstruktor, der eine andere Klasse verwendet.

Was geschieht, wenn Sie Code in den Konstruktor einfügen, der eine andere Klasse verwendet hat? Hier erhalten Sie Folgendes:

Der Konstruktor verfügt nun eindeutig über Code, der eine andere Klasse verwendet, und die Klassenkopplungsmetrik zeigt diese Tatsache. Auch hier können Sie sehen, dass die gesamte Klassenkopplung von PersonStuff() 1 ist und von DoSomething() ebenfalls 1 ist, um zu zeigen, dass nur eine externe Klasse verwendet wird, unabhängig davon, wie viel interner Code Sie verwenden.

Erstellen Sie als Nächstes eine weitere neue Klasse. Geben Sie dieser Klasse einen Namen, und erstellen Sie einige Eigenschaften darin:

Verwenden Sie nun die Klasse in unserer DoSomething() Methode innerhalb der PersonStuff Klasse, und berechnen Sie Codemetriken erneut:

Wie Sie sehen können, steigt der Kopplungsgrad für die PersonStuff-Klasse auf 2. Bei genauerer Betrachtung der Klasse können Sie feststellen, dass die DoSomething() Methode am stärksten gekoppelt ist, aber der Konstruktor nutzt immer noch nur eine Klasse. Mithilfe dieser Metriken können Sie die maximale Gesamtanzahl für eine bestimmte Klasse anzeigen und einen Drilldown zu den Details pro Mitglied ausführen.

Die Magische Zahl

Wie bei der zyklomatischen Komplexität gibt es keine Beschränkung, die allen Organisationen entspricht. S2010 weist jedoch darauf hin, dass ein Grenzwert von 9 optimal ist:

"Daher betrachten wir die Schwellenwerte [...] als effektivste. Diese Schwellenwerte (für ein einzelnes Element) sind CBO = 9[...]." (Hervorhebung hinzugefügt)

Codeanalyse

Die Codeanalyse enthält eine Kategorie von Maintainability-Regeln. Weitere Informationen finden Sie unter Wartbarkeitsregeln. Bei der Verwendung der Legacy-Code-Analyse enthält der Regelsatz "Erweiterte Entwurfsrichtlinie" einen Bereich für die Wartbarkeit.

Innerhalb des Wartungsbereichs ist eine Regel für die Klassenkopplung:

Diese Regel gibt eine Warnung aus, wenn die Klassenkopplung übermäßig ist. Weitere Informationen finden Sie unter CA1506: Vermeiden einer übermäßigen Klassenkopplung.

Zitate

CK94

Chidamber, S. R. & Kemerer, C. F. (1994). A Metrics Suite for Object Oriented Design (IEEE Transactions on Software Engineering, Vol. 20, Nr. 6). Abgerufen am 14. Mai 2011 von der Website der University of Pennsylvania: http://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf

KKLS2000

Kabaili, H., Keller, R., Lustman, F., und Saint-Denis, G. (2000). Class Cohesion Revisited: Eine empirische Studie über industrielle Systeme (Tagungsband des Workshops zu quantitativen Ansätzen im objektorientierten Software Engineering). Abgerufen am 20. Mai 2011 von der Université de Montréal-Website http://www.iro.umontreal.ca/~sahraouh/qaoose/papers/Kabaili.pdf

SK2003

Subramanyam, R. & Krishnan, M. S. (2003). Empirische Analyse von CK-Metriken für objektorientierte Designkomplexität: Auswirkungen auf Softwarefehler (IEEE Transactions on Software Engineering, Vol. 29, Nr. 4).

S2010

Shatnawi, R. (2010). Eine quantitative Untersuchung der zulässigen Risikostufen von objektorientierten Metriken in Open-Source-Systemen (IEEE Transactions on Software Engineering, Vol. 36, Nr. 2).

YC79

Edward Yourdon und Larry L. Constantine. Strukturiertes Design. Prentice Hall, Englewood Cliffs, N.J., 1979.