Eine breite Fahrzeugpalette, spezifische Produktanforderungen aus globalen Ma¨rkten und eine Vielzahl softwarebasierter Ausstattungsvarianten fu¨hren in der Automobilindustrie zu einer immer gro¨ßeren Produktvielfalt. Um die entstehende Komplexita¨t beherrschen zu ko¨nnen, wird die Methode des merkmalbasierten Variantenmanagements eingesetzt. Der bei der Daimler AG verfolgte Ansatz sieht vor, dass variable Komponenten in Entwicklungsartefakten, wie beispielsweise einem Matlab / Simulink-Modell, mithilfe von aussagenlogischen Formeln u¨ber Merkmalen konfiguriert werden. Fehler innerhalb dieser Konfigurationsformeln bzw. des Merkmalmodells ko¨nnen bei der Konfiguration zu inkonsistenten Systemvarianten f u¨hren. Wir pra¨sentieren daher Konsistenzbedingungen, um die Konfiguration abzusichern. Diese basieren auf SAT-Analysen des Merkmalmodells und der Konfigurationsformeln. Erste Implementierungen zeigen, dass die Performanz solcher Analysen auf industriellen Variantenmodellen praxistauglich ist.
In der Automobilindustrie wird das Konzept der Software-Produktlinien [CN01] eingesetzt, um der steigenden Variantenkomplexita¨t in softwarebasierten Systemen zu begegnen. Erreicht dabei die Variabilita¨t in Entwicklungsartefakten, wie z.B. einem SimulinkModell oder einem Anforderungsdokument, eine hinreichende Komplexita¨t, so wird sie in einem merkmalbasierten Variantenmodell dokumentiert. Darin werden die gemeinsamen und unterschiedlichen funktionalen Eigenschaften der System-Varianten in einem Merkmalmodell [KCH+90] festgehalten. Um auch die Konfiguration des Artefaktes zu erm o¨glichen, muss zusa¨tzlich das Mapping zwischen Merkmalen und den variablen Bestandteilen des Artefaktes erstellt werden, welches im sogenannten Konfigurationsmodell abgebildet wird.
Ist ein Variantenmodell im Einsatz, entwickelt es sich stetig weiter. Dadurch entsteht die Herausforderung, dessen Konsistenz im Evolutionsprozess zu gewa¨hrleisten, welche auch schon in anderen Arbeiten thematisiert wurde [LSB+, Hol12]. Als einen Lo¨ sungsansatz
Copyright c 2014 for the individual papers by the papers’ authors. Copying permitted for private and academic purposes. This volume is published and copyrighted by its editors.
yDieser Beitrag wurde durch das BMBF im Projekt SPES 2020 XT (Fo¨rderkennz: 01IS12005) gefo¨rdert. dafu¨r pra¨sentieren wir Analysen des Variantenmodells, um nach einer A¨ nderung pru¨fen zu ko¨nnen, ob Inkonsistenzen bzw. Fehlmodellierungen aufgetreten sind. Durch die aussagenlogische Fundierung des Merkmalmodells ko¨nnen diese Konsistenzbedingungen auf die Frage der Erfu¨llbarkeit einer aussagenlogischen Formel (SAT) zuru¨ckgefu¨hrt werden. 2
In diesem Abschnitt wird na¨her auf die beiden Teilmodelle des Variantenmodells und den Konfigurationsprozess eingegangen. 2.1
Im Merkmalmodell sind die funktionalen Eigenschaften des Systems hierarchisch als Baum strukturiert [KCH+90].
Definition: Sei zuna¨chst M = (M; H [ C; r) ein 3-Tupel bestehend aus: einer endlichen Menge M , der Menge H der hierarchischen Beziehungen:
H := opt [_ obl [_ alt [_ dis
M
M , der Menge C der Cross-Tree-Constraints:
C := req [_ con
M
M und einem ausgezeichnetem Wurzelelement r 2 M Wir nennen M ein Merkmalmodell, falls gilt: (M1) Fu¨r jedes m 2 M n frg existiert genau ein x 2 M mit (x; m) 2 H (M2) Es existiert kein x 2 M mit (x; r) 2 H (M3) Fu¨r jedes x 2 M existieren x1; : : : ; xn 2 M mit (r; x1); : : : ; (xn; x) 2 H Mit anderen Worten: Interpretiert man M als Knotenmenge und H als Kantenmenge, so ist (M; H) ein Baum. Die Relationen in H beschreiben dabei die Variationstypen der Merkmale. Wir unterscheiden in Anlehnung an bestehende Ansa¨tze [Bat05, CE00] die folgenden Typen: optional (opt), obligatorisch (obl), alternativ (alt) und disjunktiv (dis). Ist ein Paar von Merkmalen in einer der Relationen enthalten, so stehen diese in einer Vater-Kind-Beziehung und das Kindmerkmal hat den entsprechenden Variationstyp. Zum Beispiel bedeutet (x; y) 2 opt, dass x das Vatermerkmal des optionalen Merkmals y ist. Dadurch definiert H eine Hierarchie auf der Menge M der Merkmale.
Abbildung 1: Beispiel fu¨r ein Merkmalmodell Mithilfe der Cross-Tree-Constraints lassen sich weitere Beziehungen zwischen Merkmalen definieren. Wir beschra¨nken uns hier auf die beiden Typen requires (req) und conflicts (con), da sie in der Praxis am ha¨ufigsten verwendet werden. In Abb. 1 sieht man ein stark vereinfachtes Beispiel fu¨r ein Merkmalmodell der Fahrerassistenzsysteme (FAS). Entsprechend der obigen Definition hat dieses Modell die folgende Struktur: opt = f(FAS, Tempomat), (FAS, Bremsassistent) (Radarsysteme, Nahbereichsradar), (Radarsysteme, Fernbereichsradar)g obl = f(FAS, Limiter), (FAS, Radarsysteme)g alt = f(Tempomat, einstufiger Tempomathebel), (Tempomat, zweistufiger Tempomathebel)g req = f(Bremsassistent, Nahbereichsradar)g bzw. dis = con = ; Ausgehend von der obigen Beschreibung des Merkmalmodells la¨sst sich nun dessen aussagenlogische Repra¨sentation definieren. Mit F (M ) bezeichnen wir dabei hier und auch im Weiteren die Menge aller aussagenlogischen Formeln u¨ber der Merkmalmenge M . Definition: Sei M = (M; H [ C; r) ein Merkmalmodell mit H = fopt; obl; alt; disg und C = freq; cong. Dann bezeichnen wir mit (M) 2 F (M ) die Formel des Merkmalmodells M. Sie ist definiert durch: (M) d=ef r ^ ^ ^
^ (x;y)2opt
^ (x;y)2obl (y ! x) (x $ y) ^ x2M (x;y1);:::;(x;yk)2alt ((x $ k _ yi) ^ ^ :(yi ^ yj )) i=1 i<j (1) (2) (3) (4) Die Idee, das Merkmalmodell mithilfe der Aussagenlogik zu formalisieren, wurde bereits in verschiedenen Arbeiten beschrieben [Bat05, CW07]. Die Struktur der hier dargestellten Formel ist angelehnt an die Darstellung in [SLB+11]. Nach dieser allgemeinen Definition werfen wir nun einen Blick auf die Formel unseres Beispiel-Merkmalmodells. Sei M das Merkmalmodell aus Abb. 1. Dann ist (M) =
F AS ^(T empomat ! F AS) ^(Bremsassistent ! F AS) ^(N ahbereichsradar ! Radarsysteme) ^(F ernbereichsradar ! Radarsysteme) ^(F AS $ Limiter) ^(F AS $ Radarsysteme) ^(T empomat $ (einstuf iger T H _ zweistuf iger T H))1 ^:(einstuf iger T H ^ zweistuf iger T H) ^(Bremsassistent ! N ahbereichsradar) Wir ko¨nnen nun das Merkmalmodell mithilfe einer aussagenlogischen Formel beschreiben. Ist diese Formel (M) erfu¨llbar, so existiert eine gu¨ltige Variante fu¨r das Merkmalmodell M. Genauer gesagt ist jede Belegung, die (M) erfu¨llt, eine gu¨ltige Variante des Merkmalmodells. Dies fu¨hrt uns zum Begriff der Selektion.
Definition: Sei M = (M; H [ C; r) ein Merkmalmodell mit M = fm1; : : : ; mng. Dann nennen wir S 2 F (M ) eine Selektion von M, falls gilt:
S = s1 ^ : : : ^ sn mit si = mi oder si = :mi fu¨r 1 i n.
Eine Selektion S 2 F (M ) heißt g u¨ltig, falls die Formel S ^ (M) 2 F (M ) erfu¨llbar ist.
1Fu¨r eine u¨bersichtlichere Darstellung der Formel haben wir in diesem Beispiel die Namen der Merkmale ”einstufiger Tempomathebel“ und ”zweistufiger Tempomathebel“ durch ”einstufiger TH“ bzw. ”zweistufiger TH“ ersetzt.
Abbildung 2: Ausschnitt aus einem Konfigurationsmodell 2.2
Im Konfigurationsmodell ist der Zusammenhang zwischen Merkmalen und den variablen Komponenten im Entwicklungsartefakt dokumentiert. Dies kann zum Beispiel ein optionales Subsystem in Simulink oder eine variable Anforderung in einem Lastenheft sein. Dabei sind fu¨r uns vor allem die aussagenlogischen Konfigurationsformeln relevant, die formal beschreiben, welche Merkmalselektion zu welcher Systemvariante fu¨hrt. Definition: Sei M ein Merkmalmodell. Ein zugeho¨riges Konfigurationsmodell ist eine endliche Menge von Variationspunkten KM = fV P1; : : : ; V PN g. Dabei besteht jeder Variationspunkt V P = ((V1; KF1); : : : ; (Vp; KFp)) aus einer endlichen Menge von Variationen V1; : : : ; Vp. Jeder Variation Vi ist eine Konfigurationsformel KFi 2 F (M ) zugeordnet. Das Tupel V M = (M; KM ) aus Merkmalmodell und Konfigurationsmodell nennen wir ein Variantenmodell.
In Abb. 2 sieht man einen beispielhaften Ausschnitt aus einem Konfigurationsmodell zu dem Merkmalmodell in Abb. 1. Es entha¨lt den Variationspunkt V P1 =VAR Tempomat mit den Variationen V1 = (Leermodul; : (T empomat)), V2 = (T M P H einstuf ig; einstuf iger T empomathebel) und V3 = (T M P H zweistuf ig; zweistuf iger T empomathebel).
V P1 hat damit vergleichsweise einfache Konfigurationsformeln, da sie jeweils nur aus einem Literal bestehen. Grundsa¨tzlich sind jedoch Konfigurationsformeln beliebiger Gro¨ße mo¨glich und auch realistisch, wodurch die Komplexita¨t entsteht, die eine manuelle Analyse deutlich erschwert bzw. unmo¨glich macht. V P1 ko¨nnte beispielsweise die Modellierung eines Subsystems in Simulink sein, welches, abha¨ngig von einem Parameter, entweder die eingehenden Signale ohne Verarbeitung weitergibt (V1) oder einen Tempomat mit einbzw. zweistufigem Tempomathebel implementiert (V2 bzw. V3). 2.3
Wie dieser Parameter ermittelt wird, beschreibt der Konfigurationsprozess. Soll dabei eine neue Systemvariante konfiguriert werden, wa¨hlt man dafu¨r zuna¨chst die gewu¨nschten Merkmale aus und definiert damit eine Selektion. Abha¨ngig von dieser Selektion wird fu¨r jeden Variationspunkt einzeln entschieden, welche seiner Variationen in das System integriert wird.
Definition: Sei dazu V P = ((V1; KF1); : : : ; (Vp; KFp)) 2 KM ein Variationspunkt und S 2 F (M ) eine Selektion. Ist dann S ^ KFi erfu¨llbar fu¨r ein 1 i p, so nennen wir Vi die an dem Variationspunkt V P fu¨r die Selektion S gu¨ltige Variation. In diesem Fall wird im weiteren davon die Rede sein, dass die Selektion S die Konfigurationsformel KFi erfu¨llt.
Wa¨ren fu¨r eine Premium-Variante der Fahrerassistenzsysteme z.B. unter anderen die Merkmale Tempomat und zweistufiger Tempomathebel ausgewa¨hlt, so wu¨rde der Konfigurationsprozess am Variationspunkt V P1 die Variation 2 als gu¨ltig bestimmen. Auf diese Art und Weise erha¨lt man fu¨r jeden Variationspunkt genau eine Variation, welche mithilfe des bereits erwa¨hnten Parameters codiert wird. Diese Liste an Variationspunkt-ParameterPaaren wird anschließend in das Entwicklungsartefakt exportiert (z.B. per xml-Datei), um die noch offene Variabilita¨t zu binden. In unserem Beispiel wu¨rde dabei in das SimulinkSubsystem die Implementierung des Tempomaten mit zweistufigem Tempomathebel eingefu¨gt werden.
Fu¨r den Konfigurationsprozess ist es dabei essentiell, dass fu¨r eine gegebene Selektion S an jedem Variationspunkt genau eine Variation gu¨ltig wird. Ist an einem Variationspunkt diese Eindeutigkeit nicht gegeben, so kann dessen Parameter gar nicht oder ggf. nur falsch ermittelt werden. Die Folge davon ist ein inkonsistentes bzw. falsch konfiguriertes Artefakt. Im na¨chsten Abschnitt werden Konsistenzbedingungen beschrieben, die solche Fehlkonfigurationen verhindern ko¨nnen. 3
In diesem Abschnitt werden Konsistenzbedingungen fu¨r das Variantenmodell vorgestellt. Diese beziehen sich vor allem auf die Konfigurationsformeln, da diese in der Regel ha¨ndisch eingegeben werden, wodurch es leicht zu Fehlern kommen kann. Außerdem wird auch die Formalisierung des Merkmalmodells einbezogen, womit eine Analyse aller theoretisch mo¨glichen (also gu¨ltigen) Selektionen sichergestellt werden kann. Somit ko¨nnen nicht nur die bestehenden, sondern auch zuku¨nftige Varianten abgesichert werden. In den folgenden Unterabschnitten wird jeweils die Konsistenzbedingung zuerst formuliert (Bedingung) und danach kurz erkla¨rt (Beschreibung). Anschließend wird dargestellt, wie die Bedingung mithilfe der Aussagenlogik gepru¨ft wird (Pru¨fung) und schlussendlich ein Beispielmodell angegeben, welches die Bedingung verletzt (Gegenbeispiel). 3.1
Bedingung: Keine Konfigurationsformel steht im Widerspruch zu der Modellierung im Merkmalmodell.
Abbildung 3: inkonsistentes Konfigurationsmodell Beschreibung: Jede Konfigurationsformel muss auch unter den Bedingungen des Merkmalmodells erfu¨llbar sein. Andernfalls wird die betroffene Konfigurationsformel von keiner gu¨ltigen Selektion erfu¨llt. Dadurch ist die zugeho¨rige Variation nie Teil einer Systemvariante und damit u¨berflu¨ssig.
Pru¨ fung: Bei dieser Konsistenzbedingung wird fu¨r jede Konfigurationsformel KF im Konfigurationsmodell einzeln gepru¨ft, ob der folgende Ausdruck erfu¨llbar ist: (M) ^ KF Ist diese Formel nicht erfu¨llbar, gibt es also keine Belegung die (M) und KF erfu¨llt, so existiert keine gu¨ltige Selektion, die die Konfigurationsformel KF erfu¨llt. Sie steht somit im Widerspruch zum Merkmalmodell.
Gegenbeispiel: Betrachten wir das Variantenmodell, welches aus dem Merkmalmodell der Fahrerassistenzsysteme von oben und dem Konfigurationsmodell in Abb. 3 besteht. Hier verletzt der Variationspunkt VAR VP 1 die beschriebene Konsistenzbedingung. Die Konfigurationsformel von Variation 2 wird bei einer gu¨ltigen Selektion immer zu false evaluieren, da die Merkmale einstufiger Tempomathebel und zweistufiger Tempomathebel im Merkmalmodell als Alternativen modelliert sind und somit nicht beide Merkmale in einer Selektion ausgewa¨hlt werden du¨rfen.
(M) ^ (:KF ) 3.2
Bedingung: Keine Konfigurationsformel wird von allen gu¨ltigen Selektionen erfu¨llt. Beschreibung: Diese Konsistenzbedingung soll verhindern, dass man eine Konfigurationsformeln formuliert, die von jeder gu¨ltigen Selektion S 2 F (M ) erfu¨llt wird, die also eine Tautologie bzgl. der Merkmalmodellierung ist.
Pru¨ fung: Bei dieser Konsistenzbedingung wird fu¨r jede Konfigurationsformel KF im Konfigurationsmodell einzeln gepru¨ft, ob der folgende Ausdruck erfu¨llbar ist: Ist diese Formel nicht erfu¨llbar, so existiert fu¨r die Konfigurationsformel KF keine gu¨ltige Selektion, die ihre Negation erfu¨llt. Somit wird diese Formel von jeder gu¨ltigen Selektion erfu¨llt, ist also eine Tautologie im Bezug auf die Merkmalmodellierung. Gegenbeispiel: Betrachten wir wieder das Variantenmodell, welches aus dem Merkmalmodell der Fahrerassistenzsysteme von oben und dem Konfigurationsmodell in Abb. 3 besteht. Hier verletzt der Variationspunkt VAR VP 2 die beschriebene Konsistenzbedingung. Die Konfigurationsformel von Variation 1 wird von jeder gu¨ltigen Selektion erfu¨llt, da das Merkmal Limiter obligatorisch ist und daher in jeder gu¨ltigen Merkmalauswahl selektiert werden muss. Damit ist diese Konfigurationsformel eine Tautologie bzgl. des Merkmalmodells. 3.3
Bedingung: An jedem Variationspunkt muss fu¨r jede gu¨ltige Selektion mindestens eine Konfigurationsformel erfu¨llt sein.
Beschreibung: Wie bereits in Abschnitt 2 beschrieben, ist im Konfigurationsprozess wichtig, dass von einer gu¨ltigen Selektion genau eine Konfigurationsformel je Variationspunkt erfu¨llt wird. Diese und die na¨chste Konsistenzbedingung stellen diese Eindeutigkeit sicher. Pru¨ fung: Jeder Variationspunkt wird bei dieser Bedingung einzeln gepru¨ft. Die Bedingung ist fu¨r den Variationspunkt V P = ((V1; KF1); : : : ; (Vp; KFp)) 2 KM verletzt, falls die folgende Formel aus F (M ) erfu¨llbar ist: Denn dann existiert eine Selektion S 2 F (M ), die (M) und
p (M) ^ ^ (:KFi)
i=1 p ^ (:KFi) i=1 (20) (21) erfu¨llt. S ist somit gu¨ltig und erfu¨llt :KFi fu¨r alle 1 i p. Diese gu¨ltige Selektion S erfu¨llt damit keine Konfigurationsformel an dem Variationspunkt V P 2 KM . Gegenbeispiel: Betrachten wir das Variantenmodell, welches aus dem Merkmalmodell der Fahrerassistenzsysteme von oben und dem Konfigurationsmodell in Abb. 4 besteht. Hier verletzt der Variationspunkt VAR VP 3 die beschriebene Konsistenzbedingung. Das Merkmal Tempomat ist im Merkmalmodell optional, kann damit an- und abgewa¨hlt werden. Beide Konfigurationsformeln werden jedoch nur von Selektionen erfu¨llt, in denen dieses Merkmal ausgewa¨hlt wurde. Dadurch kann fu¨r eine Fahrzeugvariante ohne Tempomat fu¨r diesen Variationspunkt keine Variation ermittelt werden, wodurch die Konfiguration fehlschla¨gt.
Abbildung 4: inkonsistentes Konfigurationsmodell 3.4
Bedingung: An jedem Variationspunkt darf fu¨r jede gu¨ltige Selektion ho¨chstens eine Konfigurationsformel erfu¨llt sein.
Beschreibung: Erga¨nzend zur vorherigen Konsistenzbedingung werden hier Variationspunkte gesucht, an denen fu¨r eine bestimmte Selektion mehr als eine Konfigurationsformel erfu¨llt werden. In diesem Fall ko¨nnte keine gu¨ltige Variation an dem Variationspunkt ermittelt werden, wodurch im Konfigurationsprozess eine fehlerhafte Systemvariante entsteht.
Pru¨ fung: Jeder Variationspunkt wird bei dieser Bedingung einzeln gepru¨ft. Die Konsistenzbedingung ist fu¨r den Variationspunkt V P = ((V1; KF1); : : : ; (Vp; KFp)) 2 KM verletzt, falls die folgende Formel erfu¨llbar ist: erfu¨llbar. Daraus folgt, dass mindestens ein Paar von Indizes 1 i; j p existiert, sodass S ^KFi^KFj erfu¨llbar ist. Das bedeutet, dass die gu¨ltige Selektion S die beiden Konfigurationsformeln KFi und KFj erfu¨llt. Die oben genannte Inkonsistenz liegt damit an dem untersuchten Variationspunkt vor, da zwei verschiedene Konfigurationsformeln existieren, die von einer gu¨ltigen Selektion erfu¨llt werden. Begru¨ndung: Ist der obige Ausdruck erfu¨llbar, so existiert eine Selektion S 2 F (M ), sodass die Formel erfu¨llbar ist. Damit ist insbesondere auch S ^ (M) erfu¨llbar, woraus folgt, dass S eine gu¨ltige Selektion ist. Daru¨ber hinaus ist außerdem damit auch (22) (23) (24)
Modell Variantenmodell 1 Variantenmodell 2
Tabelle 1: Laufzeiten des Prototyps
KB1 KB2 0,143 Sek. 0,143 Sek. 0,146 Sek. 0,147 Sek.
Gegenbeispiel: Betrachten wir wieder das Variantenmodell, welches aus dem Merkmalmodell der Fahrerassistenzsysteme von oben und dem Konfigurationsmodell in Abb. 4 besteht. Hier verletzt der Variationspunkt VAR VP 4 die beschriebene Konsistenzbedingung. Da es durchaus mo¨glich ist, eine gu¨ltige Selektion mit den Merkmalen Tempomat und einstufiger Tempomathebel zu definieren, wu¨rden in diesem Fall beide Konfigurationsformeln von dieser Selektion erfu¨llt werden. Fu¨r diesen Variationspunkt ko¨nnte damit keine eindeutige Variation ermittelt werden, wodurch die Konfiguration fehlschla¨gt. 4
Um die beschriebenen Konsistenzbedingungen auch an bestehenden Variantenmodellen pru¨fen zu ko¨nnen, ist eine prototypische Implementierung entstanden. Dadurch kann ein beliebiges Modell analysiert und im Fehlerfall der betroffene Variationspunkt bzw. die betroffene Konfigurationsformel angegeben werden. Die Analysen wurden an zwei Variantenmodellen durchgefu¨hrt, welche in der industriellen Praxis entstanden sind. Variantenmodell 1 besteht aus einem Merkmalmodell mit 298 Merkmalen und 367 Cross-TreeConstraints und einem Konfigurationsmodell mit 164 Variationspunkten und insgesamt 429 Variationen und demnach ebenso vielen Konfigurationsformeln. Die Gro¨ße des Modells liegt damit in einem Bereich, der fu¨r Doma¨nen wie Motorsteuerung, Fahrerassistenz oder e-Drive u¨blich ist. Das zweite Variantenmodell befindet sich noch in der Entwicklung und ist daher etwas kleiner: 94 Merkmale, 43 Cross-Tree-Constraints, 14 Variationspunkte mit 36 Variationen.
Tabelle 1 zeigt die Zeit, die der SAT-Solver im Durchschnitt beno¨tigt, um eine Anfrage zu bearbeiten. Da bei KB1 bzw. KB2 jede Konfigurationsformel einzeln analysiert wird, mu¨ssen bei unserem ersten Beispielmodell 429 Analysen durchgefu¨hrt werden. Die Pru¨fung des gesamten Modells beno¨tigt daher 429 x 0,143 Sek. 61,3 Sekunden. Bei KB3 und KB4 wird dagegen nur fu¨r jeden Variationspunkt eine SAT-Analyse durchgefu¨hrt, wodurch sich die Laufzeit verringert. Mit durchschnittlich ca. 0.14 Sekunden sind die Laufzeiten des Solvers fu¨r uns zufriedenstellend, zumal auch nach zahlreichen Durchla¨ufen keine Analyse la¨nger als eine halbe Sekunde dauerte. Alle Laufzeiten wurden dabei auf einem Windows 7-PC mit 2,53 GHz und 4 GB RAM gemessen.
Auch andere Arbeiten bescha¨ftigen sich mit dem Mapping zwischen Merkmalen und Komponenten. Reiser et al. pra¨sentieren einen Ansatz fu¨r das Variantenmanagement hierarchischer komponentenbasierter Systeme [RKW09]. Dabei beschreiben Merkmalmodelle die Variabilita¨t der jeweiligen Hierarchieebene, wobei mit sogenannten configuration links Konfigurationsinformationen zwischen den Modellen ausgetauscht werden ko¨nnen. Obwohl sich auch unsere Modellierung auf variable Komponenten bezieht, liegt der Unterschied darin, dass das gesamte System in einem Variantenmodell (und damit einem Merkmalmodell) abgebildet wird, auf das sich die vorgestellten Konsistenzbedingungen beziehen. In [MRM+12] wird ein mengentheoretischer Formalismus vorgestellt, um ein Tracing zwischen Merkmalen (Spezifikation) und Komponenten (Implementierung) zu beschreiben. Wa¨hrend in deren Mapping ein Merkmal stets von einer oder mehreren Teilmengen von Komponenten implementiert werden kann, wird bei uns der Zusammenhang mithilfe einer booleschen Formel ausgedru¨ckt. Diese kann beliebig komplex sein, sodass eine Komponente (in unserem Fall eine Variation) von mehreren Merkmalen abha¨ngen kann oder z.B. in das System integriert wird, sobald ein Merkmal oder eine Kombination von Merkmalen nicht ausgewa¨hlt wird.
Ein a¨hnlicher Ansatz wird in [MHP+07] verfolgt. Hier wird zwischen Produktlinien- und Softwarevariabilita¨t unterschieden und eine separate Modellierung mit OVM- bzw. Merkmalmodellen vorgeschlagen. Auf einer formalisierten Beschreibung dieser Modelle und deren Beziehungen ko¨nnen anschließend Analysen automatisch ausgefu¨hrt werden. Teile dieser Analysen (z.B. nicht realisierbare Merkmalselektionen) ko¨nnen auf unsere Art der Modellierung u¨bertragen werden. Der Großteil ist dagegen fu¨r uns in diesem Beitrag nicht relevant (z.B. fehlende Eindeutigkeit zwischen Produktlinien- und Softwarevariabilita¨t, ungenutzte Merkmale), da sie keine direkte Gefa¨hrdung fu¨r den Konfigurationsprozess darstellen. Insgesamt zielen die vorgestellten Analysen eher darauf ab, ob die Architektur der Produktlinie flexibel genug ist, um die geplanten Produkte zu konfigurieren, wohingegen wir uns in diesem Paper auf Fehler in der Aussagenlogik der Konfigurationsformeln konzentrieren, um den Konfigurationsprozess an sich abzusichern.
Thaker et al. beschreiben einen Mechanismus fu¨r die ”safe composition of product lines“ [TBKC07]. Auch dort werden SAT-Analysen vorgestellt, um zu pru¨fen, ob gu¨ltige Merkmalselektionen zu inkonsistenten Systemvarianten fu¨hren ko¨nnen. Wa¨hrend wir auf Inkonsistenzen innerhalb des Variantenmodells eingehen, werden dort Constraints beschrieben, die sich aus der Zusammensetzung von ”feature modules“, also aus der Produktlinie selbst, ergeben. 6
Die vorgestellten Analysen sollen sicherstellen, dass der Konfigurationsprozess fehlerfrei abla¨uft, damit eine gu¨ltige Merkmalselektion stets zu einer validen Systemvariante fu¨hrt. Mit den Konfigurationsformeln stehen dabei gerade die Modellelemente im Fokus, die oft Literatur [CE00] [CN01] [CW07] [Hol12] [LSB+] ha¨ndisch erstellt werden und daher eine potentielle Fehlerquelle darstellen. Die manuelle Pru¨ fung der beschriebenen Bedingungen ist vor allem bei Modellen u¨ blicher Gr o¨ße nur mit sehr viel Aufwand oder gar nicht mo¨ glich. Da unser Prototyp die Analysen in angemessener Zeit ausfu¨ hren kann, stellt er eine große Unterst u¨tzung fu¨ r den Entwicklungsprozess des Variantenmodells dar.
Don Batory. Feature models, grammars, and propositional formulas. In Proceedings of the 9th international conference on Software Product Lines. Springer-Verlag, 2005. Krzysztof Czarnecki und Ulrich Eisenecker. Generative Programming: Methods, Tools, and Applications. Addison-Wesley, Reading, MA, USA, 2000.
Paul C. Clements und Linda Northrop. Software Product Lines: Practices and Patterns. SEI Series in Software Engineering. Addison-Wesley, August 2001. [RKW09] [SLB+11]
M-O Reiser, Ramin Tavakoli Kolagari und Matthias Weber. Compositional variabilityconcepts and patterns. In HICSS’09. 42nd Hawaii International Conference on System Sciences. IEEE, 2009.