Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "AML"
(→The AtlanMod Matching Language) |
|||
| Line 1: | Line 1: | ||
| − | The AtlanMod Matching Language (AML) is a | + | The AtlanMod Matching Language (AML) is a Domain Specific Language for expressing matching strategies. A matching strategy computes equivalences between models. Equivalences (also known as mappings, correspondences) can leverage essential model management tasks, among them, model transformation generation. AML is implemented on top of [http://www.eclipse.org/m2m/atl/ ATL] and [http://www.eclipse.org/gmt/amw/ AMW]. |
| − | AML extends the fundamental stated in | + | AML extends the fundamental stated in [http://www.eclipse.org/gmt/amw/usecases/matching the AMW matching use case]. There, a matching strategy is a chain of transformations. Each transformation: |
| + | ** instruments a type of heuristic, | ||
| + | ** takes as input a set of models: the models to be matched (i.e., Left and Right), an equal model that refers to them, and a set of additional models, | ||
| + | ** and, yields an equal model. Equal models conform to an extension of the AMW core metamodel. | ||
| − | AML keeps the declarative flavor of ATL for expressing | + | AML keeps the declarative flavor of ATL for expressing matching rules, and adds dataflow programming constructs for describing transformation chains. Figure 1. shows the AML architecture: |
| − | + | [[Image:AMLArchitecture.png]] | |
| − | + | ||
| − | + | * The AML Compiler takes a given AML program and performs the following tasks: | |
| − | + | ** Analyze the AML program (syntax and semantic). | |
| − | + | ** Generate an ATL transformation for each matching rule. | |
| − | + | ** Translate the modelFlow block into an Ant script specifying the transformation chain. | |
| − | + | ** Integrate ATL transformation from a Library. | |
| − | + | ||
| − | + | * The AML Accuracy component enables to measure the precision, recall, and fscore of a strategy. How? by comparing an computed equal model to an expected equal model. | |
| − | + | ||
| − | + | * The AMW GUI allows users to manually refine equal models. | |
| + | |||
| + | * HOTs take computed equal models and generate ATL transformations. Each HOT adresses an application domain, e.g., model adaptation, model merging. | ||
Revision as of 10:15, 11 November 2009
The AtlanMod Matching Language (AML) is a Domain Specific Language for expressing matching strategies. A matching strategy computes equivalences between models. Equivalences (also known as mappings, correspondences) can leverage essential model management tasks, among them, model transformation generation. AML is implemented on top of ATL and AMW.
AML extends the fundamental stated in the AMW matching use case. There, a matching strategy is a chain of transformations. Each transformation:
- instruments a type of heuristic,
- takes as input a set of models: the models to be matched (i.e., Left and Right), an equal model that refers to them, and a set of additional models,
- and, yields an equal model. Equal models conform to an extension of the AMW core metamodel.
AML keeps the declarative flavor of ATL for expressing matching rules, and adds dataflow programming constructs for describing transformation chains. Figure 1. shows the AML architecture:
- The AML Compiler takes a given AML program and performs the following tasks:
- Analyze the AML program (syntax and semantic).
- Generate an ATL transformation for each matching rule.
- Translate the modelFlow block into an Ant script specifying the transformation chain.
- Integrate ATL transformation from a Library.
- The AML Accuracy component enables to measure the precision, recall, and fscore of a strategy. How? by comparing an computed equal model to an expected equal model.
- The AMW GUI allows users to manually refine equal models.
- HOTs take computed equal models and generate ATL transformations. Each HOT adresses an application domain, e.g., model adaptation, model merging.