More restrictive bindings

Relationship	Role	Object
Causes	From	A
	To	B
Causes	From	B
	To	C

 

You see this quite often, e.g. Data Flow Diagrams can have Flow from Process to Store, External or Process, and also from Store, External or Process back to Process - but not between a combination of just Stores and Externals. Not all metamodeling languages (i.e. metametamodels) can cope nicely with things like that. That's why GOPPRR has the concept of binding, and bindings are owned by graph types - rather than trying to say that a relationship type owns its bindings, or a relationship type owns its roles, or (worst) an object type knows its bindings.

1) During development, the only real user is the metamodeler, and models at that stage are small and often just for playing around with the language. Those kind of models are updated by hand (or even thrown away if the language changes completely). At this stage there's little point trying to automate model updates (beyond what MetaEdit+ offers automatically), because it would take longer to build the automation than simply do it once by hand.

 

2) During metamodel use, existing models generally shouldn't be rendered invalid by metamodel changes. They represent real products, and probably a fair amount of work by the modelers. Just as with the evolution of programming languages, the old structures should be allowed - in other words, the models must still open OK, and generators must still work with them. Modelers need to be warned of the obsolesence, not only in the "language version release notes" but also in the models themselves. The best way to do this is often with a little generator that finds the old structures; this can then be run as part of a checking report, and also by the symbols of the elements in question - e.g. so they show a red exclamation mark or some other warning sign. Where possible there should also be advice on the recommended way to update the models, e.g. "Please replace instances of Foo with NewFoo".

 

Of course if the change can be specified precisely, it's easy enough to use the API to write a model transformation that automates the update. In practice this is actually vanishingly rare - there's just something about language evolution, whether in human languages or computer languages, that makes this kind of change unusual.

 

In fact, most changes to metamodels in production are benign, not requiring changes to existing models. Nine times out of ten, the changes are structural extensions which are handled automatically by MetaEdit+, which upgrades the existing models. Rules are more often relaxed than tightened - the metamodeler initially often tries to lock things down too much. Modelers intuition of the domain and language allows them to see things like new ways of connecting objects, along with the appropriate semantics of what that would mean. The metamodeler then relaxes the rule forbidding that kind of connection, and extends the generators to provide appropriate code for that case.