Automated Transformation of Statements Within Evolving Domain Specific Languages

1
Automated Transformation of Statements Within
Evolving Domain Specific Languages

• Peter Bell
• CEO/CTO, SystemsForge
• 7th OOPSLA Workshop on Domain-Specific Modeling
  (DSM07) - 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,000s 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 purevariants 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 1330 517c
• Demo
• Code Generation 2008
• June 25-27 2008, Cambridge, England
• Blog www.pbell.com

Email peter_at_pbell.com - Yahoo freshstartsw -
AIM appgeneration
13
Find Out More

• Practitioners Report
• A Practical, High Volume Software Product Line
• Thursday 1330 517c
• Demo
• Code Generation 2008
• June 25-27 2008, Cambridge, England
• Blog www.pbell.com

Email peter_at_pbell.com - Yahoo freshstartsw -
AIM appgeneration