Question about EAs mapping for UML to C code

[mse]

EA has a rather interesting mapping for c-code generation. According to the C options document, there is the following for example:

struct - UML class with <<struct>> stereotype
typedef struct - UML class with <<struct>> stereotype with TaggedValue C::typedef true

So when I went to conduct a training on this, while the model was clear and understood, a developer ended up modeling the typedef as a UML Data Type. I was about to disagree with that but, in reality what he modeled is correct because a UML DataType is simply a type that is differentiated by its values (Section 10.2.3.1 https://www.omg.org/spec/UML/2.5/PDF).

I'm not sure that is enough to go with one or the other. EA does not generate code for a UML Data type. EA will generate code for a class with a <<struct>> stereotype however.

Finally, we are not generating code from the model, but I do want to make sure that our intents are clear and that one does model a struct as a class, while the other goes with a data type, leading to varying modeling standards. Of course I will eventually create a team standard for us to use, but before I do that, I want to have this concept clear so that it is justifiable.

[Eve]

If you are not using the code generation then you can ignore any rules we specify and make up your own standards. The important thing is that you make the decision so that you don't end up with conflicting modeling standards.

DataTypes model Types whose instances are distinguished only by their value.

I think that's the key difference here. As soon as you have any other distinguishing characteristic (such as an id attribute) then it can no longer be represented as a datatype. I'd argue that even a char* attribute would break that requirement because the value is generally distinguished by the target of the pointer instead of the value itself.

Having it based on a class means that it doesn't have that additional requirement, which means that it's the more general option.