1Marko Rosenmüller - University of Magdeburg, Germany

Feature-oriented Refactoring ofBerkeley DB

Dagstuhl Seminar on Software Engineering for Tailor-made DatamangementJuli 7th, 2008

2Marko Rosenmüller - University of Magdeburg, Germany

Outline

• Data Management for Embedded Systems

• Feature-oriented Programming

• Berkeley DB Refactoring

• Evaluation

3Marko Rosenmüller - University of Magdeburg, Germany

Data Management for Embedded Systems

• Diverse hardware and application scenarios

• Restricted resources – Memory,

– Performance,

– Power consumption

• Recurring functionality

• Results in redevelopment of data management functionality

• Tailor-made solutions to avoid functional overhead Software Product Lines

4Marko Rosenmüller - University of Magdeburg, Germany

Berkeley DB

• Embedded DBMS– Embedded into application; used via API

– Binary size of 480 – 680 KB

• Static activation / deactivation of 11 features using #ifdef– indexes,

– replication,

– encryption,

– etc.

5Marko Rosenmüller - University of Magdeburg, Germany

Berkeley DB Source Code

• C language and #ifdef– Often used in embedded

domain

• Missing separation of concerns

• High development effort and maintenance costs

• Nested preprocessorstatements

6Marko Rosenmüller - University of Magdeburg, Germany

Components

• Why not use components for embedded systems?– Too much overhead

– Small components needed but decreasing performance and increasing memory usage for smaller components

– Inability to modularize crosscutting concerns

– Additional development effort to implement components

7Marko Rosenmüller - University of Magdeburg, Germany

Software Product Lines – New Paradigms

• New programming paradigms to implement product lines:– Aspect-oriented programming (AOP) and

– Feature-oriented programming (FOP)

Decomposition of DBMS with respect to featuresModularization of crosscutting concernsGenerate customized / downsized DBMS

8Marko Rosenmüller - University of Magdeburg, Germany

Feature-oriented Programming

• Decomposition of OOP classes into base classes and refinements

• Refinements implement class extensions needed for a feature

• Composition of classes according to feature selection

9Marko Rosenmüller - University of Magdeburg, Germany

FeatureC++

• FOP for C++ and thus embedded domain

• Integration of AOP (AspectC++)

• Modularization of crosscutting features

• Based on code transformation to C++

• Resource consumption?– Important in embedded domain

– C++ vs. C. What abut FeatureC++?

– Static optimizations to avoid any overhead

– Support for low-level languages (assembler)

Evaluation using Berkeley DB

10Marko Rosenmüller - University of Magdeburg, Germany

Berkeley DB – Refactoring

• Decomposition of Berkeley DB according to features– Transformation from C code into FeatureC++ code– Further extraction of features

• 35 features, 24 optional

• 400,000 different variants possible

Mandatory

Optional

Alternative

OR

11Marko Rosenmüller - University of Magdeburg, Germany

Berkeley DB – Binary Size and Performance

• Binary size compared to original version

• Performance comparison (Oracle reading benchmark)

No negative impact of FOP

Functional overhead • increases binary size and • decreases performance

0

0,5

1

1,5

2

2,5

1 2 3 4 5 6 7

Configuration

Mio

. q

ue

rie

s /

s

C

FeatureC++

Marko Rosenmüller - University of Magdeburg, Germany

12Marko Rosenmüller - University of Magdeburg, Germany

Berkeley DB – Refactored Source Code

• Separated / modularized features– Feature not entangled– Smaller methods / classes due to separated feature code– Less source code needed to understand functionality

13Marko Rosenmüller - University of Magdeburg, Germany

Problems Observed

• High effort to refactor into a large number of features

• Feature interactions– Can be modularized but even higher effort

• Problems with fine-grained refactorings– Extensions of method signatures

– Small parts of methods (e.g., single statements)

• Mixed granularity to reduce development effort– Fine granularity for features used in DBMS for very small

systems

– Larger extension features used in bigger systems

14Marko Rosenmüller - University of Magdeburg, Germany

Summary

• FOP applicable to embedded systems– modularization of crosscutting concerns

– No negative impact on resource consumption or performance

• Separation into base code and extending features may reduce complexity to understand source code

• Tradeoff between granularity and development effort

• Design for extensibility needed (FAME-DB)