Skip to content
Tobias Nett edited this page Jan 23, 2015 · 20 revisions
The FRaMED editor works with a separate model. This ensures the simplicity of the original CROM-Model. Moreover, it provides developers with more flexibility and freedom.

To close the gap between the two models of FRaMED and CROM, a model-to-model transformation is implemented. This is done by using the Epsilon Transformation Language.

Transformation process

This part will contain some architecture documentation about the the transformation and its working process.

Assumptions and Prerequisites

The transformation requires some labels, i.e., NamedElements, to follow specific syntactic rules. This is necessary in order to be able to parse the given strings accordingly to their meaning in the graphical model. The assumed syntax is briefly defined in the following (using an EBNF-like notation).

  Operation := <name> "(" {Parameter} ")" ":" <type> 
  Attribute := <name> ":" <type> 
  Parameter := Attribute 
  Cardinality := (<integer> | "*") [".." (<integer> | "*")] 

Additional white spaces are ignored. <name> and <type> both stand for valid Java identifiers. The graphical front-end is responsible for assuring the correct format.

Transformation Table

Rigid and Anti-Rigid Types

Graphical Element Transformation
A Shape with type NaturalType, which contains
  • a NamedElement for the type's name,
  • a segment (first segment) containing zero or more NamedElements as attributes,
  • a segment (second segment) containing zero or more NamedElements as operations.
A NaturalType with respective name, attributes, and operations.
A Shape with type CompartmentType, which contains
  • a NamedElement for the type's name,
  • a segment (first segment) containing zero or more NamedElements as attributes,
  • a segment (second segment) containing zero or more NamedElements as operations,
  • a reference to a child model. The child model can contain parts with roles, relationships, and constraints.
A CompartmentType with respective name, attributes, operations, and child reference.
A Shape with type DataType, which contains
  • a NamedElement for the type's name,
  • a segment (first segment) containing zero or more NamedElements as attributes,
  • a segment (second segment) containing zero or more NamedElements as operations.
A DataType with respective name, attributes, and operations.
A Shape with type RoleType, which contains
  • a NamedElement for the type's name,
  • a segment (first segment) containing zero or more NamedElements as attributes,
  • a segment (second segment) containing zero or more NamedElements as operations.
A RoleType with respective name, attributes, and operations.

Groups

Graphical Element Transformation
A Shape with type Group, which contains
  • a NamedElement for the group's name,
  • a reference to a child model, which can contain arbitrary model elements.
A Group with respective name, and a correctly transformed child model. The child model's elements are contained in the group.

Relations and Relationships

Graphical Element Transformation
A Relation of type Inheritance. The inheritance relation connects two elements of the same type, i.e., it is one of the following:
  • DataInheritance between data types
  • NaturalInheritance between natural types
  • CompartmentInheritance between compartment types
  • RoleInheritance between role types
The corresponding, specific inheritance type with super and sub references. Furthermore, the relation is added to the outgoing relations of the source, and to the incoming relations of the target type.
A Relation of type Relationship, with
  • a name,
  • source and target elements,
  • source and target label, specifying the cardinalities,
  • referenced relations which further describe the type of the relationship,
The corresponding Relationship with correct name. The connected role types are referenced via Places, which also hold the cardinalities.
Graphical Element Transformation
</td>
<td>
  
</td>
</td>

Constraints

Testing

To ensure variety in all of our tests without setting up separate models by hand in every one we implemented a parameterized test which loads test cases out of the testcases directory inside the org.framed.transformation.test plug-in. To serialize those test cases a little emf model was build which consists of the TestCase case with the following attributes:

  • title
  • description
  • framed model (Which will be transformed)
  • crom model (the expected one which is used for comparing purposes)

So we just need to create a new file by using the default EMF-Editor implementation or FRaMED itself (for the framed model) to provide new tests.

Clone this wiki locally