How do I generate unique IDs for design elements?

[mse]

In requirements, I see that auto counters work fine by generating an ID like REQ0001, REQ0002, ... in the name field. However, I want to create a similar scheme for design elements where every design element has it's own ID. Obviously I don't want to have classes with names DGN001, DGN002, DGN003, ..., so what is the best way to achieve this goal? For now, I'm thinking of creating a counter for the Alias instead. So I might have a class with the following properties:

Name: CustomerC
Alias: DGN0055

Is this the best we can do? As a side note, I do not want to use the GUID either, as that is unacceptably long.

[Geert Bellekens]

The alias seems like the best place for something like this.
You can setup auto-counter schemes for the alias as well.

Geert

[qwerty]

FWIW, this functionality renders useless in practical use: If you have multiple editors with (version) controlled packages each one has its own counter. Even if you manage to have all to use the same setting, the counter can not be synched. It more or less only works for a central database.

Also: why have such a numbering scheme for classes? Someone out there to go with a class model with numbered classes? Or Actions? Or anything else (except requirements and issues)?

q.

[Modesto Vega]

FWIW, this functionality renders useless in practical use: If you have multiple editors with (version) controlled packages each one has its own counter. Even if you manage to have all to use the same setting, the counter can not be synched. It more or less only works for a central database.

Also: why have such a numbering scheme for classes? Someone out there to go with a class model with numbered classes? Or Actions? Or anything else (except requirements and issues)?

q.

Unless you use a database level trigger to update the field on creation, not that I would necessarily recommend it. This assumes the OP uses a repository.

I can see scenarios where you would like to do that. GUIDs, as I mentioned elsewhere, are not very user friendly.

[mse]

Also: why have such a numbering scheme for classes? Someone out there to go with a class model with numbered classes? Or Actions? Or anything else (except requirements and issues)?

It's not the class names that I want to change, rather, just another TaggedValue or some other field of the class that contains a unique identifier. So I would still have a class like "Customer", or "Date", etc. And those classes would have some field like ID with values like DGN0034, DGN1030, etc.

[Geert Bellekens]

Also: why have such a numbering scheme for classes? Someone out there to go with a class model with numbered classes? Or Actions? Or anything else (except requirements and issues)?

It's not the class names that I want to change, rather, just another TaggedValue or some other field of the class that contains a unique identifier. So I would still have a class like "Customer", or "Date", etc. And those classes would have some field like ID with values like DGN0034, DGN1030, etc.

I think the question was why? What is the reason you need these ID's in the first place.

Geert

[mse]

Because we want to perform traceability between varying elements. so we'd like to demonstrate the following:

Req0011 <- DGN0034 <- Code

According to our process team, they do not want to trace by name like this:

Req0011 <- CustomerClass <- Code

[qwerty]

Geert hit the spot, but you still don't. My question: why for anything EXCEPT requirements and issues? Probably: because we can. But then there are the limitations where you even can't use it for correct issue numbering. The Enterprise in EA definitely is not meant for the ability to deploy it in an enterprise :-/

q.

[mse]

True, I myself am trying to understand the "why" behind it. A particular requiement with a unique ID can of course trace to a design element of a certain name such as a class with the name "Customer". I suppose this might come from the DOORS mentality rather than thinking of model-based documentation. In DOORS everything gets a unique ID and you trace between those IDs.

The only thing else that I can think of would be like in manufacturing where every part in an assembly has some kind of ID or identification system. You don't refer to just any part by name, but rather a specific ID of a part so that it's clear which one you are using.

Furthermore, it looks like the idea is that they are going to propose Reqtify to perform traceability, and they might be concerned that we will need IDs in EA. I still need to get an answer as to how Reqtify works with EA.

[Modesto Vega]

I agree that Geert hit the spot when he asked why?

However, I am starting to stop asking why because the majority of the times it boils down to one of 2 answers: because it can be done or because it is the wanting of somebody who can request it and has the clout to get it done.

If you are using an RDBMS as the repository, the easiest way to do this is by using the alias field and an on create trigger, with the trigger using a sequence to calculate the value. But I do not recommend it.

I cannot think of another way to due this in Sparx EA if it must be done.

[qwerty]

You probably "can do" it with EA. But it's not worth the effort. There are two ways. One is to educate people to trust and use EA as a modeling tool. Here you just have issue/requirement elements which are linked to other elements (via e.g. <<trace>>). The other way (if they "think" they need those IDs) is to use a standard RM tool and pay a lot of extra money for it and the synch effort. Most likely it will go down the 2nd gully :-/

q.