Project Prototypes
Berkeley DB Refactoring
Instead of beginning from scratch, one can refactor existing data management systems, e.g., using FOP. When starting with existing, tested, and optimized data management systems and incrementally detaching features to introduce variability this results in a stripped-down version that contains only the core functionality. Additional features can be added when required for a certain use case.
In the FAME-DBMS project, we chose this approach to compare downsized versions with the original application which makes it useful as a research benchmark. In a non-trivial case study we refactored the C version of the embedded database engine Berkeley DB into features. The footprint of Berkeley DB is fairly small (484 KB) and there are already a few static configuration options available. Even though, it is still too large for deeply embedded devices and contains several features like TRANSACTIONS that might not be required in all use cases. Therefore, we transformed the Berkeley DB code from C to C++ and then refactored it into features using FeatureC++. We used behavior preserving refactorings to maintain performance and to avoid errors. Our case study has shown that the transformation from C to FeatureC++ (1) has no negative impact on performance or resource consumption, (2) successfully increases customizability (24 optional features) so that we are able to create far more variants that are specifically tailored to a use case, and (3) successfully decreases binary size by removing unneeded functionality to satisfy the tight memory limitations of small embedded systems. The picture depicts the refactored version of Berkeley DB.
FAME-DBMS Prototype
The first self-made prototype of FAME-DBMS is developed by the experience of the decomposition of Berkeley DB and a prototypical Storage Manager product line. The feature model displays only some configurable parts of the whole DBMS. The gray features are not further expanded features, empty circles represent optional features while filled circles represent mandatory ones.
The minimal version of this product line has a binary code size of 10KB which enables the usage in deeply embedded systems, e.g., SmartCards. Therefore, we support a very fine granularity of features and variability that are required in such constraint environments. DBMS functionality, e.g., Transaction Management, that is only relavant in medium constrained systems like PDAs and Cellphones, has only a rudimental decomposition and variability. This is reasoned by a performance overhead and interaction complexity for fine granular features. Thus, one key challenge for the development of a DBMS software product line is the choice of the granularity of features to be implemented.
Scenario
We chose a demonstration scenario of a sensor network for FAME-DBMS project. Sensor nodes measure values for temperature, air presure, and luminance in a biological environment. This helps to observate the coniditions of the growth of different plants. In addition, a biological scientist adds data about the plants into a PDA.
Information is retrieved from the network via an access point and transfered to the PDA. The whole data is stored inside a server system for further analysis. In every embedded system of this scenario the FAME-DBMS is used to store and retrieve the data. The DBMS server can also be based on an extended version of FAME-DBMS which is not yet implemented.
The embedded system BTNode is used as the access point for the sensor network because of the ability to send radio signals to the sensor nodes and to communicate via Bluetooth to the PDA.