Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] First 0.9.0 bug (maybe)
I come a bit late into this discussion, so I do not have all the background on past dicussions that you folks have. Nevertheless, that won't stop me from voicing my opinions:

(1) In ObjecTime/ROOM, there was a clear distinction between the "concurrency level", which incorporated capsules, protocols, and state machines, and a "passive data level", which covered passive classes and their behaviors. The latter was used for capturing message data and local capsule variables. However, it was still all one language, with two clear domains. I mention this not for nostalgic reasons, but because this provided a useful conceptual and methodological framework that helped people decide where and when to use which parts of the language. From what I recall from user feedback, this crisp partitioning worked out well. As things currently stand, the UML-RT/UML split does not bring out this distinction clearly enough, nor does it provide the kind of methodological guidance that existed in ObjecTime/ROOM. I suspect that people, especially beginners, will be confused as to which they should choose (UML-RT or UML) at a given point. My suggestion (which may not be appreciated much by legacy RSA RTE users) is to make the concurrent/passive split more explicit. It may come down to simply renaming the menu items (e.g., instead of the terms "UML-RT" and "UML" use terms such as, respectively, "Concurrency" and "Passive" - or something similar). This also reenforces the view that this is one language, not two that have been duct-taped together arbitrarily.

(2) Remember that we may want to support passive class state machines, which means that these state machine diagrams will have to be made available for passive classes.

(3) Similarly, I think we must allow protocol state machines (standard UML ones are quite sufficient) to be associated with protocols.

Cheers... Bran

On Tue, Mar 28, 2017 at 6:48 AM, Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:
Hi,

Some comments inline.

/Peter Cigéhn

On 28 March 2017 at 12:31, Remi Schnekenburger <rschnekenburger@eclipsesource.com> wrote:
Hi,

The example of being forced to use UML menu to create extension makes me feel that there is something missing in our current configuration (we just had 0.9, we have room for improvment). I would expect that from the UML-RT menu, we can build any simple UML-RT model. My comprehension about UML-RT language is that it includes the required subset of 'plain' UML it needs, a bit as SysML relies on its UML4SysML subset of the UML language. In this case, generalization should be part of the UML-RT relathionship menu, the UML menu being used when dealing with for example activities or sequence, which are currently not part of the language. The content of the UML subset required for UML-RT should be at least what is  needed in the facade (just guessing here...)

​Regarding the relationship menu and creation of the generalization, it was probably just a misunderstanding. I reopened bug 507284 and bug 507554 due to this, and the remaining issue of having them on a separate UML-RT specific menu are currently planned for future.
​

So what you proposed in the bug 507277 seems a very good starting point. Again, placing the relationship menu under new UML-RT Child, or as a sibling of it, is rather user dependent. It depends if you have a wide screen or one with a bigger height ;) I would place it at the same level of the new UML-RT Child menu, only because the semantic behind the selected element against which the menu is build is not the same. For the nodes, the selection will be the container of the created element. For the relationship, the selection is the source of the created element, and may not be the container.  

For the UML property view, I would indeed propose to hide it on the basic level, as any required UML property should be accessible from UML-RT property view. And yes, both things (menus and property views) should be related, and the Architecture Framework should be the "glue" for those configurations.

So as a conclusion for the diagrams, it would be natural to continue on the same approach, e.g. creating a new UML-RT diagram menu?

​Yes, I would say that if we have started off with a separate UML-RT new child menu, separate UML-RT tab in properties view, that maybe the best is to extrapolate and continue in ​that direction also for the relationship and diagram menus. Yes, it will be more menus when you want to use both the standard UML ones, and the UML-RT specific ones. But in the scenario where you *only* have the UML-RT specific ones, it will not be an issue.

And with the new architecture framework, maybe it makes sense to not even mix UML-RT and basic UML in the same model. If you want to use both, then partition you "logical" model into multiple models, where each part (model) is registered with its architecture. Then we do have the scenario where these multi-models all load into the same model editor (which was brought up in some initial discussion around this), which needs to be sorted out. Maybe we need to play around a bit with all these scenarios now when we have the new framework in place. But since all this is completely new, fresh off the presses, I am not sure that we all have understood yet how to use it at its best (and there are probably scenarios which have not even been considered by those that so far have developed the new framework, for which we need to start provide feedback when we start understanding it ourselves).

