Module_concepts
This section explains the main concepts handled in Modelio module development.
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:
-
Each distinct object should have a unique identifier;
-
No module’s object should change of identifier between module version.
To generate an identifier, launch the following command in Modelio’s script view:
1 newElement = modelingSession.getModel().createClass() 2 print newElement.getUuid() 3 newElement.delete()
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, before being packaged in a compressed archive (.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, which is made up of the classical V.R.C version number of the Module (ex: 1.03.01).
The version identification is used to reference the right module to be run on a specific Modelio version. It can also be checked at run time for compatibility issues when required.
A profile is a structuring object within a module that contains UML extensions. Profiles can’t be nested.
Modules also very often 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 Java generator would use specific notes to produce method implementation code.
Possible UML extensions that can be defined in a Module are:
-
stereotypes,
-
note types,
-
tagged value types
Stereotype is the mean to refine a metamodel class. Tagged value are declared within a stereotype and can be seen as metaclass attributes. They can be boolean or carry information if of string type. Note types are specific to Modelio. They are also declared within a stereotype and are used to type text note associated with a model element.
UML extensions can be hidden from module users. In this case they act as caches. In this case extensions consistency with model changes should be managed carefully because users don’t have a grip on it.
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:
-
Menu commands
-
Toolbar button commands
-
Diagram toolbar button commands
-
Diagram palette button commands
-
Contextual menu commands
-
Property view toolbar button commands
The following figure illustrates the different kinds of command.
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. 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.
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.
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 that will, in most cases, modify the user model.
The Module developer benefits from a complete model navigation and transformation API, also known as MDA-model.
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.
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.
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 he wants to be notified of.
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
Illustration 3: Module runtime states and events
The expected behavior of the module, its implementation, and recommended practices are described.
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 here.
See Module developer’s documentation / API documentation wiki for a complete Modelio MDA API description. For the MDA-model part of the Modelio MDA API, this wiki page presents the conventions and principles that were at the origin of the conception of the API, as well as the fundamental rules used to navigate in the model using this API.+