Home » Modeling » UML2 » Property redefinitions
| Property redefinitions [message #476248] |
Tue, 02 October 2007 02:19  |
 Dave Carlson
Messages: 402
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0006_01C80468.5AEE84B0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
I have a question about use of Property redefinitions. I interpret the =
following quote from the UML 2.1.1 spec to mean that when a subclass =
includes a property whose name is equal to a property in one of its =
general classes, then it should be treated as a redefinition even if =
there is no explicit redefinition between those properties in the model.
"All redefinitions should be made explicit with the use of a =
{redefines <x>} property string. Matching features in subclasses without =
an explicit redefinition result in a redefinition that need not be shown =
in the notation. Redefinition prevents inheritance of a redefined =
element into the redefinition context thereby making the name of the =
redefined element available for reuse, either for the redefining =
element, or for some other."
If that's correct, then should the model validation throw an error if =
the subclass property type or multiplicity is not compatible with the =
implicitly redefined property? I've done some testing in RSM 7 and if I =
create an explicit property redefinition, then I do get a validation =
error for incompatible type or multiplicity. But no error without the =
redefinition. I expect that it would be computationally expensive to =
check for matching properties of *every* property during validation. =
But this constraint from the spec does not appear to be enforced.
Do I have the correct interpretation of the spec?
Also, it is very difficult to create property redefinitions in RSM 7 =
(using the UML properties dialog, not the properties tabs), and without =
the {redefines xxx} notation in a diagram it's nearly impossible to know =
when a refinition has been added.
Thanks,
Dave Carlson
------=_NextPart_000_0006_01C80468.5AEE84B0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I have a question about use of Property =
redefinitions. I interpret the following quote from the UML 2.1.1 =
spec=20
to mean that when a subclass includes a property whose name is =
equal to a=20
property in one of its general classes, then it should be treated as a=20
redefinition even if there is no explicit redefinition between those =
properties=20
in the model.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV>
<P><FONT face=3DArial size=3D2>"All redefinitions should be made =
explicit with the=20
use of a {redefines <x>} property string. Matching features in=20
subclasses without an explicit redefinition result in a redefinition =
that need=20
not be shown in the notation. Redefinition prevents inheritance of a =
redefined=20
element into the redefinition context thereby making the name of the =
redefined=20
element available for reuse, either for the redefining element, or for =
some=20
other."</FONT></P></DIV></BLOCKQUOTE>
<P dir=3Dltr><FONT face=3DArial size=3D2>If that's correct, then should =
the=20
model validation throw an error if the subclass property type or=20
multiplicity is not compatible with the implicitly redefined =
property? =20
I've done some testing in RSM 7 and if I create an explicit property=20
redefinition, then I do get a validation error for incompatible =
type or=20
multiplicity. But no error without the redefinition. I =
expect that=20
it would be computationally expensive to check for matching properties =
of=20
*every* property during validation. But this constraint from the =
spec does=20
not appear to be enforced.</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Do I have the correct =
interpretation of the=20
spec?</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Also, it is very difficult to =
create property=20
redefinitions in RSM 7 (using the UML properties dialog, not the =
properties=20
tabs), and without the {redefines xxx} notation in a diagram it's =
nearly=20
impossible to know when a refinition has been added.</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Thanks,</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2> Dave =
Carlson</FONT></P></BODY></HTML>
------=_NextPart_000_0006_01C80468.5AEE84B0--
|
|
|
| Re: Property redefinitions [message #476256 is a reply to message #476248] |
Wed, 03 October 2007 14:10  |
james bruck
Messages: 1724
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0043_01C805A5.B0F75100
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Dave,
I think your interpretation is what is implied by the paragraph but it =
seems a little impractical and expensive to compute as you mention. =20
Also there doesn't seem to be an explicit constraint listed in the =
constraints section that enforces this paragraph.
RSA and opensource UML basically only enforce explicit constraints.
I will ask the UML guru of that section to clarify and I will get back =
to you if I receive additional info.
You might want to open up a bug on RSA to request that it be more user =
friendly such that if a user creates a property with the same name as an =
inherited one then an explicit redefinition is made ( an automatic =
semantic procedure ). RSA already has such semantic procedures to help =
users out.
In terms of the ease of use of RSA, you might want to experiment with =
visualizing properties on composite structure diagrams. Inherited =
properties are marked differently and you can bring up a context menu to =
redefine them ( right click on them ). State machines have some =
capabilities in that regard also.
I'm not sure of the (minor) version of RSA you have but there have been =
some recent improvements in that area.
(You might want to raise usability issues against RSA... they take =
customer defects seriously.)
- James.
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message =
news:fds9ra$vk1$1@build.eclipse.org...
Hi,
I have a question about use of Property redefinitions. I interpret =
the following quote from the UML 2.1.1 spec to mean that when a subclass =
includes a property whose name is equal to a property in one of its =
general classes, then it should be treated as a redefinition even if =
there is no explicit redefinition between those properties in the model.
"All redefinitions should be made explicit with the use of a =
{redefines <x>} property string. Matching features in subclasses without =
an explicit redefinition result in a redefinition that need not be shown =
in the notation. Redefinition prevents inheritance of a redefined =
element into the redefinition context thereby making the name of the =
redefined element available for reuse, either for the redefining =
element, or for some other."
If that's correct, then should the model validation throw an error if =
the subclass property type or multiplicity is not compatible with the =
implicitly redefined property? I've done some testing in RSM 7 and if I =
create an explicit property redefinition, then I do get a validation =
error for incompatible type or multiplicity. But no error without the =
redefinition. I expect that it would be computationally expensive to =
check for matching properties of *every* property during validation. =
But this constraint from the spec does not appear to be enforced.
Do I have the correct interpretation of the spec?
Also, it is very difficult to create property redefinitions in RSM 7 =
(using the UML properties dialog, not the properties tabs), and without =
the {redefines xxx} notation in a diagram it's nearly impossible to know =
when a refinition has been added.
Thanks,
Dave Carlson
------=_NextPart_000_0043_01C805A5.B0F75100
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1589" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I think your interpretation is what is =
implied by=20
the paragraph but it seems a little impractical and expensive to compute =
as you=20
mention. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Also there doesn't seem to be an =
explicit=20
constraint listed in the constraints section that enforces this=20
paragraph.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>RSA and opensource UML basically only =
enforce=20
explicit constraints.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I will ask the UML guru of that =
section to=20
clarify and I will get back to you if I receive additional =
info.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>You might want to open up a bug on RSA =
to request=20
that it be more user friendly such that if a user creates a =
property with=20
the same name as an inherited one then an explicit redefinition is made =
( an=20
automatic semantic procedure ). RSA already has such =
semantic=20
procedures to help users out.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>In terms of the ease of use of RSA, you =
might want=20
to experiment with visualizing properties on composite structure=20
diagrams. Inherited properties are marked differently and =
you can=20
bring up a context menu to redefine them ( right click on them =
). =20
State machines have some capabilities in that regard also.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm not sure of the (minor) version of =
RSA you have=20
but there have been some recent improvements in that area.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>(You might want to raise usability =
issues against=20
RSA... they take customer defects seriously.)</FONT></DIV></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>- James.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Dave Carlson" <<A=20
=
href=3D"mailto:dcarlson@xmlmodeling.com">dcarlson@xmlmodeling.com</A>>=
wrote=20
in message <A=20
=
href=3D"news:fds9ra$vk1$1@build.eclipse.org">news:fds9ra$vk1$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I have a question about use of =
Property=20
redefinitions. I interpret the following quote from the UML =
2.1.1 spec=20
to mean that when a subclass includes a property whose name is =
equal to a=20
property in one of its general classes, then it should be treated as a =
redefinition even if there is no explicit redefinition between those=20
properties in the model.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV>
<P><FONT face=3DArial size=3D2>"All redefinitions should be made =
explicit with=20
the use of a {redefines <x>} property string. Matching =
features in=20
subclasses without an explicit redefinition result in a redefinition =
that=20
need not be shown in the notation. Redefinition prevents inheritance =
of a=20
redefined element into the redefinition context thereby making the =
name of=20
the redefined element available for reuse, either for the redefining =
element, or for some other."</FONT></P></DIV></BLOCKQUOTE>
<P dir=3Dltr><FONT face=3DArial size=3D2>If that's correct, then =
should the=20
model validation throw an error if the subclass property type or=20
multiplicity is not compatible with the implicitly redefined =
property? =20
I've done some testing in RSM 7 and if I create an explicit property=20
redefinition, then I do get a validation error for incompatible =
type or=20
multiplicity. But no error without the redefinition. I =
expect that=20
it would be computationally expensive to check for matching properties =
of=20
*every* property during validation. But this constraint from the =
spec=20
does not appear to be enforced.</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Do I have the correct =
interpretation of the=20
spec?</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Also, it is very difficult to =
create=20
property redefinitions in RSM 7 (using the UML properties dialog, not =
the=20
properties tabs), and without the {redefines xxx} notation in a=20
diagram it's nearly impossible to know when a refinition has been =
added.</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Thanks,</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2> Dave=20
Carlson</FONT></P></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0043_01C805A5.B0F75100--
|
|
|
| Re: Property redefinitions [message #476259 is a reply to message #476256] |
Wed, 03 October 2007 16:27 |
Dave Carlson
Messages: 402
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0016_01C805A7.F52CCB50
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi James,
Thanks very much for your detailed response. I am still running RSM =
7.0.0.2 and will update today to the latest revision, thanks for the =
tip. And I will take a careful look at composite structure diagrams. =
This is for work I am doing on large healthcare domain models, where the =
need to specialize and redefine general semantic domain models is a very =
important part of their methodology.
Another related question. In UML2, it seems that there is no way to =
remove or prohibit a property in a specialized class, except maybe by =
adding a Constraint to the subclass. This is also an important =
requirement for the healthcare models, and currently the classes are =
cloned and modified in order to remove properties. I am trying to make =
this process more rigorous. In UML 1.3 (e.g., in Rose), I could change =
a subclass property multiplicity to [0..0], but the UML2 spec prohibits =
an upper bound < 0. Any ideas here?
Thanks!
Dave
"James Bruck" <jbruck@ca.ibm.com> wrote in message =
news:fe07ti$kt0$2@build.eclipse.org...
Hi Dave,
I think your interpretation is what is implied by the paragraph but it =
seems a little impractical and expensive to compute as you mention. =20
Also there doesn't seem to be an explicit constraint listed in the =
constraints section that enforces this paragraph.
RSA and opensource UML basically only enforce explicit constraints.
I will ask the UML guru of that section to clarify and I will get back =
to you if I receive additional info.
You might want to open up a bug on RSA to request that it be more user =
friendly such that if a user creates a property with the same name as an =
inherited one then an explicit redefinition is made ( an automatic =
semantic procedure ). RSA already has such semantic procedures to help =
users out.
In terms of the ease of use of RSA, you might want to experiment with =
visualizing properties on composite structure diagrams. Inherited =
properties are marked differently and you can bring up a context menu to =
redefine them ( right click on them ). State machines have some =
capabilities in that regard also.
I'm not sure of the (minor) version of RSA you have but there have =
been some recent improvements in that area.
(You might want to raise usability issues against RSA... they take =
customer defects seriously.)
------=_NextPart_000_0016_01C805A7.F52CCB50
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi James,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks very much for your detailed =
response. =20
I am still running RSM 7.0.0.2 and will update today to the latest =
revision,=20
thanks for the tip. And I will take a careful look at composite =
structure=20
diagrams. This is for work I am doing on large healthcare =
domain=20
models, where the need to specialize and redefine general semantic =
domain models=20
is a very important part of their methodology.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Another related question. In =
UML2, it seems=20
that there is no way to remove or prohibit a property in a specialized =
class,=20
except maybe by adding a Constraint to the subclass. This is also =
an=20
important requirement for the healthcare models, and currently the =
classes are=20
cloned and modified in order to remove properties. I am trying to =
make=20
this process more rigorous. In UML 1.3 (e.g., in Rose), I could =
change a=20
subclass property multiplicity to [0..0], but the UML2 spec =
prohibits an=20
upper bound < 0. Any ideas here?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> Dave</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"James Bruck" <<A=20
href=3D"mailto:jbruck@ca.ibm.com">jbruck@ca.ibm.com</A>> wrote in =
message <A=20
=
href=3D"news:fe07ti$kt0$2@build.eclipse.org">news:fe07ti$kt0$2@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I think your interpretation is what =
is implied by=20
the paragraph but it seems a little impractical and expensive to =
compute as=20
you mention. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Also there doesn't seem to be an =
explicit=20
constraint listed in the constraints section that enforces this=20
paragraph.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>RSA and opensource UML basically only =
enforce=20
explicit constraints.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I will ask the UML guru of that =
section to=20
clarify and I will get back to you if I receive additional =
info.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>You might want to open up a bug on =
RSA to request=20
that it be more user friendly such that if a user creates a =
property with=20
the same name as an inherited one then an explicit redefinition is =
made ( an=20
automatic semantic procedure ). RSA already has such =
semantic=20
procedures to help users out.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>In terms of the ease of use of RSA, =
you might=20
want to experiment with visualizing properties on composite structure=20
diagrams. Inherited properties are marked differently and =
you can=20
bring up a context menu to redefine them ( right click on them =
). =20
State machines have some capabilities in that regard =
also.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm not sure of the (minor) version =
of RSA you=20
have but there have been some recent improvements in that =
area.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>(You might want to raise usability =
issues against=20
RSA... they take customer defects seriously.)</FONT></DIV></DIV>
<DIV><FONT face=3DArial =
size=3D2></FONT> </DIV></BLOCKQUOTE></BODY></HTML >
------=_NextPart_000_0016_01C805A7.F52CCB50--
|
|
|
| Re: Property redefinitions [message #476261 is a reply to message #476259] |
Wed, 03 October 2007 17:46 |
james bruck
Messages: 1724
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0012_01C805C3.C3245940
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Dave,
Have you tried setting the RedefinableElement.setIsLeaf() to true in the =
more generalized context for those elements you don't want specialized?
From the spec ...=20
Indicates whether it is possible to further specialize a =
RedefinableElement. If the value is true, then it is not possible to =
further specialize the RedefinableElement. Default value is false.=20
- James.
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message =
news:fe0ft0$1cf$1@build.eclipse.org...
Hi James,
Thanks very much for your detailed response. I am still running RSM =
7.0.0.2 and will update today to the latest revision, thanks for the =
tip. And I will take a careful look at composite structure diagrams. =
This is for work I am doing on large healthcare domain models, where the =
need to specialize and redefine general semantic domain models is a very =
important part of their methodology.
Another related question. In UML2, it seems that there is no way to =
remove or prohibit a property in a specialized class, except maybe by =
adding a Constraint to the subclass. This is also an important =
requirement for the healthcare models, and currently the classes are =
cloned and modified in order to remove properties. I am trying to make =
this process more rigorous. In UML 1.3 (e.g., in Rose), I could change =
a subclass property multiplicity to [0..0], but the UML2 spec prohibits =
an upper bound < 0. Any ideas here?
Thanks!
Dave
"James Bruck" <jbruck@ca.ibm.com> wrote in message =
news:fe07ti$kt0$2@build.eclipse.org...
Hi Dave,
I think your interpretation is what is implied by the paragraph but =
it seems a little impractical and expensive to compute as you mention. =
Also there doesn't seem to be an explicit constraint listed in the =
constraints section that enforces this paragraph.
RSA and opensource UML basically only enforce explicit constraints.
I will ask the UML guru of that section to clarify and I will get =
back to you if I receive additional info.
You might want to open up a bug on RSA to request that it be more =
user friendly such that if a user creates a property with the same name =
as an inherited one then an explicit redefinition is made ( an automatic =
semantic procedure ). RSA already has such semantic procedures to help =
users out.
In terms of the ease of use of RSA, you might want to experiment =
with visualizing properties on composite structure diagrams. Inherited =
properties are marked differently and you can bring up a context menu to =
redefine them ( right click on them ). State machines have some =
capabilities in that regard also.
I'm not sure of the (minor) version of RSA you have but there have =
been some recent improvements in that area.
(You might want to raise usability issues against RSA... they take =
customer defects seriously.)
------=_NextPart_000_0012_01C805C3.C3245940
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1589" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Have you tried setting the=20
RedefinableElement.setIsLeaf() to true in the more generalized context =
for those=20
elements you don't want specialized?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>From the spec ... <FONT size=3D2>
<P>Indicates whether it is possible to further specialize a =
RedefinableElement.=20
If the value is true, then it is not possible to further specialize the=20
RedefinableElement. Default value is </FONT><I><FONT=20
face=3D"Times New Roman,Times New Roman" size=3D2>false</I></FONT><FONT =
size=3D2>.=20
</P></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>- James.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Dave Carlson" <<A=20
=
href=3D"mailto:dcarlson@xmlmodeling.com">dcarlson@xmlmodeling.com</A>>=
wrote=20
in message <A=20
=
href=3D"news:fe0ft0$1cf$1@build.eclipse.org">news:fe0ft0$1cf$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi James,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks very much for your detailed=20
response. I am still running RSM 7.0.0.2 and will update today =
to the=20
latest revision, thanks for the tip. And I will take a careful =
look at=20
composite structure diagrams. This is for work I am doing on=20
large healthcare domain models, where the need to specialize and =
redefine=20
general semantic domain models is a very important part of their=20
methodology.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Another related question. In =
UML2, it seems=20
that there is no way to remove or prohibit a property in a specialized =
class,=20
except maybe by adding a Constraint to the subclass. This is =
also an=20
important requirement for the healthcare models, and currently the =
classes are=20
cloned and modified in order to remove properties. I am trying =
to make=20
this process more rigorous. In UML 1.3 (e.g., in Rose), I could =
change a=20
subclass property multiplicity to [0..0], but the UML2 spec =
prohibits an=20
upper bound < 0. Any ideas here?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> Dave</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"James Bruck" <<A=20
href=3D"mailto:jbruck@ca.ibm.com">jbruck@ca.ibm.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:fe07ti$kt0$2@build.eclipse.org">news:fe07ti$kt0$2@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I think your interpretation is what =
is implied=20
by the paragraph but it seems a little impractical and expensive to =
compute=20
as you mention. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Also there doesn't seem to be an =
explicit=20
constraint listed in the constraints section that enforces this=20
paragraph.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>RSA and opensource UML basically =
only enforce=20
explicit constraints.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I will ask the UML guru of that =
section to=20
clarify and I will get back to you if I receive additional=20
info.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>You might want to open up a bug on =
RSA to=20
request that it be more user friendly such that if a user =
creates a=20
property with the same name as an inherited one then an explicit=20
redefinition is made ( an automatic semantic procedure =
). RSA=20
already has such semantic procedures to help users out.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>In terms of the ease of use of RSA, =
you might=20
want to experiment with visualizing properties on composite =
structure=20
diagrams. Inherited properties are marked differently =
and you=20
can bring up a context menu to redefine them ( right click on them=20
). State machines have some capabilities in that regard=20
also.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm not sure of the (minor) version =
of RSA you=20
have but there have been some recent improvements in that =
area.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>(You might want to raise usability =
issues=20
against RSA... they take customer defects =
seriously.)</FONT></DIV></DIV>
<DIV><FONT face=3DArial=20
size=3D2></FONT> </DIV></BLOCKQUOTE></BLOCKQUOTE ></BODY></HTML>
------=_NextPart_000_0012_01C805C3.C3245940--
|
|
|
| Re: Property redefinitions [message #476263 is a reply to message #476261] |
Wed, 03 October 2007 18:21 |
Dave Carlson
Messages: 402
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_000C_01C805B7.FCF6DCD0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi James,
That does not seem to address the issue we have. We need to prevent an =
inherited property from being used in a subclass, in effect eliminating =
it. This should affect generated artifacts, e.g. Java for the subclass =
would not allow that property to be set, or XSD for the subclass would =
have maxOccurs=3D0 for that element (a pattern sometimes used in XSD =
design).
I interpret setIsLeaf(true) to mean that the subclass cannot change the =
superclass property definition (override its type or multiplicity). We =
do want to redefine it to prevent its use (and hiding it in the subclass =
diagram presentation).
Dave
"James Bruck" <jbruck@ca.ibm.com> wrote in message =
news:fe0kh7$a1d$2@build.eclipse.org...
Hi Dave,
Have you tried setting the RedefinableElement.setIsLeaf() to true in =
the more generalized context for those elements you don't want =
specialized?
From the spec ...=20
Indicates whether it is possible to further specialize a =
RedefinableElement. If the value is true, then it is not possible to =
further specialize the RedefinableElement. Default value is false.=20
------=_NextPart_000_000C_01C805B7.FCF6DCD0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi James,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>That does not seem to address the issue =
we=20
have. We need to prevent an inherited property from being used in =
a=20
subclass, in effect eliminating it. This should affect generated=20
artifacts, e.g. Java for the subclass would not allow that property to =
be set,=20
or XSD for the subclass would have maxOccurs=3D0 for that element (a =
pattern=20
sometimes used in XSD design).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I interpret setIsLeaf(true) to mean =
that the=20
subclass cannot change the superclass property definition (override its =
type or=20
multiplicity). We do want to redefine it to prevent its use (and =
hiding it=20
in the subclass diagram presentation).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Dave</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"James Bruck" <<A=20
href=3D"mailto:jbruck@ca.ibm.com">jbruck@ca.ibm.com</A>> wrote in =
message <A=20
=
href=3D"news:fe0kh7$a1d$2@build.eclipse.org">news:fe0kh7$a1d$2@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Have you tried setting the=20
RedefinableElement.setIsLeaf() to true in the more generalized context =
for=20
those elements you don't want specialized?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>From the spec ... <FONT size=3D2>
<P>Indicates whether it is possible to further specialize a=20
RedefinableElement. If the value is true, then it is not possible to =
further=20
specialize the RedefinableElement. Default value is </FONT><I><FONT=20
face=3D"Times New Roman,Times New Roman" =
size=3D2>false</I></FONT><FONT size=3D2>.=20
</P></FONT></FONT></DIV></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_000C_01C805B7.FCF6DCD0--
|
|
|
| Re: Property redefinitions [message #476265 is a reply to message #476263] |
Thu, 04 October 2007 01:36 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_02AD_01C80605.6FD348E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Dave,
No, there's no concept of "exclusions" in UML, i.e. redefining an =
element such that it does not appear in the redefining context.
Kenn
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message =
news:fe0mk6$s7b$1@build.eclipse.org...
Hi James,
That does not seem to address the issue we have. We need to prevent =
an inherited property from being used in a subclass, in effect =
eliminating it. This should affect generated artifacts, e.g. Java for =
the subclass would not allow that property to be set, or XSD for the =
subclass would have maxOccurs=3D0 for that element (a pattern sometimes =
used in XSD design).
I interpret setIsLeaf(true) to mean that the subclass cannot change =
the superclass property definition (override its type or multiplicity). =
We do want to redefine it to prevent its use (and hiding it in the =
subclass diagram presentation).
Dave
"James Bruck" <jbruck@ca.ibm.com> wrote in message =
news:fe0kh7$a1d$2@build.eclipse.org...
Hi Dave,
Have you tried setting the RedefinableElement.setIsLeaf() to true in =
the more generalized context for those elements you don't want =
specialized?
From the spec ...=20
Indicates whether it is possible to further specialize a =
RedefinableElement. If the value is true, then it is not possible to =
further specialize the RedefinableElement. Default value is false.=20
------=_NextPart_000_02AD_01C80605.6FD348E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16481" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>No, there's no concept of "exclusions" =
in UML, i.e.=20
redefining an element such that it does not appear in the redefining=20
context.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Kenn</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Dave Carlson" <<A=20
=
href=3D"mailto:dcarlson@xmlmodeling.com">dcarlson@xmlmodeling.com</A>>=
wrote=20
in message <A=20
=
href=3D"news:fe0mk6$s7b$1@build.eclipse.org">news:fe0mk6$s7b$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi James,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>That does not seem to address the =
issue we=20
have. We need to prevent an inherited property from being used =
in a=20
subclass, in effect eliminating it. This should affect generated =
artifacts, e.g. Java for the subclass would not allow that property to =
be set,=20
or XSD for the subclass would have maxOccurs=3D0 for that element (a =
pattern=20
sometimes used in XSD design).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I interpret setIsLeaf(true) to mean =
that the=20
subclass cannot change the superclass property definition (override =
its type=20
or multiplicity). We do want to redefine it to prevent its use =
(and=20
hiding it in the subclass diagram presentation).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Dave</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"James Bruck" <<A=20
href=3D"mailto:jbruck@ca.ibm.com">jbruck@ca.ibm.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:fe0kh7$a1d$2@build.eclipse.org">news:fe0kh7$a1d$2@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Have you tried setting the=20
RedefinableElement.setIsLeaf() to true in the more generalized =
context for=20
those elements you don't want specialized?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>From the spec ... <FONT size=3D2>
<P>Indicates whether it is possible to further specialize a=20
RedefinableElement. If the value is true, then it is not possible to =
further=20
specialize the RedefinableElement. Default value is </FONT><I><FONT=20
face=3D"Times New Roman,Times New Roman" =
size=3D2>false</I></FONT><FONT size=3D2>.=20
</P></FONT></FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY ></HTML>
------=_NextPart_000_02AD_01C80605.6FD348E0--
|
|
|
| Re: Property redefinitions [message #476267 is a reply to message #476265] |
Thu, 04 October 2007 15:28 |
Dave Carlson
Messages: 402
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0010_01C80668.E7DEC180
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Kenn,
That was my reading of the UML spec, but I wanted to confirm that I was =
not overlooking something. Thanks.
Dave
"Kenn Hussey" <Kenn.Hussey@embarcadero.com> wrote in message =
news:fe1g2m$237$1@build.eclipse.org...
Dave,
No, there's no concept of "exclusions" in UML, i.e. redefining an =
element such that it does not appear in the redefining context.
Kenn
------=_NextPart_000_0010_01C80668.E7DEC180
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Kenn,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>That was my reading of the UML spec, =
but I wanted=20
to confirm that I was not overlooking something. =
Thanks.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Dave</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Kenn Hussey" <<A=20
=
href=3D"mailto:Kenn.Hussey@embarcadero.com">Kenn.Hussey@embarcadero.com</=
A>>=20
wrote in message <A=20
=
href=3D"news:fe1g2m$237$1@build.eclipse.org">news:fe1g2m$237$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>No, there's no concept of =
"exclusions" in UML,=20
i.e. redefining an element such that it does not appear in the =
redefining=20
context.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial =
size=3D2>Kenn</FONT></DIV></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0010_01C80668.E7DEC180--
|
|
|
| Re: Property redefinitions [message #476353 is a reply to message #476256] |
Tue, 09 October 2007 17:49 |
james bruck
Messages: 1724
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0054_01C80A7B.2A974130
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
This is what Bran Selic (OMG Chair) has answered...
----------------------------------------------------
This should be clarified in the spec. It is unclear and also includes at =
least one spelling mistake. Alternatively, we should ban implicit =
redefinitions and flag them as simple name conflicts.
Two features of the same kind defined in a class and a superclass (i.e., =
they are both either structural features or behavioral features) does =
indeed imply a redefinition and, therefore, must conform to the =
compatibility constraint on redefinitions. Therefore, the tool should =
indeed flag an error in case of conflicting redefinitions.
"James Bruck" <jbruck@ca.ibm.com> wrote in message =
news:fe07ti$kt0$2@build.eclipse.org...
Hi Dave,
I think your interpretation is what is implied by the paragraph but it =
seems a little impractical and expensive to compute as you mention. =20
Also there doesn't seem to be an explicit constraint listed in the =
constraints section that enforces this paragraph.
RSA and opensource UML basically only enforce explicit constraints.
I will ask the UML guru of that section to clarify and I will get back =
to you if I receive additional info.
You might want to open up a bug on RSA to request that it be more user =
friendly such that if a user creates a property with the same name as an =
inherited one then an explicit redefinition is made ( an automatic =
semantic procedure ). RSA already has such semantic procedures to help =
users out.
In terms of the ease of use of RSA, you might want to experiment with =
visualizing properties on composite structure diagrams. Inherited =
properties are marked differently and you can bring up a context menu to =
redefine them ( right click on them ). State machines have some =
capabilities in that regard also.
I'm not sure of the (minor) version of RSA you have but there have =
been some recent improvements in that area.
(You might want to raise usability issues against RSA... they take =
customer defects seriously.)
- James.
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message =
news:fds9ra$vk1$1@build.eclipse.org...
Hi,
I have a question about use of Property redefinitions. I interpret =
the following quote from the UML 2.1.1 spec to mean that when a subclass =
includes a property whose name is equal to a property in one of its =
general classes, then it should be treated as a redefinition even if =
there is no explicit redefinition between those properties in the model.
"All redefinitions should be made explicit with the use of a =
{redefines <x>} property string. Matching features in subclasses without =
an explicit redefinition result in a redefinition that need not be shown =
in the notation. Redefinition prevents inheritance of a redefined =
element into the redefinition context thereby making the name of the =
redefined element available for reuse, either for the redefining =
element, or for some other."
If that's correct, then should the model validation throw an error =
if the subclass property type or multiplicity is not compatible with the =
implicitly redefined property? I've done some testing in RSM 7 and if I =
create an explicit property redefinition, then I do get a validation =
error for incompatible type or multiplicity. But no error without the =
redefinition. I expect that it would be computationally expensive to =
check for matching properties of *every* property during validation. =
But this constraint from the spec does not appear to be enforced.
Do I have the correct interpretation of the spec?
Also, it is very difficult to create property redefinitions in RSM 7 =
(using the UML properties dialog, not the properties tabs), and without =
the {redefines xxx} notation in a diagram it's nearly impossible to know =
when a refinition has been added.
Thanks,
Dave Carlson
------=_NextPart_000_0054_01C80A7B.2A974130
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>This is what Bran Selic (OMG Chair) has =
answered...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial=20
size=3D2>---------------------------------------------------- </FONT></DIV=
>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DHelv size=3D2>
<P>This should be clarified in the spec. It is unclear and also includes =
at=20
least one spelling mistake. Alternatively, we should ban implicit =
redefinitions=20
and flag them as simple name conflicts.</P>
<P>Two features <U>of the same kind </U>defined in a class and a =
superclass=20
(i.e., they are both either structural features or behavioral features) =
does=20
indeed imply a redefinition and, therefore, must conform to the =
compatibility=20
constraint on redefinitions. Therefore, the tool should indeed flag an =
error in=20
case of conflicting redefinitions.</P></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"James Bruck" <<A=20
href=3D"mailto:jbruck@ca.ibm.com">jbruck@ca.ibm.com</A>> wrote in =
message <A=20
=
href=3D"news:fe07ti$kt0$2@build.eclipse.org">news:fe07ti$kt0$2@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I think your interpretation is what =
is implied by=20
the paragraph but it seems a little impractical and expensive to =
compute as=20
you mention. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Also there doesn't seem to be an =
explicit=20
constraint listed in the constraints section that enforces this=20
paragraph.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>RSA and opensource UML basically only =
enforce=20
explicit constraints.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I will ask the UML guru of that =
section to=20
clarify and I will get back to you if I receive additional =
info.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>You might want to open up a bug on =
RSA to request=20
that it be more user friendly such that if a user creates a =
property with=20
the same name as an inherited one then an explicit redefinition is =
made ( an=20
automatic semantic procedure ). RSA already has such =
semantic=20
procedures to help users out.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>In terms of the ease of use of RSA, =
you might=20
want to experiment with visualizing properties on composite structure=20
diagrams. Inherited properties are marked differently and =
you can=20
bring up a context menu to redefine them ( right click on them =
). =20
State machines have some capabilities in that regard =
also.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm not sure of the (minor) version =
of RSA you=20
have but there have been some recent improvements in that =
area.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>(You might want to raise usability =
issues against=20
RSA... they take customer defects seriously.)</FONT></DIV></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>- James.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Dave Carlson" <<A=20
=
href=3D"mailto:dcarlson@xmlmodeling.com">dcarlson@xmlmodeling.com</A>>=
=20
wrote in message <A=20
=
href=3D"news:fds9ra$vk1$1@build.eclipse.org">news:fds9ra$vk1$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I have a question about use of =
Property=20
redefinitions. I interpret the following quote from the UML =
2.1.1 spec=20
to mean that when a subclass includes a property whose name is =
equal to=20
a property in one of its general classes, then it should be treated =
as a=20
redefinition even if there is no explicit redefinition between those =
properties in the model.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV>
<P><FONT face=3DArial size=3D2>"All redefinitions should be made =
explicit with=20
the use of a {redefines <x>} property string. Matching =
features in=20
subclasses without an explicit redefinition result in a =
redefinition that=20
need not be shown in the notation. Redefinition prevents =
inheritance of a=20
redefined element into the redefinition context thereby making the =
name of=20
the redefined element available for reuse, either for the =
redefining=20
element, or for some other."</FONT></P></DIV></BLOCKQUOTE>
<P dir=3Dltr><FONT face=3DArial size=3D2>If that's correct, then =
should the=20
model validation throw an error if the subclass property type =
or=20
multiplicity is not compatible with the implicitly redefined =
property? =20
I've done some testing in RSM 7 and if I create an explicit property =
redefinition, then I do get a validation error for incompatible =
type or=20
multiplicity. But no error without the redefinition. I =
expect=20
that it would be computationally expensive to check for matching =
properties=20
of *every* property during validation. But this constraint =
from the=20
spec does not appear to be enforced.</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Do I have the correct =
interpretation of=20
the spec?</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Also, it is very difficult =
to create=20
property redefinitions in RSM 7 (using the UML properties dialog, =
not the=20
properties tabs), and without the {redefines xxx} notation in a=20
diagram it's nearly impossible to know when a refinition has =
been=20
added.</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Thanks,</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2> Dave=20
Carlson</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML >
------=_NextPart_000_0054_01C80A7B.2A974130--
|
|
|
| Re: Property redefinitions [message #476356 is a reply to message #476353] |
Tue, 09 October 2007 18:02 |
Dave Carlson
Messages: 402
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_000C_01C80A6C.535CDE40
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thanks, James. Will you or someone at Rational submit this as a bug to =
RSx? For the UML2 library, seems best for now to add a constraint that =
a property without redefinition must not have same name as a property =
owned by generals.
Dave
"James Bruck" <jbruck@ca.ibm.com> wrote in message =
news:fegeui$ml2$1@build.eclipse.org...
This is what Bran Selic (OMG Chair) has answered...
----------------------------------------------------
This should be clarified in the spec. It is unclear and also includes =
at least one spelling mistake. Alternatively, we should ban implicit =
redefinitions and flag them as simple name conflicts.
Two features of the same kind defined in a class and a superclass =
(i.e., they are both either structural features or behavioral features) =
does indeed imply a redefinition and, therefore, must conform to the =
compatibility constraint on redefinitions. Therefore, the tool should =
indeed flag an error in case of conflicting redefinitions.
"James Bruck" <jbruck@ca.ibm.com> wrote in message =
news:fe07ti$kt0$2@build.eclipse.org...
Hi Dave,
I think your interpretation is what is implied by the paragraph but =
it seems a little impractical and expensive to compute as you mention. =
Also there doesn't seem to be an explicit constraint listed in the =
constraints section that enforces this paragraph.
RSA and opensource UML basically only enforce explicit constraints.
I will ask the UML guru of that section to clarify and I will get =
back to you if I receive additional info.
You might want to open up a bug on RSA to request that it be more =
user friendly such that if a user creates a property with the same name =
as an inherited one then an explicit redefinition is made ( an automatic =
semantic procedure ). RSA already has such semantic procedures to help =
users out.
In terms of the ease of use of RSA, you might want to experiment =
with visualizing properties on composite structure diagrams. Inherited =
properties are marked differently and you can bring up a context menu to =
redefine them ( right click on them ). State machines have some =
capabilities in that regard also.
I'm not sure of the (minor) version of RSA you have but there have =
been some recent improvements in that area.
(You might want to raise usability issues against RSA... they take =
customer defects seriously.)
- James.
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message =
news:fds9ra$vk1$1@build.eclipse.org...
Hi,
I have a question about use of Property redefinitions. I =
interpret the following quote from the UML 2.1.1 spec to mean that when =
a subclass includes a property whose name is equal to a property in one =
of its general classes, then it should be treated as a redefinition even =
if there is no explicit redefinition between those properties in the =
model.
"All redefinitions should be made explicit with the use of a =
{redefines <x>} property string. Matching features in subclasses without =
an explicit redefinition result in a redefinition that need not be shown =
in the notation. Redefinition prevents inheritance of a redefined =
element into the redefinition context thereby making the name of the =
redefined element available for reuse, either for the redefining =
element, or for some other."
If that's correct, then should the model validation throw an error =
if the subclass property type or multiplicity is not compatible with the =
implicitly redefined property? I've done some testing in RSM 7 and if I =
create an explicit property redefinition, then I do get a validation =
error for incompatible type or multiplicity. But no error without the =
redefinition. I expect that it would be computationally expensive to =
check for matching properties of *every* property during validation. =
But this constraint from the spec does not appear to be enforced.
Do I have the correct interpretation of the spec?
Also, it is very difficult to create property redefinitions in RSM =
7 (using the UML properties dialog, not the properties tabs), and =
without the {redefines xxx} notation in a diagram it's nearly impossible =
to know when a refinition has been added.
Thanks,
Dave Carlson
------=_NextPart_000_000C_01C80A6C.535CDE40
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Thanks, James. Will you or =
someone at=20
Rational submit this as a bug to RSx? For the UML2 library, seems =
best for=20
now to add a constraint that a property without redefinition must not =
have same=20
name as a property owned by generals.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Dave</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"James Bruck" <<A=20
href=3D"mailto:jbruck@ca.ibm.com">jbruck@ca.ibm.com</A>> wrote in =
message <A=20
=
href=3D"news:fegeui$ml2$1@build.eclipse.org">news:fegeui$ml2$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>This is what Bran Selic (OMG Chair) =
has=20
answered...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial=20
=
size=3D2>---------------------------------------------------- </FONT></DIV=
>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DHelv size=3D2>
<P>This should be clarified in the spec. It is unclear and also =
includes at=20
least one spelling mistake. Alternatively, we should ban implicit=20
redefinitions and flag them as simple name conflicts.</P>
<P>Two features <U>of the same kind </U>defined in a class and a =
superclass=20
(i.e., they are both either structural features or behavioral =
features) does=20
indeed imply a redefinition and, therefore, must conform to the =
compatibility=20
constraint on redefinitions. Therefore, the tool should indeed flag an =
error=20
in case of conflicting redefinitions.</P></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"James Bruck" <<A=20
href=3D"mailto:jbruck@ca.ibm.com">jbruck@ca.ibm.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:fe07ti$kt0$2@build.eclipse.org">news:fe07ti$kt0$2@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I think your interpretation is what =
is implied=20
by the paragraph but it seems a little impractical and expensive to =
compute=20
as you mention. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Also there doesn't seem to be an =
explicit=20
constraint listed in the constraints section that enforces this=20
paragraph.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>RSA and opensource UML basically =
only enforce=20
explicit constraints.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I will ask the UML guru of that =
section to=20
clarify and I will get back to you if I receive additional=20
info.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>You might want to open up a bug on =
RSA to=20
request that it be more user friendly such that if a user =
creates a=20
property with the same name as an inherited one then an explicit=20
redefinition is made ( an automatic semantic procedure =
). RSA=20
already has such semantic procedures to help users out.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>In terms of the ease of use of RSA, =
you might=20
want to experiment with visualizing properties on composite =
structure=20
diagrams. Inherited properties are marked differently =
and you=20
can bring up a context menu to redefine them ( right click on them=20
). State machines have some capabilities in that regard=20
also.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm not sure of the (minor) version =
of RSA you=20
have but there have been some recent improvements in that =
area.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>(You might want to raise usability =
issues=20
against RSA... they take customer defects =
seriously.)</FONT></DIV></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>- James.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Dave Carlson" <<A=20
=
href=3D"mailto:dcarlson@xmlmodeling.com">dcarlson@xmlmodeling.com</A>>=
=20
wrote in message <A=20
=
href=3D"news:fds9ra$vk1$1@build.eclipse.org">news:fds9ra$vk1$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I have a question about use of =
Property=20
redefinitions. I interpret the following quote from the UML =
2.1.1=20
spec to mean that when a subclass includes a property whose =
name is=20
equal to a property in one of its general classes, then it should =
be=20
treated as a redefinition even if there is no explicit =
redefinition=20
between those properties in the model.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV>
<P><FONT face=3DArial size=3D2>"All redefinitions should be made =
explicit=20
with the use of a {redefines <x>} property string. =
Matching=20
features in subclasses without an explicit redefinition result =
in a=20
redefinition that need not be shown in the notation. =
Redefinition=20
prevents inheritance of a redefined element into the =
redefinition=20
context thereby making the name of the redefined element =
available for=20
reuse, either for the redefining element, or for some=20
other."</FONT></P></DIV></BLOCKQUOTE>
<P dir=3Dltr><FONT face=3DArial size=3D2>If that's correct, then =
should the=20
model validation throw an error if the subclass property type =
or=20
multiplicity is not compatible with the implicitly redefined=20
property? I've done some testing in RSM 7 and if I create an =
explicit property redefinition, then I do get a validation =
error for=20
incompatible type or multiplicity. But no error without the=20
redefinition. I expect that it would be computationally =
expensive to=20
check for matching properties of *every* property during =
validation. =20
But this constraint from the spec does not appear to be=20
enforced.</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Do I have the correct =
interpretation of=20
the spec?</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Also, it is very =
difficult to create=20
property redefinitions in RSM 7 (using the UML properties dialog, =
not the=20
properties tabs), and without the {redefines xxx} notation in a=20
diagram it's nearly impossible to know when a refinition has =
been=20
added.</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Thanks,</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2> Dave=20
=
Carlson</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE ></BODY></HTML>
------=_NextPart_000_000C_01C80A6C.535CDE40--
|
|
|
| Re: Property redefinitions [message #625068 is a reply to message #476248] |
Wed, 03 October 2007 14:10 |
james bruck
Messages: 1724
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0043_01C805A5.B0F75100
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Dave,
I think your interpretation is what is implied by the paragraph but it =
seems a little impractical and expensive to compute as you mention. =20
Also there doesn't seem to be an explicit constraint listed in the =
constraints section that enforces this paragraph.
RSA and opensource UML basically only enforce explicit constraints.
I will ask the UML guru of that section to clarify and I will get back =
to you if I receive additional info.
You might want to open up a bug on RSA to request that it be more user =
friendly such that if a user creates a property with the same name as an =
inherited one then an explicit redefinition is made ( an automatic =
semantic procedure ). RSA already has such semantic procedures to help =
users out.
In terms of the ease of use of RSA, you might want to experiment with =
visualizing properties on composite structure diagrams. Inherited =
properties are marked differently and you can bring up a context menu to =
redefine them ( right click on them ). State machines have some =
capabilities in that regard also.
I'm not sure of the (minor) version of RSA you have but there have been =
some recent improvements in that area.
(You might want to raise usability issues against RSA... they take =
customer defects seriously.)
- James.
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message =
news:fds9ra$vk1$1@build.eclipse.org...
Hi,
I have a question about use of Property redefinitions. I interpret =
the following quote from the UML 2.1.1 spec to mean that when a subclass =
includes a property whose name is equal to a property in one of its =
general classes, then it should be treated as a redefinition even if =
there is no explicit redefinition between those properties in the model.
"All redefinitions should be made explicit with the use of a =
{redefines <x>} property string. Matching features in subclasses without =
an explicit redefinition result in a redefinition that need not be shown =
in the notation. Redefinition prevents inheritance of a redefined =
element into the redefinition context thereby making the name of the =
redefined element available for reuse, either for the redefining =
element, or for some other."
If that's correct, then should the model validation throw an error if =
the subclass property type or multiplicity is not compatible with the =
implicitly redefined property? I've done some testing in RSM 7 and if I =
create an explicit property redefinition, then I do get a validation =
error for incompatible type or multiplicity. But no error without the =
redefinition. I expect that it would be computationally expensive to =
check for matching properties of *every* property during validation. =
But this constraint from the spec does not appear to be enforced.
Do I have the correct interpretation of the spec?
Also, it is very difficult to create property redefinitions in RSM 7 =
(using the UML properties dialog, not the properties tabs), and without =
the {redefines xxx} notation in a diagram it's nearly impossible to know =
when a refinition has been added.
Thanks,
Dave Carlson
------=_NextPart_000_0043_01C805A5.B0F75100
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1589" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I think your interpretation is what is =
implied by=20
the paragraph but it seems a little impractical and expensive to compute =
as you=20
mention. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Also there doesn't seem to be an =
explicit=20
constraint listed in the constraints section that enforces this=20
paragraph.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>RSA and opensource UML basically only =
enforce=20
explicit constraints.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I will ask the UML guru of that =
section to=20
clarify and I will get back to you if I receive additional =
info.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>You might want to open up a bug on RSA =
to request=20
that it be more user friendly such that if a user creates a =
property with=20
the same name as an inherited one then an explicit redefinition is made =
( an=20
automatic semantic procedure ). RSA already has such =
semantic=20
procedures to help users out.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>In terms of the ease of use of RSA, you =
might want=20
to experiment with visualizing properties on composite structure=20
diagrams. Inherited properties are marked differently and =
you can=20
bring up a context menu to redefine them ( right click on them =
). =20
State machines have some capabilities in that regard also.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm not sure of the (minor) version of =
RSA you have=20
but there have been some recent improvements in that area.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>(You might want to raise usability =
issues against=20
RSA... they take customer defects seriously.)</FONT></DIV></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>- James.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Dave Carlson" <<A=20
=
href=3D"mailto:dcarlson@xmlmodeling.com">dcarlson@xmlmodeling.com</A>>=
wrote=20
in message <A=20
=
href=3D"news:fds9ra$vk1$1@build.eclipse.org">news:fds9ra$vk1$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I have a question about use of =
Property=20
redefinitions. I interpret the following quote from the UML =
2.1.1 spec=20
to mean that when a subclass includes a property whose name is =
equal to a=20
property in one of its general classes, then it should be treated as a =
redefinition even if there is no explicit redefinition between those=20
properties in the model.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV>
<P><FONT face=3DArial size=3D2>"All redefinitions should be made =
explicit with=20
the use of a {redefines <x>} property string. Matching =
features in=20
subclasses without an explicit redefinition result in a redefinition =
that=20
need not be shown in the notation. Redefinition prevents inheritance =
of a=20
redefined element into the redefinition context thereby making the =
name of=20
the redefined element available for reuse, either for the redefining =
element, or for some other."</FONT></P></DIV></BLOCKQUOTE>
<P dir=3Dltr><FONT face=3DArial size=3D2>If that's correct, then =
should the=20
model validation throw an error if the subclass property type or=20
multiplicity is not compatible with the implicitly redefined =
property? =20
I've done some testing in RSM 7 and if I create an explicit property=20
redefinition, then I do get a validation error for incompatible =
type or=20
multiplicity. But no error without the redefinition. I =
expect that=20
it would be computationally expensive to check for matching properties =
of=20
*every* property during validation. But this constraint from the =
spec=20
does not appear to be enforced.</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Do I have the correct =
interpretation of the=20
spec?</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Also, it is very difficult to =
create=20
property redefinitions in RSM 7 (using the UML properties dialog, not =
the=20
properties tabs), and without the {redefines xxx} notation in a=20
diagram it's nearly impossible to know when a refinition has been =
added.</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Thanks,</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2> Dave=20
Carlson</FONT></P></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0043_01C805A5.B0F75100--
|
|
|
| Re: Property redefinitions [message #625071 is a reply to message #476256] |
Wed, 03 October 2007 16:27 |
Dave Carlson
Messages: 402
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0016_01C805A7.F52CCB50
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi James,
Thanks very much for your detailed response. I am still running RSM =
7.0.0.2 and will update today to the latest revision, thanks for the =
tip. And I will take a careful look at composite structure diagrams. =
This is for work I am doing on large healthcare domain models, where the =
need to specialize and redefine general semantic domain models is a very =
important part of their methodology.
Another related question. In UML2, it seems that there is no way to =
remove or prohibit a property in a specialized class, except maybe by =
adding a Constraint to the subclass. This is also an important =
requirement for the healthcare models, and currently the classes are =
cloned and modified in order to remove properties. I am trying to make =
this process more rigorous. In UML 1.3 (e.g., in Rose), I could change =
a subclass property multiplicity to [0..0], but the UML2 spec prohibits =
an upper bound < 0. Any ideas here?
Thanks!
Dave
"James Bruck" <jbruck@ca.ibm.com> wrote in message =
news:fe07ti$kt0$2@build.eclipse.org...
Hi Dave,
I think your interpretation is what is implied by the paragraph but it =
seems a little impractical and expensive to compute as you mention. =20
Also there doesn't seem to be an explicit constraint listed in the =
constraints section that enforces this paragraph.
RSA and opensource UML basically only enforce explicit constraints.
I will ask the UML guru of that section to clarify and I will get back =
to you if I receive additional info.
You might want to open up a bug on RSA to request that it be more user =
friendly such that if a user creates a property with the same name as an =
inherited one then an explicit redefinition is made ( an automatic =
semantic procedure ). RSA already has such semantic procedures to help =
users out.
In terms of the ease of use of RSA, you might want to experiment with =
visualizing properties on composite structure diagrams. Inherited =
properties are marked differently and you can bring up a context menu to =
redefine them ( right click on them ). State machines have some =
capabilities in that regard also.
I'm not sure of the (minor) version of RSA you have but there have =
been some recent improvements in that area.
(You might want to raise usability issues against RSA... they take =
customer defects seriously.)
------=_NextPart_000_0016_01C805A7.F52CCB50
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi James,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks very much for your detailed =
response. =20
I am still running RSM 7.0.0.2 and will update today to the latest =
revision,=20
thanks for the tip. And I will take a careful look at composite =
structure=20
diagrams. This is for work I am doing on large healthcare =
domain=20
models, where the need to specialize and redefine general semantic =
domain models=20
is a very important part of their methodology.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Another related question. In =
UML2, it seems=20
that there is no way to remove or prohibit a property in a specialized =
class,=20
except maybe by adding a Constraint to the subclass. This is also =
an=20
important requirement for the healthcare models, and currently the =
classes are=20
cloned and modified in order to remove properties. I am trying to =
make=20
this process more rigorous. In UML 1.3 (e.g., in Rose), I could =
change a=20
subclass property multiplicity to [0..0], but the UML2 spec =
prohibits an=20
upper bound < 0. Any ideas here?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> Dave</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"James Bruck" <<A=20
href=3D"mailto:jbruck@ca.ibm.com">jbruck@ca.ibm.com</A>> wrote in =
message <A=20
=
href=3D"news:fe07ti$kt0$2@build.eclipse.org">news:fe07ti$kt0$2@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I think your interpretation is what =
is implied by=20
the paragraph but it seems a little impractical and expensive to =
compute as=20
you mention. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Also there doesn't seem to be an =
explicit=20
constraint listed in the constraints section that enforces this=20
paragraph.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>RSA and opensource UML basically only =
enforce=20
explicit constraints.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I will ask the UML guru of that =
section to=20
clarify and I will get back to you if I receive additional =
info.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>You might want to open up a bug on =
RSA to request=20
that it be more user friendly such that if a user creates a =
property with=20
the same name as an inherited one then an explicit redefinition is =
made ( an=20
automatic semantic procedure ). RSA already has such =
semantic=20
procedures to help users out.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>In terms of the ease of use of RSA, =
you might=20
want to experiment with visualizing properties on composite structure=20
diagrams. Inherited properties are marked differently and =
you can=20
bring up a context menu to redefine them ( right click on them =
). =20
State machines have some capabilities in that regard =
also.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm not sure of the (minor) version =
of RSA you=20
have but there have been some recent improvements in that =
area.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>(You might want to raise usability =
issues against=20
RSA... they take customer defects seriously.)</FONT></DIV></DIV>
<DIV><FONT face=3DArial =
size=3D2></FONT> </DIV></BLOCKQUOTE></BODY></HTML >
------=_NextPart_000_0016_01C805A7.F52CCB50--
|
|
|
| Re: Property redefinitions [message #625073 is a reply to message #476259] |
Wed, 03 October 2007 17:46 |
james bruck
Messages: 1724
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0012_01C805C3.C3245940
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Dave,
Have you tried setting the RedefinableElement.setIsLeaf() to true in the =
more generalized context for those elements you don't want specialized?
From the spec ...=20
Indicates whether it is possible to further specialize a =
RedefinableElement. If the value is true, then it is not possible to =
further specialize the RedefinableElement. Default value is false.=20
- James.
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message =
news:fe0ft0$1cf$1@build.eclipse.org...
Hi James,
Thanks very much for your detailed response. I am still running RSM =
7.0.0.2 and will update today to the latest revision, thanks for the =
tip. And I will take a careful look at composite structure diagrams. =
This is for work I am doing on large healthcare domain models, where the =
need to specialize and redefine general semantic domain models is a very =
important part of their methodology.
Another related question. In UML2, it seems that there is no way to =
remove or prohibit a property in a specialized class, except maybe by =
adding a Constraint to the subclass. This is also an important =
requirement for the healthcare models, and currently the classes are =
cloned and modified in order to remove properties. I am trying to make =
this process more rigorous. In UML 1.3 (e.g., in Rose), I could change =
a subclass property multiplicity to [0..0], but the UML2 spec prohibits =
an upper bound < 0. Any ideas here?
Thanks!
Dave
"James Bruck" <jbruck@ca.ibm.com> wrote in message =
news:fe07ti$kt0$2@build.eclipse.org...
Hi Dave,
I think your interpretation is what is implied by the paragraph but =
it seems a little impractical and expensive to compute as you mention. =
Also there doesn't seem to be an explicit constraint listed in the =
constraints section that enforces this paragraph.
RSA and opensource UML basically only enforce explicit constraints.
I will ask the UML guru of that section to clarify and I will get =
back to you if I receive additional info.
You might want to open up a bug on RSA to request that it be more =
user friendly such that if a user creates a property with the same name =
as an inherited one then an explicit redefinition is made ( an automatic =
semantic procedure ). RSA already has such semantic procedures to help =
users out.
In terms of the ease of use of RSA, you might want to experiment =
with visualizing properties on composite structure diagrams. Inherited =
properties are marked differently and you can bring up a context menu to =
redefine them ( right click on them ). State machines have some =
capabilities in that regard also.
I'm not sure of the (minor) version of RSA you have but there have =
been some recent improvements in that area.
(You might want to raise usability issues against RSA... they take =
customer defects seriously.)
------=_NextPart_000_0012_01C805C3.C3245940
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1589" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Have you tried setting the=20
RedefinableElement.setIsLeaf() to true in the more generalized context =
for those=20
elements you don't want specialized?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>From the spec ... <FONT size=3D2>
<P>Indicates whether it is possible to further specialize a =
RedefinableElement.=20
If the value is true, then it is not possible to further specialize the=20
RedefinableElement. Default value is </FONT><I><FONT=20
face=3D"Times New Roman,Times New Roman" size=3D2>false</I></FONT><FONT =
size=3D2>.=20
</P></FONT></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>- James.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Dave Carlson" <<A=20
=
href=3D"mailto:dcarlson@xmlmodeling.com">dcarlson@xmlmodeling.com</A>>=
wrote=20
in message <A=20
=
href=3D"news:fe0ft0$1cf$1@build.eclipse.org">news:fe0ft0$1cf$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi James,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks very much for your detailed=20
response. I am still running RSM 7.0.0.2 and will update today =
to the=20
latest revision, thanks for the tip. And I will take a careful =
look at=20
composite structure diagrams. This is for work I am doing on=20
large healthcare domain models, where the need to specialize and =
redefine=20
general semantic domain models is a very important part of their=20
methodology.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Another related question. In =
UML2, it seems=20
that there is no way to remove or prohibit a property in a specialized =
class,=20
except maybe by adding a Constraint to the subclass. This is =
also an=20
important requirement for the healthcare models, and currently the =
classes are=20
cloned and modified in order to remove properties. I am trying =
to make=20
this process more rigorous. In UML 1.3 (e.g., in Rose), I could =
change a=20
subclass property multiplicity to [0..0], but the UML2 spec =
prohibits an=20
upper bound < 0. Any ideas here?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> Dave</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"James Bruck" <<A=20
href=3D"mailto:jbruck@ca.ibm.com">jbruck@ca.ibm.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:fe07ti$kt0$2@build.eclipse.org">news:fe07ti$kt0$2@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I think your interpretation is what =
is implied=20
by the paragraph but it seems a little impractical and expensive to =
compute=20
as you mention. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Also there doesn't seem to be an =
explicit=20
constraint listed in the constraints section that enforces this=20
paragraph.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>RSA and opensource UML basically =
only enforce=20
explicit constraints.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I will ask the UML guru of that =
section to=20
clarify and I will get back to you if I receive additional=20
info.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>You might want to open up a bug on =
RSA to=20
request that it be more user friendly such that if a user =
creates a=20
property with the same name as an inherited one then an explicit=20
redefinition is made ( an automatic semantic procedure =
). RSA=20
already has such semantic procedures to help users out.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>In terms of the ease of use of RSA, =
you might=20
want to experiment with visualizing properties on composite =
structure=20
diagrams. Inherited properties are marked differently =
and you=20
can bring up a context menu to redefine them ( right click on them=20
). State machines have some capabilities in that regard=20
also.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm not sure of the (minor) version =
of RSA you=20
have but there have been some recent improvements in that =
area.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>(You might want to raise usability =
issues=20
against RSA... they take customer defects =
seriously.)</FONT></DIV></DIV>
<DIV><FONT face=3DArial=20
size=3D2></FONT> </DIV></BLOCKQUOTE></BLOCKQUOTE ></BODY></HTML>
------=_NextPart_000_0012_01C805C3.C3245940--
|
|
|
| Re: Property redefinitions [message #625075 is a reply to message #476261] |
Wed, 03 October 2007 18:21 |
Dave Carlson
Messages: 402
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_000C_01C805B7.FCF6DCD0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi James,
That does not seem to address the issue we have. We need to prevent an =
inherited property from being used in a subclass, in effect eliminating =
it. This should affect generated artifacts, e.g. Java for the subclass =
would not allow that property to be set, or XSD for the subclass would =
have maxOccurs=3D0 for that element (a pattern sometimes used in XSD =
design).
I interpret setIsLeaf(true) to mean that the subclass cannot change the =
superclass property definition (override its type or multiplicity). We =
do want to redefine it to prevent its use (and hiding it in the subclass =
diagram presentation).
Dave
"James Bruck" <jbruck@ca.ibm.com> wrote in message =
news:fe0kh7$a1d$2@build.eclipse.org...
Hi Dave,
Have you tried setting the RedefinableElement.setIsLeaf() to true in =
the more generalized context for those elements you don't want =
specialized?
From the spec ...=20
Indicates whether it is possible to further specialize a =
RedefinableElement. If the value is true, then it is not possible to =
further specialize the RedefinableElement. Default value is false.=20
------=_NextPart_000_000C_01C805B7.FCF6DCD0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi James,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>That does not seem to address the issue =
we=20
have. We need to prevent an inherited property from being used in =
a=20
subclass, in effect eliminating it. This should affect generated=20
artifacts, e.g. Java for the subclass would not allow that property to =
be set,=20
or XSD for the subclass would have maxOccurs=3D0 for that element (a =
pattern=20
sometimes used in XSD design).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I interpret setIsLeaf(true) to mean =
that the=20
subclass cannot change the superclass property definition (override its =
type or=20
multiplicity). We do want to redefine it to prevent its use (and =
hiding it=20
in the subclass diagram presentation).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Dave</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"James Bruck" <<A=20
href=3D"mailto:jbruck@ca.ibm.com">jbruck@ca.ibm.com</A>> wrote in =
message <A=20
=
href=3D"news:fe0kh7$a1d$2@build.eclipse.org">news:fe0kh7$a1d$2@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Have you tried setting the=20
RedefinableElement.setIsLeaf() to true in the more generalized context =
for=20
those elements you don't want specialized?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>From the spec ... <FONT size=3D2>
<P>Indicates whether it is possible to further specialize a=20
RedefinableElement. If the value is true, then it is not possible to =
further=20
specialize the RedefinableElement. Default value is </FONT><I><FONT=20
face=3D"Times New Roman,Times New Roman" =
size=3D2>false</I></FONT><FONT size=3D2>.=20
</P></FONT></FONT></DIV></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_000C_01C805B7.FCF6DCD0--
|
|
|
| Re: Property redefinitions [message #625077 is a reply to message #476263] |
Thu, 04 October 2007 01:36 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_02AD_01C80605.6FD348E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Dave,
No, there's no concept of "exclusions" in UML, i.e. redefining an =
element such that it does not appear in the redefining context.
Kenn
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message =
news:fe0mk6$s7b$1@build.eclipse.org...
Hi James,
That does not seem to address the issue we have. We need to prevent =
an inherited property from being used in a subclass, in effect =
eliminating it. This should affect generated artifacts, e.g. Java for =
the subclass would not allow that property to be set, or XSD for the =
subclass would have maxOccurs=3D0 for that element (a pattern sometimes =
used in XSD design).
I interpret setIsLeaf(true) to mean that the subclass cannot change =
the superclass property definition (override its type or multiplicity). =
We do want to redefine it to prevent its use (and hiding it in the =
subclass diagram presentation).
Dave
"James Bruck" <jbruck@ca.ibm.com> wrote in message =
news:fe0kh7$a1d$2@build.eclipse.org...
Hi Dave,
Have you tried setting the RedefinableElement.setIsLeaf() to true in =
the more generalized context for those elements you don't want =
specialized?
From the spec ...=20
Indicates whether it is possible to further specialize a =
RedefinableElement. If the value is true, then it is not possible to =
further specialize the RedefinableElement. Default value is false.=20
------=_NextPart_000_02AD_01C80605.6FD348E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16481" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>No, there's no concept of "exclusions" =
in UML, i.e.=20
redefining an element such that it does not appear in the redefining=20
context.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Kenn</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Dave Carlson" <<A=20
=
href=3D"mailto:dcarlson@xmlmodeling.com">dcarlson@xmlmodeling.com</A>>=
wrote=20
in message <A=20
=
href=3D"news:fe0mk6$s7b$1@build.eclipse.org">news:fe0mk6$s7b$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi James,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>That does not seem to address the =
issue we=20
have. We need to prevent an inherited property from being used =
in a=20
subclass, in effect eliminating it. This should affect generated =
artifacts, e.g. Java for the subclass would not allow that property to =
be set,=20
or XSD for the subclass would have maxOccurs=3D0 for that element (a =
pattern=20
sometimes used in XSD design).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I interpret setIsLeaf(true) to mean =
that the=20
subclass cannot change the superclass property definition (override =
its type=20
or multiplicity). We do want to redefine it to prevent its use =
(and=20
hiding it in the subclass diagram presentation).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Dave</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"James Bruck" <<A=20
href=3D"mailto:jbruck@ca.ibm.com">jbruck@ca.ibm.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:fe0kh7$a1d$2@build.eclipse.org">news:fe0kh7$a1d$2@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Have you tried setting the=20
RedefinableElement.setIsLeaf() to true in the more generalized =
context for=20
those elements you don't want specialized?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>From the spec ... <FONT size=3D2>
<P>Indicates whether it is possible to further specialize a=20
RedefinableElement. If the value is true, then it is not possible to =
further=20
specialize the RedefinableElement. Default value is </FONT><I><FONT=20
face=3D"Times New Roman,Times New Roman" =
size=3D2>false</I></FONT><FONT size=3D2>.=20
</P></FONT></FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY ></HTML>
------=_NextPart_000_02AD_01C80605.6FD348E0--
|
|
|
| Re: Property redefinitions [message #625081 is a reply to message #476265] |
Thu, 04 October 2007 15:28 |
Dave Carlson
Messages: 402
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0010_01C80668.E7DEC180
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Kenn,
That was my reading of the UML spec, but I wanted to confirm that I was =
not overlooking something. Thanks.
Dave
"Kenn Hussey" <Kenn.Hussey@embarcadero.com> wrote in message =
news:fe1g2m$237$1@build.eclipse.org...
Dave,
No, there's no concept of "exclusions" in UML, i.e. redefining an =
element such that it does not appear in the redefining context.
Kenn
------=_NextPart_000_0010_01C80668.E7DEC180
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Kenn,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>That was my reading of the UML spec, =
but I wanted=20
to confirm that I was not overlooking something. =
Thanks.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Dave</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Kenn Hussey" <<A=20
=
href=3D"mailto:Kenn.Hussey@embarcadero.com">Kenn.Hussey@embarcadero.com</=
A>>=20
wrote in message <A=20
=
href=3D"news:fe1g2m$237$1@build.eclipse.org">news:fe1g2m$237$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>No, there's no concept of =
"exclusions" in UML,=20
i.e. redefining an element such that it does not appear in the =
redefining=20
context.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial =
size=3D2>Kenn</FONT></DIV></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_0010_01C80668.E7DEC180--
|
|
|
| Re: Property redefinitions [message #625165 is a reply to message #476256] |
Tue, 09 October 2007 17:49 |
james bruck
Messages: 1724
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0054_01C80A7B.2A974130
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
This is what Bran Selic (OMG Chair) has answered...
----------------------------------------------------
This should be clarified in the spec. It is unclear and also includes at =
least one spelling mistake. Alternatively, we should ban implicit =
redefinitions and flag them as simple name conflicts.
Two features of the same kind defined in a class and a superclass (i.e., =
they are both either structural features or behavioral features) does =
indeed imply a redefinition and, therefore, must conform to the =
compatibility constraint on redefinitions. Therefore, the tool should =
indeed flag an error in case of conflicting redefinitions.
"James Bruck" <jbruck@ca.ibm.com> wrote in message =
news:fe07ti$kt0$2@build.eclipse.org...
Hi Dave,
I think your interpretation is what is implied by the paragraph but it =
seems a little impractical and expensive to compute as you mention. =20
Also there doesn't seem to be an explicit constraint listed in the =
constraints section that enforces this paragraph.
RSA and opensource UML basically only enforce explicit constraints.
I will ask the UML guru of that section to clarify and I will get back =
to you if I receive additional info.
You might want to open up a bug on RSA to request that it be more user =
friendly such that if a user creates a property with the same name as an =
inherited one then an explicit redefinition is made ( an automatic =
semantic procedure ). RSA already has such semantic procedures to help =
users out.
In terms of the ease of use of RSA, you might want to experiment with =
visualizing properties on composite structure diagrams. Inherited =
properties are marked differently and you can bring up a context menu to =
redefine them ( right click on them ). State machines have some =
capabilities in that regard also.
I'm not sure of the (minor) version of RSA you have but there have =
been some recent improvements in that area.
(You might want to raise usability issues against RSA... they take =
customer defects seriously.)
- James.
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message =
news:fds9ra$vk1$1@build.eclipse.org...
Hi,
I have a question about use of Property redefinitions. I interpret =
the following quote from the UML 2.1.1 spec to mean that when a subclass =
includes a property whose name is equal to a property in one of its =
general classes, then it should be treated as a redefinition even if =
there is no explicit redefinition between those properties in the model.
"All redefinitions should be made explicit with the use of a =
{redefines <x>} property string. Matching features in subclasses without =
an explicit redefinition result in a redefinition that need not be shown =
in the notation. Redefinition prevents inheritance of a redefined =
element into the redefinition context thereby making the name of the =
redefined element available for reuse, either for the redefining =
element, or for some other."
If that's correct, then should the model validation throw an error =
if the subclass property type or multiplicity is not compatible with the =
implicitly redefined property? I've done some testing in RSM 7 and if I =
create an explicit property redefinition, then I do get a validation =
error for incompatible type or multiplicity. But no error without the =
redefinition. I expect that it would be computationally expensive to =
check for matching properties of *every* property during validation. =
But this constraint from the spec does not appear to be enforced.
Do I have the correct interpretation of the spec?
Also, it is very difficult to create property redefinitions in RSM 7 =
(using the UML properties dialog, not the properties tabs), and without =
the {redefines xxx} notation in a diagram it's nearly impossible to know =
when a refinition has been added.
Thanks,
Dave Carlson
------=_NextPart_000_0054_01C80A7B.2A974130
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>This is what Bran Selic (OMG Chair) has =
answered...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial=20
size=3D2>---------------------------------------------------- </FONT></DIV=
>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DHelv size=3D2>
<P>This should be clarified in the spec. It is unclear and also includes =
at=20
least one spelling mistake. Alternatively, we should ban implicit =
redefinitions=20
and flag them as simple name conflicts.</P>
<P>Two features <U>of the same kind </U>defined in a class and a =
superclass=20
(i.e., they are both either structural features or behavioral features) =
does=20
indeed imply a redefinition and, therefore, must conform to the =
compatibility=20
constraint on redefinitions. Therefore, the tool should indeed flag an =
error in=20
case of conflicting redefinitions.</P></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"James Bruck" <<A=20
href=3D"mailto:jbruck@ca.ibm.com">jbruck@ca.ibm.com</A>> wrote in =
message <A=20
=
href=3D"news:fe07ti$kt0$2@build.eclipse.org">news:fe07ti$kt0$2@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I think your interpretation is what =
is implied by=20
the paragraph but it seems a little impractical and expensive to =
compute as=20
you mention. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Also there doesn't seem to be an =
explicit=20
constraint listed in the constraints section that enforces this=20
paragraph.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>RSA and opensource UML basically only =
enforce=20
explicit constraints.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I will ask the UML guru of that =
section to=20
clarify and I will get back to you if I receive additional =
info.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>You might want to open up a bug on =
RSA to request=20
that it be more user friendly such that if a user creates a =
property with=20
the same name as an inherited one then an explicit redefinition is =
made ( an=20
automatic semantic procedure ). RSA already has such =
semantic=20
procedures to help users out.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>In terms of the ease of use of RSA, =
you might=20
want to experiment with visualizing properties on composite structure=20
diagrams. Inherited properties are marked differently and =
you can=20
bring up a context menu to redefine them ( right click on them =
). =20
State machines have some capabilities in that regard =
also.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm not sure of the (minor) version =
of RSA you=20
have but there have been some recent improvements in that =
area.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>(You might want to raise usability =
issues against=20
RSA... they take customer defects seriously.)</FONT></DIV></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>- James.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Dave Carlson" <<A=20
=
href=3D"mailto:dcarlson@xmlmodeling.com">dcarlson@xmlmodeling.com</A>>=
=20
wrote in message <A=20
=
href=3D"news:fds9ra$vk1$1@build.eclipse.org">news:fds9ra$vk1$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I have a question about use of =
Property=20
redefinitions. I interpret the following quote from the UML =
2.1.1 spec=20
to mean that when a subclass includes a property whose name is =
equal to=20
a property in one of its general classes, then it should be treated =
as a=20
redefinition even if there is no explicit redefinition between those =
properties in the model.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV>
<P><FONT face=3DArial size=3D2>"All redefinitions should be made =
explicit with=20
the use of a {redefines <x>} property string. Matching =
features in=20
subclasses without an explicit redefinition result in a =
redefinition that=20
need not be shown in the notation. Redefinition prevents =
inheritance of a=20
redefined element into the redefinition context thereby making the =
name of=20
the redefined element available for reuse, either for the =
redefining=20
element, or for some other."</FONT></P></DIV></BLOCKQUOTE>
<P dir=3Dltr><FONT face=3DArial size=3D2>If that's correct, then =
should the=20
model validation throw an error if the subclass property type =
or=20
multiplicity is not compatible with the implicitly redefined =
property? =20
I've done some testing in RSM 7 and if I create an explicit property =
redefinition, then I do get a validation error for incompatible =
type or=20
multiplicity. But no error without the redefinition. I =
expect=20
that it would be computationally expensive to check for matching =
properties=20
of *every* property during validation. But this constraint =
from the=20
spec does not appear to be enforced.</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Do I have the correct =
interpretation of=20
the spec?</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Also, it is very difficult =
to create=20
property redefinitions in RSM 7 (using the UML properties dialog, =
not the=20
properties tabs), and without the {redefines xxx} notation in a=20
diagram it's nearly impossible to know when a refinition has =
been=20
added.</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Thanks,</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2> Dave=20
Carlson</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML >
------=_NextPart_000_0054_01C80A7B.2A974130--
|
|
|
| Re: Property redefinitions [message #625168 is a reply to message #476353] |
Tue, 09 October 2007 18:02 |
Dave Carlson
Messages: 402
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_000C_01C80A6C.535CDE40
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thanks, James. Will you or someone at Rational submit this as a bug to =
RSx? For the UML2 library, seems best for now to add a constraint that =
a property without redefinition must not have same name as a property =
owned by generals.
Dave
"James Bruck" <jbruck@ca.ibm.com> wrote in message =
news:fegeui$ml2$1@build.eclipse.org...
This is what Bran Selic (OMG Chair) has answered...
----------------------------------------------------
This should be clarified in the spec. It is unclear and also includes =
at least one spelling mistake. Alternatively, we should ban implicit =
redefinitions and flag them as simple name conflicts.
Two features of the same kind defined in a class and a superclass =
(i.e., they are both either structural features or behavioral features) =
does indeed imply a redefinition and, therefore, must conform to the =
compatibility constraint on redefinitions. Therefore, the tool should =
indeed flag an error in case of conflicting redefinitions.
"James Bruck" <jbruck@ca.ibm.com> wrote in message =
news:fe07ti$kt0$2@build.eclipse.org...
Hi Dave,
I think your interpretation is what is implied by the paragraph but =
it seems a little impractical and expensive to compute as you mention. =
Also there doesn't seem to be an explicit constraint listed in the =
constraints section that enforces this paragraph.
RSA and opensource UML basically only enforce explicit constraints.
I will ask the UML guru of that section to clarify and I will get =
back to you if I receive additional info.
You might want to open up a bug on RSA to request that it be more =
user friendly such that if a user creates a property with the same name =
as an inherited one then an explicit redefinition is made ( an automatic =
semantic procedure ). RSA already has such semantic procedures to help =
users out.
In terms of the ease of use of RSA, you might want to experiment =
with visualizing properties on composite structure diagrams. Inherited =
properties are marked differently and you can bring up a context menu to =
redefine them ( right click on them ). State machines have some =
capabilities in that regard also.
I'm not sure of the (minor) version of RSA you have but there have =
been some recent improvements in that area.
(You might want to raise usability issues against RSA... they take =
customer defects seriously.)
- James.
"Dave Carlson" <dcarlson@xmlmodeling.com> wrote in message =
news:fds9ra$vk1$1@build.eclipse.org...
Hi,
I have a question about use of Property redefinitions. I =
interpret the following quote from the UML 2.1.1 spec to mean that when =
a subclass includes a property whose name is equal to a property in one =
of its general classes, then it should be treated as a redefinition even =
if there is no explicit redefinition between those properties in the =
model.
"All redefinitions should be made explicit with the use of a =
{redefines <x>} property string. Matching features in subclasses without =
an explicit redefinition result in a redefinition that need not be shown =
in the notation. Redefinition prevents inheritance of a redefined =
element into the redefinition context thereby making the name of the =
redefined element available for reuse, either for the redefining =
element, or for some other."
If that's correct, then should the model validation throw an error =
if the subclass property type or multiplicity is not compatible with the =
implicitly redefined property? I've done some testing in RSM 7 and if I =
create an explicit property redefinition, then I do get a validation =
error for incompatible type or multiplicity. But no error without the =
redefinition. I expect that it would be computationally expensive to =
check for matching properties of *every* property during validation. =
But this constraint from the spec does not appear to be enforced.
Do I have the correct interpretation of the spec?
Also, it is very difficult to create property redefinitions in RSM =
7 (using the UML properties dialog, not the properties tabs), and =
without the {redefines xxx} notation in a diagram it's nearly impossible =
to know when a refinition has been added.
Thanks,
Dave Carlson
------=_NextPart_000_000C_01C80A6C.535CDE40
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Thanks, James. Will you or =
someone at=20
Rational submit this as a bug to RSx? For the UML2 library, seems =
best for=20
now to add a constraint that a property without redefinition must not =
have same=20
name as a property owned by generals.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Dave</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"James Bruck" <<A=20
href=3D"mailto:jbruck@ca.ibm.com">jbruck@ca.ibm.com</A>> wrote in =
message <A=20
=
href=3D"news:fegeui$ml2$1@build.eclipse.org">news:fegeui$ml2$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>This is what Bran Selic (OMG Chair) =
has=20
answered...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial=20
=
size=3D2>---------------------------------------------------- </FONT></DIV=
>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DHelv size=3D2>
<P>This should be clarified in the spec. It is unclear and also =
includes at=20
least one spelling mistake. Alternatively, we should ban implicit=20
redefinitions and flag them as simple name conflicts.</P>
<P>Two features <U>of the same kind </U>defined in a class and a =
superclass=20
(i.e., they are both either structural features or behavioral =
features) does=20
indeed imply a redefinition and, therefore, must conform to the =
compatibility=20
constraint on redefinitions. Therefore, the tool should indeed flag an =
error=20
in case of conflicting redefinitions.</P></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"James Bruck" <<A=20
href=3D"mailto:jbruck@ca.ibm.com">jbruck@ca.ibm.com</A>> wrote in =
message=20
<A=20
=
href=3D"news:fe07ti$kt0$2@build.eclipse.org">news:fe07ti$kt0$2@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi Dave,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I think your interpretation is what =
is implied=20
by the paragraph but it seems a little impractical and expensive to =
compute=20
as you mention. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Also there doesn't seem to be an =
explicit=20
constraint listed in the constraints section that enforces this=20
paragraph.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>RSA and opensource UML basically =
only enforce=20
explicit constraints.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I will ask the UML guru of that =
section to=20
clarify and I will get back to you if I receive additional=20
info.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>You might want to open up a bug on =
RSA to=20
request that it be more user friendly such that if a user =
creates a=20
property with the same name as an inherited one then an explicit=20
redefinition is made ( an automatic semantic procedure =
). RSA=20
already has such semantic procedures to help users out.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>In terms of the ease of use of RSA, =
you might=20
want to experiment with visualizing properties on composite =
structure=20
diagrams. Inherited properties are marked differently =
and you=20
can bring up a context menu to redefine them ( right click on them=20
). State machines have some capabilities in that regard=20
also.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I'm not sure of the (minor) version =
of RSA you=20
have but there have been some recent improvements in that =
area.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV>
<DIV><FONT face=3DArial size=3D2>(You might want to raise usability =
issues=20
against RSA... they take customer defects =
seriously.)</FONT></DIV></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>- James.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Dave Carlson" <<A=20
=
href=3D"mailto:dcarlson@xmlmodeling.com">dcarlson@xmlmodeling.com</A>>=
=20
wrote in message <A=20
=
href=3D"news:fds9ra$vk1$1@build.eclipse.org">news:fds9ra$vk1$1@build.ecli=
pse.org</A>...</DIV>
<DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I have a question about use of =
Property=20
redefinitions. I interpret the following quote from the UML =
2.1.1=20
spec to mean that when a subclass includes a property whose =
name is=20
equal to a property in one of its general classes, then it should =
be=20
treated as a redefinition even if there is no explicit =
redefinition=20
between those properties in the model.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV>
<P><FONT face=3DArial size=3D2>"All redefinitions should be made =
explicit=20
with the use of a {redefines <x>} property string. =
Matching=20
features in subclasses without an explicit redefinition result =
in a=20
redefinition that need not be shown in the notation. =
Redefinition=20
prevents inheritance of a redefined element into the =
redefinition=20
context thereby making the name of the redefined element =
available for=20
reuse, either for the redefining element, or for some=20
other."</FONT></P></DIV></BLOCKQUOTE>
<P dir=3Dltr><FONT face=3DArial size=3D2>If that's correct, then =
should the=20
model validation throw an error if the subclass property type =
or=20
multiplicity is not compatible with the implicitly redefined=20
property? I've done some testing in RSM 7 and if I create an =
explicit property redefinition, then I do get a validation =
error for=20
incompatible type or multiplicity. But no error without the=20
redefinition. I expect that it would be computationally =
expensive to=20
check for matching properties of *every* property during =
validation. =20
But this constraint from the spec does not appear to be=20
enforced.</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Do I have the correct =
interpretation of=20
the spec?</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Also, it is very =
difficult to create=20
property redefinitions in RSM 7 (using the UML properties dialog, =
not the=20
properties tabs), and without the {redefines xxx} notation in a=20
diagram it's nearly impossible to know when a refinition has =
been=20
added.</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2>Thanks,</FONT></P>
<P dir=3Dltr><FONT face=3DArial size=3D2> Dave=20
=
Carlson</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE ></BODY></HTML>
------=_NextPart_000_000C_01C80A6C.535CDE40--
|
|
|
Goto Forum:
Current Time: Tue Apr 16 07:13:53 GMT 2024
Powered by FUDForum. Page generated in 0.49603 seconds |
] 
Search
Help
Register
Login
Home
