Softwarevarianten mit EASy-Producer

Konfigurieren statt programmieren: Automatisierte Produktanpassung ist kein Hexenwerk

Klaus Schmid, Holger Eichelberger

©iStockphoto.com/nadla

Alles schon mal da gewesen? Gerade mal wieder Teile eines alten Systems genutzt, um die Bedürfnisse eines neuen Kunden zu erfüllen? Häufig verwendete Systeme werden oft sogar kopiert und dann angepasst. Was zunächst zu schnellen Ergebnissen führt, kann zu einem Wartungsalptraum werden, da Anpassungen im eigentlich gemeinsamen Code umständlich mehrfach durchgeführt werden müssen. Aber es geht auch anders: Durch systematische Wiederverwendung kann man diese Probleme minimieren. In diesem Beitrag stellen wir EASy-Producer vor: eine Eclipse-Erweiterung, die die konsistente Konfiguration und Anpassung unterstützt und diesen Prozess auch flexibel automatisieren kann.

Die Entwicklung von gut angepassten, kundenspezifischen Lösungen bei gleichzeitig maximaler Wiederverwendung ist eine Herausforderung für jede Softwareentwicklung. Dabei ist es üblicherweise sinnvoll, eine gemeinsame Plattform zu entwickeln, das jeweilige Produkt daraus durch Konfiguration abzuleiten und, falls erforderlich, mit kundenspezifischen Funktionen zu ergänzen. Auch wenn dies auf den ersten Blick nach mehr Aufwand klingt, lohnt sich dieser Weg üblicherweise nach kurzer Zeit [1]. Nicht nur, da individuelle Produkte dann schneller erstellt werden können, sondern auch, weil Änderungsaufwände nicht mehrfach anfallen. Es gibt bereits eine Vielzahl von Beispielen für so entwickelte Systeme (man spricht auch von Softwareproduktlinien):

  • Betriebssysteme wie der Linux-Kernel, die mehrere tausend Einstellungsmöglichkeiten beispielsweise für verschiedene Architekturen anbieten. Die endgültige Version entsteht dann erst beim Übersetzen des Kernels.
  • Eingebettete Systeme wie Steuergeräte im Automobilbereich. Nach unserer Erfahrung geht es auch hier teilweise um mehrere tausend Einstellungen, sodass die Software für verschiedene Automobilhersteller aus dem gleichen Code abgeleitet werden kann.
  • Flexible Informationssysteme, die auf verschiedensten Kundensystemen installiert werden und Anpassungsmöglichkeiten von der Weboberfläche bis zu den Geschäftsregeln bieten müssen. Ein Beispiel ist HISinOne der Hochschul-Informations-System (HIS) eG, das mehr als 100 000 Konfigurationseinstellungen anbietet [2].

Verschiedene Rahmenbedingungen haben zudem einen wesentlichen Einfluss darauf, welche Arten und Techniken der Anpassung sinnvoll sind. Je nach Ausprägung kann die Anpassung zur Entwicklungszeit oder die Laufzeitanpassung (z. B. durch Konfigurationsdateien) der bessere Ansatz sein. Beispielsweise muss konfigurierbare Software für eingebettete Systeme so angepasst werden, dass sie in den knappen Speicher passt. Sicherheitsstandards oder vertragliche Vereinbarungen können erfordern, dass nur Funktionen ausgeliefert werden, die für eine bestimmte Installation benötigt werden. Oder, in manchen Installationen soll ein Wartungstechniker gewisse Features zur Laufzeit freischalten können, in anderen aber nicht. Unabhängig davon, wann die Konfiguration erfolgt, ist Folgendes wichtig zu beachten:

  • Konsistente Konfiguration: Einstellmöglichkeiten hängen oft voneinander ab und können nicht beliebig getätigt werden, d. h., das System arbeitet nur korrekt, wenn es konsistent konfiguriert ist. Abhängigkeiten können aber auch die Konfiguration vereinfachen, da mit der Abwahl eines Funktionsbereichs dessen Einstellmöglichkeiten oder auch weitere abhängige Funktionsbereiche verschwinden.
  • Lebenszyklusweite Abhängigkeiten: Es kann Abhängigkeiten zwischen Entwicklungszeitkonfiguration und Laufzeitkonfiguration geben, die ebenfalls konsistent aufgelöst werden müssen.

