Eclipse Community Forums: Papyrus » Following the OO paradigm in papyrus

Home » Modeling » Papyrus » Following the OO paradigm in papyrus

Following the OO paradigm in papyrus [message #1830046]

Thu, 16 July 2020 05:37

Eclipse User

This is an "high level" question:

I have a set of methods, like getInputPortsNames(Class umlClass) in one big utility class.

I would like to follow the Object Oriented Paradigm, avoiding utility classes, calling directly the methods as follows:
umlClass.getInputPortsNames();

Is there a way to "embed" additional methods into the UML elements.

Many thanks for the help!

Re: Following the OO paradigm in papyrus [message #1830055 is a reply to message #1830046]

Thu, 16 July 2020 08:48

Eclipse User

Hi

A Complete OCL document does exactly what you want by complementing an existing metamodel with additional / elaborated operations / properties / constraints.

As a textual language it is supported by an Xext editor.

For your own classes, you can use Papyrus' embedded OCL editor. However UML users like to do everything graphically so the Papyrus graphical support for Complete OCL is poor. The UML spec itself refuses to use Complete OCL and so incurs needless complexity by avoiding all helpers.

For third party (UML) classes you have no choice but to use a Complete OCL document. (Unless you want to overcome all the hurdles with making normal UML tools work with YourUML with embedded goodies.)

Regards

Ed Willink

Re: Following the OO paradigm in papyrus [message #1830056 is a reply to message #1830055]

Thu, 16 July 2020 09:05

Eclipse User

My first idea was based on the following steps:
1. Create a new profile that extends the UML profile.
2. In the profile, define a new Stereotype for example MyUMLClass that extends the element UMLClass, with the operation getInputPortsNames.
3. Then, I don't know how, replace the UMLFactory that is used to create the umlClass, with a custom factory that implements the method createClass returning the instantiated object MyUMLClass with the method getInputPortsNames.

Does it make sense to you?

[Updated on: Thu, 16 July 2020 09:05] by Moderator

Re: Following the OO paradigm in papyrus [message #1830086 is a reply to message #1830056]

Fri, 17 July 2020 02:55

Eclipse User

My goal is not the "extension" of uml classes on top of Papyrus, but their replacement with classes that have additional methods.

For example if I call:

myPackage.createOwnedClass(...)

As output I would have an instance of org.eclipse.uml2.uml.Class, but implemented with additional methods (for example class.getInputPortsNames).

To do so, shouldn't be possible to replace the
org.eclipse.uml2.uml.UMLFactory.eINSTANCE with a custom implementation of UMLFactory?

Re: Following the OO paradigm in papyrus [message #1830097 is a reply to message #1830086]

Fri, 17 July 2020 05:11

Eclipse User

Hi

Your suggestion makes perfect sense and it should just work.

The UML2Ecore conversion should fold the stereotypes into the Ecore classes. This happens for properties. cf the EReference stereotype used to enrich the UML.uml with transient and volatile EAttributes before conversion to UML.ecore.

The merge might happen for operations, but since I've not considered it or seen it done, I suspect you may need to raise a Bugzilla. I'm not clear how clashing/ambiguous operation names should be resolved.

If your operations are defined with OCL bodies, then the conversion/genmodel synthesis will need to rewrite body sub-expressions such as aClass.extension_MyClass.doMyThing() to accommodate the folding of the MyClass extension object into the Class instance. As the author of the OCL support, I can pretty much guarantee that this is not supported. If you get close enough with UML2Ecore raise an OCL Bugzilla for the operation rewrites.

Ah! But you are not regenerating UML so you do not provide the opportunity for the folding to occur. You can apply the MyClass stereotype to one of your classes, you cannot apply it to the UML Class. Complete OCL is your only option.

If you do regenerate UML you can add your own goodies, but you will lose all the manually crafted goodies in the Eclipse UML implementation. e.g. Eclipse UML maintains caches of slot values to avoid the cost of supporting classes bloated with the myriad facilities almost nobody ever uses. If you really want your UML you could strip Deployments and Use Cases and ... so that a naively generated YourUML wouldn't be that inefficient. But it wouldn't be UML, so you would have difficulty using tools such as Papyrus. Also Eclipse UML has a manual Java implementation of all the constraints. You would therefore lose the debugged validation. The embedded OCL within UML has now been bug-fixed syntax-wise and the OCL2Java generator can be used to auto-generate the constraints, but the code has never been executed so all the functional bugs remain to be removed. Also the OCL2Java synthesis has many unfulfilled opportunities for optimization / non-crazy behaviour in regard to compound Collection execution. Also UML2Ecore will need to be substantially revisited for YourUML2Ecore.

Regards

Ed Willink

Re: Following the OO paradigm in papyrus [message #1830102 is a reply to message #1830097]

Fri, 17 July 2020 06:02

Eclipse User

Many thanks Ed!

In summary the following desired scenario is not possible to achieve:
- I have an instance of org.eclipse.uml2.uml.Package.
- I call myPackage.createOwnedClass() that doesn't return an instance of
org.eclipse.uml2.uml.Class but an instance of MyClass that extends org.eclipse.uml2.uml.Class.

Am I right?

Re: Following the OO paradigm in papyrus [message #1830128 is a reply to message #1830102]

Fri, 17 July 2020 12:08

Eclipse User

Hi

I wouldn't rule out that kind of kludge. However I tried it once but discovered that the quartet of XXX{Package/Factory} {/Impl} classes are too tightly coupled making use of a replacement non-trivial. That was for my model, and I did not like the way it was going. For UML I would expect it to be harder.

I think you should step back and reflect. Your search for OO elegance requires you to go dangerously close to the limits of EMF/UML2 so that you will probably end up fighting the framework. This kind of fight rarely works out well.

Utility classes may be less elegant but they are not a fight.

Regards

Ed Willink

Re: Following the OO paradigm in papyrus [message #1830144 is a reply to message #1830097]

Fri, 17 July 2020 15:51

Eclipse User

Ed Willink wrote on Fri, 17 July 2020 05:11

raise an OCL Bugzilla for the operation rewrites.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=500519 has an additional comment identifying this use case.

Regards

Ed Willink

Re: Following the OO paradigm in papyrus [message #1830183 is a reply to message #1830128]

Mon, 20 July 2020 02:59

Eclipse User

Shouldn't be the possiblity to replace their interface easily one of the main advantace of the approch based on Factories?

In my case, shouldn't be enough to replace the init() of the UMLFactoryImpl?

public static UMLFactory init() {
		try {
			UMLFactory theUMLFactory = (UMLFactory) EPackage.Registry.INSTANCE
				.getEFactory(UMLPackage.eNS_URI);
			if (theUMLFactory != null) {
				return theUMLFactory;
			}
		} catch (Exception exception) {
			EcorePlugin.INSTANCE.log(exception);
		}
		return new UMLFactoryImpl();
	}

Re: Following the OO paradigm in papyrus [message #1830187 is a reply to message #1830183]

Mon, 20 July 2020 04:45

Eclipse User

Sorry, I have given you my two cents worth. Might be possible; probably hard.

Now you can give it a try and demonstrate how right / wrong my advice was.

Since UMLFactoryImpl is in org.eclipse.uml2.uml.internal.impl which is not exported API, some would say that you definitely cannot do what you suggest.

Regards

Ed Willink

Re: Following the OO paradigm in papyrus [message #1830258 is a reply to message #1830187]

Wed, 22 July 2020 04:46

Eclipse User

- The registry EPackageRegistry has stored the entity <FactoryId, FactoryInstance> i.e. <UMLPackage.eNS_URI, instance of UMLFactoryImpl>
- In Papyrus, the EPackageRegistry is retrieved by looking at the property 'org.eclipse.emf.ecore.EPackage.Registry.INSTANCE'.

I proceeded as follows:
- I created the class MyUMLFactory that extends UMLFactory.
- The key action was to put the entity <UMLPackage.eNS_URI, instance of MyUMLFactory> in the EPackageRegistry.
- I created the registry MyRegistry that extends EPackageRegistryImpl and adds the entity <UMLPackage.eNS_URI, instance of MyUMLFactory>
- Then, for the execution of my software that is build on top of Papyrus, in the VMArgument I added "-Dorg.eclipse.emf.ecore.EPackage.Registry.INSTANCE="extendeduml.MyRegistry""

In this way, each invocation of UMLFactory is replaced with the invocation of MyUMLFactory.

[Updated on: Wed, 22 July 2020 05:01] by Moderator

Re: Following the OO paradigm in papyrus [message #1830267 is a reply to message #1830258]

Wed, 22 July 2020 08:45

Eclipse User

Hi

Congratulations and thank you for sharing the principles your solution. If you are able to share a zipped or GitHub project users may be able to share even more.

Regards

Ed Willink

Previous Topic:	Please ignore
Next Topic:	DSML Custom Storage Format

Goto Forum:

-=] Back to Top [=-

Current Time: Sun Jul 27 21:47:12 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter