-
Die
Erfindung betrifft ein Verfahren einer mittels eines elektronischen
Rechners automatisch durchgeführten Bestimmung eines Gütefaktors
einer Computersteuerung, die als Programmcode vorliegt, wobei im
Rechner Filtermodule realisiert sind, die jeweils eine Analyse der
Computersteuerung oder eines Teiles der Computersteuerung bezüglich
eines definierten Parameters ermöglichen, wobei ein auf die
Computersteuerung angewandtes Filtermodul eine Repräsentation,
insbesondere die Größe, des untersuchten Parameters
als Kennzahl ausgibt. Die Erfindung betrifft zudem eine Vorrichtung
zur automatischen Bestimmung eines Gütefaktors.
-
Die
Erfindung liegt somit im technischen Umfeld der Entwicklung von
Computersteuerungen. Dabei handelt es sich bei der Erfindung um
ein Verfahren, mit dem eine Computersteuerung, die als Datenpaket
mit mehreren Modulen in Programmcode vorliegt, auf vorbestimmte
Qualitätskriterien untersucht wird. Dabei geschieht die
automatische Untersuchung mittels eines Computers. Die Qualitätskriterien spiegeln
sich in einem Gütefaktor wieder, der für die Computersteuerung,
insbesondere aber für einzelne Module der Computersteuerung
ausgegeben wird.
-
Dieser
Gütefaktor hat unmittelbaren Einfluss auf die Funktion
des mit der Computersteuerung zu betreibenden Computers, da eine
Computersteuerung verhältnismäßig geringer
Güte die Funktion des Computers stark beeinträchtigen
kann. Es liegt somit im Bestreben eines jeden Fachmannes, die Gütefaktoren
von Programmen oder Programmteilen zu bestimmen und diese als Grundlage
für Verbesserungen an der Computersteuerung, beispielsweise
im Sinne einer grundlegenden Überarbeitung („Refactoring”)
laufender Computersteuerungen im Hinblick auf eine größere
Zuverlässigkeit zu nutzen. Aus den Gütefaktoren
lassen sich auch Rückschlüsse auf die „Wartbarkeit” der
jeweiligen Computersteuerung ziehen, die im Zusammenhang mit der „Änderbarkeit” von
Software nach der ISO/IEC 9126 steht.
-
Dabei
ist festzustellen, dass Wartungskosten, über den gesamten
Lebenszyklus eines Computerprogramms betrachtet, mitunter mehr als
60% der Gesamtkosten ausmachen. Mit bekannten Methoden können
die zu erwartenden Wartungskosten – wenn überhaupt – nur
unter großem Aufwand bestimmt werden. Herkömmliche
Methoden der Bewertung von Computersteuerungen konzentrieren sich
zunächst auf die Analyse der vorhandenen Dokumentation,
Erstellungsprozesse und Entwicklungsmethoden. Anhand dieser Artefakte
kann jedoch nicht beurteilt werden, inwieweit der Code leicht verständlich ist,
ob der Aufbau modular erfolgte, ob die Architektur wie entworfen
implementiert wurde, ob Technologiestandards eingehalten wurden,
ob sich neue Mitarbeiter mit akzeptablem Aufwand einarbeiten können oder
ob einzelne Komponenten wiederverwertbar sind. Es kann nicht einmal
beurteilt werden, ob die implementierte Software mit der Dokumentation übereinstimmt.
Um belastbare Aussagen zu bekommen, bedarf es nach wie vor umfassender
manueller Analysen des Quellcodes. Mit den bekannten Methoden benötigt
eine Untersuchung eines komplexen Systems mit einer Millionen Programmzeilen
(„lines of code”, LOC) und einer angenommenen
Untersuchungsgeschwindigkeit von 360 LOC/h mit fünf Entwicklern
knapp acht Mannjahre zuzüglich der Vorbereitung und Umsetzung.
-
Es
gibt auch heute schon Verfahren, die Programmcode mit einer Vielzahl
metrischen Verfahren („Metriken”) vermessen. Dies
geschieht beispielsweise durch Visualisierung, durch metrische Analyse, durch
Clone-Erkennung, durch „Antipattern”-Erkennung
oder ähnlichem. Für diese Arten der Vermessung
sind eine ausreichende Menge von entsprechenden Werkzeugen und „Open-Source-Tools” bekannt.
Die Ergebnisse sind jedoch nur wenig hilfreich, da sie nur begrenzte
Aussagekraft haben. Mitunter lässt eine an einem speziellen Programm
eingesetzte Metrik keinerlei Rückschlüsse auf
die Qualität zu, da das Programm bezüglich gerade
dieser Metrik nicht „auffällig” ist.
Halbwegs brauchbare Aussagen können heutzutage auch nur
von Fachleuten getätigt werden, die sich anhand einer Vielzahl
von Einzelergebnissen ein Bild von der gesamten Situation verschaffen.
-
Die
Aufgabe der vorliegenden Erfindung liegt nunmehr zunächst
darin, ein Verfahren vorzuschlagen, mit dem überhaupt eine
Automatisierung der Bewertung solcher Computersteuerungen oder Teilen
davon möglich wird. Dieses sollte sich mit einfachen Mitteln
kostengünstig umsetzen lassen und Gütefaktoren
ausgeben, die als Grundlage für eine Änderung
der Untersuchung Computersteuerungen herangezogen werden können.
Zudem ist es Aufgabe der Erfindung, eine zuverlässig arbeitende
Vorrichtung zu schaffen, mit dem sich eine solche Bewertung automatisch
in hoher Geschwindigkeit durchführen lässt.
-
Diese
Aufgaben werden durch das Verfahren mit den Merkmalen des Anspruch
1 und die Vorrichtung nach Anspruch 9 gelöst. Vorteilhafte
Ausführungsformen sind in den jeweiligen Unteransprüchen genannt.
-
Der
wesentliche Grundgedanke der Erfindung basiert darauf, zunächst
eine automatische „Vermessung” der zu untersuchenden
Computersteuerung oder Teilen davon vorzunehmen, wobei für die
Vermessung bekannte metrische Verfahren („Metriken”)
als Filtermodule herangezogen werden. Die Erfindung liegt dann in
einer speziellen Kombinationen der sich als Kennzahlen darstellenden
Ergebnisse der einzelnen Metriken und der Analyse der sich aus der
Kombinationen erwachsenden Resultate. Dies wird umgesetzt durch
eine im Rechner realisierte Verknüpfungsfunktion, welcher
Ergebnisse in Form von Kennzahlen mindestens zweier Filtermodule
zugeführt werden. Die Verknüpfungsfunktion verknüpft
die Kennzahlen entsprechend einer vorgegebenen Regel, wobei das
Ergebnis der Verknüpfung in die Definition des Gütefaktors
einfließt. Der Gütefaktor der Computersteuerung
oder eines als Modul vorliegenden Teiles der Computersteuerung wird
dem Nutzer letztendlich über ein Ausgabemedium ausgegeben.
-
In
dem ersten Schritt der automatischen Vermessung werden beispielsweise
die Länge, die Komplexität, die Kopplung, die
Kommentare, die Duplikate und/oder die Kohäsion berechnet,
wobei eine Liste derjenigen Module, die die vorgegebenen Grenzwerte übersteigen
ausgegeben wird. Die nachfolgende Verknüpfung verursacht
quasi die Aufdeckung von „Antipatterns”, also
ungewöhnlichen Mustern innerhalb der Programmsteuerung.
Solche Antipatterns sind beispielsweise Gott-Klassen, Datenklassen
und unnötige Hierarchien. Wenn ein Modul Antipatterns zeigt,
kann es als problematisch markiert werden. Dabei geschieht die Erkennung
der Antipatterns vollautomatisch.
-
Der
besondere Vorteil der erfindungsgemäßen Verknüpfung
liegt darin, dass die letztendlichen Ergebnisse von wesentlich höherer
Aussagekraft als die Ergebnisse der einzelnen Metriken für
sich sind. Dabei hat sich herausgestellt, dass die Aussagekraft der
Ergebnisse bedeutend verbessert werden können, wenn sich
die Kombination auf bestimmte Metriken beschränkt. So liegt
ein ganz wesentlicher Aspekt der Erfindung auch darin, aus allen
möglichen (insgesamt mehr als 100) bekannten Metriken eine bestimmte
Gruppe von wenigen, insbesondere zwischen fünf und sieben,
Metriken auszuwählen und nur diese zu nutzen. Dabei werden
die Filtermodule ausgewählt, die für die spätere
Kombination besonders geeignet sind. Diese zeichnen sich zunächst
dadurch aus, dass sie „linear unabhängig” sind,
also voneinander unabhängige Ergebnisse liefern. Zudem findet
die Auswahl danach statt, welche Metriken mit großen „Ausschlägen” oder
hoher Auflösung eine gute Differenzierung ermöglichen.
Metriken, die sowohl bei gutem als auch schlechtem Code gleich ausschlagen
sind nicht geeignet.
-
Die
Gruppe der im Hinblick auf eine hohe Aussagekraft ausgewählten
Metriken wird an späterer Stelle genauer vorgestellt. Hier
sei schon erwähnt, dass es besonders vorteilhaft ist, der
bestimmten Gruppe Filterfunktionen zur Ermittlung der Komplexität,
zur Ermittlung der Anzahl der Duplikate, zur Ermittlung des Vererbungsbaumes,
zur Ermittlung der Kommentarrate und zur Ermittlung der Anzahl der
Methoden zuzuordnen. Die genannten Filterfunktionen haben sich im Rahmen
von Untersuchungen mit einer Vielzahl von Metriken und anschließender
obiger Analyse als die geeignetsten herausgestellt, so dass auf
den Gebrauch anderer Metriken nahezu vollständig verzichtet
werden kann. Die Reduktion auf die Gruppe von Metriken macht letztendlich
die automatische Auswertung der Ergebnisse überhaupt erst
möglich. Vor allem sind die automatisch erlangten Ergebnisse
in ihrer Systematik übersichtlich und reproduzierbar. Diese
Filtermodule werden erfindungsgemäß auf die Computersteuerung angewendet.
-
Die
Kombination der Metriken und deren Ergebnisse findet in einem der
ersten Analyse nachfolgenden Schritt statt. Anhand dieser analytischen Auswertung
können letztendlich „kritische” Bereiche, insbesondere
kritische Module, im Code der Computersteuerung identifiziert werden.
Als kritische Module sind insbesondere solche anzusehen, die nicht dem
aktuellen Entwicklungsstandard entsprechen und/oder die besonders
komplex, also verschachtelt und/oder lang sind. Auch schwer verständliche
Bereiche und Bereiche, die das Finden von Fehlern erschweren oder
die Wiederverwendung schwer machen, können kritisch sein.
All diese Punkte tragen dazu bei, die Wartungskosten des Programmcodes in
die Höhe zu treiben. Dabei ist eine gute Wartbarkeit umso
wichtiger, je größer die geplante Verwendungsdauer
ist, je größer und komplexer die Software oder
je geringer die Verfügbarkeit von Experten ist.
-
Neben
der Auswahl und der kombinatorischen Anwendung der Filtermodule,
liegt ein weiterer wesentlicher Gedanke der Erfindung in einer nachgeschalteten
Relevanzprüfung. Diese ist vorteilhaft, da manche Module,
die zunächst als kritisch klassifiziert wurden, aus übergeordnetem
Grund dennoch als qualitativ ausreichend zu beurteilen sind. Ein
solcher übergeordneter Grund kann darin liegen, dass das Modul
schon lange existiert und/oder noch nie bedeutende Modifikationen
erfahren hat und/oder schon immer stabil lief. Insgesamt ist es
also vorteilhaft, die „Historie” des Moduls bei
der Relevanzprüfung zu berücksichtigen. Dann werden „alt
bewährte” Module durch die Relevanzprüfung
trotz offenbar geringer Güte herausgefiltert und als hochwertig
qualifiziert. Auf diese Weise werden mit dem erfindungsgemäßen
Verfahren wirklich nur die Module herausgefiltert und dem Nutzer
als minderwertig vorgestellt, bei denen erhöhter Änderungsbedarf
besteht. Die Relevanzprüfung erfolgt ebenfalls vollautomatisch über
die Auswertung des Repositories.
-
Eine
Relevanzprüfung kann so aussehen, dass Teile respektive
Module der untersuchten Computersteuerung anhand des jeweils ermittelten
Gütefaktors aufgelistet werden, wobei die automatische Relevanzprüfung
an den einzelnen Modulen vorgenommen wird. Als Ergebnis der Relevanzprüfung werden
nur die als kritisch verbliebenen Module markiert.
-
Die Überprüfung
der Relevanz ist aus folgendem Grund vorteilhaft: Die Metrik-Messung
allein, ebenso die Bestimmung der Antipatterns, generiert mitunter
eine lange Liste problematischer Bereiche und Verbesserungsvorschläge.
In der Regel können aus wirtschaftlichen Gründen
nicht alle Vorschläge umgesetzt werden oder Änderungsvorschläge
haben keinen Sinn, so dass es unnötig ist, an diesen Stellen zu
refaktorieren.
-
Vorteilhafterweise
werden in einem letzten Schritt die Ergebnisse in Form eines Reports
an den Nutzer ausgegeben. Dieser enthält die vorteilhafterweise
aus den Gütefaktoren bestimmte Aussagen betreffend die
Wartbarkeit der einzelnen Module. Zudem können Hinweise
ausgegeben werden, an welchen Stellen bestimmte Module auf welche
Art modifiziert werden sollten, um den Anforderungen an eine hohe
Zuverlässigkeit und eine gute Wartbarkeit zu genügen.
Letztendlich kann eine aussagekräftige Ansicht aller Module
erzeugt und dem Nutzer ausgegeben werden.
-
Eine
solche Ausgabe kann visuell geschehen, beispielsweise als „Citylyzer-View”,
die eine „Skyline” einer Stadt erzeugt, wobei
große Blöcke mit großer Wahrscheinlichkeit
Gott-Klassen sind. Je nach Metrik sind auch Streubilder möglich.
So sind beispielsweise bei einer Auftragung der Komplexität gegen
LOC die oben rechts befindlichen Module von geringer Qualität.
-
Die
beiden wesentlichen Schritte des erfindungsgemäßen
Vorgehens sind somit erstens die automatische Visualisierung und
Vermessung des Softwaresystems mit der folgenden kombinatorische Betrachtung
und Analyse der Ergebnisse und zweitens die Relevanzprüfung.
Mit der erfindungsgemäßen Vorgehensweise kann
die Zeit für eine aussagekräftige Beurteilung
einer Computersteuerung auf wenige Tage reduziert werden, was mit
einer massiven Kostenersparnis einher geht. Letztendlich macht es
die Erfindung überhaupt erst möglich, Beurteilungen
von Software automatisiert und standardisiert und damit wirtschaftlich
durchzuführen. Der Nutzer wird damit erstmals in die Lage
versetzt, die zu erwartenden Wartungskosten genau abschätzen
zu können.
-
Nachfolgend
sind die Metriken aufgelistet, die sich aufgrund der empirischen
Untersuchungen als besonders vorteilhaft für den Einsatz
in dem erfindungsgemäßen Verfahren herausgestellt
haben. Zudem werden Werte für die Größenordnung
der sich daraus ergebenden Kennzahlen angegeben:
- „Lines
of Code” (LOC) ist die Anzahl der nicht leeren Zeilen im
Code. Pro Modul sollte die LOC unter 100 liegen.
- ”McCabe's Cyclomatic Complexity” (MVG, CC)
ist eine Komplexitätsmesszahl aus der Summe der Komplexität
aller Funktionen. Dabei wird die Anzahl der linear unabhängigen
azyklischen Pfade durch den Code gemessen. Als oberer Grenzwert
kann 10 vorgegeben werden.
-
Kopplungen:
-
- • „Coupling between objects” (CBO)
ist die Anzahl der Module, die das betrachtete Modul aufrufen oder
von diesem aufgerufen werden.
- • Response For a Class (RFC) ist eine Maßzahl für
die potentielle Kommunikation zwischen der betrachteten und anderen
Klassen, inklusive aller Methoden aus der Vererbungshierarchie und
die Methoden, die von anderen Objekten aufgerufen werden. Je größer
der RFC, desto komplexer und desto schwieriger zu testen. Der Grenzwert
sollte unter 50 liegen.
-
- „Depth of inheritance tree” (DIT) ist
die Länge des längsten Pfades des Vererbungsbaumes.
Je länger der Vererbungsbaum, desto schwieriger ist es, das Verhalten
des betrachteten Moduls vorauszusagen. Andererseits kann ein höherer
Wert Wiederverwendung vereinfachen. Für DIT wird vorteilhafterweise ein
Grenzwert von 5 angenommen.
-
Bei
Bedarf können auf folgende Metriken hinzugenommen werden:
- „Lines of code per line of comment” ist die
Kommentardichte als Anzahl der Codezeilen pro Kommentarzeile. Die
Zahl Kommentarzeilen sollte bei etwa 30% der LOC liegen. Sinnvolle
Kommentare erhöhen Verständlichkeit und vereinfachen
die Wartung. „Lines of Comments” (COM) ist die
absolute Anzahl der Kommentarzeilen.
- „Weighted methods per class” (WMC) ist die
durchschnittliche Anzahl der Methoden pro Klasse.
-
Während
jede einzelne der mittels dieser Metriken erzeugten Kennzahlen kaum
Schlüsse auf die Qualität der Software zulassen,
können anhand erfindungsgemäßer Kombinationen
Aussagen darüber gemacht werden, inwieweit die Software
wartbar, also insbesondere erweiterbar oder verständlich
ist, so dass sich Entwickler schnell einarbeiten können. Dadurch
werden die Wartungskosten erheblich gesenkt.
-
Diese
Form der Qualitätssicherung hilft, Source Code, der in
bisherigen Methoden hauptsächlich als „black-box” betrachtet
wurde, transparent zu machen und innerhalb kurzer Zeit Problemstellen
zu identifizieren und dem Programmierer zur Verbesserung vorzuschlagen.
Die Erfindung präsentiert dabei automatisch einen konkreten
Verbesserungsvorschlag, basierend auf den Ergebnissen der Analyse.
Die Erfindung trägt dazu bei, die Qualität der
Computersteuerung zu erhöhen, da auffällige Stellen
nach ihrer unkomplizierten Entdeckung einem Reengineering unterworfen
werden können. So ist es möglich, die Kosten über
den gesamten Lebenszyklus zu senken. Die erfindungsgemäße
Methode ermöglicht einem Kunden erstmals, die Software
von Lieferanten anhand der inneren Qualität zu überprüfen
und Folgekosten transparent zu machen. Mit der Erfindung werden
automatische Aussagen über die Wartbarkeit von Software
möglich, automatisch Schwachstellen aufgespürt
und somit ein schnelles Refactoring ermöglicht und die
Wartungskosten nachhaltig gesenkt.
-
Nachfolgend
wird die Erfindung anhand der 1 bis 4 näher
erklärt. Es zeigen
-
1 ein
Schaubild MVG/LOC,
-
2:
ein Schaubild zur Kommentardichte,
-
3:
ein Schaubild zu Duplikaten,
-
4:
ein Schaubild zur Duplikatfrequenz,
-
5:
ein Schaubild zur Kopplung,
-
6:
eine Visualisierung der WMC („Weighted Methods per Class”),
-
7:
eine Vererbungshierarchie,
-
8:
ein Netzdiagramm und
-
9:
ein zusammenfassendes Flussdiagramm.
-
Nachfolgend
werden zunächst die einzelnen Metriken anhand der Figuren
erklärt:
Entsprechende Filtermodule untersuchen automatisch
einerseits die Modulgröße (LOC) und andererseits
die Modulkomplexität (MVG). Die Komplexitätsmessung
nach McCabe misst die Anzahl linear unabhängiger azyklischer
Pfade durch den Code. Werden die Komplexität und die Modulgröße
durch die Verknüpfungsfunktion verbunden, können
problematische Stellen im Code identifiziert und ein Gütefaktor bestimmt
werden. Je mehr Module in dem umrandeten „kritischen Bereich” 1 des
in 1 gezeigten Schaubildes, in dem MVG gegen die
LOC aufgetragen ist, enthalten sind, desto schlechter ist die Wartbarkeit.
Der kritische Bereich 1 umfasst dabei diejenigen Module,
die eine zu große Anzahl unterschiedlicher azyklischer
Pfade haben. Dabei steigt die Komplexität mitunter exponentiell
mit der Anzahl der Zeilen. Eine gute Kapselung und ein gutes Design
können dieses exponentielle Wachstum verhindern.
-
Für
die „McCabe's Cyclomatic Complexity”, also die
Anzahl der linear unabhängigen Pfade durch den Code, kann
als Grenzwert die Zahl 10 vorgegeben werden.
-
Eine
weitere Verknüpfung führt zu der aussagekräftigen „Kommentardichte”,
also der von einem Filtermodul untersuchten Anzahl der Kommentarzeilen
pro Modul im Verhältnis zu der von einem anderen Filtermodul
untersuchten Modulgröße (LOC). Wenn große
Klassen schlecht kommentiert sind, bedeutet dies eine massive Beeinträchtigung
der Wartbarkeit. In 2 ist eine Kommentardichte im
Diagramm Kommentarzeilen/LOC dargestellt. Im umrandeten kritischen
Bereich 2 liegen die Module, deren Wartung schwierig ist.
Dabei werden als „gesundes” Verhältnis
für die Zahl der Kommentare im Verhältnis zum
LOC etwa 30% angesehen.
-
Auch
können Duplikate oder Clone, also identische oder nahezu
identische Codesequenzen, die mehrmals in einem System vorkommen,
betrachtet werden. Da sie die Entwicklung stark beschleunigen, kommen
Duplikate häufig vor. Duplikation erhöht jedoch
die Programmlänge und senkt die Codeverständlichkeit.
Zudem muss jeder Fehler in dupliziertem Code an jeder Stelle behoben
werden. Die 3 und 4 zeigen
Analyseergebnisse, wobei in einem idealen System die Graphen leer
wären. Übersteigt die Duplikatmenge einen gewissen
Prozentsatz des Codes oder existieren viele kleine Code-Clones,
ist von problematischer Wartbarkeit auszugehen. 3 zeigt
die Länge der Clones und die Anzahl der Instanzen, also
die Häufigkeit des Vorkommens (beispielsweise 2000 Clone
der Länge 20 Zeilen). Als wichtiger Faktor sei die Gesamtlänge
der Duplikate genannt, um die die Systemgröße
bei einem Reengineering verringert werden könnte. Die Erfahrung
zeigt, dass die Summe aller Duplikate 10%–30% der Systemgröße
ausmacht. 4 zeigt die Häufigkeit
(Frequenz) einzelner Duplikatsinstanzen, also wie oft ein einzelnes
Stück Code dupliziert wurde. Im Beispiel wurden 2 Codefragmente
200-mal kopiert.
-
Die
Anzahl der Codezeilen pro Modul sollte unter dem Grenzwert von 100
liegen. Dabei sollte die Zahl der Nicht-Kommentarzeilen pro Modul
kleiner als 50 sein.
-
Die „Kopplung” definiert,
wie einzelne Systemteile miteinander verbunden sind. Während
die Modularisierung und damit die Trennung einzelner Aufgaben in
einzelne Module die Übersicht erhöht und eine
teilweise Wiederverwendung ermöglicht, müssen
die einzelnen Elemente auch weiterhin Informationen austauschen.
Ist die Kopplung zwischen zwei Bereichen zu eng, werden also zu
viele Daten ausgetauscht, deutet das auf einen falschen Schnitt in
der Modularisierung hin. Müssen einzelne Objekte mit zu
vielen anderen Objekten Informationen austauschen, deutet dies auf
eine falsche Kapselung hin. Wie in 5 dargestellt,
ist das gezeigte Modul 3 besonders vielen anderen Modulen
gekoppelt. Bei einer Änderung der Schnittstelle dieses
Moduls müssen alle verbundenen Module ebenfalls geändert
werden, was den Aufwand und damit die Wartungskosten erhöht.
Die Erfindung bewertet die Kopplung jedes Moduls. Überschreitet
ein Modul einen festgelegten Grenzwert, wird dieses als kritischer
Bereiche des Codes identifiziert.
-
Für
die Kopplung, also die Anzahl derjenigen Module, die mit dem betrachteten
Modul als Aufrufer oder aufgerufener verbunden sind, kann als Grenzwert 30 vorgegeben
werden.
-
Zudem
besteht jede Klasse aus einer Sammlung einzelner Methoden. Wird
die Anzahl der Methoden pro Klasse zu groß, so wird diese
Klasse unübersichtlich und der Code schwieriger zu verstehen. Komplexe,
große Klassen mit zu vielen Methoden weisen beispielsweise
auf eine „Gott-Klasse” hin, also eine Klasse,
die zu viel Funktionalität beinhaltet und damit ein Paradigma
der Objektorientierung – ”eine Aufgabe pro Klasse” – verletzt.
Für eine schnelle Verständlichkeit des Codes sollten
die einzelnen Methoden nicht zu lang sein, wobei eine Methode idealerweise
komplett auf eine Bildschirmseite passt. Erfindungsgemäß wird
die Anzahl der Methoden pro Klasse berechnet. In 6 ist
sowohl die Vererbungshierarchie als Baum, als auch die Größe
der Klassen durch die Einfärbung (je dunkler, desto größer),
die Anzahl der Attribute als Breite der Rechtecke sowie die Anzahl
der Methoden pro Klasse als Höhe der Rechtecke dargestellt.
Alle besonders hohen Elemente bedürfen für das
Kriterium der Anzahl der Methoden pro Klasse einer Überprüfung
und können automatisch aus dem Code gewonnen werden. Die
langen, also dunkel eingefärbten, Klassen und Methoden
können automatisch als problematische Stellen im Code gekennzeichnet
werden.
-
Eine
Parameterliste beschreibt die Anzahl derjenigen Werte, die einer
Funktion beim Aufruf übergeben werden. Überschreitet
die Anzahl der Parameter einen bestimmten Wert, für den
sich in der Praxis der Wert „sieben” bewährt
hat, so ist der nachfolgende wie auch der aufrufende Code schwer
verständlich. Die Wartung und die Wiederverwendung des
Codes wird damit schwierig.
-
Gerade
bei der Objektorientierung ist die Vererbung und damit die leichte
Wiederverwertbarkeit von Funktionalität sowie deren Modifikation
möglich. Wird die Vererbungshierarchie jedoch zu hoch und überschreitet
kritische Werte, so ist die Funktionalität einer Kind-Klasse
nur noch sehr schwer nachvollziehbar, da in jeder Hierarchie die
Funktionalität der Vorfahren überschrieben werden
kann. Existiert keine oder nur geringe Vererbungshierarchie, deutet dies
auf eine nicht ausreichend eingesetzte Objektorientierung hin, wie
beispielsweise in 7 an den Bereichen 4 und 5 zu
erkennen ist. Hierarchien, die einen Grenzwert überschreiten,
werden automatisch erkannt und als problematisch identifiziert.
Als Grenzwert für die Höhe des Vererbungsbaumes
kann die Zahl „5” vorgegeben werden.
-
Zusätzlich
zu den genannten Metriken können auch noch „hart
kodierte Konstanten” untersucht werden, da eine hohe Anzahl
die Verständlichkeit des Codes erschwert. Auch das Vorhandensein
von unfertigem Code kann durch Zählen von Kennzeichnungen
wie „todo”, „xxx” oder ähnlichem
untersucht werden. Unverwendeter und auskommentierter Code kann
das System aufblähen und die Verständlichkeit erschweren.
-
Die
vollautomatische Erkennung der Antipatterns beruht auf der Analyse
und Kombination mehrer Metriken kann folgendermaßen geschehen.
Zur Erkennung beispielsweise einer „Gott-Klasse” können
folgende Regeln verwendet werden: Wenn die Komplexität
groß, beispielsweise > 100,
und wenn „lines of code” groß und wenn
Anzahl der Methoden groß und wenn die Anzahl der Attribute
groß und wenn viele Attribute anderer Klassen direkt verwendet
werden, also eine hohe Kopplung besteht, dann folgt daraus, dass
es sich um eine „Gott-Klasse” handelt. Dabei erlaubt
das System die freie Konfiguration von neuen Regeln, so dass die
Suche nach weiteren Antipatterns leicht eingebaut werden kann.
-
Zu
dem Antipattern „Gott-Klasse” gibt es bekannte
Restrukturierungsvorschläge. So sollte eine Aufteilung
der Funktionalität in Einheiten erfolgen, so dass jede
Klasse nur noch eine Aufgabe hat.
-
Auch
die Erkennung einer ”Datenklasse”, also einer ”dummen” Klasse,
die nur Daten hält, ist möglich. Eine solche liegt
vor, wenn viele eigene Attribute vorhanden sind und eine geringe
Komplexität vorherrscht und wenn zudem Daten von vielen
verschiedenen anderen Klassen verwendet werden. Eine Datenklasse
widersprich dem Prinzip der Objektorientierung, nämlich
Daten bei der Funktionalität zu halten und so eine Kapselung
zu garantieren. Als Refaktorierungsvorschlag kann ausgegeben werden, die
Daten zu der Funktionalität ziehen, die Klasse auflösen
und so eine Kapselung zu erreichen.
-
Die
Ergebnisse der angewandten Metriken können auch in einem „Netz” entsprechend 8 dargestellt
werden, wobei das Netz eine Verknüpfungsregel symbolisiert.
In diesem Fall bilden die fünf Metriken „Komplexität” 8, „Duplikate” 9, „Vererbungsbaum” 10, „Methodenzahl” 11 und „Kommentarrate” 12 die
radialen „Fäden” des Netzes, wobei der
Nullpunkt im Zentrum liegt. Die Größe der ermittelten Kennzahl
ist radial aufgetragen. Während keine Metrik für
sich alleine betrachtet eine aussagekräftige Schlussfolgerung
erlaubt, so kann anhand dieser Auftragung ein Gütefaktor
bestimmt und über ein Ausgabemedium ausgegeben werden.
-
Werden
in einer untersuchten Computersteuerung Grenzwerte mehrerer Metriken
verletzt, deutet das auf schwerwiegende Probleme des Codes hin.
In 8 ist Polygon 6 die SOLL-Hülle,
während das Polygon 7 die aktuellen IST-Werte
repräsentiert. Befindet sich die IST-Messung, wie hier,
außerhalb der SOLL-Werte und zeigen zudem die Metriken „Komplexität” und „Kommentardichte” Module im
kritischen Bereich, ist dies ein klares Indiz für eine schwere
Verständlichkeit des Codes, eine entsprechend schwierige
Fehleridentifikation, kaum Möglichkeiten zur Wiederverwendung
und erhöhte Testkosten. Insgesamt spricht das für
einen kleinen Gütefaktor und damit für eine schlechte
Wartbarkeit der Computersteuerung.
-
In 9 ist
ein Flowchart dargestellt, in dem die einzelnen Schritte der erfindungsgemäßen
Vorgehensweise noch einmal dargestellt sind.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste
der vom Anmelder aufgeführten Dokumente wurde automatisiert
erzeugt und ist ausschließlich zur besseren Information
des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen
Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt
keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-