Entwicklung von Softwarevarianten mit FeatureIDE

FeatureIDE: One Size fits all?

Thomas Thüm und Fabian Benduhn

One size fits all? In der Softwareentwicklung trifft dieses Motto nur selten zu. Die Entwicklung von Pro-grammen, die alle erdenklichen Funktionen beinhalten, ist oft nicht die beste Lösung. Solche Programme beinhalten viele unnötige Fehlerquellen, sind übermäßig aufgebläht und tragen regelmäßig zur Verwirrung des Benutzers bei. Während den meisten Anwendern wenigstens ein paar Vertreter dieser Gattung von eier-legenden Wollmilchsäuen bekannt sein dürften, sind in vielen Anwendungsbereichen solche Programme nicht einmal vorstellbar. Eingebettete Systeme, Smartphones oder der Automobilbereich sind bekannte Bei-spiele solcher Domänen. Die meisten Softwareprodukte werden zumindest in einer Reihe von Varianten entwickelt. Der Kunde kann sich dann diejenige Variante aussuchen, die ihm am meisten zusagt oder die er sich leisten kann.

Eine gängige Technik, um Softwarevarianten zu entwickeln, ist die Verwendung von Versionsverwaltungstools wie SVN, Git oder Mercurial. Dabei wird jede Variante in einem eigenen Branch entwickelt. Allerdings haben viele Varianten einen nicht unerheblichen Anteil an gleichem Quelltext und unterscheiden sich nur in bestimmten Aspekten. Beim Erstellen einer neuen Variante wird oft der gesamte Quelltext einer existierenden Variante in einen neuen Branch kopiert. Danach kann der Quelltext verändert oder erweitert werden. Durch die Verwendung von Versionsverwaltungstools für die Entwicklung von Softwarevarianten ergeben sich einige Nachteile:

  • Das Finden und Beheben von Fehlern in einer Variante zieht oft identische Änderungen in anderen Varianten nach sich, das hat einen erhöhten Arbeitsaufwand zur Folge.
  • Das Erstellen einer Variante ist komplex und teuer. Varianten können deshalb nicht auf Vorrat produziert werden, was zu langen Entwicklungszeiten führt.

Das Eclipse-Plugin FeatureIDE bietet eine neuartige Möglichkeit für die Entwicklung von Softwarevarianten, welche diese Probleme vermeidet. FeatureIDE erlaubt eine komfortable und benutzerfreundliche Entwicklung von Softwarevarianten und erlaubt es dabei, Quelltext wiederzuverwenden, der in mehreren Varianten benötigt wird.

FeatureIDE am Beispiel

Die wesentliche Idee von FeatureIDE besteht darin, jede Funktionalität (Feature) separat zu entwickeln. Hinterher können durch Kombination dieser Features unterschiedliche Varianten automatisch erzeugt werden. Wir zeigen an einem kleinen Beispiel, einem Taschenrechner, wie das funktioniert.

Zuordnung von Quelltext zu Features

In FeatureIDE wird jede Anwendung in unterschiedliche Quelltextfragmente aufgeteilt, so genannte Features. Das mag erst einmal ähnlich zu dem bekannten Konzept von Klassen klingen, aber es gibt einen wichtigen Unterschied. Ein Feature, in unserem Sinne, beschreibt einen Aspekt der Software, die für den Benutzer eine Bedeutung hat, z. B. sind die Operationen Addition und Multiplication Features, da es für den Benutzer einen Unterschied macht, ob der Taschenrechner diese Funktionen unterstützt oder nicht.

Abb. 1: Features der BeispielanwendungAbb. 1: Features der Beispielanwendung (Vergrößern)

Zu jedem Feature können beliebig viele Quelltextartefakte gehören, Artefakte sind Klassen, Methoden, Felder oder auch einzelne Anweisungen. Auch zusätzliche Dokumente, wie z. B. Grafiken oder Benutzerdokumentation, können einem Feature zugeordnet werden. Besonders die Möglichkeit, Methoden und Klassen nur teilweise zu verändern, bietet eine große Flexibilität beim Entwurf der Features. Abbildung 1 zeigt die Features unserer Beispielanwendung mit den dazugehörigen Quelltextartefakten. Die Spalten beziehen sich auf Features und die Zeilen auf Klassen bzw. andere Dokumente. In den Zellen kann man genauer erkennen, welche Quelltextartefakte zu den jeweiligen Features gehören. Man erkennt dort etwa, dass das Feature Addition mehrere Methoden und ein Feld der Klasse Calculator enthält, Multiplication beinhaltet zwei Methoden und Graphical führt zusätzlich die Klasse UserInterface ein.

Geschrieben von
Thomas Thüm und Fabian Benduhn
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.