Natürlich ist all dies nicht neu: Entsprechende Ansätze gibt es bereits seit mehr als zwanzig Jahren. Es gibt spezialisierte Werkzeuge im Open-Source-Bereich (wie beispielsweise für die Linux-Kernel-Konfiguration), aber auch kommerzielle Werkzeuge, die versuchen, einen relativ breiten Bereich abzudecken. EASy-Producer ist anders: Einerseits ist das Werkzeug unter einer Open-Source-Lizenz (Apache 2.0) verfügbar, andererseits ist es extrem allgemein und flexibel einsetzbar. So bietet es eine der mächtigsten Konfigurationsbeschreibungssprachen (inklusive entsprechender Logikunterstützung), es werden komplexe Multiprojektszenarien unterstützt, und es wurde versucht, möglichst keine spezifischen Annahmen über die Entwicklungsmethoden und -sprachen in das Werkzeug fest einzubauen, um die Anwendbarkeit nicht einzuschränken. Dies wurde durch die Entwicklung mächtiger DSLs für Konfigurations- und Instanziierungsbeschreibung erreicht. Um sicherzustellen, dass das Werkzeug relevante Probleme professioneller Softwareentwicklung abdeckt, wurde es in verschiedenen Projekten in Kooperation mit Unternehmen wie SAP, Siemens, Robert Bosch oder dem Mittelständler Klug IS entwickelt bzw. analysiert.

Aufgrund des Umfangs des Werkzeugs können wir in diesem Beitrag nur einen ersten Eindruck vermitteln. Wir werden dazu mit der Konfiguration beginnen, um dann aufbauend darauf die automatisierten Produktanpassungen zu beschreiben.

Konfigurieren – Wie geht das?

Als Beispiel für eine kurze Einführung in die Möglichkeiten von EASy-Producer nutzen wir ein einfaches Logistiksystem zur Verwaltung eines Warenlagers. Natürlich ist ein reales Logistiksystem sehr komplex und kann hunderte oder tausende von Einstellmöglichkeiten enthalten. Wir beschränken uns hier auf ein paar beispielhafte Konfigurationsmöglichkeiten, um einige grundlegende Möglichkeiten der Sprache EASy-IVML darzustellen (IVML steht für „Integrated Variability Modeling Language“).

project PL_Lager {
  enum EntnahmeTyp {FIFO, MHD, Random};
  EntnahmeTyp entnahme;
  enum LagerTyp {Kuehlung, Palette, Regal};
  setOf(LagerTyp) lagerKategorien = {LagerTyp.Palette};
  lagerKategorien.size() > 0;
  lagerKategorien->exists(LagerTyp l | l == LagerTyp.Palette);
  compound LagerPlatz {
    LagerTyp lagerArt;
    Boolean hatMHD;
    Integer groesse;
    lagerArt == LagerTyp.Kuehlung implies hatMHD;
  }

  setOf(LagerPlatz) lager;
  enum BindingTime {devTime, runTime};
  annotate BindingTime bt = BindingTime.devTime to lagerKategorien;
}

Grundlage der Konfiguration in IVML ist das Projekt. Es beschreibt eine Konfigurationseinheit. Die Grundidee der Beschreibung von Konfigurationsmöglichkeiten in EASy ist an die Definition von Variablen in Programmiersprachen angelehnt. So stehen die Basistypen (Integer, Real, String, Boolean) zur Verfügung, und es können eigene Aufzählungstypen definiert werden (enum in Listing 1). Die Sprache erlaubt die Definition neuer Typen (bspw. beschreibt der EntnahmeTyp die Möglichkeiten, Waren aus einem Lagerplatz zu entnehmen). Wir gehen hier davon aus, dass im Lager ein globaler Entnahmetyp unterstützt wird – man könnte dies auch je Lagerplatz definieren. IVML unterstützt die Definition neuer Typen wie Mengen (setOf, bspw. lager in Listing 1) oder Listen (sequenceOf), die mehrfache gleichartige Einstellungen beschreiben, oder zusammengesetzte Datentypen (compound), die Konfigurationseinstellungen gruppieren. Eine Besonderheit bei Compounds ist, dass sie ähnlich wie Klassen abgeleitet (refines), verfeinert und in heterogenen Mengen verwaltet werden können. Damit sind Compounds vergleichbar zu Klassen mit dem Unterschied, dass es keine Methoden gibt.

Eine wesentliche Erweiterung gegenüber einer reinen Beschreibung von Konfigurationsmöglichkeiten (Variablen) ist die Möglichkeit, auch Constraints, d. h. Abhängigkeiten zwischen Werten, zu beschreiben. Ein einfaches Beispiel ist in Listing 1 in Zeile 6 zu sehen. Der Constraint besagt, dass es mindestens eine Lagerkategorie geben muss, was durch den Default-Wert in Zeile 5 grundlegend erfüllt ist. Neben solchen globalen Constraints kann ein Compound auch Constraints enthalten, der auf alle Compound-Instanzen angewendet wird. So beschreibt der Compound in Zeile 12, dass ein Lagerplatz, der Kühlung hat, auch ein Haltbarkeitsdatum kennen muss.

Damit ist zwar klar, wie man die Konfigurationsmöglichkeiten beschreiben, aber noch nicht, wie man eine konkrete Konfiguration durchführen kann. Im Prinzip wird eine konkrete Konfiguration in Form von Variablenzuweisungen beschrieben (bspw. als Teil einer Deklaration in Zeile 5). Eine solche Zuweisung kann in einem ableitenden Projekt wieder verändert werden. Man spricht daher auch von einem Default. Um auszudrücken, dass eine Zuweisung endgültig ist (und basierend darauf Aktionen geschehen können), gibt es das freeze-Statement. Eine „gefrorene“ Variable kann nicht mehr im Wert verändert werden. Entsteht durch eine Zuweisung ein Konflikt mit einem Constraint, so wird dies automatisch entdeckt.

Natürlich gibt diese kleine Übersicht nur die wichtigsten Konzepte wieder. So besitzt die IVML Möglichkeiten zur Definition abgeleiteter Typen (typedef), die ebenfalls Constraints enthalten können. Constraints können als Defaults eingesetzt werden, die in der Ableitung verändert werden, und man kann durch die Nutzung von Typverfeinerung, Referenzen und Constraints selbst komplexe topologische Konfigurationsprobleme beschreiben, d. h. Konfigurationen, die aus verknüpften Elementen bestehen und Strukturen wie Graphen definieren können.

Eine weitere wichtige Eigenschaft von IVML ist, dass sich die Konfigurationsinformation mit beliebiger Metainformation annotieren lässt. So kann bspw. eine Variable mit dem Zeitpunkt beschrieben werden, zu dem sie konfiguriert werden sollte (so genannte Bindungszeit). In den letzten beiden Zeilen von Listing 1 findet sich die Beschreibung, dass lagerkategorien bereits zur Entwicklungszeit festgelegt werden sollen.

Insgesamt handelt es sich bei IVML um eine sehr mächtige Konfigurationsbeschreibungssprache, die in einfachen, programmiersprachennahen Konstrukten verpackt ist, um sie für Entwickler leicht verwendbar zu machen.

Handarbeit – nein danke

Doch EASy-Producer ist nicht nur eine Sprache zur Beschreibung von Konfigurationen. Vielmehr zielt das Werkzeug insgesamt darauf ab, sowohl Konfigurationsdefinition als auch Umsetzung zu unterstützen. Zugleich tut es dies auf zwei Ebenen: einerseits interaktiv innerhalb von Eclipse, andererseits mithilfe spezieller Sprachen für die Konfiguration und für die automatisierte Ableitung. Damit ergibt sich insgesamt Abbildung 1: Textuelle Sprachen bilden die Grundlage und spezielle Editoren (teilweise basierend auf Xtext, teilweise vereinfachende Sichten) machen die Mächtigkeit der Sprachen leichter verwendbar.

