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 relative form.

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 option)
- 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 granted, otherwise the access is allowed if the action is selected for:
- the community [refers to every user defined in the OBEROn database]
- 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

- 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 sides (note)
- 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 of them.

The same result can be obtained with the following OOQL command :