“A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the speciﬁc needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.” http://www.sei.cmu.edu/productlines/
In software areas in which there is a strong separation between high-level requirements and reusable implementation-oriented components, realizing and using a SPL is a cumbersome process. The different variability spaces corresponding to these two development stages must also be linked together so that several different relationships can be handled in the SPL and the full transformation process from requirements to the application source-code can be carried out. Taking Video Surveillance (VS) as its validation use case, we implement an homogeneous approach in which i) both variability spaces are described through feature models, ii) relationships are described as rules to handle links from domain variations to platform variations, iii) consistency checking is automated on feature models and rules and iv) the selection of the suitable implementation modules partially drives generation of source code. The resulting framework enables stakeholders to express different viewpoints while ensuring traceability and consistency.
Our prototype tool implements the operations required in our approach. It is a plugin for the Eclipse Platform, based on FeatureIDE.
NEW The project has evolved and a language dedicated to feature model management now integrates operators to realize the approach. Have a look at FAMILIAR!
The figure is a screenshot of the tool annotated with the stakeholders involved in the process and the numbers representing the order of operations. First, consistency checking (1) is realized on FMs and transformation rules. Then, the VS expert obtains a task FM configuration (2). Once all variability choices are resolved in the task FM, the transformation can be applied (3). The result is a new platform model and the configuration must be completed by the software engineer (4). It is possible that the resulting platform FM is not fully configured and is rather a specialization. In this case, the transformation process ensures by construction that each remaining variability choice in the platform FM will not lead to an inconsistent task FM. In addition, getting no specialized FM or no configuration may also happen after applying transformation rules. Let us take an example.
A set of transformation rules (see transfo.rule) links a domain variability model with a software variability model. The domain variability model is configured by a user (see domain.equation): B, D and E are selected while C and F are deselected. The transformation mechanism applies the rules. As D and E are selected, D implies the selection of M and E implies the selection of N, M and N should be both selected in the software variability model. Unfortunately, M and N are mutually exclusive. As a result, the domain configuration can not lead to a valid software configuration and a message error is displayed.
Finally, note that the tool enables users to activate the transformation process at each configuration step (and not only when a FM is fully configured).
Contact: Mathieu Acher