Skip to main content
Jump to: navigation, search

MoDisco/Components/Composition/Architecture

MoDisco
Website
Download
Community
Mailing ListForums
Bugzilla
Open
Help Wanted
Bug Day
Contribute
Browse SourceProject Set File

Requirements

In this document, we use this terms:

  • composing model: a group of models,
  • composed model: a member of the group of models.

Functional requirements

We need a mechanism to achieve these goals:

  • R1. a composing model groups several models together using model element level links
  • R2. a composing model establishes links between elements of these models
    • 1. links can have different arities
    • 2. links can be considered as elements.
    • 3. links can have sub links.
  • R3. a composing model remain the composed models unchanged
  • R4. a composing model remain the metamodels of the composed models unchanged
  • R5. a composing model is a model describing which models are in the group and which model elements are linked
    • 1. a composing model contains links between model elements
  • R6. a composing model conforms to a meta-model.
    • 1. the metamodel of the composing model defines the meta-links between the meta-classes.
    • 2. each link contained in the composing model conforms to a metalink defined by a metamodel
  • R7. a composed model can be a composing model

As we need to add links starting from elements of the composed metamodels without changing these metamodels, we need :

  • R8. virtual reference which can be added to composed models to be able to navigate links in the opposite way

Our approach is to create, in a new metamodel (the composing metamodel), elements which could be interpreted as additional links between metaclasses of other metamodels (the composed metamodels). Because in the majority of cases, the referred models are conforms to meta-models that have not been designed to be referred. We then need a mechanism to add “virtual” references to the referred meta-models. We need a "virtual add" because referred meta-model can’t be modified in most use cases. And the use of bidirectional references is not recommended to avoid cycle problems.

  • R9. The "virtual" references between model elements should conform to "virtual" links between metaclasses. These "virtual" references, contained in the composing model, should hold all the information required to find the source and the target elements in the composed models.

Non functional requirements

  • R10. To be usable by transformation and generation engine based on EMF.

Functional specification

Composing Model

MoDosco ComposingModel meta-model.png

Figure 1 - ComposingModel meta-model

If ComposingModel is kind of Model, this imply that MetaComposingModel is a kind of MetaModel.

Model element to model element links

In the meta-model presented on Figure 2, the class “Link” corresponds to the "link" concept (R2) and the LinkEnd is used to represent the "different arities" (R2.1). The LinkType class corresponds to the link typing (R6.2). The subLinks reference allows a link to have sub links (R2.3).

ComposingModel’s attribute named “referredModels” is a derived attribute (self.referredModels = self.links->collect(e|e.linksEnds->collect(f|f.referes.eContainer()))).

MoDosco Link meta-model.png

Figure 2 - Link meta-model

The Figure 3 presents the meta-model completed by the following items:

  • a link is a kind of ModelElement (R2.2)
  • a LinkType is a kind of MetaClass ;

MoDosco Main functional class diagram.png

Figure 3 – Main functional class diagram

Summary

Requirement Realization
R1 a composing model groups several models together using model element level links ComposingModel::/referredModels
R2 a composing model establishes links between elements of these models ComposingModel::/links
R2.1 links can have different arities Link::linkEnds [1..*]
R2.2 links can be considered as elements. Link extends ModelElement
R2.3 links can have sub links. Link::subLinks
R3 a composing model remain the composed models unchanged LinkEnd::refers has not any opposite. ComposingModel::/referredModels has not any opposite.
R4 a composing model remain the metamodels of the composed models unchanged LinkEndType::type has not any opposite. MetaComposingModel::/referredMetaModels has not any opposite.
R5 a composing model is a model describing which models are in the group and which model elements are linked ComposingModel extends Model, ComposingModel::/referredModels, ComposingModel::/links
R5.1 a composing model contains links between model elements ComposingModel::/links
R6 a composing model conforms to a meta-model. ComposingModel extends Model. MetaComposingModel extends MetaModel. Model::conforms_to : MetaModel
R6.1 the metamodel of the composing model defines the meta-links between the meta-classes. MetaComposingModel extends MetaModel. LinkType extends MetaClass. MetaModel::metaClasses : MetaClass
R7 a composed model can be a composing model ComposingModel extends Model
R8 virtual reference which can be added to composed models to be able to navigate links in the opposite way VirtualOppositeRef::getLinkedElements(ModelElement)
R9 The “virtual” references between model elements should conform to “virtual” links between metaclasses. These “virtual” references, contained in the composing model, should hold all the information required to find the source and the target elements in the composed models. VirtualOppositeRef, VirtualOppositeRef::opposite1, VirtualOppositeRef::opposite2, MetaComposingModel::virtualOppositeReference

Implementation specification

Model element to model element links

MoDisco is based on EMF. The composed model must then be implemented on the top of EMF. In this document we will assume that the EMF resource is the EMF implementation of the concept of model.

A link (or a LinkType) between to models (or meta-models) can be realized using an EClass containing EReferences referring linked meta-model’s EClass(es). (This also works for unary links.)

MoDisco LinkClass.png

The subLink reference is implemented using a containment reference and links between links are implemented using non-containment reference.

The capability for a resource to refer other resources is already provided by EMF and satisfies the non functional requirements.

Utility API

The functional derived attributes are implemented in a utility class named: org.eclipse.gmt.modisco.infra.composition.CompositionUtils. This class contains the following methods:

  • List<EPackage> getRefferedEPackages(EPackage ePackage)
    • ePackage.eClassifiers->collect(e|e.eReference.eType.ePackage)->asSet()
  • List<Resource> getReferredModels(Resource resource)
    • Returns the resources referred by the resource “resource”.
  • List<EPackage> conformsTo(Resource resource)
    • resource.getContents()->collect(e|e.eClass().ePackage)->asSet()
  • Map<EReference,List<EObject>> getLinkEnds(EObject link)
    • Returns a map referred eObject group by the corresponding EReference excluding eObject referred by a containment reference and excluding eObjects conform to an EClass contained in the same EPackage than the eObject “link” meta-class.
  • Map<EReference,List<EObject>> getReferredLink(EObject link)
    • Returns a map referred eObject group by the corresponding EReference excluding eObject referred by a containment reference and excluding eObjects not conform to an EClass contained in the same EPackage than the eObject “link” meta-class.
  • List<EReference> getLinkEndTypes(EClass linkType)
    • Return the list of eReference owned by the eClass “linkType” excluding eReference having a type contained in the same packade than the eClass “linkType
  • List<EClass> getLinkTypes(EPackage)
    • Returns eClasses for which getLinkEndTypes(EClass linkType) retruns a non empty list.

Virtual references and virtual resources

The virtual add of reference is provided by the MoDisco facet feature.

To be able to satisfy the R10 "To be usable by transformation and generation engine based on EMF." non-functional requirement, a virtual EMF resource implementation integrating the MoDisco role feature is necessary. Thanks to this vitural resource, the requirement is satisfied for engines using the EMF reflexive API.

The class implementing this virtual resource is named: org.eclipse.gmt.modisco.infra.facet.MoDiscoVirtualResource.

When a composing model is loaded in a MoDisco virtual resource, the virtual resource needs to know which facet set to load. A dedicated Ecore annotation name is provided: "org.eclipse.gmt.modisco.infra.facet.default.facetset".

Summary

Functional elements to realize EMF based implementation
Reference EReference
Reference::type EReference::eType
MetaClass EClass
MetaClass::references EClass::eReferences
MetaModel EPackage
MetaModel::metaClasses EPackage::eClassifiers
ModelElement EObject
ModelElement::conformsTo EObject.eClass()
Model Resource
Model::conformsTo CompositionUtils.conformsTo(Resource)
LinkEnd EObject::eGet(EStructuralFeature)
LinkEnd::refers EObject::eGet(EStructuralFeature)
LinkEnd::conformsTo EObject::eGet(EStructuralFeature)
Link EObject
Link extends ModelElement EObject realize Link and ModelElement
Link::subLinks EObject.eContents()
Link::linkEnd CompositionUtils.getLinkEnds(EObject)
Link::referredLinks CompositionUtils.getReferredLinks(EObject link)
Link::conformsTo EObject.eClass()
ComposingModel Resource
ComposingModel extends Model Resource implements Model and ComposingModel
ComposingModel::referredModels CompositionUtils.getReferredModels(Resource resource)
ComposingModel::links Resource.getContents()
LinkEndType EReference
LinkEndType implements Reference EReference implements LinkEndType and Reference
LinkType EClass
LinkType extends MetaClass EClass implements LinkType and MetaClass
LinkType::linkEndType CompositionUtils.getLinkEndTypes(EClass linkType)
MetaComposingModel EPackage
MetaComposingModel extends MetaModel EPackage implements MetaComposingModel and MetaModel
MetaComposingModel::refferedMetaModels CompositionUtils.getRefferedEPackages(EPackage)
MetaComposingModel::LinkTypes CompositionUtils.LinkType(EPackage)
MetaComposingModel::virtualOppositeReference Ecore annotation named "org.eclipse.gmt.modisco.infra.composition.default.facetset " containing a facet set URI.
VirtualOppositeReference facet::Shortcut
VirtualOppositeReference extends Reference facet::Shortcut extends Reference
VirtualOppositeReference::opposite1 facet::Shortcut::oppositeReference
VirtualOppositeReference::opposite2 facet::Shortcut::path[0]

Back to the top