Configuration is a common way in many markets to cope with reducing costs and improving customer satisfaction. There are various approaches to represent product configurations, the most common of which is feature modeling. However, feature models suffer from principal limitations, including ambiguity and lack of abstraction, increasing maintainability effort and limiting lifecycle support. In this paper, we suggest using a multi-level modeling approach to improve flexibility, reuse, and integrity and demonstrate the advantages of the approach over feature modeling.
The variety and complexity of systems have dramatically increased in the last two
decades. These introduce challenges to the development of software that the
wellknown modeling paradigms could not handle without modifications and adaptations.
Software Product Line Engineering (SPLE) [
Current approaches to SPLE adopt a two-layered framework [16]: domain
engineering containing the specification and implementation of product line artifacts
(potential configurations) and application engineering consisting the specification and
implementation of specific product artifacts (valid configurations). The rigid division
into these two levels imposes limitations on the ability to abstract concepts that are
used across these levels and to define the semantics of the various models which may
be expressed in different languages. Moreover, checking models for consistency and
correctness is challenging in the general context of SPLE and particularly with respect
to variability management. Scalability and visualization/graphical overload are
mentioned among the most prominent challenges [
To address the above challenges, we propose to adopt a Multi-Level Modeling
(MLM) approach. Generally, MLM [
In [18], we have explored MLM in the context of SPLE variability mechanisms –
techniques applied in order to adapt software product line artifacts to the context of
particular products. Here, we aim to analyze prospects of applying MLM to SPLE in
the context of variability management. Particularly, we demonstrate the limitations of
feature modeling [
The rest of the paper is structured as follows. Section 2 reviews current approaches to variability modeling, focusing on feature modeling and exemplifying its limitations. Section 3 introduces the MLM approach and demonstrates its potential to model configurations and to address feature modeling drawbacks. Finally, Section 4 discusses future research directions. 2
Variability management has gained interest in the past decade [
While feature modeling may serve as a versatile tool for representing variability in requirements, they are limited in specifying and designing software product lines. In order to demonstrate the limitations, we use the feature model depicted in Fig. 1. The model specifies a family of software systems for bicycle dealerships. Each system needs to represent and manage domain objects – bicycles, which exist in a remarkable variety. Some dealers need to cover the full range in great detail (including the actual distinction between racing bikes and pro-racers). Others are more satisfied with a more generic concept of bicycle, which is characterized by its weight, its parts (fork, frame, two wheels), and so on.
Analyzing the bicycles model, we observe the following limitations.
Ambiguity: Apparently, a feature may represent a class (e.g., frame or fork), an attribute (e.g., size or weight), a possible attribute value (e.g., alum or carbon), or even the result of an operation (e.g., the weight of a bicycle is the sum of its constituents’ weights). In an early stage of requirements analysis, it can be a good idea to use such an abstraction. However, the closer one gets to the design phase, the more problematic this abstraction may be: the concept of a feature does not allow for a clear correspondence to software design concepts such as class, attribute, etc. Therefore, feature models do not allow for a straightforward transformation to design documents such as object models, and the synchronization of design documents and feature models is a remarkable challenge that requires introduction of additional languages and tracing capabilities, such as in orthogonal variability modeling [16].
Lack of abstraction: The lack of classification will not only prevent modellers from expressing knowledge they have, it also creates a threat to maintainability and integrity. Since it is not possible to define classes that are characterized by a certain feature configuration, it is not possible to define constraints that apply to these classes. Defining corresponding constraints directly on features is not only cumbersome, it may in the end even be a wasted exercise, because it can create additional complexity that compromises a model's readability. Since feature models lack the concept of class, they do not support a well-founded concept of generalization/specialization either. Therefore, redundancy will often be unavoidable, which jeopardizes a model's integrity.
To demonstrate this limitation, consider the need to specify classes of racing bikes and pro-racers. Both are specializations of bicycles, whereas pro-racers are special racing bikes. The following constraints can be introduced for constraining valid configurations of those classes of bicycles: 1. 2.
Racing => ¬Suspension ∧ ¬SaftyRelf ∧ ¬AllTerrain ∧ ¬AllTerrain1 ∧ Race ∧ Race1 ∧ City
ProRacer => Racing ∧ ¬MudMount ∧ Tubless ∧ UClcretified ∧ Carbon1
This specification hinders the hierarchy of the three domains (regular bicycles, racing bikes, and pro racers). It makes the models less understandable for the modellers, especially when analyzing the consequences of feature modification, as all features appear in the same (domain engineering) level without separation into the different bicycles classes.
Another example of the lack of abstraction refers to the need to specify that the
size of the front wheel equals to the size of the back wheel, but its weight is lighter.
Here, we need the distinction between classes, attributes, and attribute values. The
expressiveness of feature models is insufficient, and hence we have to use extensions
that support specification of feature cardinalities and attributes, e.g., the extension
proposed in [
Wheel[
Wheel[
This specification is complicated and its maintainability and comprehensibility are further questioned. Hence, in the following we propose a multi-level modelling language for supporting variability modeling in software product lines without forcing overload of concepts. 3
To develop a convincing rationale for this proposal we first give a brief overview of core concepts of MLM. Then, we outline why the additional abstraction enabled by MLM is promising for designing and managing product lines. Finally, we illustrate the potential of MLM for overcoming the aforementioned limitations using the bicycles example. 3.1
• • •
In the traditional paradigm, all entity types or classes of a model are located on the same level of classification, which is usually M1. Therefore, it is not possible to express knowledge about classes of classes. Furthermore, classes cannot be modelled as objects that have a state and can execute operations. This lack of abstraction is sometimes handled by overloading one level of classification. However, the ambiguity caused by overloading creates a serious threat to integrity. A further option would be to extensionally model all cases that were otherwise covered by a metaclass. Unfortunately, that may tremendously increase a model’s complexity and, therefore, jeopardize its integrity and maintainability.
Multi-level modelling [
Unlimited number of classification levels: A class can be defined on any classification level.
Classes as objects: Every class is an object at the same time, that is, it may have a state and may execute operations.
Deferred instantiation: Classes may define properties that apply not only to their direct instances, but to instances of instances of instances etc. Therefore, it is possible to specify that a property is to be instantiated only on a lower level. Classes on different classification levels may co-exist in one model: In the traditional paradigm, there is a strict distinction between model and modelling language. A multi-level model may include objects on different classification levels, which may located on M0 or M1 or may be part of languages or meta-languages. 3.2
Modelling product lines is aimed at a clear definition of all relevant kinds of variability. To foster modelling productivity, a language for modelling product lines should promote reuse, which recommends powerful abstractions. Furthermore, such a language should support the maintenance of product lines, which recommends powerful abstractions, too. In ideal case, the concepts provided with the language should be suited for the entire software lifecycle, at least on different levels of precision and detail.
Classification is a powerful concept to express variability. A class defines the properties that are shared by all its instances. The property types define the extension of the set of instances. From another point of view a class can be regarded as a set of constraints that need to be satisfied by its instances. The more restrictive the properties, or more general: the constraints are, the better is the chance to clearly discriminate valid against invalid variants. Nevertheless, the variation that can be defined through classification is limited to the variation of instances of the class. Possible variations of the class (and of other similar classes) cannot be accounted for. This is different with MLM. Metaclasses can be used to define variations of classes. In addition, they may serve to account for possible, future variability that is not known yet. For example, we know that types of bicycle frames are made of aluminum, carbon, and so on. Therefore, these materials can be used in a metaclass to define a range of possible variants. At the same time, we know that there may be other materials in the future, which can be accounted for by extending the set of materials at a later time. Hence, extending metaclasses on any level improves the chance to modify a product line in an elegant and convenient way. 3.3
The diagram in Fig. 2 illustrates how variability can be represented in a multi-level
model. In the example, we use the FMMLx [
The upper levels of Fig. 2 can be considered as models of products and corresponding software systems at different levels of abstraction. Software vendors will benefit from introducing (domain-specific) concepts in various levels and receiving those concepts all the way down the hierarchy of products. Moreover, the transition among levels is smooth: each level reduces the number of valid configurations of its upper level by introducing constraints or assigning values to attributes. The transition from M4 to M3, for example, is done by specifying that a racing bike, as well as its frame, is not suited for tough terrains but suited for races, a racing bike is suited for cities, a racing fork does not have a suspension, and so on. Note that the constraint marked as c1 in the figure could be specified in feature modeling, yet its specification would require complicated dependencies between features in the single level model.
The models in the MLM approach can be easily mapped into code as they already specify the type of the various elements. For example, a wheel, a frame, and a fork are classes, while size and weight are attributes. The three classes of bicycles, regular, racing, and pro-racers, are clearly shown in different abstraction levels of the MLM approach, M2, M3 and M4 in the figure, allowing their separation for different types of bicycle dealers, e.g., those who require differentiation between racing bikes and pro-racers (level M2) and those who do not require this (level M3). 2,2 1,* 0 ofInstance 1 ofType 0 ofInstance 1 ofType 0 0 0,1 1 1,* 0,1 1 1,*
Bicycle allTerrain: Boolean race: Boolean city: Boolean 1 weight: Float 1 salesPrice: Float 0 partSalesPrice: Float 2 highestPrice() : Float 1 getFrontWheel() : Wheel 1 getBackWheel() : Wheel 2 averagePrice() ^Bicycle^
RacingBike
UCIcertified: Boolean
1 weight: Float
1 salesPrice: Float
0 partSalesPrice: Float
2 highestPrice() : Float
1 getFrontWheel() : Wheel
1 getBackWheel() : Wheel
2 averagePrice() : Float
allTerrain = false
race = true
city = true
(1) Bicycle.instances[
Wheel.instances<3>(w1,w2)
b.getFrontWheel() = w1 and b.getBackWheel()
= w2 and w1 <> w2)
(2) Bicycle.instances[
Metaclass Intristic attribute/operation/association, instantiated in objects on level M0/M1/M2 Object state Object returned by an operation
Frame 0 0,1 1 1,* over feature modeling which include better abstraction and expressiveness, unambiguity, and integrity. Those properties ease the reuse and maintenance of models and allows for easy transformation into later stages of design and implementation.
To take full advantage of the potential of the MLM approach, we plan to devise a multi-level constraint language which allows defining constraints that span over multiple levels of classification. In addition, we plan to develop a comprehensive method to guide the construction of multilevel DSMLs. While a method for developing DSMLs within the MOF paradigm provides useful support, it does not help with decisions concerning the appropriate number of levels or the separation of levels. We further intend to evaluate the usefulness of the approach for performing different SPLE activities, including constraining valid software configurations and deriving specific configurations to certain requirements. 15. Kang, K. C., Cohen, S. G., Hess, J. A., Novak, W. E., & Peterson, A. S. (1990). Featureoriented domain analysis (FODA) feasibility study (No. CMU/SEI-90-TR-21). CarnegieMellon Univ Pittsburgh Pa Software Engineering Inst. 16. Pohl, K., Böckle, G., van der Linden, F. (2005) Software Product-line Engineering: Foundations, Principles, and Techniques, Springer. 17. Prehofer, C. (1997). Feature-oriented programming: A fresh look at objects. ECOOP'97—
Object-Oriented Programming, 419-443. 18. Reinhartz-Berger, I., Sturm, A., & Clark, T. (2015). Exploring Multi-Level Modeling Relations Using Variability Mechanisms. In MULTI@ MoDELS, pp. 23-32. 19. Van Gurp, J., Bosch, J. & Svahnberg, M. (2001). On the notion of variability in software product lines. In proceedings of the Working IEEE/IFIP Conference on Software Architecture, pp. 45-54.