-
Notifications
You must be signed in to change notification settings - Fork 127
Modelio_projects_concepts
Most modules manipulate the model or at least navigate in it. However there is no simple “the model” concept in a Modelio project which is itself a concept that has to be clearly understood before any development in Modelio.
This section is a technical glossary and reminder around the Project concept.
Summary :
| Concept | Summary |
|---|---|
the directory where the “user projects” are stored. |
|
directory in the Workspace, holding all the data required to work on that “project”. |
|
UML/BPMN/Analyst model the user is supposed to work on. |
|
UML/BPMN/Analyst model whose all elements are read-only. |
|
Modules are the way to extend Modelio. |
|
one of the root element of a Work Model in a Modelio Project. |
The Modelio workspace is the directory where the “user projects” are stored. This is similar to the Eclipse workspace concept.
To manage its workspace Modelio provides:
-
A dedicated perspective, called the Workspace perspective. It is selected by default when Modelio starts. The perspective displays the workspace contents as a list of projects on the left side of Modelio window, along with a central view showing details about the project currently selected in the project list.
-
A command to switch from the curent workspace to another the workspace
-
A refresh button that updates the list of projects by re-examining the workspace directory contents.
In the context of the Modelio application, a Project represents a particular directory in the Workspace, holding all the data required to work on that “project”. This directory is called the Project space of the project.
Projects are listed in the Workspace perspective. They can be opened, closed, exported and so on…
Once opened, Projects can be worked on, ie their content is displayed and accessible for edition, processing and so on.
An opened Project appears to be a composition of:
-
Work models
-
Libraries
-
Modules
These are the top most elements in the model browser of Modelio.
Warning: A common problem with the term Project is that it is also used to designate a particular metaclass in the Modelio metamodel. Beware of the difference. Where some ambiguity may occur in this document, projects at the application level will be qualified Modelio Project while metaclass instances will be noted Project metaclass.
A work model, as its name let us guess, is a UML/BPMN model the user is supposed to work on. In other words, it is essentially a modifiable and editable model, although practical editability can be conditionned by user’s rights or locking conditions (SVN).
Work models are either local, ie only present on the user’s workstation or remote ie hosted on a server in which case they are managed by SVN and shared by several users.
The contents of a Work Model is always structured as a model tree whose top most elements are called roots.
A work model has up to two roots:
-
A Project metaclass instance containing the UML/BPMN model
-
A ModuleComponent metaclass instance containing the local MDA model (see Modules )
Remember that a Modelio Project can be composed of several Work Models, each of which being a part of the whole project contents (this is why they care sometimes generically called “fragments”)
A Library is a UML/BPMN model whose elements are read-only, ie they cannot be modified. Note that this is different from locked elements in a Work Model which can be read-only at some moments. Library model elements are not expected to be modified in any circumstances, they are by essence non-modifiable in the project.
Most often, libraries are brought in the model under the form of Model Components.
A typical example is the JDK, when you need to model elements based on some JDK classes, you can add the JDK Model Component to your project. Obviously, you do not expect to modify anything in it.
The contents of a Library is structured as a model tree whose root is a Project metaclass instance.
Modules are the way to extend Modelio.
Module mainly bring two things in the module:
-
Modeling extensions called MDA extensions that augment the representation capabilities of the tool by defining Stereotypes and their properties
-
Functional and GUI extensions to Modelio
MDA extensions are model elements too, therefore they are stored in Modules fragments in the Modelio Project.
The contents of a Module is structured as a model tree whose root is a ModuleComponent metaclass instance.
You would now understand why the local module of a Work Model, where local MDA extensions can be defined ‘on the fly’ is rooted in the Work Model as a ModuleComponent metaclass instance.
As seen above, the Modelio metamodel defines a Project metaclass that should not be confused with the Modelio Project concept.
The Project metaclass is one of the root element of a Work Model in a Modelio Project. Project instances has no composition parents, ie they are really top most element in the model tree.
The most important thing about Project instances is their Model relation that gives the concrete access to the model they contains. The getModel() accessor of Project (metaclass) will therefore return a Package metaclass that contains the model elements.