A Model-Based Framework for Automated Product Derivation∗ Ina Schaefer, Alexander Worret, Arnd Poetzsch-Heffter Software Technology Group TU Kaiserslautern Kaiserslautern, Germany {inschaef | worret | poetzsch}@cs.uni-kl.de Abstract—Software product line engineering aims at devel- is restricted to configurative variability [4]. The different oping a set of systems with well-defined commonalities and product configurations are captured in a feature model where variabilities by managed reuse. This requires high up-front features are designated product characteristics. Automated investment for creating reusable artifacts, which should be balanced by cost reductions for building individual products. product derivation means that a product implementation for We present a model-based framework for automated product a particular feature configuration is automatically generated derivation to facilitate the automatic generation of products. from the reusable product line artifacts. Software product In this framework, a model-based design layer bridges the line engineering processes, such as PuLSE [5] or KobrA [6], gap between feature models and implementation artifacts. focus on managing product line variability in all software The design layer captures product line variability by a core design and ∆-designs specifying modifications to the core for development phases, but leave product derivation as a man- representing product features. This structure is mapped to ual activity. In [7], only organizational and technical re- the implementation layer guiding the development of code quirements for automated product derivation are considered. artifacts capable of automatic product derivation. We evaluate Some approaches [8], [9] aim at automatically deriving the framework for a CoBox-based product line implementation design documents. However, no approach provides guidance using extended UML class diagrams for the design and frame technology for the implementation layer. for the design and implementation of product line artifacts capable of automated product derivation. Keywords-Software Product Lines; Automated Product To overcome this problem, we propose a model-based Derivation; Model-based Development; Frame Technology framework for automated product derivation. A design layer bridges the gap between feature models and product imple- I. I NTRODUCTION mentations. During domain engineering, it guides the de- A software product line is a set of software systems with velopment of implementation artifacts capable of automated well-defined commonalities and variabilities [1]. Software product derivation. On the design layer, a product line is product line engineering aims at developing these systems described by a core design and a set of ∆-designs. The by managed reuse in order to reduce time to market and to core design represents a product with a basic set of features. increase product quality. The creation of reusable artifacts The ∆-designs define modifications to the core design that requires a high up-front investment which should be bal- are necessary to incorporate specific product characteristics. anced by cost reductions for building individual products. ∆-designs can cover combinations of features. This makes Currently, derivation of single products requires manual the presented approach very flexible because modifications intervention during application engineering, especially for caused by several features can be designed differently from product implementation, which can be tedious and error- modifications caused by one of these features. In order to prone [2]. Hence, it cannot be guaranteed that the overall obtain a design for a product with a particular feature con- development costs are reduced by product line engineering figuration during application engineering, the modifications when compared to other reuse approaches. specified by the respective ∆-designs are applied to the Automated product derivation (or software mass cus- core. A design can be validated and verified before code tomization [3]) is an approach to create single products by artifacts are developed. Furthermore, designs can be refined removing the need for manual intervention during appli- based on the principles of model-driven development [10]. cation engineering. Besides, automated product derivation Refinements are orthogonal to product line variability be- allows centralized product line maintenance and product cause they can be performed in both core and ∆-designs line evolution, because modifications of the artifacts can equally. Therefore, the proposed approach serves as a basis automatically be propagated to the products. In order to be for model-driven development of software product lines with able to create products automatically, product line variability automated product derivation. ∗ This work has been partially supported by the Rheinland-Pfalz Research In order to develop reusable code artifacts capable of Center for Mathematical and Computational Modelling (CM )2 and by the automated product derivation, the structure of the design European project HATS, funded in the Seventh Framework Program. layer is mapped to the implementation layer. A product line implementation consists of a core implementation of on modeling product line variability. In KobrA [6], UML the product described by the core design and a set of diagrams are annotated with variant stereotypes to describe ∆-implementations corresponding to the ∆-designs which variation points in models. In [13], a UML profile for specify the modifications to the core implementation to re- representing product line variability is introduced. However, alize the designated product characteristics. The core design resolving the modeled variabilities requires additional doc- and core implementation refer to a complete product and can uments and manual intervention. be developed by single application engineering techniques. In [14], [15], the general idea to use model-driven de- The implementation of a product for a particular feature velopment for product derivation is advocated. Models in configuration is obtained automatically during application the problem domain, which correspond to feature models engineering by applying the modifications of the respective of product lines, are stepwise transformed to models in a ∆-implementations to the core implementation. The design solution domain, i.e. models of products or product im- layer is independent of a specific implementation technique. plementations. However, these approaches rely on manual The only requirement for a concrete implementation tech- intervention for configuring and performing model trans- nique is that the modifications of the core can be represented formations. [4] proposes the integration of model-driven appropriately and applied automatically. The separation development and aspect-oriented concepts. The introduced of design and implementation artifacts into core and ∆- notion of positive variability refers to a core model to designs/implementations allows a stepwise development of which selectively certain parts are added. The difference of the software product line. The approach can easily deal with this notion to ∆-designs/implementations is that the latter evolving software product lines by capturing new features can also contain modifications and removals of design and in additional ∆-designs/implementations. implementation artifacts. Model transformations in [4] are We have evaluated the proposed model-based framework realized by aspect-oriented composition of artifacts which at the development of a shopping system product line. In also extends to the implementation by means of aspect- order to consider variable deployments, the implementation oriented programming concepts. However, the manual im- layer is based on the CoBox component model [11]. We de- plementation of certain product parts is explicitly included veloped a notation for CoBox-based core and ∆-designs. For in the approach which is not considered in our framework implementing the product line variability, we applied frame for automated product derivation. technology [12]. The core implementation is captured by Most approaches for automated product derivation con- core frames and the ∆-implementations by sets of ∆-frames sider only the design layer or the implementation layer. For specifying the modifications to the core implementation. automated derivation of product designs, [8] proposes an The main advantages of the model-based framework for approach to automatically generate UML class and activity automated product derivation are: diagrams via annotations from variability models of the • The separation of core and ∆-designs/implementations complete product line. In [9], product architectures are allows an evolutionary development of product lines. automatically derived from a common domain architecture • Product variability can be handled very flexibly because model by means of model transformations. [16] considers an ∆-designs/implementations allow representing modifi- automated derivation of UML class diagrams by resolving cations caused by combinations of features. explicitly specified feature-class dependencies. • The design layer facilitates model-based validation and There are different technologies for automated code gen- verification before implementation. eration applied in the context of software product lines, • The framework can be used with different implemen- such as conditional compilation, frame technology [12], tation techniques to exploit their strengths in particular [17], generative programming [18] or code annotations [19]. application domains. Also, compositional approaches, such as aspect-oriented • The framework serves a basis for model-driven de- programming [20], feature-oriented programming [21] or velopment of software product lines with automated mixins [22], are used to automatically generate product product derivation because refinements are orthogonal implementations from reusable artifacts. However, in order to product line variability. to generate products, it is assumed that the necessary code This paper is organized as follows: In Section II, we artifacts already exist. A systematic process how to design review related work. In Section III, we present our model- these artifacts is not provided. based framework for automated product derivation that is The model-based framework for automated product realized in Section IV and evaluated in Section V. Section derivation presented in [23] is structurally similar to the VI concludes the paper with an outlook to future work. framework proposed in this paper. It contains a modeling layer describing the relation between product features and II. R ELATED WORK implementation artifacts. Because the implementation is Model-driven development [10] is increasingly used in based on aspect-oriented programming, the models define software product line engineering. Many approaches focus how classes and aspects are composed for feature con- figurations. Product derivation is fully automated, but in contrast to the work presented in this paper, the approach is conceptually restricted to aspect-oriented techniques. This limits the means for dealing with product variability to the expressiveness of aspect-oriented concepts that can, for instance, not deal appropriately with features removing code. III. M ODEL -BASED AUTOMATED P RODUCT D ERIVATION In order to provide a standardized technique how to design and implement product line artifacts suitable for automated product derivation, we propose a model-based framework. This approach is based on a model-based design layer that links product line variability declared in a feature model with the underlying implementation layer. Figure 1. Model-based Automated Product Derivation Overview. The proposed approach is structured into three layers (see Figure 1). During domain engineering, the variability of the software product line is captured by a feature model on the feature layer. Based on the modifications to the core design in order to represent specific feature model, reusable design and code artifacts are product characteristics. The step from the feature model to developed representing the product line variability on the the design artifacts is a creative process because product line underlying design and implementation layers. The design variability can be represented in different ways in a design. and the implementation artifacts are separated into a core In order to find a core design for a product line, a suitable design/implementation and ∆-designs/implementations, basic feature configuration has to be identified. Mandatory respectively, that can be configured automatically for a features are always contained in the basic configuration, specific feature configuration during application engineering. as they have to be present in all valid configurations. For The design concepts can be chosen such that relevant optional features, the guideline adopted is that ∆-designs system aspects in each design stage can be adequately should add rather than remove functionality. If an optional expressed. The design layer is independent of a concrete feature only adds entities to the design, the feature should not implementation technique, but provides the structure of the be a part of the basic configuration. However, if an optional implementation artifacts. Designs can be refined based on feature is included in many products, adding it to the core the principles of model-driven development [10], until they configuration can be beneficial because it can be tested are detailed enough for implementation. A product line thoroughly without considering product line variability. If design can be validated and verified before the development selecting an optional feature causes that functionality is of code artifacts such that errors can be corrected less costly. excluded from products, this feature should be contained in the core configuration to keep the core as small as Feature Layer. The products of a software product line possible. Alternative features represent options where at are described by a feature model. Features can represent least one or exactly one feature has to be included in a functional behavior of products, but can also refer to non- valid configuration. Since the core configuration has to be functional aspects, such as deployment issues. A feature valid, a choice between these options is necessary. If a model declares the configurative variability of the product feature selection requires to pick at least one feature, for line, i.e., the commonalities of all products are captured the core exactly one feature should be chosen. The decision by mandatory features, possible variabilities are modeled which option to include in the core can be based on an by optional features, and constraints between features are estimation which feature is most likely contained in many defined. The set of possible products of a product line is configurations. described by the set of valid feature configurations. ∆-designs define modifications of the core design to incorporate specific product characteristics. The modifica- Design Layer. The design of a product line is split into tions caused by ∆-designs comprise additions of design a core design and a set of ∆-designs that are developed entities, removals of design entities and modifications of the during domain engineering. The core design corresponds to existing design entities. The ∆-designs contain application a product of the product line with a basic set of features. conditions determining under which feature configurations This core can be developed according to well-established the specified modifications have to be carried out. These single application design principles. The variability of the application conditions are Boolean constraints over the fea- product line is handled by ∆-designs. The ∆-designs declare tures contained in the feature model and build the connection between features in the feature model and the design level. reusable artifacts during domain engineering that suitable for A ∆-design does not necessarily refer to exactly one feature, automated product derivation during application engineer- but potentially to a combination of features. For example, ing. The design layer provides the structure for the corre- if the feature model contains two features A and B, the sponding code artifacts. Because core design and core imple- constraint (A ∧ ¬B) attached to a ∆-design denotes that the mentation are complete products, they can be developed by modifications are only carried out for a feature configuration well-established principles from single application engineer- if feature A is selected and feature B is not selected. ing. The independence of ∆-designs and ∆-implementations The general application constraints allow very flexible from core designs and core implementations, respectively, ∆-designs as combinations of features can be handled yields the potential of incremental, evolutionary product individually. The number of ∆-designs that are created for line development. Refinement of designs along the lines of a feature model depends on the desired granularity of the model-driven development can easily be incorporated into application conditions. The application conditions of all the proposed framework, because refinement is orthogonal to ∆-designs can be checked if all features are addressed in at the concepts for capturing product line variability. Since the least one design. In order to obtain a design for a particular design layer is independent of the implementation layer, the product during application engineering, all ∆-designs proposed model-based framework can be used with different whose constraints are valid under the respective feature concrete implementation techniques, as long as the concrete configuration are applied to the core. This can involve implementation technique allows expressing the desired different ∆-designs that are applicable for the same feature modifications and supports automatic code generation. in isolation as well as in combinations with other features. To avoid conflicts between modifications targeting the same IV. A F RAMEWORK FOR M ODEL - BASED AUTOMATED design entities, first all additions, then all modifications and P RODUCT D ERIVATION finally all removals are performed. In order to evaluate the proposed approach, we realized the model-based framework for automated product deriva- Implementation Layer. In order facilitate automated tion for developing an information system product line. product derivation, the structure of the design is mapped As application domain for the product line, we use the to the structure of the implementation artifacts that are Common Component Modeling Example (CoCoME) [24] developed during domain engineering. The implementation that describes a software system for cash desks dealing with artifacts are separated into a core implementation and ∆- payment transactions in supermarkets. Information systems implementations. The core design is implemented by the involving clients-server communications are generally dis- core implementation. As the core design is a complete prod- tributed and highly concurrent. To deal with this inherent uct, single application engineering methods can be applied complexity, we implement our system in the object-oriented, for implementing the core. This implementation can also be data-centric CoBox component and concurrency model [11]. validated and verified thoroughly by well-established prin- A CoBox is a runtime component consisting of a (non- ciples. ∆-designs are implemented by ∆-implementations empty) set of runtime objects, i.e., other CoBoxes or in- which have the same structure as the ∆-designs. The addi- stances of ordinary classes. Each CoBox at runtime executes tions, modifications and removals of code specified in ∆- a set of tasks, of which at most one can be active at any implementations capture the corresponding additions, mod- time. A task is active as long as it has not finished or ifications, removals declared in the ∆-designs. The applica- willingly suspends its execution. Thus, inside a CoBox all tion condition attached to a ∆-implementation determines code is executed sequentially. A CoBox communicates with under which feature configurations the code modifications other CoBoxes outside of its own CoBox via asynchronous are to be carried out. The conditions directly refer to the messages. CoBoxes allow flexible deployment because the application condition of the implemented ∆-designs. The location where a CoBox is instantiated does not influence its process to obtain a product implementation for a specific functional behavior. This allows considering also variability feature configuration during application engineering is the of deployment besides variability of functionality in the same as for the design. The modifications specified by all product line to be developed ∆-implementations with a valid application conditions under a specific feature configuration are applied to the core. A. Feature Layer Again, first all additions, then all modifications and finally For representing product line variability on the feature all removals of code are carried out. This analogous priority layer, we use feature diagrams [25]. In a feature diagram, rule ensures that a product implementation generated for a the set of possible product configurations is determined by specific feature configuration is an implementation of the a hierarchical feature structure. A feature can either be corresponding product design. mandatory, if it is connected to its parent feature with a The close correspondence between design layer and im- filled circle, or optional, if it is connected with an empty plementation layer provides a general approach to create circle. Additionally, a set of features can form an alternative Figure 2. Feature Model for the CoCoME Software Product Line selection in which at least one (filled triangle) or exactly one (empty triangle) feature has to be included in a valid configuration. Furthermore, constraints between features can be represented by explicit links. To use CoCoME [24] as an example for a product line, we extended the application scenario with functional and deployment variabilities keeping the original system as one possible configuration. The feature model for the CoCoME software product line is shown in Figure 2. A CoCoME system has different payment options. First, it is possible to pay by cash or by one of the non-cash payment options, i.e., credit card, prepaid card or electronic cash. At least one Figure 3. Core Design for the CoCoME Software Product Line payment option has to be chosen for a valid configuration. Product information can be input using a keyboard or a scanner where at least one option has to be selected. Further- is provided by determining on which deployment targets more, the system has optional support to weigh goods, either CoBoxes should be instantiated. This is expressed by a at the cash desks themselves or at separate facilities. With doubled-headed arrow from a deployment target to a CoBox. respect to deployment, there is the alternative option to have The design layer handles the variability of the feature a single-desk system with only one cashier or a multi-desk model by a core design and a set of ∆-designs. The core system with a set of cashiers. The multi-desk system can design of a CoBox-based product line is denoted by a CoBox optionally comprise an express mode which requires cash design. ∆-designs require additional notation to specify the payment or a self-service mode requiring non-cash payment. modifications to the core design. In a ∆-design, it is defined which CoBoxes or classes are added or removed and which B. Design Layer member variables or methods in existing CoBoxes or classes Since we aim at a CoBox-based design and implemen- are added, removed or modified. The + symbol marks tation of the product line, the design layer has to capture additions, − marks removals and ∗ denotes modifications. all relevant aspects for specifying CoBoxes. This includes As UML class diagrams already use the + and − symbols the CoBoxes that classes belong to as well as deployment for public and private members, we attach the alteration information for the CoBoxes. We introduce an extension to symbols to the right top corner of an altered CoBox, of UML class diagrams [26] to express the additional informa- an altered class or of an rectangle surrounding the altered tion. Usually, UML diagrams are extended by stereotype class members. Additionally, each ∆-design contains its ap- annotations. This, however, would drastically impair the plication condition, a Boolean constraint over the features in readability of the diagrams. With the extended notation, a the feature model, to determine for which configurations the CoBox design consists of a set of CoBoxes and ordinary ∆-design is applied to the core. The application condition classes. Graphically, CoBoxes are represented by a rounded is displayed in an angular box at the top of the design. box named the same as the owning CoBox class. Ordinary The core configuration of the CoCoME software product classes are denoted as usual UML classes. Both, CoBox line includes cash payment, keyboard input, and is a multi- classes and ordinary classes have member variables and desk system because cash payment and keyboard input are methods. CoBoxes can contain other CoBoxes and other features of almost any cash desk system and most shops ordinary classes. UML relations describe relations between comprise more than one cashier. Other optional features CoBoxes and classes. In addition, deployment information are not incorporated into the core in order to keep it as p u b l i c cobox c l a s s CashDesk { ... p r i v a t e Keyboard k e y b o a r d ; p r i v a t e Order currentOrder ; ... public void selectCashPayment ( ) { keyboard ! setStateCashPayment ( ) ; } ... } Listing 5. Core Frame for the CashDesk CoBox the application condition. This condition determines that the ∆-design is applied in all feature configurations in with the CreditCard feature is included. During application engineering, we obtain a design for a multi-desk system containing cash payment, credit card payment and keyboard input by applying the modifications specified in the ∆- design to the core design. This allows performing model- based validation and verification of this product already on the design level before the implementation is derived. Figure 4. ∆-Design for Credit Card Payment C. Implementation Layer The implementation layer for the CoCoME software product line is realized by frame technology [12]. Frames small as possible. The resulting CoBox core design is structure source code into parts with pre-defined break shown in Figure 3. The design specifies the CashDesk points. The break points can be adapted by inserting code and StoreServer CoBoxes for realizing the core func- from other frames or by removing code from break points. tionality. Instances of the CashDesk and StoreServer In our model-based framework, the structure of the CoBox- CoBoxes are created on the deployment targets Cash Desk based design is directly mapped to the frame structure on Client and Store Server, respectively, that have to be the implementation layer. The core design of a product line physically connected. The logical connection is established is realized by a set of core frames. Each CoBox in the core via an additional ConnectionAgent CoBox created on design is implemented by a core frame. The code in this each deployment target. core frame also contains break points that are necessary Figure 4 depicts the ∆-design containing the modifi- for modifications caused by ∆-frames. For each ∆-design cations for credit card payment, that is not included in in which the CoBox is altered, a ∆-frame is constructed the core configuration. To provide credit card functionality, that contains the respective modifications to this CoBox. a CoBox Bank has to be added to the system. Further, Additionally, for each CoBox newly created by a ∆-design, the CoBox CashDesk has to be extended by a CoBox a ∆-frame is generated that contains its implementation. The CardReader and further class members to take care of application conditions of the ∆-frames are the same as the the credit card payment. Also, the ConnectionAgent ones of the implemented ∆-designs. Special build frames gets further member variables and methods to handle the capture in which feature configurations the modifications of communication with the Bank. This is denoted by the + a ∆-frame are applied to the core frames. symbol attached to the respective classes and members. XVCL [17] is a programming language-independent im- Additionally, two methods of the CashDesk CoBox are plementation of frame technology using an XML-dialect modified, which is shown by the ∗ symbol. Deployment for defining frames, break points and break point adapta- information for the Bank CoBox is provided relative to the tions. We use XVCL to realize the implementation layer overall system. The deployment target Bank Server on of the CoCoME product line. The XVCL core frame for which the Bank CoBox is to be instantiated has to establish the CashDesk CoBox is depicted in Listing 5. This a physical connection to the deployment target on which frame implements the design specified in Figure 3. The CashDesk CoBox is executed. This allows dealing with frame contains XVCL break tags for including addi- deployment modifications caused by other ∆-designs. The tional attributes and methods that are specified by feature angular box in the top right corner of the ∆-design shows frames targeting this core frame. The ∆-frame in List- ... ... public void creditCardPinEntered ( i n t pin ) { cardReader ! d i s a b l e ( ) . await ( ) ; B a n k I n t e r f a c e bank = c o n n e c t W i t h B a n k ( ) ; i f ( bank == n u l l ) { System . o u t . p r i n t l n ( ” CashDesk : Bank n o t a v a i l a b l e . ” ) ; cardReader ! enable ( ) ; return ; } i f ( bank ! v a l i d a t e P a y m e n t D a t a ( c u r r e n t C r e d i t C a r d N u m b e r , pin , currentOrder . price ) . await () ) { receiveMoney ( c u r r e n t O r d e r . p r i c e ) ; } else { System . o u t . p r i n t l n ( ” CashDesk : U n a b l e t o v e r i f y p i n . ” ) ; cardReader ! enable ( ) ; } } Listing 6. ∆-Frame for the CashDesk CoBox for the Credit Card Feature Figure 7. Automated Product Derivation using XVCL ing 6 is an XVCL frame corresponding to the modifi- cations applied to the CashDesk CoBox for the Credit V. E VALUATION Card feature that is specified in the ∆-design in Figure 4. Among other modifications, this ∆-frame defines that We realized the CoCoME product line with the pro- the CashDesk_AdditionalMethods break point in the posed model-based framework for automated product deriva- CashDesk core frame has to be adapted by inserting tion [27]. The CoBox-based implementation of the product the creditCardPinEntered method if the Credit Card line is carried out in JCoBox1 that is compiled to standard feature is part of the configuration to be implemented. Java. As XVCL is programming language-independent, it is straight-forward to use it for the JCoBox implementation of The code for a product implementing a particular feature the CoCoME product line. In the current implementation, configuration can be automatically derived from the core 168 different products of the CoCoME product line can be frames and ∆-frames of the product line implementation derived automatically by the XVCL-based two-step deriva- during application engineering by the two-step derivation tion process. The implementation of the CoCoME software process depicted in Figure 7. Adapting core frames as it is product line consists of 12 core frames, 21 ∆-frames and 12 necessary for automated product derivation is not possible build frames. The derivation process requires 6 additional in a single XVCL run. XVCL frames are defined in a tree- meta frames not containing any source code to guide the structured frame hierarchy. This structure is traversed (in- derivation. Non-variable system parts are implemented in 5 order) during processing, such that adaptations in superordi- regular source code files. nate frames overwrite adaptations in subordinate frames, if The advantage of the presented approach is that it is not both frames target the same break point. This is useful for limited to a particular implementation language or technique flexible specialized frame adaptations, but in our application, and applicable in a variety of scenarios. The development frames adapting the same break point should not modify of the product line core allows using established single each other. Therefore, in the two-step derivation process, application engineering principles. Manual product-specific first, the modifications specified in the ∆-frames with intervention is explicitly avoided such that modifications in valid application condition are accumulated into a single any of the product line artifacts can be fully automatically temporary modification frame by one run of the XVCL propagated to existing products. There is no need for ad- processor. The selection of the ∆-frames contributing to ditional customization of products after product derivation. the accumulated modifications is controlled by special build Modifications of the product line artifacts, however, affect frames capturing the application conditions of the ∆-frames. all three layers. This introduces the need for additional syn- In the second processing step, the accumulated modifications chronization mechanisms in case of parallel modifications. in the temporary modification frames are applied to adapt the corresponding core frames by a second run of the XVCL VI. C ONCLUSION processor. This ensures a flat frame hierarchy for the second We have presented a model-based framework for auto- process, so that a set of modifications targeting the same mated product derivation relying on an independent model- break point are accumulated instead of being overwritten. based design layer. The design bridges the gap between The result of this process is a product implementation for the desired feature configuration. 1 http://softech.informatik.uni-kl.de/Homepage/JCoBox feature models and product implementations. Its structure [13] T. Ziadi, L. Hélouët, and J.-M. Jézéquel, “Towards a UML guides the development of implementation artifacts capable Profile for Software Product Lines,” in Workshop on Product of automated product derivation. We realized and evaluated Familiy Engineering (PFE), 2003, pp. 129–139. the proposed framework with an extended version of UML [14] S. Deelstra, M. Sinnema, J. van Gurp, and J. Bosch, “Model for the design and frame technology for the implementation. Driven Architecture as Approach to Manage Variability in For future work, we will realize the introduced framework Software Product Families,” in Workshop on Model Driven with different implementation techniques to evaluate its Architecture: Foundations and Applications (MDAFA 2003), 2003, pp. 109–114. general applicability. A first candidate is the trait-based language presented in [28]. Additionally, we will improve [15] Ø. Haugen, B. Møller-Pedersen, J. Oldevik, and A. Solberg, the tool support following our prototypical implementation. “An MDA-based framework for model-driven product deriva- In order to analyze the effects of product line evolution tion,” in Software Engineering and Applications (SEA), 2004, pp. 709–714. for automated product derivation, we will formalize our approach to give a formal account how the design and [16] H. Gomaa and M. E. Shin, “Automated Software Product implementation layers are affected by newly added features. Line Engineering and Product Derivation,” in HICSS, 2007. R EFERENCES [17] H. Zhang and S. Jarzabek, “XVCL: A Mechanism for Handling Variants in Software Product Lines,” Science of [1] P. Clements and L. Northrop, Software Product Lines: Prac- Computer Programming, vol. 53, pp. 381–407, 2004. tices and Patterns. Addison Wesley Longman, 2001. [18] U. W. Eisenecker and K. Czarnecki, Generative Program- [2] S. Deelstra, M. Sinnema, and J. Bosch, “Product Derivation ming. Addison-Wesley, 2000. in Software Product Families: A Case Study,” Journal of Systems and Software, vol. 74, no. 2, pp. 173–194, 2005. [19] C. Kästner, S. Apel, and M. Kuhlemann, “Granularity in Software Product Lines,” in International Conference on Software Engineering (ICSE), 2008, pp. 311–320. [3] C. W. Krueger, “New Methods in Software Product Line Development,” in SPLC, 2006, pp. 95–102. [20] G. Kiczales et al., “Aspect-Oriented Programming,” in European Conference on Object-Oriented Programming [4] M. Völter and I. Groher, “Product Line Implementation using (ECOOP). Springer-Verlag, 1997. Aspect-Oriented and Model-Driven Software Development,” in SPLC, 2007, pp. 233–242. [21] D. Batory, J. N. Sarvela, and A. Rauschmayer, “Scaling Step- Wise Refinement,” in International Conference on Software [5] J. Bayer et al., “PuLSE: a Methodology to Develop Software Engineering (ICSE), 2003, pp. 187–197. Product Lines,” in Symposium on Software Reusability (SSR), 1999, pp. 122–131. [22] Y. Smaragdakis and D. S. Batory, “Mixin Layers: An Object-Oriented Implementation Technique for Refinements [6] C. Atkinson et al., Component-based Product Line Engineer- and Collaboration-based Designs,” ACM Trans. Softw. Eng. ing with UML. Addison-Wesley, 2002. Methodol., vol. 11, no. 2, pp. 215–255, 2002. [7] J. D. McGregor, “Preparing for Automated Derivation of [23] G. Botterweck, K. Lee, and S. Thiel, “Automating Product Products in a Software Product Line,” Carnegie Mellon Soft- Derivation in Software Product Line Engineering,” in Soft- ware Engineering Institute, Tech. Rep., 2005. ware Engineering, 2009, pp. 177–182. [24] S. Herold et al., “CoCoME - The Common Component Mod- [8] K. Czarnecki and M. Antkiewicz, “Mapping Features to eling Example,” in Common Component Modeling Example, Models: A Template Approach Based on Superimposed Vari- A. Rausch et al., Eds. Springer-Verlag, 2008, pp. 16 – 53. ants,” in Generative Programming and Component Enginer- ing (GPCE), 2005, pp. 422 – 437. [25] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson, “Feature-Oriented Domain Analysis (FODA) [9] G. Botterweck, L. O’Brien, and S. Thiel, “Model-driven Feasibility Study,” Carnegie Mellon Software Engineering Derivation of Product Architectures,” in Automated Software Institute, Tech. Rep., 1990. Engineering (ASE), 2007, pp. 469–472. [26] G. Booch, J. Rumbaugh, and I. Jacobson, The Unified Mod- [10] B. Selic, “The Pragmatics of Model-driven Development,” eling Language User Guide. Addison-Wesley, 1999. IEEE Software, Sept 2003. [27] A. Worret, “Automated Product Derivation for the CoCoME [11] J. Schäfer and A. Poetzsch-Heffter, “CoBoxes: Unifying Software Product Line: From Feature Models to CoBoxes,” Active Objects and Structured Heaps,” in Formal Methods for Master’s thesis, University of Kaiserslautern, March 2009. Open Object-Based Distributed Systems (FMOODS 2008), 2008, pp. 201–219. [28] L. Bettini, V. Bono, F. Damiani, and I. Schaefer, “Implement- ing Software Product Lines using Traits,” Dipartimento di [12] P. G. Bassett, Framing Software Reuse: Lessons From the Informatica, Università di Torino, Tech. Rep., 2009, available Real World. Prentice Hall, 1996. at http://www.di.unito.it/˜damiani/papers/isplut.pdf.