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
Agile DSM
Background
Problem
Research
Proposed solution (work in progress)
Conclusions
Background
Generate custom web applications
Feature modeler
Decision support
Horizontal DSLs
Extensible framework
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
Ideal Workflow
“We need to change X . . . ”
Describe grammatical transformation
Update framework/generator templates
Research
Existing Approaches
MetaEdit+
Avanade
Genvoca
Comparable Approaches
Migrations (Rails)
Database refactoring
API evolution
Schema Evolution
Solution: Meta Grammar
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.
Solution: Catalog
Add Element
Allow Relationship to have-many
Add Optional Attribute
Move a Relationship from supporting
Add Essential Attribute has-one to has-many.
Add Optional Relationship Deprecate Element
Add Essential Relationship Deprecate Attribute
Change Attribute to Element Deprecate Relationship
Change Element to Attribute Delete Element
Transform Data Type of Attribute Delete Attribute
Make Attribute Optional Delete Relationship
Make Attribute Required Remove a Relationship from a DSL to
Limit Relationship to has-one remove unnecessary Relationship.
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
Can You Help?!
More efficient reuse of DSL statements within a SPL
Package evolution in feature models
Evolution of inter-related DSL collections
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.com
Email: peter@pbell.com - Yahoo: freshstartsw - AIM: appgeneration
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.com
Email: peter@pbell.com - Yahoo: freshstartsw - AIM: appgeneration