Object nodes

[Bill Watkins]

Two features that it would be nice to have on Object Nodes would be a
right-click menu item to "Select object's class in containment tree", and
the option to have the object's class's documentation copied into the object
node's documentation window so you don't have to manually copy it from the
class.

[Andrius Strazdauskas]

Hi,

I will add the suggestion on navigating to classifier in the containment
tree.

Regarding the documentation synchronization. We think that semantic meaning
of ObjectNode is more like a data storage, like database, the has the
information, which type is specified by Classifier. So automatically setting
the Classifier's documentation would be incorrect.

Best regards,
--
Andrius Strazdauskas
Product Research and Development Manager
No Magic Lithuanian Development Center
Savanoriu pr. 363, LT 49425 Kaunas
Phone: +370 37 705889 Fax: +370 37 320670
E-mail: andriuss
WWW: http://www.magicdraw.com
--
MagicDraw - UML Made Simple

----- Original Message -----
From: "nntp://news.nomagic.com/nomagic.products.magicdrawuml.suggestions"
<nobody-to-reply>
To: "Andrius Strazdauskas" <andrius.strazdauskas>
Sent: Friday, September 01, 2006 9:15 AM
Subject: Object nodes


> Two features that it would be nice to have on Object Nodes would be a
> right-click menu item to "Select object's class in containment tree", and
> the option to have the object's class's documentation copied into the
object
> node's documentation window so you don't have to manually copy it from the
> class.
>

[Bill Watkins]

I disagree with the "data store" analogy. I checked some UML 2 references,
and they seem to continue to support the UML 1 meaning, i.e., an object node
specifically represents an instance of some class (or "any" class), and may
be in a specific "state". The persistence or lack-thereof of the object is
not implied. (The "data store" analogy seems more appropriate to the
"central buffer node" added in UML 2.)

From the "Unified Modeling Language: Superstructure", Rev. 3 specification:"
An object node is an activity node that indicates an instance of a
particular classifier, possibly in a particular state,may be available at a
particular point in the activity."

From "Unified Modeling Language Reference Manual", 2ed, Rumbaugh, et al, pg
487, "object node", Semantics:
"An object node represents an object value that exists at a point within a
computation." ... "This represents the creation of an object of the class,
or a new object value as the result of a computation."

Bill Watkins

"Andrius Strazdauskas" <andriuss> wrote in message
news:17372285.1157119364542.JavaMail.SYSTEM@peleda...
> Hi,
>
> I will add the suggestion on navigating to classifier in the containment
> tree.
>
> Regarding the documentation synchronization. We think that semantic
> meaning
> of ObjectNode is more like a data storage, like database, the has the
> information, which type is specified by Classifier. So automatically
> setting
> the Classifier's documentation would be incorrect.
>
> Best regards,
> --
> Andrius Strazdauskas

[Nerijus Jankevicius]

Hello Bill,

Object Node is an abstract metaclass, so only subclasses can be
instantiated. There are just two cases - CentralBuffer and DataStore. Both
of them represents object node as storage of objects of some particular type
and state.
CentralBufferNode is used by default to represent "ObjectNode" in MagicDraw
(double click and check specification).

Regards,
--
Nerijus Jankevicius
System Analyst
OMG-Certified UML Professional
No Magic Lithuanian Development Center
Savanoriu pr. 363, LT 49425 Kaunas
P.O. box 2166, LT- 3000, Kaunas
Phone: +370-37-324032 Fax: +370-37-320670
e-mail: nerijus
WWW: http://www.magicdraw.com


----- Original Message -----
From: "nntp://news.nomagic.com/nomagic.products.magicdrawuml.suggestions"
<nobody-to-reply>
To: "Nerijus Jankevicius" <nerijus>
Sent: Monday, September 04, 2006 9:48 AM
Subject: Re: Object nodes


>I disagree with the "data store" analogy. I checked some UML 2 references,
> and they seem to continue to support the UML 1 meaning, i.e., an object
> node
> specifically represents an instance of some class (or "any" class), and
> may
> be in a specific "state". The persistence or lack-thereof of the object
> is
> not implied. (The "data store" analogy seems more appropriate to the
> "central buffer node" added in UML 2.)

