Home » Modeling » Papyrus » ValuePin and ActionInputPin in Moka
| ValuePin and ActionInputPin in Moka [message #1747610] |
Wed, 16 November 2016 13:06  |
 wpila Mising name
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  |
Arnaud Cuccuru
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 #1748104 is a reply to message #1748091] |
Fri, 18 November 2016 13:57 |
Arnaud Cuccuru
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 |
wpila Mising name
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.
|
|
|
Goto Forum:
Current Time: Wed Oct 16 01:05:26 GMT 2024
Powered by FUDForum. Page generated in 0.04031 seconds |
] 
Search
Help
Register
Login
Home
