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

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

Problem: Schlehte 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 neu geschrieben werden.
  • Viele Informationen über das API sind nicht im Code verfügbar, sondern nur in der Dokumentation.

Dies führt uns zu folgenden Forschungsfragen:

1. Wie weit lässt sich die API-Verbesserung automatisieren?
2. Was geschieht bei Änderungen der Original-APIs?
3. Wie weit können wir natürlichsprachliche Informationen aus der Dokumentation nutzen?

Die Erste der obigen Forschungsfragen zu lösen ist das Thema dieser Projektgruppe. Die beiden anderen Fragen sind Themen für darauf aufbauende Bachleor-Arbeiten. Je nachdem, wie schnell wir vorankommen, sind durchaus noch weitere Themen, die hier aber zu weit führen würden, für mögliche BAs relevant.

In der Projektgruppe werden wir folgende Pipeline bauen, auf die wir im nachfolgenden Text im Detail eingehen werden:

Der Parser bekommt eine Python-Bibliothek als Eingabe und erzeugt daraus eine Datenstruktur (z. B. im JSON-Format), die die API-Elemente beschreibt, also deren Module, Klassen, Funktionen und Parameter. Wir erfassen hier also den “Ist-Zustand” der API. ← Dieser Teil ist bereits in einer früheren Projektgruppe fertiggestellt worden.

Wir erstellen in der PG als erstes einen kleinen Editor der es erlaubt Annotationen für bestimmte API-Elemente zu vergeben. So könnte der Kernel-Parameter der SVC, den wir in der Projektgruppe Angewandte Softwaretechnologie erklärt haben, mit der Annotation Enum versehen werden, um anzuzeigen, dass man hier besser Enums verwenden sollte. Analog könnte der Verbose Parameter mit einer passenden Annotation versehen werden. 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 wird zusammen mit der ursprünglichen API eine verbesserte API abgeleitet, bei der zum Beispiel der Kernel-Parameter mittels Enums dargestellt wird. Wir erhalten in diesem Schritt also den “Soll-Zustand”, den wir im gleichen Format abspeichern wie den “Ist-Zustand” aus Schritt 0 (etwa JSON).

Aus dem Vergleich von “Ist-Zustand” und “Soll-Zustand” erzeugen wir den Code für unsere Adapter, die nach außen hin unsere verbesserte Soll-API anbieten aber intern die alte Ist-API aufrufen.

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 kann sich mit der API-Evolution befassen, eine andere mit der automatischen Inferenz von Annotationen aus der Dokumentation.

Wenn sich die zugrunde liegende API ändert möchte man in der Regel bestehende Annotationen weiterhin verwenden und sich nur um angepasste Elemente der API kümmern müssen. Das Tool sollte also Folgendes bieten:

• Löschungen
  1. Erkennung gelöschter API-Elemente
  2. Automatisches Löschen der entsprechenden Annotationen
• Änderungen/Ergänzungen
  1. Erkennung neuer / geänderter API-Elemente
  2. Aufforderung zur Annotation im Editor durch Benutzer
  3. Aktualisierung der verbesserten API
  4. Aktualisierung des Adapter-Codes

Mit dem in der PG zu erstellenden Editor könen Benutzer von Hand Annotationen erstellen. Idealerweise sollte auch dieser Schritt automatisiert sein oder zumindest sollten dem Benutzer Annotationen vorgeschlagen werden. Dies lässt sich erreichen, indem man mit Techniken des Natural Language Processing (NLP) die Dokumentation analysiert und daraus die entsprechenden Annotationen herleitet:

• Technologien
  • Prinzipien guten API Designs
  • Grundlagen des Maschinellen Lernens
  • Praxis in Java-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.