Embedding - M2 - ASM

Recall ASM abstract states are defined by algebraic structures, where data come as abstract objects (one for each category of data), i.e., as elements of sets, with basic operations. This definition is the algebraic data types in the functional language Gofer (the basis of AsmGofer), which is a subset of Haskell. However, it poses a series of challenges for the embedding due to the object-oriented style used by the fUML meta-models (SHIELDS; JONES, 2001).

There are some kinds of polymorphism that Haskell doesn’t support, or at least not natively, e.g., . . . subtyping, common in OO languages, where values of one type can act as values of another type¹.

In this context, the transformationEmbedding - M2 - ASM faces thesubtyping issue(SHIELDS;

JONES, 2001). For example: in the abstract syntax of fUML anActionis a kind ofActivityNodethat is a kind ofRedefinableElement, which is a kind ofNamedElementthat, finally, is a kind ofElement.

One technique to face the subtyping issue is:for each super-class, it is defined an algebraic data type that has a discriminator used to indicate the sub-classes(GARGANTINI et al., 2009). Therefore, the sub-classes are disjoint subsets of the set defined by the algebraic data type of the super-class. This technique defines different sets for each super-class so the super-classes cannot have relationships of type “is kind of” between them. Otherwise, a class could be part of two sets, which will turn its manipulation by the operational semantics hard and error prone. Even more, a class must be part of one and only one set so it is described by one and only one algebraic data type with an adequate discriminator. Moreover, the algebraic data types must have a data constructor for an empty element, i.e., part of the set but not part of any subset (a common pattern in functional programming languages). This is the technique applied in the ultra deep embedding for the abstract syntax and for the semantic domain in this work, however, the question is which classes should be chosen in order to guarantee that they define disjoint sets.

The choice of classes is made analyzing the class hierarchy of each meta-model, and passing two multi-valued parameters for the transformation, which are: (1) the list of the key classifiers, i.e., each one defines an algebraic data type, and (2) the list oftarget classifiers, i.e., the classifiers that will be part of the sets defined by the key classifiers (which set is the adequate one is defined by the transformation). These lists must respect the constraints previously discussed, furthermore, only classifiers in these lists are embedded, which makes easy to select elements from bUML.

For example: the execution ofEmbedding - M2 - ASM that supports the ASM mainSyn chooses Event as a key classifier and SignalEvent as a target classifier. Therefore, Event has its alge-braic data typeFUML_Syntax_CommonBehaviors_Communications_Event, which has a discrimi-natorFUML_Syntax_CommonBehaviors_Communications_EventTypewith only one possible value SignalEvent FUML_Syntax_CommonBehaviors_Communications_SignalEvent. Additionally, there is a FUML_Syntax_CommonBehaviors_Communications_EventEmpty allowing empty elements to

1http://www.haskell.org/haskellwiki/Polymorphism#Other_kinds_of_polymorphism

