Home » Modeling » UML2 » AddStructuralFeatureValue constraint
|
Re: AddStructuralFeatureValue constraint [message #476903 is a reply to message #476902] |
Fri, 01 February 2008 13:02 |
Eclipse User |
|
|
|
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 |
Krzysztof Kaczmarski 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 |
Eclipse User |
|
|
|
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 |
Eclipse User |
|
|
|
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 |
james bruck 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 |
Krzysztof Kaczmarski 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 |
Krzysztof Kaczmarski 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 |
Eclipse User |
|
|
|
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 |
Krzysztof Kaczmarski 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 |
Eclipse User |
|
|
|
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 |
Eclipse User |
|
|
|
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 |
james bruck 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 |
Krzysztof Kaczmarski 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 |
Krzysztof Kaczmarski 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
>
>
|
|
|
Goto Forum:
Current Time: Tue Sep 24 04:04:36 GMT 2024
Powered by FUDForum. Page generated in 0.03375 seconds
|