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,

Depends on what you mean with "Papyrus-RT-based DSL", and how much tooling/customization that you expect to be built/implemented on top of Papyrus-RT for it to be called a DSL. Do you count the use of MMA from MMA, as a "Papyrus-RT-based DSL"? 

I we take the systems modeling perspective, I would expect that there will be a need for the "RT interaction profile" (or whatever we will call that), on top of what we have planned so far. Not sure either if that counts as a "Papyrus-RT-based DSL", since it just handling the aspects of using UML-RT in the context of interactions/sequence diagrams. This I just see as a structuring of the UML-RT profile into separate parts (similar to how the state-machine aspect is kept in a separate profile, from the core structuring aspects in the core UML-RT profile).

Additional "DSL aspects" I could very well see that you can handle with 3PP tools like MMA from Adocus, and then you don't need any additional tooling implemented (since MMA handles that completely dynamically based on the meta-model iin form of an ordinary class model that you feed it). Or that you just combine the use of plain UML, e.g adding use case diagrams and activity diagrams into the mix of using structure modeling from UML-RT.

So, yes, I could expect people wanting to use the structural part of Papyrus-RT, without necessary go as far as they create a "Papyrus-RT-based DSL" (if we exclude the use of MMA).

/Peter Cigéhn

On 27 April 2016 at 14:42, charles+zeligsoft.com <charles@xxxxxxxxxxxxx> wrote:
Peter:

Do you see people wanting to use only the structural part of Papyrus-RT without using it as part of a Papyrus-RT-based DSL?

/Charles

On 2016.04.27, at 07:55 , Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:

Hi,

The move of the run-time model library, I am not fully sure that I agree that being part of "Core". As I draw the picture in [3] I see the placement of the run-time model library more in the "Common Runtime" part, outside of "Core".

I really think that we must consider how UML-RT can (and will) be used in context where neither the code-generator, nor the run-time (including the run-time model library) ever being used, e.g. when using UML-RT as the base for systems modeling or using UML-RT as a base for other DSMLs where you probably only are using the structuring modeling aspects of UML-RT.

In those cases, I would like to see that the user does not have to bring a long the run-time model library at all in their installation, if the user is only interested in the structure modeling aspect of Papyrus-RT.

/Peter Cigéhn

On 27 April 2016 at 12: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.

-        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.

-        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

https://bugs.eclipse.org/bugs/show_bug.cgi?id=488104

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

including base protocol in UML-RT model library

https://bugs.eclipse.org/bugs/show_bug.cgi?id=477721

 

[2] https://git.eclipse.org/r/#/c/67560/

 

[3] https://dev.eclipse.org/mhonarc/lists/papyrus-rt-dev/msg00215.html

 

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

 

Rémi SCHNEKENBURGER

+33 (0)1 69 08 48 48

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


_______________________________________________
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