In our recent paper, we demonstrated that the product line engineering as a developing paradigm can ease the construction of a family of compilers [1]. We showed engineering activities for a family of compilers from product line analysis through product line architecture design to product line component design. Then, we presented how to build particular compilers from core assets resulting from the previous activities and how to take advantage of modern programming language technology to organize this task. Particularly, we used the Standard ML programming language which supports the powerful module system including parameterized modules called functors. Our work showed that the module system in Standard ML was powerful enough to express and implement variations identified by product line engineering.

One of frequent questions on our experience was on Standard ML. We have been asked if our result can be still applicable to other languages which do not support the powerful module systems such as Standard ML. For example, can we obtain the similar result with Java? This question does nothing with so called the-war-of-languages where no one can win. It does ask the very belief that the general approach to the product line engineering is independent of a particular implementation technology. While we are sure that Java and Standard ML differ in many features, how can our the product line engineering be independent? In this paper, we try to solve this simple question by answering the following sub-questions:

• What means by being independence of implementation technologies. We are going to introduce our own terminology of being independence.
• Survey as many technologies as possible in the literature.
• Classify them into core concepts. The goal of this paper is not to decide which language is better than others. Rather, we are going to focus on the very concept which limits the power of the surface languages.
• Investigate mixtures of core concepts. The combination of multiple concepts would give better support.
• Build a link between product line analysis and the core concepts in a possible mixed way.
• Then, re-evaluate the previous work in the literature.

This work is close to work done by Don Batory in that they compared concrete programming lanauges. But, there is a bug difference ...

• what is required is to support adaptable components. adaptability of compilers.
• [need a way how a module is implemented as templates or may be parameterized so that they can be instantiated differently depending on the choice of value.]
• [For the language parameter of variation, different parsing modules may be needed depending on the language selected.]
• pure feature models are independent of any design or implementation model.
• PL - DSL - Model-driven (Code Generator)
• variability mechanism: for example, typical variability mechanisms in C/C++ source code files are pre-processor statements.

Survey

SPCL 2008

• Feature Relation and Dependency Management: An Aspect-Oriented Approach by Cho, Lee and Kang. To address code scattering problem that a variable feature is implemented across multiple components, this paper introduces aspect-oriented implementation patterns where effective mechanisms for crosscutting concerns are provided. It is based on the object-oriented patterns in [2] where feature dependency analysis was proposed.
• Applying Software Product Lines to Build Autonomic Pervasive Systems by Cetina, Fons, and Pelechano. In this paper, the variability model is prepared to be deployed by translating the model elements into the implementation code (via the code generation phase). More specifically, they used a DSL called Pervasive Modeling Language (PervML) proposed in [3] which is a UML-like modeling language. Then, the PervML specification is automatically translated into Java code. They defined the realization model which related features and the PervML elements with the default and alternative tags. Each generated code represents variations and they are stated on demand to build a pervasive system.
• Automatic Domain-Specific Modeling Languages for Generating Framework-Based Applications by Santos, Koskimies, and Lopes. In this paper, aspects are combined with frameworks to relieve domain engineers from developing code generators which map domain specific models into codes.
• Aspect-oriented Modeling for Variability Management by Noda and Kishi. They proposed the aspect-oriented modeling technique (similar to hyperslice) to model functionalities (aspect) and crosscutting relationships (aspect-relation-ruels) separately. There is a big gap between the concepts at the requirement level (such as features) and those at the implementation level (such as classes or aspects in programming languages). Product line architecture plays an important role in bridging this gap by deciding how features are modularized by means of architectural components.
• Building a Family of Compilers by Chae and Blume. They uses Standard ML to implement variations among components.

SPCL 2007