[Bill Watkins]

Thanks for the follow-up. I see that the UML 2 standard indeed refers to an
object node as an "abstract activity node", but I don't have access to an
actual metamodel to see what this means. The problem is, the idea that
there is no such thing as a concrete object node per se, is contrary to
everything I've read in UML2 references about what an object node is
supposed to represent. Everything I've read indicates that an object node
by itself is supposed to represent an instance of an object, possibly typed
and in a state, that is passed between actions. None of the texts, e.g.,
"Unified Modeling Language Reference Manual", 2nd Ed., Rumbaugh et al, treat
Object Node as an abstract class in and of itself, but rather, they all talk
about it as something distinct, without the central buffer node or datastore
semantics that the subclasses provide.

To carry the confusion further, Rumbaugh says specifically in the
description of Central Buffer Nodes, "Flows from central buffer nodes do not
connect directly to actions." MagicDraw does allow this.

As I said, I don't have access to the metamodel, but is it possible that an
"abstract activity node" is actually supposed to be an actual symbol like
"abstract_activity_node", e.g., "an object node is-a
abstract_activity_node", instead of being intepreted as "an object node is
an abstract activity_node"? I can't offhand think of any other reason why
the interpretations are so different, or why there would even be an "object
node" class that was itself abstract and that had only one direct child.

Thanks for your patience,
Bill Watkins

"Nerijus Jankevicius" <nerijus> wrote in message
news:19708320.1157353938877.JavaMail.SYSTEM@peleda...
> Hello Bill,
>
> Object Node is an abstract metaclass, so only subclasses can be
> instantiated. There are just two cases - CentralBuffer and DataStore. Both
> of them represents object node as storage of objects of some particular
> type and state.
> CentralBufferNode is used by default to represent "ObjectNode" in
> MagicDraw (double click and check specification).
>
> Regards,
> --
> Nerijus Jankevicius
> System Analyst
> OMG-Certified UML Professional
> No Magic Lithuanian Development Center
> Savanoriu pr. 363, LT 49425 Kaunas
> P.O. box 2166, LT- 3000, Kaunas
> Phone: +370-37-324032 Fax: +370-37-320670
> e-mail: nerijus
> WWW: http://www.magicdraw.com
>
>

[Bill Watkins]

Just to follow-up, we've found two other tools that appear to agree with
your interpretation of the metamodel. I'm still trying to find out why the
tool vendors are reading something different into the metamodel than most
authors seem to see.

Thanks,
Bill Watkins

[Nerijus Jankevicius]

Hello Bill,

I agree, that simple ObjectNode element would be usable and more intuitive.
Now we must hide CentralBuffer under name "ObjectNode".
Our metamodel implementation is generated from OMG provided UML metamodel
automatically, and ObjectNode metaclass is really abstract and can't be
instantiated.
I will try to discuss this issue in UML 2 RTF group.
Thanks for your remarks.

Regards,
--
Nerijus Jankevicius
System Analyst
OMG-Certified UML Professional
No Magic Lithuanian Development Center
Savanoriu pr. 363, LT 49425 Kaunas
P.O. box 2166, LT- 3000, Kaunas
Phone: +370-37-324032 Fax: +370-37-320670
e-mail: nerijus
WWW: http://www.magicdraw.com


----- Original Message -----
From: "nntp://news.nomagic.com/nomagic.products.magicdrawuml.suggestions"
<nobody-to-reply>
To: "Nerijus Jankevicius" <nerijus>
Sent: Wednesday, September 13, 2006 12:00 PM
Subject: Re: Object nodes


> Just to follow-up, we've found two other tools that appear to agree with
> your interpretation of the metamodel. I'm still trying to find out why
> the
> tool vendors are reading something different into the metamodel than most
> authors seem to see.
>
> Thanks,
> Bill Watkins
>

[Bill Watkins]

Thanks!