Community
Participate
Working Groups
Created attachment 243285 [details] before applying the stereotype Steps to reproduce: - Create a simple SysML model with a requirements table inside - Add a requirement into the requirements table (see screenshot : before) - Create a profile that contains a single stereotype that extends the SysML Requirements stereotype, for instance by adding some extra property - Apply the profile to the model - Apply the stereotype to the requirement in the model Result: The requirements table is now corrupt and contains the error message instead of the original content: "Several stereotypes with this feature are applied -> not yet managed" (see screenshot : after) Tooling info: Papyrus UML (Incubation) 1.0.0.v201405200454 org.eclipse.papyrus.sdk.feature.feature.group Eclipse Modeling Project
Created attachment 243286 [details] after applying the stereotype
This doesn't really look like a bug; more like something which is not supported, because you're not using the Requirement Table in an intended way If you stereotype extends Requirement, then you should only have this stereotype applied (And remove requirement), which would avoid the duplicate property. But then, I suppose the requirement table wouldn't recognize your custom Requirement as a Requirement. So, you should probably use a different kind of Table (Generic Table, or a custom one)
(In reply to Camille Letavernier from comment #2) > > If you stereotype extends Requirement, then you should only have this > stereotype applied (And remove requirement), which would avoid the duplicate > property. But then, I suppose the requirement table wouldn't recognize your > custom Requirement as a Requirement. Hmm ... it is not permitted by UML to have the same stereotype applied multiple times, which is what we get if Requirement and its sub-stereotype are both applied (thus Requirement being applied twice), so the reporter shouldn't have been able to get into such a situation.
(In reply to Camille Letavernier from comment #2) > This doesn't really look like a bug; more like something which is not > supported, because you're not using the Requirement Table in an intended way > > If you stereotype extends Requirement, then you should only have this > stereotype applied (And remove requirement), which would avoid the duplicate > property. But then, I suppose the requirement table wouldn't recognize your > custom Requirement as a Requirement. > > So, you should probably use a different kind of Table (Generic Table, or a > custom one) I just started realising this myself. It seems like the best way to achieve this SysML-based-DSL in papyrus is to create a new stereotype that directly extends the meta-class Class, and has an OCL constraint stating that its base_Class also should have the Requirement stereotype set. In this way, there's no need (at the "cost" of having two stereotypes) Let's close this one, although to say the least corrupting the table is a weird way of saying to the user that he's followed the wrong path here...
(In reply to Klaas Gadeyne from comment #4) > (In reply to Camille Letavernier from comment #2) > > This doesn't really look like a bug; more like something which is not > > supported, because you're not using the Requirement Table in an intended way > > > > If you stereotype extends Requirement, then you should only have this > > stereotype applied (And remove requirement), which would avoid the duplicate > > property. But then, I suppose the requirement table wouldn't recognize your > > custom Requirement as a Requirement. > > > > So, you should probably use a different kind of Table (Generic Table, or a > > custom one) > > I just started realising this myself. It seems like the best way to achieve > this SysML-based-DSL in papyrus is to create a new stereotype that directly > extends the meta-class Class, and has an OCL constraint stating that its > base_Class also should have the Requirement stereotype set. > In this way, there's no need (at the "cost" of having two stereotypes) Hmm, the mid-air collision also ate the rest of this sentence it seems :-( This should have read: In this way, there's no need to _re_create all the nice SysML customization stuff and one can reuse the SysML requirements table (at the "cost" of having two stereotypes) > Let's close this one, although to say the least corrupting the table is a > weird way of saying to the user that he's followed the wrong path here...
Just checking, is this to be closed and is the recommended way to go as described: ...It seems like the best way to achieve this SysML-based-DSL in papyrus is to create a new stereotype that directly extends the meta-class Class, and has an OCL constraint stating that its base_Class also should have the Requirement stereotype set. In this way, there's no need (at the "cost" of having two stereotypes)... Because I have A LOT of specializations of Requirement (implementing SYSMOD) and are experiencing this issue as well. Or is there a change to the tables coming? Regards, Tomas Sandkvist
Hi Thomas, (In reply to Tomas Sandkvist from comment #6) > Just checking, is this to be closed and is the recommended way to go as > described: > > ...It seems like the best way to achieve this SysML-based-DSL in papyrus is > to create a new stereotype that directly extends the meta-class Class, and > has an OCL constraint stating that its base_Class also should have the > Requirement stereotype set. > In this way, there's no need (at the "cost" of having two stereotypes)... > > Because I have A LOT of specializations of Requirement (implementing SYSMOD) > and are experiencing this issue as well. > > Or is there a change to the tables coming? (I was woken up by https://www.eclipse.org/forums/index.php/mv/msg/981174/1602954/#msg_1602954) My 2 cents: - From a language definition point of view, the "SYSMOD approach" (and my original one) seems to make a lot of sense + It will be a lot faster to define the new stereotypes using inheritance + For somebody studying the profile, it is much clearer what is meant without having to study/examine OCL constraints - From a language/tooling usage it's not so clear to me + As the original bug demonstrated, it would (at least at this point in time) require a lot more tooling customizations if one would use the above approach. Especially for _lightweight_ customizations of existing languages (such as the SysMOD extension to SysML), this does not seem to be a good option IMHO. So you could argue that this is indeed a tooling issue, and that it is papyrus' job to let you reuse as much of the infrastructure as possible if you define _without_ the 'need' of applying the same stereotype twice. More concretely, this would mean that papyrus would 'recognise' that <<YourRequirementExtension>> generalizes <<SysML::Requirement>> and that it would then (if wanted) would allow you to reuse the existing tooling customization for SysML, even if you don't use the original <<SysML::Requirement>> stereotype As such, I will leave the bug open for now:-) + OTOH, From the perspective of some that wants to create/use/prototype the SysML-based-DSL, I could even understand that one says: "I don't even want to do any tooling customization", I just want to drag a requirement from the existing SysML tool, and indicate that it is of a special type YourRequirementExtension by applying a stereotype. In that case, I would argue that the problem is not really at the papyrus side, but rather on the side of the UML spec. And that this might a drawback of UML profiles. Side remark: AFAIR Tim Weilkiens does have a Magicdraw version of SysMOD available. Do you know how it is implemented in Magicdraw?
Created attachment 250572 [details] MagicDraw SYSMOD
(In reply to Klaas Gadeyne from comment #7) > Hi Thomas, > > (In reply to Tomas Sandkvist from comment #6) > > Just checking, is this to be closed and is the recommended way to go as > > described: > > > > ...It seems like the best way to achieve this SysML-based-DSL in papyrus is > > to create a new stereotype that directly extends the meta-class Class, and > > has an OCL constraint stating that its base_Class also should have the > > Requirement stereotype set. > > In this way, there's no need (at the "cost" of having two stereotypes)... > > > > Because I have A LOT of specializations of Requirement (implementing SYSMOD) > > and are experiencing this issue as well. > > > > Or is there a change to the tables coming? > > (I was woken up by > https://www.eclipse.org/forums/index.php/mv/msg/981174/1602954/#msg_1602954) > > My 2 cents: > - From a language definition point of view, the "SYSMOD approach" (and my > original one) seems to make a lot of sense > + It will be a lot faster to define the new stereotypes using inheritance > + For somebody studying the profile, it is much clearer what is meant > without having to study/examine OCL constraints > > - From a language/tooling usage it's not so clear to me > + As the original bug demonstrated, it would (at least at this point in > time) require a lot more tooling customizations if one would use the above > approach. Especially for _lightweight_ customizations of existing languages > (such as the SysMOD extension to SysML), this does not seem to be a good > option IMHO. So you could argue that this is indeed a tooling issue, and > that it is papyrus' job to let you reuse as much of the infrastructure as > possible if you define _without_ the 'need' of applying the same stereotype > twice. More concretely, this would mean that papyrus would 'recognise' that > <<YourRequirementExtension>> generalizes <<SysML::Requirement>> and that it > would then (if wanted) would allow you to reuse the existing tooling > customization for SysML, even if you don't use the original > <<SysML::Requirement>> stereotype > > As such, I will leave the bug open for now:-) > > + OTOH, From the perspective of some that wants to create/use/prototype > the SysML-based-DSL, I could even understand that one says: "I don't even > want to do any tooling customization", I just want to drag a requirement > from the existing SysML tool, and indicate that it is of a special type > YourRequirementExtension by applying a stereotype. In that case, I would > argue that the problem is not really at the papyrus side, but rather on the > side of the UML spec. And that this might a drawback of UML profiles. > > Side remark: AFAIR Tim Weilkiens does have a Magicdraw version of SysMOD > available. Do you know how it is implemented in Magicdraw? Hi Klaas! It appears to be through extension, see attachment. Found at http://example.system-modeling.com/#Diagrams___17_0_4_2_3c00182_1383042645268_401693_14948
Hi, (In reply to Tomas Sandkvist from comment #9) > (In reply to Klaas Gadeyne from comment #7) > > Side remark: AFAIR Tim Weilkiens does have a Magicdraw version of SysMOD > > available. Do you know how it is implemented in Magicdraw? > > Hi Klaas! > > It appears to be through extension, see attachment. Found at > http://example.system-modeling.com/ > #Diagrams___17_0_4_2_3c00182_1383042645268_401693_14948 I've had a quick look, but it's hard to draw conclusions from this online visualisation. I was trying to find out if the Car Access System, (which has the <<System>> Stereotype applied that generalizes <<Block>>) also would have the <<Block>> stereotype applied. Unfortunately, I cannot conclude anything from the diagrams, for instance http://example.system-modeling.com/#Package___15_1_3c00182_1208274398703_434904_4794 only _shows_ the <<system>> stereotype, but that doesn't mean that the <<block>> stereotype is not applied however. So far, it's inconclusive to me (I'll have to check it when I get into the office and get my hands on the MD license) However, some things do seem a little fishy to me: For instance, at http://example.system-modeling.com/#Architecture___15_1_3c00182_1214400915109_462076_5113, you can see that even the lifeline object has the stereotype system applied (even though it only _points_ to the system).
(In reply to Klaas Gadeyne from comment #10) > Hi, > > (In reply to Tomas Sandkvist from comment #9) > > (In reply to Klaas Gadeyne from comment #7) > > > Side remark: AFAIR Tim Weilkiens does have a Magicdraw version of SysMOD > > > available. Do you know how it is implemented in Magicdraw? > > > > Hi Klaas! > > > > It appears to be through extension, see attachment. Found at > > http://example.system-modeling.com/ > > #Diagrams___17_0_4_2_3c00182_1383042645268_401693_14948 > > I've had a quick look, but it's hard to draw conclusions from this online > visualisation. I was trying to find out if the Car Access System, (which > has the <<System>> Stereotype applied that generalizes <<Block>>) also would > have the <<Block>> stereotype applied. Unfortunately, I cannot conclude > anything from the diagrams, for instance > http://example.system-modeling.com/ > #Package___15_1_3c00182_1208274398703_434904_4794 only _shows_ the > <<system>> stereotype, but that doesn't mean that the <<block>> stereotype > is not applied however. So far, it's inconclusive to me (I'll have to check > it when I get into the office and get my hands on the MD license) > > However, some things do seem a little fishy to me: For instance, at > http://example.system-modeling.com/ > #Architecture___15_1_3c00182_1214400915109_462076_5113, you can see that > even the lifeline object has the stereotype system applied (even though it > only _points_ to the system). I've had some direct contact with Mr. Weilkiens through Google+. and AFAIK he appears interested in helping people out, if that would become necessary. But you'll probably figure it out if you do have access to MagicDraw (poor me, will never have such expensive tools to play around with)
(In reply to Tomas Sandkvist from comment #11) > (In reply to Klaas Gadeyne from comment #10) > > Hi, > > > > (In reply to Tomas Sandkvist from comment #9) > > > (In reply to Klaas Gadeyne from comment #7) > > > > Side remark: AFAIR Tim Weilkiens does have a Magicdraw version of SysMOD > > > > available. Do you know how it is implemented in Magicdraw? > > > > > > Hi Klaas! > > > > > > It appears to be through extension, see attachment. Found at > > > http://example.system-modeling.com/ > > > #Diagrams___17_0_4_2_3c00182_1383042645268_401693_14948 > > > > I've had a quick look, but it's hard to draw conclusions from this online > > visualisation. I was trying to find out if the Car Access System, (which > > has the <<System>> Stereotype applied that generalizes <<Block>>) also would > > have the <<Block>> stereotype applied. Unfortunately, I cannot conclude > > anything from the diagrams, for instance > > http://example.system-modeling.com/ > > #Package___15_1_3c00182_1208274398703_434904_4794 only _shows_ the > > <<system>> stereotype, but that doesn't mean that the <<block>> stereotype > > is not applied however. So far, it's inconclusive to me (I'll have to check > > it when I get into the office and get my hands on the MD license) Magicdraw seems to get it fairly right: 1/ The SysMOD profile in Magicdraw comes in the form of a SysMOD plugin. This plugin defines specific diagrams (such as the SysMOD BDD Diagram), which, in papyrus speak, seems to be nothing more than a customized palette added to the block definition diagram 2/ When you create a <<System>> item from that palette, it does _not_ have the stereotype <<Block>> applied! 3/ When you select the <<System>> artefact in the MD equivalent of the model explorer, and try to add additional stereotypes, it's _not_ possible to add the <<Block>> stereotype to it unless your remove the <<System>> Stereotype first! 4/ In a requirements (traceability) table, all elements that generalize a given concept show up. So if you select <<Requirement>> as the 'base' element, also elements stereotyped with <<MyCustomRequirement>> will be shown in the table. The possible disadvantage I see of the approach is the "OTOH" statement I made in comment #7. It's not directly obvious to me how for instance I could combine the SysMOD profile with a custom profile and do some quick prototyping (but then again, I don't know Magicdraw at all). Now, all this being said, I've also redid a quick experiment regarding item 4/ above in Papyrus (luna nightly build). It seems like, as long as you make sure that only one stereotype is applied, the same approach (today) works perfectly [*] fine in papyrus. This means that Camille's statement in comment #2 (see quote below) is not true (anymore). [quote] But then, I suppose the requirement table wouldn't recognize your custom Requirement as a Requirement. So, you should probably use a different kind of Table (Generic Table, or a custom one) [/quote] So to summarize, there seems to be only one problem here. Therefor I'm going to retitle this bug into "Papyrus should not allow to apply the same stereotype twice". Given the number of questions that deal with this matter on the forum, I guess this is a critical bug for DSMLs using UML profiles. If you are prototyping, you should realize that you first need to remove the original stereotype and only afterwards can apply the inherited version. If anyone disagrees, please speak up :-) [*] To be honest: that is a lie! I did encounter some trouble when I defined a new version of my custom profile -> all elements typed by <<MyRequirement>> disappeared from the requirements table and I had to delete and recreate it (but then again, this is definitely another bug :-)
Today, I got my hands on a profile and model in papyrus MARS that demonstrated this bug. (aka. damned, we should have discussed this during the DSML workshop last week :-)
Don't know if this belongs here/is related, but I have not been able to show the stereotype parameters in a requirement diagram in Mars. These are shown with 'null' as data. Should this be a separate bug do you think or part of the issues worked with within the context of this one? Regards, Tomas
I confirm this bug but it is a normal or a minor bug according to https://wiki.eclipse.org/WTP/Conventions_of_bug_priority_and_severity. As you discussed previsouly, we think it should not be possible to apply a stereotype and its extension on the same element, because in the case of the Requirement Stereotype and CustomRequirement extending Requirement, when they are applied both a an element, there feature are duplicated, you get Req::id and text twice and the feature's values are not synchronized. So
I open a UML2 bug 535456.
