Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 112953

Summary:	OCL engine lacks support for stereotypes
Product:	[Modeling] OCL	Reporter:	Kevin Cornell <kcornell>
Component:	Core	Assignee:	Christian Damus <give.a.damus>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	enhancement
Priority:	P1	CC:	dleroux
Version:	1.0.0
Target Milestone:	M6
Hardware:	PC
OS:	Windows All
Whiteboard:

Description Kevin Cornell

2005-10-18 11:47:16 EDT

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.

Comment 1 Christian Damus

2005-10-25 11:45:35 EDT

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

Comment 2 Vishy Ramaswamy

2005-10-31 13:48:55 EST

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)

Comment 3 Nobody - feel free to take it

2005-11-01 10:42:59 EST

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

Comment 4 Christian Damus

2005-12-20 09:47:52 EST

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 ***

Comment 5 Ed Willink

2011-05-27 02:49:02 EDT

Closing after over 18 months in resolved state.