• Keine Ergebnisse gefunden

Refactoring delta-oriented software product lines

N/A
N/A
Protected

Academic year: 2022

Aktie "Refactoring delta-oriented software product lines"

Copied!
1
0
0

Wird geladen.... (Jetzt Volltext ansehen)

Volltext

(1)

Refactoring Delta-Oriented Software Product Lines

Sandro Schulze, Ina Schaefer

Institute for Software Engineering and Automotive Informatics TU Braunschweig

M¨uhlenpfordtstraße 23, 38106 Braunschweig {sanschul,i.schaefer}@tu-bs.de

Abstract: SPLs evolve over time due to new or changed requirements and need to be maintained to retain their value. To this end,refactoringshave been proposed to improve the design and structure of (object-oriented) software systems. Unfortunately, traditional refactorings are not applicable offhand to SPLs, because these refactorings do not take program variability into account as first class program entities. However, recent work has shown that variability constitutes an entirely new problem dimension for refactoring and, thus, must be explicitly addressed. Hence, applying refactoring to implementation artifacts of evolving SPLs must be part of domain engineering and thus, automatically applicable to all possible program variants. In our AOSD’13 pa- per, we address refactoring of software product lines by presenting a catalogue and im- plementation of refactorings for delta-oriented SPLs. Additionally, we proposecode smellsto guide developers to potential refactoring opportunities. We show how code smells can aid the identification of SPL refactorings and how these refactorings im- prove the evolvability and maintainability of delta-oriented SPLs. Particularly, our refactorings ensure behavior preservation for all variants of the SPL (except for evolu- tionary refactorings). While tailored to a particular variability mechanism, our refac- torings and code smells can be adopted for other mechanisms as well.

82

Referenzen

ÄHNLICHE DOKUMENTE

In previous work, we proposed delta-oriented test case prioritization for incre- mental SPL integration testing, where differences between architecture test model variants allow

To determine to what extent code clones exist in feature-oriented product lines, we conducted an analysis on ten different feature- oriented SPLs.. In this section we describe

Example: In our example in Figure 6, we have to move the field undoStore from feature Undo to feature Peak, be- cause the method that uses the field is moved as well (using the

In the industrial practice of evolving an SPL, it is common that evolution is performed on both levels, which may af- fect the same artifacts (e.g., code, models) in different ways

But, we found some approaches that actually propose product-based analyses and do not discuss how to deal with many products; these approaches apply type checking [16], model

 -oriented programming solves the feature traceability problem via collaborations and rolls (mapping). Implementation via

 If the base code changes, existing pointcuts could match to new join points or existing join points will not match anymore.  Chess example: A developer adds a method to declare a

However, to actually measure the effect of input data on non-functional properties the measurement environment has to be extended so that it generates test data according to