| I actually agree with Ernesto in that the services provided by the runtime library are part of the UML-RT language definition and therefore comparable to the UML-RT profile and the validation rules.
I also agree with Peter in that there are many cases within “sketching” of an architecture where the runtime library is not needed and I agree that the two scenarios Peter described in his Wed, Apr 27, 2016 at 10:38 message are reasonable, with the caveat expressed further below. So the two “packages I would see are:
- UML-RT based structure modeling (we can already do structure modeling in UML, UML-RT is a differentiator); optional high level state machine modeling); optional UML-RT model library (which we could rename to something more palatable for all scenarios); no code generation
- Full-fledged UML-RT modeling with code-generation/run-time (including the run-time model library)
However, I disagree with Peter that could not be helpful, for example as an intermediate step between the architecture and the implementation or to illustrate that there are cases where capsule parts must be connected before they can start processing (ergo the need for rtBound and rtUnbound) or a case where a timeout to a process is required - where you do not need to have action code for it to be meaningful. Granted, in this cases you could just create empty but named triggers, but then you would start moving away from UML-RT, which is also a scenario worth considering.
Finally, I think that all we need right now is to address the most common scenarios, as described by and Rémi (in his 27 April 2016 at 16:22 message) and corrected by Peter (in his Apr 27, 2016 at 10:38 AM message), while enabling users to still bring in the runtime library if they so desire by still having the “Load registered package" for UMLRT-RTS.uml (re: Rémi in his 27 April 2016 at 16:22 message).
Thanks and regards,
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.
/Peter Cigéhn
_______________________________________________ papyrus-rt-dev mailing list papyrus-rt-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
|
