Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] multiple inheritance in profile

Thanks Ed for your help, I really appreciate it.

Unfortunately default options are definitely not satisfying, as the “Discard” of “Duplicate Feature Inheritance” violently removes the Child to Stereo2 inheritance.

 

However, following your “make it simple” advice, I restarted from scratch, removed the Child to Element extension association (and all subsetted/redefined properties) to see what happens.

 

When “Duplicate Feature Inheritance” is “Processed”, the feature “base_Element” of Stereo2 is renamed as “Stereo2_base_element”, BUT a “redefine” annotation is generated [1] (I missed it in my preceding experiments).

 

Stereo2 generated interface is indeed correct, and provides a “getBase_Element” function [2].

 

BUT… there is a (single) error in the generated code [3]. Adding subsetted/redefined features information doesn’t make more difference in fact.

 

As genmodel validation doesn’t report any error, and considering the generated code compilation error, I’m tempted to think it’s a code generator bug : I think the first “case” statement should be removed (it was indeed the first error reported by Gery!).

At least other similar functions like eSet/eGet don’t contain this first case[4].  Apart from that, generated code looks fine (but I didn’t test it).

 

 

[1]

 

[2]From Stereo2Impl.java

 

[3]From Stereo2Impl.java

 

[4]From Stereo2Impl.java

 

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Ed Willink
Envoyé : mercredi 29 mars 2017 13:12
À : mdt-papyrus.dev@xxxxxxxxxxx
Objet : Re: [mdt-papyrus.dev] multiple inheritance in profile

 

Hi

I absolutely meant subset. More specifically I meant that the Child properties should specify each StereoX property as a subsettedProperty.

I find the many UML2Ecore GenOptions very confusing. I strongly recommend that you ensure that the default behavior just works allowing non-standard options to be a user choice.

The options tend to be set to 'sensible', so don't touch them. Occasionally they have a paranoid legacy compatibility value that needs to change to 'sensible'.

Since, once correctly defined, the metaclass redefinition has unambiguous intent, it should be code generated the same for all options, you should perhaps file a bug for each option configuration that fails to generate useful code.

It could well be that since base_XXX has special functionality, UML2Ecore must have corresponding special functionality, but perhaps only to avoid a corruption induced by a different special functionality for one of the gen options.

Unfortunately UML2Ecore is something of a partial triumph over stupidity. There are aspects of UML that are fundamentally incompatible with Ecore and so UML2Ecore has to approximate. This is achieved by the magic subsets/redefines/... annotations for which I have never found any documentation. The gen options are similarly undocumented. Users are forced to use empirical design to see what happens. Tooling such as OCL is forced into empirical discovery using too many Bugzillas to achieve convergence on the semantics.

    Regards

        Ed Willink

On 29/03/2017 11:41, REVOL Sébastien wrote:

Hello Ed,

Thanks a lot for your answer.

 

I made progress, but I’m still stuck.

Redefinition/Duplicate features seem to work well when there is only one inheritance path.

“Duplicate Features” and “Redefining Properties” options have to be set to “Process”.

 

However, with multiple inheritance, I can’t get it working.  

When I set “Duplicate Feature Inheritance” to “Process”, the feature “base_Element” of Stereo2 is renamed as “Stereo2_base_element” [1], which is not acceptable.

 

When it’s set to “discard”, Stereo2 inheritance is removed [2].

 

Last when it’s set to “ignore”, ecore model looks close to what I need [3], but I have validation errors [4] and a compilation error in generated code [5].

Notice that I have only one compilation error, a duplication of feature identifiers in the metamodel package, but apart from that, generated code looks fine.

 

Is there something I’m still doing wrong? Or should I fill a UML2 bug?

 

By the way, when you said “Each end of the 'redefining' Extension should subset the corresponding ends of the 'redefined' Extension.”

I guess you meant “redefine” and not “subset” (I also tried “subset” to be sure, but did not see any improvement…)

It finally appears that it’s not necessary to redefine each end. The “redefine/duplicates” are indeed generated even if only the “owned by classier” end is redefined.

But I was tricked by the genmodel editor which is hiding annotations…

 

 

 

[1]

 

[2]

[3]

 

[4]

 

[5]From TestProfilePackage.java

 

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Ed Willink
Envoyé : mardi 28 mars 2017 18:10
À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx>
Objet : Re: [mdt-papyrus.dev] multiple inheritance in profile

 

Hi Sébastien

It's hard to get right, especially when my terminology is confusingly loose.

"Child must provide an Extension association to redefine the two inherited Extensions to eliminate the ambiguity"

Each end of the 'redefining' Extension should subset the corresponding ends of the 'redefined' Extension. The ends should be in the same order.

UML.merged.uml has numerous examples for Associations.

    Regards

        Ed Willink


On 28/03/2017 16:23, REVOL Sébastien wrote:

Hi Gery,

You can’t rename base_XXXX attributes, their name follow a naming convention imposed by stereotype mechanism tooling.

 

I think Ed gave us the right solution (thanks Ed!): " Child must provide an Extension association to redefine the two inherited Extensions to eliminate the ambiguity."

 

I'm currently trying to implement it[1].

Unfortunately don’t see any effect.

 

I tried to see how UML metamodel is implemented. I randomly chose a redefined property example : “DurationInterval::max” redefines “Interval::max”. [2]

In the corresponding .ecore file, we can find a corresponding “duplicates” annotation [3].

 

It seems to be the clue for a correct code generation.

How can we trigger its generation? By default, I don’t have it in my test example.

Is it due to the fact that we have a multiple redefinition?

 

[1]

 

 

[2]From : org.eclipse.uml2.uml\model\UML.merged.uml

 

[3] From org.eclipse.uml2.uml\model\UML.ecore

 

-----Message d'origine-----
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de DELOGE Gery 249233
Envoyé : mardi 28 mars 2017 16:34
À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx>
Objet : [PROVENANCE INTERNET] Re: [mdt-papyrus.dev] multiple inheritance in profile

 

Hi,

 

No problem Ed.

 

Another issue raised while using generated code with "DUPLICATE_FEATURE_INHERITANCE : process". I cannot set anymore two stereotypes on the same element.

 

I'm currently testing the other solution (ie. rename duplicate attribute in BPMN profile).

 

I'm still not sure where the problem is : BPMN profile, UPR implementation of the profile, generator...

 

Cheers,

Géry

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Ed Willink Envoyé : mardi 28 mars 2017 13:49 À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx> Objet : Re: [mdt-papyrus.dev] multiple inheritance in profile

 

Hi

Gery: Apologies , I thought you were a user not developer. A repro is ideally a simple zipped project that may be downloaded and used to examine the problem free from the complexity of a large application.

I recall struggling with multi-metaclassing for the OCL evaluation since exactly one set of Element slots should be reified regardless of whether Stereo1, Stereo2 or Child is instantiated.

After a bit of thought the problem seems very simple:

 

Child must provide an Extension association to redefine the two inherited Extensions to eliminate the ambiguity.

 

In Papyrus, you perhaps just draw a Child to Element metaclass relationship and add the redefinitions in the properties pages.

 

I think my OCL tests have some Extension redefinitions, so perhaps it's a simple OMG model bug requiring the missing redefinition. Add it to the model and the tooling may work.

    Regards

        Ed Willink

 

 

On 28/03/2017 11:08, REVOL Sébastien wrote:

Hi all,

To complete the discussion, the duplicated features are those generated by the "extends relationship" : let's consider a stereotype "Child" that inherits from Stereo1 and Stereo2 [1].  Both of them extend the same "Element" metaclass.

In practice ecore generates a "base_Element" eRef for both Stereo1 and Stereo2.

 

In theory, those features have the same meaning and they should be merged in Child.

 

By default, with the "discard" option for duplicated feature inheritance, the UML to Ecore generator directly removes the Stereo2 inheritance [2].

 

"Process" option preserves the inheritance, but renames the one of the features [3].

 

"Ignore" option preserve feature names and inheritance, but a model validation error occurs [4].

 

Last, "Report" option directly stops the process when the UML model loaded [5].

 

I don't know if it's a known issue and if there is an existing solution?  (feature redefinition?)

 

 

[1]

 

 

[2]

 

 

[3]

 

 

[4]

 

 

 

[5]

 

 

-----Message d'origine-----

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de MAGGI Benoit Envoyé : mardi 28 mars 2017 11:39 À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx> Objet : [PROVENANCE INTERNET] Re: [mdt-papyrus.dev] multiple inheritance in profile

 

Hi Ed,

 

Gery is currently working on the BPMN Papyrus DSML, you may find all sources in this eclipse repository [1].

I think it's quite natural for him to use this mailing list for such tricky dev question.

 

The root issue is that OMG BPMN profile is indeed using multi-inheritance and same property name [2].

(IMHO: very bad idea, but I didn't check if it's valid for an UML profile)

 

Maybe it should be reported as OMG bug?

 

Regards,

Benoit

 

1: https://git.eclipse.org/c/papyrus/org.eclipse.papyrus-bpmn.git/

2: BPMNActivity extends InteractionNode and BaseElement BaseElement and InteractionNode both have a base_Element property.

 

-----Message d'origine-----

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Ed Willink Envoyé : mardi 28 mars 2017 11:22 À : Papyrus Project list <mdt-papyrus.dev@xxxxxxxxxxx> Objet : Re: [mdt-papyrus.dev] multiple inheritance in profile

 

Hi

 

This is the Papyrus developers list. Please use the Papyrus forum for Papyrus usage questions. Use the UML2 forum for UML questions.

 

You haven't provided a repro so I may be misunderstanding what is nasty.

 

base_XXX/extension_XXX is effectively reserved for use by the Stereotype implementation mechanics. Very bad practice to re-use it. Imperfect tooling may get confused.

 

Duplicate feature names are prohibited in Ecore and UML. In Ecore (for the reified Stereotype) you would be in trouble. However UML provides a redefinition capability. This should be used to break the conflict. I've only used it in some superficial OCL test cases, so you may have some bugs to circumvent. Raise Bugzillas with fulll project repros.

 

     Regards

 

         Ed Willink

 

On 28/03/2017 09:53, DELOGE Gery 249233 wrote:

> Hi,

> 

> I had annoying exceptions in BPMN. The root cause was an issue in BPMN profile generated code with multiple inheritance.

> A stereotype inherits from two parents who have each a property named with the same name.

> Basically BPMNActivity inherits from InteractionNode and from BaseElement who have both a base_element attribute.

> 

> Initial configuration was UML2 generator (xmlns:genmodel="http://www.eclipse.org/uml2/2.2.0/GenModel in genmodel file) and DUPLICATE_FEATURE_INHERITANCE set to DISCARD.

> In this case, the inheritance from InteractionNode is not present in generated code and effect is IllegalArgumentException.

> 

> First test was renaming base_element attribute in InterractionNode and keeping DUPLICATE_FEATURE_INHERITANCE to discard.

> Code was generated without error and multiple inheritance is fine.

> 

> Second test was setting DUPLICATE_FEATURE_INHERITANCE to Process. In

> that case multiple inheritance is generated correctly but I have one

> error in generated code in a switch case in eIsSet method

>             case BPMNProfilePackage.INTERACTION_NODE__BASE_ELEMENT:

>                           return isSetBase_Element();

> INTERACTION_NODE__BASE_ELEMENT cannot be resolved or is not a field

> Commenting this case and everything look fine.

> 

> Does anyone already have this issue ?

> What is the best solution ?

> 

> Cheers,

> Géry

> 

> 

> _______________________________________________

> mdt-papyrus.dev mailing list

> mdt-papyrus.dev@xxxxxxxxxxx

> To change your delivery options, retrieve your password, or

> unsubscribe from this list, visit

> https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev

> 

 

 

---

This email has been checked for viruses by Avast antivirus software.

https://www.avast.com/antivirus

 

_______________________________________________

mdt-papyrus.dev mailing list

mdt-papyrus.dev@xxxxxxxxxxx

To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev

_______________________________________________

mdt-papyrus.dev mailing list

mdt-papyrus.dev@xxxxxxxxxxx

To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev

 

 

 

_______________________________________________

mdt-papyrus.dev mailing list

mdt-papyrus.dev@xxxxxxxxxxx

To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev

 

 

Virus-free. www.avast.com

 

_______________________________________________

mdt-papyrus.dev mailing list

mdt-papyrus.dev@xxxxxxxxxxx

To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev





_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev

 

Virus-free. www.avast.com

 




_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev

 

Virus-free. www.avast.com

 

Back to the top