Forschungsprojekt feasiPLe

Expressing variability within architecture models

The structure of the solution space of a product line is described by appropriate architecture models. In the context of product-line development an architecture model is independent of a concrete variant. In the meaning of model-driven software development the model is called variants-independent model (VIM). To create variants-independent models it must be possible to express variability within an architecture model. With the usage of a concrete variant of a product-line, an appropriate variant-specific model (VSM) of the product-line architecture could be derived.

Mechanism of variants-independent modelling

To express variability at level of architecture, a special interface was elaborated, which is used within an architecture model. This interface is called XVI (explicit variability interface) and is adaptable to several kinds of architectures. The approach based on the extension of the underlying metamodel of the architecture. Therefore certain model elements of the architecture model will be tagged as variation point, where the product-line architecture offers variable behavior. In relation to the choosed variant of the architecture, the defined variation points will be activated or deactivated within the transformation from VIM to VSM.

Generally two kinds of variation points were distinguished: declarative and referencing variation points. Declarative variation points specify locations (model elements) within the architecture model, where the behaviour of the application should be adjustable. Referencing variation points were used to reference declarative variation points to create compounds of variation points. A variation point is coupled to a concrete model element of the architecture model. If a declarative variation point is deactivated during building a variant, all of its referencing variation points would be deactivated as well. Hence, all related model elements covered by this variation point compound, will be removed from the final variant-specific model.

If the architecture is modelled by the usage of a UML diagram, the enhancement for the XVI mechanism is done by an appropriate UML profile. This profile consists of a stereotype <<VariationPoint>>, which is applicable of any UML element, such as packages, classifiers, operations or associations. As shown in the image below, the stereotype has an attribute "ref", which is used to create the references to other (declarative) variation points. Hilfe eine Referenzbeziehung zu einem anderen Variationspunkt aufgebaut wird.

Stereotype <<VariationPoint>>

Example: persistence management

An example of object persistence within a software system is used to visualize the usage of explicit variability interfaces. The following extract of a UML diagram of the peristence component shows that several model elements were defined as variation point.

Usage of variation points within the persistence component

Within the component there exist exactly two declarative variation points:

• Variation point "PersistenceStrategy" to enable or disable object persistence for software systems.
• Variation point "PersistenceStrategy.delete(Object)" to enable or disable the removability of already persisted objects.

Both declarative variation points were referenced by several elements within the component. For example the operation DBPersistence.delete(Object) and XMLPersistence.delete(Object) reference the variation point PersistenceStrategy.delete(Object). To create a variant without support for removing persisted objects, the variation point PersistenceStrategy.delete(Object) must be deactivated, which removes the related delete-operation of the interface Persistence. In accordance to the referencing variation points, the delete-operations of the classes DBPersistence and XMLPersistence will be removed as well automatically. Hence, one declarative variation point covers three (arbitary) model elements of the architecture.

Within a more comprehensive architecture model, one declarative variation point obtains a bigger set of related model elements. If the architecture is mapped to a feature model of a problem space, it is enough to connect the features of the product family to the declarative variation points of the VIM. As a benifit of that, the inner-architectural dependencies between active and inactive model elements must not be observed, because they were resolved correclty by the referencing variation points.

Back to the feasiPLe Architecture