Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] Textual syntax for UML-RT merged into master

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

Back to the top