Extending SysML Profile elements

[chulbe1]

I want to generalize, extend, etc. elements from SysML profile (e.g. block). What's the correct way to get the SysML profile stereotypes on the profile diagram to make sure I am not duplicating the SysML block stereotype?

[Eve]

There is partial support for extending stereotypes from other profiles. You can use it by adding a stereotype element with the fully qualified name (eg. SysML1.2::block) to your profile. (I haven't tested if it needs to be made abstract or not.) You can then specialize the added stereotype.

Limitations that I am currently aware of that we will address in a future build

• Shape scripts and custom icons are not inherited. It's likely other things such as composite diagram types etc aren't either.
• It's a painful unintuitive process.

[Paolo F Cantoni]

[size=18]...[/size]

Limitations that I am currently aware of that we will address in a future build

• Shape scripts and custom icons are not inherited. It's likely other things such as composite diagram types etc aren't either.
• It's a painful unintuitive process.

Simon,

Does that mean that we could (paradoxically) use this method to create our own shape scripts for the "standard" shapes.

Also, when inherting shapes scripts (in the future) will there be provision for extending them?  It's a real issue out here...

Paolo

[Eve]

It means that if you inherit from a SysML1.2::block it will be drawn currently as a stereotyped class.

Calling the parent script is a situation that we have thought of. I'm not sure at this stage if it will be possible to override subshapes.

[chulbe1]

There is partial support for extending stereotypes from other profiles. You can use it by adding a stereotype element with the fully qualified name (eg. SysML1.2::block) to your profile. (I haven't tested if it needs to be made abstract or not.) You can then specialize the added stereotype.

Limitations that I am currently aware of that we will address in a future build

• Shape scripts and custom icons are not inherited. It's likely other things such as composite diagram types etc aren't either.
• It's a painful unintuitive process.

Any idea when inheriting the shape scripts/icons could be implemented?

Maybe there is another way to get some of what I want. One thing I would like is to set the default appearance for blocks based on multiple stereotypes. For example I all <<block,logical>> blocks to be green, and all <<block,physical>> blocks to be red. I changed my custom profile to extend the "Class" metaclass with stereotypes logical and physical. I import that profile and apply those stereotypes to blocks in a template package. Whenever I create a block and add that stereotype it's as if the template package for a block with those stereotypes is not checked again. Does it only check the template package once?

[qwerty]

Any idea when inheriting the shape scripts/icons could be implemented?

There is a way to extract the existing shape scripts from the provided MDG files so you can paste them in your stereotypes. I posted that in another thread and I can try to find it if you're interested.

q.

[chulbe1]

Any idea when inheriting the shape scripts/icons could be implemented?

There is a way to extract the existing shape scripts from the provided MDG files so you can paste them in your stereotypes. I posted that in another thread and I can try to find it if you're interested.

q.

Yes, I would be interested. I did a quick search and did not see what you were talking about so if it is not too much trouble to find, please send me the link or repost.

Chris

[qwerty]

Searching the forum is a PITA. I think it's easier to sum up once again (sorry for the brevity then):

- Open the MDG and locate the stereotype with notepad++
- locate the according EAShapeScript attribute inside
- copy its base64 tag contents
- paste it into a new file buffer
- select all
- Plugins/Mime Tools/Base64 Decode
- save the binary result to a temp.zip on disk
- open the zip
- inside you find a str.dat containing the shape script

q.

[togo]

Searching the forum is a PITA

You may want to try the following read-only copy of this forum:

• http://groups.google.com/forum/#!forum/sparx-enterprise-architect-general
  
• http://groups.google.com/forum/#!forum/sparx-enterprise-architect-uml-process
  
• http://groups.google.com/forum/#!forum/sparx-enterprise-architect-bugs-and-issues
  

- togo

[qwerty]

I tried the first link and searched for qwerty in the general list. A hit count of 2687. Phew. I obviously posted more than I posted?! The last time I tried it I had almost no hits (searching for something else). Seems the google way of counting is a bit strange...

q.

[James Gibson]

Hi,

I am just evaluating EA for a specific customisation of the UPDM Profile and MTG technology.  What I want to do is create a UPDM Custom Viewpoint profile extension. In this I want to extend from Stereotypes in UPDM. I am guessing this is the same as the SysML extension request.

Given I do want to extend UPDM, what is the qualifier I need. For example, if I want to extend a UPDM Package Capability <<Capability>>  I need to create the  UPDM2.0::Capability stereotype, right?

It will be a very large extension  with some novel dynamic behavior requiring sripting/automation.so I want to be able to do this as effectively as possible. I take it from this exchange that it is not extending composite diagram types etc. In general, does this mean that all the diagrams etc defined for UPDM2.0 won't actually work and everything will be a real pain?

Are you considering putting proper Profile extension from other profiles into the product? I hope I am wrong, but at the moment it means I will not actually be able to do my UPDM extension without so much pain that it will be impossible in reality.

If you are planning to include proper profile extension in a coming build, when can we expect to see it?  I can hold off for a month or so but I do need this capability. BTW, the number of users is expected to be in the hundreds so it will be a large EA deployment.  profile extension is very important to me.

In summary:
1. Is an effective and productive  UPDM/SysML Profile extension working in EA?
2. If not, when do you expect this to be available, and what is the priority?
3. If I use the current workarounds, how much loss of functionality do I expect. What breaks?
4. I intend to do a preliminary design mapping. Does this mean I should use UPDM2.0::Capability as the fully qualified name? Should it be abstract or not?

Thanks for your help. Sorry for the large number of questions but there are a lot of risks we want to mitigate.
Cheers
James

  

[KP]

Hi,

I am just evaluating EA for a specific customisation of the UPDM Profile and MTG technology.  What I want to do is create a UPDM Custom Viewpoint profile extension. In this I want to extend from Stereotypes in UPDM. I am guessing this is the same as the SysML extension request.

Given I do want to extend UPDM, what is the qualifier I need. For example, if I want to extend a UPDM Package Capability <<Capability>>  I need to create the  UPDM2.0::Capability stereotype, right?

It will be a very large extension  with some novel dynamic behavior requiring sripting/automation.so I want to be able to do this as effectively as possible. I take it from this exchange that it is not extending composite diagram types etc. In general, does this mean that all the diagrams etc defined for UPDM2.0 won't actually work and everything will be a real pain?

Are you considering putting proper Profile extension from other profiles into the product? I hope I am wrong, but at the moment it means I will not actually be able to do my UPDM extension without so much pain that it will be impossible in reality.

If you are planning to include proper profile extension in a coming build, when can we expect to see it?  I can hold off for a month or so but I do need this capability. BTW, the number of users is expected to be in the hundreds so it will be a large EA deployment.  profile extension is very important to me.

In summary:
1. Is an effective and productive  UPDM/SysML Profile extension working in EA?
2. If not, when do you expect this to be available, and what is the priority?
3. If I use the current workarounds, how much loss of functionality do I expect. What breaks?
4. I intend to do a preliminary design mapping. Does this mean I should use UPDM2.0::Capability as the fully qualified name? Should it be abstract or not?

Thanks for your help. Sorry for the large number of questions but there are a lot of risks we want to mitigate.
Cheers
James

Hi James,

You probably want to send these questions to Sparx Support. Use the "Report a Bug" link at the bottom of the page...