Die CCD-Workbench ist die Arbeitsumgebung für Clean Code Developer in Eclipse. Die Workbench beinhaltet eine Grad-Anzeige, einen Inspector und einen Analyzer.
Die Grad-Anzeige visualisiert den aktuellen Grad des Clean Code Developers in seiner Arbeitsumgebung. Der Inspector der Workbench verwaltet die zu inspizierenden Java Quellcode-Dateien. Eine Inspektion ist zweigeteilt in eine manuelle Inspektion und eine automatische Inspektion kategorisierbar.
Bei der manuellen Inspektion kennzeichnet der Reviewer Quellcode "Smells" mit CCD Annotationen. Bei der automatischen Inspektion hingegen werden Quellcode "Smells" durch Parsen und Analysieren des Quellcodes erkannt. Ein Verstoß gegen ein CCD-Prinzip in einer Java Quellcodedatei kennzeichnet der Analyzer durch das Hervorheben der Quellcodezeile und Annotation mit einer Warnmarkierung im Eclipse Quellcode-Editor.
Die Grad-Anzeige visualisiert den aktuellen Grad des Clean Code Developers in seiner Arbeitsumgebung. Der Inspector der Workbench verwaltet die zu inspizierenden Java Quellcode-Dateien. Eine Inspektion ist zweigeteilt in eine manuelle Inspektion und eine automatische Inspektion kategorisierbar.
Bei der manuellen Inspektion kennzeichnet der Reviewer Quellcode "Smells" mit CCD Annotationen. Bei der automatischen Inspektion hingegen werden Quellcode "Smells" durch Parsen und Analysieren des Quellcodes erkannt. Ein Verstoß gegen ein CCD-Prinzip in einer Java Quellcodedatei kennzeichnet der Analyzer durch das Hervorheben der Quellcodezeile und Annotation mit einer Warnmarkierung im Eclipse Quellcode-Editor.
In dem nachfolgenden UML-Diagramm werden die Akteure und der Kern der Anwendungsfälle der CCD-Workbench veranschaulicht:
Die CCD-Prinzipien setzen sich aus Syntax und Semantik zusammen. Syntax-Prüfungen sind automatisiert durch einen Parser ausführbar. Semantische Prüfungen hingegen sind nur sehr viel schwerer und mit deutlich höherer Software-Intelligenz prüfbar.
Parsevorgang:
Ein Lexer liest die Java-Quellcodedateien und erzeugt aus dem Eingabestrom die Tokens zur Weiterverarbeitung im Parseprozess. Für den Parser sind die Tokens atomare Eingabezeichen, die zur Syntaxprüfung herangezogen werden. Im Parseprozess wird nach der Syntaxprüfung ein Ableitungsbaum (Parsebaum) erstellt, der zur Weiterverarbeitung dient. Auf Basis des Parsebaums und des CCD-Regelsets (DSL) kann der CCD-Parser Regelverstöße gegen CCD-Prinzipien erkennen.
Bei der automatischen Syntaxprüfung und Erkennung von Quellcode "Smells" wird eine Untermenge von möglichen Verstößen gegen CCD-Prinzipien erkannt. Für Folgeversionen der CCD-Workbench sind weitere Muster zur Erkennung geplant.
Die Architektur der CCD-Workbench ist komponentenorientiert. Das Komponentenmodell der CCD-Workbench setzt sich aus Kern- und Anzeigekomponenten zusammen. Die Anzeigekomponenten verwenden die Eclipse RCP Plattform und sind mit SWT/JFace programmiert. Die Bündelung der Komponenten und Konfiguration der Eclipse Plugins und Features basiert auf OSGI.
Komponentenmodell der CCD-Workbench:
Auszug der Benutzerschnittstelle der CCD-Workbench:
Im Inspector wird zunächst ein Bearbeitungsstatus vergeben. Danach selektiert man die Java Quellcodedateien und wählt die Aktion "CCD Analyse" im PopUp Menü oder der Toolbar aus, um den Analyseprozess zu starten.
Nach der Analyse werden die Regelverstöße in der Analyzer-View angezeigt. Pro Java Quellcodedatei wird eine Aufzählung von Verstößen visualisiert. Das Format eines Eintrages setzt sich aus dem Kürzel des Verstoßes (LOD, TDA, etc.), der Zeilennummer und Review-Aktion (A = Annotation (manuell) / D = Detection (automatisch)) zusammen. Selektiert man in der Analyzer-View eine Quellcodedatei wird der Java Quellcode-Editor aufgeschaltet, um entsprechende Zeilen mit Verstößen gegen CCD-Prinzipien hervorzuheben.
Der Analyzer visualisiert im vorliegenden Fall einen Verstoß gegen das Law of Demeter (LOD) und Tell don't ask (TDA). Die Regelschärfe zu einem CCD-Prinzip kann in den Eclipse Preferences definiert werden.
Fazit:
Der CCD-Reviewprozess ist automatisierbar. Quellcode, der aufgrund der Semantik nicht automatisiert analysiert werden kann, wird im Reviewprozess durch Annotationen gekennzeichnet. Die Annotationen sind im Nachgang durch den Analyzer erkennbar und werden nach der Beseitigung des "Code Smells" gelöscht. Bei der Annotierung steht die Markierung im Vordergrund, die ein Reviewer vornimmt und ein Entwickler nach dem Vier-Augen-Prinzip korrigiert.
Die Grundvoraussetzung für die automatische Analyse ist ein Parsebaum, der Muster zur Auswertung beinhaltet. Das Parsen mit regulären Ausdrücken und Java Stringfunktionen (Tokenizer, etc.) ist dabei als zu schwach anzusehen. Der Parsebaum ist deshalb auf Basis der regulären Java-Syntax aufzubauen. Im Parseprozess fallen Muster an, die wiederum analysierbar sind. Komplexere Muster sind beim Parsen erkennbar und Teil des Analysevorgangs. Dennoch ist ein gewisser Aufwand für die Erkennung und Behandlung der Muster vorhanden. Die Bildung von Mustergruppen ist aufgrund der vielfältigen Merkmale der CCD-Prinzipien kaum möglich. Neue Muster werden deshalb im Zuge der Release-Bildung jeweils einzeln in die CCD-Workbench integriert.
Clean Code Developer Workbench © 2010 - 2013 Blogbetreiber (alle Rechte vorbehalten)