Automated Transformation of Statements Within Evolving Domain Specific Languages

Automated Transformation of Statements Within Evolving Domain Specific Languages

Peter BellCEO/CTO, SystemsForge

7th OOPSLA Workshop on Domain-Specific Modeling (DSM’07) - October 2007

Peter BellCEO/CTO, SystemsForge

7th OOPSLA Workshop on Domain-Specific Modeling (DSM’07) - October 2007

Agile DSM

Background

Problem

Research

Proposed solution (work in progress)

Conclusions

BackgroundGenerate custom web applications

Feature modeler

Decision support

Horizontal DSLs

Extensible framework

The ProblemLots 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

ResearchExisting Approaches

MetaEdit+

Avanade

Genvoca

Comparable Approaches

Migrations (Rails)

Database refactoring

API evolution

Schema Evolution

Solution: Meta Grammar

Solution: PrimitivesADD - 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: CatalogAdd 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.

ConclusionsCatalog 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 MorePractitioners 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 MorePractitioners 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