Home » Modeling » UML2 » Should ValueSpecification be really a TypedElement?
| Should ValueSpecification be really a TypedElement? [message #477567] |
Thu, 03 July 2008 08:42  |
Eclipse User |
|
|
|
Hi all,
after studying the values and instances concepts of the UML2 superstructure,
i was wondering that a ValueSpecification is also inhereting TypedElement.
What's the main reason for this? In the case of being a
LiteralSpecification, its type is directly combined with the value argument.
In the case of beeing a InstanceValue, the instance references a
InstanceSpecification, that points to a concrete classifier.
IMHO, there is no sense in defining the ValueSpecification as a
TypedElement, or is it for the enhancing mechanism of the metamodel?
Hope, this question isn't too silly.
-- Timothy
|
|
|
| Re: Should ValueSpecification be really a TypedElement? [message #477568 is a reply to message #477567] |
Thu, 03 July 2008 09:33  |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
--=-9KySbOAP3Q+PoKvj1WU7
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Timothy,
For me, the TypedElement-ness of ValueSpecification is most valuable
(tee hee) in the OpaqueExpression. Here, you can constrain the type for
expressions that otherwise are not interpreted by your tool.
Otherwise, for InstanceValues, there is the problem of the fact that
InstanceSpecifications can have multiple classifiers, which doesn't
match very well with the single type of a TypedElement. However, the
type of a TypedElement is optional, so I expect that often the right
thing to do is just to leave it blank.
HTH,
Christian
On Thu, 2008-07-03 at 14:42 +0200, Timothy Marc wrote:
> Hi all,
>
> after studying the values and instances concepts of the UML2 superstructure,
> i was wondering that a ValueSpecification is also inhereting TypedElement.
> What's the main reason for this? In the case of being a
> LiteralSpecification, its type is directly combined with the value argument.
> In the case of beeing a InstanceValue, the instance references a
> InstanceSpecification, that points to a concrete classifier.
> IMHO, there is no sense in defining the ValueSpecification as a
> TypedElement, or is it for the enhancing mechanism of the metamodel?
>
> Hope, this question isn't too silly.
>
> -- Timothy
>
>
--=-9KySbOAP3Q+PoKvj1WU7
Content-Type: text/html; charset=utf-8
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Timothy,<BR>
<BR>
For me, the TypedElement-ness of ValueSpecification is most valuable (tee hee) in the OpaqueExpression. Here, you can constrain the type for expressions that otherwise are not interpreted by your tool.<BR>
<BR>
Otherwise, for InstanceValues, there is the problem of the fact that InstanceSpecifications can have multiple classifiers, which doesn't match very well with the single type of a TypedElement. However, the type of a TypedElement is optional, so I expect that often the right thing to do is just to leave it blank.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Thu, 2008-07-03 at 14:42 +0200, Timothy Marc wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Hi all,</FONT>
<FONT COLOR="#000000">after studying the values and instances concepts of the UML2 superstructure, </FONT>
<FONT COLOR="#000000">i was wondering that a ValueSpecification is also inhereting TypedElement. </FONT>
<FONT COLOR="#000000">What's the main reason for this? In the case of being a </FONT>
<FONT COLOR="#000000">LiteralSpecification, its type is directly combined with the value argument. </FONT>
<FONT COLOR="#000000">In the case of beeing a InstanceValue, the instance references a </FONT>
<FONT COLOR="#000000">InstanceSpecification, that points to a concrete classifier.</FONT>
<FONT COLOR="#000000">IMHO, there is no sense in defining the ValueSpecification as a </FONT>
<FONT COLOR="#000000">TypedElement, or is it for the enhancing mechanism of the metamodel?</FONT>
<FONT COLOR="#000000">Hope, this question isn't too silly.</FONT>
<FONT COLOR="#000000">-- Timothy </FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-9KySbOAP3Q+PoKvj1WU7--
|
|
|
| Re: Should ValueSpecification be really a TypedElement? [message #626759 is a reply to message #477567] |
Thu, 03 July 2008 09:33 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
--=-9KySbOAP3Q+PoKvj1WU7
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Timothy,
For me, the TypedElement-ness of ValueSpecification is most valuable
(tee hee) in the OpaqueExpression. Here, you can constrain the type for
expressions that otherwise are not interpreted by your tool.
Otherwise, for InstanceValues, there is the problem of the fact that
InstanceSpecifications can have multiple classifiers, which doesn't
match very well with the single type of a TypedElement. However, the
type of a TypedElement is optional, so I expect that often the right
thing to do is just to leave it blank.
HTH,
Christian
On Thu, 2008-07-03 at 14:42 +0200, Timothy Marc wrote:
> Hi all,
>
> after studying the values and instances concepts of the UML2 superstructure,
> i was wondering that a ValueSpecification is also inhereting TypedElement.
> What's the main reason for this? In the case of being a
> LiteralSpecification, its type is directly combined with the value argument.
> In the case of beeing a InstanceValue, the instance references a
> InstanceSpecification, that points to a concrete classifier.
> IMHO, there is no sense in defining the ValueSpecification as a
> TypedElement, or is it for the enhancing mechanism of the metamodel?
>
> Hope, this question isn't too silly.
>
> -- Timothy
>
>
--=-9KySbOAP3Q+PoKvj1WU7
Content-Type: text/html; charset=utf-8
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Timothy,<BR>
<BR>
For me, the TypedElement-ness of ValueSpecification is most valuable (tee hee) in the OpaqueExpression. Here, you can constrain the type for expressions that otherwise are not interpreted by your tool.<BR>
<BR>
Otherwise, for InstanceValues, there is the problem of the fact that InstanceSpecifications can have multiple classifiers, which doesn't match very well with the single type of a TypedElement. However, the type of a TypedElement is optional, so I expect that often the right thing to do is just to leave it blank.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
<BR>
On Thu, 2008-07-03 at 14:42 +0200, Timothy Marc wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Hi all,</FONT>
<FONT COLOR="#000000">after studying the values and instances concepts of the UML2 superstructure, </FONT>
<FONT COLOR="#000000">i was wondering that a ValueSpecification is also inhereting TypedElement. </FONT>
<FONT COLOR="#000000">What's the main reason for this? In the case of being a </FONT>
<FONT COLOR="#000000">LiteralSpecification, its type is directly combined with the value argument. </FONT>
<FONT COLOR="#000000">In the case of beeing a InstanceValue, the instance references a </FONT>
<FONT COLOR="#000000">InstanceSpecification, that points to a concrete classifier.</FONT>
<FONT COLOR="#000000">IMHO, there is no sense in defining the ValueSpecification as a </FONT>
<FONT COLOR="#000000">TypedElement, or is it for the enhancing mechanism of the metamodel?</FONT>
<FONT COLOR="#000000">Hope, this question isn't too silly.</FONT>
<FONT COLOR="#000000">-- Timothy </FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-9KySbOAP3Q+PoKvj1WU7--
|
|
|
Goto Forum:
Current Time: Wed Jul 23 15:45:51 EDT 2025
Powered by FUDForum. Page generated in 0.03434 seconds |
Home