(I'm writing this reply in a separate thread because I might be deviating from the original topic).
I understand that when you are modelling at certain levels of abstraction, and in particular when you are "sketching", the run-time model library seems of little use. But I have trouble understanding the scenario where you wouldn't write any action code at all, because in UML-RT the only way capsules can communicate is by sending messages, and the only way to send messages is in actions. If you don't have at least sending actions, you only have a collection of state machine diagrams with triggers that are rather meaningless (*). I see this sort of modelling as a "draft" mode, akin to writing only the skeleton of a Java program where all methods are empty, and therefore no method invokes any other method. I suppose this scenario makes sense in very early stages of development, but I'm not sure I know any programmer who starts writing code by writing only a set of empty methods.
This brings us to the more high-level question of how are we to support such "sketching" or "drafting" mode, and what is to be considered "sketching". At some level, sketching could be just using a drawing tool (or a whiteboard). Using Papyrus already constraints such sketching, as the models will adhere to the UML meta-model, and in our case, to the UML-RT profile. This limits the form which models can take. So what is envisioned for this? If drafting is to be supported, then we would need to know what forms of drafting should be supported, w.r.t. tooling, validation, codegen and runtime, as a drafting model has implications on all of these.
(*) Had I designed UML-RT, I would've given actions a more "first-class" role, since they are not truly orthogonal to the semantics of the language.
Hi,
First of all, I just want to clarify that this is not an argument about whether the run-time model library is target/action language agnostic or not. I'm perfectly happy with the intention of keeping the run-time model library target/action language agnostic, even though I could also very well see that we could have different run-time model libraries, depending on target/action language and let the target language "shine through" in the run-time model library if that makes things easier. But that' s a completely different question, and I have no intention of bringing that discussion up again! :)
So we just state that the run-time model library is target/language agnostic and that it can be placed in the "Common Runtime" 'box' that I made in my little sketch (Reference [3] in Remi's first mail in this thread).
This is more related to if you actually need the run-time model library at all, in certain modeling scenarios. If you haven't choosen to install any specific target/action language, then as I said, the use of the run-time model library is still pretty limited, even though it is target/action language agnostic. I really do not see why you would like to model stuff with e.g. the empty Frame protocol, if you are not planning on writing any action code? And since you mention rtBound/rtUnbound, I also have a hard time to see why you would like to create a state-machine with triggers based on such low-level protocol messages like rtBound/rtUnbound, if you are actually not planning on writing any action code as the next step (and actually have a run-time that generates events based on those protocol messages during run-time). For me all this is about which abstraction level (how "sketchy") you plan your model to be. And this is especially true when doing systems modeling based on UML-RT (which is what I have been involved in for the last 10+ years... :)
If you are modeling on an abstraction level where you don't have the need for action code, then you are highly likely also without the need to go into any of the details in the run-time model library.
_______________________________________________
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