Re: [papyrus-rt-dev] Redefinition of OpaqueBehaviors

[Philip Langer <planger@xxxxxxxxxxxxxxxxx>]

Hi,

One benefit for end-users I could foresee with doing this in the "right way", is that the proposed improvements to EMF Compare that Philip mentioned the other day, see bug 512514, regarding proper support for redefinition, hopefully can improve the way truly redefined OpaqueBehaviors can be presented in EMF Compare. Apart from that I doubt that any end-user really bothers about a correct redefinition being established or not. What do you say Philip, do you think that the proposed improvements to EMF Compare could be useful also for this case as well?

Yes, I would think so. I'll have to check how the currently planned implementation would behave for OpaqueBehaviors, but I assume that we could make it work for them too. I also think that it may require additional customization with respect to the generic default behavior of EMF Compare, because also without redefinition support, OpaqueBehaviors require some special treatment due to their "semantically connected" language and body attributes. We have implemented this special treatment of those attributes already a while ago, but I'll have to double-check how this can be combined with the redefinition support. Anyway, I think we can make this work.

I'll add this use case to the set of test cases that we use for design and implementation of this feature.

Thanks and best wishes,

Philip

 

On Fri, Feb 24, 2017 at 4:38 PM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:

Hi,

I would propose that we go for the option of letting OpaqueBehaviors being redefinable. Since we have bug 511060 in the pipe for 1.0, related to the handling of the RTGuard in the model import tool, we can have one more bug done at the same time for the handling need to establish the redefinition assocation for, including applying the RTRedefinedElement stereotypes on, OpaqueBehaviors during import. Should hopefully not be that much more work if both are done at the same time.

One benefit for end-users I could foresee with doing this in the "right way", is that the proposed improvements to EMF Compare that Philip mentioned the other day, see bug 512514, regarding proper support for redefinition, hopefully can improve the way truly redefined OpaqueBehaviors can be presented in EMF Compare. Apart from that I doubt that any end-user really bothers about a correct redefinition being established or not. What do you say Philip, do you think that the proposed improvements to EMF Compare could be useful also for this case as well?

/Peter Cigéhn

On 24 February 2017 at 15:04, Christian Damus <give.a.damus@xxxxxxxxx> wrote:

Hi, Team,

The inheritance support for state machines currently implemented in the master branch has raised a question.

In general, in UML-RT, we use the capability of RedefinableElements from UML to link model elements to the definitions that they redefine.  So, for example, a Transition that in the state machine of a subclass overrides its inherited effect code is created as a redefinition that references the parent state machine’s transition as its redefinedTransition and gets the «RTRedefinedElement» stereotype applied to it.  Also, because the effect is an OpaqueBehavior that, like all behaviours in UML, is redefinable, the overriding effect likewise references the redefined transition’s effect as a redefinedBehavior and has the stereotype applied.

This seems to be different to what RSA-RTE does, which tool ignores the redefinable-ness of behaviours in the role of transition effect or state entry/exit behaviour.  It happens to be an automatic consequence of the framework that I implemented for UML-RT in which all RedefinableElements are treated in the same way when they are redefined in the tooling.

What shall we do, and in which release?  We can

• align with RSA-RTE, which requires that
• • we code a special case in our UML-RT metamodel to unimplement the RedefinableElement-ness of OpaqueBehaviors in these roles
• let OpaqueBehaviors be redefinable as in UML, which requires that
• • we update the model importer to set the redefinition associations in OpaqueBehaviors that RSA-RTE did not set, similar to processing that we do to apply stereotypes (e.g., «RTGuard») in the state machines that RSA-RTE does not have
  • we make sure that all paths through the current Properties View UI (sans Code Snippet View) result in the same OpaqueBehavior redefinition pattern (currently there is a case that is incomplete)
    

AFAICS, the UML-RT Profile Specification suggests that our implementation is on the right track:  the «RTRedefinedElement» constraint indicates that it may be applied to “Behavior (if it is a state machine, a method of an operation, a transition effect, an entry or exit action)” which does seem to cover this situation.  And it would be odd to apply the stereotype without also setting the UML-ish redefinition association of the bahaviour element.  But I would like us to be clear on the intent of the usage in our tooling.

Cheers,

Christian

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

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

--

Dr. Philip Langer

Senior Software Architect / General Manager
EclipseSource Services GmbH

Email: planger@xxxxxxxxxxxxxxxxx

Web: http://eclipsesource.com/vienna
Mobile: +43 664 246 11 23

Phone: +43 1 348 338 - 10
Phone: +49 89 21 555 30 - 17
Fax: +43 1 348 338 - 99

Fax: +49 89 21 555 30 - 19
Skype: philip.langer.at

EclipseSource Services GmbH

Wiedner Hauptstraße 52
1040 Wien

General Manager: Dr. Philip Langer
Registered Office: Wiedner Hauptstraße 52, 1040 Wien; Handelsgericht Wien, FN 421413a