Results 1 -
7 of
7
Granularity in software product lines
, 2008
"... Building software product lines (SPLs) with features is a challenging task. Many SPL implementations support features with coarse granularity – e.g., the ability to add and wrap entire methods. However, fine-grained extensions, like adding a statement in the middle of a method, either require intric ..."
Abstract
-
Cited by 131 (48 self)
- Add to MetaCart
Building software product lines (SPLs) with features is a challenging task. Many SPL implementations support features with coarse granularity – e.g., the ability to add and wrap entire methods. However, fine-grained extensions, like adding a statement in the middle of a method, either require intricate workarounds or obfuscate the base code with annotations. Though many SPLs can and have been implemented with the coarse granularity of existing approaches, fine-grained extensions are essential when extracting features from legacy applications. Furthermore, also some existing SPLs could benefit from fine-grained extensions to reduce code replication or improve readability. In this paper, we analyze the effects of feature granularity in SPLs and present a tool, called Colored IDE (CIDE), that allows features to implement coarse-grained and fine-grained extensions in a concise way. In two case studies, we show how CIDE simplifies SPL development compared to traditional approaches.
Integrating Compositional and Annotative Approaches for Product Line Engineering
"... Software product lines can be implemented with many different approaches. However, there are common underlying mechanisms which allow a classification into compositional and annotative approaches. While research focuses mainly on composition approaches like aspect- or feature-oriented programming be ..."
Abstract
-
Cited by 18 (9 self)
- Add to MetaCart
(Show Context)
Software product lines can be implemented with many different approaches. However, there are common underlying mechanisms which allow a classification into compositional and annotative approaches. While research focuses mainly on composition approaches like aspect- or feature-oriented programming because those support feature traceability and modularity, in practice annotative approaches like preprocessors are common as they are easier to adopt. In this paper, we compare both groups of approaches and find complementary strengths. We propose an integration of compositional and annotative approaches to combine advantages, increase flexibility for the developer, and ease adoption. 1.
Language-Independent Safe Decomposition of Legacy Applications into Features
"... Software product lines (SPL) usually consist of code and non-code artifacts written in different languages. Often they are created by decomposing legacy applications into features. To handle different artifacts uniformly (code, documentation, models, etc.), current SPL technologies either use an app ..."
Abstract
-
Cited by 7 (6 self)
- Add to MetaCart
Software product lines (SPL) usually consist of code and non-code artifacts written in different languages. Often they are created by decomposing legacy applications into features. To handle different artifacts uniformly (code, documentation, models, etc.), current SPL technologies either use an approach that is so general that it works on character or token level, but can easily introduce subtle errors; or they provide specialized tools for a low number of languages. Syntax errors that only occur in certain variants are difficult to detect, as the exploding number of variants makes a manual testing unfeasible. In this paper, we present CIDE, an generic SPL tool that can ensure syntactic correctness for all variants. We show CIDE’s underlying mechanism that abstracts from textual representation and generalize it from
Evolution of legacy system comprehensibility through automated refactoring
- In Proc. Int’l Workshop on Machine Learning Technologies in Software Engineering
, 2011
"... Software engineering is a continually evolving discipline, wherein researchers and members of industry are working towards defining and refining what are known as “best practices. ” Best practices are the set of known correct engineering techniques that lead to quality software. When a software arti ..."
Abstract
-
Cited by 3 (0 self)
- Add to MetaCart
Software engineering is a continually evolving discipline, wherein researchers and members of industry are working towards defining and refining what are known as “best practices. ” Best practices are the set of known correct engineering techniques that lead to quality software. When a software artifact is produced, it becomes temporally locked into a single instantiation of these best practices at a given point in time. If such software is not maintained in such a way as to keep it current with the evolution of practice, then there is a good chance that subsequent engineers may not understand the design choices made. There are known techniques, called refactorings, which allow for structural changes to software without altering the outward appearance and behavior, thus maintaining the intent of the original design. Unfortunately, refactoring requires an engineer to both understand the techniques to be applied and the code to which they are applied to. This is not always feasible. We have developed an automated system utilizing Evolutionary Algorithms to manipulate refactorings correctly without requiring an underlying understanding of the software. This then allows for sustained levels of quality of evolving software systems. The understandability, maintainability, and reusability of the software regenerate as best practices evolve.
Taming Multi-core Parallelism with Concurrent Mixin Layers
"... Abstract The recent shift in computer system design to multi-core technology requires that the developer leverage explicit parallel programming techniques in order to utilize available performance. Nevertheless, developing the requisite parallel applications remains a prohibitively-difficult undert ..."
Abstract
- Add to MetaCart
Abstract The recent shift in computer system design to multi-core technology requires that the developer leverage explicit parallel programming techniques in order to utilize available performance. Nevertheless, developing the requisite parallel applications remains a prohibitively-difficult undertaking, particularly for the general programmer. To mitigate many of the challenges in creating concurrent software, this paper introduces a new parallel programming methodology that leverages feature-oriented programming (FOP) to logically decompose a product line architecture (PLA) into concurrent execution units. In addition, our efficient implementation of this methodology, that we call concurrent mixin layers, uses a layered architecture to facilitate the development of parallel applications. To validate our methodology and accompanying implementation, we present a case study of a product line of multimedia applications deployed within a typical multi-core environment. Our performance results demonstrate that a product line can be effectively transformed into parallel applications capable of utilizing multiple cores, thus improving performance. Furthermore, concurrent mixin layers significantly reduces the complexity of parallel programming by eliminating the need for the programmer to introduce explicit low-level concurrency control. Our initial experience gives us reason to believe that concurrent mixin layers is a promising technique for taming parallelism in multi-core environments.
Dekanat An Algebra for Refactoring and Feature-Oriented Programming
"... Abstract. A software product line (SPL) is a set of programs that share features (i.e., user-visible program characteristics) and that differ in features. SPLs are commonly developed by reusing code from a shared code base. The code base of an SPL as well as the individual products are target of ref ..."
Abstract
- Add to MetaCart
(Show Context)
Abstract. A software product line (SPL) is a set of programs that share features (i.e., user-visible program characteristics) and that differ in features. SPLs are commonly developed by reusing code from a shared code base. The code base of an SPL as well as the individual products are target of refactoring to maintain them or to integrate them with other programs. To develop proper refactoring tools, we must formalize the challenges faced and must distinguish stand-alone-program refactoring from SPL refactoring. We clarify the relationship between refactoring and SPLs, develop a formal, algebraic model of refactorings and SPLimplementation techniques, and prove important properties for the algebraic structure of refactorings in this setting. Developers of future refactoring tools of SPLs can now tackle the challenges in their tools one by one. 1