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, 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@xxxxxxxxxxxxxxxxx>, 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@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
_______________________________________________
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

Back to the top