Model components service

Modelio v3.5

About Model Components

A complete presentation of Modelio Model Components can be found in the Modelio User documentation. However let us remind here their main characteristics:

  • A Model components is an independent, identified and coherent part of a larger model.
  • A Model components is packaged into an individual single file.
  • A Model component has a version number.
  • A Model component has to be deployed in a project for its contents to be available.
  • A Model component’s contents is read-only in the project it has been deployed in.


The model component service provide a programmatic access to the model components of the currently opened project:

  • the model component service interface is IModelComponentService.
  • the IModelComponentService instance can be obtained from the IModuleContext of the module via IModelioServices.

The model component service API provides functions to:

  1. Manage the model components deployed in the project
    1. List the model components of the project
    2. Deploy a model component in the project
    3. Remove a model component from the project
  2. Build a Model component whose definition is modelled in the project
    1. Package a model component defined in the project

Listing the model components

From the IModelComponentService instance, listing the currently deployed model components is straightforward.

2IModelComponentService mcService = myModule.getModuleContext().getModelioservices().getModelComponentService();
4for (IModelComponentDescriptor mcd : mcService.getModelComponents() ) {
5    System.out.println("  - " + mcd.getName() + ", " + mcd.getVersion().toString());

Note the type of the returned values which is IModelComponentDescriptor.
IModelComponentDescriptor is a convenient object that holds the main administrative data about a model component:

  1. its name
  2. its version
  3. its archive name

Listing the existing model components of the current project is typically used to check that a required model component is present and react accordingly if it is not present (warn the user, propose to deploy it and so on)

Deploying a model component

Deploying a model component consists in making its contents available in the current project given its archive. This has to be done once in a project although there is no harm doing it several times except that the operation may take some time.
Updating a model component consists in deploying the next version of an already deployed model component. At the API level this case is treated exactly as an initial deployment.

2IModelComponentService mcService = myModule.getModuleContext().getModelioservices().getModelComponentService();
3File archive = ... // code to get a Java File object representing the model component archive file path
4IProgressMonitor monitor = null; 
6mcService.deployModelComponent(archive, monitor);

The second parameter passed to the deployModelComponent() method is a progress monitor object from org.eclipse.core.runtime, see Eclipse documentation for more details on IProgressMonitor objects. This parameter can safely be null , but of course null will provide no monitoring at all.

Removing a model component

Removing a model component from the currently opened project consists in deleting all the model elements that the model components has brought in the model at deployment time.

This is a quite complex operation that can lead to serious side-effects:
Just imagine that your model is currently heavily using classifiers defined in the model component being removed, to type its attribute associations or parameters. Removing the model component will literally undefine the type of all these elements and most probably somewhat break the model. Furthermore, the removal of a model component might even fail if some elements using it cannot be modified for some reasons.

2IModelComponentService mcService = myModule.getModuleContext().getModelioservices().getModelComponentService();
3IModelComponentDescriptor mcdescriptor = ... // code to get the descriptor of the modelcomponent to remove

Note that there is no available IModelComponentDescriptor constructor and that only values returned by getModelComponents() or deployModelComponent() can be used.

Packaging a model component

Model components are modelled in a Modelio project as a stereotyped artifact (<< Model Component Archive >>) which manifest the model elements to be embedded int he Model Component archive. The transformation of the modelled artifact into a Model Component archive is called packaging a model component.

A Model Component naturally embeds the UML model elements manifest by its defining artifact. However, additional contents can be added to the archive by the modules deployed in the project. Not all modules are able or willing to add some contents to a model component, those who do are called contributors.

During the packaging operations Modelio will query the contributors for the additional contents they want to add to the model component being packaged.

Let’s illustrate all this in a commented code fragment.

 1Artifact artifact = ... // Given: the <<Model Component Archive>> sterotyped artifact representing the Model Component to package
 2File     archive = ...  // Given: the archive file to produce
 4IModelComponentService mcService = myModule.getModuleContext().getModelioservices().getModelComponentService();
 6// Let's collect all peer modules deployed in the project.
 7// This will be useful later to define the contributors
 8IModuleService moduleService = myModule.getModuleContext().getModelioservices().getModuleService();
 9Set<IPeerModule> allPeerModules = new HashSet<IPeerModule>(moduleService.getAllPeerModules()); 
11// Here we could refine the allPeerModules list returned previously by selecting only some of them
14// And now carry out the packaging task
15IProgressMonitor monitor = null;            // Providing a null monitor is safe
17mcService.packageModelComponent(artifact, allPeerModules, archive, monitor);

line 4: get the IModuleService instance
line 8,9: we collect the peer modules that are deployed in the project in order to propose them as contributors to the packaging. Of course what we get here is the complete list of all the modules available in the project, which might be too much.
Most of the times only a few contributions are required, therefore the ‘all peers’ list can be refined before being used for the packaging call.
line 12: some code to refine the contributors list. For example, in Modelio a GUI is used to prompt the user about tha contributors to use.
line 15: the packaging operation can be long. The opportunity is given to provide a IProgressMonitor instance to monitor it. As null value is perfectly safe we use it here to simplify the code fragment.
line 17: this is where the packaging operation is run