in the current implementation (0.9), the java ecore model (org.eclipse.gmt.modisco.java/model/java.ecore) is not derived from the GASTM ecore model (org.eclipse.modisco.omg.gastm/model/gastm.ecore). Instead many elements (e.g. Statement or TypeDeclaration) are specified twice.
Beside of the redundancy, I assumed I can write code based on the GASTM model types which is then automatically able to process models extracted with the Java discoverer.
So why are the models not linked and how to achieve compatibility with other discoverers later on?
The MoDisco Java & GASTM metamodels are two different & distinct ones.
The Java metamodel is based on the JDT specification, and the corresponding Java model discoverer allows to automatically get a full Java model out of any Java project(s).
It is specifically targeting the Java technology, and there is currently no plan to deeply modify it.
The GASTM metamodel is the direct implementation of the corresponding specification as defined by the OMG Architecture Driven Modernization Task Force.
It is targeting the generic description of program ASTs independently from any particular language or technology.
Note that MoDisco does not provide any associated model discoverer in its current version.
Having said that, it is still possible to obtain a more generic GASTM model from a previously discovered Java model by implementing a corresponding Java-to-GASTM model transformation (cf. model transformation technologies such as ATL http://www.eclipse.org/atl/).
This transformation component is currently not available in MoDisco, but could be a nice and useful contribution to the project .
We understood the OMG ASTM specification to define a GAST model representing elements of a general OOP language and specialized AST models, extending the GAST model for different languages such as JAVA oder C#. This is because we expected the MoDisco Java model to be such an extending AST model.
Our plan was to implement our tooling in a way that operates as much as possible on the generic level with only small extensions that are language specific.
A transformation should be a manageable task, but what we need is the link back to the source entities and the inventory model. So we would still need a link between the GAST and the Java model. This would lead to an additional linking infrastructure such as a tracemodel in between and the model as well as the processing would become very large for bigger projects
This model is what we are using so far and what we were really happy about.
However, this does not help to provide calculations and analysis in a generic way, which can be reused later one for example for cpp when we develop a discoverer for an cpp2kdm model.
No, I was just mentioning this framework as an example of linking framework between related models.
In your case, you would probably need a different type of support even if following a relatively similar approach.
based on your experience with the OMG GAST model and MoDisco, would you recommend to
* build a java specific AST model (let's call it JavaASTM) which derives from the GASTM and includes the java specific language constructs
* build a transformation to create this model based on the MoDisco discoverer results
Or would you recommend to work on a contribution for MoDisco to adapt the current java ecore model and the current discoverer and code generation to connect the java specific and GAST models as recommended by the OMG specification?
In my opinion, the first solution you proposed is lighter to implement: 1) build a specific extension of the ASTM metamodel for Java and 2) create a model-to-model transformation from the MoDisco java metamodel to this new JavaASTM one.
The second option is an alternative but would require more work as you would also have to implement a new model discoverer.
Talking about easier integration in MoDisco and afterward maintenance of the components, the first option is also preferable.
we started to work on this transformation. Unfortunatly, their is some lack of clarity about the OMG GASTM standard and how to use the model elements. Do you know any existing GASTM instance to take a look on?
Sorry but we currently don't have any GASTM model available in MoDisco. Only the metamodel EMF implementation is provided right now.
Our single reference is actually the official OMG ADM specification: http://www.omg.org/spec/ASTM/
However, it could be great in the future to also provide such model examples as part of MoDisco.