Cardinality-Based Feature Models and Model-Driven Engineering
Total Page:16
File Type:pdf, Size:1020Kb
Cardinality-Based Feature Modeling and Model-Driven Engineering: Fitting them Together Abel Gómez1, Isidro Ramos2 Department of Information Systems and Computation Universidad Politécnica de Valencia Valencia, Spain [email protected] [email protected] Abstract—Feature Modeling is a technique which uses a spe- Generative Programming and SPLs facilitate the development cific visual notation to characterize the variability of product lines of software products for different platforms and their use under by means of diagrams. In this sense, the arrival of metamodeling different technologies. frameworks in the Model-Driven Engineering field has provided the necessary background to exploit these diagrams (called In this paper we discuss the main issues that arise when feature models) in complex software development processes. trying to use feature models in a MDE process, and how to However, these frameworks (such as the Eclipse Modeling Frame- easily overcome them. We also present a tool that allows the work) have some limitations when they must deal with software developers of SPLs to define, use and exploit feature models artifacts at several abstraction layers. This paper presents a in a modeling and metamodeling tool. In our case, we have prototype that allows the developers to define cardinality-based feature models with constraints. These models are automatically chosen the Eclipse Modeling Framework (EMF). Moreover, translated to Domain Variability Models (DVM) by means the EMF framework provides several tools which permit us to of model-to-model transformations. Thus, such models can be enrich these models (by means of OCL expressions and OCL instantiated, and each different instantiation is a configuration interpreters) and to deal easily with them (by using model of the feature model. This appproach allows us to take advantage transformations). All these features of EMF allows us to use of existing generative programming tools, query languages and validation formalisms; and, what is more, DVMs can play a key this framework to start a Software Product Line. role in MDE processes as they can be used as inputs in complex The remainder of this paper is structured as follows: in model transformations. sectionII we present the starting point of our work and the Keywords-Software Product Lines; Model Driven Architecture; main problems that arise when trying to use feature models Feature Modeling; UML; OCL in a MDA process; and in sections III andIV we present both the ideal approach and the practical approaches to use I. INTRODUCTION feature modeling in a MDA context. In sectionV we show The key aspect of Software Product Lines (SPL) [6] that our feature metamodel and how we operationalize the solution characterizes this approach against other software reuse tech- presented in sectionIV in our prototype tool. Related works niques is how to describe and manage variability. Although are discussed in sectionVI and in section VII we present our several approaches have addressed this problem, the most of conclusions and future works. them are based on feature modeling, proposed in [12]. In II. FOUNDATIONS this approach, the commonalities and varibilities among the products of a SPL are expressed by means of the so-called A. Cardinality-based feature models at a glance features (user-visible aspect or characteristic of the domain), Cardinality-based feature modeling [8] integrates several of which are hierarchically organized in feature models. the different extensions that have been proposed to the original The use of feature models can be exploited by means of FODA notation [12]. In this sense, a cardinality based feature metamodeling standards. In this context, the Model-Driven model is also a hierarchy of features, but the main difference Architecture [14] proposed by the Object Management Group with the original FODA proposal is that each feature has is a widely used standard which arises as a suitable frame- associated a feature cardinality which specifies how many work. In this sense, the Meta Object Facility (MOF) and the clones of the feature are allowed in a specific configuration. Query/Views/Transformations (QVT) standards allows us to Cloning features is useful in order to define multiple copies define feature models and their instances, and use them in of a part of the system that can be differently configured. a Model-Driven Engineering (MDE) process. In this context, Moreover, features can be organized in feature groups, MDE and the Generative Programming approach [7] provides which also have a group cardinality. This cardinality restricts a suitable basis to support the development of SPLs. Moreover, the minimun and the maximun number of group members that can be selected. Finally, an attribute type can be specified for model level, thus, we can have mutiple copies of the same a given feature. Thus, a primitive value for this feature can be feature. Several specializations can be done at model level defined during configuration. until only one variant is possible. In feature models is also quite common to describe con- straints between features such as the implies and the excludes C. Cardinality-based feature models and MDE main issues relationships, which are the most common used ones. Accord- In previous paragraphs we have described what cardinality ing to the original FODA notation, these constraints can be based feature models are and how they are usually exploited. expressed by means of propositional formulas [2], thus, it is Nevertheless, there are some issues, that we will address in possible to reason about the satisfiability of the feature model. the remaining of this paper, that cause some problems when As explained in [8], this interpretation for feature models is not trying to use feature models in a MDE process. very adequated when dealing with cardinality-based feature The first one comes from the classical definition of config- models due to the fact that we can have multiple copies of the uration of a feature model (the set of features that are selected same feature. Therefore, it is necessary to clearly define the from a feature model). This definition tends to define the semantics of the constraint relationships in the new context, configuration as a copy mechanism instead of as an instan- where features can have multiple copies, and features can tiation mechanism. Although this definition can be somewhat have an attribute type and a value. In this case, we need intuitive when dealing with traditional feature models, it can more expressive approaches to (i) define constraints between be confusing when dealing with cardinality-based ones. In features and (ii) perform formal reasoning over the feature this case, the instantiation concept is best suited when talking models and their constraints. about cardinality-based feature models with attribute types, B. Feature models and their configuration given that the configuration is more easily understandable as an instance-of relationship rather than as a copy-and-refinement- A configuration of a feature model is usually defined as of the set of features that are selected from a feature model relationship. without violating any of the constraints defined in it, but it The second issue that comes up is how to deal with model can also be defined as a valid set of instances of a feature constraints when features can be cloned in our models and model. I.e., the relationship between a feature model and a such features can have an attribute type. In this case, as pointed configuration is comparable to the relationship between a class out in sectionII, we need to use more expressive languages and an object. The first definition, is well-suited when dealing that allows us (i) to deal with sets of features (i.e. n copies of with “traditional” feature models (those that can be defined feature A) and (ii) to deal with typed variables which values by using the original FODA notation). In this case, every can be unbounded in order to easily represent attribute types. instantiation of the elements of the feature model will follow III. PUTTING MODEL-DRIVEN ENGINEERING AND the singleton pattern, that is, every feature can have at most FEATURE MODELING TOGETHER one instance. Fig.1 shows an example of this. In Fig. 1a an example feature model is represented. This The Meta Object Facility standard (MOF, [16]), which pro- feature model represents a system S, with two features A and vides support for meta-modeling, defines a strict classification B. The first one, feature A, is mandatory (it must be included of software artifacts in a four-layer architecture (from M3 to in every possible product of the product line), and the second M0 layer). The meta-metamodel layer (M3) is where the MOF one, feature B, is optional (it can be included in a particular language is found. MOF can be seen as a subset of the UML product or not). Thus, we have two possible configurations for class diagram, and can be used to define metamodels at M2 this feature model, which are represented in figures 1b and 1c. layer. This way, artifacts that reside in layer x, are expressed As can be seen, this process of selection of features (ac- in terms of the constructors defined in layer x + 1. cording to the defined constraints) is closely related with a In turn, the Query/Views/Transformations (QVT, [15]) stan- copy mechanism, that is, a configuration of a feature model dard describes how to provide support to queries and model is a more restrictive copy of the original one that represents transformations in a MDE process. QVT uses the pre-existent exactly one variant. This mechanism can also be used in Object Constraint Language (OCL, [17]) language to perform cardinality-based feature models. In this case, when features queries over software artifacts. The QVT standard provides have an upper bound greater than 1 they can be cloned at three different languages to describe these transformations.