Feature Model to Product Architectures: Applying MDE to Software Product Lines Pedro O. Rossel, Daniel Perovich, and Mar´ıaCecilia Bastarrica Department of Computer Science, Universidad de Chile {prossel,dperovic,cecilia}@dcc.uchile.cl Abstract. A Software Product Line (SPL) is a portfolio of similar soft- ware products that target a particular domain. SPL methodologies gen- erally use Feature Modeling to express requirements including variabil- ity, and provide a prescribed way to develop particular products from reusable assets. These methodologies do not explicitly preserve design rationale, which is implicitly stated in the SPL architecture. Having a systematic, tool-enabler, scalable and evolvable method for generating family members is desirable. In this paper, we use Feature Configuration Models (FCM) as the DSL for specifying particular product require- ments, and we apply MDE techniques for systematizing the process of product generation. We use model transformations for stating how the Product Architecture is built from the FCM, and for integrating the reusable components. Such transformations share a common but evolv- able set of rules, and conform an explicit representation of the SPL ra- tionale. We apply our approach for developing a Meshing Tool SPL. 1 Introduction Software Product Lines (SPL) is an approach to develop related systems reusing a managed set of core assets sharing functionality and quality attributes [4]. Most SPL development processes identify three stages. In the Domain Engi- neering (DE) stage reusable assets are developed and maintained, and the scope and production plan are defined. In Application Engineering (AE) particular product requirements are gathered, and the product is built by arranging the reusable assets according to the production plan. If some product requirements fall beyond the scope the Management stage determines whether the product will be built or not. The DE stage is formed by three activities: Domain Anal- ysis, Domain Design, and Domain Implementation [18]. The Domain Analysis produces the Domain Model. This model is used during Domain Design as a basis for designing the Product Line Architecture (PLA) and the catalogue of software components that will populate it. In the Domain Implementation, the designed components are built. Both, the Domain Model and the PLA capture commonalities and variabilities of the SPL. The Domain Model gathers all the potentially required features for any particular product in the SPL. The PLA is built in such a way that it articulates all the identified features according to the quality requirements for the whole SPL. Counting on a Domain Model, a PLA and a component catalogue, the AE consists of choosing the desired features, eliminating variabilities from the PLA yielding a product architecture (PA), and selecting the appropriate component implementations. These components are put together according to the PA obtaining the desired product. Traditional approaches to SPLs are well defined. However, the design de- cisions that must be made, such as designing the PLA, require to take into account the whole information the domain analysis may produce. This situation puts stress on the domain analysis activity and the artifacts it produces. Feature models are a widely used approach to domain analysis capturing commonalities and variabilities [6], and there are several methods and notation for generating them [1, 11]. But still having a well documented domain analysis, the architect has a huge responsibility on the success of the SPL: if the PLA he/she designs is not appropriate, all products will be flawed. This makes the PLA design a hard task. What is even worse, the PLA may become inadequate if the SPL scope evolves since the rationale of the PLA design is usually lost in the design pro- cess, and the PLA should be redesigned from scratch [7]. There have been some successful experiences in automating product generation in SPLs [9, 14], most of them targeting specific domains. Automation is thus desirable and also feasible. Tools supporting product generation should be scalable, traceable, and manage consistency and visualization for variability among different artifacts [2]. We define a SPL development process based on the Praise reference pro- cess [18]. We apply MDE [17] techniques to provide a systematization of the DE stage, which enables the automation of the AE stage. To this end, we con- sider features in the Feature Model to represent main functional areas. Archi- tectural decisions are explicitly recorded as model transformation rules attached to each feature. For each component either an implementation or a generator is implemented. Therefore, generating a particular product consists of defining a particular Feature Configuration Model only. The actual Product Architecture is automatically generated by applying the set of rules of the selected features. The actual product is built by using the implementations and generators of those components participating in the product architecture. The rest of the paper is structured as follows. Section 2 presents the defined development process, including first its rationale, and then detailing the activities and artifacts involved in both, the DE and the AE stages. We successfully applied this process by addressing the Meshing Tool domain1, and report a key part of this experience in Section 3. Related work is reviewed in Section 4. Finally, Section 5 concludes with a discussion and suggests further work directions. 2 Model-Driven Development of Software Product Lines In this work, we define a process based on the Praise reference process [18] for SPLs. We only deal with Domain Engineering and Application Engineering, 1 http://mate.dcc.uchile.cl/research/tools/mddofspl/ Domain Domain Domain Domain Domain Domain Analyst Analysis Designer Design Implementer Implementation Feature-to-Architecture Component Component Domain Engineering Engineering DomainDomain Domain Engineering DomainEngineering Domain Feature Model Transformation Rule Generator Implementation [one set of rules per feature] [one per internal- [one per leaf- node feature] node feature] Feature Product Product Configuration FeatureFeature----totototo----ArchitectureArchitecture Product Generator Implementation Transformation Architecture Application Engineering ApplicationEngineering Application Application Engineering ApplicationEngineering Application Product Product Product Product Analyst Analysis Design Implementation Fig. 1. Model-Driven Development Process of Software Product Lines. both organized in terms of three major activities. First, Analysis uses features to explicitly define functionality, and also variability in the case of DE. Second, De- sign is architecture-centric, and tackles critical structural and quality-addressing decisions. Third, Implementation deals with actual component and product de- velopment. Figure 1 illustrates the proposed process. The major goal of our process is automating AE. Particularly, once the func- tionality of the new product is defined in the Feature Configuration Model, the Product Architecture is automatically derived from it, and the product imple- mentation supporting such an architecture can also be automatically generated. To achieve such a goal, we define a systematic process to perform DE and we apply MDE [17] techniques. We conceive all participating artifacts as models, rendering rigorous and unambiguous artifacts amenable to be manipulated by tools. A metamodeling approach is used to define the DSLs needed to express each participating artifact. Altogether, the automation of AE is achieved by means of model transformations that are automatically derived from the models defined in DE, and applied during AE. 2.1 Process Rationale Features represent functionality. We constrain Feature Models only to features representing services, functionalities, parameters or data storages. Quality at- tributes need to be documented in a separated artifact as they are needed for design. However, as proposed in [13], a Feature Model can be refined into one that only refers to functional capabilities identifying quality attributes also as features. Features lead component architecture construction. Domain Design focuses on the construction of the PLA that embodies the critical design decisions that address functionality and quality, and also commonality and variability. In our approach, we organize these decisions in terms of the features in the Feature Model, which in turn, guide the compositional structure of the architectural components. Each feature inspires an architectural component that encapsulates the set of decisions that guides the component internal organization. Decisions are made locally to each particular feature, only considering its direct member features. Quality- related decisions are associated with features near the root of the Feature Model, while functional-specific decisions are associated with features near the leaves. Record the architecting activity, not the architecture. In the traditional approach, the Domain Design develops the PLA, usually yielding complex architecture definitions in non-standard ADLs. During Product Design, all variabilities in the PLA are resolved to obtain a particular Product Architecture (PA). While Product Analysis resolves variability at the feature level, Product Design resolves variability at the architectural level; then, the effort is somehow duplicated. Hav- ing no direct traceability from features to architectural components, and mainly to architectural