Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Objectteams » Role migration - is it really needed?
Role migration - is it really needed? [message #507623] Thu, 14 January 2010 06:46 Go to next message
Eugene Hutorny is currently offline Eugene Hutorny
Messages: 109
Registered: January 2010
Senior Member
I noticed somewhere in your plans to support role migration.

Do you have a good example to illustrate role migration?
One which I seen in the literature IMHO is just wrong modelling:
Quote:

Mary works for The System Enterprise and when she leaves the enterprise a newcomer should be able to continue her work at the state Mary has left it



It is modelled an Mary's role in The System Enterprise is transferred from one person to another. I think this model is missing one distinct entity - Established Post. With this entity the model will look like this:
The System Enterprise has zero one or more Established Post
Position has no behaviour, only state, e.g. it can not act.
When The System Enterprise hires Mary she takes one of vacant position - it can be modelled as a ternary relationship (Company as Employer,EstablishedPost as Position,Person as Employee) or two separate relationships.
When Mary leaves the company, she takes all her belongings but leaves all work-related state in the scope of position.
When a newcomer takes the same position he takes the state kept in EstablishedPost and continues.

What do you think?


Re: Role migration - is it really needed? [message #507767 is a reply to message #507623] Thu, 14 January 2010 15:36 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 1007
Registered: July 2009
Senior Member
Eugene Hutorny wrote on Thu, 14 January 2010 01:46
I noticed somewhere in your plans to support role migration.


Oh please, were did it say it's planned?
It's included since version 1.2.5 Wink
(see http://www.objectteams.org/def/1.2/s6.html#s6.2.e )
Quote:

Do you have a good example to illustrate role migration?
One which I seen in the literature IMHO is just wrong modelling:
Quote:

Mary works for The System Enterprise and when she leaves the enterprise a newcomer should be able to continue her work at the state Mary has left it




My example would be similar: a Lecturer (role) owns a deck of slides.
As the Person falls ill, a substitute is called to act as "the same
Lecturer" with the same slides etc.
Quote:

It is modelled an Mary's role in The System Enterprise is transferred from one person to another. I think this model is missing one distinct entity - Established Post. With this entity the model will look like this:
The System Enterprise has zero one or more Established Post
Position has no behaviour, only state, e.g. it can not act.
When The System Enterprise hires Mary she takes one of vacant position - it can be modelled as a ternary relationship (Company as Employer,EstablishedPost as Position,Person as Employee) or two separate relationships.
When Mary leaves the company, she takes all her belongings but leaves all work-related state in the scope of position.
When a newcomer takes the same position he takes the state kept in EstablishedPost and continues.

What do you think?


Your model obviously works, too. The difference is, whether or not you
are forced by the language to make EstablishedPost explicit.
It may just be very convenient to speak of "the Lecturer" owning the slides,
without explicit distinction whether I'm talking about the EstablishedPost
or the role associated with this post. The light-weight solution may still have
an implicit concept of established posts: these may be variables of the
enclosing team. (It's a common theme that variables can sometimes be
used as a light-weight concept for roles - without the need for
specific role types).

That said, I haven't yet seen any applications of role migration in real world
OT/J code.
Given that the solution uses a special type IBaseMigratable rather than
new syntax this is pretty light-weight and shouldn't bother those who
don't need it Wink

Or do you think this feature makes the language unneccessarily complex
and more difficult to understand?
Re: Role migration - is it really needed? [message #507846 is a reply to message #507767] Thu, 14 January 2010 20:49 Go to previous messageGo to next message
Eugene Hutorny is currently offline Eugene Hutorny
Messages: 109
Registered: January 2010
Senior Member
Stephan Herrmann wrote on Thu, 14 January 2010 10:36

Oh please, were did it say it's planned?
It's included since version 1.2.5 Wink



May be I mistakenly read release notes as a release plan? Wink

Stephan Herrmann wrote on Thu, 14 January 2010 10:36

Or do you think this feature makes the language unneccessarily complex
and more difficult to understand?


Sometimes implementation of a nice feature sacrifice the qualities of others. (That's why I like simple things - I can enjoy their pure beauty Smile )
My fear that the role class may become inconsistent for the migration duration.

[Updated on: Thu, 14 January 2010 20:56]

Report message to a moderator

Re: Role migration - is it really needed? [message #507997 is a reply to message #507846] Fri, 15 January 2010 13:45 Go to previous message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 1007
Registered: July 2009
Senior Member
Eugene Hutorny wrote:

> My fear that the role class may become inconsistent for the migration
> duration.

If you are speaking of low level inconsistency, be assured that we try
hard to avoid this: the migrate methods are synchronized, they don't
accept null inputs etc. Thus you should never see a role with a
temporarily missing base link, or inconsistent state of the internal
role cache (as accessed by lifting and the getRole* group of methods).

If you are speaking of application level semantic inconsistencies,
programmers will always be able to create those. If, e.g., the team
keeps explicit references for a role's base object [1] you will be
able to program situations where you will be surprised to find a
base object that is no longer any role's base object.

[1] it shouldn't - the rules about base import tell you to avoid
mentioning the base class within the team. Do you see how we
care about consistency?

However, in clean designs, no part of the program should reference
both a given role *and* its base object. In such designs you should
see no adverse effect of role migration.

But still, you needn't use the feature and if you don't,
its existence shouldn't affect you at all,
you don't have to pay for it.

Stephan
Re: Role migration - is it really needed? [message #567627 is a reply to message #507767] Thu, 14 January 2010 20:49 Go to previous message
Eugene Hutorny is currently offline Eugene Hutorny
Messages: 109
Registered: January 2010
Senior Member
Stephan Herrmann wrote on Thu, 14 January 2010 10:36
> Oh please, were did it say it's planned?
> It's included since version 1.2.5 ;)


May by I mistakenly read release notes as a release plan? ;)

Stephan Herrmann wrote on Thu, 14 January 2010 10:36
> Or do you think this feature makes the language unneccessarily complex
> and more difficult to understand?


Sometimes implementation of a nice feature sacrifice the quality of others. (That's why I like simple things - I can enjoy their pure beauty :) )
My fear that the role class may become inconsistent for the migration duration.
Re: Role migration - is it really needed? [message #567660 is a reply to message #507846] Fri, 15 January 2010 13:45 Go to previous message
Stephan Herrmann is currently offline Stephan Herrmann
Messages: 1007
Registered: July 2009
Senior Member
Eugene Hutorny wrote:

> My fear that the role class may become inconsistent for the migration
> duration.

If you are speaking of low level inconsistency, be assured that we try
hard to avoid this: the migrate methods are synchronized, they don't
accept null inputs etc. Thus you should never see a role with a
temporarily missing base link, or inconsistent state of the internal
role cache (as accessed by lifting and the getRole* group of methods).

If you are speaking of application level semantic inconsistencies,
programmers will always be able to create those. If, e.g., the team
keeps explicit references for a role's base object [1] you will be
able to program situations where you will be surprised to find a
base object that is no longer any role's base object.

[1] it shouldn't - the rules about base import tell you to avoid
mentioning the base class within the team. Do you see how we
care about consistency?

However, in clean designs, no part of the program should reference
both a given role *and* its base object. In such designs you should
see no adverse effect of role migration.

But still, you needn't use the feature and if you don't,
its existence shouldn't affect you at all,
you don't have to pay for it.

Stephan
Previous Topic:Binary (in)compatibility?
Next Topic:Accessing role class
Goto Forum:
  


Current Time: Thu Sep 18 11:46:09 GMT 2014

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

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