Hello...
Hello!
I must confess that I had a much more complex set of interfaces in mind
than the simple one-type-for-all-Model-Elements that Bob has drawn. The
simple, one-type-for-all-Model-Elements is simple to implement but on
the other hand, I agree with Tom that the benefit gained from it is
probably low too.
So far we have chosen the path of deriving the interfaces from UML 1.4
but we because of the transition between NSUML and MDR we have the whole
set of Façade and helpers. In a way we could say that we have a not so
elegant compromise. I thought, when we started the transition to MDR
that MDR and JMI would be the last (meta-)metamodel that we needed to
support so that we could just throw away the Façade and helpers by now.
I am not so sure anymore. We have several problems that require us to
choose a path:
1. The MDR-generated interfaces depend on the MOF model. I.e. a new MOF
model and ArgoUML would stops compiling. This makes it impossible to
have ArgoUML support several metamodels. I don't know if this is under
control now. I should at least be isolated to the model-mdr tree.
2. Ability to plug in other model types (EMF, ...). Is this really
interesting?
If we choose the path of "freezing" the metamodel version and remove the
ability to plug in other model types we could remove the Façade and
helpers and everything would be much simpler. Consequences are that the
change to UML 2.0 or UML 2.1 will be a huge step.
If we continue the path that we are now on, having a layer in between,
we can come far with allowing us to experiment with different versions
of the UML metamodel and different model types. On the other hand
changing and supporting the huge set of Façade and helpers is a lot of
work. We see this problem already. Especially if we go towards a new UML
version with new interesting constructs that are to be "supported" for
old model versions or implementation. Having them optional is
complicated, we have seen that too.
There is one thing we haven't discussed around this and that is if we
could use the UML 2.0 architecture to get the right balance between
these two extremes. I mean, if we separate the Model subsystem in two
layers, the UML infrastructure layer and the UML superstructure layer,
this will reduce the interface to the infrastructure layer model
subsystem to just include the interfaces in the UML Infrastructure. The
UML superstructure layer would then be built using nothing but calls to
the infrastructure layer reducing the complexity. This means that the
UML superstructure layer would be the same independently of the
implementation of the model subsystem. Could it be generated from the
UML superstructure specification?
Will this help in any way or is it just complicating matters?
/Linus
> -----Original Message-----
> From: Tom Morris [mailto:[EMAIL PROTECTED]
> Sent: den 9 januari 2007 19:48
> To: [email protected]
> Subject: RE: [argouml-dev] ModelElementFacade (again)
>
> > You'll find some of my initial thoughts here -
> >
>
http://argouml.tigris.org/servlets/SearchList?list=dev&searchText=modele
le
> me
> ntfacade&defaultField=subject&Search=Search
>
> Thanks for the pointer. I never would have found a two year old
> discussion!
>
> I agree with the previous comments (Linus & Steffan ?) that
maintaining
> such
> a set of proxy interfaces (or façade) by hand is an untenable
proposition.
> We already have too much hand-maintained machinery of this type that
> duplicates information from the UML metamodel.
>
> The project that Steffan referenced
> http://argouml.tigris.org/servlets/ReadMsg?list=dev&&msgNo=17655
(which I
> think is the precursor to the Eclipse ATL project) might be one source
of
> automated tools to deal with this. Also MDR actually builds a set of
> proxy
> interfaces like this by reflection when it reads in the XMI file
> representing the UML 1.4 metamodel (or any MOF 1.3 metamodel), so that
the
> internal concrete MDR objects implement interfaces named
> org.omg.uml.foundation.core.ModelElement,
> org.omg.uml.foundation.core.GeneralizableElement, etc. It might be
> possible
> to leverage or intercept this machinery, but that wouldn't help us
with
> anything MOF 2.0 or EMF based.
>
> That brings up the question of which metamodel do we automatically
derive
> the interfaces from? Is it UML 1.4 or UML 2.1 or some EMF metamodel?
The
> intersection of them all? The union of them all? (These last two
would,
> of
> course, require us to hand create the merged metamodel).
>
> Note that the earlier thread contained some misinformation about EMF.
It
> is
> *not* compatible with OMG's EMOF (if you read the Eclipse descriptions
> they
> are always surrounded with marketing weasel words like "similar to" or
> "culturally compatible with"). Even if they were compatible, UML 2.1
is
> specified using CMOF, not EMOF. (I think E="Essential" and
C="Complete",
> but that's off the top of my head without verification).
>
> I have more comments on the details of the proposed implementation,
but
> I'm
> not sure they're relevant unless we can resolve some of these
overarching
> questions. Until we have a clear idea of where we're headed, I think
> there's too high a risk that this will be wasted effort. I know we
want
> to
> get to UML 2.1, but I have no idea what the technological basis is
going
> to
> be for our getting there. We need to figure that out before deciding
on a
> migration path for the Model subsystem's API.
>
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
