Issue 10823: names and namespaces (uml2-rtf) Source: No Magic, Inc. (Mr. Nerijus Jankevicius, nerijus(at)nomagic.com) Nature: Uncategorized Issue Severity: Summary: Namespace defines derived "member" collection for NamedElements identifiable by name. However not all Namespaces subset this collection, so NamedElements are added just to ownedElements. Example: Activity and ActivityNodes. Actions and ObjectNodes could have identical names because they are not added into "ownedMember" collection and are not identified by name. Is this correct or bug in metamodel? I believe we could find more such Namespaces. Resolution: Revised Text: Actions taken: March 14, 2007: received issue Discussion: End of Annotations:===== m: "Nerijus Jankevicius" To: Subject: names and namespaces Date: Wed, 14 Mar 2007 10:21:10 +0200 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org Hello, Namespace defines derived "member" collection for NamedElements identifiable by name. However not all Namespaces subset this collection, so NamedElements are added just to ownedElements. Example: Activity and ActivityNodes. Actions and ObjectNodes could have identical names because they are not added into "ownedMember" collection and are not identified by name. Is this correct or bug in metamodel? I believe we could find more such Namespaces. Thanks. -- 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@magicdraw.com WWW: http://www.magicdraw.com Subject: RE: names and namespaces Date: Thu, 15 Mar 2007 08:14:42 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: names and namespaces Thread-index: AcdmErANZqVRk2DWTr2b2pCdfSRmtAAvsS8A From: "Tim Weilkiens" To: "Nerijus Jankevicius" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l2F8Dvru027278 Hi Nerijus, I think you're right. ActivityNode should subset ownedMember instead of ownedElement. Could you file an issue? Tim ----------------------------------------------------------------- Tim Weilkiens Consultant, Instructor OMG Representative, INCOSE member oose Innovative Informatik GmbH Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 CEO Bernd Schröder-Oestereich, Christian Weiss Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 Internet: www.oose.de, E-Mail: office@oose.de > -----Original Message----- > From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] > Sent: Wednesday, March 14, 2007 9:21 AM > To: uml2-rtf@omg.org > Subject: names and namespaces > > Hello, > > Namespace defines derived "member" collection for > NamedElements identifiable by name. > However not all Namespaces subset this collection, so > NamedElements are added just to ownedElements. > > Example: Activity and ActivityNodes. Actions and ObjectNodes > could have identical names because they are not added into > "ownedMember" collection and are not identified by name. > Is this correct or bug in metamodel? I believe we could find > more such Namespaces. > > Thanks. > -- > 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@magicdraw.com > WWW: http://www.magicdraw.com > > Subject: RE: names and namespaces Date: Thu, 15 Mar 2007 11:23:21 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: names and namespaces thread-index: AcdmErANZqVRk2DWTr2b2pCdfSRmtAAvsS8AABDBhMA= From: "Ed Seidewitz" To: "Tim Weilkiens" , "Nerijus Jankevicius" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l2FGMa7H028979 I think we need to be careful here. A namespace requires that all the owned members in it be "distinguishable". This usually means they all have different names (unless they can be otherwise distinguished by type or signature). Now, the name of an activity node has no formal meaning, but it is very common for people to use the name in a tool as a way to describe visually the behavior of the activity node -- particularly in an informal model when all the pins and edges may not be in place. It is not uncommon to use shorthands like "Call X" for the name of a call behavior action on behavior X. But, if the activity was the namespace for it activity nodes, one would seemingly not be able to have to activity nodes with the same name "Call X". Then you would have to use some arbitrary convention like "Call X (1)" and "Call X (2)", which is annoying. I actually had this happen to me back in the old days when using Rose for informal activity modeling. We entered the description of the required behavior as the name of each action. But Rose did not allow two actions in an activity to have the same name, so if there were two with the same behavioral description, we had a conflict. So, I don't think that just because something is a namespace, all of its owned elements have to be owned members. In the case of activity, it is a namespace because it is a kind behavior which is a kind of class, and so it is a namespace for the attributes and operations defined in it. That doesn't mean it has to be a namespace for its activity nodes. We similarly look carefully at other cases that may exist before deciding to make owned elements into owned members. -- Ed > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Thursday, March 15, 2007 3:15 AM > To: Nerijus Jankevicius; uml2-rtf@omg.org > Subject: RE: names and namespaces > > Hi Nerijus, > > I think you're right. ActivityNode should subset ownedMember instead > of ownedElement. Could you file an issue? > > Tim > > ----------------------------------------------------------------- > Tim Weilkiens > Consultant, Instructor > OMG Representative, INCOSE member > > oose Innovative Informatik GmbH > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany > HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 > CEO Bernd Schröder-Oestereich, Christian Weiss > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > Internet: www.oose.de, E-Mail: office@oose.de > > > > -----Original Message----- > > From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > Sent: Wednesday, March 14, 2007 9:21 AM > > To: uml2-rtf@omg.org > > Subject: names and namespaces > > > > Hello, > > > > Namespace defines derived "member" collection for > > NamedElements identifiable by name. > > However not all Namespaces subset this collection, so > > NamedElements are added just to ownedElements. > > > > Example: Activity and ActivityNodes. Actions and ObjectNodes > > could have identical names because they are not added into > > "ownedMember" collection and are not identified by name. > > Is this correct or bug in metamodel? I believe we could find > > more such Namespaces. > > > > Thanks. > > -- > > 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@magicdraw.com > > WWW: http://www.magicdraw.com > > > > > Subject: RE: names and namespaces Date: Thu, 15 Mar 2007 16:11:54 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: names and namespaces Thread-Index: AcdmErANZqVRk2DWTr2b2pCdfSRmtAAvsS8AABDBhMAAClEVcA== From: "Ed Seidewitz" To: "Tim Weilkiens" , "Nerijus Jankevicius" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l2FLB6r0010703 While I was looking up something else, I happened to notice the following in the UML spec, which is relevant to the point I was making. This is from the beginning of the Semantics part of Section 12.3.8 on ActivityNode: "Nodes can be named, however, nodes are not required to have unique names within an activity to support multiple invocations of the same behavior or multiple uses of the same action. See Action, which is a kind of node. The fact that Activity is a Namespace, inherited through Behavior, does not affect this, because the containment of nodes is through ownedElement, the general ownership metaassociation for Element that does not imply unique names, rather than ownedMember." So, in this case at least, the use of ownedElement, not ownedMember, was really intentional, for exactly the reason I suggested. -- Ed > -----Original Message----- > From: Ed Seidewitz > Sent: Thursday, March 15, 2007 11:23 AM > To: 'Tim Weilkiens'; Nerijus Jankevicius; uml2-rtf@omg.org > Subject: RE: names and namespaces > > I think we need to be careful here. > > A namespace requires that all the owned members in it be > "distinguishable". This usually means they all have different > names (unless they can be otherwise distinguished by type or > signature). Now, the name of an activity node has no formal > meaning, but it is very common for people to use the name in > a tool as a way to describe visually the behavior of the > activity node -- particularly in an informal model when all > the pins and edges may not be in place. It is not uncommon to > use shorthands like "Call X" for the name of a call behavior > action on behavior X. But, if the activity was the namespace > for it activity nodes, one would seemingly not be able to > have to activity nodes with the same name "Call X". Then you > would have to use some arbitrary convention like "Call X (1)" > and "Call X (2)", which is annoying. > > I actually had this happen to me back in the old days when > using Rose for informal activity modeling. We entered the > description of the required behavior as the name of each > action. But Rose did not allow two actions in an activity to > have the same name, so if there were two with the same > behavioral description, we had a conflict. > > So, I don't think that just because something is a namespace, > all of its owned elements have to be owned members. In the > case of activity, it is a namespace because it is a kind > behavior which is a kind of class, and so it is a namespace > for the attributes and operations defined in it. That doesn't > mean it has to be a namespace for its activity nodes. > > We similarly look carefully at other cases that may exist > before deciding to make owned elements into owned members. > > -- Ed > > > -----Original Message----- > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > Sent: Thursday, March 15, 2007 3:15 AM > > To: Nerijus Jankevicius; uml2-rtf@omg.org > > Subject: RE: names and namespaces > > > > Hi Nerijus, > > > > I think you're right. ActivityNode should subset ownedMember instead > > of ownedElement. Could you file an issue? > > > > Tim > > > > ----------------------------------------------------------------- > > Tim Weilkiens > > Consultant, Instructor > > OMG Representative, INCOSE member > > > > oose Innovative Informatik GmbH > > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany > > HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 > > CEO Bernd Schröder-Oestereich, Christian Weiss > > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > > Internet: www.oose.de, E-Mail: office@oose.de > > > > > > > -----Original Message----- > > > From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > > Sent: Wednesday, March 14, 2007 9:21 AM > > > To: uml2-rtf@omg.org > > > Subject: names and namespaces > > > > > > Hello, > > > > > > Namespace defines derived "member" collection for > > > NamedElements identifiable by name. > > > However not all Namespaces subset this collection, so > > > NamedElements are added just to ownedElements. > > > > > > Example: Activity and ActivityNodes. Actions and ObjectNodes > > > could have identical names because they are not added into > > > "ownedMember" collection and are not identified by name. > > > Is this correct or bug in metamodel? I believe we could find > > > more such Namespaces. > > > > > > Thanks. > > > -- > > > 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@magicdraw.com > > > WWW: http://www.magicdraw.com > > > > > > > > DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=B5NGIzdSpLA6XFriuyiB4Gn7VBTqGwn5+VkUV3nWbBZaX/bc+ZGU7CcnhDcG/p0cD1aDC07TWh4L3LuCKGab1zNIDxMw/Rssm6PyfSDYV+5BzxbjC2Llzr5I/F326z77WbDR93Dkdy56tEuF2AfY5eO1hvrtylgpFFE/EwNbvSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FMN13akp9ulnsBrBny3L+euFilTKBAi1meIRnSNrqKF51SqzaKh8DMOlAC+1X+zo7HsgvCrM8WaNEWryUMvxwFcjCCA7UYqnjFqvCLzwHgZe6q+IiOskByiMKPozYCu5znHO/QqNExGF4ePsLb0+90ZL6fwHXztoMoXzpQJg4Lo= Date: Thu, 15 Mar 2007 21:53:16 -0400 From: "Karl Frank" To: "Ed Seidewitz" Subject: Re: names and namespaces Cc: "Tim Weilkiens" , "Nerijus Jankevicius" , uml2-rtf@omg.org X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l2G2qMb3025903 Interesting, but imo this reveals the ubiquitous nature of the defect, rather than showing why there is no defect. So, as Ed has discovered, a specialization of NameSpace can choose to ignore the fact that its generallization redefined the ownedElement metassociation, and revert to the ancestral ownedElement! This means redefinition is always implicitly partial and leaky, and whether it applies in any given case is up to the metamodel author. There is always a secret unredefined ancestral metaassociation lurking in the background throughout the inheritance hierarchy of the metamodel, which one can call upon to get around the strictures of specialization! - Karl On 3/15/07, Ed Seidewitz wrote: While I was looking up something else, I happened to notice the following in the UML spec, which is relevant to the point I was making. This is from the beginning of the Semantics part of Section 12.3.8 on ActivityNode: "Nodes can be named, however, nodes are not required to have unique names within an activity to support multiple invocations of the same behavior or multiple uses of the same action. See Action, which is a kind of node. The fact that Activity is a Namespace, inherited through Behavior, does not affect this, because the containment of nodes is through ownedElement, the general ownership metaassociation for Element that does not imply unique names, rather than ownedMember." So, in this case at least, the use of ownedElement, not ownedMember, was really intentional, for exactly the reason I suggested. -- Ed > -----Original Message----- > From: Ed Seidewitz > Sent: Thursday, March 15, 2007 11:23 AM > To: 'Tim Weilkiens'; Nerijus Jankevicius; uml2-rtf@omg.org > Subject: RE: names and namespaces > > I think we need to be careful here. > > A namespace requires that all the owned members in it be > "distinguishable". This usually means they all have different > names (unless they can be otherwise distinguished by type or > signature). Now, the name of an activity node has no formal > meaning, but it is very common for people to use the name in > a tool as a way to describe visually the behavior of the > activity node -- particularly in an informal model when all > the pins and edges may not be in place. It is not uncommon to > use shorthands like "Call X" for the name of a call behavior > action on behavior X. But, if the activity was the namespace > for it activity nodes, one would seemingly not be able to > have to activity nodes with the same name "Call X". Then you > would have to use some arbitrary convention like "Call X (1)" > and "Call X (2)", which is annoying. > > I actually had this happen to me back in the old days when > using Rose for informal activity modeling. We entered the > description of the required behavior as the name of each > action. But Rose did not allow two actions in an activity to > have the same name, so if there were two with the same > behavioral description, we had a conflict. > > So, I don't think that just because something is a namespace, > all of its owned elements have to be owned members. In the > case of activity, it is a namespace because it is a kind > behavior which is a kind of class, and so it is a namespace > for the attributes and operations defined in it. That doesn't > mean it has to be a namespace for its activity nodes. > > We similarly look carefully at other cases that may exist > before deciding to make owned elements into owned members. > > -- Ed > > > -----Original Message----- > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > Sent: Thursday, March 15, 2007 3:15 AM > > To: Nerijus Jankevicius; uml2-rtf@omg.org > > Subject: RE: names and namespaces > > > > Hi Nerijus, > > > > I think you're right. ActivityNode should subset ownedMember instead > > of ownedElement. Could you file an issue? > > > > Tim > > > > ----------------------------------------------------------------- > > Tim Weilkiens > > Consultant, Instructor > > OMG Representative, INCOSE member > > > > oose Innovative Informatik GmbH > > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 Hamburg, Germany > > HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 > > CEO Bernd Schröder-Oestereich, Christian Weiss > > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > > Internet: www.oose.de, E-Mail: office@oose.de > > > > > > > -----Original Message----- > > > From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > > Sent: Wednesday, March 14, 2007 9:21 AM > > > To: uml2-rtf@omg.org > > > Subject: names and namespaces > > > > > > Hello, > > > > > > Namespace defines derived "member" collection for > > > NamedElements identifiable by name. > > > However not all Namespaces subset this collection, so > > > NamedElements are added just to ownedElements. > > > > > > Example: Activity and ActivityNodes. Actions and ObjectNodes > > > could have identical names because they are not added into > > > "ownedMember" collection and are not identified by name. > > > Is this correct or bug in metamodel? I believe we could find > > > more such Namespaces. > > > > > > Thanks. > > > -- > > > 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@magicdraw.com > > > WWW: http://www.magicdraw.com > > > > > > > > Subject: RE: names and namespaces Date: Fri, 16 Mar 2007 11:31:58 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: names and namespaces Thread-Index: Acdnbd5Qul7XEc7sQ4uMGnPiDEIzeAAcKEEA From: "Ed Seidewitz" To: "Karl Frank" Cc: "Tim Weilkiens" , "Nerijus Jankevicius" , X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l2GGV7Xp002538 Karl-- ownedMember is not a redefinition of ownedElement, it is a subset. ownedMember and ownedElement are actually two separate properties of Namespace, such that all ownedMembers of a Namespace are ownedElements, but _not_ vice versa. Looked at the other way around, ownedElement is a derived union of all the properties of subclasses of Element that are declared to be subsets of ownedElement. Namespace::ownedMember is only one such subset. Activity::node is declared to be another such subset, a disjoint peer to the ownedMember subset inherited by Activity from Namespace. So, there is nothing semantically dubious about this. One could argue that ownedMember _should_ have been a redefinition of ownedElement, rather than a subset, but that is another matter. Clearly, there were some specific reasons that it was not. (Also, note that the semantics of redefinition is actually rather more ambiguous in UML 2 than the semantics of derived union, and varies based on the kind of element being redefined.) (By the way, I believe a similar point came up not too long ago, having to do with the fact that the input and output properties of an Action don't, just by the reason of their existence, catch all the InputPins and OutputPins that might be attached to the Action. They are just unions of those properties of subclasses of Action that are specifically declared to be subsets of input and output. It is therefore important that the model for each individual action so declare any associations it has with InputPins and/or OutputPins.) -- Ed > -----Original Message----- > From: Karl Frank [mailto:karl.karolus@gmail.com] > Sent: Thursday, March 15, 2007 9:53 PM > To: Ed Seidewitz > Cc: Tim Weilkiens; Nerijus Jankevicius; uml2-rtf@omg.org > Subject: Re: names and namespaces > > Interesting, but imo this reveals the ubiquitous nature of the defect, > rather than showing why there is no defect. > > So, as Ed has discovered, a specialization of NameSpace can choose to > ignore the fact that its generallization redefined the ownedElement > metassociation, and revert to the ancestral ownedElement! > > This means redefinition is always implicitly partial and leaky, and > whether it applies in any given case is up to the metamodel author. > There is always a secret unredefined ancestral metaassociation lurking > in the background throughout the inheritance hierarchy of the > metamodel, which one can call upon to get around the strictures of > specialization! > > - Karl > > On 3/15/07, Ed Seidewitz wrote: > > While I was looking up something else, I happened to notice > the following in the UML spec, which is relevant to the point > I was making. This is from the beginning of the Semantics > part of Section 12.3.8 on ActivityNode: > > > > "Nodes can be named, however, nodes are not required to > have unique names within an activity to support multiple > > invocations of the same behavior or multiple uses of the > same action. See Action, which is a kind of node. The fact that > > Activity is a Namespace, inherited through Behavior, does > not affect this, because the containment of nodes is through > > ownedElement, the general ownership metaassociation for > Element that does not imply unique names, rather than > > ownedMember." > > > > So, in this case at least, the use of ownedElement, not > ownedMember, was really intentional, for exactly the reason I > suggested. > > > > -- Ed > > > > > > > -----Original Message----- > > > From: Ed Seidewitz > > > Sent: Thursday, March 15, 2007 11:23 AM > > > To: 'Tim Weilkiens'; Nerijus Jankevicius; uml2-rtf@omg.org > > > Subject: RE: names and namespaces > > > > > > I think we need to be careful here. > > > > > > A namespace requires that all the owned members in it be > > > "distinguishable". This usually means they all have different > > > names (unless they can be otherwise distinguished by type or > > > signature). Now, the name of an activity node has no formal > > > meaning, but it is very common for people to use the name in > > > a tool as a way to describe visually the behavior of the > > > activity node -- particularly in an informal model when all > > > the pins and edges may not be in place. It is not uncommon to > > > use shorthands like "Call X" for the name of a call behavior > > > action on behavior X. But, if the activity was the namespace > > > for it activity nodes, one would seemingly not be able to > > > have to activity nodes with the same name "Call X". Then you > > > would have to use some arbitrary convention like "Call X (1)" > > > and "Call X (2)", which is annoying. > > > > > > I actually had this happen to me back in the old days when > > > using Rose for informal activity modeling. We entered the > > > description of the required behavior as the name of each > > > action. But Rose did not allow two actions in an activity to > > > have the same name, so if there were two with the same > > > behavioral description, we had a conflict. > > > > > > So, I don't think that just because something is a namespace, > > > all of its owned elements have to be owned members. In the > > > case of activity, it is a namespace because it is a kind > > > behavior which is a kind of class, and so it is a namespace > > > for the attributes and operations defined in it. That doesn't > > > mean it has to be a namespace for its activity nodes. > > > > > > We similarly look carefully at other cases that may exist > > > before deciding to make owned elements into owned members. > > > > > > -- Ed > > > > > > > -----Original Message----- > > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > > Sent: Thursday, March 15, 2007 3:15 AM > > > > To: Nerijus Jankevicius; uml2-rtf@omg.org > > > > Subject: RE: names and namespaces > > > > > > > > Hi Nerijus, > > > > > > > > I think you're right. ActivityNode should subset > ownedMember instead > > > > of ownedElement. Could you file an issue? > > > > > > > > Tim > > > > > > > > > ----------------------------------------------------------------- > > > > Tim Weilkiens > > > > Consultant, Instructor > > > > OMG Representative, INCOSE member > > > > > > > > oose Innovative Informatik GmbH > > > > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 > Hamburg, Germany > > > > HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 > > > > CEO Bernd Schröder-Oestereich, Christian Weiss > > > > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > > > > Internet: www.oose.de, E-Mail: office@oose.de > > > > > > > > > > > > > -----Original Message----- > > > > > From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > > > > Sent: Wednesday, March 14, 2007 9:21 AM > > > > > To: uml2-rtf@omg.org > > > > > Subject: names and namespaces > > > > > > > > > > Hello, > > > > > > > > > > Namespace defines derived "member" collection for > > > > > NamedElements identifiable by name. > > > > > However not all Namespaces subset this collection, so > > > > > NamedElements are added just to ownedElements. > > > > > > > > > > Example: Activity and ActivityNodes. Actions and ObjectNodes > > > > > could have identical names because they are not added into > > > > > "ownedMember" collection and are not identified by name. > > > > > Is this correct or bug in metamodel? I believe we could find > > > > > more such Namespaces. > > > > > > > > > > Thanks. > > > > > -- > > > > > 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@magicdraw.com > > > > > WWW: http://www.magicdraw.com > > > > > > > > > > > > > > > > > DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jZ5skf78KxKRQ30iPfj/DiCYOxQaXJ93dnSEhWrorRW1MarzocRO870sp99qI4BDOPSZjvz3X6Mg5ljb6W7q0bwI4bsb4G5q9juewb1bhSsiP1S00FuWyOIOOmZFTbwjZClfeASY9gE2To+Uk1nhA4KdU7juzMOXJpeZI4DEC6I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XtMO7wYyezg/3TOMMt+Yu1yD83CnIBFbUdtz7RtXNc768gKqp28LSl9XQaCfzBJEesr7DvciUFZf8nrkkom1CVk/9NrHWY+wsbM1wVmXkk4m7q+KQ4L6hBzU8YGlHk1uo2qknTpirX4HLr5zbGpxMjGqeflfGJAkk6qZ3nyHCIc= Date: Fri, 16 Mar 2007 12:34:12 -0400 From: "Karl Frank" To: "Ed Seidewitz" Subject: Re: names and namespaces Cc: "Tim Weilkiens" , "Nerijus Jankevicius" , uml2-rtf@omg.org X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l2GHXNDh026993 Your point is well taken. Sorry to have missed the important diff, that it is as you say not a redefinition. - Karl On 3/16/07, Ed Seidewitz wrote: Karl-- ownedMember is not a redefinition of ownedElement, it is a subset. ownedMember and ownedElement are actually two separate properties of Namespace, such that all ownedMembers of a Namespace are ownedElements, but _not_ vice versa. Looked at the other way around, ownedElement is a derived union of all the properties of subclasses of Element that are declared to be subsets of ownedElement. Namespace::ownedMember is only one such subset. Activity::node is declared to be another such subset, a disjoint peer to the ownedMember subset inherited by Activity from Namespace. So, there is nothing semantically dubious about this. One could argue that ownedMember _should_ have been a redefinition of ownedElement, rather than a subset, but that is another matter. Clearly, there were some specific reasons that it was not. (Also, note that the semantics of redefinition is actually rather more ambiguous in UML 2 than the semantics of derived union, and varies based on the kind of element being redefined.) (By the way, I believe a similar point came up not too long ago, having to do with the fact that the input and output properties of an Action don't, just by the reason of their existence, catch all the InputPins and OutputPins that might be attached to the Action. They are just unions of those properties of subclasses of Action that are specifically declared to be subsets of input and output. It is therefore important that the model for each individual action so declare any associations it has with InputPins and/or OutputPins.) -- Ed > -----Original Message----- > From: Karl Frank [mailto:karl.karolus@gmail.com] > Sent: Thursday, March 15, 2007 9:53 PM > To: Ed Seidewitz > Cc: Tim Weilkiens; Nerijus Jankevicius; uml2-rtf@omg.org > Subject: Re: names and namespaces > > Interesting, but imo this reveals the ubiquitous nature of the defect, > rather than showing why there is no defect. > > So, as Ed has discovered, a specialization of NameSpace can choose to > ignore the fact that its generallization redefined the ownedElement > metassociation, and revert to the ancestral ownedElement! > > This means redefinition is always implicitly partial and leaky, and > whether it applies in any given case is up to the metamodel author. > There is always a secret unredefined ancestral metaassociation lurking > in the background throughout the inheritance hierarchy of the > metamodel, which one can call upon to get around the strictures of > specialization! > > - Karl > > On 3/15/07, Ed Seidewitz wrote: > > While I was looking up something else, I happened to notice > the following in the UML spec, which is relevant to the point > I was making. This is from the beginning of the Semantics > part of Section 12.3.8 on ActivityNode: > > > > "Nodes can be named, however, nodes are not required to > have unique names within an activity to support multiple > > invocations of the same behavior or multiple uses of the > same action. See Action, which is a kind of node. The fact that > > Activity is a Namespace, inherited through Behavior, does > not affect this, because the containment of nodes is through > > ownedElement, the general ownership metaassociation for > Element that does not imply unique names, rather than > > ownedMember." > > > > So, in this case at least, the use of ownedElement, not > ownedMember, was really intentional, for exactly the reason I > suggested. > > > > -- Ed > > > > > > > -----Original Message----- > > > From: Ed Seidewitz > > > Sent: Thursday, March 15, 2007 11:23 AM > > > To: 'Tim Weilkiens'; Nerijus Jankevicius; uml2-rtf@omg.org > > > Subject: RE: names and namespaces > > > > > > I think we need to be careful here. > > > > > > A namespace requires that all the owned members in it be > > > "distinguishable". This usually means they all have different > > > names (unless they can be otherwise distinguished by type or > > > signature). Now, the name of an activity node has no formal > > > meaning, but it is very common for people to use the name in > > > a tool as a way to describe visually the behavior of the > > > activity node -- particularly in an informal model when all > > > the pins and edges may not be in place. It is not uncommon to > > > use shorthands like "Call X" for the name of a call behavior > > > action on behavior X. But, if the activity was the namespace > > > for it activity nodes, one would seemingly not be able to > > > have to activity nodes with the same name "Call X". Then you > > > would have to use some arbitrary convention like "Call X (1)" > > > and "Call X (2)", which is annoying. > > > > > > I actually had this happen to me back in the old days when > > > using Rose for informal activity modeling. We entered the > > > description of the required behavior as the name of each > > > action. But Rose did not allow two actions in an activity to > > > have the same name, so if there were two with the same > > > behavioral description, we had a conflict. > > > > > > So, I don't think that just because something is a namespace, > > > all of its owned elements have to be owned members. In the > > > case of activity, it is a namespace because it is a kind > > > behavior which is a kind of class, and so it is a namespace > > > for the attributes and operations defined in it. That doesn't > > > mean it has to be a namespace for its activity nodes. > > > > > > We similarly look carefully at other cases that may exist > > > before deciding to make owned elements into owned members. > > > > > > -- Ed > > > > > > > -----Original Message----- > > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > > Sent: Thursday, March 15, 2007 3:15 AM > > > > To: Nerijus Jankevicius; uml2-rtf@omg.org > > > > Subject: RE: names and namespaces > > > > > > > > Hi Nerijus, > > > > > > > > I think you're right. ActivityNode should subset > ownedMember instead > > > > of ownedElement. Could you file an issue? > > > > > > > > Tim > > > > > > > > > ----------------------------------------------------------------- > > > > Tim Weilkiens > > > > Consultant, Instructor > > > > OMG Representative, INCOSE member > > > > > > > > oose Innovative Informatik GmbH > > > > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 > Hamburg, Germany > > > > HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 > > > > CEO Bernd Schröder-Oestereich, Christian Weiss > > > > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > > > > Internet: www.oose.de, E-Mail: office@oose.de > > > > > > > > > > > > > -----Original Message----- > > > > > From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > > > > Sent: Wednesday, March 14, 2007 9:21 AM > > > > > To: uml2-rtf@omg.org > > > > > Subject: names and namespaces > > > > > > > > > > Hello, > > > > > > > > > > Namespace defines derived "member" collection for > > > > > NamedElements identifiable by name. > > > > > However not all Namespaces subset this collection, so > > > > > NamedElements are added just to ownedElements. > > > > > > > > > > Example: Activity and ActivityNodes. Actions and ObjectNodes > > > > > could have identical names because they are not added into > > > > > "ownedMember" collection and are not identified by name. > > > > > Is this correct or bug in metamodel? I believe we could find > > > > > more such Namespaces. > > > > > > > > > > Thanks. > > > > > -- > > > > > 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@magicdraw.com > > > > > WWW: http://www.magicdraw.com > > > > > > > > > > > > > > > > > From: ericson_george@emc.com Subject: RE: names and namespaces Date: Fri, 16 Mar 2007 12:50:14 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: names and namespaces Thread-Index: Acdnbd5Qul7XEc7sQ4uMGnPiDEIzeAAcKEEAAAIe0SA= To: , Cc: , , X-OriginalArrivalTime: 16 Mar 2007 16:50:16.0140 (UTC) FILETIME=[2C4A70C0:01C767EB] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.16.92433 X-PerlMx-Spam: Gauge=, SPAM=1%, Reason='EMC_FROM_0+ -3, SUPERLONG_LINE 0.05, NO_REAL_NAME 0, __CP_MEDIA_2_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org This discussion reminds me of a question based on the following: Subset is documented as being equivalent to subclassing: "The constraint {subsets endA} means that the association end to which this constraint is applied is a specialization of association end endA that is part of the association being specialized." I'm not sure I fully understand what the above means in a formal sense. To illustrate: Given classes C1 and C2 with association between them having roles c1 and c2. And further class C3 with association between it and C1 with roles c3 and c4. Then we have two associations A_c1_c2 and A_c1_c3. If c3 subsets c2, then the definition above asserts: A_c1_c3 is a subclass of A_c1_c2 c3 is a subclass of c2 Question: Are both of the above correct? Question: Is there any relationship between A_c1_c3.c1 and A_c1_c3.c1? George -----Original Message----- From: Ed Seidewitz [mailto:ed-s@enterprisecomponent.com] Sent: Friday, March 16, 2007 11:32 AM To: Karl Frank Cc: Tim Weilkiens; Nerijus Jankevicius; uml2-rtf@omg.org Subject: RE: names and namespaces Karl-- ownedMember is not a redefinition of ownedElement, it is a subset. ownedMember and ownedElement are actually two separate properties of Namespace, such that all ownedMembers of a Namespace are ownedElements, but _not_ vice versa. Looked at the other way around, ownedElement is a derived union of all the properties of subclasses of Element that are declared to be subsets of ownedElement. Namespace::ownedMember is only one such subset. Activity::node is declared to be another such subset, a disjoint peer to the ownedMember subset inherited by Activity from Namespace. So, there is nothing semantically dubious about this. One could argue that ownedMember _should_ have been a redefinition of ownedElement, rather than a subset, but that is another matter. Clearly, there were some specific reasons that it was not. (Also, note that the semantics of redefinition is actually rather more ambiguous in UML 2 than the semantics of derived union, and varies based on the kind of element being redefined.) (By the way, I believe a similar point came up not too long ago, having to do with the fact that the input and output properties of an Action don't, just by the reason of their existence, catch all the InputPins and OutputPins that might be attached to the Action. They are just unions of those properties of subclasses of Action that are specifically declared to be subsets of input and output. It is therefore important that the model for each individual action so declare any associations it has with InputPins and/or OutputPins.) -- Ed > -----Original Message----- > From: Karl Frank [mailto:karl.karolus@gmail.com] > Sent: Thursday, March 15, 2007 9:53 PM > To: Ed Seidewitz > Cc: Tim Weilkiens; Nerijus Jankevicius; uml2-rtf@omg.org > Subject: Re: names and namespaces > > Interesting, but imo this reveals the ubiquitous nature of the defect, > rather than showing why there is no defect. > > So, as Ed has discovered, a specialization of NameSpace can choose to > ignore the fact that its generallization redefined the ownedElement > metassociation, and revert to the ancestral ownedElement! > > This means redefinition is always implicitly partial and leaky, and > whether it applies in any given case is up to the metamodel author. > There is always a secret unredefined ancestral metaassociation lurking > in the background throughout the inheritance hierarchy of the > metamodel, which one can call upon to get around the strictures of > specialization! > > - Karl > > On 3/15/07, Ed Seidewitz wrote: > > While I was looking up something else, I happened to notice > the following in the UML spec, which is relevant to the point > I was making. This is from the beginning of the Semantics > part of Section 12.3.8 on ActivityNode: > > > > "Nodes can be named, however, nodes are not required to > have unique names within an activity to support multiple > > invocations of the same behavior or multiple uses of the > same action. See Action, which is a kind of node. The fact that > > Activity is a Namespace, inherited through Behavior, does > not affect this, because the containment of nodes is through > > ownedElement, the general ownership metaassociation for > Element that does not imply unique names, rather than > > ownedMember." > > > > So, in this case at least, the use of ownedElement, not > ownedMember, was really intentional, for exactly the reason I > suggested. > > > > -- Ed > > > > > > > -----Original Message----- > > > From: Ed Seidewitz > > > Sent: Thursday, March 15, 2007 11:23 AM > > > To: 'Tim Weilkiens'; Nerijus Jankevicius; uml2-rtf@omg.org > > > Subject: RE: names and namespaces > > > > > > I think we need to be careful here. > > > > > > A namespace requires that all the owned members in it be > > > "distinguishable". This usually means they all have different > > > names (unless they can be otherwise distinguished by type or > > > signature). Now, the name of an activity node has no formal > > > meaning, but it is very common for people to use the name in > > > a tool as a way to describe visually the behavior of the > > > activity node -- particularly in an informal model when all > > > the pins and edges may not be in place. It is not uncommon to > > > use shorthands like "Call X" for the name of a call behavior > > > action on behavior X. But, if the activity was the namespace > > > for it activity nodes, one would seemingly not be able to > > > have to activity nodes with the same name "Call X". Then you > > > would have to use some arbitrary convention like "Call X (1)" > > > and "Call X (2)", which is annoying. > > > > > > I actually had this happen to me back in the old days when > > > using Rose for informal activity modeling. We entered the > > > description of the required behavior as the name of each > > > action. But Rose did not allow two actions in an activity to > > > have the same name, so if there were two with the same > > > behavioral description, we had a conflict. > > > > > > So, I don't think that just because something is a namespace, > > > all of its owned elements have to be owned members. In the > > > case of activity, it is a namespace because it is a kind > > > behavior which is a kind of class, and so it is a namespace > > > for the attributes and operations defined in it. That doesn't > > > mean it has to be a namespace for its activity nodes. > > > > > > We similarly look carefully at other cases that may exist > > > before deciding to make owned elements into owned members. > > > > > > -- Ed > > > > > > > -----Original Message----- > > > > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > > > > Sent: Thursday, March 15, 2007 3:15 AM > > > > To: Nerijus Jankevicius; uml2-rtf@omg.org > > > > Subject: RE: names and namespaces > > > > > > > > Hi Nerijus, > > > > > > > > I think you're right. ActivityNode should subset > ownedMember instead > > > > of ownedElement. Could you file an issue? > > > > > > > > Tim > > > > > > > > > ----------------------------------------------------------------- > > > > Tim Weilkiens > > > > Consultant, Instructor > > > > OMG Representative, INCOSE member > > > > > > > > oose Innovative Informatik GmbH > > > > Tower Falkenried-Piazza, Straßenbahnring 7, D-20251 > Hamburg, Germany > > > > HRB 66648 Amtsgericht Hamburg, USt-Id DE191433946 > > > > CEO Bernd Schröder-Oestereich, Christian Weiss > > > > Phone: +49 (40) 41 42 50-0, Fax: +49 (40) 41 42 50-50 > > > > Internet: www.oose.de, E-Mail: office@oose.de > > > > > > > > > > > > > -----Original Message----- > > > > > From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] > > > > > Sent: Wednesday, March 14, 2007 9:21 AM > > > > > To: uml2-rtf@omg.org > > > > > Subject: names and namespaces > > > > > > > > > > Hello, > > > > > > > > > > Namespace defines derived "member" collection for > > > > > NamedElements identifiable by name. > > > > > However not all Namespaces subset this collection, so > > > > > NamedElements are added just to ownedElements. > > > > > > > > > > Example: Activity and ActivityNodes. Actions and ObjectNodes > > > > > could have identical names because they are not added into > > > > > "ownedMember" collection and are not identified by name. > > > > > Is this correct or bug in metamodel? I believe we could find > > > > > more such Namespaces. > > > > > > > > > > Thanks. > > > > > -- > > > > > 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@magicdraw.com > > > > > WWW: http://www.magicdraw.com > > > > > > > > > > > > > > > > > Subject: RE: names and namespaces Date: Fri, 16 Mar 2007 13:57:35 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: names and namespaces Thread-Index: Acdnbd5Qul7XEc7sQ4uMGnPiDEIzeAAcKEEAAAIe0SAAAzKmQA== From: "Ed Seidewitz" To: Cc: X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org George -- This discussion reminds me of a question based on the following: Subset is documented as being equivalent to subclassing: "The constraint {subsets endA} means that the association end to which this constraint is applied is a specialization of association end endA that is part of the association being specialized." This is interesting. It is also not correct. Notice that it is in the non-normative introductory part of the spec. I think it is left over from earlier versions. You can find normative description of subsetting and derived unions in the semantics part of Section 7.3.44 on Property (near the top of page 129 in formal/07-02-03). See also Section 7.3.3 on Association, particularly the paragraph on page 42 contrasting subsetting to specialization. (And Figure 7.25 on page 48 gives a nice simple example of the way derived unions and subsetting are used in the abstract syntax models.) The statement you quoted should be fixed, to avoid confusion. (Juergen, this should probably be recorded as an issue.) -- Ed