Wie IDEs von ihren Usern lernen können – und User von ihrer IDE.

"IDE 2.0?"

Marcel Bruch

Mit Web 2.0 hat ein fundamentales Umdenken in der Nutzung des Internets stattgefunden: Informationen werden nicht mehr länger von wenigen bereitgestellt und von vielen genutzt, sondern jeder ist jetzt in der Lage, seine Informationen und Erfahrungen bereitzustellen und zu einem „Großen Ganzen“ zusammenzufügen. Wikipedia ist ein Beispiel für den Erfolg solcher Anwendungen. Die Frage ist nun: Können IDEs von diesem Konzept profitieren? Und wenn ja, wie genau?

Software Frameworks sind aus dem heutigen Entwicklungsprozess kaum noch wegzudenken. Kein Wunder, treten sie doch mit einer Vielzahl von Versprechungen an, um die Welt der Softwareentwicklung effizienter zu gestalten. Dennoch ist ihr Einsatz nicht kostenlos: Bevor Frameworks effizient eingesetzt werden können, müssen Entwickler den Umgang mit ihnen zuerst einmal erlernen.

Um die Einarbeitung möglichst gering zu halten, stellen Framework-Entwickler verschiedene Dokumentationen zur Verfügung. Dennoch bleibt oftmals unklar, wie gewisse Anforderungen mit Hilfe des Frameworks erfüllt werden können. Wenn die bestehende Dokumentation keine Hilfestellung mehr geben kann, stellt der Quellcode anderer Programme, die das Framework bereits auf ähnliche Weise benutzt haben, eine interessante Informationsquelle dar. In diesem Artikel wollen wir anhand zweier Beispiele zeigen, wie IDEs ihre Nutzer beim Erlernen neuer Frameworks besser unterstützen könnten: beispielsweise, indem sie aus dem Quellcode anderer Anwendungen die korrekte Nutzung des Frameworks erkennen und dieses Wissen dem Entwickler wieder zur Verfügung stellen.

Das Projekt „Eclipse Code Recommenders“ Wer mehr über den hier vorgestellten Ansatz und das Projekt Eclipse Code Recommenders erfahren möchte, dem sei das vom Eclipse Magazin und itemis am26.11.2009 in Frankfurt veranstaltete Eclipse DemoCamp empfohlen, in dem Marcel Bruch das Projekt in einer Live-Demo vorstellen wird.
„IDE 2.0“ – Wie geht das? Zwei Beispiele wie Code anderer Anwendungen Entwicklern helfen könnte.

Nehmen wir die folgende Situation als Beispielszenario: Ein Entwickler möchte mit den Frameworks SWT und JFace einen einfachen Eingabe-Dialog erzeugen. Innerhalb dieses Dialogs soll ein Benutzer über ein Textfeld eine Eingabe machen können, die vom System dann ausgelesen wird. Nehmen wir weiter an, dass der Entwickler bereits die korrekte Basisklasse (in unserem Fall die Klasse org.eclipse.jface.dialogs.Dialog) ausgewählt hat. Abbildung 1 zeigt den Code, den die Entwicklungsumgebung für den Entwickler initial bereit stellt.

Abbildung 1: Ausgangssituation des Beispielszenarios

Nachdem die ersten Zeilen generiert sind, stellen sich für den Entwickler zwei Fragen: Wo kann der Code für das Text-Widget platziert werden? Und wie muss das Text-Widget konfiguriert bzw. verwendet werden, damit der Code am Ende lauffähig ist und die Eingabe tatsächlich ausgelesen werden kann?

Beschäftigen wir uns zuerst mit dem Wo.

[ header = Seite 2: HotSpot-Identifikation der Klasse Dialog ]

HotSpot-Identifikation der Klasse Dialog