/Peter Cigéhn
 

Cheers,
Rémi










2017-03-28 11:04 GMT+02:00 Peter Cigéhn <peter.cigehn@xxxxxxxxx>:
Hi,

No it is far from obvious which approach, i.e. separate UML-RT specific menus or having filtered version of some common menu, is best from a user experience point of view. We have had this discussion not only regarding the new diagrams menu, but also for the new relationship menu (where bug 507277 proposes to have a separate UML-RT specific menu, but we currently create generalizations using the "ordinary" UML menu).

I see this as highly related also to the principle of a separate and customized UML-RT tab in the properties view, vs. the ordinary standard UML one (which we do not customize/filter at all). There we have discussed to configure it so that the UML tab is not shown at all, for the minimal, pure, UML-RT experience. But for the advanced user, or the scenario where UML-RT is mixed with ordinary UML modeling, you can have both tabs.

The legacy tooling have really not had any specific UML-RT menus, or tabs in the properties view, but have "blended" things in with ordinary UML modeling. Personally I like the style that we started using in Papyrus-RT better, i.e. a separate UML-RT new child menu and a completely separate UML-RT tab in the properties view. But still I don't know which one of these two approaches gives the best overall user experience, for all the different scenarios we can see and different configurations of Papyrus-RT, from the "miminal" Papyrus-RT configuration to combining UML-RT with base UML or possibly other DSMLs.

/Peter Cigéhn

On 28 March 2017 at 10:48, Remi Schnekenburger <rschnekenburger@eclipsesource.com> wrote:
Hi,

I would find also comfortable and it would improve user experience to be able to create a UML-RT state machine diagram on a capsule, with the implicit creation of the RT-state machine and all usual content (region/state/initial/initial trans). And at the same time, the ability to create a plain state machine diagram should be removed.

For the creation of a new sub-menu dedicated to UML-RT diagrams, I am not sure that it may be of interest. I would have rather imagine a "new view" menu, with all tables/UML diagram/UML-RT diagram/ Further customized UML-RT diagrams at the same place, and its content filtered based on the active viewpoint(s).
I could imagine that several viewpoints would exist for plain Papyrus-RT, at least 'basic' and 'advanced'. With basic, you would find only the new UML-RT child menu and only access to UML-RT customized diagram, advanced would had the new UML one, and access also to plain UML diagrams. So beginners would have a quite straight user experience, with less available menus, and experts would still have access to the full UML stack. 
But I know we have been discussing of that UML-RT specific menus quite a lot in the past ;-)

Cheers,
Rémi
 

2017-03-28 9:27 GMT+02:00 Peter Cigéhn <peter.cigehn@xxxxxxxxx>:
Hi,

Regarding the UML-RT specific diagrams on the "New Diagram..." menu is apparently pretty confusing. I wrote bug 511187 to track some improvements in this area, specifically regarding the creation of state-machine diagrams. The existence of the possibility of creating UML-RT specific diagrams on the "New Diagram..." menu have never been intentional (if it ever have been possible). We for example removed the possibility of creating these diagram types in the new model wizard, since it does not make sense to create a "stand alone" capsule structure diagram, or state-machine diagram, without a capsule or state-machine. See for example the discussion in bug 475805. The creation of these diagrams have always been intended to be made automatically when creating the capsule or the state-machine. But apparently this seem to be confusing.

So if users expect the possibility of being able to create the diagrams directly, then we probably should extend bug 511187 to also cover the creation of capsule structure diagrams. But the behavior then should of course be to create the capsule (at the location where the user selects to create the diagram) and then as usual let the creation of the capsule create its owned/nested capsule structure diagrams. We should probably also think through whether we shall have a specific, "New UML-RT Diagram..." menu, similar to the specific "New UML-RT Child..." menu, to make it clear where you find the standard UML stuff, vs. the UML-RT specific stuff.

Some more comments inline below.

