Hi everybody,
During our last application design, I have
encountered the following issue and I don't know if Orion can handled it in
a specific manner:
I have a hierarchy of users that consists of 3
levels: Class, Group, User. A class can contain one or more groups, a group can
contain one or more users. For instance, an instance of Class can be
"professor", an instance of Group can be "chemistry professor", and an instance
of User can be "John" (John is a chemistry professor). We have 1..* relationship
for each of the 3 levels. Of course, these are entity beans. Furthermore,
we have another entity bean, called Role. The ideea is that every User
can have a Role in an application (for instance, John can be a
SystemAdmin in an application), but also, a Group or a Class can have
one or more Roles (instead of assigning a Role to every User in a Group or
a Class, we assign the Role to the whole Group or Class, saving a lot of
time this way, thus all the User in the respective Group or Class will have
that Role). For all the Roles, we need to keep the id of the person(s) to
whom the Role was assigned. But only at run-time I can find out
the type of the component in the user hierarchy (either Class, Group, or User),
to which the role has been assigned. In other words, an attribute
in class Role has to store a value that is sometimes an instance of Class,
sometimes an instance of Group and sometimes an instance of User.
Analyzing this issue, we came along with this
diagram:
1 *
Abstract being ----------
Role
| inherits
--------------------------
|
|
|
|
|
|
Class Group
User
1 ------- *
1----- *
How can we achieve this in Orion? Is it
possible?
Thank you for your time,
best regards,
George.
|
- RE: Design strategy George Mardale
- RE: Design strategy Alex Paransky
- RE: Design strategy George Mardale
- RE: Design strategy Owen Fellows
- Re: Design strategy George Mardale
- RE: Design strategy Shields James
- Re: Design strategy Daniel Lopez
- RE: Design strategy Simon Evans
- RE: Design strategy Alex Paransky
- Re: Design strategy George Mardale
- RE: Design strategy BRICKER_JONATHAN_E