Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » If-expressions
If-expressions [message #61241] Sun, 24 August 2008 05:09 Go to next message
Stefan Schulze is currently offline Stefan Schulze
Messages: 70
Registered: July 2009
Member
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 14:18 Go to previous messageGo to next message
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 15:05 Go to previous messageGo to next message
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 #61359 is a reply to message #61335] Sun, 24 August 2008 19:20 Go to previous messageGo to next message
Stefan Schulze is currently offline Stefan Schulze
Messages: 70
Registered: July 2009
Member
"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
Re: If-expressions [message #61405 is a reply to message #61359] Sun, 24 August 2008 19:36 Go to previous message
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
>
>
Previous Topic:Sequence.subSequence with invalid arguments
Next Topic:OrderedSet::flatten()
Goto Forum:
  


Current Time: Mon Sep 22 20:24:20 GMT 2014

Powered by FUDForum. Page generated in 0.01873 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software