PhD Thesis Proposal: Supporting Framework-Based Development

1. PhD Thesis Proposal:Supporting Framework-Based Development Tom Tourwé Programming Technology Lab 4/2/2014

2. Original IWT Proposal • Frameworks need to be flexible and reusable • Use of extra abstractions and indirections • Heavy reliance on late binding and polymorphism • Flexibility is often not needed in specific customizations of the framework • Exisiting compilers for OO languages do not take this into account and are unable to optimize the framework significantly

3. Original IWT Proposal • Proposed solution • Make high-level information about the design of a framework explicitly available • Design patterns, best-practice patterns, … • Make information about the customization of the framework explicitly available • Which concrete participants of a design pattern are used? • How are objects composed? • …

4. Original IWT Proposal • Proposed solution • … • Use this information to perform transformations on the framework in order to optimize its performance • Break superfluous abstractions • Remove unnecessary indirections • Remove polymorphism

5. Two possible thesis subjects • Use design information to implement declarative framework specialization • Describe FW design and customization • Use this to optimize the performance • Use design information to provide support for framework-based development • Describe FW design, customization, evolution, maintenance, refactoring, etc … • Use this to provide active support for automatic code generation, perform impact analysis, detect evolution conflicts, etc …

6. Framework-based Development • Typical activities on a framework from a user-level view • Customizing the FW • For specific customers/situations • Maintaining/Refactoring the FW • Fix bugs • promote customizations into FW • Make code more reusable • Evolving the FW • Adding new code

7. Framework-based Development • From an implementation-level view, all these activities • Are based on (low-level) transformations of the source code • Require profound knowledge of the structure and dependencies of the framework

8. Problems with FWBD • Customization • Which classes need to be subclassed? • Which methods need to be overridden? • Which classes need to be used? • Maintenance/Refactoring • Which changes need to be made? • Where do these changes need to be made? • What impact do the changes have on existing code?

9. Problems with FWBD • Evolution • Impact of the changes on the FW code? • Impact of the changes on the customizations? • Two independent evolution steps may conflict • Conflict detection • Conflict resolution • No explicit support in existing tools and environments

10. Example: Refactoring Browser • Refactoring: behavior-preserving transformation • Too restrictive, very low-level • No explicit representation of FW information • Impact of changes? • No explicit representation of changes • Conflict detection and resolution? • No explicit support for adding new, user-defined refactorings

11. Proposed Solution (Thesis Statement) Explicitly and formally representing framework-specific information and the operations performed upon the framework allows for supporting framework-based development by guiding implementation, assessing the impact of changes and detecting and resolving possible conflicts.

12. What is needed • High-level description of framework information • Design patterns, coding conventions, best-practice patterns, idioms, etc … • Roles of classes and methods and relations between them become explicit • Extra information that can be useful/necessary • Explicit breaking of design for performance, quick patches, …

13. What is needed • High-level description of framework operations • Represent change and evolution • Participants that are added to/removed from/changed in current design • Represent actions that can/need to be performed • Using pre-defined transformations (refactorings) on design structures

14. What we get • Explicit description of FW structure and dependencies • Explicit description of changes made to the FW • Impact analysis is possible • Detecting and resolving conflicts is possible • High-level transformations on the design structures • Can be expressed in terms of lower-level refactorings • Can be used to detect more high-level conflicts

15. Criteria for descriptions • High level • Abstract over implementation details • Intuitive • Easy to understand and write down • Open • Express any kind of information • Adaptable • Descriptions may need to be changed • Extensible • Easy to add new information

16. What is needed (technical) • A declarative notation • To support all the criteria • A reasoning engine (SOUL) • To reason about the available information • To check constraints • To infer the impact of changes • To detect conflicts • A transformation system (Scheme) • To define transformations that need to be executed when a particular action is performed on the FW.

17. Table of Contents • Introduction • Motivation: why do we need FWBD • Explain FWBD and the problems associated with it • Explain the thesis statement and the contributions • Related Work • Prog related DMP stuff, transformation systems, formal design descriptions, evolution, refactoring, restructuring, etc …

18. Table of Contents • The proposed formalism • Criteria for supporting FWBD • A declarative approach for representing design information and program transformations • Implementing and using the formalism • How to represent FW information • How to represent FW operations • Validation and Experiments • On a small scale: impact analysis and evolution in the Scheme system • On a larger scale: MgX?

19. Table of Contents • … • Conclusion • Future Work

20. Demonstration • Add a new special form to the Scheme system • Requires adding new participants to the patterns that are used • Can be specified in terms of operations on those patterns • Add a new participant in the Chain Of Responsibility • Add appropriate HandleRequest participant • Add two new factory methods to this new participant • Add a new Closure and a new Converter class