How do I remove decorations from extended types being rendered in new stereotype

[RusDavies]

I'm creating a new UML profile, in which I extend an Archimate2 Node to create a new stereotype.

Normally, a bare ArchiMate2 Node renders with a little cube as a decoration in the top right of its image.  I'm sure it's very pretty, if you like that kind of thing.

Frankly, I don't like it.  It causes my left eye to twitch with rage.  So, in my extended version, I no longer want that decoration to be rendered.  To that end, I've added a shape script, as follows (where AwesomeNode.emf" is an imported image):

  1  shape main{
  2      image("AwesomeNode.emf", 0, 0, 100, 100);
  3   }
  4
  5  shape label{
  6      setOrigin("SW", 0, 0);
  7      println("#NAME#");
  8  }
  9
10  decoration KillTheCube{
11  }

That renders my little EMF nicely, and adds a label.  However, unsurprisingly, it doesn't in fact kill the cube. 

So, what am I doing wrong?  How do I do it properly?

Perhaps, If the cube in the ArchiMate2 Node type is being rendered by a decoration method which needs to be overridden, then the name of the decoration function matters.  Is that how it works?  If so, how would I discover the required name?  Otherwise, how do I get rid of the little cube?

I'm rapidly running out of eye-twitch pills, so I'll happily send a Mars Bar to anyone who can help me! 

[qwerty]

Try DrawNativeShape() in the main shape (just a guess).

q.

[Geert Bellekens]

If the DrawNativeShape doesn't work then you could try to put your own decoration on the same location as the standard cube decoration.

I don't think it will help, but if you want to get a hold of the original shapescript in the Archimate MDG, you can.
The shapescripts are stored int eh MDG xml as zipped, base64 encoded text files.
So if you reverse the process
- base64decode the script part
- save as zip file
- unzip

Then you have the shape script of the original Archimate stereotype.

Adventurous people (e.g. Paolo) haven been known to replace the shapescripts in the standard Archimate MDG by their own improved versions. That would eliminate the need to extend the Archimate stereotype.
Come to think of it, that may even be the simplest way to get rid of those pesky eye-twitching decorations.

Geert

[RusDavies]

Thanks for the replies. 

These both seem like excellent ideas.  I'll give them a try, and update accordingly. 

Already, my eye is twitching less. 

[qwerty]

Though another member here called that "making Archimate non-Archimante" 

q.

[Glassboy]

Though another member here called that "making Archimate non-Archimante" 

No, I said it's making "Sparx's UML rendered Archimate more UML".  I think it's generous to say EA does Archimate, it does UML that looks like Archimate.  Creating Archimate models in tools like Archi is a very different experience.

And if you want to get the shapescript you don't need to go through Geert's complicated process.  Create some shapescript on an element.  Cut and paste the shapescript from the MDG into resulting image attribute (completely replacing the contents).  Open the shapescript editor.

[RusDavies]

LOL, that's a clever way of getting the ShapeScript, Glassboy.  As it happened, I went a more painful route, by writing a bash script to suck all of the ShapeScript from an MDG file.  In case any one else finds it useful, here it is.

Code: [Select]

#!/bin/bash

function Error() {
  printf "ERROR: $1.\n" 1>&2 && exit 1
}

[ -z "$1" ] && Error "Incorrect number of params."
[ ! -e "$1" ] && Error "Source file doesn't exist."

XPATHBASE="/MDG.Technology/UMLProfiles/UMLProfile/Content/Stereotypes/Stereotype"
TARGETDIR="${1%.xml}_ShapeScripts"

MTS=$(xmlstarlet sel -T -t -v "${XPATHBASE}/@metatype" $1)

[ -z "$MTS" ] && Error "No metatypes found in source file."

mkdir -p ${TARGETDIR}

for MT in ${MTS}
do
  printf "\n\n=====================\nExtracting ShapeScript for metatype=${MT}\n"
  xmlstarlet sel -t -v "${XPATHBASE}[@metatype='${MT}']/Image[1]" $1 | \
    base64 -i -d | \
    funzip | \
    tr -d '\000' | \
    tee ${TARGETDIR}/${MT}.ShapeScript
done

exit 0

In other news, here's what I've discovered so far:

1) ShapeScript is awful. Quite possibly the work of the Devil himself.

