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

Help

Home

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

Show: Today's Messages :: Show Polls :: Message Navigator

Following the OO paradigm in papyrus [message #1830046]

Thu, 16 July 2020 09:37

Alberto Debiasi

Messages: 84
Registered: March 2018

Member

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!

Report message to a moderator

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

Thu, 16 July 2020 12:48

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

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

Report message to a moderator

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

Thu, 16 July 2020 13:05

Alberto Debiasi

Messages: 84
Registered: March 2018

Member

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 13:05]

Report message to a moderator

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

Fri, 17 July 2020 06:55

Alberto Debiasi

Messages: 84
Registered: March 2018

Member

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?

Report message to a moderator

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

Fri, 17 July 2020 09:11

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

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

Report message to a moderator

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

Fri, 17 July 2020 10:02

Alberto Debiasi

Messages: 84
Registered: March 2018

Member

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?

Report message to a moderator

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

Fri, 17 July 2020 16:08

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

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

Report message to a moderator

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

Fri, 17 July 2020 19:51

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

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

Report message to a moderator

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

Mon, 20 July 2020 06:59

Alberto Debiasi

Messages: 84
Registered: March 2018

Member

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();
	}

Report message to a moderator

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

Mon, 20 July 2020 08:45

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

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

Report message to a moderator

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

Wed, 22 July 2020 08:46

Alberto Debiasi

Messages: 84
Registered: March 2018

Member

- 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 09:01]

Report message to a moderator

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

Wed, 22 July 2020 12:45

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

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

Report message to a moderator

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

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 23 06:50:27 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter