OOPSLA workshop on Domain-Specific Modeling (DSM’03) 1 Jeff Gray - Jonathan Sprinkle - David Oglesby - Stuart Kent - Kerry Raymond - Jean Bezivin - Paulo Borba - Edward Willink - Jane Lin - Krzysztof Czarnecki - Audris Kalnins OOPSLA Workshop on Domain- Specific Modeling Model Transformation Workgroup

OOPSLA workshop on Domain-Specific Modeling (DSM’03) 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!

OOPSLA workshop on Domain-Specific Modeling (DSM’03) 3 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? How to handle metamodel evolution?

OOPSLA workshop on Domain-Specific Modeling (DSM’03) 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...

OOPSLA workshop on Domain-Specific Modeling (DSM’03) 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

OOPSLA workshop on Domain-Specific Modeling (DSM’03) 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?

OOPSLA workshop on Domain-Specific Modeling (DSM’03) 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

OOPSLA workshop on Domain-Specific Modeling (DSM’03) 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