|
| Re: OCL expr as an initializer [message #476443 is a reply to message #476441] |
Wed, 31 October 2007 12:34  |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Krzysztof,
The default value could be an ExpressionInOcl, or it could simply be an
OpaqueExpression having "OCL" in its language.
I'm not sure what you mean by matching. The OCL parser will interpret the
types of MultiplicityElements in your model as having the appropriate OCL
collection type.
ExpressionInOcl is not a MultiplicityElement, so it cannot implicitly
declare its type as a collection type in the usual UML way. Pins are
MultiplicityElements, so I suppose that inputs to them should conform to
their implied collection types.
Some Actions have the ability to index collections, so these should work
with Sequences and OrderedSets. I'm not sure that there is much cohesion
between the specifications in this area, though. For example, the
AddStructuralFeatureValueAction has an "inserAt" InputPin that accepts the
collection index. However, UML requires this to be an UnlimitedNatural
(why? * would never be valid), but indexing in OCL is by Integer.
Moreover, the WriteStructuralFeatureAction abstract metaclass requires that
the type of the "value" InputPin be the same as the structural feature's
type, but doesn't account for multiplicities of either the structural
feature or the value specified by the pin (either by an ObjectFlow or by
using a ValuePin). On that subject, the only constraint on ValuePin is
that its value specification must have a type "compatible with" the pin's
type. That's pretty vague.
All of this is to say, that I'm not sure that you can actually satisfy the
type conformance constraints using ValueSpecifications of any kind in
Actions because ValueSpecifications are not MultiplicityElements, so you
cannot express collection types in the way that Pins require.
HTH,
Christian
Krzysztof Kaczmarski wrote:
> Hi All,
>
> in the OCL standard description there is an information that OCL
> expression may be used as an initialization expression for UML class
> attributes. I suppose that in such case Property's defaultValue is set
> to ExpressionInOCL object.
> My question is how are the types and values mapped between OCL and
> UML. If we have a Property that is a collection ( dogs:Dog[0..*] ) are
> the values from a resulting OCL matched automatically?
>
> This question has a little deeper meaning for me. If we use
> ExpressionInOCL as a ValueSpecification in a UML Action (for example
> ValueSpecificationAction) and we need to use OutputPin and ObjectFlow
> to actually consume resulting values. How is the OCL collection
> interpreted then?
>
> Thanks in advance,
> Krzysztof
|
|
|
| Re: OCL expr as an initializer [message #625346 is a reply to message #476441] |
Wed, 31 October 2007 12:34 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Krzysztof,
The default value could be an ExpressionInOcl, or it could simply be an
OpaqueExpression having "OCL" in its language.
I'm not sure what you mean by matching. The OCL parser will interpret the
types of MultiplicityElements in your model as having the appropriate OCL
collection type.
ExpressionInOcl is not a MultiplicityElement, so it cannot implicitly
declare its type as a collection type in the usual UML way. Pins are
MultiplicityElements, so I suppose that inputs to them should conform to
their implied collection types.
Some Actions have the ability to index collections, so these should work
with Sequences and OrderedSets. I'm not sure that there is much cohesion
between the specifications in this area, though. For example, the
AddStructuralFeatureValueAction has an "inserAt" InputPin that accepts the
collection index. However, UML requires this to be an UnlimitedNatural
(why? * would never be valid), but indexing in OCL is by Integer.
Moreover, the WriteStructuralFeatureAction abstract metaclass requires that
the type of the "value" InputPin be the same as the structural feature's
type, but doesn't account for multiplicities of either the structural
feature or the value specified by the pin (either by an ObjectFlow or by
using a ValuePin). On that subject, the only constraint on ValuePin is
that its value specification must have a type "compatible with" the pin's
type. That's pretty vague.
All of this is to say, that I'm not sure that you can actually satisfy the
type conformance constraints using ValueSpecifications of any kind in
Actions because ValueSpecifications are not MultiplicityElements, so you
cannot express collection types in the way that Pins require.
HTH,
Christian
Krzysztof Kaczmarski wrote:
> Hi All,
>
> in the OCL standard description there is an information that OCL
> expression may be used as an initialization expression for UML class
> attributes. I suppose that in such case Property's defaultValue is set
> to ExpressionInOCL object.
> My question is how are the types and values mapped between OCL and
> UML. If we have a Property that is a collection ( dogs:Dog[0..*] ) are
> the values from a resulting OCL matched automatically?
>
> This question has a little deeper meaning for me. If we use
> ExpressionInOCL as a ValueSpecification in a UML Action (for example
> ValueSpecificationAction) and we need to use OutputPin and ObjectFlow
> to actually consume resulting values. How is the OCL collection
> interpreted then?
>
> Thanks in advance,
> Krzysztof
|
|
|
Powered by
FUDForum. Page generated in 0.02618 seconds
] 
Search
Help
Register
Login
Home
