Home » Modeling » OCL » If-expressions
| If-expressions [message #61241] |
Sun, 24 August 2008 01:09  |
Eclipse User |
|
|
|
Hi...
I have in mind, that an if-expression in ocl is valid, if the then-type and
the else-type both have a common supertype. This supertype is the
result-type of the expression (sadly I can't find this or a related
statement in the spec).
According to the definition of OclAny, this is the common supertype for all
types in my UML-model.
As a result, I'd expect, that
> if foo() then anyWriter else anyBook endif
would return anything of type OclAny, but in the current implementation it
returns an error because Writer and Book don't have a common supertype.
I think this behaviour makes sense, but isn't this behaviour violating the
OCL-specification?
Stefan
|
|
|
| Re: If-expressions [message #61289 is a reply to message #61241] |
Sun, 24 August 2008 10:18  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Stefan,
See some replies in-line, below.
HTH,
Christian
Stefan Schulze wrote:
> Hi...
>
> I have in mind, that an if-expression in ocl is valid, if the then-type and
> the else-type both have a common supertype. This supertype is the
> result-type of the expression (sadly I can't find this or a related
> statement in the spec).
Section 8.3.7 "Well-formedness rules of the Expressions package" has
this for IfExp:
[2] The type of the if expression is the most common supertype of the
else and then expressions.
context IfExp
inv: self.type = thenExpression.type.commonSuperType(
elseExpression.type)
> According to the definition of OclAny, this is the common supertype for all
> types in my UML-model.
Yes, I suppose it would be one of the Classifier.allInstances() in the
definition of Classifier::commonSuperType(Classifier) in Section 8.3.8.
> As a result, I'd expect, that
>> if foo() then anyWriter else anyBook endif
> would return anything of type OclAny, but in the current implementation it
Yes, unless, of course, either of the anyWriter and anyBook expressions
has a collection type.
> returns an error because Writer and Book don't have a common supertype.
> I think this behaviour makes sense, but isn't this behaviour violating the
> OCL-specification?
I, too, think it makes sense because an expression of type OclAny isn't
of much use to anyone. What would you do with it? It has no
interesting features. However, this would seem to be a violation of the
semantics.
>
> Stefan
>
>
|
|
|
| Re: If-expressions [message #61335 is a reply to message #61241] |
Sun, 24 August 2008 11:05 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Stefan,
It occurs to me that the whole notion of OclAny being an implicit
supertype of all model classes is flawed to begin with, as it violates
the UML semantics of generalization. A UML classifier is only permitted
to specialize a classifier of the same or conformant metaclass.
From Classifier:
[3] A classifier may only specialize classifiers of a valid type.
self.parents()->forAll(c | self.maySpecializeType(c))
[8] The query maySpecializeType() determines whether this classifier may
have a generalization relationship to classifiers of
the specified type. By default a classifier may specialize
classifiers of the same or a more general type. It is intended to be
redefined by classifiers that have different specialization
constraints.
Classifier::maySpecializeType(c : Classifier) : Boolean;
maySpecializeType = self.oclIsKindOf(c.oclType)
Thus, the following generalizations are allowed:
- aClass --|> anotherClass
- aComponent --|> aClass
- anAssociationClass --|> aClass
but not:
- aClass --|> anInterface
- aClass --|> aComponent
- aClass --|> anAssociationClass
In particular, as OclAny is an instance of a metaclass AnyType that is
defined uniquely for it, the following cases are just like the first
case, above:
- Writer (a Class) --|> OclAny (an AnyType)
- Book --|> OclAny
The same proble exists for OclVoid and OclInvalid, which cannot be
specializations of model classes.
So, considering that the entire type system of OCL is fundamentally
corrupt, I guess that we can make our own rules for commonSuperType()
:-D
Seriously, though, we should probably stick to the intent of OCL and fix
its own problems, separately.
cW
Stefan Schulze wrote:
> Hi...
>
> I have in mind, that an if-expression in ocl is valid, if the then-type and
> the else-type both have a common supertype. This supertype is the
> result-type of the expression (sadly I can't find this or a related
> statement in the spec).
>
> According to the definition of OclAny, this is the common supertype for all
> types in my UML-model.
>
> As a result, I'd expect, that
>> if foo() then anyWriter else anyBook endif
> would return anything of type OclAny, but in the current implementation it
> returns an error because Writer and Book don't have a common supertype.
> I think this behaviour makes sense, but isn't this behaviour violating the
> OCL-specification?
>
> Stefan
>
>
|
|
| |
| Re: If-expressions [message #61405 is a reply to message #61359] |
Sun, 24 August 2008 15:36 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Stefan,
You have been doing a good job of finding bugs in the implementation,
too, observing issues that have hitherto escaped everyone else's
attention. Thanks for that!
The purpose of the MDT components, including OCL, is to provide
reference implementations of modeling specifications such as those
defined by the OMG. Thus, we strive to implement them as accurately as
we can, warts and all. This work also turns up issues in the
specification, which I am working with the RTF to address at OMG.
For this component, the "reference implementation" mandate is difficult
to manage, as the implementation predates the MDT project and was not
previously focused on strict compliance.
I hope that you are finding the MDT OCL component useful in your
application, and that you will continue to ask questions and to raise
problems!
Thanks,
Christian
Stefan Schulze wrote:
> "Christian W. Damus" <cdamus@zeligsoft.com> schrieb im Newsbeitrag
> news:g8rtcg$pv5$1@build.eclipse.org...
>> Seriously, though, we should probably stick to the intent of OCL and fix
>> its own problems, separately.
>
> My intent wasn't primaly to show flaws in this OCL-implementaten, but to
> understand more of the OCL specification (and I guess you are extremely well
> informed about this specification). I try to verify my understanding of the
> specification by the implementation. And I think looking for bugs in the
> specification, check another (but more consistent) behaviour in the
> implementation and getting an "Yes, it seems to be a bug in the
> specification" is a very effective way to learn the details (and flaws) of
> the OCL.
>
> So thank you for this very detailed and interesting explanation. It makes
> some other points in the specification much more clear.
>
> Stefan
>
>
|
|
|
Goto Forum:
Current Time: Tue Nov 04 01:52:22 EST 2025
Powered by FUDForum. Page generated in 0.05746 seconds |
Home