160 likes | 239 Views
This study introduces a dynamic analysis method to identify variation points in source code, crucial for product lines with multiple versions. The method involves code instrumentation at the method level using aspect-oriented programming, aiming to invoke specific features. By comparing traces generated by different versions and visualizing variation points, the algorithm detects divergent behaviors effectively. Preliminary results on Pacman game variations show the potential for quick merges and insights into source code. Future work includes parameter optimization, enhanced accuracy, and visualization for larger software systems.
E N D
Identification of Variation Points Using Dynamic Analysis Bas Cornelissen
Introduction • Product lines • Several versions for various customers • Each having its own set of features • Variation points • Configurable features
Introduction • Identifying variation points in source code • Isolation of code responsible for specific features • Useful in merging product line members • Research proposal • Dynamic analysis • Comparison of traces generated by two versions • Detection and visualization of variation points
Method • Code instrumentation • At method level • Aspect-oriented programming • Execution using similar scenarios • Aimed at invoking one particular feature
Method • Detection algorithm • Sliding windows • Parameters • Checksum size • Minimum branch length • Maximum branch length • Visualization • Dot
Method • Running example • Pacman • 20 classes, 1000 LOC • Various versions • Original (reference) • Map extension • Additional game entities, e.g. holes
Preliminary results • Original vs. map version
Preliminary results • Original vs. map version • Slightly different initialization • One fork…
Preliminary results • Original vs. map version • Slightly different initialization • One fork… • …and a quick merge
Preliminary results • Original vs. hole version
Preliminary results • Original vs. hole version • Slightly different initialization: a fork …
Preliminary results • Original vs. hole version • Slightly different initialization: a fork … …and a quick merge
Preliminary results • Original vs. hole version • Slightly different initialization: a fork … …and a quick merge • Divergent behavior →
Conclusions • Efficient algorithm • Parameterized • Branch lengths have upper bounds • Meaningful results • Architect gains quick insight into relevant source code • Creating similar scenarios may be hard in some cases • e.g., deterministic behavior is a must
Future work • Parameter optimization • Improved accuracy • Incorporation of stack depths • Incorporation of method arguments • Better visualization • Large software systems • Support for other abstraction levels
Discussion points • How can the parameters be optimized? • Maximum/minimum branch length • How can we make the results more meaningful?