Marko Rosenmüller - University of Magdeburg, Germany 1 Feature-oriented Refactoring of Berkeley DB Dagstuhl Seminar on Software Engineering for Tailor-made Datamangement Juli 7th, 2008

Marko Rosenmüller - University of Magdeburg, Germany 2 Outline Data Management for Embedded Systems Feature-oriented Programming Berkeley DB Refactoring Evaluation

Marko Rosenmüller - University of Magdeburg, Germany 3 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

Marko Rosenmüller - University of Magdeburg, Germany 4 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.

Marko Rosenmüller - University of Magdeburg, Germany 5 Berkeley DB Source Code C language and #ifdef –Often used in embedded domain Missing separation of concerns High development effort and maintenance costs Nested preprocessor statements

Marko Rosenmüller - University of Magdeburg, Germany 6 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

Marko Rosenmüller - University of Magdeburg, Germany 7 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 features  Modularization of crosscutting concerns  Generate customized / downsized DBMS

Marko Rosenmüller - University of Magdeburg, Germany 8 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

Marko Rosenmüller - University of Magdeburg, Germany 9 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

Marko Rosenmüller - University of Magdeburg, Germany 10 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

Marko Rosenmüller - University of Magdeburg, Germany 11 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 Marko Rosenmüller - University of Magdeburg, Germany

12 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

Marko Rosenmüller - University of Magdeburg, Germany 13 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

Marko Rosenmüller - University of Magdeburg, Germany 14 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)