| Introduction
Joint Command, Control and Consultation Information Exchange Data Model JC3IEDM is a
standard for the so called joint operational concepts.
It holds all the necessary information to be exchanged in coalition or multinational operations.
The program is managed by the Multilateral Interoperability Programme (MIP).
Each participating nation has to implement this standard in its related applications.
The participating countries have their own command and control information systems.
Changes and extensions in JC3IEDM have their impact to the national systems,
which implement this standard. In this context the reaction time of the national systems to
adopt the changes in JC3IEDM is crucial for the success of the national systems.
Through a model driven approach, in which change management and access code generation occur
automatically, a minimum time for adoption after changes in the basis model is achieved.
Problem
There are three main challenges. Those are high complexity, size of the models,
and the heterogeneity of the modelling languages. It is not trivial to bridge or convert the instances of JC3IEDM and C2IS to each other.
We first aimed of using JC3IEDM as our national data model and planed to reverse engineer an UML model for the C2IS application,
but the JC3IEDM is just an exchange format and it´s not optimized as an operative data model.
JC3IEDM´s complexity is caused by the fact that it is trying to express a lot of information all on one dimension.
Mapping a usual object model or data model to the JC3IEDM is very complicated.
The second difficulty is the constraints of JC3IEDM.
There are formally defined coded rules in Admin-DB and about 120 Rules described in several MS-Word documents,
which also have to be handled by the system.
The third problem is the change management.
The changes on the MIP site cause mostly changes on the C2IS site.
Change on any of these two sites will cause changes of conversion rules.
The mentioned problems lead to a lot of different kinds of concerns.
These concerns make up the complexity. In order to cope with the complexity,
we need to apply the principle "separation of concerns".
Actually, it is the key principle of software engineering to cope with complexity and achieve the required software quality.
In MDA context, different concerns are represented by models.
We decided to use models and model transformations to achieve our goals.
Proposed Solution
We developed an eclipse based Tool named datX4MIP which means "data exchange for MIP".
The overall idea is to derive an object model from the JC3IEDM using pattern oriented refactoring.
The derivation process is supported by datX4MIP.
The tool shall also produce the mapping information between the object model and its original source model JC3IEDM.
The national extension can be modelled in another model.
The national object model can have references to the MIP-Object model.
These two models will be merged into a single object model for the C2IS application.
Then a O(bject)/R(elational) Mapping tool can be used to generate the database schema and the persistence layer.
With the mapping information produced by the tool,
we can generate the bi-directional transformation between the instances of these two parts: MIP part and national C2IS part.
One of the important issues in a MDA oriented approach is tool support.
The main idea of MDA is to use model transformations to get a run-time component successively.
Here the run-time component is program code.
This approach can only be successful if at least a great part of these transformations can be done automatically.
Since our main goal is to manage the models, we call the whole effort "model management".
We built our specific MDD-support tool on top of the commercial tool ModelCVS by APG,
which is an ECLIPSE based tool. This product is resulted from the research project "ModelCVS",
in which the Austrian army is also participated.
The application domain of this product´s datX component is data integration between structural world and OO world.
In our case MIP´s JC3IEDM belongs to the structural world, and the national C2IS to the OO world.
Below the datX components and their functionalities.
DEM:
The component DEM is the integration part between JC3IEDM and EMF.
It is responsible for all JC3IDEM specific basic functionalities.
These are:
- Providing a JC3IEDM-EMF meta model and the creation of its instances. Also the visualization of the instance belongs to the functionality set.
- Transforming JC3IEDM-EMF to Ecore. The resulted ECORE model is the base model for the target object model. We call it "Generated Base Model".
- Defining a mapping model for JC3IEDM-EMF and ECORE. The mapping between the derived ECORE model and the original JC3IEDM-EMF is expressed by a mapping model.
- Parsing PDU (Protocol Definition Unit) (stream in JC3IEDM format) and visualization. An incoming JC3IEDM instance is in a stream format.
We applied a parser to parse the stream, added JC3IEDM information to it, and visualized it with an eclipse view.
DEM-T:
This component provides a function for transforming an incoming PDU to
objects of the application and vice versa based on two implementation strategies:
reflection (like "dynamic" code generation) and code generation.
CCM:
- Supports change management process:
A Process Advisor will be provided to guide a model manager through the change management process.
- Offers model operations:
server model operations are important in this process. For example model compare and model merge.
Offering such kind of support is also CCM´s task.
Report:
- This component support report generation.
The reports are such as documentation of models, comparison result of model comparison.
|