Community
Participate
Working Groups
Created attachment 268257 [details] error picture Hi, The state machine diagram does not show any content after adding any transition. How to reproduce: 1- create a simple capsule 2- add a state machine diagram with at least two states and one transition. 3- if you close the diagram and open it again, you will never be able to see the content again, because the following error will be shown. org.eclipse.core.runtime.AssertionFailedException: assertion failed: at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110) at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96) at org.eclipse.papyrusrt.umlrt.tooling.diagram.statemachine.internal.decorators.TransitionDecoratorProvider$TransitionDecorator.<init>(TransitionDecoratorProvider.java:129) at org.eclipse.papyrusrt.umlrt.tooling.diagram.statemachine.internal.decorators.TransitionDecoratorProvider.createDecorators(TransitionDecoratorProvider.java:84) Please note that it starts to happen after adding a transition and without a transition, it works fine. Thanks Mojtaba
The screen shot reveals that the wrong kind of state-machine diagram are being used. Unfortunately there is some confusion regarding how state-machine diagrams are supposed to be created. See Bug 511187 regarding proposed improvements to reduce the consequences of this confusion. The problem here is that an ordinary UML state-machine diagram are being used, and not the specific state-machine diagram customized for UML-RT and Papyrus-RT. The way to create this in Papyrus-RT 0.9 is to use the "UML-RT New Child" menu and right-click on a capsule and choose "StateMachine". This will then create a state-machine, some initial elements (initial psuedostate, a first state and an initial transition between them), and the state-machine diagram is automatically created. It is important to have the state-machine profile applied before doing this, since the menu choice for creating a state-machine is not available unless the state-machine profile is applied. Best to ensure this is to use any of the templates when creating a model, e.g. the "UML-RT for C++" template. So the work-flow in 0.9 is to first create the state-machine, which will automatically create the correct state-machine diagram type. Bug 511187 proposes improvements to possibly also support the work flow where the diagram is created first, which then automatically creates state-machine. But this work-flow is currently not supported in 0.9 (since there is no menu choice to directly create the specific "UML-RT State Machine Diagram"). But I can confirm the exception when following the steps to reproduce and creating an ordinary UML state-machine diagram that is provided by base Papyrus.
This will be fixed by Bug 511187 so can we just close this as a duplicate?
(In reply to Simon Redding from comment #2) > This will be fixed by Bug 511187 so can we just close this as a duplicate? Well, Bug 511187 only reduces the risk of creating the wrong kind of state-machine diagram. The issue with this exception being thrown if someone creates an ordinary UML state-machine diagram with Papyrus-RT will still remain. I just have a feeling that this issue should be looked into to avoid the exception appearing for that scenario (consider if someone wants to mix UML with UML-RT). But I guess that could be moved to future as long as we improve the way state-machines and state-machine diagrams can be created (support both work flows with what is created first).
I check the Bug 511187 description and I am not sure if this exception will be fixed on that bug? It seems it mainly fix the confusion for creating the state machine. We have some state machines designed in version 0.7 using UML state machine and we need to migrate them to 0.9 version. Because of this exception, we can not do that. The only solution is to recreate all state machine after migration.
(In reply to Mojtaba Bagherzadeh from comment #4) > I check the Bug 511187 description and I am not sure if this exception will > be fixed on that bug? It seems it mainly fix the confusion for creating the > state machine. Yes, as I indicated in Comment 3 that bug is only about reducing the confusion and allowing additional workflows where the state-machine diagrams is created first. It is as you say, nothing at all related to this exception as such. > We have some state machines designed in version 0.7 using UML state machine > and we need to migrate them to 0.9 version. Because of this exception, we > can not do that. The only solution is to recreate all state machine after > migration. When it comes to any migration scenarios I am a bit uncertain what can and cannot be supported. We have already had discussion about old models that exist in the Payrus-RT Git repo itself, used for testing and similar, which was created a long time ago before customization of the state-machine diagrams were in place, e.g. with respect to which view point type the diagram is based on. Apart from that there will be further migration scenarios to consider when moving to Oxygen also, see Bug 516138 for example. But if this bug is mainly about a migration scenario, then maybe it should be written as such. My first impression was that it was only about the case when a state-machine diagram had been created wrong. But as you describe it, you have a specific need for upgrading old standard UML state-machine diagrams to UML-RT specific state-machine diagrams. Maybe you should write a specific bug for your migration scenario so that it can be discussed to what extent this can and should be supported?
Thanks for your prompt reply. The bug has two consequences: 1 - Not using the UML state machine in papyrusRT, which is fine and we could follow it easily. 2 - Previously, the UML state machine was working fine(no functionality difference between UML state machine and UMLRT state machine), so that some users such as I used to create UML state machine instead of UMLRT state machine. Because of this bug, those models are useless partially, and to use them we need to recreate the UMLRT state machine diagram for them which is not an easy task. If you want to create another bug to discuss the migration, I am fine with that. However, I think giving priority to this bug and fixing that is a big help to view those model content and try to apply the additional update to make them work. I will attach a sample model which create in 0.8 and I can not use it in 0.9. I did not use any specific feature except UML state machine. Thanks Mojtaba
Created attachment 268270 [details] Sample model created in papyrusRT 0.8 (Just a model)
(In reply to Mojtaba Bagherzadeh from comment #7) > Created attachment 268270 [details] > Sample model created in papyrusRT 0.8 I checked the attached zip-file and it only contains the .di-file from the model. You need to include the .notation and the .uml file as well for it to be useful. May I suggest that you zip together the complete project directory, including the .project file. Doing so requires much less work to import the project into a workspace, i.e. then you can simply do File > Import... and then select "Existing Projects into Workspace" and in the dialog you simply then can select the zip file (which contains the complete project including the .project file). Makes it much easier for anyone that wants to open the sample model. Personally I *always* zip together a complete project in this way when attaching example/sample models to bugs in Bugzilla to make it easier for both myself (when later verifying the bug), and the developer who is going to use the example/sample model.
Created attachment 268274 [details] Sample model created in papyrusRT 0.8 The full project is attached.
(In reply to Mojtaba Bagherzadeh from comment #6) > Thanks for your prompt reply. The bug has two consequences: > 1 - Not using the UML state machine in papyrusRT, which is fine and we could > follow it easily. > > 2 - Previously, the UML state machine was working fine(no functionality > difference between UML state machine and UMLRT state machine), so that some The new diagrams do have some new functionality, such as not showing the stereotypes, decorators for actions and guards, support for inheritance (inherited elements are greyed out), etc. > users such as I used to create UML state machine instead of UMLRT state > machine. Because of this bug, those models are useless partially, and to use > them we need to recreate the UMLRT state machine diagram for them which is > not an easy task. The models are not really useless. The old diagrams may be broken, but the semantic model should still be fine, and in particular, code generation should still work the same. Furthermore, you can manually upgrade the diagrams (in the 0.9 RCP, not the developer version): in the Model Explorer, right-click on the state machine element, select New Diagram->UML-RT State Machine Diagram (it has a yellow icon). This creates an empty diagram. Then you can drag and drop the state machine elements from the Model Explorer into the diagram. You'll have to manually arrange them, although you can use the auto-layout button (it looks like Earth with three squares on top of it, and the tooltip reads "Layout the Current Diagram with Eclipse Diagram Layout"). The automatic layout is far from perfect, but it helps. If you do this, you might have to drag and drop each element separately rather than selecting them all and dropping them, otherwise, multiple copies of some diagram elements might be created. A similar approach can be followed for Capsule Structure diagrams. > If you want to create another bug to discuss the migration, I am fine with > that. However, I think giving priority to this bug and fixing that is a big > help to view those model content and try to apply the additional update to > make them work. > > I will attach a sample model which create in 0.8 and I can not use it in > 0.9. I did not use any specific feature except UML state machine. I'm not sure how big a priority we should give to supporting migration of very old diagrams. After all, we are still in incubation, and there are a lot of other priority bugs for the 1.0 milestone.
Thanks a lot, I did not know about the drag&drop, I will try that. If drag&drop works, It is a very good workaround for migrating models with UML state machine.
Thanks for your comments, I found that the bug is not related to UML state machine and it can be reproduced in UMLRT state machine too if the RTStateMachine profile is not set for the state machine. After setting the profile of the state machine to RTStateMachine the issue is solved (for UMLRT state machine as well as UML State machine) and now I can use my previous models in the version 9.0. To summarize the issue, I think instead of assertion, the PapyrusRT should show a meaningful message regarding setting the profile of state machine to RTStateMachine. Thanks Mojtaba
I can confirm that the exception is no longer thrown if the RTStateMachine stereotype is applied on the state-machine when testing the model attached to Comment 9. So the issue seem to be related to when opening an ordinary UML state-machine in the context of Papyrus-RT. I would suggest even that the ordinary UML state-machine diagram should open without a dialog (and of course no exception). Since it does not have any of the UML-RT specific stereotypes applied (it does not seem to have any of the UML-RT stereotypes applied on any of the elements), it formally is not a UML-RT state-machine. Ernesto, how "strict" have the code-generator been made? Does it even accept an ordinary UML state-machine, without any of the UML-RT stereotypes being applied? I guess that since this model have been used to generate code, the code-generator have been rather "forgiving". But I saw that some of the latest changes to the code-generator it was added functionality to check that stereotypes have been applied correctly to indicate that it is a UML-RT state-machine.
(In reply to Peter Cigehn from comment #13) > Ernesto, how "strict" have the code-generator been made? Does it even accept > an ordinary UML state-machine, without any of the UML-RT stereotypes being > applied? I guess that since this model have been used to generate code, the > code-generator have been rather "forgiving". But I saw that some of the I haven't really tested lately without the stereotypes, but in theory it should work fine. The code generator basically ignores the stereotypes (for state machines only; for structure, stereotypes are needed) except for RTGuard, which is needed, but the rest don't really add anything, so they are not even looked at. Of course, it will assume that the state machine, even if it doesn't have the stereotypes, conforms to the UML-RT syntax, i.e. no orthogonal regions, no transitions "crossing state boundaries", no shallow history, no forks or joins, etc. These assumptions will have some consequences: if there is more than one region, only the first one will be looked at. If a transition crosses a boundary, it will likely end up in a codegen error. Shallow history, forks and joins are just ignored. > latest changes to the code-generator it was added functionality to check > that stereotypes have been applied correctly to indicate that it is a UML-RT > state-machine. I'm not sure which changes are you referring to. Are you talking about the updates to the UMLRTStateMachProfileUtil class in change https://git.eclipse.org/r/96782? I added utility methods such as "isRTState" simply for completeness, to be symmetric with the UMLRTProfileUtil class, but these are not really being used.
(In reply to Ernesto Posse from comment #14) > (In reply to Peter Cigehn from comment #13) > > latest changes to the code-generator it was added functionality to check > > that stereotypes have been applied correctly to indicate that it is a UML-RT > > state-machine. > > I'm not sure which changes are you referring to. Are you talking about the > updates to the UMLRTStateMachProfileUtil class in change > https://git.eclipse.org/r/96782? I added utility methods such as "isRTState" > simply for completeness, to be symmetric with the UMLRTProfileUtil class, > but these are not really being used. Yes, it was exactly those changes I was referring to. I did not look so close regarding whether they actually were used, just saw that they were added to this utility class.
(In reply to Peter Cigehn from comment #15) > (In reply to Ernesto Posse from comment #14) > > (In reply to Peter Cigehn from comment #13) > > > latest changes to the code-generator it was added functionality to check > > > that stereotypes have been applied correctly to indicate that it is a UML-RT > > > state-machine. > > > > I'm not sure which changes are you referring to. Are you talking about the > > updates to the UMLRTStateMachProfileUtil class in change > > https://git.eclipse.org/r/96782? I added utility methods such as "isRTState" > > simply for completeness, to be symmetric with the UMLRTProfileUtil class, > > but these are not really being used. > > Yes, it was exactly those changes I was referring to. I did not look so > close regarding whether they actually were used, just saw that they were > added to this utility class. Right. I added them "just in case" we needed them or we need to enforce the profile, but perhaps we wont, specially if the new façade is fully integrated into the code generator (Bug 511393). However a possible side-effect of such integration might be that pure UML state machines without RT stereotypes may no longer be supported. But I'm not sure. It will require more investigation when that bug is addressed, and of course this will be relevant only if pure UML state machines should be supported.
(In reply to Ernesto Posse from comment #16) > Right. I added them "just in case" we needed them or we need to enforce the > profile, but perhaps we wont, specially if the new façade is fully > integrated into the code generator (Bug 511393). However a possible > side-effect of such integration might be that pure UML state machines > without RT stereotypes may no longer be supported. But I'm not sure. It will > require more investigation when that bug is addressed, and of course this > will be relevant only if pure UML state machines should be supported. Well, that was exactly the reason I asked. Personally I could very well see that the code-generator could be strict and require that the UML-RT stereotypes are applied correctly. We had such discussions earlier related to the RTGuard stereotype. Since the code-generator is specifically for UML-RT, I could very well see that it shall not support ordinary UML state-machines (without any, or only a subset, of the UML-RT stereotypes being applied). But that of course will have an impact on "legacy" models like the one discussed in this bug, that was created prior to any of the tooling for properly creating UML-RT state-machines really were in place in Papyrus-RT, which does not have any, or only a few, of the stereotypes applied. But maybe that is too strict, but on the other hand, the reason why the stereotypes exist is to be able to be strict about UML-RT state-machines.
(In reply to Peter Cigehn from comment #17) > Well, that was exactly the reason I asked. Personally I could very well see > that the code-generator could be strict and require that the UML-RT > stereotypes are applied correctly. We had such discussions earlier related > to the RTGuard stereotype. Since the code-generator is specifically for > UML-RT, I could very well see that it shall not support ordinary UML > state-machines (without any, or only a subset, of the UML-RT stereotypes > being applied). But that of course will have an impact on "legacy" models > like the one discussed in this bug, that was created prior to any of the > tooling for properly creating UML-RT state-machines really were in place in > Papyrus-RT, which does not have any, or only a few, of the stereotypes > applied. But maybe that is too strict, but on the other hand, the reason why > the stereotypes exist is to be able to be strict about UML-RT state-machines. I don't really have a very strong opinion on this other than to say that it is convenient for the user not to have to use the stereotypes, e.g. if the user creates by mistake a normal state machine rather than an -RT one. I would say than in that case, it's on the user if he gets errors for attempting to do non-RT stuff. I think validation should detect whether the stereotypes are applied or not, and issue warnings if not. However, if you feel strongly about the code generator being strict, and issue errors if it doesn't find the stereotypes, I suggest opening a codegen bug. But as I said, that might not be necessary once Bug 511393 is addressed.
(In reply to Ernesto Posse from comment #18) > However, if you feel strongly about the code generator being strict, and > issue errors if it doesn't find the stereotypes, I suggest opening a codegen > bug. But as I said, that might not be necessary once Bug 511393 is > addressed. No, I don't see that this needs to be explicitly driven by any bug. As you say, if Bug 511393 means that the code-generator starts to become a bit more strict when it comes to applied stereotypes, then we just let it become more strict. But I don't see the need to take any explicit steps to make such checks "complete" or that we shall put any additional effort on testing to make it "complete" for all stereotypes.
No migration expectations from a product point of view while in incubation. This will be a requirement for "real" versions. Workaround exists for 1.0. Charles to create release note for 1.0 from comments.
