[news.eclipse.modeling.mdt.uml2] Re: Enumeration Default Value

["Kenn Hussey" <Kenn.Hussey@xxxxxxxxxxxxxxx>]

Alexandre,

To be fair, there is a difference between MultiplicityElement::lowerValue 
and MultiplicityElement::lower; former is effectively typed by a "wrapper" 
type and so is nullable, whereas the latter is typed by a primitive. So, 
while MultiplicityElement::lowerBound() won't return null (since it too is 
typed by a primitive), MultiplicityElement::getLowerValue() will - that's 
why the OCL expression you mentioned references 
MultiplicityElement::lowerValue instead of MultiplicityElement::lower.

These "limitations" you mention, at least in the case of profiles, arise 
from the mapping of UML concepts to EMOF/Ecore concepts and from the fact 
that some things which are expressable in Ecore (like whether a feature's 
value has been set) aren't expressable in UML. To support an "unset" state 
for stereotype properties, simply apply the Ecore profile and set the 
EAttribute::isUnsettable tag to 'true'...

Kenn

"Alexandre Torres" <alexandre.torres@xxxxxxxxx> wrote in message 
news:a5c037f8b73afdc4d389f096a9566494$1@xxxxxxxxxxxxxxxxxx
> Lets revive this thread.
> This is too another real problem, not being able to set primitive types as 
> null, like Boolean. If you read the UML spec you going to see that several 
> ocl rules are based upon nullable integer values like MultiplicityElement 
> lower bound:
> From UML specification:
> lowerBound = if lowerValue->isEmpty() then 1 else 
> lowerValue.integerValue() endif
>
> so, lowerbound will never be empty when using uml2. Divergences like that 
> may seem small now, but in the long term make hard or impossible 
> interoperate models between tools. And as pointed before, the lack of 
> hability to say that some thing accept nulls, leaving the decision about 
> the value assumed to default values or later check is important. For 
> instance, I can use default values to simulate the "unset" state, but, if 
> the default value changes, it's impossible to tell what situation the user 
> choose the value and what the situation where the user left it unset. To 
> make it worse, the unset state works very well for String and not 
> primitive types.
> But if I add an wrapper as Ed proposed, this will make my model "strange". 
> Someone looking at my model will say "why you did it?" and I will have to 
> answer "becouse my uml toolkit has this limitation". All ocl rules will 
> had to be written to use wrappers, and will look alien to uml purists, and 
> bigger too.
> Well i'm disappointed with this limitation. Someone that works with uml 
> should not be bound with those EMF problems (UML-MOF problems are already 
> a lot).
> In the end I can't find any OMG uml tool that really implements the 
> specification with a good support for profile creation like eclipse's 
> implementation - what is only possible becouse of EMF's maturity. But EMF 
> will not evolve ?
>
> Thanks
>