This section explains the main concepts handled in Modelio module development.

Identifier

All module’s objects requires to have an identifier assigned to them. While identifier is obviously a low level concept as it is a strong requirement and it is explicitly managed by module developer, it is still worth mentioning.

Modelio uses universally unique identifier (uuid) to internally identifies module’s objects.

The following rules should be strictly enforced, otherwise models can be lost:

  1. Each distinct object should have a unique identifier;

  2. No module’s object should change of identifier between module version.

To generate a new valid identifier, simply launch the following command in Modelio’s script view:


  
1
2
3


  
newElement = modelingSession.getModel().createClass()
print newElement.getUuid()
newElement.delete()

The new identifier will be printed in the Jython view where the module developer can copy it and further paste it in the module.xml definition file of his module.

Note: Modelio Studio users do not have to deal with creating new identifiers and managing them because Modelio Studio does all this for them.

Module

Modules are the Modelio means of extending the metamodel (through the addition of UML extensions) and improving the Graphic User Interface by adding new business ergonomic solutions.

A Module is defined as a set of XML, java and resource files and so on that is packaged in a single compressed archive (file extension: .jmdac). This file can be deployed in user projects and executed in Modelio.

Modules may evolve over time. Therefore, each module have a version identification.
The version identification:

  • is a classical V.R.C version number of the Module (ex: 1.03.01)

  • is used to reference the right module to be run on a specific Modelio version

  • can also be checked at run time for compatibility issues when required

  • is typically used to name the package .jmdac archive (eg: MyModule.V.R.C.jmdac)

Profiles

A profile is a structuring object within a module that contains UML extensions.
A Module may contain several Profiles, however Profiles can’t be nested.

Profiles are typically used to group UML extensions relevant to a particular domain or to a particular family of definitions into ‘categories’ represented by profiles. For exemple, a code generator and reverser module might group its code generation specific annotations into a specific generation profile and group its code reverse specific annotations into a reverse dedicated profile. This kind of approach often makes the maintenance of the module a lot easier.

UML extensions

Most modules provide a specific domain-oriented view of the model. For this purpose, they can provide a set of dedicated annotations which are UML extensions of the metamodel. These extensions are defined and structured in UML profiles. For example, our typical code generator and reverser module would use specific notes to produce method implementation code.

Possible UML extensions that can be defined in a Module are:

Stereotype

A Stereotypes is the means to refine a metamodel class. The Stereotype can be understood as a new metaclass that would inherit from its base metaclass. This interpretation remains an approximation as no real new metaclass is added to Modelio’s metamodel. Stereotype only mimics a metaclass.

Tagged value

Tagged values are declared within a stereotype and, to continue with our previous metaclass metaphor, can be seen as the new metaclass attributes.
Tagged values are typed: they can be boolean or carry information if of string type.

Note types

Note types are specific to Modelio. They are also declared within a stereotype and are used to type the text note associated with a model element. Notes may only contain multiline text.

Property tables

As the name indicates, Property Tables hold properties. The type of a Property Table strictly defines the properties that are stored in a table, their names and, more important, their types.
Property types are richer than those available for Tagged Values (boolean or String) including highly specialized types such as Date, Time, Float and so on.
Property tables and their richly typed properties are intended to replace Tagged Values when a Stereotype has to provided many strongly typed properties. Note that a Stereotype can define only one Property Table type.

Hidden extensions

UML extensions can be hidden from module users, ie they do not appear in the GUI. In this case they act as caches or internal variables. Hidden extensions consistency with model changes should be managed carefully because users don’t have a grip on it.

Module commands

The end-user can interact with the module through commands that are specific to the Module.

There are several different kinds of module commands in Modelio:

  1. Menu commands

  2. Toolbar button commands

  3. Diagram toolbar button commands

  4. Diagram palette button commands

  5. Contextual menu commands

  6. Property view toolbar button commands

The following figure illustrates the different kinds of command.

image
Illustration 2: Modelio kinds of command

Menu and toolbar commands 1) and (2 are global to the application, meaning that Modelio will always display them.

Contextual menu commands (5) appear on user request (right click) in a dedicated sub-menu whose name is the name of the module ("Java Designer" in our screenshot example). They are filtered according to the type (metaclass) of the currently selected model element. For example, some commands will appear only for classes (when a class is selected), while others will be available only when an attribute is selected. This mechanism is automatically managed by Modelio, and no code has to be written for it. However, it can be completed or superseded with specific code to hide or gray out a command under a given context.

Diagram palette commands (4) are filtered according to both the type (metaclass) of the currently selected model element and the type of diagram which is active. For example, some commands will appear only for classes if the currently active diagram is a static diagram, but will be hidden when a class is selected in a component diagram.

GUI features

Modules have GUI features. They can provide their own dialog boxes for some of their specific operations.
Modules are especially rich in this area as they can benefit from modern GUI toolkits like SWT to build such dialog boxes.

Model management

Another important core feature of a Module is model navigation and manipulation. Obviously, after a Module command has been activated by the end-user, and after a dedicated GUI has been popped and used to get further parameters for the command to perform, some processing will be carried out by the Module. This processing of the command will, in most cases, modify the user model.

The Module developer benefits from a complete model navigation and transformation API, known as the MDA-model API and which is a part of the [Modelio MDA API].

See https://github.com/ModelioOpenSource/Modelio/wiki/Modelio-API for a complete description of the Modelio MDA API.

The https://github.com/ModelioOpenSource/Modelio/wiki/Module_service page presents the conventions and principles that were at the origin of the conception of the the MDA-model API, as well as the fundamental rules used to navigate in the model.

Model navigation

The MDA-Model API provides classes and methods that represent the user UML model, and allows you to navigate through it. Each metaclass and each association from the Modelio metamodel has its equivalent counterpart class and accessors in MDA-model.

Transactions

Without getting into advanced implementation details, please note that modifications to the model are transactional. This means that any modification of the model has to be encapsulated into a Transaction that is either committed or rolled back at the end of the modification sequence. The decision to commit or roll back changes in the model is left to the Module developer, who is the only person responsible for such a decision. However, the Module developer can rely on the Audit System integrated within Modelio to help him decide whether or not to commit his ongoing transaction.

Model events

Finally, a Module can receive certain events that indicate, for example, that the model has been modified. By processing these events, the Module can update its displayed views or information or start particular processing. In order to receive events, the Module has to register for those particular events it wants to be notified of.

Runtime Phases

From its deployment into a Modelio user project to its operational use, a module runs through several states that are called runtime Phases.

Runtime phases are very important for the module developer who has to provide the Java code to be executed when certain events occur.

The runtime events that the Module has to deal with at runtime are:

  • Install: when the module archive is installed (unzipped)

  • Selection: when the module is deployed in a Modelio project

  • Start: when a project in which the module has been deployed is opened

  • Stop: when a project in which the module has been deployed is closed

  • Upgrade: when a new version of a module is selected in the current project

Module concepts module runtime states and events
Illustration 3: Module runtime states and events

Peers services

When deployed and run in a project opened in Modelio, Modules have the ability to use the services that are provided by the other Modules that are also deployed and run in the project. These other Modules are named peer Modules, their services, peer services.

As a Module developer, you might have to play two roles:

  • a peer services provider role that leads you to create a model and code that provide peer services to others

  • a peer services consumer, writing code that calls the peer services provided by other Modules

For detailed information about peer services, see https://github.com/ModelioOpenSource/Modelio/wiki/Module_service

<< Previous

Index

How to create a Modelio Studio project? >>