Hi,
I tested again, and now it seem to have installed the additional components. I was now able to create a .umlrt-file and the editor opened as expected (including that it applied the Xtext nature to the project).
I played around with a bit. Here is some quick initial feedback on the syntax:
* I found it a bit confusing with the top level nodes "entities" vs. "protocols". I would have expected to be able to place the protocols next to the capsule, instead of having to place them in a separate top level node. Also the fact that you have to have protocols coming after the entities was also a bit confusing if you want to define your protocol before defining the capsules. At least make it possible to place the top level nodes in any order (at least allow protocols to be placed before entities) if they are to be kept.
* Do we really need any of the top level nodes? Why not allow to write "capsule", "protocol", "class", "package" at the top level, i.e. directly under model and package as you have in the model explorer. There is not additional grouping level like this inside models/packages in UML, so what has been the driver for it in the textual syntax? Why not let the "package" be the user defined packaging as you would expect it to be? Right now you have to write like this (with this ordering of entities and protocols):
model test {
description "This is my first model using the UML-RT textual syntax"
entities {
capsule Client {
rtport p : Control;
}
capsule Server {
conjugate rtport p : Control;
}
capsule Top {
part client : Client;
part server : Server;
connect client.p to server.p;
}
}
protocols {
protocol Control {
out message request();
in message response();
}
}
}
If you remove the top level nodes, then you can write like this instead (if the user wants to have this kind of grouping):
model test {
description "This is my first model using the UML-RT textual syntax"
package MyProtocols {
protocol Control {
out message request();
in message response();
}
}
package MyEntities {
capsule Client {
rtport p : Control;
}
capsule Server {
conjugate rtport p : Control;
}
capsule Top {
part client : Client;
part server : Server;
connect client.p to server.p;
}
}
}
But the user is now in control of the packaging, and if the user do not want to have this packaging/grouping, one should be able to write:
model test {
description "This is my first model using the UML-RT textual syntax"
protocol Control {
out message request();
in message response();
}
capsule Client {
rtport p : Control;
}
capsule Server {
conjugate rtport p : Control;
}
capsule Top {
part client : Client;
part server : Server;
connect client.p to server.p;
}
}
* Regarding the ports, we probably should look into the possibility of having five different keywords for the different kinds of ports. Since the properties of the ports to a high degree is derived from other properties, e.g. visibility is always derived from isService (isService=true -> visibility=public, isService=false -> visibility=protected), isPublish is also derived based on isService and isWired. So it will just be confusing and complex for the user to specify all this information in a redundant way. Just consider the work currently ongoing in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=477033 regarding how the properties are handled in the properties view. Why let the textual syntax reveal all the details that we try to "hide" and "automate" in the UI of Papyrus-RT? I guess that it will be much easier and more compact to actually have keywords for external behavior port, internal behavior port, relay port, SAP and SPP, correponding to the radio buttons in the properties view. If I compare with the capsule part you have the keyword "fixed", "optional", "plugin", which could be made int the corresponding way as for ports. Also consider to have the keyword as just "port", and not "rtport". Not sure why we need a "rt"-prefix for the port?
* The multiplicity for parts and ports should not have to be specified using lower and upper bound. Since we are aiming for a single "replication factor", it should be sufficient to only specify an "upper bound", i.e. the replication factor.
That's what I have found so far after a quick test. I will probably get back with more when I have had the time to test more.
/Peter Cigéhn