Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » Code generator problem with redefinitions
Code generator problem with redefinitions [message #477608] Wed, 16 July 2008 13:41 Go to next message
Lutz Wrage is currently offline Lutz WrageFriend
Messages: 181
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------040808080705050600010608
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I ran into the following problem when generating code from my metamodel.
It's when I use a combination of multiple inheritance an redefinition.
See the attached file for a minimal example.
I have a class C that specializes two classes A and B. A and B have
properties a and b, respectively. In C I redefine both properties. I
generate code for this model (with processing duplicate features). The
generated Java implementation class CImpl extends AImpl.

However, the generated code has the problem that it is impossible to get
the value of feature b in C, because eGet, etc., only go up the Java
inheritance hierarchy. Accessing C.b in any way leads to a stack
overflow. To me this looks like an oversight in the UML code generator
because it creates no code that takes UML multiple inheritance into
account for this scenario.

I changed my metamodel to use subsetting instead, but that's not quite
the correct semantics in my situation.

- Lutz

--------------040808080705050600010608
Content-Type: text/xml;
name="Test1.uml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="Test1.uml"

<?xml version="1.0" encoding="UTF-8"?>
<uml:Model xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:uml="http://www.eclipse.org/uml2/2.1.0/UML" xmi:id="_qb8akM37EdqwVrslYOdUDA" name="TestModel">
<packagedElement xmi:type="uml:Package" xmi:id="_w8IxIM37EdqwVrslYOdUDA" name="Test">
<packagedElement xmi:type="uml:Class" xmi:id="_cv18EFM1Ed2i_6GVTGi6aw" name="A">
<ownedAttribute xmi:id="_flLxjFM1Ed2i_6GVTGi6aw" name="a" type="_cv18EFM1Ed2i_6GVTGi6aw" association="_flLxiFM1Ed2i_6GVTGi6aw">
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_flLxjVM1Ed2i_6GVTGi6aw" value="1"/>
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_flLxjlM1Ed2i_6GVTGi6aw" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Class" xmi:id="_deB3yFM1Ed2i_6GVTGi6aw" name="B">
<ownedAttribute xmi:id="_zYp8DFM1Ed2i_6GVTGi6aw" name="b" type="_deB3yFM1Ed2i_6GVTGi6aw" association="_zYp8CFM1Ed2i_6GVTGi6aw">
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_zYp8DVM1Ed2i_6GVTGi6aw" value="1"/>
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_zYp8DlM1Ed2i_6GVTGi6aw" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Association" xmi:id="_flLxiFM1Ed2i_6GVTGi6aw" name="Association1" memberEnd="_flLxiVM1Ed2i_6GVTGi6aw _flLxjFM1Ed2i_6GVTGi6aw">
<ownedEnd xmi:id="_flLxiVM1Ed2i_6GVTGi6aw" name="source" type="_cv18EFM1Ed2i_6GVTGi6aw" association="_flLxiFM1Ed2i_6GVTGi6aw">
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_flLxilM1Ed2i_6GVTGi6aw" value="1"/>
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_flLxi1M1Ed2i_6GVTGi6aw" value="1"/>
</ownedEnd>
</packagedElement>
<packagedElement xmi:type="uml:Class" xmi:id="_i5YGIFM1Ed2i_6GVTGi6aw" name="C">
<generalization xmi:id="_lPuSc1M1Ed2i_6GVTGi6aw" general="_cv18EFM1Ed2i_6GVTGi6aw"/>
<generalization xmi:id="_OKjRM1M2Ed2i_6GVTGi6aw" general="_deB3yFM1Ed2i_6GVTGi6aw"/>
<ownedAttribute xmi:id="_TbwsLVM2Ed2i_6GVTGi6aw" name="a" type="_i5YGIFM1Ed2i_6GVTGi6aw" association="_TbwsKVM2Ed2i_6GVTGi6aw">
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_TbwsLlM2Ed2i_6GVTGi6aw" value="1"/>
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_TbwsL1M2Ed2i_6GVTGi6aw" value="1"/>
</ownedAttribute>
<ownedAttribute xmi:id="_UARHbFM2Ed2i_6GVTGi6aw" name="b" type="_i5YGIFM1Ed2i_6GVTGi6aw" association="_UARHaFM2Ed2i_6GVTGi6aw">
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_UARHbVM2Ed2i_6GVTGi6aw" value="1"/>
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_UARHblM2Ed2i_6GVTGi6aw" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Association" xmi:id="_zYp8CFM1Ed2i_6GVTGi6aw" name="Association2" memberEnd="_zYp8CVM1Ed2i_6GVTGi6aw _zYp8DFM1Ed2i_6GVTGi6aw">
<ownedEnd xmi:id="_zYp8CVM1Ed2i_6GVTGi6aw" name="source" type="_deB3yFM1Ed2i_6GVTGi6aw" association="_zYp8CFM1Ed2i_6GVTGi6aw">
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_zYp8ClM1Ed2i_6GVTGi6aw" value="1"/>
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_zYp8C1M1Ed2i_6GVTGi6aw" value="1"/>
</ownedEnd>
</packagedElement>
<packagedElement xmi:type="uml:Association" xmi:id="_TbwsKVM2Ed2i_6GVTGi6aw" name="Association5" memberEnd="_TbwsKlM2Ed2i_6GVTGi6aw _TbwsLVM2Ed2i_6GVTGi6aw">
<ownedEnd xmi:id="_TbwsKlM2Ed2i_6GVTGi6aw" name="source" type="_i5YGIFM1Ed2i_6GVTGi6aw" association="_TbwsKVM2Ed2i_6GVTGi6aw">
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_TbwsK1M2Ed2i_6GVTGi6aw" value="1"/>
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_TbwsLFM2Ed2i_6GVTGi6aw" value="1"/>
</ownedEnd>
</packagedElement>
<packagedElement xmi:type="uml:Association" xmi:id="_UARHaFM2Ed2i_6GVTGi6aw" name="Association6" memberEnd="_UARHaVM2Ed2i_6GVTGi6aw _UARHbFM2Ed2i_6GVTGi6aw">
<ownedEnd xmi:id="_UARHaVM2Ed2i_6GVTGi6aw" name="source" type="_i5YGIFM1Ed2i_6GVTGi6aw" association="_UARHaFM2Ed2i_6GVTGi6aw">
<upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="_UARHalM2Ed2i_6GVTGi6aw" value="1"/>
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="_UARHa1M2Ed2i_6GVTGi6aw" value="1"/>
</ownedEnd>
</packagedElement>
</packagedElement>
</uml:Model>

--------------040808080705050600010608
Content-Type: text/xml;
name="TestModel.ecore"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="TestModel.ecore"

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="TestModel"
nsURI="http:///TestModel.ecore" nsPrefix="TestModel">
<eSubpackages name="Test" nsURI="http:///TestModel/Test.ecore" nsPrefix="TestModel.Test">
<eClassifiers xsi:type="ecore:EClass" name="A">
<eStructuralFeatures xsi:type="ecore:EReference" name="a" ordered="false" lowerBound="1"
eType="#//Test/A"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="B">
<eStructuralFeatures xsi:type="ecore:EReference" name="b" ordered="false" lowerBound="1"
eType="#//Test/B"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="C" eSuperTypes="#//Test/A #//Test/B">
<eAnnotations source="duplicates">
<contents xsi:type="ecore:EReference" name="a" ordered="false" lowerBound="1"
eType="#//Test/A">
<eAnnotations source="redefines" references="#//Test/A/a"/>
</contents>
<contents xsi:type="ecore:EReference" name="b" ordered="false" lowerBound="1"
eType="#//Test/B">
<eAnnotations source="redefines" references="#//Test/B/b"/>
</contents>
</eAnnotations>
</eClassifiers>
</eSubpackages>
</ecore:EPackage>

--------------040808080705050600010608--
Re: Code generator problem with redefinitions [message #477609 is a reply to message #477608] Wed, 16 July 2008 14:15 Go to previous messageGo to next message
Lutz Wrage is currently offline Lutz WrageFriend
Messages: 181
Registered: July 2009
Senior Member
That was so misleading... Here the clarification:

The stack overflow occurs if the feature is accessed using eGet and
eIsSet, which are used in the generated editor, for example. That's
where I ran into the problem.

The generated isSet and getB methods are obviously fine, and there
certainly is code to handle multiple inheritance. It seems that it's not
enough, though.

- Lutz

Lutz Wrage wrote, on 7/16/2008 9:41 AM:
> Hi,
>
> I ran into the following problem when generating code from my metamodel.
> It's when I use a combination of multiple inheritance an redefinition.
> See the attached file for a minimal example.
> I have a class C that specializes two classes A and B. A and B have
> properties a and b, respectively. In C I redefine both properties. I
> generate code for this model (with processing duplicate features). The
> generated Java implementation class CImpl extends AImpl.
>
> However, the generated code has the problem that it is impossible to get
> the value of feature b in C, because eGet, etc., only go up the Java
> inheritance hierarchy. Accessing C.b in any way leads to a stack
> overflow. To me this looks like an oversight in the UML code generator
> because it creates no code that takes UML multiple inheritance into
> account for this scenario.
>
> I changed my metamodel to use subsetting instead, but that's not quite
> the correct semantics in my situation.
>
> - Lutz
>
Re: Code generator problem with redefinitions [message #477619 is a reply to message #477609] Fri, 18 July 2008 16:03 Go to previous messageGo to next message
Lutz Wrage is currently offline Lutz WrageFriend
Messages: 181
Registered: July 2009
Senior Member
No need to reply to this. I've reported a bug (patch attached):
https://bugs.eclipse.org/bugs/show_bug.cgi?id=241411

- Lutz

Lutz Wrage wrote, on 7/16/2008 10:15 AM:
> That was so misleading... Here the clarification:
>
> The stack overflow occurs if the feature is accessed using eGet and
> eIsSet, which are used in the generated editor, for example. That's
> where I ran into the problem.
>
> The generated isSet and getB methods are obviously fine, and there
> certainly is code to handle multiple inheritance. It seems that it's not
> enough, though.
>
> - Lutz
>
> Lutz Wrage wrote, on 7/16/2008 9:41 AM:
>> Hi,
>>
>> I ran into the following problem when generating code from my
>> metamodel. It's when I use a combination of multiple inheritance an
>> redefinition. See the attached file for a minimal example.
>> I have a class C that specializes two classes A and B. A and B have
>> properties a and b, respectively. In C I redefine both properties. I
>> generate code for this model (with processing duplicate features). The
>> generated Java implementation class CImpl extends AImpl.
>>
>> However, the generated code has the problem that it is impossible to
>> get the value of feature b in C, because eGet, etc., only go up the
>> Java inheritance hierarchy. Accessing C.b in any way leads to a stack
>> overflow. To me this looks like an oversight in the UML code generator
>> because it creates no code that takes UML multiple inheritance into
>> account for this scenario.
>>
>> I changed my metamodel to use subsetting instead, but that's not quite
>> the correct semantics in my situation.
>>
>> - Lutz
>>
Re: Code generator problem with redefinitions [message #477620 is a reply to message #477619] Fri, 18 July 2008 18:06 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Thanks Lutz,

I'll have a look at the defect in detail for the next iteration of UML2.

Cheers,
- James.


"Lutz Wrage" <lwrage@sei.cmu.edu> wrote in message
news:g5qet7$uh7$1@build.eclipse.org...
> No need to reply to this. I've reported a bug (patch attached):
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=241411
>
> - Lutz
>
> Lutz Wrage wrote, on 7/16/2008 10:15 AM:
>> That was so misleading... Here the clarification:
>>
>> The stack overflow occurs if the feature is accessed using eGet and
>> eIsSet, which are used in the generated editor, for example. That's where
>> I ran into the problem.
>>
>> The generated isSet and getB methods are obviously fine, and there
>> certainly is code to handle multiple inheritance. It seems that it's not
>> enough, though.
>>
>> - Lutz
>>
>> Lutz Wrage wrote, on 7/16/2008 9:41 AM:
>>> Hi,
>>>
>>> I ran into the following problem when generating code from my metamodel.
>>> It's when I use a combination of multiple inheritance an redefinition.
>>> See the attached file for a minimal example.
>>> I have a class C that specializes two classes A and B. A and B have
>>> properties a and b, respectively. In C I redefine both properties. I
>>> generate code for this model (with processing duplicate features). The
>>> generated Java implementation class CImpl extends AImpl.
>>>
>>> However, the generated code has the problem that it is impossible to get
>>> the value of feature b in C, because eGet, etc., only go up the Java
>>> inheritance hierarchy. Accessing C.b in any way leads to a stack
>>> overflow. To me this looks like an oversight in the UML code generator
>>> because it creates no code that takes UML multiple inheritance into
>>> account for this scenario.
>>>
>>> I changed my metamodel to use subsetting instead, but that's not quite
>>> the correct semantics in my situation.
>>>
>>> - Lutz
>>>
Re: Code generator problem with redefinitions [message #626799 is a reply to message #477608] Wed, 16 July 2008 14:15 Go to previous message
Lutz Wrage is currently offline Lutz WrageFriend
Messages: 181
Registered: July 2009
Senior Member
That was so misleading... Here the clarification:

The stack overflow occurs if the feature is accessed using eGet and
eIsSet, which are used in the generated editor, for example. That's
where I ran into the problem.

The generated isSet and getB methods are obviously fine, and there
certainly is code to handle multiple inheritance. It seems that it's not
enough, though.

- Lutz

Lutz Wrage wrote, on 7/16/2008 9:41 AM:
> Hi,
>
> I ran into the following problem when generating code from my metamodel.
> It's when I use a combination of multiple inheritance an redefinition.
> See the attached file for a minimal example.
> I have a class C that specializes two classes A and B. A and B have
> properties a and b, respectively. In C I redefine both properties. I
> generate code for this model (with processing duplicate features). The
> generated Java implementation class CImpl extends AImpl.
>
> However, the generated code has the problem that it is impossible to get
> the value of feature b in C, because eGet, etc., only go up the Java
> inheritance hierarchy. Accessing C.b in any way leads to a stack
> overflow. To me this looks like an oversight in the UML code generator
> because it creates no code that takes UML multiple inheritance into
> account for this scenario.
>
> I changed my metamodel to use subsetting instead, but that's not quite
> the correct semantics in my situation.
>
> - Lutz
>
Re: Code generator problem with redefinitions [message #626810 is a reply to message #477609] Fri, 18 July 2008 16:03 Go to previous message
Lutz Wrage is currently offline Lutz WrageFriend
Messages: 181
Registered: July 2009
Senior Member
No need to reply to this. I've reported a bug (patch attached):
https://bugs.eclipse.org/bugs/show_bug.cgi?id=241411

- Lutz

Lutz Wrage wrote, on 7/16/2008 10:15 AM:
> That was so misleading... Here the clarification:
>
> The stack overflow occurs if the feature is accessed using eGet and
> eIsSet, which are used in the generated editor, for example. That's
> where I ran into the problem.
>
> The generated isSet and getB methods are obviously fine, and there
> certainly is code to handle multiple inheritance. It seems that it's not
> enough, though.
>
> - Lutz
>
> Lutz Wrage wrote, on 7/16/2008 9:41 AM:
>> Hi,
>>
>> I ran into the following problem when generating code from my
>> metamodel. It's when I use a combination of multiple inheritance an
>> redefinition. See the attached file for a minimal example.
>> I have a class C that specializes two classes A and B. A and B have
>> properties a and b, respectively. In C I redefine both properties. I
>> generate code for this model (with processing duplicate features). The
>> generated Java implementation class CImpl extends AImpl.
>>
>> However, the generated code has the problem that it is impossible to
>> get the value of feature b in C, because eGet, etc., only go up the
>> Java inheritance hierarchy. Accessing C.b in any way leads to a stack
>> overflow. To me this looks like an oversight in the UML code generator
>> because it creates no code that takes UML multiple inheritance into
>> account for this scenario.
>>
>> I changed my metamodel to use subsetting instead, but that's not quite
>> the correct semantics in my situation.
>>
>> - Lutz
>>
Re: Code generator problem with redefinitions [message #626811 is a reply to message #477619] Fri, 18 July 2008 18:06 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Thanks Lutz,

I'll have a look at the defect in detail for the next iteration of UML2.

Cheers,
- James.


"Lutz Wrage" <lwrage@sei.cmu.edu> wrote in message
news:g5qet7$uh7$1@build.eclipse.org...
> No need to reply to this. I've reported a bug (patch attached):
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=241411
>
> - Lutz
>
> Lutz Wrage wrote, on 7/16/2008 10:15 AM:
>> That was so misleading... Here the clarification:
>>
>> The stack overflow occurs if the feature is accessed using eGet and
>> eIsSet, which are used in the generated editor, for example. That's where
>> I ran into the problem.
>>
>> The generated isSet and getB methods are obviously fine, and there
>> certainly is code to handle multiple inheritance. It seems that it's not
>> enough, though.
>>
>> - Lutz
>>
>> Lutz Wrage wrote, on 7/16/2008 9:41 AM:
>>> Hi,
>>>
>>> I ran into the following problem when generating code from my metamodel.
>>> It's when I use a combination of multiple inheritance an redefinition.
>>> See the attached file for a minimal example.
>>> I have a class C that specializes two classes A and B. A and B have
>>> properties a and b, respectively. In C I redefine both properties. I
>>> generate code for this model (with processing duplicate features). The
>>> generated Java implementation class CImpl extends AImpl.
>>>
>>> However, the generated code has the problem that it is impossible to get
>>> the value of feature b in C, because eGet, etc., only go up the Java
>>> inheritance hierarchy. Accessing C.b in any way leads to a stack
>>> overflow. To me this looks like an oversight in the UML code generator
>>> because it creates no code that takes UML multiple inheritance into
>>> account for this scenario.
>>>
>>> I changed my metamodel to use subsetting instead, but that's not quite
>>> the correct semantics in my situation.
>>>
>>> - Lutz
>>>
Previous Topic:Continuing saga of the standalone app
Next Topic:Serialize a UMLResource as OMG XMI
Goto Forum:
  


Current Time: Tue Aug 09 11:56:14 GMT 2022

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

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

Back to the top