Upload
dennis-west
View
212
Download
0
Embed Size (px)
Citation preview
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