be part of theEvent set. See the following excerpt where the naming convention for the algebraic data types are shown (packageHierarchy "_" keyClassifierName").

data FUML_Syntax_CommonBehaviors_Communications_EventType = FUML_Syntax_CommonBehaviors_Communications_SignalEvent data FUML_Syntax_CommonBehaviors_Communications_Event =

FUML_Syntax_CommonBehaviors_Communications_Event String

String

FUML_Syntax_Classes_Kernel_VisibilityKind FUML_Syntax_Classes_Kernel_VisibilityKind FUML_Syntax_Classes_Kernel_Classifier

FUML_Syntax_CommonBehaviors_Communications_EventType | FUML_Syntax_CommonBehaviors_Communications_EventEmpty

Another issue is the identity of the sets’ members, while the embedded abstract syntax can work with static or dynamic ids, the embedded semantic domain only admits dynamicids. The dynamism is a required characteristic in the embedded semantic domain because it defines the meaning of a given instance of the abstract syntax, in other words, the dynamic functions store the state. Thus, if the identity of the abstract syntax is chosen to be static, another parameter for the transformation is required (generateSemantics) indicating how the identity of an algebraic data type is defined. In fact, this work chooses to use static ids for the abstract syntax elements because the ids are statically defined in the meta-model (xmiId) and a user-model (which instantiates the abstract syntax) is static for the operational semantics. Therefore, when generating theembedded abstract syntax the xmiId is used as id(see the previous excerpt, the first Stringparameter is the xmiId), however, when generating theembedded semantic domain the id is dynamically generated, which indeed is the use of the ASMreserveto create new elements (see the following extract where the use of thereserve from ASM is coded using the class Create for an element from the embedded semantic domain, theOffer).

data FUML_Semantics_Activities_IntermediateActivities_Offer = FUML_Semantics_Activities_IntermediateActivities_Offer Int | FUML_Semantics_Activities_IntermediateActivities_OfferEmpty

instance Create FUML_Semantics_Activities_IntermediateActivities_Offer where createElem i = FUML_Semantics_Activities_IntermediateActivities_Offer i

UML PrimitiveTypes are mapped into primitive types of AsmGofer, namely Boolean to Bool, StringtoString,Integer andUnlimitedNatural to Int, andReal to Float.

Properties of classes are mapped into ASM functions. Moreover, the properties of the super-classes and sub-super-classes of thekey classifier which maps to an algebraic data type are also defined as functions for the algebraic data type. The multiplicity and the meta-propertiesisOrdered and isUniqueare considered for the definition of the codomain, furthermore,bags(multiplicity greater than 1 andisOrdered=falseandisUnique=false) are reported as error, andordered sets(multiplicity greater than 1 and isOrdered=true and isUnique=true) are reported as warnings and mapped into sets. The transformation only considers properties that are owned by a classifier, therefore, if an association end is owned by the classifier it is embedded, otherwise, not. Consequently, bidirectional navigations where both association ends are owned by classifiers are embedded as two functions, one for each classifier. These functions for the embedded abstract syntax can be static or dynamic, whereas they must be dynamic for the embedded semantic domain (for the same reason previously presented). The following extract shows the resultant function for the

18

property offeredTokens from Offer in the embedded semantic domain, which have the following meta-properties:isOrdered=false,isUnique=true,multiplicity=0..* andtypeequals toToken. Note the Dynamic keyword declaring that it is a dynamic function, and the naming decoration for functions"function_" keyClassifierName "_" [classifierName] "_" propertyName, where classifierNameis optional and can be the name of a super-class or the name of a sub-class (a target classifier).

function_Offer_offeredTokens :: Dynamic ( FUML_Semantics_Activities_IntermediateActivities_Offer ->

{FUML_Semantics_Activities_IntermediateActivities_Token} )

The same rationale applied for the identity of the sets’ members leads to static functions for the embedded abstract syntax. As every definition of the embedded abstract syntax are based on static functions, it is possible to define in the data constructor all the properties that are not bidirectionality navigable². The following extract shows the function for the propertynamedefined by the super-class NamedElement from Event in the embedded abstract syntax. Note the first parameter of the non-empty data constructor isxmiId and the second is thename a property of NamedElement, furthermore, twovisibilitiesappear becauseEvent has as its parents two classifiers that declare visibility, PackageableElement redefines the property visibility from NamedElement.

Finally, note the use of name decoration to give a distinct name to each distinct function of a single property, e.g.name fromNamedElement (SHIELDS; JONES, 2001).

function_Event_NamedElement_name :: FUML_Syntax_CommonBehaviors_Communications_Event -> String function_Event_NamedElement_name (FUML_Syntax_CommonBehaviors_Communications_Event

xmiId name1 visibility2 visibility3 signal4 fUML_Syntax_CommonBehaviors_Communications_EventType) = name1

The last issue for the transformationEmbedding - M2 - ASM is theSemanticVisitor, an instance of the Visitor design pattern, used by the meta-model of the semantics from fUML inten-sively, in fact, the execution model. Following the object-oriented design pattern, fUML uses the Visitor pattern in order to avoid changes in the class hierarchy defined in the abstract syntax meta-model, at the same time, to provide operations, which are defined using bUML activities (in reality, each operation has an opaque behavior written in Java but supported by the Java to UML Activity Mapping). For example: the class from the abstract syntax ActivityNode has a paired class in the semantic domain calledActivityNodeActivation, which specializes SemanticVis-itor, has an unidirectional association to oneActivityNode and has the corresponding behaviors.

Nevertheless, this object-oriented pattern does not apply for ASM because behavior is not coupled with the structure so ultra deep embedding of the classes that are exclusively defined for behavior definition would only demand more algebraic data types without any new information. Therefore, theSemanticVisitors defined uniquely for behavior definition are not embedded, e.g.

ActivityNodeActivation and Evaluation. This simply means that the semantic domain is embed-ded, while the semantic mapping defined by operations specified using bUML not, nonetheless, the operation names for allkey classifiersandtarget classifiersare generated as comments to sup-port a clear matching between operations in the semantics meta-model and rules in the ASM semantic mapping. For example, the classLocus from the semantics meta-model of fUML is chosen askey classifier andtarget classifier so it defines an algebraic data type without

2Although circular algebraic data types are not an issue for lazy functional programming lan-guages, this work, avoid them so only not bidirectional properties are defined in the data construc-tor.

a discriminator because it does not have sub-classes, in addition, all the properties are embedded using dynamic functions and its signatures of operations are generated as comments in order to guide the definition of the semantic mapping (using the same name decoration previously shown but changing the prefix from"function_"to"operatio_").

data FUML_Semantics_Loci_LociL1_Locus = FUML_Semantics_Loci_LociL1_Locus Int | FUML_Semantics_Loci_LociL1_LocusEmpty function_Locus_executor :: Dynamic ( FUML_Semantics_Loci_LociL1_Locus -> FUML_Semantics_Loci_LociL1_Executor ) -- operatio_Locus_add :: FUML_Semantics_Loci_LociL1_Locus -> FUML_Semantics_Classes_Kernel_Value -> Rule () -- operatio_Locus_remove :: FUML_Semantics_Loci_LociL1_Locus -> FUML_Semantics_Classes_Kernel_Value -> Rule () -- operatio_Locus_instantiate :: FUML_Semantics_Loci_LociL1_Locus -> FUML_Syntax_Classes_Kernel_Classifier ->

-- Rule FUML_Semantics_Classes_Kernel_Value

In summary, every key classifier defines an algebraic data type. All properties from the super-classes and sub-super-classes (target classifiers) are defined for the algebraic data type applying name decoration. The embedded abstract syntax uses parameters in the non-empty data constructor for each unidirectional property and a parameter for thexmiId, moreover, all functions are static. While the embedded semantic domain does not define parameters in the non-empty data constructor using thereserve from ASM, furthermore, every function is a dynamic function. Finally, the embedded semantic domain does not have pureSemanticVisitors in the key classifiers or target classifiers.

Although there are particularities between the embedding of abstract syntax and semantic domain, they share the same set of the main rules, which characterizes theultra deep embedding.

Finally, when embedding the abstract syntax,Embedding - M2 - ASM must generate the transfor-mationEmbedding - M1 - ASM. The process of generation ofEmbedding - M1 - ASM is defined by the same set of rules above described. For eachkey classifier, all its subclasses listed in thetarget classifiers are used to generate a template for one static function for each instance of the target classifiers. Furthermore, the bidirectional navigable properties generate templates also according to the same pattern (for eachkey classifier, all its subclasses listed in thetarget classifiers)³. The next subsection briefly discusses the resultant transformation.

Using the Distributed Package

The meta-modelsfUML_Syntax_ExtendedandfUML_Semantics_Extendedare used to define the abstract syntax and the semantic domain for synchronous and hybrid fUML. Specifically, they are the basis for the generation, through ultra-deeep embedding, of the algebraic data types used in the ASMs.

The transformationembeddingM2_ASM.mtllocated in the projectHybrid fUML Transformations is responsible to read these models and generate the respective embedded version. This transfor-mation has a large number of parameters, which are used to indicate whether an execution will generate an embedded abstract syntax or an embedded semantic domain among others.

The transformation embeddingM2_ASM.mtl can be executed by the configured run Embedding M2_ASM - Syntaxor the configured runEmbedding M2_ASM - Semantics.

3The stereotypes are covered by this transformation, however, it is not presented in this work.

20

Each run of aEmbedding M2_ASM - Syntaxgenerates a file

Hybrid fUML Transformations\transformedFiles\embeddedM2.gs and a file Hybrid fUML Transformations\transformedFiles\embeddingM1_ASM.genmtl. The file embeddedM2.gsmust be copied into the

Hybrid fUML ASMs\synchronousfUML\1syntax_abstractSyntax_embedded.gs.

The file embeddingM1_ASM.genmtl must be copied into

Hybrid fUML Transformations\embeddingM1_ASM.mtl.

Each run of a Embedding M2_ASM - Semantics generates a file Hybrid fUML Transformations\transformedFiles\embeddedM2.gs. The file embeddedM2.gs must be copied into the

Hybrid fUML ASMs\synchronousfUML\5semanticDomain_embedded.gs.