Kopplung und Kohäsion - LCOM-Metriken

Unter der Bezeichnung "Lack of Cohesion in Methods" wurde erstmals in [Chidamber 1991] eine Metrik vorgeschlagen, welche das Konzept der Kohäsion auf Implementierungen von Klassen anwandte. Die Metrik durchlebte zahlreiche abweichende Definitionsversuche und ist bis heute umstritten. Die Geschichte dieser Metrik soll an dieser Stelle einen Einblick gewähren, welchen Problemen man begegnet, wenn man versucht, Kohäsion konkret fassbar zu machen.

Das Original

In [Chidamber 1991] wird LCOM wie folgt definiert:

• Gegeben eine Klasse C mit Methoden M₁, M₂, ..., M_n. 
• Dann lassen sich n Teilmengen von Instanzvariablen bilden, wobei jede Teilmenge I_i genau diejenigen Instanzvariablen enthält, welche von Methode M_i verwendet werden.
• LCOM = Anzahl der disjunkten Teilmengen I_i.

Redefinition durch Li und Henry

Während die originale Definition auf disjunkten Teilmengen von Instanzvariablen aufbaut, wird in [Li 1993] und [Li 1995] eine Definition vorgeschlagen, die auf disjunkten Teilmengen von Methoden beruht:

• Bilde für eine Klasse die Menge aller Methoden-Teilmengen die folgende Bedingung erfüllt:
• Jede Teilmenge enthält mindestens eine Methode.
• Jedes Methoden-Paar einer Teilmenge greift auf mindestens eine gemeinsame Instanzvariable zu.
• LCOM = Anzahl der disjunkten Methoden-Teilmengen.

Von dieser Definition wurde eine graphenbasierte Variante in [Hitz 1996] erstellt, der das folgende anschauliche Bild unterliegt: Die Methoden einer Klasse lassen sich als Knoten eines ungerichteten Graphen repräsentieren. Zwischen den Knoten aller Methoden, die auf eine gemeinsame Instanzvariable zugreifen, bestehe eine Kante. Auf diese Weise ergeben sich n disjunkte Teilgraphen ("Cluster"). LCOM ist genau die Anzahl dieser Cluster.

Redefinition durch Chidamber und Kemerer

In [Chidamber 1994] entwickelten Chidamber und Kemerer selbst eine neue LCOM-Definition. Diese Definition beruht nicht mehr auf der Größe disjunkter Teilmengen, sondern bildet eine Differenz von paarweise nicht-kohäsiven und paarweise kohäsiven Methoden.

• Es werden die Paare aller Methoden der Klasse gebildet.
• Für jedes Paar wird geprüft, ob es mindestens ein gemeinsames Attribut verwendet.
• Es ergeben sich zwei Mengen P und Q:
• P: die Paare, die kein gemeinsames Attribut verwenden
• Q: die Paare, die mindestens ein gemeinsames Attribut verwenden
• LCOM = |P| - |Q| oder mindestens 0.

Prozentsatzmethode

• Ermittle für jede Instanzvariable den Anteil der Methoden, welche diese Variable nutzen.
• Bilde den Mittelwert dieser Prozentwerte und subtrahiere ihn von 100%.
• Ein hoher Wert weist auf schlechte Kohäsion hin.

Weitere Variationen und Implementierungsunterschiede

Auch die einzelnen LCOM-Definitionen erlauben noch Freiheitsgrade. Sollen Konstruktoren zu den Methoden zählen oder nicht? Sollen geerbte Instanzvariablen berücksichtigt werden oder nicht? Soll der gegenseitige Aufruf von Methoden berücksichtigt werden oder nicht? Sollen die gefundenen Kohäsionswerte durch Betrachtung externer Kopplungen "normalisiert" werden? Usw.

Schlussbetrachtung und Bewertung

In einer Reihe empirischer Untersuchungen, darunter [Etzkorn 1998] und [Mäkelä 2006],  werden verschiedene LCOM-Definitionen mittels Anwendung auf konkrete Klassen empirisch untersucht. Dabei ergeben sich teils deutliche Abweichungen zwischen den unterschiedlichen Ansätzen. Etzkorn und Kollegen betrachten die Definition aus [Chidamber 1994] als problematisch, konstatieren aber der Redefinition von Li und Henry (ohne Betrachtung geerbter Instanzvariablen, aber mit Betrachtung von Konstruktoren), insgesamt eine gute Annäherung der von Experten beurteilten Kohäsion. Mäkelä und Kollege fassen zusammen:

"Ein guter LCOM-Wert deutet auf ein gutes Klassendesign hin, während schlechte LCOM-Werte nicht notwendigerweise ein schlechtes Klassendesign bedeuten müssen."

In Anbetracht der Intensität der Forschung in diesem Bereich erscheint sowohl die Vielfalt der Definitionen als auch die empirisch festgestellte Aussagekraft ernüchternd. Es kann zumindest festgehalten werden, dass eine zweifelsfreie und aussagekräftige Formalisierung der Kohäsion von Methoden auf Grund rein syntaktischer Eigenschaften von Klassen bis heute nicht gelungen ist. Die verfügbaren Metriken liefern allenfalls Hinweise, die im Einzelfall vom Entwickler zu überprüfen sind.

Quellen

[Chidamber 1991] - Towards a metrics suite for object-oriented design, PROCEEDINGS: OOPSLA ’91, pp. 197-211, Chidamber, S.R., and C.F. Kemerer (1991)
[Chidamber 1994] - A metrics suite for object-oriented design,  Chidamber, S.R., and C.F. Kemerer (1994)
[Etzkorn 1998] - A Practical Look at the Lack of Cohesion in Methods Metric, Letha H. Etzkorn, Carl G. Davis, Wei Li (1998)
[Li 1993] -  Maintenance metrics for the object-oriented paradigm, Li, W. and S. Henry (1993)
[Li 1995] - Measuring object-oriented design, Li, W., S. Henry, D. Kafury, and R. Schulman (1995)
[Mäkelä2006] - Observations on Lack of Cohesion Metrics, Sami Mäkelä, Ville Leppänen (2006)