Community
Participate
Working Groups
As can be noted from the Papyrus-RT forum, user's following the getting started guide at https://wiki.eclipse.org/Papyrus-RT/User/User_Guide/Getting_Started is instructed to create a state-machine by *first* creating the diagram. Apart from the user's guide being based on 0.7 and really should be updated, this causes a standard UML state-machine to be created, without any of the Papyrus-RT specific customizations. I do know from experience helping other user's as well, that this seem to be a common mistake. To avoid this there are a number of options: 1) Remove the choice of creating the UML standard StateMachine diagram coming from Papyrus, i.e. remove the menu choice New Diagram > StateMachine Diagram when right clicking on a Capsule 2) Make it possible to create a UML-RT State Machine Diagram, i.e. add menu chice New Diagram > UML-RT State Machine Diagram, to make it clear for user's that there is indeed a separate kind of UML-RT state-machine diagram, in the corresponding way as we already have New Diagram > UML-RT Capsule Structure Diagram. I really think that option 2 shall be done. The behavior of this should in practice be exactly the same as using New UML-RT Child > StateMachine, i.e. the same structure should of course be maintained and the state-machine diagram shall be nested/owned by the state-machine itself (even though the user did the selection of creating the diagram by right-clicking on the capsule). If the capsule already owns a UML-RT state-machine, then the choice of New Diagram > UML-RT State Machine Diagram should be removed, in the corresponding way as it is done the New UML-RT Child > StateMachine menu choice. Option 1 might not be needed in case we do 2. If we don't do 2, then we definitively need to do 1, to avoid the mistakes seen on the forum, and which other new user's have made. If we do 2, then we can hopefully skip 1 and keep the creation of ordinary Papyrus diagrams "as-is". All this on the other hand raises the question how the domain specific menu choices shall be structured. Currently we only have a UML-RT specific new child menu. There is a proposal to introduce a UML-RT specific New Relationship menu, see Bug 507277, but currently they are intermixed on the standard "New Relationship" menu, e.g. the creationg of the generalization relationship to establish inheritance. But with the discussion in this bug related to New Diagram, the question is also how we shall handle the creation of UML-RT specific diagrams. Should they also be on a specific "New UML-RT Diagram" menu, or should we continue with this "intermixing" of both Papyrus UML diagrams with the UML-RT specific diagram, causing this "confusion" about which diagram to create?
As an extension to this bug, it could also be considered if the UML-RT Capsule Structure Diagram also should be included in the scope, i.e. maybe the same principle that the user shall be able to create a diagram, which then it its turn first creates the capsule, with the diagram owned/nested within it as usual.
(In reply to Peter Cigehn from comment #1) > As an extension to this bug, it could also be considered if the UML-RT > Capsule Structure Diagram also should be included in the scope, i.e. maybe > the same principle that the user shall be able to create a diagram, which > then it its turn first creates the capsule, with the diagram owned/nested > within it as usual. As far as I remember, we had some issues with the commands to create the diagrams and the elements in core Papyrus. It was quite impossible to override / modify the kind of elements to be created on the fly during diagram creation and the conditions for the creation of a diagram. The switch to Oxygen and Architecture Framework viewpoint switch may be the opportunity to update those commands and make them more extensible and subject to filters based on active viewpoints for example.
(In reply to Remi Schnekenburger from comment #2) > As far as I remember, we had some issues with the commands to create the > diagrams and the elements in core Papyrus. It was quite impossible to > override / modify the kind of elements to be created on the fly during > diagram creation and the conditions for the creation of a diagram. > The switch to Oxygen and Architecture Framework viewpoint switch may be the > opportunity to update those commands and make them more extensible and > subject to filters based on active viewpoints for example. Okay, if there are such limitations I don't think that we should spend too much time on this, unless it is obvious how to solve it. It was just a proposal to reduce the apparent "confusion" that exist regarding the creation of UML-RT specific diagrams. I think that the main focus and main scenario still should be that you create the capsule (which then automatically creates its capsule structure diagram), not the other way around. But for user's who are more used to *first* create the diagram, such a work flow of course is of course good if it can be supported also.
(In reply to Peter Cigehn from comment #0) > As can be noted from the Papyrus-RT forum, user's following the getting > started guide at > https://wiki.eclipse.org/Papyrus-RT/User/User_Guide/Getting_Started is > instructed to create a state-machine by *first* creating the diagram. Apart > from the user's guide being based on 0.7 and really should be updated, this > causes a standard UML state-machine to be created, without any of the > Papyrus-RT specific customizations. I do know from experience helping other > user's as well, that this seem to be a common mistake. <...SNIP...> I'm almost done with the 0.9 version of the Getting Started Tutorial, which will resolve this problem. I do, still, support this bug for the reason listed by Peter (and that I have seen an example of the "diagram creation first" approach just yesterday...). I'll leave the solution and implementation discussion to the development team.
(In reply to Charles Rivet from comment #4) > (In reply to Peter Cigehn from comment #0) > > As can be noted from the Papyrus-RT forum, user's following the getting > > started guide at > > https://wiki.eclipse.org/Papyrus-RT/User/User_Guide/Getting_Started is > > instructed to create a state-machine by *first* creating the diagram. Apart > > from the user's guide being based on 0.7 and really should be updated, this > > causes a standard UML state-machine to be created, without any of the > > Papyrus-RT specific customizations. I do know from experience helping other > > user's as well, that this seem to be a common mistake. > > <...SNIP...> > > I'm almost done with the 0.9 version of the Getting Started Tutorial, which > will resolve this problem. I do, still, support this bug for the reason > listed by Peter (and that I have seen an example of the "diagram creation > first" approach just yesterday...). > > I'll leave the solution and implementation discussion to the development > team. Note that the 0.9 version of the Getting Started tutorial is live on the wiki.
I am seeing similar behaviour with Papyrus, so this may be a Papyrus issue. The best approach seems to be to create a state machine diagram and let it create the statemachine - this seems to consistently provide good results (at least in Papyrus). This should be placed in a release note (and in a FAQ?). Someone should try to validate whether this is a Papyrus issue and, given the case, create a Papyrus bug to address it. Observation: I got a lot of cases of Papyrus hanging when trying various combinations while trying to replicate the bugs in base Papyrus. There are still a lot of instabilities there.
Charles to update tutorial and provide documentation and release note.
Release note is not necessary for this bug. Will be addressed in tutorial (and, by extension, documentation.
v1.0 of the Getting Started with Papyrus-RT has been updated.
Closing...
