Hi,
The façade is intended to (and currently does, in both branches) implement the “smarts” that creates and edits much of the complex structure of UML-RT behind the scenes in the UML model, which in the Tooling is the responsibility of element-type edit-helper advice. So, for example, when you do aPackage.createProtocol(“MyProtocol”), you get a new nested UML package with the collaboration, message-sets, AnyReceiveEvent, dependencies, and stereotype applications ready to go. And when you do myProtocol.setSuperProtocol(aProtocol), all of the message-set interfaces get their generalizations, too, according to the collaboration generalization, and also all of the inherited operations are manifested.
Actually, much of this is done in the “UML-RT metamodel” implementation which is another layer, our customization of the UML2 project’s UML implementation. And that already benefits all clients such as Codegen, Tooling, and Compare.
None of this changes with my prototype of a modelled façade on the branch, which basically is a refactoring of what is on master into a more EMF-like shape with features now accessible via the EMF run-time APIs. So, inasmuch as manipulation of the façade by generic EMF tooling such as Compare is concerned, it may provide already a some of the benefit we hope for from a “metamodel".
But, for the Compare case in particular, what do we actually anticipate the façade doing for us? Do we want to do all compare/merge operations in terms of the façade? Because the façade is not a complete description of the user’s model: the model also has “pure UML” bits. And, I don’t just mean passive classes; I suppose there can be interaction models and who knows what else for the purposes of high-level design. So, compare/merge then would be dealing with both the façade and UML together. In some degree, profiles already present this kind of hybrid metamodel kind of problem, so it’s not so new. But what is different about the façade is that it isn’t persisted: it doesn’t live in a resource in Git that needs to be merged.
So, for 1.0 at least, if we agree that time should be spent on this refactoring, I would support maintaining the current wrapper design, but not moving the façade towards a stand-alone metamodel with two-way synchronization.
What we want to do with this façade seems to me an agenda item for Friday’s sync call, if not a call of its own.