search

eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

OCL engine lacks support for stereotypes #6

Closed eclipse-ocl-bot closed 1 month ago

eclipse-ocl-bot commented 1 month ago

| --- | --- | | Bugzilla Link | 112953 | | Status | CLOSED DUPLICATE of bug 117542 | | Importance | P1 enhancement | | Reported | Oct 18, 2005 11:47 EDT | | Modified | May 27, 2011 02:49 EDT | | Version | 1.0.0 | | Reporter | Kevin Cornell |

Description

A user can define a profile with stereotypes and with OCL constraints. \ Unfortunately these constraints can only be made against the UML meta-model and \ not the profile's stereotypes, which limits the use of OCL in all but the most \ simple of profiles.

Solution: OCL has the expressions isTypeOf, isKindOf, it would be very useful \ to have the same for testing stereotypes , isStereotypeOf, isStereotypeKindOf.

eclipse-ocl-bot commented 1 month ago

By Christian Damus on Oct 25, 2005 11:45

Recommend "isStereotypedAs" instead of "isStereotypeOf". The latter would seem \ to query whether the target of the operation call is a stereotype of some \ metaclass.

eclipse-ocl-bot commented 1 month ago

By Vishy Ramaswamy on Oct 31, 2005 13:48

Need to add support for clients to define new operations on OCL types. \ Currently, the only operations that the OCL interpreter can actually evaluate \ are in two categories: 1)Operations defined by the OCL specification. These are implemented by the \ EvaluationVisitor 2)Operations defined in the Ecore metamodel. These are invoked reflectively \ (via java.lang.reflect.Method) on their targets

Should orovide support for extending the existing Environment API for look-up \ of operations. Currently, clients extend the OCL parser's Environment \ interface to customize the look-up of classifiers. They can also do this to \ customize the look-up of operations, properties, etc. of classifiers. This \ mechanism can be used to return additional operations not present in the Ecore \ model, as EOperations (note that any assumptions that such EOperations will \ actually be owned by the EClassifier would have to be fixed). We would have \ to add some API to the EvaluationEnvironment interface that a client can \ extend, for the OCL parser to call back to invoke an EOperation (something \ like "Object invoke(Object target, EOperation operation, Object[] args)" comes \ to mind)

eclipse-ocl-bot commented 1 month ago

By Nobody - feel free to take it on Nov 01, 2005 10:42

Concur with the need as expressed in the Description. Without this capability, OCL \ usage in constraints is severely limited.

eclipse-ocl-bot commented 1 month ago

By Christian Damus on Dec 20, 2005 09:47

This defect expresses the same requirement as Bug 117542, which has already been resolved by providing the hook in the Environment API (as described in this bug).

It appears that it is a UML client (as the discussion is about stereotypes) that now simply needs to make the appropriate operations available in its UML-to-Ecore adapter, and to provide the implementations for them in its environment. In case this client is using the org.eclipse.uml2 API, I hear that the next version of that API is to have all of the "custom operations" such as isApplied(Stereotype) modeled in Ecore, so that may simplify the problem.

This bug has been marked as a duplicate of 117542

eclipse-ocl-bot commented 1 month ago

By Ed Willink on May 27, 2011 02:49

Closing after over 18 months in resolved state.