Artefakteübergreifendes Varianten-Management Werkzeuggestützte Erweiterung der herkömmlichen Produktlinienentwicklung

Die Komplexität der Software-Komponenten in eingebetteten Systemen im Automobilbereich wächst stetig. Getrieben durch Kundenwünsche, Produktdifferenzierung, unterschiedliche Märkte und gesetzliche Vorgaben, nimmt auch die Variantenzahl einzelner Software-Komponenten zu. Das Konzept der Produktlinienentwicklung berücksichtigt die Variantenvielfalt bereits in der Entwicklungsphase, jedoch können Produktlinienspezifikationen schnell komplex und somit schwer beherrschbar werden. Unter anderem weil komplexe bzw. variantenreiche Entwicklungsartefakte unter-schiedlichen Typs entstehen und diese zueinander in Beziehung gesetzt werden müssen. Dieser Artikel nimmt sich dieses Problems an und stellt einen werkzeuggestützten Lösungsansatz als Erweiterung der herkömmlichen Produktlinienentwicklung vor.

Betrachtet man heute die Entwicklungsartefakte (z.B. Anforderungsspezifikationen, Modelle, Quell-Code, Testspezifikationen, Dokumentationen) für Systeme genauer, so stellt man fest, dass zunehmend nicht ein einzelnes statisches System, sondern ein System mit Varia­bilitäten beschrieben wird. Hiermit wird die Wiederverwendung solcher Entwicklungsartefakte für unterschiedlich ausgeprägte Systeme beabsichtigt. So werden z.B. in Anforderungsspezifikationen zusätzliche Attribute hinzugefügt, mit denen ausgedrückt wird, ob eine bestimmte Anforderung für eine konkrete Ausprägung des Systems Bestand hat oder nicht. In Abhängigkeit von den Eigenschaften eines konkreten Systems werden dann die Anforderungen mit Hilfe von View-Mechanismen gefiltert, so dass nur die relevanten Anforderungen übrig bleiben. Eine Anforderungsspezifikation enthält typischerweise eine Vielzahl solcher Attribute. Darüber hinaus existieren im Regelfall zusätzliche Bedingungen bezüglich der Wertesetzung zwischen diesen Attributen. So existieren beispielsweise Include-Beziehungen, wenn die Wertesetzung eines Attributs eine bestimmte Wertesetzung eines anderen Attributs impliziert, oder Exclude-Beziehungen, die den gegenseitigen Ausschluss des Setzens bestimmter Werte zweier Attribute bedingen. Solche Bedingungen sind zusätzlich in den Filtern einer View und beim manuellen Wertesetzen durch den Anforderungsentwickler zu berücksichtigen.

Bei der modellgetriebenen Erstellung von variantenreichen Modellen ist ein ähnliches Vorgehen zu beobachten. Betrachtet man etwa Matlab-Simulink/Stateflow-Modelle, so existieren an vielen Stellen im Modell Variationspunkte. Diese sind beispielsweise mit bedingt ausführbaren Blöcken realisiert, wie etwa Enabled SubSystems, indem deren Enabled-Port jeweils ein Konstantenblock vorgeschaltet wird. In diesem Fall korreliert ein solcher Konstantenblock mit einer variablen Systemeigenschaft und aktiviert bzw. deaktiviert das Enabled SubSystem dauerhaft. Hierbei werden in der Regel die variablen Systemeigenschaften außerhalb des Simulink-Modells in einer flachen Codierungsliste verwaltet, etwa einer Excel-Datei. Nach Konfiguration einer solchen Codierungsliste wird ein äquivalentes Simulink-Datenobjekt generiert. Es stellt zusammen mit dem Simulink-Modell eine Variante dar, indem es den zuvor angesprochenen Konstantenblöcken gesetzte Werte aus der Codierungsliste zuweist. Aus derart mit Variabilität versehenen Modellen kann schließlich Programm-Code generiert werden, bei dem ein Enabled SubSystem nur dann im Code vorkommt, wenn der vom vorgeschalteten Konstantenblock ausgehende Wert dessen Enabled Port aktiviert.

Ein weiteres wichtiges Entwicklungsartefakt ist manuell erstellter C-Code. Variable Systemeigenschaften werden hierbei üblicherweise mittels Präprozessoranweisungen (z.B. #ifdef) im Code berücksichtigt. Zur Konfiguration kommen auch hier Codierungslisten zum Einsatz.

Die beschriebenen Ansätze zur Handhabung von Variabilität sind zwar ein Mittel, mit dem man Varianten von Systemen mit ähnlichen Eigenschaften erstellen kann, jedoch sind hier Nachteile zu erkennen, die sich bei wachsender Komplexität negativ auswirken. Nachteilig ist die artefakttypspezifische heterogene Spezifikation von variablen Systemeigenschaften (z.B. Attribute in Anforderungsspezifikationen, Codierungslisten bei Simulink und C-Code). Dazu kommt noch das implizite und teilweise informell dokumentierte Wissen über Einschränkungen hinzu, z.B. durch Include- bzw. Exclude-Beziehungen. Insgesamt fehlt auf diese Weise der notwendige neutrale und artefakttypunabhängige Gesamtüberblick über die variablen Eigenschaften potentieller Systeme. Die Gefahr von Inkonsistenzen sowohl innerhalb eines Artefakttyps als auch artefakttypübergreifend ist signifikant, und die Wartbarkeit wird mit steigender Komplexität zunehmend schwierig. Das Prinzip der Produktlinienentwicklung hat zum Ziel, diesen Nachteilen entgegenzuwirken.