Eclipse Community Forums: UML2 » Code generator problem with redefinitions

Help

Home

Home » Modeling » UML2 » Code generator problem with redefinitions

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

Code generator problem with redefinitions [message #477608]

Wed, 16 July 2008 13:41

Lutz Wrage

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--

Report message to a moderator

Re: Code generator problem with redefinitions [message #477609 is a reply to message #477608]

Wed, 16 July 2008 14:15

Lutz Wrage

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
>

Report message to a moderator

Re: Code generator problem with redefinitions [message #477619 is a reply to message #477609]

Fri, 18 July 2008 16:03

Lutz Wrage

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
>>

Report message to a moderator

Re: Code generator problem with redefinitions [message #477620 is a reply to message #477619]

Fri, 18 July 2008 18:06

james bruck

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
>>>

Report message to a moderator