| Re: [papyrus-rt-dev] Modeling the UML-RT Façade |
Hi,Thanks for the comments, so far. It is encouraging to see so much interest in this kind of change.iPlease see some comments in-line, below.
Thanks,
Christian
On Jan 23, 2017, 04:19 -0500, Remi Schnekenburger <rschnekenburger@eclipsesource.com >, wrote:
Hi team,@Patrick: I do not have the implementation details from Christian, but I don't see there issues on using the new facade on OSGi. It should not involve more than EMF and UML2 plugins, which are already supported out of Eclipse & OSGi (at least, it should, or you would not even be able to read the model itself).That’s right. The modelled API is still in the same bundle and in the same package as before, with the same dependencies. A smooth, compatible evolution for clients.
@all: We indeed discussed yesterday on such improvement on facade support with Philip last week. This is one of the major topic IMO for great support for DSLs for Papyrus and its derivative products. The advantage of using an EMF approach would be indeed the integration with external tools like EMF compare, xtext grammars, QVTo transformation, all the tools that should be EMF based, and that can have some troubles to integrate with UML2 world would be quite transparent to the user.Current approach with element types fits nicely with GMF runtime, and it could be seen as slightly higher level, but the 2 main drawbacks are the fact that the metamodel complexity is hidden in the configurations and that we cannot enforce that the model is edited through this framework. Xtext is for example not aware of that framework, and tricks have to be used to reuse it. We could see that issue with textual modeling.I wasn’t looking to make any element-types for the façade: it is still just wrappers on the UML model, and like much of the EMF run-time, the element-types rely on the factory to create “naked” elements that are attached to the model and filled in with details. The façade doesn’t “exist” as such in any model, so these workflows don’t really apply. It is still geared towards providing a thin API to abstract the complexity of UML for extenders primarily.
If we want to drive a complete modelling experience from the façade, then it would have to be more than just a thin wrapper: it would have to be essentially a clone of the UML model that stores all of the same state (well, the subset that UML-RT actually needs) that is synchronized with the UML model, like the AOF approach. But that is still something that I want to avoid: the façade scales as the size of the UML model, and I would prefer the thin wrapper approach over two-way synchronization. So, that does still limit its capabilities to some extent, but leaves room for scalability techniques like soft caching of façades to let them be garbage-collected when no longer in use, and who knows what else we might need with very large models.
I was thinking however to a facade implementation where the elements would really inherit from the UML metaclass, not an association to this class itself. I do know it breaks slightly the UML philosophy, where stereotypes can be removed/added on the fly.I don’t think this could work. The problem with making, for example, Capsule a subclass of Class is that now instances of it will be persisted in the UML model as Capsules, breaking the UML serialization. Applications that only understand UML will not be able to read these models (although, it is perhaps doubtful the extent to which they could plausibly work with these models anyways). Moreover, it would mean that generic UML-based plug-ins in a Papyrus-RT environment would have to know how to choose between creating a normal Class versus a Capsule, especially as both present equivalent representation of the same concept (as we have already proven with the profile).
But in the case of stereotypes defining new concepts, as the capsule one, I would not be so worried about that side effect. It would cause issues in the case of annotating stereotypes, which should be seen more as associations in this case. This implementation would have of course many drawbacks, but I would be curious to setup also a prototype for that approach. I did not yet think carefully about implementation details. One of the advantage I see here is that we would not maintain a "glue element", but we would have directly a compatible element. This would avoid switching with toUML() and other artifices to real implementation elements.I guess one of the questions we need to answer is the intended purpose of the façade: do we want it to be the metamodel that the entire tooling is built on, or do we want it to be a convenient API for extenders and other plug-ins to inspect and modify the model without as much complexity as the tooling provided by Papyrus-RT requires? So far, the driving use cases have been the latter, similar to what the “legacy tooling” offers, and the extent to which it has evolved so far is just an accident of my stretching it to use in the Properties View. It hasn’t been on the critical path for the 1.0 release, and I doubt that we could afford to make it so.
I would however be interested to investigate your proposal, Christian, that seems a really interesting step ! :) I am for example curious to discover how notifications can be handled, I remember that was an issue Florian had to work on his facade prototype a few years ago.That’s one of the details that I have been uninterested in implementing in the façade, is notifications. The use cases so far have been all about code grabbing a façade for some model element, working with it for a bit, and then forgetting about it. Subscribing to notifications hasn’t been interesting. Although, as all of the properties of the façade are (literally) derived by computation, and the façade objects themselves are all attached to the model by Adapters, it would not be difficult to add support for injection of notifications into the façade objects so that they may, themselves, be observed. Not difficult, but it would take time.So, again my main concern is for scheduling and risk to the delivery of state machine inheritance, if we want to develop the façade into something more than it currently is.
Cheers,Rémi______________________________
2017-01-23 9:46 GMT+01:00 Patrik Nandorf <patrik.nandorf@xxxxxxxxxxxx>:
Hi,
Maybe I'm just missing it but would this change the ability to use the façade outside Eclipse, i.e without OSGi in any way?
/Patrik
On 01/23/2017 05:39 AM, Christian Damus 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/mailma n/listinfo/papyrus-rt-dev
_______________________________________________
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
--
Remi Schnekenburger
Senior Software Architect / General ManagerEclipseSource Paris
Email: rschnekenburger@eclipsesource.com
Web: http://eclipsesource.com/paris
Mobil: +49 89 21 555 30 - 25
Phone: +49 89 21 555 30 - 25
Fax: +49 89 21 555 30 - 19
EclipseSource France SAS
7 rue de la Croix Martre
91873 Palaiseau
General Manager: Remi Schnekenburger_________________
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
_______________________________________________
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