[Feature Request]: Adding "uid" (not "_id") property for all elements in order to support unique external trackable identifier. Show this "uid" in HTML docs.

[Vasileios Pothos]

Hi,
Based on my previous request ([Feature Request]: Export UID of items, in Properties Tables in HTML Docs... and in Index page per item.), could you please provide a unique-id property for each element, thus as for every element:

1. guaranteed to be unique (i.e. use stduuid or boost's uuid or something similar, and when uid is created just check if already exist in the mdj file, if yes generate another)
2. not changeable - should never change regarding a created element (i.e. `_id` changes when fragments are exported and imported)
3. Easy copyable in external documents (ideally a string of alphanumerics only, so double-click to select it at once)
4. Copiable and Searchable via the StarUML (like my plugin `Model Id : Copy and Select` for does for `_id` via keyboard shortcuts : I guess I could just update my plugin then)
5. Non-Editable (that could break easily the first constrain)
6. Non-Human Readable (that could complicate it much more. The is no need for someone to read it. In documentation more text by the user can be added around it for explainability)
7. Exported in HTML Docs, in element's parameters as the second parameter after the name, so given a name, someone to be able to get(copy) the ID and search for it elsewhere (i.e. source code)
8. Exported in HTML Docs, in "Index" page where all elements are listed, in a parenthesis after the name of each element thus someone to be able to search an uid via browser to find out to which element it belongs. (i.e. copy uid from the source code with double-click and ctrl+c, and then search in "Index" page to find the element and open it from there)

Because no such UID exist currently, for almost a year now I'm exposing and using `_id` from my plugin, but yes, it's like more like a "hack" and needs special treatment (not import fragments, copy then manually by externally editing the mdj files). Ideally if StarUML could provide an official UID, based in the above constrains it would help a lot to track our elements - and their documentation - in our external documents and source codes. For me it's the way I work, making StarUML a crucial part of the documentation through this uid per element.

Thanks

[StarUML]

Thank you for your feedback.

The "id" we proposed is a simple data field that is entered by the user. Your request seems to go beyond common sense. As far as we know, there is no modeling tool that provides element-level UIDs for external tracking that meets your requirements (if you know of one, please let us know). We can't add a feature just for you, it can only be considered if it is universally useful for everyone.

It's also a good idea to post it on our UserVoice for comments and votes.
https://staruml.uservoice.com/

Thank you.

2024년 7월 16일 화요일 오후 1시 6분 13초 UTC+9에 vasileio...@gmail.com님이 작성:

[Vasileios Pothos]

Hi.

I am not sure what other softwares provide. I invested on StartUML, so I haven't looked around.

But what I am saying makes perfectly sense. StarUML to my understanding is a modeling tool - not just a diagram tool. As a modeling tool, every model and it's parts should be uniquely identified (thats what `_id` does eventually, but internally and partially only for the mdj file). I am only asking to extent this model/element identification thus to be more global and accessible to us - the users - who need to refer to these models externally. Making a model and not being able to refer to it's components in external documentation or source code or whatever doesn't make sense to me. Making a diagram, makes sense - but not a model.

Based on your request, I did a quick search. And I see this exists on other Model making tools, for instance in this forum people as asking how to get the Nodes GUIDs, and there is indeed build-in functionality for such actions "Right click | Copy / Paste | Copy Node GUID to Clipboard".
https://sparxsystems.com/forums/smf/index.php?topic=44864.0

I totally understand that such a feature may be indeed very-low priority for your customers (not-useful to them) based on your experience, and I may only be the exception here. And it's ok for me. I can still work with `_id` to mitigate this missed feature for me, as I did for some time now. The only problem for me is that after 6.2.0 update, and without this `_id` being exported to HTML Docs, it potentially breaks my designed workarounds and future vision working with this tool. But I understand, this is my problem. I was just trying to see how can I solve it and if there any possibility to be solved with any update from StarUML. But I feel we are not exactly in the same page regarding our needs and roadmaps around these subject. Its ok! :)

Thanks for your reply!