Results 1 - 10
of
16
An Algebra for Feature-Oriented Software Development
"... Feature-Oriented Software Development (FOSD) provides a multitude of formalisms, methods, languages, and tools for building variable, customizable, and extensible software. Along different lines of research different ideas of what a feature is have been developed. Although the existing approaches h ..."
Abstract
-
Cited by 126 (48 self)
- Add to MetaCart
(Show Context)
Feature-Oriented Software Development (FOSD) provides a multitude of formalisms, methods, languages, and tools for building variable, customizable, and extensible software. Along different lines of research different ideas of what a feature is have been developed. Although the existing approaches have similar goals, their representations and formalizations have not been integrated so far into a common framework. We present a feature algebra as a foundation of FOSD. The algebra captures the key ideas and provides a common ground for current and future research in this field, in which also alternative options can be explored.
FeatureHouse: Language-independent, automatic software composition
- In Proc. Int’l Conf. on Software Engineering
"... Superimposition is a composition technique that has been applied successfully in many areas of software development. Although superimposition is a general-purpose concept, it has been (re)invented and implemented individually for various kinds of software artifacts. We unify languages and tools that ..."
Abstract
-
Cited by 96 (46 self)
- Add to MetaCart
Superimposition is a composition technique that has been applied successfully in many areas of software development. Although superimposition is a general-purpose concept, it has been (re)invented and implemented individually for various kinds of software artifacts. We unify languages and tools that rely on superimposition by using the language-independent model of feature structure trees (FSTs). On the basis of the FST model, we propose a general approach to the composition of software artifacts written in different languages, Furthermore, we offer a supporting framework and tool chain, called FEATUREHOUSE. We use attribute grammars to automate the integration of additional languages, in particular, we have integrated Java, C#, C, Haskell, JavaCC, and XML. Several case studies demonstrate the practicality and scalability of our approach and reveal insights into the properties a language must have in order to be ready for superimposition. 1.
An Analysis of the Variability in Forty Preprocessor-Based Software Product Lines
- ICSE'10
, 2010
"... Over 30 years ago, the preprocessor cpp was developed to extend the programming language C by lightweight metaprogramming capabilities. Despite its error-proneness and low abstraction level, the preprocessor is still widely used in present-day software projects to implement variable software. Howeve ..."
Abstract
-
Cited by 43 (17 self)
- Add to MetaCart
(Show Context)
Over 30 years ago, the preprocessor cpp was developed to extend the programming language C by lightweight metaprogramming capabilities. Despite its error-proneness and low abstraction level, the preprocessor is still widely used in present-day software projects to implement variable software. However, not much is known about how cpp is employed to implement variability. To address this issue, we have analyzed forty open-source software projects written in C. Specifically, we answer the following questions: How does program size influence variability? How complex are extensions made via cpp’s variability mechanisms? At which level of granularity are extensions applied? Which types of extension occur? These questions revive earlier discussions on program comprehension and refactoring in the context of the preprocessor. To provide answers, we introduce several metrics measuring the variability, complexity, granularity, and types of extension applied by preprocessor directives. Based on the collected data, we suggest alternative implementation techniques. Our data set is a rich source for rethinking language design and tool support.
Types and Modularity for Implicit Invocation with Implicit Announcement
- ACM TRANSACTIONS ON SOFTWARE ENGINEERING AND METHODOLOGY (TOSEM
, 2009
"... Through implicit invocation, procedures are called without explicitly referencing them. Implicit announcement adds to this implicitness by not only keeping implicit which procedures are called, but also where or when — under implicit invocation with implicit announcement, the call site contains no s ..."
Abstract
-
Cited by 29 (4 self)
- Add to MetaCart
Through implicit invocation, procedures are called without explicitly referencing them. Implicit announcement adds to this implicitness by not only keeping implicit which procedures are called, but also where or when — under implicit invocation with implicit announcement, the call site contains no signs of that, or what it calls. Recently, aspect-oriented programming has popularized implicit invocation with implicit announcement as a possibility to separate concerns that lead to interwoven code if conventional programming techniques are used. However, as has been noted elsewhere, as currently implemented it establishes strong implicit dependencies between components, hampering independent software development and evolution. To address this problem, we present a type-based modularization of implicit invocation with implicit announcement that is inspired by how interfaces and exceptions are realized in JAVA. By extending an existing compiler and by rewriting several programs to make use of our proposed language constructs, we found that the imposed declaration clutter tends to be moderate; in particular, we found that for general applications of implicit invocation with implicit announcement, fears that programs utilizing our form of modularization become unreasonably verbose are unjustified.
A Model of Refactoring Physically and Virtually Separated Features
"... Physical separation with class refinements and method refinements à la AHEAD and virtual separation using annotations à la #ifdef or CIDE are two competing implementation approaches for software product lines with complementary advantages. Although both approaches have been mainly discussed in isola ..."
Abstract
-
Cited by 28 (21 self)
- Add to MetaCart
(Show Context)
Physical separation with class refinements and method refinements à la AHEAD and virtual separation using annotations à la #ifdef or CIDE are two competing implementation approaches for software product lines with complementary advantages. Although both approaches have been mainly discussed in isolation, we strive for an integration to leverage the respective advantages. In this paper, we lay the foundation for such an integration by providing a model that supports both physical and virtual separation and by describing refactorings in both directions. We prove the refactorings complete, so every virtually separated product line can be automatically transformed into a physically separated one (replacing annotations by refinements) and vice versa. To demonstrate the feasibility of our approach, we have implemented the refactorings in our tool CIDE and conducted four case studies.
Feature (De)composition in Functional Programming
- Department of Informatics and Mathematics, University of Passau
, 2009
"... Abstract. The separation of concerns is a fundamental principle in software engineering. Crosscutting concerns are concerns that do not align with hierarchical and block decomposition supported by mainstream programming languages. In the past, crosscutting concerns have been studied mainly in the co ..."
Abstract
-
Cited by 13 (9 self)
- Add to MetaCart
(Show Context)
Abstract. The separation of concerns is a fundamental principle in software engineering. Crosscutting concerns are concerns that do not align with hierarchical and block decomposition supported by mainstream programming languages. In the past, crosscutting concerns have been studied mainly in the context of object orientation. Feature orientation is a novel programming paradigm that supports the (de)composition of crosscutting concerns in a system with a hierarchical block structure. In two case studies we explore the problem of crosscutting concerns in functional programming and propose two solutions based on feature orientation. 1
Using modularity metrics to assist move method refactoring of large systems
- in 2013 7th International Conference on Complex, Intelligent, and Software Intensive Systems (CISIS). IEEE
"... title={Using Modularity Metrics to assist Move Method Refactoring of Large Systems}, year={2013}, pages={529-534}, publisher={IEEE}, doi={10.1109/CISIS.2013.96}, ..."
Abstract
-
Cited by 5 (4 self)
- Add to MetaCart
title={Using Modularity Metrics to assist Move Method Refactoring of Large Systems}, year={2013}, pages={529-534}, publisher={IEEE}, doi={10.1109/CISIS.2013.96},
Language-Independent Quantification and Weaving for Feature Composition
"... Based on a general model of feature composition, we present a composition language that enables programmers by means of quantification and weaving to formulate extensions to programs written in different languages. We explore the design space of composition languages that rely on quantification and ..."
Abstract
-
Cited by 4 (4 self)
- Add to MetaCart
(Show Context)
Based on a general model of feature composition, we present a composition language that enables programmers by means of quantification and weaving to formulate extensions to programs written in different languages. We explore the design space of composition languages that rely on quantification and weaving and discuss our choices. We outline a tool that extends an existing infrastructure for feature composition and discuss results of three initial case studies. We found that, due to its language independence, our approach is less powerful than aspect-oriented languages but still usable for many implementation problems.
Traon. Inquiring the usage of aspect-oriented programming: an empirical study
- In ICSM ’09: Proceedings of the 25 th International Conference on Software Maintenance
, 2009
"... Back in 2001, the MIT announced aspect-oriented programming as a key technology in the next 10 years. Nowadays, 8 years later, AOP is not widely adopted. Several reasons can explain this distrust in front of AOP, and one of them is the lack of robust tools for analysis, testing and maintenance. In o ..."
Abstract
-
Cited by 3 (2 self)
- Add to MetaCart
(Show Context)
Back in 2001, the MIT announced aspect-oriented programming as a key technology in the next 10 years. Nowadays, 8 years later, AOP is not widely adopted. Several reasons can explain this distrust in front of AOP, and one of them is the lack of robust tools for analysis, testing and maintenance. In order to develop dedicated solutions for assisting the development with AOP, and increase its adoption, we need to understand how it is actually used. In this paper we analyze 38 aspect-oriented open source projects with respect to the impact of aspects on the projects, and to coverage of the language features. This reveals that AOP is currently used in a cautious way. This work is a first step to built support and development tools dedicated to actual practices for AOP, based on empirical usage profiles. 1.
Code Clones in Feature-Oriented Software Product Lines
"... Some limitations of object-oriented mechanisms are known to cause code clones (e.g., extension using inheritance). Novel programming paradigms such as feature-oriented programming (FOP) aim at alleviating these limitations. However, it is an open issue whether FOP is really able to avoid code clones ..."
Abstract
-
Cited by 2 (1 self)
- Add to MetaCart
(Show Context)
Some limitations of object-oriented mechanisms are known to cause code clones (e.g., extension using inheritance). Novel programming paradigms such as feature-oriented programming (FOP) aim at alleviating these limitations. However, it is an open issue whether FOP is really able to avoid code clones or whether it even facilitates (FOP-related) clones. To address this issue, we conduct an empirical analysis on ten feature-oriented software product lines with respect to code cloning. We found that there is a considerable amount of clones in feature-oriented software product lines and that a large fraction of these clones is FOP-related (i.e., caused by limitations of feature-oriented mechanisms). Based on our results, we initiate a discussion on the reasons for FOP-related clones and on how to cope with them. We exemplary show how such clones can be removed by the application of refactoring.