Um erste Anhaltspunkte zu bekommen, welche Methoden der Basisklasse überschrieben werden müssen, wird zuerst die Javadoc-Klassendokumentation der Basisklasse nach Hinweisen untersucht. Im Fall der Klasse Dialog ist diese Untersuchung allerdings nicht sehr erfolgreich; die Klassendokumentation beschreibt lediglich das Konzept der „modalen Dialoge“ (vgl. Javadoc View in Abbildung 1), gibt jedoch keinen Aufschluss darüber, wo der eigene Code eingefügt werden kann. Darüber hinaus gibt es in der Klasse auch keine abstrakten Methoden, die einen Entwickler auf die relevanten, da zu implementierenden Methoden hinweisen könnten. Der Entwickler ist jetzt also gezwungen, alle 55 Methoden von Dialog manuell zu untersuchen, d.h. nach interessant klingenden Methodennamen zu fahnden bzw. die Javadocs der Methoden auf entsprechenden Informationen hin zu analysieren.

Nun kommt die Frage auf, wie andere Entwickler die Klasse Dialog typischerweise erweitert haben, d.h. welche der 55 Methoden bisher von Entwicklern besonders häufig überschrieben wurden.

Würde der Entwickler den gesamten Code seiner Eclipse-Entwicklungsumgebung nach Dialog-Subklassen durchsuchen, käme er zu dem Ergebnis, dass fast alle Subklassen die MethodeDialog.createDialogArea() bzw. sehr viele Subklassen die Methode Dialog.okPressed() überschreiben. Diese Methoden scheinen also in besonderem Maße für Subklassen interessant zu sein – warum also nicht auch jetzt? Die spannende Frage lautet: Wieviel würde ein Entwickler davon profitieren, wenn ihm die IDE exakt diese beiden Methoden vorschlagen würde, anstelle der gesamten Liste – oder ihm zumindest eine Empfehlung geben könnte, welche der vielen Methoden er sich genauer anschauen sollte?

Abbildung 2 zeigt, wie eine solche Integration in der Eclipse-Entwicklungsumgebung aussehen kann: Die Eclipse Code Completion (1) links im Bild zeigt hier anstelle der 55 nur noch vier Methoden an, die tatsächlich häufig überschrieben wurden. Das sind die Methoden createDialogArea(), configureShell(), okPressed() und createButtonsForButtonBar(). Die gleichen Informationen werden alternativ auch in einer „erweiterten Javadoc View“ (2) rechts im Bild direkt innerhalb der Klassendokumentation angezeigt und können so die Klassendokumentation der Klasse Dialog sinnvoll mit den vorher vermissten Benutzerinformationen ergänzen.

Abbildung 2: Vorschläge, welche Methoden der Basisklasse überschrieben werden sollten.

Die in diesem Beispiel gezeigten Informationen können durch verhältnismäßig einfache Analysen aus dem Quellcode bestehender Subklassen extrahiert werden. Um die in Abbildung 2 gezeigten Ergebnisse zu bekommen, wurde der Quellcode aller auf der Eclipse 3.4 Update Site gehosteten Plug-ins analysiert, deren Überschreibungsinformationen vollautomatisch extrahiert und in eine Datenbank geschrieben. Der dabei analysierte Quellcode umfasste ca. 700 MB.

Zurück zum Beispiel. Nehmen wir für unser Szenario an, dass der Entwickler sich die Dokumentation der vier vorgeschlagenen Methoden näher angeschaut und entschieden hat, die MethodencreateDialogArea() und okPressed() zu überschreiben. Sind die relevanten Einsprungmethoden gefunden, muss nun der eigentliche Code für das Text-Widget geschrieben werden, also die Frage nach dem „wie benutze ich eine Instanz eines Frameworks korrekt?“ beantwortet werden.

Instanz-Verwendungsmuster für SWT-Text-Felder

Nehmen wir an, dass der Entwickler bereits das SWT-Text-Feld erzeugt hat und es im nächsten Schritt noch konfigurieren möchte. Löst der Entwickler, wie in Abbildung 3 gezeigt, die Eclipse Code Completion auf der Variable text aus, schlägt diese ihm nun alle potenziell möglichen Methoden vor, die auf einem Text-Widget aufgerufen werden können – im Fall von SWT-Text also rund 160 Methoden.

Abbildung 3: Default Code-Completion auf einem SWT Text Widget – runde 160 Methoden obwohl nur drei ge-braucht werden.

