PrimitiveType can be generalized, but not be specialized - why?

[Uffe]

The way I think Sparx should work is that any Data Type or non-built-in Primitive should appear and be selectable through the list without having to use "select type".

The problem is that that list becomes far too large in any non-trivial example. It just doesn't work.

This should be very easy to improve without using the list. We just need and extra item in the context menu called "Select Data Type" that restricts the "Select Type" search to just the following stereotypes <<data type>> and <<primitive>>.

Don't forget enumerations.

Damn - beat me to it.

I think Modesto's suggestion is good, but it's a far bigger change than it appears at first blush. You'd need to add it everywhere a type can be selected -- operations, parameters, template parameters...

That would help a little, but not much. In a repository I usually have many different data models that at different abstraction levels, that each use should only use their own set of datatypes as types of the attributes. It would be useful for me if we could limit the types to select to only those that are defined in that model, and nothing else.

That's a different suggestion. Not necessarily a bad one, but you are up against the fundamental problem that "model" is not defined (it means different things on different manual pages). Namespace, possibly.

But this is thin ice because you're basically talking about introducing something like a type model (by which I mean one where you define a bunch of types) which would have a special meaning, and EA doesn't really do special-meaning modelling: all models are equal, and no model is more equal than the others.

I think.

/Uffe

[Paolo F Cantoni]

[[SNIP]

But this is thin ice because you're basically talking about introducing something like a type model (by which I mean one where you define a bunch of types) which would have a special meaning, and EA doesn't really do special-meaning modelling: all models are equal, and no model is more equal than the others.

I think.

/Uffe

"Animal Model"? "Four types good, two types bad!"

(couldn't resist),
Paolo

[Geert Bellekens]

The concept of namespace works partially, but now I still have to select the namespace manually, so its each time an extra step.
If the "select type" dialog would automatically limit the dialog to the namespace of my model, that could be enough. That would actually only be a minor change (select the namespace automatically)

Geert

[ngong]

Thank you for all this valuable discussion. I know, it is tough to get a discussion converting to a result. Maybe Eve told it. However, I got more confused than enlightened. I guess, my understanding is compliant with Geert.

One of my common task in modeling is to explain any data type by breaking them down to a set of primitive types. Otherwise my model would miss some semantics. For me, that is the very purpose of primitive types.

A class attribute may represent the value of speed, another one the value of acceleration. Both boil down to my primitive Float. Speed and acceleration values shall not be compatible, e.g. in assignment.

Therefore I introduce a data type for the speed value, say SpeedValue_t, and for acceleration value, say AccelerationValue_t.

What I understood about Generalization (an inheritance in general) is that SpeedValue_t can be defined as a special kind of Float, as is AccelerationValue_t. Means SpeedValue_t is a Float and AccelerationValue_t is a Float.

But: EA justifies this as not UML compliant. For my understanding of UML 2.5.1 EA should! (using Realization relation is a workaround for me for now)

And: as Float is not e.g. a SpeedValue_t (at least in the case of AccelerationValue_t, or if SpeedValue_t has an inheritable operation) Float can not be a special kind of SpeedValue_t! But EA allows the SpeedValut_t to be specialized to Float. This feels completely wrong!

visualisation created with EA 15.1

[Modesto Vega]

[SNIP]
Therefore I introduce a data type for the speed value, say SpeedValue_t, and for acceleration value, say AccelerationValue_t.

Have you considered that introducing the SpeedValue_t and AccelerationValue_t data types is part of the problem? Why do you need to define them as a special type of Float?

It seems as if you are using these 2 data types to represent the values of 2 attributes classes.

By the way, if instead of using a Generalization you use a Realization you can draw the relationships the way you want them which is more intuitive.

[Uffe]

Hello again,

One of my common task in modeling is to explain any data type by breaking them down to a set of primitive types. Otherwise my model would miss some semantics. For me, that is the very purpose of primitive types.

This might be an issue. A UML PrimitiveType is solely and precisely something which "defines a predefined DataType, without any substructure". If you don't agree with this definition, you are headed for trouble.

A class attribute may represent the value of speed, another one the value of acceleration. Both boil down to my primitive Float. Speed and acceleration values shall not be compatible, e.g. in assignment.
Therefore I introduce a data type for the speed value, say SpeedValue_t, and for acceleration value, say AccelerationValue_t.

Makes sense.

What I understood about Generalization (an inheritance in general) is that SpeedValue_t can be defined as a special kind of Float, as is AccelerationValue_t. Means SpeedValue_t is a Float and AccelerationValue_t is a Float.

They can, if you're focusing on the representation rather than the meaning. If you're focusing on meaning, a speed is not a float, it is a physical property which may be measured (and the measurement may be stored in a floating-point value, or in two floating-point values, or some other way).

If you're not sure about which of these you're trying to model, again, you're headed for trouble. Are you in concept land or representation land?

But: EA justifies this as not UML compliant. For my understanding of UML 2.5.1 EA should! (using Realization relation is a workaround for me for now)

But if you decide that Float is a UML PrimitiveType, and that Speed is a UML DataType, you have also decided that they are two different things in the UML language. As I mentioned earlier in the thread, I don't believe generalizations should be permitted either way between these two, but if in any direction, it has to be from DataType to PrimitiveType, because DataTypes can have attributes and PrimitiveTypes can't. EA permits it in the other direction, which doesn't make sense.

And: as Float is not e.g. a SpeedValue_t (at least in the case of AccelerationValue_t, or if SpeedValue_t has an inheritable operation) Float can not be a special kind of SpeedValue_t! But EA allows the SpeedValut_t to be specialized to Float. This feels completely wrong!

visualisation created with EA 15.1

Didn't look at that, but I think there are two ways you can resolve this easily.

1) Make all your types either «primitive» or «dataType». «dataType» if you want them to have attributes, «primitive» otherwise.
Either way, you can generalize between them the way you want.

2) Make your Float a «primitive», and your SpeedValue_t and AccelerationValue_t «dataType»s with Float attributes.

HTH,


/Uffe