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 again,

I tested a little bit more with state machine modeling. I am not fully sure why the syntax requires to always have a composite top state? I would have assumed that you should be able to directly put your first level directly in the state machine (as you normally do when modeling it graphically). 

Also I feel that in general it needs to be considered which elements really have to have explicit names and not. Since the textual notation will force users to give names to "everything", compared to when you are using the graphical notation, where some things can simple be left unnamed, or where the tooling proposes a default name that the user never have to bother about explicitly naming, e.g. the single state machine that the tooling simply will name 'StateMachine'. Does the textual syntax even have to provide an explicit name for the state machine (since a capsule should only be able to have one state machine)? Do a user ever reference the state machine (by name)? I did not test the redefinition case, but I hope that the user is not responsible for setting up all the redefinition relations (I expect the tooling in Papyrus-RT will set up those redefinition relations automatically as soon as the generalization between the capsules are setup).

There are probably more issues like this that needs further elaboration.

/Peter Cigéhn

On 7 December 2015 at 10:00, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:
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


On 4 December 2015 at 22:51, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
It was a problem of missing resources in the deployed packages. It fixed now. It should be available in the nightly update site by tomorrow.

On Thu, Dec 3, 2015 at 11:25 AM, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
Thanks Peter. I'll look into it.

On Thu, Dec 3, 2015 at 11:14 AM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:
Hi,

Yes, I was now able to install the new feature. But when trying to open the editor for a .umlrt-file, the editor cannot start. Some exceptions are thrown with the following stack trace. I have a feeling that something else needs to be installed explicitly (or that there are some missing dependencies). I will check more tomorrow if there is some issue with my installation of Papyurus-RT nightly...

/Peter Cigéhn

Back to the top