In the next few sections, we will examine the steps to map elements from one domain to another, synchronize them, and display them in the diagrams provided by the target domain. The example we will use maps elements from the Eclipse Plug-in Development Environment (PDE) Plugin model to elements of the UML model.
Let's look at a few basic concepts of the PDE Plugin model. The PDE Plugin model is not an EMF model. Rather, it's just an underlying semantic model to represent Eclipse plugins implemented using plain old java objects (POJO). In Eclipse, a plugin project contains a MANIFEST.MF file as well as an optional plugin.xml file. These files describe various aspects of the project. For example, they contain the ID of the plugin and the ID of other plugins it may depend on. Plugins may depend on other plugins. This is known as a plugin dependency or plugin import. Plugin imports can be added and removed through the "Dependencies" tab of Eclipse's plugin editor. The dependencies list of the plugin that depends on other plugins will be modified.
As explained in the overview section, when mapping from the source to the target domain, we'll need to create references to domain elements using enough properties to uniquely dereference the domain element. To uniquely identify a plugin, we need to know the plugin's IDs and the version of the plugin. To uniquely identify a plugin import, we need to know the plugin being depended on (supplier plugin) and the dependent plugin (client plugin) and their versions. We also need to know what the match rule is. The match rule is a PDE concept that determines the criteria for plugin matching. For example, does the plugin need to be exactly the same as the version specified, or will a later version suffice? We don't need to know about the match rule in detail.
The following table summarizes key properties of the plugin and plugin import domain elements.
| Source Domain Element | Key Properties |
|---|---|
| IPluginBase | Plugin ID, Plugin Version |
| IPluginImport | Client ID, Client Version, Supplier ID, Supplier Version, Supplier Match Rule |
In the PDE model, objects representing the plugin concept implement the IPluginBase interface and objects representing the concept of a dependency between two plugins implement the IPluginImport interface.
When changes occur in plugins (such as a plugin dependency being added or removed), a PluginModelDelta event is fired. Implementors of IPluginModelsListener that have been registered as a listner will receive a modelsChanged() event, and the listener can then perform the appropriate action.
The code below registers a plugin model listener.
PDECore.getDefault().getModelManager().addPluginModelListener(pluginModelListener);
Knowing this will be useful when we synchronize elements from the target model with changes in source elements.
For more information on the PDE plug-in model, please refer to the Plug-in Development Environment Guide.
We'll assume a basic understanding of the model described by the UML 2 standard. If not, at the very least, a basic understanding of the concept of a UML Artifact and a UML Usage will prove helpful.
Conveniently, the IPluginBase and the IPluginImport can be mapped to UML 2 elements as shown in the table below.
| Source Domain Element (PDE Plugin Model) |
Target Domain Element (UML Model) |
|---|---|
| IPluginBase | Artifact |
| IPluginImport | Usage |
The UML Artifact is a UML Named Element and hence has a feature for its name. The plugin's ID property will be stored in this feature. The Artifact also has an EList for its client dependencies, which are the UML Usages that represent the plugin dependencies. This is equivalent to the way in which the dependent plugin keeps track of the plugins that it depends on, and not the other way.
The UML Usage has an EList for clients and another EList for suppliers, and so the plugin client and the plugin supplier will be stored in the respective list.
In this section, we have learnt to distinguish between concrete examples of source domain elements and target domain elements.
The next few sections will describe mapping between source and target elements. We will visualize these source elements onto diagrams containing visual representations of the target elements. Also, we will learn how to implement drag and drop and add context menu items to visualize the source elements onto diagrams, how to handle opening a visualized element, and even how to synchronize the source and target elements with changes made to either of them. In short, we will learn the basic steps required to have a mapped target that's up to date with your source element, visualized onto a diagram!