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,

On 7 December 2015 at 17:40, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
Thanks Peter. Those are very good points. I'll simplify the grammar. FYI there was not a lot of rationale behind the grammar. The main reason for it is that it was derived from the intermediate meta-model, but we'll refine it to make it more usable.

​I guess there are more things to consider, e.g. the current syntax for providing the action/guard code snippets is a bit too "talky" also, i.e. that you must provide a keyword ​
'source​' before the code snippet. Also this about string delimiters and the escape issue that you describe needs to be considered. Since we do know that the code snippets themselves can become rather complex with lots of target language code, e.g. C++, how is the user going to get good formatting and completion support when editing the code snippets in the context of the UML-RT textual syntax?


I'll make most names optional, although they can be useful, since content-assist does not yet show qualified names, so giving explicit names can help differentiate them.

For redefinitions, the only thing the user would be required to do is at the class/capsule level, e.g.

        capsule A

        {

            // ...

        }

        capsule B

        {

            redefines A

            //...

        }


Of course, a user can specify refinement relations inside a state machine, for example if some state S2 of B redefines some state S1 of A. 

​Okay, I maybe would have expected a 'generalize​' keyword to align with what you do when you model grahpically. You simply establish a generalization relationship and then the tooling handles all the redefinition stuff for you (keep in mind that I now mainly refer to legacy tooling, and what I expect that the Papyrus-RT tooling eventually will support in a similar manner).

The question is what to do with elements that have the same name but there is no explicit redefinition relation, for example, should we interpret state S1 of B to redefine state S1 of A even when there is no explicit redefinition? Currently the code generator interprets such situations as redefinitions, so that the generated code for B will have a function corresponding to S1 of B and nothing for S1 of A (but the code for A will have the state function for its own S1).

I think explicit redefinitions should be necessary only in the case where the elements involved have different names, would you agree?

​Yes, without having given this much thought, that sounds reasonable. The user should be able to specify as little as possible, and only need to provide exactly those parts of the state machine that is being redefined (exactly as we propose to handle it in the graphical notation tooling). 

I think that the biggest obstacle for the textual notation will be all names that the user has to give things, and all text-based cross-references that needs to have matching names. If one can follow some implicit naming scheme like this, and thus avoid having to have explicit name based cross references. 

When doing a redefinition in the graphical based notation, you simply select the state/transition and so on that you want to redefine, and start editing it. The tooling then ensures that all redefine relationships and only the stuff that is redefined really needs to be redefined (based on the specialization of the UML meta-model implementation that is planned to be introduced, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=467545​). Since the expected level of tooling support in the graphical tooling will be on a very high level (as it also is in the legacy tooling), the textual notation needs to be on par with this. Otherwise I see that the textual notation maybe not will live up to is expectations by the end-users...
 

By the way, the (GUI) tooling does not yet do any automatic redefinitions. The code generator uses redefinitions if it finds them, but if not, it uses the strategy outlined above, treating elements with the same name as redefinitions.

​I am fully aware of that we have not yet have all the tooling support for inheritance, including the layout inheritance of capsule structure diagrams and state machine diagrams, and redefinition support. I expect this area to be rather complex and full of pot holes that we will bump into (knowing from experience from legacy tooling, and our rather lengthy discussions in relation to the UML-RT profile document and how redefinition shall be defined, all the limitations of the UML spec, the intricacies with the specialization of the UML meta-model implementation and so on).

I guess, some of these issues also needs to be considered when it comes to the textual notation. But before knowing about all of them, maybe we need to get the graphical notation tooling in place first. Maybe we also should do some import testing of legacy models with some inheritance and redefinition of state machines?

/Peter Cigéhn

PS. Just as a reminder since I feel that the Bugzillas I write on the code generator often get stuck in unconfirmed, here is a list of Bugzillas that I have written, including the first one related to the textual notation tooling:

Bug 483776 - [Codegen] Installing the UML-RT textual syntax feature causes superfluous "Say hello world" tool to appear on tool bar
Bug 482662 - RtCppProperties profile have lots of dangling base_* properties
Bug 481013 - Incorrect enum literal in umlrt.ecore model
Bug 479131 - [codegen] Protocol message parameter must be possible to be left untyped to cover for * case

Back to the top