[news.eclipse.modeling.mdt.uml2] Re: Question about extending classes wi

["Christian W. Damus" <cdamus@xxxxxxxxxxxxx>]

Hi, Rafael,

I do not agree that the behaviour observed in the MDT UML2 
implementation is consistent wth the UML specification or its intention.

The discussion of the MOF equivalent of a metaclass extension makes it 
clear that the semantics of Extensions are consistent with those of 
ordinary Associations.  Thus, the multiplicities of extension ends have 
the same meaning as for association ends:  they constrain the number of 
links (association instances) that can have some instance of a class (in 
this case, a stereotype) in a particular role, linked to the same object 
(in this case, a UML element, instance of the extended metaclass) in the 
other role.

So, in any metaclass extension, it actually means that at most one 
instance of the stereotype (or any stereotype conforming to it) can be 
linked by that extension to the same instance of the extended metaclass. 
 This is just like any other association.  Consider an association like 
this:

  Car [1] -------- [4] Wheel

with MagWheel specializing Wheel.  We cannot have a Car with 4 Wheels 
and 4 MagWheels.  So it is, also, with stereotype generalization and 
metaclass extensions.

It makes sense for an abstract stereotype to have a required extension, 
because this simply means that an instance of that stereotype must be 
linked to an instance of the extended metaclass.  It can be an instance 
of any concrete sub-stereotype, but nonetheless only one instance.

It does appear to me that, in the more general case, the ability to 
apply multiple sub-stereotypes of a stereotype to a single element, 
where the extension is defined on the super-stereotype, is a bug in 
UML2.  It's also a special case of a more general problem of not 
validating the multiplicities of non-navigable association ends, because 
they don't exist in the Ecore representation.

Cheers,

Christian

Rafael Chaves wrote:
> I was curious about this issue as I had never noticed that feature 
> before. I decided to implement support for abstract stereotypes and 
> required extensions in the TextUML Toolkit. See:
>
> http://abstratt.com/blog/2008/11/11/feature-required-extensions-for-stereotypes/ 
>
>
> But back to the topic - from what I observed when playing with the 
> latest TextUML Toolkit implementation (based on UML2 2.2):
>
> 1) a required extension causes the declaring stereotype to be implicitly 
> applied to all instances of the extended metaclass on a package where 
> the defining profile is applied;
> 2) that effect applies only to the stereotype declaring the extension, 
> not to any substereotypes (which makes a lot of sense), which still must 
> be applied explicitly;
> 3) as with other kinds of classifiers, abstract stereotypes cannot be 
> instantiated (applied), which also makes a lot of sense;
>
> Corollary: making an abstract stereotype declare a required extension 
> has no effect whatsoever, and thus is pointless.
>
> Finally, for two stereotypes A and B, where B specializes A, it seems to 
> be legal to apply both B and A to a target metaclass instance. So even 
> if "3" above was not true, or if you made your base stereotype 
> non-abstract, it would be valid to apply the substereotypes. This does 
> not seem to be covered by the UML specification.
>
> Granted, much of what is said above is based on observation of the 
> behavior of the MDT UML2 implementation, but I think that the observed 
> behavior makes a lot of sense, and seems to be well aligned with the UML 
> spec.
>
> Also, maybe there should be a constraint in the UML spec that ensured 
> that abstract stereotypes did not declare required extensions.
>
> Does this all make sense?
>
> Cheers,
>
> Rafael
>
> James Bruck wrote:
> > Hi Alex,
> >
> > I think you are right when you say: For I guessed multiple stereotypes 
> > for metaclasses are only possible if you make an extension for each one?
> > The Element.isStereotypeApplicable(), is implemented that way and I 
> > also confirmed this by playing around with the UML editor.
> >
> > You are correct in creating a required stereotype by setting the lower 
> > bound of the extension end to 1.  Extension::isRequired() checks the 
> > lower bound of the first owned end.
> >
> > So I'm not sure why you can succesfully apply the second stereotype as 
> > you mention.
> >
> > Can you post a small piece of your profile and model so I can see what 
> > exactly is going on.
> >
> > Cheers,
> > - James.
> >
> >
> >
> >
> > "Alex " <eistoeter@xxxxxx> wrote in message 
> > news:99faa26dde1e9bb59c698d7f755fc70e$1@xxxxxxxxxxxxxxxxxx
> > > Hi
> > >
> > > I made a custom uml profile for our models. At the moment it only 
> > > contains three stereotypes. One is abstract and the other two inherit 
> > > from this abstract stereotype.
> > >
> > > I then established an extension for uml::Class and linked it with the 
> > > abstract stereotype. I also made it be a required extension, so the 
> > > multiplicity of the extension end ist 1...1
> > >
> > > Now I assumed this means that any class in my model must ALWAYS HAVE 
> > > EXACTLY ONE stereotype that inherits from my abstract stereotype.
> > >
> > > But still it is possible to say:
> > >
> > > umlClass.applyStereotype(ConcreteStereotype1);
> > > umlClass.applyStereotype(ConcreteStereotype2);
> > >
> > > Then my umlClass will have both stereotypes assigned. Is this a bug? 
> > > For I guessed multiple stereotypes for metaclasses are only possible 
> > > if you make an extension for each one?
> > >
> > > Can someone bring light into this?
> > >
> > > Best regards