• Optimization of Variability in Software Product Lines by Felix Loesch and Robert Bosch GmbH. They present a new method to optimize the variability. They represent variability with preprocessor conditionals or conditional compilation. [In future work, we plan to extend our method for other variability mechanisms.]
• A Component Model supporting Decomposition and Composition of Consumer Electronics Software Product Lines by Chong-Mok Park, Seokjin Hong, Kyoung-Ho Son, and Jagun Kwon. They propose a component model in the context of software product lines. They used specification languages to define components and their interfaces and their compiler generates corresponding C header files. Variabilities are represented as source code fragments enclosed with pre-processor directives such as #ifdef/#else/#endif, pre-processor variables defined using #define statements, variables used in build scripts, etc. Their work is similar to Koala.
• Minimally Invasive Migration to Software Product Lines by Hans Peter Jepsen, Jan Gaardsted Dall, and Danilo Beuche. They report how to apply PLE into a frequency converter device domain. Thier configuration of the system is partially done by #define in header files and by inclusion of files into the build via makefile includes. They are considering pure::variants [6] in combination with a project planning tool as additionally required tools to be able to scale up platform development to more projects.
• A Case Study Implementing Features Using AspectJ by Christian Kastner, Sven Apel, and Don Batory. They evaluate the suitability of AspectJ to implement features. Then, they document where AspectJ is unsuitable for implementing features of refactored legacy applications and explain why. [We hope that our work, and confirmations of our results, can serve as a starting point to improve programming languages and support developers in selecting the right language for the right problem in SPL development.] [AspectJ may still be useful for implementing features in an SPL that was designed to be extensible, where extension points were anticipated or naming conventions could be used to exploit the strengths of AspectJ. This is a topic of future study.][read related work]
• Product Line Implementation using Aspect-Oriented and Model-Driven Software Development by Markus Voelter and Iris Groher. [This paper presents an approach that facilitates variability implementation, management and tracing by integrating model-driven and aspect-oriented software development.]
• Higher-Order Transformations for Product Lines by Jon Oldevik and Oystein Haugen. [The paper investigates the applicability of higher-order transformation for product line variability, using the MOFScript language. We devise an aspect-oriented extension to MOFScript that we call Hi-Transform. It is specifically contrasting in the usage of higher-order transformations as a variability mechanism. The ideas presented combine generative programming with aspects to provide variability in product line engineering.]
• A Variability Modeling Method for Adaptable Services in Service-Oriented Computing by Soo Ho Chang and Soo Dong Kim. They present a method to model service variability and design adaptable services. The variability model is represented on XML Scheme. (looks like just modeling)

SPLC 2006

• Service Grid Variability Realization by Jilles van Gurp and Juha Savolainen. [They have presented list of techniques and accompanying process intended for realizing variability in service oriented architectures.] They provide various techniques in the similar way of design pattern.

SPLC 2005

• The PLUSS Approach - Domain Modeling with Features, Use Cases and Use Case Realizations by Magnus Eriksson, Jürgen Börstler and Kjell Borg. They describe variants in Use Case Specifications.
• Feature-Oriented Re-engineering of Legacy Systems into Product Line Assets – a Case Study by Kyo Chul Kang, Moonzoo Kim, Jaejoon Lee and Byungkil Kim. They present their experience of re-engineering legacy home service robot applications into product line assets through feature modeling and analysis. They designed components with a macro-processing mechanism.
• Extracting and Evolving Mobile Games Product Lines by Vander Alves, Pedro Matos Jr., Leonardo Cole, Paulo Borba and Geber Ramalho. We present a method for creating and evolving product lines combining the reactive and extractive approaches, relying on AOP to modularize crosscutting concerns and to generalize the implementations of these concerns in order to increase code reuse.
• Comparison of System Family Modeling Approaches by Øystein Haugen, Birger Møller-Pedersen and Jon Oldevik. This paper illustrated three main approaches differentiated by the kind of language used to model the system family.
• Defining Domain-Specific Modeling Languages to Automate Product Derivation: Collected Experiences by Juha-Pekka Tolvanen and Steven Kelly. They examined approaches to identifying concepts for DSM languages, based on experiences collected from over 20 real-world cases. Typically, the variability space was captured in the language concepts, and the modelers’ role was to concentrate on the issues which differ between the products.
• Supporting Production Strategies as Refinements of the Production Process by Oscar Díaz, Salvador Trujillo and Felipe I. Anfurrutia. PL reinforces a separation of concerns between programming and assembling and this paper focused on the assembling process. Even further, it extends variability to the production process itself. [SPLs are complex systems, and SPL techniques should be used not only to manage the artifacts of the product itself, but also those artifacts that comprise the environment/framework where these products are built.]

SPLC 2004

• Automatic Generation of Program Families by Model Restrictions by Andrzej Węsowski. [We have presented a software development methodology for product families based on the automatic generation of restricted programs from the model of the most complex one. The methodology has been demonstrated for the language of statecharts using a combination of intuitions from program slicing and partial evaluation. The development of the single greatest model may not be feasible for them.]
• Dynamic Configuration of Software Product Lines in ArchJava by Sebastian Pavel, Jacques Noyé and Jean-Claude Royer. Our main contribution was to design and develop a pattern allowing the implementation of software components in ArchJava. When implementing componentbased applications, software architectures in ArchJava are much more explicit than architectures in a standard object-oriented language like Java.
• A Feature-Based Approach to Product Line Production Planning by Jaejoon Lee, Kyo C. Kang and Sajoong Kim. Techniques belonging to the former class should be able to control feature inclusion by including or excluding code segments or components from products: Code generation, preprocessing, macroprocessing.

