Repräsentation von Java-Fakten für den constraintbasierten
Werbung
FernUniversität in Hagen Fakultät für Mathematik und Informatik Lehrgebiet Programmiersysteme Prof. Dr. Friedrich Steimann Repräsentation von Java-Fakten für den constraintbasierten Refaktorisierungsansatz mit Hilfe von TGraphen Masterarbeit im Studiengang Master of Science in Informatik vorgelegt von Matthias Kleine [email protected] betreut durch Prof. Dr. Friedrich Steimann, Dipl.-Inform. Andreas Thies Juli 2011 1 2 Danksagung Das Erstellen dieser Arbeit stand im Zeichen der Geburt meiner Tochter Alina. Ihre ersten Lebensmonate werden in meiner Erinnerung für immer mit dieser Arbeit verbunden sein. Es wäre mir, gerade unter diesen Umständen, nicht möglich gewesen, die Arbeit ohne die Unterstützung und das Verständnis meiner Frau Simona abzuschließen. Ihr gilt daher mein besonderer Dank. 3 4 Inhaltsverzeichnis 1 Einleitung.......................................................................................................................................11 1.1 Aufbau der Arbeit...................................................................................................................11 2 Der constraintbasierte Refaktorisierungsansatz............................................................................13 2.1 Grundideen und -begriffe.......................................................................................................14 2.1.1 Variablen...........................................................................................................................14 2.1.2 Relationen und Constraint-Regeln....................................................................................14 2.1.3 Constraints und Constrainterfüllung.................................................................................15 2.1.4 Das Finden einer constrainterfüllenden Refaktorisierung................................................15 2.2 Benötigte Java-Fakten für Sichtbarkeitsconstraints...............................................................16 2.2.1 Übersicht der Constraint-Regeln.......................................................................................16 2.2.2 Eigenschaften von Deklarationen und Referenzen...........................................................17 2.2.3 Implizite Quelltext-Elemente............................................................................................19 2.2.4 Öffentliche Eigenschaften externer Bibliotheken.............................................................19 2.2.5 Rückreferenzierung des Quelltexts und Kommentare......................................................20 2.3 Bisherige Ansätze zur Repräsentation der Fakten.................................................................20 2.3.1 Repräsentation als Eclipse-AST.......................................................................................20 2.3.2 Erweiterte Faktenextraktion und Speicherung in Hashtabellen........................................20 2.3.3 Nutzung eines Java-Compilers.........................................................................................21 2.3.4 Weitere Graphen-basierte Ansätze....................................................................................21 2.3.5 Sonstige Alternativen........................................................................................................22 2.3.6 Zusammenfassung der Probleme der bisherigen Ansätze.................................................22 3 TGraphen zur Repräsentation von Java-Fakten.............................................................................23 3.1 Bezeichnung...........................................................................................................................23 3.2 Formale Eigenschaften von TGraphen..................................................................................23 3.3 Beispiel für einen TGraphen..................................................................................................23 3.4 Repräsentation von Software-Systemen mittels TGraphen...................................................24 3.5 Kurze Entwicklungsgeschichte..............................................................................................25 3.6 Architekturübersicht zu GraBaJa und dem Graphenlabor.....................................................26 3.7 Einige Eigenschaften im Detail.............................................................................................27 3.7.1 Faktenextraktion...............................................................................................................27 3.7.2 Metamodell.......................................................................................................................28 3.7.2.1 Einfacher Beispiel-Quelltext..................................................................................28 3.7.2.2 Programmwurzel und Dateibezug..........................................................................29 3.7.2.3 Typ- und Methoden-Definitionen...........................................................................30 3.7.2.4 Subtyp-Beziehungen und Methoden-Aufrufe........................................................31 3.7.2.5 Rückreferenzierung des Quelltexts........................................................................32 3.7.3 Die Abfragesprache GReQL.............................................................................................33 3.7.3.1 Bezeichnung, Komponenten und Geschichte.........................................................33 3.7.3.2 Einblick in die Syntax............................................................................................33 3.7.3.2.1 Ausdrücke.......................................................................................................33 5 3.7.3.2.2 from-with-report-Ausdrücke..........................................................................34 3.7.3.2.3 Pfadbeschreibungen als reguläre Ausdrücke..................................................34 3.7.3.2.4 Beispiel einer Abfrage an den TGraphen........................................................35 3.8 Welche Vorteile können erhofft werden?...............................................................................35 3.8.1 Lösung der Probleme anderer Ansätze.............................................................................35 3.8.2 Einige formale Vorteile.....................................................................................................36 3.8.3 Eignung für programmanalytische Aufgaben...................................................................36 3.8.4 Programmiersprachenübergreifende Refaktorisierungen.................................................36 3.9 Vorgehensweise bei Anpassungen im TGraphen...................................................................37 3.9.1 Anpassung des Metamodells.............................................................................................39 3.9.1.1 Ergänzung von Attributen zu existierenden Typen.................................................39 3.9.1.1.1 Typen für Attribute..........................................................................................39 3.9.1.1.2 Ergänzung der Attributliste eines Typs...........................................................40 3.9.1.2 Ergänzung neuer Knoten- oder Kantentypen.........................................................40 3.9.2 Modifikation des generierten TGraphen...........................................................................41 3.9.2.1 Traversieren und Abfragen.....................................................................................41 3.9.2.1.1 Traversieren aller Knoten des Graphen..........................................................41 3.9.2.1.2 Traversieren aller Kanten des Graphen...........................................................41 3.9.2.1.3 Traversieren aller Inzidenzen zu einem Knoten.............................................42 3.9.2.1.4 Suche nach Knoten bei fixem Pfad.................................................................42 3.9.2.1.5 Suche nach Knoten von einem Knoten aus....................................................42 3.9.2.1.6 Suche nach Knoten auf Graph-Ebene mittels GReQL...................................43 3.9.2.1.7 Suche nach Kanten.........................................................................................43 3.9.2.2 Ändern von Attributwerten.....................................................................................43 3.9.2.3 Erzeugen von Knoten und Kanten..........................................................................43 3.9.2.4 Löschen von Knoten und Kanten...........................................................................44 3.10 Weiterführende Informationen.............................................................................................44 3.10.1 Weblinks und Dokumentation.........................................................................................44 3.10.2 Download und Lizenzinformation..................................................................................45 3.10.3 Referenzprojekte.............................................................................................................45 3.10.3.1 ReDSeeDS............................................................................................................46 3.10.3.2 SOAMIG..............................................................................................................46 3.10.3.3 COBUS.................................................................................................................46 4 Identifikation der notwendigen Anpassungen...............................................................................47 4.1 Motivation..............................................................................................................................47 4.2 Abgleich der Eigenschaften von Deklarationen und Referenzen..........................................47 4.3 Repräsentation impliziter Quelltext-Elemente.......................................................................53 4.3.1 Implizite super()-Aufrufe..................................................................................................53 4.3.2 Implizite Konstruktor-Definitionen..................................................................................53 4.3.3 Implizite Erweiterung von Object.....................................................................................54 4.3.4 Implizite Erweiterung von Enum......................................................................................54 4.3.5 Implizite Modifier im Kontext von Interfaces..................................................................54 6 4.3.6 Impliziter Modifier für Annotationstyp-Elemente............................................................55 4.3.7 Abgrenzung.......................................................................................................................56 4.3.7.1 Elemente ohne implizite Modifier..........................................................................56 4.3.7.2 Implizite Typkonvertierungen................................................................................56 4.3.7.3 Implizites this-Schlüsselwort.................................................................................57 4.4 Repräsentation der Override-Beziehung................................................................................57 4.5 Repräsentation statischer Bindungen.....................................................................................57 4.5.1 Methoden- und Konstruktoren-Aufrufe............................................................................58 4.5.2 Feld-Zugriffe.....................................................................................................................60 4.5.3 Ermittlung statischer Bindungen nach Faktenextraktion..................................................61 4.6 Referenzierung von Empfänger-Typen..................................................................................62 4.7 Fehlerhafte Lokationsinformation für Klassen......................................................................62 4.7.1 Abgrenzung.......................................................................................................................63 4.8 Repräsentation von Java-Elementen externer Bibliotheken..................................................63 4.9 Markierung der Veränderlichkeit von Quelltext-Elementen..................................................64 4.10 Rückreferenzierung des Quelltexts und Kommentare.........................................................64 5 Dokumentation der vorgenommenen Anpassungen......................................................................65 5.1 Beispiel für eine Anreicherung..............................................................................................65 5.2 Vorbereitung des TGraphen...................................................................................................66 5.3 Anreicherung der impliziten Quelltext-Elemente..................................................................66 5.4 Umsetzung der Override-Beziehung.....................................................................................67 5.5 Umsetzung der Referenzierung von Empfänger-Typen........................................................67 5.5.1 Einschränkungen der umgesetzten Anreicherung.............................................................67 5.6 Anpassung der Lokationsinformation für Klassen.................................................................68 5.7 Prototypische Umsetzung eines Bytecode-Faktenextraktors.................................................68 5.7.1 Nutzung von BCEL zum Einlesen des Bytecodes............................................................68 5.7.2 Repräsentierte Elemente und Beziehungen......................................................................69 5.7.2.1 Nur public und protected Elemente........................................................................69 5.7.2.2 Implizitheit wird nicht berücksichtigt....................................................................69 5.7.2.3 Klassen und Interfaces............................................................................................69 5.7.2.4 Methoden- und Variablen-Deklarationen...............................................................69 5.7.2.5 Supertyp-Beziehungen...........................................................................................70 5.8 mutable-Attribut zur Markierung der Veränderlichkeit.........................................................70 5.9 Reihenfolge der Anreicherung...............................................................................................70 6 Exemplarische Constraint-Generierung mittels TGraph...............................................................72 6.1 Laufzeitverbesserte Variante..................................................................................................74 7 Diskussion.....................................................................................................................................75 7.1 Allgemeine Eignung für die Entwicklungsarbeit...................................................................75 7.1.1 Verständlichkeit und Benutzbarkeit der Schnittstellen.....................................................75 7.1.1.1 Methoden zum Navigieren im TGraphen...............................................................75 7.1.1.2 Die Nutzung von GReQL.......................................................................................77 7.1.1.3 Util-Methoden........................................................................................................77 7 7.1.2 Verwendbarkeit des Metamodells.....................................................................................77 7.1.2.1 Wahl der Typ-Bezeichner.......................................................................................78 7.1.2.2 Kompositionen statt Aggregationen.......................................................................78 7.1.3 Reifegrad...........................................................................................................................78 7.2 Erweiterbarkeit.......................................................................................................................79 7.2.1 Anreicherung des TGraphen.............................................................................................79 7.2.2 Wartbarkeit des Faktenextraktors......................................................................................80 7.3 Performance...........................................................................................................................80 7.3.1 Rahmenbedingungen.........................................................................................................80 7.3.2 Laufzeit.............................................................................................................................81 7.3.3 Speicherverbrauch.............................................................................................................81 7.3.4 Vergleichsmessungen für verschiedene Quelltexte...........................................................82 7.3.5 Bewertung der Performance-Messungen..........................................................................83 8 Ausblick.........................................................................................................................................84 8.1 Notwendige Implementierungsarbeiten.................................................................................84 8.1.1 Neu-Implementierung der statischen Bindungen..............................................................84 8.1.2 Vervollständigung der Referenzierung von Empfänger-Typen.........................................84 8.1.3 Implementierung eines Bytecode-Faktenextraktors.........................................................85 8.1.4 Der GraBaJa-Faktenextraktor und künftige Java-Versionen............................................85 8.2 Über die Sichtbarkeitsconstraints hinaus...............................................................................85 8.2.1 Eignung für beliebige Constraint-Regeln.........................................................................85 8.2.2 Parallelen zur REFACOLA...............................................................................................86 9 Zusammenfassung.........................................................................................................................89 10 Anhang.........................................................................................................................................91 10.1 Installations- und Build-Hinweise zu JGraLab und GraBaJa..............................................91 10.2 Dokumentation des Erweiterungs-Projekts.........................................................................92 10.2.1 Struktur des Projekts.......................................................................................................92 10.2.2 Installation.......................................................................................................................93 10.2.3 Zahlen zum Umfang der Implementierung.....................................................................94 10.2.4 Demonstration mittels TGraph-Browser.........................................................................94 10.3 Versionsinformation.............................................................................................................98 8 Abbildungsverzeichnis Abbildung 1: Einfacher Beispiel-TGraph..........................................................................................23 Abbildung 2: GUPRO-Architekturschema.........................................................................................25 Abbildung 3: Architekturübersicht GraBaJa / Graphenlabor.............................................................26 Abbildung 4: Metamodell: Programmwurzel und Dateibezug..........................................................29 Abbildung 5: Metamodell: Typ und Methoden-Definitionen.............................................................30 Abbildung 6: Metamodell: Subtyp-Beziehungen und Methoden-Aufrufe.........................................31 Abbildung 7: line- und offset-Attribute von Kanten..........................................................................32 Abbildung 8: Workflow bei der Umsetzung von TGraph-Anpassungen...........................................38 Abbildung 9: Heap-Monitoring während der Faktenextraktion des JUnit-Quelltexts.......................82 Abbildung 10: Entwicklungsprojekte.................................................................................................91 Abbildung 11: Import des Projekts.....................................................................................................91 Abbildung 12: Übersicht wesentlicher Implementierungs-Bestandteile............................................92 Abbildung 13: Konfiguration des Build Path.....................................................................................94 Abbildung 14: Argumente für den Start des TGraphBrowserServers................................................94 Abbildung 15: Startseite des TGraph-Browsers.................................................................................95 Abbildung 16: Struktur der Demonstrations-Beispiele......................................................................96 Abbildung 17: Anzeige während des TGraphen-Uploads..................................................................96 Abbildung 18: Tabellen-Ansicht des eingelesenen TGraphen...........................................................96 Abbildung 19: Visualisierungs-Modus des TGraph-Browsers...........................................................97 Abbildung 20: Generierte Dateien......................................................................................................98 9 Tabellenverzeichnis Tabelle 1: Benötigte Eigenschaften von Deklarationen.....................................................................18 Tabelle 2: Benötigte Eigenschaften von Referenzen..........................................................................19 Tabelle 3: Abgleich der Eigenschaften von Deklarationen................................................................51 Tabelle 4: Abgleich der Eigenschaften von Referenzen.....................................................................53 Tabelle 5: Implizite super()-Aufrufe...................................................................................................53 Tabelle 6: Implizite Konstruktor-Definitionen...................................................................................53 Tabelle 7: Implizite Erweiterung von Object.....................................................................................54 Tabelle 8: Implizite Erweiterung von Enum.......................................................................................54 Tabelle 9: Implizite Modifier im Kontext von Interfaces...................................................................55 Tabelle 10: Impliziter Modifier für Annotationstyp-Elemente...........................................................56 Tabelle 11: Überprüfte Formen statischer Methoden-Bindung..........................................................59 Tabelle 12: Überprüfte Formen statischer Feld-Bindung...................................................................61 Tabelle 13: Laufzeit- und Speichermessungen für diverse Quelltexte...............................................82 10 1 Einleitung Der Einsatz von Constraints für die Entwicklung von Refaktorisierungs-Werkzeugen hat sich beginnend mit [TIP2003] in Bezug auf die Typ-Korrektheit von Java-Programmen und nachfolgend in [STEI2009] für die korrekte Behandlung der Java-Sichtbarkeitsregeln als fruchtbar erwiesen. Während für die Generierung der von Tip genutzten Type Constraints bereits effiziente Implementierungen existieren, die auch Eingang in die Eclipse-Standarddistribution gefunden haben, zeigte sich bei der Generierung der von Steimann vorgeschlagenen Sichtbarkeitsconstraints, dass die hierfür benötigten Fakten nur umständlich und ineffizient aus der verwendeten FaktenBasis zu extrahieren waren. Als Alternative zu den bisher erprobten Möglichkeiten der Fakten-Extraktion wird in der vorliegenden Arbeit die Verwendung sogenannter TGraphen untersucht. Dabei handelt es sich um eine Klasse von Graphen mit speziellen Eigenschaften, die sich ausgehend von [EBERT1995] als besonders geeignet für die Repräsentation von Software-Systemen erwiesen haben. Die Arbeitsgruppe um Ebert am Institut für Softwaretechnik der Universität Koblenz-Landau (IST) entwickelte ein umfangreiches Framework zur Handhabung dieser Graphen, welches als Ausgangspunkt für die vorliegende Arbeit genutzt wird. Insbesondere verspricht die in diesem Framework integrierte Graphen-Abfragesprache GReQL Vorteile gegenüber dem programmatischen Durchsuchen abstraker Syntaxbäume, das den bisherigen Implementierungen zu Grunde lag. Am Beispiel der Sichtbarkeitsconstraints wird gezeigt, dass die aus Java-Programmen generierten TGraphen nicht alle Informationen enthalten, die für die Constraint-Generierung benötigt werden. Die unzureichend repräsentierten Fakten werden spezifiziert, und sofern im Rahmen dieser Arbeit die Implementierung einer erweiterten Faktenextraktion möglich war, wird diese dokumentiert. Um auch künftigen Anpassungen den Weg zu bereiten, wird der Workflow, der dabei vom Entwickler zu durchlaufen ist, detailliert beschrieben. Quelltext-Beispiele für vorgenommene Anpassungen und eine exemplarische Constraint-Generierung sollen dem Leser selbst einen Eindruck der Eignung von TGraphen vermitteln, bevor im Rahmen einer Diskussion die im Rahmen dieser Arbeit gesammelten Erfahrungen aus Entwicklersicht dargestellt werden. 1.1 Aufbau der Arbeit Nach dieser Einleitung werden im Kapitel 2. Der constraintbasierte Refaktorisierungsansatz zunächst die Grundideen des Einsatzes von Constraint-Systemen im Rahmen von Refaktorisierungen beschrieben. Es folgt eine detaillierte Spezifikation der sich ergebenden Anforderungen an die zu repräsentierenden Java-Fakten am Beispiel der Sichtbarkeitsconstraints. Das Kapitel 3. TGraphen zur Repräsentation von Java-Fakten beschreibt die allgemeinen Eigenschaften von TGraphen und erläutert, warum diese für die Repräsentation von SoftwareSystemen zum Zwecke der Programmanalyse geeignet erscheinen. Es wird eine Übersicht der wesentlichen Komponenten des vom IST bereitgestellten Frameworks zur Handhabung von TGraphen gegeben. In detaillierteren Darstellungen wird auf das für die Java-Repräsentation zur Verfügung stehende Metamodell und die Abfragesprache GReQL eingegangen. Im Kapitel 4. Identifikation der notwendigen Anpassungen werden die Anforderungen an den Informationsgehalt des TGraphen zur Generierung von Sichtbarkeitsconstraints mit den tatsächlich repräsentierten Informationen abgeglichen. Die Notwendigkeit zur Repräsentation einer 11 Information auf der Basis der Anforderungen der Sichtbarkeitsconstraints wird dabei wo immer möglich mittels der Java Language Specification belegt. Ist die jeweilige Information bereits in der gewünschten Form im TGraphen enthalten, so wird dies durch einen Verweis auf die hierfür im TGraphen zur Verfügung stehenden genutzten Knoten- und Kantentypen deutlich gemacht. Zu Beginn des Kapitels 5. Dokumentation der vorgenommenen Anpassungen wird ein detailliertes Beispiel gegeben, das die Vorgehensweise deutlich machen und einen Einblick in die Entwicklungsarbeit mit TGraphen geben soll. Die weiteren Abschnitte dieses Kapitels beschreiben die jeweils umgesetzten Lösungen. Das Kapitel 6. Exemplarische Constraint-Generierung mittels TGraph schlägt die Brücke zur eigentlichen Constraint-Generierung. Am Beispiel einer Constraint-Regel wird gezeigt, wie die Extraktion der hierfür erforderlichen Fakten aus dem angepassten TGraphen erfolgen kann. Die durchgeführten Implementierungsarbeiten werden im Kapitel 7. Diskussion aus Entwicklersicht bewertet. Zu den untersuchten Qualitätskriterien zählen die Verständlichkeit, die Benutzbarkeit und die Erweiterbarkeit sowie eine Einschätzung des Reifegrades des eingesetzten Frameworks. Zudem werden die Ergebnisse einiger Performance-Messungen für die Extraktion größerer BeispielProjekte dargestellt. Im Kapitel 8. Ausblick werden sowohl die kürzerfristig notwendigen Schritte wie auch die längerfristigen Perspektiven aufgezeigt, die sich ergeben, wenn der Ansatz weiter verfolgt werden soll. Das Kapitel 9. Zusammenfassung resümiert die Ergebnisse dieser Arbeit und gelangt zu einer abschließenden Einschätzung der Eignung von TGraphen als Fakten-Basis für constraintbasierte Refaktorisierungen. 12 2 Der constraintbasierte Refaktorisierungsansatz Mit der steigenden Komplexität von Software-Systemen haben auch die Anforderungen an die Werkzeuge zugenommen, die in der Software-Entwicklung eingesetzt werden. [MENS2004] weist in diesem Zusammenhang auf die Bedeutung von Refaktorisierungs-Werkzeugen hin und beschreibt wesentliche Qualitätskriterien, die für ihren Einsatz relevant sind. Wie [STEI2010] zeigt, existiert jedoch bis heute – im Gegensatz etwa zum Compilerbau – keine zufriedenstellende Theorie, welche als Grundlage für die Spezifikation von Refaktorisierungen und die darauf basierende Implementierung von Werkzeugen dienen könnte. Gängige Beschreibungen von Refaktorisierungen, wie sie z. B. in [FOWLER1999] gegeben werden, folgen zumeist einem imperativen Ansatz. Für jede Refaktorisierung werden eventuelle Vorbedingungen sowie die durchzuführenden Schritte aufgelistet, die eine erfolgreiche Refaktorisierung gewährleisten sollen. Als Problem hat sich dabei die Vielzahl der nötigen Fallunterscheidungen erwiesen, die erkannt und implementiert werden müssen, damit ein Refaktorisierungs-Werkzeug in allen denkbaren Konstellationen zuverlässig arbeitet. Gemäß [SCHÄFER2010-1] sind die auf diesem Ansatz basierenden Implementierungen häufig schwer zu verstehen und zu warten. Eine Alternative zu diesem imperativen Ansatz besteht in einer regelbasierten Herangehensweise, wie sie beispielsweise in [PEREZ2009] beschrieben wird. Dabei kann der Quelltext in eine Graphen-Repräsentation überführt werden, um die Refaktorisierung mittels Transformationsregeln auf dem Graphen umzusetzen. Die Transformationsregeln sind deklarativer Natur und sollen so die Probleme imperativer Ansätze vermeiden. Wie [STEI2010] zeigt, wurden in der Praxis zur Umsetzung dieser Regeln jedoch häufig umfangreiche prozedurale Komponenten eingesetzt, so dass der Unterschied zu imperativen Ansätzen an Bedeutung verlor. Der constraintbasierte Refaktorisierungsansatz ist ebenfalls deklarativer Natur. [TIP2007] stellt diesen Ansatz für einige Refaktorisierungen der Typen und Klassenhierarchien von JavaProgrammen vor. Er zeigt, wie durch die Einführung von Constraints die Typ-Korrektheit der refaktorisierten Programme gewährleistet werden kann. In [STEI2009] legen Steimann und Thies dar, wie dieser Ansatz zur korrekten Behandlung der Sichtbarkeits-Eigenschaft von Java-Elementen bei verschiedenen Refaktorisierungen eingesetzt werden kann. [STEI2010] schlägt den constraintbasierten Ansatz als mögliche theoretische Grundlage für den Bau von RefaktorisierungsWerkzeugen vor. In den folgenden Abschnitten wird der constraintbasierte Refaktorisierungsansatz zunächst allgemein, d. h. ohne den speziellen Bezug zu Sichtbarkeitsconstraints beschrieben. Die weiteren Abschnitte dieses Kapitels behandeln am Beispiel der Sichtbarkeitsconstraints, welche Anforderungen sich durch die notwendige Constraint-Generierung für die Repräsentation von JavaFakten ergeben. Abschließend wird gezeigt, welche Alternativen zur Repräsentation dieser Fakten bestehen und welche Probleme von diesen Ansätzen bislang nicht zufriedenstellend gelöst werden. 13 2.1 Grundideen und -begriffe 2.1.1 Variablen In einem constraintbasierten Ansatz werden Eigenschaften von Programmelementen in Form von Bedingungen (engl. constraints) beschrieben. Zur Repräsentation solcher Eigenschaften dienen Constraint-Variablen. So ist beispielsweise für Java-Programme die deklarierte Sichtbarkeit einer Methode eine solche Eigenschaft, die durch eine Variable ausgedrückt werden kann. Für eine konkrete Methode kann die deklarierte Sichtbarkeit festgestellt werden, indem der in der Deklaration der Methode verwendete Access-Modifier (public, protected, private oder kein Modifier) betrachtet wird. Ein weiteres Beispiel ist der Typ einer Variablen-Deklaration. Auch dieser Typ kann festgestellt und einer Constraint-Variablen als Wert zugewiesen werden. Die Änderung einer Variablenbelegung entspricht somit einer Programmänderung. Die Menge von Programmänderungen, die für eine Refaktorisierung durchgeführt werden soll, lässt sich umgekehrt als eine Menge geänderter Variablenbelegungen verstehen. Aus Constraint-Variablen entsteht ein Constraint, also eine Einschränkung der möglichen Variablenbelegungen, indem verschiedene Constraint-Variablen zueinander in Relation gesetzt werden. Die Art dieser Relationen wird im folgenden Abschnitt beschrieben. 2.1.2 Relationen und Constraint-Regeln Durch Relationen zwischen Constraint-Variablen kann ausgedrückt werden, dass die Programmänderungen, die durch eine Refaktorisierung durchgeführt werden, nicht beliebiger Art sein dürfen. Sie müssen vielmehr in Einklang mit der Java-Syntax stehen und dürfen über die gewünschte Refaktorisierung hinaus keinerlei Änderung der Programm-Semantik bewirken. Beispielsweise darf die Methode einer Subklasse, welche eine Methode ihrer Superklasse überschreibt, nicht weniger sichtbar sein als die überschriebene Methode. Dies lässt sich wie folgt ausdrücken: [Sichtbarkeit der Methode der Subklasse] ≥ α [Sichtbarkeit der Methode der Superklasse] In diesem Beispiel steht der ≥ α -Operator für die Relation der Sichtbarkeit der beiden Methoden. Das tiefgestellte α drückt dabei aus, dass es sich um eine Relation von Sichtbarkeits-Eigenschaften (engl. accessibility) handelt. Die beiden Sichtbarkeiten können einem konkreten Programm entnommen und in den obigen Ausdruck eingesetzt werden, wodurch sich z. B. die folgende konkrete Ausprägung ergeben könnte: public ≥ α protected Analog könnte eine Subtyp-Beziehung mittels T1 τ T2 dargestellt werden, um auszudrücken, dass T1 ein Subtyp von T2 ist. Das tiefgestellte τ zeigt an, dass es sich um eine typbezogene Relation handelt. Um aus diesem Ausdruck eine Constraint-Regel zu machen, müssen die konkreten Typen T1 und T2 durch Constraint-Variablen ersetzt werden. Beispielsweise muss der Typ einer Variablen, an die eine Zuweisung erfolgt, ein Subtyp oder identisch mit dem Typ des Ausdrucks sein, der auf der rechten Seite der Zuweisung steht. Dies lässt sich wie folgt ausdrücken: [Typ der Variablen, an die zugewiesen wird] ≤ τ [Typ des Ausdrucks auf der rechten Seite] 14 Für ein gegebenes syntaktisch korrektes Programm ist die durch solche Ungleichungen ausgedrückte Bedingung immer wahr. Für die Sichtbarkeiten wird dabei als Ordnungsrelation gemäß [JLS3] § 6.6.1 public > protected > default > private angenommen. Für die Subtypen-Beziehung gelten die Eigenschaften, die in [JLS3] § 4.10 spezifiziert sind. Würde eine Refaktorisierung dazu führen, dass die Sichtbarkeit der überschriebenen Methode auf private reduziert wird, so wäre hingegen die nachfolgend ausgedrückte Bedingung nicht mehr wahr. Die durchgeführte Refaktorisierung wäre demnach unzulässig. private ≥ α protected Welche Variablen und Relationen für eine Refaktorisierung zu einem gegebenen Programm erzeugt werden, hängt zum einen von den syntaktischen und semantischen Eigenschaften der Programmiersprache und zum anderen von den Anforderungen der jeweiligen Refaktorisierung ab. Für jede Refaktorisierung ist die Anwendung einer bestimmten Auswahl von ConstraintGenerierungs-Regeln (auch kurz Constraint-Regeln, engl. constraint rules genannt) relevant. Die Constraint-Regeln bilden somit den eigentlichen Kern des constraintbasierten Refaktorisierungsansatzes, indem mit ihrer Hilfe das System aus Variablen und Relationen erzeugt wird, das die Grundlage für die spätere Problemlösung bildet. 2.1.3 Constraints und Constrainterfüllung Ein Constraint stellt einen Ausdruck aus Variablen und Relations-Operatoren dar, der für eine Refaktorisierung aus einem gegebenen Programm generiert wurde. Ein Constraint ist somit spezifisch für ein Programm und eine Eigenschaft, die im Rahmen der Refaktorisierung bewahrt werden soll. Setzt man für ein syntaktisch korrektes Programm die konkreten Ausprägungen der Variablen in den Ausdruck ein, so ist der gesamte Ausdruck wahr. Man sagt dann auch, das Constraint sei für das Programm erfüllt (engl. constraint satisfaction). Die Menge aller generierten Constraints wird als Constraint-System (engl. constraint set) bezeichnet. Sind alle Constraints eines Constraint-Systems erfüllt, so wird im Folgenden das Constraint-System selbst als erfüllt bezeichnet. 2.1.4 Das Finden einer constrainterfüllenden Refaktorisierung Die Refaktorisierung muss so durchgeführt werden, dass nach dem Einsetzen der aus dem geänderten Programm ermittelten neuen Ausprägungen aller Constraint-Variablen das ConstraintSystem weiterhin erfüllt ist. Das Finden einer constrainterfüllenden Refaktorisierung kann jedoch auch umgekehrt erfolgen: Nach dem Aufbau des Constraint-Systems legt man die gewünschte Programmänderung fest und wendet dann einen Standardalgorithmus zur Lösung des ConstraintSystems an. Findet dieser eine Lösung, so wird diese anschließend auf Quelltext-Ebene zurückgeschrieben (engl. writing back the solution). Auf diese Weise können erprobte Algorithmen zum Einsatz kommen, die im Rahmen der constraintbasierten Programmierung entwickelt wurden (siehe z. B. [HOF2007]). In der Praxis gibt der Benutzer zunächst seine gewünschte Programmänderung vor und legt somit neue Ausprägungen für bestimmte Variablen des Constraint-Systems fest. Zusätzlich kann er ggf. festlegen, dass die Werte weiterer Variablen unverändert bleiben müssen. Sind diese Vorgaben gesetzt, so erledigt der Constrainterfüllungs-Algorithmus die weitere Arbeit. Dieser ist auch in der Lage, weitere Abhängigkeiten aufzulösen: Wenn etwa das Ändern einer Constraint-Variablen zu 15 einer Constraint-Verletzung führen würde, die nur durch Änderungen weiterer Variablen geheilt werden kann, so kann der Algorithmus diesen Prozess so lange fortsetzen, bis eine Lösung gefunden ist. Kann keine Lösung gefunden werden, so ist das gestellte Refaktorisierungs-Problem unlösbar. 2.2 Benötigte Java-Fakten für Sichtbarkeitsconstraints In der vorliegenden Arbeit wird die Brauchbarkeit von TGraphen zur Repräsentation von JavaFakten für einen constraintbasierten Refaktorisierungsansatz am Beispiel der Sichtbarkeitsconstraints untersucht. Es wird darauf verzichtet, die dort beschriebenen Constraint-Regeln nochmals formal vollständig wiederzugeben. Eine solche Zusammenfassung ist beispielsweise bereits in [PAS2011] erfolgt. Die textuellen Beschreibungen aus dieser Arbeit bilden auch die wesentliche Grundlage für den folgenden Abschnitt 2.2.1. Übersicht der Constraint-Regeln. Auf der Basis dieser Regeln erfolgt im Abschnitt 2.2.2. Eigenschaften von Deklarationen und Referenzen die Identifikation der Informationen, die zum Zwecke der Generierung von Sichtbarkeitscontraints effizient ermittelbar sein müssen. In den verbleibenden Abschnitten dieses Kapitels werden noch einige spezifische Faktentypen behandelt, die ggf. eine besondere Behandlung erfordern. 2.2.1 Übersicht der Constraint-Regeln Ausgehend von [STEI2009] wurden für die Constraint-Regeln Kurzbezeichner eingeführt, die ihren Ursprung in bestimmten Programmeigenschaften (wie z. B. Acc für Accessibility oder Inh für Inheritence) haben. Diese Kurzbezeichner werden im Rahmen der folgenden Übersicht eingeführt und im weiteren Verlauf der Arbeit referenziert, wenn auf bestimmte Constraint-Regeln verwiesen werden soll. • • • • • • Acc-1: Der Access-Modifier eines Deklarationselements muss gewährleisten, dass dieses Element für alle Referenzen, die sich auf es beziehen, sichtbar ist. Acc-2: Beim Zugriff auf als protected deklarierte nicht-statische Member oder Konstruktoren eines Typen T muss sichergestellt werden, dass ein paketübergreifender Zugriff nur durch Referenzen erfolgen darf, deren Typ eine Subklasse von T ist. Inh-1: Auf geerbte Elemente muss genauso wie auf entsprechende Elemente der Superklasse zugegriffen werden können. Inh-2: Diese Constraint-Regel behandelt den Sonderfall zweier statisch deklarierter Felder, deren unqualifizierter Name identisch ist. Bindet in einem solchen Fall eine Referenz an das erste dieser Elemente und ist der Deklarationsort des anderen Elements auch Deklarationsort einer der Superklassen der Referenz, so muss die Sichtbarkeit des ersten Elements größer sein als die kleinste nötige Sichtbarkeit, um von der Referenz aus auf das andere Element zugreifen zu können. Sub-1: Überschreibt oder verdeckt eine Methode die andere, so muss der Access-Modifier der einen größer oder gleich dem der anderen sein. Sub-2: Implementiert eine Klasse Methoden eines Interfaces, so müssen diese Methoden public deklariert sein. • Dyn-1: Eine überschriebene Methode der Superklasse muss in der Subklasse, in der sie • überschrieben wird, sichtbar sein. Nur dann kann eine dynamische Bindung entstehen. Dyn-2: Stehen zwei Methoden-Deklarationen bei (ggf. unter Berücksichtigung von Type Erasure) identischer Signatur nicht in einer Override-Beziehung, und ist der Deklarationsort 16 • der ersten Methode eine der Lokationen der Superklassen des Deklarationsortes der zweiten Methode, so muss die Sichtbarkeit der ersten Methode größer sein als die der zweiten. Andernfalls würde eine Override-Beziehung entstehen, welche dynamische Bindung ermöglicht. Abs: Abstrakte Methoden dürfen nicht private deklariert sein. • Ovr: Ist die Referenz auf eine Methoden-Deklaration auch potentiell Referenz einer zweiten Methoden-Deklaration, die im Sinne des statischen Bindealgorithmus von Java spezifischer (siehe [JLS3] § 15.12.2.5), aber aktuell von der Referenz aus nicht sichtbar ist, so muss eine Änderung der Sichtbarkeit jener zweiten Methoden-Deklaration sicherstellen, dass diese für die Referenz weiterhin unsichtbar bleibt. Ansonsten entstünde eine Overload-Beziehung, welche die Referenz statisch an die zweite statt an die erste Deklaration binden würde. 2.2.2 Eigenschaften von Deklarationen und Referenzen Aus den beschriebenen Constraint-Regeln lässt sich die Notwendigkeit zur Ermittlung bestimmter Eigenschaften von Deklarationen und Referenzen ableiten, die im Folgenden beschrieben werden. Bei diesen Eigenschaften handelt es sich um Mengen von Java-Elementen, die ausgehend von der jeweiligen Deklaration oder Referenz effizient ermittelbar sein müssen. Die folgenden beiden Tabellen korrespondieren mit den Tabellen im Kapitel 4.2. Abgleich der Eigenschaften von Deklarationen und Referenzen, in welchen die im TGraphen vorgefundene Information mit der hier geforderten abgeglichen wird. Eigenschaften von Deklarationen Access-Modifier static-Modifier für Variablen-Deklarationen abstract-Modifier für Methoden-Deklarationen Alle (auch implizite) Access-Modifier. Die Default-Sichtbarkeit (also ein fehlender Access-Modifier) muss dabei nicht explizit repräsentiert werden. Ebenso wenig ist für die Zwecke der vorliegenden Arbeit der in [STEI2009] beschriebene absent-Modifier zu repräsentieren. Der static-Modifier für Variablen-Deklarationen. Der abstract-Modifier für Methoden-Deklarationen. Identifier Alle Identifier, d. h. alle im Rahmen von Deklarationen verwendeten Bezeichner. Typen Alle Typen von Variablen, Rückgabetypen von Methoden, die Typen der formalen Methoden-Parameter sowie Ausprägungen von Typvariablen. Lokationen Alle Lokationen von Deklarationen, d. h. die Information darüber, an welcher Stelle im Sinne eines voll qualifizierten Pfades sich eine Deklaration befindet. Im Falle methodenlokaler Typdeklarationen ist zudem die Methode inklusive ihrer geordneten Liste der formalen Parameter in den voll qualifizierten Pfad einzubeziehen. Formale Parameterliste Die geordnete Liste der formalen Parameter für Methoden und 17 Eigenschaften von Deklarationen Konstruktoren. Supertyp-Beziehungen Der Supertyp jedes Typen, d. h. für jede Klasse die Superklasse und die implementierten Interfaces sowie für jedes Interface die Superinterfaces. Override-Beziehung Override-Beziehungen zwischen Methoden-Deklarationen. An der Override-Beziehung wird besonders deutlich, dass es nützlich sein kann, die eigentlich bereits in der Fakten-Basis verfügbare Information redundant, aber in effizient zugreifbarer Form zu repräsentieren. Denn mittels der Supertyp-Beziehung und der verfügbaren Methoden-Signaturen ließe sich die Override-Beziehung gemäß [JLS3] § 8.4.8.1 jeweils auch programmatisch ermitteln. Wird die Override-Beziehung jedoch bereits in der Fakten-Basis repräsentiert, entfallen solche Aufwände. Deklarations-Art Die Art der deklarierten Elemente. In Java können folgende Elemente deklariert werden: Klassen, Interfaces, Methoden, Konstruktoren, Variablen, Enums, Annotationstypen, Elemente von Annotationstypen und Typ-Parameter. Menge der TypParameter Die eventuelle Menge der Typ-Parameter bei Verwendung generischer Datentypen. Tabelle 1: Benötigte Eigenschaften von Deklarationen Eigenschaften von Referenzen Identifier Alle Identifier, mit denen Deklarationen referenziert werden. Lokationen Die Lokationen, an denen die Referenzen stehen. Es gilt dabei das für die Lokationen von Deklarationen Gesagte. Statische Bindungen Die Deklarationen, an die vom Compiler gebunden wird (statische Bindungen). Typ-Referenzen Referenzen auf Typen kommen in Java für folgende Elemente vor (Empfänger-Typen werden im folgenden Tabellen-Eintrag betrachtet): • • • • • Deklarationen von Methoden (Rückgabetyp, Typen der Methodenparameter) Deklarationen von Variablen Deklaration von Typparametern Deklaration von Arrays Angabe von Interface-Typen im Rahmen der implements- 18 Eigenschaften von Referenzen • • • Empfänger-Typ Klausel Angabe von Supertypen im Rahmen der extends-Klausel Angabe von Exception-Typen im Rahmen der throwsKlausel im Rahmen der Objekt- oder Array-Erzeugung mittels new Der Typ des Empfängers (engl. receiver) von Methoden-/KonstruktorAufrufen oder Feld-Zugriffen. Tabelle 2: Benötigte Eigenschaften von Referenzen 2.2.3 Implizite Quelltext-Elemente Über den explizit formulierten Quelltext hinaus enthalten Java-Programme eine Reihe impliziter Quelltext-Elemente. Diese sind u. a. in [JLS3] spezifiziert und werden vom Java-Compiler in den Java-Bytecode aufgenommen. Es handelt sich also um statische Quelltext-Eigenschaften, die somit auch Relevanz für Refaktorisierungen haben. An dieser Stelle wird nur eine kurze Übersicht gegeben. Eine detaillierte Beschreibung der für Sichtbarkeitsconstraints anzureichernden impliziten Elemente wird im Rahmen des Abgleichs der notwendigen Anpassungen im Kapitel 4.3. Repräsentation impliziter Quelltext-Elemente gegeben. • Implizite Modifier: Einige Deklarationsarten – insbesondere im Kontext von Interfaces – weisen implizite Modifier auf. So sind Interfaces immer abstract, ihre Methoden immer public und abstract. • Implizite Ableitungen: Alle Klassen, die nicht explizit eine andere Klasse ableiten, leiten implizit von Object ab. Alle Enum-Definitionen leiten implizit von Enum ab. • Implizite Konstruktor-Informationen: Ist in einer Klasse kein Konstruktor definiert, so wird in dieser der implizite Default-Konstruktor angenommen. Jeder Konstruktor, der nicht explizit seinen Superkonstruktor aufruft, ruft darüber hinaus implizit den parameterlosen Konstruktor der Superklasse auf. 2.2.4 Öffentliche Eigenschaften externer Bibliotheken Sind externe Bibliotheken (in Form von .class- oder .jar-Dateien, deren Quelltext nicht vorliegt) in ein Java-Programm eingebunden, so können Eigenschaften dieser Bibliotheken, die im Abschnitt 2.2.2. Eigenschaften von Deklarationen und Referenzen beschrieben wurden, relevant für eine Refaktorisierung sein. Die Deklarationen in diesen Bibliotheken sind potentielles Ziel für Referenzen oder Supertyp-Beziehungen. Referenzen in diesen Bibliotheken können potentiell, wenn auch weniger häufig, auf Deklarationen im eigenen Quelltext verweisen. 19 2.2.5 Rückreferenzierung des Quelltexts und Kommentare Sollen Änderungen des Java-Programms in den Quelltext zurückgeschrieben werden, so sind zunächst die zu ändernden Quelltext-Stellen dort aufzufinden, wo sie tatsächlich geändert werden sollen. Eine Änderung des Java-Programms innerhalb des TGraphen wäre zwar prinzipiell möglich, dann wäre allerdings auch ein formatierungsbewahrender Mechanismus zum Zurückschreiben der Änderungen erforderlich. Der Code-Generator für Java-Quelltext, der im Rahmen des GraBaJaProjekts implementiert wurde, verwirft jedoch die Formatierung und ist daher ohne weiteres Zutun nicht für diesen Zweck geeignet. Naheliegend ist daher die Vorgehensweise, den TGraphen lediglich für den Aufbau des Constraint-Systems zu nutzen, die berechneten Änderungen dann jedoch mit den Mitteln der Entwicklungsumgebung, für welche die Refaktorisierung implementiert wird, zurückzuschreiben. Bei einer Implementierung für Eclipse würde hierfür die Nutzung des abstrakten Syntaxbaums (engl. Abstract Syntax Tree, kurz AST) naheliegen, der von den in Eclipse integrierten Java Development Tools (siehe [URL:JDT]) bereitgestellt wird und der über eine entsprechende Rewrite-Funktionalität (siehe [URL:ASTREWRITER]) verfügt. Um diejenigen Elemente, die im AST geändert werden müssen, effizient auffinden zu können, wäre die Repräsentation einer Positionsinformation dieser Elemente hilfreich. Im Kontext der Rückreferenzierung des Quelltexts kann auch die Repräsentation von Kommentaren betrachtet werden. Da im Rahmen der Durchführung von Refaktorisierungen ggf. auch Bezeichner oder Pfade in Kommentaren angepasst werden sollen (dies wird von einigen RefaktorisierungsWerkzeugen über einen Preview-Dialog unterstützt), wäre es nützlich, die Kommentare ebenfalls im TGraphen zu repräsentieren. 2.3 2.3.1 Bisherige Ansätze zur Repräsentation der Fakten Repräsentation als Eclipse-AST Die Java Development Tools des Eclipse-Projekts stellen ein Framework zum Einlesen von JavaQuelltext in einen AST zur Verfügung, welches die Grundlage zahlreicher Werkzeuge der EclipseIDE ist, darunter auch einige der integrierten Refaktorisierungs-Werkzeuge. Der eingelesene AST repräsentiert das jeweilige Java-Projekt vollständig und korrekt und stellt eine etablierte API für Abfragen und Manipulationen zur Verfügung. Es verwundert daher nicht, dass diese Repräsentationsform auch gewählt wurde, um den constraintbasierten Refaktorisierungsansatz exemplarisch umzusetzen, so etwa in [KEG2007] und [STEI2009]. Dabei zeigten sich jedoch einige Nachteile: • • 2.3.2 Es bestehen nur unzureichende Möglichkeiten, den AST um Informationen anzureichern, die speziell für die Constraint-Generierung häufig benötigt werden. Einige Informationen erwiesen sich, obwohl prinzipiell im AST vorhanden, als nur umständlich oder ineffizient extrahierbar, da die Art der Abfragen, die für die ConstraintGenerierung genutzt wird, nur schwer über die API des AST abzubilden war. Erweiterte Faktenextraktion und Speicherung in Hashtabellen Die im vorherigen Absatz beschriebenen Probleme führten zu einer erweiterten Faktenextraktion auf der Basis des Eclipse-AST, welche die für die Constraint-Generierung wichtigsten Informationen in Form von Hashtabellen aufbaute und eine rudimentäre API zur Verfügung stellte, 20 um die jeweiligen Abfragen zu stellen. Als problematisch erwiesen sich bei diesem Ansatz das Laufzeitverhalten und der Speicherverbrauch. So dauerte die Faktenextraktion für einige Beispielprojekte mehrere Minuten und benötigte so viel Speicherplatz, dass diese Problemlösung für Refaktorisierungs-Werkzeuge als nicht praktikabel erscheint. Des Weiteren ist die genutzte API zum Stellen der Abfragen sehr spezifisch und müsste für weitere Constraint-Generierungen nach und nach ergänzt werden, was die Erweiterbarkeit des gesamten Ansatzes in Frage stellt. Auch das parallele Vorhalten von Informationen über den Java-Quelltext in zwei unterschiedlichen Datenstrukturen (AST und Hashtabellen) erscheint architektonisch als wenig elegant und würde künftige Erweiterungen erschweren. 2.3.3 Nutzung eines Java-Compilers In [EKMAN2008] weisen Ekman und Kollegen auf die Problemstellung hin, dass ein Großteil der Arbeit bei der Implementierung von Refaktorisierungen in der Analyse der Quelltext-Elemente besteht. Sie stellen fest, dass diese Analysen in vielerlei Hinsicht solchen Analysen ähneln, die in Compilern implementiert sind, und schlagen daher die Implementierung einer Refactoring-Engine auf der Basis eines erweiterbaren Compilers (JustAddJ, siehe [URL:JUSTADDJ]) vor. Sie zeigen, dass dieser Ansatz erfolgreich für die Refaktorisierungen „Rename“, „Extract Method“ und „Encapsulate Field“ funktioniert. Dieser Ansatz ist auch deshalb interessant, weil in weiteren Arbeiten dieser Forschungsgruppe, darunter [SCHÄFER2010-1], darauf hingewiesen wird, dass sich imperative Refaktorisierungsansätze als zu komplex und schwer wartbar erwiesen haben, weshalb dort eine abstraktere Spezifikationssprache vorgeschlagen und auf Basis der Compiler-basierten RefactoringEngine deren Funktionsfähigkeit exemplarisch gezeigt wird. Die Bewertung einer möglichen Nutzung des Compiler-basierten Ansatzes für den hier beschriebenen contraintbasierten Refaktorisierungsansatz vermag im Rahmen der vorliegenden Arbeit nicht geleistet zu werden. Die genannten Arbeiten legen nahe, dass diese Herangehensweise zumindest für die Extraktion der rein programmiersprachlichen Fakten durchaus tragfähig sein könnte. Allerdings ist anzumerken, dass ein Compiler ausschließlich sprachspezifische Eigenschaften unterstützen kann und in dieser Hinsicht weniger Flexibilität als ein TGraph-basierter Ansatz bietet. TGraphen ermöglichen grundsätzlich progammiersprachenübergreifende Repräsentationen und wären auch in der Lage, weitere Artefakte wie z. B. XML-Spezifikations-Dateien für Dependency Injection Container á la Spring oder EJB 3 zu verarbeiten, wie sie heute in produktiven Umgebungen häufig im Einsatz sind. 2.3.4 Weitere Graphen-basierte Ansätze [RENSINK2009] beschreibt die Konstruktion eines typisierten Graphen zur Repräsentation von Java-Programmen. Für den Aufbau des Graphen wird der Eclipse-AST genutzt. Der aufgebaute Graph ist zwar typisiert, ihm fehlen jedoch die für TGraphen geforderte Ordnung und Attributierung der Knoten und Kanten. Der resultierende Graph kann insgesamt als eine deutlich schlankere Version eines TGraphen angesehen werden, zumal die umfangreichen und ausgereiften Möglichkeiten des Graphenlabors weitgehend fehlen. Die genannte Arbeit unterstreicht daher lediglich den Bedarf für eine leistungsfähige Graphenrepräsentation von Java-Quelltext. 21 2.3.5 Sonstige Alternativen Im Artikel „A Generic System to Support Multi-Level Understanding of Heterogeneous Software“ aus [GUPRO1998] nennen Ebert und Kollegen einige weitere vorgeschlagene Alternativen zur Repräsentation von Software, ohne diese im Detail zu diskutieren: • • • • Relationale Datenbanken [CHEN1990] PROLOG-Datenbanken [JARZ1995] LISP images [WELLS1995] Hybride Wissensdatenbanken (engl. hybrid knowledge bases) [JARZ1995] Die von Ebert genannten Argumente, die gegenüber diesen Ansätzen für TGraphen sprechen, werden im Kapitel 3.8. Welche Vorteile können erhofft werden? wiedergegeben. Eine weitere Alternative, die im Rahmen der vorliegenden Arbeit nicht näher untersucht wurde, bildet das gemäß [URL:JTRANSFORMER] als query and transformation engine for Java source code bezeichnete JTransformer. Dieses arbeitet intern mit einer AST-Repräsentation auf Basis einer PROLOG-Datenbank. Ohne eingehendere Untersuchung können die Möglichkeiten dieses Werkzeugs gegenüber TGraphen allerdings nicht abgeschätzt werden. 2.3.6 Zusammenfassung der Probleme der bisherigen Ansätze Mit den bisherigen Lösungsansätzen zur Repräsentation von Java-Fakten konnte grundsätzlich die Funktionsfähigkeit des constraintbasierten Refaktorisierungsansatzes gezeigt werden, jedoch wiesen all diese Ansätze Probleme auf, welche einer Umsetzung in produktiven Entwicklungsplattformen und damit der in [STEI2010] beschriebenen Idee, zahlreiche oder gar alle RefaktorisierungsWerkzeuge einer IDE auf einer einheitlichen, constraintbasierten Infrastruktur aufzusetzen, im Wege stünden. Die in der vorliegenden Arbeit untersuchte Repräsentation von Java-Fakten mittels TGraphen wird sich daran messen lassen müssen, ob sie diese Probleme zu lösen imstande wäre. Deshalb werden diese Probleme hier nochmals kurz zusammengefasst: • • • • Abfrage von Information: Die Abfrage der benötigten Information muss entweder über umständliches Traversieren der bereitstehenden Datenstruktur (AST) oder über eine zu spezielle API erfolgen. Es existiert keine einheitliche Abfragesprache, welche allen bekannten und künftigen Constraint-Generierungen zu Grunde liegt. Anreicherung der Daten: Die Anreicherung der gewählten Datenstruktur mit zusätzlicher benötigter Information ist schwierig. Einheitliche Datenstruktur: Die Information wird mitunter in zwei unterschiedlichen Datenstrukturen vorgehalten. Performance: Die Faktenextraktion erweist sich als zu speicher- und zeitaufwändig. Inwieweit diese Probleme durch TGraphen vermieden werden können, wird im Abschnitt 3.8.1. Lösung der Probleme anderer Ansätze untersucht. Eine grobe Einschätzung der Performance von Faktenextraktionen für TGraphen gibt das Kapitel 7.3. Performance. 22 3 TGraphen zur Repräsentation von Java-Fakten 3.1 Bezeichnung TGraphen bestehen wie alle Graphen aus einer Knoten- und Kantenmenge sowie einer Inzidenzfunktion, welche jeder Kante ein Knotenpaar zuordnet. Der Begriff des „TGraphen“ wurde erstmalig in [EBERT1995] eingeführt. Das vorangestellte „T“ zeigt die Typisierung der Knoten und Kanten an. Auch wenn die besonderen Eigenschaften von TGraphen, die im folgenden Abschnitt beschrieben werden, rein formaler Natur sind und in diesem Sinne eine spezielle Graphenklasse im Sinne einer bloßen mathematischen Struktur kennzeichnen, wird der Begriff des „TGraphen“ bis heute ausschließlich im Kontext der Forschungs- und Entwicklungsarbeiten der Arbeitsgruppe um Ebert verwendet. Der Begriff ist daher weniger als anerkannter formal-mathematischer Fachbegriff zu verstehen, sondern vielmehr eine Art Markenname für die von Ebert und Kollegen zur Repräsentation von Software-Systemen eingesetzten Graphen und die dabei verwendeten Werkzeuge. 3.2 Formale Eigenschaften von TGraphen TGraphen weisen die folgenden formalen Eigenschaften auf: • • • • 3.3 Sie sind typisiert, d. h. jeder Knoten und jede Kante weist einen Typ auf. Sie sind attributiert, d. h. jeder Knoten und jede Kante kann über ein oder mehrere Attribute verfügen, die je nach Typ des Attributs unterschiedliche Ausprägungen annehmen können. Sie sind gerichtet, d. h. jede Kante verbindet einen Startknoten mit einem Endknoten. Sie sind in mehrfacher Hinsicht geordnet: Alle Knoten des gesamten Graphen bilden eine Reihenfolge. Alle Kanten des gesamten Graphen bilden eine Reihenfolge. Alle inzidenten Kanten zu einem Knoten bilden eine Reihenfolge. Beispiel für einen TGraphen Die folgende Abbildung zeigt drei dieser vier Eigenschaften: Abbildung 1: Einfacher Beispiel-TGraph 23 Dieser Beispiel-TGraph repräsentiert einen kleinen Ausschnitt aus dem Straßennetz. Die Knoten repräsentierten Städte und können unterschiedliche Typen wie „Landeshauptstadt“, „Stadt“ oder „Kleinstadt“ annehmen. Die Kanten repräsentieren verbindende Straßen der Typen „Autobahn“ und „Bundesstrasse“. Die Namen von Städten und Straßen werden über ein Attribut angegeben. Die Richtung der Kanten drückt sich in der Pfeilspitze aus (auf die Rückrichtung wurde hier jeweils verzichtet). Die Ordnung des Graphen ist der Abbildung nicht zu entnehmen und kann als interne Verwaltungsinformation betrachtet werden. 3.4 Repräsentation von Software-Systemen mittels TGraphen [EBERT2010] fasst zusammen, warum Graphen grundsätzlich zur Repräsentation von SoftwareSystemen geeignet sind: Jede Entität eines Software-Systems kann als Knoten dargestellt werden, während jede Beziehung zwischen diesen Entitäten durch eine Kante gebildet werden kann. Grundsätzlich ist die Art der Entität dabei nicht auf Quelltext-Elemente beschränkt, sondern kann auch weitere Artefakte wie etwa Dateien oder Testfälle umfassen, so dass Graphen eine leistungsfähige und programmiersprachenübergreifende Möglichkeit zur Modellierung von Software in unterschiedlichen Kontexten darstellen. Nutzt man zusätzlich die formalen Eigenschaften von TGraphen, so wird diese Darstellungsform gemäß [EBERT2002] noch leistungsfähiger : • • • • Durch Attribute können Knoten und Kanten mit zusätzlichen Informationen angereichert werden. Durch Typisierung von Knoten und Kanten können unterschiedliche Entitäten des Software-Systems auf einfache Weise voneinander unterschieden werden. Sie ermöglicht eine Modellierung, welche Entitäten zu welchen anderen Entitäten überhaupt in Beziehung stehen dürfen. Zudem lassen sich für unterschiedliche Entitäten unterschiedliche Attributmengen definieren. Gerichtete Kanten ermöglichen die präzisere Modellierung von Beziehungen zwischen Entitäten. Des Weiteren setzt eine Reihe effizienter Graphen-Algorithmen gerichtete Kanten voraus. Zu erwähnen ist jedoch an dieser Stelle, dass die Implementierung von TGraphen innerhalb des Graphenlabors, die nachfolgend noch ausführlich beschrieben wird, trotz gerichteter Kanten auch eine Traversierung in der jeweiligen Gegenrichtung einer Kante ermöglicht. Dies erleichtert die Entwicklungsarbeit mit TGraphen und ermöglicht auch den Einsatz von Algorithmen für ungerichtete Graphen. Durch eine definierte Ordnung lassen sich auf natürliche Weise Sequenzen (z. B. von Anweisungen, Parametern usw.) darstellen, die ansonsten weniger elegant über Positionsindizes oder andere Hilfsmittel realisiert werden müssten. Zudem ermöglicht die Ordnungseigenschaft ebenfalls die Implementierung deterministischer GraphenAlgorithmen. Damit stellen TGraphen aus formaler Sicht eine leistungsfähige Repräsentationsform beliebiger Software-Systeme dar. Sie sind nicht auf eine spezielle Programmiersprache oder überhaupt auf Quellcode beschränkt, sondern sind in der Lage, die Komplexität moderner Software-Systeme in einer einheitlichen, gut untersuchten Struktur darzustellen, die mit algorithmischen Standardverfahren behandelt werden kann. 24 3.5 Kurze Entwicklungsgeschichte Das Konzept einer auf TGraphen basierenden Modellierung nicht nur von Programm-Quelltext, sondern von Software-Systemen im Allgemeinen wurde erstmalig im Jahr 1995 von Ebert und Franzke in [EBERT1995] vorgestellt. Die Ausarbeitung dieses Konzepts erfolgte in den folgenden Jahren in Form eines „Graphenlabors“ (GraLab), welches u. a. ausführlich in Form eines Benutzerhandbuchs in [DAHM1998] dokumentiert wurde. Das Graphenlabor stellte für sich genommen eine leistungsfähige Schnittstelle zur Verwendung von TGraphen als Datenstruktur bereit und war in C++ implementiert. Im Rahmen der Diplomarbeit [KAHLE2006] wurde das Graphenlabor um eine in Java implementierte Version namens JGraLab ergänzt. Beide Versionen werden bis heute offiziell von der Arbeitsgruppe Ebert betreut. Aktuelle Weiterentwicklungen und Projekte werden jedoch ausschließlich auf Basis von JGraLab durchgeführt. Alle weiteren Ausführungen der vorliegenden Arbeit beziehen sich auf JGraLab. Parallel zur Entwicklung der konzeptionellen Grundlagen von TGraphen und der Implementierung des Graphenlabors war das IST ab Mitte der neunziger Jahre am Projekt GUPRO („Generische Umgebung zum Programmverstehen“) beteiligt, welches gemäß [EBERT1996] die programiersprachenübergreifende Entwicklung von Programmverstehens-Werkzeugen zum Ziel hatte. Dabei sollte die Repräsentation von Programm-Quelltexten möglichst flexibel erfolgen, um auch unvorhersehbare Analyseanforderungen mit minimalen Aufwand umsetzen zu können. GUPRO baute auf den Erfahrungen mit TGraphen auf und schuf u. a. eine Graphen-Repräsentation für COBOL. Dabei war der GUPRO-Ansatz allgemeinerer Natur: Es sollten nicht nur Programmiersprachen, sondern auch Jobkontrolltexte, Datenbankbeschreibungen und andere Dateiinhalte repräsentierbar sein. In GUPRO existiert daher das zentrale Konzept eines Repositories, in welchem die unterschiedlichen zu repräsentierenden Inhalte in einheitlicher Form vorgehalten und analysiert werden können. Dies zeigt die folgende Grafik aus [GUPRO1998]: Abbildung 2: GUPRO-Architekturschema 25 Während das eigentliche Projekt 1998 abgeschlossen war, wurden die daraus entstandenen Komponenten auch anschließend vom IST weiterentwickelt und um neue Komponenten ergänzt. Heute kommen gemäß [URL:GUPRO] insbesondere Graphen-Repräsentationen für C- und AdaProgramme zum Einsatz (siehe auch 3.8.4.Programmiersprachenübergreifende Refaktorisierungen). Da für GUPRO die analytischen Aspekte für die Repräsentation des Quelltexts im Vordergrund standen, wurde die Abfragesprache GReQL („GUPRO-Repository Query Language“) entworfen und auf der Basis von GraLab und JGraLab implementiert. Diese Arbeiten begannen mit [KAMP1996], die javabasierte Version wurde in [BILD2006] entworfen und in den folgenden Jahren ausimplementiert. GReQL erweitert somit das Graphenlabor um leistungsfähige AbfrageMöglichkeiten zur Analyse von TGraphen. Die Nutzung von TGraphen und des Graphenlabors für die Repräsentation von Java-Quelltext wurde im Rahmen der Studienarbeit [BALD2008] geleistet. Dort wird der eigentliche Faktenextraktor sowie das Metamodell für Java-Quellcode beschrieben. Diese Komponente wird heute unter der Bezeichnung GraBaJa („Graph Based Java“) am IST gewartet. 3.6 Architekturübersicht zu GraBaJa und dem Graphenlabor Für die Zwecke der vorliegenden Arbeit ist insbesondere die Repräsentation von Java-Quelltext relevant, die durch die GraBaJa-Komponente auf der Basis des Graphenlabors geleistet wird. Zudem ist die Abfragesprache GReQL von besonderer Bedeutung. Die folgende Abbildung veranschaulicht die wesentlichen Komponenten und ihre Zusammenhänge: Abbildung 3: Architekturübersicht GraBaJa / Graphenlabor 26 Die vom Graphenlabor angebotenen Funktionen, die im Rahmen dieser Arbeit genutzt werden, umfassen insbesondere folgende: • • • • Bereitstellung der Basisklassen, von denen alle speziellen Graphen-Implementierungen ableiten müssen, und damit auch der Basisfunktionen für die Implementierungsarbeit mit TGraphen. Ein Code-Generator zur Erzeugung der Graph-Klassen nach Anpassung des GraBaJaMetamodells. Im generierten Code werden insbesondere auch Factory- und SchnittstellenMethoden bereitgestellt, welche die Erzeugung und Verwendung neuer Knoten- und Kantentypen erleichtern. Utilities, insbesondere Export- und Konvertierungsfunktionen für das Abspeichern eingelesener Graphen in verschiedenen Datei-Formaten. Beispielsweise hat sich das DOTFormat (siehe [URL:DOT]) für die visuelle Untersuchung repräsentierter Programmfragmente als hilfreich erwiesen. Zu diesem Zweck steht auch ein TGraphBrowser zur Verfügung, mit dessen Hilfe in einem erzeugten TGraphen interaktiv navigiert werden kann. Die Möglichkeit zur Nutzung von GReQL-Abfragen, d. h. Parser, Auswerter und Optimierer für die GReQL-Abfragesprache. GraBaJa stellt für die Zwecke dieser Arbeit insbesondere folgende Funktionen bereit: • • 3.7 3.7.1 Das in einem speziellen Dateiformat spezifizierte Metamodell, welches die für JavaQuelltexte spezifischen Knoten- und Kantentypen sowie deren Beziehungen und Attribute beschreibt. Einen Faktenextraktor mit entsprechenden Schnittstellen-Methoden für das Einlesen von Dateien, um die TGraphen-Repräsentation eines Java-Projekts zu erzeugen. Die Interna des Faktenextraktors werden im Rahmen dieser Arbeit nicht modifiziert, da die Modifikation des TGraphen ausschließlich über Metamodell-Anpassungen und nachträgliche programmatische Anreicherungen erfolgt. Einige Eigenschaften im Detail Faktenextraktion Die Faktenextraktion für den TGraphen basiert im Wesentlichen auf einem mittels des Parsergenerators ANTLR auf Basis einer ausgewählten Javagrammatik erzeugten Parser (für Details zur Verwendung von ANTLR innerhalb des Faktenextraktors siehe [BALD2008], S. 12ff). Die Faktenextraktion ist ebenfalls in der genannten Arbeit im Kapitel „7. Funktionsweise des Javaextraktors“ ausführlich beschrieben. Zusammenfassend wird dabei ausgehend von einem mittels des generierten Parsers erzeugten AST ein TGraph aufgebaut, der zunächst nur die syntaktische Information des AST enthält. In weiteren Verarbeitungsschritten wird dieser TGraph um Dateiinformationen sowie einige Zusatzinformationen wie Variablenzugriffe und MethodenAufrufe ergänzt. Zudem werden ggf. einige weitere Informationen über die ReflectionFunktionalität von Java ermittelt und in den TGraphen integriert. 27 3.7.2 Metamodell Das Metamodell wird in einem speziellen Dateiformat definiert, das vom Graphenlabor vorgegeben ist. Die Spezifikationsdatei wird im Folgenden kurz als „Schemadatei“ bezeichnet. In der Terminologie von [BALD2008] wird der Begriff des Metamodells auf die UML-Repräsentation der Schemadatei angewendet. Diese Einschränkung soll hier nicht getroffen werden, da die Pflege der UML-Repräsentation grundsätzlich seit Abschluss der genannten Arbeit nicht konsequent fortgeführt wurde und nur mit einem speziellen kommerziellen Werkzeug möglich ist (siehe auch 3.9.1. Anpassung des Metamodells). In der vorliegenden Arbeit werden mit dem Begriff des Metamodells somit allgemeiner alle für einen TGraphen verwendbaren Knoten- und Kantentypen und deren Eigenschaften bezeichnet. Das spezielle Metamodell, das im Rahmen von GraBaJa entwickelt wurde, definiert alle Knoten und Kantentypen zur Repräsentation von Java-Quelltext, deren mögliche Attribute, ihre eventuelle Vererbungsbeziehung sowie die Richtung der Kanten. Details zum Entwurf des GraBaJaMetamodells sind im Kapitel „5.4 Eigenes Metamodell für Java 5“ sowie in „Anhang A. Metamodell der Graphklassen“ in [BALD2008] beschrieben. An dieser Stelle soll ein Einblick gegeben werden. Der durch das GraBaJa-Metamodell spezifizierte TGraph und seine Eigenschaften nach der Faktenextraktion wird im Folgenden sowie im weiteren Verlauf der Arbeit als „GraBaJa-TGraph“ bezeichnet. 3.7.2.1 Einfacher Beispiel-Quelltext Der folgende einfache Beispiel-Quelltext dient zur Veranschaulichung des Metamodells. Die Zeilen sind dateiübergreifend durchnummeriert. Die Zeilennummern werden bei der Beschreibung des TGraphen jeweils in Klammern referenziert. Da bereits simple Java-Programme wie dieses zu relativ komplexen Graphen führen, werden für unterschiedliche Teile des Metamodells in der Folge verschiedene Ausschnitte aus dem generierten TGraphen gezeigt. Datei Superklasse.java: 1 2 3 4 package testsources.not4autotests; class Superklasse { public void superklassenmethode() {} } Datei Subklasse.java: 5 package testsources.not4autotests; 6 class Subklasse extends Superklasse { 7 void subklassenmethode() { 8 superklassenmethode(); 9 } 10 } 28 3.7.2.2 Programmwurzel und Dateibezug Der folgende Ausschnitt zeigt die Verankerung des Java-Programms im Dateisystem. Es wird nur die Repräsentation von Superklasse.java gezeigt. Abbildung 4: Metamodell: Programmwurzel und Dateibezug Jeder GraBaJa-TGraph enthält einen Program-Knoten, von dem aus sich der Bezug zum Dateisystem aufspannt. Über die Abstraktion TranslationUnit sind die geparsten Dateien (SourceFile) und ihre Verwender (SourceUsage) in den Graphen eingebunden. Letztere bilden die Brücke zum eigentlichen Java-Quelltext. Dem Program-Knoten ist auch die Paket-Hierarchie (JavaPackage) zugeordnet. 29 3.7.2.3 Typ- und Methoden-Definitionen Abbildung 5: Metamodell: Typ und Methoden-Definitionen Typ- und Paket-Definitionen sind über eine IsExternalDeclarationIn-Kante an das Dateisystem angeknüpft. Die PackageDefinition (Zeile 1) ordnet der Datei das Paket zu, dem sie angehört. Die in diesem Beispiel definierte Klasse beginnt mit dem Knoten ClassDefinition (Zeile 2) und weist einen Block (Zeilen 2 bis 4) auf. In diesem sind die Member der Klasse über IsMemberOf-Kanten referenziert. Das Beispiel enthält lediglich eine MethodDefinition (Zeile 3). 30 3.7.2.4 Subtyp-Beziehungen und Methoden-Aufrufe Abbildung 6: Metamodell: Subtyp-Beziehungen und Methoden-Aufrufe Subtyp-Beziehungen zwischen Klassen werden über eine IsSuperClassOfClass-Kante (Zeile 6) repräsentiert. Für die Beziehungen zwischen Klassen und Interfaces sowie zwischen Interfaces und Interfaces existieren analoge Kantentypen (IsInterfaceOfClass, IsInterfaceOf). Für Methoden-Aufrufe existiert der Knotentyp MethodInvocation (Zeile 8). Dieser wird durch eine Kante des Typs IsDeclarationOfInvokedMethod an einen Knoten des Typs MethodDefinition geknüpft. Dieser Kanten-Typ wird im Kapitel 4.5. Repräsentation statischer Bindungen ausführlich untersucht. 31 3.7.2.5 Rückreferenzierung des Quelltexts Zur Rückreferenzierung von TGraphen-Instanzen auf den ursprünglichen Quelltext existieren im TGraphen zwei Attribute an jeder Kante: Ein line-Attribut gibt die Zeile des jeweiligen QuelltextElements innerhalb der TranslationUnit an, in welcher das Element enthalten ist. Und ein offset-Attribut gibt die Anzahl der Zeichen an, die das jeweilige Element vom Dateibeginn entfernt steht. Für die Klasse package testsources.not4autotests; public class EinfacheKlasse { } wird der folgende TGraph generiert, dessen Kanten-Attribute hier mit ausgegeben werden (was aus Platzgründen bei den anderen TGraph-Abbildungen bisher nicht der Fall war): Abbildung 7: line- und offset-Attribute von Kanten Bei Änderungen des TGraphen bleiben diese Attribute (wenn sie nicht explizit modifiziert werden) unverändert und spiegeln somit die Positionsinformation der Elemente im ursprünglichen Zustand wider. Diese kann etwa genutzt werden, um die entsprechenden Elemente im Eclipse-AST aufzufinden, der ebenfalls eine Offset-Information verwaltet (siehe hierzu die Methode getSourceRange() in [URL:ISOURCEREF]). 32 Anmerkung: Zählt man für das obige Beispiel den Offset, d. h. die Anzahl der Zeichen vom Dateibeginn bis beispielsweise zum public-Modifier, so stellt man eine Abweichung fest: Während der TGraph 38 Zeichen zählt, so kommt man durch manuelles Zählen lediglich auf 36 Zeichen – jedenfalls dann, wenn man auf einem Windows-Betriebssystem arbeitet und die JavaDatei dort erzeugt hat. Dieser Unterschied ergibt sich daraus, dass die Funktion zur Berechnung des Offsets für den Zeilenumbruch die tatsächlich codierten Zeichen zählt. Unter Windows sind dies jedoch zwei Zeichen (carriage return und line feed), während es beispielsweise unter Unix nur eines (line feed) ist. Generiert man Java-Datei und TGraph unter Unix, so wird als Offset tatsächlich 36 berechnet. 3.7.3 Die Abfragesprache GReQL 3.7.3.1 Bezeichnung, Komponenten und Geschichte Der Name „GReQL“ leitet sich aus der Langbezeichnung „GUPRO-Repository Query Language“ ab. Als Teil des Graphenlabors existiert von GReQL eine C++-Implementierung und eine als „GReQL 2“ bezeichnete Java-Implementierung. Da im Rahmen der vorliegenden Arbeit die JavaKlassenbibliothek genutzt wird, ist mit „GReQL“ immer die Java-Version GReQL 2 gemeint. Zentrale Komponenten von GReQL sind der Parser, der Auswerter, der Optimierer und eine Funktionsbibliothek. Zudem existieren Container-Klassen für eine einheitliche Behandlung (der Typen) von GReQL-Ergebnissen. GReQL wurde gemäß [KAMP1996] bereits für die ersten Versionen des Graphenlabors entwickelt und basiert auf der Graphen-Spezifikationssprache GRAL („Graph Specification Language“, siehe [URL:GRAL]). Diese wurde ebenfalls von Ebert und Kollegen auf Grundlage der sogenannten „ZNotation“ (siehe [URL:Z]) entwickelt, einer Spezifikationssprache, die bereits seit 1977 an der Universität Oxford ausgearbeitet wurde. Die Spezifikation von GReQL 2 erfolgte erstmalig in [MAR2006], die Implementierung des Auswerters in [BILD2006] und die des Optimierers in [HORN2008]. 3.7.3.2 Einblick in die Syntax Die Syntax von GReQL ist angelehnt an SQL. Dem GReQL-Auswerter wird eine Instanz des abgefragten TGraphen sowie die GReQL-Abfrage als Zeichenkette übergeben. Als Ergebnis erhält man die Instanz einer Containerklasse, die das Interface JValue implementiert. Einige dieser Containerklassen implementieren zusätzlich Iterable und stellen Ergebnismengen dar. Welchen Container-Typen man erhält, hängt von der Formulierung der Abfrage ab. 3.7.3.2.1 Ausdrücke Es existieren eine Vielzahl möglicher Ausdrucksformen: arithmetische Ausdrücke, Funktionsaufrufe, Schleifen, Attributzugriffe usw. Beispiele hierfür sind (je Zeile): true - 2 3 + 4 E // alle Kanten 33 V{ClassDefinition!} from e:E with mutable == true reportSet e end // alle veraenderlichen // Kanten als Set Um Ausdrücke, die keine Abfrage an einen TGraphen darstellen, auswerten zu lassen, kann der GReQL-Auswerter auch ohne TGraphen-Instanz zu einer Evaluierung veranlasst werden: GreqlEvaluator eval = new GreqlEvaluator("3 + 4", null, null); eval.startEvaluation(); int i = eval.getEvaluationResult().toInteger(); // Zuweisung von 7 an i 3.7.3.2.2 from-with-report-Ausdrücke Für die Abfrage eines gegebenen TGraphen ist der from-with-report-Ausdruck die wichtigste Ausdrucksform. Dabei besteht eine Abfrage gemäß [URL:GREQL] aus bis zu drei Teilen: einer from-Klausel, einer with-Klausel und einer report-Klausel. Zunächst werden in der from-Klausel Variablen und ihre Wertebereiche deklariert. Diese Deklaration erfolgt in der Syntax <Variablenname>:<Wertebereich> nach dem from-Schlüsselwort. Innerhalb einer from-Klausel können mehrere solche Deklarationen durch Kommata separiert werden. Der optionale zweite Abschnitt formuliert in einer with-Klausel die Bedingungen auf diesen Variablen. Dabei sind insbesondere Pfadbeschreibungen in Form regulärer Ausdrücke (regular path expressions, siehe [GREQLREF]) als Bedingungen relevant – auf diese wird im folgenden Abschnitt näher eingegangen. Schließlich beschreibt eine reportKlausel die Ausgabe. Dabei existieren unterschiedliche Varianten des report-Schlüsselworts: Neben report können u. a. auch reportSet oder reportMap verwendet werden. Durch diese Wahl wird der Container-Typ des Ergebnisses beeinflusst. 3.7.3.2.3 Pfadbeschreibungen als reguläre Ausdrücke Die Formulierung der Pfadbeschreibungen innerhalb des TGraphen erfolgt mittels regulärer Ausdrücke. In diesen können neben gewöhnlichen Ausdrücken auch Kantensymbole und die Kleene-Operatoren * und + verwendet werden. Als Kantensymbole werden dabei Pfeilausdrücke der Art --> (ausgehende Kante), <-- (eingehende Kante), <-> (Kante ohne bestimmte Richtung) oder --exp-> (genau eine Kante, die dem Ausdruck exp entspricht) verwendet. Die KleeneOperatoren werden auf eine solche Pfadbeschreibung angewandt und stehen wie bei regulären Ausdrücken üblich für die beliebig häufige (bei + mindestens einmalige) Iteration des beschriebenen Pfades. Ist eine fixe Anzahl von Iterationen gesucht, so kann diese über <Pfadbeschreibung>^n ausgedrückt werden, wobei n für diese Anzahl steht. Für Start- und Endknoten kann zudem eine Restriktion in Form von {<Knotentyp>} angegeben und mit einem &-Symbol an die Pfadbeschreibung geknüpft werden: <Pfadbeschreibung> & {<Knotentyp>} beschreibt alle Pfade, auf welche die <Pfadbeschreibung> zutrifft und deren Endknoten vom Typ <Knotentyp> ist. Zu beachten ist, dass eine solche Pfadbeschreibung eine 34 Menge liefert und daher noch nicht zur Verwendung in einer with-Klausel taugt. Sie kann allerdings verwendet werden, um den Wertebereich einer Variablen innerhalb der from-Klausel zu definieren. 3.7.3.2.4 Beispiel einer Abfrage an den TGraphen Im folgenden Beispiel werden alle Klassen-Definitionen gesucht, die ein Interface implementieren: from c:V{ClassDefinition}, i:V{InterfaceDefinition}, t:E{IsTypeDefinitionOf} with c <--* <-t-- i reportSet c end Der reguläre Ausdruck c <--* <-t-- i bildet den Kern dieser Abfrage. Die Klassen-Definition wird durch die Variable c vertreten. Zu dieser dürfen beliebig viele eingehende Kanten eines beliebigen Typs führen. Dies wird durch <--* ausgedrückt. Durch den Teilausdruck <-t-- i wird gefordert, dass irgendwo im Pfad eine IsTypeDefinitionOf-Kante vorkommt (repräsentiert durch die Variable t), die von einer InterfaceDefinition (Variable i) weg zeigt. Dies kann nur dann der Fall sein, wenn die Klassen-Definition entweder direkt oder über eine ihrer Superklassen ein Interface implementiert. An dieser Stelle sollte ein Einblick in die Formulierung von GReQL-Abfragen gegeben werden. Die Sprache ist sehr viel umfangreicher als es an dieser Stelle erschöpfend dargestellt werden kann. Auf umfassendere Dokumentationen wird im Kapitel 3.10. Weiterführende Informationen hingewiesen. 3.8 3.8.1 Welche Vorteile können erhofft werden? Lösung der Probleme anderer Ansätze Im Kapitel 2.3. Bisherige Ansätze zur Repräsentation der Fakten wurden einige Alternativen zur Verwendung von TGraphen für die Repräsentation von Java-Fakten beschrieben. Wie sich dort unter 2.3.6. Zusammenfassung der Probleme der bisherigen Ansätze gezeigt hat, waren diese Ansätze mit verschiedenen Problemen verbunden. TGraphen bieten Lösungen für eine Reihe dieser Probleme an: • • • Abfrage von Information: Für die Abfrage von Information aus TGraphen steht die Abfragesprache GReQL zur Verfügung, die über eine konsistente und erprobte Syntax verfügt und sehr effizient arbeitet. Anreicherung der Daten: Die Anreicherung des TGraphen ist problemlos möglich. Die Erzeugung neuer Graphen-Elemente (Knoten oder Kanten) erfolgt auf einheitliche Weise über Factory-Methoden. Handelt es sich um gänzlich neuartige Informationen, so ist ggf. eine Anpassung des Metamodells des TGraphen erforderlich, die in einer hierfür vorgesehenen Spezifikationsdatei erfolgt. Die vorliegende Arbeit liefert eine Reihe von Beispielen für derartige Anreicherungen. Einheitliche Datenstruktur: Die gesamte über den Java-Quelltext benötigte Information 35 • 3.8.2 wird in einer einheitlichen und konsistenten Datenstruktur vorgehalten. Die Elemente dieser Datenstruktur sind entsprechend dem eingesetzten Metamodell typisiert und bieten somit eine intuitiv verständliche Schnittstelle zum repräsentierten Quelltext an. Performance: TGraphen gelten als laufzeit- und speichereffizient sowohl im Rahmen der Faktenextraktion als auch bei Abfragen über die integrierte Abfragesprache GReQL (siehe z. B. [KAHLE2006] S. 82ff). Eine Performance-Messung für einige Beispiel-Projekte wird im Kapitel 7.3. Performance vorgestellt. Einige formale Vorteile Ebert und Kollegen nennen im Artikel „A Generic System to Support Multi-Level Understanding of Heterogeneous Software“ aus [GUPRO1998] eine Reihe formaler Vorteile, von denen die wichtigsten an dieser Stelle zusammengefasst werden: • • • 3.8.3 Graphen als Standard-Formalismus: Graphen sind allgemein ein wohlverstandener Formalismus, der mit effizienten Standard-Algorithmen ausgestattet ist. Z-Notation als Grundlage: TGraphen liegt ein formal ausgearbeitetes Konzept zu Grunde, welches auf einer Spezifikation in Z-Notation basiert (siehe auch 3.7.3.1. Bezeichnung, Komponenten und Geschichte). Ebert und Kollegen betrachten dies als Grundlage für konsistent entwickelte Werkzeuge, die auf dem Graphen-Repository arbeiten sollen. Formale Spezifikation des Metamodells: Es liegt eine formale Spezifikation des Metamodells für jede Graphen-Implementierung vor, welche die Implementierung von darauf basierenden Refaktorisierungs-Werkzeugen unterstützt. Speziell für das Thema dieser Arbeit bedeutet dies, dass jeder Entwickler von Refaktorisierungs-Werkzeugen für JavaQuelltext, die auf TGraphen arbeiten sollen, eine vollständige und als UMLKlassendiagramm exportierbare Dokumentation des Metamodells nutzen kann. Eignung für programmanalytische Aufgaben Die TGraphen des Graphenlabors wurden speziell konstruiert, um programmanalytische Aufgaben damit bewältigen zu können. So sind TGraphen gemäß [EBERT1995] daraufhin angelegt, nicht nur sprachsyntaktische, sondern auch zusätzliche Informationen über Software-Systeme aufnehmen zu können. Dies unterscheidet TGraphen prinzipiell auch von abstrakten Syntaxbäumen (oder -graphen), die historisch eine generische, insbesondere im Compilerbau genutzte Repräsentation der bloßen Sprachsyntax darstellen. Die Ausrichtung auf analytische Einsatzzwecke zeigt sich auch bei der aufwändig integrierten Abfragesprache GReQL. Diese bietet mächtige Analysemöglichkeiten, die weit über die Programmierschnittstelle gewöhnlicher Datenstrukturen hinausgehen. 3.8.4 Programmiersprachenübergreifende Refaktorisierungen [STEI2010] beschreibt auch die Möglichkeit programiersprachenübergreifender Refaktorisierungen. TGraphen würden hierfür eine geeignete Grundlage liefern, da sie grundsätzlich ebenfalls programmiersprachenübergreifend konstruiert sind. So bietet das Repository-Konzept von TGraphen (siehe Grafik im Kapitel 3.5. Kurze Entwicklungsgeschichte) bereits eine Infrastruktur zur Handhabung mehrerer Graphenrepräsentationen an. 36 In diesem Kontext könnte auch die Idee eines Referenz-Metaschemas interessant sein, die in [WINTER2000] vorgestellt wird. So wäre es denkbar, verschiedene objektorientierte Programmiersprachen in einem gemeinsamen Metaschema zu repräsentieren, von welchem die programmiersprachenspezifischen Schemata abgeleitet werden. Dies würde es beispielsweise ermöglichen, GReQL-Abfragen auf Typen des Metaschemas zu formulieren und somit AnalyseKomponenten zu entwickeln, die unabhängig von einer konkreten Sprache sind. Die Möglichkeit zur Repräsentation von Information, die über die Syntax einer speziellen Programmiersprache hinaus geht, würde auch die Repräsentation weiterer Nicht-Java-Dateien ermöglichen, so z. B. Spezifikationsdateien von Dependency Injection Containern wie Spring, EJB 3 oder JSF. Da in diesen Dateien u. a. auch Typ-Bezeichner und Paketpfade enthalten sind, entsteht bei Refaktorisierungen, die zu Umbenennungen oder Verschiebungen führen, häufig ein manueller Zusatzaufwand. Auf Basis von TGraphen könnten die Inhalte solcher Spezifikationsdateien repräsentiert, abgefragt und im Rahmen einer Refaktorisierung modifiziert werden. 3.9 Vorgehensweise bei Anpassungen im TGraphen Die erweiterte Java-Faktenextraktion, die im Rahmen dieser Arbeit für TGraphen implementiert wurde, lässt sich grob in Änderungen des Metamodells zur Build-Zeit und Änderungen am generierten TGraphen zur Laufzeit unterteilen. Dieses Kapitel soll einen Überblick der wichtigsten Entwicklungstätigkeiten gegeben, die im Rahmen dieser Modifikationen durchgeführt wurden, um evtl. künftigen Autoren und Entwicklern, die auf der vorliegenden Arbeit aufbauen wollen, einen schnellen Einstieg zu ermöglichen. Das folgende Diagramm gibt eine Übersicht des Workflows, der im Rahmen der Entwicklungsarbeit beim Hinzufügen neuer Informationen durchlaufen wird. 37 Abbildung 8: Workflow bei der Umsetzung von TGraph-Anpassungen Zu Beginn ist abzuwägen, ob die gewünschte neue Information adäquat durch das bestehende Metamodell repräsentiert werden kann. Die im Metamodell verfügbaren Knoten- und Kantentypen stellen die Entitäten dar, aus denen der Graph aufgebaut wird. Ist zu ergänzende Information neuartig und kann durch bestehende Knoten- und Kantentypen oder Attribute nicht oder nur umständlich abgebildet werden, so ist eine Anpassung des Metamodells in der Datei java5.tg erforderlich (siehe 3.9.1. Anpassung des Metamodells). Nachdem dort die gewünschten Anpassungen vorgenommen und ein Build des GraBaJa-Projekts durchgeführt wurden, sind die Informationen zur Laufzeit in den generierten TGraphen aufzunehmen. Dies könnte durch eine Anpassung des GraBaJa-Faktenextraktors geschehen. Da sich dieser jedoch als problematisch erwiesen hat (siehe 7.2.2. Wartbarkeit des Faktenextraktors), wurden alle zur Laufzeit vorzunehmenden Anpassungen im Rahmen dieser Arbeit nach erfolgter Faktenextraktion umgesetzt. Innerhalb der GraBaJa-Ressourcen wurde für diese Arbeit ausschließlich das Metamodell, also die Datei java5.tg angepasst. Die Anpassungen nach Faktenextraktion sind meist eine Abfolge von 38 Informationssuche im Graphen (siehe 3.9.2.1. Traversieren und Abfragen sowie 3.7.3. Die Abfragesprache GReQL) und dem Erzeugen neuer Knoten und Kanten (siehe 3.9.2.3. Erzeugen von Knoten und Kanten) oder dem Setzen von Attributen (siehe 3.9.2.2. Ändern von Attributwerten). 3.9.1 Anpassung des Metamodells Durch das Metamodell wird festgelegt, welche Knoten- und Kantentypen im TGraphen verfügbar sind und in welchen Beziehungen diese zueinander stehen. Eigenschaften und Beispiele des GraBaJa-Metamodells wurden in Abschnitt 3.7.2. Metamodell beschrieben. Sollen neuartige Informationen in den TGraphen aufgenommen werden, so ist hierfür in der Regel eine Anpassung des Metamodells sinnvoll. In [BALD2008] ist davon die Rede, dass die Modelländerungen in UML durchgeführt und per Modelltransformation in die Schemadatei übertragen werden. Dies ist grundsätzlich auch mittels des kommerziellen Werkzeugs „Rational Software Architect“ (RSA) möglich, über welches sich ein Export in das XMI-Format erzeugen lässt, das wiederum in das Format der Spezifikationsdatei konvertiert werden kann. Dieser Weg erscheint jedoch in Anbetracht des recht intuitiv verständlichen Dateiformats als umständlich und ist zudem nicht allgemein zugänglich, da das genannte Werkzeug kostenpflichtig lizenziert werden muss. Nur nebenbei sei bemerkt, dass auch für die umgekehrte Transformation der Schemadatei in das XMI-Format des RSA im Graphenlabor entsprechende Konvertierungsfunktionen zur Verfügung stehen. Die GraBaJa-Schemadatei ist im GraBaJa-Entwicklungsprojekt unter dem Namen java5.tg abgelegt. Nach der Modifikation dieser Datei ist für das GraBaJa-Projekt ein Ant-Build auszuführen. Zu diesem Zweck wird das build-Target des Ant-Builds ausgeführt, der in der build.xml-Datei des GraBaJa-Projekts spezifiziert ist. Der Build erzeugt eine neue grabaja.jarDatei, die in das eigene Entwicklungsprojekt zu integrieren ist. Zwei Arten von Metamodell-Anpassungen werden im Folgenden ausführlicher beschrieben: • • die Ergänzung von Attributen zu existierenden Typen die Aufnahme neuer Knoten- und Kantentypen 3.9.1.1 Ergänzung von Attributen zu existierenden Typen 3.9.1.1.1 Typen für Attribute Eine der formalen Eigenschaften von TGraphen besteht darin, dass alle Knoten und Kanten attributiert sind (siehe 3.2. Formale Eigenschaften von TGraphen). Durch Attribute können Knoten und Kanten auf einfache Weise um zusätzliche Informationen ergänzt werden. Grundsätzlich kann jedes Attribut in der Schemadatei einen der folgenden Typen annehmen: (1) Boolean, (2) Integer, (3) Long, (4) Double, (5) String, (6) Set<?> (wobei ? ein beliebiger weiterer TGraph-Typ sein darf), (7) List<?>, (8) Map<?,?>, (9) definierte Enums und (10) definierte Records. 39 Die Typen (1) bis (8) sind selbsterklärend. Zu beachten ist, dass es sich hier um TGraph-Typen handelt und nicht um Java-Typen. Definierte Enums sind ihrerseits in der Schemadatei definiert. So handelt es sich beispielsweise bei MethodInvocationTypes um ein solches Enum, das wie folgt definiert ist: EnumDomain MethodInvocationTypes( METHOD, CONSTRUCTOR, SUPERMETHOD, SUPERCONSTRUCTOR, EXPLICITCONSTRUCTOR ) ; Mittels des Schlüsselworts EnumDomain können beliebige weitere Enum-Typen definiert werden, mit denen dann Attribut-Deklarationen in der Schemadatei versehen werden können. Analog zu EnumDomain können mittels RecordDomain Records in Analogie zu Pascal definiert werden. Dieser Mechanismus wird aktuell nur selten genutzt und daher hier nicht ausführlicher beschrieben. 3.9.1.1.2 Ergänzung der Attributliste eines Typs Knoten- und Kantentypen sind in der Schemadatei als VertexClass bzw. EdgeClass definiert. Am Beispiel des Knotentyps MethodInvocation soll die Ergänzung eines Attributs gezeigt werden. MethodInvocation ist in der aktuellen Schemadatei wie folgt definiert: VertexClass MethodInvocation : Expression { type : MethodInvocationTypes } ; MethodInvocation verfügt bereits über ein Attribut namens type. Dieses ist seinerseits typisiert durch den wie oben definierten Enum-Typ MethodInvocationTypes. Eine Erweiterung der MethodInvocation um ein Boolean-Attribut sähe also wie folgt aus: VertexClass MethodInvocation : Expression { implicit : Boolean, type : MethodInvocationTypes } ; 3.9.1.2 Ergänzung neuer Knoten- oder Kantentypen Die Ergänzung neuer Knoten- oder Kantentypen erfolgt durch entsprechende VertexClass- oder EdgeClass-Definitionen in der Schemadatei. Dabei kann ein Supertyp angegeben werden, dessen Eigenschaften geerbt werden. Ein Beispiel für eine solche Supertyp-Beziehung zeigt die Deklaration der MethodInvocation im vorhergehenden Abschnitt, die von Expression ableitet. Dies ermöglicht beispielsweise die Nutzung von Supertypen in GReQL-Abfragen: Alle Ausdrücke lassen sich durch eine einzige Suche nach dem Knotentyp Expression im TGraphen finden. Nach einem Build des GraBaJa-Projekts sind die definierten Typen für den TGraphen verfügbar. 40 3.9.2 Modifikation des generierten TGraphen Ein generierter GraBaJa-TGraph ist eine Instanz des Typs Java5 (auf die Angabe voll qualifizierter Typen wird hier verzichtet, wenn die Bezeichner innerhalb des GraBaJa-Projekts eindeutig sind). Um eine solche Instanz zu erzeugen, kann beispielsweise die GraphBuilder-Klasse verwendet werden, welche entsprechende Methoden zum Parsen von Java-Dateien und zum Erzeugen des TGraphen bereitstellt. Mittels der getGraph()-Methode kann vom GraphBuilder die erzeugte Java5-Instanz bezogen werden. Diese dient als Ausgangspunkt für alle Operationen auf dem erzeugten Graphen. In den folgenden Abschnitten werden die Basisoperationen beschrieben, die bei der Entwicklungsarbeit mit TGraphen benötigt werden. 3.9.2.1 Traversieren und Abfragen Im Abschnitt 3.7.3. Die Abfragesprache GReQL wurde bereits ausführlich auf GReQL eingegangen. Das Graphenlabor bietet über GReQL hinaus verschiedene Möglichkeiten an, um durch den TGraphen zu traversieren oder bestimmte Knoten und Kanten zu finden. In den folgenden Abschnitten werden verschiedene Schnittstellen-Methoden beschrieben, die für die Traversierung oder für das Absetzen von GReQL-Abfragen eingesetzt werden können. Grundsätzlich gilt dabei, dass Methoden, die nicht zu einem Aufruf des GReQL-Auswerters führen, effizienter arbeiten und daher bevorzugt werden sollten. Die folgenden Beispiele sind z. T. leicht modifiziert aus [KAHLE2006] (S. 150ff) übernommen. 3.9.2.1.1 Traversieren aller Knoten des Graphen Das Traversieren aller Knoten eines Graphen ist eine typische Operation und lässt sich auf Grund der Ordnung des Graphen auf einfache Weise iterativ erledigen. Vertex v1 = tgraph.getFirstVertex(); // tgraph ist eine Java5-Instanz Vertex nextv = v1; do { // Hier tun, was immer mit dem Knoten zu tun ist. nextv = nextv.getNextVertex(); } while (nextv != v1); 3.9.2.1.2 Traversieren aller Kanten des Graphen Edge e1 = tgraph.getFirstEdge(); // tgraph ist eine Java5-Instanz Edge nexte = e1; do { // Hier tun, was immer mit der Kante zu tun ist. nexte = nexte.getNextEdge(); } while (nexte != e1); 41 3.9.2.1.3 Traversieren aller Inzidenzen zu einem Knoten Edge nexti = vertex.getFirstIncidence(); while (nexti != null) { // Hier tun, was immer mit der Kante zu tun ist. // So gelangt man z. B. an das Objekt auf der anderen Seite der Kante: Vertex thatvertex = nexti.getThat(); nexti = nexti.getNextIncidence(); } Häufig möchte man nicht die Kanten selbst, sondern die damit verknüpften Objekte betrachten. Hierfür kann die getThat()-Methode genutzt werden, die für alle Kantentypen zur Verfügung steht. Gelangt man von einem bestimmten Knoten aus (z. B. wie oben mittels der SchnittstellenMethode getNextIncidence()) an eine Kante, so liefert getThat() immer den anderen mit der Kante verknüpften Knoten. Mit getThis() erhält man den ursprünglichen Knoten zurück. 3.9.2.1.4 Suche nach Knoten bei fixem Pfad Häufig sucht man zu einem Knoten einen oder eine Menge von weiteren Knoten, die über einen bekannten Pfad mit dem Ausgangsknoten verknüpft sind. Zu diesem Zweck kann die reachableVertices()-Methode auf jedem Knoten verwendet werden: Set<ClassDefinition> cd_set = methoddeclaration.reachableVertices(ClassDefinition.class, new PathElement(IsMemberOf.class, EdgeDirection.OUT), new PathElement(IsClassBlockOf.class, EdgeDirection.OUT)); In diesem Beispiel wird ausgehend von einer Methoden-Deklaration die enthaltende Klasse gesucht. Gemäß Metamodell-Definition führt der Pfad zur enthaltenden Klasse über eine Kante des Typs IsMemberOf zu einem Knoten des Typs Block und weiter über eine Kante des Typs IsClassBlockOf zu der gesuchten ClassDefinition-Instanz. Um diesen Pfad zu spezifizieren reicht es aus, die Kanten und ihre Richtung anzugeben. Die reachableVertices()-Methode gibt also den gesuchten Typ und in der Folge eine beliebig lange Liste von PathElement-Instanzen, jeweils bestehend aus Kantentyp und -richtung, zur Spezifikation des Suchpfades an. Als Ergebnis erhält man immer ein Set des gesuchten Typs. Diese Suchmethode ist besonders effizient, da hierfür nicht der GReQL-Auswerter benötigt wird. Sie erfordert andererseits auch sehr spezielle Abfragen und eine detaillierte Kenntnis des Metamodells. 3.9.2.1.5 Suche nach Knoten von einem Knoten aus Die reachableVertices()-Methode ist überladen und bietet auch eine Suche mittels GReQLAusdruck an: String greql = " -->{^IsDeclarationOf,^IsTypeDefinitionOf}* & {Type}"; List<Type> typelist = v.reachableVertices(greql, Type.class); 42 Die Abfrage im obigen Beispiel sucht für einen beliebigen gegebenen Knoten v nach dem enthaltenden Typ. Dies unterscheidet diese Version der reachableVertices()-Methode wesentlich von der oben beschriebenen: Die Pfadspezifikation ist nicht fix, sondern ein regulärer Ausdruck, der es ermöglicht, unterschiedliche Pfade als mögliche Treffer zu spezifizieren. Demgemäß ist die Ausführung dieser Methode jedoch auch weniger performant als die Version mit fixer Pfadangabe. 3.9.2.1.6 Suche nach Knoten auf Graph-Ebene mittels GReQL Wie bereits im Abschnitt 3.7.3. Die Abfragesprache GReQL beschrieben, können Abfragen auch auf Graph-Ebene erfolgen. Hierzu wird eine Instanz der Klasse GreqlEvaluator erzeugt, die Auswertung der übergebenen Abfrage veranlasst und anschließend das Ergebnis ausgelesen. Ein Beispiel für diese Vorgehensweise wurde bereits im o. g. Kapitel gegeben. 3.9.2.1.7 Suche nach Kanten Für die Suche nach Kanten stehen weniger Möglichkeiten zur Verfügung als für die Suche nach Knoten. So existieren insbesondere keine zu reachableVertices() analoge Methoden für die Suche nach Kanten. Auf Graph-Ebene kann allerdings mittels der Klasse GreqlEvaluator auch nach Kanten gesucht werden. So findet die nachfolgende Suche alle IsMemberOf-Kanten im Graphen (man beachte, dass vor den geschweiften Klammern für die Suche nach Kanten ein E anzugeben ist): GreqlEvaluator eval = new GreqlEvaluator( "from x:E{IsMemberOf}" + " reportSet x" + " end", tgraph, null); 3.9.2.2 Ändern von Attributwerten Für jedes Attribut eines Typen werden beim Ausführen des GraBaJa-Builds Getter und Setter erzeugt, über die auf die Attribute zugegriffen werden kann. Das Ändern von Attributwerten ist entsprechend einfach über den Setter des Attributs möglich: methodinvocation.set_type(MethodInvocationTypes.SUPERCONSTRUCTOR); Im gegebenen Beispiel wird das type-Attribut einer MethodInvocation-Instanz auf den Wert SUPERCONSTRUCTOR des Enums MethodInvocationTypes gesetzt. 3.9.2.3 Erzeugen von Knoten und Kanten Für das Erzeugen von Knoten und Kanten sollten die entsprechenden Factory-Methoden des Graphen genutzt werden, da im Rahmen der Erzeugung auch einige Verwaltungsinformationen im Graphen korrekt gesetzt werden müssen. Für jeden Knoten- oder Kantentyp stehen entsprechende create*()-Methoden zur Verfügung. So erfolgt die Erzeugung einer neuen ClassDefinitionInstanz wie folgt: 43 ClassDefinition cd = tgraph.createClassDefinition(); Die so erzeugte Instanz wäre nun zwar im Graphen verfügbar und könnte auch über die getNextVertex()-Methode grundsätzlich iterativ erreicht werden, ohne zusätzliche Informationen und Verknüpfungen wäre die erzeugte ClassDefinition jedoch kaum sinnvoll. Zunächst sind die Attribute der Klasse entsprechend zu setzen: cd.set_external(false); cd.set_fullyQualifiedName("mypackage.MyClass"); cd.set_name("MyClass"); Da durch eine Klasse auch immer ein Typ definiert wird, sollte zudem eine entsprechende Instanz des Typs QualifiedType miterzeugt und verknüpft werden: QualifiedType qt = tgraph.createQualifiedType(); qt.set_fullyQualifiedName("mypackage.MyClass"); Diese ist nun mittels einer Kante des Typs IsTypeDefinitionOf mit der ClassDefinition zu verknüpfen: tgraph.createIsTypeDefinitionOf(cd, qt); Die Integration dieser Knoten in den TGraphen kann nun je nach Bedarf noch weiter fortgesetzt werden. Insbesondere wäre es hier sinnvoll, die entsprechenden Instanzen und Verknüpfungen zur Quelltext-Datei mittels der entsprechenden SourceFile und TranslationUnit-Knoten herzustellen und so den bisher isolierten Teilgraphen im Gesamtgraphen vom Program-Knoten aus erreichbar zu machen. Das Beispiel zeigt, dass Ergänzungen im TGraphen in der Regel ganze Bündel von Knoten und Kanten betreffen, da die einzelnen Knoten und Kantentypen so feingranular sind, dass sie für sich genommen keinen Sinn machen. 3.9.2.4 Löschen von Knoten und Kanten Das Löschen von Knoten oder Kanten ist entweder über eine Graphen-Methode oder über die delete()-Methode jedes einzelnen Typen möglich: v1.delete(); tgraph.deleteVertex(v2); e1.delete(); tgraph.deleteEdge(e2); // // // // Loescht den Knoten. Gleichwertig. Loescht die Kante. Gleichwertig. 3.10 Weiterführende Informationen 3.10.1 Weblinks und Dokumentation Die Arbeitsgruppe Ebert des IST der Universität Koblenz-Landau pflegt im Bereich ihres Webauftritts ein Einstiegsportal zum Thema Graphentechnologie unter [URL:ISTGRAPHEN], von dem aus speziellere Übersichtsseiten zu den Themen TGraphen, Graphenlabor, GReQL, GUPRO sowie damit verbundenen Themen erreicht werden können. 44 Über diesen offiziellen Webauftritt hinaus pflegt das IST ein Wiki unter [URL:ISTWIKI]. Dort werden Artikel und Tutorials zu JGraLab und GReQL angeboten, die einen praxisorientierten Einblick gewähren. Spezielle Wiki-Artikel zu GraBaJa fehlen allerdings. Bei Problemen mit der Nutzung der vom IST bereitgestellten Frameworks kann das BugtrackingSystem [URL:HELENA] der Universität Koblenz-Landau verwendet werden. Eine Einführung in die grundlegenden Konzepte und Komponenten von GUPRO gibt das umfassende Werk [GUPRO1998], das wesentliche Forschungsarbeiten und Handbücher bis zum Jahr 1998 zusammenstellt. Die Grundlagen-Informationen zu JGraLab, GraBaJa und GReQL 2 sind lediglich über die bereits angeführten Diplom- und Studienarbeiten einsehbar. Für GReQL existiert die hilfreiche Referenzkarte [GREQLREF], die zwar nicht öffentlich bereitgestellt wird, aber jederzeit bei der Arbeitsgruppe Ebert angefragt werden kann. 3.10.2 Download und Lizenzinformation Die jeweils aktuellen Entwicklungsprojekte, die für die Verwendung von JGraLab und GraBaJa notwendig sind, können über ein Quellcode-Repository des IST heruntergeladen werden. Auf den Wikiseiten des IST ist zudem unter [URL:JGRALABDOWN] eine Download-Seite verfügbar, über die Binaries von JGraLab bezogen werden können. Eine analoge Download-Seite für GraBaJa existiert allerdings nicht. Die Version der Projekte, die der vorliegenden Arbeit zu Grunde lag, wurde zudem in ein Repository des Lehrgebiets Steimann der Fernuniversität Hagen aufgenommen. Für den Zugang zu diesem Repository ist ein Nutzerzugang erforderlich, der im Lehrgebiet erbeten werden kann. JGraLab wird gemäß Wikiseiten unter General Public License (GPL) in Version 3 (siehe [URL:GPL3]) veröffentlicht. In den Datei-Headern der JGraLab-Quelltexte wird zudem eine Ausnahme formuliert, welche die Lizenzerklärung kompatibel zur Eclipse Public License (EPL, siehe [URL:EPL]) macht, um beispielsweise das Entwickeln und Veröffentlichen von EclipsePlugins unter EPL zu ermöglichen, was bei reiner GPL-Lizensierung auf Grund der Restriktionen der GPL nicht möglich wäre. Dieselben Lizenzbedingungen gelten gemäß den Datei-Headern der Quellcode-Dateien für GraBaJa. Zu beachten sind zudem eine Reihe weiterer Open Source-Lizenzen, die für Komponenten wie ANTLR, Apache Commons und weitere Utilities benötigt werden. Sollen JGraLab und / oder GraBaJa kommerziell weiterentwickelt und ggf. in Produkte integriert werden, die nicht unter GPL oder EPL veröffentlicht werden sollen, so ist eine individuelle Lizenzierung für kommerzielle Zwecke möglich. Hierfür ist Kontakt mit dem IST aufzunehmen. 3.10.3 Referenzprojekte Um einen Einblick in Verwendung und Reifegrad des Graphenlabors zu geben, werden in den folgenden Abschnitten kurze Beschreibungen von Referenzprojekten gegeben. Die Projektliste ist nicht vollständig. In den Projekten wird jeweils JGraLab eingesetzt. GraBaJa wurde lediglich für ein Seitenthema im Rahmen einer Masterarbeit im Kontext des SOAMIG-Projekts eingesetzt (siehe 3.10.3.2. SOAMIG). Ein offizielles Referenzprojekt, das GraBaJa zur Repräsentation von JavaFakten einsetzt, existiert bislang nicht. 45 3.10.3.1 ReDSeeDS ReDSeeDS („Requirements-Driven Software Development System“, siehe [URL:REDSEEDS]) ist ein von über zehn Forschungseinrichtungen und kommerziellen Unternehmen seit 2006 betriebenes Projekt, welches u. a. durch die Europäische Union unterstützt wird. Auf der Grundlage einer Spezifikationssprache für Anforderungen (Requirements Specification Language, RSL) wurde eine Engine entwickelt, welche das Formulieren von Anforderungen, ihre Verwaltung in einem FaktenRepository, das Stellen von Abfragen an das Repository, das Extrahieren wiederverwendbarer Anforderungs-Elemente sowie eine Transformation in Design-Modelle unterstützen soll. Innerhalb dieser Engine wird JGraLab als Fakten-Repository eingesetzt. Das Erfragen von Informationen aus diesem Repository erfolgt über GReQL. 3.10.3.2 SOAMIG SOAMIG ist gemäß [URL:SOAMIG] ein vom Bundesministerium für Bildung und Forschung gefördertes Projekt mit dem Ziel der „Entwicklung eines allgemeinen Vorgehensmodells für die Softwaremigration durch Transformation von Legacy-Systemen in serviceorientierte Architekturen und die Unterstützung der Transformation durch Softwarewerkzeuge“. Auch im SOAMIG-Projekt kommt JGraLab als Fakten-Repository zum Einsatz, hier u. a. gemäß [ZIM2009] prototypisch für COBOL-Fakten, die um Geschäftsprozessmodelle und Tracability-Informationen erweitert werden. Auch eine weitere (von GraBaJa unabhängige) Variante von Java-Graphen wurde im SOAMIG entwickelt und eingesetzt. Im Rahmen der Masterarbeit [FUHR2011] wurde darüber hinaus GraBaJa für das Einlesen von Java-Quellcode eingesetzt. Die eingelesenen Javagraphen wurden dort mit einem Graphen zur Repräsentation von Aktivitätsdiagrammen verschmolzen und mittels GReQL analysiert. Eine gute Übersicht der in SOAMIG entwickelten Werkzeuge und der Integration des Graphenlabors gibt [HORN2011]. 3.10.3.3 COBUS Das Projekt COBUS (COBOL-Bestandsanalyse und -Sanierung) wird vom IST seit November 2009 in Zusammenarbeit mit der Debeka Versicherungsgruppe durchgeführt. Ziel ist es gemäß [URL:COBUS], „eine umfassende Bestandsanalyse und -bewertung des COBOL-basierten Softwaresystems der Debeka durchzuführen. Auf Grundlage dieser Analyse und Bewertung werden anschließend geeignete Maßnahmen abgeleitet, mit denen die Qualität des Systems optimiert und die langfristige Weiterentwickelbarkeit sichergestellt werden kann“. Für die Analyse der umfangreichen COBOL-Fakten wird in diesem Projekt JGraLab eingesetzt. Hierfür werden die COBOL-Quelltexte in ein vereinfachtes COBOL-Schema überführt, für welches dann mittels GReQL diverse Metriken berechnet und Code-Konventionen überprüft werden. 46 4 Identifikation der notwendigen Anpassungen In diesem Kapitel wird zunächst erläutert, warum es überhaupt erforderlich ist, am TGraphen, wie er vom Faktenextraktor des GraBaJa-Projekts für einen gegebenen Java-Quelltext erzeugt wird, Anpassungen vorzunehmen. Die weiteren Abschnitte gleichen die im originalen TGraphen repräsentierten Informationen mit denen ab, die im Kapitel 2.2. Benötigte Java-Fakten für Sichtbarkeitsconstraints gefordert wurden, und beschreiben die notwendigen Erweiterungen des TGraphen zur Repräsentation dieser Fakten. 4.1 Motivation Warum sind überhaupt Anpassungen am TGraphen vorzunehmen? Wie in [BALD2008] gezeigt wurde, sind analog zum Eclipse-AST alle syntaktischen Fakten der eingelesenen Quelltexte vollständig im TGraphen repräsentiert. Für den Entwickler einer Refaktorisierung sind damit auch alle Fakten, die im Abschnitt 2.2.2. Eigenschaften von Deklarationen und Referenzen beschrieben wurden, programmatisch abfragbar bzw. mit der entsprechenden Kenntnis von Java-Interna aus den gegebenen Informationen abzuleiten. Dennoch sprechen folgende Gründe für eine erweiterte Faktenextraktion außerhalb eines konkreten Refaktorisierungs-Werkzeugs: • • • • 4.2 Allgemeine Nützlichkeit: Die angereicherten Informationen sind für Analysezwecke allgemein nützlich und keineswegs nur für Sichtbarkeitsconstraints relevant. Es wäre daher nicht angemessen, innerhalb des Constraint-Generators den nicht unerheblichen Implementierungsaufwand zu betreiben, der für die Extraktion dieser Fakten notwendig ist. Performance: Im Rahmen der Constraint-Generierung wird so häufig auf diese Informationen zugegriffen, dass es schon aus Performance-Gründen geboten erscheint, sie in einer effizient abfragbaren Form in den TGraphen aufzunehmen. Änderungen des Metamodells: Änderungen des Metamodells des TGraphen sind grundsätzlich in einem separaten Entwicklungsprojekt nicht möglich, sondern werden im Rahmen eines GraBaJa-Builds auf der Basis einer Spezifikationsdatei per Codegenerator erzeugt. Ohne Änderung des Metamodells hätten einige Informationen gar nicht oder nur schwer in den TGraphen aufgenommen werden können. Evaluation der Arbeit mit TGraphen: Neben dem konkreten Ziel der Anreicherung des TGraphen um die für die Generierung von Sichtbarkeitsconstraints notwendigen Informationen ist es auch Ziel dieser Arbeit zu untersuchen, inwieweit sich TGraphen generell für die Anreicherung und Abfrage von Zusatzinformationen eignen. Vision des constraintbasierten Refaktorisierungsansatzes ist es gemäß [STEI2010] letztlich, verschiedenen Refaktorisierungs-Werkzeugen eine gemeinsame Infrastruktur bereitzustellen, aus welcher sich diese nach Baukastenprinzip bedienen können. Wenn ein TGraph die Kernkomponente einer solchen gemeinsamen Infrastruktur sein soll, dann ist zu fragen, ob sich die Entwicklungsarbeit mit TGraphen nach einer vernünftigen Einarbeitungszeit als praktikabel erweist. Abgleich der Eigenschaften von Deklarationen und Referenzen Die folgende Tabelle zeigt auf, welche der für Deklarationen und Referenzen geforderten Eigenschaften (siehe Abschnitt 2.2.2. Eigenschaften von Deklarationen und Referenzen) in den TGraphen aufzunehmen sind. 47 Eigenschaften von Deklarationen Eigenschaft Repräsentation im unmodifizierten Anpassungsbedarf und Verweis GraBaJa-TGraphen auf detaillierte Beschreibung Access-Modifier Access-Modifier sind grundsätzlich im TGraphen mittels des Knotentyps Modifier repräsentiert und werden dem jeweiligen Deklarations-Element über eine IsModifierOf*-Kante zugeordnet. Der Typ des Modifiers wird dabei über das Attribut type der Modifier-Instanz repräsentiert. Nicht repräsentiert sind allerdings implizite Modifier, da der Faktenextraktor grundsätzlich nur explizite Syntaxinformation für die Erzeugung heranzieht. Die notwendigen Erweiterungen um implizite Java-Elemente werden im Kapitel 4.3. Repräsentation impliziter Quelltext-Elemente beschrieben. static-Modifier für Die Repräsentation erfolgt im TGraphen analog zu AccessModifiern. Die Notwendigkeit zur Anreicherung des impliziten static-Modifiers für InterfaceMember wird im Abschnitt 4.3.5. Implizite Modifier im Kontext von Interfaces beschrieben. Die Repräsentation erfolgt im TGraphen analog zu AccessModifiern. Die Notwendigkeit zur Anreicherung des impliziten abstract-Modifiers für Interface-Member wird im Abschnitt 4.3.5. Implizite Modifier im Kontext von Interfaces beschrieben. Identifier Identifier sind für alle DeklarationsArten durch Knoten des Typs Identifier im TGraphen repräsentiert. Die Zuordnung erfolgt über unterschiedliche Kantentypen, die von der Deklarations-Art abhängen, so z. B. IsClassNameOf für Klassen-Deklarationen oder IsNameOfMethod für MethodenDeklarationen. Kein Anpassungsbedarf. Typen Die im Rahmen von Deklarationen Kein Anpassungsbedarf. verwendeten Typen sind im TGraphen durch Knoten der Typen BuiltInType (für primitive Datentypen) und QualifiedType (für Referenz-Typen) repräsentiert. Die Verknüpfung des jeweiligen Deklarations-Elements mit diesen Knoten erfolgt je nach DeklarationsArt über Kanten der Typen VariablenDeklarationen abstract-Modifier für MethodenDeklarationen 48 Eigenschaften von Deklarationen IsTypeOf, IsTypeOfParameter, IsExceptionThrownBy und IsUpperBoundOfTypeParameter. Lokationen Die Lokationen von DeklarationsElementen werden im TGraphen über das Attribut fullyQualifiedName der jeweiligen Typ-Definition, in der die Deklaration enthalten ist, repräsentiert. Für jedes DeklarationsElement kann die enthaltende TypDefinition über eine einzige GReQLAbfrage ermittelt und somit die Lokation aus dem genannten Attribut ausgelesen werden. Formale Parameterliste Die formale Parameterliste von Methoden und Konstruktoren wird über Instanzen des Typs Wie sich herausgestellt hat, wird der Wert des fullyQualifiedNameAttributs vom Faktenextraktor nicht immer korrekt ermittelt. Details zu diesem Problem werden im Kapitel 4.7. Fehlerhafte Lokationsinformation für Klassen beschrieben. ParameterDeclaration repräsentiert, die mittels der Kantentypen IsParameterOfMethod oder IsParameterOfConstructor mit der jeweiligen Deklaration verknüpft sind. Die Reihenfolge der Parameter wird über die Inzidenzordnung des TGraphen verwaltet, d. h. beim Iterieren über die IsParameterOf*Kanten (mittels der getIsParameterOf Incidences()-Methode der Deklaration) durchläuft man die Parameter in der gewünschten Reihenfolge. SupertypBeziehungen Supertyp-Beziehungen werden je nach Art der beiden verknüpften Typen über unterschiedliche Kantentypen repräsentiert. Für SuperklassenBeziehungen existiert der Kantentyp IsSuperTypeOfClass. Ist ein Interface der Supertyp (per implements-Schlüsselwort), so existieren verschiedene IsInterfaceOf*-Kantentypen wie z. B. IsInterfaceOfClass. Erweitert ein Interface ein anderes (mittels extends-Schlüsselwort), so 49 Der Faktenextraktor ignoriert die implizite Supertyp-Beziehung zu Object, wenn ein Typ keine explizite extends-Beziehung deklariert. Ebenso wenig wird die implizite Supertyp-Beziehung einer Enum-Definition zu Enum repräsentiert. Details zu diesen impliziten Erweiterungen werden in den Abschnitten 4.3.3. Implizite Erweiterung von Object und 4.3.4. Implizite Erweiterung von Enum Eigenschaften von Deklarationen heißt der Kantentyp überraschenderweise beschrieben. IsSuperClassOfInterface. Spezielle Supertyp-Beziehungen ergeben sich gemäß [JLS3] § 4.10.3 für Array-Typen. Insbesondere endet die Typ-Hierarchie von Array-Typen bei Object, so dass alle Array-Typen die Methoden von Object erben. Im Hinblick auf die Sichtbarkeitsconstraints sind demgemäß mögliche OverrideBeziehungen und statische Bindungen bzgl. dieser Methoden zu überprüfen. Override-Beziehungen scheiden aus, da ein Array-Typ keine eigenen Methoden deklarieren kann. Die statische Bindung des Aufrufs einer Object-Methode auf einem Array könnte für die Contraint-Regeln Acc1, Acc-2, Inh-1, Inh-2 und Ovr relevant sein. All diese Regeln sind jedoch entweder für die Beziehung eines Array-Typs zu Object immer erfüllt (Acc-1, Inh-1), oder die durch diese Regeln beschriebene Konstellation kann für Array-Typen nicht auftreten (Acc-2, Inh-2, Ovr). Override-Beziehung Die Override-Beziehung wird im TGraphen nicht repräsentiert. Die Override-Beziehung ist in den TGraphen aufzunehmen. Details werden im Kapitel 4.4. Repräsentation der OverrideBeziehung beschrieben. Deklarations-Art Alle Deklarations-Arten werden im TGraphen über entsprechende Knotentypen repräsentiert: ClassDefinition, InterfaceDefinition, EnumDefinition, AnnotationDefinition, MethodDeclaration, MethodDefinition, ConstructorDefinition, VariableDeclaration, Kein Anpassungsbedarf. AnnotationField, 50 Eigenschaften von Deklarationen TypeParameterDeclaration. Menge der TypParameter Die Menge der Typ-Parameter wird über Instanzen des Typs Kein Anpassungsbedarf. TypeParameterDeclaration repräsentiert. Die Verknüpfung zu dem jeweiligen mit Typ-Parameter versehenen Deklarations-Element (Klasse, Interface, Konstruktor, Methoden-Deklaration) erfolgt mittels des Kantentyps IsTypeParameterOf. Werden alle Deklarationen repräsentiert? Explizite Deklarationen werden vollständig repräsentiert. Der Faktenextraktor ignoriert implizite KonstruktorDefinitionen in Klassen, die nicht über eine explizite KonstruktorDefinition verfügen. Dieser Mangel wird im Abschnitt 4.3.2. Implizite KonstruktorDefinitionen behandelt. Tabelle 3: Abgleich der Eigenschaften von Deklarationen Eigenschaften von Referenzen Eigenschaft Repräsentation im unmodifizierten Anpassungsbedarf und Verweis GraBaJa-TGraphen auf detaillierte Beschreibung Identifier Für die Identifier von Referenzen wird Kein Anpassungsbedarf. ebenfalls der Knotentyp Identifier herangezogen. Die Kantentypen unterscheiden sich je nach Art der Referenz: IsNameOfInvokedMethod für Methoden- und Konstruktor-Aufrufe sowie IsFieldNameOf für VariablenZugriffe. Lokationen Die Lokationen von Referenzen können wie die für Deklarationen über das fullyQualifiedName-Attribut der enthaltenden Typ-Definition ermittelt werden. Der Anpassungsbedarf wurde bereits für die LokationsEigenschaft von Deklarationen beschrieben. Statische Bindungen Die Repräsentation statischer Bindungen erfolgt über die Kantentypen Es ist eine Neu-Implementierung der statischen Bindungen erforderlich. Eine ausführliche Untersuchung und Begründung erfolgt im Kapitel IsDeclarationOfInvoked Method sowie 51 Eigenschaften von Referenzen IsDeclarationOfAccessed Field. Typ-Referenzen 4.5. Repräsentation statischer Bindungen. Alle im Abschnitt 2.2.2. Eigenschaften Kein Anpassungsbedarf. von Deklarationen und Referenzen beschriebenen Typ-Referenzen sind im TGraphen repräsentiert. Hierzu existieren zahlreiche unterschiedliche Kantentypen, die hier nicht vollständig wiedergegeben werden sollen. Die folgenden Beispiele sollen einen Eindruck von der Repräsentation der Typ-Referenzen im Metamodell vermitteln: IsReturnTypeOf, IsTypeOfVariable, IsInterfaceOf, IsSuperClassOf, IsElementTypeOf, IsCastedTypeOf, IsExceptionThrownBy Empfänger-Typen Beziehungen von Methoden- und Konstruktor-Aufrufen sowie FeldZugriffen zum jeweiligen EmpfängerTypen werden nicht im TGraphen repräsentiert. Die Referenz auf EmpfängerTypen ist im TGraphen aufzunehmen. Details werden im Kapitel 4.6. Referenzierung von Empfänger-Typen beschrieben. Werden alle Referenzen repräsentiert? Zwei Arten von Referenzen werden nicht repräsentiert. Zum einen erzeugt der Compiler für jeden Konstruktor einer Klasse die implizite InstanzInitialisierungs-Methode (engl. instance initialization method) <init> mit dem Rückgabetyp void und der Parameter-Liste des Konstruktors. Innerhalb dieser Methode werden allen MemberVariablen der Klasse Default-Werte gemäß [JLS3] § 4.12.5 zugewiesen. Bei diesen Zuweisungen handelt es sich letztlich um Referenzen auf die jeweiligen Variablen-Deklarationen, die im TGraphen jedoch nicht repräsentiert sind. Hieraus ergeben sich für die Generierung der Sichtbarkeitsconstraints jedoch keine Probleme, da die fehlenden impliziten Der zweite fehlende ReferenzTyp ist der implizite super()Aufruf zu Beginn eines jeden Konstruktor-Blocks, wenn ein expliziter super()-Aufruf fehlt. Dieses Problem wird näher im Abschnitt 4.3.1. Implizite super()-Aufrufe behandelt. 52 Eigenschaften von Referenzen Zuweisungen die statischen Eigenschaften des Programms nicht verändern. Tabelle 4: Abgleich der Eigenschaften von Referenzen 4.3 Repräsentation impliziter Quelltext-Elemente Im Rahmen der Untersuchungen für diese Arbeit wurden eine Reihe impliziter Quelltext-Elemente identifiziert, welche für die Generierung von Sichtbarkeitsconstraints relevant sind. Diese Relevanz wird im Folgenden für die einzelnen Elemente näher erläutert. 4.3.1 Implizite super()-Aufrufe Spracheigenschaft Gemäß [JLS3] § 8.8.7 wird beim Fehlen eines expliziten Konstruktor-Aufrufs zu Beginn eines Konstruktor-Blocks vom Compiler implizit ein Aufruf des parameterlosen Konstruktors angenommen. Relevanz für Refaktorisierungen Wenn eine Subklasse einen super()-Aufruf tätigt, so muss ihre Superklasse einen für die Subklasse sichtbaren parameterlosen Konstruktor definieren. Wäre der parameterlose Konstruktor der Superklasse für die Subklasse nicht sichtbar, weil er z. B. durch eine Refaktorisierung auf private gesetzt wird, so resultierte dies in einem Syntax-Fehler. Relevante Contraint-Regeln: Acc-1. Tabelle 5: Implizite super()-Aufrufe 4.3.2 Implizite Konstruktor-Definitionen Spracheigenschaft Gemäß [JLS3] § 8.8.9 wird für Klassen ohne Konstruktor-Definition automatisch ein Default-Konstruktor ohne Parameter und ohne throws-Klausel bereitgestellt, welcher den parameterlosen Konstruktor der Superklasse aufruft. Relevanz für Refaktorisierungen Da es durch die implizite Konstruktor-Definition zu einem super()-Aufruf kommt, gilt das im vorhergehenden Absatz Gesagte. Die Vorgehensweise bei der Anreicherung des TGraphen um implizite Konstruktor-Definitionen wird ausführlich im Kapitel 5.1. Beispiel für eine Anreicherung beschrieben. Relevante Constraint-Regeln: Acc-1. Tabelle 6: Implizite Konstruktor-Definitionen 53 4.3.3 Implizite Erweiterung von Object Spracheigenschaft Relevanz für Refaktorisierungen Gemäß [JLS3] § 4.3.2 ist die Klasse Object Superklasse aller anderen Klassen. Daraus folgt, dass eine Klasse, die nicht explizit von einer anderen Klasse ableitet, implizit direkte Subklasse von Object ist. Keine der einer Superklasse (hier Object) geerbten Methoden darf in der Subklasse eine geringere Sichtbarkeit haben darf als in der Superklasse selbst. Relevante Constraint-Regeln: Sub-1, Dyn-1. Tabelle 7: Implizite Erweiterung von Object 4.3.4 Implizite Erweiterung von Enum Spracheigenschaft Relevanz für Refaktorisierungen Gemäß [JLS3] § 8.9 leiten alle EnumDie von Enum geerbten Methoden können in EnumDefinitionen implizit von der Superklasse Definitionen überschrieben werden. Wie bereits im Enum ab. vorhergehenden Abschnitt festgestellt wurde, darf eine überschreibende Methode nicht weniger sichtbar sein als die überschriebene. Relevante Constraint-Regeln: Sub-1, Dyn-1. Tabelle 8: Implizite Erweiterung von Enum 4.3.5 Implizite Modifier im Kontext von Interfaces Im Kontext von Interfaces spielen zahlreiche implizite Modifier eine Rolle. Kurzbeschreibung abstract-Modifier für das Interface selbst Spracheigenschaft Gemäß [JLS3] § 9.1.1.1 ist jedes Interface implizit abstract. public-Modifier für Interface- Gemäß [JLS3] § 9.1.5 sind alle Member Member eines Interfaces implizit public. Zu den Membern eines Interfaces zählen die Deklarationen von Methoden, Variablen, Klassen, Interfaces (und damit auch Annotationstypen, da diese gemäß [JLS3] § 9.6 spezielle 54 Relevanz für Refaktorisierungen Nicht relevant für Sichtbarkeitsconstraints. Die Relevanz ist in diesem Fall offensichtlich, da die Vergabe anderer Sichtbarkeiten als public syntaktisch verboten ist. Des Weiteren dürfen implementierende Klassen diese Sichtbarkeit nicht reduzieren. Kurzbeschreibung Spracheigenschaft Interface-Definitionen sind) sowie Enums. static-Modifier für Interface- Gemäß [JLS3] § 9.3 sind alle Variablen-Deklarationen im Body eines Interfaces implizit static. Member Gemäß [JLS3] § 9.5 sind weiterhin alle Member-TypDeklarationen (engl. member type declarations) implizit static. Member-Typen sind Klassen, Interfaces (und damit auch Annotationstypen) und Enums. abstract-Modifier für Interface-Methoden final-Modifier für Variablen- Deklarationen in Interfaces Relevanz für Refaktorisierungen Relevante Constraint-Regeln: Acc-1, Sub-1, Dyn-1, Abs. Relevante Constraint-Regeln: Inh-2. Auf Grund der Komplexität dieser Regel wird hier auf eine Wiederholung der Problemstellung verzichtet. Gemäß [JLS3] § 9.4 ist jede Relevante Constraint-Regel: Methoden-Deklaration im Body Abs. eines Interfaces implizit abstract. Gemäß [JLS3] § 9.3 ist jede Nicht relevant für Variablen-Deklaration im Body Sichtbarkeitsconstraints. eines Interfaces implizit final. Tabelle 9: Implizite Modifier im Kontext von Interfaces 4.3.6 Impliziter Modifier für Annotationstyp-Elemente Spracheigenschaft Relevanz für Refaktorisierungen Annotationstypen (engl. annotation types) sind gemäß [JLS3] § 9.6 spezielle Interfaces. Die Member von Annotationstypen sind methodenartig definiert und werden meist einfach als „Elemente“ (engl. annotation type elements) bezeichnet. (Der entsprechende TGraphen-Typ wurde AnnotationField genannt. Dies entspricht allerdings nicht der Terminologie der JLS.) Als Member gilt für die Elemente von Annotationstypen die bereits oben festgestellte Eigenschaft Es gilt die Bereits für den public-Modifier von Interface-Membern festgestellte Relevanz: Die Vergabe anderer Sichtbarkeiten als public ist syntaktisch verboten. Relevante Constraint-Regeln: Acc-1, Sub-1, Dyn-1. 55 Spracheigenschaft Relevanz für Refaktorisierungen ([JLS3] § 9.1.5), dass alle Member eines Interfaces implizit public sind. Tabelle 10: Impliziter Modifier für Annotationstyp-Elemente 4.3.7 Abgrenzung Im Rahmen der Zusammenstellung der impliziten Quelltext-Elemente, die für die Erzeugung von Sichtbarkeitsconstraints relevant sind, wurden weitere Kandidaten untersucht, für die jedoch festgestellt wurde, dass eine Repräsentation im TGraphen nicht erforderlich ist. Diese werden im Folgenden dokumentiert. 4.3.7.1 Elemente ohne implizite Modifier Die folgenden Quelltext-Elemente können keine impliziten Modifier aufweisen: • • • Konstruktoren: Gemäß [JLS3] § 8.8.3 kann im Rahmen einer Konstruktor-Definition ausschließlich ein Access-Modifier angegeben werden. Fehlt dieser, so ist damit DefaultSichtbarkeit deklariert. Formale Methoden-Parameter: Der gemäß [JLS3] § 8.4.1 einzig erlaubte Modifier für die formalen Parameter einer Methode ist final. Fehlt der final-Modifier, so wird er nicht implizit angenommen. Typ-Parameter (von Klassen, Interfaces und Methoden): Gemäß [JLS3] § 18.1 sind keine Modifier möglich. 4.3.7.2 Implizite Typkonvertierungen [JLS3] § 5 beschreibt ausführlich unterschiedliche gewissermaßen implizite TypkonvertierungsMechanismen. Dabei wird der Typ S eines Ausdrucks abhängig vom Kontext, in dem er verwendet wird, in einen anderen Typ T konvertiert, der es dem Kontext erlaubt, den Ausdruck wie einen Ausdruck des Typs T zu behandeln. Die Konvertierung erfolgt dabei bereits durch den Compiler und kann ggf. eine zusätzliche Laufzeitprüfung erfordern. Grundsätzlich werden im genannten Kapitel elf Konvertierungstypen (siehe [JLS3] § 5.1) und fünf relevante Kontextarten beschrieben. In allen Fällen einer impliziten Typkonvertierung wird die Konvertierung durch den Kontext ausgelöst. Dabei entspricht der Zieltyp der Konvertierung in vier der fünf Kontextarten jeweils einem bereits im Kontext sichtbaren Typ: • • • • Bei der Assignment Conversion (siehe [JLS3] § 5.2) ist dies der deklarierte Typ der Variablen, an die zugewiesen wird. Bei der Method Invocation Conversion (siehe [JLS3] § 5.3) ist es der deklarierte Typ der Methoden-Parameter. Bei der String Conversion (siehe [JLS3] § 5.4) ist der Zieltyp immer String. Bei der Casting Conversion (siehe [JLS3] § 5.5) ist der Zieltyp immer im Cast-Operator deklariert (siehe [JLS3] § 15.16). 56 Die fünfte Kontextart (Numeric Promotion, siehe [JLS3] § 5.6) sind arithmetische Operatoren und hat ausschließlich Einfluss auf die Konvertierung numerischer Datentypen, die alle immer sichtbar sind. Aus dem Gesagten ergibt sich, dass es in keinem Fall zu einer Verletzung von Sichtbarkeitsconstraints kommen kann, da diese ansonsten auch ohne die Typkonvertierung durch den jeweiligen Kontext verletzt gewesen sein müssten. 4.3.7.3 Implizites this-Schlüsselwort Hat ein Methoden-Aufruf (einer nicht-statischen Methode) die Form name() oder ein Feld-Zugriff (eines nicht-statischen Feldes) die Form name = <Wert>, so ist das Empfänger-Objekt dieser Referenzen implizit this, so als ob der Zugriff über this.name() oder this.name = Wert erfolgt wäre. Dies bedeutet allerdings nicht, dass analog zu anderen impliziten Java-Elementen von einem impliziten this-Schlüsselwort auszugehen wäre. In der [JLS3] wird kein solches implizites this beschrieben, sondern es heißt lediglich im Kapitel über statische Methoden ([JLS3] § 8.4.3.2): „An instance method is always invoked with respect to an object, which becomes the current object to which the keywords this and super refer during the execution of the method body.“ this kann demgemäß zwar als Empfänger-Objekt angenommen werden, ist aber nicht implizit im Quelltext vorhanden. Unabhängig davon, ob ein implizites this-Schlüsselwort bei einem Methoden-Aufruf oder FeldZugriff in der beschriebenen Form angenommen werden kann (wofür es keine Hinweise gibt), ist mit Blick auf den Empfänger-Typ der jeweiligen Referenz auch keine Repräsentation erforderlich. Denn die Referenz erfolgt vom Methoden-Aufruf (Knoten-Typ MethodInvocation) zum Typ des Empfänger-Objekts, und dies ist in diesem Fall genau der Typ, der die Referenz enthält. Analoges gilt für den Feld-Zugriff. Die benötigte Information kann also auch ohne die Annahme eines impliziten this-Schlüsselworts ermittelt und repräsentiert werden. 4.4 Repräsentation der Override-Beziehung Im Abschnitt 4.3.3. Implizite Erweiterung von Object wurde bereits erwähnt, dass die Sichtbarkeit einer überschreibenden Methode nicht geringer sein darf als die der überschriebenen (ConstraintRegel Sub-1). Daraus ergibt sich unmittelbar die Relevanz der Override-Beziehung für die Generierung der Sichtbarkeitsconstraints. Weitere relevante Constraint-Regeln sind Sub-2, Dyn1und Dyn-2. Die Ermittlung der Override-Beziehungen im angepassten TGraphen hat auf Basis der Spezifikation der Override-Beziehung zu erfolgen, die in [JLS3] § 8.4.8.1 gegeben wird. 4.5 Repräsentation statischer Bindungen Statische Bindungen stellen die Beziehung von Referenzen auf Deklarationselemente dar und sind daher für mehrere Constraint-Regeln relevant: Acc-1, Acc-2, Inh-1 und Inh-2. Im Folgenden wird die Repräsentation statischer Bindungen im GraBaJa-TGraphen separat für Methoden-Aufrufe und Feld-Zugriffe dargestellt. 57 4.5.1 Methoden- und Konstruktoren-Aufrufe Wie bereits im Abschnitt 3.7.2.4. Subtyp-Beziehungen und Methoden-Aufrufe gezeigt wurde, existiert im GraBaJa-TGraphen der Kantentyp IsDeclarationOfInvokedMethod, der als Kandidat zur Repräsentation statischer Methoden-Bindungen in Betracht kommt. Da in [BALD2008] keine weitere Dokumentation zum Gehalt dieser Kante entnehmbar ist und auch sonst keine Dokumentation zu dieser Fragestellung gefunden werden konnte, war für die Zwecke der vorliegenden Arbeit zu untersuchen, ob durch diesen Kantentyp tatsächlich statische Bindung im Sinne der Spezifikation von [JLS3] § 15.12 repräsentiert wird. Auf Anfrage bei den Autoren von [BALD2008] ergab sich, dass [JLS3] § 15.12 nicht als Vorlage für die Implementierung des Extraktions-Algorithmus verwendet wurde. Das informell formulierte Ziel der Implementierung war vielmehr, die „speziellst mögliche“ Methoden-Deklaration zu finden und den Methoden-Aufruf mit dieser zu verknüpfen. Dies entspricht allerdings bereits weitgehend den Vorgaben der [JLS3], die in § 15.12.1 feststellt: „There may be more than one such method, in which case the most specific one is chosen.“ Die Ausführungen der [JLS3] zu diesem Thema umfassen mehr als 40 Seiten und behandeln zahlreiche sehr spezielle Konstellationen. Eine Überprüfung all dieser Konstellationen hätte den Rahmen dieser Arbeit überschritten. Für die Zwecke dieser Arbeit wurde daher eine Reihe von Konstellationen ausgewählt, die den Großteil der in der Praxis vorkommenden statischen Methoden-Bindungen abdecken. Für jede dieser Konstellationen wurde ein Quelltext-Beispiel erstellt und der generierte TGraph überprüft. Im Folgenden werden die überprüften Formen für Methoden-Aufrufe wiedergegeben. Beispiel Beschreibung mymethod(); Einfacher Methoden-Aufruf einer innerhalb der Klasse deklarierten Methode. this.mymethod(); Methoden-Aufruf auf this. super.superklassenmethode(); Methoden-Aufruf auf super. feld.ueberladeneMethode(""); Aufruf einer überladenen Methode. feld.interfaceMethode(); Aufruf einer Methode, wobei feld mit einem Interface-Typ deklariert ist. Liegt keine Implementierung des Interfaces vor, so wird an die Interface-Deklaration gebunden, andernfalls an die spezifischste Implementierung. Klasse.statischeMethode(); Aufruf einer statischen Methode. ueberschriebeneMethode(); Aufruf einer überschriebenen Methode. variableStelligkeit("", "", ""); Aufruf einer Methode mit variabler Stelligkeit. Klasse.<String>generischeMethode(); Aufruf einer statischen generischen Methode. 58 Beispiel Beschreibung methodeMitTypParametern(mylist); Aufruf einer Methode mit generischem Typ als Parametertyp. Dies funktioniert auch bei Type Erasure. Im Beispiel wurde mylist mit List deklariert, während die Methoden-Deklaration List<String> als Parameter-Typ deklariert. Tabelle 11: Überprüfte Formen statischer Methoden-Bindung In all diesen Fällen repräsentierte die IsDeclarationOfInvokedMethod-Kante die statische Methoden-Bindung gemäß [JLS3] § 15.12 korrekt. Konstruiert man allerdings ein komplexeres Beispiel, so wird eine falsche Bindung ermittelt. Gegeben seien die beiden folgenden Klassendefinitionen innerhalb der Datei AuessereKlasse.java: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 public class AeussereKlasse { class Testklasse { public String toString(){return "AuessereKlasse.Testklasse";} } public static void main(String[] args) { new AeussereKlasse().test1method(); } void method() { System.out.println(new Testklasse().toString()); class Testklasse{ public String toString(){return "AuessereKlasse.method().Testklasse";} } } } class Testklasse{ public String toString(){return "Testklasse";} } Führt man dieses Programm aus, so lautet die Ausgabe: AuessereKlasse.Testklasse Diese entspricht dem korrekten voll qualifizierten Pfad der Klasse, an die der Compiler bindet. Untersucht man die IsDeclarationOfInvokedMethod-Kante für den Aufruf der toString()Methode in Zeile 9, so wird dieser jedoch nicht an die Klassen-Definition aus Zeile 2 (voll qualifizierter Pfad AuessereKlasse.Testklasse), sondern an die Klassen-Definition aus Zeile 15 (voll qualifizierter Pfad Testklasse) gebunden. Dies ist im Sinne der statischen Bindung die falsche Klasse. Für die Zwecke dieser Arbeit ist damit zunächst gezeigt, dass der Bindealgorithmus des GraBaJaFaktenextraktors für Methoden-Aufrufe nicht in allen Fällen die statischen Bindungen repräsentiert. Dies ist nicht notwendigerweise als Fehler zu betrachten, da es – wie oben erwähnt – nicht das Entwicklungsziel war, die statischen Bindungen im Sinne von [JLS3] § 15.12 in den TGraphen aufzunehmen. 59 Andererseits hat sich gezeigt, dass der Algorithmus für eine große Zahl von in der Praxis vorkommenden Fällen tatsächlich die statische Bindung repräsentiert. Es wäre sicherlich möglich, den Algorithmus des Faktenextraktors auch für Sonderfälle wie den oben konstruierten so anzupassen, dass die Bindung der Spezifikation aus [JLS3] § 15.12 entspricht. Für die Zwecke dieser Arbeit wurde entschieden, eine solche Korrektur des Faktenextraktors nicht vorzunehmen. Hierfür sind zwei Gründe zu nennen: • Im Abschnitt 7.2.2. Wartbarkeit des Faktenextraktors wird näher erläutert, warum Anpassungen des Faktenextraktors grundsätzlich problematisch sind und vermieden werden sollten. • Eine Anpassung des Faktenextraktors löst nicht das Problem, dass Bindungen auch für nachträgliche Anreicherungen des TGraphen aufgelöst werden können müssen. Dies muss jedoch ohnehin außerhalb des Faktenextraktors erfolgen, so dass eine NeuImplementierung in jedem Fall notwendig wäre. Näheres hierzu wird in den Abschnitten 4.5.3. Ermittlung statischer Bindungen nach Faktenextraktion und 8.1.1. NeuImplementierung der statischen Bindungen ausgeführt. Zugleich wurde jedoch entschieden, die IsDeclarationOfInvokedMethod-Kante vorläufig so zu betrachten „als ob“ sie die statischen Bindungen korrekt repräsentierte. Andernfalls wäre beispielsweise eine Implementierung der Referenz von Methoden-Aufrufen auf Empfänger-Typen (siehe Kapitel 4.6. Referenzierung von Empfänger-Typen) nur schwer möglich gewesen. Um dennoch eine Implementierung vornehmen zu können, wurde hier die IsDeclarationOfInvokedMethod-Kante im Sinne der statischen Bindung eingesetzt. Dies erscheint zumindest vor dem Hintergrund, dass diese Interpretation in der überwiegenden Mehrzahl der überprüften Fälle zutrifft, für die Zwecke dieser Arbeit gerechtfertigt. 4.5.2 Feld-Zugriffe Analog zu Methoden-Aufrufen existiert im GraBaJa-TGraphen für Feld-Zugriffe ein Kantentyp IsDeclarationOfAccessedField, welche einen FieldAccess mit einer VariableDeclaration verknüpft. Gemäß [JLS3] § 15.11 kann ein Feld-Zugriff grundsätzlich entweder über einen sogenannten Primary Expression ([JLS3] § 15.8) oder über super erfolgen. Die folgende Tabelle gibt eine Übersicht der wichtigsten Formen von Feld-Zugriffen. 60 Beispiel Beschreibung x = feld; Zugriff auf ein innerhalb der Klasse deklariertes Feld und Zugriff auf Methoden-Argumente. x = objekt.feld; Zugriff auf das öffentliche Feld eines anderen Objekts. objekt kann dabei auch der Name eines Methoden-Arguments sein. x = this.feld; Zugriff über this. x = super.feld; Zugriff über super. x = Klasse.statischesfeld; Zugriff auf ein statisches Feld. int i = new String[10].length; Zugriff über Array Creation Expression gemäß [JLS3] § 15.10. x = new Klasse().feld; Zugriff über Class Instance Creation Expression gemäß [JLS3] § 15.9. x = array[0].feld; Zugriff über ArrayAccess Expression gemäß [JLS3] § 15.13. Tabelle 12: Überprüfte Formen statischer Feld-Bindung Alle bis auf eine dieser Zugriffsformen wird korrekt im TGraphen repräsentiert: Der Zugriff über einen Array Creation Expression wird nicht repräsentiert. Dies wurde als Fehler an die Betreuer des IST gemeldet und soll in einer künftigen GraBaJa-Version behoben werden. Aus der Perspektive der Sichtbarkeitsconstraints ist dies jedoch nicht relevant, da das length-Feld im Array-Typ nur implizit deklariert ist und seine Sichtbarkeit auch nicht modifiziert werden kann. Für die Zwecke dieser Arbeit kann daher der Kantentyp IsDeclarationOfAccessedField als Repräsentation der statischen Bindung von Feld-Zugriffen interpretiert werden. Folgende Besonderheiten sind festzustellen: • • 4.5.3 Auch der Zugriff auf die linke Seite einer Zuweisung wird als FieldAccess repräsentiert und mittels der IsDeclarationOfAccessedField-Kante an die Deklaration der Variablen gebunden. Auch der Zugriff auf super und this wird als FieldAccess repräsentiert. Die IsDeclarationOfAccessedField-Kante wird dann direkt an die ClassDefinition gebunden, auf die sich super oder this bezieht. Ermittlung statischer Bindungen nach Faktenextraktion Da der GraBaJa-Faktenextraktor die Bindungen, die durch die Kantentypen IsDeclarationOfInvokedMethod und IsDeclarationOfAccessedField repräsentiert werden, bereits beim Einlesen des Quelltexts auflöst, werden die statischen Bindungen für nachträglich in den TGraphen aufgenommene Deklarationen oder Referenzen nicht im TGraphen repräsentiert. Der Algorithmus des Faktenextraktors ist ohne Anpassungen für diesen Zweck nicht verwendbar, da er auf Ebene des vom ANTLR-generierten Parser erzeugten AST und den zugehörigen Symboltabellen arbeitet. Hiervon betroffen sind die folgenden Anreicherungen: 61 • • • Ergänzte implizite super()-Aufrufe müssten an die Deklaration des aufgerufenen Konstruktors gebunden werden. An hinzugefügte implizite Konstruktoren müssten die Aufrufe dieser Konstruktoren gebunden werden. Nach der Aufnahme der impliziten Erweiterung von Object müssten Aufrufe der ObjectMethoden an die Deklarationen dieser Methoden in Object gebunden werden. Referenzen des eigenen Quelltexts auf Deklarationen, die in externen Bibliotheken vorkommen, müssten nach der Faktenextraktion externer Bibliotheken (siehe Kapitel 4.8. Repräsentation von Java-Elementen externer Bibliotheken) an diese Deklarationen gebunden werden. Um für diese und eventuelle künftige nachträgliche Anreicherungen des TGraphen die statischen Bindungen ermitteln zu können, müssen die Bindealgorithmen außerhalb des GraBaJaFaktenextraktors neu implementiert werden. Dies wird näher im Abschnitt 8.1.1. NeuImplementierung der statischen Bindungen ausgeführt. • 4.6 Referenzierung von Empfänger-Typen Für zahlreiche Constraint-Regeln ist der Empfänger-Typ eines Methoden- oder Konstruktor-Aufrufs sowie eines Feld-Zugriffs relevant: Acc-2, Inh-1, Inh-2 sowie Ovr. Die Ermittlung der Empfänger-Typen ist wie folgt vorzunehmen: • Für Feld-Zugriffe entspricht der Empfänger-Typ dem Typ, an den statisch gebunden wird. • Bei statischen Methoden ist der Empfänger-Typ gleich dem Typ, in dem die Methode deklariert ist. • Bei einem Aufruf nichtstatischer Methoden in der Form <Methodenname>() ist das Empfänger-Objekt implizit this und somit der Empfänger-Typ gleich der Klasse, in welcher der Methoden-Aufruf enthalten ist. • Bei einem Aufruf nichtstatischer Methoden in der Form <Ausdruck>.<Methodenname>(...) ergibt sich der Empfänger-Typ aus dem statischen Typ des Ausdrucks, der dem Methodennamen vorangestellt ist. Wie dieser ermittelt wird, ist für jede mögliche Ausdrucksform [JLS3] § 15 zu entnehmen. 4.7 Fehlerhafte Lokationsinformation für Klassen Im Rahmen der Untersuchung von TGraphen ist aufgefallen, dass im Falle methodenlokal definierter Klassen der voll qualifizierte Klassenname, der im GraBaJa-TGraphen mittels des Attributs fullyQualifiedName für die ClassDefinition erzeugt wird, ggf. uneindeutig sein kann. Das folgende Beispiel veranschaulicht das Problem: 62 package mypackage; public class AeussereKlasse { class InnereKlasse { public String toString(){ return "AuessereKlasse.InnereKlasse"; } } void method() { class InnereKlasse { public String toString(){ return "AuessereKlasse.method().InnereKlasse"; } } } } Generiert man für dieses Beispiel den TGraphen, so werden zwei ClassDefinition-Instanzen erzeugt, deren fullyQualifiedName-Attribut den identischen Wert mypackage.AeussereKlasse.InnereKlasse hat. Dies würde es bei der weiteren Analyse des Quellcodes auf Basis der TGraphen-Repräsentation erschweren, sich jeweils auf die korrekte InnereKlasse zu beziehen. 4.7.1 Abgrenzung Das Problem ist nur für Klassen-Definitionen relevant. Aus [JLS3] § 14.3 bzw. aus dem Fehlen entsprechender Beschreibungen für Interfaces oder Enums geht implizit hervor, dass ausschließlich Klassen-Definitionen und nicht Interface- oder Enum-Definitionen methodenlokal erfolgen können. Der Eclipse-Java-Compiler bestätigt dies durch die Meldung „The member interface ... can only be defined inside a top-level class or interface“ (und analog für Enum-Definitionen). Demgemäß ist das fullyQualifiedName-Attribut ausschließlich für Klassen-Definitionen anzupassen. 4.8 Repräsentation von Java-Elementen externer Bibliotheken Die Möglichkeit zur Ausführung einer bestimmten Refaktorisierung kann von Eigenschaften externer Bibliotheken abhängen, da die Deklarationen (und ggf. auch Referenzen) in diesen Bibliotheken in vielfältiger Weise mit dem eigenen Quelltext in Verbindung stehen können. Da jedoch für externe Bibliotheken der Quellcode nicht vorliegt und der Faktenextraktor des GraBaJa-Projekts nicht in der Lage ist, Fakten aus dem Java-Bytecode (im Folgenden jeweils kurz als „Bytecode“ bezeichnet) zu generieren, wären derartige Eigenschaften des betrachteten SoftwareSystems unzugänglich. Es ist daher ein Faktenextraktor für Java-Bytecode erforderlich, welcher mindestens diejenigen Programmelemente in den TGraphen überführt, welche von außen potentiell sichtbar sind oder welche selbst Teile des eigenen Quelltexts referenzieren. 63 4.9 Markierung der Veränderlichkeit von Quelltext-Elementen Wie in [STEI2010] beschrieben, erfolgt die Lösung von Refaktorisierungs-Problemen bei einem constraintbasierten Ansatz über Standardalgorithmen, welche die Constraint-Variablen und deren Relationen als Eingabe erhalten. Eine Constraint-Variable steht für ein potentiell veränderliches Quelltext-Element. Beim Generieren der Constraint-Variablen ist es somit notwendig zu wissen, ob das betreffende Quelltext-Element tatsächlich veränderlich oder – wie z. B. bei Elementen der JavaKlassenbibliothek oder aus externen Bibliotheken – einer Änderung durch eine Refaktorisierung gar nicht zugänglich ist. Im TGraphen sind daher die veränderlichen Elemente als solche zu markieren. 4.10 Rückreferenzierung des Quelltexts und Kommentare Die Rückreferenzierung auf den ursprünglichen Quelltext ist gegeben und wurde im Rahmen der Beschreibung des Metamodells im Abschnitt 3.7.2.5. Rückreferenzierung des Quelltexts dargestellt. Ebenso werden Kommentare und ihre Position im Quelltext mittels der Knotentypen SingleLineComment und MultiLineComment und des Kantentypen IsCommentIn im TGraphen repräsentiert. 64 5 Dokumentation der vorgenommenen Anpassungen 5.1 Beispiel für eine Anreicherung In diesem Abschnitt soll ein durchgehendes Beispiel für eine der durchgeführten Anpassungen gegeben werden, die sowohl eine Erweiterung des Metamodells als auch eine Anreicherung des generierten TGraphen erforderte. Gefordert wird gemäß Abschnitt 4.3.2. Implizite KonstruktorDefinitionen die Aufnahme impliziter Konstruktor-Definitionen in den TGraphen und ihre Markierung als implizit, d. h. im expliziten Quelltext nicht vorhanden. Zu diesem Zweck ist es zunächst notwendig, ein neues Attribut implicit für ConstructorDefinition-Instanzen einzuführen. In der Schemadatei wird hierfür der Spezifikation von ConstructorDefinition dieses Attribut hinzugefügt: VertexClass ConstructorDefinition : Member { implicit : Boolean }; Nach einem GraBaJa-Build steht dieses Attribut zur Verfügung. Um alle impliziten Konstruktor-Definitionen in den TGraphen aufzunehmen, müssen nun die ClassDefinition-Instanzen durchlaufen und einzeln überprüft werden. Das Finden aller ClassDefinition-Instanzen des TGraphen ist mittels einer GReQL-Abfrage möglich: GreqlEvaluator eval = new GreqlEvaluator( "from x:V{ClassDefinition}" + " reportSet x" + " end", tgraph, null); eval.startEvaluation(); Set<ClassDefinition> cdset = new HashSet<ClassDefinition>(); for (JValue res : (JValueSet)eval.getEvaluationResult()) { cdset.add((ClassDefinition)res.toObject()); } Die Konvertierung von JValue-Objekten in ClassDefinition-Objekte ist dabei notwendig, da der GReQL-Auswerter ein JValueSet generiert. Die ClassDefinition-Objekte können nun einzeln daraufhin überprüft werden, ob eine implizite Konstruktor-Definition in den TGraphen aufzunehmen ist. Dies ist genau dann der Fall, wenn noch keine explizite Konstruktor-Definition vorliegt. Der Pfad von einer ClassDefinition zu einer ConstructorDefinition ist eindeutig definiert, so dass hier die reachableVertices()-Methode zum Einsatz kommen kann: classdef.reachableVertices(ConstructorDefinition.class, new PathElement(IsClassBlockOf.class, EdgeDirection.IN), new PathElement(IsMemberOf.class, EdgeDirection.IN)); Ist das gelieferte Set leer, so muss eine implizite Konstruktor-Definition in den TGraphen integriert werden. Zu diesem Zweck ist zunächst der Block der Klasse zu besorgen, in welchen die Konstruktor-Definition aufzunehmen ist: 65 Set<Block> blockset = classdef.reachableVertices(Block.class, new PathElement(IsClassBlockOf.class, EdgeDirection.IN)); Aus diesem Set kann das einzige Ergebnis-Element verwendet werden, da es zu jeder Klasse nur einen Block geben kann. Nun werden die neuen Instanzen erzeugt und verknüpft: ConstructorDefinition constrdef = tgraph.createConstructorDefinition(); Identifier identifier = tgraph.createIdentifier(); identifier.set_name(classdef.get_name()); Block body = tgraph.createBlock(); tgraph.createIsNameOfConstructor(identifier, constrdef); tgraph.createIsBodyOfConstructor(body, constrdef); constrdef.set_implicit(true); Hierdurch werden zunächst Instanzen des Typs ConstructorDefinition und Identifier erzeugt, die mittels einer IsNameOfConstructor-Kante verknüpft werden. Für den Konstruktor wird ein leerer Block erzeugt, welcher mittels IsBodyOfConstructor mit diesem verknüpft wird. Schließlich wird das neue implicit-Attribut gesetzt. Die ConstructorDefinition ist nun noch dem oben gefundenen Block der gerade betrachteten ClassDefinition zuzuordnen, indem eine IsMemberOf-Kante zwischen diesen erzeugt wird. Damit ist die Anreicherung abgeschlossen: tgraph.createIsMemberOf(constrdef, block); 5.2 Vorbereitung des TGraphen Für einige der vorgenommenen Anpassungen hat es sich der folgende Sachverhalt als problematisch erwiesen: • Klassen-Definitionen und der durch die Klasse repräsentierte Typ werden im TGraphen durch zwei unterschiedliche Knotentypen repräsentiert: Die Klassen-Definition selbst als ClassDefinition und der durch sie repräsentierte Typ als QualifiedType. • Der GraBaJa-Faktenextraktor erzeugt jedoch nicht in jedem Fall beide Instanzen. Existiert im Graphen keine Typ-Referenz, so wird nur der ClassDefinition-Knoten erzeugt. Soll nun im Laufe des Anreicherungsvorgangs, etwa durch zusätzlich aufgenommene Deklarationen, eine Typ-Referenz zu einer Klasse hergestellt werden, so wäre immer zunächst zu prüfen, ob der QualifiedType-Knoten auch bereits im TGraphen verfügbar ist. Um für alle Abfragen und Anreicherungen zuverlässig davon ausgehen zu können, dass zu jeder ClassDefinition auch ein QualifiedType verfügbar ist, wurde der TGraph zu Beginn des Anreicherungsvorgangs um diese Knoten ergänzt. 5.3 Anreicherung der impliziten Quelltext-Elemente Alle im Kapitel 4.3. Repräsentation impliziter Quelltext-Elemente geforderten Quelltext-Elemente wurden in den TGraphen aufgenommen. Um diese als implizit kennzeichnen zu können, wurde wie bereits im Kapitel 5.1. Beispiel für eine Anreicherung gezeigt ein Attribut namens implicit für die betroffenen Knoten-Typen in das Metamodell des TGraphen aufgenommen. 66 5.4 Umsetzung der Override-Beziehung Um die Anforderungen aus Kapitel 4.4. Repräsentation der Override-Beziehung zu erfüllen, wurden im TGraphen die Kantentypen IsOverrdingMethodOf und IsOverriddenMethodBy eingeführt. Im Rahmen der Anreicherung werden alle Konstellationen zwischen Klassen und Superklassen, Klassen und Interfaces sowie Interfaces und Superinterfaces wie folgt berücksichtigt: • In Klassen definierte Methoden werden verknüpft mit ◦ evtl. überschriebenen Methoden in einer ihrer Superklassen (extends-Beziehung zwischen Klassen) ◦ evtl. überschriebenen Methoden in einem der implementierten Interfaces (implementsBeziehung zwischen Klassen und Interfaces) oder deren Superinterfaces (extendsBeziehung zwischen Interfaces). • In Interfaces definierte Methoden werden mit evtl. überschriebenen Methoden in einem ihrer Superinterfaces (extends-Beziehung zwischen Interfaces) verknüpft. Bei der Feststellung der Override-Beziehung durch Vergleich der Methoden-Signaturen wird Type Erasure berücksichtigt. Die Override-Beziehung ist damit vollständig gemäß [JLS3] § 8.4.8.1 umgesetzt. • 5.5 Umsetzung der Referenzierung von Empfänger-Typen Um die Beziehung zu Empfänger-Typen im TGraphen repräsentieren zu können, wurden die folgenden Kantentypen in das Metamodell des TGraphen aufgenommen: QualifiedType ← IsReceiverOfInvokedMethod ← MethodInvocation TypeSpecification ← IsReceiverOfAccessedField ← FieldAccess Für Methoden-Aufrufe kommt als Empfänger-Typ nur ein Referenz-Typ (QualifiedType) in Betracht, während bei Feld-Zugriffen auch ein primitiver Datentyp (BuiltInType) möglich ist. Daher wird für Feldzugriffe der gemeinsame Supertyp von QualifiedType und BuiltInType referenziert. Dieser Supertyp ist TypeSpecification. Für die beiden neuen Kantentypen wurde der gemeinsame abstrakte Supertyp IsReceiverOf deklariert. Dies ermöglicht es, unabhängig vom Referenztyp (Methoden-Aufruf oder Feld-Zugriff) nach Empfänger-Typen zu suchen. 5.5.1 Einschränkungen der umgesetzten Anreicherung Der <Ausdruck> eines Methoden-Aufrufs der Form <Ausdruck>.<Methodenname>(...) kann zahlreiche unterschiedliche Formen annehmen. Die Regeln zur Ermittlung des Typs dieses Ausdrucks nehmen weite Teile des umfangreichen Kapitels [JLS3] § 15 in Anspruch, so dass die Ermittlung des Empfänger-Typs für alle potentiellen Ausdrucks-Arten den Rahmen dieser Arbeit überschritten hätte. Die Anreicherung der IsReceiverOf*-Kanten erfolgte daher mit den folgenden Einschränkungen: • Für Feld-Zugriffe erfolgt die Anreicherung der IsReceiverOfAccessedField-Kante ohne Ausnahme. 67 • • Für Konstruktor-Aufrufe erfolgt die Anreicherung der IsReceiverOfInvokedMethodKante ohne Ausnahme. Für Methoden-Aufrufe wurde die folgende Auswahl getroffen: m() feldname.m() this.m() super.m() m1().m2() // Nur dann, wenn statische Bindung zu m1 repräsentiert ist. Klassenname.m() 5.6 Anpassung der Lokationsinformation für Klassen Das im Kapitel 4.7. Fehlerhafte Lokationsinformation für Klassen wurde durch eine Neuermittlung der Pfadinformation für alle Klassen gelöst. Eine eindeutige Abbildung des voll qualifizierten Pfades ist wie folgt möglich und wurde vollständig umgesetzt: <package>.<AuessereKlasse>. \ <Methodenname>(<Parametertyp-Liste>).(...).<EigentlicheDeklaration> Dieser voll qualifizierte Name bezieht eventuelle Methoden, in denen Klassen definiert sein können, mit ein. Die Aufnahme der Parametertyp-Liste ermöglicht zudem die Differenzierung der Pfade im Falle überladener Methoden. Jeder Parametertyp ist dabei seinerseits in der voll qualifizierten Form anzugeben, was eine rekursive Anreicherung erfordert. Dabei kann es nicht zu einer Endlosrekursion kommen, da eine methodenlokal definierte Klasse nur innerhalb des Blocks sichtbar ist, in dem sie definiert ist (siehe [JLS3] § 14.3) und somit in der formalen Parameterliste oder gar außerhalb der Methode nicht verwendet werden darf. Es werden ausschließlich diejenigen Klassen-Definitionen modifiziert, die als mutable markiert sind. Für Quelltext-Elemente, die nicht mutable sind, liegt nur eine unvollständige Repräsentation der Information vor, die für die Ermittlung des voll qualifizierten Namens notwendig wäre. 5.7 Prototypische Umsetzung eines Bytecode-Faktenextraktors Der im Kapitel 4.8. Repräsentation von Java-Elementen externer Bibliotheken geforderte Faktenextraktor für Java-Bytecode wurde im Rahmen dieser Arbeit prototypisch umgesetzt. Die gewählte Lösung und der Umfang der Implementierung wird im Folgenden beschrieben. 5.7.1 Nutzung von BCEL zum Einlesen des Bytecodes Für das Einlesen von Bytecode und die Extraktion der darin enthaltenen Java-Elemente wurde die Bibliothek BCEL („Byte Code Engineering Library“, siehe [URL:BCEL]) ausgewählt. Da sich bereits nach kurzer Evaluierung herausstellte, dass die von BCEL angebotenen Möglichkeiten für die Zwecke dieser Arbeit ausreichend sind, wurden keine weiteren Werkzeuge evaluiert und die Entscheidung für die Nutzung von BCEL getroffen. 68 5.7.2 Repräsentierte Elemente und Beziehungen Eine vollständige Repräsentation der in externen Bibliotheken enthaltenen Java-Elemente ist zum einen zur Generierung von Sichtbarkeitsconstraints nicht notwendig, zum anderen hätte dies den Rahmen dieser Arbeit überschritten. Das Erzeugen von Teilgraphen aus Bytecode stellt daher im Rahmen dieser Arbeit primär einen proof of concept dar, der für eine produktive Nutzung noch im Detail ausgearbeitet werden müsste. 5.7.2.1 Nur public und protected Elemente Es wurde davon ausgegangen, dass eigen-implementierte Quelltexte nur public oder protected deklarierte Elemente externer Bibliotheken nutzen. Der Ausnahmefall, dass ein eigenimplementierter Quelltext innerhalb des Packages einer externen Bibliothek definiert ist, wurde daher ignoriert. Dies gilt sowohl für die repräsentierten Typen als auch für die darin deklarierten Methoden und Variablen. 5.7.2.2 Implizitheit wird nicht berücksichtigt Ob das jeweilige Element im ursprünglichen Quellcode nur implizit oder explizit enthalten war, ist dem Bytecode nicht mehr zu entnehmen und hat für die Constraint-Generierung keine Bedeutung. Die Information würde lediglich beim Zurückschreiben von Änderungen eine Rolle spielen. Im Rahmen von Refaktorisierungen werden jedoch keine Änderungen an Elementen des Bytecodes vorgenommen. Das implicit-Attribut (siehe Kapitel 5.3. Anreicherung der impliziten QuelltextElemente) erhält für alle erzeugten Elemente den Wert false. 5.7.2.3 Klassen und Interfaces Es werden alle (public oder protected) Klassen und Interfaces aus dem Bytecode ausgelesen und in den TGraphen überführt. Enum-Definitionen sowie die Definition von Annotationstypen bleiben unberücksichtigt. Alle Modifier der Klassen und Interfaces werden repräsentiert. 5.7.2.4 Methoden- und Variablen-Deklarationen Es werden alle (public oder protected) Methoden und Variablen-Deklarationen in den TGraphen überführt. Methoden werden mit allen Modifiern, ihrem Rückgabetyp und der Liste der formalen Parameter erzeugt. Die Repräsentation von Variablen erfolgt mit ihrem deklarierten Typen. Für die im Rahmen von Methoden- oder Variablen-Deklarationen verwendeten Typen gelten einige Sonderbehandlungen: • • Diese werden auch dann im TGraphen repräsentiert, wenn sie innerhalb einer externen Bibliothek nicht als public oder protected deklariert sind. Ansonsten wäre eine sinnvolle Repräsentation von Methoden- oder Variablen-Deklarationen nicht möglich. Die Typen werden ausschließlich über eine QualifiedType-Instanz repräsentiert, nicht über eine zugehörige ClassDefinition oder InterfaceDefinition. Letztere werden nur dann erzeugt, wenn die Klasse oder das Interface in der externen Bibliothek public oder protected deklariert ist. Dies lässt sich wie folgt rechtfertigen: Die QualifiedType-Instanz enthält zum einen den voll qualifizierten Namen des Typen und 69 reicht somit aus, um ihn eindeutig zu identifizieren. Zum anderen werden auch SupertypBeziehungen über Kanten zur QualifiedType-Instanz abgebildet, so dass die eigentlichen Klassen- und Interface-Deklarationen auch zur Ermittlung dieser Beziehungen überflüssig sind. 5.7.2.5 Supertyp-Beziehungen Supertyp-Beziehungen zwischen Klassen und Interfaces werden rekursiv in den TGraphen überführt. Sowohl alle Superklassen als auch alle implementierten Interfaces einer Klasse werden erzeugt. Für Interfaces werden alle erweiterten Interfaces in den TGraphen aufgenommen. Es werden zum einen alle Supertyp-Beziehungen (zu public oder protected deklarierten Typen) innerhalb des Bytecodes in den TGraphen überführt. Zum anderen sorgt bereits der Faktenextraktor dafür, dass explizite Supertyp-Beziehungen vom Quelltext in die externe Bibliothek im TGraphen repräsentiert sind. Denn der Faktenextraktor erzeugt in solchen Fällen für die Supertypen Instanzen, ohne ihren Block und eventuelle Modifier zu kennen. Existieren solche Instanzen bereits, so werden sie verwendet und um die im Bytecode ausgelesenen Modifier angereichert. 5.8 mutable-Attribut zur Markierung der Veränderlichkeit Um veränderliche Quelltext-Elemente wie im Kapitel 4.9. Markierung der Veränderlichkeit von Quelltext-Elementen gefordert als solche markieren zu können, wurde ein neues Attribut namens mutable für alle Knoten und Kanten eingeführt. Dabei wurde entschieden, dass nur solche Knoten als mutable markiert werden können, die in einer der für das Einlesen des TGraphen angegebenen Quelldateien enthalten sind. Für Kanten wurde nach folgender Regel verfahren: Ist einer der beiden Knoten, welche die Kante verknüpft, mutable, so ist auch die Kante mutable. Diese Regel lässt sich wie folgt motivieren: • • • 5.9 Alle Beziehungen zwischen Knoten, die sämtlich nicht veränderlich sind (also aus externen Bibliotheken oder der Java-Klassenbibliothek stammen), sind ebenfalls nicht veränderlich. Alle Beziehungen zwischen Knoten, die sämtlich veränderlich sind, sind ebenfalls veränderlich. Existiert zwischen einem veränderlichen und einem nicht veränderlichen Knoten eine Beziehung, so muss davon ausgegangen werden, dass bei Modifikation des veränderlichen Knoten auch die Kante zu ändern ist. Zum Beispiel kann der veränderliche Knoten gelöscht werden, dann wäre auch die Kante zu löschen. Wäre die Kante nicht veränderlich, so würde dies die Modifikationsmöglichkeiten des veränderlichen Knotens unzulässig einschränken, was nicht einzusehen ist. Reihenfolge der Anreicherung Die Reihenfolge der Anreicherung ist relevant, da zwischen den unterschiedlichen ergänzten JavaElementen Abhängigkeiten bestehen. Die gewählte Reihenfolge wird im Folgenden erläutert: 1. Markierung der Veränderlichkeit von Quelltext-Elementen: Diese sollte vor dem Einlesen des Bytecodes erfolgen, da alle aus Bytecode erzeugten Elemente nicht veränderlich sind. 2. Bytecode einlesen: Das Einlesen sollte vor dem Erzeugen der impliziten Quelltext-Elemente erfolgen, da beispielsweise die impliziten super()-Aufrufe an Konstruktoren binden können, die im Bytecode deklariert sind. 3. Implizite Java-Elemente: Die impliziten Java-Elemente werden nach der Extraktion des 70 Bytecodes in dieser Reihenfolge erzeugt: • Implizite Object-Erweiterung. Implizite Konstruktoren: Diese müssen vor den impliziten super()-Aufrufen erzeugt werden, da erst im Anschluss den impliziten Konstruktoren auch implizite super()Aufrufe hinzugefügt werden können. • Implizite super()-Aufrufe, Modifier sowie Erweiterung von Object und Enum. 4. Override-Beziehung: Die Override-Beziehung kann erst nach der Ergänzung der impliziten Modifier sowie der impliziten Erweiterung von Object und Enum korrekt für alle Elemente ermittelt werden. 5. Referenzierung der Empfänger. 6. Anpassung des voll qualifizierten Pfades. • 71 6 Exemplarische Constraint-Generierung mittels TGraph In diesem Kapitel soll am Beispiel der Constraint-Regel Sub-1 gezeigt werden, wie mittels des erzeugten TGraphen die notwendigen Fakten zur Constraint-Generierung erzeugt werden können. Gegeben seien die folgenden Java-Dateien: Superclass.java: public class Superclass { void m0(Object o) {} private void m1(int i) {} protected void m2() {} public String m3(String s) {return null;} } Subclass.java: public class Subclass extends Superclass { @Override void m0(Object o) {} private void m1(int i) {} @Override public void m2() {} @Override public String m3(String s) {return null;} } Die Constraint-Regel Sub-1 verlangt, dass der Access-Modifier einer überschreibenden Methode mindestens so groß sein muss wie der Access-Modifier der überschriebenen Methode. Im Beispiel kommen drei Override-Beziehungen vor. Durch die im Kapitel 5.4. Umsetzung der OverrideBeziehung beschriebenen Anpassungen wurde die Override-Beziehung in den TGraphen aufgenommen und kann nun effizient ausgelesen werden. Das folgende Codefragment zeigt die grundlegende Vorgehensweise: public void generateSub1(Java5 tgraph) { for (MethodDeclaration overriding : findAllMethodDeclarations(tgraph)) { for (IsOverridingMethodOf iomo : overriding.getIsOverridingMethodOfIncidences(EdgeDirection.OUT)) { MethodDeclaration overridden = (MethodDeclaration)iomo.getThat(); // So saehe die Constraint-Erzeugung aus: addSub1Constraint(overriding, overridden); // Fuer unsere Zwecke soll eine Ausgabe der Access-Modifier ausreichen: printResult(getAccessModifierOfMethod(overridden), getAccessModifierOfMethod(overriding)); } } } 72 addSub1Constraint(...) entspricht dabei einer gleichnamigen Methode der Klasse Sub1Visitor aus der Implementierung der Access Modifier Modifier-Refaktorisierung, wurde aber im Rahmen dieser Arbeit nicht ausimplementiert. Die Schnittstellen-Methode getIsOverridingMethodOfIncidences(...) ermöglicht das einfache Auffinden aller Override-Beziehungen für jede betrachtete Methoden-Deklaration. Die Verfügbarkeit dieser Methode wurde durch die Aufnahme des Kantentyps IsOverridingMethodOf im Metamodell des TGraphen erreicht. Die Methode findAllMethodDeclarations(...) wird mittels einer GReQL-Abfage wie folgt implementiert: private Set<MethodDeclaration> findAllMethodDeclarations(Java5 tgraph) { GreqlEvaluator eval = new GreqlEvaluator( "from x:V{MethodDeclaration}" + " reportSet x" + " end", tgraph, null); eval.startEvaluation(); Set<MethodDeclaration> methoddeclarations = new HashSet<MethodDeclaration>(); for (JValue res : (JValueSet)eval.getEvaluationResult()) { methoddeclarations.add((MethodDeclaration)res.toObject()); } return methoddeclarations; } Um das gefundene Ergebnis für das Quelltext-Beispiel anschaulich zu machen, wurde eine kurze Textausgabe der Access-Modifier für die Methoden-Paare mit Override-Beziehung implementiert. Die Ermittlung der Access-Modifier kann dabei über eine Methode wie die folgende umgesetzt werden: private String getAccessModifierOfMethod(MethodDeclaration method) { String modifier = "DEFAULT"; for (IsModifierOfMethod imom : method.getIsModifierOfMethodIncidences(EdgeDirection.IN)) { Modifier mod = (Modifier)imom.getThat(); Modifiers type = mod.get_type(); if (type.equals(Modifiers.PUBLIC) || type.equals(Modifiers.PROTECTED) || type.equals(Modifiers.PRIVATE)) { modifier = type.toString(); break; } } return modifier; } 73 Eine Textausgabe könnte nun wie folgt aussehen: Sub-1: Ueberschreibende Methode: Ueberschriebene Methode : Sub-1: Ueberschreibende Methode: Ueberschriebene Methode : Sub-1: Ueberschreibende Methode: Ueberschriebene Methode : 6.1 PUBLIC PUBLIC PUBLIC PROTECTED DEFAULT DEFAULT Laufzeitverbesserte Variante Der oben angegebene Beispiel-Quelltext iteriert mittels der Methode findAllMethodDeclarations(...) über alle Methoden-Deklarationen des TGraphen. Dies ist jedoch in der Regel für eine konkrete Refaktorisierung ein unnötig großer Aufwand, da von der durchzuführenden Änderung meist nur eine kleine Auswahl von Methoden-Deklarationen betroffen ist. In [STEI2011] wird daher vorgeschlagen, nur diejenigen Constraints zu generieren, die tatsächlich für die Refaktorisierung notwendig sind. Wie dies auf der Basis von TGraphen aussehen könnte, soll das folgende Beispiel zeigen. Vorgegeben sei, dass durch die Refaktorisierung die Sichtbarkeit einer nichtstatischen MethodenDeklaration reduziert werden soll. Mit Blick auf die Sub-1-Constraint-Regel sind von dieser Änderung alle Methoden betroffen, welche durch die betreffende Methode überschrieben werden. Die Reduktion der Sichtbarkeit könnte dazu führen, dass nach der Änderung keine OverrideBeziehung mehr zwischen den Methoden besteht. Für diese spezielle Refaktorisierung könnte die Ermittlung der betroffenen Methoden-Paare wie folgt aussehen: public void generateSub1ReducedAccessibility(Java5 tgraph, MethodDeclaration reduced) { for (IsOverridingMethodOf iomo : reduced.getIsOverridingMethodOfIncidences( EdgeDirection.OUT)) { MethodDeclaration overridden = (MethodDeclaration)iomo.getThat(); addSub1Constraint(reduced, overridden); } } Mittels der Schnittstellen-Methode getIsOverridingMethodOfIncidences(...) werden ausschließlich die überschriebenen Methoden gefunden und durchlaufen, so dass keine überflüssigen Constraints erzeugt werden. 74 7 Diskussion Im Folgenden sollen wesentliche Erfahrungen, die im Rahmen der zuvor beschriebenen Implementierungsarbeiten gemacht wurden, wiedergegeben und bewertet werden. Des Weiteren werden durchgeführte Performance-Messungen für die Faktenextraktion dargestellt und eingeschätzt. 7.1 Allgemeine Eignung für die Entwicklungsarbeit In diesem Abschnitt werden einige Qualitäts-Kriterien beschrieben, die für Entwickler, die auf der Basis des Graphenlabors (Refaktorisierungs-)Werkzeuge entwickeln möchten, besonders relevant sind. Die hier gegebenen Einschätzungen erheben keinen Anspruch auf Vollständigkeit und sind vielmehr im Sinne eines Erfahrungsberichts zu verstehen. 7.1.1 Verständlichkeit und Benutzbarkeit der Schnittstellen Das Graphenlabor stellt dem Entwickler die Datenstruktur TGraph zur Verfügung und bietet für dessen Handhabung umfangreiche Schnittstellen an. Diese Schnittstellen lassen sich wie folgt grob unterteilen und werden in den folgenden Abschnitten separat diskutiert: • • • Methoden zum Navigieren im TGraphen Die Nutzung von GReQL Util-Methoden 7.1.1.1 Methoden zum Navigieren im TGraphen Das Graphenlabor stellt eine ganze Reihe unterschiedlicher Methoden für das Navigieren im TGraphen zur Verfügung, die dem Entwickler lediglich die Qual der Wahl lassen. Nach einiger Übung erweist es sich als unproblematisch, Knoten oder Kanten im Graphen zu finden – sei es in unmittelbarer Nachbarschaft oder über längere Pfade hinweg. Die Eigenschaften des TGraphen bieten hierfür umfassende Möglichkeiten: Die Typisierung ermöglicht die Nutzung von Methoden der Art get<Kantentyp>Incidences() von einem Knoten aus, die per Codegenerator aus dem Metamodell miterzeugt werden. Ist eine derart spezielle Navigation einmal nicht gewünscht, ermöglicht die Ordnung des TGraphen die Verwendung verschiedener getNext*()- oder getFirst*()-Methoden, um Knoten oder Kanten effizient zu iterieren. Bei der Suche nach speziellen Pfaden von einem Knoten zu einem anderen hat sich die reachableVertices()Methode als besonders hilfreich erwiesen. Sie erledigt über eine simple Syntax, wofür ansonsten ein vergleichsweise aufwändiges Traversieren des Graphen nötig wäre. Und helfen all diese speziellen Anwendungsfälle nicht weiter, so bieten GReQL-basierte Abfragen schließlich die maximale Flexibilität, um beliebig komplexe Suchabfragen zu formulieren. Es gibt allerdings auch noch Spielraum für Verbesserungen. So liefern etwa einige Abfragemethoden immer eine typisierte Collection, obwohl sogar das Metamodell mehrere Treffer für eine Abfrage verbietet. So kann z. B. zu einer ClassDefinition nur genau ein Block existieren. Die folgende Abfrage 75 classdefinition.reachableVertices(Block.class, new PathElement(IsClassBlockOf.class, EdgeDirection.IN)); liefert aber nichtsdestoweniger ein Set<Block>, aus welchem man sich anschließend das einzige Element herausnehmen muss. So entsteht wiederholt Boilerplate Code, der kompakte Lösungen komplexer aussehen lässt als nötig. Wünschenswert wäre generell, die jeweiligen Methoden in einer Version zur Verfügung zu stellen, die genau ein Element des erfragten Typs liefert – auch in Fällen, in denen zumindest syntaktisch mehrere Treffer möglich sind. Denn in der Praxis kommt es häufig vor, dass auch in solchen Fällen nur genau ein Element gesucht wird, das der Entwickler auch hinreichend genau spezifizieren kann, um sicher zu sein, dass es nur diesen einen Treffer gibt. Solche Methoden könnten z. B. simple Wrapper um die bereits existierenden Methoden sein und für den Fall, dass tatsächlich einmal mehr als ein Element gefunden wird, eine Exception werfen. Die Ableitung des Metamodells aus der ANTLR-Javagrammatik und die Notwendigkeit zur Repräsentation auch feingranularer Syntax-Elemente bringt es zudem mit sich, dass das Navigieren im Graphen gelegentlich etwas komplex anmutet. Für analytische Zwecke wäre es wünschenswert, Beziehungen in den TGraphen aufzunehmen oder Schnittstellen-Methoden anzubieten, die typische analytische Fragestellungen widerspiegeln. Um beispielsweise alle Methoden einer Klasse zu erhalten, muss man umständlich über eine IsClassBlockOf-Kante und eine Block-Instanz navigieren, da die MethodDefinition der ClassDefinition nicht direkt zugeordnet ist. Im Quellcode sieht eine solche Abfrage so aus: classdefinition.reachableVertices(MethodDeclaration.class, new PathElement(IsClassBlockOf.class, EdgeDirection.IN), new PathElement(IsMemberOf.class, EdgeDirection.IN)); Dies ist eine vergleichsweise aufwändige Formulierung der sicher häufig gestellten Frage nach den Methoden einer Klasse, die sich prinzipiell als simpler Methoden-Aufruf denken ließe: // Diese Methode existiert aber nicht: classdefinition.getMethodDeclarations(); // Die Methode koennte auch ueberladen sein, um ueber ganz bestimmte // Methoden einer Klasse iterieren zu koennen, z. B.: classdefinition.getMethodDeclarations(Modifiers.PUBLIC); classdefinition.getMethodDeclarations(Modifiers.STATIC); Für analytische Zwecke ist die Existenz bestimmter Elemente im Metamodell irrelevant. (Im obigen Beispiel stört die zwischengeschaltete Block-Instanz, da jede Klassen-Definition über einen Block verfügt.) Des Weiteren liegt der Fokus einer Abfrage oftmals auf bestimmten Knoten, die mit einem gegebenen Knoten in Beziehung stehen, und nicht auf dem Pfad, der zu diesen Knoten führt. Höherwertige Schnittstellen-Methoden würden das Navigieren im Javagraphen erleichtern und den Quelltext lesbarer machen. Es folgen einige weitere Beispiele für sinnvolle SchnittstellenMethoden: • • • • • Finde alle Methoden/Felder/Konstruktoren einer Klasse. Finde alle Interfaces, welche von der Klasse implementiert werden. Finde alle Subtypen eines Typs. Finde alle formalen Parameter einer Methode. Finde zu einem gegebenen Element die Klasse, in welcher dieses Element implementiert ist. 76 • • Finde die Klassen- / Interface-Definition zu dem Typ, mit dem eine Variable deklariert ist / welcher der Rückgabetyp einer Methode ist / welcher als Typ eines Methoden-Parameters deklariert ist usw. Finde alle Modifier eines Deklarationselements. Finde den Access-Modifier eines Deklarationselements. 7.1.1.2 Die Nutzung von GReQL Mit GReQL steht eine Abfragesprache zur Verfügung, welche die Mächtigkeit regulärer Ausdrücke aufweist. Hinsichtlich der Leistungsfähigkeit der Sprache bleiben damit keine Wünsche offen. Die Verfügbarkeit einer Abfragesprache legt die Separierung von Abfrage-Code und dem Rest der Anwendung im Sinne eines Data Access Object (DAO)-Patterns nahe (siehe den J2EE-PatternKatalog in [ALUR2002]), wie man dies auch für SQL- oder Hibernate-Queries häufig sieht. Dabei werden alle Queries in einer DAO-Klasse implementiert, in welcher somit die gesamte AbfrageLogik verwaltet werden kann. Dies fördert nicht nur die Wiederverwendung, sondern ermöglicht auch z. B. im Falle späterer Metamodell-Änderungen, die eine Anpassung mehrerer Queries nach sich ziehen, dass diese Anpassungen an genau einem Ort erfolgen können. Die Sprachsyntax von GReQL ist gut verständlich und in vernünftiger Zeit erlernbar. Die Anlehnung an die Syntax regulärer Ausdrücke für Zeichenketten, insbesondere die Operatoren * und +, ermöglichen ein intuitives Verständnis der Pfadausdrücke. Andererseits bestehen Pfadausdrücke auch zu großen Teilen aus Syntax-Elementen, die man sich erarbeiten muss und mit denen man Erfahrungen zu sammeln hat, so dass eine gewisse steile Lernkurve in den ersten Entwicklungstagen mit GReQL nicht vermieden werden kann. Hinzu kommt, dass eine effiziente Formulierung von Abfragen auch eine detaillierte Kenntnis des Metamodells erfordert und auch dessen Kennenlernen Zeit in Anspruch nimmt. 7.1.1.3 Util-Methoden Das Graphenlabor bietet eine Reihe von Hilfswerkzeugen für den Umgang mit Graphen auf höherer Ebene an. So existieren z. B. diverse Export-Formate, von denen sich insbesondere der Export in das DOT-Format als nützlich erwiesen hat. Das DOT-Format lässt sich mittels frei verfügbarer Werkzeuge wie Graphviz (siehe [URL:GRAPHVIZ]) in eine Abbildung des generierten TGraphen konvertieren, die in einer beliebigen Grafik-Software betrachtet werden kann. Gerade für das Verstehen einfacher Zusammenhänge hat sich diese Vorgehensweise als brauchbarer erwiesen als der in das Graphenlabor integrierte TGraph-Browser. Dieser ermöglicht zwar eine interaktive Ansicht des Graphen auch unter Nutzung von GReQL-Abfragen, doch ein schnelles Hin- und HerNavigieren im TGraphen mittels Mausklicks oder auch ein zügiges Aus- und Ein-Zoomen gelingen in einer Grafik-Software besser. 7.1.2 Verwendbarkeit des Metamodells Das GraBaJa-Metamodell hat sich als solider Ausgangspunkt erwiesen. Verbesserungspotential liegt im Detail. Im Folgenden werden einige Ideen für mögliche Verbesserungen beschrieben, die sich im Rahmen der Entwicklungsarbeit ergeben haben. 77 7.1.2.1 Wahl der Typ-Bezeichner Die Terminologie wurde nicht in jeder Hinsicht kompatibel zur JLS gewählt, was gelegentlich das Verständnis etwas erschwert. Beispielsweise sucht man den Begriff AnnotationField nicht nur in der [JLS3] vergeblich – er ist vielmehr im gesamten englischen Sprachraum unüblich. Auch die namentliche Unterscheidung zwischen Definitionen und Deklarationen (z. B. bei MethodDeclaration und MethodDefinition) führt gelegentlich zu sprachlichen Schwierigkeiten, wenn man sich auf die JLS beziehen will, in der diese Unterschiede nicht klar spezifiziert sind und die oft auch dann von method declarations spricht, wenn das GraBaJaMetamodell eine MethodDefinition erzeugt. Etwas unpassend erscheint auch die Verwendung des Typs IsSuperClassOfInterface für die extends-Beziehung zwischen Interfaces. Da die Benennungen der Typen größtenteils aus der für ANTLR verwendeten Javagrammatik stammen bzw. von dort übernommen wurden, ist die primäre Ursache für diese Benennungen dort zu suchen. 7.1.2.2 Kompositionen statt Aggregationen Einige Aggregationen hätten als Komposition modelliert werden können. Bei einer Komposition hängt die Lebensdauer eines Teilobjekts von der Lebensdauer des umfassenden Container-Objekts ab. Dies ermöglicht die Nutzung entsprechender Operationen (wie z. B. dem Löschen des Container-Objekts inklusive aller Teilobjekte durch einen einzigen Methoden-Aufruf) und hilft, inkonsistente Graphen-Zustände zu vermeiden. 7.1.3 Reifegrad Für die Entscheidung über die Verwendung einer Bibliothek ist es oftmals interessant, ihren Reifegrad zu beurteilen: Weist die Bibliothek noch „Kinderkrankheiten“ auf, weil sie bisher kaum verwendet wurde? Bei der Beurteilung des Reifegrads muss zwischen dem Graphenlabor und GraBaJa unterschieden werden. Während das Graphenlabor als ausgereift bezeichnet werden kann und im Rahmen der Untersuchungen für diese Arbeit keinerlei Fehler festgestellt wurde, welcher der Funktionalität des Graphenlabors zuzuordnen ist, sieht dies für GraBaJa anders aus: • • • • • • Die Konstruktion voll qualifizierter Pfade war unvollständig, siehe Kapitel 4.7. Fehlerhafte Lokationsinformation für Klassen. Das Setzen der voll qualifizierten Pfade war fehlerhaft für Instanzen des Typs QualifiedType. Während beispielsweise die zugehörige ClassDefinition einen korrekten Pfad aufwies, wurde in QualifiedType lediglich der Typ-Name ohne Pfad abgelegt. Auf Verbesserungspotential des Metamodells wurde oben bereits hingewiesen. Die Grammatik-Spezifikation für ANTLR weist aktuell knapp zwanzig unerledigte TodoVermerke und als „quick fix“ kommentierte Stellen auf. Die Codierung des Faktenextraktors auf Basis von ANTLR gilt zudem im betreuenden Lehrgebiet des IST der Universität Koblenz-Landau als schwer zu warten, siehe Abschnitt 7.2.2. Wartbarkeit des Faktenextraktors. Zu GraBaJa existiert über die Studienarbeit [BALD2008] hinaus keinerlei Dokumentation. Da seit dieser Studienarbeit jedoch Änderungen und Bugfixes erfolgt sind, kann der Stand der Dokumentation nicht mehr als aktuell betrachtet werden. 78 • GraBaJa wurde bislang noch in keinem größeren Referenzprojekt eingesetzt. In der Zusammenschau dieser Sachverhalte muss davon ausgegangen werden, dass ein größeres Entwicklungsprojekt auf der Basis von GraBaJa einen gewissen Zusatzaufwand für die Behandlung von Problemen betreiben müsste, die bisher auf Grund mangelnder produktiver Nutzung noch unbemerkt geblieben sind. 7.2 Erweiterbarkeit Die Beurteilung der Erweiterbarkeit von TGraphen fällt geteilt aus. Während Erweiterungen des Metamodells und nachträgliche Erweiterungen des vom Faktenextraktor erzeugten TGraphen durchweg gut unterstützt werden, ist die Erweiterbarkeit des Faktenextraktors als problematisch einzustufen. 7.2.1 Anreicherung des TGraphen Metamodell-Anpassungen: Anpassungen des Metamodells sind nach kurzem Einlesen in die Syntax der Schemadatei problemlos möglich. Die Ergänzung neuer Knoten- und Kantentypen macht dabei nicht nur die neuen Typen für die Verwendung im TGraphen verfügbar, sondern auch eine Reihe praktischer Schnittstellen-Methoden. Zu bedenken ist allerdings, dass MetamodellAnpassungen einen neuen Build des GraBaJa-Projekts erfordern. Factory-Methoden: Für die Integration neuer Instanzen in den TGraphen hat sich die Nutzung von Factory-Methoden der Art Java5.createClassDefinition() oder Java5.createIsMemberOf(Member, Block) als sehr hilfreich erwiesen. Die Nutzung der Factory-Methoden stellt sicher, dass der Graph geordnet bleibt – die Verwaltung der Knoten-, Kanten- und Inzidenzreihenfolgen erfolgt für den Entwickler transparent. Erzeugungsmethoden für mehrere zusammenhängende Elemente: In der Regel ist es wenig sinnvoll, einzelne Instanzen isoliert im TGraphen zu erzeugen. So verfügt eine Klasse (ClassDefinition) oder eine Methode (MethodDefinition) immer auch über einen Block (Block). Member (wie z. B. VariableDeclaration) verfügen immer auch über einen Typ (QualifiedType oder BuiltInType) usw. Für solche Konstellationen würde man sich Erzeugungsmethoden wünschen, die syntaktisch eng gekoppelte Instanzen über einen einzigen Aufruf erzeugen. Hierfür sollen einige Beispiele aufgeführt werden: • Die Erzeugung einer Klasse könnte über einen einzigen Aufruf der Art Java5.createClassDefinitionWithBlock() eine ClassDefinition erzeugen, die bereits über eine IsClassBlockOf-Kante mit einem Block verknüpft ist. • Bei der Verknüpfung von Typen stellt sich regelmäßig das Problem, dass man die betreffende QualifiedType-Instanz zunächst im TGraphen finden muss, um sie dann z. B. (bei Variablen-Deklarationen) mittels einer IsTypeOfVariable-Kante zu verknüpfen. Derartige wiederkehrende Fleißarbeiten würde man gerne der Erzeugungsmethode überlassen, indem man die Typen bei der Erzeugung einfach angibt: Java5.createVariableDeclaration(<Deklarierende Klasse>, <Deklarierter Typ>). 79 • Will man einer Klasse ein Member hinzufügen, so muss man sich hierfür zunächst den Block der Klasse besorgen. Dieser Zusatzschritt könnte durch eine Methode Java5.addMemberMethod(<Deklarierende Klasse>, <MethodenDeklaration>) vermieden werden. Zahlreiche weitere Beispiele ließen sich aufzählen. Bei umfangreichen Entwicklungsarbeiten würde dies zum einen TGraphen vermeiden helfen, die syntaktisch inkorrekten Java-Programmen entsprechen, zum anderen wäre der entstehende Quelltext kompakter und besser verständlich. 7.2.2 Wartbarkeit des Faktenextraktors Die im Sinne der Wartbarkeit problematischste Komponente von GraBaJa ist der ANTLR-basierte Faktenextraktor. Der größte Teil von dessen Anwendungslogik ist in der ANTLR-GrammatikSpezifikation java15.tree.g definiert: eine gut 2800 Zeilen lange Datei in spezieller Syntax, deren Details in [URL:ANTLRGRAMMAR] eingesehen werden können. Die hier definierte kontextfreie Grammatik ist durchsetzt mit sogenannten Actions, Java-Fragmenten in geschweiften Klammern, welche u. a. den internen AST und eine Symboltabelle aufbauen, die den Ausgangspunkt für die Erzeugung des TGraphen darstellen. Gespräche mit Mitarbeitern des IST haben ergeben, dass es sich in der Vergangenheit als schwierig erwiesen hat, diese Datei punktuell zu modifizieren. Da es seit dem Abschluss der Arbeit [BALD2008] keine Änderungen der JavaSyntax mehr gegeben hat, bestand hierzu auch keine Notwendigkeit mehr. Wenn jedoch mit der nächsten Sprachversion Java 7 syntaktische Änderungen eintreten, so geht man beim IST derzeit davon aus, dass diese nicht durch Anpassungen des ANTLR-Mechanismus umgesetzt werden, sondern auf Basis eines neu zu entwickelnden Faktenextraktors. 7.3 7.3.1 Performance Rahmenbedingungen Die Performance-Messungen wurden unter folgenden Systemvoraussetzungen durchgeführt: • • • CPU: Intel(R) Core(TM) Duo P8400 2.26 GHZ Arbeitsspeicher: 4 GB Betriebssystem: Windows Vista (32 Bit), Service Pack 2 Als Referenz für die folgende ausführliche Beschreibung wurde der Quelltext des JUnit-Projekts in Version 3.8.2 mittels des GraBaJa-Faktenextraktors eingelesen und der so erzeugte TGraph mit allen implementierten Anreicherungen erweitert. Im Abschnitt 7.3.4. Vergleichsmessungen für verschiedene Quelltexte werden Messungen für weitere Projekte einander gegenübergestellt. Im Rahmen der ersten Performance-Messungen ergab sich, dass das Setzen der mutable-Attribute einen überproportionalen Rechenaufwand verursachte. Da für dieses Setzen sämtliche Knoten und Kanten des TGraphen durchlaufen werden und die Ermittlungslogik jeweils Abfragen an den TGraphen erfordert, stieg die Laufzeit der Anreicherung des TGraphen um ein Vielfaches. Die untenstehenden Laufzeit-Ergebnisse wurden daher ohne das Setzen der mutable-Attribute ermittelt. Für die Problematik der Veränderlichkeit von Java-Elementen muss vor diesem Hintergrund ggf. eine einfachere Lösung gefunden werden. 80 7.3.2 Laufzeit Bereits der Faktenextraktor erzeugt einige Ausgaben zur Laufzeit: processing 50 elements time: 1.328s 1738 type specification(s) to resolve. processing 1738 elements time: 0.484s 615 field accesses to resolve. processing 615 elements time: 0.141s 1754 method invocations to resolve. processing 1754 elements time: 0.204s Insgesamt benötigt die reine Faktenextraktion zwei Sekunden. Inklusive Anreicherung werden vier Sekunden benötigt. Dabei werden 50 Java-Dateien eingelesen und ein TGraph mit rund 51000 Knoten und Kanten erzeugt. 7.3.3 Speicherverbrauch Um einen Einblick in den Speicherverbrauch zu geben, wurde mittels des Monitoring-Werkzeugs JConsole (siehe [URL:JCONSOLE]) der Heap-Verbrauch während der Faktenextraktion inklusive Anreicherung beobachtet. Dies führte zu dem Ergebnis, das in der untenstehenden Abbildung dokumentiert ist. Zu Beginn der Ausführung wurde manuell eine Garbage Collection ausgelöst (Knick nach unten). Der Heap-Verbrauch sank dabei unter 1 MB. Während der Ausführung stieg der Heap-Verbrauch bis knapp unter 10 MB an. Das anschließende Abfallen der Kurve entspricht der Beendigung des Prozesses. 81 Abbildung 9: Heap-Monitoring während der Faktenextraktion des JUnit-Quelltexts 7.3.4 Vergleichsmessungen für verschiedene Quelltexte Projekt Anzahl Anzahl Knoten Laufzeit mit / ohne Dateien und Kanten Anreicherung Maximaler HeapVerbrauch Jester 1.37b 45 ca. 23.000 3s/2s < 10 MB JUnit 3.8.2 50 ca. 51.000 4s/2s < 10 MB HTMLparser 1.6 149 ca. 220.000 24 s / 12 s < 40 MB JHotDraw 6.01b 289 ca. 246.000 33 s / 13 s < 50 MB Eclipse Draw2D 3.4.2 245 ca. 262.000 56 s / 13 s < 50 MB Tabelle 13: Laufzeit- und Speichermessungen für diverse Quelltexte 82 7.3.5 Bewertung der Performance-Messungen Wie sind diese Extraktionsdauern zu bewerten? Sicherlich wird man Wartezeiten von bis zu einer Minute für größere Entwicklungsprojekte bei der Umsetzung interaktiver Werkzeuge vermeiden wollen. Jedoch erscheinen diese Zeiten in Anbetracht von ca. 250.000 repräsentierten Knoten und Kanten nicht unvernünftig hoch. Zudem wurde bereits im Abschnitt 2.3.2. Erweiterte Faktenextraktion und Speicherung in Hashtabellen erwähnt, dass auch ein auf dem Eclipse-AST basierender Ansatz mitunter Extraktionsdauern von mehreren Minuten erforderte, wenn diese Zeiten auch mangels identischer Rahmenbedingungen nur eine vage Vergleichbarkeit ermöglichen. Mehr als die Hälfte der Zeit wird vom Faktenextraktor aufgewandt: Ein Profiling mit dem Werkzeug JProfiler (siehe [URL:JPROFILER]) ergab am Beispiel von JUnit, dass 55% der Zeit für die Faktenextraktion (Parsen der Dateien, Mapping des AST auf den TGraphen, Auflösen der statischen Bindungen) aufgewandt wird. Die nachfolgende Anreicherung erfordert für JUnit ca. 40% der Zeit. Da weder die reine Faktenextraktion noch die implementierten Anreicherungen auf Laufzeit-Aspekte hin optimiert sind, ist durchaus von einigem Optimierungspotential hinsichtlich der Laufzeit auszugehen. Der Speicherverbrauch ist in Anbetracht der großen Zahl von Knoten und Kanten als gering einzustufen. 83 8 Ausblick Die Anreicherungen des TGraphen, die im Rahmen dieser Arbeit vorgenommen wurden, ermöglichen bereits die Generierung von Sichtbarkeitsconstraints für die meisten in der Praxis vorkommenden Situationen. Um alle wesentlichen Aspekte des Problembereichs im Rahmen dieser Arbeit behandeln zu können, wurden einige Anreicherungen jedoch unter Einschränkungen implementiert, so dass durch sie nur die in der Praxis häufigsten Konstellationen abgedeckt sind. Für eine vollständige Umsetzung der Generierung von Sichtbarkeitsconstraints auf der Grundlage von TGraphen sind somit noch einige Implementierungsarbeiten erforderlich, die im Kapitel 8.1. Notwendige Implementierungsarbeiten zusammengefasst werden. Über die Sichtbarkeitsconstraints hinaus war es Ziel dieser Arbeit, die generelle Eignung von TGraphen für den constraintbasierten Refaktorisierungsansatz zu zeigen. Das Kapitel 8.2. Über die Sichtbarkeitsconstraints hinaus zeigt hierzu einige Möglichkeiten auf. 8.1 8.1.1 Notwendige Implementierungsarbeiten Neu-Implementierung der statischen Bindungen Statische Bindungen werden derzeit durch den GraBaJa-Faktenextraktor in den TGraphen eingebracht. Die im Kapitel 4.5. Repräsentation statischer Bindungen durchgeführten Untersuchungen haben gezeigt, dass diese Bindungen größtenteils zuverlässig ermittelt werden, im Einzelfall aber auch von der Bindung gemäß [JLS3] § 15.12 abweichen. Dort wurde zudem bereits im Abschnitt 4.5.3. Ermittlung statischer Bindungen nach Faktenextraktion ausgeführt, dass selbst eine Korrektur des Faktenextraktors nicht das Problem lösen würde, dass statische Bindungen auch für Deklarationen und Referenzen ermittelt werden müssen, die nach der Faktenextraktion in den TGraphen eingebracht werden. Um TGraphen produktiv als Fakten-Basis für Refaktorisierungs-Werkzeuge nutzen zu können, wäre es demnach erforderlich, die statischen Bindungen von Methoden-Aufrufen und Feld-Zugriffen außerhalb des Faktenextraktors und ausschließlich auf der Basis der im TGraphen repräsentierten Information neu zu implementieren. Der GraBaJa-Faktenextraktor sollte ausschließlich zur Extraktion der syntaktischen Quelltext-Fakten dienen. Jegliche Anreicherung um abgeleitete Informationen sollte allein auf der Basis der im TGraphen zur Verfügung stehenden Information erfolgen, um auch nachträgliche Änderungen des TGraphen neu analysieren und die Anreicherung auf dieser Grundlage wieder vervollständigen zu können. 8.1.2 Vervollständigung der Referenzierung von Empfänger-Typen Die Referenzierung von Empfänger-Typen erfolgt für Feldzugriffe und Konstruktor-Aufrufe vollständig. Für Methoden-Aufrufe wurde hingegen eine Auswahl der am häufigsten vorkommenden Aufruf-Formen für die Implementierung ausgewählt und im Abschnitt 5.5.1. Einschränkungen der umgesetzten Anreicherung beschrieben. Um die Referenzierung von Empfänger-Typen zu vervollständigen, sind die verbleibenden Aufruf-Typen zu ergänzen. 84 8.1.3 Implementierung eines Bytecode-Faktenextraktors Die im Rahmen dieser Arbeit für eine eingeschränkte Menge von Quelltext-Elementen umgesetzte Bytecode-Faktenextraktion auf der Basis von BCEL berücksichtigt die öffentlichen Eigenschaften der Deklarationen von Klassen und Interfaces, von Methoden (mit Modifiern, Rückgabetyp und formaler Parameterliste) sowie von Variablen (mit Modifier und deklariertem Typ). Supertyp- und Override-Beziehungen aus dem eigenen Quelltext-Bereich zu diesen Deklarationen werden aufgebaut. Damit ist eine Grundlage für einen Bytecode-Faktenextraktor gelegt. Für eine produktive Nutzung des Bytecode-Faktenextraktors müsste dieser um folgende Funktionen erweitert werden: Repräsentation aller von außerhalb des Bytecodes sichtbarer Fakten. Insbesondere sind auch Elemente mit Package-Zugriff erforderlich, da eigener Quelltext und Bytecode-Elemente innerhalb desselben Packages deklariert sein können. • Repräsentation der statischen Bindungen zu den aus dem Bytecode extrahierten Deklarationen. Hierzu wäre die im Abschnitt 8.1.1. Neu-Implementierung der statischen Bindungen geschilderte Implementierung des statischen Bindealgorithmus auf der Basis von TGraphen erforderlich. • Repräsentation der Referenzen, die aus dem Bytecode heraus auf Deklarationen innerhalb des eigenen Quelltexts zeigen. In diesem Kontext soll auf die Arbeit [WETZLER2011] hingewiesen werden, in welcher die Implementierung eines Bytecode-Faktenextraktors auf Basis von BCEL beschrieben wird. Die dort beschriebene Implementierung kann in Kombination mit der Implementierung der vorliegenden Arbeit als Ausgangspunkt für einen Bytecode-Faktenextraktor auf TGraph-Basis dienen. • 8.1.4 Der GraBaJa-Faktenextraktor und künftige Java-Versionen Wie bereits in Abschnitt 7.2.2. Wartbarkeit des Faktenextraktors geschildert, hat sich der GraBaJaFaktenextraktor als schwer erweiterbar erwiesen. Für künftige Java-Versionen ist daher ggf. die Implementierung eines neuen Faktenextraktors erforderlich. 8.2 8.2.1 Über die Sichtbarkeitsconstraints hinaus Eignung für beliebige Constraint-Regeln In dieser Arbeit wurde am Beispiel der Sichtbarkeitsconstraints gezeigt, wie TGraphen angepasst werden können, um als geeignete Grundlage für constraintbasierte Refaktorisierungen zu dienen. Die Konzentration auf Sichtbarkeitsconstraints soll jedoch nicht übersehen lassen, dass TGraphen sich prinzipiell als Grundlage für die Umsetzung beliebiger Constraint-Regeln eignen. Die gesamte im Rahmen dieser Arbeit angereicherte Information war entweder bereits im TGraphen vorhanden oder ließ sich aus der Java-Sprachspezifikation ableiten. Ein erneuter Zugriff auf die Quelltext-Dateien nach der durch den GraBaJa-Faktenextraktor erfolgten Generierung des TGraphen war in keinem Fall notwendig. Die exemplarische Umsetzung für Sichtbarkeitsconstraints hat gezeigt, dass die Anreicherung der Fakten-Basis in vielen Fällen lediglich erfolgt, um auf die benötigte Information bei der späteren Generierung der ConstraintRegeln komfortabel und performant zugreifen zu können. Der im Kapitel 3.9. Vorgehensweise bei 85 Anpassungen im TGraphen beschriebene Workflow für die Aufnahme zusätzlicher Informationen ist ebenso beliebige Informationen anwendbar, die für eine Umsetzung weiterer Constraint-Regeln in die Fakten-Basis aufgenommen werden sollen. Vorstellbar sind beispielsweise • • • • 8.2.2 der Einsatz für die Generierung von Type Constraints, für den nach einem Abgleich der Constraint-Regeln, die im Kapitel „2.4.2 Aufbau der Constraints“ in [BÄR2010] aufgeführt werden, keinerlei zusätzliche Anpassungen der Fakten-Basis erforderlich sind, da sämtliche dort beschriebenen Programmelemente und -konstrukte bereits im TGraphen repräsentiert werden die Aufnahme zusätzlicher Informationen für die Refaktorisierung paralleler Systeme wie z. B. die Repräsentation der in [SCHÄFER2010-2] beschriebenen Dependency Edges in den TGraphen die Repräsentation programmrelevanter Information, die nicht in Java-Quelltexten vorliegt, wie z. B. die Konfigurationsdateien von Dependency Injection Containern oder ViewDefinitionen von Web-Anwendungen, die als XHTML oder JSP-Dateien vorliegen die Ergänzung von Analyse-Information externer Werkzeuge, wie dies z. B. im Abschnitt 2.3.3. Nutzung eines Java-Compilers beschrieben wurde. Parallelen zur REFACOLA In [STEI2011] wird auf der Basis des constraintbasierten Refaktorisierungsansatzes die Beschreibungssprache REFACOLA (engl. Refactoring Constraint Language) zur Spezifikation von Spracheigenschaften, Constraint-Regeln und Refaktorisierungen vorgestellt. Die Konzeption der Sprache ist programmiersprachenübergreifend. Auch aus diesem Grund tun sich Parallelen zur Verwendung von TGraphen auf, deren eingehendere Untersuchung lohnen würde. Hier soll lediglich ein anschauliches Beispiel gegeben werden. Die folgende Regeldefinition wurde mittels der REFACOLA notiert: language Java rules FieldAccessibility for all d : Java.Field r : Java.FieldReference do if Java.binds(r, d) then r.hostType != d.hostType -> d.accessibility > private end Es fällt nicht schwer, diese Spezifikation in eine Implementierung für TGraphen umzusetzen. Die eigentliche Regeldefinition kann innerhalb einer Methode erfolgen und hat erkennbare Ähnlichkeit mit der oben gegebenen. 86 1 public class FieldAccessibility implements JavaRuleDefinition { 2 public void defineRule(Java5 tgraph) { 3 for (FieldAccess fa : findAllFieldAccesses(tgraph)) { 4 VariableDeclaration vd = getBoundVariableDeclaration(fa); 5 6 TypeSpecification type_vd = getTypeOfVariable(vd); 7 TypeSpecification type_fa = getReceiverTypeOfFieldAccess(fa); 8 9 if (type_vd != type_fa) {// Pruefung auf Identitaet ist hier moeglich. 10 checkAccessibilityOfVariable(vd); 11 } 12 } 13 } 14 // Die notwendigem Methoden-Deklarationen folgen. 15 } Dass nichtsdestoweniger noch ein gutes Stück Weg zurückzulegen wäre, um beispielsweise REFACOLA-Spezifikationen automatisiert in Quelltext wie diesen zu transformieren, zeigen die in defineRule() verwendeten Methoden, die zusätzlich zu implementieren sind. Um einen Eindruck von diesem Weg zu geben, werden hier Beispiel-Implementierungen dieser Methoden gezeigt: Zeile 2, Ermittlung aller Feld-Zugriffe: private Set<FieldAccess> findAllFieldAccesses(Java5 tgraph) { GreqlEvaluator eval = new GreqlEvaluator( "from x:V{FieldAccess}" + " reportSet x" + " end", tgraph, null); eval.startEvaluation(); Set<FieldAccess> access_set = new HashSet<FieldAccess>(); for (JValue res : (JValueSet)eval.getEvaluationResult()) { access_set.add((FieldAccess)res.toObject()); } return access_set; } Zeile 3, Ermittlung der Deklaration, an die ein Feld-Zugriff gebunden wird: private VariableDeclaration getBoundVariableDeclaration(FieldAccess fa) { IsDeclarationOfAccessedField idoaf = fa.getFirstIsDeclarationOfAccessedFieldIncidence(EdgeDirection.OUT); return (VariableDeclaration)idoaf.getThat(); } 87 Zeile 5, Ermittlung des Typs der Variablen-Deklaration: private TypeSpecification getTypeOfVariable(VariableDeclaration vd) { IsTypeOfVariable itov = vd.getFirstIsTypeOfVariableIncidence(EdgeDirection.IN); return (TypeSpecification)itov.getThat(); } Zeile 6, Ermittlung des Empfänger-Typs des Feld-Zugriffs: private TypeSpecification getReceiverTypeOfFieldAccess(FieldAccess fa) { IsReceiverOfAccessedField iroaf = fa.getFirstIsReceiverOfAccessedFieldIncidence(EdgeDirection.OUT); return (TypeSpecification)iroaf.getThat(); } Zeile 9, Prüfung der geforderten Sichtbarkeit: private void checkAccessibilityOfVariable(VariableDeclaration vd) { IsModifierOfVariable imov = vd.getFirstIsModifierOfVariableIncidence(EdgeDirection.IN); Modifier mod = (Modifier)imov.getThat(); if (mod.get_type().equals(Modifiers.PRIVATE)) { // Constraintverletzung. Tue, was getan werden muss. } } Bei einigen dieser Beispiele macht sich der bereits im Abschnitt 7.1.1.1. Methoden zum Navigieren im TGraphen festgestellte Umstand bemerkbar, dass es an Schnittstellen-Methoden mangelt, die unmittelbar von Knoten zu Knoten navigieren. Statt dessen ist es jeweils notwendig, zunächst die verknüpfende Kante zu ermitteln und dann mittels getThat() und notwendiger Cast-Operation die eigentlich interessierende Knoten-Instanz zu erlangen. Bei der ebenfalls möglichen Verwendung der reachableVertices()-Methode hätte man statt dessen ein Set mit genau einem Knoten als Ergebnis erhalten und jeweils den einen Knoten aus dem Set entnehmen müssen. Ohne diese Umstände würde bereits rund die Hälfte des Beispiel-Quelltexts entfallen. 88 9 Zusammenfassung Das Ziel dieser Arbeit war es, die Eignung von TGraphen als Fakten-Basis für den constraintbasierten Refaktorisierungsansatz zu untersuchen. Wie das Kapitel 2. Der constraintbasierte Refaktorisierungsansatz am Beispiel der Sichtbarkeitsconstraints gezeigt hat, resultieren aus der Notwendigkeit einer effizienten ConstraintGenerierung hohe Ansprüche an die in der Fakten-Basis repräsentierten Informationen. Zum Zwecke der Constraint-Generierung werden bestimmte Beziehungen wie etwa statische Bindungen, Override-Beziehungen oder die Referenzierung von Empfänger-Typen besonders häufig benötigt und müssen daher auf einfache und performante Weise ermittelbar sein. Dies erfordert nicht nur eine vollständige Repräsentation aller (auch impliziter oder nur in Form von Bytecode vorliegender) Programmelemente, sondern auch eine teils redundante Anreicherung der Fakten über die rein syntaktische Ebene hinaus. Im Kapitel 4. Identifikation der notwendigen Anpassungen wurde sichtbar, dass diese Ansprüche von dem zur Verfügung stehenden Extraktor für Java-Fakten in vielerlei Hinsicht nicht erfüllt werden. Dieser eignet sich zwar als zuverlässiges Transformationswerkzeug, um explizit vorliegenden Java-Quelltext in eine TGraphen-Repräsentation zu überführen. Er ist jedoch weder in der Lage, nur implizit oder in Form von Bytecode vorliegende Fakten zu ermitteln, noch erwies sich die Auflösung von Methoden- und Feld-Bindungen als brauchbar. Weitere Beziehungen wie Override-Beziehungen oder die Referenzierung von Empfänger-Typen sind gar nicht erst in einfach zugreifbarer Form repräsentiert, sondern müssen vergleichsweise aufwändig aus den syntaktischen Fakten und der Java Language Specification abgeleitet werden. Andererseits wurde zunächst im Kapitel 3. TGraphen zur Repräsentation von Java-Fakten die grundlegende Eignung von TGraphen für den gewünschten Einsatzzweck aufgezeigt. Die Möglichkeiten zur Modellierung der Fakten-Basis sind auf Grund der Typisierung von Knoten und Kanten sowie der Ergänzung durch Attribute umfangreich. Die so strukturierten Fakten können mittels einer mächtigen Abfragesprache analysiert werden. Dabei gewähren zahlreiche Schnittstellen-Methoden einen flexiblen Zugang zu der gewünschten Information. Die vorgenommenen Implementierungen, die in den Kapiteln 5. Dokumentation der vorgenommenen Anpassungen und 6. Exemplarische Constraint-Generierung mittels TGraph dargestellt wurden, bestätigen diese Eignung. Implizite Quelltext-Elemente werden nach der erweiterten Faktenextraktion ebenso wie Override-Beziehungen vollständig im TGraphen repräsentiert. Wo die Implementierung unvollständig blieb, lag dies nicht an der Nutzung von TGraphen als Fakten-Basis, sondern an der Komplexität der einzubringenden Information. So erwies sich die Java Language Specification der statischen Bindungen oder der Ermittlung der statischen Typen verschiedener Java-Ausdrücke als zu umfangreich, als dass eine Umsetzung aller Einzelheiten sich in den Rahmen dieser Arbeit gefügt hätte. Auch die Entwicklung eines BytecodeFaktenextraktors konnte nur bis zu einem Punkt geführt werden, von dem aus sichtbar wird, dass eine Umsetzung auf der Basis von TGraphen grundsätzlich in eleganter Form möglich ist. Auch aus der Sicht des Entwicklers, der auf der Grundlage von TGraphen Entwicklungsarbeit zu leisten hat, ergab sich im Rahmen des Kapitels 7. Diskussion ein weitgehend positives Bild. Auf der Habenseite stehen ein nachvollziehbares und gut erweiterbares Metamodell, eine umfangreiche Entwicklungs-Schnittstelle und die leistungsfähige integrierte Abfragesprache. Diesen stehen eine anfänglich steile Lernkurve sowie kleinere Schwächen einzelner Schnittstellen-Methoden 89 gegenüber. Es wurden Vorschläge zur Ergänzung der Entwicklungs-Schnittstelle gemacht, die für die speziellen Anforderungen der Analyse von Java-Elementen die Entwicklungsarbeit erleichtern und die Qualität der entwickelten Software verbessern würden. Im Rahmen des Kapitels 8. Ausblick wurden zunächst noch einmal die nächsten Schritte zusammengefasst, die erforderlich wären, wenn der Ansatz weiter verfolgt werden soll. Darüber hinaus wurde nach der vorangegangenen Konzentration auf zahlreiche Details die Perspektive wieder auf die allgemeinere Problemstellung constraintbasierter Refaktorisierungen gelenkt und an Hand einiger Beispiele aufgezeigt, dass die für Sichtbarkeitsconstraints gewonnenen Erkentnisse sich auch auf weitere Constraint-Arten anwenden lassen. Zusammenfassend lässt sich feststellen, dass die Nutzung von TGraphen als Fakten-Basis für die Entwicklung constraintbasierter Refaktorisierungs-Werkzeuge eine vielversprechende, wenn auch nicht kurzfristig erreichbare Möglichkeit darstellt. 90 10 10.1 Anhang Installations- und Build-Hinweise zu JGraLab und GraBaJa Die folgenden Installationshinweise beziehen sich auf die im Subversion-Repository des Lehrgebiets Steimann sowie auf der Installations-CD zu dieser Arbeit abgelegten Projekte. JGraLab und GraBaJa werden in separaten Eclipse-Java-Projekten gepflegt. Des Weiteren ist für den Build der Projekte ein zusätzliches Projekt namens common notwendig, welches verwendete Bibliotheken bereitstellt. Im Subversion-Repository stellt sich dies wie folgt dar. Abbildung 10: Entwicklungsprojekte Die Projekte können aus dem Repository mittels Check Out (Rechtsklick auf das jeweilige Projekt und dann Check Out wählen) in den Eclipse-Workspace aufgenommen werden. Die Installation von der CD erfolgt über die Funktion File → Import → Existing Projects into Workspace. Abbildung 11: Import des Projekts Dabei sollte die Option Copy projects into workspace aktiviert werden. Im nachfolgenden Dialog wählt man als root directory das jeweilige Projektverzeichnis. Im Anschluss an den Import sollte zudem überprüft werden, ob die Projektordner mit einem Schreibschutz versehen wurden, was bei einem Import von CD der Fall sein kann, da ggf. die Schreibschutz-Attribute der Dateien auf der CD von Eclipse übernommen werden. Am erreicht man dies, indem in den Eigenschaften des Workspace-Ordners (im Windows-Explorer Rechtsklick auf den Ordner, dann auf Eigenschaften klicken) das Attribut Schreibgeschützt deaktiviert wird. 91 Die drei Projekte müssen im Dateisystem auf einer Ebene liegen und sind in der Reihenfolge (1) common, (2) jgralab und (3) grabaja zu bauen. Zu diesem Zweck ist in jedem der Projekte eine build.xml-Datei für einen Ant-Build abgelegt. Der Build von jgralab und grabaja erzeugt jeweils eine .jar-Datei unter <Projektname>/build/jar. Diese können ins eigene Entwicklungsprojekt eingebunden werden (siehe Abschnitt 10.2.2. Installation). Für JGraLab existiert im Wiki des IST eine Installationsanleitung unter [URL:JGRALABINSTALL]. 10.2 Dokumentation des Erweiterungs-Projekts 10.2.1 Struktur des Projekts Das Erweiterungs-Projekt wurde unter dem Namen TGraphEnhancements in das SubversionRepository des Lehrgebiets Programmiersysteme der Fernuniversität Hagen sowie auf die Installations-CD dieser Arbeit aufgenommen. Die folgende Abbildung gibt eine Übersicht der wesentlichen Implementierungs-Bestandteile: Abbildung 12: Übersicht wesentlicher Implementierungs-Bestandteile 92 Im Package demo finden sich Dateien und Verzeichnisse, die im Abschnitt 10.2.4. Demonstration mittels TGraph-Browser näher beschrieben werden. Das Package enhance enthält alle Quelltexte, welche im Rahmen der Anreicherung des TGraphen relevant sind. Der Controller im enhance.ablauf-Package steuert die Reihenfolge der Anreicherung. Im enhance.handlers-Package sind die Klassen enthalten, welche die eigentlichen Modifikationen im TGraphen ausführen. Für jede Art der Informationsanreicherung wurde eine Handler-Klasse implementiert. Struktur und Ablauf der Handler-Klassen sind in den meisten Fällen sehr ähnlich. Die Faktenextraktion aus Bytecode wurde im Package enhance.bcel umgesetzt. Es ist sowohl möglich, einzelne .class-Dateien als auch ganze .jar-Dateien zu übergeben. Im enhance.dao-Package wurden Abfragen an den TGraphen versammelt, die entweder GReQL nutzen oder auf dem Einsatz von Schnittstellen-Methoden basieren. Auf diese Weise sollte nach Möglichkeit die eigentliche Anpassungslogik von den Abfragen separiert werden. Da für einige Knotentypen besonders viele Abfragen entstanden sind, wurden für diese separate DAO-Klassen erstellt. Beispielsweise enthält das ClassDefinitionDao ausschließlich Abfragen, die Klassen-Definitionen zurückliefern. Im enhance.service-Package wurden einige häufig verwendete Hilfsmethoden implementiert. Im Package examples wurden die Beispiel-Implementierungen für die Constraint-Generierung sowie für die Parallelen zur REFACOLA abgelegt. Das Package testsources enthält zahlreiche Beispiel-Quelltexte, die im Lauf der Untersuchungen der Arbeit erstellt wurden, um die Repräsenation bestimmter Programmkonstrukte im TGraphen überprüfen zu können. Diese Quelltexte werden auch von den Unit-Tests des Packages test genutzt. Zu jeder implementierten Handler-Klasse sowie zum BytecodeFaktenextraktor existiert eine entsprechende Unit-Test-Klasse, welche die vorgenommenen Anreicherungen testet. Über die Packages hinaus befindet sich im Verzeichnis jar die BCEL-Bibliothek bcel-5.2.jar sowie die Datei BcelTestclass.jar. Letztere wird von der Testklasse eingelesen, welche die Bytecode-Faktenextraktion überprüft. Im Verzeichnis doc/literatur befinden sich zahlreiche der im Literaturverzeichnis dieser Arbeit referenzierten Dokumente mit den dort verwendeten Kurzbezeichnungen. 10.2.2 Installation Die Integration des TGraphEnhancements-Projekts in den Eclipse-Workspace erfolgt wie bereits in 10.1. Installations- und Build-Hinweise zu JGraLab und GraBaJa beschrieben. Ein Build ist nicht erforderlich. Nach dem Build von JGraLab und GraBaJa sind deren erzeugte .jar-Dateien (unter jgralab/build/jar und grabaja/build/jar) sowie die BCEL-Bibliothek bcel-5.2.jar in den Build Path des TgraphEnhancements-Projekts aufzunehmen. Dies erfolgt im Dialog Java Build Path in den Properties des Projekts mittels Add External JARs. Es sollte sich das folgende Bild ergeben: 93 Abbildung 13: Konfiguration des Build Path Danach sollten sich die unter src/test abgelegten Unit-Tests fehlerfrei mit dem Test runner JUnit 4 ausführen lassen. 10.2.3 Zahlen zum Umfang der Implementierung Mittels des Metrics-Plugins für Eclipse (siehe [URL:METRICS]) wurden einige Kennzahlen der Umsetzung ermittelt. Es wurden insgesamt 4931 Lines of Code (LoC) bzw. 3028 Method Lines of Code (MLoC) in 86 Klassen mit 51 Attributen und 236 Methoden implementiert. Davon entfielen 1827 LoC und 939 MLoC auf den Testcode der Packages test und testsources. Auf den eigentlichen Code zur Anpassung des TGraphen entfielen 2846 LoC und 1922 MLoC. 10.2.4 Demonstration mittels TGraph-Browser Das Graphenlabor stellt eine Webanwendung für das interaktive Navigieren in TGraphen zur Verfügung, welche nun vorgestellt werden soll, um sie für die Ansicht einiger DemonstrationsBeispiele nutzen zu können. Hierfür ist zunächst der Server zu starten. Dies geschieht am einfachsten innerhalb von Eclipse über die Ausführung der Java-Klasse de.uni_koblenz.jgralab.utilities.tgraphbrowser.TGraphBrowserServer aus dem JGraLab-Projekt, die über eine main()-Methode verfügt. Um die graphische Visualisierung nutzen zu können, müssen zwei Programm-Argumente in der Run-Konfiguration eingetragen werden: Abbildung 14: Argumente für den Start des TGraphBrowserServers 94 • • Mittels der -d-Option ist der Pfad zu der ausführbaren Datei dot.exe anzugeben, die mit der Software Graphviz (siehe [URL:GRAPHVIZ]) installiert wird. Diese wird vom TGraphBrowserServer zur Generierung SVG-Dateien (siehe [URL:SVG]) genutzt, die in einem Webbrowser angezeigt werden können. Die -dt-Option gibt an, wie lange der TGraphBrowserServer maximal auf die Generierung der SVG-Dateien warten soll. Ohne die Angabe dieser Option funktioniert die Graphenvisualisierung nicht. Beim Ausführen des TGraphBrowserServers sollte es in der Konsole zu einer Ausgabe wie der folgenden kommen: TGraphBrowserServer is running on port 8080 The current workspace is: C:\Users\Besitzer\AppData\Local\Temp\tgraphbrowser\workspace Press CTRL + C to quit. Die Anwendung kann jetzt in einem Webbrowser unter http://localhost:8080 aufgerufen werden. Es öffnet sich die folgende Startseite: Abbildung 15: Startseite des TGraph-Browsers Über den Durchsuchen-Button können nun TGraphen-Dateien in den Server geladen werden. Zur Demonstration der vorgenommenen Anreicherungen liegen hierzu einige bereits generierte Dateien vor. Unterhalb des Packages demo finden sich mehrere Sub-Packages, die für mehrere Erweiterungs-Themen Beispiel-Quelltexte enthalten. Unterhalb dieser Sub-Packages findet sich jeweils ein Package generated, welches die TGraphen-Dateien enthält, die in den Server geladen werden können. Eine der Dateien heißt *_erweitert.tg. Diese enthält den TGraphen nach Anreicherung, die andere den ummodifierten TGraphen, wie er vom GraBaJa-Faktenextraktor erzeugt wird. Ein Beispiel: 95 Abbildung 16: Struktur der Demonstrations-Beispiele Nach dem Hochladen der .tg-Datei dauert es eine Weile, bis der TGraph in den Server eingelesen ist. In dieser Zeit wird der folgende Dialog angezeigt: Abbildung 17: Anzeige während des TGraphen-Uploads Ist der Graph geladen, so wird eine Seite wie die folgende angezeigt: Abbildung 18: Tabellen-Ansicht des eingelesenen TGraphen Dabei handelt es sich zunächst um die Tabellen-Ansicht des eingelesenen TGraphen. Es würde an dieser Stelle zu weit führen, alle interessanten Details zur Verwendung des TGraph-Browsers auszuführen. Die Interaktion ist weitgehend selbsterklärend, bei Bedarf kann [JANKE2010] konsultiert werden. Auf folgende Möglichkeiten sei kurz hingewiesen: • • • Im Explorer-Bereich links kann mittels der Typ-Hierarchie des TGraphen separat nach Knoten- und Kantentypen gebrowst werden. In der Tabellen-Ansicht kann auf sowohl geblättert als auch auf Knoten- und Kantentypen geklickt werden, um durch den Graphen zu navigieren. Durch Klick auf den Button „Select by GReQL“ kann ein Editor-Fenster geöffnet werden, um eine GReQL-Abfrage an den Graphen zu stellen. Von näherem Interesse ist der Button „Show graphical view“. Klickt man auf diesen, so wechselt der TGraph-Browser von der Tabellen-Ansicht in den Visualisierungs-Modus. 96 Abbildung 19: Visualisierungs-Modus des TGraph-Browsers Zur Navigation können hier einige Zoom-Elemente links verwendet werden. Es ist auch möglich, auf einzelne Knoten des Graphen zu klicken, die dann farbig markiert werden. Setzt man danach in der Kopfleiste die „Size of environment“, so kann die nähere Umgebung des markierten Knoten eingegrenzt oder erweitert werden. Es wurden Demonstrations-Beispiele zu folgenden Themen erstellt: • Override-Beziehung: Hier können im erweiterten TGraphen die IsOverriddenMethodByund IsOverridingMethodOf-Kanten gefunden werden. • • Implizite Modifier: In diesem Beispiel werden bei der Erweiterung einige zusätzliche Kanten zu Modifiern in den TGraphen aufgenommen, deren implicit-Attribut den Wert true hat. Um diese Attribut zu sehen, kann im TGraph-Browser die Ansicht der Attribute über „Show attributes“ aktiviert werden. Receiver-Typen: Dieses Beispiel zeigt die Anreicherung der IsReceiverOf-Kanten. Sollen eigene Beispiele erzeugt werden, so wurde hierfür ein Parser implementiert. Im Package demo.generierung des TGraphEnhancements-Projekts findet sich neben der Klasse DemoParser die Datei files2parse.txt. In diese Datei können beliebig viele Zeilen mit Dateinamen (entweder relativ zum Projekt oder absolut) eingetragen werden. Wird ein Verzeichnis angegeben, so wird in diesem Verzeichnis und allen seinen Unterverzeichnissen nach Dateien gesucht, die auf .java enden. Führt man nach der gewünschten Eintragung der zu parsenden Dateien und Verzeichnisse den DemoParser aus, so werden folgende vier Dateien im outputVerzeichnis des TgraphEnhancements-Projekts erzeugt oder überschrieben: 97 Abbildung 20: Generierte Dateien Zusätzlich zu den TGraphen-Dateien, die auf .tg enden, werden Graphen-Dateien im DOT-Format erzeugt. Diese können bei Bedarf mit Graphviz geladen werden, um beispielsweise BitmapGrafiken für die Graphen generieren zu können. 10.3 Versionsinformation Als Basis der Implementierungsarbeit, die im vorliegenden Dokument beschrieben wird, wurden die folgenden Revisionsnummern der jeweiligen damaligen Subversion-Projekte des IST verwendet: • • • common: Revisionsnummer 3319 vom 14.11.2010. jgralab: Revisionsnummer 3373 vom 14.11.2010. grabaja: Revisionsnummer 12989 vom 14.11.2010. Die Implementierungsarbeit erfolgte unter Eclipse Helios (Version 3.6.1) unter Verwendung von Java 1.6. 98 Literaturverzeichnis ALUR2002: BÄR2010 BALD2008: BILD2006: CHEN1990: DAHM1998: EBERT1995: EBERT1996: EBERT2002: EBERT2010: EKMAN2008: FOWLER1999: FUHR2011: GREQLREF: GUPRO1998: HOF2007: HORN2008: HORN2011: JANKE2010 Alur, Deepak; Crupi, John; Malks, Dan, Core J2EE Patterns – Die besten Praxislösungen und Design-Strategien, 2002 Bär, Robert, Mutantengenerierung durch Type Constraints, 2010 Baldauf, Arne; Vika, Nicolas, Java-Faktenextraktor für Gupro, 2008 Bildhauer, Daniel, Ein Interpreter für GReQL 2 - Entwurf und prototypische Implementation, 2006 Y.-F. Chen; M. Y. Nishimoto; C. V. Ramamoorthy, Tutorial on the C Information Abstraction System, 1990 Dahm, Peter; Widmann, Friedbert, Das Graphenlabor, 1998 Ebert, Jürgen; Franzke, Angelika, A Declarative Approach to Graph Based Modeling, in: Mayr, E.; Schmidt, G.; Tinhofer, G., Graphtheoretic Concepts in Computer Science, 1995 Ebert, Jürgen; Gimnich, Rainer; Winter, Andreas, Wartungsunterstützung in heterogenen Sprachumgebungen. Ein Überblick zum Projekt GUPRO, 1996 Ebert, Jürgen; Kullbach, Bernt; Riediger, Volker; Winter, Andreas, GUPRO – Generic Understanding of Programs, 2002 Ebert, Jürgen; Bildhauer, Daniel, Reverse Engineering Using Graph Queries, 2010 Ekman, Torbjörn; Schäfer, Max; Verbaere, Mathieu, Refactoring is not (yet) about transformation, 2008 Fowler, Martin, Refactoring. Improving the Design of Existing Code, 1999 Fuhr, Andreas, Identifying Legacy Code for Service Implementation using Dynamic Analysis and Data Mining, 2011 Bildhauer, Daniel; Großmann, Eckhard; Horn, Tassilo, GReQLReference Card, 2010 Ebert, Jürgen (Herausgeber); Gimnich, Rainer (Herausgeber); Stasch, Hans H. (Herausgeber); Winter, Andreas (Herausgeber), GUPRO: Generische Umgebung zum Programmverstehen, 1998 Hofstedt, Petra; Wolf, Armin, Einführung in die ConstraintProgrammierung. Grundlagen, Methoden, Sprachen, Anwendungen, 2007 Horn, Tassilo, Ein Optimierer für GReQL 2, Fuhr, Andreas; Horn, Tassilo; Riediger, Volker, An Integrated Tool Suite for Model-Driven Software Migration towards Service-Oriented Architectures, 2011 Janke, Daniel Dominik, TGraphBrowser - Implementierung eines Webservers zum Browsen von TGraphen, 2010 99 JARZ1995: S. Jarzabek; T. P. Keam, Design of a Generic Reverse Engineering Assistant Tool, 1995 JLS3: Gosling, James; Joy, Bill; Steele, Guy; Bracha, Gilad, The Java Language Specification Third Edition, 2005 KAHLE2006: Kahle, Steffen, JGraLab: Konzeption, Entwurf und Implementierung einer Java-Klassenbibliothek für TGraphen, 2006 KAMP1996: Kamp, Manfred, GReQL - eine Anfragesprache für das GUPRORepository 1.1, 1996 KEG2007: Kegel, H., Contraint-basierte Typinferenz für Java 5, 2007 MAR2006: Marchewka, Karin, GReQL 2, 2006 MENS2004 Mens, Tom; Tourwé, Tom, A Survey of Software Refactoring, 2004 PAS2011: Pasenkova, Anastasia, Ein EclipsePlugin zum Aufspüren toter Codefragmente auf Basis von Sichtbarkeitsconstraints, 2011 PEREZ2009: Pérez, Javier; Crespo, Yania; Hoffmann, Berthold; Mens, Tom, A Case Study to Evaluate the Suitability of Graph Transformation tools for Program Refactoring, 2009 RENSINK2009: Rensink, Arend; Zambon, Eduardo, A Type Graph Model for Java Programs, 2009 SCHÄFER2010: Schäfer, Max; de Moor, Oege, Specifying and Implementing Refactorings, 2010 STEI2009: Steimann, Friedrich; Thies, Andreas, From Public to Private to Absent: Refactoring Java Programs under Constrained Accessibility, 2009 STEI2010: Steimann, Friedrich, Korrekte Refaktorisierungen: Der Bau von Refaktorisierungswerkzeugen als eigenständige Disziplin, 2010 STEI2011: Steimann, Friedrich; Kollee, Christian; von Pilgrim, Jens, A Refactoring Constraint Language and its Application, 2011 TIP2003: Tip, Frank; Kiezun, Adam; Bäumer, Dirk, Refactoring for generalization using type constraints, 2003 TIP2007: Tip, Frank, Refactoring Using Type Constraints, 2007 URL:ANTLRGRAMMAR: http://www.antlr.org/wiki/display/ANTLR3/Grammars URL:ASTREWRITER: http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.jdt.doc.isv/ reference/api/ org/eclipse/jdt/core/dom/rewrite/ASTRewrite.html URL:BCEL: http://jakarta.apache.org/bcel/ URL:COBUS: http://www.uni-koblenz-landau.de/koblenz/fb4/institute/ IST/AGEbert/projekte/cobus URL:DOT http://www.graphviz.org/doc/info/lang.html URL:EPL: http://www.eclipse.org/legal/epl-v10.html URL:GPL3: http://www.gnu.org/licenses/gpl-3.0.html URL:GRAL: http://www.uni-koblenz-landau.de/koblenz/fb4/institute/ IST/AGEbert/MainResearch/Graphentechnologie/EER-GRAL URL:GRAPHVIZ: http://www.graphviz.org/ 100 URL:GREQL: http://www.uni-koblenz-landau.de/koblenz/fb4/institute/ IST/AGEbert/MainResearch/Graphentechnologie/GReQL URL:GUPRO: http://www.uni-koblenz-landau.de/koblenz/fb4/institute/ IST/AGEbert/projekte/abgprojekte/GUPRO URL:HELENA: https://helena.uni-koblenz.de/redmine URL:ISOURCEREF: http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.cdt.doc.isv/ reference/api/org/eclipse/cdt/core/model/ISourceReference.html URL:ISTGRAPHEN: http://www.uni-koblenz-landau.de/koblenz/fb4/institute/ IST/AGEbert/MainResearch/Graphentechnologie URL:ISTWIKI: http://userpages.uni-koblenz.de/~ist/Main_Page URL:JCONSOLE: http://download.oracle.com/javase/6/docs/ technotes/guides/management/jconsole.html URL:JDT: http://www.eclipse.org/jdt URL:JGRALABDOWN: http://userpages.uni-koblenz.de/~ist/JGraLab_Download URL:JPROFILER: http://www.ej-technologies.com URL:JGRALABINSTALL: http://userpages.uni-koblenz.de/~ist/JGraLab_Documentation URL:JTRANSFORMER: https://sewiki.iai.uni-bonn.de/research/jtransformer/start URL:JUSTADDJ http://jastadd.org/web URL:METRICS http://metrics.sourceforge.net/ URL:REDSEEDS: http://www.redseeds.eu/ URL:SOAMIG: http://www.soamig.de/ URL:SVG http://www.w3.org/TR/SVG11/ URL:Z: http://www.imn.htwk-leipzig.de/~weicker/pmwiki/pmwiki.php/Main/ SpezifikationsspracheZ WELLS1995: C. H. Wells, R. Brand; L. Markosian, Customized Tools for Software Quality Assurance and Reengineering, 1995 WETZLER2011 Wetzler, Gabriel, Faktenextraktion aus Java-Bytecode für Refaktorisierungswerkzeuge, 2011 WINTER2000: Winter, Andreas, Referenz-Metaschema für visuelle Modellierungssprachen, 2000 ZIM2009: Zimmermann, Yvonne; Uhlig, Denis; Kaiser, Uwe, Tool- und Schnittstellenarchitektur für eine SOA-Migration, 2009 101
