Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Papyrus » ValuePin and ActionInputPin in Moka
ValuePin and ActionInputPin in Moka [message #1747610] Wed, 16 November 2016 13:06 Go to next message
wpila Mising name is currently offline wpila Mising nameFriend
Messages: 6
Registered: November 2016
Junior Member
Hello!

I check Moka to see how could it be useful for me. Just now it's far from it, but it's in the beginning and the future can show something different, so I intend to follow the development. If I look at:

https://www.eclipse.org/forums/index.php/t/1082242/

I wonder how is it possible, that anybody could try to solve such a simple task in such a complicated way. But with OpaqueBehaviors it could be solved as wanted by Bruno, so my question is: is there anything happening in this area.

Trying to simplify activity diagrams a little bit, I checked ValuePins and ActionInputPins. It seems that there is no implementation for both of them. So I have created ValuePinActivation as follows:

public class ValuePinActivation extends PinActivation {
	
	@Override
	public void run() {
		super.run();
		
		ValuePin pin = (ValuePin) this.node;
		Value value = this.getExecutionLocus().executor.evaluate(pin.getValue());
		
		ObjectToken token = new ObjectToken();
		token.value = value;
		addToken(token);		
	}
}


For simple cases it works, I don't understand the subject enough to know what else is needed. When searching for solution I have seen, that Activation classes are generated from fUML_Semantics.uml. But how is it done? Nowhere in Maven poms could I find any trace of it, I tried also to install Papyrus Java Developer and generate Java code, but it didn't help.

With ActionInputPin I failed earlier, because Papyrus properties don't show fromAction property and I don't want to edit uml files manually.

Before continuing I will see, if I get some insights from this message.

Greetings

Wieslaw
Re: ValuePin and ActionInputPin in Moka [message #1747975 is a reply to message #1747610] Thu, 17 November 2016 11:50 Go to previous messageGo to next message
Arnaud Cuccuru is currently offline Arnaud CuccuruFriend
Messages: 34
Registered: April 2010
Member
Hi Wieslaw,

ActionInputPin and ValuePins are not implemented by Moka's fUML execution engine, because they are not in the fUML subset (http://www.omg.org/spec/FUML/).

Nevertheless, as you have seen, the architecture of the tool is quite open, and you can embedd your own execution engine (with support for ValuePins and ActionInputPins). Another possibility to simplify diagrams is to have some kind of implicit ReadSelfAction (i.e., if you don't connect anything to the "target" or "object" pin of a CallOperationAction or Read/Add StructuralFeatureAction, the engine could consider that we implicitly target the context object). We have already developped engines supporting these simplifications, but we did it for clients, each time with subtile methodological differences. There is no formal plan today to release those engines, but we are aware that executable modeling is a bit too complex, and that such an engine would help.

Regarding the absence of "fromAction" in the property view for ActionInputPin, please fill a bug in the Eclipse Bugzilla.

Cheers,

Arnaud
Re: ValuePin and ActionInputPin in Moka [message #1747980 is a reply to message #1747975] Thu, 17 November 2016 12:37 Go to previous messageGo to next message
wpila Mising name is currently offline wpila Mising nameFriend
Messages: 6
Registered: November 2016
Junior Member
Thanks Arnaud. But by far more important subject is the Java body implementation for OpaqueBehaviors. UML is perfect for high level view of the solution, using it for low level stuff becomes crazy as the Berno's example shows. But the combination of high level fUML and low level Java could be splendid and maybe even sufficient from the performance point of view for some non-critical applications. Is there anything going on in this area? JBPM can use Java in this way and maybe some implementation ideas could be taken from them?

Greetings

Wieslaw
Re: ValuePin and ActionInputPin in Moka [message #1747985 is a reply to message #1747980] Thu, 17 November 2016 12:53 Go to previous messageGo to next message
Arnaud Cuccuru is currently offline Arnaud CuccuruFriend
Messages: 34
Registered: April 2010
Member
Wieslaw,

So far, we are able to associate a java implementation to an Opaque Behavior using an extension point of Moka (org.eclipse.papyrus.moka.fuml.library). Opaque Behaviors are defined in a uml model library, and the extension point enables to map java implementations to these Opaque Behaviors (so the approach requires the development of a plugin).
This feature can probably be helpful for your use case, but I guess you are looking for some more "dynamic" usage, where you define the Opaque Behavior in your model, and directly embedd the java code implementation inside (without the need to develop a specific plugin). Is it correct?

Arnaud
Re: ValuePin and ActionInputPin in Moka [message #1748050 is a reply to message #1747610] Fri, 18 November 2016 08:26 Go to previous messageGo to next message
wpila Mising name is currently offline wpila Mising nameFriend
Messages: 6
Registered: November 2016
Junior Member
Yes. Yes. Yes.
Re: ValuePin and ActionInputPin in Moka [message #1748070 is a reply to message #1748050] Fri, 18 November 2016 10:40 Go to previous messageGo to next message
Arnaud Cuccuru is currently offline Arnaud CuccuruFriend
Messages: 34
Registered: April 2010
Member
Wieslaw,

It seems that this kind of Java integration is a bit complex to achieve, since it would probably require things like just-in-time compiling.

The alternative we are working on concerns the integration of Alf (Action Language for Foundational UML), as mentionned in a separate thread (https://www.eclipse.org/forums/index.php/t/1082242/ ).

Another possible alternative (that we have not experimented so far) concerns the integration of a scripting language (python, js, or whatever), which could be more or less functionnaly equivalent to the java integration you have mentionned, and probably more easy to achieve.

Could you please fill an "enhancement bug" in the Papyrus bugzilla on those topics?

By the ways, thanks for your interest and your feedbacks.
Re: ValuePin and ActionInputPin in Moka [message #1748091 is a reply to message #1748070] Fri, 18 November 2016 12:21 Go to previous messageGo to next message
wpila Mising name is currently offline wpila Mising nameFriend
Messages: 6
Registered: November 2016
Junior Member
Alf is tranformed into fUML giving the horrible result as in Bruno's example, so not.

Java can be used as a scripting language in Java 9, so there is no need to introduce unnecessary additional languages. Also as the end result Java code can be generated from the solution. So I would suggest JShell API with hook back into Moka's JVM. Java 9 is not yet released, but before this extension is mature, it will be present.

Greetings

Wieslaw
Re: ValuePin and ActionInputPin in Moka [message #1748104 is a reply to message #1748091] Fri, 18 November 2016 13:57 Go to previous messageGo to next message
Arnaud Cuccuru is currently offline Arnaud CuccuruFriend
Messages: 34
Registered: April 2010
Member
Well, you do not necessarily have to look at the result of the Alf compiler. So the "horrible fUML result" is not really a problem for the end user, except that it may cause scalability issues (since everything is compiled into equivalent fUML model elements, the model can get big).

The integration of a scripting language adresses another concern: putting actual implementations behind opaque UML stuff (OpaqueBehaviors, OpaqueActions, OpaqueExpressions), that is to say things that you can't specify directly as an activity (or equivalent Alf statement). And your pointer on JShell looks interesting for this use case. Thanks

Using a scripting language as an alternative to Alf is feasible, but raises integration problems regarding "hook back into Moka's JVM" (e.g., if you want to invoke other OpaqueBehaviors as part of your script, or invoke operations on fUML objects).

[Updated on: Fri, 18 November 2016 13:58]

Report message to a moderator

Re: ValuePin and ActionInputPin in Moka [message #1748223 is a reply to message #1748104] Mon, 21 November 2016 11:28 Go to previous message
wpila Mising name is currently offline wpila Mising nameFriend
Messages: 6
Registered: November 2016
Junior Member
When complaining about fUML result I don't mean the visual side of it, I mean the explosion of complexity. From a+b in Java I get two machine instructions, from a+b in Alf I get quite a large activity, which is then interpreted. I wonder what could be the execution ratio between these two representations, but it must be immense. So it can be a huge problem for the end user limiting the range of use cases for Moka.

But I was thinking a little bit about Java interpreter for it and you are right, it's not easy. First all fUML must be translated to Java and this is not a problem. It's one time shot and Papyrus offers the needed tools. Compiling Java is also simple. But mapping of Moka's objects to Java objects and, after execution of Java snippet, mapping them back can be even more complicating then the interpretation of fUML created from Alf. I would say, I would rather limit Java language inside of OpaqueBehaviors and create simplified MVM (Moka's Virtual Machine), which would use Java's bytecodes, but interpret them using Moka's objects.

Is this idea reasonable: Alf inside of Moka is interpreted and we don't care about performance. Afterwards we generate from the solution Java during which Alf is translated directly to Java and we get full speed.

Previous Topic:changing .uml model file do not change .di model file
Next Topic:[Papyrus 2.0] How do I change numeric type id:s to symbolic dito in the notation file
Goto Forum:
  


Current Time: Sun Oct 06 20:15:07 GMT 2024

Powered by FUDForum. Page generated in 0.05553 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top