1. Automated Transformation of Statements Within Evolving Domain Specific Languages Peter Bell CEO/CTO, SystemsForge 7th OOPSLA Workshop on Domain-Specific Modeling (DSM’07) - October 2007 Peter Bell CEO/CTO, SystemsForge 7th OOPSLA Workshop on Domain-Specific Modeling (DSM’07) - October 2007

2. Agile DSM Background Problem Research Proposed solution (work in progress) Conclusions

3. Background Generate custom web applications Feature modeler Decision support Horizontal DSLs Extensible framework

4. The Problem Lots of metadata (100,000’s statements) Evolving understanding How upgrade statements as grammars evolves? Single meta-modeler Web UI for modelers (bootstrapped) Single, evolving version of DSLs Automatically evolve statements - not grammars

5. Ideal Workflow “We need to change X... ” Describe grammatical transformation Update framework/generator templates

6. Research Existing Approaches MetaEdit+ Avanade Genvoca Comparable Approaches Migrations (Rails) Database refactoring API evolution Schema Evolution

7. Solution: Meta Grammar

8. Solution: Primitives ADD - An Item (Element, Attribute or Relationship) can be added to a DSL to make it more expressive. EDIT - An Item can have its name, Properties and/or Relationships changed, perhaps making an Attribute optional or changing the multiplicity of a Relationship. COPY - Information can be copied between Items. For example, as part of the "change Attribute to Element" transformation, the values for an Attribute could be copied to the new Element to avoid data loss within the transformation. DEPRECATE - Deprecation is an important concept that allows for the expression of the intent to Delete an Item in some future version. Some systems such as pure:variants [15] allow for multiple-levels of deprecation. We have not yet determined how strictly we will implement deprecation, but initially we plan on "warning" if deprecated Items are found in a statement and removing them from editing tools so they cannot be added to new statements. DELETE - Occasionally it is necessary to remove an Element or attribute from a grammar.

9. Solution: Catalog Add Element Add Optional Attribute Add Essential Attribute Add Optional Relationship Add Essential Relationship Change Attribute to Element Change Element to Attribute Transform Data Type of Attribute Make Attribute Optional Make Attribute Required Limit Relationship to has-one Allow Relationship to have-many Move a Relationship from supporting has-one to has-many. Deprecate Element Deprecate Attribute Deprecate Relationship Delete Element Delete Attribute Delete Relationship Remove a Relationship from a DSL to remove unnecessary Relationship.

10. Conclusions Catalog of transformations simplifies evolution Benefits: No analysis paralysis Easy to optimize DSLs Future Work: Select UI for describing grammars and transforms Implement system (database and XML) Add constraints to catalog Consider DSL relationships/interfaces

11. Can You Help?! More efficient reuse of DSL statements within a SPL Package evolution in feature models Evolution of inter-related DSL collections

12. Find Out More Practitioners Report: A Practical, High Volume Software Product Line Thursday 13:30 517c Demo: Code Generation 2008 June 25-27 2008, Cambridge, England Blog: www.pbell.comwww.pbell.com Email: peter@pbell.com - Yahoo: freshstartsw - AIM: appgenerationpeter@pbell.com

13. Find Out More Practitioners Report: A Practical, High Volume Software Product Line Thursday 13:30 517c Demo: Code Generation 2008 June 25-27 2008, Cambridge, England Blog: www.pbell.comwww.pbell.com Email: peter@pbell.com - Yahoo: freshstartsw - AIM: appgenerationpeter@pbell.com