Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "VIATRA/Integration/UMLSupport"
(Add static profile example repo) |
m (Harmath.incquerylabs.com moved page EMFIncQuery/UMLSupport to VIATRA/UMLSupport: Project merge) |
(No difference)
|
Revision as of 05:09, 18 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.
The code for this example can be found in this repository.