Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » Inconsistent genmodel behavior
Inconsistent genmodel behavior [message #1713582] Thu, 05 November 2015 09:54 Go to next message
Johan Van Noten is currently offline Johan Van NotenFriend
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 #1713793 is a reply to message #1713582] Fri, 06 November 2015 16:26 Go to previous messageGo to next message
Johan Van Noten is currently offline Johan Van NotenFriend
Messages: 87
Registered: July 2009
Member
Oops... I discovered a mistake on my side that explains the inconsistencies.

During the reload operation, I mindlessly supposed that the reload happened automatically when walking through the wizard and modifying options.
So, I modified the genmodel options and walked further through the wizard.
But... the automatic reload happens before you have the ability to change any options.
Of course, no modifications happen during that first automatic reload, but the modifications are stored in the genmodel, causing them to become active on the next trial... causing "apparent inconsistent behavior".

Two conclusions:

  • I was stupid Sad
  • Wouldn't it be wise for the wizard to invoke an automatic reload after the options have modified? This feels like a natural flow: the user is in a "reload" action, he wants to reload with different parameters, so a user could forget that the "load" is still manual in that case.

Re: Inconsistent genmodel behavior (own mistake - solution proposed) [message #1713829 is a reply to message #1713793] Fri, 06 November 2015 18:44 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6112
Registered: July 2009
Senior Member
Hi

Bad human factors can also be bugs.

I can't quite follow your 'stupidity' so could you elucidate?

Regards

Ed Willink


On 06/11/2015 16:26, Johan Van Noten wrote:
> Oops... I discovered a mistake on my side that explains the
> inconsistencies.
>
> During the reload operation, I mindlessly supposed that the reload
> happened automatically when walking through the wizard and modifying
> options.
> So, I modified the genmodel options and walked further through the
> wizard.
> But... the automatic reload happens before you have the ability to
> change any options.
> Of course, no modifications happen during that first automatic reload,
> but the modifications are stored in the genmodel, causing them to
> become active on the next trial... causing "apparent inconsistent
> behavior".
>
> Two conclusions:
>
> I was stupid :(
> Wouldn't it be wise for the wizard to invoke an automatic reload after
> the options have modified? This feels like a natural flow: the user is
> in a "reload" action, he wants to reload with different parameters, so
> a user could forget that the "load" is still manual in that case.
>
>
Re: Inconsistent genmodel behavior (own mistake - solution proposed) [message #1713839 is a reply to message #1713829] Fri, 06 November 2015 21:50 Go to previous messageGo to next message
Johan Van Noten is currently offline Johan Van NotenFriend
Messages: 87
Registered: July 2009
Member
Hi Ed,

Thanks for asking me to elaborate on my own stupidity Smile

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 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6112
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 Go to previous messageGo to next message
Johan Van Noten is currently offline Johan Van NotenFriend
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 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 6112
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
>
Previous Topic:View UML diagram on Eclipse
Next Topic:Performance with Stereotypes (UMLUtil.getNamedElement())
Goto Forum:
  


Current Time: Mon Nov 19 03:50:15 GMT 2018

Powered by FUDForum. Page generated in 0.02090 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top