Re: [papyrus-rt-dev] Textual syntax for UML-RT merged into master

[Ernesto Posse <eposse@xxxxxxxxxxxxx>]

Hi Peter.

This was an unintended side-effect of my latest commit which adds support for importing other models. I agree that it is an undesirable syntax. I'll open a bug for it. I think I can fix the trigger case without having to change the concrete syntax.

Showing only the relevant elements on code completion is also desirable, I'll open a separate bug for that one, or maybe a separate bug for each relevant case (e.g. proposing only ports in the relevant capsule as one bug, propose connector ends as another, etc.)

By the way, one form of import is now supported:

import uri "<some-uri-to-a-.umlrt>"

It can be used at the model level and at the package level.

For models in the workspace you can use

import uri "platform:/resource/some-project/.../some-model.umlrt"

It does not yet support importing .uml models (including the RTS library). I'm working on that.

On Fri, Jan 15, 2016 at 4:51 AM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:

Hi,

I tested a bit with the latest build of Papyrus-RT, and saw that the textual syntax had changed a bit. I guess that some references now needs to be qualified. Here is a small example that I played around with:

model test {

protocol Control {

out message request();

in message response();

}

capsule Client {

port pc : Control;

statemachine  {

initial ClientInitial;

state ClientActive;

transition Initial from ClientInitial to ClientActive action 'pc.request().send();';

}

}

capsule Server {

conjugate port ps : Control;

statemachine {

initial ServerInitial;

state ServerActive;

transition Initial from ServerInitial to ServerActive action '';

transition from ServerActive to ServerActive triggers { on "Control.request" from { ps }} action 'ps.response().send();';

}

}

capsule Top {

fixed part client : Client;

fixed part server : Server;

connect client."Client.pc" to server."Server.ps";

}

}

I wonder in which direction this will be taking. It feels a bit redundant to be forced to qualify the protocol message with its protocol when specifying a trigger. The most natural would of course be that the selected port implicitly gives the scope for the protocol message to choose, including also the conjugation of the port, i.e. the completion support should only propose the protocol messages from the protocol used for typing the selected port and only the protocol messages in the relevant direction based on the conjugation of the port. 

But then you need to textually specify the port before the protocol message, i.e the syntax would have to be swapped to something like this instead:

transition from ServerActive to ServerActive triggers { from { ps } on request } action 'ps.response().send();';

Similar for the specification of ports on parts, i.e. it feels very redundant to have to qualify the port with the name of the capsule since that is given by the selected capsule part. The same is of course applicable here, that the completion support should only propose the ports on the selected capsule part. It could probably even go as far as when the completion support for the "to" end of the connector, to only list the compatible ports on the selected capsule part, i.e. ports typed by the same protocol and with matching conjugation.

Any comments related to this?

/Peter Cigéhn

_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev

--

Ernesto Posse

Zeligsoft.com