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

[Peter Cigéhn <peter.cigehn@xxxxxxxxx>]

Hi again,

I just realized that my example with having the "simple" prefix optional before "state" and let a state by default be a simple state could also be applied on ports and parts.

If we make the prefix optional also for those cases, a let a port without prefix by default always be an external behavior port and a part without a prefix always be a fixed capsule part.

Then we can make things even more compact for the most common cases, i.e. for external behavior ports and fixed capsule parts.

/Peter Cigéhn

On 11 December 2015 at 09:11, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:

Hi,

On 10 December 2015 at 18:05, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:

It does make sense to specify the action language at a higher level. My main concern is how to link other languages with the "core" UML-RT Xtext grammar, in such a way that we can keep the action language(s) separate. Right now I don't have an answer to that. I'll keep investigating.

We realized that there is another important issue: should the textual syntax support the concepts from the RtCppProperties profile? If we are to support it, the question is how. How should the textual syntax for that look like? Also, since it is a C++-centric profile, I think it should be kept separate from the core grammar.

​This feels like the same issue with the target action language. I guess there is a need to (dynamically?) "weave" together ​multiple grammars, or (dynamically?) extend the grammar with additional aspects, e.g. RtCppProperties and the C+ action langauge. When supporting Java as action language, you should be able to "weave" the grammar for a RtJavaProperties and the Java action language (probably based on JDT support for completion/refactoring and so on).

I also have another (simpler) question: the suggestion for five keywords for ports, is, I assume, to replace "notification", "published", "wired" with something like "external port", "internal port", "relay port", "sap" and "spp"?

​My initial idea was to always have the keyword "port" for all five cases, but with different "prefix" keywords (as it seem to be for the three different kinds of capsule parts). The prefixes could then be "external", "internal", "relay", "sap" and "spp". So in practice you would write 

external port

internal port

relay port

sap port

spp port

For the "external" and "internal" we normally have referred to them as "external behavior" and "internal behavior", e.g. in the properties view and in the UML-RT profile document. But I guess we can make that implicit (all of the five ports are behavior ports, apart from relay which is the only case which is not a behavior port).

This then aligns well with:

fixed part

optional part

plugin part

 

By the way, one of the improvements is already merged, in case you didn't noticed it: 62275. The 'entities', 'protocols', 'packages' or
'typedefinitions' groupings in a model or inside a package have been removed. You can directly write capsules, classes, protocols, packages and typedefs in a model or inside a package and in any order. Keep in mind that content-assist is not yet aware of qualified names, so it is currently possible to access only names within the same namespace (package).

I'm still working on the other improvements.

​Yes, I saw that right after you had made that change, when I got syntax errors on my ​existing .umlrt-files! So I simply updated them, and that change made a huge improvement regarding readability! 

This morning, I got some new syntax errors, so I updated based on them as well. Looks even better, both the removal of the fixed top state, and the removal of (superfluous) top level grouping nodes made a huge difference (in the same way as they did a huge difference on the grouping on the model/package level).

​One thing that I would like to propose is to skip (or maybe make optional) is the "simple" prefix on simple, non-composite, states. To me it feels natural to just ​refer to them as "state". Then when you have nested state machines, you can simply add the prefix "composite". But it feels superfluous to always have to write "simple state". When you "convert" a simple state into a composite state you should only have to add the "composite" prefix (instead of having to remove "simple" and then add/replace it with "composite").

The shorter syntax for specifying the action code was a huge improvement also. I still have my doubts though how this is going to work out in practice. Here we really need to elaborate further. Since you really want to to have the completion support for the action language itself, e.g. by using CDT, how can we incorporate the CDT editor "inline" within the UML-RT textual editor? How can the user get good formatting of both the UML-RT parts as well as the target language parts (which has its formatting conventions). Also when you get compilation errors in the generated code, you want to easily navigate back to the code snippet within the UML-RT textual editor, and place the cursor on the right line (and possibly column) in the original context. I don't think that it will be sufficient to only navigate back to the generated C++ file. 

Have we considered the same synchronization mechanism, where you can change the generated C++ code, and then the change is synchronized back to the model, but in this case back to the source .umlrt-file?

/Peter Cigéhn