Wissenschaftliches Arbeiten (Updated: 03.07.13)

4. Oktober 2012 – 14:14

Blog-Eintrag zum Modul Wissenschaftliches Arbeiten an der Beuth Hochschule für Technik im Semester SS13.

Allgemeine Informationen

Name: Florian Oeser
Matrikelnummer: 780586
Gruppe: B
eMail: florian.oeser(at)gmail.com

Gewählter Artikel

Wolfinger, Reinhard, et al. “Adding genericity to a plug-in framework.” ACM SIGPLAN Notices.Vol. 46. No. 2. ACM, 2010.

Abstract

Im Bereich der Softwareentwicklung spricht man von einem Plug-in, wenn eine oder mehrere Softwarekomponenten eine bestehende Anwendung um eine bestimmte Funktionalität erweitern (ohne Neustart). Dadurch lassen sich Anwendungen optimal und kosteneffizient skalieren.

Im Kern basiert das Paper auf einem Plug-in Framework für Microsoft .NET, welches ebenfalls von einem Teil der Autoren entwickelt wurde. Das Plux.NET getaufte Framework ermöglicht Software-Kompositionen durch eine Art “Plug & Play”-Mechanismus.

Plux.NET definiert ein Kompositionsmodel und führt dabei die „Slot & Plug“-Metapher ein. Ein Slot spezifiziert einen Vertrag (Interface) und eine Liste von Parametern mit deren Namen und Typen. Dies geschieht deklarativ über .NET-Attribute (Metadaten), welche später zur Laufzeit über Reflection ausgelesen werden können. Ein Plug stellt eine konkrete Implementierung des korrespondierenden Slot-Interfaces dar. Die Angabe des passenden Slots sowie die Angabe konkreter Parameterwerte, geschieht wieder deklarativ.

Plux.NET selbst ist Plug-in basiert. Das bedeutet, das die eigene Anwendung ebenfalls als Plug-in implementiert werden muss. Das Framework definiert einen entsprechenden Slot (Interface), welcher mit einem passenden Plug in der eigenen Anwendung implementiert wird. Wird nun Plux.NET gestartet, sucht dieses nach eben solchen Plug’s und startet seinerseits die eigentliche Anwendung, da diese den besagten Slot implementiert hat. Weiterhin muss die Anwendung einen Slot definieren (öffnen), welches wieder einen konkreten Plug aufnehmen kann. Findet nun das Plux.NET-Framework zur Runtime ein entsprechendes Plug, welches zu dem definierten Slot passt, wird dieses geladen und der Anwendung übergeben. Der Anwendung wurde also ein Plug-in hinzugefügt.

Zusammenfassend besitzt Plux.NET ein Kompositionsmodel, welches eine Anwendung aus Komponenten zusammenfügt, welche wiederum aus einer definierten Anforderung (Slot) und einer passenden Implementierung (Plug) bestehen. Das Framework verbindet diese automatisch anhand der deklarierten Metadaten.

Sollen nun aber Komponenten an unterschiedlichen Stellen oder zu unterschiedlichen Zwecken in der Anwendung zum Einsatz kommen (wiederverwendet werden), bräuchte man verschieden ausgeprägte Metadaten. Beispielsweise könnte man sich zwei Grids in zwei verschiedenen Views vorstellen, welche beide wiederum an zwei verschiedene Datenquellen gebunden werden sollen. Implementiert man die Grid’s als Slot’s und die Datenquellen als Plug’s, würde das Kompositionsmodel automatisch beide Datenquellen an beide Grid’s binden. Dies ist nicht gewünscht, schließlich sollte das Grid in einer bestimmten View auch nur an die für es vorgesehene Datenquelle gebunden werden.

Die Plug’s müssten also selektiv mit den Slot’s verbunden werden. Ohne einen generischen Ansatz müssten die Kompositionen programmatisch definiert werden. Es wäre auch denkbar die Metadaten anzupassen und für jede View ein spezifisches Grid (Slot) zu definieren, zu welchem dann nur genau eine Datenquelle (Plug) implementiert ist. Beide Wege wären mit dem Plux.NET-Framework möglich, sind aber aus vielen Gründen ungeeignet. Beispielsweise würde das Anpassen der Metadaten immer auch zur Folge haben, das neue Subklassen (für die jeweiligen Slots/Plugs) angelegt werden müssten, obwohl eben eine Änderung der Metadaten hinreichend wäre.

Die Autoren beschreiben in ihrem Paper einen Template-basierten Ansatz für die Metadaten, welcher ebenfalls im Plux.NET-Framework implementiert wurde. Die entsprechenden Slot- und Plugnamen und die Parameterwerte werden mit Platzhaltern ersetzt. Die Metadaten sind somit unvollständig und werden erst zur Laufzeit parametrisiert, sobald eine Komponente verbunden wird und deren konkrete Ausprägung bekannt ist. Die Informationen darüber können aus einer externen Quelle wie einer Konfigurationsdatei stammen.

Ausarbeitung Beta

Adding genericity to a plug-in framework (.pdf, 438KB)

Ausarbeitung Final

Adding genericity to a plug-in framework (.pdf, 325KB)

Präsentation

Link zur Präsentation in Google Docs

Adding genericity to a plugin framework_Präsentation_Florian Oeser (.pdf, 527KB)

Post a Comment