Abb. 1: Die verschiedenen Sichten von EASy-Producer

Abb. 1: Die verschiedenen Sichten von EASy-Producer

So kann beispielsweise eine Konfiguration direkt in die Oberfläche eingegeben werden. Zu diesem Zweck wertet EASy-Producer die Konfigurationsdefinition aus und generiert die Konfigurationsoberfläche automatisch. Natürlich wird bei der interaktiven Konfiguration auch die Konsistenz der Eingaben überprüft, sodass sich Konfigurationsprobleme leichter erkennen lassen.

Ein wichtiges Grundkonzept des Ansatzes ist das Produktlinienprojekt (PLP). Ein PLP entsteht, indem man die EASy-Producer Nature einem Eclipse-Projekt hinzufügt und das Projekt um Konfigurationsinformation und Transformationsvorschriften ergänzt. Jedes PLP besteht dabei aus einer beliebigen Kombination neu geschriebener ergänzender Teile sowie aus abgeleiteten Teilen aus anderen Projekten, die wiederverwendet werden. Damit kann ein PLP die Produktlinieninfrastruktur, d. h. den gemeinsamen Code, enthalten, ein Teil der Infrastruktur, ein Produkt oder auch eine Kombination sein. Vorläufig beschränken wir uns darauf, dass es ein Infrastruktur- und ein oder mehrere Produkt-PLPs gibt, und greifen die allgemeine Idee am Ende des Beitrags wieder auf. Durch den Kunstgriff, dass das PLP auf Eclipse-Projekte abgebildet werden, lassen sich alle Standardfähigkeiten von Eclipse verwenden. Beim Start untersucht EASy-Producer den Workspace, um relevante Projekte zu finden. Damit kann es die Abhängigkeiten zwischen Projekten verwalten, soweit diese sich im Workspace befinden, aber man ist nicht gezwungen, Vorgängerprojekte ebenfalls immer auszuchecken.

Automatisierte Produktanpassung – Kein Hexenwerk

Wie oben beschrieben, ist es oft erforderlich, ganze Produkte anzupassen. Im Fall von C-Produkten werden hierzu gerne Präprozessorbefehle eingesetzt. Je nach Bindungszeit und Programmiersprache sind auch andere Verfahren wie Konfigurationsdateien, das Einweben von Aspekten oder Dependency Injection gebräuchlich.

Da man nicht vorhersehen kann, welches Anpassungsverfahren in einer konkreten Entwicklung benötigt wird, wurde die universelle und erweiterbare Skriptsprache VIL (Variability Implementation Language) entwickelt, die es ermöglicht, die notwendigen Anpassungen flexibel festzulegen. VIL lehnt sich in Grundideen an bekannte Sprachen wie Ant oder Make an. Im Gegensatz zu anderen Skriptsprachen beinhaltet dieser Ansatz spezielle Erweiterungen, die die Produktanpassung erleichtern. Dazu muss ein Entwickler, der den Anpassungsansatz kennt, die notwendigen Skripte schreiben. Aus den verschiedenen Möglichkeiten demonstrieren wir hier zwei alternative Ansätze: Präprozessierung und Manipulation von Konfigurationsdateien.

private class GoodsRecord {
  // #if($hatMHD == true)
  private Date mhd;
  // #end
}

Listing 2 zeigt eine stark vereinfachte Warenklasse aus dem Beispiellogistiksystem. Da es für Java keinen offiziellen Präprozessor gibt, verwenden wir hier beispielhaft Apache Velocity. Dabei markieren wir nicht benötigte Codeteile mit Velocity-Anweisungen in Kommentaren, die zur Vereinfachung genau auf die Konfigurationsvariablen reagieren.

