Home » Modeling » Papyrus » extending requirement diagram in SysML
|
| Re: extending requirement diagram in SysML [message #997852 is a reply to message #997795] |
Tue, 08 January 2013 21:47   |
|
Hi, Jeni,
You should be able to import the SysML profile as an imported package
in your profile. In the Model Explorer, select the root package of
your profile and select "Import Registered Package" (not sure of the
exact label) in the context menu. Can you choose the SysML profile in
this dialog? If so, then you'll end up with that profile imported and
its types available to use in generalization relationships,
associations, etc.
However, I'm not sure that the UML2 implementation of "dynamic
profiles" support these kinds of dependencies between profiles very
well. I think it may copy all of the definitions from the referenced
profiles (SysML in your case) into your profile's Ecore definition, so
that at the EMF level you end up with a distinct copy of SysML that
isn't interoperable with the original SysML profile. Perhaps somebody
in this newsgroup knows better than I how this works with dynamic
profiles. I know that dependencies between profiles work well when the
profiles are statically generated.
HTH,
Christian
On 2013-01-08 18:56:19 +0000, Jeni Martin said:
> Hi,
> I just started working with Papyrus and I went through tutorial for
> making UML profiles (with the example of requirement Model). Now I want
> to extend the Requirement element in SysML. So I want to choose
> Requirement as my base metaclass. How can I do that?
>
> Thank you so much in advance for your help.
|
|
| |
| Re: extending requirement diagram in SysML [message #998732 is a reply to message #998727] |
Thu, 10 January 2013 15:19 |
|
Hi, Camille,
Thanks for the correction of the menu action.
Indeed, stereotypes are not metaclasses and thus cannot be extended by
stereotypes. But the Eclipse UML implementation supports
generalization of stereotypes well (though, as I said, I'm not sure
about how practical it is to have generalization relationships to
stereotypes in another profile when the profiles are dynamically
defined).
cW
On 2013-01-10 15:11:59 +0000, Camille Letavernier said:
> Hello,
>
>
> I think the "Import registered package" menu won't work in this case.
> It is intended for UML Libraries.
>
> However, the "Import registered profile" menu will work fine.
>
> You cannot choose the SysML Requirement as the "Base Metaclass" of your
> new Stereotype. Instead, you should create a Generalization between
> your Stereotype and the SysML Requirement.
>
>
> Regards,
> Camille
|
|
| |
| Re: extending requirement diagram in SysML [message #1000588 is a reply to message #1000342] |
Tue, 15 January 2013 04:00 |
|
Hi, Jeni,
A package import adds members of the imported package (SysML profile)
into the importing namespace (your profile), but only those members
that have names that are distinct from all of the names in the
importing namespace. Thus, a package import shouldn't be able to add
duplicate names, which is what this warning is about.
Which element names are repeated?
cW
On 2013-01-14 15:04:26 +0000, Jeni Martin said:
> Hi,
>
> Thank yuo so much for all replies and helps.
>
> I imported the SysML as standard profile and made a new stereotype
> (without any new property)which is the specialization of Stereotype
> Requirement (from SysML). but when I validate it, it says not all
> members of namespace Profile are distinguishable within it.
>
> What do you think?
>
> Thanks.
|
|
| |
| Re: extending requirement diagram in SysML [message #1103504 is a reply to message #1001498] |
Fri, 06 September 2013 22:11 |
 David Hetherington
Messages: 9
Registered: May 2013
Location: Austin, TX |
Junior Member |
|
|
I am also interested in this subject. I would like to create a profile to create the <<System>> stereotype that you see in the first "System Context" diagram of every textbook. Using the original tutorial and the updated hints above, I was able to get this working almost perfectly but with one small remaining problem. Basically, I created my profile, imported the SysML profile, dragged a copy of the <<Block>> element onto my diagram, and then dragged a new stereotype onto the diagram. After naming the new stereotype <<System>> I added a generalization relationship to <<Block>>
(See uploaded file: Asatte_SysML_Profile_System_Generalizes_Block.png)
So far, so good. However, when I then create a test model, add a block and apply the new profile (all of which works as described) it shows up nicely in the model explorer, but not in the actual diagram. Like thisL
(See uploaded file: Not_OK_Diagram_Still_Shows_Block.png)
Looks like a (small) bug to me. Actually, I have a done step-by-step screen captures all the way from zero for this which I could drop into a Word document if that would be helpful... However, I am hoping that it is just something I missed...(?)
David Hetherington
[Updated on: Fri, 06 September 2013 22:11] Report message to a moderator |
|
| |
| Re: extending requirement diagram in SysML [message #1105346 is a reply to message #1104038] |
Mon, 09 September 2013 18:29 |
David Hetherington
Messages: 9
Registered: May 2013
Location: Austin, TX |
Junior Member |
|
|
Thanks, that was helpful! I had not noticed the buttons in the upper right hand corner to toggle the appearance. Now, however, it shows both <<system>> (my new stereotype) and <<block>> (the stereotype it is derived from)
Is there a way to suppress <<block>> and show only <<system>> (?)
In fact, it looks like this behavior has nothing to do with my stereotype.
If I just drag a completely normal SysML block onto my diagram it looks like this:
If I use the right-hand button, it toggles to this:
That is, instead of turning the display of <<block>> on and off, it alternates between one and two copies of <<block>>.... (?)
Thanks,
David Hetherington
|
|
| | |
| Re: extending requirement diagram in SysML [message #1106894 is a reply to message #1105990] |
Wed, 11 September 2013 17:36 |
David Hetherington
Messages: 9
Registered: May 2013
Location: Austin, TX |
Junior Member |
|
|
A little more information. Instead of creating a Papyrus SysML project, I created a Papyrus UML project and then used "apply registered profile" to apply SysML to it. I then dragged a class (the UML concept) onto the diagram and applied the "Block" profile from SysML to it. After that, the icons to show/hide the <<block>> work perfectly - exactly as expected.
Of course, this approach will work. After all, SysML is simply a profile applied to UML. However, it is less convenient because the diagram editor shows UML constructs rather than SysML constructs. However, using the model explorer and right clicking "New SysML Child" still works. You can create the SysML child and then drag it onto the UML+SysML diagram and that works fine. Relationships are a bit more problematic.
At any rate, the team that implemented the SysML diagram editor seems to have not got this quite right.... the names should not be hard-coded, but rather should be shown based on the profile applied...(?)
Thanks!
David Hetherington
David Hetherington
|
|
|
| Re: extending requirement diagram in SysML [message #1108447 is a reply to message #1106894] |
Fri, 13 September 2013 21:51 |
David Hetherington
Messages: 9
Registered: May 2013
Location: Austin, TX |
Junior Member |
|
|
Hmmm... So today I downloaded the Papyrus source code tree (which is huge) and spent the day looking at it carefully. This behavior is not so easy to change, at least not for a beginner, and it is deeply embedded in both the UML and SysML side of Papyrus. From what I can see, the <<class>> element is the only element that does NOT hard-code the label to the shape. This behavior is true for both the base UML and also for the SysML. When I found the part that adds or subtracts the stereotype according to the buttons discussed above, it carefully prepends the stereotype list to whatever was there before inserting a comma in the string and then uses the same comma to strip it when you click the button again.
While I still feel that the original intent of UML is that you should be able to elide (hide) anything - including the stereotype - making the change to Papyrus to make this possible would be rather involved. Probably the best way would be to add a new appearance property "Display stereotype = true/false" that handled the basic stereotype. We would then have to rework the logic in AddAppliedQNStereotypeToDisplayCommand.java and RemoveAppliedStereotypePropertiesToDisplayCommand.java to accommodate the more complicated logic. Unfortunately, while I can allocate part of a Friday to reading some source code, I don't have quite enough time to do the work to get fully setup to be able to build and debug Papyrus (it looks pretty complicate) and learn all the ins and outs of the ui and datastructures to make this sort of change. I will submit it as a feature request instead and hope that someone who is already setup and educated on Papyrus building will find the request interesting enough to implement.
Thanks!
David Hetherington
David Hetherington
|
|
|
Goto Forum:
Current Time: Thu Apr 25 19:42:02 GMT 2024
Powered by FUDForum. Page generated in 0.03836 seconds |
] 
Search
Help
Register
Login
Home
