Forschungsprojekt feasiPLe

Ausdruck von Variabilität auf Architekturebene

Architekturmodelle beschreiben die Struktur des Lösungsraumes einer Produktlinie. Ein Architekturmodell wird im Kontext der Produktlinieentwicklung unabhängig von einer konkreten Variante erstellt. Abgebildet auf die modellgetriebene Softwareentwicklung wird ein derartiges Modell als VIM (variants-indepent model) bezeichnet. Um variantenunabhängig modellieren zu können, muss es möglich sein, Variabilität innerhalb eines Architekturmodells ausdrücken zu können. Mit Hilfe der Konfiguration einer konrekten Produktvariante einer Produktfamilie ist es möglich, ein entsprechendes variantenspezifisches Modell (VSM) der Produktlinienarchitektur abzuleiten.

Mechanismus für die variantenunabhängige Modellierung

Für das Ausdrücken von Variabilität auf Architekturebene wurde eine spezielle Schnittstelle ausgearbeitet, die innerhalb eines Architekturmodells zum Einsatz kommt. Diese Schnittstelle wird als XVI (Explicit Variability Interface) bezeichnet und ist auf verschiedene Arten von Architekturen adaptierbar. Der Ansatz basiert auf einer Erweiterung des zugrundeliegenden Metamodells der Architektur. Dabei werden an bestimmten Elementen der Architektur sogenannte Variationspunkte (variation points) installiert, an denen die Produktlinienarchitektur variables Verhalten aufweisen soll. Bei der späteren Transformation von VIM zu VSM werden die Variationspunkte entsprechend der gewünschten Variante der Architektur aktiviert oder deaktiviert.

Grundsätzlich wird zwischen zwei Arten von Variationspunkten unterschieden: Deklarative und referenzierende Variationspunkte. Deklarative Variationspunkte definieren einen Punkt in der Architektur, an dessen Stelle das Verhalten der Architektur anpassbar sein soll. Referenzierende Variationspunkte werden genutzt, um auf deklarative Variationspunkte zu verweisen. Bei dem Einsatz von referenzierenden Variationspunkten entstehen Variationspunktverbunde, um verschiedene Modellelemente an einen deklarativen Variationspunkt zu koppeln. Wird bei der Bildung einer konkreten Variante der Architektur ein deklarativer Variationspunkt aktiviert oder deaktiviert, werden auch alle dessen referenzierenden Variationspunkte entsprechend aktiviert oder deaktiviert. Aufgrund des Referenzmechanismus werden bei Deaktivierung eines einzigen deklarativen Variationspunktes alle seine betreffende Modellelemente bei der Transformation in eine Architekturvariante automatisch entfernt.

Für den Fall, dass die Architektur durch ein UML-Diagramm beschrieben ist, erfolgt die XVI-Erweiterung mit Hilfe eines entsprechenden UML-Profils. Dieses UML-Profil besteht aus einem Stereotyp <<VariationPoint>>, der auf sämtliche Elemente, wie beispielsweise Pakete, Klassen, Operationen oder Assoziationen, der UML applizierbar ist. Wie im unteren Bild dargestellt, besitzt der Stereotyp ein Attribut "ref", mit dessen Hilfe eine Referenzbeziehung zu einem anderen Variationspunkt aufgebaut wird.

Stereotyp <<VariationPoint>>

Beispiel: Persistenzmanagement

Zur Veranschaulichung der Verwendung von expliziten Variabilitätsschnittstellen soll ein Beispiel zur Persistierung von Objekten dienen. Der nachfolgende Ausschnitt eines UML-Diagramms zeigt eine solche Persistenzkomponente, deren Elemente teilweise als Variationspunkt definiert wurden.

Verwendung der Variationspunkte in der Persistenz-Komponente

In dem dargestellten Beispiel werden exakt zwei Variationspunkte deklariert:

• Variationspunkt "PersistenceStrategy": Dient zur Aktivierung/Deaktivierung von Objektpersistierung.
• Variationspunkt "PersistenceStrategy.delete(Object)": Dient zur Aktivierung/Deaktivierung des Löschens persistierter Objekte.

Beide deklative Variationspunkte werden von weiteren Variationspunkten innerhalb der Komponente referenziert. So referenzieren beispielsweise die Operationen DBPersistence.delete(Object) und XMLPersistence.delete(Object) auf den Variationspunkt PersistenceStrategy.delete(Object). Soll aus der vorliegenden variantenunabhängigen Architektur eine konkrete Variante gebildet werden, die das Löschen persistierter Objekte in einem Softwaresystem nicht unterstützt, wird der deklarative Variationspunkt PersistenceStrategy.delete(Object) deaktiviert und damit die entsprechende Delete-Operation der Schnittstelle PersistenceStrategy entfernt. Entsprechend der Variationspunktreferenzen werden dann automatisch auch die Delete-Operationen in den Klassen DBPersistence und XMLPersistence entfernt. Auf diese Weise beeinflusst ein deklarativer Variationspunkt drei (beliebige) Modellelemente innerhalb der Architektur.

Bei einem entsprechend umfangreichen Architekturmodell liegt es nahe, dass sich ein deklarativer Variationspunkt auf eine Vielzahl von Modellelementen bezieht. Soll später das variantenunabhängige Architekturmodell auf ein Feature-Modell eines Problemraums gemappt werden, ist es ausreichend, die deklarativen Variationspunkte der Architektur mit den Features der Produktfamilie zu verbinden. Dabei entsteht der Vorteil, dass auf architekturinterne Abhängigenkeiten zwischen aktivierten oder deaktivierten Modellelementen nicht geachtet werden muss, da diese bereits durch die Variationspunktreferenzen korrekt aufgelöst werden.

Zurück zur feasiPLe Architektur