1 / 16

Dynamic Analysis for Identifying Variation Points in Source Code: A Research Proposal

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.

cassandra-hardin
Download Presentation

Dynamic Analysis for Identifying Variation Points in Source Code: A Research Proposal

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Identification of Variation Points Using Dynamic Analysis Bas Cornelissen

  2. Introduction • Product lines • Several versions for various customers • Each having its own set of features • Variation points • Configurable features

  3. 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

  4. Method • Code instrumentation • At method level • Aspect-oriented programming • Execution using similar scenarios • Aimed at invoking one particular feature

  5. Method • Detection algorithm • Sliding windows • Parameters • Checksum size • Minimum branch length • Maximum branch length • Visualization • Dot

  6. Method • Running example • Pacman • 20 classes, 1000 LOC • Various versions • Original (reference) • Map extension • Additional game entities, e.g. holes

  7. Preliminary results • Original vs. map version

  8. Preliminary results • Original vs. map version • Slightly different initialization • One fork…

  9. Preliminary results • Original vs. map version • Slightly different initialization • One fork… • …and a quick merge

  10. Preliminary results • Original vs. hole version

  11. Preliminary results • Original vs. hole version • Slightly different initialization: a fork …

  12. Preliminary results • Original vs. hole version • Slightly different initialization: a fork … …and a quick merge

  13. Preliminary results • Original vs. hole version • Slightly different initialization: a fork … …and a quick merge • Divergent behavior →

  14. 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

  15. Future work • Parameter optimization • Improved accuracy • Incorporation of stack depths • Incorporation of method arguments • Better visualization • Large software systems • Support for other abstraction levels

  16. Discussion points • How can the parameters be optimized? • Maximum/minimum branch length • How can we make the results more meaningful?

More Related