Version 3 of Modelio introduced the concept of model fragments, and projects made up of these fragments. The distribution of these model fragments via the network opened the way to World Wide Modeling technology (WWM). By composing the same set of model fragments in different ways, it became possible to give each and every participant in the organization the exact project view which corresponds to his/her activities. Like the web, there is no “central server” with WWM. The organization is highly decentralized, which allows the most open and agile cooperation modes.
When the number of fragments, users, roles, projects and their combinations increases, Constellation provides a solid tool support for their daily management:
These questions are related to project/fragment portfolio management, and more generally to governance issues. This is where the main Constellation functionality comes in: organizing and managing collaborative (distributed) World Wide Modeling projects, both with regard to the content of these projects and to the management of the teams and individuals who work on them (rights, viewpoints on the project, and so on.).
A minimum level of familiarity with the main concepts of Modelio 3 is required to fully understand the benefits of the Constellation solution. The following links provide a quick but essential reminder of the main concepts and characteristics of Modelio 3. They can be skipped by skilled Modelio users.
A user is a person who will interact with a Constellation solution. However, this basic definition covers many different situations that will be made clearer below.
Catalog of users
The catalog of users of Constellation contains all the people known to the Constellation server. A user is typically defined by his/her name, first name and login name. Additional user data can be provided, such as an email address or even a picture.
Classification of users
Constellation distinguishes between Modelio users and Constellation users.
Modelio users are users working with Modelio Modeler. From Modelio, they mainly open, modify and close projects. To become a Modelio user, a user must be enrolled in at least one project. The enrollment of people in a project grants them the right to join and work on the project.
Constellation administrators are users working with Constellation administration tool, ie Constellation’s administration Web pages. These pages are used to configure projects, add users or fragments, and so on.
A Constellation administrator may have only limited access to Constellation administration pages, depending on his/her attributed administration role (see Administration roles for full details).
For now, just remember that a user becomes a Constellation administrator by being assigned an administration role, and that this role defines which administration operations he/she is allowed to carry out.
Of course, a person can be a Modelio user or a Constellation administrator or both.
A Constellation project is a Modelio project whose definition is established in one place, the Constellation server itself.
The configuration of a project in Constellation includes all the configuration elements of a Modelio 3 project (see [Modelio 3 Projects]) plus the list of the users who are enrolled as contributors to the project. Only contributors to a project are allow to open and modify it.
This allows Constellation to manage both the contents of the project and the team working on the project.
More about Constellation projects…
Constellation mainly manages several catalogs: projects, users, fragments. These catalogs are “flat”, in other words, they provide neither organization nor partitioning. This can become an issue when a Constellation server is used by several organizations who do not expect to share information about their respective projects.
For example, several departments of a given company might not be allowed, for reasons of confidentiality, to see each other’s projects.
Therefore, in Constellation, projects and users are attached to a domain.
Domains are mainly named groups of projects and users. They have one or several administrators who are in charge of managing them. Domains are used to partition the Constellation catalog and administration commands.
This partitioning also establishes certain visibility rules between projects, users (and fragments), and enables or forbids certain combinations of them.
As a general rule of thumb, one might consider that each domain is an independent closed space, and that no relationship can be established between objects that belong to distinct domains (unless special arrangements are made).
Please note that:
In constellation a User can be enrolled in a Project meaning that the user can work on the project. Efficient project management requires that all users are not equal when working on a Project in terms of what they are allowed to do or not.
Therefore, what can be done by a given user on a given project is defined by the user’s rights on the project.
For the users' rights to be effective and controlled, the user must provide some authentication data, most often a user name and a password. For this reason, each user in Constellation has a native login (a user name and password pair) that is recorded for him in the Constellation server.
The native login will be required from a user when he joins a Project or opens a Project he has been enrolled in.
There is currently no exception to this behavior although Modelio can be asked to locally store this authentication data to avoid the burden of re-entering user and pass each time the project is opened. However locally storing the authentication data clearly weakens the security.
Right now, let’s retain that any user is at least authenticated when opening a project and that his rights are controlled from this authhentication.
In Constellation, users are enrolled in a Project under a Profile.
The Profile defines which fragments of the project will be seen by the user along with the rights that are to be granted to him.
In most cases, several users enrolled in a project share the same Profile for the very good reason that they have similar activites and responsabilities in the project. Profiles are then used to organize the project team.