Hi Christian,
Some in-lined comments:
Right. UnlimitedNatural is poorly defined. Mathematically, the
naturals are a subset of the integers, but UML adds an explicit
infinity (which is mathematically bogus, btw) that, by definition,
falls outside of the range of the Integer type. So, UnlimitedNatural
cannot be a subtype of Integer, nor can Integer be a subtype of
UnlimitedNatural because of the negative values.
Therefore, there is no reason for considering that UnlimitedNatural as
a subtype of Real, which will need to be fixed.
Besides it seems that
UnlimitedNatural (Integer) is considered as an Integer in the OCL
Standard Library with all Integer's operations, is this correct ?¿?.
Well, we had to map UnlimitedNatural to a Java type, and chose
int/Integer to align with MDT UML2 and to avoid the performance cost of
BigInteger.
My question had another concerns. I was thinking about the fact that
UnlimitedNatural type has the same operations Integer has. However, I
was confused, that operations come from considering UnlimitedType as a
Real subtype.
Its not clear for me, at
least reading the spec. Beside, which kind of sense make adding
something to the unlimited value (*) ? In any case, * must be the result
Heh heh ... a good point. Hence the mathematical bogosity of the *
value. Actually, * only makes sense as a value in multiplicity
specifications. It can hardly ever be useful in OCL expressions
because it UnlimitedNaturals only occur in metamodels (upper bounds of
MultiplicityElements). They are never used in models.
Note, also, that the *only* UnlimitedNatural literal value that
OCL can express in the * value, because all numeric values look like
Integers. There is no defined relationship between UnlimitedNatural
and Integer types and no coercion operations, to convert between these
types.
Fixing commonSuperType and
getRelationship methods would produce the following error (which I
would really expect) for the example "2 + *"
Got expected exception: Cannot find operation (+(UnlimitedNatural)) for
the type (Integer).
However because of the design of the stdlib in which UnlimitedNatural
primitive type have the integer operations (+(Real) ) I can't do
anything whith the other example "* + 2" at parsing time. At least, the
implementation evaluates those expressions to invalid.
I wouldn't worry about that: it can hardly be an interesting case. No
useful OCL expressions will run into this :-)
-------------
Another idea is considering the type conformance between Integer and
UnlimitedNaturals, so that Integer conforms to the UnlimitedNatural
type (which is always valued as *).
As I mentioned already, we cannot do this. The negative integers don't
fit.
So, as a conclusion I think that a possible patch to solve the related
issue would enclose the following matters:
- Revising commonSuperType, so that OclAny is considered a common super
type in every case, excepting the cases we deal with collection types.
- Revising getRelationShip so that UnlimitedNatural must not be
considered a Real's subtype.
- Revising test cases. Some of them have incorrect considerations about
type conformance.
Anyway, I think that OCL
specification should better clarify the rules of type conformance (if
any) between this primitive types. So that we don't have to make
interpretations about which are valid (parsed/evaluated) expressions
and which are not (and why they are not valid).
Absolutely! I think the UnlimitedNatural type should be eliminated.
There is no need for a * value in multiplicities: it is a nice visual
representation in diagrams, but the MultiplicityElement can just as
well have an " / isUnlimited : Boolean" attribute as well as an
optional "upperBound : Integer" attribute (the derived isUnlimited
attribute being determined by the absence of the upper bound). The
UnlimitedNatural is more trouble than it's worth; an abomination.
I understand, and I agree with you. I hadn't thought about the use of
the symbol * in OCL expressions (I'm usually so immerse in the
low-level parsing world), and it doesn't make sense a query which
checks if a company have infinite employers >.<
Thank you very much for the response.
Cheers,
Adolfo.
--
|
Adolfo
Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231 / +34 617 718268 |
|
