Eclipse Community Forums: EMF » Changing attribute behavior in subclasses

Help

Home

Home » Modeling » EMF » Changing attribute behavior in subclasses

Show: Today's Messages :: Show Polls :: Message Navigator

Changing attribute behavior in subclasses [message #687110]

Tue, 31 May 2011 20:04

Alain Picard

Messages: 266
Registered: July 2009

Senior Member

What is the best way of changing the behavior of an attribute in a
sub-class.

Let's take an easy and common example with EMF itself. EMF defines a
ENamedElement that has a "name" attribute. Now let's imagine that some
of its subclasses need this name to be marked as required and others
don't. Since the behavior is not universal, we can't mark the attribute
as "required" at the level of ENamedElement, but how could we then mark
it as "required" for let's say, EClass.

We can surely have a validation, probably OCL to check this, but this
doesn't make it a formal definition according to our meta-model. Here we
would like EEF to read this "value" and make our field bold since it is
required (w/o any other manual intervention and at the model level for
validation).

Thanks for providing me some insight.

Alain

Report message to a moderator

Re: Changing attribute behavior in subclasses [message #687112 is a reply to message #687110]

Wed, 01 June 2011 01:06

Ed Merks

Messages: 33136
Registered: July 2009

Senior Member

Alain,

Comments below.

Alain Picard wrote:
> What is the best way of changing the behavior of an attribute in a
> sub-class.
My knee jerk reaction is to say attributes don't have behavior...
>
> Let's take an easy and common example with EMF itself. EMF defines a
> ENamedElement that has a "name" attribute. Now let's imagine that some
> of its subclasses need this name to be marked as required and others
> don't. Since the behavior is not universal, we can't mark the
> attribute as "required" at the level of ENamedElement, but how could
> we then mark it as "required" for let's say, EClass.
You can't, but you could define a named constraint on the subclass and
implement it to enforce that the name isn't null. It's similar to a
typed element's type allowing a null type (because an operation without
a type is void), while a structural feature must have a type. (It's not
actually the same, because we have a derived
eReferenceType/eAttributeType and mark it required.)
>
>
> We can surely have a validation, probably OCL to check this, but this
> doesn't make it a formal definition according to our meta-model.
That's true. There's really no way to make it evident from the
multiplicity of features.
> Here we would like EEF to read this "value" and make our field bold
> since it is required (w/o any other manual intervention and at the
> model level for validation).
I see. Unfortunately there's no way to do this .
>
> Thanks for providing me some insight.
I suppose one approach is to have only EOperations on the base class and
then features in the derived classes that will implement those
operations. That might be less than ideal as well...
>
> Alain

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Changing attribute behavior in subclasses [message #687113 is a reply to message #687112]

Wed, 01 June 2011 04:44

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Alain, Ed

UML2 provides the solution in UML and consequently via UML2Ecore in Ecore.

UML supports redefinition of properties and this is reified as a
'redefines' EAnnotation in Ecore.

You just need EEF and other tools to fully support the
UML-semantics-in-Ecore. Can't promise to be there
yet on OCL but we're trying.

Regards

Ed Willink

On 01/06/2011 02:06, Ed Merks wrote:
> Alain,
>
> Comments below.
>
> Alain Picard wrote:
>> What is the best way of changing the behavior of an attribute in a
>> sub-class.
> My knee jerk reaction is to say attributes don't have behavior...
>>
>> Let's take an easy and common example with EMF itself. EMF defines a
>> ENamedElement that has a "name" attribute. Now let's imagine that
>> some of its subclasses need this name to be marked as required and
>> others don't. Since the behavior is not universal, we can't mark the
>> attribute as "required" at the level of ENamedElement, but how could
>> we then mark it as "required" for let's say, EClass.
> You can't, but you could define a named constraint on the subclass and
> implement it to enforce that the name isn't null. It's similar to a
> typed element's type allowing a null type (because an operation
> without a type is void), while a structural feature must have a type.
> (It's not actually the same, because we have a derived
> eReferenceType/eAttributeType and mark it required.)
>>
>>
>> We can surely have a validation, probably OCL to check this, but this
>> doesn't make it a formal definition according to our meta-model.
> That's true. There's really no way to make it evident from the
> multiplicity of features.
>> Here we would like EEF to read this "value" and make our field bold
>> since it is required (w/o any other manual intervention and at the
>> model level for validation).
> I see. Unfortunately there's no way to do this .
>>
>> Thanks for providing me some insight.
> I suppose one approach is to have only EOperations on the base class
> and then features in the derived classes that will implement those
> operations. That might be less than ideal as well...
>>
>> Alain

Report message to a moderator