A FacetSet can contain other FacetSets, using the eSubpackages containment reference:
In this example, we define a FacetSet for a library metamodel. We sub-divide the "library" FacetSet into two FacetSets : one dedicated to writers and the other one to books. The "writer" FacetSet contains Facets related to writers, and the "book" FacetSet contains Facets related to books.
You can call a FacetOperation from another Facet attribute, reference or operation. For this, you can implement the Facet element with an OperationCallQuery. This query can take literal arguments (in the form of other queries), that will be evaluated and passed to the called FacetOperation. This can be useful in order to factorize the implementation of your Facet elements.
Example:
In this example, we create a Facet to extend a "Writer" EClass, that represents a writer that has written a certain number of books, as represented by the attribute "numberOfBooksWritten". On this Facet, we define 3 boolean FacetAttributes, that classify the writer as "unproductive", "prolific", or "very prolific". To help implement these 3 Facet attributes, instead of implementing 3 separate queries, we create a more generic operation "isInProlificnessInterval" to factorize code. This operation takes 2 parameters (lower and upper bound), and returns whether the "numberOfBooksWritten" of the writer is between the lower and upper bounds. This FacetOperation is implemented by a JavaQuery. Once this FacetOperation is written, we can re-use it to create the 3 FacetAttributes. For this, we define the implementation of each FacetAttribute with an OperationCallQuery that references the operation "isInProlificnessInterval". Each OperationCallQuery contains two IntegerLiteralQuery, that give the values for the lower and upper bounds that are the parameters of the called FacetOperation.
The previous example makes use of the IntegerLiteralQuery to return a literal integer value. There are several more predefined query types for different kinds of values:
A query is evaluated on a source element, and it returns a value.
A query's source type is the type of the element the query is evaluated on.
A derived typed element is always contained in a Facet. A derived typed element can be evaluated on instances of the metaclass extended by the Facet, for instances that conform to this Facet.
So, there are two ways to determine the source type of a derived typed element.
The first case is when the Facet that contains the derived typed element extends "directly" a metaclass, then the source type is this metaclass that is extended by the Facet.
Here is an example where a query implements a FacetAttribute:
The query's source type is the metaclass extended by the Facet in which the FacetAttribute implemented by the query is defined.
The second case is when a Facet extends another Facet, then the source type of the derived typed element is the metaclass extended by the topmost Facet in the inheritance tree. Since a derived typed element is implemented by a query, the source type of this query is the same as that of the derived typed element.
Here is a similar example where the Facet extends another Facet:
The query's source type is now the metaclass extended by the Facet extended by a second Facet in which the FacetAttribute implemented by the query is defined.
A query's return type is the type of the value returned by the query, so it is the eType of the derived type element.
A query implements a derived typed element (such as a Facet attribute, reference or operation) to give it a value. As such, the return type and multiplicity of the query are the same as the type and multiplicity of its containing derived typed element.
In both of preceeding examples the query's return type is the type of the FacetAttribute implemented by this query.
With an OperationCallQuery, we have a specific case: the OperationCallQuery contains other queries used as arguments for the operation called by the OperationCallQuery.
The source and return type of an operation call query are computed in the same way as described above. But the argument query is a bit special: its source type is the same as that of its parent OperationCallQuery, and its return type is the type of the corresponding parameter (at the same index in the list of parameters of the operation as the query's one in the list of arguments of the OperationCallQuery).
Here is an example with an operation that takes one parameter:
Contributors:
Laurent Pichierri (Soft-Maint) - Bug 375789 - Documentation