OOPSLA Workshop on Domain - Specific Modeling Model Transformation Workgroup

1. OOPSLA Workshop on Domain-Specific ModelingModel Transformation Workgroup Jeff Gray - Jonathan Sprinkle - David Oglesby - Stuart Kent - Kerry Raymond - Jean Bezivin - Paulo Borba - Edward Willink - Jane Lin - Krzysztof Czarnecki - Audris Kalnins

2. Objectives • How to handle metamodel evolution? • Model & code migration, size of models, number and distribution of users, code generation • Metamodel (and transformation) versioning • How to divide responsibility between modeling language and transformer/ generator? • Language characteristics that influence code generation/model migration success • Have fun!

3. How to handle metamodel evolution? • Correctly!! • When do to have to handle it? • Problem comes with the data, not the lang. change • What must you consider • Semantics, APIs, Interpreters, Training, Documents • Are there really changes that don’t matter • Maybe, or maybe not • What are the dimensions of change • What is being affected? What has been changed?

4. How to handle metamodel evolution? • This isn’t a new problem, though ... • w3c is much more concerned about change to schema than we are • Programming languages can evolve • But not in the same way • The nature of a Domain Specific model means that D-S >> Backward Compatibility • Can we build metamodels that are easier to evolve? • Whose job is this anyway? • I’m glad you asked ...

5. How to divide responsibility between modeling language and transformer/ generator • Whose responsibility is it for change • Should the tool be responsible for migration after the changes are made to the metamodel • Should the tool just be more fluid to accept “problems” and allow the users to make the solutions • How far along are we to finding solutions • Can we find a solution for all models, or just in certain contexts? • To what extent can we automatically generate (without any input) the transformer (and is this dangerous?) • What is the QoS of the tool • How much does the tool itself aid the (user) in these efforts • Understanding the intent of the metamodeler can go a long way toward making changes to any transforms that exist

6. Model & code migration, size of models, number and distribution of users, code generation • The number and distribution of users necessarily determines how your models should be stored/archived • Source control of a large system stored in just one file? • Working on different attributes from different continents? • How much of a change in the domain requires that you change the metamodel? • i.e., how long can you creak along on what you had and just change values or do “hacks” to make it work with the new domain • Consider the total cost of migration • Training, education, model transforms • When the MM is a superset of the old metamodel, is it a change? What about a subset? • Just changing element names? • When you make the change, can you also provide the utilities to “import” the original models • Or, can you generate these from the MM changes?

7. Metamodel (and transformation) versioning • When you have A and change it to A’, what elements are the same? • Versioning can help here • What is the granularity of the metamodel storage? • You want to control this on the model level, not on the rendering level • It’s not the individual elements that matter, it’s the total metamodel identity • It’s difficult (impossible?) to make a change that everyone will recognize as insignificant • What is the level of granularity at which we will version? • Each language should decide what its level is • Does changing the comment in a model make a difference? • Could be, what if the versioning is controlled by file savetime? • Always assume that something downstream is affected

8. Language characteristics that influence code generation/model migration success • There are examples in other programming paradigms • Generate your API using patterns that are receptive to change • E.g., CORBA, never use enums, only integer constants • Use (or create) tools that aren’t too fussy about change • Using optional attributes to ease the process • The development and production tools should behave differently here • It can (should?) be done that • You can examine the set of modeling constructs and find which ones are better for evolution in some contexts • Recommend/instruct that some methods be used in those contexts • Should we have normal forms for modeling? • No optional attributes  Make a subtype