View
214
Download
0
Category
Tags:
Preview:
Citation preview
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)
Recommended