2) DrawNativeShape() doesn't help.  It simply renders the Native type.  If I then add anything after that call, it gets painted on top. 

3) Having extracted the ShapeScript for ArchiMate 2 Node, the decoration method is decoration node { ... }.  However, adding a decoration method with the same name to my extension doesn't override the original.  Instead, both get rendered. This is not consistent with the behaviour of shape main { ... }, which does get overridden. 

4) If I add yet another stereotype between the ArchiMate 2 Node stereotype and my own, then the decoration isn't rendered.  I don't consider this a solution, since I don't understand why.   

5) Flipping the "Rectangular notation" flag in effect removes the cube, per it's condition rendering in the ShapeScript for the Node.  I also don't consider this a solution.

Any more thoughts?

[Glassboy]

Any more thoughts?

Yes I have some thoughts.  Given that there are at least three forum members who want to "extend" the Sparx implementation of Archimate 2, why not replace it entirely?  Create a project on a web based source repository and have people work on particular parts of it.

[RusDavies]

Perhaps I'm missing some subtly of the suggestion, but what does one gain by replacing the existing Sparx ArchiMate profile entirely?  It contains features that are useful.  Why re-invent all those features, only to gain an extra c. 5% (in my case)? Isn't extending existing types the whole point of UML extensibility?  What am I missing here?

From my perspective, a fresh start doesn't seem to solve the problem that I have here, which is how to override the decorations of underlying stereotypes.  That's a generic issue of how Enterprise Architect behaves, and not tied specifically to ArchiMate 2.  Perhaps you have an alternative implementation strategy that works around the restrictions I'm hitting? 

As an aside, assuming one did fire up a new ArchiMate implementation, one reason not to create a GitHub repository (for example) for such a project is because the paths for icon assets used by the profile helpers and MDG generator are absolute, rather than relative.  That's a royal PITA for sharing a MDG project between developers.  I'd want a solution to that before my right eye starts twitching too. 

[MaXyM]

Hello guys
Is this issue solved in some way?
I'm also struggling with adding custom icon. In fact I want to replace default icon of component with custom one in regards to stereotype set.

Following this discussion I extracted shape scripts (thanx RusDavies for bashscript), took Component script found in Archimate, added to my stereotype and...
Its appearance varies from default stereotype.
1. component name non bolded
2. component icon looks different than default one
3. icon position is also different

On image below, you can see to components. One on the left is default one, without any stereotype. Right one has set "test" stereotype "powered by" shapescript stolen from Archimate package

[qwerty]

That's the purpose of shape script: to define your own shapes. It looks like the icon is drawn and most likely it will stretch if you elongate the shape.

q.

[MaXyM]

It seems you missed the point.
First of all icons are not affected by size of objects they are owned by (including streaching)
Second, I did use the same shape script than stored in Archimate package. So I was expecting the same behaviour/appearance. But I got different font for name as well as different icon look (ie icon's corners)

But it would be OK if will be possible to "override" an icon by custom one. Unfortunatelly AFAIK it is no possible with use DrawNativeShape() function (that's why I tried to copy whole shape)

[qwerty]

No, I don't get your point. The right Component is an Archimate stereotype. It uses it's own shape script and therefore does only resemble the native Component. What would you expect?

q.

[Paolo F Cantoni]

"

No, I don't get your point. The right Component is an Archimate stereotype. It uses it's own shape script and therefore does only resemble the native Component. What would you expect?

q.

Sigh...

Hi MaXym,

Have you confirmed that all other aspects of the two elements are identical?  Font? Type? etc.  Did you create them in the same way?  If you change the stereotype of your extended element to the original stereotype do they now look the same?  If not then THAT's your problem.

qwerty is right, once you embark on your own shapescripts - even copying the supplied ones, you're in for an "interesting" (in the Chinese sense) time!

Paolo

[MaXyM]

Both items are just components dragged from tool to deployment diagram. right one has set my custom 'test' stereotype, which uses shape script borrowed from component element found in Archimate package.
If I remove my stereotype from right one, it turns back to look the same as left one.