Last week, I wrote about the similarities of ecore and the actifsource core. This time, I want to tell you about the differences and why they exist.
Elements Missing in Actifsource
Some things that are present in ecore do not have a correspondence in the actifsource core:
Elements Missing in Actifsource
Some things that are present in ecore do not have a correspondence in the actifsource core:
- Operations
- Information which is used only for the serialization of data: volatile, transient, id, resolveProxies, instanceClassName
- Factories
- Annotations
- Derived References and Attributes
Why were these things left out in the actifsource core? You will understand this when we look at the purposes of the two meta-models. Quoting from the EMF homepage:
If you want to map your domain classes to Java (or C, C++, Ruby, Scala..) you make use of Generic Code Templates. Like that, you have full control about every single character of the generated code! This explains why there is no need to have Operations, Factories and mapping information in the actifsource core model.
Annotations
Annotations are a way to attach additional information to any ecore element. There is currently no such thing in actifsource. However, it is possible to create an extension of the actifsource core model and define so-called Decorators which add additional information to the elements (actually, any model, not just the core can be extended in this way!). This has the advantage that the for additional information a meta-model can be defined such that they are fully typed as well. Ecore annotations on the other hand are just maps with key-value pairs of strings.
Derived Attibutes and References
Derived features do not add more information to the model but calculate something based on the ordinary attributes and references. For example, the eAllAtributes Reference collects all attributes on a class inculding those defined on its super-classes. Such funtionallity does not really describe the structure of the model but are just helpers. Actifsource has a similar concept: Functions. However, these functions are only used when writing code templates. They allow you to define and use what would be a derived feature in ecore for the purpose of code generation. Each function is associated to a function space which is usually the template. Like that, these functions do not clutter the domain model.
Additional Elements in Actifsource
Some elment of actifsource cannot be mapped to anything in ecore:
Aspects
Some elements of actifsource can implement a so-called Aspect. Each aspect has an interface which defines its purpose. Aspects allow to associate elements with functionality (usually implemented as Java class) which is needed for displaying, validating or editing models. For example, there are aspects which further restrict the range of a Relation, validate additinal contraints or add entries to the content-assist in the resource editor.
Sub-Relations
Sub-relations restrict a relation which is defined in a base class. Instances of the sub-class can then only realise the restricted association. Surprisingly, you can find such a constellation in the ecore model:
"EMF provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor."So, an ecore model must hold all information to generate a set of java classes which allow reading and writing the model including notifications and serialization. In actifsource however, you model your domain using domain classes. These domain classes do not directly map to Java classes for editing and serializing the model! Instead, instantiation and editing of your model is done in actifsource itself using the Resource Editor. Therefore, we do not want any information for mapping to a Java representation in the core itself!
If you want to map your domain classes to Java (or C, C++, Ruby, Scala..) you make use of Generic Code Templates. Like that, you have full control about every single character of the generated code! This explains why there is no need to have Operations, Factories and mapping information in the actifsource core model.
Annotations
Annotations are a way to attach additional information to any ecore element. There is currently no such thing in actifsource. However, it is possible to create an extension of the actifsource core model and define so-called Decorators which add additional information to the elements (actually, any model, not just the core can be extended in this way!). This has the advantage that the for additional information a meta-model can be defined such that they are fully typed as well. Ecore annotations on the other hand are just maps with key-value pairs of strings.
Derived Attibutes and References
Derived features do not add more information to the model but calculate something based on the ordinary attributes and references. For example, the eAllAtributes Reference collects all attributes on a class inculding those defined on its super-classes. Such funtionallity does not really describe the structure of the model but are just helpers. Actifsource has a similar concept: Functions. However, these functions are only used when writing code templates. They allow you to define and use what would be a derived feature in ecore for the purpose of code generation. Each function is associated to a function space which is usually the template. Like that, these functions do not clutter the domain model.
Additional Elements in Actifsource
Some elment of actifsource cannot be mapped to anything in ecore:
Aspects
Some elements of actifsource can implement a so-called Aspect. Each aspect has an interface which defines its purpose. Aspects allow to associate elements with functionality (usually implemented as Java class) which is needed for displaying, validating or editing models. For example, there are aspects which further restrict the range of a Relation, validate additinal contraints or add entries to the content-assist in the resource editor.
Sub-Relations
Sub-relations restrict a relation which is defined in a base class. Instances of the sub-class can then only realise the restricted association. Surprisingly, you can find such a constellation in the ecore model:
- ETypedElement has the relation eType with target EClassifier
- EAttribute inherits the eType relation
- EAttribute has the (derived) relation eAttributeType with target EDataType
Now, the eType of an EAttribute should never map to something that is not an EDataType! This means that the eAttributeType relation is actually a sub-relation of eType! Sadly, this information is missing in ecore!
Decocrating Relations
Deocrating relations can be used to define Homomorphisms in your model. I might write about this another time. If you do not want to wait, check out the Statemachine Tutorial where you can find an example of a decorating relation.
Decocrating Relations
Deocrating relations can be used to define Homomorphisms in your model. I might write about this another time. If you do not want to wait, check out the Statemachine Tutorial where you can find an example of a decorating relation.
No comments:
Post a Comment