Da VIL eine Einbindung mit Velocity anbietet, können wir die Produktanpassung in wenigen Zeilen beschreiben (Listing 3). Das Skript erhält das Quellprojekt source, die aktuelle Konfiguration config und das Zielprojekt target von EASy-Producer als Eingabe mit der Idee, dass die Inhalte des Quellprojekts unter Berücksichtigung der Konfiguration genutzt werden, um eine angepasste Instanz in das Zielprojekt abzuleiten. Transformationsanweisungen beschreiben wir in Form von Regeln, die von Make inspiriert sind. Das mag für Java-basierte Systeme etwas ungewöhnlich erscheinen, erlaubt uns aber, Transformationen mit Vor- und Nachbedingungen einzuschränken. Da Vor- und Nachbedingungen nicht angegeben werden müssen, kann man Transformationen auch eher workfloworientiert wie in Ant schreiben. Die main-Regel in Listing 3 steuert den Ablauf. Da wir den gemeinsamen Code nicht verändern möchten, ist der erste Schritt das Kopieren der benötigten Dateien von source nach target. Dies erfolgt in Listing 3 in der Regel copySRCFiles, die Vor- und Nachbedingung in Form von Quell- und in Ziel-Pattern ausnutzt, um nur die nicht vorhandenen bzw. nicht mehr aktuellen Dateien zu kopieren. Dabei wird in der Regel jede zu kopierende Datei in FROM und der jeweilige Zielpfad in TO bereitgestellt. Hier können auch gleich weitere Anpassungen an den zu kopierenden Dateien erfolgen. Danach wenden wir (in Zeile 4) Velocity auf alle Java-Dateien an.

vilScript PL_Lager (Project source, Configuration config, Project target) {
  main(Project source, Configuration config, Project target) = : {
    copySRCFiles(source, target);
    velocity("$target/**/*.java", config);
  }
  copySRCFiles(Project source, Project target) = "$target/src/**/*.java" :
    "$source/src/**/*.java" {
    FROM.copy(TO);
  }
}

Nehmen wir nun alternativ an, dass die Programmteile für das Mindesthaltbarkeitsdatum über Dependency Injection ein- und ausgeschaltet werden können und es eine XML-Datei gibt, die die Einstellungen für die Maximalkonfiguration beinhaltet. Dann können wir die XML-Funktionen von VIL anwenden, um eine passende Konfigurationsdatei abzuleiten.

Listing 4 zeigt eine VIL-Regel, die eine Konfigurationsdatei für das Spring-Framework anpasst. Dabei verwenden wir zwei spezielle VIL-Typen: Das XmlFileArtifact stellt eine geparste XML-Datei dar, und PL_Lager ist ein dynamischer Typ, der den Zugriff auf eine Configuration durch Funktionen vereinfacht, die aus der Konfigurationsdefinition abgeleitet sind. In Zeile 2 definieren wir zunächst einen XPath-Ausdruck, der das zu manipulierende Element in der XML-Datei festlegt. In Zeile 3 greifen wir auf das so festgelegte XML-Element zu und ersetzen dessen Inhalt durch den Konfigurationswert für das Mindesthaltbarkeitsdatum.

instantiateMhdSpring (XmlFileArtifact f, PL_Lager config) = : {
  String xPath = "/spring/objects/object[id='mhd']/property";
  f.selectByXPath(xPath).projectSingle().setCData(config.hatMhd);
}

Grundsätzlich sind in VIL zunächst alle Dateien erst einmal vom Typ FileArtifact. Durch Mapping-Regeln kann VIL automatisch den speziellen Typ für eine Datei heraussuchen. Um diesen zu verwenden, kann der Skriptentwickler Regeln überladen, die VIL anhand des tatsächlichen Typs aufruft (Dynamic Dispatch).

