New standard element property: ID

[matthew.james]

Want to raise a thought here before I raise a feature request - in case there is already a way of doing this.

I'd like to have an element ID as a genuine separate element property (ie not text embedded in the name field).  This being a field that can contain an alphanumeric ID for the element, that is (perhaps optionally) displayed wherever the name is displayed - ie in the browser, on shapes and in selections.

This field could be filled automatically or manually, and could be used as a shorthand to identify the element and perhaps refer to some concept or identity outside the model.  For example:
- Project ID to external PMO listing
- Server ID from CMDB
etc

Similar things that I am aware of:
1) Auto Naming: This has most of the capability I am looking for *except* that:
- It is implemented as a substring embedded in the name field - the numbering is created at the time it is applied but can be deleted afterwards
- If auto number is re-applied to a package the rule just adds another number (eg two prefixes) as EA doesn't really know that there is aleady a number (cos it's just part of the name)
- Can only be applied to classes, not StereoTypes
2) Package level numbering: This nicely keeps the numbering out of the name field but doesn't use it anywhere else (as far as I can tell) and there is no control over number (it is after all a package level number)

Happy to hear if people have any other ways to handle this and / or if you think it is a good or bad idea

[KP]

1) Auto Naming: This has most of the capability I am looking for *except* that:
- It is implemented as a substring embedded in the name field - the numbering is created at the time it is applied but can be deleted afterwards

If you look at the Auto Name Counters dialog, you can apply to the Alias field instead. This takes it out of the name field, and there are various diagram-level settings that allow you to display name, alias or both.

[matthew.james]

If you look at the Auto Name Counters dialog, you can apply to the Alias field instead. This takes it out of the name field, and there are various diagram-level settings that allow you to display name, alias or both.

Thanks KP - I meant to mention the alias as well in my post.  At the time I could only see how to display the alias OR the name on diagrams but not both.  Based on your advice I have now found the setting which activates both - thanks.  The alias doesn't show in the project browser and other places but it is a good start.

One question - the view preference settings that control Alias usage on diagrams (ie 'Alias only' or 'Alias and Name', are these model settings or user settings?  If I turn on 'Alias and Name' will that be reflected in the model and other users get he same behaviour or will only I get this?

[KP]

One question - the view preference settings that control Alias usage on diagrams (ie 'Alias only' or 'Alias and Name', are these model settings or user settings?  If I turn on 'Alias and Name' will that be reflected in the model and other users get he same behaviour or will only I get this?

Everything in the Preferences dialog is a user setting, so only you will see it. (Although be aware that in a shared model, you may see elements resizing if they have more text to display, which may mess up other people's diagram layouts.)

[matthew.james]

Everything in the Preferences dialog is a user setting, so only you will see it.

Hmm ... I suspected / feared that to be the case.  Ok, thanks

[Glassboy]

Want to raise a thought here before I raise a feature request - in case there is already a way of doing this.

I'd like to have an element ID as a genuine separate element property (ie not text embedded in the name field).  This being a field that can contain an alphanumeric ID for the element, that is (perhaps optionally) displayed wherever the name is displayed - ie in the browser, on shapes and in selections.

This field could be filled automatically or manually, and could be used as a shorthand to identify the element and perhaps refer to some concept or identity outside the model.  For example:
- Project ID to external PMO listing
- Server ID from CMDB
etc

What is your reasoning for this not being a tagged value?

[Geert Bellekens]

What is your reasoning for this not being a tagged value?

I agree, that is exactly what tagged values are for, to extend the standard properties with your own.

Geert

[matthew.james]

What is your reasoning for this not being a tagged value?

I agree, that is exactly what tagged values are for, to extend the standard properties with your own.
Geert

Several
- It felt to me like a general property that would be useful and valuable to many people as a global element standard property (and presumably the existing numbering features have been added for that reason, just the implementation doesn't quite work as well as I believe it could)
- A tagged value would not be displayed on shapes and in the project browser, ie alongside the element name (even a standard property wouldn't be without core EA changes like the ones that have been made to support display of the Alias property)
- I'm trying to avoid extending and customising (albeit I'm happy to admit that EA is designed for this type of extension)
- I'm not really familiar with how tagged values are best implemented (so maybe this would be easier than I think it would be). In particular I'm working with the Archimate MDG and stereotypes which adds another level of confusion / complexity

I raised this here to guage interest and to understand what options I might already have. The general response is:
- Use the alias an auto number features that are there, or
- Use a tagged value
Which are both reasonable approaches

[Glassboy]

Several
- It felt to me like a general property that would be useful and valuable to many people as a global element standard property (and presumably the existing numbering features have been added for that reason, just the implementation doesn't quite work as well as I believe it could)

You've suggested an arbitrary use property.  Which is the opposite of a standard property.  With everyone using it in different ways it would drive confusion into models.

- A tagged value would not be displayed on shapes and in the project browser, ie alongside the element name (even a standard property wouldn't be without core EA changes like the ones that have been made to support display of the Alias property)

I'm not sure the relevance of this comment.  It sounds like you actually need to organise your workspace differently so you see more information when browsing the project browser.

- I'm trying to avoid extending and customising (albeit I'm happy to admit that EA is designed for this type of extension)

I'm not sure how adding a poorly defined global property is better for anyone than a properly defined extension.

- I'm not really familiar with how tagged values are best implemented (so maybe this would be easier than I think it would be). In particular I'm working with the Archimate MDG and stereotypes which adds another level of confusion / complexity

Even if Sparx did what you ask your property wouldn't be displayed on any ArchiMate shape.  I suggest you look at the Language Customization Mechanisms section of the ArchiMate notation.

[matthew.james]

I'll prefix this by saying that
1) I've only been using the tool for a couple of weeks so I'm yet to fully understand its approach
2) I did post this suggestion to test its validity and understand what options I have
So ... perhaps be gentle to noobs

You've suggested an arbitrary use property.  Which is the opposite of a standard property.  With everyone using it in different ways it would drive confusion into models.

No, I've suggested an extremely standard use case of having a unique, stable identifier for an element given that names are inherently 'unstable' - they change over time and aren't useful as a reliable reference. The main purposes for such an identifier is for shorthand referencing and for external referencing, ie outside of the model.  This is commonly seen in many real world scenarios - principles, policies, standards, requirements, constraints, positions, projects etc, etc, etc.
As I've mentioned, Sparx' response would likely be (quite reasonably) "we've already got that property, it's called Alias and look there is also support for auto-numbering and for displaying this on diagrams" - this is very close to what I was looking for, I just hadn't connected to how Alias works (I'll blame lack of familiarity with the tool)

I'm not sure the relevance of this comment.  It sounds like you actually need to organise your workspace differently so you see more information when browsing the project browser.

The relevance of the comment is that it is the heart of my requirement.  I'd like this ID to be displayed with the element name wherever the element name is displayed - on diagrams but also in the project browser.  The Alias field comes close (has diagram support, albeit slightly kludgy being mixed between model / diagram properties and individual user preferences), but doesn't display in the project browser.  I note that others have previously suggested / requested this support so I'm clearly not alone with that desire.
If you have suggestions on how I can achieve something like this this by organising my workspace differently I'm very keen to understand more about that ...

I'm not sure how adding a poorly defined global property is better for anyone than a properly defined extension.

*If* my requirement were to be broadly supported *then* it makes sense for it to be built into the base types rather than added as a tagged value to every type and stereotype independently
I suspect that is why Alias was implemented as a global property ...

Even if Sparx did what you ask your property wouldn't be displayed on any ArchiMate shape.  I suggest you look at the Language Customization Mechanisms section of the ArchiMate notation.

I understand your perspective on the purity of Archimate and I do agree, however as you have pointed out Archimate, by specification, allow customisation.  I'm happy to be corrected, but I don't see how the specification dictates the format and display of the text in the shape ... ?
Specifically - what would be the difference between an element with the name "5.2 Lorem Ipsum" and an element with an ID "5.2" and a name "Lorem Ipsum" displayed on the shape as "5.2 Lorem Ipsum".
Or am I missing your point here ?

Thanks

[Glassboy]

Even if Sparx did what you ask your property wouldn't be displayed on any ArchiMate shape.  I suggest you look at the Language Customization Mechanisms section of the ArchiMate notation.

I understand your perspective on the purity of Archimate and I do agree, however as you have pointed out Archimate, by specification, allow customisation.  I'm happy to be corrected, but I don't see how the specification dictates the format and display of the text in the shape ... ?
Specifically - what would be the difference between an element with the name "5.2 Lorem Ipsum" and an element with an ID "5.2" and a name "Lorem Ipsum" displayed on the shape as "5.2 Lorem Ipsum".
Or am I missing your point here ?

The customisation that ArchiMate allows is the extension you are not wanting to do, namely defining a profile of tagged values.  However ArchiMate - as far as I can see - does not provide a mechanism for you to display these things visually as UML and other notations do.  You'll also see that each element generally has some notes on naming that doesn't include any kind of classification scheme.

Sparx's ArchiMate representation is already more UMLised than it should be.  There are frequent posts here asking how to UMLise it more.  This is just putting lipstick on a pig.  The reasons people want to do it is valid, but the logical conclusion is not to bastardise ArchiMate, it's to create your own UML meta-model containing the concepts you want to use from ArchiMate and leaving all the brain death and 70s IT concepts behind.

[matthew.james]

The customisation that ArchiMate allows is the extension you are not wanting to do, namely defining a profile of tagged values.  However ArchiMate - as far as I can see - does not provide a mechanism for you to display these things visually as UML and other notations do.  You'll also see that each element generally has some notes on naming that doesn't include any kind of classification scheme.

If you look at Sparx through an Archimate modelling lens (forget the heritage, other capabilities and different notations) I think it's fair to say that any attribute of a Sparx Archimate element fits into the definition of 'adding attributes' as defined in the Archimate spec. This includes 'standard' element properties (Alias, Status, Author) as well as any attributes / tagged values added to the stereotypes.  The specific mechanisms are really just a side effect of the tool's implementation approach.

Sparx's ArchiMate representation is already more UMLised than it should be.  There are frequent posts here asking how to UMLise it more.  This is just putting lipstick on a pig.  The reasons people want to do it is valid, but the logical conclusion is not to bastardise ArchiMate, it's to create your own UML meta-model containing the concepts you want to use from ArchiMate and leaving all the brain death and 70s IT concepts behind.

Now *this* is a much more interesting conversation.  Certainly I'm aware of much similar criticism of Archimate, and I'm far more interested in the Strategy, Business & Motivatioon layers, a little bit with Implementation (which is light anyway) and not as much in Application and Technology.  I'm also not especially wedded to Archimate, however it does have the advantage of being a 'standard'.
So - are you doing anything like this (or know of anyone who is) and/or do you have any suggestions on where I might look for inspiration ?
Or are you more coming from a general modelling perspective - ie, if the notation isn't representing the ideas well enough then work with one that does (?)

[Glassboy]

Now *this* is a much more interesting conversation.  Certainly I'm aware of much similar criticism of Archimate, and I'm far more interested in the Strategy, Business & Motivatioon layers, a little bit with Implementation (which is light anyway) and not as much in Application and Technology.  I'm also not especially wedded to Archimate, however it does have the advantage of being a 'standard'.
So - are you doing anything like this (or know of anyone who is) and/or do you have any suggestions on where I might look for inspiration ?
Or are you more coming from a general modelling perspective - ie, if the notation isn't representing the ideas well enough then work with one that does (?)

At least two posters here have extensively reworked or custom ArchiMate MDGs.  Every couple of weeks to a month someone asks a question on extending ArchiMate.  I stick to vanilla ArchiMate so as not to cause problems for my customers who struggle with the basics.  For most of the real crunchy things I do, I use other notations such as UML, Sequence Diagram, DFDs et al as it's easier to be correct.

While ArchiMate is a standard, it is a standard from a consortium of tool vendors, it's certainly not an "open" standard.