- 1 KDM.Source extension : a core metamodel for weaving Code models and KDM Inventory models
- 2 How to create a composition metamodel between Code models and KDM Inventory models
- 3 How to develop a discoverer for the composition metamodel
- 4 Requirements
- 5 Source Repository
KDM.Source extension : a core metamodel for weaving Code models and KDM Inventory models
The component proposes a small framework for building weaving information between code models (Java, C++, ...) and physical resources (disk files and directories).
KDM inventory model also proposes SourceRegion/SourceRef concepts for weaving other kdm models (kdm code models, ...) with physical representation. Some references exist from other KDM subpackages to the SourceRef concept.
MoDisco proposes to compose KDM inventory models with non-KDM models. For technical reasons (generic reuse), a new metamodel extending KDM Source has been created.
A subpart of KDM Source model is extended for linking the SourceRegion concept with non-KDM elements, via the ASTNodeSourceRegion metaclass.
Moreover a recurrent pattern, in such a model composition, is to link KDM SourceFile with a code model element. Such a link is represented with CodeUnit2File metaclass.
How to create a composition metamodel between Code models and KDM Inventory models
Given a particular code metamodel (Such as the Java one), MoDisco proposes to extend KDMSourceExtension to define a metamodel composition between inventory models and code models.
The ASTNodeSourceRegion should be subclassed, and a reference to one concrete code metaclass should "specialize" the ASTNodeSourceRegion->node:EObject reference (one simple way is to set the new reference as derivated from the generic one). (TODO : an opposite reference should be described for allowing navigation from code elements to the SourceRegion instances --> waiting for facet shortcut evolution)
In most cases the CodeUnit2File will be subclassed.
A reference example of such a composition metamodel is the Java Application example.
How to develop a discoverer for the composition metamodel
A discoverer will instantiate elements for the composition metamodel described before. Such a discoverer will have to manipulate the both kdm.source and code models.
A kdm.source model can be discovered using the [KDM Source discoverer]. Note that such a discoverer only provides a representation of files/directories. It does not instantiate SourceRegions subclasses.
A discoverer for the related code model is a prerequisite. The [Java Discoverer] is an example. Such a discoverer is not supposed to instantiate SourceRegions subclasses. To avoid ambiguity, we will talk about it as a "leaf code discoverer".
The composite discoverer should, in most cases, invoke the leaf discoverers (kdm.source and code). Another way is to provide the leaf models as parameters values to the composite discoverer.
Instrumenting the leaf code discoverers for retrieving visited source regions
In most cases, code discoverers have access to physical localization for each portion of code that is modeled.
There are two ways for a composite discoverer to catch such an information when invoking the leaf discoverer :
- subclass some leaf discoverer implementation classes.
- add a listener to the leaf discoverer to listen for source regions visit events.
The second way implies that the leaf discoverer extends the org.eclipse.modisco.kdm.source.extension.discovery.AbstractRegionDiscoverer class to support the registering of org.eclipse.modisco.kdm.source.extension.discovery.SourceRegionVisitListener.
AbstractRegionDiscoverer.notifyRegionSourceVisit must be called when appropriate from inside the leaf discoverer.
The [Java discoverer] implementation class illustrates such a pattern application.
The following figure illustrates the architecture for leaf and composite discoverers related to a CSharp metamodel.
Instantiate source region nodes
Once the composite discoverer has the capability to retrieve information about sources regions visited and associated code model elements, it will instantiate the SourceRegion.
Resources Distribution and memory usage
To use the plug-in you need:
- JDK 1.5 or above
- a version of Eclipse 3.6 or above with the following set of plug-ins installed
- EMF 2.5.0 or higher
All of the source code is stored in a public source repository, which you can access at: