Model-driven Support for Source Code Variability in Automotive Software Engineering Cem Mengi∗ , Christian Fu߆ , Ruben Zimmermann† , and Ismet Aktas‡ ∗ Computer Science 3 (Software Engineering) RWTH Aachen University, Ahornstr. 55, 52074 Aachen, Germany Email: mengi@i3.informatik.rwth-aachen.de † Carmeq GmbH Carnotstr. 4, 10587 Berlin, Germany Email: {christian.fuss | ruben.zimmermann}@carmeq.com ‡ Computer Science 4 (Distributed Systems) RWTH Aachen University, Ahornstr. 55, 52074 Aachen, Germany Email: ismet.aktas@cs.rwth-aachen.de Abstract—Variability on source code level in automotive soft- their specifics [3], [6]. ware engineering is handled by C/C++ preprocessing directives. This paper deals with variability on source code level. Here, It provides fine-grained definition of variation points, but brings we focus on the programming languages C/C++, because they highly complex structures into the source code. The software gets more difficult to understand, to maintain and to integrate are the most widely used languages in automotive software changes. Current approaches for modeling and managing vari- engineering. With about 51% C has the most portion followed ability on source code do not consider the specific requirements by C++ with about 30%. Assembler comes with about 8% and of the automotive domain. To close this gap, we propose a model- all other languages are applied less than 5% [7]. driven approach to support software engineers in handling source Variation points are implicitly modeled by implementing code variability and configuration of software variants. For this purpose, a variability model is developed that is linked with the C/C++ preprocessing directives. In this way, variable (condi- source code. Using this approach, a software engineer can shift tional) compilation results in specific software variants. This work steps to the variability model in order to model and manage approach allows fine-grained definition of variation points, variation points and implement their variants in the source code. but brings highly complex structures into the source code. The software gets more difficult to understand, to maintain Index Terms—automotive software engineering; programming; model-driven engineering; variability modeling; and to integrate changes. The main reason for this is that a software engineer has no support on source code level beside the programming language. Particularly, the user has to deal I. I NTRODUCTION simultaneously with problem space, configuration knowledge, Today the automotive industry provides customers a lot of and solution space [8]. If a huge number of variation points possibilities to individualize their products. They can select exists, knowledge about a valid configuration gets difficult. from a huge set of optional fittings, e.g., parking assistant, rain Furthermore, a software developer has to find out the scattered sensor, intelligent light system, and/or comfort access system. code and the dependencies of one variant manually which is The possibility to configure individual vehicles leads to the also very hard and time consuming. situation that both OEMs (Original Equipment Manufacturers) There exists a wide range of techniques and mechanisms and suppliers have to capture explicitly potential variation for modeling and managing variability [2], [9]–[15]. Most of points in their artifacts [1]–[3]. them handle variability on a higher abstraction level. Elements Thereby, the existence of variation points range over the of reusability are primarily software components, or constructs whole electric/electronic (E/E) development process. They are of object-oriented programming such as classes and methods available in the requirements, system specification, architec- which are replaced for specific variants of software. A support ture design, source code, but also in the test and integration for fine-grained specifications of variation points on source phase. Beyond that, variation points arise also during pro- code level are provided by a few number of concepts and tools duction, operation and maintenance phase. This means that [16]–[20], but they do not consider the specific requirements in the whole product life cycle for a vehicle which hold up for the automotive domain. Particularly, safety critical applica- approx. 20-25 years, there evolve various types of variation tions come under regular code reviews and therefore have high points [4], [5]. Therefore, artifacts of different phases in the demands on source code quality. Consequently, readability and development process have to be investigated in order to explore understandability of source code are of high importance, but the above mentioned existing solutions do not consider this #ifdef identifier sufficiently. ... To close this gap, we propose a model-driven approach #endif to support software developers in handling versatile source code and configuration of software variants. For this purpose, (a) #ifdef preprocessing directive. we have developed a concept to separate problem space, configuration knowledge, and solution space. The problem #ifndef identifier space includes a common cardinality-based feature model to ... capture and manage variability [10], [11]. Furthermore, it #endif supports the possibility to configure a software variant. The configuration knowledge can subsequently be transformed to (b) #ifndef preprocessing directive. the solution space. The solution space contains the source code. Here, we use a view-based approach in order to display #if constant-expression the current configuration and hide everything that do not ... belong to the configuration. #endif The paper is structured as follows: In Section II, we (c) #if preprocessing directive. analyze preprocessing directives that can express variation points. Particularly, a detailed consideration will show where problem space, configuration knowledge, and solution space is #if constant-expression1 integrated. Furthermore, the problems that we will treat will be ... described in detail by using an example. In Section III, we will #elif constant-expression2 describe our approach to solve the problems. Here, we explain .. the separation of problem space, configuration knowledge, and . solution space and go into detail of the three parts. Section IV, #elif constant-expressionN contains a short description of our implementation approach. ... In Section V, we will check if we have solved the mentioned #else problems. Finally, Section VI will summarize the paper. ... #endif II. A NALYZING S OURCE C ODE VARIABILITY (d) #if, #elif, #else preprocessing directive. In this section, we will investigate how variability can Fig. 1. Preprocessing directives to handle variation points before compilation. be expressed using C/C++ preprocessing directives. We will introduce an example in order to explain arising problems of this approach in more detail. A. Expressing Variability with C/C++ Preprocessing Direc- tives The current approach to express variation points and to configure specific software variants is to apply C/C++ pre- Fig. 2. Multilayer information in the solution space. processing directives. For this purpose, statements for condi- tional inclusions are used, e.g., #ifdef, #ifndef, #if, #elif, #else (see Figure 1) [21]. In the following, we will Analyzing preprocessing directives in detail, we have iden- use preprocessing block or block as a synonym for complete tified that different aspects of variability information is mixed preprocessing directives. into the code. We have decided to divide the information The identifier for #ifdef and #ifndef directives in analogy to Czarnecki’s generative domain model which in Figure 1a and 1b is a point of variation, because depending consists of a problem space, solution space and a configuration on its evaluation the contained source code is either included knowledge mapping between them [8]. Figure 2 illustrates this for compilation or not. by an example. In the same way, the constant-expression in #if The constant-expression Feature_A && Feature_B of and #elif preprocessing directives shown in Figure 1c the #if preprocessing directive is used to control the in- and 1d is also a point of variation. If it is evaluated to nonzero, clusion of the contained source code. Thereby, an identifier the appropriate part of source code is included for compilation, references a feature that is implemented in that code block, otherwise not. Note, that a constant-expression allows e.g., Feature_A and Feature_B. This kind of information more complex arithmetic and logical expressions. In the fol- is part of the problem space. The linking of an identifier lowing, we will use block rule or simply rule as a synonym with arithmetic and/or logical operations reflect configuration for a constant expression. knowledge. Finally, the contained code reflect the implemen- 1 #if PRIO_USE_SORTED_OBJECTS == 1 2 #define PRIO_QUICKSORT 1 3 #define PRIO_INSERTIONSORT 0 4 5 ... 6 7 #if PRIO_QUICKSORT 8 ... Fig. 4. Separation of problem space, configuration knowledge, and solution space. 9 #endif 10 11 #if PRIO_INSERTIONSORT 3) code-variants of one variation point are scattered and 12 ... have to be find manually, and 13 #endif 4) no explicit capturing of dependencies between variation 14 points. 15 static void sortTracks(...) { 16 #if PRIO_QUICKSORT As described in Section II-A we have detected information 17 quicksortTrack(...); in the source code that belongs to both problem space and 18 #elif PRIO_INSERTIONSORT solution space. For example, line 1, 7, 11, 16 etc. in Figure 3 19 insertionsortTracks(...); are variability information that are part of the problem space 20 #else and configuration knowledge. Even so, they are strongly 21 #error missing ... integrated into the solution space, i.e., the source code. 22 #endif Furthermore, considering the source code example, a soft- 23 ware engineer always has to work with all variation points 24 } simultaneously, even most of them are not part of a specific 25 #endif variant. For example, the insertion-sort algorithm in Figure 3 does not belong to the variant if quick-sort is chosen (lines 3, Fig. 3. An example for variability handling with preprocessing directives. 11-14, and 18-19). If more complex code sizes are regarded, solving a valid configuration gets more difficult. tation which is part of the solution space. Moreover, code-variants of one variation point are typically not implemented in a complete block but rather are scattered. B. Problem Description by Example For example, the quick-sort variant in Figure 3 appears in In this section, we will explain the problems that currently lines 2, 7-9, and 16-17. Particularly, this complicate including exists when dealing with C/C++ preprocessing directives to changes into code-variants or their appropriate preprocessing handle variability information. For this purpose, we will in- directives. If the code gets more complex, finding the code- troduce an example. variants manually gets very hard and time consuming. If Typically, sensors are adopted to collect data. In some changes into code or conditions have to be done, all relevant situations it is necessary to prioritize the captured data. If so, source code have to be find out manually to hold them different variants of sorting algorithms can be applied, e.g., consistent. quick-sort or insertion-sort. Finally, in many cases variation points are not isolated but The associated C source code is shown in Figure 3. The depend on each other. In the source code, there is no explicit code between line 1 to 25 is only included if prioritization is capturing of such information. For example, quick-sort and selected. One of the sorting algorithms have to be configured insertion-sort in Figure 3 are only included if a prioritization (set to 1) in order to integrate the appropriate source code into is necessary. If so, then they have an exclusive dependency on the software variant. In our case, it is the quick-sort (see line each other, i.e., only one can be chosen. 2). Particularly, the sortTracks(...) function (line 15) includes only the part of the source code which belongs to the III. M ODEL - DRIVEN S UPPORT FOR S OURCE C ODE quick-sort algorithm (line 17). VARIABILITY Although using preprocessing directives allows fine-grained To deal with the identified problems mentioned in Sec- and flexible specification of variation points, the source code tion II-B, we propose a model-driven approach to treat source gets more difficult to understand, to maintain, and to integrate code variability and to support configuration of software changes. Analyzing the source code, we have identified four variants. Therefore, we have developed a concept to separate main problems, i.e., problem space and configuration knowledge from solution 1) mixing problem space, configuration knowledge and space. The problem space is supported by a variability model solution space, that is based on Czarnecki’s cardinality-based feature model 2) viewing all variation points without the knowledge of a [10], [11] (in the following we will use the term variability valid configuration, model as a synonym). Here, variation points are captured and «interface» Concept A user configures a specific variant whereas every modifi- 1 cation of the source code, i.e., adding, deleting or modifying code lines, is linked with that configuration. Later on, it will +groups 0..* +rootFeature 1 be possible to display or hide code blocks depending on a «interface» «interface» +children 0..* specified configuration. Group The basic principle for every transformation is the con- Feature 1 +groups 1..* figuration knowledge from the variability model. If features F 1, F 2, . . . , F n are selected, a transformation into a rule of the form F_1 && F_2 && ...&& F_n is executed. In +members «interface» the following examples, we always assume that this constant- 0..* CardinalityBasedElement expression is used. Depending on the modification of the source code, the constant-expression is integrated into a preprocessing direc- Fig. 5. Meta-model of the cardinality-based feature model. tive. 1) Modification of Source Code Outside Existing Prepro- cessing Blocks: The most simple case is when a software managed. The configuration knowledge contains all informa- engineer modifies code outside existing preprocessing blocks. tions to transform knowledge from problem space to solution space. The variability model supports the configuration. The a) Adding: If we have a rule of the form F_1 && F_2 solution space includes the source code. By integrating a && ...&& F_n, then it is embedded to an #if preprocess- view-based approach, only the configured part of the source ing block: code is displayed. This reflects the result from problem space #if F_1 && F_2 && ...&& F_n transformed to solution space. ... Figure 4 gives an overview of the separation of our ap- #endif proach. The general idea is, that a software developer not only work on the solution space, i.e., the source code, but also shift In this way, the code is only included for compilation, if the work steps into the variability model that is able to capture appropriate configuration is selected. the problem space and configuration knowledge. b) Deleting: Deleting code lines during a given configu- ration F 1, F 2, . . . , F n do not delete them from the source A. Source Code Variability Model file, but implies that the deleted lines should not appear in The focus on this paper does not lie on defining a new that configuration. For this purpose, we use the following #if variability model, but rather using existing solutions to support preprocessing directive with the deleted code lines: variability on source code level. Analyzing existing approaches #if !(F_1 && F_2 && ...&& F_n) we have decided to adapt a cardinality-based feature model. . . . deleted code lines Since it is a very common way to model variability, an #endif integration of other tools and models get more simple. Partic- ularly, this integration would allow using variability modeling 2) Modification of Source Code Inside Existing Preprocess- techniques which are applied on a more abstract level, i.e., ing Blocks: A slightly different case arises, if modifications managing variability for classes, methods, objects etc. Our inside existing preprocessing blocks are made. approach can then be used for fine-grained modeling of a) Adding: If code is added inside a preprocessing block, variability, i.e., on source code lines. then it is split in two blocks with the constant-expression as Figure 5 shows the meta-model for the cardinality-based before and the added code lines are embraced with an #if feature model. It allows to define a tree-based structure. preprocessing directive and a rule F_1 && F_2 && ...&& Thereby, a Concept node contains exactly one feature, i.e., F_n that is transformed from the specified configuration. the rootFeature. A Feature consists of an arbitrary number #if constant-expression 1 of children features. Moreover, a Concept node references line 1 #if constant-expression 1 #endif an arbitrary number of Groups which define the number of line 1 #if constant-expression 2 elements in a group that can be specified for a configuration. line 2 ⇒ line 2 line 3 #endif B. Transformation of Configuration Knowledge #endif #if constant-expression 1 line 3 To profit from the separation, it is an essential part to shift #endif work steps to the central variability model. For this purpose, a connection between variability model and source code is In 4 the example above, the blue marked code[12]line Implementation B. W.(line_2) Kernighan and D. M. Ritchie. C P guage, 2nd Ed. Prentice Hall, January 198 necessary. To achieve this, we will use preprocessing directives on the left side is added during a configuration F 1, F 2, [13] F. J. v. d. Linden, K. Schmid, and E. Ro which were, as described in Section II, the primary concept .5. . ,Related F n. InWork that case, line_1 and line_3 are Productembraced Lines in Action: The Best Indu Product Line Engineering. Springer-Verla to express variation points. In this way, it will be possible to with the 6 Conclusion preprocessing directive as before and Secaucus, NJ, USA,is2007. line_2 automatically add or delete preprocessing directives. embraced with an #if preprocessing directive[14]and a constant- C. Lopes and G. Kiczales. Aspect-orien Technology of Object-Oriented Languag References Conference on, 0:468, 2000. [15] C. Mengi and I. Armaç. Functional Var [1] S. Apel, T. Leich, and G. Saake. Aspectual feature modules. Adaptable Functional Networks. In VaMo IEEE Trans. Softw. Eng., 34(2):162–180, 2008. ternational Workshop on Variability Mode [2] T. Asikainen, T. Soininen, and T. Männistö. A Koala-Based Intensive Systems, volume 29 of ICB Resea Approach for Modelling and Deploying Configurable Soft- 83–92. Universität Duisburg-Essen, 2009. ware Product Families. In PFE 2003: Software Product- [16] S. J. Paul, P. Bassett, H. Zhang, and W. Z Family Engineering, 5th International Workshop, volume based variant configuration language. In expression F_1 && F_2 && ...&& F_n (in the figure this purpose, we only have to extend the constant-expression above, denoted as constant-expression_2). of the preprocessing block which include the code lines that This adaptation differs from the transformation for modifi- should appear in the current configuration. cation of source code outside existing preprocessing directives. #if constant-expression 1 #if constant-expression 1 If we would transform the added code lines in the same way line 1 || constant-expression 2 line 1 as in Section III-B1a then we would get a nested structure. But ... ⇒ ... line n this would bring an implication into the code that possibly is #endif line n #endif not planned by a software developer. For example, if line_2 would be nested into the superior preprocessing block, then In the example above, the blue marked 4 Implementation code andlines [12] B. W. Kernighan D. M. Ritchie. C Progr the code lines would only exist in a variant that includes on the left side should included into Language, 2nd Ed. Prentice Hall, January 1988. a configuration [13] F. J. v. d. Linden, K. Schmid, and E. R 5 Related Work a configuration of the superior block. By dividing them in F 1, F 2, . . . , F n. The appropriateSoftware preprocessing Product Lines in Action: The Best Industr Springer-Verlag New York, Inc., Secaucus, NJ, USA multiple blocks of preprocessing directives this side effect block after transformation is shown on 6 Conclusion [14] C.the right Lopes and side.Aspect-oriented progra G. Kiczales. is avoided and the described implication is still possible if The code line now would appear in Technology of Object-Oriented Languages, Inter configuration Conference on, 0:468, 2000. References the software engineer uses the configuration of the variability that is transformed to constant-expression_1 [15] C. Mengi and I. Armaç. Functional Variant M for Adaptable Functional Networks. In VaMo model. or[1] IEEE S. Apel, T. Leich, and G. Saake. Aspectual feature modules. constant-expression_2, whereThird International constant- Workshop on Variability Mode Trans. Softw. Eng., 34(2):162–180, 2008. Software-Intensive Systems, volume 29 of ICB R b) Deleting: When deleting code lines, the mentioned expression_2 [2] T. Asikainen, T. Soininen, is and theT. Männistö. current Aconfiguration Koala- Report, 1, F F pages 2,Universität 83–92. . . . , Duisburg-Essen, 2 Based Approach for Modelling and Deploying Config- problems for adding code do not appear, because the reference F n.urable Software Product Families. In PFE 2003: Software [16] S. J. Paul, P. Bassett, H. Zhang, and W. Zhang. Xml-based variant configuration language. In IC to the superior preprocessing block is mandatory and must be Product-Family Engineering, 5th International Workshop, b) Deleting: volume If in aComputer 3014 of Lecture Notes complete Science, pagespreprocessing block is Proceedings of the international conference on S engineering, pages 810–811, 2003. kept, so that the constant-expression of the superior prepro- deleted, 225–249.an adaptation Springer, 2003. of the constant-expression [17] K. Pohl, should G. Böckle, be and F. J. van der [3] D. Beuche, H. Papajewski, and W. Schröder-Preikschat. Software Product Line Engineering: Foundations, P cessing block and the constant-expression that is transformed made. Thereby, Variability managementthewithtransformation of a configuration feature models. Sci. Comput. is moti- Springer, September 2005. Program., 53(3):333–352, 2004. from the current configuration must be included. vated by the [4] A. Bryant, sameK. principle A. Catton, De Volder, and asG. C.for Murphy. [18] Pure Systems website. http://www.pure-systems.co deleting [19] code lines M. Sinnema, inside S. Deelstra, J. Nijhuis, and J. Bosch Explicit programming. In AOSD ’02: Proceedings of the #if constant-expression 1 existing preprocessing blocks. 1st international conference on Aspect-oriented software AMOF: A Framework for Modeling Variability in S Product Families. In SPLC 2004: Software Produc line 1 development, pages 10–18, New York, NY, USA, 2002. Third International Conference, volume 3154 of #endif ACM. #if constant-expression 1 #if constant-expression 1 #if constant-expression 1 Notes in Computer Science, pages 197–213. Springe #if constant-expression 1 [5] P. line 1Clements and L. Northrop.&& !constant-expression 2 line 1 Software line 1 line 2 ⇒ && !constant-expression 2 ... product lines: practices and patterns. ⇒ Addison- line 2 Wesley Longman Publishing Co., Inc., Boston, MA, ... USA, line 3 line n #endif 2001. line n #endif #endif [6] K. Czarnecki and U. Eisenecker. #if constant-expression 1 #endif Generative programming: methods, tools, and applications. line 3 ACM Press/Addison-Wesley Publishing Co. New York, NY, #endif In the example above, the red marked and struck out code USA, 2000. Deleting [11] C. Kästner, S. Apel, and M. Kuhlemann. Granularity i [7] K. Czarnecki, S. Helsen, and U. W. Eisenecker. Formal- ware product lines. In ICSE ’08: Proceedings of th lines on the left side are deleted during a configuration F 1, izing cardinality-based feature models and their specializa- international conference on Software engineering, In 4 the example above, the red marked and struck out code line Implementation 4 Granularity [11] C. Kästner, S. Apel, and M. Kuhlemann. Implementation in soft- tion. Software Process: Improvement and Practice, 10(1):7– F 2, . . . , F n. The result of the transformation with the ware product lines. In ICSE ’08: Proceedings of the 30th 311–320, New York, NY, USA, 2008. ACM. (line_2) on the left side is deleted during a configuration international conference on Software [8] 29, 2005. engineering, pagesand C. H. Kim. Cardinality-Based Fea- [12] B. W. Kernighan and D. M. Ritchie. C Program 5 Related Work given configuration is shown on the right side. Considering 311–320, New York, NY, USA, 2008. 5ACM. K. Czarnecki Related Work Language, 2nd Ed. Prentice Hall, January 1988. F 1, F 2, . . . , F n. In that case, line_1 and line_3 ture Modeling and Constraints: A Progress Report. In [13] F. J. v. d. Linden, K. Schmid, and E. Ro 6 Conclusion the constant-expression on the right side, the appropriate [12] B. W. Kernighan and D. M. Ritchie. COOPSLA’05 Programming International Workshop on Software Factories, Software Product Lines in Action: The Best Industria are embraced with the preprocessing block as before and Language, 2nd Ed. Prentice Hall, January 6 1988. Conclusion October 2005. Springer-Verlag New York, Inc., Secaucus, NJ, USA, [13] F. J. v. d. Linden, K. Schmid, [9] code lines only appear if constant-expression_1 andEmbedded E. Rommes. Systems Design. http://www.embedded.com/. [14] C. Lopes and G. Kiczales. Aspect-oriented program References is included into an #if preprocessing block line_2 Software Product Lines in Action: The[10] BestK.Industrial C. Kang,Practice in Product S. G. Cohen, J. A.Line but not constant-expression_2 holds, where Hess,Engineering. W. E. Novak, and A. S. Technology of Object-Oriented Languages, Interna References Springer-Verlag New York, Inc., Secaucus, NJ, USA, 2007. Peterson. Feature-Oriented Domain Analysis (FODA) Fea- with a constant-expression constant-expression_1 [14] C. Lopes and G. Kiczales. Aspect-orientedsibility programming. Conference on, 0:468, 2000. [1] S. Apel, T. Leich, and G. Saake. Aspectual feature modules. constant-expression_2 is equal to F_1 && F_2 && Study. Technical report, Carnegie-Mellon University [15] C. Mengi and I. Armaç. Functional Variant Mo && IEEE !constant-expression_2, Trans. Softw. Eng., 34(2):162–180, 2008. where constant- Technology of Object-Oriented Languages, [1] S. International Software Apel, T.Engineering Leich, and G.Institute, Saake. November 1990. modules. Aspectual feature for Adaptable Functional Networks. In VaMoS [2] T. Asikainen, T. Soininen, and T. Männistö. A Koala- Conference on, 0:468, 2000. ...&& F_n. [11] IEEE C. Kästner, Trans.S.Softw. Apel,Eng., and M. Kuhlemann. Granularity 34(2):162–180, 2008. in soft- Third International Workshop on Variability Modell expression_2 is the result Based Approach for Modelling and Deploying Config- of the transformation of the [15] C. Mengi and I. Armaç. Functional Variant ware Modeling product lines. In ICSE ’08: Proceedings [2] T. Asikainen, T. Soininen, and T. Männistö. A Koala- for Adaptable Functional Networks. In international VaMoS 2009: of the 30th Software-Intensive Systems, volume 29 of ICB Re conference on Software engineering, pages Report, pages 83–92. Universität Duisburg-Essen, 200 current configuration, i.e., urable Software Product Families. In PFE 2003: Software F_1 Product-Family Engineering, 5th International Workshop, && F_2 && ...&& F_n. Third International Workshop on Variability Based Approach C. Views on Source Code Modelling 311–320, urable Software of New York, for Modelling NY,Families. Product USA, 2008. and Deploying ACM. In PFE Config- 2003: Software [16] S. J. Paul, P. Bassett, H. Zhang, and W. Zhang. Software-Intensive Systems, volume 29 of ICB Research We volume have3014 decided to split of Lecture Notes theScience, in Computer preprocessing pages block but nesting Product-Family Engineering, 5th International Workshop, The solution space of our approach is the source code. In Report, pages 83–92. Universität Duisburg-Essen, 2009. Xml-based variant configuration language. In ICS Proceedings of the international conference on So 225–249. Springer, 2003. volume 3014 of Lecture Notes in Computer Science, pages them [3] D. would Beuche, H. in this case Papajewski, and W.also be possible. [16] S. J. Paul, P. Bassett, H. Zhang, and W. Zhang. Xvcl: Schröder-Preikschat. order to take the advantages of the division the transformation 225–249. Springer, 2003. Xml-based variant configuration language. In ICSE ’03: engineering, pages 810–811, 2003. Variability management with feature models. Sci. Comput. [3] D. Beuche, H. Papajewski, and W. Schröder-Preikschat. [17] K. Pohl, G. Böckle, and F. J. van der L IfProgram., only53(3):333–352, #if !constant-expression_2 2004. would be Proceedings of the international conference on Software engineering, pages 810–811, 2003. of configuration knowledge must be reflect in the source code. Variability management with feature models. Sci. Comput. Software Product Line Engineering: Foundations, Pri [4] A. Bryant, A. Catton, K. De Volder, and G. C. Murphy. Springer, September 2005. included then the deleted code Explicit programming. In AOSD ’02: Proceedings of the line would be appear in Program., [4] A. Bryant, 53(3):333–352, A. Catton, 2004. For this purpose, we have adopt a view-based approach where [17] K. Pohl, G. Böckle, and F. J. van der Linden. K. De Volder, and G. C. Murphy. [18] Pure Systems website. http://www.pure-systems.com Software Product Line Engineering: Foundations, Principles and Techniques. each1st variant that international conference do not contain on Aspect-oriented development, pages 10–18, New York, NY, USA, 2002. software the configuration F 1, Springer, September 2005. Explicit programming. In AOSD ’02: Proceedings of the all source code is hidden that is not part of the configuration. [19] M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch. AMOF: A Framework for Modeling Variability in So 1st international conference on Aspect-oriented software [18] Pure Systems website. http://www.pure-systems.com/. F 2,ACM. . . . , F n. Particularly, it would be independent from The configuration is made on the cardinality-based feature [19] M. Sinnema, S. Deelstra, J. Nijhuis, and J.development, Bosch. COV-pages 10–18, New York, NY, USA, 2002. Product Families. In SPLC 2004: Software Product [5] P. Clements and L. Northrop. ACM. Third International Conference, volume 3154 of L constant-expression_1. Software product lines: practices and patterns. Addison- AMOF: A Framework for Modeling Variability in Software model which was explained in Section III-A. Depending on [5] P.Product Lines, Product Families. In SPLC 2004: Software Clements and L. Northrop. Notes in Computer Science, pages 197–213. Springer, Wesley Longman Publishing Co., Inc., Boston, MA, USA, 3)2001.Modification of Source Code for Complete Preprocessing Software product lines: practices and patterns. the configuration, all constant-expressions of preprocessing Third International Conference, volume 3154 of Lecture Addison- Notes in Computer Science, pages 197–213.Wesley Springer,Longman 2004. Publishing Co., Inc., Boston, MA, USA, Blocks: [6] K. Beside Czarnecki of andadding U. or Eisenecker. deleting code lines, in some Generative programming: methods, tools, and applications. directives are evaluated to decide whether the block should 2001. [6] K. Czarnecki and U. Eisenecker. situations it is ACM Press/Addison-Wesley USA, 2000. also reasonable Publishing Co. New York,toNY,add or delete complete be displayed or hidden. In principle, this emulates the prepro- Generative programming: methods, tools, and applications. ACM Press/Addison-Wesley Publishing Co. New York, NY, preprocessing blocks [7] K. Czarnecki, S. Helsen, and U.inW.aEisenecker. given configuration. Formal- cessor with the advantage that targeted configurations can be USA, 2000. izing cardinality-based feature models and their specializa- a)Software tion. Adding: Process: If it is necessary Improvement to add a preprocessing block and Practice, 10(1):7– [7] K. Czarnecki, S. Helsen, and U. W. Eisenecker. Formal- viewed.izing cardinality-based feature models and their specializa- 29, 2005. of[8]one variant (or configuration) K. Czarnecki and C. H. Kim. Cardinality-Based Fea- into another one, this could be tion. Software Process: Improvement and Practice, 10(1):7– doneture by configuring the variant Modeling and Constraints: A Progress Report. In where the code block appears, 29, 2005. IV. I MPLEMENTATION [8] K. Czarnecki and C. H. Kim. Cardinality-Based Fea- OOPSLA’05 International Workshop on Software Factories, ture Modeling and Constraints: A Progress Report. In copying it, October 2005. configuring the variant [9] Embedded Systems Design. http://www.embedded.com/. where it should appear, The described concepts are implemented in a way that they OOPSLA’05 International Workshop on Software Factories, and [10] K.then C. Kang, pasting S. G. Cohen,it. J. A.This Hess, W.method E. Novak, andisA. a S. little bit uncomfortable. can be integrated into existing development processes and October 2005. [9] Embedded Systems Design. http://www.embedded.com/. Peterson. Feature-Oriented Domain Analysis (FODA) Fea- Therefore, sibility Study.we support Technical adding University report, Carnegie-Mellon complete code blocks into a projects as seamless as possible. Therefore, we had to follow [10] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Software Engineering Institute, November 1990. Peterson. Feature-Oriented Domain Analysis (FODA) Fea- configuration automatically without copy/paste actions. For general requirements: sibility Study. Technical report, Carnegie-Mellon University Software Engineering Institute, November 1990. Solution Space Problem Space Configuration Knowledge Fig. 6. A screenshot of the developed Eclipse plugin. 1) At all time, valid C/C++ code must be available. it supports a software developer to detect modeling errors. 2) Editing and maintenance of source code must be possi- ble without the need for specific tooling. V. P ROBLEMS R EVISTED 3) Additional work load for a software developer must be If we consider again the listed problems in Section II-B, we as low as possible. observe that they are solved by the described concepts. 4) Dynamic changes must be feasible. The core problem was that problem space, configuration The implementation is fulfilled by developing a plugin for knowledge, and solution space were mixed. By dividing them the Eclipse Framework [22]. The cardinality-based feature we have formed a basis to solve the other problems. Knowl- model is implemented with support of the Eclipse Modeling edge about a valid configuration is given through support Framework (EMF) [23]. An editor for the feature model was of the configurable feature model. Code-variants must not also generated by using EMF which can be used in parallel find out manually, but are solved by the configuration which to the Eclipse C/C++ Development Tooling (CDT) [24]. A then is transformed to the source code. By adopting a view- screenshot is shown in Figure 6. based approach only the relevant code lines are displayed. The left part contains the editor where C/C++ source code Dependencies between variation points are also stored in the can be written. The right part contains a view on a configurable feature model by expressing cardinalities. feature model. The software developer can use both parts in Overall, complex work steps are now shifted to a model parallel in order to configure a specific variant of interest so where they can be handled more easier. The software engineer that all other code lines that are not included into the variant can now concentrate on the main work, i.e., developing are hidden. In some situations, not all modifications on model software. configuration should influence the view on the source code. In the same way, not all modifications on source code should VI. C ONCLUSION influence the selected configuration. For this purpose, the user In this paper we have described a model-driven approach gets the possibility to explicitly select a control element that to handle source code variability. We have outlined existing triggers the linking between code and model. If the linking problems, analyzed them in detail in order to propose a is stopped the transformation is subsequently executed. This solution. The main problem is that problem space, configu- means, that all preprocessing directives are added into the ration knowledge, and solution space is mixed, i.e., a software source code. engineer works only on the source code without any support The editor to configure a variant has the ability to select or to treat variability. This leads to the situation that source code deselect features and to solve implications. Furthermore, the is overcrowded with variation points without knowing how configuration of invalid variants are avoided. At the same time, they depend on each other. In our approach we have suggest a division of problem space, configuration knowledge, and [18] C. Lopes and G. Kiczales, “Aspect-oriented programming,” Technology solution space. A cardinality-based feature model is adopted of Object-Oriented Languages, International Conference on, vol. 0, p. 468, 2000. and linked with the source code in order to shift work steps [19] A. Bryant, A. Catton, K. De Volder, and G. C. Murphy, “Explicit into the model. By a configuration support modifications on programming,” in AOSD ’02: Proceedings of the 1st international the source code are linked with the model. Furthermore, conference on Aspect-oriented software development. New York, NY, USA: ACM, 2002, pp. 10–18. transformation of configuration is supported by adopting a [20] S. J. Paul, P. Bassett, H. Zhang, and W. Zhang, “Xvcl: Xml-based variant view-based approach. configuration language,” in ICSE ’03: Proceedings of the international In future work, we want to integrate this approach with conference on Software engineering, 2003, pp. 810–811. [21] B. W. Kernighan and D. M. Ritchie, C Programming Language, 2nd earlier phases of an E/E development process. Software ar- Ed. Prentice Hall, January 1988. chitectures are one essential artifact that need support for [22] The Eclipse Foundation website, http://www.eclipse.org/. variability handling. If variability support is provided, an [23] F. Budinsky, S. A. Brodsky, and E. Merks, Eclipse Modeling Framework. Pearson Education, 2003. integration with the source code level would be an essential [24] Eclipse C/C++ Development Tooling Project, benefit. http://www.eclipse.org/cdt/. R EFERENCES [1] P. Clements and L. Northrop, Software product lines: practices and patterns. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2001. [2] K. Pohl, G. Böckle, and F. J. van der Linden, Software Product Line Engineering: Foundations, Principles and Techniques. Springer, September 2005. [3] F. J. v. d. Linden, K. Schmid, and E. Rommes, Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 2007. [4] M. Broy, “Challenges in automotive software engineering,” in ICSE ’06: Proceedings of the 28th international conference on Software engineering. New York, NY, USA: ACM, 2006, pp. 33–42. [5] A. Pretschner, M. Broy, I. H. Kruger, and T. Stauner, “Software engineer- ing for automotive systems: A roadmap,” in FOSE ’07: 2007 Future of Software Engineering. Washington, DC, USA: IEEE Computer Society, 2007, pp. 55–71. [6] C. Mengi and I. Armaç, “Functional Variant Modeling for Adaptable Functional Networks,” in VaMoS 2009: Third International Workshop on Variability Modelling of Software-Intensive Systems, ser. ICB Research Report, vol. 29. Universität Duisburg-Essen, 2009, pp. 83–92. [7] Embedded Systems Design website, http://www.embedded.com/. [8] K. Czarnecki and U. Eisenecker, Generative programming: methods, tools, and applications. ACM Press/Addison-Wesley Publishing Co. New York, NY, USA, 2000. [9] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Pe- terson, “Feature-Oriented Domain Analysis (FODA) Feasibility Study,” Carnegie-Mellon University Software Engineering Institute, Tech. Rep., November 1990. [10] K. Czarnecki, S. Helsen, and U. W. Eisenecker, “Formalizing cardinality-based feature models and their specialization,” Software Process: Improvement and Practice, vol. 10, no. 1, pp. 7–29, 2005. [11] K. Czarnecki and C. H. Kim, “Cardinality-Based Feature Modeling and Constraints: A Progress Report,” in OOPSLA’05 International Workshop on Software Factories, October 2005. [12] M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch, “COVAMOF: A Framework for Modeling Variability in Software Product Families,” in SPLC 2004: Software Product Lines, Third International Conference, ser. Lecture Notes in Computer Science, vol. 3154. Springer, 2004, pp. 197–213. [13] D. Beuche, H. Papajewski, and W. Schröder-Preikschat, “Variability management with feature models,” Sci. Comput. Program., vol. 53, no. 3, pp. 333–352, 2004. [14] Pure Systems website, http://www.pure-systems.com/. [15] T. Asikainen, T. Soininen, and T. Männistö, “A Koala-Based Approach for Modelling and Deploying Configurable Software Product Families,” in PFE 2003: Software Product-Family Engineering, 5th International Workshop, ser. Lecture Notes in Computer Science, vol. 3014. Springer, 2003, pp. 225–249. [16] C. Kästner, S. Apel, and M. Kuhlemann, “Granularity in software product lines,” in ICSE ’08: Proceedings of the 30th international conference on Software engineering. New York, NY, USA: ACM, 2008, pp. 311–320. [17] S. Apel, T. Leich, and G. Saake, “Aspectual feature modules,” IEEE Trans. Softw. Eng., vol. 34, no. 2, pp. 162–180, 2008.