| Re: [papyrus-rt-dev] Textual syntax for UML-RT merged into master |
Hi,Just a quick comment, since exactly as I expected, when we start digging into the details there are tons of aspects to consider! :)This about specifying the language for each specific code snippet is exactly what I see that the default language framework that is under discussion (and in the works on Remis whiteboard) is all about. You should be able to specify the default language for a complete model, and then the tooling will creata opaque behaviors/_expression_/actions and so on, where the language/body pair have the default language assigned (to avoid the user having to specify the langua, which is the proposal for the code snippet view is all about also). In a similar manner I would expect you to be able to specify the default action language, on a much higher level, e.g. on project level so that the editor the UML-RT textual notation, knows that all code snippets will be in that language. I doubt that we have the need of specifying the language on each code snippet (even if UML supports it). In practice you probably decide which parts of your larget models is implemented in which target language, and then it is probably sufficient with granularity of specifying it per project/model and probably per .uml-rt-file. Move the default lanugage property to the level of the model node and make sure that you tie it in with the default language framework that Remi works on./Peter CigéhnOn 8 December 2015 at 17:19, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:On Tue, Dec 8, 2015 at 7:41 AM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote: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 stringdelimiters 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?Indeed. Ideally it should be enough to write something likeentry action { log.log("something"); }However, there are several issues to consider:1) the "main" language and the action language are not the same. In theory is should be possible to use alternative action languages, e.g. Java or Alf. So this means there might be a need in the grammar to identify the action language being used, for example something likeentry action "C++" { ... }2) the action may be provided externally, e.g. in a separate file. This was the reason behind using the "source" keyword. For example we could haveentry action { source 'log.log("something");' }orentry action { file "somefile.cc" }In general users would just write the action code directly in there, but for large actions they may decide to put them externally. Of course, nothing prevents the user from writing something likeentry action { source '#include "somefile.hh"' }
but that would work only for C/C++ as action language.Even without considering external files, once can thing of declaring actions separately from their use, e.g. something likedecl action SomeAction { ... }...entry action { do SomeAction }So while the syntax is indeed a bit "talky", it is more flexible. Hence there is a trade-off. But I can change it and eliminate the extra keywords to keep it as simple as possible, and if later it is decided to have more flexibility we can revisit this.3) Delimiters and action language-specific support: the quotes around the code are needed because the code is opaque. Otherwise the intermediate meta-model would have to include the abstract syntax for the action language. Even worse, it would have to include the abstract syntax for all possible action languages, and the parser would have to parse them too!I'll investigate if there are ways in Xtext to link the parser to external parsers, formatters, code assistants, etc. but for now I don't see a straight-forward solution.I also found a paper that talks about supporting new languages with the CDT. Maybe there is a way to integrate these.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.The exact keyword is tricky. I can think of several options:1) B refines A2) B generalize A: I find it confusing because it's too close to "B generalizes A" which is incorrect, as A is the general classifier.3) B generalizedby A: awkward, long, prone to wrong spelling (e.g. generalisedby)4) B subclassof A: awkward5) B subcapsuleof A: confusing: a subcapsule is usually understood to be a capsule instantiated in a capsule part6) B superclass A: awkward7) B extends A8) B specializes A: prone to wrong spellingsomething else?Also, as a matter of style we could write this keyword before the braces, to make it more similar to Java/C++.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.I'll make names optional for most things, although I imagine you'd like to preserve explicit names for capsules, classes, ports, parts, attributes, operations, parameters, states, protocols and protocol messages. The rest we can give names according to some scheme. The code generator already assigns names to things that don't have one. We'll have to see how to apply that scheme to the text editor so that content-assist can be aware if this.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...I haven't given this too much thought, but I think this is doable, but the question would be how to redefine things textually. This goes back to the issue about redefining things that are deeply nested. For example, if we hadcapsule A{statemachine{state S0{state S1 { ... }state S2 { ... }...}state S3 { ... }}}and we want to redefine only S2, we could do something likecapsule B redefines A{statemachine{state S0{state S2 { ... }}}}where only the strictly necessary elements are mentioned. Perhaps we could even have some sort of shurtcut:capsule B redefines A{statemachine{redef S0.S2 { ... }}}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?Yes, I think we need to test inheritance in legacy models, although, since the tooling support is not there yet, we'll only be able to test code generation and runtime./Peter CigéhnPS. 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:Thanks, sorry about that. I'm aware of them, but we haven't gotten around to fix them. I'll change them to NEW.Bug 483776 - [Codegen] Installing the UML-RT textual syntax feature causes superfluous "Say hello world" tool to appear on tool barBug 479131 - [codegen] Protocol message parameter must be possible to be left untyped to cover for * case
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
--Ernesto PosseZeligsoft.com
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev