Home » Modeling » OCL » impedance mismatch between OCL and UML2
| impedance mismatch between OCL and UML2 [message #7254] |
Tue, 20 February 2007 21:00  |
Eclipse User |
|
|
|
Originally posted by: chaves.inf.ufsc.nospam.br
I realy appreciate the effort that went into making the Eclipse OCL
(which originally was restricted to EMF) work with UML2.
However, there seems to be some spots where the integration between OCL
and UML2 is rather limited, and there is a mismatch between the two
APIs, when one would expect them to integrate seamlessly.
One example: OperationCallExp and PropertyCallExp both integrate nicely
with UML2 operations. However, VariableExp refers explicitly to OCL
variables, so it is impossible to make it work with UML2 variables.
Is there an intent of improving this situation?
Thanks,
Rafael
|
|
|
| Re: impedance mismatch between OCL and UML2 [message #7295 is a reply to message #7254] |
Wed, 21 February 2007 15:15  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Rafael,
The Expressions package of the OCL Abstract Syntax model does not use UML's
Variable. It defines its own Variable type, with such features as an
initialization expression and reference to a parameter that it represents
(these are not available in the UML Variable metaclass). See Fig. 8.2 (p.
40) of the OCL 2.0 specification for details.
Cheers,
Christian
Rafael Chaves wrote:
> I realy appreciate the effort that went into making the Eclipse OCL
> (which originally was restricted to EMF) work with UML2.
>
> However, there seems to be some spots where the integration between OCL
> and UML2 is rather limited, and there is a mismatch between the two
> APIs, when one would expect them to integrate seamlessly.
>
> One example: OperationCallExp and PropertyCallExp both integrate nicely
> with UML2 operations. However, VariableExp refers explicitly to OCL
> variables, so it is impossible to make it work with UML2 variables.
>
> Is there an intent of improving this situation?
>
> Thanks,
>
> Rafael
|
|
|
| Re: impedance mismatch between OCL and UML2 [message #9276 is a reply to message #7295] |
Wed, 21 February 2007 17:31 |
| Eclipse User |
|
|
|
Originally posted by: chaves.inf.ufsc.nospam.br
Ok, thanks. I confess I am disappointed by the lack of alignment between
OCL and UML (the specs, not the implementations @ Eclipse.org). The
outcome is that I will be forced to come up with a band-aid solution in
order to overcome this.
Anyway, thanks for the explanation.
Rafael
Christian W. Damus wrote:
> Hi, Rafael,
>
> The Expressions package of the OCL Abstract Syntax model does not use UML's
> Variable. It defines its own Variable type, with such features as an
> initialization expression and reference to a parameter that it represents
> (these are not available in the UML Variable metaclass). See Fig. 8.2 (p.
> 40) of the OCL 2.0 specification for details.
>
> Cheers,
>
> Christian
>
>
> Rafael Chaves wrote:
>
>> I realy appreciate the effort that went into making the Eclipse OCL
>> (which originally was restricted to EMF) work with UML2.
>>
>> However, there seems to be some spots where the integration between OCL
>> and UML2 is rather limited, and there is a mismatch between the two
>> APIs, when one would expect them to integrate seamlessly.
>>
>> One example: OperationCallExp and PropertyCallExp both integrate nicely
>> with UML2 operations. However, VariableExp refers explicitly to OCL
>> variables, so it is impossible to make it work with UML2 variables.
>>
>> Is there an intent of improving this situation?
>>
>> Thanks,
>>
>> Rafael
>
|
|
|
| Re: impedance mismatch between OCL and UML2 [message #9344 is a reply to message #7295] |
Fri, 23 February 2007 08:10 |
| Eclipse User |
|
|
|
Originally posted by: chaves.inf.ufsc.nospam.br
Hi Christian,
Thanks for clarifying my question around UML x OCL variables.
One thing though that only now I realized is that the approach you took
for making Eclipse OCL work with UML2 (using Java generics) has some
limitations. For instance, you cannot define the superclass of a class
to be a template parameter. So any metaclasses defined by OCL that are
supposed to extend UML metaclasses (for instance, OCLExpression should
extend UML's TypedElement, but since OCL is standalone, a placeholder
TypedElement class had to be defined - I am pretty sure there are other
cases).
So, two questions:
1) do you agree that this situation is less than optimal?
2) if you said 'yes' to #1: is fixing this somewhere in Eclipse OCL's
roadmap?
Personally, I have the feeling that trying to make OCL work with EMF and
UML2 with a single API and still be compliant with the UML specs is
not feasible, given the limitations of what you can do with Java
generics. An alternative approach would be to have two API (one based on
EMF and the other on UML), possibly sharing a big chunk of the
implementation. Did you consider taking that approach?
Rafael
Christian W. Damus wrote:
> Hi, Rafael,
>
> The Expressions package of the OCL Abstract Syntax model does not use UML's
> Variable. It defines its own Variable type, with such features as an
> initialization expression and reference to a parameter that it represents
> (these are not available in the UML Variable metaclass). See Fig. 8.2 (p.
> 40) of the OCL 2.0 specification for details.
>
> Cheers,
>
> Christian
>
>
> Rafael Chaves wrote:
>
>> I realy appreciate the effort that went into making the Eclipse OCL
>> (which originally was restricted to EMF) work with UML2.
>>
>> However, there seems to be some spots where the integration between OCL
>> and UML2 is rather limited, and there is a mismatch between the two
>> APIs, when one would expect them to integrate seamlessly.
>>
>> One example: OperationCallExp and PropertyCallExp both integrate nicely
>> with UML2 operations. However, VariableExp refers explicitly to OCL
>> variables, so it is impossible to make it work with UML2 variables.
>>
>> Is there an intent of improving this situation?
>>
>> Thanks,
>>
>> Rafael
>
|
|
|
| Re: impedance mismatch between OCL and UML2 [message #9369 is a reply to message #9344] |
Fri, 23 February 2007 11:11 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Rafael,
See some replies in-line, below.
Thanks,
Christian
Rafael Chaves wrote:
> Hi Christian,
>
> Thanks for clarifying my question around UML x OCL variables.
>
> One thing though that only now I realized is that the approach you took
> for making Eclipse OCL work with UML2 (using Java generics) has some
> limitations. For instance, you cannot define the superclass of a class
> to be a template parameter. So any metaclasses defined by OCL that are
> supposed to extend UML metaclasses (for instance, OCLExpression should
> extend UML's TypedElement, but since OCL is standalone, a placeholder
> TypedElement class had to be defined - I am pretty sure there are other
> cases).
The OCL specification, itself, is a little peculiar in this regard. The OCL
has two important dialects: CompleteOCL (binding to UML) and EssentialOCL
(binding to EMOF). I don't know how interesting BasicOCL is, in practice.
Chapter 13.2 "OCL Adaptation for Metamodeling" is an amusing read. The
adaptations of the OCL metamodel that it describes make sense, but are
rather awkward when one is trying to devise a usable API. For example:
Core::Basic does not contain the intermediate notion of
Classifier but uses instead directly the Type notion as
the base class for the type system. Consequently, any reference
to the Classifier class in the complete OCL specification has to
be re-interpreted as a reference to the Type class.
and this:
In complete OCL, TupleType has DataType as base type. In BasicOCL
Tuple has also Class as base type so that the attributes of the
tuple can be defined in the same way as in complete OCL - as
Property instances.
These re-interpretations are further complicated by the fact that the
corresponding metaclasses in Core::Basic and in UML (and in EMOF) are
different: the metaclasses named "Type", "Class", "TypedElement", etc. in
these metamodels are distinct. So, in reality, there are three totally
separate OCL Abstract Syntax models. It is only in the concrete syntax
that there is unity.
Of course, MDT OCL doesn't actually attempt to implement EssentialOCL, but
rather EcoreOCL (considering Ecore as an approximation of EMOF).
> So, two questions:
>
> 1) do you agree that this situation is less than optimal?
Yes, I do.
> 2) if you said 'yes' to #1: is fixing this somewhere in Eclipse OCL's
> roadmap?
Not actually in the plan, no. The main goal of the current design was to
minimize the amount of API as much as possible, to present a clean and
easy-to-use interface to tool developers. Also, having two distinct APIs
is a maintenance head-ache. The generic API allows for the construction of
a single parser/interpreter, and the Ecore and UML bindings are very small
extensions to that.
> Personally, I have the feeling that trying to make OCL work with EMF and
> UML2 with a single API and still be compliant with the UML specs is
> not feasible, given the limitations of what you can do with Java
> generics. An alternative approach would be to have two API (one based on
> EMF and the other on UML), possibly sharing a big chunk of the
> implementation. Did you consider taking that approach?
Yes. As I mentioned above, that didn't seem to be the best way to go from
an API perspective. The main concern that I have at this stage is for
compliance of the serial form of OCL constructs (XMI in particular). I
think the Types package should be OK, because these are actually redefined
by the org.eclipse.ocl.ecore and org.eclipse.ocl.uml plug-ins to implement
the metamodel adaptations from Chapter 13. Most importantly, the OCL types
need to conform to the particular metamodel's "classifier" metaclass.
It wasn't necessary to similarly redefine the Expressions package from an
API (and parser implementation) perspective, but I'm not sure yet whether
it is possible with EMF to ensure XMI compatibility there. Probably some
kind of XMI import/export (as in the MDT UML2 API) would be required, or
possibly even redefining the Expressions package in each of the bindings (I
would rather avoid that). In any case, I would definitely need help to
investigate this, as I am not nearly as familiar with XMI and the way that
the UML family of specifications works as are Kenn and Ed.
I've had to take a pragmatic approach with my limited experience and
resources to implement the requirements that I know about. I know that
there are problems, but I think the 1.1 API is an improvement over 1.0 on
both the Ecore and (obviously) UML side. I'm certainly open to whatever
help the community can offer to continue to improve it.
>
> Rafael
>
> Christian W. Damus wrote:
>> Hi, Rafael,
>>
>> The Expressions package of the OCL Abstract Syntax model does not use
>> UML's
>> Variable. It defines its own Variable type, with such features as an
>> initialization expression and reference to a parameter that it represents
>> (these are not available in the UML Variable metaclass). See Fig. 8.2
>> (p. 40) of the OCL 2.0 specification for details.
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Rafael Chaves wrote:
>>
>>> I realy appreciate the effort that went into making the Eclipse OCL
>>> (which originally was restricted to EMF) work with UML2.
>>>
>>> However, there seems to be some spots where the integration between OCL
>>> and UML2 is rather limited, and there is a mismatch between the two
>>> APIs, when one would expect them to integrate seamlessly.
>>>
>>> One example: OperationCallExp and PropertyCallExp both integrate nicely
>>> with UML2 operations. However, VariableExp refers explicitly to OCL
>>> variables, so it is impossible to make it work with UML2 variables.
>>>
>>> Is there an intent of improving this situation?
>>>
>>> Thanks,
>>>
>>> Rafael
>>
|
|
|
Goto Forum:
Current Time: Mon Nov 03 19:42:20 EST 2025
Powered by FUDForum. Page generated in 0.05170 seconds |
Home