Re: [papyrus-rt-dev] Modeling the UML-RT Façade

[Philip Langer <planger@xxxxxxxxxxxxxxxxx>]

Hi Christian,

thanks a lot for this experiment and the summary you sent!

Being involved in the textual modeling effort and in the EMF Compare customization part, I do think it indeed is worthwhile to have an EMF-based facade.

For textual modeling, as you wrote, an EMF-based facade would help integrating Xtext with the custom UML-RT elements. We'd have to solve the bootstrapping issue, but aside from that, this would enable us to define the grammar against a the "facade metamodel" (that is the extended UML.ecore of your facade) and, in memory, build a native UML-RT model with all its stereotype applications etc. Xtext wouldn't have to be aware of how UML-RT concepts are actually mapped onto raw UML concepts.

The other use case is the EMF Compare customization. Currently we achieve all the integration by teaching EMF Compare the specifics of UML-RT. This is fine but it also means reverse engineering and re-implementing everything that is already implemented in some way in Papyrus-RT. An alternative approach that I started thinking about more and more a couple of weeks ago is to let EMF Compare work on with an UML-RT-specific facade instead of the pure UML model. Of course, we'd require the facade to be a "normal" metamodel API/implementation (essentially an extended UML.ecore) that can be instantiated from the plain UML model. This way, all the raw specifics of UML-RT could be hidden from EMF Compare (and its users) and let the facade handle them. This will enable a larger degree of reuse among Papyrus-RT tooling and its EMF Compare integration.

So in summary, the beauty of an EMF-based facade is that it may facilitate the direct integration of EMF technologies (Xtext, EMF Compare, and probably several more) without the need of intrusive customizations of those technologies, as it is today.

So far my two cents on this topic.

Thanks a lot and best wishes,

Philip

On Mon, Jan 23, 2017 at 5:39 AM, Christian Damus <give.a.damus@xxxxxxxxx> wrote:

Hi, Team,

The question arose last week of why the initial implementation of the façade API for UML-RT wasn’t modelled with UML2/EMF but instead is a suite of POJOs wrapping the UML model.  I had originally decided on this approach for several reasons, all having to do with services provided by EMF and by UML2 that I didn’t want the façade to be able to interact with.  For example, I didn’t want the façades to be EObjects that could be mistaken for model elements by various of the generic frameworks in Eclipse (GMF, and Papyrus Properties View to name but two), I didn’t want cross-referencers discovering and possibly leaking these objects, and most importantly I wanted the façade API to have complete control over instantiation and reuse of façade objects to a degree that is incompatible with the EMF run-time’s expectations.

This was also before I, myself, started making significant use of the façades in the Papyrus-RT tooling, which I hadn’t really anticipated.

But, the more I thought about it, the more I wondered whether maybe this decision was overthinking the potential issues, and if I could relax those restrictions, then maybe applications could be careful and find some useful advantage in a modelled solution.  So, this week-end, I quickly worked up a refactoring of the façade API as a generated UML model that still is an entirely disconnected wrapper:  the association between a façade and the UML element that it represents is not modelled as a reference.  The result is a commit on a new branch, if you’re interested in taking a look:

• committers/cdamus/facade

This is also very nearly 100% API-compatible with the current POJO implementation on master, with the one exception being in the access to excluded elements, which no longer are returned by query operations like UMLRTCapsule::getPort(String name), which incidentally can be generated by UML2 instead of hand-coded (this codegen pattern plus structural modeling capabilities like derived unions and redefinition actually help quite a lot in the definition of a rich façade API).  The Profile and Core component tests pass with this modelled façade.  I haven’t tried the tooling UI, yet, which I know will have problems with the façades being EObjects.

One use case that was discussed off-line as potentially finding the modelled façade useful is textual modelling, which might base its syntax on the façade instead of UML.  However, there are bootstrapping issues that would have to be worked out:  the façade pretty much assumes that some UML(-RT) model already exists before it can be used to create and modify content.

Anyways, all this is to say that so far it was a useful experiment in a bit of my free time and I would like to solicit some opinions on whether we should take it any further.  I have not thought through all of the potential issues with an EMF-based façade API, yet, and it would take some time to do that.  So, what does the team think?  Do you see reasons why it would be particularly valuable to have a modelled façade API?  Do you see potential pitfalls?  If this is a change we’d like to make, it would possibly be better done sooner than later (e.g., after 1.0).  Or, maybe after 1.0 would be the best time to do it, when there’s a longer window of opportunity before the next release with less feature pressure?  At any rate, it would be nice to have some kind of decision on whether to pursue this in the short term before I start working on the façade for state machines, which would (hopefully) be some time later this week.  In the mean-time, I’ve got lower-level work to do on the state machines before I reach that point.

Thanks,

Christian

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

--

Dr. Philip Langer

Senior Software Architect / General Manager
EclipseSource Services GmbH