Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "VIATRA/Integration/UMLSupport"
(→Status of derived features) |
(Add Static profile support) |
||
Line 1: | Line 1: | ||
− | == | + | == Derived feature support == |
The EMF metamodel for UML 2 contains several derived features which are not supported in IncQuery patterns by default. This optional integration component provides support for them via defining appropriate [[EMFIncQuery/UserDocumentation/Surrogate_Queries|surrogate queries]]. | The EMF metamodel for UML 2 contains several derived features which are not supported in IncQuery patterns by default. This optional integration component provides support for them via defining appropriate [[EMFIncQuery/UserDocumentation/Surrogate_Queries|surrogate queries]]. | ||
Line 12: | Line 12: | ||
[[File:EMF-IncQuery_UML_Queries.png|815px]] | [[File:EMF-IncQuery_UML_Queries.png|815px]] | ||
− | == Status of derived features == | + | === Status of derived features === |
{| border="1" | {| border="1" | ||
!Derived feature | !Derived feature | ||
Line 168: | Line 168: | ||
|Vertex.outgoing || Done || Since 1.0.0 | |Vertex.outgoing || Done || Since 1.0.0 | ||
|} | |} | ||
+ | |||
+ | == Static profile support == | ||
+ | |||
+ | If you have an EMF-UML profile, you can query over applications of its stereotypes and their tagged values as if they were ordinary EClasses and EAttributes. As of 1.1.0, VIATRA only supports static profiles, so you have to define one as described in [http://nyssen.blogspot.hu/2009/09/defining-static-profiles-with-eclipse.html this blog post]. | ||
+ | |||
+ | On the example below, we created a pattern matching <tt>ExampleStereotype</tt> applications, which matches a simple UML instance model: | ||
+ | |||
+ | [[File:Static-profile.png]] | ||
+ | |||
+ | Note for Papyrus users: it is recommended to also register your profile with Papyrus. To accomplish this, add an extension for the <tt>org.eclipse.papyrus.uml.extensionpoints.UMLProfile</tt> extension point, pointing to the UML model file containing your profile. For more information, refer to [https://www.eclipse.org/forums/index.php/t/604098/ this thread]. |
Revision as of 13:09, 16 February 2016
Derived feature support
The EMF metamodel for UML 2 contains several derived features which are not supported in IncQuery patterns by default. This optional integration component provides support for them via defining appropriate surrogate queries.
- Install the feature UML Support for EMF-IncQuery from the IncQuery update site.
- Add the following plugins to your dependencies:
- org.eclipse.incquery.runtime
- org.eclipse.incquery.uml
- Now you can use most of the derived features like every other feature.
Status of derived features
Derived feature | Status | Remark |
---|---|---|
Action.context | Done | Since 1.1.0 |
Action.input | Done | Since 1.0.0 |
Action.output | Done | Since 1.0.0 |
Activity.group | Done | Since 1.0.0 |
Activity.node | Done | Since 1.0.0 |
ActivityEdge.inGroup | Done | Since 1.0.0 |
ActivityGroup.containedEdge | Done | Since 1.0.0 |
ActivityGroup.containedNode | Done | Since 1.0.0 |
ActivityGroup.inActivity | Done | Since 1.1.0 |
ActivityGroup.subgroup | Done | Since 1.0.0 |
ActivityGroup.superGroup | Done | Since 1.0.0 |
ActivityNode.activity | Done | Since 1.1.0 |
ActivityNode.inGroup | Done | Since 1.0.0 |
Association.endType | Done | Since 1.0.0 |
Behavior.context | Done | Since 1.1.0 |
Class.extension | TODO | Buggy in 1.0.0, disabled in 1.1.0 (implementation checks Metaclass stereotype application, so it will be incorrect if used on classes that are _not_ metaclasses) |
Class.superClass | Done | Since 1.0.0 |
Classifier.attribute | Done | Since 1.0.0 |
Classifier.feature | Done | Since 1.0.0 |
Classifier.general | Done | Since 1.0.0 |
Classifier.inheritedMember | TODO | |
Component.provided | TODO | |
Component.required | TODO | |
ConnectableElement.end | Done | Since 1.0.0 |
Connector.kind | Done | Since 1.0.0 |
ConnectorEnd.definingEnd | TODO | |
DeploymentTarget.deployedElement | Done | Since 1.0.0 |
DirectedRelationship.source | Done | Since 1.0.0 |
DirectedRelationship.target | Done | Since 1.0.0 |
Element.ownedElement | Done | Since 1.0.0 |
Element.owner | Done | Since 1.0.0 |
EncapsulatedClassifier.ownedPort | Done | Since 1.0.0 |
Extension.isRequired | TODO | |
Extension.metaclass | Done | Since 1.0.0 |
Feature.featuringClassifier | Incorrect | Since 1.0.0, known problems (opposite of Classifier.feature according to specification, but implementation gives different result in some corner cases involving signals) |
Message.messageKind | Done | Since 1.0.0 |
MultiplicityElement.lower | TODO | |
MultiplicityElement.upper | TODO | |
NamedElement.clientDependency | Done | Since 1.0.0 |
NamedElement.namespace | Done | Since 1.0.0 |
NamedElement.qualifiedName | Done | Incorrect in 1.0.0, fixed in 1.1.0 |
Namespace.importedMember | Incorrect | Since 1.0.0, known problems (imported members of Profiles are not fully correct) |
Namespace.member | Incorrect | Since 1.0.0, known problems (inherited class members are not included) |
Namespace.ownedMember | Done | Since 1.0.0 |
OpaqueExpression.result | Done | Since 1.0.0 |
Operation.isOrdered | TODO | |
Operation.isUnique | TODO | |
Operation.lower | TODO | |
Operation.type | TODO | |
Operation.upper | TODO | |
Package.nestedPackage | Done | Since 1.0.0 |
Package.nestingPackage | Done | Since 1.1.0 |
Package.ownedStereotype | Done | Since 1.0.0 |
Package.ownedType | Done | Since 1.0.0 |
Parameter.default | TODO | |
Port.provided | TODO | |
Port.required | TODO | |
Property.default | TODO | |
Property.isComposite | Done | |
Property.opposite | TODO | |
ProtocolTransition.referred | Done | Since 1.0.0 |
RedefinableElement.redefinedElement | Done | Since 1.0.0 |
RedefinableElement.redefinitionContext | Done | Since 1.0.0 |
RedefinableTemplateSignature.inheritedParameter | Done | Since 1.0.0 |
Relationship.relatedElement | Done | Since 1.0.0 |
State.isComposite | Done | Since 1.0.0 |
State.isOrthogonal | Done | Since 1.0.0 |
State.isSimple | TODO | |
State.isSubmachineState | TODO | |
Stereotype.profile | TODO | |
StructuredClassifier.part | Done | Since 1.0.0 |
StructuredClassifier.role | Done | Since 1.0.0 |
Type.package | Done | Since 1.0.0 |
Vertex.incoming | Done | Since 1.0.0 |
Vertex.outgoing | Done | Since 1.0.0 |
Static profile support
If you have an EMF-UML profile, you can query over applications of its stereotypes and their tagged values as if they were ordinary EClasses and EAttributes. As of 1.1.0, VIATRA only supports static profiles, so you have to define one as described in this blog post.
On the example below, we created a pattern matching ExampleStereotype applications, which matches a simple UML instance model:
Note for Papyrus users: it is recommended to also register your profile with Papyrus. To accomplish this, add an extension for the org.eclipse.papyrus.uml.extensionpoints.UMLProfile extension point, pointing to the UML model file containing your profile. For more information, refer to this thread.