[news.eclipse.tools.uml2] Re: Is Feature Refinement supported ?

[Ed Merks <merks@xxxxxxxxxx>]

Antonio,

We have no plans to address this other than what UML2 import and the extended UML code generator already provides.  Ecore is very much focused on keeping things lean and efficient and on describing things that can be easily realized in a Java API.  So while we may well at some point look at expressing such things as "standard" annotations within the Ecore model, we won't ever relax the constraint that a feature with a given name can be defined at most once in the hierarchy.


Antonio Carrasco Valero wrote:

Hi Ed!

Should we consider thes limitation,
of eCore not allowing redefinition of features in subclasses,
as something to resolve in the future ?

This seriously impairs the ability to reuse Eclipse UML implementation in 
DSLs.

I believe that that, in the very honest goal
of keeping EMF codegen straightforward,
those honestly interested in the reuse of Eclipse UML in their DSLs,
will be seriously discouraged to do so.

This limitation forces to do all kinds of nasty hacks in the metamodels,
that´s why it is used all over the UML2 specification
(and why package merge and UML flattening is possible).

Other ways of constraining, apart from subclassing UML,
still leave a metamodel that is exactly like the original, unrefined one,
when inspected reflectively.
This amounts the same as creating Profiles of UML
- as many are so intelligently doint, given the obstacles to derive  DSLs 
from UML.

Cheers,
Antonio Carrasco Valero
Model Driven Development ltd.




"Ed Merks" <merks@xxxxxxxxxx> wrote in message 
news:ehkt0k$ehc$1@xxxxxxxxxxxxxxxxx...
  

Antonio,

This is possible in UML2 but not in Ecore.  The UML2 Ecore  importer will 
create new features (with a different name)s for such a cases.  Narrowing 
the multiplicity isn't even possible with Java , i.e.,  List<X> getX can't 
be overridden with X getX(), and narrowing the type would only be possible 
for single valued features in Java 5.0, i.e., X getX() can be overridden 
by Y getX() if Y inherits from X, and isn't possible for multi-valued 
features in Java 5.0 because there is no inheritance relation between 
List<X> and List<Y> regardless of the inheritance relation between X and 
Y, i.e., List getX can be overridden by List getX but List<X> getX cannot 
be overridden by List<Y> getX.  It's usually best to consider such 
refinements to be constraints rather than to expect the API itself to 
morph since Java is not completely capable of expressing this.


Antonio Carrasco Valero wrote:
    

Hi !
Is it possible to refine features in subclasses ?
i.e, define in a sub-EClass,
an EReference feature that re-defines the referenced type
to an specialization of the type referenced by the supertype,
or that narrows multiplicity from 1..n to 1..1, ...