Dr. Günter Kniesel-Wünsche, Lars Reimann

Application Programming Interfaces (API) beschleunigen die Entwicklung neuer Anwendungen, indem sie häufig benötigte Funktionalität kapseln.

Problem: Schlechte APIs. Oft konzentrieren sich jedoch die Autoren von APIs darauf, diese Funktionalität möglichst schnell oder möglichst allgemein bereitzustellen, ohne auf Erlern- und Benutzbarkeit zu achten. Ein Beispiel dafür ist scikit-learn, eine weit verbreitete und sehr mächtige Python-API für Maschinelles Lernen (ML), die allerdings im Hinblick auf Benutzbarkeit erheblichen Verbesserungsbedarf hat.

Ziel: API-Verbesserung. Wir möchten also eine bestehende API verbessern, indem wir typische Probleme erkennen und wie beschrieben lösen. Dazu gibt es mehrere Ansätze:

• Wir bauen eine komplett neue ML-API. → Das ist sehr viel Aufwand und man würde im Wesentlichen nur das Rad neu erfinden.
• Wir schreiben scikit-learn um. → Das wäre inkompatibel zu dem bestehenden scikit-learn.
• Wir schreiben Adapter, um die Funktionalität von scikit-learn hinter einer neuen Schnittstelle anzubieten. → Diese Lösung ist die sinnvollste, allerdings gibt es auch hier Schwierigkeiten:
  • Das manuelle Erstellen von Adaptern ist mühselig und fehleranfällig, insbesondere weil scikit-learn ziemlich umfangreich ist.
  • Bei jeder neuen Version von scikit-learn müssen die Adapter angepasst werden.
  • Viele Informationen über das API sind nicht im Code verfügbar, sondern nur in der natürlichsprachlichen Dokumentation.

Dies führt uns zu folgenden Forschungsfragen:

1. Wie weit lässt sich die Erzeugung von initialen Adaptern automatisieren, wenn klar ist, welche Verbesserungen sinnvoll sind?
2. Wie weit lässt sich die Herleitung der sinnvollen Verbesserungen automatisieren?

Wir werden bei dieser PG mit diesem Thema nicht bei Null anfangen, sondern auf Vorarbeiten aus früheres PGs, Bachelorarbeiten und eigener Forschung aufbauen. Das folgende Bild gibt einen Überblick über die bereits existierenden Komponenten und deren Interaktion:

Der Parser bekommt eine Python-Bibliothek als Eingabe und erzeugt daraus eine Datenstruktur im JSON-Format, die die API-Elemente beschreibt, also Module, Klassen, Funktionen und Parameter. Wir erfassen hier also den “Ist-Zustand” der API.

Diese Informationen werden in einen webbasierten Editor geladen, in dem Benutzer bei API-Elementen Verbesserungswünsche anmerken können (z.B. “ersetze String-Parameter durch Enum”). Diese Verbesserungswünsche bezeichnen wir als Annotationen. Die Annotationen werden als Ergänzungen der vom Parser extrahierten Informationen gespeichert und bilden die Basis für den nächsten Schritt.

Aus den Annotationen und den Informationen über die ursprüngliche API wird eine verbesserte API abgeleitet, sowie die Adapter, die dieses API auf Basis des Bestehenden implementieren. Wir erhalten in diesem Schritt also den “Soll-Zustand”, der zunächst noch in einem internen Datenmodell abgespeichert wird.

Aus dem “Soll-Zustand” wird anschließend Python-Programmcode generiert.

Alle oben beschriebenen Komponenten existieren bereits. Dadurch ist die Erzeugung der Adapter automatisiert (Forschungsfrage 1). Allerdings müssen Benutzer alle Annotationen im Editor selbst setzen, was noch immer ein erheblicher manueller Aufwand ist.

Das Ziel dieser Projektgruppe ist es daher, Forschungsfrage 2: So viele Verbesserungen / Annotationen wie möglich automatisch herzuleiten und an den Annotationseditor weiterzu reichen. Der Benutzer hat dann - wenn überhaupt - nur noch die Aufgabe, im Editor die automatisch generierten Annotationen zu überprüfen. Für diesen Ansatz stehen uns folgende Informationen zur Verfügung :

1. Code der Original-API (API-Code)
2. Dokumentation der Original-API (API-Dokumentation)
3. Code, der die Original-API benutzt (Client-Code)

Aus API-Code und -Dokumentation lässt sich beispielsweise erkennen, wenn statt eines Strings besser ein Enum genutzt werden sollte. Hierzu gibt es in einer Bachleor-Arbeit entstandenen Code, der Verfahren zur Verarbeitung natürlicher Sprache (NLP) nutzt und das im folgenden Bild illustrierte Vorgehen umsetzt:

Der Client-Code kann analysiert werden, um nicht (oder sehr selten) genutzte API-Elemente zu erkennen, die aus der verbesserten API entfernt werden können. Auch hierzu gibt es Vorarbeiten.

Diese Grundideen werden wir in der Vorbesprechung genauer erläutern. In der PG werden wir uns dann tiefer in die vorhandenen Ideen und den vorhandenen Code einarbeiten und darauf aufbauend versuchen die Grenzen der Automatisierung weiter und weiter zu schieben.

• Technologien
  • Prinzipien guten API Designs
  • Grundlagen des Maschinellen Lernens
  • Praxis in Python-Programmierung
• Softskills
  • Agile Softwareentwicklung
  • Gruppenleitung
  • Teamarbeit

All dies ist eingebettet in das Open-Source Projekt Simple-ML. Die Zeit, die Sie in dieser Projektgruppe investieren, kommt also der ML-Community zugute und Sie selbst können bei zukünftigen Bewerbungen stets auf die entsprechenden Repositories verweisen.

Das Know-How, das Sie durch die Projektgruppe erwerben und der in der PG erstellte Code können als Grundlage für weiterführende Bachelorarbeiten dienen.

Eine Bachelorarbeit könnte sich z.B. mit der Frage der API-Evolution befassen: Wenn sich die zugrunde liegende API ändert, möchte man bestehende Annotationen weiterhin verwenden und sich manuell nur um angepasste Elemente der API kümmern müssen. Ein Evolutions-Unterstützung-Tool sollte also Folgendes bieten:

• Erkennung gelöschter API-Elemente und automatisches Löschen der entsprechenden Annotationen
• Erkennung neuer / geänderter API-Elemente, Aufforderung des Benutzers zur erneuten Annotation im Editor
• automatische Aktualisierung der verbesserten API und des Adapter-Codes

Weitere Anschlussthemen besprechen wir im Laufe der Projektgruppe, wenn wir darauf stoßen.