On 27 March 2017 at 22:39, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
I realized something. Setting the Viewpoint configuration did work. But I thought it didn't because the new diagram types are not available anymore in the "New Diagram..." context menu. I was not aware that these had been removed. But otherwise it works fine now, so yes, it was the Viewpoint configuration after all.

I did this exercise precisely because a user had trouble when attempting it. He wanted to install it using the update site because he wanted to be able to have Papyrus-RT together with other modelling tools in the same Eclipse environment. Is it possible to make such mixtures with the Eclipse Installer?

 
​Well, if you write your own setup file, making a "combined" setup file for Papyrus-RT together with whatever else you want to have installed, then that I guess should be fine (unless that other modeling tool for some reason have some conflict with Papyrus/Papyrus-RT). Personally I think that every tool-smith, that works with putting together their own configuration of Papyrus-RT with whatever else they want, should spend time on learning how to author Oomph setup files. Personally I think that it is a well spent investment, that gives payback just for a few re-installations of your specific setup... 



On Mon, Mar 27, 2017 at 1:33 PM Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:
Hi,

Just for the sake of it, I tried doing a manual installation directly from the p2 repositories. I started with downloading the Neon.3 C/C++ package. Then I added

I started from the minimal platform: the bare Eclipse platform. 

​Okay, so you made the initial installation with the Eclipse Installer? I cannot find a downloadable .zip-file with only the Eclipse platform. I was doing this test with a scenario that I found more likely, i.e. for a user that already had an existing Eclipse installation, based on one of the packages.

Anyway, I guess it should not really matter (as we already have concluded) which initial installation you base this scenario on.
​
 
all the needed repositories, i.e. the same list as in the Oomph setup file. Made sure to only have those enabled. Then I installed all the features, selecting "All Available Sites“ so I could install all features at once. Selected the same features as in the Oomph setup file apart from CDT and EGit since they were already part of the package. 

After installation everything worked as expected. I could switch to the Papyrus perspective and I could switch to the UML-RT viewpoint. Creating a capsule with a statemachine also created the diagrams as expected. So from what I can tell this all works as expected. 

I think we are back to the fact that we have no good instructions. So I really don't know what you did that made it not work. As Charles wrote, we will have expert users running into the same issues as you did Ernesto. 

To be honest though, I don't understand how anyone would like to go through this when you use an Oomph setup file instead... ;-)

/Peter Cigéhn 

Den 27 mars 2017 6:17 em skrev "charles+zeligsoft.com" <charles@xxxxxxxxxxxxx>:
+1 on:

I don't think so. But the website does warn that this option is for "Eclipse veterans”.


Exactly. Since we point out that using the p2 is for "experts", we could just put a short list of the requirements and settings in the wiki, rather than comprehensive instructions.



However…we do need to be ready to answer questions from the expert Eclipse veterans… Forewarned is forearmed!

_______________________________________________
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
--
Ernesto Posse
Zeligsoft

_______________________________________________
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




--
Remi Schnekenburger

Senior Software Architect / General Manager
EclipseSource Paris

Email: rschnekenburger@eclipsesource.com
Web: http://eclipsesource.com/paris 
Phone: +33 1 85 41 08 65
German Phone: +49 89 21 555 30 - 25
Hangouts: rschnekenburger@eclipsesource.com

EclipseSource France SAS
7 rue de la Croix Martre
91120 Palaiseau

General Manager: Remi Schnekenburger
Registered Office: 7 rue de la Croix Martre, 91120 Palaiseau, France
Commercial Register 824 977 516  R.C.S. EVRY

_______________________________________________
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




--
Remi Schnekenburger

Senior Software Architect / General Manager
EclipseSource Paris

Email: rschnekenburger@eclipsesource.com
Web: http://eclipsesource.com/paris 
Phone: +33 1 85 41 08 65
German Phone: +49 89 21 555 30 - 25
Hangouts: rschnekenburger@eclipsesource.com

EclipseSource France SAS
7 rue de la Croix Martre
91120 Palaiseau

General Manager: Remi Schnekenburger
Registered Office: 7 rue de la Croix Martre, 91120 Palaiseau, France
Commercial Register 824 977 516  R.C.S. EVRY

_______________________________________________
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