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

Bug 269598

Summary:	Create common superinterface for DataType, Interface and Class with operations-related methods
Product:	[Modeling] MDT.UML2	Reporter:	Sergey Vladimirov <vlsergey>
Component:	Core	Assignee:	Christian Damus <give.a.damus>
Status:	VERIFIED FIXED	QA Contact:
Severity:	enhancement
Priority:	P2	CC:	bruck.james, Kenn.Hussey
Version:	unspecified	Keywords:	plan
Target Milestone:	M3	Flags:	give.a.damus: luna+ Kenn.Hussey: review+
Hardware:	PC
OS:	Windows Vista
Whiteboard:	Community Support

Description Sergey Vladimirov

2009-03-21 15:51:35 EDT

Build ID: I20090313-0100

Create common superinterface for DataType, Interface and Class (and other?) with operations-related methods:
 - EList<Operation> getOwnedOperations();
 - Operation createOwnedOperation(String name, EList<String> ownedParameterNames, EList<Type> ownedParameterTypes);
 - Operation getOwnedOperation(String name, EList<String> ownedParameterNames, EList<Type> ownedParameterTypes);
 - Operation getOwnedOperation(String name, EList<String> ownedParameterNames, EList<Type> ownedParameterTypes, boolean ignoreCase, boolean createOnDemand);
 - Operation createOwnedOperation(String name, EList<String> parameterNames, EList<Type> parameterTypes, Type returnType);

Comment 1 Christian Damus

2013-10-17 16:32:54 EDT

I have pushed a new branch bugs/269598 (commit 5392e94) with a proposed solution.

This introduces new interfaces OperationOwner and AttributeOwner defining, respectively, the factory method and finder method signatures for metaclasses that own operations and attributes.  Classifier interfaces are updated as follows to extend these new interfaces:

  * Artifact -> AttributeOwner, OperationOwner
  * Class -> OperationOwner
  * DataType -> AttributeOwner, OperationOwner
  * Interface -> AttributeOwner, OperationOwner
  * Signal -> AttributeOwner
  * StructuredClassifier -> AttributeOwner
  
Note that Class inherits AttributeOwner from StructuredClassifier.  Also, I didn't do anything for Receptions as these do not map to Ecore/Java constructs.

This solution makes use of @extends mark-up, which preserves the custom interfaces during codegen merge, because it didn't seem to make sense to model these new interfaces when the APIs they define were not originally modeled but are generated by UML2's custom codegen templates for java API convenience.  For completeness, I did experiment with modeling these new AttributeOwner and OperationOwner interfaces but I didn't like the results:

  * modeling them as Classes in UML.uml results in
    * an awkward re-ordering of stuff in the UML.merged.uml and
      therefore also UML.genmodel, UML.ecore, and UML.metamodel.uml
    * the uml.edit plug-in getting item providers for them, which is
      not useful
    * these would be the *only* metaclasses in UML.ecore and
      UML.metamodel.uml that are not merged from UML spec (as
      indicated now in the generated Javadoc comments)
  * modeling them as Interfaces in UML.uml to avoid uml.edit impact
     results in the UML.metamodel.uml having interfaces, which it
     never did before and which to me rather "smells" (UML interfaces
     don't fit with metamodeling IMO)
     
Another option may have been to further customize the UML codegen templates, but that would be overkill because this is a special case that we want to apply only to owned features of classifiers in UML.  It isn't applicable to all features that support factory and finder methods, and not to other models than the UML.

Comment 2 Christian Damus

2013-10-17 16:39:45 EDT

A follow-up commit b2a676a fixes some typos in the OperationOwner.

Comment 3 Kenn Hussey

2013-10-20 21:49:39 EDT

The changes have been merged and pushed to the 'master' branch in git.

Comment 4 Kenn Hussey

2013-10-21 13:36:23 EDT

The changes are now available in an integration build for 4.2.0.