In a nutshell:
GMTF generates an MDA tool to carry out the smooth transformation of models through a rich UI.
Problem Space
In order to minimize the chaos, the product vendors are very fast coming up with standard specifications for industry domain models. For example, telecom industry has proposed a common meta-model for telecom products. Similarly, warehouse tools have agreed upon CWM (Common Warehouse Model).Statistical tools trying to adopt a common Predictive Mark-up Modeling Language (PMML). Rule Engines adhere to Ontology Definition Model (ODM). These meta-models are very often referred as Computational Independent Model (CIM).
All these meta-models are by and large approved and governed by OMG.
Of course, the most popular meta-model formats are UML, XSD and Annotated POJO.
In an attempt to ensure synergy and interoperability between different meta-models, OMG has proposed MOF (Meta-Object Facility).
It’s the responsibility of MOF implementers to provide an API that can convert heterogeneous CIMs into a standard Platform Independent Model (PIM - MOF implementation).
Finally, business analysts and domain specific model developers will be happiest, if they can see their CIMs being magically (I mean graphically) transformed into Platform Specific Models (PSMs) i.e. the vendor specific domain.
Solution Approach
Eclipse outscores all other tools in the universe as far as graphical transformation is concerned! We shall see it happening soon.
To address the problem space mentioned above we propose to leverage the powerful modeling features of Eclipse and build a Graphical Modeling Transformation Framework tool.
The tool aims at providing a robust CIM2PIM and PIM2PSM converter API.
** Detailed tutorial and code-coverage is out-of-scope for this article and will be covered in the future articles.
MDA: The backbone of GMTF Model-driven architecture (MDA™) is a software design approach launched by the Object Management Group in 2001. MDA supports model-driven engineering of software systems. MDA provides a set of guidelines for structuring specifications expressed as models.
Model Driven Architecture takes the following approach:
Then defining the system functionality into platform-independent model (PIM - e.g. EMOF) using an appropriate Domain Specific Language (e.g. eclipse EMF).
Finally, given a Platform Definition Model (PDM - e.g. eclipse GMF vocabulary) corresponding to CORBA, Dot Net, the Web, etc., the PIM is translated to one or more platform-specific models (PSMs - e.g. UML with domain specific stereotype).
Computers can run PSM, using different Domain Specific Languages, or a General Purpose Language like Java, C#, Python, etc.
As per OMG, the meta-models (referring to PIMs) extending from OMG EMOF standard are inter-convertible. XML Metadata Interchange (XMI), designed to streamline data integration, is the common format for representing and interchanging those OMG compliant meta-models.
Phases of transformation
Initial: CIM - initial design time representation of the relationship
between entities in all application domains (e.g. Banking, health, finance, telecom, aerospace)
Intermediate: PIM - runtime in-memory structure in all implementation platforms
Final: PSM - structure of persisted data.
Graphically Editing the PSM: GMTF in action
Visual Representation of PSM
UML is a visual modelling and design language that in recent years has evolved into the de facto standard for specifying and documenting complex, object-oriented software. UML Superstructure specification deals with visualization of various diagrams.
How to persist and manipulate the diagram notations?
A UML diagram may be stored in XMI format, and conversely, a UML diagram may be created from an XMI file. In the following section we will analyze how GMTF provides a solution to this problem.
Leveraging Eclipse APIs to build the GMTF tool Eclipse, the sweetheart of product developers all-over the world, makes it so easy to graphically transform a diverse array of models.
Following steps will help us convert CIM to PIM and then PIM to PSM
Step 1: Create the model transformation API.
The Eclipse modelling world revolves around ECORE framework; a great implementation of OMG's EMOF standard. Here we leverage the following features to generate ECORE model and its controller API from a CIM.
Key features of modelling frameworks (ECLIPSE):
XMI conformance.
Emphasizes Forward Engineering - producing code from abstract, human-elaborated specifications.
Reflective API for create/read/update /delete of model
Persistence API using custom/ECORE serializer
API for converting annotated java model/XSD model/ UML model into ECORE model
Strong implementation of command, adapter, decorator and mvc patterns.
Proactive validation using OCL and post-build validation showing problem markers
Powerful and optimised query API
Robust transaction API for managing multiple resources working on the same model.
Strong correlation with hibernate API.
Auto-synchronization of resource, model, explorers, viewers and editors.
Popular model types
UML, EMF, POJO, XSD, CWM, PMML, WSDL, DB Schema
Step 2 : Visualize the ECORE models Now that we have converted heterogeneous models into ECORE meta-model, the obvious question pops up, “How to visualize the ECORE models graphically?”
Eclipse, the matchmaker has arranged a great marriage between UML meta model (implemented as uml.ecore – the PIM – an extension of OMG’s MOF) and GMF tooling fwk (PDM). The combined soul is lovingly called UML Diagramming Framework (uml2tools plugin)
Eclipse Graphical Modelling Framework (
GMF) is an exemplary implementation
A very rich set of APIs to represent an ECORE model in a graphical editor
Defines standardized model to describe diagram elements
Separates the diagram (view) elements from the semantic (domain model) elements.
Models used to define graphics, tooling, mapping
Code generation targets runtime.
Promotes use of Domain-Specific Languages
Huge range of reusable components (action bars, connection handlers, collapsed components, varieties of shapes, routers, property viewers, navigator actions, toolbars, palette tools) for graphical editors.
Leverages all standard based technologies for command infrastructure, validation, transitioning, object constraint language, reporting etc.
Attempts to follow with the Diagram Interchange specification.
Designed for extensibility
GMF Runtime Architecture
GMF provides a standardized model to describe Diagram Elements
Step 2 can be further broken down into the following sub-steps.
a) The Developer needs to specify what all diagram elements (rectangle, ellipse) to be displayed.
GMF Graphical Definition Model
A platform-neutral model to define:
Figures
Nodes and Child Nodes
Connections
Compartments
Diagram Labels
Figure Galleries allow for reuse:
Share common shapes, labels, connections, etc.
Custom figures to allow any GEF figure
Wizard provides starter definition from any domain ECORE model
b)The developer needs to configure the drawing palette -- GMF Tool Model
c) Map the ECORE model elements with the drawing tools and figures.i.e. during runtime, as you drag n drop a person tool from the pallete on the editor, a rectangle showing the model element Person will be created.
GMF Mapping Model
A model to specify the relationship between:
Domain elements (*.ecore)
Graphical elements (*.gmfgraph)
Tooling elements (*.gmftool)
Allows for audit & metric definitions (both domain and diagram)
Leverages EMF Validation
Domain can be constrained and initialized
Leverages EMF OCL
Wizard provides starter mapping from existing domain, graphical, and tooling definition
d) Finally, specify how you want your code to be generated! Absolutely amazing!
GMF Code Generation Model
A model used to specify code generation parameters
Result of transformed mapping model
Code generation using JavaTM Emitter Templates (JET)
•Substitute provided templates with your own
Alter properties for generation as per domain specific look
Plug-in provider name, ID, package namespace, etc.
Specify runtime options
Print support, validation support, file extension, etc.
Diagram persistence (same or separate from domain)
Tabbed Properties View
Project Explorer (Navigator) support
Hurray! You are done!
The GMTF API infrastructure is ready! (No Coding! Huh.)
Without waiting any longer … just right-click your code generation model and choose
‘generate code’ …
A plethora of features get generated and your graphical editor is ready to render any ECORE model …
GMTF Case Study - Seeing is believing!
Okay, enough of designing and coding. Launch your RCP and here comes the Financial Analysts.
The following picture summarizes how a Financial Analyst can convert a CIM into a finance domain specific model using our GMTF tool.
•Rose UML > UML Ecore PIM > Bank PSM using eclipse GMF PDM
•Annotated POJO > UML PIM > BPMN PSM using eclipse GMF PDM
•XSD > EMF model > Finance PSM
Scenario – 1
In the GMTF tool’s eclipse perspective,
User selects a Finance Models folder of the Finance project in the explorer.
User opens an import wizard to select a model (java /xsd /rose uml /wsdl /db schema/ pmml etc.)
User finishes the wizard:
Behind the scene,
The Model Converter API (Step 1) will invoke appropriate builder (Java2Ecorebuilder /
Xsd2EcoreBuilder/ Uml2Ecorebuilder/ Db2UmlBuilder etc.) to generate the PIM –UML ECORE model.
GMF convert the PIM into the uml superstructures (PSM)
Then the domain specific (Finance/ HealthCare etc.) stereotypes are applied to the uml model in order to obtain a PDM.
Finally GMF persists and displays the PDM using a diagram notational model (an eclipse specific diagram persistence vocabulary).
The PDM (domain specific uml model) is rendered on a graphical editor.
e.g. Java Model / WSDL model transformed into Domain Specific UML model.
Scenario-2
User can simply drag and drop a model on to the graphical editor.
e.g. DB Schema transformed into a Domain Specific UML model
Transformation of persistence Format : CIM2PSM
Sample wsdl model : Initial CIM
>>> transformed into Domain Specific UML model : Final PSM Eclipse
This domain specific uml file now can be imported into any other xmi-compliant uml tools (Rational / EA/ Poseidon etc.).
Only the data "behind" the diagram <uml:Model/>… will be transmitted.
The diagram elements will be recreated by importer tools.
Conclusion
Now that GMTF tool presents a beautiful editor, user can enhance the PDM using powerful like connection handlers, collapsed components, varieties of shapes, routers, property viewers, navigator actions, toolbars and palette tools - to just name a few!
GMF has simply revolutionized the visual model techniques with the mantra “XMI Everywhere!”
GMF is fast emerging as the most popular visual modeling framework to build standard notational, tooling and graphical model compliant to OMG modeling specifications, transforming heterogeneous data into domain specific models.
References
Acronyms
XMI - XML Metadata Interchange
EMOF - Essential Meta Object Facility
PMML – Predictive Markup Modeling Language
ODM – Ontology Definition Model
MDA – Model Driven Architecture
PIM – Platform Independent Model
PDM – Platform Definition Model
PSM – Platform Specific Model
SBVR – Standard Business Vocabulary for Rules
CWM – Common Warehouse Management Model