Insgesamt ist EASy-Producer ein erweiterbarer Werkzeugkasten, der dem Entwickler eine Vielzahl von Anpassungsmöglichkeiten zur Verfügung stellt. Welche Anpassung für ein Projekt die richtige ist und welche VIL-Fähigkeiten dafür benötigt werden, hängt von der jeweiligen Architektur, der Entwicklungskultur und dem Bindungszeitpunkt ab. Allerdings können wir in diesem Beitrag nur einen kleinen Ausschnitt der Fähigkeiten von VIL diskutieren, denn VIL ermöglicht ebenfalls:

  • Manipulation bestehender Dateien: In Einzelfällen können Anpassungen einer Textdatei durch Operationen wie Anhängen oder Ersetzen von regulären Ausdrücken erfolgen. Mehr Sicherheit bieten jedoch syntaxgestützte Operationen, die von VIL-Erweiterungen bereitgestellt werden. Von Hause aus unterstützt VIL dies bspw. für Java.
  • Generierung von Textdateien und Code: Produkte können auch durch Codegenerierung abgeleitet werden. Da Codegenerierung oft durch Templates beschrieben wird, haben wir die Templatesprache VTL realisiert, die Fähigkeiten von VIL mit bekannten Templatekonzepten der Sprache Xpand verbindet. Natürlich kann man so auch Konfigurations- oder Skriptdateien für die Laufzeitanpassung automatisiert erzeugen.
  • Löschen von Elementen: Falls es die Architektur erlaubt, können Anpassungen auch durch das Löschen ganzer Quelltextdateien oder von Dateifragmenten erzeugt werden.
  • Ausführung komplexer externer Operationen: VIL-Erweiterungen können komplexe Befehle definieren, die nicht so einfach in VIL beschrieben werden können. Aktuell stehen u. a. Velocity, der Java-Compiler, der AspectJ-Compiler, Ant, Make und Maven zur Verfügung. Für Sonderfälle kann man in VIL auch direkt Kommandozeilenoperationen ausführen.
  • Wertanpassungen: Manchmal entspricht der konfigurierte Wert nicht dem Format, das für ein Artefakt benötigt wird, aber man möchte dieses Format auch nicht in die Konfiguration schreiben, z. B. Zeichenkodierungen, Quotes oder Escapes. Daher kann man durch VIL-Ausdrücke Konfigurationswerte an das Zielartefakt anpassen.
  • Struktur der Konfiguration: Neben den Werten kann VIL auch auf die Typen einer Konfiguration und deren Struktur zugreifen. Damit kann man elegant eine Konfiguration ablaufen und Artefakte erzeugen, z. B. individuelle Konfigurationsdateien für einzelne Lagerplätze. Zudem hat VIL Zugriff auf die Metainformation der Konfiguration, sodass Anpassungen von IVML-Annotationen abhängen können.
  • Generische Anpassungen: Die Anpassung in Listing 4 ist auf eine Konfigurationseinstellung festgelegt, kann also nicht wiederverwendet werden. In realen Projekten würde man dies generisch machen, indem entweder eine Mapping-Datei verwendet wird oder die Verbindung zwischen Konfiguration und Änderung im Quelltext durch Annotationen hergestellt wird. Beides wird durch VIL unterstützt.

Ist das alles? Was geht noch?

Komplexe Netzwerke: Der typische Fall einer Produktlinie ist, dass es eine wiederverwendbare (und anpassbare) Implementierung gibt – und aufbauend darauf die verschiedenen Produkte, die diese Infrastruktur instanziieren und gegebenenfalls durch spezifische Funktionalität ergänzen. Ein Produktlinienprojekt in EASy-Producer kann jedoch beliebig viele wiederverwendbare Teile mit neuen Teilen kombinieren. Darüber hinaus kann ein Projekt viele Vorgänger haben (also wiederverwendbare Teile kombinieren), und diese wiederverwendbaren Teile können auch lediglich teilweise konfiguriert werden. So kann ein Teil der Konfigurationsmöglichkeiten weitergegeben werden. Damit sind dann komplexe Projektbeziehungen wie in Abbildung 2 möglich, bei denen bspw. Variabilität von der PL_Graphics über die PL_Video zu Produkt 3 weitergegeben werden kann.

eichelberger_2

Abb. 2: EASy-Producer unterstützt nicht nur einfache Produktlinien, sondern komplexe Projektabhängigkeiten

Automatisierung: In der Praxis – vor allem im Kontext agiler Ansätze – sind kontinuierliche, automatisierte Builds sehr wichtig. Daher ist es auch notwendig, Konfiguration und Instanziierung automatisieren zu können. Dies ist möglich, da zu den EASy-Producer-Werkzeugen neben der Eclipse-Integration auch eine weitere Version gehört, die von der Kommandozeile, bzw. aus beliebigen Build-Skripten heraus aufgerufen werden kann. Damit lassen sich Continuous-Integration-Szenarien effektiv abbilden. Insbesondere ist es möglich, beliebig viele Varianten automatisiert zu generieren.

Späte Konfiguration: Die Beispiele, die wir besprochen haben, fokussierten darauf, EASy-Producer zur Entwicklungszeit zu nutzen, um Anpassungen durchzuführen. Prinzipiell kann eine Konfiguration aber zu jedem Zeitpunkt erfolgen (bspw. Startzeit, Laufzeit), da EASy-Producer auch ohne die Eclipse-Umgebung lauffähig ist. Darüber hinaus erlauben Sprachfeatures wie Annotationen, Konfigurationsinformationen dahingehend auszuwählen, wann eine Konfiguration erfolgen soll (Bindungszeit), und die Transformationen entsprechend anzupassen. Vor allem der Bereich der Anpassung zur Laufzeit ist aktuell Gegenstand der Weiterentwicklung des Werkzeugs. So wenden wir EASy-Producer im Bereich der Big-Data-Analyse an, um Datenverarbeitungspipelines zu konfigurieren [3]. Dazu wurde einerseits ein grafisches Werkzeug mit Drag-and-Drop-Editor für topologiebasierte Konfigurationen entwickelt, andererseits werden die Fähigkeiten zur Laufzeit(re-)konfiguration – auf die wir hier aus Platzgründen kaum eingehen konnten – weiterentwickelt.

Zusammenfassung

EASy-Producer ist ein Eclipse-Plug-in, das die konsistente Konfiguration von Softwaresystemen und die automatisierte Ableitung von Produkten ermöglicht. Dies kann sowohl interaktiv innerhalb der Eclipse-Umgebung erfolgen, als auch automatisiert unabhängig von Eclipse. Ziel des Ansatzes ist es, dem Entwickler möglichst große Flexibilität zu geben, sodass Produktlinien verschiedenster Größe realisiert werden können. Um zu überprüfen, dass die Konzepte und deren Umsetzung funktionieren, haben wir mit EASy-Producer bislang diverse (industrielle) Fallstudien über Warenwirtschaftssysteme, Automobilsoftware, betriebliche Informationssysteme aber auch Mobile-Apps durchgeführt.

Weitere Informationen zu Easy-Producer (Sprachhandbücher, Onlineressourcen etc.) stehen bereit. Dort findet sich auch die Eclipse-Updatesite. Das Projekt ist unter Open-Source-Lizenz (Apache 2.0) online zugänglich auf GitHub, die Entwicklung migriert dorthin (aktuell findet man dort die Releaseversionen). Die Autoren freuen sich auch über eine Kontaktaufnahme.

Verwandte Themen:

Geschrieben von
Klaus Schmid
Klaus Schmid
Klaus Schmid arbeitet seit fast zwanzig Jahren im Bereich Produktlinienentwicklung. Er ist Professor für Software Engineering an der Universität Hildesheim; zuvor war er am Fraunhofer IESE tätig. Sein Hauptinteresse gilt der Steigerung von Softwareentwicklungseffizienz und -qualität.
Holger Eichelberger
Holger Eichelberger
Holger Eichelberger ist Mitarbeiter von Professor Schmid und hat zuvor an der Universität Würzburg promoviert. Seine Hauptinteressen sind die einfache Entwicklung von konfigurierbaren und adaptiven Softwaresystemen sowie Performanceanalyse.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: