Improving Alignment of Crosscutting Features with Code in Product Line Engineering.

Hundt, Christine; Mehner, Katharina; Pfeiffer, Carsten; Sokenou, Dehla

doi:10.5381/jot.2007.6.9.a21

Cited by 6 publications

(2 citation statements)

References 13 publications

(12 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The interface represents which classes are commonly available in the feature group. This inheritance mechanism is not novel; it is provided by Caesar [24,25], CaesarJ [4], and Object Teams [14,16]. However, they are not studied in the context of modularity of feature modules [20,29]; this paper focuses on how to use this inheritance mechanism to efficiently implement derivatives.…”

Section: Implementing Feature Interactions In Featuregluonjmentioning

confidence: 99%

Implementing Feature Interactions with Generic Feature Modules

Takeyama

Chiba

2013

Software Composition

View full text Add to dashboard Cite

Abstract. The optional feature problem in feature-oriented programming is that implementing the interaction among features is difficult. Either of the modules for the interacting features cannot contain the code for the interaction if those features are optional. A modular approach for implementing such interaction is separating it into a module called derivative. However, as the number of derivatives increases, it does not scale. This paper shows how derivatives for combinations of features from each group are efficiently implemented. A group of features are implemented by using the inheritance of feature modules. A super feature module works as a common interface to members of that group. It thereby allows to describe a generic derivative applicable for the groups. This paper also presents a feature-oriented programming language, FeatureGluonJ, which provides language constructs for this approach. Feature-Oriented ProgrammingFeature-oriented programming (FOP) [26] is a programming paradigm where source code is decomposed for each feature. Although it was originally an approach for implementing similar classes, it now refers to an approach for implementing similar software products; such a family of products is called a software product line (SPL). This allows developers by just selecting the features for that necessary product.In FOP, the code for each feature is separately described in a module called a feature module. A feature module is a collaboration of the classes needed for the feature and/or extensions to the classes belonging to other features. The extensions can be aspects in AspectJ; advices can attach code for the feature to existing code; inter-type declarations can add new fields to an existing class. Several product lines such as the feature-oriented version of Berkeley DB [18] and MobileMedia [30] not contain the code for the interaction since the code must be effective only when those interacting features are selected. Although a possible approach is separating such code into independent modules called derivatives [21,22], the number of derivatives tends to be large as the numbers of features increases. This paper proposes a design principle to reduce the effort in implementing derivatives. A group of features are implemented by inheriting their common super feature module. This module works as an interface common to its subfeatures and allows implementing a derivative in a reusable manner for every combination of sub-features. To demonstrate this principle, we developed a new FOP language, FeatureGluonJ, which provides a language construct called a generic feature module for reusable implementation of derivative as well as a feature-oriented module system supporting inheritance. The Optional Feature ProblemThis section explains a difficulty in feature-oriented decomposition known as the optional feature problem [21,22]. We can see this problem in the MobileMedia SPL. MobileMedia is a family of multimedia-management application for mobile devices and widely used in the research community of...

show abstract

Section: Implementing Feature Interactions In Featuregluonjmentioning

confidence: 99%

Implementing Feature Interactions with Generic Feature Modules

Takeyama

Chiba

2013

Software Composition

View full text Add to dashboard Cite

show abstract

“…For example, CaesarJ [8] supports static composition based on virtual classes and dynamic deployment of aspects. Object Teams support dynamic binding of teams, which can be used to represent features of an SPL [22]. Furthermore, activation teams are statically instantiated.…”

Section: Related Workmentioning

confidence: 99%

Flexible feature binding in software product lines

et al. 2011

View full text Add to dashboard Cite

A software product line (SPL) is a family of programs that share assets from a common code base. The programs of an SPL can be distinguished in terms of features, which represent units of program functionality that satisfy stakeholders' requirements. The features of an SPL can be bound either statically at program compile time or dynamically at run time. Both binding times are used in SPL development and have different advantages. For example, dynamic binding provides high flexibility whereas static binding supports finegrained customizability without any impact on performance (e.g., for use on embedded systems). However, contemporary techniques for implementing SPLs force a programmer to choose the binding time already when designing an SPL and to mix different implementation techniques when multiple binding times are needed. We present an approach that integrates static and dynamic feature binding seamlessly. It allows a programmer to implement an SPL once and to decide per feature at deployment time whether it should be bound statically or dynamically. Dynamic binding usually introduces an overhead regarding resource consumption and performance. We reduce this overhead by statically merging features that are used together into dynamic binding units. A program can be configured at run time by composing binding units on demand. We use feature models to ensure that only valid feature combinations can be selected at compile and at run time. We provide a compiler and evaluate our approach on the basis of two non-trivial SPLs.

show abstract