Home » Modeling » UML2 » Inconsistent genmodel behavior
| Inconsistent genmodel behavior [message #1713582] |
Thu, 05 November 2015 09:54  |
 Johan Van Noten
Messages: 87
Registered: July 2009 |
Member |
|
|
Environment: Mars.1 + Papyrus today's Nightly
Disclaimer:
Since my scenario uses UML2 models, afaik the generator model is UML2 specific. Therefore, I post this in the UML2 thread. Would that not be appropriate, please advise on the correct thread to use.
Two questions:
* When following the steps described below, I set some genmodel options and at the end reset them to the original values. The generated code is different in both cases. This behavior makes the genmodel behavior unpredictable from a user point of view.
* I tried to find good documentation about the genmodel options, but unfortunately I can't find it. This makes the adoption of the genmodel more difficult than required.
Scenario:
Below are the steps I followed. Each step is also contained in the attached archive. In order to reuse the provided projects, just rename them by trimming their ".vx" extension.
The general intention of this example is: create a static profile and generate the corresponding code.
v0 - Profile defined, no genmodel yet
v1 - Add GenModel, stick to default settings (only add base package, point model code to /src-gen),
generate Model code,
add static profile definition to the plugin.xml
v2 - Reload GenModel, set the following options:
- Validation Delegates = Process
- Non-API invariants = Process
- Invocation Delegates = Process
--> !! strange: compare the contents of the project (nothing changed, except the genmodel)
v3 - Revert the genmodel settings applied in v2 (coming back to v1), regenerate code
--> !! strange: the code now suddenly changes quite significantly, although from a user's point of view the genmodel is back to the original settings. Comparing the genmodel, it seems that internally it has changed anyway, but a user doesn't see that...
|
|
| | |
| Re: Inconsistent genmodel behavior (own mistake - solution proposed) [message #1713839 is a reply to message #1713829] |
Fri, 06 November 2015 21:50  |
Johan Van Noten
Messages: 87
Registered: July 2009 |
Member |
|
|
Hi Ed,
Thanks for asking me to elaborate on my own stupidity 
Well, imagine the following scenario:
* I have defined a profile and want to make it static, so as expected I will want to create a genmodel to obtain an ecore file and later generate code for it. No problem so far.
* Later, I update some stuff in my profile and want to regenerate code. I learned that some changes are not automatically reflected, so I should reload the genmodel. No worries, rightclick the genmodel's top element, select reload, walk through the wizard, then regenerate, done.
* At some point in time, I realize that I should change one of the options in my genmodel. Well, same procedure: rightclick the genmodel's top element, select reload, walk through the wizard, change the desired options along the way, then regenerate, done.
Ooops... nope. this last step doesn't work... The options are not yet taken into account. After you get the opportunity to change the options, no automatic reload happens anymore. You have to manually select "Load".
In my case, I forgot to click Load (assuming that the reload would happen automatically) and therefore experienced "strange behavior": my options seemed not to be taken into account.
Confused as I was, I then thought I was selecting the wrong options, so changed some other options during a next "reload" and suddenly I saw the behavior I expected from my previous selections (since those were previously saved, but never got applied till now).
So, in my opinion, the user should end up in a consistent and predictable state at the end of the wizard, whatever the user does (an invariant in sw terminology).
This is not the case in the wizard's current implementation (or I am still misinterpreting the wizard's functionality).
A user can currently select some options during the wizard, click "Next" till finish and end up with:
* His options saved in the genmodel
* The reload action not taking those options into account
--> This causes an inconsistent state.
Therefore, I suggested to make sure that a user's option updates are always applied in a "reload" action within one reload wizard session.
This can be done by:
* either refuse "Next" if the user modifies options, until the user manually clicks "Load"
* or automatically re-reload on "Next" if the user has modified any options
What's your opinion on this?
Johan
|
|
|
| Re: Inconsistent genmodel behavior (own mistake - solution proposed) [message #1713851 is a reply to message #1713839] |
Sat, 07 November 2015 06:59 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
I'm fairly sure there is something to address, but without an accurate
repro it could be a variety of problems.
a) are you talking about OCL2Java; OCL codegen retained the first CG
attempt in memory inhibiting some later changes; fixed in Mars.
b) are you talking about UML2Ecore options
c) are you talking about ordinary Ecore GenModel content; has got much
more 'dynamic' recently
d) are you talking about extended UML2 GenModel content; should have got
much more 'dynamic' recently
e) are you talking about profile re-definition/re-application; a
misguided attempt at versioning that always confuses me; even worse in
Papyrus
Regards
Ed Willink
On 06/11/2015 21:50, Johan Van Noten wrote:
> Hi Ed,
>
> Thanks for asking me to elaborate on my own stupidity :)
>
> Well, imagine the following scenario:
> * I have defined a profile and want to make it static, so as expected
> I will want to create a genmodel to obtain an ecore file and later
> generate code for it. No problem so far.
> * Later, I update some stuff in my profile and want to regenerate
> code. I learned that some changes are not automatically reflected, so
> I should reload the genmodel. No worries, rightclick the genmodel's
> top element, select reload, walk through the wizard, then regenerate,
> done.
> * At some point in time, I realize that I should change one of the
> options in my genmodel. Well, same procedure: rightclick the
> genmodel's top element, select reload, walk through the wizard, change
> the desired options along the way, then regenerate, done.
>
> Ooops... nope. this last step doesn't work... The options are not yet
> taken into account. After you get the opportunity to change the
> options, no automatic reload happens anymore. You have to manually
> select "Load".
> In my case, I forgot to click Load (assuming that the reload would
> happen automatically) and therefore experienced "strange behavior": my
> options seemed not to be taken into account.
> Confused as I was, I then thought I was selecting the wrong options,
> so changed some other options during a next "reload" and suddenly I
> saw the behavior I expected from my previous selections (since those
> were previously saved, but never got applied till now).
>
> So, in my opinion, the user should end up in a consistent and
> predictable state at the end of the wizard, whatever the user does (an
> invariant in sw terminology).
> This is not the case in the wizard's current implementation (or I am
> still misinterpreting the wizard's functionality).
> A user can currently select some options during the wizard, click
> "Next" till finish and end up with:
> * His options saved in the genmodel
> * The reload action not taking those options into account
> --> This causes an inconsistent state.
>
> Therefore, I suggested to make sure that a user's option updates are
> always applied in a "reload" action within one reload wizard session.
> This can be done by:
> * either refuse "Next" if the user modifies options, until the user
> manually clicks "Load"
> * or automatically re-reload on "Next" if the user has modified any
> options
>
> What's your opinion on this?
>
> Johan
>
|
|
|
| Re: Inconsistent genmodel behavior (own mistake - solution proposed) [message #1714293 is a reply to message #1713851] |
Wed, 11 November 2015 13:21 |
Johan Van Noten
Messages: 87
Registered: July 2009 |
Member |
|
|
Hi Ed,
Sorry for my silence. I just returned from abroad...
I'm not sure how to choose between the options you propose (I can't correctly situate each one of them).
Therefore, I'll include a simplified step-by-step approach as you requested, based on the attached project "com.ecme.myprofile".
The project is attached in a "consistent state": the contained generated code corresponds correctly to the options in the profile's genmodel.
Now follow my "wrong" workflow:
* Open the genmodel with the "EMF Generator" editor
* Right-click the top-level element and select "Reload"
* Walk through the wizard till you see the "UML Import" page (you will see warnings, but these can be ignored as described in the manual)
* Modify the "Invariant Constraints" and "Validation Delegates" properties from "Ignore" to "process".
* Press Next and finish
* Right-click the top-level element again and select "Generate model code".
--> You observe no difference in the generated code, although relevant options have been modified.
* Right-click the top-level element again, select "Reload"
* Now walk through the wizard without any modification at all.
* Right-click the top-level element again to "Generate model code".
--> Now you observe the previously expected differences in the generated code, although in this iteration you didn't modify any options anymore.
Conclusion:
Although not strictly "wrong", this behaviour is very confusing.
As described in my previous comment, it would be much clearer if the genmodel reload ends with an invariant: the options and the reload result should be in sync whenever the user finishes the wizard.
If you agree with my opinion, I will submit a corresponding bug, I guess on the UML2 project since I suppose the "UML Import" part of the genmodel wizard is UML2 specific. Right?
Thanks,
Johan
|
|
|
| Re: Inconsistent genmodel behavior (own mistake - solution proposed) [message #1714648 is a reply to message #1714293] |
Sat, 14 November 2015 22:04 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
'Although not strictly "wrong", this behaviour is very confusing.'
You seem very tolerant. It seems strictly wrong to me.
[I have never really understood the "Load" button. I usually Reload from
the Package Explorer menu and never know whether I need to "Load" or not.]
Regards
ed Willink
On 11/11/2015 13:21, Johan Van Noten wrote:
> Hi Ed,
>
> Sorry for my silence. I just returned from abroad...
>
> I'm not sure how to choose between the options you propose (I can't correctly situate each one of them).
> Therefore, I'll include a simplified step-by-step approach as you requested, based on the attached project "com.ecme.myprofile".
>
> The project is attached in a "consistent state": the contained generated code corresponds correctly to the options in the profile's genmodel.
>
> Now follow my "wrong" workflow:
> * Open the genmodel with the "EMF Generator" editor
> * Right-click the top-level element and select "Reload"
> * Walk through the wizard till you see the "UML Import" page (you will see warnings, but these can be ignored as described in the manual)
> * Modify the "Invariant Constraints" and "Validation Delegates" properties from "Ignore" to "process".
> * Press Next and finish
> * Right-click the top-level element again and select "Generate model code".
> --> You observe no difference in the generated code, although relevant options have been modified.
>
> * Right-click the top-level element again, select "Reload"
> * Now walk through the wizard without any modification at all.
> * Right-click the top-level element again to "Generate model code".
> --> Now you observe the previously expected differences in the generated code, although in this iteration you didn't modify any options anymore.
>
> Conclusion:
> Although not strictly "wrong", this behaviour is very confusing.
> As described in my previous comment, it would be much clearer if the genmodel reload ends with an invariant: the options and the reload result should be in sync whenever the user finishes the wizard.
>
> If you agree with my opinion, I will submit a corresponding bug, I guess on the UML2 project since I suppose the "UML Import" part of the genmodel wizard is UML2 specific. Right?
>
> Thanks,
> Johan
>
|
|
|
Goto Forum:
Current Time: Fri Apr 19 22:09:48 GMT 2024
Powered by FUDForum. Page generated in 0.03850 seconds |
] 
Search
Help
Register
Login
Home
