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:
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.
