define object connections
In an application context, domain
objects are very often connected together to create a structure.
For example, a product can be decomposed into several structured
parts like assemblies and sub-assemblies or, a book can be represented
by a structure of chapters and pages.
Each node in these object structures is logically interconnected
with others. In OBEROn you can define phisical links between objects
specifying their characteristics with linktypes administration
objects. Linktype definitions should be done after fields and classes.
Users enabled to manage Linktypes (see user
access rights )
can create a new item by clicking the "Add new LinkType"
button from the "Context Design" menu and compile the
When you define a new linktype you should take into
account the following aspects:
- the logical meaning and, therefore, the name and description
of the link
- the faculty to create more than one instance of the same linktype
between two objects (expressed with the duplicable option)
- the possibility to connect an object to itself with this linktype
when both from side and to side allow the same object class (self-link
- the concurrent user action check (check-update option), to avoid that users override the changes when they try to edit the same link instance at the same time (the first user can write, the other users have to reload the object status before performing a new update)
- the possibility to restore the previuos
field values of link instances and main characteristics (holder, active and hidden flags ) after an update operation (undo option) .
- Fields: needed to specify the additional link's properties
for the generated instances
- History Trace : everytime a user executes an action on a link instance, a new record containing the action description,
the event time and the user name, will be added in the history table; this form defines the events to trace for the instances of the current linktype.
- Access Rights : define the user access on a link instances; the user can perform the specified actions if the access for them is permitted:
to the community or
to the holder and the user is the link holder (alternative holder) or
directly to the user or to a user category (team or assignment)
to which the user belong
In particular the access precedence is computed as follow:
- if the user is a superuser, then the access is automatically
otherwise the access is allowed if the action is selected for:
- the community [refers to every user defined in the OBEROn
- the holder [refers to the user who is the current (main/alternative) holder
of the link instance.
The user who created an link it is identified as its holder and
keeps this role unless this qualify is transferred to someone else]
- the user directly
- a team to which the user directly or indirectly (due to
the team hierarchy) belong
- an assignment directly associated to the user or inherited
from a team
||Create a new link instance. Usually this action is allowed for a specific
team or assignment (when links are created, the holder is
the one performing the other actions).
||Allows a user to view the properties
of a link, including field values, the history, etc. If a
user has not the read access he can only see the basic properties
(linktype and class, name, revision, holder, currentstage, lifecycle, locker of both side objects)
while the other will be hidden by a '#####' string.
||Edit the field values of a
||Change the linktype for the link
instance. The operation is allowed if the new linktype is not hidden. Values for fields
that are not in common between the old and the new linktype will
||Change the link holder or modify the alternative holder list.
||Restore back the previous values of link fields and basic properties
||Remove a link from the database.
- From/To Side specifications:
- classes of objects that will be allowed to
connect by this type of link. As a link has two ends you should
define also its direction or, in details, which types of objects
can be connected on the "from" side and which classes
on the "to" side.
- the meaning of the link from the point of view of object on both
- the cardinality for the link at the "from" and
"to" side or, in other terms, you should establish if
the link allows a single object or many objects (multiple)
on the two ends.
- the behaviour in case of object revision or clonation; when an
object at the from/to end is revised or cloned a new object instance
is created, you should define what will happen to the link's instances
of this type when these events occur. The choices for revisions
and clones are: none (when the link is kept on the original
object), move (when the link is automatically moved
on the new revision or clone), and duplicate (if the
link is replicated for the new revision or clone).
When you add a class on the "from" or the
"to" side of a linktype, all derived classes in the class-hierarchy
automatically will be allowed and it is not necessary to add all
The same result can be obtained with
the following OOQL command :
'Rental' !duplicate !selflink checkupdate !undo
'Connects a movie with a customer who have rented it'
create ,edit ,undo
team 'CustomerCare' create, edit
who have rented the movie'
class 'Customer' ;