Bug 90776 - ATL "mapsTo" directive seems to be ignored
Summary: ATL "mapsTo" directive seems to be ignored
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: gmt (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Freddy Allilaire CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-08 06:11 EDT by Dennis Wagelaar CLA
Modified: 2017-04-11 15:13 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Wagelaar CLA 2005-04-08 06:11:50 EDT
One can use the "mapsTo" directive in ATL to indicate which target element
corresponds to which source element. This is necessary if another element needs
to link to the element that represents the source element in the target model.
Example:

rule TaggedValue {
	from s : INMODEL!TaggedValue
	to t : OUTMODEL!TaggedValue mapsTo s (
		name <- s.name,
		modelElement <- s.modelElement,
		isSpecification <- s.isSpecification,
		dataValue <- s.dataValue,
		type <- s.type,
		referenceValue <- s.referenceValue)
}

The above rule copies TaggedValues from the source model to the target model.
The "modelElement" attribute points to the element that owns the tagged value.
This should point to the element in the target model that maps to the particular
 "modelElement" in the source model. The following rule copies AssociationEnds,
that may have tagged values:

rule AssociationEnd {
	from s : INMODEL!AssociationEnd (
		s.visibility <> #vk_public)
	to t : OUTMODEL!AssociationEnd mapsTo s (
		name <- s.name,
		association <- s.association,
		stereotype <- s.stereotype,
		participant <- s.participant,
		visibility <- s.visibility,
		targetScope <- s.targetScope,
		changeability <- s.changeability,
		ordering <- s.ordering,
		aggregation <- s.aggregation,
		isNavigable <- s.isNavigable,
		multiplicity <- s.multiplicity)
}

If this rule is then combined with the following rule, which creates a setter
operation for single, navigable association ends:

rule PublicSingleAssociationEndSetter {
	from s : INMODEL!AssociationEnd (
		s.isNavigable and
		s.multiplicity.range->select(r|r.upper<>1)->isEmpty() and
		s.visibility = #vk_public)
	to set : OUTMODEL!Operation (
	   	name <- 'set' + s.name,
		owner <- s.association.connection->select(x|x<>s)->first().participant,
		visibility <- s.visibility,
		ownerScope <- s.targetScope,
		isAbstract <- false,
		concurrency <- #cck_sequential),
	   setp : OUTMODEL!Parameter (
	   	name <- s.name,
		behavioralFeature <- set,
		type <- s.participant,
		kind <- #pdk_in),
	   setbody : OUTMODEL!ProcedureExpression (
	   	language <- 'java',
		body <- 'this.' + s.name + ' = ' + s.name + ';'),
	   setm : OUTMODEL!Method (
	   	owner <- s.association.connection->select(x|x<>s)->first().participant,
		body <- setbody,
		specification <- set)
}

..then the tagged value all of a sudden showed up under the newly created setter
operation. It turns out that whichever rule came last determines which element
"maps to" the source element. I worked around this problem by moving all
"mapsTo" rules behind the rules that introduce additional elements.