MOF-Metamodels and Formal Languages

MOF-Metamodels and Formal Languages

Liliana María Favre
DOI: 10.4018/978-1-61520-649-0.ch005
OnDemand:
(Individual Chapters)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

This chapter describes how to automatically translate MOF metamodels into NEREUS (Favre, 2005) (Favre, Martinez, & Pereira, 2005). We describe a bridge between MOF metamodels and NEREUS based on reusable schemes and a system of transformation rules. We consider MOF metamodels that are expressed by UML class diagrams, packages diagrams and OCL specifications. The text of a NEREUS specification is completed gradually. Figure 1 shows the main steps of this transformation. First, the signature and axioms are obtained by instantiating the reusable scheme BOX_. Next, associations are transformed by instantiating reusable schemes that exist in the component Association. Finally, OCL specifications are transformed using a set of transformation rules. Then, a specification that reflects all the information of UML diagrams is constructed. Following we describe the transformation of a basic package (that does not depend on others) including only classes and relationships. Following sections describe how to transform basic classes and associations. The transformation processes is supported by reusable schemes and a system of transformation rules for translating OCL specifications into NEREUS.
Chapter Preview
Top

Translating Basic Specifications

In NEREUS the elements of <parameterList> are pairs C1:C2 where C1 is the formal generic parameter constrained by an existing class C2 or C1: ANY. In CASL, the first syntax is translated into [C2] and the second in [sort C1]. Next, we show two expressions in NEREUS and the CASL:

NEREUS CLASS CartesProd [ E:ANY; E1: ANY]
CASL spec CARTESPROD [sort E] [sort E1]
NEREUS CLASS HASH [T:ANY; V:HASHABLE]
CASL spec HASH [sort T] [HASHABLE]

NEREUS and CASL have the similar syntax for declaring types. The sorts in the IS-SUBTYPE paragraph are linked to subsorts in CASL.

The signatures of the NEREUS operations are translated into operations or predicates in CASL. Data type declarations may be used to abbreviate declarations of types and constructors.

Any NEREUS function that includes partial functions must specify the domain of each of them. This is the role of the PRE clause that indicates what conditions the function’s arguments must satisfy to belong to the function’s domain. To indicate that a CASL function may be partial the notation uses -›?; the normal arrow will be reserved for total functions. The translation includes an axiom for restricting the domain. For example, a partial function remove (see Bidirectional-3 specification in Appendix-B)

remove: Bidirectional-3 (b) x Class1 (c1) x Class2(c2) -> Bidirectional-3
pre: isRelated (b,c1,c2)

is translated into

remove: Bidirectional-3 (b) x Class1 x Class2 ->? Bidirectional-3
…
forall b:Bidirectional-3, c1:Class1; c2: Class2
def remove (b,c1,c2)  isRelated (b,c1,c2)

In NEREUS it is possible to specify three different levels of visibility for operations: public, protected and private. In CASL, a private visibility requires to hide the operation by means of the operator Hide. On the other hand, a protected operation in a class is included in all the subclasses of that class, and it is hided by means of the operator Hide or the use of local definitions.

Complete Chapter List

Search this Book:
Reset