Since Modelio 3, a model is no longer an indivisible block. It is now composed of a set of fragments linked with each other. Some can be edited, others can’t, but all of them are visible in Modelio as a unique model.
The project administrator is usually in charge with splitting the project into consistent work models, as well adding necessary libraries and modules to the project. This dividing is often linked to the model content and to the work organization. The following questions should be asked prior to organizing the project:
It should be noted that even though configuring the accesses is done at profile level, it can influence the splitting of the project in fragments. On the other hand, different technical parts of the project don’t necessarily have to be separated into fragments if they are meant to be used in the same way by the project users.
A project can contain different kinds of fragments, each corresponding to specific needs. Answering the above questions will help the project administrator choose what kind of fragment to add to the project.
| Type of fragment | Distribution | Access mode | Use | Comments |
|---|---|---|---|---|
| Local | Local | Read write | Work model | Simple user |
| SVN | Local, network | Read write | Work model | Team work |
| Model component | Local, network | Read | Library | Managed in versions |
| HTTP | Network | Read | Library | Regular updates |
| Module | Local, network | Read | Library + Commands | Managed in versions |
Local fragments are peculiar to each member of the project, their content is never shared. They’re ideal to make some experiments or to store tests data.
SVN work fragments let several project members work on the same model part.
Read-only model components contain model elements and files in a fixed version, which generally represent external libraries. It is possible to create one from a work fragment to materialize a delivery for example.
HTTP fragments are often used to publish reusable parts of the model as libraries, but not in a fixed version. They offer more flexibility than model components, specifically during intense development phases.
The structure of a project in Constellation is never frozen, of course. It can be modified at any time during the project’s life. The configuration of user profiles also has an impact on the project content for each member as it indicates for each fragment whether it will be visible (and modifiable in the case of work fragments).
In Constellation, the project administrator has the ability to modify the content of the project. The project structure modifications go unnoticed by users, who will benefit from them when opening the project in Modelio.
To configure the content of a project, the administrator can use existing fragments or create new ones. The list of fragments that can be used in a project depends on the following rules:
If the administrator of the project chooses to add a fragment to it, the fragment will be reserved to the project. The fragment is then said to belong to the project. To make it available to other users, the project administrator will have to contact the domain administrator, who has the ability to change a fragment’s affiliations.
See also:
Model components and modules added to a project are always managed in version. It is possible to swap versions thanks to the update commands.
See also:
When a project administrator removes a fragment from a project, it is essential that the impact on other fragment be clear. This means that any reference to model elements belonging to the removed fragment will now be considered missing and be displayed in red in Modelio. This does not cause any malfunctioning of Modelio, but it remains a situation one should avoid as it would trouble users and disturb the behaviour of some modules.
It is a good practice to remove all those references before removing the fragment from the project. If the references can’t be removed without disturbing the model, it means the fragment to be removed is essential and cannot be removed.
See also: