Consistency Management(via Triple Graph Grammars) with eNeo
A hands-on introduction to bidirectional model transformation with eNeo by @Anthony A
eMoflon::Neo(referred to as just eNeo as from now) is part of the eMoflon tool suite. eNeo supports model management as a layer over Neo4j, a fairly well-known graph database.
This handbook focusses on bidirectional model transformation as a model management task. I assume you have worked through +(Meta-)Modelling with eNeo and +Model Transformation (via Graph Transformation) with eNeo meaning you have eNeo installed and running. While we shall start with a completely new workspace in this handbook and do not strictly need anything from the other handbooks, I will not explain in detail how to create metamodels, models, and rules.
Bidirectional transformations(bx) are a mechanism for maintaining the consistency of two(or more) related sources of information. While this definition certainly includes forward and backward model transformations, it also includes other scenarios of consistency management, some of which we’ll be discussing in this handbook.
eNeo uses Triple Graph Grammars(TGGs) as an underlying formalism for bx as suggested by Andy Schürr in his seminal paper on consistency management. eNeo combines TGGs with search-based optimisation techniques to yield a hybrid approach that is relatively tolerant with respect to the input supplied by the user. For further details and especially numerous relevant references, the interested reader is referred to Nils Weidmann’s PhD thesis, which not only explains in detail the theory on which eNeo is based, but also provides a recent literature review on“fault-tolerance” in the broad field of Model-Driven Engineering(MDE).
Concurrent engineering as an application scenario
Taking the example from this paper, we’ll assume we wish to support the concurrent engineering of requirements and corresponding architecture models. Requirements are managed in the tool to the left of the diagram below, architectural models of some kind in the tool to the right. In this scenario, requirements are to be connected via traceability links to relevant architectural elements. These traceability links are to be created and maintained in the requirements management tool(RM tool). To enable this, all architectural elements(here components and ports) that can be connected to requirements, must be represented in the RM tool so they can be traced to requirements. While requirements and architecture are changed concurrently, the challenge to be addressed here will be to support maintaining the consistency of both models in some way.
Metamodels and correspondence links
Create a new Java project in your Eclipse workspace and name it Liaison. You can of course name it whatever you want but it might be easier to compare your work with our screenshots.
Create a file RequirementsLanguage.msl in the src folder of the project with the following contents:
metamodelRequirements {
Requirement {
.description: EString
.isFinal: EBoolean
}
ArchElt {
.id: EInt
-relevantFor(0..*)->Requirement
}
}
A Requirement has a string as description and can be marked as being final, e.g., reviewed and accepted by all relevant stakeholders. The idea being that more can be demanded for final requirements, for example concerning traceability.
To connect requirements to architectural elements, ArchElt is used to represent these elements that are assumed to be present in some other tool. The only information we wish to keep about these elements in the RM tool is a unique id.
For the second metamodel, create a file ArchitecturalLanguage.msl with the following contents:
Concurrent engineering as an application scenario
Metamodels and correspondence links
metamodel Requirements { Requirement { .description: EString .isFinal: EBoolean } ArchElt { .id: EInt -relevantFor(0..*)->Requirement }
}metamodel Architecture {
Component { .id : EInt <+>-subComponents(0..*) -> Component <+>-ports(0..*) -> Port }