Hello George,
It seems to me that the motivations for having a moment-interval are different than
those
for having a role. A role abstracts very different behaviour through an interface. A
moment-interval retains time based information allowing it to be queried or used as a
basis
for rebuilding a context. Perhaps an example would be in order,
Suppose a security system. You want to see whether a person can perform a certain
action.
Unfortunately, you have several ways of slicing the accesses - managers can perform
certain
operations and see salaries. They can also delegate their operational powers but not
the
right to see the salaries. Moreover the manager-on-duty has extensive powers. In this
system you simply need roles. The employee has no powers but receives them through the
roles he plays - especially when he is the manager-on-duty.
Now suppose that this system requires a historical component. You must be able to
answer
"at time X, these were the rights of employee Y" or "the accumulated time of employee
Y as
manager-delagate was Z". In this case you will need a moment-interval (along with
other
things).
You could probably mix the two by saying, "at this moment-interval, these were the
roles",
but you would have to make sure that the roles did not change.
So:
1) Do you still need a relationship between the employee and the rights? The mechanism
seems adequate. Do you need one between your person and the company? Not to manage
the
employment. You might have a derived one though. This would allow the Person to
answer
"where are you working now?" or the employee to answer "can he touch that button?"
2) Person - Company
Modeling as a Role:
Advantages:
Manages and hides different behaviour because of state or inherent differences
well
Simple to add roles
Allows changes in behaviour in a Role to affect all instances
Disadvantages:
Moderately complex
Only handles the present
Modeling as a Moment-Interval:
Advantages:
Allows rebuilding a chronology
Allows intellegent queries throughout all the hisorical data (after the fact)
Prevents changes in behaviour in a Role from affecting all instances (takes a
little
extra work)
Disadvantages:
Quite complex
Modeling as a many-to-one association:
Advantages:
Simple - why make it more difficult than required
Disadvantages:
No encapsulation - it may seems trivial to implement this but when a class
such as
Person has a dozen relationships like this it tends to become a god-class.
Requires exhaustive search to change rights based on a Role (i.e. if you have
the
concept of a Role, users will expect that the system will simply change all Human
Resource
employees' rights at once.)
--
Neil Pitman
[EMAIL PROTECTED]
+1.514.863.5465
george brown wrote:
> Hello James,
> First, thank you for your reply.
>
> So, we would have 2 choices:
> 1- model it as Employment (i.e. moment-interval)
> Person -(1)------(0..*)- Employment -(1..*)-------(1)-Company
>
> 2-model it as Employee (i.e Role).
> Person -(1)------(0..*)- Employee -(1..*)-------(1)-Company
>
> Or, perhaps, a 3rd one too: hane both Employee and Employment
> 3- have both Employment and Employee.
> Person -(1)------(0..*)- Employee -(1..*)-------(1)-Company
> |
> (1)
> |
> |
> (0..*)
> |
> Employment
>
> Now, questions:
>
> 1- Would we still need to have association between Peosn and Company?
>
> 2- What would be the (dis)advantages of not modeling Employee/Employment as
> an association class?
>
> Thanks.
> George
>
> >From: "Baker, James D" <[EMAIL PROTECTED]>
> >Reply-To: "Baker, James D" <[EMAIL PROTECTED]>
> >To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> >Subject: FW: (ROSE) would anyone give me an detailed explaination of assoc
> >iation
> >Date: Fri, 22 Dec 2000 08:43:22 -0800
> >
> >
> >
> >
> >As I described it, Employment is not a role. It could be a
> >moment-interval.
> >
> >I discussed this issue with Ron Norman, a CCM I'm acquainted with. If you
> >want to model this differently, you could use roles. Both Coad and Martin
> >Fowler, in his writings on analysis patterns, suggest the use of roles
> >where
> >the association has interesting behavior.
> >
> >Ron said:
> >
> >I think it might also be modeled as: Company class (green), Person class
> >(green), and Employee (yellow). Employee would be role played and
> >associated
> >with Person who is associated with Company. Employee could have same
> >attributes as you suggest so long as the role is for a single person
> >working
> >for a single company (roles usually have 0..1 multiplicity between them and
> >their person/place/thing (green) class.
> >Bottom line: depends on the domain requirements one is modeling...sometimes
> >an association class, other times a role. Roles usually only come into play
> >when their behavior (methods) is interesting and different from other roles
> >played by the same or different people/place/thing objects.
> >
> >
> >J.D.
> >My ideas, my words. You can't blame anyone that might employ me for them.
> >
> >
> >-----Original Message-----
> >From: george brown [mailto:[EMAIL PROTECTED]]
> >Sent: Thursday, December 21, 2000 2:21 PM
> >To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> >Subject: RE: (ROSE) would anyone give me an detailed explaination of
> >assoc iation
> >
> >
> >
> >Hi James,
> >Is the association class of Employment conceptually a "role" played by a
> >Person in a Company. I.e. what Coad refers to it in "Java Modeling ...
> >using
> >
> >UML"? I'm not really sure if you've read the book, anyway.
> >
> >Thanks,
> >George
> >
> >
> >
> > >From: "Baker, James D" <[EMAIL PROTECTED]>
> > >Reply-To: "Baker, James D" <[EMAIL PROTECTED]>
> > >To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> > >Subject: RE: (ROSE) would anyone give me an detailed explaination of
> >assoc
> > >iation
> > >Date: Thu, 21 Dec 2000 07:30:02 -0800
> > >
> > >
> > >See if this makes any sense to you.
> > >
> > >If you have a Person class and a Company class, then one association
> > >between
> > >Person and Company might be Employment. Employment has several
> >attributes
> > >you might want to maintain, such as start date, current salary, vacation
> > >days accrued, etc. In this case, the association would be modeled as a
> > >class.
> > >
> > >To generalize from this example, association classes are used when you
> >want
> > >to specify attributes and operations for an association. There is a
> > >constraint placed on the association class that there can be only one
> > >instance of the association class for any set of instances of the other
> >two
> > >classes.
> > >
> > >HTH,
> > >
> > >J.D. Baker
> > >My ideas, my words. You can't blame anyone that might employ me for them.
> > >
> > >-----Original Message-----
> > >From: daniel wang [mailto:[EMAIL PROTECTED]]
> > >Sent: Thursday, December 21, 2000 6:40 PM
> > >To: [EMAIL PROTECTED]
> > >Subject: (ROSE) would anyone give me an detailed explaination of
> > >association
> > >
> > >
> > >hi :
> > > i don't really understand the association class in uml. when i
> >should
> > >make use of them?
> > >best regards
> > >
> > >daniel
> > >
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages:
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************