Letztendlich benötigt ein Entwickler in dieser Situation jedoch selten mehr als drei Methoden aus dieser Liste: Nämlich (i) setLayoutData(), um das Text-Widget entsprechend innerhalb des Containers zu positionieren, (ii) setText(), um eventuelle frühere Benutzereingaben wieder bereitzustellen und (iii) add-ModifyListener(), falls bei Änderungen im Textfeld eine Syntaxüberprüfung vorgenommen werden soll. Drei Methoden, die ein Entwickler aus den angebotenen 160 Methoden selbst herausfinden muss – eine Aufgabe, die einen Entwickler, der mit dem SWT-Framework vertraut ist, kaum vor ein Problem stellen wird, für unerfahrenen Entwickler jedoch erst einmal eine Herausforderung darstellt.

Schaut man sich die Situation genauer an, kommt man auch hier schnell zum Schluss, dass es eine Reihe von Klassen geben muss, die ein Text-Widget in einer vergleichbaren Situation in ähnlicher Art und Weise bereits benutzt haben müssten. Die Frage lautet also: Kann die Entwicklungsumgebung einen Entwickler auch hier unterstützen, indem sie ihm beispielsweise irrelevante und unwahrscheinliche Methoden filtert oder ihm zumindest die für ihn besonders relevanten Methoden gesondert anzeigt?

[ header = Seite 3: Das Eclipse Recommenders Project ]

Abbildung 4 zeigt, wie auch hier eine mögliche IDE-Unterstützung aussehen kann. Die Code Completion (1) zeigt nur die für den Entwickler relevanten Methoden an. In der Recommendations View (2) auf der rechten Seite werden alle Empfehlungen für das Text-Widget noch einmal in der Übersicht angezeigt. Betrachtet man diese View noch etwas genauer, sieht man, dass das System innerhalb der Methode okPressed() nur noch die Methode getText() vorschlägt. Diese Methode liefert die Benutzereingabe im Textfeld zurück und gibt somit noch die letzte, fehlende Information für den Entwickler: den Ort bzw. das Wann und das Wie für das Einlesen der Benutzereingabe.

Abbildung 4: Intelligente Code Completion zeigt nur noch relevante (häufig verwendete) Methoden an.

Die Informationen für diese Vorschläge sind (mit etwas aufwändigeren statischen Analysen) ebenfalls direkt aus dem Beispielcode anderer Anwendungen zu extrahieren. Auch für diese Situation wurden einmalig ca. 700MB Quellcode vollautomatisch analysiert und die tatsächlichen Verwendungen für Instanzen wie beispielsweise SWT-Text extrahiert und in einer Datenbank abgespeichert.

Das Eclipse Code Recommenders Projekt

Die in Abbildung 2 und 4 gezeigte IDE ist kein fiktives Mock-Up sondern ein Forschungsprototyp, entwickelt an der Technischen Universität Darmstadt. Die Forschergruppe um Prof. Mira Mezini forscht seit mehreren Jahren an Techniken, um Entwickler beim Erlernen neuer Frameworks besser zu unterstützen und stellt nun ihren ersten Prototypen auf der Projektseite zum Download bereit. Der Prototyp unterstützt bisher die drei am häufigsten verwendeten Frameworks in Eclipse: SWT, JFace und Eclipse UI. Weitere Informationen zum Projekt finden sich im Web unter http://www.stg.tu-darmstadt.de/research/core/ oder in der Live-Demo auf dem Eclipse Demo Camp in Frankfurt am Main am 26.11.2009.

Geschrieben von
Marcel Bruch
Marcel Bruch
  Dr. Marcel Bruch ist Projektleiter von Eclipse Code Recommenders, CEO von Codetrails und Wissenschaftler an der TU Darmstadt, wo die Ideen hinter IDE 2.0 bereits die Basis seiner Dissertation bildeten. Er spricht regelmäßig auf einschlägigen Konferenzen und gibt Schulungen zu den Themen OSGi und Eclipse e4. Mail: marcel.bruch@codetrails.com Twitter: @marcelbruch  
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.