Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » AddStructuralFeatureValue constraint
AddStructuralFeatureValue constraint [message #476902] Fri, 01 February 2008 12:20 Go to next message
Krzysztof Kaczmarski is currently offline Krzysztof KaczmarskiFriend
Messages: 88
Registered: July 2009
Member
Hi All,

I found the following constraint on InputPin's value

self.value.type = self.structuralFeature.featuringClassifier

in the WriteStructuralFeatureAction which is used in other specialized
actions (AddStructualFeatureValueAction). The question is, does this
constraint allow to assign a value of a specialized type to a more
general property type?
Like to put a Student object in a property of Person type?
If such an assignment is not allowed, what is the reason?

Thanks for any suggestions,
Krzysztof
Re: AddStructuralFeatureValue constraint [message #476903 is a reply to message #476902] Fri, 01 February 2008 13:02 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Krzysztof,

This constraint doesn't make sense to me.

Firstly, the OCL expression is ill-formed: featuringClassifier is a
multi-valued feature, but type is scalar.

Second, this constraint indicates that the value written into a structural
feature must be of the type that defines the feature, but that's silly.
The value should at least be of the type *of* the feature, not the type
*featuring* the feature.

So, I would say that this is an issue for the RTF, and the constraint should
be formulated thus:

self.value.type.conformsTo(self.structuralFeature.type)

This would allow Student instances to be written into a structural feature
of type Person.

Cheers,

Christian


Krzysztof Kaczmarski wrote:

> Hi All,
>
> I found the following constraint on InputPin's value
>
> self.value.type = self.structuralFeature.featuringClassifier
>
> in the WriteStructuralFeatureAction which is used in other specialized
> actions (AddStructualFeatureValueAction). The question is, does this
> constraint allow to assign a value of a specialized type to a more
> general property type?
> Like to put a Student object in a property of Person type?
> If such an assignment is not allowed, what is the reason?
>
> Thanks for any suggestions,
> Krzysztof
Re: AddStructuralFeatureValue constraint [message #476904 is a reply to message #476903] Sat, 02 February 2008 07:14 Go to previous messageGo to next message
Krzysztof Kaczmarski is currently offline Krzysztof KaczmarskiFriend
Messages: 88
Registered: July 2009
Member
Thanks, Christian.

What is the procedure of correcting this problem? Is there any way I
can help?

Cheers,
Krzysztof


Christian W. Damus wrote:
> Hi, Krzysztof,
>
> This constraint doesn't make sense to me.
>
> Firstly, the OCL expression is ill-formed: featuringClassifier is a
> multi-valued feature, but type is scalar.
>
> Second, this constraint indicates that the value written into a structural
> feature must be of the type that defines the feature, but that's silly.
> The value should at least be of the type *of* the feature, not the type
> *featuring* the feature.
>
> So, I would say that this is an issue for the RTF, and the constraint should
> be formulated thus:
>
> self.value.type.conformsTo(self.structuralFeature.type)
>
> This would allow Student instances to be written into a structural feature
> of type Person.
>
> Cheers,
>
> Christian
>
>
> Krzysztof Kaczmarski wrote:
>
>> Hi All,
>>
>> I found the following constraint on InputPin's value
>>
>> self.value.type = self.structuralFeature.featuringClassifier
>>
>> in the WriteStructuralFeatureAction which is used in other specialized
>> actions (AddStructualFeatureValueAction). The question is, does this
>> constraint allow to assign a value of a specialized type to a more
>> general property type?
>> Like to put a Student object in a property of Person type?
>> If such an assignment is not allowed, what is the reason?
>>
>> Thanks for any suggestions,
>> Krzysztof
>
Re: AddStructuralFeatureValue constraint [message #476906 is a reply to message #476904] Mon, 04 February 2008 12:26 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, K,

You can start by searching the list of issues under consideration by the UML
2.2 RTF (revision task force) to see whether this problem has already been
raised (and possibly resolved):

http://www.omg.org/issues/uml2-rtf.html

If this appears to be a new issue, you can report it to OMG via the
issues-reporting form:

http://www.omg.org/technology/agreement.htm

Cheers,

Christian


Krzysztof Kaczmarski wrote:

> Thanks, Christian.
>
> What is the procedure of correcting this problem? Is there any way I
> can help?
>
> Cheers,
> Krzysztof
>
>
> Christian W. Damus wrote:
>> Hi, Krzysztof,
>>
>> This constraint doesn't make sense to me.
>>
>> Firstly, the OCL expression is ill-formed: featuringClassifier is a
>> multi-valued feature, but type is scalar.
>>
>> Second, this constraint indicates that the value written into a
>> structural feature must be of the type that defines the feature, but
>> that's silly. The value should at least be of the type *of* the feature,
>> not the type *featuring* the feature.
>>
>> So, I would say that this is an issue for the RTF, and the constraint
>> should be formulated thus:
>>
>> self.value.type.conformsTo(self.structuralFeature.type)
>>
>> This would allow Student instances to be written into a structural
>> feature of type Person.
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Krzysztof Kaczmarski wrote:
>>
>>> Hi All,
>>>
>>> I found the following constraint on InputPin's value
>>>
>>> self.value.type = self.structuralFeature.featuringClassifier
>>>
>>> in the WriteStructuralFeatureAction which is used in other specialized
>>> actions (AddStructualFeatureValueAction). The question is, does this
>>> constraint allow to assign a value of a specialized type to a more
>>> general property type?
>>> Like to put a Student object in a property of Person type?
>>> If such an assignment is not allowed, what is the reason?
>>>
>>> Thanks for any suggestions,
>>> Krzysztof
>>
Re: AddStructuralFeatureValue constraint [message #476907 is a reply to message #476906] Mon, 04 February 2008 12:31 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Sorry, Krzysztof,

I don't seem to have pasted your complete name. I didn't mean to assume
such familiarity.

Christian


Christian W. Damus wrote:

> Hi, K,
>
> You can start by searching the list of issues under consideration by the
> UML 2.2 RTF (revision task force) to see whether this problem has already
> been raised (and possibly resolved):
>
> http://www.omg.org/issues/uml2-rtf.html
>
> If this appears to be a new issue, you can report it to OMG via the
> issues-reporting form:
>
> http://www.omg.org/technology/agreement.htm
>
> Cheers,
>
> Christian
>
>
> Krzysztof Kaczmarski wrote:
>
>> Thanks, Christian.
>>
>> What is the procedure of correcting this problem? Is there any way I
>> can help?
>>
>> Cheers,
>> Krzysztof
>>
>>
>> Christian W. Damus wrote:
>>> Hi, Krzysztof,
>>>
>>> This constraint doesn't make sense to me.
>>>
>>> Firstly, the OCL expression is ill-formed: featuringClassifier is a
>>> multi-valued feature, but type is scalar.
>>>
>>> Second, this constraint indicates that the value written into a
>>> structural feature must be of the type that defines the feature, but
>>> that's silly. The value should at least be of the type *of* the feature,
>>> not the type *featuring* the feature.
>>>
>>> So, I would say that this is an issue for the RTF, and the constraint
>>> should be formulated thus:
>>>
>>> self.value.type.conformsTo(self.structuralFeature.type)
>>>
>>> This would allow Student instances to be written into a structural
>>> feature of type Person.
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>>
>>> Krzysztof Kaczmarski wrote:
>>>
>>>> Hi All,
>>>>
>>>> I found the following constraint on InputPin's value
>>>>
>>>> self.value.type = self.structuralFeature.featuringClassifier
>>>>
>>>> in the WriteStructuralFeatureAction which is used in other specialized
>>>> actions (AddStructualFeatureValueAction). The question is, does this
>>>> constraint allow to assign a value of a specialized type to a more
>>>> general property type?
>>>> Like to put a Student object in a property of Person type?
>>>> If such an assignment is not allowed, what is the reason?
>>>>
>>>> Thanks for any suggestions,
>>>> Krzysztof
>>>
Re: AddStructuralFeatureValue constraint [message #476908 is a reply to message #476907] Mon, 04 February 2008 17:51 Go to previous messageGo to next message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi, Krzysztof

I could raise that on your behalf if you wish.
(The OMG process might be a bit cumbersome if you want to raise only one
issue).

....special thanks to "big-C" for confirming this as an issue ... ;-)

Cheers,

- J.


"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:fo70jh$8fd$3@build.eclipse.org...
> Sorry, Krzysztof,
>
> I don't seem to have pasted your complete name. I didn't mean to assume
> such familiarity.
>
> Christian
>
>
> Christian W. Damus wrote:
>
>> Hi, K,
>>
>> You can start by searching the list of issues under consideration by the
>> UML 2.2 RTF (revision task force) to see whether this problem has already
>> been raised (and possibly resolved):
>>
>> http://www.omg.org/issues/uml2-rtf.html
>>
>> If this appears to be a new issue, you can report it to OMG via the
>> issues-reporting form:
>>
>> http://www.omg.org/technology/agreement.htm
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Krzysztof Kaczmarski wrote:
>>
>>> Thanks, Christian.
>>>
>>> What is the procedure of correcting this problem? Is there any way I
>>> can help?
>>>
>>> Cheers,
>>> Krzysztof
>>>
>>>
>>> Christian W. Damus wrote:
>>>> Hi, Krzysztof,
>>>>
>>>> This constraint doesn't make sense to me.
>>>>
>>>> Firstly, the OCL expression is ill-formed: featuringClassifier is a
>>>> multi-valued feature, but type is scalar.
>>>>
>>>> Second, this constraint indicates that the value written into a
>>>> structural feature must be of the type that defines the feature, but
>>>> that's silly. The value should at least be of the type *of* the
>>>> feature,
>>>> not the type *featuring* the feature.
>>>>
>>>> So, I would say that this is an issue for the RTF, and the constraint
>>>> should be formulated thus:
>>>>
>>>> self.value.type.conformsTo(self.structuralFeature.type)
>>>>
>>>> This would allow Student instances to be written into a structural
>>>> feature of type Person.
>>>>
>>>> Cheers,
>>>>
>>>> Christian
>>>>
>>>>
>>>> Krzysztof Kaczmarski wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I found the following constraint on InputPin's value
>>>>>
>>>>> self.value.type = self.structuralFeature.featuringClassifier
>>>>>
>>>>> in the WriteStructuralFeatureAction which is used in other specialized
>>>>> actions (AddStructualFeatureValueAction). The question is, does this
>>>>> constraint allow to assign a value of a specialized type to a more
>>>>> general property type?
>>>>> Like to put a Student object in a property of Person type?
>>>>> If such an assignment is not allowed, what is the reason?
>>>>>
>>>>> Thanks for any suggestions,
>>>>> Krzysztof
>>>>
>
Re: AddStructuralFeatureValue constraint [message #476909 is a reply to message #476908] Tue, 05 February 2008 12:59 Go to previous messageGo to next message
Krzysztof Kaczmarski is currently offline Krzysztof KaczmarskiFriend
Messages: 88
Registered: July 2009
Member
Yes, it really is. How can I know all those informations about
document if they are not explicitly stated in the first page?
What should be taken for "Document #"?

James, If it is not a problem. Please fill free to rise this issue.
It would be great if Polish-Japanese Institute of Information
Technology could be present somewhere in the description.

Cheers,
Krzysztof



James Bruck wrote:
> Hi, Krzysztof
>
> I could raise that on your behalf if you wish.
> (The OMG process might be a bit cumbersome if you want to raise only one
> issue).
>
> ...special thanks to "big-C" for confirming this as an issue ... ;-)
>
> Cheers,
>
> - J.
>
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:fo70jh$8fd$3@build.eclipse.org...
>> Sorry, Krzysztof,
>>
>> I don't seem to have pasted your complete name. I didn't mean to assume
>> such familiarity.
>>
>> Christian
>>
>>
>> Christian W. Damus wrote:
>>
>>> Hi, K,
>>>
>>> You can start by searching the list of issues under consideration by the
>>> UML 2.2 RTF (revision task force) to see whether this problem has already
>>> been raised (and possibly resolved):
>>>
>>> http://www.omg.org/issues/uml2-rtf.html
>>>
>>> If this appears to be a new issue, you can report it to OMG via the
>>> issues-reporting form:
>>>
>>> http://www.omg.org/technology/agreement.htm
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>>
>>> Krzysztof Kaczmarski wrote:
>>>
>>>> Thanks, Christian.
>>>>
>>>> What is the procedure of correcting this problem? Is there any way I
>>>> can help?
>>>>
>>>> Cheers,
>>>> Krzysztof
>>>>
>>>>
>>>> Christian W. Damus wrote:
>>>>> Hi, Krzysztof,
>>>>>
>>>>> This constraint doesn't make sense to me.
>>>>>
>>>>> Firstly, the OCL expression is ill-formed: featuringClassifier is a
>>>>> multi-valued feature, but type is scalar.
>>>>>
>>>>> Second, this constraint indicates that the value written into a
>>>>> structural feature must be of the type that defines the feature, but
>>>>> that's silly. The value should at least be of the type *of* the
>>>>> feature,
>>>>> not the type *featuring* the feature.
>>>>>
>>>>> So, I would say that this is an issue for the RTF, and the constraint
>>>>> should be formulated thus:
>>>>>
>>>>> self.value.type.conformsTo(self.structuralFeature.type)
>>>>>
>>>>> This would allow Student instances to be written into a structural
>>>>> feature of type Person.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> Krzysztof Kaczmarski wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I found the following constraint on InputPin's value
>>>>>>
>>>>>> self.value.type = self.structuralFeature.featuringClassifier
>>>>>>
>>>>>> in the WriteStructuralFeatureAction which is used in other specialized
>>>>>> actions (AddStructualFeatureValueAction). The question is, does this
>>>>>> constraint allow to assign a value of a specialized type to a more
>>>>>> general property type?
>>>>>> Like to put a Student object in a property of Person type?
>>>>>> If such an assignment is not allowed, what is the reason?
>>>>>>
>>>>>> Thanks for any suggestions,
>>>>>> Krzysztof
>
>
Re: AddStructuralFeatureValue constraint [message #476910 is a reply to message #476908] Tue, 05 February 2008 13:01 Go to previous message
Krzysztof Kaczmarski is currently offline Krzysztof KaczmarskiFriend
Messages: 88
Registered: July 2009
Member
Oh, and I checked that there are no issues like this among already
submitted. It looks to be a new one.

KK

James Bruck wrote:
> Hi, Krzysztof
>
> I could raise that on your behalf if you wish.
> (The OMG process might be a bit cumbersome if you want to raise only one
> issue).
>
> ...special thanks to "big-C" for confirming this as an issue ... ;-)
>
> Cheers,
>
> - J.
>
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:fo70jh$8fd$3@build.eclipse.org...
>> Sorry, Krzysztof,
>>
>> I don't seem to have pasted your complete name. I didn't mean to assume
>> such familiarity.
>>
>> Christian
>>
>>
>> Christian W. Damus wrote:
>>
>>> Hi, K,
>>>
>>> You can start by searching the list of issues under consideration by the
>>> UML 2.2 RTF (revision task force) to see whether this problem has already
>>> been raised (and possibly resolved):
>>>
>>> http://www.omg.org/issues/uml2-rtf.html
>>>
>>> If this appears to be a new issue, you can report it to OMG via the
>>> issues-reporting form:
>>>
>>> http://www.omg.org/technology/agreement.htm
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>>
>>> Krzysztof Kaczmarski wrote:
>>>
>>>> Thanks, Christian.
>>>>
>>>> What is the procedure of correcting this problem? Is there any way I
>>>> can help?
>>>>
>>>> Cheers,
>>>> Krzysztof
>>>>
>>>>
>>>> Christian W. Damus wrote:
>>>>> Hi, Krzysztof,
>>>>>
>>>>> This constraint doesn't make sense to me.
>>>>>
>>>>> Firstly, the OCL expression is ill-formed: featuringClassifier is a
>>>>> multi-valued feature, but type is scalar.
>>>>>
>>>>> Second, this constraint indicates that the value written into a
>>>>> structural feature must be of the type that defines the feature, but
>>>>> that's silly. The value should at least be of the type *of* the
>>>>> feature,
>>>>> not the type *featuring* the feature.
>>>>>
>>>>> So, I would say that this is an issue for the RTF, and the constraint
>>>>> should be formulated thus:
>>>>>
>>>>> self.value.type.conformsTo(self.structuralFeature.type)
>>>>>
>>>>> This would allow Student instances to be written into a structural
>>>>> feature of type Person.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> Krzysztof Kaczmarski wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I found the following constraint on InputPin's value
>>>>>>
>>>>>> self.value.type = self.structuralFeature.featuringClassifier
>>>>>>
>>>>>> in the WriteStructuralFeatureAction which is used in other specialized
>>>>>> actions (AddStructualFeatureValueAction). The question is, does this
>>>>>> constraint allow to assign a value of a specialized type to a more
>>>>>> general property type?
>>>>>> Like to put a Student object in a property of Person type?
>>>>>> If such an assignment is not allowed, what is the reason?
>>>>>>
>>>>>> Thanks for any suggestions,
>>>>>> Krzysztof
>
>
Re: AddStructuralFeatureValue constraint [message #625981 is a reply to message #476902] Fri, 01 February 2008 13:02 Go to previous message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, Krzysztof,

This constraint doesn't make sense to me.

Firstly, the OCL expression is ill-formed: featuringClassifier is a
multi-valued feature, but type is scalar.

Second, this constraint indicates that the value written into a structural
feature must be of the type that defines the feature, but that's silly.
The value should at least be of the type *of* the feature, not the type
*featuring* the feature.

So, I would say that this is an issue for the RTF, and the constraint should
be formulated thus:

self.value.type.conformsTo(self.structuralFeature.type)

This would allow Student instances to be written into a structural feature
of type Person.

Cheers,

Christian


Krzysztof Kaczmarski wrote:

> Hi All,
>
> I found the following constraint on InputPin's value
>
> self.value.type = self.structuralFeature.featuringClassifier
>
> in the WriteStructuralFeatureAction which is used in other specialized
> actions (AddStructualFeatureValueAction). The question is, does this
> constraint allow to assign a value of a specialized type to a more
> general property type?
> Like to put a Student object in a property of Person type?
> If such an assignment is not allowed, what is the reason?
>
> Thanks for any suggestions,
> Krzysztof
Re: AddStructuralFeatureValue constraint [message #625982 is a reply to message #476903] Sat, 02 February 2008 07:14 Go to previous message
Krzysztof Kaczmarski is currently offline Krzysztof KaczmarskiFriend
Messages: 88
Registered: July 2009
Member
Thanks, Christian.

What is the procedure of correcting this problem? Is there any way I
can help?

Cheers,
Krzysztof


Christian W. Damus wrote:
> Hi, Krzysztof,
>
> This constraint doesn't make sense to me.
>
> Firstly, the OCL expression is ill-formed: featuringClassifier is a
> multi-valued feature, but type is scalar.
>
> Second, this constraint indicates that the value written into a structural
> feature must be of the type that defines the feature, but that's silly.
> The value should at least be of the type *of* the feature, not the type
> *featuring* the feature.
>
> So, I would say that this is an issue for the RTF, and the constraint should
> be formulated thus:
>
> self.value.type.conformsTo(self.structuralFeature.type)
>
> This would allow Student instances to be written into a structural feature
> of type Person.
>
> Cheers,
>
> Christian
>
>
> Krzysztof Kaczmarski wrote:
>
>> Hi All,
>>
>> I found the following constraint on InputPin's value
>>
>> self.value.type = self.structuralFeature.featuringClassifier
>>
>> in the WriteStructuralFeatureAction which is used in other specialized
>> actions (AddStructualFeatureValueAction). The question is, does this
>> constraint allow to assign a value of a specialized type to a more
>> general property type?
>> Like to put a Student object in a property of Person type?
>> If such an assignment is not allowed, what is the reason?
>>
>> Thanks for any suggestions,
>> Krzysztof
>
Re: AddStructuralFeatureValue constraint [message #625984 is a reply to message #476904] Mon, 04 February 2008 12:26 Go to previous message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Hi, K,

You can start by searching the list of issues under consideration by the UML
2.2 RTF (revision task force) to see whether this problem has already been
raised (and possibly resolved):

http://www.omg.org/issues/uml2-rtf.html

If this appears to be a new issue, you can report it to OMG via the
issues-reporting form:

http://www.omg.org/technology/agreement.htm

Cheers,

Christian


Krzysztof Kaczmarski wrote:

> Thanks, Christian.
>
> What is the procedure of correcting this problem? Is there any way I
> can help?
>
> Cheers,
> Krzysztof
>
>
> Christian W. Damus wrote:
>> Hi, Krzysztof,
>>
>> This constraint doesn't make sense to me.
>>
>> Firstly, the OCL expression is ill-formed: featuringClassifier is a
>> multi-valued feature, but type is scalar.
>>
>> Second, this constraint indicates that the value written into a
>> structural feature must be of the type that defines the feature, but
>> that's silly. The value should at least be of the type *of* the feature,
>> not the type *featuring* the feature.
>>
>> So, I would say that this is an issue for the RTF, and the constraint
>> should be formulated thus:
>>
>> self.value.type.conformsTo(self.structuralFeature.type)
>>
>> This would allow Student instances to be written into a structural
>> feature of type Person.
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Krzysztof Kaczmarski wrote:
>>
>>> Hi All,
>>>
>>> I found the following constraint on InputPin's value
>>>
>>> self.value.type = self.structuralFeature.featuringClassifier
>>>
>>> in the WriteStructuralFeatureAction which is used in other specialized
>>> actions (AddStructualFeatureValueAction). The question is, does this
>>> constraint allow to assign a value of a specialized type to a more
>>> general property type?
>>> Like to put a Student object in a property of Person type?
>>> If such an assignment is not allowed, what is the reason?
>>>
>>> Thanks for any suggestions,
>>> Krzysztof
>>
Re: AddStructuralFeatureValue constraint [message #625985 is a reply to message #476906] Mon, 04 February 2008 12:31 Go to previous message
Eclipse UserFriend
Originally posted by: cdamus.ca.ibm.com

Sorry, Krzysztof,

I don't seem to have pasted your complete name. I didn't mean to assume
such familiarity.

Christian


Christian W. Damus wrote:

> Hi, K,
>
> You can start by searching the list of issues under consideration by the
> UML 2.2 RTF (revision task force) to see whether this problem has already
> been raised (and possibly resolved):
>
> http://www.omg.org/issues/uml2-rtf.html
>
> If this appears to be a new issue, you can report it to OMG via the
> issues-reporting form:
>
> http://www.omg.org/technology/agreement.htm
>
> Cheers,
>
> Christian
>
>
> Krzysztof Kaczmarski wrote:
>
>> Thanks, Christian.
>>
>> What is the procedure of correcting this problem? Is there any way I
>> can help?
>>
>> Cheers,
>> Krzysztof
>>
>>
>> Christian W. Damus wrote:
>>> Hi, Krzysztof,
>>>
>>> This constraint doesn't make sense to me.
>>>
>>> Firstly, the OCL expression is ill-formed: featuringClassifier is a
>>> multi-valued feature, but type is scalar.
>>>
>>> Second, this constraint indicates that the value written into a
>>> structural feature must be of the type that defines the feature, but
>>> that's silly. The value should at least be of the type *of* the feature,
>>> not the type *featuring* the feature.
>>>
>>> So, I would say that this is an issue for the RTF, and the constraint
>>> should be formulated thus:
>>>
>>> self.value.type.conformsTo(self.structuralFeature.type)
>>>
>>> This would allow Student instances to be written into a structural
>>> feature of type Person.
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>>
>>> Krzysztof Kaczmarski wrote:
>>>
>>>> Hi All,
>>>>
>>>> I found the following constraint on InputPin's value
>>>>
>>>> self.value.type = self.structuralFeature.featuringClassifier
>>>>
>>>> in the WriteStructuralFeatureAction which is used in other specialized
>>>> actions (AddStructualFeatureValueAction). The question is, does this
>>>> constraint allow to assign a value of a specialized type to a more
>>>> general property type?
>>>> Like to put a Student object in a property of Person type?
>>>> If such an assignment is not allowed, what is the reason?
>>>>
>>>> Thanks for any suggestions,
>>>> Krzysztof
>>>
Re: AddStructuralFeatureValue constraint [message #625986 is a reply to message #476907] Mon, 04 February 2008 17:51 Go to previous message
james bruck is currently offline james bruckFriend
Messages: 1724
Registered: July 2009
Senior Member
Hi, Krzysztof

I could raise that on your behalf if you wish.
(The OMG process might be a bit cumbersome if you want to raise only one
issue).

....special thanks to "big-C" for confirming this as an issue ... ;-)

Cheers,

- J.


"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:fo70jh$8fd$3@build.eclipse.org...
> Sorry, Krzysztof,
>
> I don't seem to have pasted your complete name. I didn't mean to assume
> such familiarity.
>
> Christian
>
>
> Christian W. Damus wrote:
>
>> Hi, K,
>>
>> You can start by searching the list of issues under consideration by the
>> UML 2.2 RTF (revision task force) to see whether this problem has already
>> been raised (and possibly resolved):
>>
>> http://www.omg.org/issues/uml2-rtf.html
>>
>> If this appears to be a new issue, you can report it to OMG via the
>> issues-reporting form:
>>
>> http://www.omg.org/technology/agreement.htm
>>
>> Cheers,
>>
>> Christian
>>
>>
>> Krzysztof Kaczmarski wrote:
>>
>>> Thanks, Christian.
>>>
>>> What is the procedure of correcting this problem? Is there any way I
>>> can help?
>>>
>>> Cheers,
>>> Krzysztof
>>>
>>>
>>> Christian W. Damus wrote:
>>>> Hi, Krzysztof,
>>>>
>>>> This constraint doesn't make sense to me.
>>>>
>>>> Firstly, the OCL expression is ill-formed: featuringClassifier is a
>>>> multi-valued feature, but type is scalar.
>>>>
>>>> Second, this constraint indicates that the value written into a
>>>> structural feature must be of the type that defines the feature, but
>>>> that's silly. The value should at least be of the type *of* the
>>>> feature,
>>>> not the type *featuring* the feature.
>>>>
>>>> So, I would say that this is an issue for the RTF, and the constraint
>>>> should be formulated thus:
>>>>
>>>> self.value.type.conformsTo(self.structuralFeature.type)
>>>>
>>>> This would allow Student instances to be written into a structural
>>>> feature of type Person.
>>>>
>>>> Cheers,
>>>>
>>>> Christian
>>>>
>>>>
>>>> Krzysztof Kaczmarski wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I found the following constraint on InputPin's value
>>>>>
>>>>> self.value.type = self.structuralFeature.featuringClassifier
>>>>>
>>>>> in the WriteStructuralFeatureAction which is used in other specialized
>>>>> actions (AddStructualFeatureValueAction). The question is, does this
>>>>> constraint allow to assign a value of a specialized type to a more
>>>>> general property type?
>>>>> Like to put a Student object in a property of Person type?
>>>>> If such an assignment is not allowed, what is the reason?
>>>>>
>>>>> Thanks for any suggestions,
>>>>> Krzysztof
>>>>
>
Re: AddStructuralFeatureValue constraint [message #625987 is a reply to message #476908] Tue, 05 February 2008 12:59 Go to previous message
Krzysztof Kaczmarski is currently offline Krzysztof KaczmarskiFriend
Messages: 88
Registered: July 2009
Member
Yes, it really is. How can I know all those informations about
document if they are not explicitly stated in the first page?
What should be taken for "Document #"?

James, If it is not a problem. Please fill free to rise this issue.
It would be great if Polish-Japanese Institute of Information
Technology could be present somewhere in the description.

Cheers,
Krzysztof



James Bruck wrote:
> Hi, Krzysztof
>
> I could raise that on your behalf if you wish.
> (The OMG process might be a bit cumbersome if you want to raise only one
> issue).
>
> ...special thanks to "big-C" for confirming this as an issue ... ;-)
>
> Cheers,
>
> - J.
>
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:fo70jh$8fd$3@build.eclipse.org...
>> Sorry, Krzysztof,
>>
>> I don't seem to have pasted your complete name. I didn't mean to assume
>> such familiarity.
>>
>> Christian
>>
>>
>> Christian W. Damus wrote:
>>
>>> Hi, K,
>>>
>>> You can start by searching the list of issues under consideration by the
>>> UML 2.2 RTF (revision task force) to see whether this problem has already
>>> been raised (and possibly resolved):
>>>
>>> http://www.omg.org/issues/uml2-rtf.html
>>>
>>> If this appears to be a new issue, you can report it to OMG via the
>>> issues-reporting form:
>>>
>>> http://www.omg.org/technology/agreement.htm
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>>
>>> Krzysztof Kaczmarski wrote:
>>>
>>>> Thanks, Christian.
>>>>
>>>> What is the procedure of correcting this problem? Is there any way I
>>>> can help?
>>>>
>>>> Cheers,
>>>> Krzysztof
>>>>
>>>>
>>>> Christian W. Damus wrote:
>>>>> Hi, Krzysztof,
>>>>>
>>>>> This constraint doesn't make sense to me.
>>>>>
>>>>> Firstly, the OCL expression is ill-formed: featuringClassifier is a
>>>>> multi-valued feature, but type is scalar.
>>>>>
>>>>> Second, this constraint indicates that the value written into a
>>>>> structural feature must be of the type that defines the feature, but
>>>>> that's silly. The value should at least be of the type *of* the
>>>>> feature,
>>>>> not the type *featuring* the feature.
>>>>>
>>>>> So, I would say that this is an issue for the RTF, and the constraint
>>>>> should be formulated thus:
>>>>>
>>>>> self.value.type.conformsTo(self.structuralFeature.type)
>>>>>
>>>>> This would allow Student instances to be written into a structural
>>>>> feature of type Person.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> Krzysztof Kaczmarski wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I found the following constraint on InputPin's value
>>>>>>
>>>>>> self.value.type = self.structuralFeature.featuringClassifier
>>>>>>
>>>>>> in the WriteStructuralFeatureAction which is used in other specialized
>>>>>> actions (AddStructualFeatureValueAction). The question is, does this
>>>>>> constraint allow to assign a value of a specialized type to a more
>>>>>> general property type?
>>>>>> Like to put a Student object in a property of Person type?
>>>>>> If such an assignment is not allowed, what is the reason?
>>>>>>
>>>>>> Thanks for any suggestions,
>>>>>> Krzysztof
>
>
Re: AddStructuralFeatureValue constraint [message #625988 is a reply to message #476908] Tue, 05 February 2008 13:01 Go to previous message
Krzysztof Kaczmarski is currently offline Krzysztof KaczmarskiFriend
Messages: 88
Registered: July 2009
Member
Oh, and I checked that there are no issues like this among already
submitted. It looks to be a new one.

KK

James Bruck wrote:
> Hi, Krzysztof
>
> I could raise that on your behalf if you wish.
> (The OMG process might be a bit cumbersome if you want to raise only one
> issue).
>
> ...special thanks to "big-C" for confirming this as an issue ... ;-)
>
> Cheers,
>
> - J.
>
>
> "Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
> news:fo70jh$8fd$3@build.eclipse.org...
>> Sorry, Krzysztof,
>>
>> I don't seem to have pasted your complete name. I didn't mean to assume
>> such familiarity.
>>
>> Christian
>>
>>
>> Christian W. Damus wrote:
>>
>>> Hi, K,
>>>
>>> You can start by searching the list of issues under consideration by the
>>> UML 2.2 RTF (revision task force) to see whether this problem has already
>>> been raised (and possibly resolved):
>>>
>>> http://www.omg.org/issues/uml2-rtf.html
>>>
>>> If this appears to be a new issue, you can report it to OMG via the
>>> issues-reporting form:
>>>
>>> http://www.omg.org/technology/agreement.htm
>>>
>>> Cheers,
>>>
>>> Christian
>>>
>>>
>>> Krzysztof Kaczmarski wrote:
>>>
>>>> Thanks, Christian.
>>>>
>>>> What is the procedure of correcting this problem? Is there any way I
>>>> can help?
>>>>
>>>> Cheers,
>>>> Krzysztof
>>>>
>>>>
>>>> Christian W. Damus wrote:
>>>>> Hi, Krzysztof,
>>>>>
>>>>> This constraint doesn't make sense to me.
>>>>>
>>>>> Firstly, the OCL expression is ill-formed: featuringClassifier is a
>>>>> multi-valued feature, but type is scalar.
>>>>>
>>>>> Second, this constraint indicates that the value written into a
>>>>> structural feature must be of the type that defines the feature, but
>>>>> that's silly. The value should at least be of the type *of* the
>>>>> feature,
>>>>> not the type *featuring* the feature.
>>>>>
>>>>> So, I would say that this is an issue for the RTF, and the constraint
>>>>> should be formulated thus:
>>>>>
>>>>> self.value.type.conformsTo(self.structuralFeature.type)
>>>>>
>>>>> This would allow Student instances to be written into a structural
>>>>> feature of type Person.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> Krzysztof Kaczmarski wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I found the following constraint on InputPin's value
>>>>>>
>>>>>> self.value.type = self.structuralFeature.featuringClassifier
>>>>>>
>>>>>> in the WriteStructuralFeatureAction which is used in other specialized
>>>>>> actions (AddStructualFeatureValueAction). The question is, does this
>>>>>> constraint allow to assign a value of a specialized type to a more
>>>>>> general property type?
>>>>>> Like to put a Student object in a property of Person type?
>>>>>> If such an assignment is not allowed, what is the reason?
>>>>>>
>>>>>> Thanks for any suggestions,
>>>>>> Krzysztof
>
>
Previous Topic:Componen element as a lifeline?
Next Topic:[Announce] MDT UML2 2.2.0 I200802052200 is available
Goto Forum:
  


Current Time: Fri Mar 29 05:11:56 GMT 2024

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

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

Back to the top