Archimate connector stereotype labels

[matthew.james]

Connectors can have stereotypes, which can be displayed automatically as text labels - using the 'show stereotype labels' diagram property.
This works for the 'standard' UML relationshiops but does not work for the Archimate relationships - the relationships do have stereotypes but no text label is displayed irrespective of the property setting.

Earlier posts have suggested that this is due to the shapescript for those connectors, specifically:

Code: [Select]

label middlebottomlabel
{
   print("");
}

So, does anybody know ... if this shapescript were changed, could the show stereotype label functionality be supported for Archimate relationships, ie enable the stereotype to be displayed or not based on the property setting ?

If so I will raise a feature (bug ?) request for this to be done

[qwerty]

You could investigate that by looking into the shapescript itself- Geert has published a github repo with all shape scripts.

q.

[Eve]

The ArchiMate technology defines a new language. Yes, it uses stereotypes to define that language, but displaying them would be non-conformant for the target language.

I'm not sure I understand why you want them displayed, but I wouldn't expect any change. Displaying UML stereotypes on ArchiMate connectors based on that option would negatively impact the majority of ArchiMate users.

[matthew.james]

Displaying UML stereotypes on ArchiMate connectors

To be clear - I'm after the Archimate relationship stereotype to be displayed, not anything related to UML types or stereotypes.  For example to have a connector display (optionally, controlled by the existing property) a text label "<<ArchiMate_Access>>", or even better "<<Access>>" to match the toolbox text.

I take your point that Archimate is a new language, although I can't see anything that precludes relationships from being labelled with stereotypes (the Archimate stereotypes). In fact the language explicitly includes the ability to specialize the base (Archimate) element and relationship types and explicitly specifies the use of the UML style guillemet notation for this.

I wouldn't expect any change. Displaying UML stereotypes on ArchiMate connectors based on that option would negatively impact the majority of ArchiMate users

I don't see how this would impact any users of Archimate negatively - assuming it would be controlled by the existing 'show stereotype labels' diagram property.  With that property turned off the behaviour would be the same as it currently is. However I also take your point that it is unlikely that this will be changed if I raise a feature request (ie I shouldn't waste my time doing that).

[Nizam]

Further to qwerty's comment and your posts, you can consider modifying the shapescripts in the MDG.
Removing middlebottomlabel this (and updating the default MDG) should restore your expected behavior.

Actual Shapescript from ArchiMate (refer Geerts https://github.com/GeertBellekens/Enterprise-Architect-Shapescript-Library)

Code: [Select]

shape main
{
noshadow=true;
setlinestyle("DOT");
moveto(0,0);
lineto(100,0);
}

label middlebottomlabel
{
print("");
}


[Eve]

To be clear - I'm after the Archimate relationship stereotype to be displayed, not anything related to UML types or stereotypes.  For example to have a connector display (optionally, controlled by the existing property) a text label "<<ArchiMate_Access>>", or even better "<<Access>>" to match the toolbox text.

I take your point that Archimate is a new language, although I can't see anything that precludes relationships from being labelled with stereotypes (the Archimate stereotypes). In fact the language explicitly includes the ability to specialize the base (Archimate) element and relationship types and explicitly specifies the use of the UML style guillemet notation for this.

Exactly, those correspond to a UML stereotype on the base UML element representing the connector. It's not something that you would actually want to display on an ArchiMate diagram. If you were using the same notation to describe a specialized form of Access connector, it would make sense to display that like a stereotype.

I don't see how this would impact any users of Archimate negatively - assuming it would be controlled by the existing 'show stereotype labels' diagram property.  With that property turned off the behaviour would be the same as it currently is. However I also take your point that it is unlikely that this will be changed if I raise a feature request (ie I shouldn't waste my time doing that).

Because by default all existing diagrams are set to show stereotypes. That means your change would show those labels on every ArchiMate diagram. Existing users would say that we've broken their diagrams. New users would throw away EA before ever finding the option.

But feel free to submit a request. I'm just one person.

[Sunshine]

Having used ArchiMate for the last 11 years here are my humble opinions on your suggestion