SPLC 2003

• A Meta-model for Representing Variability in Product Family Development by Felix Bachmann, Michael Goedicke, Julio Leite, Robert Nord, Klaus Pohl, Balasubramaniam Ramesh and Alexander Vilbig. [Variability Management is seen as the key aspect that differentiates conventional software engineering and software product line engineering.] We argue for a uniform representation of variation across various activities where variability is introduced and exercised. [What about?]
• Managing Component Variability within Embedded Software Product Lines via Transformational Code Generation by Ian McRitchie, T. John Brown and Ivor T.A. Spence. [Any engineering methodology for software families must therefore provide mechanisms for managing variability through the design and implementation stages. Design strategies based upon modular decomposition mechanisms such as collaborations, [7] dimensions [8] and aspects [9] have emerged for managing concerns which crosscut a number of software modules.] The developed approach uses a combination of transformative generation and metaprogramming to manage component variability.
• A Koala-Based Approach for Modelling and Deploying Configurable Software Product Families by Timo Asikainen, Timo Soininen and Tomi Männistö. They proposed Koalish, which extends Koala, a component model and architecture description language, with explicit variation modelling mechanisms.
• Feature Binding Analysis for Product Line Component Development by Jaejoon Lee and Kyo C. Kang. ...macro...
• A Product Derivation Framework for Software Product Families by Sybren Deelstra, Marco Sinnema and Jan Bosch. We have presented a product derivation framework as basis for further discussion. [In the initial phase, two different approaches towards deriving the initial product configuration exist, i.e. assembly and configuration selection (see

also Figure 2)... We identify three types of assembly approaches including construction, generation and the combined one.]

SPLC 2002

• Representing Variability in Software Product Lines: A Case Study by Michel Jaring and Jan Bosch. In Rohill, products that are instantiated directly from the product line account for approximately 80 percent of the products shipped. Instantiation is based on a license 31 key (DLLs). The remaining products are customer specific (i.e., these products are adapted after instantiation). In general, makefiles account for approximately 5 percent and product specific code accounts for 15 percent of the variability supported in customer-specific products.
• Model-Driven Product Line Architectures by Dirk Muthig and Colin Atkinson. This paper tried to combine the concepts of product line and model-driven architectures. [Providing an effective representation of the variabilities in a product family is an important factor in successfully managing a product line infrastructure...Jacobson, Griss, and Jonsson define variation point in their book on software reuse as follows: “a variation point identifies one or more locations at which the variation will occur” [4].]
• Systematic Integration of Variability into Product Line Architecture Design by Steffen Thiel and Andreas Hein. [While, on the requirements level, the methods for analyzing product line variability are understood today, their transition to architecture remains vague.] This paper presents a systematic approach to integrate variability with product line architecture design.
• Adaptable Components for Software Product Line Engineering by T. John Brown, Ivor Spence, Peter Kilpatrick and Danny Crookes. The techniques we present allow the construction of large transparently adaptable components via composition and parameterization in C++ (and possibly Java). This paper has introduced a number of ideas which, when taken together, enable the construction of very adaptable software components: template patterns, skeleton object (a la higher order function), recursive argument lists (?)...
• Widening the Scope of Software Product Lines — From Variation to Composition by Rob van Ommering and Jan Bosch. [Most software product line research focuses on an early analysis of commonality and variation [1], followed by the creation of a variant-free architecture [25] with a sufficient number of variation points [13] to deal with diversity.] [Traditional product lines cover families in which products have many commonalities and few differences. This enables the creation of a variant-free architecture with variation points to implement the differences. The variation points typically control the internals of a component, but they may also control the presence or absence of certain components, the selection of a concrete component to implement an abstract component (a place holder), or even the binding between components.] [Figure 6 shows variation and composition as two independent dimensions. The variation axis is marked with ‘As is’ (no variation), parameterization, inheritance, and plug-ins as subsequently more advanced techniques of variation. The composition axis is marked with no composition (yet reuse), and composition.]
• Using a Marketing and Product Plan as a Key Driver for Product Line Asset Development by Kyo C. Kang, Patrick Donohoe, Eunman Koh, Jaejoon Lee and Kwanwoo Lee. Design objects are prepackaged into the SpeedController component, in

which features are used to parameterize the component; this component will be instantiated at product-build time for the selected feature using a macro-processing mechanism.

SPLC 2001

• Representing Product Family Architectures in an Extensible Architecture Description Language by Eric M. Dashofy and André van der Hoek. We introduce an extensible XML-based representation that is suitable as a basis for rapidly defining new representations for product family architectures.

SPLC 2000

• Domain-Oriented Engineering of Elevator Control Software: A Product Line Practice by Kwanwoo Lee, Kyo C. Kang, Eunman Koh, Wonsuk Chae, Bokyoung Kim, Byoung Wook Choi. In the component specification, a macro processing facility similar to [1] is used to parametrize the content of the component according to feature selection.
• Component-Based Product Line Development: The KobrA Approach by Colin Atkinson, Joachim Bayer, and Dirk Muthig. [They also have complementary strengths, since they address the problem of reuse at opposite ends of the granularity spectrum—product line development essentially supports "reuse in the large" while component based development supports "reuse in the small." This paper describes a method, KobrA, which cleanly integrates the two paradigms into a systematic, unified approach to software development and maintenance.]
• Object-Oriented Frameworks and Product Lines by Don Batory, Rich Cardone, and Yannis Smaragdakis. [The essence of our approach is understanding software in terms of object-oriented collaborations or refinements, and creating a parametric model of product-lines that is based on refinement/collaboration composition.] It covers many techniques to implement PLs.
• Implementing Product-Line Features by Composing Component Aspects by Martin L. Griss. In this paper we describe our work on agent-based product-line CBSE for flexible e-commerce systems. The essential idea is to directly implement a feature as a fragment of code (an aspect), and then use some mechanism or tool to combine these fragments into complete methods, classes or components.
• Aspect-Oriented Analysis for Product Line Architecture by Tomoji Kishi and Natsuko Noda. In this paper, we propose an aspect-oriented analysis method for PLA design in which we analyze product requirements from each aspect separately.

ETC

• Implementing product line variabilities by Critina Gacek and Michalis Anastasopoulos (Symposium on Software Reusability, SSR 2001). They introduce the framework for comparison of implementation approaches. They present comparison matrix which ranks each implementation techniques (aggregation, AOP, conditional compilation, dynamic class loading, parameterization and so on) according to the feature properties (mandatory, optional or alternative). However, their code examples still remain conceptual level and only report the "possibilities" of their use in product line implementation. Moreover, they fail to explicitly address architectural issues.
• Variability in Evolving Software Product Lines by Mikael Svahnberg. They discuss about interesting connection between variation and evolution. [hopefully see it soon]
• Managing variability in software architecture by Felix Bachmann and Len Bass (SSR 2001). They specifically discuss design and realization of variability in software architectures. Interestingly, they also pointed out that variations can be either optional or alternative. However, they did not investigate how to implement such architectural variations at the code level. Their suggestion only mention adopting of generators or configuration systems to realize variations.
• Code Generation to Support Static and Dynamic Composition of Software Product Lines by Marko Rosenm¨uller, Norbert Siegmund, Gunter Saake and Sven Apel. [In this paper, we present an approach that employs code generation to support static and dynamic composition of features of a single code base. We offer an implementation on top of FeatureC++, an extension of the C++ programming language that supports software composition based on features.]
• Separation of concerns in software product line engineering by Mazen Saleh and Hassan Gomaa. This paper provides a systematic approach for modularizing crosscutting concerns. Optional and alternative source code is grouped by feature in a variable source code file, which corresponds to an aspect file. [The code weaver reads the features selected for the application from the customization file, and then integrates the selected feature source code from the variable source code file with the kernel source code.]
• When less is more: implementing optional features by John M. Hunt and John D. McGregor. [In this paper we consider how to implement features in a product context using a variety of techniques (inheritance, abstraction(i.e., java interface) and parameterization) and present an analysis of the tradeoffs involved in providing optional features.][If the need for the optional feature is known when the client is being coded, using an XVCL frame for the optional feature provides the best way to cleanly exclude the feature without a runtime penalty.][However, aspects require that the existing code provide a suitable hook for the optional feature.][Our contribution is an investigation of approaches to the implementation of an optional feature in a product context using a variety of techniques and an analysis of the tradeoffs involved.] Their work remains at the code level which should be dealt at the level of architecture mainly because they use Java which does not distinguish between architecture and function.

Reference

[1] Matthias Blume, Umut Acar, and Wonseok Chae. Exception handlers as extensible cases, 6th ASIAN Symposium on Programming Languages and Systems (APLAS 2008), Dec 9-11, 2008.

[2] Kwanwoo Lee and Kyo C. Kang. Feature Dependency Analysis for Product Line Component Design, Proceedings of the 8th International Conference Software Reuse (ICSR8), 2004.

[3] Javier Mu˜noz, Vicente Pelechano, Carlos Cetina. Implementing a Pervasive Meeting Room: A Model Driven Approach.