Model API?

The API to the xtUML metamodel is simply the xtUML metamodel viewed as an xtUML model.  Applications that wish to interface are written in xtUML and operate on the metamodel as they would any other xtUML application model.

Almost nobody access the xtUML metamodel with native hand-craft Java.  Of course this is supported, but it is far easier and more portable to build models.

xtUML action language supplies model-level statements that support:

There is a Java API “under the hood in the architecture”, but small amounts of code use it.  To interface with the tool, developers build xtUML models that operate against the xtUML metamodel (using action language) and then translate the models with MC-Java.

The “Java API” will change when we update MC-Java to generate EMF-aware Java.  Once we do this, EMF “stuff” (hand-craft Java and EMF toolery) can operate against the lower level API.  However, developers will continue to interface with the metamodel using xtUML at the model level.  This is cool; all this architectural change, and the user API does not change!

Upon introducing EMF, MC-Java will be modified so that the xtUML metamodel structure will translate into classes based on EObject rather than simple native Java classes.

MC-Java action language translation will be modified so that the ‘create’ statement generates the appropriate EMF constructor rather than the custom native Java constructor used today.  The ‘select’ statements will translate into EMF ‘find’ (or whatever EMF does to search instances of a particular class).  The relationship traversal will be interesting; xtUML action language supports traversal across several relationships of varying multiplicity and conditionality in a single statement.  So, we will likely generate methods on classes that support selecting through them (resulting in an instance or instance set).