Show Connectors IDs on diagrams

[YogaMatt]

Connectors have IDs. Is it possible to show them on a diagram?
Any workarounds it not?
Thanks in advance.

[Geert Bellekens]

Why would you want to show the connector ID on the diagram?

With the EA Navigator you can copy the guid of an operation to the clipboard if that helps at all.

Geert

[YogaMatt]

Hi Geert
To the rescue again I see 
A stakeholder wants the numeric ID (not GUID). We're showing interfaces on a diagram and want a quick way of cross-referencing with the interface catalogue, in which we display the numeric ID assigned by EA. Quick and dirty.
Cheers
Matthew

[Geert Bellekens]

Matthew,

You do realize that the numeric ID's are not stable?
There's even a function in EA to reset the ID's (Tools|Data Management|Reset IDs...) so I think it's a bad idea to use those ID's in any way.

Geert

[YogaMatt]

Thanks Geert

That's a new one on me. Is the "Reset IDs" function the only means by which the IDs change? If not, what else might/does change them? (I can imagine that import and export will change them).

If you are versioning then IDs will be internally consistent within a version. Between versions could be problematic though ...

Cheers

Matthew

[Geert Bellekens]

Yes, XMI import export will change the numeric ID's.

The only thing guaranteed to be stable in terms of ID is the GUID.

If you really need a numeric ID's you better manage that yourself (and store it in a tagged value or something like that)
With shapescripts you can show values from tagged values on the diagram.

So I guess the "proper" way of doing something like this would be to create a connector stereotype in a UML Profile, and add ID as a tagged value to this stereotype.
Then attach a shapescript to this stereotype that shows the ID of the connector in one of the labels.

Geert

[YogaMatt]

Once again, very helpful.
As we already have a stereotype for the connector type in question, we're some way there.
I'd still like to understand better the drivers behind the instability - have IDs got a bad rap for stability because of unintended consequences of diff/merging etc, or are there other causes?

[Geert Bellekens]

The reason is (I think) that they use auto-increment ID's and so the application has no control over the ID's as they get assigned automatically by the database.

Also a common way of collaboration is to use a central version control repository where each user works in his/her own .eap file. If you work this way everyone will have a different ID for the same element. The XMI in general does not contain ID's, but relies on GUID's to relate things to each other.

Geert

[YogaMatt]

That makes perfect sense.
With regard the mode of versioning you mention, that will quickly cause ID drift between branches that'll need to be reconciled - hence instability will be seen (if you're paying regard to variations between branches off the trunk).
With regards to automatic assignment - IF what happens is that IDs are assigned from max(ID) + 1 rather than filling holes created by deleted connectors, then IDs could be used, but with caution.
Like everything, if we know what we're doing and tie down the implications of a particular approach, then use what works?
Thanks,
Matthew

[Paolo F Cantoni]

That makes perfect sense.
With regard the mode of versioning you mention, that will quickly cause ID drift between branches that'll need to be reconciled - hence instability will be seen (if you're paying regard to variations between branches off the trunk).
With regards to automatic assignment - IF what happens is that IDs are assigned from max(ID) + 1 rather than filling holes created by deleted connectors, then IDs could be used, but with caution.
Like everything, if we know what we're doing and tie down the implications of a particular approach, then use what works?
Thanks,
Matthew

Hi Matt,
The IDs are Surrogate Keys - they are (quite rightly) intended NOT to become Domain Keys (which by exposing them - you create).  As Geert says they are unstable, and what's more, under certain circumstances will be re-used - internally.  For example, after a project Transfer or Compacting an .eap file.  It's just NOT worth the risk.

As Geert says, if you need to specifically identify relations then do so by using a mechanism that IS Stable - such as a tagged value (or by re-using - hijacking - one of the unused fields) whose value YOU control.

Paolo

[Dermot]

As an alternative to creating Tagged Values - Connectors do have an Alias, this can be shown on the diagram by selecting the Diagram Property
 [ x ] Use Alias If Available.
The Shortfall is that you will see all the Element Aliases if these are set as well.

[YogaMatt]

As an alternative to creating Tagged Values - Connectors do have an Alias, this can be shown on the diagram by selecting the Diagram Property
 [ x ] Use Alias If Available.
The Shortfall is that you will see all the Element Aliases if these are set as well.

Hi Matt,
The IDs are Surrogate Keys - they are (quite rightly) intended NOT to become Domain Keys (which by exposing them - you create).  As Geert says they are unstable, and what's more, under certain circumstances will be re-used - internally.  For example, after a project Transfer or Compacting an .eap file.  It's just NOT worth the risk.

Both excellent contributions, and marked as helpful. What I love about the forum is the way it extends your options and ignites passions.
Being aware of the risks of some practices, and having options without those risks, it would be folly to take the risk.
Namaste