Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] Integration of the rts model library in the core
Hi,

I have a hard time seeing actual use of modeling with the run-time model library, but without any specific target/action language selected. As I already indicated in my little sketch, the run-time model library (if placed in the "Common Runtime" part) gets included by selected a specific target/action language feature (C++ or Java in the sketch).

As soon as you want to model run-time stuff, e.g. add an SAP based on any of the system protocols in the run-time model library, then you are a very small step away from needing a target language and actually reference that SAP in your action code. Keep in mind that two of the three system protocol actually do not have any protocol messages, since they are accessed directly as methods on the C++ representation of the port. So the use for adding SAPs based on empty protocol, without writing action code is pretty limited.

Sure, there could be some special cases where you are doing some "sketchy" modeling and still want to add SAP ports (based on "empty" protocols), but not write any action code. But I have a feeling that this is such an uncommon case, and if this is needed, then I would like to propose that you have to select a action/target language to be able to do that. Just to reduce the number of choices and alternatives.

So I would like to simplify things to cover two cases: Structure modeling (optionally with high level state machine modeling), but no code-generation/run-time support (and no run-time model library) and full-fledged UML-RT modeling with code-generation/run-time (including the run-time model library).

/Peter Cigéhn

On 27 April 2016 at 16:22, SCHNEKENBURGER Remi 211865 <Remi.SCHNEKENBURGER@xxxxxx> wrote:

Sorry, I meant “Papyrus-RT” core, not “Papyrus” for the new place for the runtime system model library.

 

“Load registered package" for UMLRT-RTS.uml integration should be still added and present in tooling part, as this is probably the only place where this is needed. So it would be still accessible in Papyrus environment easily, and keep a small dependency footprint for code generators. I will move this extension to a tooling.xxx plugin.

 

I am now thinking about the integration and the automatic loading of the model library when creating a new model. The default language framework may provide support there, but it seems we will have 3 different possibilities when creating a new model, with all current extensions installed:

-        Structural modeling with no support (reference / load) of the runtime model library

-        Model with support of the runtime model library

-        Model with C++ support

Do you see some other case?

 

Regards,

Rémi

 

 

 

-------------------------------------------------------

 

Rémi SCHNEKENBURGER

+33 (0)1 69 08 48 48

CEA Saclay Nano-INNOV

Institut CARNOT CEA LIST

 

Description : PapyrusLogo_SmallFormatwww.eclipse.org/papyrus

 

De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de charles+zeligsoft.com
Envoyé : mercredi 27 avril 2016 14:39
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Integration of the rts model library in the core

 

Some comments inline below.

 

/Charles

 

On 2016.04.27, at 06:29 , SCHNEKENBURGER Remi 211865 <Remi.SCHNEKENBURGER@xxxxxx> wrote:

 

Hi all,

 

I restart the work on these bugs [1] this week. I wanted to integrated quite fast, as it impacts the architecture of the tool, especially having some impact on code generator and tooling.

 

The contribution on gerrit [2]  is ongoing, we are only facing now some small issues on the integration/testing part. Thanks to Ernesto, the contribution for the testing of the code generator was updated. I can easily now integration the contribution if it is OK with everyone, I just have to remove the reviewer Hudson-ci from the list of reviewers, and its -1 will be removed from the votes. Some historic discussion already happened on that mailing list [3]

 

However, before integrating this contribution, I wanted to be sure everyone was OK on it:

-        I created a new plugin for the rts model library. This model is supposed to be independent from any implementation language, so I added it to the core part of Papyrus, with no link to C++ as it was before. In fact, RTS model library and the runtime were distributed in the same plugin historically for convenience.

 

<cr>

I don’t think it should be in Papyrus Core. It really only belongs in Papyrus-RT. This library and the runtime is specific to UML-RT and therefore to Papyrus-RT.

</cr>



-        I moved the library in this new plugin, cleaned bit the dependencies, and I would like also to remove the extension as a Papyrus library. This declaration is used only for a tooling point of view, to be listed in the list of available registered libraries, it has no impact on the element resolution when model is loaded. Removing it would remove the dependency of the library to Papyrus, thus making it usable on standalone model transformation / code generation / etc.

 

<cr>

Regarding the part about the extension, does that mean it will no longer show in the “Load registered package”? I agree with this as long as it is automatically included in models. Actually, since Ericsson is (or planning on) using Papyrus-RT as a DSML platform that may not require the codegen or RTS, automatic inclusion may not be an ideal solution, but then you should also be able to remove stuff when creating a DSML.

However, it must be tied to the UML-RT code generation and the actual runtime. So if you are planning on using one of these, all three must be available in the toolset. Perhaps an option for UML-RT code generation on project/model setup, with default on inclusion (as I believe it to be the most common option)?

</cr>



-        I changed the pathmap location. It now points to the new plugin, so there are no impacts on the existing models referencing the model library by the pathmap (which should be always the case).

-        The o.e.prt.rts only contains the generated C++ code. As it is C++ dependent, I would advise to make it obvious in the namespace.

-         

Does everyone agree on that changes?

 

Once the contribution is merged, I can finish the work on the system protocol identification (and system classes by the way) relying on default language framework & specific profile

 

Regards,

Rémi

 

 

[1] Bug 488104: Identify UML-RT system classes in UMLRT-RTS model library

Bug 477721: Decide on common principle to identify system protocols,

including base protocol in UML-RT model library

 

 

 

-------------------------------------------------------

 

Rémi SCHNEKENBURGER

CEA Saclay Nano-INNOV

Institut CARNOT CEA LIST

 

<image001.png>www.eclipse.org/papyrus

 

_______________________________________________
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


Back to the top