Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] facade and transition creation
Hi Christian,

So I foresee some conflicts if you have also worked on canonical synchronization and children strategies ;-) To help the work on transitions, I had to adapt a bit and to enhance the way canonical mode works for UML-RT state machines. 
I had the issue of transitions displayed into a diagram where they should not. I planned initially to fix them by modifying the view providers. That would be the best solution, but there is no solution AFAIK to totally remove a provider from the view service and I am "polluted" by the Papyrus generic one. So I took the issue on another point of view, and I came modifying the canonical edit policy, or more precisely, the RT state machine children strategy. That's good that we discussed that topic, as I may also introduce a solution not viable when the inheritance will be in place. I check that the transition is contained in the "only" region displayed at screen. I ensure I do not have too much when running canonical policy. But there may be some troubles in cases of inheritance...

I will let you commit and do the merge on top of your contribution. I had 2 failing tests on the remote server [1] , where successful on the local machine. So I can wait before merging. 

Cheers,
Rémi

[1] https://git.eclipse.org/r/91294/



2017-02-21 17:04 GMT+01:00 Christian Damus <give.a.damus@xxxxxxxxx>:
Hi, Rémi,

I don’t have specific use cases to inform the discussion about the façade API for transitions, so I can only say that what you propose sounds good to me.  😀 

However, I should note that I am happy to see more test coverage for canonical synchronization in the state machine diagram, but as you might expect I have completely overhauled the implementation in my work on inheritance.  So, obviously more reason to have improved test coverage, but I hope that you haven’t yet delved into fixing anything in the canonical children strategies!  A merge could be painful.

(I am working now on gerrit reviews to post today for merging my working into master.  It’s not finished, but I think it is time to start integrating it.  More on that soon in a new thread on this list.)

Cheers,

Christian

On Feb 21, 2017, 08:06 -0500, Remi Schnekenburger <rschnekenburger@eclipsesource.com>, wrote:
Hi team,

I was investigating the usage of the facade for the tests, currently extending the tests around canonical mode and state machines (not working well currently for transitions).
While working with the tests, I (re)discovered the fact that the facade is a very efficient way to build semantic test environments. However, I found some limitation on the creation of transitions, and I wanted to discuss about potential improvements. 

Currently, the method createTransitionTo on UMLRTVertex creates the transition, without taking care of the target and source, e.g. by passing the rules setup for the creation of transition on Bug 494284: [Tooling] Create a UML-RT Transition using the tool palette in a state machine diagram. There is also no kind implied there

Would there be any added value (except for the tests) to update that method to follow the rules, and for example create by default entry/exit points? If yes, what should be the APIs there? 
1. createTransition(targetVertex, TransitionKind)?
2. createExternalTransition(targetVertex), createInternalTransition() & createLocalTransition(targetVertex).
The other way of formulating this: are there any other interested parties involved in the definition of the creation methods? And what would be there constraints / wishes?

Cheers,
Rémi 
--
Remi Schnekenburger
Senior Software Architect / General Manager
EclipseSource Paris

Email: rschnekenburger@eclipsesource.com
Web: http://eclipsesource.com/paris
Mobil: +49 89 21 555 30 - 25 
Phone: +49 89 21 555 30 - 25
Fax: +49 89 21 555 30 - 19
Hangouts: rschnekenburger@eclipsesource.com

EclipseSource France SAS
7 rue de la Croix Martre
91120 Palaiseau

General Manager: Remi Schnekenburger
Registered Office: 7 rue de la Croix Martre, 91120 Palaiseau, France
Commercial Register 824 977 516  R.C.S. EVRY
_______________________________________________
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




--
Remi Schnekenburger

Senior Software Architect / General Manager
EclipseSource Paris

Email: rschnekenburger@xxxxxxxxxxxxxxxxx
Web: http://eclipsesource.com/paris
Mobil: +49 89 21 555 30 - 25 
Phone: +49 89 21 555 30 - 25
Fax: +49 89 21 555 30 - 19
Hangouts: rschnekenburger@xxxxxxxxxxxxxxxxx

EclipseSource France SAS
7 rue de la Croix Martre
91120 Palaiseau

General Manager: Remi Schnekenburger
Registered Office: 7 rue de la Croix Martre, 91120 Palaiseau, France
Commercial Register 824 977 516  R.C.S. EVRY

Back to the top