Links

Introduction

Two types of link between modeling elements can be distinguished:

· links which necessitate the prior check-out of all linked elements (this is the case for non-oriented links)

· links which only necessitate the check-out of the origin elements (this is the case for oriented links)

Adding non-oriented links

In the case of non-oriented links, all linked elements must be checked out before the creation of the link within the model.

The types of link concerned are:

· associations and aggregations between classes, nodes, components, objects, etc.

· communication links between actors and use cases

· DataFlows between packages, classes, …

Note: If you want to add an association between two classes belonging to two different packages, then you must carry out a check-out either on both the classes, or on the package for one of the classes and then on the class belonging to the other package, or on both the packages.

A typical example of this is where work is carried out on a package, where it is then necessary to add a link towards a class belonging to another package.

Adding oriented links

Where oriented links are concerned, only a check-out of the origin element is required.

The types of link concerned are:

· generalizations between packages, classes, actors, use cases, nodes, etc.

· dependencies between packages, classes, actors, components, etc.

· implementation links between classes, components and interfaces

For this type of link, other than the check-out of the origin element, no particular precautions are necessary.

Deleting links between elements

The same recommendations must be taken into account when links between elements are deleted as when they are added.

For oriented links, a check-out of the origin element must be carried out before deletion.

For non-oriented links, a check-out of the origin and destination elements must be carried out before deletion.

Link circularity problems

After "concurrent" model modifications, it is possible to produce circular dependencies between packages.

Example:

On a model which has two packages, P1 and P2, a user U1 carries out a check-out on P1, adds a dependency from P1 to P2 and then carries out a check-in. During this time, a second user, U2, is carrying out the opposite operations. The result of these modifications renders importing an update impossible, since Objecteering displays an error message, due to the mutual dependency between packages.

To correct this type of problem, one of the users should simply re-execute the check-out of his package and replace one of the circular dependencies by a reference link.

Reference links are not graphically visible, but can be entered using the icons situated in the central column of the explorer. They are used by Objecteering to calculate visibility between modeling elements, but are not checked for circularity.

Once a model containing all the modifications has been built, we recommend that you review this model, in order to check that the circularity (now with referencing) is not linked to the incorrect structuring of the applications.