Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Changing attribute behavior in subclasses
Changing attribute behavior in subclasses [message #687110] Tue, 31 May 2011 20:04 Go to next message
Alain Picard is currently offline Alain PicardFriend
Messages: 223
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
Re: Changing attribute behavior in subclasses [message #687112 is a reply to message #687110] Wed, 01 June 2011 01:06 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30450
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
Re: Changing attribute behavior in subclasses [message #687113 is a reply to message #687112] Wed, 01 June 2011 04:44 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6457
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
Re: Changing attribute behavior in subclasses [message #687130 is a reply to message #687113] Thu, 02 June 2011 14:02 Go to previous message
Alain Picard is currently offline Alain PicardFriend
Messages: 223
Registered: July 2009
Senior Member
Thanks Ed(s).

Alain
Re: Changing attribute behavior in subclasses [message #687339 is a reply to message #687110] Wed, 01 June 2011 01:06 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30450
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
Re: Changing attribute behavior in subclasses [message #687340 is a reply to message #687112] Wed, 01 June 2011 04:44 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6457
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
Re: Changing attribute behavior in subclasses [message #687367 is a reply to message #687113] Thu, 02 June 2011 14:02 Go to previous message
Alain Picard is currently offline Alain PicardFriend
Messages: 223
Registered: July 2009
Senior Member
Thanks Ed(s).

Alain
Previous Topic:EMF and OODB
Next Topic:[CDO] License acceptance is preventing install
Goto Forum:
  


Current Time: Wed Sep 18 21:54:25 GMT 2019

Powered by FUDForum. Page generated in 0.02251 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top