Derzeit existiert nur ein einziges Werkzeug – RefactorErl –, das die Erhe-bung von Softwaremaßen für die Sprache Erlang umfassend und komfortabel unterstützt. Andere Werkzeuge erfüllen nur Teilaufgaben wie die Erstellung des
68 DaStartIss(*,V)FMSNull sein kann, wird der Nenner hier auf mindestens Eins gesetzt.
·Syntaxbaums (Syntax Tools69) oder des ·Aufrufgraphen (xref70) und erfor-dern die Implementierung weiterer Algorithmen, um die erforderlichen Informa-tionen abzufragen und zum Beispiel den ·Kontrollflussgraphen zu erstellen. Die Erstellung von ·Kontrollflussgraphen ist für dynamisch getypte und/oder funktio-nale Programmiersprachen allgemein deutlich schwieriger als für statisch getypte oder imperative Programmiersprachen [67:1] [88:2]. Daher wurde für diese Arbeit trotz der bei einem Prototypen zu erwartenden Schwierigkeiten das Werkzeug RefactorErl ausgewählt.
RefactorErl71 dient in erster Linie zur Umstrukturierung von Erlang-Pro-grammen. Aufbauend auf der dafür notwendigen statischen Analyse der Program-me erlaubt es auch, Softwaremaße und andere Informationen abzufragen. Es wird seit 2006 am Lehrstuhl für Programmiersprachen und Compiler der Fakultät für Informatik an der Eötvös-Loránd-Universität in Budapest, Ungarn, entwickelt.
Für die vorliegende Untersuchung wurde der Prototyp in Version 0.9.12.01 vom 17. Januar 2012 verwendet. Zur Zeit der Fertigstellung dieser Arbeit aktuell ist die Version 0.9.12.04 vom 20. April 2012, deren Änderungen für die Untersuchung irrelevant sind.
Aus dem zu bearbeitenden Programmcode erstelltRefactorErlzunächst einen abstrakten Syntaxbaum. In verschiedenen Analyseschritten wird dieser Baum durch zusätzliche Knoten und Kanten zum sogenanntenProgrammgraphenerweitert, der Ergebnisse der statischen semantischen Analyse enthält: den Aufrufgraphen, sta-tisch analysierbare Eigenschaften dynamischer Konstrukte (zum Beispiel mögliche Datentypen) und Informationen über den Datenfluss [53:269].
3.3.1 Abfragesprache
Zum Abfragen der im Programmgraphen gespeicherten Information dient eine Abfragesprache, die von der internen Struktur des Graphen abstrahiert und eine logische Sicht bietet, die der Struktur von Erlang-Programmen entspricht: Mo-dule und Header, die Funktionen, Makros und Records definieren, die wiederum aus Ausdrücken aufgebaut sind. Abb. 3.1, S. 60 stellt diese logische Sicht dar.
69 http://www.erlang.org/doc/apps/syntax_tools/
70 http://www.erlang.org/doc/man/xref.html 71 http://plc.inf.elte.hu/erlang/
Abfragen beschreiben ähnlich wie XPath-Abfragen Schrittfolgen im Programm-graphen, wobei die Schritte mit einem Punkt voneinander getrennt werden: mods (oben links in Abb. 3.1 auf der nächsten Seite) wählt alle Modul-Knoten aus, mods.funsalle Funktions-Knoten,mods.funs.varsalle Variablen-Knoten und so weiter. In jedem Schritt kann die ausgewählte Knotenmenge durch ein Prädikat eingeschränkt werden; beispielsweise wähltmods[name = mod_bsp].funs[name = fakul] die Funktion aus Listing 2.1, S. 46 aus. Knoten haben verschiedene Eigen-schaften, die (wienameim Beispiel) als letzter Schritt abgefragt oder in Prädikaten verwendet werden können (siehe Abb. 3.1 auf der nächsten Seite). Ausführliche Erläuterungen zur Abfragesprache finden sich in [79].
Einige Maße stellt RefactorErl direkt bereit, indem sie als Eigenschaften von Modulen oder Funktionen abgefragt werden können. Leider ist die Abfragesprache für die Definitionen einiger Maße zu eingeschränkt. So bietet sie etwa keine Mög-lichkeit, beliebige Knoten zu zählen oder in Abfragen Variablen zu verwenden.
Abfrageergebnisse können jedoch Erlang-Variablen zugewiesen und dann wei-terverarbeitet werden. Für diese Untersuchung wurde daher eine Messumgebung entwickelt, die auf der Grundlage eines relationalen Datenbanksystems kompli-ziertere Abfragen erlaubt (siehe Anhang B.2, S. 126).
3.3.2 Werkzeugvalidität von RefactorErl
In seiner Rolle als ·Refactoring-Werkzeug wird RefactorErl sowohl vom Ent-wicklungsteam selbst als auch von anderen Autoren überprüft. Zu ersteren zäh-len Tejfel u. a. [87], die das Werkzeug spezifikationsbasiertem Testen unterziehen, sowie Bozó u. a. [13], die auf die Überprüfung von Programmtransformationen eingehen. Andere Autoren sind Deckers [20] und Jumpertz [51], die erfolgreiche Ansätze zur Verifizierung von RefactorErl vorstellen.
Derzeit sind keine Programmfehler öffentlich bekannt. Obwohl bisher nicht explizit untersucht, stärkt dies auch das Vertrauen in die Messfunktionalität, da diese auf dem gleichen Programmgraphen beruht, der beim Refactoring verwendet wird.
Eine Überprüfung der Messfunktionalität erfolgt in Abschnitt 4.2.4, S. 72.
eigene Grafik
Abbildung 3.1 – Mit RefactorErl abfragbare Relationen und Attribute von Pro-grammkomponenten. Die Darstellung ist an das Entity-Relationship-Model ange-lehnt. Attribute sind mit ihren Datentypen beschriftet: atom, bool, int, string, unknown. Dünne Verbindungslinien bezeichnen 1:1-Beziehungen, fette Linien 1:N-Beziehungen.
Im vorangehenden Kapitel wurden die zu untersuchenden Maße und das Werkzeug zu ihrer Erhebung behandelt. Nun erfolgt die Vorstellung des untersuchten Soft-wareprodukts, des Aufbaus der Untersuchung und der Art der gewonnenen Daten.
Anschließend werden Hypothesen bezüglich der untersuchten Maße formuliert, die Daten statistisch ausgewertet und auf dieser Basis Aussagen zu den Hypothesen getroffen.
4.1 Untersuchungsobjekt ejabberd
Für die vorliegende Studie muss das Untersuchungsobjekt folgende Eigenschaften haben:
• Der Programmtext und Informationen über bekannte Fehler müssen verfüg-bar sein.
• Es muss hauptsächlich in Erlang geschrieben sein.
• Es sollte möglichst umfangreich und häufig verwendet sein, um belastbare Ergebnisse zu erzielen.
Große Datenbanken mit fertigen Messergebnissen wie FLOSSMetrics72oder PRO-MISE73 enthalten keine Erlang-Projekte (und überhaupt kaum Projekte, die funktionale Programmiersprachen verwenden). Mit Ausnahme der Laufzeitum-gebung und Standardbibliothek Erlang/OTP selbst sind in Frage kommende Erlang-Projekte deutlich kleiner als Softwaresysteme, die in vergleichbaren Un-tersuchungen imperativer Programmiersprachen betrachtet werden: einige Zehn-tausend Zeilen gegenüber mehreren Millionen oder mehr Zeilen.
72 http://flossmetrics.org/sections/deliverables/WP1
73 http://promisedata.org/
ejabberd ist eines der beliebtesten [68:432] Serverprogramme für das Extensi-ble Messaging and Presence Protocol, XMPP [82:3] und für seine Ska-lierbarkeit und Clustering-Fähigkeit bekannt [82:253]. Mit etwa 70000 Zeilen ist es eines der umfangreichsten in Erlang entwickelten Projekte. Der Programmtext ist für alle 29 Release-Versionen von ejabberd verfügbar. Zusätzlich enthält das Versionsverwaltungssystemgitfür den Entwicklungszeitraum von über neun Jah-ren auch alle etwa 2600 Zwischenschritte mit Informationen zu den einzelnen Co-deänderungen (Commits). Fehleraufzeichnungen liegen imFallbearbeitungssystem (engl. Issue Tracking System)Jira vor. Bis Ende 2010 gab es rund 1500 Einträge in diesem System, die Fehler oder sonstige Änderungsgründe dokumentieren.
ejabberd wird auch erfolgreich in einem Kommunikationssystem für Tablet-Computer eingesetzt, das seit 2010 bei dem auf mobile Messtechnik und PC-Netzwerktechnik spezialisierten Berliner Unternehmen ESYS GmbH74 entsteht.
Für dieses System hat der Autor eineJava-Bibliothek zur Verwendung des XMPP-Protokolls umgesetzt, die den Austausch textueller und grafischer Nachrichten auf der Android-Plattform erlaubt.75 Die intensive praktische Beschäftigung mit ejabberd war der Ausgangspunkt für die vorliegende Untersuchung.