To be clear - I'm after the Archimate relationship stereotype to be displayed, not anything related to UML types or stereotypes.  For example to have a connector display (optionally, controlled by the existing property) a text label "<<ArchiMate_Access>>", or even better "<<Access>>" to match the toolbox text.

Whilst section 15.2 of the ArchiMate® 3.0.1 Specification does suggestion using stereotypes on specialisations of elements and relationships I've not seen anything in the literature to show stereotypes of the standard elements and relationships so you are asking for a deviation which is not necessarily better.

I take your point that Archimate is a new language, although I can't see anything that precludes relationships from being labelled with stereotypes (the Archimate stereotypes). In fact the language explicitly includes the ability to specialize the base (Archimate) element and relationship types and explicitly specifies the use of the UML style guillemet notation for this.

ArchiMate has been around for a while now and I started using it in 2007. The standard was published by the open group in 2009 but ArchiMate was around since 2004. So its not really new is it? This is evident by the fact that most books on the subject are in there 3rd or 4th Edition.

I don't see how this would impact any users of Archimate negatively - assuming it would be controlled by the existing 'show stereotype labels' diagram property.  With that property turned off the behaviour would be the same as it currently is. However I also take your point that it is unlikely that this will be changed if I raise a feature request (ie I shouldn't waste my time doing that).

I for one would be annoyed if I had to go and turn that off in every diagram as I have a model with over 1,000 diagrams.
If your really want that type of feature I suggest you create your own ArchiMate based MDG and put as many deviations as you like in it with shape scripts.

[matthew.james]

... its not really new is it?

It was not my contention that Archimate is new - I was referring to an earlier statement by Simon from Sparx where he stated that "The ArchiMate technology defines a new language".  I interpreted this as meaning that the Archimate MDG in Sparx implements a new language (on top of the base UML).

With respect to your other comments ... I have noticed an interesting tendency in these forums for people (from Sparx and otherwise) to refer to the Archimate specification for justification on why the Sparx implementation can't or shouldn't implement certain features but then conversely dismiss that same Archimate specification in reference to other features.  I suspect there are other forces at play behind some of those thoughts, such as "this is what we are used to" and "that's going to be hard to implement".

Of course, these thoughts are quite legitimate - and behind my requests there is an element of "I want it to work differently to how it does". I'm more than happy to accept when there are good reasons why people don't want things changed (including the forces I mentioned above).  As per my earlier post, I have already accepted that this change was unlikely to be accepted (c'est la vie). But if you don't ask you don't get, and some other changes / bugs I have raised have been supported.

WRT creating my own Archimate based MDG ...
- I'm not really interested in building my own tool, that's why I buy one (and Archimate was the specific feature set we were looking for in the Sparx tool). 
- It seems wasteful for multiple Sparx users to be creating their own custom Archimate MDGs (as seems to have happened to work around limitations and bugs)
- I have suggested an option for Sparx to open source the Archimate MDG as a way for the community to work together to enhance it.  This has some support from other users so perhaps I will raise that as a formal feature request instead

[Glassboy]

... its not really new is it?

It was not my contention that Archimate is new - I was referring to an earlier statement by Simon from Sparx where he stated that "The ArchiMate technology defines a new language".  I interpreted this as meaning that the Archimate MDG in Sparx implements a new language (on top of the base UML).

If we are going to be more nuanced.  ArchiMate is not UML.  According to the ArchiMate working group, ArchiMate is sometimes like UML and sometimes not.  I generally see Dr Seuss style illustrations when I read/hear this.

[matthew.james]

If we are going to be more nuanced.  ArchiMate is not UML.

Agreed, I should have been clearer "... the Archimate MDG in Sparx implements a new language, using a UML profile / extension approach, which is somewhat / mostly like the Archimate specification"

I generally see Dr Seuss style illustrations when I read/hear this.

Now there's an image I won't get out of my head for awhile :-)

[Glassboy]

Yes and no.  The Open Group ArchiMate members aren't clear on when ArchiMate is like UML and when it really isn't.  If they were the Sparx implementation would be better.

The most visible members of the ArchiMate working group are competing tool manufacturers, so there is a competitive advantage in them being vague.