Salva talks about ATL4Pros, a slight ATL extension to facilitate the transformation of models annotated with UML profiles (btw, if you are interested in applying profiles to general EMF models, see this other work).

The concept of UML profiles serves as a lightweight extension mechanism for UML. Arbitrary stereotypes and tagged values can be defined within a UML profile which can be subsequently applied to UML model elements. Using stereotypes within an ATL transformation is feasible, but this leads to verbose transformation code, as it is shown in the exemplary ATL code snippet for transforming EJB archives into UML models we present below:


rule EJBArchive_2_Model  {
	from
		s : EJB!EJBArchive
	to
		t : UML!Model (
			name <- s.name
		)
	do {
		t.applyProfile(profile!Profile.allInstances().asSequence().first());
			thisModule.stereo <- profile!Stereotype.allInstances()
                                                       -> any( e | e.name = 'EJBArchive');
			t.applyStereotype(thisModule.stereo); 

			if(not s.version.oclIsUndefined()){
				t.setValue(thisModule.stereo, 'version',s.version);
			}
	}
}

The workaround for using UML profiles in ATL transformations is based on providing the profile as an additional input model for the transformation as well as making calls to the Java UML2 API for assigning profiles and stereotypes and setting tagged values in the imperative ActionBlock (cf. line 10 to 20 in listing above).

Although the presented example does its job, it presents several drawbacks: Profile related model manipulation tasks are implicitly established by means of calling Java operations. In particular, the transformation engineer needs to have knowledge concerning the Java UML2 API in order to correctly invoke operations for applying profiles, applying stereotypes, and for setting tagged values. Moreover, all the operations have to be defined in the imperative ActionBlocks which use is strongly discouraged.

With ATL4pros, we aim for an ATL extension which is tailored for the usage of UML profiles within ATL transformations. The benefits of such an extension for handling UML profiles are evident: The number of lines of code can be reduced due to the absence of complex statements for querying profile information from an additional input model representing the UML profile. This, together with eliminating the need for imperative code strongly improves readability. Furthermore, ATL4pros eases the UML2 API handling because the engineer does not need anymore specific knowledge about the intricacies of the underlying Java UML2 API.

The proposed transformation, written in ATL4pros, looks as following:


rule EJBArchive_2_Model  {
	from
		s : EJB!EJBArchive
	to
		t : UML!Model (
			name <- x.name
		) apply PRO!EJBArchive (
				version <- s.version
		)
}

When looking closer at this transformation two extensions of the standard ATL syntax have to be introduced by ATL4pros for allowing for a more concise definition:

  1. The keyword apply (cf. line 7 ) is incorporated into ATL and can be used for applying a stereotype on a UML model element. Therefore, a new construct has to be added to the existing ATL metamodel.
  2. The tagged values of a stereotype may be set just like normal features (cf. line 8), for avoiding the explicit writing of imperative code.

A transformation defined using an extended syntax cannot be processed by the existing compiler and virtual machine without modifying these components to support the extended syntax also in the runtime. This would require for a heavyweight extension impacting practically all ATL runtime components which would lead to a separated runtime which has to be separately maintained from the standard runtime. However, in our case, the desired behavior can be, although in a far more verbose way as shown by the motivating example, addressed using the standard ATL syntax. Therefore, we can implement a more lightweight extension mechanism just by preprocessing the transformations defined in the extended syntax to produce standard ATL code. The figure below summarizes the process to implement this approach on ATL.

 

Extending the abstract syntax is the first activity which has a direct dependency to the ATL.ecore artifact. As a next step, the concrete syntax is modified to reflect the performed extension of the abstract syntax. The concrete syntax of ATL is defined in the ATL.tcs artifact which has to be modified in order to use the new syntax elements in the ATL editor. In the last step, an operational semantics is, as ATL transformations are themselves models, defined in terms of a HOT (Higher Order Transformation) implemented in ATL refining mode (changes are performed in-place over the input transformation model).

For more information, see this paper

Want to build better software faster?

Want to build better software faster?

Read about the latest trends on software modeling and low-code development

You have Successfully Subscribed!

Pin It on Pinterest

Share This